Amazon VPC – Private Networking on AWS

1. The whole picture of a VPC

The section opens with one diagram that contains everything the rest of the chapter explains, and it is worth keeping in your head as a map. Inside a Region there is a VPC; inside an Availability Zone of that VPC sit a Public Subnet and a Private Subnet. An Internet Gateway connects the VPC to the Internet, a Router and its Route Tables decide where packets go, and a NAT Gateway in the public subnet lets private instances reach out. Security Groups wrap each EC2 instance and NACLs wrap each subnet. VPC Peering Connections join this VPC to others. A VPC Endpoint provides private paths to S3, Amazon DynamoDB and CloudWatch. VPC Flow Logs record what happens. On the hybrid side, a Corporate Data Center connects either through a Customer Gateway and VPN Gateway over an S2S VPN Connection, or through a DX Location over a Direct Connect Connection — and a Transit Gateway can sit in the middle as the hub for both VPN and DX.

Every component in that paragraph gets its own section below, and section 17 rebuilds the diagram step by step.

2. Understanding CIDR — the foundation

CIDR stands for Classless Inter-Domain Routing, a method for allocating IP addresses. You have already used it in Security Group rules and in AWS networking generally, because it is how a range of IP addresses is written down.

You have seen the two extremes:

• WW.XX.YY.ZZ/32 means exactly one IP.
• 0.0.0.0/0 means all IPs.

But anything in between is available too: 192.168.0.0/26 means 192.168.0.0 – 192.168.0.63, which is 64 IP addresses.

A CIDR has two components:

• The Base IP, an IP contained in the range, written XX.XX.XX.XX — for example 10.0.0.0 or 192.168.0.0.
• The Subnet Mask, which defines how many bits can change in the IP — for example /0, /24, /32.

The subnet mask can be written in two forms:

Short form	Full form
/8	255.0.0.0
/16	255.255.0.0
/24	255.255.255.0
/32	255.255.255.255

The subnet mask decides the size of the range

The subnet mask lets part of the underlying IP take additional values counting up from the base IP. Written out for a base of 192.168.0.0:

CIDR	Number of IPs	Range
192.168.0.0/32	1	192.168.0.0
192.168.0.0/31	2	192.168.0.0 to 192.168.0.1
192.168.0.0/30	4	192.168.0.0 to 192.168.0.3
192.168.0.0/29	8	192.168.0.0 to 192.168.0.7
192.168.0.0/28	16	192.168.0.0 to 192.168.0.15
192.168.0.0/27	32	192.168.0.0 to 192.168.0.31
192.168.0.0/26	64	192.168.0.0 to 192.168.0.63
192.168.0.0/25	128	192.168.0.0 to 192.168.0.127
192.168.0.0/24	256	192.168.0.0 to 192.168.0.255
192.168.0.0/16	65,536	192.168.0.0 to 192.168.255.255
192.168.0.0/0	All IPs	0.0.0.0 to 255.255.255.255

The quick memo the deck offers is the one to memorize, because it lets you answer most CIDR questions without doing any arithmetic. Counting the four octets of an IPv4 address:

• /32 — no octet can change.
• /24 — the last octet can change.
• /16 — the last 2 octets can change.
• /8 — the last 3 octets can change.
• /0 — all octets can change.

A small self-test

CIDR	Result
192.168.0.0/24	192.168.0.0 – 192.168.0.255 (256 IPs)
192.168.0.0/16	192.168.0.0 – 192.168.255.255 (65,536 IPs)
134.56.78.123/32	Just 134.56.78.123
0.0.0.0/0	All IPs

When in doubt during practice, the deck points at https://www.ipaddressguide.com/cidr as a calculator.

Public versus private IP (IPv4)

The Internet Assigned Numbers Authority (IANA) set aside certain blocks of IPv4 addresses for private (LAN) use, leaving everything else for public (Internet) use. Private IPs can only take these values:

Private range	CIDR	Note from the deck
10.0.0.0 – 10.255.255.255	10.0.0.0/8	Used in big networks
172.16.0.0 – 172.31.255.255	172.16.0.0/12	The AWS default VPC is in this range
192.168.0.0 – 192.168.255.255	192.168.0.0/16	For example, home networks

All the rest of the IP addresses on the Internet are public.

Exam tip

Memorize the three private ranges and which one holds the default VPC. Questions frequently hand you a CIDR and expect you to know immediately whether it is legal inside a VPC.

3. VPC and subnets

All new AWS accounts have a default VPC. New EC2 instances launch into the default VPC if no subnet is specified. The default VPC has Internet connectivity and all EC2 instances inside it get public IPv4 addresses, along with a public and a private IPv4 DNS name.

For VPCs you create yourself:

• VPC = Virtual Private Cloud.
• You can have multiple VPCs in an AWS Region — maximum 5 per Region, a soft limit.
• Maximum 5 CIDRs per VPC. For each CIDR, the minimum size is /28 (16 IP addresses) and the maximum size is /16 (65,536 IP addresses).
• Because a VPC is private, only the private IPv4 ranges are allowed — the three from the table above.
• Your VPC CIDR should NOT overlap with your other networks, for example the corporate network.

Subnets and the 5 IP addresses AWS reserves

