DEV Community: Toqeer Afzal

NAT Gateway vs VPC Endpoints: Which Path Should Your Private AWS Traffic Take?

Toqeer Afzal — Sat, 17 Oct 2026 16:23:17 +0000

Private subnets are one of the first good habits you learn in AWS. Put your EC2 instances, containers and databases where the internet cannot start a connection to them, and you remove a large class of risk.

The catch is that private workloads still need to talk to things: operating system repositories, third-party APIs, and AWS services such as Amazon S3. AWS gives you more than one way to make that happen, and they are not interchangeable.

This article walks through three tools:

NAT Gateway for outbound access from private subnets.
S3 Gateway Endpoint for free, route-table-based access to S3 from inside one VPC.
S3 Interface Endpoint (AWS PrivateLink) for private S3 access that can extend beyond the VPC, for example to on-premises networks.

By the end you should be able to look at a requirement and pick the right one, and explain why.

Note on sources. Technical statements here are based on the official AWS documentation and blog posts listed in the References section. Prices change and differ by Region, so I describe the cost model and point you to the AWS pricing pages instead of quoting numbers as universal facts. Console labels may change over time.

Understanding AWS VPC networking

A quick vocabulary pass before the comparisons.

VPC: your isolated virtual network in AWS, defined by one or more CIDR ranges.
Public subnet: a subnet whose route table has a route to an Internet Gateway (IGW).
Private subnet: a subnet with no direct route to an IGW. Its resources use private IP addresses only.
Route table: the list of rules that decides where traffic leaves a subnet. The most specific matching route wins.
Internet Gateway: the VPC component that connects public subnets to the internet. It handles the mapping between a public IPv4 address and a private one for resources that have a public address.
NAT Gateway: a managed service that lets resources in a private subnet start outbound connections without exposing them to unsolicited inbound traffic.
ENI (Elastic Network Interface): a virtual network card with a private IP address. Interface endpoints are built from ENIs.

How does a private instance reach an AWS service?

An EC2 instance in a private subnet that runs aws s3 cp has three realistic options:

Go out through a NAT Gateway to the service's public endpoint.
Use an S3 Gateway Endpoint, selected by a route in the subnet's route table.
Use an S3 Interface Endpoint, reached at a private IP address inside the VPC.

flowchart LR
    EC2["Private EC2 instance"] --> RT{"Private route table"}
    RT -->|"0.0.0.0/0"| NAT["NAT Gateway (public subnet)"]
    NAT --> IGW["Internet Gateway"]
    IGW --> NET["Public internet / external service"]
    RT -->|"S3 prefix list"| GWE["S3 Gateway Endpoint"]
    GWE --> S3A["Amazon S3 (same Region)"]
    RT -->|"VPC CIDR (local)"| IFE["S3 Interface Endpoint (ENI + private IP)"]
    IFE --> S3B["Amazon S3 via PrivateLink"]

Figure 1. Three exit paths from a private subnet. The route table, plus DNS for the interface endpoint, decides which one is used.

What is an AWS NAT Gateway?

A NAT Gateway performs network address translation for resources in private subnets. Instances keep private IPv4 addresses. The NAT Gateway replaces the source address of outgoing packets and translates replies back.

Public vs private NAT Gateway

According to the AWS documentation, a NAT Gateway has one of two connectivity types:

	Public NAT Gateway (default)	Private NAT Gateway
Purpose	Outbound internet access from private subnets	Connectivity to other VPCs or on-premises networks
Elastic IP	Required, associated at creation	Cannot be associated
Internet Gateway	Used for internet access	If traffic is sent to an IGW, the IGW drops it
Placement	In a public subnet	In a subnet, routed via a transit gateway or virtual private gateway
Inbound connections	No unsolicited inbound connections from the internet	No unsolicited inbound connections from the connected networks

Two points trip people up:

A public NAT Gateway needs an Elastic IP and a route toward an Internet Gateway for internet access.
A private NAT Gateway does not give you internet access. It is for translating addresses toward other private networks, for example when CIDR ranges overlap.

Traffic flow

sequenceDiagram
    participant I as Private EC2
    participant R as Private route table
    participant N as NAT Gateway (public subnet)
    participant G as Internet Gateway
    participant E as External service
    I->>R: Packet to 203.0.113.10
    R->>N: 0.0.0.0/0 targets the NAT Gateway
    N->>G: Source translated to NAT address
    G->>E: Source becomes the Elastic IP
    E-->>G: Response
    G-->>N: Translated back
    N-->>I: Delivered to the original instance

Figure 2. Outbound flow through a public NAT Gateway. The external address 203.0.113.10 is a documentation example.

The setup requires:

A NAT Gateway in a public subnet, with an Elastic IP.
The public subnet's route table has 0.0.0.0/0 pointing to the IGW.
The private subnet's route table has 0.0.0.0/0 pointing to the NAT Gateway.

Availability and design

Classic (zonal) NAT Gateways live in one Availability Zone. For resilience, a common design is one NAT Gateway per AZ, with each private route table pointing to the NAT Gateway in its own AZ. This also avoids sending traffic across AZs just to reach NAT, which can add data transfer cost.

AWS also documents regional NAT Gateways, which expand across the AZs where you have workloads and simplify routing. They do not support private connectivity, so private NAT still uses zonal gateways. Check the documentation for current Region availability and limits before choosing.

Where NAT is the right tool

Downloading OS updates and packages from public repositories.
Calling third-party SaaS APIs.
Any destination on the public internet that has no private path.

Limits to keep in mind

It is billed by time and by data processed (see the cost section), so heavy traffic to AWS services through NAT can become expensive.
It is outbound-only. It is not a way to publish services.
Traffic to S3 through NAT leaves your VPC through the internet path, even though S3 is an AWS service. That is often not what security teams want.

What is a VPC endpoint?

A VPC endpoint lets resources in your VPC connect privately to supported AWS services (and to services powered by PrivateLink) without needing an internet gateway, NAT device, or VPN for that traffic.

There are two types relevant here:

Gateway endpoint. A target in your route table. Available only for Amazon S3 and Amazon DynamoDB.
Interface endpoint (AWS PrivateLink). One or more ENIs with private IPs in your subnets, protected by security groups. Available for many AWS services and for partner or your own PrivateLink services.

