Build a Two-AZ AWS VPC

Build a resilient two-AZ VPC with private NAT egress and secure instance access.

Introduction

30 Second Summary

A door labelled private offers little protection if its path still leads straight outside. Network labels have the same weakness until traffic proves where it can travel.

In this project, you will manually build a two-zone Amazon Virtual Private Cloud (Amazon VPC) with separate public and private subnets. You will prove that a private Amazon Elastic Compute Cloud (Amazon EC2) probe gains controlled internet access through same-zone NAT gateways while its public IPv4 address stays blank.

What You'll Build

Your demo shows a four-subnet resource map beside a private probe whose internet test changes from silence to live replies after you add same-zone NAT routes.

By the end of this project, you'll have:

  • A two-tier network layout that visibly separates four subnets across two Availability Zones.
  • A private probe you can administer through an EC2 Instance Connect Endpoint without assigning a public IPv4 address or running a bastion host.
  • A repeatable connectivity test that changes from no replies to live replies when you add the same-zone NAT route.
  • Secret Mission: Remove a working private default route, diagnose the outage from the route table and resource map, then restore service.

Are there any prerequisites?

You need an AWS account or sandbox that permits VPC and EC2 lifecycle operations. Use Microsoft Edge or Google Chrome on Windows with AWS credits or sandbox coverage for the paid resources.

Before We Start

Before any resources are created, this is your moment to lock in the network you are building and the behavior you plan to prove. You will use that goal to guide every routing decision in the project.

Preflight Access and Choose the Region

Your two-AZ network later creates resources that can accrue charges. A missing permission could stop the lab after those resources exist.

This preflight checks your AWS Management Console access for Amazon Virtual Private Cloud (Amazon VPC) plus Amazon Elastic Compute Cloud (Amazon EC2). It also locks every later resource to one Region plus two Availability Zones.

In this step, get ready to:
  • Choose one Region plus two standard Availability Zones.
  • Confirm the sandbox permissions required for creation through cleanup.
  • Set the naming and IPv4 address plan.
Choose one Region and two Availability Zones

An AWS Region keeps this lab's regional resources in one location. Availability Zones give the VPC two separate locations inside that Region.

  • Use Microsoft Edge or Google Chrome to sign in to the AWS Management Console with your sandbox credentials.
  • Choose the Regions selector in the console navigation bar.
  • Select US East (N. Virginia) unless your sandbox requires another Region.
  • Record the selected Region as your selected AWS Region.

The selected Region now appears in the console navigation bar. Every regional page you visit should show this same selection.

  • Enter EC2 in the console search bar.
  • Select Amazon EC2 from the search results.
  • Select EC2 Dashboard in the navigation pane.
  • Choose Account attributes in the upper-right corner.
  • Choose Zones.
  • Identify the first two entries classified as Availability Zones while excluding Local Zone and Wavelength Zone entries.
  • Record the first standard zone as your first standard Availability Zone.
  • Record the second standard zone as your second standard Availability Zone.

That is your first guardrail in place: every later resource now has one Region boundary plus two standard zones.

Preflight the required permissions

Your assigned role's IAM permissions control every create operation. They also control the cleanup operations that prevent unwanted charges.

  • Review the permission guide or role summary supplied by your sandbox administrator.
  • Confirm permission to create, describe, tag, modify, and delete VPCs, subnets, route tables, routes, plus Internet Gateways.
  • Confirm permission to allocate plus release Elastic IP addresses.
  • Confirm permission to create, describe, tag, modify, and delete NAT gateways plus security groups.
  • Confirm permission to launch, describe, tag, modify, and terminate EC2 instances.
  • Confirm endpoint creation includes ec2:CreateInstanceConnectEndpoint, ec2:CreateNetworkInterface, ec2:CreateTags, plus iam:CreateServiceLinkedRole when the service-linked role is absent.
  • Confirm permission to describe, modify, and delete EC2 Instance Connect Endpoints plus their network interfaces.
  • Confirm endpoint connections include ec2-instance-connect:OpenTunnel plus ec2-instance-connect:SendSSHPublicKey.

If a Permission Is Missing

Sandbox roles are often narrower than full AWS accounts. A missing action needs an administrator decision before this lab creates anything.

  • Capture the denied action from any AccessDenied message.
  • Request the missing action from your sandbox administrator.
  • Keep SSH closed to 0.0.0.0/0 while the access issue is unresolved.

Need help interpreting the policy boundary? Help me identify which AWS permission my sandbox role is missing.

Lock in the naming and address plan

