The Boundaries of the AWS Global Network - Autonomous Systems, Partitions, and What a Private Path Does Not Guarantee

First Published:
Last Updated:

A reviewer asks whether a particular call path meets a control requirement, and the conversation collapses almost immediately. Someone says the traffic never leaves AWS. Someone else says an interface endpoint was added, so it is private. A third person says the bucket policy restricts the principal, so it is fine. Each statement may be individually true and none of them answers the question, because they are answers to three different questions that happen to share the word "secure."

This article separates those three questions and keeps them separate. A network path carries three independent guarantees — where the packets travel, what protects the bytes while they travel, and who is permitted to make the call — and establishing one of them tells you nothing about the other two. Everything else here is in service of that separation: what AWS actually commits to when it says traffic stays on its global network, why autonomous systems and interconnection agreements are the reason the first guarantee has the shape it has, why partitions are a harder boundary than any of them, and how to turn a path into an authorization condition without breaking the services that call on your behalf.

Every fact below was verified against AWS official documentation on 2026-08-09, with the specific page linked at the point of use. This article reports no measurements: no route was traced, no autonomous system path was observed, and no packet capture was taken. Where AWS states something about its own network, that statement is attributed to AWS and quoted within the range AWS actually asserts. Where two official pages say slightly different things, both are shown rather than reconciled by guesswork. No pricing figures appear anywhere in this article, including in the sections where cost is the usual reason people care.

Table of Contents

  1. 1. Introduction: What This Article Settles, and What It Delegates
  2. 2. Three Independent Guarantees
  3. 3. Why the Three Separate: Autonomous Systems and Interconnection
  4. 4. What Staying Inside the AWS Network Actually Means
  5. 5. Encryption in Transit as a Separate Layer
  6. 6. Partitions as a Structural Boundary
  7. 7. Reachability Models by Endpoint Type
  8. 8. Turning the Path into an Authorization Condition
  9. 9. Failure Modes
  10. 10. A Design Checklist for Network Boundaries
  11. 11. Frequently Asked Questions
  12. 12. Summary
  13. 13. References

1. Introduction: What This Article Settles, and What It Delegates

The decision this article supports is narrow and comes up constantly: you have a call path, and you have to state what is and is not guaranteed about it, in terms an auditor or a security reviewer will accept. That is a different task from choosing a connectivity option, and a different task again from designing a segmentation strategy. It is the definitional layer underneath both, and it is the layer that most architecture discussions skip.

Skipping it is expensive in a specific way. When "the traffic stays inside AWS" is treated as a single fact rather than a claim about one of three axes, two errors follow. The first is over-claiming: a control requirement about confidentiality gets signed off on the basis of a routing property. The second is over-building: an interface endpoint gets added to satisfy a requirement that endpoints do not address, and the real gap stays open while the architecture diagram gets more complicated.

1.1 Scope

In scope: the three guarantees and why they are independent; autonomous systems, transit, and peering as the structure that produces the reachability guarantee; the exact scope of what AWS says about traffic staying on its global network; encryption in transit as a distinct layer with its own preconditions; partitions as a boundary that is categorically stronger than the others; the reachability model of each endpoint type; how to express a path as an IAM condition; the failure modes that follow from conflating the three; and a checklist for stating what you can defend.

Out of scope, with delegation:

  • How to configure and operate VPC endpoints — endpoint policies, DNS options, cross-account and cross-Region behavior, and IaC. That is the subject of AWS PrivateLink and VPC Endpoints Complete Guide, and section 7 deliberately stops at the reachability model rather than repeating it.
  • Which connectivity option to choose — peering versus Transit Gateway versus PrivateLink versus Cloud WAN, and the hybrid equivalents. See AWS VPC Connectivity Decision Guide and AWS Hybrid Connectivity Decision Guide.
  • How to design the boundary itself — segmentation, inspection, identity-aware access, and the policy layering that implements it. See AWS Zero Trust Network Architecture Guide, whose opening premise is the same as section 2.3 here and whose subject is the method rather than the definition.
  • Auditing and enforcing encryption in transit inside a Region — the monitor and enforce workflow, the flow log field, and the resource migration path. That is the subject of VPC Encryption Controls, and section 5 hands off to it.
  • Deep treatment of any single partition. Partitions appear here as parallel instances of one structural idea. A dedicated treatment of one of them is a different article.

1.2 How the facts were established

Every AWS behavior stated below comes from an AWS primary source: service user guides, the AWS Fault Isolation Boundaries whitepaper, the Amazon VPC FAQ, the AWS Peering Policy, and AWS What's New announcements. Secondary commentary was not used. Where a value can change — the set of partition identifiers, the instance families that encrypt between instances, the feature set of a recently launched capability — the confirmation date is stated in the text so that a future reader can tell how stale the claim is.

2. Three Independent Guarantees

Start with the three, before any AWS-specific mechanism, because the mechanisms only make sense once the axes exist.

2.1 Reachability path: where the packets travel

This is a statement about topology and routing. It answers "does this traffic transit networks operated by third parties." It is the guarantee people usually mean when they say a path is private, and it is the one AWS makes the most specific public statements about.

What it is good for: data residency and transit questions, and requirements phrased in terms of exposure to the public internet. What it cannot do: it says nothing about who may issue a request, and nothing about whether the bytes are readable to anyone who does get on the path.