Both support endpoint policies, which control which principals can do which actions on which resources through the endpoint. The default policy is full access, so tightening it is worth doing.

S3 Gateway Endpoint vs S3 Interface Endpoint

This is the part that causes most confusion, because both are "an endpoint for S3" and both keep traffic on the AWS network.

S3 Gateway Endpoint

How it works:

You create the endpoint in a VPC and associate it with route tables.
AWS adds a route that sends S3-bound traffic to the endpoint, using the S3 managed prefix list. In the route table you will see the prefix list ID as the destination and the endpoint ID (vpce-...) as the target.
There is no ENI and no endpoint security group. In security groups you can reference the prefix list ID. Network ACLs cannot reference prefix lists, so use the IP ranges instead.
The AWS documentation states there is no additional charge for gateway endpoints.
The endpoint must be in the same Region as the S3 buckets.

Limits:

The documentation says gateway endpoints do not allow access from on-premises networks.
They also do not allow access from peered VPCs in other Regions or through a transit gateway. The endpoint connection cannot be extended out of the VPC, so resources across VPN, VPC peering, Transit Gateway or Direct Connect cannot use it.
For Amazon-provided DNS, both DNS hostnames and DNS resolution must be enabled on the VPC.
aws:SourceIp cannot be used in policies for requests that traverse a VPC endpoint. Use aws:VpcSourceIp or the VPC/endpoint conditions instead.

S3 Interface Endpoint

How it works:

PrivateLink creates endpoint ENIs with private IPs in the subnets you choose (typically one per AZ).
Security groups on those ENIs control who can connect, typically TCP 443.
Each endpoint gets regional and zonal DNS names that resolve to the endpoint's private IPs. For S3 you reach buckets with a bucket-prefixed name such as bucket.vpce-<id>-<suffix>.s3.<region>.vpce.amazonaws.com. You can point the AWS CLI at it with --endpoint-url.
Because the endpoint is just private IPs in your network, on-premises systems connected over Direct Connect (private VIF) or Site-to-Site VPN can reach it, as AWS describes in its hybrid access guidance.
Other VPCs can reach the endpoint IPs over routed connectivity such as Transit Gateway or peering, provided routing, DNS and security groups allow it.
Cost model: hourly charge per endpoint per AZ, plus a per-GB data processing charge.

The DNS wrinkle (worth reading twice)

The S3 interface endpoint supports a Private DNS option with a special mode: private DNS only for the inbound Resolver endpoint. According to AWS:

With this mode, on-premises DNS queries (forwarded to a Route 53 Resolver inbound endpoint) resolve S3 names to the interface endpoint's private IPs.
Queries from inside the VPC resolve to S3's public IPs, and those requests use the gateway endpoint (no extra charge).
This mode requires an S3 gateway endpoint in the same VPC.
If you enable private DNS for all traffic instead, VPC traffic also goes through the interface endpoint and you pay interface endpoint data processing for it.

This is the cost-friendly hybrid pattern: gateway endpoint for workloads in the VPC, interface endpoint for on-premises and other networks.

Comparison table

	S3 Gateway Endpoint	S3 Interface Endpoint
Connectivity model	Route table target using S3 prefix list	ENI with private IPs (PrivateLink)
Route table requirement	Yes, route per associated route table	No special S3 route; normal VPC routing to the ENI IPs
ENI / private IP	No	Yes, per subnet/AZ
Security groups	No (use prefix list in your own SGs; policy controls on the endpoint)	Yes, on the endpoint ENIs
On-premises access	Not supported	Supported over Direct Connect or VPN, with DNS set up
Cross-VPC / Transit Gateway	Not supported	Possible with correct routing, DNS and security
DNS	Standard S3 names; VPC DNS settings required	Endpoint-specific names; optional private DNS (inbound-only mode needs a gateway endpoint)
Cost model	No additional endpoint charge	Hourly per AZ plus per-GB processing
Typical use	Workloads inside one VPC	Hybrid access, shared-services VPCs, strict private access designs

They are not interchangeable. If an on-premises server needs private S3 access, a gateway endpoint will not do it. If a workload inside the VPC only needs cheap private S3 access, an interface endpoint is usually unnecessary spend.

Understanding the architecture image

![Architecture diagram comparing an S3 Gateway Endpoint, which routes traffic from a private subnet through a route table prefix list and cannot be reached from on-premises or peered VPCs, with an S3 Interface Endpoint, which uses an ENI and security group reachable from on-premises servers and spoke VPCs via Transit Gateway.]

Figure 3. Gateway vs Interface endpoint for S3. Place this image right after this heading.

The image uses four numbered callouts. Here is each one, with a few checks.

1. Route injected (Gateway). The route table gets an entry whose destination is the S3 prefix list and whose target is the gateway endpoint. Traffic to S3 follows that route; everything else follows the other routes. This matches the AWS documentation. One refinement: the route is added when you associate the route table with the endpoint, and removed when you disassociate it.

2. Gateway = $0. The AWS documentation says there is no additional charge for gateway endpoints. Note that this refers to the endpoint itself. Normal S3 request and storage charges still apply, and other data transfer charges can apply in specific cases such as cross-Region access.

3. Interface = ENI + SG. The interface endpoint is an ENI with a private IP, protected by a security group that you configure (for example, allow HTTPS 443 from your sources). The image abbreviates the hostname as bucket.vpce-....s3.amazonaws.com. The real endpoint-specific name follows the pattern bucket.vpce-<id>-<suffix>.s3.<region>.vpce.amazonaws.com, so copy it from your endpoint's details rather than from the picture.

4. Transitive routing. The image shows on-premises servers (Direct Connect or VPN) and spoke VPCs (via Transit Gateway) reaching the interface endpoint. That is achievable, but "transitive" is shorthand. It works because the endpoint is a private IP in your network, so anything with a route to that IP, DNS that resolves to it, and security group permission can connect. An interface endpoint does not make every connected network able to reach S3 automatically.

The red "no route in" warning. This shows that on-premises and peered networks cannot use the gateway endpoint. The AWS documentation confirms the limitation, and the underlying reason is that gateway endpoints cannot be extended out of the VPC. It is less about a missing route and more about how the feature works.