Subnets are tied to an Availability Zone, and you define a CIDR for each one. AWS reserves 5 IP addresses in every subnet — the first 4 and the last 1. These addresses are not available for use and cannot be assigned to an EC2 instance.

For a subnet with CIDR block 10.0.0.0/24:

Address	Role
10.0.0.0	Network Address
10.0.0.1	Reserved by AWS for the VPC router
10.0.0.2	Reserved by AWS for mapping to the Amazon-provided DNS
10.0.0.3	Reserved by AWS for future use
10.0.0.255	Network Broadcast Address — AWS does not support broadcast in a VPC, so the address is reserved

Exam tip

The deck gives this exact calculation, and the exam gives it back to you. If you need 29 IP addresses for EC2 instances, you cannot choose a /27 (32 addresses, 32 − 5 = 27, which is less than 29). You need a /26 (64 addresses, 64 − 5 = 59, which is more than 29). Always subtract 5 before comparing.

4. Internet Gateway and route tables

An Internet Gateway (IGW) is what gives the resources inside a VPC — EC2 instances, for instance — a way out to the Internet. It scales horizontally and is both highly available and redundant, so there is nothing to size.

The facts that get tested:

• It must be created separately from the VPC and then attached.
• One VPC can only be attached to one IGW, and vice versa.
• The gateway by itself grants no Internet access; the route tables have to be edited as well.

That last point is the whole trick. Attaching the gateway is only half the job; until a route table entry sends 0.0.0.0/0 to the IGW, nothing changes. A subnet is “public” precisely because its route table points at an IGW.

5. Bastion Hosts

A Bastion Host is how you SSH into private EC2 instances. The bastion lives in the public subnet, which is connected to all the other private subnets, and you hop through it.

Two Security Group rules define the pattern:

• The Bastion Host security group must allow inbound from the Internet on port 22 from a restricted CIDR — for example the public CIDR of your corporation, not 0.0.0.0/0.
• The security group of the private EC2 instances must allow the security group of the Bastion Host, or the private IP of the Bastion Host.

Exam tip

Referencing the bastion’s security group rather than a CIDR is the answer the exam prefers, because it keeps working when the bastion is replaced and its private IP changes.

6. NAT Instance

NAT stands for Network Address Translation. A NAT Instance allows EC2 instances in private subnets to connect to the Internet. It is outdated, but still appears on the exam, so the configuration details matter:

• It must be launched in a public subnet.
• You must disable the EC2 setting Source / destination Check.
• It must have an Elastic IP attached.
• Route tables must be configured to route traffic from the private subnets to the NAT Instance.

The address rewriting is what the name describes. Following one request from a private instance at 10.0.0.20 to a server at 50.60.4.10, through a NAT Instance whose Elastic IP is 12.34.56.78:

Hop	Source	Destination
Private instance to NAT	10.0.0.20	50.60.4.10
NAT to Internet	12.34.56.78	50.60.4.10
Internet back to NAT	50.60.4.10	12.34.56.78
NAT back to private instance	50.60.4.10	10.0.0.20

The source/destination check has to be off precisely because the instance is forwarding packets that are neither from nor to itself.

Limitations of a NAT Instance

• A pre-configured Amazon Linux AMI is available, but it reached the end of standard support on December 31, 2020.
• It is not a highly available or resilient setup out of the box — you need to create an ASG in multi-AZ with a resilient user-data script.
• Internet traffic bandwidth depends on the EC2 instance type.
• You must manage security groups and rules yourself: inbound, allow HTTP/HTTPS traffic coming from the private subnets and allow SSH from your home network (access provided through the Internet Gateway); outbound, allow HTTP/HTTPS traffic to the Internet.

7. NAT Gateway

The NAT Gateway is the managed answer to all of that: an AWS-managed NAT with higher bandwidth, high availability and no administration. You pay per hour for usage and for bandwidth.

The specifics:

• A NAT Gateway is created in a specific Availability Zone and uses an Elastic IP.
• It cannot be used by an EC2 instance in the same subnet — only from other subnets.
• It requires an IGW: the path is private subnet, then NAT Gateway, then Internet Gateway.
• It provides 5 Gbps of bandwidth with automatic scaling up to 100 Gbps.
• There are no security groups to manage or required.

High availability for a NAT Gateway

A NAT Gateway is resilient within a single Availability Zone. To be fault tolerant you must create multiple NAT Gateways in multiple AZs. The subtlety worth understanding is why there is no failover between them: no cross-AZ failover is needed, because if an AZ goes down it does not need NAT — the instances that would have used it are gone too.

NAT Gateway versus NAT Instance

Criterion	NAT Gateway	NAT Instance
Availability	Highly available within an AZ (create another in a different AZ)	Use a script to manage failover between instances
Bandwidth	Up to 100 Gbps	Depends on the EC2 instance type
Maintenance	Managed by AWS	Managed by you — software, OS patches and so on
Cost	Per hour and amount of data transferred	Per hour, by EC2 instance type and size, plus network charges

The deck’s comparison table also lines the two up on Public IPv4, Private IPv4, Security Groups and whether it can be used as a Bastion Host — the security group row is the one already answered above: the NAT Gateway has none to manage, the NAT Instance has rules you own.