2.2 Transport protection: what protects the bytes

This is a statement about cryptography, and it has to be qualified by layer. Physical-layer encryption on the backbone, hardware encryption between instances, bulk encryption applied when traffic leaves a Region, and application-layer TLS are four different mechanisms with four different scopes and four different failure conditions. "Encrypted in transit" without naming the layer is not a usable claim, because the layer determines which adversary the encryption addresses and which components can still see plaintext.

What it is good for: confidentiality and integrity requirements. What it cannot do: it does not restrict who can open a connection, and a path that is fully encrypted end to end is still fully reachable by anyone holding valid credentials.

2.3 Authorization: who is permitted to call

This is a statement about identity and policy. In AWS it is produced by the evaluation of identity-based policies, resource-based policies, permissions boundaries, service control policies, resource control policies, and session policies, and it is entirely independent of how the request arrived.

What it is good for: the actual question of who can read or modify the resource. What it cannot do: it does not change the path, and it does not encrypt anything.

2.4 Why one does not imply another

The three are independent in both directions, and the counterexamples are ordinary rather than exotic.

A path can be fully internal and fully open. Traffic from an instance to a bucket over a gateway endpoint never touches the public internet, and if the bucket policy grants access broadly, the internal path has not made the object less exposed to anyone else who is authorized. A path can be fully encrypted and fully open in exactly the same way. And a path can be tightly authorized and still traverse networks you do not control, because an IAM condition on the principal says nothing about routing.

The reverse implications fail too. Restricting a bucket to a specific VPC endpoint does not encrypt the traffic, and it does not stop a principal inside that VPC from doing whatever the policy allows. Enabling hardware encryption between instances does not prevent the same instances from being reachable from anywhere your security groups permit.

The three independent guarantees and what each one does not establish
The three independent guarantees and what each one does not establish
The practical consequence is a discipline rather than a technique. When someone asserts that a path is secure, ask which of the three they mean, then ask for the evidence for the other two separately. The rest of this article supplies the evidence you should expect for each.

3. Why the Three Separate: Autonomous Systems and Interconnection

The reachability guarantee has the shape it has because of how networks interconnect. This section is the supporting argument for section 2.1, not the subject of the article, so it stays at the level needed to read AWS's own statements precisely.

3.1 The unit of routing

The internet is not a network. It is a set of independently operated networks that agree to exchange reachability information with each other. Each such network is an autonomous system, identified by an autonomous system number, and it makes its own routing decisions. Traffic between two hosts in different autonomous systems reaches its destination because some sequence of autonomous systems has agreed to carry it.

AWS itself operates as an autonomous system in this sense. AWS also exposes autonomous system numbers to customers in two other, unrelated contexts, and it is worth separating them immediately because the terms collide. On AWS Direct Connect virtual interfaces, AWS uses a public autonomous system number on the AWS side and customers announce prefixes with their own; on virtual private gateway and Transit Gateway VPN tunnels, AWS uses a configurable private autonomous system number. Those are properties of a customer's private connection, documented in the AWS Direct Connect routing and BGP guidance and summarized in AWS Networking Glossary. Separately, AWS WAF can match a request against the autonomous system number associated with the client IP address, which is a filtering feature rather than a routing one. Neither of those is what this section is about.

3.2 Transit and peering

Two autonomous systems can interconnect in essentially two commercial shapes.

In a transit relationship, one network pays another to carry its traffic toward the rest of the internet, and the provider announces a full or near-full view of reachable destinations. In a peering relationship, two networks exchange traffic destined for each other and for their respective customers, typically without payment, and each announces only the routes it is willing to serve. Peering is realized either as a direct physical interconnection between two parties, commonly called a private network interconnection, or over a shared fabric at a public internet exchange where many networks connect once and peer with several counterparties.

The distinction matters here for one reason: peering is selective by construction. A peering relationship carries traffic to the destinations the peer chooses to announce, and nothing obliges either side to announce everything or to keep announcing it.

3.3 What AWS publishes about its own interconnection

AWS documents its own posture in the AWS Peering Policy, and it is unusually explicit. The policy states the requirements for parties wishing to peer with AWS's AS16509 network on a settlement-free basis, and it records that AWS peers both at public internet exchange points and over private network interconnections.

Three statements in that policy are load-bearing for anyone reasoning about paths. First, AWS advertises routes selectively at each location, with proximity to Regions and service endpoints named among the factors. Second, AWS reserves the right to advertise, withdraw, or stop advertising routes at its discretion, in order to maintain availability, redistribute traffic, or mitigate abuse. Third, and most directly relevant to a design review, the policy states that peering under it is not a service offering, does not establish a contractual relationship, and is not subject to service level agreements or network availability guarantees. The policy points parties who want supported and managed connectivity with routes to the entire Amazon network toward AWS Direct Connect instead.

Autonomous system interconnection and where an AWS Region sits
Autonomous system interconnection and where an AWS Region sits

3.4 Route control is not a reachability guarantee

Put those together and the reason for the three-way separation becomes concrete. Route advertisement is a mechanism for influencing which path traffic takes, exercised unilaterally by each participant and subject to change. It is not a mechanism for deciding who may reach a service, and it is not a mechanism for protecting the contents of what crosses it. The internet's routing layer has no notion of your identity and no notion of your data.