Two more assumptions to be aware of:

The image says "reachable from any routed network". In practice you also need DNS and security groups to line up, and the AWS hybrid guidance describes specific DNS steps for on-premises.
The image shows a single S3 bucket. Remember the endpoint must be in the same Region as the bucket for the gateway type.

NAT Gateway vs VPC endpoint

	NAT Gateway	VPC Endpoint
Main purpose	Outbound connectivity with address translation	Private connectivity to supported AWS and PrivateLink services
Traffic destination	Public internet (public NAT) or other private networks (private NAT)	A specific AWS service or PrivateLink service
Internet dependency	Public NAT needs an IGW and Elastic IP	None for the endpoint path itself
Security	Blocks unsolicited inbound; outbound is broad unless filtered	Endpoint policies, security groups (interface), bucket and IAM conditions
Routing	Default route (`0.0.0.0/0`) to the NAT Gateway	Gateway: prefix list route. Interface: private IPs and DNS
Cost model	Hourly plus per-GB processed (check AWS pricing)	Gateway: no additional charge. Interface: hourly per AZ plus per GB
Common use	OS updates, third-party APIs	S3, DynamoDB and other AWS services without internet egress

They solve different problems, and you will often use them together: NAT for the internet, endpoints for AWS services.

A real-world production architecture

Requirements for an example company:

Private EC2 instances download OS updates and call external repositories.
Logs and backups go to Amazon S3, kept on a private AWS path.
Selected on-premises systems also need private S3 access.
NAT data-processing costs should stay low.

flowchart TB
    subgraph ONPREM["On-premises"]
        SRV["Backup servers"]
        DNS["On-prem DNS (conditional forwarder)"]
    end

    subgraph VPC["Application VPC (2 AZs)"]
        subgraph PUB["Public subnets"]
            NATA["NAT Gateway AZ-a"]
            NATB["NAT Gateway AZ-b"]
        end
        subgraph PRIV["Private subnets"]
            EC2A["EC2 AZ-a"]
            EC2B["EC2 AZ-b"]
        end
        subgraph ENDPOINTS["Endpoints"]
            GWE["S3 Gateway Endpoint"]
            IFE["S3 Interface Endpoint (ENIs, SG: 443 from on-prem)"]
            RES["Route 53 Resolver inbound endpoint"]
        end
        IGW["Internet Gateway"]
    end

    S3[("Amazon S3 buckets")]
    NET["Public repositories / external APIs"]

    EC2A -->|"S3 prefix list"| GWE
    EC2B -->|"S3 prefix list"| GWE
    GWE --> S3
    EC2A -->|"0.0.0.0/0"| NATA
    EC2B -->|"0.0.0.0/0"| NATB
    NATA --> IGW
    NATB --> IGW
    IGW --> NET
    SRV -->|"Direct Connect or VPN"| IFE
    DNS -.->|"S3 domain forwarded"| RES
    IFE --> S3

Figure 4. Gateway endpoint for in-VPC S3 traffic, NAT for the internet, and an interface endpoint for on-premises S3 access.

Which traffic uses what

Traffic	Path	Why
OS updates, external repositories	NAT Gateway	Public internet destinations
EC2 to S3 (logs, backups)	S3 Gateway Endpoint	No additional endpoint charge, stays on the AWS network
On-premises to S3	S3 Interface Endpoint	Gateway endpoints are not reachable from on-premises

Design points

Multi-AZ. One NAT Gateway per AZ with matching route tables, and interface endpoint ENIs in each AZ you use. Alternatively evaluate a regional NAT Gateway.
Routing. The gateway endpoint's S3 prefix-list route covers S3 public IP ranges, which are more specific than the default route, so S3 traffic is steered to the endpoint instead of NAT.
DNS. Use the inbound-resolver-only private DNS option on the interface endpoint, with a gateway endpoint in the VPC. Forward the S3 domain from on-premises DNS to the Route 53 Resolver inbound endpoint.
Security groups. On the interface endpoint, allow TCP 443 only from the on-premises ranges (and other networks you intend to allow).
IAM. Instances use instance profiles (roles), never long-lived keys. Grant only the S3 actions and prefixes they need.
Bucket policy. Restrict the bucket to your endpoints with aws:sourceVpce or aws:sourceVpc. Be careful: AWS notes that a policy limiting access to a specific endpoint also blocks console access.
Endpoint policy. Limit the endpoint to the buckets you own, for example with s3:ResourceAccount.

When is the S3 interface endpoint justified? When something outside the VPC needs private S3 access: on-premises systems, or other VPCs and Regions over private links. If everything is inside one VPC, the gateway endpoint is usually enough.

Practical implementation

Console labels and options change over time, so treat the names below as a guide.

S3 Gateway Endpoint (console)

Open the VPC console.
Go to Endpoints and choose Create endpoint.
Choose the AWS services category and search for com.amazonaws.<region>.s3.
Select the service entry whose type is Gateway.
Select the correct VPC.
Select the private route tables used by your private subnets.
Set an endpoint policy. Replace the default full-access policy with one limited to your buckets.
Create the endpoint, then confirm the route table now shows an S3 prefix list route targeting the vpce- ID.
From a private instance, run aws s3 ls s3://<your-bucket> --region <region> using an instance role. Check the result using the route table, VPC Flow Logs and, if needed, CloudTrail.

S3 Gateway Endpoint (AWS CLI)

Replace everything in angle brackets with your own values.

aws ec2 create-vpc-endpoint \
  --vpc-id <vpc-id> \
  --vpc-endpoint-type Gateway \
  --service-name com.amazonaws.<region>.s3 \
  --route-table-ids <rtb-id-1> <rtb-id-2>

S3 Interface Endpoint (console)

In Endpoints, choose Create endpoint and search for the S3 service for your Region.
Choose the Interface type entry (S3 lists both types).
Select the VPC and subnets in each AZ you need.
Attach a security group allowing inbound TCP 443 from the networks that should connect.
Configure DNS to match your design: either endpoint-specific names only, or private DNS. For the hybrid pattern, choose the inbound-resolver-only option, which needs the gateway endpoint in the same VPC.
Build the DNS path for on-premises: a Route 53 Resolver inbound endpoint in the VPC, and a conditional forwarder on your on-premises DNS.
Confirm routing from on-premises (Direct Connect or VPN) to the endpoint subnets.
Test and review logs.