Real-world example

A team keeps a NAT Instance alive because it doubles as their SSH jump box and saves a few dollars. Then a batch job saturates the instance type’s bandwidth and every private subnet’s outbound traffic slows at once. The NAT Gateway’s 5 Gbps baseline scaling to 100 Gbps exists exactly to remove that failure mode.

8. Security Groups and NACLs

The order a packet passes through the two layers

For an incoming request, the packet meets the NACL inbound rules at the subnet boundary, then the SG inbound rules at the instance, and the response leaves under outbound allowed (stateful) at the security group but must still satisfy the NACL outbound rules (stateless).

For an outgoing request the mirror applies: NACL outbound rules, then SG outbound rules, with the reply inbound allowed (stateful) at the security group but subject to the NACL inbound rules (stateless).

Stateful versus stateless is the entire difference, and everything else follows from it.

Network Access Control List (NACL)

Think of a NACL as a firewall placed on the subnet’s edge, policing what enters and what leaves it. A subnet gets exactly one NACL, and until you say otherwise a brand-new subnet is handed the Default NACL.

The rules you write behave like this:

• Every rule carries a number between 1 and 32766, and the smaller the number, the earlier it is consulted.
• Evaluation stops at the first rule that matches. Write #100 ALLOW 10.0.0.10/32 alongside #200 DENY 10.0.0.10/32 and the address gets through, because rule 100 is reached first.
• Nothing that matches no rule survives: the final entry is an asterisk (*) that denies the request.
• AWS recommends adding rules in increments of 100, which leaves gaps to slot new rules into later.
• A NACL you have just created denies everything until you add rules.
• Because deny rules exist here and nowhere else, a NACL is the right place to block one specific IP address at the subnet level — something a security group cannot do at all.

The Default NACL

The Default NACL accepts everything inbound and outbound for the subnets it is associated with. Do not modify the Default NACL; create custom NACLs instead.

Direction	Rule #	Type	Protocol	Port Range	Source / Destination	Allow/Deny
Inbound	100	All IPv4 Traffic	All	All	0.0.0.0/0	ALLOW
Inbound	*	All IPv4 Traffic	All	All	0.0.0.0/0	DENY
Outbound	100	All IPv4 Traffic	All	All	0.0.0.0/0	ALLOW
Outbound	*	All IPv4 Traffic	All	All	0.0.0.0/0	DENY

Ephemeral ports

For any two endpoints to establish a connection they must use ports. The client connects to a defined port and expects the response on an ephemeral port. Different operating systems use different ranges:

Operating system	Ephemeral port range
IANA & MS Windows 10	49152 – 65535
Many Linux kernels	32768 – 60999

In the deck’s example, a client at 11.22.33.44 with ephemeral port 50105 sends a request to a web server at 55.66.77.88 on fixed port 443. The request carries source 11.22.33.44:50105 and destination 55.66.77.88:443; the response comes back with source 55.66.77.88:443 and destination 11.22.33.44:50105. A stateful security group allows that response automatically. A stateless NACL does not.

NACLs with ephemeral ports — a two-tier architecture

Take a Web Subnet (public) holding the web tier and a DB Subnet (private) holding a DB instance listening on port 3306. To let the web tier query the database through two custom NACLs, all four of these rules are required:

NACL	Rule needed
Web-NACL	Allow outbound TCP on port 3306 to the DB Subnet CIDR
Web-NACL	Allow inbound TCP on ports 1024-65535 from the DB Subnet CIDR
DB-NACL	Allow inbound TCP on port 3306 from the Web Subnet CIDR
DB-NACL	Allow outbound TCP on ports 1024-65535 to the Web Subnet CIDR

Two of the four rules exist only because of the return traffic. Forget them and the connection opens and then hangs.

The rules are written per target subnet CIDR, so a multi-AZ design with Web Subnet A, Web Subnet B, DB Subnet A and DB Subnet B needs a NACL rule for each target subnet’s CIDR — the rule count grows with the number of subnets, not with the number of instances.

Security Group versus NACL

Security Group	NACL
Sits at the instance boundary	Sits at the subnet boundary
Only allow rules exist	Both allow and deny rules exist
Stateful — the reply to an allowed flow comes back on its own, no matter what the rules say	Stateless — nothing comes back unless a rule permits it, which is where ephemeral ports bite
The verdict is reached after every rule has been considered	The verdict comes from walking the rules lowest number to highest and stopping at the first match
Attaches to an EC2 instance only because someone explicitly attached it	Covers every EC2 instance in the subnet it is associated with, automatically

9. VPC Peering

VPC Peering privately connects two VPCs using the AWS network, making them behave as if they were in the same network.

The three rules that answer nearly every peering question:

• The two VPCs must not have overlapping CIDRs.
• A VPC Peering connection is NOT transitive — it must be established for each pair of VPCs that need to communicate. Three VPCs that all need to talk need three connections: A–B, B–C and A–C.
• You must update the route tables in each VPC’s subnets so the EC2 instances can actually reach each other.

Two more facts:

• You can create a VPC Peering connection between VPCs in different AWS accounts and different regions.
• You can reference a security group in a peered VPC — this works across accounts, but only in the same region.