This is why an AWS statement about traffic staying on the AWS network is a statement about exactly one of the three axes, and why the next section reads it so literally.

4. What Staying Inside the AWS Network Actually Means

4.1 The statement and its exact scope

The Amazon VPC FAQ answers the question directly. Asked whether traffic goes over the internet when two instances communicate using public IP addresses, or when an instance communicates with a public AWS service endpoint, AWS answers no, and states that when using public IP addresses, all communication between instances and services hosted in AWS uses AWS's private network. The FAQ then states the rule in packet terms: packets that originate from the AWS network with a destination on the AWS network stay on the AWS global network, with a stated exception discussed below.

The Amazon VPC User Guide states the same rule with more detail about scope. Packets originating in the private global network with a destination in the private global network stay in it and do not traverse the public internet, and AWS says explicitly that this holds whether the destination address is private or public. The guide gives the two-VPC case using public IP addresses as its worked example, and states that the destination may be in the same Availability Zone, a different Availability Zone in the same Region, or a different Region.

Read carefully, the useful precision is in three places. The rule is expressed in terms of origin and destination both being on the AWS network, not in terms of address type. It is a statement about the path, not about protection or permission. And it explicitly extends across Regions, which is what makes the exception in the next subsection significant rather than a footnote.

4.2 Two official pages, two different exception lists

Both pages carve out an exception, and as confirmed on 2026-08-09 they do not carve out the same one.

  • The Amazon VPC FAQ states the exception as traffic to or from AWS China Regions and the AWS European Sovereign Cloud Region.
  • The Amazon VPC User Guide states the exception as the China Regions.

This article does not adjudicate which page is more current, and you should not build a control narrative on the narrower of the two. The defensible reading is structural rather than geographic: the guarantee is stated for traffic within a partition, and traffic that crosses a partition line should be treated as outside the guarantee until an AWS source says otherwise for the specific pair you care about. Section 6 develops why that reading is the safe one, and it is the same reading that survives the next time AWS adds a partition.

The general discipline generalizes past this one example. When a control claim rests on a single sentence in AWS documentation, check whether a second AWS page states the same rule, and record the confirmation date next to the claim in your own design document. Two pages agreeing is a much stronger position in a review than one page quoted from memory.

4.3 What the statement does not say

The statement is about the path. Enumerating what it leaves untouched is the whole point of reading it precisely.

It does not say the traffic is encrypted. Encryption on the AWS network is a separate set of mechanisms with their own conditions, covered in section 5, and the FAQ itself presents encryption as an additional fact rather than as part of the routing answer.

It does not say the resource is unreachable by others. A public service endpoint reached over the AWS network is the same endpoint anyone else reaches. The path your packets take has no bearing on whose packets also arrive.

It does not say the traffic is invisible to your own account boundary problems. Cross-account access that stays entirely on the AWS network is still cross-account access.

And it does not say you can dispense with the controls that address the other two axes. This is the practical reason PrivateLink, endpoint policies, and IAM conditions remain necessary even though the routing question is already answered favorably: they answer different questions.

4.4 Where the boundary is being redrawn

Two developments are worth knowing because they change what the phrase "inside AWS" can mean in a design conversation.

The first is auditability. Until recently, the encryption facts in section 5 were things you reasoned about from documentation and instance types. Amazon VPC Encryption Controls turns them into something you can observe and enforce per VPC, which moves transport protection from an argument into a control. Section 5.4 covers what it exposes.

The second is that AWS now offers a first-party path to other cloud providers. AWS Interconnect - multicloud reached general availability on 2026-04-13 with Google Cloud as the launch partner, per the AWS What's New announcement, and a separate announcement records general availability with Oracle Cloud Infrastructure in July 2026, with Microsoft Azure stated as coming later in 2026. For the purposes of this article the point is not the feature but the framing it forces: a private path to a destination that is not AWS is still a path whose transport protection and authorization you must establish separately, and the destination sits under a different provider's identity system entirely.

5. Encryption in Transit as a Separate Layer

Transport protection on AWS is not one mechanism. It is at least four, and they compose rather than substitute. Every claim below is from the Amazon EC2 data protection documentation unless otherwise attributed, confirmed 2026-08-09.

5.1 The physical layer

AWS states that all data flowing across AWS Regions over the AWS global network is automatically encrypted at the physical layer before it leaves AWS secured facilities, and that all traffic between Availability Zones is encrypted. AWS presents further layers as additive rather than alternative.

What this covers is the wire between facilities. What it does not cover is anything inside a facility that you are responsible for, and it is not a substitute for protection that is visible to your application. It is also not something you configure, which means it is not something you can point at as evidence of a control you operate.

5.2 Instance-to-instance encryption and its three preconditions

Some instance types use the offload capabilities of the underlying Nitro System hardware to automatically encrypt in-transit traffic between instances. AWS describes the encryption as using Authenticated Encryption with Associated Data algorithms with 256-bit encryption, and states that there is no impact on network performance.