S3 Interface Endpoint (AWS CLI sketch)

aws ec2 create-vpc-endpoint \
  --vpc-id <vpc-id> \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.<region>.s3 \
  --subnet-ids <subnet-id-a> <subnet-id-b> \
  --security-group-ids <sg-id> \
  --private-dns-enabled \
  --dns-options PrivateDnsOnlyForInboundResolverEndpoint=true

Check the current create-vpc-endpoint reference for the exact option names before using this in a real account.

To test through the endpoint-specific DNS name from a machine with network access to the endpoint:

aws s3 ls s3://<your-bucket> \
  --region <region> \
  --endpoint-url https://bucket.<vpce-dns-name-from-the-console>

Copy <vpce-dns-name-from-the-console> from the endpoint's Details page. Do not paste credentials into commands or scripts. Use roles or your normal credential provider.

Example bucket policy that denies access outside a specific gateway endpoint (adapt carefully, and test with a non-critical bucket first because it can lock you out of the console):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnlessFromMyEndpoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::<your-bucket>",
        "arn:aws:s3:::<your-bucket>/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "<vpce-id>"
        }
      }
    }
  ]
}

Security best practices

Use IAM roles, not hard-coded access keys. Instance profiles and task roles avoid secrets in code.
Least privilege. Scope IAM policies, endpoint policies and bucket policies to the buckets and actions required.
Layer your controls. IAM says who, the endpoint policy says what can pass through this door, the bucket policy says who may enter the bucket.
Use HTTPS/TLS. Enforce it with a bucket policy condition on aws:SecureTransport.
Lock down interface endpoint security groups. Allow 443 only from known sources.
Log and review. VPC Flow Logs show network flows. CloudTrail records API activity.
Avoid unintended public access. Keep S3 Block Public Access on unless you have a reviewed reason.
Review cross-account and cross-network access carefully, especially when many VPCs and on-premises ranges can reach one shared interface endpoint.

Cost optimization

Cost is the main reason many teams adopt endpoints, so here is the model.

NAT Gateway. Billed for each hour it is available and for each GB of data it processes. Check the VPC pricing page for your Region. Heavy S3 traffic sent through NAT pays the processing charge on every GB.
S3 Gateway Endpoint. AWS documents no additional charge for the endpoint. Moving large S3 traffic off NAT onto a gateway endpoint can remove that NAT processing cost for that traffic.
S3 Interface Endpoint. Billed per hour for each endpoint in each AZ, plus per-GB data processing. The AWS PrivateLink pricing page shows example rates for US East (N. Virginia) of $0.01 per hour per endpoint ENI and $0.01 per GB for the first tier. Rates are Region-specific, so verify them for your own Region.
Placement matters. If you enable private DNS for all traffic on the interface endpoint, in-VPC traffic goes through it and incurs its data charges. The inbound-resolver-only mode lets VPC traffic use the free gateway endpoint instead.
Other charges still apply. S3 requests, storage, and some data transfer scenarios (such as cross-Region or cross-AZ traffic) are billed separately.

I have not run cost benchmarks for this article, so I am not claiming any specific saving. Estimate with the AWS Pricing Calculator using your own traffic.

Common mistakes and troubleshooting

Problem	What to check
Route table not associated	In the endpoint details, confirm the private route tables are listed. Check the subnet's actual route table.
No S3 prefix-list route	In the route table, look for a route with an S3 prefix list destination and a `vpce-` target.
IAM or bucket policy denies	Check the instance role, bucket policy and endpoint policy. Read the exact `AccessDenied` message and CloudTrail event.
Security group blocks HTTPS	For interface endpoints, allow 443 inbound from the client. Check the client's outbound rules and NACLs.
Wrong DNS	Run `nslookup` or `dig` for the S3 name from the failing host. Private IP means the interface endpoint, public IP means the gateway path or internet. Verify VPC DNS hostnames and resolution, and any on-premises forwarders.
Expecting the gateway endpoint to work from peered VPCs or via Transit Gateway	It does not extend out of its VPC. Create an endpoint in that VPC, or use an interface endpoint.
Expecting the interface endpoint to open S3 to every connected network	You still need routing to the ENI IPs, DNS that returns them, and security group access.
Subnet or AZ coverage gaps	Confirm the interface endpoint has a subnet in each AZ that needs it, and that the NAT and route tables match your AZ layout.
Bucket in a different Region	A gateway endpoint serves buckets in its own Region. Traffic to other Regions will take another path, such as NAT, and can cost more.
Wrong credentials or a restrictive bucket policy during tests	Confirm which identity the CLI uses with `aws sts get-caller-identity`. Remember that a `aws:sourceVpce` deny also blocks the console.

A good habit is to test in order: DNS, then route, then security group, then policies.

Conclusion

NAT Gateway: use it for outbound access to the public internet, or for private NAT toward other private networks.
S3 Gateway Endpoint: use it as the default for workloads inside one VPC that need S3. No additional endpoint charge, but it does not leave the VPC.
S3 Interface Endpoint: use it when on-premises systems or other networks need private S3 access, and prefer the inbound-resolver-only DNS option so the VPC itself keeps using the gateway endpoint.

Decision rule: gateway inside, interface outside, NAT for the open internet.

What does your S3 and NAT setup look like today? Have you found NAT charges you did not expect, or run a hybrid design with interface endpoints? Share it in the comments, I would love to compare patterns.

References

AWS VPC Peering vs Transit Gateway: A Practical Guide to Scalable Cloud Networking

Toqeer Afzal — Wed, 07 Oct 2026 17:47:15 +0000

AWS VPC Peering vs Transit Gateway: A Practical Guide to Scalable Cloud Networking

*Modern cloud environments rarely stay simple.
*
A startup may begin with a single Amazon VPC and a few EC2 instances. As the organization grows, separate environments are introduced for production, development, testing, security, monitoring, analytics, and shared services.