A CIDR block defines the IPv4 range available to a network. These four /24 subnet ranges fit inside the VPC's /16 range without overlapping.

  • Set the planned VPC to nw-network-lab with IPv4 CIDR 10.0.0.0/16.
  • Use your first standard Availability Zone as AZ A.
  • Use your second standard Availability Zone as AZ B.
  • Assign nw-public-a the IPv4 CIDR 10.0.0.0/24 in AZ A.
  • Assign nw-private-a the IPv4 CIDR 10.0.1.0/24 in AZ A.
  • Assign nw-public-b the IPv4 CIDR 10.0.2.0/24 in AZ B.
  • Assign nw-private-b the IPv4 CIDR 10.0.3.0/24 in AZ B.

Before you check the consoles, do you expect both service pages to expose their creation controls?

  • Check that the console's Regions selector shows your selected AWS Region.
  • Enter VPC in the console search bar.
  • Select Amazon VPC from the search results.
  • Check whether the VPC dashboard displays Create VPC without an AccessDenied message.
  • Use the console search bar to return to Amazon EC2.
  • Select Instances in the navigation pane.
  • Check whether the Instances page displays Launch instance without an AccessDenied message.

You should see Create VPC on the VPC dashboard. You should also see Launch instance on the EC2 Instances page.

That's the risk cleared: your selected Region exposes both creation paths. No billable project resources exist yet.

Seeing AccessDenied?

Stop before creating any project resource. The denied action identifies the permission your sandbox administrator needs to review.

  • Capture the denied action shown in the message.
  • Send the denied action to your sandbox administrator.
  • Resume the project after both console pages expose their creation controls.

Need help preparing the request? Help me explain this AWS AccessDenied message to my sandbox administrator.

Your access, Region, zones, permissions, and address plan are ready. Next, you will create the VPC plus its four-subnet layout.

Build the VPC and Four-Subnet Layout

Your permission preflight cleared the path for the first network resources. You can now turn your CIDR plan into an Amazon VPC.

A layout with four subnets is the smallest useful model of a two-tier network. Spreading them across two Availability Zones makes the structure visible before routing changes traffic behavior.

In this step, get ready to:
  • Create the VPC network boundary with the planned address range.
  • Create four named subnets across AZ A and AZ B.
  • Inspect the completed layout in the VPC Resource map.
Create the VPC

The VPC uses the larger 10.0.0.0/16 address range as its network boundary. Each planned /24 subnet fits inside this range.

Why build this manually?

An automated wizard can create several network components at once. Manual creation keeps every address choice visible.

You will see exactly how the layout changes when route tables are introduced later. That visibility makes the final connectivity test easier to explain.

  • Switch back to the Amazon VPC console from earlier in your selected Region.
  • Choose Create VPC.
  • Select VPC only.
  • Enter nw-network-lab for Name tag.
  • Enter 10.0.0.0/16 using IPv4 CIDR manual input.
  • Keep IPv6 CIDR block set to no IPv6 CIDR.
  • Keep Tenancy set to Default.
  • Choose Create VPC.

That is the network boundary in place. You can now see nw-network-lab with the IPv4 CIDR 10.0.0.0/16.

VPC missing after creation?

  • Check that the console still shows the selected Region from earlier.
  • Compare the entered IPv4 CIDR with 10.0.0.0/16.
  • Capture the denied operation if the console reports a permissions problem.

Still blocked? Help me troubleshoot why my VPC was not created..

Create the two subnets in AZ A

AZ A receives one public-designated subnet and one private-designated subnet. Their separate address ranges reserve space for different traffic paths later.

  • Choose Subnets in the Amazon VPC navigation pane.
  • Choose Create subnet.
  • Select nw-network-lab for VPC ID.
  • Enter nw-public-a for Subnet name.
  • Select AZ A for Availability Zone.
  • Use Manual input to enter 10.0.0.0/24 in the IPv4 CIDR block field.
  • Leave public IPv4 auto-assignment disabled.
  • Choose Create subnet.

Your first subnet is ready. You will see nw-public-a in AZ A with the IPv4 CIDR 10.0.0.0/24.

  • Choose Create subnet again.
  • Select nw-network-lab for VPC ID.
  • Enter nw-private-a for Subnet name.
  • Select AZ A for Availability Zone.
  • Use Manual input to enter 10.0.1.0/24 in the IPv4 CIDR block field.
  • Leave public IPv4 auto-assignment disabled.
  • Choose Create subnet.

AZ A now contains both planned tiers. You will see nw-public-a and nw-private-a with separate /24 ranges.

Subnet creation not working?

  • Confirm that nw-network-lab is selected in the subnet form.
  • Confirm that both subnets use AZ A.
  • Compare the subnet CIDRs with 10.0.0.0/24 and 10.0.1.0/24.

Need another pair of eyes? Help me troubleshoot my AZ A subnet settings..

Create the two subnets in AZ B and inspect the map

