AWS Network Services Explained: VPC, Route 53, CloudFront and More

Amazon Virtual Private Cloud (Amazon VPC) is your logically isolated virtual network within the AWS Cloud. When you create a VPC, you define its private IP address range (a CIDR block, such as 10.0.0.0/16), and everything you launch with a network presence — EC2 instances, RDS databases, load balancers — lives inside it. "Logically isolated" is the phrase to remember: your VPC's traffic is separated from every other customer's, even though it runs on shared AWS infrastructure. When an exam question asks for "a logically isolated section of the AWS Cloud where you can launch resources in a virtual network you define," the answer is Amazon VPC.

You carve the VPC's IP range into subnets, smaller address ranges where resources are actually placed. The rule that matters most for the exam: each subnet exists in exactly one Availability Zone. A subnet cannot span AZs, while the VPC itself spans all AZs in its Region. The scope stops there: a VPC belongs to exactly one Region and cannot stretch across Regions — a multi-Region design uses a separate VPC in each Region. This is why highly available architectures use multiple subnets — one or more per Availability Zone — so an application can survive the loss of a single AZ.

Traffic direction inside a VPC is controlled by route tables. A route table is a set of rules attached to subnets that decides where network traffic is sent — locally within the VPC, out to the internet, or toward a gateway. Every route table contains a local route for the VPC's whole IP range, which cannot be removed: any subnet, public or private, can always reach resources in the VPC's other subnets. Other routes point traffic at a target — usually a gateway. At the Cloud Practitioner level you only need to recognize what a route table is; you will not configure one on the exam. But route tables are the key to the next concept, because a subnet's route table is exactly what makes it "public" or "private."

An internet gateway (IGW) is a VPC component that allows communication between your VPC and the internet — in both directions. A VPC has at most one internet gateway, and it is not a single point of failure: AWS runs it as a horizontally scaled, redundant and highly available component, so you never deploy a second one for resilience. A public subnet is simply a subnet whose route table has a route to that internet gateway: resources in it with public IP addresses can be reached from the internet and can reach out to it. A private subnet has no route to an internet gateway, so its resources cannot be reached directly from the internet at all. This definition — public means "routes to an IGW," private means "no direct internet route" — is tested constantly. A private subnet is not cut off from the rest of the VPC, though: the local route still lets its resources talk to every other subnet in the VPC.

Keep routing and filtering separate. A route decides whether a path to the internet exists at all; security groups and network ACLs only decide whether traffic is allowed to use a path that already exists. A security group or network ACL rule that allows inbound traffic from the internet therefore does nothing for a resource in a private subnet — with no route to an internet gateway, that traffic has no way in. To accept connections that start on the internet, a resource needs a public subnet (and a public IP address); its firewall rules then decide which of those connections are admitted.

But private resources often still need to initiate internet connections: a database server downloading security patches, an application server calling a third-party API. That is the job of a NAT gateway (network address translation). A NAT gateway lets resources in private subnets make outbound connections to the internet while blocking unsolicited inbound connections from the internet to those resources. Responses to outbound requests flow back, but nothing on the internet can start a conversation with a private instance. Where it lives depends on its mode: the long-standing zonal NAT gateway is placed in a public subnet in one Availability Zone and reaches the internet through that subnet's internet gateway, while a regional NAT gateway (introduced in 2025) is created for the VPC as a whole, spans its Availability Zones automatically and needs no public subnet. Either way, the private subnets' route tables send internet-bound traffic to the NAT gateway.

The internet-gateway-versus-NAT-gateway contrast is the single most common Task 3.5 question pattern:

• Internet gateway: two-way internet access for the VPC; required for public subnets. Trigger: "allow the VPC to communicate with the internet."
• NAT gateway: outbound-only internet access for private-subnet resources. Trigger: "instances in a private subnet need to download updates, but must not be reachable from the internet."

One more gateway sits on the edge of a VPC: the virtual private gateway, the AWS-side endpoint of a Site-to-Site VPN connection attached to the VPC. It carries traffic to and from your on-premises network, not to the internet, so it is neither an internet gateway nor a NAT gateway.

If the scenario mentions receiving traffic from the internet, think internet gateway and public subnet. If it mentions private resources reaching out — updates, patches, external APIs — while staying unreachable, think NAT gateway.

Put the components together with the layout the exam loves to describe: a classic three-tier web application — web tier, application tier, database tier — built for high availability across two Availability Zones.