The preconditions are the part that gets dropped in summaries, and all three must hold:

  1. Both instances use one of the instance types AWS enumerates as supporting it. The list spans general purpose, compute optimized, memory optimized, storage optimized, accelerated computing, and high-performance computing families, and it grows with new generations, so it should be read from the documentation rather than remembered.
  2. The instances are in the same Region.
  3. The instances are in the same VPC or in peered VPCs, and the traffic does not pass through a virtual network device or service, with a load balancer and a transit gateway named as examples.

That third condition is the one that quietly invalidates the claim in real architectures. An architecture that routes east-west traffic through a shared inspection layer, a Transit Gateway hub, or a load balancer has an intermediate hop, and the instance-to-instance encryption AWS describes does not apply across it. The physical-layer statement in section 5.1 still holds, and application-layer TLS still holds if you are using it, but the specific hardware encryption does not.

Rather than tracking the type list by hand, AWS documents a query that returns the current set:

aws ec2 describe-instance-types \
    --filters Name=network-info.encryption-in-transit-supported,Values=true \
    --query "InstanceTypes[*].[InstanceType]" \
    --output text | sort

The same property is available at provisioning time. The EC2 attribute-based instance type selection request structure exposes RequireEncryptionInTransit, which defaults to false, so a fleet can be constrained to encrypting types declaratively instead of by maintaining an allow list.

5.3 Cross-Region peering

AWS states that all cross-Region traffic using Amazon VPC peering and Transit Gateway peering is automatically bulk-encrypted when it exits a Region, with the physical-layer encryption applying as an additional layer before traffic leaves AWS secured facilities.

Note the scope carefully: this is about traffic leaving a Region over those two mechanisms. It is not a general statement that anything crossing a Region boundary by any means receives that specific treatment.

5.4 The application layer, and where auditing moved

Application-layer TLS remains the only layer that is under your control end to end, that survives intermediate hops, and that you can demonstrate from the client side. Nothing below it removes the need for it.

What has changed is that the state of the layers underneath is now observable. Amazon VPC Encryption Controls, documented in Enforce VPC encryption in transit, operates in two modes. Monitor mode provides visibility into the encryption status of traffic flows between resources inside and across VPCs, adds an encryption-status field that VPC Flow Logs can emit, and exposes a GetVpcResourcesBlockingEncryptionEnforcement operation for identifying resources that are not enforcing encryption in transit. Enforce mode prevents the use of features and services that allow unencrypted traffic within the VPC boundary, and AWS states that an existing VPC cannot be switched to enforce mode directly: it must be enabled in monitor mode first, with non-compliant resources remediated or explicitly excluded. New VPCs can be created with enforce mode on.

One consequence is worth flagging here because it connects transport protection back to reachability. AWS states that in enforce mode, traffic that is not encrypted at the application layer is dropped by PrivateLink endpoints hosted inside the VPC. That is a case where a transport-protection control changes reachability behavior, which is exactly why the two need to be reasoned about separately before they are combined.

The operational workflow — reading the flow log field, working through the blocking-resource inventory, deciding which exclusions are acceptable, and sequencing the migration to enforce mode — is the subject of VPC Encryption Controls rather than this one.

Enabling enforce mode on a VPC that carries production traffic can break existing workloads. Treat it as a change with a rollback plan, run monitor mode long enough to see the full inventory, and do not enable it as part of a verification exercise.

6. Partitions as a Structural Boundary

Everything so far has been about degrees. Partitions are different in kind, and they are the one boundary in this article that cannot be crossed by configuration, by permission, or by adding a network path.

6.1 The identifiers and the ARN field

AWS groups Regions into partitions. The AWS Fault Isolation Boundaries whitepaper states the structure directly: every Region is in exactly one partition, each partition has one or more Regions, and partitions have independent instances of AWS Identity and Access Management, providing a hard boundary between Regions in different partitions.

The partition is the second field of every Amazon Resource Name, immediately after the literal arn prefix:

arn:aws:s3:::example-bucket
arn:aws-us-gov:s3:::example-bucket

The identifiers confirmed on 2026-08-09 from AWS sources are as follows. This table is not a claim of completeness — it lists the identifiers that appear in the AWS sources cited, as of the confirmation date, and AWS operates additional infrastructure whose identifiers are not enumerated in these general-purpose references.

IdentifierNamed inSource
awsAWS commercial RegionsFault Isolation Boundaries whitepaper, CloudFormation pseudo parameter reference
aws-cnRegions in ChinaFault Isolation Boundaries whitepaper, CloudFormation pseudo parameter reference
aws-us-govAWS GovCloud RegionsFault Isolation Boundaries whitepaper, CloudFormation pseudo parameter reference
aws-euscAWS European Sovereign CloudAWS SDK API reference for the partner selling model

Two things follow from the table's provenance. The whitepaper and the CloudFormation reference both enumerate three identifiers, while a fourth appears in a service API reference, which means any list of partitions you write down is a snapshot of the sources you consulted rather than an enumeration of what exists. Record the date and the sources next to the list, and re-derive it rather than trusting an old copy.

6.2 One IAM per partition

The single most consequential property is that IAM is instantiated separately per partition. The Fault Isolation Boundaries whitepaper states that you cannot use IAM credentials from one partition to interact with resources in a different partition.

The same whitepaper's treatment of global services makes the shape of this explicit. Services it calls partitional — IAM, AWS Organizations, AWS Account Management, and others — have their own control plane and data plane in each partition, and a failure in one partition's instance does not affect another. In the aws partition the IAM control plane is in us-east-1 with regionalized data planes; equivalent independent planes exist in the other partitions.