AZ B mirrors the two-tier structure from AZ A. The remaining CIDR blocks complete the layout without overlapping the first pair.

  • Choose Create subnet.
  • Select nw-network-lab for VPC ID.
  • Enter nw-public-b for Subnet name.
  • Select AZ B for Availability Zone.
  • Use Manual input to enter 10.0.2.0/24 in the IPv4 CIDR block field.
  • Leave public IPv4 auto-assignment disabled.
  • Choose Create subnet.

The first half of AZ B is now visible. You will see nw-public-b with the IPv4 CIDR 10.0.2.0/24.

  • Choose Create subnet again.
  • Select nw-network-lab for VPC ID.
  • Enter nw-private-b for Subnet name.
  • Select AZ B for Availability Zone.
  • Use Manual input to enter 10.0.3.0/24 in the IPv4 CIDR block field.
  • Leave public IPv4 auto-assignment disabled.
  • Choose Create subnet.

The full subnet layout is now built. nw-network-lab contains two planned tiers in each Availability Zone.

Before you inspect the map, how many /24 subnets do you expect to see across the two Availability Zones?

  • Select VPCs in the Amazon VPC navigation pane.
  • Select nw-network-lab.
  • Open the Resource map tab.
  • Choose Show details.
  • Confirm that four /24 subnets appear across exactly two Availability Zones.
  • Compare each displayed CIDR with the planned subnet ranges.

You will see four non-overlapping /24 subnets split between AZ A and AZ B under nw-network-lab.

What makes a subnet public?

The subnet names record their intended roles. The names do not control network traffic.

Routing creates the actual public or private behavior. The next step gives each tier its explicit path.

Map missing a subnet?

  • Refresh the VPC Resource map.
  • Confirm that nw-network-lab is still selected.
  • Compare the four subnet names with the Subnets list.

Still missing part of the layout? Help me diagnose my VPC Resource map..

Your two-AZ subnet layout is complete. Next, you will turn those tier labels into real network behavior with explicit routing.

Configure Public and Private Routing

Your Amazon VPC now has four subnets across two Availability Zones. Their names describe the intended network tiers.

The public tier needs an Internet Gateway. Each private route table must remain local-only so the probe hits a controlled egress failure in the next step.

In this step, get ready to:
  • Attach an Internet Gateway to nw-network-lab.
  • Create one public route table plus two local-only private route tables.
  • Associate every subnet explicitly with its intended route table.
Create and attach the Internet Gateway

An Internet Gateway gives a VPC a routing target at the edge of the internet. Attaching one establishes that target for the public route table you create next.

  • Return to the Amazon VPC console from earlier.
  • Choose Internet gateways in the left navigation.
  • Choose Create internet gateway.
  • Enter nw-igw for the Name tag.
  • Choose Create internet gateway.

You should see the details for nw-igw. The gateway now exists in your selected Region.

  • Choose Attach to a VPC.
  • Select nw-network-lab.
  • Choose Attach internet gateway.

That establishes your network edge. nw-igw is now attached to nw-network-lab.

Why doesn't attachment provide internet access?

The gateway becomes useful when a subnet's route table sends traffic to it. Attachment alone leaves every existing subnet on its current route.

The public route table will send 0.0.0.0/0 to nw-igw. That route creates the public tier's path.

Unable to attach the gateway?

  • Confirm the console still shows your selected Region.
  • Confirm nw-igw is not attached to another VPC.
  • Confirm your sandbox role permits Internet Gateway attachment.

Still blocked? Help me troubleshoot an Internet Gateway attachment failure.

Create route tables and the public path

A route table decides where traffic goes after it leaves a subnet. You need one shared table for the public tier plus one isolated table for each private subnet.

  • Choose Route tables in the left navigation.
  • Choose Create route table.
  • Enter nw-rt-public for Name.
  • Select nw-network-lab for VPC.
  • Choose Create route table.

You should see nw-rt-public with its automatically created 10.0.0.0/16 route to local.

Why build the routes manually?

An automated VPC wizard can create routing components for you. Manual creation exposes each route target plus each subnet association.

That visibility makes the later connectivity test easier to explain and troubleshoot.

  • Return to Route tables.
  • Choose Create route table.
  • Enter nw-rt-private-a for Name.
  • Select nw-network-lab for VPC.
  • Choose Create route table.

You should see nw-rt-private-a with only the 10.0.0.0/16 route to local.

  • Return to Route tables.
  • Choose Create route table.
  • Enter nw-rt-private-b for Name.
  • Select nw-network-lab for VPC.
  • Choose Create route table.

You should see nw-rt-private-b with only the 10.0.0.0/16 route to local.

What does the local route allow?

The automatically created local route lets addresses inside 10.0.0.0/16 reach one another when security controls permit the traffic.

A private table containing only this route has no default route for internet-bound traffic. This preserves the controlled isolation you test later.

