DEV Community

Cover image for AWS Architecture Unlocked: Follow a Request Through a VPC
Naami Ahmed
Naami Ahmed

Posted on Originally published at naamiahmed.medium.com

AWS Architecture Unlocked: Follow a Request Through a VPC

#aws #networking #cloud #beginners

Understanding VPCs, subnets, route tables, Internet Gateway, NAT Gateway, Security Groups, NACLs, IAM, and S3 through one real-world request.

What actually happens when a user opens an application running on AWS?

You have probably seen diagrams like this:

User → Load Balancer → EC2 → RDS
Enter fullscreen mode Exit fullscreen mode

It looks simple.

But then the questions start:

  • How does the request enter the AWS network?
  • Why is the Load Balancer in a public subnet?
  • Why is the application server in a private subnet?
  • How does a private EC2 instance access the internet?
  • What exactly does the NAT Gateway do?
  • What is the difference between an Internet Gateway and a NAT Gateway?
  • Where do Route Tables fit into all of this?
  • If Security Groups protect resources, what does a Network ACL protect?
  • How does the application access S3?
  • Does IAM provide the network connection to S3?
  • What actually happens to a packet as it travels through the architecture?

Learning AWS services individually is one thing.

Understanding how those services work together is another.

That is what this article is about.

Rather than explaining AWS networking as a collection of definitions, let's follow a request through a realistic AWS architecture and understand what happens at each step.

1. The Big Picture

Let's imagine that we are running a simple web application on AWS.

Our architecture contains:

  • Amazon Route 53
  • Amazon VPC
  • Two Availability Zones
  • Public subnets
  • Private application subnets
  • Private database subnets
  • Internet Gateway
  • NAT Gateway
  • Application Load Balancer
  • EC2 application servers
  • Amazon RDS
  • Amazon S3
  • VPC Endpoint
  • Route Tables
  • Security Groups
  • Network ACLs
  • IAM

At a high level:

                         INTERNET
                            │
                            ▼
                       Route 53
                            │
                            ▼
                 Application Load Balancer
                            │
                ┌───────────┴───────────┐
                │                       │
          Application A           Application B
                │                       │
                └───────────┬───────────┘
                            │
                           RDS
                            │
                           S3
Enter fullscreen mode Exit fullscreen mode

But there is much more happening underneath.

Let's open this architecture step by step.

2. First: What Is a VPC?

An Amazon VPC, or Virtual Private Cloud, is your logical network environment inside AWS.

Think about a company office.

The office has:

  • different rooms
  • entrances
  • internal areas
  • security controls
  • different routes between areas

A VPC gives you a similar networking boundary in AWS.

Inside a VPC, you can create:

  • Subnets
  • Route Tables
  • Security Groups
  • Network ACLs
  • Internet Gateways
  • NAT Gateways
  • VPC Endpoints

A VPC spans the Availability Zones in an AWS Region, and you can create subnets in those Availability Zones.

For example:

AWS Region
│
└── VPC
    │
    ├── Availability Zone A
    │
    └── Availability Zone B
Enter fullscreen mode Exit fullscreen mode

The VPC is therefore the main networking boundary for our application.

3. Why Do We Use Multiple Availability Zones?

Before discussing public and private subnets, there is another important concept: Availability Zones.

An AWS Region contains multiple Availability Zones.

Instead of putting our entire application into one Availability Zone, we can distribute resources across multiple Availability Zones.

For example:

                    VPC
                     │
          ┌──────────┴──────────┐
          │                     │
       AZ - A                 AZ - B
          │                     │
     Application A        Application B
Enter fullscreen mode Exit fullscreen mode

Why?

Because if one Availability Zone experiences a problem, resources in another Availability Zone can continue serving traffic.

This is one of the basic ideas behind high availability.

For our example, we'll use two Availability Zones.

4. Public Subnet vs Private Subnet

This is one of the most important concepts to understand.

We can divide our VPC into different subnets.

For example:

VPC
│
├── Availability Zone A
│   ├── Public Subnet
│   ├── Private Application Subnet
│   └── Private Database Subnet
│
└── Availability Zone B
    ├── Public Subnet
    ├── Private Application Subnet
    └── Private Database Subnet
Enter fullscreen mode Exit fullscreen mode

But what actually makes a subnet "public"?

It is not simply a label saying Public Subnet.

The important factor is routing.

A subnet can be considered public when its route table contains a route to an Internet Gateway. For IPv4 internet traffic, that commonly looks like:

Destination       Target

0.0.0.0/0         Internet Gateway
Enter fullscreen mode Exit fullscreen mode