This is why the boundary is categorically different from the others in this article. A routing boundary can be changed by adding a connection. An encryption boundary can be changed by changing instance types. An authorization boundary can be changed by editing a policy. A partition boundary cannot be crossed by any of those, because the identity system on the other side has never heard of your principal.

6.3 What cannot cross

The whitepaper states that capabilities designed to provide cross-Region functionality, giving Amazon S3 Cross-Region Replication and AWS Transit Gateway inter-Region peering as examples, are supported only between Regions in the same partition.

The consequence for architecture is that a multi-partition estate is not a multi-Region estate with extra Regions. It is two estates. Replication between them is an application-level data movement problem with its own authentication story, not a feature you enable. Centralized logging, centralized security tooling, and centralized identity all need a deliberate design that acknowledges two independent identity systems rather than one.

Partitions as a hard boundary
Partitions as a hard boundary

6.4 Writing policies and templates that survive

The everyday cost of ignoring partitions is not an outage. It is a body of policy and template code that silently only works in one partition.

In CloudFormation, the pseudo parameter AWS::Partition returns the partition the resource is in, and AWS states that using it is what makes templates work correctly across partitions:

Resources:
  ExampleRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: !Sub "ec2.${AWS::URLSuffix}"
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonSSMManagedInstanceCore"

For handwritten IAM policies, a wrong partition in a resource ARN is a detectable defect rather than a subtle one. IAM Access Analyzer's policy validation includes an INVALID_PARTITION check, documented in the policy validation check reference, which reports an error when the resource ARN for a service does not support the partition given. Running policy validation in a pipeline turns a class of portability bugs into a build failure. The IAM Policy Analyzer tool on this site is useful for inspecting the structure of a policy while you are working on it.

A practical rule that costs nothing: treat a literal arn:aws: in source-controlled policy or template code as a finding, and require either a partition variable or an explicit comment stating that the artifact is partition-specific by design.

7. Reachability Models by Endpoint Type

Endpoint types are usually compared by what they cost to run and which services support them. Here they are compared on one axis only: what the name resolves to, and therefore where the packets go. Implementation detail is delegated to AWS PrivateLink and VPC Endpoints Complete Guide.

The type taxonomy is from AWS PrivateLink concepts, confirmed 2026-08-09. AWS lists Interface, GatewayLoadBalancer, Resource, and Service network as VPC endpoint types, and separately notes Gateway endpoints for Amazon S3 and DynamoDB, which AWS states do not use AWS PrivateLink unlike the other types.

7.1 The public service endpoint

With no endpoint at all, the service name resolves to a public address, and the request follows whatever route exists from the source to that address. If the source is inside AWS, section 4 applies and the packets stay on the AWS global network within the partition. If the source is on-premises, they do not.

The reachability consequence that matters: the destination is a shared, publicly addressable endpoint. Your request arriving over an internal path does not make it a different endpoint from the one everyone else uses.

7.2 Gateway endpoints

A gateway endpoint is a route table entry rather than an address in your VPC. Creating one produces a prefix list, and the prefix list identifier is placed in the route tables of the subnets that should use it, as described in AWS prescriptive guidance for private-network configurations. DNS resolution is unchanged — the service name still resolves to public addresses — and the redirection happens in routing, because those addresses are in the prefix list.

Two consequences follow. First, a gateway endpoint is not reachable from outside the VPC, because a route table entry has no address that an on-premises network can send to. Second, whether a given flow uses the endpoint depends on which route table the source subnet is associated with, which makes an accidental route table association a silent reachability change.

7.3 Interface endpoints and private DNS

An interface endpoint is one or more elastic network interfaces with private addresses from your subnets. Creating it generates endpoint-specific regional DNS hostnames that resolve to those addresses.

The behavior that produces the most surprises concerns private DNS. When private DNS is enabled, the default service hostname resolves to the endpoint addresses — but, as AWS describes in its guidance on centralized DNS management with Route 53 and Transit Gateway, that resolution applies in the VPC where the endpoint resides. Other VPCs continue to resolve the public address unless you deliberately extend resolution to them, for example with a private hosted zone associated to those VPCs and an alias record targeting the endpoint-specific hostname.

The reachability model to hold in your head is therefore: an interface endpoint changes what a name resolves to, per VPC, and everything downstream of that follows from resolution. A spoke VPC that was assumed to use a centralized endpoint but was never associated with the hosted zone is not using it, and nothing about the endpoint's existence will tell you so.

7.4 Resource endpoints and service-network endpoints

A resource endpoint, per AWS PrivateLink concepts, is used to access a resource shared with you that resides in another VPC — AWS gives a database, an EC2 instance, an application endpoint, a domain-name target, or an IP address as examples, including in a private subnet in another VPC or in an on-premises environment. AWS states that resource endpoints do not require a load balancer and let you access the resource directly.

A service-network endpoint provides access to a service network you created or that was shared with you, and AWS states that a single service-network endpoint can be used to privately access multiple resources and services associated with that network. That model overlaps with AWS VPC Lattice Complete Guide, which is where the service-network abstraction is treated properly.