The public table needs one additional route. Its destination represents traffic that does not match a more specific route.

  • Select nw-rt-public from the route table list.
  • Choose Actions.
  • Choose Edit routes.
  • Choose Add route.
  • Enter 0.0.0.0/0 for Destination.
  • Select nw-igw for Target.
  • Choose Save changes.

The Routes tab should now show 10.0.0.0/16 to local plus 0.0.0.0/0 to nw-igw.

Can't choose the Internet Gateway?

  • Confirm nw-rt-public belongs to nw-network-lab.
  • Confirm nw-igw is attached to nw-network-lab.
  • Confirm both resources are in the selected Region.

Need another pair of eyes? Help me find why nw-igw is unavailable as a route target.

Associate every subnet and verify the routes

An explicit subnet association makes the routing decision visible. It also prevents these subnets from silently relying on the VPC's main route table.

  • Select nw-rt-public from the route table list.
  • Open the Subnet associations tab.
  • Choose Edit subnet associations.
  • Select the checkboxes beside nw-public-a plus nw-public-b.
  • Choose Save associations.

Both public-designated subnets should now appear as explicit associations for nw-rt-public.

  • Select nw-rt-private-a from the route table list.
  • Open the Subnet associations tab.
  • Choose Edit subnet associations.
  • Select the checkbox beside nw-private-a.
  • Choose Save associations.

The private subnet in AZ A should now appear as the explicit association for nw-rt-private-a.

  • Select nw-rt-private-b from the route table list.
  • Open the Subnet associations tab.
  • Choose Edit subnet associations.
  • Select the checkbox beside nw-private-b.
  • Choose Save associations.

The private subnet in AZ B should now appear as the explicit association for nw-rt-private-b.

How do the associations work?

One route table can serve multiple subnets. Each subnet can use only one route table at a time.

Your two public subnets share one internet path. Each private subnet has its own isolated table for the same-AZ NAT route you add later.

Before you inspect the finished routing state, which tables do you expect to have a 0.0.0.0/0 route?

  • Select nw-rt-public.
  • Open the Routes tab.
  • Confirm it shows 10.0.0.0/16 to local plus 0.0.0.0/0 to nw-igw.
  • Open the Subnet associations tab.
  • Confirm it lists nw-public-a plus nw-public-b.
  • Select nw-rt-private-a.
  • Open the Routes tab.
  • Confirm it shows only 10.0.0.0/16 to local.

The first private table has no route for destinations outside the VPC. Its explicit association keeps nw-private-a on that local-only path.

  • Open the Subnet associations tab.
  • Confirm it lists only nw-private-a.
  • Select nw-rt-private-b.
  • Open the Routes tab.
  • Confirm it shows only 10.0.0.0/16 to local.
  • Open the Subnet associations tab.
  • Confirm it lists only nw-private-b.

Both private route tables are deliberately local-only. The single public table is the only table with an Internet Gateway route.

  • Choose VPCs in the left navigation.
  • Select nw-network-lab.
  • Open the Resource map tab.
  • Choose Show details.
  • Trace each subnet to its explicitly associated route table.

You should see both public subnets connected to nw-rt-public with a path to nw-igw. Each private subnet should lead to its own local-only route table with no default egress route.

Do the associations look wrong?

  • Return to the affected route table's Subnet associations tab.
  • Choose Edit subnet associations.
  • Select only the subnet relationships defined in this step.
  • Choose Save associations.

Still seeing the wrong path? Help me check my route table associations.

Your routing tiers are now explicit. Next, you'll launch a private probe and watch the missing default route block its outbound traffic.

Launch and Test a Private Probe

Your Amazon VPC now separates public subnets from private subnets through explicit route-table associations. The private route tables still contain only the local route.

A route diagram alone cannot prove what a private workload experiences. You will launch a private Amazon EC2 probe and reach it through an EC2 Instance Connect Endpoint so you can test the current routing from inside nw-private-a.

In this step, get ready to:
  • Create security groups that restrict administrative access to the endpoint path.
  • Create a private management endpoint inside nw-private-a.
  • Launch a private probe and test its current outbound path.
Create tightly scoped management security groups

Security groups are allow-only firewalls for connected resources. A security group reference limits SSH traffic to resources carrying the referenced group.

  • Return to the Amazon VPC console in your selected Region.
  • Choose Security groups in the navigation pane.
  • Choose Create security group.
  • Enter nw-eice-sg as the name.
  • Enter nw-eice-sg as the description.
  • Select nw-network-lab for VPC.
  • Choose Create security group.

Good start. The endpoint group now exists with no inbound rules and the default outbound rule.

  • Choose Create security group again.
  • Enter nw-probe-sg as the name.
  • Enter nw-probe-sg as the description.
  • Select nw-network-lab for VPC.
  • Choose Create security group.