Soon, an important question appears:

How should these networks communicate securely, privately, and at scale?

Two important AWS networking solutions commonly used to solve this problem are:

Amazon VPC Peering
AWS Transit Gateway

Both can connect VPCs using private networking, but they are designed for different architectural requirements.

In this article, we will compare VPC Peering and Transit Gateway from a practical cloud-engineering perspective, including routing, scalability, network design, real-world use cases, cost considerations, and hands-on AWS scenarios.

## The Short Answer

Before going deeper, remember this:

VPC Peering connects two VPCs directly.

Transit Gateway provides a centralized hub for connecting multiple VPCs and networks.

A simple VPC Peering architecture looks like this:

┌───────────────┐   **    VPC Peering  **     ┌───────────────┐
│    VPC-A      │────────────────────────│    VPC-B      │
│ 10.0.0.0/16   │                        │ 10.1.0.0/16   │
└───────────────┘                        └───────────────┘

A Transit Gateway architecture looks like this:

                    ┌───────────────┐
                    │    Transit    │
                    │    Gateway    │
                    └───────┬───────┘
                            │
             ┌──────────────┼──────────────┐
             │              │              │
             ▼              ▼              ▼
          VPC-A           VPC-B           VPC-C

The difference may look simple, but it becomes extremely important as your cloud environment grows.

1. What Is Amazon VPC Peering?

Amazon VPC Peering is a networking connection between two VPCs that allows resources in those VPCs to communicate using private IP addresses.

The VPCs can be in the same AWS Region or, where supported, across AWS Regions.

For example:

Application VPC
10.0.0.0/16
      │
      │
      │ VPC Peering
      │
      ▼
Database VPC
10.1.0.0/16

An EC2 instance in the application VPC can communicate with a database or service in the second VPC using private addressing, assuming routing and security controls allow the traffic.

VPC Peering is particularly useful when you have a relatively small number of VPCs and a clear requirement for direct connectivity.

2. How VPC Peering Works

Creating a peering connection does not automatically make all traffic work.

Three major areas need to be considered:

VPC Peering connection
Route tables
Security controls

Suppose we have:

VPC-A
CIDR: 10.0.0.0/16

VPC-B
CIDR: 10.1.0.0/16

The route table associated with the relevant subnet in VPC-A could contain:

Destination       Target
10.1.0.0/16       pcx-xxxxxxxx

VPC-B needs the return route:

Destination       Target
10.0.0.0/16       pcx-xxxxxxxx

The security groups and network ACLs must also permit the required traffic.

This leads to an important AWS networking principle:

Connectivity is not the same thing as reachability.

A connection can exist while traffic still fails because of missing routes or security rules.

3. A Practical VPC Peering Scenario

Imagine a SaaS company has separated its application and data workloads.

Application VPC

CIDR: 10.10.0.0/16

Database VPC

CIDR: 10.20.0.0/16

The application needs private access to a database service.

The architecture could be:

┌──────────────────────┐
│   Application VPC    │
│    10.10.0.0/16     │
│                      │
│      EC2 / App       │
└──────────┬───────────┘
           │
           │ VPC Peering
           │
┌──────────▼───────────┐
│     Database VPC     │
│    10.20.0.0/16      │
│                      │
│    Database Tier     │
└──────────────────────┘

The application subnet needs a route toward the database CIDR.

The database side needs a return route.

The database security group should allow only the required application traffic.

For example, if the application requires HTTPS:

Source: 10.10.0.0/16
Protocol: TCP
Port: 443

In a production environment, avoid opening unnecessary ports or using broader access rules when more restrictive rules are possible.

4. The Most Important VPC Peering Limitation: No Transitive Routing

This is one of the most important concepts to understand.

Suppose:

VPC-A
   │
   │ Peering
   │
VPC-B
   │
   │ Peering
   │
VPC-C

A common assumption is:

VPC-A → VPC-B → VPC-C

But VPC Peering does not automatically provide this kind of transitive routing.

In other words:

A VPC cannot use another VPC as a router simply because both have peering connections.

If VPC-A needs direct connectivity to VPC-C, an appropriate connectivity design is required.

This becomes increasingly difficult to manage as the number of VPCs increases.

*5. Why VPC Peering Can Become Difficult at Scale
*
Imagine an organization with:

Production VPC
Development VPC
Testing VPC
Security VPC
Monitoring VPC
Shared Services VPC
Analytics VPC

If many of these VPCs need direct communication, a mesh of peering connections can become difficult to manage.

For a full mesh, the number of point-to-point connections is:

N × (N − 1) / 2

For example:

*| Number of VPCs *| *Full-Mesh Connections *|
| -------------: | --------------------: |
| 2 | 1 |
| 3 | 3 |
| 4 | 6 |
| 5 | 10 |
| 10 | 45 |
| 20 | 190 |

The mathematical problem is not the only concern.

You also have to think about:

Route tables
Security rules
Connection lifecycle
Network documentation
Troubleshooting
Change management
Operational ownership

This is where a centralized networking architecture becomes attractive.

6. What Is AWS Transit Gateway?

AWS Transit Gateway is a centralized network transit service that can connect multiple VPCs and supported network environments through a central hub.

Instead of creating direct connections between every VPC, each VPC can attach to the Transit Gateway.

                    ┌────────────────────┐
                    │   AWS Transit      │
                    │      Gateway       │
                    └─────────┬──────────┘
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
          ▼                   ▼                   ▼
       VPC-A                VPC-B                VPC-C

This is commonly described as a hub-and-spoke architecture.

The Transit Gateway acts as the hub.

The VPCs become the spokes.

7. Practical Transit Gateway Architecture**

Consider an organization with separate AWS environments:

                    AWS Transit Gateway
                            │
       ┌────────────────────┼────────────────────┐
       │                    │                    │
       ▼                    ▼                    ▼
 Production VPC       Security VPC        Shared Services
       │                                         │
       ▼                                         ▼
 Application                               Monitoring

Additional VPCs can be connected to the same Transit Gateway according to the organization's architecture and routing requirements.

This approach can simplify connectivity management compared with maintaining a large collection of direct VPC-to-VPC connections.

## 8. Transit Gateway Routing