10. VPC Endpoints (AWS PrivateLink)

Reaching an AWS service normally means reaching a public URL, because that is how every one of them is exposed. A VPC Endpoint, which runs on AWS PrivateLink, replaces that public hop with a path that never leaves the private network. Endpoints are redundant and scale horizontally, and because the traffic stays inside, an IGW or a NAT Gateway is no longer part of the route to AWS services at all.

Concretely, an EC2 instance in a private subnet that needs Amazon SNS has two options: route out through a NAT Gateway and an Internet Gateway to the public endpoint, or go straight to a VPC Endpoint inside the VPC. The second option is shorter, private and usually cheaper.

When something does not work, check two things: DNS Setting Resolution in your VPC, and the Route Tables.

The two types of endpoint

Type	How it works	Coverage	Cost
Interface Endpoints (powered by PrivateLink)	You get an ENI holding a private IP address to enter through, and a Security Group has to be attached to it	Most AWS services	$ per hour + $ per GB of data processed
Gateway Endpoints	You get a gateway whose only use is as a target in a route table; security groups do not apply	S3 and DynamoDB, and nothing else	Free

Gateway or Interface Endpoint for S3?

• The Gateway endpoint is most likely going to be preferred all the time at the exam.
• Cost: free for Gateway, $ for the Interface endpoint.
• The Interface Endpoint is preferred when access is required from on-premises (over Site-to-Site VPN or Direct Connect), from a different VPC, or from a different region — cases where a route table entry inside one VPC is not enough.

Example: Lambda in a VPC reaching DynamoDB

DynamoDB is a public service from AWS, so a Lambda function placed inside a VPC has to get to a public endpoint somehow.

• Option 1: access from the public internet. Because Lambda is in a VPC, this needs a NAT Gateway in a public subnet and an Internet Gateway.
• Option 2, better and free: access from the private VPC network. Deploy a VPC Gateway Endpoint for DynamoDB and change the route tables.

AWS PrivateLink / VPC Endpoint Services, and ClassicLink

The section summary adds two related items:

• AWS PrivateLink / VPC Endpoint Services — connect services privately from your service VPC to a customer’s VPC. It does not need VPC Peering, the public Internet, a NAT Gateway or route tables, and it must be used with a Network Load Balancer and an ENI.
• ClassicLink — connect EC2-Classic EC2 instances privately to your VPC.

Exam tip

PrivateLink with a Network Load Balancer is the answer when a provider must expose a service to thousands of customer VPCs. Peering would require one connection and non-overlapping CIDRs per customer; PrivateLink scales without either constraint.

11. VPC Flow Logs

VPC Flow Logs capture information about the IP traffic going into your interfaces, at three levels:

• VPC Flow Logs
• Subnet Flow Logs
• Elastic Network Interface (ENI) Flow Logs

They help monitor and troubleshoot connectivity issues. The data can go to S3, CloudWatch Logs, and Kinesis Data Firehose. They also capture network information from AWS managed interfaces: ELB, RDS, ElastiCache, Redshift, WorkSpaces, NAT Gateway, Transit Gateway and others — which is what makes them useful for debugging managed services you cannot log into.

The syntax of a flow log line

A record contains these fields, in order: version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, log-status.

The three that matter most in practice:

• srcaddr and dstaddr help identify the problematic IP.
• srcport and dstport help identify the problematic ports.
• action records the success or failure of the request due to a Security Group or NACL.

Flow logs can be used for analytics on usage patterns or malicious behavior, and you query them using Athena on S3, or CloudWatch Logs Insights.

Using Flow Logs to debug Security Groups and NACLs

Look at the ACTION field and reason from stateful versus stateless:

Incoming requests

• Inbound REJECT — the cause is the NACL or the Security Group; either could have blocked it.
• Inbound ACCEPT, Outbound REJECT — the cause is the NACL. The security group is stateful, so if the request was accepted inbound, the response could not have been blocked by the security group.

Outgoing requests

• Outbound REJECT — NACL or Security Group.
• Outbound ACCEPT, Inbound REJECT — the NACL, for the same reason in reverse.

Exam tip

“Accepted one way, rejected on the way back” always points at the NACL. That single inference is worth a question on its own.

Three architectures for analyzing Flow Logs

Pipeline	What it gives you
VPC Flow Logs to CloudWatch Logs, then a Metric Filter, then a CW Alarm, then Amazon SNS	An alert on a pattern, for example unexpected SSH or RDP traffic
VPC Flow Logs to CloudWatch Logs, then CloudWatch Contributor Insights	The top-10 IP addresses by traffic
VPC Flow Logs to an S3 Bucket, then Amazon Athena, then Amazon QuickSight	Ad-hoc SQL analysis and dashboards

12. AWS Site-to-Site VPN

A Site-to-Site VPN joins a corporate data center to a VPC over the public Internet, with two gateways at the ends:

• The Virtual Private Gateway (VGW) is the VPN concentrator on the AWS side of the VPN connection. It is created and attached to the VPC from which you want to create the Site-to-Site VPN connection, and you can customize its ASN (Autonomous System Number).
• The Customer Gateway (CGW) is the software application or physical device on the customer side of the VPN connection.