Both security groups now exist in the same VPC. You can reference the probe group as the endpoint group's only outbound destination.

  • Select nw-eice-sg from the security group list.
  • Open the Outbound rules tab.
  • Choose Edit outbound rules.
  • Choose Delete beside the default outbound rule.

Why remove the default outbound rule?

The default rule permits all outbound traffic. Replacing it with one targeted rule means the endpoint can send only TCP port 22 traffic to resources associated with nw-probe-sg.

  • Choose Add rule.
  • Select Custom TCP for Type.
  • Enter 22 for Port range.
  • Select nw-probe-sg for Destination.
  • Choose Save rules.
  • Select nw-probe-sg from the security group list.
  • Open the Inbound rules tab.
  • Choose Edit inbound rules.
  • Choose Add rule.
  • Select SSH for Type.
  • Select nw-eice-sg for Source.
  • Choose Save rules.
  • Select nw-eice-sg.
  • Open the Outbound rules tab.
  • Confirm the only outbound rule is Custom TCP on port 22 with destination nw-probe-sg.
  • Select nw-probe-sg.
  • Open the Inbound rules tab.
  • Confirm the only inbound rule is SSH from nw-eice-sg.

That security boundary is now in place. Administrative traffic can move from the endpoint group to the probe group without opening SSH to the internet.

Unable to save the security group rules?

  • Confirm both security groups belong to nw-network-lab if one group does not appear as a source or destination.
  • Capture the denied action if the console reports AccessDenied.
  • Request that action from the sandbox administrator before continuing.
  • Ask for help with the rule configuration by selecting Help me troubleshoot my AWS security group references..
Create the private management endpoint

The endpoint provides a managed path to a private instance without requiring a public IPv4 address. Placing it in nw-private-a keeps the management path inside the VPC.

  • Choose Endpoints in the Amazon VPC navigation pane.
  • Choose Create endpoint.
  • Enter nw-eice-a for Name tag.
  • Select EC2 Instance Connect Endpoint for Type.
  • Select nw-network-lab under Network settings.

Why use an EC2 Instance Connect Endpoint?

The endpoint carries the browser-based SSH connection to the instance's private IPv4 address. The probe needs no bastion host and no public IPv4 address.

The endpoint service can reach the endpoint without an inbound rule on nw-eice-sg. Its outbound rule still limits the next hop to the probe group on port 22.

  • Select nw-eice-sg under Security groups.
  • Select nw-private-a for Subnet.
  • Select IPv4 for IP address type.
  • Leave Preserve Client IP cleared.
  • Choose Create endpoint.

Provisioning can feel quiet while AWS creates the endpoint network interface. Its status moves through Pending before it becomes usable.

  • Wait until the endpoint's Status changes to Available.

The private management path is ready. The endpoint now sits beside the future probe in nw-private-a.

Endpoint not becoming available?

  • Refresh the endpoint list if the status remains unchanged.
  • Confirm the endpoint uses nw-private-a and nw-eice-sg if creation fails.
  • Capture the denied action if the console reports AccessDenied.
  • Ask the sandbox administrator to grant the missing endpoint lifecycle permission.
  • Get targeted help by selecting Help me diagnose my EC2 Instance Connect Endpoint..
Launch and test the private probe

Launching the probe starts Amazon EC2 usage charges. Its root volume can also incur Amazon EBS storage charges.

The lab uses one t3.micro instance to keep the test small. The cleanup section removes the instance and its storage after the network proof is complete.

  • Switch back to the Amazon EC2 console in your selected Region.
  • Choose Instances in the navigation pane.
  • Choose Launch instance.
  • Enter nw-private-probe-a as the instance name.
  • Select the AWS-published AL2023 standard AMI under Application and OS Images (Amazon Machine Image).
  • Confirm the selected image is the standard Amazon Linux 2023 image instead of the minimal image.
  • Select t3.micro under Instance type.

Why use the standard AL2023 image?

The AL2023 standard AMI includes EC2 Instance Connect. That support lets the console push a temporary SSH public key when you start the private connection.

The endpoint supplies the private network path. This combination allows the lab to proceed without a permanent key pair.

  • Select Proceed without a key pair (Not recommended) under Key pair (login).
  • Select nw-network-lab under Network settings.
  • Select nw-private-a for the subnet.
  • Set Auto-assign Public IP to Disable.
  • Choose the existing security group option.
  • Select nw-probe-sg as the only security group.
  • Keep the default root volume under Configure storage.
  • Choose Launch instance.

The first boot can take a little time while AWS prepares the instance and runs its status checks. Keep the instance list visible during this wait.

  • Wait until nw-private-probe-a enters the running state.
  • Select nw-private-probe-a.
  • Review its networking details.
  • Confirm the Public IPv4 address field is blank.

The probe is running without a public IPv4 address. That is the isolation boundary you set out to preserve.

