Your managed entry point is published as a name, but a partner allowlisted the single address it resolved once, so why does that break?

## A name in front of a moving set When a platform publishes a managed entry point as a **name**, the name is the contract and the addresses behind it are an implementation detail the platform reserves the right to change. It changes them for ordinary reasons: the pool grows into another availability zone, an unhealthy member is replaced, capacity is rebalanced, or the fleet is migrated. Each resolution of the name is therefore a **snapshot with a lifetime**, and the lifetime is short by design so the platform can move without coordinating with anyone. A partner that resolves the name once and writes the answer into a firewall rule has converted that snapshot into a permanent assumption. Nothing warns them, because nothing they own has changed. ## Which direction the rule points Be precise about the direction, because two different mechanisms are easy to confuse: - **The case here:** the partner calls *you*. Their **outbound** rule names your entry point's address as the permitted destination. What breaks it is your door's address changing. - **The other case:** you call *the partner*, and they permit your **source** address inbound. That one is about the address your traffic leaves from, which is a different subject entirely. Everything below is about the first case: a destination allowlist pointed at a rented front door. ## Why the failure arrives late and looks like nothing The change is silent on both sides, and the gap between cause and symptom is the reason this is a senior question: - The platform adds or replaces an address in the set; your service is entirely healthy throughout. - The old address often keeps answering for a while, as the platform drains it, so nothing fails immediately. - Some of the partner's calls succeed and some fail, depending on which member they had pinned, which reads like an intermittent fault rather than a configuration one. - When it finally fails completely, the last deployment on either side was weeks ago, so the change log points nowhere. - The partner's evidence — a name that resolves fine from a developer's laptop — makes it look like your problem. ## What to offer instead | option | what it gives the partner | what it costs you | |---|---|---| | re-resolve the published name, honour its lifetime | tracks every change the platform makes | requires the partner's stack to resolve names at call time | | a reserved address you allocate and attach | a genuinely stable destination to pin | you hold an allocation, pay for it, and are pinned to it | | the provider's published address ranges | a rule that will not break | far too broad: those ranges cover many tenants, so the rule permits much more than you | | mutual authentication instead of address filtering | proof of who is calling, not where from | a credential or certificate to manage on both sides | The honest answer in most reviews is the second row combined with the fourth: reserve a stable address because the partner's appliance genuinely cannot re-resolve, and put real authentication on the call so the address is a convenience rather than a control. ## An address is not an identity The deeper error underneath the allowlist is treating reachability as authorization. Being able to reach a destination proves nothing about who is calling, and being reached at a known address proves nothing about who is answering. Address filters are a useful blunt reduction of exposure; they are not authentication in either direction, and a design that relies on one to establish trust has one control where it believes it has two. ## Making the decision deliberately When a partner asks for an address, the right response is three questions. Can your side re-resolve at call time — and if not, what is the actual constraint? Is the dependency contractual, so that a change on our side needs a change window on yours? And what authenticates the call, separately from where it comes from? If the answers lead to pinning, pin it properly: reserve the allocation, document that it is now an external contract, and put it on the list of things that an environment rebuild must preserve. A pinned address that nobody recorded as a commitment is the version of this that fails twice.