Configuration details that get tested

Which IP address does the Customer Gateway device use?

• The public, Internet-routable IP address of your Customer Gateway device.
• If it is behind a NAT device that is enabled for NAT traversal (NAT-T), use the public IP address of the NAT device.

Two more steps that are easy to skip and produce a VPN that is “up” but carries no traffic:

• Important: enable Route Propagation for the Virtual Private Gateway in the route table associated with your subnets.
• If you need to ping your EC2 instances from on-premises, add the ICMP protocol to the inbound rules of your security groups. A failing ping is very often just a missing ICMP rule, not a broken tunnel.

AWS VPN CloudHub

AWS VPN CloudHub provides secure communication between multiple sites if you have multiple VPN connections. It is a low-cost hub-and-spoke model for primary or secondary network connectivity between different locations — VPN only.

• Because it is a VPN connection, it goes over the public Internet.
• To set it up, connect multiple VPN connections on the same VGW, set up dynamic routing and configure the route tables.

The result is that customer networks at different sites can reach each other through the VGW, not only reach the VPC.

13. AWS Direct Connect (DX)

Direct Connect provides a dedicated private connection from a remote network to your VPC. A dedicated connection must be set up between your data center and an AWS Direct Connect location, and you need to set up a Virtual Private Gateway on your VPC.

One connection carries both kinds of traffic: you access public resources such as S3 and private resources such as EC2 over the same connection, using a public virtual interface and a private virtual interface on separate VLANs.

Use cases:

• Increase bandwidth throughput — working with large data sets, at lower cost.
• A more consistent network experience — applications using real-time data feeds.
• Hybrid environments — on-premises plus cloud.

It supports both IPv4 and IPv6.

Direct Connect Gateway

If you want to set up a Direct Connect to one or more VPCs in many different regions within the same account, you must use a Direct Connect Gateway. One AWS Direct Connect connection from the customer network reaches the gateway, and private virtual interfaces fan out from it to a VPC of 10.0.0.0/16 in us-east-1 and a VPC of 172.16.0.0/16 in us-west-1.

Connection types

Type	Capacity	How it is ordered
Dedicated Connections	1 Gbps, 10 Gbps and 100 Gbps	A physical ethernet port dedicated to one customer; the request is made to AWS first, then completed by AWS Direct Connect Partners
Hosted Connections	50 Mbps, 500 Mbps, up to 10 Gbps (with 1, 2, 5, 10 Gbps available at select partners)	Requests are made via AWS Direct Connect Partners; capacity can be added or removed on demand

Lead times are often longer than 1 month to establish a new connection — which is the fact that decides several exam scenarios about urgent migrations.

Encryption on Direct Connect

Data in transit is not encrypted, but it is private. If you need encryption, AWS Direct Connect + VPN provides an IPsec-encrypted private connection. It is good for an extra level of security, but slightly more complex to put in place.

Exam tip

“Private” and “encrypted” are not the same claim. Any question that asks for an encrypted connection over Direct Connect is asking for DX + VPN, never DX alone.

Resiliency for Direct Connect

The deck shows two postures:

• High resiliency for critical workloads — one connection at each of multiple locations, so the loss of a single Direct Connect location does not disconnect you.
• Maximum resiliency for critical workloads — separate connections terminating on separate devices in more than one location, removing the device as well as the location as a single point of failure.

Site-to-Site VPN as a backup

In case Direct Connect fails, you can set up a backup Direct Connect connection — expensive — or a Site-to-Site VPN connection. The VPN is the cheap insurance: lower bandwidth and over the public Internet, but it keeps the corporate data center talking to the VPC while the DX link is repaired.

14. Transit Gateway

Network topologies get complicated fast: a handful of VPCs meshed with VPC Peering connections, several VPN connections to customer gateways and a Direct Connect Gateway produce exactly the tangle of criss-crossing links the slide is titled after — and because peering is not transitive, every pair that has to talk needs a link of its own.

Transit Gateway gives you transitive peering between thousands of VPCs and on-premises networks in a hub-and-spoke (star) connection.

• It is a regional resource that can work cross-region.
• Share it cross-account using Resource Access Manager (RAM).
• You can peer Transit Gateways across regions.
• Route Tables limit which VPC can talk with which other VPC — the hub is also the policy point.
• It works with Direct Connect Gateway and VPN connections.
• It supports IP Multicast, which is not supported by any other AWS service.

Site-to-Site VPN ECMP

ECMP stands for Equal-cost multi-path routing, a routing strategy that allows a packet to be forwarded over multiple best paths. The use case here: create multiple Site-to-Site VPN connections to increase the bandwidth of your connection to AWS, all attached to the Transit Gateway alongside the VPC attachments.

Throughput with ECMP

Setup	Throughput
VPN to a Virtual Private Gateway (1 VPC, one VPN connection with 2 tunnels)	1.25 Gbps
VPN to a Transit Gateway, 1x	2.5 Gbps (ECMP) — 2 tunnels used
VPN to a Transit Gateway, 2x	5.0 Gbps (ECMP)
VPN to a Transit Gateway, 3x	7.5 Gbps (ECMP)

Note that the Transit Gateway also charges per GB of TGW processed data, so the extra bandwidth is not free.