Probe not reaching the running state?

  • Confirm the instance uses nw-private-a if the launch summary shows a different subnet.
  • Confirm the instance type is t3.micro if the sandbox rejects the launch configuration.
  • Capture the denied action if the launch fails with AccessDenied.
  • Request the missing instance lifecycle permission from the sandbox administrator.
  • Get help with the launch by selecting Help me troubleshoot my private EC2 probe..
  • Keep nw-private-probe-a selected.
  • Choose Connect.
  • Open the EC2 Instance Connect tab.
  • Set Connection type to Connect using a Private IP.
  • Choose Private IPv4 address as the address.
  • Select nw-eice-a for EC2 Instance Connect Endpoint.
  • Verify Username is ec2-user.
  • Choose Connect.

You should see a browser terminal connected as ec2-user. That connection proves the private management endpoint works without a public IPv4 address.

Browser terminal not connecting?

  • Confirm nw-eice-a still shows Available.
  • Confirm the instance uses nw-probe-sg.
  • Confirm the endpoint uses nw-eice-sg.
  • Verify the inbound and outbound port 22 references if the connection times out.
  • Ask for connection help by selecting Help me troubleshoot my private EC2 Instance Connect session..

Before you run the test, ask yourself whether the local-only route table can carry this packet to the internet.

  • Test the current private egress path by running this command in the browser terminal:
ping ietf.org

What does this test prove?

You will see ietf.org resolve to an IP address through DNS. Name resolution works inside the VPC.

No ICMP reply lines return because nw-rt-private-a has no 0.0.0.0/0 route. The packet has no path from the private subnet to the internet.

  • Allow several ping attempts to run.
  • Press Ctrl+C to stop the command.
  • Leave the browser terminal open for the next step.

This controlled failure is your proof of isolation. The probe is reachable for administration while its subnet still lacks internet egress.

Did the ping return replies?

  • Return to nw-rt-private-a if reply lines appear.
  • Confirm its only route is 10.0.0.0/16 with target local.
  • Reconnect through nw-eice-a if the browser terminal closes.
  • Get help interpreting the result by selecting Help me diagnose why my private probe has internet access..

Your private probe is secure and reachable through its endpoint. Next, you will add same-AZ NAT egress and repeat the identical test to prove the routing change.

Add NAT Egress and Prove Connectivity

Your private probe is reachable through EC2 Instance Connect Endpoint. Its subnet still has only the local route. The earlier ping resolved ietf.org without receiving replies, which exposed the missing outbound path.

A public NAT gateway gives the private probe outbound IPv4 access without assigning it a public IPv4 address. Placing one in each Availability Zone keeps every private route table on a same-zone path to the existing Internet Gateway.

In this step, get ready to:
  • Create one public NAT gateway in each public subnet.
  • Add a same-AZ default route to each private route table.
  • Prove the private probe can reach the internet without a public IPv4 address.
Create one public NAT gateway per Availability Zone

Each public NAT gateway needs a public subnet with a route to nw-igw. Your existing public subnets already meet that requirement.

Billable Resources Start Here

This is the point where billable infrastructure begins. Each NAT gateway costs $0.045 per NAT Gateway-hour in US East.

Each public IPv4 address costs $0.005 per hour. Partial NAT Gateway-hours are billed as full hours, so complete the test before moving to cleanup.

  • Return to the Amazon VPC console from earlier.
  • Select NAT gateways in the left navigation.
  • Choose Create NAT gateway.
  • Enter nw-nat-a in the Name field.
  • Select nw-public-a in the Subnet field.
  • Set Connectivity type to Public.
  • Choose Allocate Elastic IP beside Elastic IP allocation ID.
  • Choose Create a NAT gateway.

You'll see nw-nat-a enter the Pending state. That state confirms AWS accepted the configuration.

The second gateway protects AZ B from depending on networking infrastructure in AZ A. Create it with the matching public subnet.

  • Choose Create NAT gateway.
  • Enter nw-nat-b in the Name field.
  • Select nw-public-b in the Subnet field.
  • Set Connectivity type to Public.
  • Choose Allocate Elastic IP beside Elastic IP allocation ID.
  • Choose Create a NAT gateway.

Provisioning can take a few minutes. A Pending status during that wait is expected.

  • Wait until both NAT gateway rows show Available.

Both gateways are ready to accept routes. You now have one allocated Elastic IP address attached to each gateway.

NAT Gateway Not Available?

  • Confirm nw-nat-a uses nw-public-a.
  • Confirm nw-nat-b uses nw-public-b.
  • If creation is blocked by AccessDenied, capture the denied action for your sandbox administrator. Help me diagnose why my NAT gateways are not becoming Available.
Route each private subnet through its same-AZ gateway