The reachability point is that these two shift the granularity of the endpoint from "one service" to "one resource" and "one network of services" respectively, which changes what a single endpoint's blast radius is when you write a policy condition against it in section 8.

7.5 What an endpoint changes and what it leaves alone

QuestionPublic endpointGateway endpointInterface endpoint
What the service name resolves toPublic addressPublic address, unchangedPrivate address in your subnet, when private DNS is enabled
How the packets are steeredNormal routingRoute table entry using a prefix listDNS resolution
Reachable from on-premises over a private connectionNot without a path to the public addressNoYes, subject to DNS and routing
Restricts who else can reach the serviceNoNoNo
Encrypts the trafficNoNoNo
Provides a value for a policy conditionNoYes, the endpoint identifierYes, the endpoint identifier

The last three rows are the ones this article exists to make unmissable. No endpoint type encrypts anything, and no endpoint type restricts anyone but you. What endpoints give you on the authorization axis is not a restriction but a fact about the request — an identifier that arrives in the request context and that you can then write a policy against. That is the subject of section 8.

8. Turning the Path into an Authorization Condition

The three guarantees are independent, but they are not unrelated. The bridge between the reachability axis and the authorization axis is a small set of global condition keys that make the path visible to policy evaluation. All key behavior below is from the AWS global condition context keys reference, confirmed 2026-08-09.

8.1 The path condition keys

aws:SourceVpce compares the VPC endpoint identifier of the request with an endpoint identifier you specify. AWS states that the key is included in the request context only if the requester uses a VPC endpoint to make the request. aws:SourceVpc works the same way for the VPC that hosts the endpoint.