Sharing a Direct Connect between multiple accounts

A Transit VIF on a VLAN from the AWS Direct Connect endpoint reaches a Direct Connect Gateway in Account 1, which connects to a Transit Gateway that serves the VPCs in Account 2. You can use AWS Resource Access Manager to share the Transit Gateway with other accounts — one physical connection, many accounts behind it.

15. VPC Traffic Mirroring

Traffic Mirroring takes a copy of the network traffic moving through your VPC so you can inspect it, and sends that copy on to security appliances that you run yourself.

• The source is always an ENI.
• The target is either an ENI or a Network Load Balancer.
• You choose between copying every packet and copying only the ones you care about, and packets can be truncated if you want just the headers.
• Source and target may share a VPC or live in two different ones, provided the two are joined by VPC Peering.

The deck’s use cases are content inspection, threat monitoring and troubleshooting.

In the deck’s picture, inbound and outbound traffic from Source A and Source B is mirrored — with an optional filter — to a Network Load Balancer fronting an Auto Scaling group of EC2 instances running security appliances.

16. IPv6 in a VPC

IPv4 was designed to provide 4.3 billion addresses, and they will be exhausted soon. IPv6 is its successor, designed to provide 3.4 × 10³⁸ unique IP addresses.

The property that changes how you design: every IPv6 address in AWS is public and Internet-routable — there is no private range.

The format is eight hexadecimal segments, each from 0000 to ffff, for example 2001:db8:3333:4444:5555:6666:7777:8888 or 2001:db8:3333:4444:cccc:dddd:eeee:ffff. Zero compression is what makes the notation readable:

Notation	Meaning
::	All 8 segments are zero
2001:db8::	The last 6 segments are zero
::1234:5678	The first 6 segments are zero
2001:db8::1234:5678	The middle 4 segments are zero

How IPv6 works inside a VPC

• There is no switching IPv4 off, for the VPC or for its subnets.
• Turning IPv6 on — remembering that those addresses are public — puts the VPC into dual-stack mode.
• Each EC2 instance then holds at minimum one private internal IPv4 and one public IPv6.
• Either protocol will carry its traffic to the Internet, and both go through the Internet Gateway.

So an instance ends up with, for example, private IP 10.0.0.5 and IPv6 2001:db8::ff00:42:8329, both reachable through the same IGW.

Troubleshooting IPv4 once IPv6 is on

Because IPv4 cannot be disabled for your VPC and subnets, a launch failure has only one likely cause. If you cannot launch an EC2 instance in your subnet, it is not because it cannot acquire an IPv6 — that space is very large. It is because there are no available IPv4 addresses in your subnet. The solution is to create a new IPv4 CIDR in your subnet.

Exam tip

This scenario is written to bait you into blaming IPv6. The answer is always “the subnet ran out of IPv4 addresses, add an IPv4 CIDR”.

Egress-only Internet Gateway

This gateway exists for IPv6 only, and the deck’s own analogy is the right one to keep: it is the NAT Gateway’s IPv6 counterpart. Instances behind it can open outbound IPv6 connections, while an IPv6 connection started from the Internet towards them never lands. And as everywhere else in this chapter, the route tables have to be updated.

The contrast in the diagram is exact: through the plain Internet Gateway, connections can be initiated from both sides; through the Egress-only Internet Gateway, the Internet cannot initiate connections.

IPv6 routing — two example route tables

For a VPC of 10.0.0.0/16 and 2001:db8:1234:1a00::/56, with a public subnet (10.0.0.0/24, 2001:db8:1234:1a00::/64) and a private subnet (10.0.1.0/24, 2001:db8:1234:1a02::/64):

Public subnet route table

Destination	Target
10.0.0.0/16	local
2001:db8:1234:1a00::/56	local
0.0.0.0/0	igw-id
::/0	igw-id

Private subnet route table

Destination	Target
10.0.0.0/16	local
2001:db8:1234:1a00::/56	local
0.0.0.0/0	nat-gateway-id
::/0	eigw-id

The pattern to remember: in the private subnet, IPv4 leaves through the NAT Gateway and IPv6 leaves through the Egress-only Internet Gateway; in the public subnet both default routes point at the Internet Gateway.

17. Building a three-tier VPC step by step

The hands-on part of the section is presented as one diagram that grows by exactly one component per lesson. That order is also a sensible order to rebuild it yourself in the console:

1. VPC — start with an empty Region and create the VPC, choosing a CIDR that does not overlap your other networks.
2. Subnets — inside an Availability Zone, add a Public Subnet and a Private Subnet.
3. Internet Gateway — create it separately, then attach it to the VPC.
4. Route Tables — add the Router and a Route Table pointing the public subnet at the IGW, then launch a Public EC2 Instance with a Security Group and confirm it reaches the Internet.
5. NAT Instance — put a NAT Instance with an EIP in the public subnet and give the private subnet its own route table pointing at it, so the Private EC2 Instance can reach the Internet.
6. NAT Gateway — replace the NAT Instance with the AWS-managed NAT Gateway, keeping the same route table idea.
7. NACLs — add a NACL to both the public and the private subnet as the second firewall layer beside the security groups.
8. VPC Peering — add VPC Peering Connections to reach other VPCs.
9. VPC Endpoints — add a VPC Endpoint so the private subnet can reach S3, Amazon DynamoDB and CloudWatch without the Internet.
10. VPC Flow Logs — turn flow logs on at the VPC level so you have troubleshooting data.
11. Site-to-Site VPN — add the VPN Gateway on the AWS side, the Customer Gateway at the Corporate Data Center, and the S2S VPN Connection between them.
12. Direct Connect and Transit Gateway — finally add the DX Location with its Direct Connect Connection, and a Transit Gateway as the hub for all the VPN and DX links.

