LEARN. PRACTICE. GROW.1. Start with the consumer-service relationship
An application team needs to query positions from another department's service. Before choosing an endpoint, record the connection initiator, protocol, destination location and intended access scope. A gateway endpoint for S3 or DynamoDB changes forwarding through service prefixes; it does not provide a general passage into partner networks. An interface endpoint supplies private interfaces for a compatible service. Eligible shared resources can also use a resource endpoint without requiring an NLB. The choice depends on the resource and supported capabilities, not merely the PrivateLink name. In the project design, show each consumer's actual path and the application's controls. A private connection does not prove that its user may read every position.
2. Follow DNS and routing separately
A name resolving to a private address still needs a usable path. Interface endpoint-specific names can be publicly resolved while returning private addresses; that does not make the service reachable from the Internet. With private DNS and the required VPC DNS attributes, the familiar service name can point to endpoint interfaces. For on-premises consumers, identify both Resolver-based name resolution and connectivity to the returned addresses. In an S3 design containing both endpoint types, private DNS only for queries arriving through an inbound Resolver allows the hybrid path to differ from the local gateway path. Also check record-type and address-family compatibility. Testing an alternative name does not prove which path the production SDK actually uses.
3. Separate service admission from operation authorization
For a shared endpoint service, allowed principals and connection acceptance control consumer admission. Broad permissions combined with automatic acceptance can admit accounts the project never intended to serve. Removing a principal from the allowlist does not terminate endpoint connections that were already accepted. Revocation therefore needs an explicit plan for existing consumers and application controls. For AWS services supporting endpoint policies, these policies add restrictions to the path; they do not replace identity or resource policies. Do not assume an endpoint policy can authorize operations in a third-party application. Acceptance should include an allowed operation, a forbidden operation and an attempt by a consumer that already had access before the change. Record the expected result for each before testing.
4. Demonstrate redundancy of the actual path
Two consumer interfaces alone do not demonstrate two healthy copies of the service. Relate endpoint Availability Zones, NLBs and the targets processing the operation. Across accounts, use AZ IDs to compare physical locations because zone names can differ. A zonal name restricts the client's choice; a regional name does not guarantee recovery of established sessions. If several NLBs are associated with the same service, maintain equivalent listener and target contracts. For access across Regions, check permissions and supported Regions. PrivateLink-managed failover between AZs is not automatic disaster recovery into another Region. The exercise should measure application success after failure and reconnection, including business tolerance, without confusing network availability with acknowledgement of an instruction.
5. Prepare DNS, address and policy changes
The provider proves ownership of a private DNS name using a public TXT record. Ownership proof and private consumer resolution serve different purposes. Before cutover, confirm verification state, authoritative-server answers and the name the application actually uses. Permission, DNS or routing changes can affect new and existing consumers differently. When introducing an S3 gateway endpoint, account for TCP connection interruption and test reconnection without duplicating operations. If a bucket policy begins requiring a particular endpoint, include administrative tools and integrations in the exercise, not only the main batch. Prepare the return to the previous path with policy owners, avoiding a network rollback that remains blocked by authorization. Record which controls must move together.
6. Hand useful evidence to production
The RUN handover should make resolution, transport and authorization failures distinguishable. Record the queried name, returned addresses, endpoint and AZ used, application identity and operation result. Keep secrets and customer data out of training evidence. In a fictional exercise, a new partner is rejected after a change while an already accepted endpoint remains operational: this observation is consistent with changed admission and does not demonstrate complete revocation. The local model below makes that distinction visible using supplied states. It does not interpret IAM, create endpoints or terminate connections. Production owners need the negative tests, ownership of each control and the authorized procedure for removing an existing consumer. Acceptance evidence should identify which conclusion each observation supports.
def can_create(principal, allowed):
return principal in allowed or "*" in allowed
def accepted_connection(endpoint, accepted):
return endpoint in accepted
allowed = {"partner-a"}
accepted = {"endpoint-old"}
assert can_create("partner-a", allowed)
assert not can_create("partner-b", allowed)
allowed.remove("partner-a")
assert not can_create("partner-a", allowed)
assert accepted_connection("endpoint-old", accepted)
accepted.remove("endpoint-old") # supplied state after a separate removal, not an AWS call
assert not accepted_connection("endpoint-old", accepted)
print("five admission-state checks passed; no endpoint access changed")
Fictional example: the funds team removes a supplier account from allowed principals. An attempt to create another endpoint is rejected, but the previous consumer can still query positions. The team identifies the accepted connection and validates the revocation procedure with the service owner, including application authorization and a negative test.
Common pitfalls
Treating private addresses as authorization; using a gateway endpoint from another network; assuming permission removal deletes accepted consumers; confusing AZ failover with regional DR.
Related topics: Hybrid DNS · Policies and identity · Change and RUN handover
Accept the complete path and test the lifecycle of both new and existing consumers.
Reference: Gateway endpoints · ANS-C01