Transit Gateway introduces another important concept:

Transit Gateway route tables.

These allow network administrators to control how traffic is routed between Transit Gateway attachments.

For example:

                 Transit Gateway
                       │
             ┌─────────┴─────────┐
             │   TGW Route Table │
             └─────────┬─────────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
        VPC-A        VPC-B        VPC-C

The VPC route tables still matter.

For example, VPC-A may need:

Destination: 10.20.0.0/16
Target: Transit Gateway

The Transit Gateway then needs the appropriate route toward the attachment containing that destination.

A useful troubleshooting mindset is:

Source
  ↓
VPC Route Table
  ↓
Transit Gateway
  ↓
TGW Route Table
  ↓
Destination VPC
  ↓
Security Controls

If connectivity fails, each layer should be checked.

## 9. Transit Gateway and Network Segmentation

One of the powerful features of a centralized architecture is the ability to design different connectivity domains.

For example:

                Transit Gateway
                       │
       ┌───────────────┼────────────────┐
       │               │                │
       ▼               ▼                ▼
   Production      Development       Security
      VPC              VPC             VPC

An organization might want:

Production → Security       ✓
Production → Monitoring     ✓
Development → Shared        ✓
Development → Production    ✕

The exact implementation depends on the organization's routing and security design, but the centralized model makes this kind of segmentation easier to manage.

This is especially useful in environments following principles such as:

Least privilege
Network segmentation
Environment isolation
Centralized security controls

## 10. VPC Peering vs Transit Gateway

Here is the practical comparison:

| Area *| VPC Peering * | Transit *Gateway * |
| -------------------- | -------------------------------- | --------------------------------------------- |
| Connectivity model | Point-to-point | Hub-and-spoke |
| Best suited for | Smaller/simple environments | Larger/multi-VPC environments |
| Centralized routing | No | Yes |
| Transitive routing | No | Supports centralized transit |
| Management | Distributed | More centralized |
| Network segmentation | More distributed | Centralized design option |
| Hybrid connectivity | Not its primary role | Strong use case |
| Initial complexity | Low | Higher |
| Scalability | Can become operationally complex | Designed for large-scale connectivity |
| Pricing model | Data transfer considerations | Attachment and data-processing considerations |

Pricing varies by architecture, traffic patterns, AWS Region, and service usage, so always check current AWS pricing when estimating costs.

## 11. When Should You Use VPC Peering?

VPC Peering is a good candidate when:

You have a small number of VPCs

For example:

Application VPC
      │
      │
   Peering
      │
      ▼
Shared Services VPC

### You need direct connectivity

If two VPCs have a specific and well-defined communication requirement, direct peering may be simpler.

### You want a straightforward architecture

Fewer components can mean easier initial implementation and troubleshooting.

12. When Should You Use Transit Gateway?**

Transit Gateway becomes attractive when you have:

### Multiple VPCs

VPC-A ──┐
VPC-B ──┤
VPC-C ──┼── Transit Gateway
VPC-D ──┤
VPC-E ──┘

### Centralized network management

You want routing and connectivity decisions to follow a centralized architecture.

### Hybrid networking requirements

Organizations may need to connect AWS environments with on-premises networks through supported connectivity architectures.

### Network segmentation

Different environments may need different communication policies.

### A growing cloud footprint

As AWS accounts, VPCs, Regions, and environments grow, a scalable network architecture becomes increasingly important.

13. Hands-On AWS Lab: Build VPC Peering

If you're learning AWS networking, don't stop at theory.

Try this lab.

Step 1 — Create VPC-A

Name: VPC-A
CIDR: 10.0.0.0/16

Step 2 — Create VPC-B

Name: VPC-B
CIDR: 10.1.0.0/16

Make sure the CIDR ranges do not overlap.

Step 3 — Create the Peering Connection

In the AWS VPC console:

VPC → Peering connections → Create peering connection

Select the requester and accepter VPC.

Step 4 — Accept the Connection

Accept the peering request from the other VPC.

Step 5 — Update Route Tables

VPC-A:

10.1.0.0/16 → Peering Connection

VPC-B:

10.0.0.0/16 → Peering Connection

Step 6 — Configure Security Groups

Allow only the traffic required for your test.

Step 7 — Test Connectivity

Launch test instances and verify connectivity using an appropriate protocol.

Then intentionally remove a route and observe the failure.

This is a great way to understand how AWS routing actually works.

14.** Hands-On AWS Lab: Build a Transit Gateway**

Create three VPCs:

VPC-A → 10.0.0.0/16
VPC-B → 10.1.0.0/16
VPC-C → 10.2.0.0/16

Step 1

Create a Transit Gateway.

Step 2

Create Transit Gateway attachments for the VPCs.

VPC-A ──┐
VPC-B ──┼── Transit Gateway
VPC-C ──┘

Step 3

Update VPC route tables.

For example:

10.1.0.0/16 → Transit Gateway
10.2.0.0/16 → Transit Gateway

Step 4

Configure the Transit Gateway route table according to your desired connectivity.

Step 5

Check security groups and network ACLs.

Step 6

Test traffic between the instances.

Then make the lab more interesting:

Try blocking Development → Production while allowing Development → Shared Services.

This turns a simple connectivity lab into a real network-design exercise.

15. A Real-World Cloud Architecture

Imagine an organization operating an e-commerce platform.

Its AWS environment contains:

Production
Development
Security
Monitoring
Shared Services
Analytics

A scalable architecture could look like:

                         ┌──────────────────┐
                         │ Transit Gateway  │
                         └────────┬─────────┘
                                  │
          ┌───────────────┬───────┼────────┬───────────────┐
          │               │       │        │               │
          ▼               ▼       ▼        ▼               ▼
     Production     Development Security Monitoring   Shared Services
        VPC              VPC        VPC       VPC          VPC

Each environment can have its own CIDR range and security controls.

The network architecture can then define which environments are allowed to communicate.

This is closer to how enterprise cloud networking is designed than simply connecting every VPC to every other VPC.

16. Common AWS Networking Mistakes

Mistake 1: Assuming a connection automatically creates routes

It doesn't.

Always check the relevant route tables.

Mistake 2: Forgetting return traffic