The new gateways do not receive traffic until a route points to them. Each private table needs a default route while retaining its existing local route and explicit subnet association.

  • Select Route tables in the Amazon VPC console.
  • Select nw-rt-private-a.
  • Choose Actions.
  • Choose Edit routes.
  • Choose Add route.
  • Enter 0.0.0.0/0 in Destination.
  • Select nw-nat-a in Target.
  • Choose Save changes.

The Routes tab now shows the local VPC route plus a default route to nw-nat-a. Traffic from nw-private-a now has an outbound target in AZ A.

Apply the matching route to AZ B. This keeps the second private subnet independent from the gateway in AZ A.

  • Select nw-rt-private-b.
  • Choose Actions.
  • Choose Edit routes.
  • Choose Add route.
  • Enter 0.0.0.0/0 in Destination.
  • Select nw-nat-b in Target.
  • Choose Save changes.

The second private table now has its own same-AZ default route. Check the routes and associations before testing the probe.

  • Select nw-rt-private-a.
  • Open the Routes tab.
  • Confirm 10.0.0.0/16 targets local.
  • Confirm 0.0.0.0/0 targets nw-nat-a.
  • Open the Subnet associations tab.
  • Confirm nw-private-a remains explicitly associated.

AZ A now has the complete private route-table configuration. Repeat the check for AZ B.

  • Select nw-rt-private-b.
  • Open the Routes tab.
  • Confirm 10.0.0.0/16 targets local.
  • Confirm 0.0.0.0/0 targets nw-nat-b.
  • Open the Subnet associations tab.
  • Confirm nw-private-b remains explicitly associated.

That's the routing fix in place. Each private subnet now sends internet-bound traffic to the NAT gateway in its own zone.

Default Route Missing?

  • Confirm both NAT gateways show Available before selecting them as targets.
  • Confirm the destination is exactly 0.0.0.0/0 in both private route tables.
  • Confirm each route points to the NAT gateway with the matching letter. Help me troubleshoot my private NAT routes.
Prove the private outbound path

The probe has not changed since the failed test. Running the same command now isolates the route change as the reason connectivity works.

Before you run the test, do you expect the host name to resolve without replies again, or do you expect reply lines this time?

  • Switch back to the existing EC2 Instance Connect browser session.
  • Test the updated outbound route by running this command:
ping ietf.org

What Does This Test Prove?

Reply lines show that ICMP traffic can now leave nw-private-a through nw-nat-a. The identical test failed before the default route existed.

The probe stays private because the gateway handles outbound connectivity. Internet hosts still cannot start connections to the probe through this path.

  • Press Ctrl+C after several reply lines.
  • Return to the Instances page in the Amazon EC2 console from earlier.
  • Select nw-private-probe-a.
  • Open the Networking details.
  • Confirm Public IPv4 address is blank.

Your probe now reaches the internet while keeping its private-only address. The outbound route changed, while the instance configuration stayed the same.

Before you inspect the map, which NAT gateway should each private subnet lead to?

  • Return to the Amazon VPC console from earlier.
  • Select VPCs.
  • Choose nw-network-lab.
  • Open the Resource map tab.
  • Choose Show details.
  • Trace the egress path from each private subnet.

You'll see nw-private-a use nw-rt-private-a to reach nw-nat-a. You'll see nw-private-b use nw-rt-private-b to reach nw-nat-b.

Both NAT gateways connect through nw-rt-public to nw-igw. That's the proof complete: your two-AZ private egress design works without exposing the probe to a public IPv4 address.

Ping Still Has No Replies?

  • Confirm nw-rt-private-a has an active 0.0.0.0/0 route to nw-nat-a.
  • Confirm nw-nat-a shows Available in nw-public-a.
  • Reconnect through nw-eice-a if the browser session expired. Help me troubleshoot why ping still has no replies.

Secret mission

Break and Repair the Private Route

Turn your working private egress path into a controlled outage. Diagnose the missing route from the network evidence before restoring service and proving recovery.

Clean Up Your Resources

Clean Up Your Resources

Your Amazon VPC lab includes resources that keep charging while they remain provisioned. Decide whether to keep the network running, pause the probe, or delete the lab entirely.

Cost warning

Two public NAT gateways incur hourly charges. Each partial NAT Gateway-hour is billed as a full hour.

Their Elastic IP addresses incur public IPv4 charges. The running Amazon EC2 instance can also incur charges.

The EBS root volume can incur storage charges. Data transfer charges may also apply.

One hour in US East (N. Virginia) is estimated at approximately $0.12 before credits. The Delete option below is the safest way to stop lab charges.