Web tier (public subnets). The load balancer that receives customer traffic lives in public subnets, one in each Availability Zone. Those subnets are public because their route table sends internet-bound traffic to the VPC's internet gateway. This is the only tier that needs to accept connections from the internet.

Application tier (private subnets). The EC2 instances running business logic sit in private subnets. Nothing on the internet can connect to them directly — they receive traffic only from the load balancer inside the VPC. When these servers need to fetch operating system patches or call an external payment API, their route table sends that outbound traffic to a NAT gateway (a zonal one placed in a public subnet, or a regional one created for the VPC). Outbound works; unsolicited inbound is blocked.

Database tier (private subnets). The databases live in their own private subnets with no internet route at all, or route outbound through the same NAT gateway when patching requires it. They accept connections only from the application tier.

Spreading each tier across two Availability Zones is what protects it from an AZ outage: because a subnet lives in one AZ, the unit of AZ resilience is a matching subnet in another AZ. The internet gateway needs no such duplication — AWS already runs it as a redundant, horizontally scaled component.

Notice what each component contributes: the VPC provides the isolated network, subnets place resources into specific Availability Zones, route tables define which subnets are public or private, the internet gateway admits customer traffic to the web tier, and the NAT gateway lets the hidden tiers reach out without being exposed. When a question sketches an architecture like this and asks "which component allows the application servers to download updates?", you can now answer NAT gateway without hesitation.

Every VPC has two built-in security layers that work at different scopes. A security group acts as a virtual firewall at the resource level — it is attached to individual resources such as EC2 instances or load balancers and controls what traffic can reach and leave them. A network ACL (access control list) is a firewall at the subnet level — it filters traffic entering and leaving an entire subnet, applying to every resource inside it, whichever security groups those resources use. Remember the pairing as two layers of defense at two scopes: security group = instance, network ACL = subnet.

One behavioral difference matters even here: security groups support allow rules only — anything not allowed is denied, but you cannot write a rule that blocks a specific source. Network ACLs support both allow and deny rules, evaluated in number order. That makes the network ACL the place for an explicit deny that covers a whole subnet. Security groups have no deny rule: you can only narrow what they allow, and because resources in a subnet may use different groups (and one group can be shared across many resources), tightening access that way means editing every group involved. The remaining details (statefulness, rule evaluation) are examined under the security domain.

Neither is AWS WAF. WAF is a web application firewall that inspects HTTP(S) requests in front of Amazon CloudFront, Application Load Balancers and Amazon API Gateway (among other web front ends), filtering by patterns such as SQL injection or request rates. It is not attached to instances or subnets, so it is not a VPC security layer. Security groups and network ACLs are free and part of the VPC itself; neither is a separate service you subscribe to.

Use this table as your recognition sheet for VPC-component questions. The exam almost always gives you the middle column and expects you to produce the left column.

Three ways of connecting VPCs and services privately also appear as answer options:

• VPC peering connects exactly two VPCs so they can route traffic to each other privately. Peering is not transitive: if VPC A peers with B and B peers with C, A still cannot reach C through B, and A cannot use B's VPN or Direct Connect link to reach an on-premises network. Connecting many VPCs this way means a separate peering for every pair.
• AWS Transit Gateway exists to solve that: a central hub in a Region to which you attach many VPCs and on-premises connections (VPN or Direct Connect), and its route tables decide which attachments can reach which — replacing a mesh of peering connections with one central point of control.
• AWS PrivateLink exposes one specific service — an AWS service, your own service or a partner's — to consumers through interface VPC endpoints, keeping the traffic off the public internet. It gives access to that service only, not full network connectivity between VPCs, and it is not a route to arbitrary internet sites.

You will not be asked to configure any of them — only to recognize what each is and what it cannot do.

Amazon Route 53 is AWS's Domain Name System (DNS) web service. Its core purpose is translation: it converts human-friendly domain names such as www.example.com into the IP addresses computers use to connect to each other. Any exam question containing "DNS," "domain name resolution," or "translate domain names to IP addresses" points to Route 53. The name itself is a mnemonic — DNS traffic uses port 53.

Route 53 does three things you should be able to list. First, DNS resolution: it answers queries for your domain, directing users to resources inside AWS (a load balancer, a CloudFront distribution, an S3 static website) or outside it. Second, domain registration: you can buy and manage domain names directly through Route 53, so registration and DNS hosting live in one service. Two near-misses do neither: AWS Certificate Manager issues SSL/TLS certificates for domains you already own, and AWS Directory Service runs Microsoft Active Directory domains for users and computers, not internet domain names. Third, health-check-aware traffic routing: Route 53 can monitor the health of your endpoints and route users away from unhealthy ones.