At step 12 the picture is exactly the overview diagram from section 1 — the chapter closes its own loop.

18. Networking costs on AWS

Networking is one of the easiest costs to overlook, and the deck reduces it to a simple per-GB picture:

Path	Price
Traffic in (ingress)	Free
Within the same AZ, using private IP	Free
Between two AZs in the same Region, using private IP	$0.01
Between two AZs in the same Region, using a Public IP / Elastic IP	$0.02
Inter-region	$0.02

Two pieces of advice follow directly from the table:

• Use private IP instead of public IP for good savings and better network performance.
• Use the same AZ for maximum savings — at the cost of high availability. That is a genuine trade-off, not an unqualified best practice.

Minimizing egress traffic cost

• Egress traffic is outbound traffic, from AWS to the outside.
• Ingress traffic is inbound traffic, from outside into AWS, and is typically free.
• The principle: try to keep as much internet traffic within AWS as possible to minimize costs.
• Direct Connect locations that are co-located in the same AWS Region result in lower cost for egress network.

The deck’s example makes it concrete: a DB Query of 100 MB returns Query Results of 50 KB. If the application sits in AWS next to the database, only the 50 KB of results leave — egress cost is minimized. If the application stays in the corporate data center while the database is on AWS, that same 100 MB query has to cross the boundary every time — egress cost is high. The lesson is to put the compute next to the data.

S3 Data Transfer pricing — analysis for the USA

Path	Price per GB
S3 ingress	Free
S3 to Internet	$0.09
S3 Transfer Acceleration	an additional $0.04 to $0.08 on top of Data Transfer pricing, in exchange for 50% to 500% faster transfer times
S3 to CloudFront	$0.00
CloudFront to Internet	$0.085 — slightly cheaper than S3, plus caching capability (lower latency) and reduced S3 Requests pricing (7x cheaper with CloudFront)
S3 Cross Region Replication	$0.02

This is one of the reasons the “S3 + CloudFront” architecture appears everywhere — see CloudFront & Global Accelerator.

NAT Gateway versus Gateway VPC Endpoint on price

The deck builds a VPC 10.0.0.0/16 in us-east-1 with two private subnets that both want to read an S3 bucket. Private subnet 1 (10.0.0.0/24) goes out through a NAT Gateway and then the Internet Gateway; private subnet 2 (10.0.1.0/24) goes through a VPC Endpoint. The first subnet’s route table sends 10.0.0.0/16 to Local and 0.0.0.0/0 to igw-id; the second sends 10.0.0.0/16 to Local and the pl-id for Amazon S3 to vpce-id.

Path	Cost
NAT Gateway	$0.045 per hour
NAT Gateway data processed	$0.045 per GB
Data transfer out to S3 (cross-region)	$0.09
Data transfer out to S3 (same-region)	$0.00
Gateway Endpoint	No cost for using it
Data transfer in/out through the endpoint (same-region)	$0.01

Putting the two columns side by side shows the gap immediately: the NAT Gateway path pays both an hourly charge and $0.045 for every GB processed, while the Gateway Endpoint itself costs nothing to use and leaves only $0.01 per GB in and out within the region. That is why the Gateway endpoint is described as “preferred all the time at the exam” in section 10.

19. Network protection and AWS Network Firewall

Everything the section has shown for guarding a network on AWS adds up to five names: the Network Access Control Lists (NACLs) and Amazon VPC security groups from this chapter, plus AWS WAF (aimed at malicious requests), AWS Shield and AWS Shield Advanced, and AWS Firewall Manager, whose job is to manage them across accounts.

The last three are covered in Security & Encryption. What the deck asks next is the interesting part: none of those five covers an entire VPC in a sophisticated way. That gap is what the next service fills.

AWS Network Firewall

Network Firewall is scoped to your entire Amazon VPC and reaches from Layer 3 to Layer 7, and there is no direction it cannot inspect. The four the deck spells out:

• traffic from one VPC to another
• traffic leaving for the internet
• traffic arriving from the internet
• traffic in either direction over Direct Connect and Site-to-Site VPN

Two implementation facts are worth carrying into the exam. The service is built on top of the AWS Gateway Load Balancer under the hood, and its rules can be owned centrally: AWS Firewall Manager can push one rule set cross-account to many VPCs at once.

Fine grained controls

The rule engine holds thousands of rules, and they match on more than addresses:

