AWS Networking Services: How Do VPC, Security Group, NACL, ELB, and Route 53 Divide the Work?

VPC: your own private network

Before you even spin up an EC2 instance on AWS, there's a more fundamental question to answer: which network does this machine live in? Who can reach it? And where can it reach out to?

That's exactly what VPC (Virtual Private Cloud) answers. It's a logically isolated network you carve out inside your AWS account, defined by a CIDR (Classless Inter-Domain Routing) range like 10.0.0.0/16. You control the IP range, split it into subnets, and design the routing yourself—by default, no other account or VPC can see what's running inside.

A VPC is usually split into several subnets. What actually distinguishes a public subnet from a private one isn't some special tag on the subnet itself—it's where its route table points:

• Internet Gateway (IGW): attached to the VPC as a whole, it's what lets resources inside talk to the outside world. A public subnet's route table has a rule pointing to the IGW, which is why resources inside it—like a public-facing web server—can be reached directly from outside.
• NAT Gateway: sits in a public subnet, but exists for the private subnets. Resources in a private subnet—say, a database or internal service you don't want exposed—can still reach out (to pull package updates, call a third-party API) through the NAT Gateway, but nothing from outside can initiate a connection back in.

Think of a VPC as an office building you own: subnets are floors, the IGW is the front door, and the NAT Gateway is a side door that only swipes out—nobody from outside can swipe their way in.

Security Group and NACL: two firewalls, two different levels of granularity

Once the VPC lays out the network boundaries, the next question is which traffic gets to move in and out of these subnets and the resources inside them. AWS gives you two layers of firewall for this, and it's easy to mix them up at first—but they guard different checkpoints.

Security Group attaches at the instance level—EC2, RDS, and the like—and it's stateful: once an inbound rule allows a connection in, the response traffic is automatically allowed back out, no matching outbound rule required. Security Groups can also only allow, never deny—if you want to block something, you simply don't allow it.

NACL (Network ACL) attaches at the subnet level and governs all traffic in and out of an entire subnet. It's stateless: allowing traffic in doesn't automatically allow the response back out—inbound and outbound rules each need to be set explicitly. NACLs can also explicitly deny, and rules are evaluated in numbered order, low to high, stopping at the first match.

ELB: once traffic arrives, who gets it?

Even with everything locked down, there's still a problem: once your backend isn't one machine but a dozen, or a hundred, how does incoming traffic know which one to hit? The answer is it doesn't get to choose—ELB (Elastic Load Balancing) sits in front and handles the distribution.

ELB comes in a few flavors, depending on which network layer it operates at:

• ALB (Application Load Balancer): operates at Layer 7 (application layer) and actually understands HTTP/HTTPS content, so it can route based on things like URL path or Host header—say, sending /api/* to one backend group and /admin/* to another. A natural fit for microservices and containerized architectures that need fine-grained routing.
• NLB (Network Load Balancer): operates at Layer 4 (transport layer), handling raw TCP/UDP connections without inspecting their content. What you get in exchange is extremely high throughput and low latency, which makes it a good fit for game servers, financial trading systems, and other scenarios that are latency-sensitive or prone to sudden traffic spikes.
• CLB (Classic Load Balancer): the original generation, supporting both Layer 4 and Layer 7 but with fairly bare-bones features. New projects basically never reach for it anymore, and AWS recommends migrating any existing CLB to ALB or NLB.

Route 53: turning domain names into IP addresses

Everything so far has been about what happens once traffic arrives, but before that even happens, a user typed a domain name—say www.example.com—and that has to become an actual IP address first. That's an earlier problem to solve.

Route 53 is AWS's DNS (Domain Name System) service, named after the port DNS standardly runs on. You create a Hosted Zone in Route 53—essentially the full set of DNS records for a domain—and then add various records inside it: A records that point to an IP address, CNAME records that point to another domain name, and AWS's own Alias record, which can point directly at AWS resources like an ALB or CloudFront and, unlike CNAME, isn't restricted from being used at the root domain.

Where Route 53 goes further is in its routing policies, which do more than plain resolution:

• Weighted: splits traffic across multiple destinations by a configured ratio—useful for canary releases and A/B testing.
• Latency-based: resolves to whichever region gives the user the lowest latency.
• Failover: pairs with a health check on your primary site, and automatically shifts traffic to a backup site the moment the primary is marked unhealthy.

Putting it together: which checkpoint each service guards

Line these services up, and you'll see they each guard a different checkpoint along the same path—how traffic finds its way to your service from the outside, and how it gets safely routed to the right machine once it arrives:

Wrapping up

VPC carves out an isolated network that's yours alone. Security Group and NACL guard traffic at the instance level and the subnet level respectively. ELB spreads incoming traffic across a whole fleet of backend machines. And Route 53 sits at the very front, resolving the domain name a user typed into the entry point for all of this.