Networking is bidirectional.

A route from A to B is not enough if B has no route back to A.

Mistake 3: Ignoring security groups

Correct routing does not override security controls.

Mistake 4: Assuming VPC Peering is transitive

It isn't.

Mistake 5: Choosing architecture only based on price

A low initial cost can become expensive operationally if the architecture becomes difficult to manage.

Mistake 6: Using overlapping CIDRs

Overlapping address ranges can create major networking limitations.

Good IP address planning should happen before connecting networks.

17. How to Choose Between Them

A useful way to approach the decision is to ask five questions.

1. How many VPCs do I have?

Two VPCs?

Peering may be enough.

Many VPCs?

Start evaluating a centralized architecture.

2. Do the VPCs need direct connectivity?

If only two environments need to communicate, direct peering may be simpler.

3. Do I need centralized routing?

If yes, Transit Gateway becomes more attractive.

4. Do I need network segmentation?

If different environments need different connectivity policies, a centralized architecture can simplify the design.

5. Will the environment grow?

Today's two-VPC architecture may become tomorrow's twenty-VPC architecture.

Good cloud architecture considers not only today's requirements but also reasonable future growth.

18. Interview Question: What Is the Difference?

Q*: What is the difference between VPC Peering and Transit Gateway?
*
A professional answer:

VPC Peering provides direct private connectivity between two VPCs, while Transit Gateway provides a centralized hub through which multiple VPCs and supported networks can connect. VPC Peering is often suitable for simple point-to-point requirements, whereas Transit Gateway is better suited to larger environments that require centralized routing, segmentation, and scalable network connectivity.

19. Interview Question: Does VPC Peering Support Transitive Routing?

No.

If:

A ↔ B
B ↔ C

you cannot assume:

A ↔ C

through B.

This is one of the most important differences to remember when designing AWS networks.

20. Is Transit Gateway Always Better?

No.

Architecture should be based on requirements.

For two VPCs:

VPC-A ───── VPC-B

VPC Peering may be perfectly reasonable.

For dozens of VPCs:

VPC-A ──┐
VPC-B ──┤
VPC-C ──┤
VPC-D ──┼── **Transit Gateway**
VPC-E ──┤
VPC-F ──┘

Transit Gateway may provide a much cleaner architecture.

The goal is not to use the most advanced service.

The goal is to use the right architecture for the problem.

21. Final Architecture Comparison

VPC Peering

                Direct Connectivity

┌───────────┐                  ┌───────────┐
│   VPC-A   │══════════════════│   VPC-B   │
└───────────┘                  └───────────┘

Think:

"I need these two VPCs to communicate directly."

Transit Gateway

                    ┌──────────────┐
                    │   Transit    │
                    │   Gateway    │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
              ▼            ▼            ▼
           VPC-A         VPC-B        VPC-C
              │
              ▼
        Shared Network

Think:

"I need a scalable central network architecture."

## Conclusion

AWS VPC Peering and Transit Gateway solve related but different networking problems.

VPC Peering is a direct connectivity model that works well when the number of VPCs and connectivity requirements are relatively simple.

Transit Gateway provides a centralized network hub that becomes increasingly valuable as environments grow and require scalable routing, segmentation, and connectivity between multiple networks.

The most important lesson is not simply memorizing the definitions.

It is understanding the architectural trade-off:

Simple network → consider direct connectivity.

Growing network → consider centralized connectivity.

Good cloud networking is not just about making two systems communicate.

It is about designing connectivity that remains:

Secure
Understandable
Scalable
Maintainable
Cost-conscious

If you're learning AWS networking, build both architectures yourself.

Create the VPCs.

Configure the routes.

Test connectivity.

Break a route.

Fix it.

Then build the same scenario with Transit Gateway.

That's when networking stops being a diagram and starts becoming a real engineering skill.

**## Key Takeaways

VPC Peering**

Direct VPC-to-VPC connectivity
Simple for smaller environments
No transitive routing
Distributed route management

** Transit Gateway**

Centralized hub-and-spoke architecture
Designed for connecting multiple networks
Centralized routing capabilities
Useful for scalable and hybrid cloud architectures

Final Thought

The real cloud-engineering skill is not knowing the definition of VPC Peering or Transit Gateway.

Hands-On with Amazon S3: Buckets, Permissions, Lifecycle Rules and Static Hosting published: true tags: aws, devops, s3 cover

Toqeer Afzal — Mon, 14 Sep 2026 15:17:36 +0000

Hands-On with Amazon S3: Buckets, Permissions, Lifecycle Rules, and Static Hosting Explained

Introduction
Cloud storage sounds abstract until you actually create a bucket, upload a file into it, and watch access rules decide who can — and can't — see that file. That's exactly the exercise this article is built on: a hands-on AWS lab covering S3 buckets, object uploads, storage classes, bucket policies, ACLs/permissions, intelligent tiering through a lifecycle rule, and static website hosting.

If you're learning cloud computing or preparing for DevOps/cloud work, S3 is one of the first services worth understanding deeply — not just because it's common but because it forces you to think about storage, access control, cost, and availability all at once.

In this post, you'll learn what each of these S3 concepts means, how they connect to each other, and how a bucket goes from "empty storage" to a fully configured, cost-optimized, publicly hosted resource.

Quick Overview

The lab covered the following core building blocks:

Buckets — the top-level container for storing data in S3.
Objects — the actual files uploaded into a bucket.
Upload — the process of putting objects into a bucket.
Storage Classes — different tiers for storing objects based on access needs.
Bucket Policy — a resource-level, JSON-based permission set attached to a bucket.
ACL (Access Control List) & Permissions — access control at the bucket/object level.
Intelligent Tiering — an S3 storage class that automatically optimizes cost based on access patterns.
Lifecycle Configuration Rule — automated rules that transition or expire objects over time.
Static Website Hosting — configuring a bucket to serve content directly as a website.
Core Concepts
Buckets

A bucket is the container that holds your data in S3. Every object you store must live inside a bucket, and every bucket name must be globally unique across all of AWS. Think of a bucket as the top-level folder for a project or application's storage needs.

Objects & Upload