• IP and port, at a scale of tens of thousands of IP addresses.
• Protocol — the deck’s example is shutting off the SMB protocol on outbound communications.
• Stateful domain list rule groups, so outbound traffic is permitted only to a named domain such as *.mycorp.com or a third-party software repository.
• Regex, for general pattern matching.
• Three verdicts per match — traffic can be allowed, dropped, or merely alerted on.
• Active flow inspection, which brings intrusion-prevention capabilities against network threats; the deck compares it to Gateway Load Balancer, with AWS doing all the managing.
• Logging of rule matches out to Amazon S3, CloudWatch Logs or Kinesis Data Firehose.

Exam tip

Three layers are easy to confuse. Security Groups and NACLs filter on IP and port at the instance and subnet level. AWS WAF is the one aimed at malicious requests. AWS Network Firewall filters Layer 3 to Layer 7 for the whole VPC, including VPC-to-VPC traffic and traffic arriving over DX or VPN.

Quick recap

Topic	What to remember for the exam
CIDR	Base IP + Subnet Mask. Octet memo: /32 changes no octet, /24 the last, /16 the last two, /8 the last three, /0 all of them
Private IP ranges	10.0.0.0/8, 172.16.0.0/12 (where the AWS default VPC lives), 192.168.0.0/16
VPC limits	5 VPCs per Region (soft limit), 5 CIDRs per VPC, each from /28 to /16, must not overlap your other networks
Subnets	AWS reserves 5 IPs (first 4, last 1). Needing 29 usable IPs means a /26, not a /27
Internet Gateway	One VPC to one IGW, horizontally scaled and highly available, but you must edit the route table for Internet access
Bastion Host	In the public subnet, SG allows port 22 from a restricted CIDR; private instances allow the bastion’s security group
NAT Instance	Public subnet, disable Source / destination Check, needs an Elastic IP, you manage the SGs, not HA by default (needs a multi-AZ ASG), bandwidth follows the instance type, AMI standard support ended December 31, 2020
NAT Gateway	Managed, 5 Gbps scaling to 100 Gbps, uses an EIP, requires an IGW, cannot serve its own subnet, no security groups, HA within one AZ so create one per AZ
NACL	Stateless, subnet level, supports deny rules, rule numbers 1–32766 (lowest wins, first match wins, * denies), a new NACL denies everything, do not edit the Default NACL
Security Group	Stateful, instance level, allow rules only, all rules evaluated
Ephemeral ports	IANA & Windows 10 49152–65535, many Linux kernels 32768–60999; with NACLs the return path needs 1024-65535
VPC Peering	No overlapping CIDRs, not transitive, update route tables on both sides; cross-account and cross-region supported; referencing a peer’s security group works cross-account but same-region only
VPC Endpoints	Interface (ENI + Security Group, most services, per hour + per GB) versus Gateway (route table target, S3 and DynamoDB only, free). Prefer Gateway for S3 at the exam; choose Interface for access from on-premises, another VPC or another region. On failure, check DNS resolution and route tables
PrivateLink	Expose a service from your VPC to customer VPCs with a Network Load Balancer and an ENI, no peering, no Internet, no NAT, no route tables
VPC Flow Logs	At VPC / Subnet / ENI level, records ACCEPT and REJECT, destinations S3, CloudWatch Logs, Kinesis Data Firehose, covers managed interfaces (ELB, RDS, ElastiCache, Redshift, WorkSpaces, NATGW, Transit Gateway), queried with Athena or CloudWatch Logs Insights. Accepted one way and rejected on the way back means NACL
Site-to-Site VPN	VGW on AWS (custom ASN possible) plus CGW on the customer side; use the NAT device’s public IP with NAT-T; enable Route Propagation; add ICMP to ping. VPN CloudHub is hub-and-spoke over multiple VPNs on one VGW, across the public Internet
Direct Connect	Private but not encrypted (encryption means DX + VPN); Dedicated 1/10/100 Gbps, Hosted 50 Mbps to 10 Gbps on demand; lead time over 1 month; Direct Connect Gateway reaches VPCs in several regions in the same account; back it up with a Site-to-Site VPN
Transit Gateway	Transitive hub-and-spoke for thousands of VPCs, VPNs and DX; regional but peerable cross-region; shared with RAM; route tables control who talks to whom; the only AWS service supporting IP Multicast. ECMP: VGW 1.25 Gbps, TGW 2.5 / 5.0 / 7.5 Gbps at 1x / 2x / 3x
Traffic Mirroring	Source is an ENI, target is an ENI or NLB, same VPC or peered VPC, packets can be filtered and truncated
IPv6	Every AWS IPv6 address is public; IPv4 cannot be disabled; a failed launch means no IPv4 left, so add an IPv4 CIDR. Egress-only Internet Gateway is the IPv6 equivalent of a NAT Gateway, outbound only, route ::/0 to eigw-id
Networking cost	Ingress free, same AZ over private IP free, cross-AZ private IP $0.01/GB, public or Elastic IP $0.02/GB, inter-region $0.02/GB; S3 to Internet $0.09/GB versus CloudFront $0.085/GB; Gateway Endpoint free versus NAT Gateway $0.045/hour + $0.045/GB
AWS Network Firewall	Protects the whole VPC, Layer 3 to 7, any direction including VPC-to-VPC and DX/VPN, built on Gateway Load Balancer, managed cross-account by Firewall Manager, logs to S3 / CloudWatch Logs / Kinesis Data Firehose