AWS documentation describes adding this route to a subnet's route table to provide internet access through an Internet Gateway.

So:

Public subnet = subnet whose routing allows internet connectivity through an Internet Gateway, with appropriately addressed resources and security controls.

A private subnet does not have a direct route to an Internet Gateway for internet-bound traffic.

5. What Does a Route Table Actually Do?

This is where many beginners become confused.

A Route Table is basically a traffic decision table.

It answers:

"Where should this traffic go?"

For example:

Destination       Target

10.0.0.0/16       local
0.0.0.0/0         igw-xxxx
Enter fullscreen mode Exit fullscreen mode

The first route says:

Traffic destined for the VPC's own CIDR stays inside the VPC.

The second says:

Traffic destined for anywhere else should use the Internet Gateway.

AWS describes a route table as a set of rules that determines where traffic from a subnet or gateway is directed.

Think of a route table like a road-sign system.

If the destination is:

10.0.0.0/16
Enter fullscreen mode Exit fullscreen mode

take the local road.

If the destination is:

0.0.0.0/0
Enter fullscreen mode Exit fullscreen mode

take the configured default route.

6. How Does Internet Traffic Enter the VPC?

Now let's follow a real request.

Imagine a user opens:

https://myapp.com
Enter fullscreen mode Exit fullscreen mode

The simplified flow is:

User
  │
  ▼
Internet
  │
  ▼
Route 53
  │
  ▼
Application Load Balancer
  │
  ▼
Private Application Server
Enter fullscreen mode Exit fullscreen mode

But how does the request actually enter the VPC?

That's where the Internet Gateway comes in.

7. Internet Gateway — The VPC's Connection to the Internet

An Internet Gateway, or IGW, is attached to the VPC.

It provides connectivity between the VPC and the internet when the appropriate routing and addressing are configured.

A simplified view:

Internet
   │
   ▼
Internet Gateway
   │
   ▼
VPC
Enter fullscreen mode Exit fullscreen mode

For a public subnet, the route table may contain:

0.0.0.0/0 → Internet Gateway
Enter fullscreen mode Exit fullscreen mode

The Internet Gateway itself is not placed inside the subnet.

It is attached to the VPC.

This is an important detail because architecture diagrams often make this confusing.

8. Application Load Balancer in the Public Subnets

Now let's introduce an Application Load Balancer.

Our architecture looks like:

                    Internet
                       │
                       ▼
               Internet Gateway
                       │
             ┌─────────┴─────────┐
             │                   │
       Public Subnet A     Public Subnet B
             │                   │
             └─────────┬─────────┘
                       │
                       ▼
               Application
               Load Balancer
Enter fullscreen mode Exit fullscreen mode

The ALB can receive requests from users and distribute them to healthy application targets.

Our application servers don't need to be directly exposed to the internet.

Instead:

Internet
   ↓
ALB
   ↓
Private Application Server
Enter fullscreen mode Exit fullscreen mode

This gives us a cleaner security boundary.

9. Why Put the Application Servers in Private Subnets?

Suppose we have two EC2 application servers:

Private Application Subnet A
        │
        └── EC2 App Server A

Private Application Subnet B
        │
        └── EC2 App Server B
Enter fullscreen mode Exit fullscreen mode

These servers do not need public IP addresses for users to access the application.

Users communicate with the ALB.

The ALB communicates with the application servers.

So:

Internet
   ↓
ALB
   ↓
Private EC2
Enter fullscreen mode Exit fullscreen mode

This reduces the direct exposure of the application servers.

This is a common pattern in multi-tier AWS architectures.

10. Security Groups: Resource-Level Protection

Now we need security.

Security Groups act as a virtual firewall associated with resources such as network interfaces.

For our application, we could create three Security Groups:

ALB Security Group
Application Security Group
Database Security Group
Enter fullscreen mode Exit fullscreen mode

For example:

ALB Security Group 

Inbound:
HTTPS 443
Source: Internet
Enter fullscreen mode Exit fullscreen mode

Application Security Group 

Inbound:
Application port
Source: ALB Security Group
Enter fullscreen mode Exit fullscreen mode

Database Security Group 

Inbound:
PostgreSQL 5432
Source: Application Security Group
Enter fullscreen mode Exit fullscreen mode

This creates a chain:

Internet
   │
   │ HTTPS 443
   ▼
ALB
   │
   │ Application traffic
   ▼
EC2
   │
   │ PostgreSQL 5432
   ▼
RDS
Enter fullscreen mode Exit fullscreen mode

Notice something important.

We don't say:

