Inside an AWS Web Request
Exploring DevOps tools and practices.
When a user types https://seqas.online into a browser, what actually happens before the application appears on the screen?
Understanding the entire request lifecycle is far more valuable than memorizing individual AWS services. Every component—DNS, Route53, ACM, the Load Balancer, the VPC, Route Tables, the Internet Gateway, Security Groups, and EC2—exists to solve a specific networking problem.
This article follows a single request from the moment a user enters a domain name until the application responds, explaining not only what each component does but why it is required.
Architecture Overview
Rather than viewing these as independent AWS services, think of them as links in a chain. Removing any one of them would break the request flow.
The Journey Begins with a Domain Name
Users never remember IP addresses. They remember names.
https://seqas.online
However, computers communicate using IP addresses rather than domain names. Before any HTTP request can be sent, the browser must first answer a simple question:
Where does this domain exist?
This process is known as DNS resolution.
Without DNS, every website would have to be accessed using numerical IP addresses, making the internet practically unusable.
Domain Registration vs DNS Management
One of the most common misconceptions is that purchasing a domain automatically means that the same provider manages DNS.
These are actually two different responsibilities.
The domain was registered through GoDaddy, making GoDaddy the domain registrar. A registrar's responsibility is ownership—it records who owns the domain.
DNS management, however, determines where traffic should actually go.
Instead of allowing GoDaddy to manage DNS records, DNS authority is delegated to Amazon Route53, allowing the AWS ecosystem to control routing for the application.
Think of it this way:
The registrar owns the address.
The DNS provider tells the world where that address points.
Understanding Name Servers
This is arguably one of the most important concepts in the entire request lifecycle.
When a Hosted Zone is created in Route53, AWS automatically generates a set of authoritative Name Servers.
For example:
ns-xxxx.awsdns.com
ns-yyyy.awsdns.net
ns-zzzz.awsdns.org
ns-aaaa.awsdns.co.uk
These servers become responsible for answering DNS queries for the domain.
However, the internet does not automatically know this.
The registrar must be informed that Route53 is now the authoritative DNS provider. This is achieved by replacing GoDaddy's default Name Servers with the Name Servers generated by Route53.
Once this delegation occurs, the flow becomes:
User
↓
Internet DNS
↓
GoDaddy
↓
"Route53 is authoritative"
↓
Route53
↓
Returns DNS records
GoDaddy continues to own the domain, but Route53 becomes responsible for directing traffic.
Why Route53 Matters
Route53 functions as AWS's managed DNS service.
Whenever a browser requests the IP address associated with the domain, Route53 responds with the configured DNS records.
Instead of hardcoding infrastructure details into the domain registration itself, Route53 provides flexibility to map the domain to AWS resources such as:
Application Load Balancers
CloudFront distributions
EC2 instances
S3 static websites
Because DNS is separated from infrastructure, resources can evolve without requiring users to change the URL they access.
Establishing Trust with HTTPS
Finding the server is only the first step.
The browser must also verify that it is communicating with the legitimate server and that communication cannot be intercepted.
This is the purpose of HTTPS.
HTTPS relies on SSL/TLS certificates to establish encrypted communication between the client and the server.
AWS manages these certificates through AWS Certificate Manager (ACM).
How ACM Proves Domain Ownership
AWS cannot simply issue a certificate because someone requested one.
Ownership must first be verified.
To achieve this, ACM generates a DNS validation record that must exist within the Route53 Hosted Zone.
Conceptually:
ACM
↓
Creates validation record
↓
Route53 stores record
↓
ACM verifies record
↓
Certificate issued
Because Route53 is authoritative for the domain, ACM can confirm ownership and issue a trusted certificate.
This process enables browsers to establish secure HTTPS connections without displaying security warnings.
Enter the Application Load Balancer
After DNS resolution and certificate validation, the browser now knows where to send the request.
However, the request does not go directly to an EC2 instance.
Instead, it first reaches the Application Load Balancer (ALB).
The Load Balancer serves several purposes:
Provides a single public entry point
Terminates HTTPS connections
Performs health checks
Distributes traffic
Supports future horizontal scaling
This design prevents applications from being tightly coupled to individual servers.
If additional EC2 instances are introduced later, the public endpoint remains unchanged.
The VPC: A Private Network Inside AWS
Once traffic reaches AWS, it enters a Virtual Private Cloud (VPC).
A VPC is essentially an isolated network where IP ranges, routing, and security policies are controlled by the architect.
In this architecture, the VPC acts as the network boundary separating application infrastructure from the rest of AWS and the public internet.
Understanding Subnets
A VPC is divided into smaller logical networks called subnets.
For example:
VPC
10.0.0.0/16
├── Public Subnet
└── Private Subnet
Subnets allow workloads with different responsibilities and security requirements to remain isolated.
They are organizational and security boundaries rather than independent networks.
What Makes a Subnet Public?
Many engineers assume a subnet has a property called "public."
It does not.
A subnet becomes public because its associated Route Table contains a route directing internet-bound traffic toward an Internet Gateway.
Conceptually:
Subnet
↓
Route Table
↓
0.0.0.0/0
↓
Internet Gateway
Without this route, internet traffic cannot enter or leave the subnet.
This distinction is fundamental to understanding AWS networking.
The Internet Gateway
An Internet Gateway serves as the bridge between the VPC and the public internet.
Without it:
Internet
✖
VPC
Even if an EC2 instance has a public IP address, packets cannot traverse between the VPC and external networks.
The Internet Gateway enables that connectivity.
Route Tables: The GPS of the Network
Every packet leaving a resource needs routing instructions.
Route Tables provide those instructions.
They answer one question:
Where should this packet go next?
For internal traffic:
Destination:
10.0.0.0/16
↓
Stay inside VPC
For external traffic:
Destination:
0.0.0.0/0
↓
Internet Gateway
Without Route Tables, packets would have no defined path to their destinations.
Why Route Table Associations Matter
A Route Table by itself has no effect.
It becomes active only after being associated with a subnet.
Route Table
↓
Association
↓
Subnet
↓
Resources follow these routes
Every EC2 instance inside that subnet inherits those routing decisions.
Security Groups: The Final Gatekeeper
Routing determines whether traffic can reach a resource.
Security Groups determine whether that traffic should be accepted.
Think of Security Groups as stateful virtual firewalls attached directly to AWS resources.
Example:
Internet
↓
Load Balancer
↓
EC2
↓
Security Group
↓
Allow HTTPS
Allow HTTP
Allow SSH (restricted)
Even if packets successfully arrive at an EC2 instance, they will be rejected unless explicitly permitted.
This layered approach significantly improves security.
The Complete Request Journey
Now the entire flow can be viewed as one continuous sequence:
User enters:
https://seqas.online
↓
Browser initiates DNS lookup
↓
GoDaddy identifies Route53 as the authoritative DNS provider
↓
Route53 returns the application's Load balancer endpoint
↓
Browser initiates HTTPS connection
↓
ACM presents a trusted certificate
↓
TLS handshake succeeds
↓
Traffic enters the VPC via IGW
↓
Request reaches Application Load Balancer
↓
Forwarded to EC2 based on listeners in the Target Groups
↓
Route Table forwards traffic appropriately(EC2 is in private subnet so request needs to go from Public to Private subnet)
↓
Security Groups validate access
↓
EC2 receives the request
↓
Application processes business logic
↓
Response travels back through the same path
↓
Browser renders the application
Although this appears complex on paper, the entire sequence typically occurs within milliseconds.
Troubleshooting Common Issues
Domain does not resolve
Verify:
Name Servers configured in GoDaddy
Route53 Hosted Zone
DNS propagation
HTTPS fails
Verify:
ACM certificate status
DNS validation records
Certificate association with the Load Balancer
Application cannot be reached
Verify:
Load Balancer listeners
Target Group health
Internet Gateway
Route Tables
Security Groups
For a deeper dive into AWS network troubleshooting, including the commands and techniques used to trace connectivity issues across the architecture, see aws-network-flow.
Final Thoughts
Cloud architecture is often taught as a collection of independent AWS services.
In reality, it is a carefully connected system where every component solves a specific networking challenge.
The registrar establishes domain ownership.
Name Server delegation transfers DNS authority.
Route53 resolves the domain.
ACM establishes trust through HTTPS.
The Application Load Balancer provides a scalable public entry point.
The Internet Gateway connects the VPC to the internet.
Route Tables determine packet paths.
Security Groups enforce access control.
EC2 hosts the application that ultimately serves the user.
Understanding this complete traffic flow transforms AWS from a set of services into a coherent networking architecture, making it significantly easier to design, scale, and troubleshoot production systems.
Reference to Terraform Templates.