The availability qualifier is the important part, and it drives the policy shape. A key that is absent from the request context does not match a positive condition, which means these keys are used in Deny statements far more often than in Allow statements. A bucket policy that denies everything not arriving through a named endpoint is the canonical form:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessOutsideTheExpectedEndpoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        },
        "Bool": {
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

The aws:PrincipalIsAWSService clause is not decoration; section 8.3 explains why omitting it is the most common way this pattern causes an outage.

One more behavior is worth knowing before you reach for a network condition at all: AWS notes that aws:SourceIp is not effective when the request comes from a VPC endpoint, and directs you to the endpoint keys instead. An address-based condition inherited from a pre-endpoint design will simply stop matching.

8.2 Organization-scoped conditions

The path is one way to describe where a request came from. Organization membership is another, and the two compose well.

aws:PrincipalOrgID compares the organization identifier of the requesting principal against a value in the policy. AWS presents it as an alternative to enumerating every account, and notes two things that matter operationally: policies using it automatically pick up accounts as they are added and removed, and the condition also applies to the management account of the organization.

aws:ResourceOrgID is the mirror image, letting a policy assert something about the organization owning the resource being accessed. The canonical use is denying data movement to resources outside your own organization, and AWS documents the pattern with aws:ResourceOrgID compared against the policy variable ${aws:PrincipalOrgID}. AWS also warns that some services require access to AWS-owned resources hosted in another account, and that using this key in identity-based policies can impede those services unless exemptions are written.

How these interact with service control policies and resource control policies at the organization level is treated in AWS Organization Guardrails with SCP and RCP.

8.3 The context that disappears on service-to-service calls

This is the failure mode that turns a correct-looking policy into an incident, and it is documented plainly enough that there is no excuse for being surprised by it.

When an AWS service makes a call to another AWS service on your behalf, certain network-specific authorization context is redacted. For aws:SourceVpce, AWS states that the source VPC endpoint of the initial request is not preserved through a forward access session, and that you must use aws:ViaAWSService or aws:CalledVia to allow requests made by AWS services in that way. Separately, AWS warns that if your policy uses these keys with Deny statements, AWS service principals might be unintentionally blocked, and recommends excluding them with aws:PrincipalIsAWSService set to false.

The practical checklist before deploying any network-conditioned Deny:

  1. Enumerate every AWS service that touches the resource on your behalf, including logging and backup destinations that nobody thinks of as callers.
  2. Add the service-principal exclusion, and decide deliberately whether aws:ViaAWSService or aws:CalledVia is also needed for the paths you intend to permit.
  3. Deploy to a non-production account first, and watch for access denials from service principals rather than from users, because those are the ones that will not show up in a functional test.
  4. Remember that the same redaction logic applies to any other network-derived key you might add later.

The S3 Bucket Policy Generator tool on this site is a convenient way to assemble and inspect the resulting statement before you commit it.

8.4 One table for both boundaries

The reason to do this work is that it lets the network boundary and the identity boundary be reviewed as one design rather than two, which is what a reviewer is implicitly asking for.

What you want to assertNetwork mechanismPolicy mechanismWhat it still does not give you
The request came through a specific private entry pointInterface endpointaws:SourceVpce in a DenyAny statement about encryption
The request came from a specific networkInterface endpoint in that VPCaws:SourceVpc in a DenyProtection against a compromised principal inside that VPC
The caller belongs to my organizationNoneaws:PrincipalOrgIDAny statement about the path taken
My data is not written outside my organizationNoneaws:ResourceOrgIDCoverage of service-owned resources without explicit exemptions
Traffic within the VPC boundary is encryptedVPC Encryption Controls in enforce modeNoneAnything about who is authorized
The resource cannot be reached from another partitionPartition boundary, structuralNone neededNothing, this one is absolute

Whichever pairing you choose, an authorization decision built on a network fact inherits the fragility of that fact. Endpoint identifiers change when endpoints are recreated, route table associations change during unrelated work, and DNS behavior differs per VPC. Section 9 is the catalog of what that costs. The broader method for layering these controls deliberately is the subject of AWS Zero Trust Network Architecture Guide.

9. Failure Modes

Each of these follows directly from conflating two of the three guarantees. They are presented as things to look for in a design review, not as attacks.

9.1 Reading "inside AWS" as "not exposed"

The pattern: a requirement about preventing unauthorized access is closed out by citing the statement in section 4.1. The reasoning is that traffic stays on the AWS network, so the resource is not exposed.

Why it fails: the statement is about the path your traffic takes. It says nothing about the resource policy, and a broadly permissive policy on a resource reached over an internal path is exactly as permissive as the same policy on a resource reached any other way.

What to check: for every control that was signed off with a routing argument, find the corresponding authorization evidence. If none exists, the control is unaddressed regardless of how good the routing story is.

9.2 Cross-account reachability nobody modeled

The pattern: an account boundary is treated as a network boundary, on the assumption that separate accounts are separate environments.

Why it fails: accounts within a partition share the same address-agnostic service endpoints and the same identity system. A resource policy that grants another account, or a role trust policy that trusts a broad principal, produces reachability that no network diagram shows. This is compounded when the resource is reached over an interface endpoint, because the diagram then looks even more contained than it is.

What to check: inventory resource-based policies and role trust policies for principals outside the account, and confirm that each is intended. IAM Access Analyzer's external access findings exist for this, and IAM Access Analyzer Deep Dive covers the analysis in depth.

9.3 DNS that resolves somewhere else

The pattern: a centralized endpoint VPC is built, everything is declared private, and one workload keeps reaching the public endpoint.

Why it fails: private DNS for an interface endpoint takes effect in the VPC where the endpoint resides, and other VPCs keep resolving the public name unless resolution is extended to them explicitly. Nothing errors. The traffic still works, still stays on the AWS network per section 4, and still bypasses the endpoint policy you wrote.

What to check: resolve the service hostname from inside each VPC that is supposed to be using the endpoint and confirm the answer is a private address in the expected range. Treat this as a recurring check rather than a one-time one, because new VPCs are created by people who were not in the original design conversation.

9.4 A Deny that locks out AWS itself

The pattern: the endpoint-restricting bucket policy from section 8.1 is deployed without the service-principal exclusion, and log delivery, replication, or backup silently stops.

Why it fails: section 8.3. The network context of the original request is not preserved through a forward access session, so a service calling on your behalf does not satisfy a condition on the endpoint identifier and is caught by the Deny.

What to check: before deployment, the four steps in section 8.3. After deployment, look specifically for denials attributed to service principals, and confirm that anything that writes into the resource asynchronously is still writing.

9.5 The hardcoded partition

The pattern: policies and templates full of arn:aws: literals, discovered only when a workload is asked to run in a different partition.

Why it fails: the partition is part of the resource identity, and no amount of permission fixes an ARN that names a partition the account is not in. Because it is a portability failure rather than a security failure, nothing detects it until the day it matters.

What to check: add INVALID_PARTITION policy validation to the pipeline, use AWS::Partition in templates, and grep source control for literal partition prefixes as a periodic hygiene task.

10. A Design Checklist for Network Boundaries

Use this to convert an assertion into something defensible. Each item asks for the evidence a reviewer should expect, and the three groups deliberately do not share evidence.

Reachability path

  1. State the source and the destination, and confirm both are on the AWS network within the same partition. If either is not, the guarantee in section 4 does not apply as written.
  2. Name the endpoint type in use and state what the service hostname resolves to, verified from inside the VPC in question rather than assumed.
  3. If a gateway endpoint is involved, name the route tables the prefix list was added to and confirm the source subnet is associated with one of them.
  4. Confirm no intermediate hop was introduced that the design does not account for, and record it if one was, because section 5.2 depends on it.
  5. Record the confirmation date and the AWS page cited for any statement about traffic staying on the AWS network, and check that a second AWS page agrees.

Transport protection

  1. Name the layer you are claiming. Physical, instance-to-instance, cross-Region bulk, and application TLS are separate claims with separate evidence.
  2. For instance-to-instance encryption, verify all three preconditions, not just the instance type, and verify them again after any change that inserts a load balancer or a transit gateway.
  3. State whether application-layer TLS is enforced, and whether it is enforced by configuration or merely used by convention.
  4. If you rely on VPC Encryption Controls, state which mode the VPC is in, list the exclusions, and state who reviews them.

Authorization

  1. List every policy type that participates in the decision, and confirm the effective outcome rather than reading a single policy.
  2. If a network condition key is used, confirm the service-principal exclusion is present and that every asynchronous caller was enumerated.
  3. Confirm that no Allow depends on a condition key that is absent when the request does not come through an endpoint.
  4. Inventory resource-based and trust policies for principals outside the account, and confirm each is intentional.

Partition

  1. Confirm that no ARN in source-controlled artifacts hardcodes a partition without a deliberate, documented reason.
  2. Confirm that no cross-Region feature in the design is expected to operate between partitions.

A useful test of whether the checklist is being used honestly: each of the three groups should be answerable without referring to the other two. If the evidence for authorization is "the traffic is private," the separation has collapsed again. Complementary VPC-level review items are collected in VPC Design Review Checklist.

11. Frequently Asked Questions

If traffic between AWS services never leaves the AWS network, why use PrivateLink at all?

Because the routing guarantee is one of three, and PrivateLink addresses different parts of the other two. An interface endpoint gives you an endpoint identifier that appears in the request context, which is what makes a policy condition on the path possible at all; it changes name resolution so that on-premises networks can reach the service over a private connection; and it gives you an endpoint policy as an additional evaluation point. None of those follow from the routing statement.

Does an interface endpoint encrypt my traffic?

No. Endpoint type and encryption are independent. Encryption comes from the mechanisms in section 5, and application-layer TLS remains your responsibility regardless of endpoint type.

Is traffic between two Availability Zones encrypted?

AWS states that all traffic between Availability Zones is encrypted, in the Amazon EC2 data protection documentation. That is a physical-layer statement about AWS infrastructure. It is not the same claim as the instance-to-instance hardware encryption in section 5.2, which has its own three preconditions.

Our instances are Nitro-based, so is traffic between them encrypted?

Only if all three conditions in section 5.2 hold. The most commonly violated one is the third: traffic must not pass through a virtual network device or service such as a load balancer or a transit gateway. An architecture that hair-pins east-west traffic through a shared hop does not satisfy it.

How many AWS partitions are there?

The honest answer is that you should derive the list from current AWS sources rather than memorize it. Section 6.1 lists the identifiers found in the AWS sources cited there as of 2026-08-09, and notes that the whitepaper and the CloudFormation reference enumerate three while a fourth appears in a service API reference. Treat any list, including that one, as a dated snapshot.

Can I replicate an S3 bucket into another partition?

Not with S3 Cross-Region Replication. The Fault Isolation Boundaries whitepaper states that cross-Region capabilities of that kind are supported only between Regions in the same partition. Moving data across a partition boundary is an application-level problem with its own authentication design, because the credentials on one side are not valid on the other.

Why did my bucket policy break log delivery?

Most likely section 8.3. A Deny conditioned on aws:SourceVpce catches AWS services calling on your behalf, because the source endpoint of the original request is not preserved through a forward access session. Exclude service principals with aws:PrincipalIsAWSService and decide deliberately about aws:ViaAWSService or aws:CalledVia.

Can I use aws:SourceIp instead of the endpoint keys?

Not for requests arriving through a VPC endpoint. AWS states that aws:SourceIp is not effective in that case and directs you to aws:SourceVpce or aws:SourceVpc.

Does the AWS Peering Policy tell me how my traffic will be routed?

No, and it is explicit about that. The policy states that AWS advertises routes selectively and may advertise, withdraw, or cease advertising them at its discretion, and that peering under the policy is not a service offering and carries no availability guarantees. For supported connectivity, the policy points to AWS Direct Connect.

What is the single most useful habit from all of this?

Write the confirmation date next to every claim about AWS network behavior in your design documents, and cite the page. The claims in this area are stable enough to rely on and volatile enough to be wrong a year later, and a dated citation is the difference between a document that can be re-verified and one that has to be rewritten.

12. Summary

The one idea worth carrying away is that a network path carries three independent guarantees, and evidence for one is not evidence for another. Reachability is about where packets travel. Transport protection is about what secures the bytes, at a layer you must name. Authorization is about who may make the call. Most disagreements about whether an AWS architecture is "private enough" are disagreements about which of the three is under discussion.

On reachability, AWS makes a specific and useful commitment: packets originating on the AWS network with a destination on the AWS network stay on the AWS global network, across Availability Zones and across Regions, whether the addresses involved are private or public. Two official pages state the exception differently as of 2026-08-09, and the reading that survives both is the structural one — the guarantee holds within a partition.

The reason the guarantee has that shape is interconnection. AWS operates as an autonomous system and states in its own peering policy that it advertises routes selectively, may withdraw them at its discretion, and offers no availability guarantee for peering. Route control decides paths, not permissions and not confidentiality.

On transport protection, at least four mechanisms compose: physical-layer encryption on the backbone and between Availability Zones, hardware encryption between qualifying instances under three preconditions that include the absence of an intermediate network device, bulk encryption on cross-Region peering traffic leaving a Region, and application-layer TLS. VPC Encryption Controls turns the state of the lower layers from an argument into an observable control, with monitor and enforce modes and a mandatory monitor-first path for existing VPCs.

Partitions are the one boundary of a different kind. Every Region belongs to exactly one, each has its own IAM instance, credentials do not carry across, and cross-Region features work only within a partition. That is not a control you configure; it is a property of the estate, and the cost of ignoring it is a body of code that hardcodes one partition into every ARN.

Finally, the bridge between the reachability axis and the authorization axis is a small set of condition keys, and using them safely requires knowing that network context is redacted on service-to-service calls. A Deny conditioned on an endpoint identifier without a service-principal exclusion is the most reliable way to break log delivery in this entire subject area.

13. References



References:
Tech Blog with curated related content

Written by Hidekazu Konishi