An object is simply a file — an image, a document, a video, a JSON file, anything — stored inside a bucket. Upload is the action of transferring that file from your local machine (or another system) into the bucket. Once uploaded, each object is identified by a unique key (essentially its path/name inside the bucket).

Storage Classes

S3 offers multiple storage classes, each designed for a different access pattern — frequently accessed data, infrequently accessed data, and long-term archival data. Choosing the right class is a balance between accessibility and cost efficiency.

Note: Exact pricing figures for each storage class were not provided in the source data, so no cost numbers are stated here. Refer to official AWS pricing pages for current rates.

Bucket Policy

A bucket policy is a JSON-based access control document attached directly to a bucket. It defines who (which AWS account, user, or role) can perform what actions (read, write, delete, etc.) on the bucket or its objects. This is the primary mechanism for controlling access at the bucket level.

ACL & Permissions

ACLs (Access Control Lists) are an older, more granular way to control access to individual buckets and objects, alongside standard permissions. While bucket policies are generally the modern, recommended approach, understanding ACLs is still useful, especially when working with legacy configurations.

Intelligent Tiering & Lifecycle Configuration Rule

Intelligent Tiering is a storage class that automatically moves objects between access tiers based on how frequently they're used — without manual intervention. This is configured through a lifecycle configuration rule, which defines automated actions on objects over time (for example, transitioning objects to a different storage class after a certain period, or expiring them altogether).

In the lab, intelligent tiering was set up specifically as a lifecycle configuration rule — meaning the automation of "move this data to a cheaper tier when it's not being accessed" is handled through S3's lifecycle rule engine.

Static Website Hosting

S3 buckets can be configured to host static websites directly — serving HTML, CSS, JS, and other static assets straight from the bucket via a website endpoint. This turns a plain storage bucket into a publicly accessible website, without needing a traditional web server.

Cloud Architecture / Structure

Based on the components covered in the lab, here's how they relate to one another inside a single S3 bucket setup:

S3 Bucket
Upload
Controls access to
Controls access to
Triggers
Moves
Serves
HTTP Request
Objects (Uploaded Files)
Bucket Policy
ACL & Permissions
Lifecycle Configuration Rule
Intelligent Tiering
Static Website Hosting
User / Client
Website Visitor

Component labels:

Objects — the files stored in the bucket.
Bucket Policy / ACL & Permissions — the two access-control layers governing who can interact with objects.
Lifecycle Configuration Rule — the automation engine that triggers storage-class transitions.
Intelligent Tiering — the storage class that lifecycle rules move eligible objects into.
Static Website Hosting — the feature that exposes bucket objects as a browsable website.
Workflow / Process

Here's the step-by-step process the lab followed, from an empty bucket to a fully configured one:

Create Bucket
Upload Objects
Set Bucket Policy
Configure ACL / Permissions
Set Lifecycle ConfigurationRule
Enable Intelligent Tiering
Enable Static WebsiteHosting
Bucket Serves ContentPublicly
Create Bucket — a globally unique bucket is created.
Upload Objects — files are added into the bucket.
Set Bucket Policy — access rules are defined at the bucket level.
Configure ACL / Permissions — finer-grained or legacy-style access control is applied.
Set Lifecycle Configuration Rule — automation rules are defined for object transitions.
Enable Intelligent Tiering — objects become eligible for automatic cost-optimized storage movement.
Enable Static Website Hosting — the bucket is exposed as a website endpoint.
Bucket Serves Content — end users/visitors can now access the hosted content.
*Practical / Real-World Example
*
A common real-world use case that matches this exact configuration: hosting a personal portfolio or documentation site directly from S3.

The bucket stores the site's HTML, CSS, JS, and image files (the objects).
A bucket policy allows public GetObject access so visitors can view the site, while restricting write/delete access to the account owner.
ACLs/permissions can be used to fine-tune access on specific objects if needed.
A lifecycle configuration rule with intelligent tiering can be applied to older assets (e.g., archived blog images) so they move to lower-cost tiers automatically if they stop being accessed frequently.
Static website hosting is enabled so the bucket serves an index.html directly to browsers via the S3 website endpoint.

This mirrors exactly the sequence of concepts covered in the lab — access control, cost optimization, and public content delivery, all from a single bucket.

Advantages
Simple, durable storage — buckets provide a straightforward way to store and organize objects.
Granular access control — bucket policies and ACLs give precise control over who can access what.
Automated cost optimization — lifecycle rules and intelligent tiering reduce the need for manual storage-class management.
No server required for static content — static website hosting lets you serve a website directly from storage, without provisioning a web server.
Challenges / Limitations
Access control complexity — having two overlapping mechanisms (bucket policy and ACLs) can make permissions harder to reason about if not managed carefully.
Public bucket risk — enabling static website hosting or public policies requires care, since misconfigured public access exposes data broadly.
Specific limitations around storage-class transition timing, minimum storage durations, or request pricing are not provided in the source data.
Best Practices

Tip: Prefer bucket policies over ACLs for new configurations, since AWS recommends policies as the modern standard — ACL usage here reflects what was covered in the lab, not a general recommendation against policies.

Important: Double-check any bucket intended for static website hosting to ensure only the intended objects are public, and nothing else in the bucket is unintentionally exposed.

Review lifecycle rules periodically to confirm objects are transitioning as intended.
Keep bucket policies and ACLs documented so access logic doesn't become guesswork later.
Test static website hosting configuration in a non-production bucket first.

(These are general cloud best practices; none of them are numeric claims from the source data.)

Conclusion

This lab walks through the full lifecycle of an S3 bucket: creating it, filling it with objects, locking down access with policies and ACLs, optimizing cost automatically through lifecycle rules and intelligent tiering, and finally exposing it as a public static website. Each piece — storage, access control, and cost management — is a core skill for anyone working with cloud infrastructure, and S3 is one of the clearest services to learn them on.

Key Takeaways
A bucket is S3's top-level storage container; objects are the files inside it.
Bucket policies and ACLs/permissions are the two layers controlling access to a bucket and its objects.
Storage classes let you match storage cost to how often data is actually accessed.
Lifecycle configuration rules automate storage-class transitions — including into intelligent tiering.
Static website hosting turns a bucket into a public website endpoint, no server required.