Resources you used:

  • Network boundary: One VPC named nw-network-lab with IPv4 CIDR 10.0.0.0/16.
  • Subnet layout: Four subnets named nw-public-a, nw-private-a, nw-public-b, and nw-private-b.
  • Routing: One Internet Gateway named nw-igw with three custom route tables and explicit subnet associations.
  • Paid egress: Two public NAT gateways named nw-nat-a and nw-nat-b with two allocated Elastic IP addresses.
  • Private administration: One EC2 Instance Connect Endpoint named nw-eice-a with security groups named nw-eice-sg and nw-probe-sg.
  • Private probe: One running t3.micro instance named nw-private-probe-a with an EBS root volume.

Keep everything running

No action is needed. This option fits when you plan to continue using the lab immediately.

  • The two NAT gateways stay Available. Hourly charges can continue.
  • The two Elastic IP addresses remain allocated. Public IPv4 charges can continue.
  • The nw-private-probe-a instance remains running. Compute charges can continue.
  • The EBS root volume remains provisioned. Storage charges can continue.
  • The endpoint and VPC network configuration remain ready for another connectivity test.

Pause - I'll come back to this later

Pausing preserves the network while reducing the probe's active compute use. NAT Gateway charges and public IPv4 charges continue.

  • Return to Instances in Amazon EC2.
  • Select nw-private-probe-a.
  • Use the stop option under Instance state.
  • Wait until the instance state shows stopped.

The EBS root volume remains provisioned while the probe is stopped. Its storage charges can continue.

The endpoint and VPC resources also remain in place. Restart the probe when you are ready to resume the lab.

Delete - I don't want to use this again

This option removes the project resources in an order that clears VPC deletion blockers. Resource deletion is permanent.

The instance creates a requester-managed network interface inside the VPC. Remove the probe before deleting the network.

  • Return to Instances in Amazon EC2.
  • Select nw-private-probe-a.
  • Choose Instance state.
  • Choose Terminate (delete) instance.
  • Choose Terminate (delete).

Termination can take a few minutes, so a short wait is normal. Compute charges stop when the instance changes to shutting-down or terminated.

The endpoint is another requester-managed network interface. Remove it before deleting the VPC.

  • Switch back to Amazon VPC in the selected Region.
  • Select Endpoints.
  • Select nw-eice-a.
  • Delete nw-eice-a from the selected endpoint's actions.
  • Wait until nw-eice-a no longer appears in the endpoint list.

The two NAT gateways are the main paid network resources. Deleting them disconnects their Elastic IP addresses without releasing those addresses.

  • Select NAT gateways in Amazon VPC.
  • Select nw-nat-a.
  • Choose Actions.
  • Choose Delete NAT gateway.
  • Enter delete.
  • Choose Delete.
  • Repeat the same deletion process for nw-nat-b.

NAT Gateway deletion can take several minutes. Wait until neither lab gateway shows Available before releasing the addresses.

The disconnected Elastic IP addresses remain allocated to your account. Release both addresses to stop their public IPv4 charges.

  • Select Elastic IPs in Amazon VPC.
  • Select the address that was associated with nw-nat-a.
  • Choose Actions.
  • Choose Release Elastic IP addresses.
  • Choose Release.
  • Repeat the same release process for the address that was associated with nw-nat-b.

Instance termination normally removes the attached root volume according to its termination setting. Check the project volume before deleting the VPC.

  • Return to the storage volume list in Amazon EC2.
  • Confirm the EBS root volume from nw-private-probe-a is absent.
  • Delete that root volume if it remains after the instance terminates.

The remaining subnets, route tables, Internet Gateway, and security groups belong to nw-network-lab. The VPC deletion flow removes them after the blocking resources are gone.

  • Return to Your VPCs in Amazon VPC.
  • Select nw-network-lab.
  • Choose Actions.
  • Choose Delete VPC.
  • Enter delete.
  • Choose Delete.

Finish with four checks that prove every paid lab resource is gone.

  • Return to Elastic IPs to confirm no addresses from this lab remain allocated.
  • Return to NAT gateways to confirm no lab gateway remains Available.
  • Return to Instances to confirm nw-private-probe-a shows terminated.
  • Return to Your VPCs to confirm nw-network-lab is absent.

Cleanup is complete once all four checks pass. Your paid lab resources are no longer running.

Nice Work!

Nice Work!

Excellent work on building a production-shaped Amazon VPC across two Availability Zones. Your live traffic tests proved that private egress follows explicit routes through same-AZ NAT gateways.

You've learned how to:

  • Design a two-AZ subnet layout with four non-overlapping /24 networks that separate public traffic from private workloads.
  • Build explicit route-table associations that direct each private subnet through its same-AZ NAT gateway. Trace the complete path to the Internet Gateway in the Resource map.
  • Reach a private Amazon EC2 probe through EC2 Instance Connect Endpoint without a public IPv4 address. Compare a failed egress test against the successful test after NAT routing.
  • Secret Mission: Broke the private default route on purpose. Diagnosed the outage through the Resource map. Restored same-AZ NAT egress to the probe.

Ready to quiz yourself?