"Allow the entire internet to access RDS on port 5432."

Instead, we restrict database access to the application tier.

This is the principle of least privilege applied to network access.

11. Security Groups Are Stateful

Security Groups are stateful.

If an allowed inbound connection is established, the response traffic is automatically allowed back without requiring a separate outbound rule for that response.

Security Groups also support allow rules rather than explicit deny rules.

This is different from Network ACLs.

12. Network ACLs — Subnet-Level Protection

A Network Access Control List, or NACL, works at the subnet level.

Think about it this way:

             VPC
              │
        ┌─────┴─────┐
        │           │
      Subnet      Subnet
        │           │
       NACL        NACL
Enter fullscreen mode Exit fullscreen mode

A Security Group protects resources.

A NACL controls traffic at the subnet boundary.

The basic comparison is:

Feature Security Group Network ACL
Scope Resource / network interface Subnet
Stateful Yes No
Allow rules Yes Yes
Deny rules No Yes
Main purpose Resource-level traffic control Subnet-level traffic control

Because NACLs are stateless, you need to think about both directions of traffic.

13. Now the Interesting Question: How Does a Private EC2 Reach the Internet?

Our application server is private.

It has no public IP address.

But suppose the application needs to:

  • call an external API
  • download a package
  • access an external service
  • retrieve some internet-hosted resource

How does it access the internet?

The answer is:

NAT Gateway.

14. NAT Gateway — Private to Internet

We put a NAT Gateway in a public subnet.

The architecture becomes:

Private EC2
     │
     ▼
Private Route Table
     │
     ▼
NAT Gateway
     │
     ▼
Internet Gateway
     │
     ▼
Internet
Enter fullscreen mode Exit fullscreen mode

The private subnet route table can contain:

Destination       Target

0.0.0.0/0         NAT Gateway
Enter fullscreen mode Exit fullscreen mode

AWS documents this pattern: a NAT device can allow resources in private subnets to initiate connections to the internet while those resources cannot receive unsolicited inbound connection requests from the internet. AWS recommends NAT Gateway as the managed NAT option for this use case.

The important concept is:

Private resources can initiate outbound internet connections through NAT without requiring direct inbound internet connectivity.

15. Internet Gateway vs NAT Gateway

This is a common interview question.

Internet Gateway

Think:

VPC ↔ Internet

It provides the VPC's connection to the internet when routing and addressing permit it.

NAT Gateway

Think:

Private Subnet → Internet

It allows private resources to make outbound connections without requiring them to have public IP addresses.

So:

PUBLIC:

EC2 / ALB
   ↓
Route Table
   ↓
Internet Gateway
   ↓
Internet
Enter fullscreen mode Exit fullscreen mode

And:

PRIVATE:

EC2
   ↓
Route Table
   ↓
NAT Gateway
   ↓
Internet Gateway
   ↓
Internet
Enter fullscreen mode Exit fullscreen mode

16. Important: NAT Gateway Does Not Make a Private Subnet Public

This is a common misunderstanding.

Some beginners think:

"If my private EC2 uses NAT Gateway, then it becomes public."

No.

The EC2 remains without a public IP address.

The NAT Gateway performs the network address translation for outbound traffic.

The return traffic is translated back to the private resource.

So the architecture remains:

Internet
   X
   │
   │ No direct unsolicited inbound connection
   │
NAT Gateway
   │
Private EC2
Enter fullscreen mode Exit fullscreen mode

17. Why Do We Need Multiple NAT Gateways?

For a highly available architecture, we generally avoid depending on one NAT Gateway in only one Availability Zone.

For example:

                VPC

        AZ-A              AZ-B
         │                  │
    Public Subnet       Public Subnet
         │                  │
    NAT Gateway A       NAT Gateway B
         │                  │
    Private App A       Private App B
Enter fullscreen mode Exit fullscreen mode

This avoids making one NAT Gateway a single point of failure for both Availability Zones.

There is also a cost consideration because NAT Gateways are billed resources.

For a learning architecture, you can show two NAT Gateways and explain that real architectures must balance availability, complexity, and cost.

18. What About the Database?

Our application needs a database.

Let's use Amazon RDS.

We can place RDS in private database subnets:

Private Application Subnet
        │
        ▼
Application Server
        │
        │ TCP 5432
        ▼
Private Database Subnet
        │
        ▼
       RDS
Enter fullscreen mode Exit fullscreen mode

The RDS database does not need to be directly accessible from the internet.

The database Security Group can allow PostgreSQL traffic only from the application Security Group.

This gives us:

Internet
   │
   X
   │
   └── No direct access to RDS

Application
   │
   ▼
RDS
Enter fullscreen mode Exit fullscreen mode

This is a very important production-style security pattern.

19. Now Let's Talk About S3

Amazon S3 is different from EC2 and RDS.

You don't create an S3 bucket inside your VPC.

S3 is an AWS managed service.

So we shouldn't draw it as:

VPC
└── S3
Enter fullscreen mode Exit fullscreen mode

as if S3 were a subnet resource.

Instead:

              VPC
               │
          Application
               │
               ▼
              S3
Enter fullscreen mode Exit fullscreen mode

But now we have two separate questions:

Question 1:

Is the application allowed to access the S3 bucket?

That's an authorization question.

Question 2:

How does the network traffic reach S3?

That's a networking question.

These are different concepts.

20. IAM Controls Authorization

Suppose our EC2 application needs to download an object from S3.

We can attach an IAM Role to the EC2 instance.

That role can contain permissions such as:

s3:GetObject
Enter fullscreen mode Exit fullscreen mode

for a specific bucket or path.

So:

EC2
 │
 ▼
IAM Role
 │
 ▼
Permission to access S3
Enter fullscreen mode Exit fullscreen mode

IAM answers:

"Is this identity allowed to perform this AWS action?"

IAM does not create the network path to S3.

That distinction is extremely important.

21. VPC Endpoint: Private Connectivity to S3

Now let's look at the networking side.

For Amazon S3, we can use a Gateway VPC Endpoint.

The traffic can be:

Private EC2
     │
     ▼
Route Table
     │
     ▼
S3 VPC Endpoint
     │
     ▼
Amazon S3
Enter fullscreen mode Exit fullscreen mode

This allows access to S3 without requiring an Internet Gateway or NAT Gateway for that S3 traffic. AWS also documents that gateway endpoints can be associated with route tables and that they can be used for private access to S3.

For example, our private route table could conceptually contain:

10.0.0.0/16       local
S3 prefix list    S3 VPC Endpoint
0.0.0.0/0         NAT Gateway
Enter fullscreen mode Exit fullscreen mode

The more-specific S3 route can send S3 traffic to the endpoint, while other internet-bound traffic can continue through the NAT Gateway. AWS documents this routing pattern as well.

22. IAM vs VPC Endpoint

This is worth remembering.

                 Application
                    │
          ┌─────────┴─────────┐
          │                   │
       IAM Role          VPC Endpoint
          │                   │
          ▼                   ▼
   Authorization          Network Path
          │                   │
          └─────────┬─────────┘
                    ▼
                   S3
Enter fullscreen mode Exit fullscreen mode

In simple words:

IAM says:

"You are allowed to do this."

VPC Endpoint says:

"This is the private network path to the AWS service."

These two concepts work together, but they are not the same thing.

23. Let's Follow the Complete User Request

Now let's put everything together.

Imagine a user opens:

https://myapp.com
Enter fullscreen mode Exit fullscreen mode

Step 1 — DNS

The user's request needs to find where the application is hosted.

Route 53 provides DNS functionality.

User
 ↓
Route 53
Enter fullscreen mode Exit fullscreen mode

Step 2 — Internet

The request travels through the internet toward our AWS application.

User
 ↓
Internet
Enter fullscreen mode Exit fullscreen mode

Step 3 — Internet Gateway

The traffic enters the VPC through the Internet Gateway according to the configured routing.

Internet
 ↓
Internet Gateway
Enter fullscreen mode Exit fullscreen mode

Step 4 — Load Balancer

The Application Load Balancer receives the request.

Internet Gateway
 ↓
Application Load Balancer
Enter fullscreen mode Exit fullscreen mode

Step 5 — Application Server

The ALB forwards the request to a healthy application server in a private subnet.

ALB
 ↓
Private EC2
Enter fullscreen mode Exit fullscreen mode

Step 6 — Database

If the application needs data:

EC2
 ↓
RDS
Enter fullscreen mode Exit fullscreen mode

The database Security Group controls whether the application is allowed to connect.

Step 7 — S3

If the application needs an image or file:

EC2
 ↓
VPC Endpoint
 ↓
S3
Enter fullscreen mode Exit fullscreen mode

IAM permissions determine whether the application is authorized to access the required S3 object.

24. What If the Application Calls an External API?

Now imagine the application needs to call:

https://api.example.com
Enter fullscreen mode Exit fullscreen mode

The application is still in a private subnet.

The traffic follows:

Private EC2
     ↓
Private Route Table
     ↓
NAT Gateway
     ↓
Internet Gateway
     ↓
Internet
     ↓
External API
Enter fullscreen mode Exit fullscreen mode

This is one of the most useful traffic flows to understand when working with AWS.

25. The Architecture at a Glance

Now we can understand the complete architecture:

                              INTERNET
                                 │
                                 ▼
                             Route 53
                                 │
                                 ▼
                         Internet Gateway
                                 │
                   ┌─────────────┴─────────────┐
                   │                           │
              Public Subnet A            Public Subnet B
                   │                           │
                   └─────────────┬─────────────┘
                                 │
                        Application LB
                                 │
                 ┌───────────────┴───────────────┐
                 │                               │
          Private App Subnet A            Private App Subnet B
                 │                               │
              EC2 App A                       EC2 App B
                 │                               │
                 ├──────────────┐  ┌─────────────┤
                 │              │  │             │
                 ▼              │  │             ▼
                RDS             │  │            S3
                 │              │  │             ▲
                 │              │  │             │
                 │              └──┴──── VPC Endpoint
                 │
                 │
          Private outbound traffic
                 │
                 ▼
             NAT Gateway
                 │
                 ▼
          Internet Gateway
                 │
                 ▼
              INTERNET
Enter fullscreen mode Exit fullscreen mode

26. One Simple Mental Model

If you forget everything else from this article, remember these questions.

VPC

Where is my network?

Subnet

Where inside the network is my resource?

Route Table

Where should the traffic go?

Internet Gateway

How does my VPC communicate with the internet?

NAT Gateway

How can private resources initiate outbound internet connections?

Security Group

Which traffic is allowed to reach this resource?

Network ACL

Which traffic is allowed or denied at the subnet boundary?

IAM

Is this identity allowed to perform this AWS action?

VPC Endpoint

Can my VPC privately reach a supported AWS service?

Once you understand these questions, AWS networking becomes much less confusing.

27. The Most Important Lesson

AWS architecture is not about memorizing hundreds of services.

It is about understanding relationships.

A real application is not:

EC2
RDS
S3
VPC
Enter fullscreen mode Exit fullscreen mode

as four independent services.

It is:

User
  ↓
DNS
  ↓
Internet
  ↓
VPC
  ↓
Load Balancer
  ↓
Application
  ↓
Database
Enter fullscreen mode Exit fullscreen mode

while security and networking operate around those components:

                IAM
                 │
                 ▼
Application ──── RDS
    │
    ├── Security Groups
    │
    ├── Route Tables
    │
    ├── NACLs
    │
    └── VPC Endpoint ─── S3
Enter fullscreen mode Exit fullscreen mode

When you start thinking in terms of traffic flow, trust boundaries, routing, and authorization, AWS architecture becomes much easier to reason about.

28. Final Takeaway

You don't need to memorize every AWS service to start understanding cloud architecture.

Start with one question:

"Where does the request come from, where does it go, and what controls it along the way?"

From that one question, many AWS concepts become connected:

Request
   │
   ▼
DNS
   │
   ▼
Internet
   │
   ▼
Internet Gateway
   │
   ▼
Public Subnet
   │
   ▼
Load Balancer
   │
   ▼
Private Subnet
   │
   ▼
Application
   │
   ├──────────► RDS
   │
   ├──────────► S3 through VPC Endpoint
   │
   └──────────► Internet through NAT Gateway
Enter fullscreen mode Exit fullscreen mode

And around that traffic flow:

Route Tables
Security Groups
Network ACLs
IAM
Enter fullscreen mode Exit fullscreen mode

work together to control where traffic goes, what traffic is allowed, and what an identity is permitted to do.

That is the AWS architecture mental model I wish I had when I first started learning cloud.

What I Would Add to the Architecture Next

This article intentionally focuses on the networking foundation.

Once this mental model is clear, you can extend the architecture with:

  • AWS WAF
  • CloudFront
  • Auto Scaling
  • ECS/EKS
  • Lambda
  • SQS
  • EventBridge
  • CloudWatch
  • AWS Secrets Manager
  • AWS KMS
  • CI/CD
  • Terraform
  • Multi-region architecture

But don't put everything into the first diagram.

A good architecture diagram should explain a system, not display every AWS service you know.

A Final Note

This article is based on my current understanding of AWS networking and architecture as a Cloud/DevOps engineer.

I'm still learning, and that's exactly why I wanted to explain these concepts from the perspective of someone who is learning how individual AWS services connect to form a complete system.

If this helped you understand AWS architecture a little better, feel free to share it with someone who is learning AWS.

Happy building! ☁️

Top comments (0)