That third capability is delivered through routing policies, which you only need to recognize at one line each: simple (one answer for everyone), weighted (split traffic by percentage), latency-based (send users to the Region that answers fastest for them), failover (switch to a standby when the primary fails its health check), geolocation (route by the user's location), and multivalue answer (answer each DNS query with up to eight healthy records chosen at random, so traffic spreads across the healthy endpoints). There are a few more (geoproximity, IP-based), but these cover the recognition level. Note the contrast between the last two kinds of resilience: failover keeps a standby idle until the primary's health check fails, whereas multivalue answer (like latency or weighted routing) sends live traffic to healthy endpoints all the time. If a question describes sending users to different endpoints based on where they are or how healthy the endpoint is, that is Route 53 doing DNS-level routing.

Keep Route 53 distinct from CloudFront: Route 53 tells the user's browser which address to connect to; it does not carry or cache the content itself — even latency-based routing only steers the user to a Region; it never serves content from a nearby location. Delivering the content quickly is the next section's job.

Amazon CloudFront is AWS's content delivery network (CDN). It caches copies of your content — images, video, static files, and also dynamic content and APIs — at edge locations around the world, so users are served from a nearby edge instead of crossing the globe to your origin server. The result is lower latency and less load on the origin. Triggers for CloudFront: "CDN," "cache content at edge locations," "deliver content with low latency to global users," "reduce load on the origin," or "stream video to viewers worldwide." CloudFront works naturally with origins such as Amazon S3 and load balancers, and it operates over HTTP and HTTPS. Do not confuse it with Amazon S3 Transfer Acceleration, a bucket feature that speeds long-distance uploads and downloads to one S3 bucket by routing them through edge locations; it does not cache content for viewers, so it is a transfer tool, not a CDN.

AWS Global Accelerator also uses AWS's edge network, but it solves a different problem. Instead of caching content, it improves the path your users' traffic takes: users connect to the nearest AWS edge location and their traffic then rides AWS's private global network to your application, avoiding the congestion and unpredictable routing of the public internet. It works for any TCP or UDP application — including non-HTTP workloads like gaming, VoIP, and IoT — and it gives you a pair of static anycast IP addresses that act as a fixed front door to endpoints in one or more Regions, improving both performance and availability.

The exam contrast to memorize: CloudFront caches content; Global Accelerator accelerates connections. If the scenario is about delivering or caching content (files, video, web pages) close to users, choose CloudFront. If it is about improving performance or availability for an application's network path, mentions TCP/UDP traffic that is not cacheable, or asks for static IP addresses that front a global application, choose Global Accelerator. Both are "edge services," both use AWS edge locations — the difference is what travels through them: cached content versus live connections.

A Network Load Balancer is the other near-miss. It also handles TCP and UDP and can have static IP addresses, but it is a Regional service: users still cross the public internet all the way to that Region. Global Accelerator's distinguishing feature is the entry point — traffic joins the AWS global network at the edge location nearest the user — and it commonly sits in front of load balancers rather than replacing them.

The final identification set covers how an on-premises network — a corporate data center or office — connects privately to AWS. AWS Site-to-Site VPN creates encrypted tunnels over the public internet between your on-premises network and your VPC; on the AWS side the tunnels end at a virtual private gateway on the VPC (or at a transit gateway). Because it runs over the internet, it is quick to set up and low cost, but its performance depends on internet conditions. Trigger phrases: "encrypted connection over the internet," "IPsec tunnel," "connect the data center to AWS quickly."

AWS Direct Connect is a dedicated, private physical network connection between your premises and AWS. Your traffic never touches the public internet, which gives consistent network performance and supports high bandwidth. It requires physical provisioning, so it takes longer to establish. Trigger phrases: "dedicated private connection," "does not traverse the public internet," "consistent, predictable network performance." For Task 3.5 you identify what each option is; note simply that they solve the same problem — private connectivity to AWS — by different means: encrypted-over-internet versus dedicated-physical-link. One more to recognize: AWS Client VPN connects individual users (for example, remote employees on laptops) securely to AWS or on-premises networks, whereas Site-to-Site VPN connects entire networks.

Close the topic with the service-level recognition table: