NAT, VPC Endpoints & EC2 Hibernate

Build a private VPC, add NAT Gateway, optimize with VPC Endpoints, and hibernate EC2.

Introduction

30 Second Summary

When companies move servers into private networks, those servers lose the ability to reach the internet or talk to cloud services. The challenge is giving private resources just enough connectivity without exposing them directly to the public internet.

In this project, you will build a multi-tier VPC from scratch, solve private subnet connectivity with a NAT Gateway, optimize costs with VPC Endpoints, and prove that EC2 Hibernate preserves RAM across a stop/start cycle.

What You'll Build

You will connect to a private instance, run commands that prove traffic is flowing through different paths, and watch an EC2 instance wake up from hibernation with its memory intact.

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

A private EC2 instance that accesses the internet through a NAT Gateway, plus S3 traffic that bypasses NAT entirely through a free Gateway Endpoint (verified by checking the route table and running real commands from inside the instance).
Session Manager connectivity to your private instance that works purely through Interface Endpoints (PrivateLink), with no internet path required.
An EC2 instance that preserves running processes and in-memory data across a hibernate/resume cycle, proving RAM contents survive.
Secret Mission: Deploy a NAT Instance with source/destination check disabled and build an exam-ready NAT Gateway vs NAT Instance comparison table.

Are there any prerequisites?

You need an AWS account with console access. No prior VPC experience is required. This project walks you through every resource from scratch.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

You're going to construct a multi-tier VPC architecture that demonstrates how private instances connect to the internet and AWS services through different networking patterns. Each pattern solves a different cost, security, or availability problem that the SAA-C03 exam tests heavily.

Build a VPC with Public and Private Subnets

Every networking pattern in this project starts from the same foundation: a VPC with isolated private subnets that have no internet access.

Without this isolation, there is no problem to solve. In this step, you will build the VPC, create public and private subnets, configure routing, and launch a private instance that deliberately cannot reach the internet or AWS services.

In this step, get ready to:

Create a VPC with public and private subnets, an Internet Gateway, and route tables.
Set up a Security Group and IAM role for your private instance.
Launch a private EC2 instance that has no internet path.

Create the VPC

In the AWS console search bar, type VPC and select VPC.
Click Create VPC.
For Resources to create, select VPC only.
In the Name tag field, enter nextwork-vpc.
For IPv4 CIDR block, choose IPv4 CIDR manual input and enter 10.0.0.0/16.
Click Create VPC.

You should see a green success banner confirming your VPC was created.

What is a VPC?

A VPC (Virtual Private Cloud) is your own isolated section of the AWS cloud. It defines the network boundary where your resources live.

The CIDR block 10.0.0.0/16 gives you 65,536 private IP addresses to assign across subnets.

Create the public and private subnets

In the left sidebar, click Subnets.
Click Create subnet.
Under VPC ID, select your nextwork-vpc.
In the Subnet name field, enter nextwork-public.
For Availability Zone, select any zone (for example, the first one listed). Note which one you choose.
For IPv4 subnet CIDR block, select Manual input and enter 10.0.1.0/24.
Click Add new subnet to add a second subnet in the same dialog.

Now configure the private subnet in the same form:

In the Subnet name field, enter nextwork-private.
For Availability Zone, select the SAME zone you chose for the public subnet.
For IPv4 subnet CIDR block, select Manual input and enter 10.0.2.0/24.
Click Create subnet.

Both subnets now appear in the Subnets list under your VPC.

Why two subnets in the same Availability Zone?

A public subnet has a route to the internet. A private subnet does not. Placing them in the same AZ keeps network latency minimal when resources in the private subnet need to communicate through the public subnet.

Create and attach an Internet Gateway

In the left sidebar, click Internet gateways.
Click Create internet gateway.
In the Name tag field, enter nextwork-igw.
Click Create internet gateway.
On the confirmation page, click Actions, then Attach to VPC.
Select nextwork-vpc and click Attach internet gateway.

The state changes to Attached. Your VPC now has a door to the internet, but no subnet can use it until you create a route.

What is an Internet Gateway?

An Internet Gateway is the bridge between your VPC and the public internet. Without a route pointing to it, subnets remain private regardless of whether the IGW is attached.

Create and configure route tables

You need two route tables: one that sends internet traffic to the IGW (public) and one that has no internet path (private).

In the left sidebar, click Route tables.
Click Create route table.
In the Name field, enter nextwork-public-rt.
For VPC, select nextwork-vpc.
Click Create route table.

Now add the internet route to this public route table:

With your nextwork-public-rt selected, click the Routes tab.
Click Edit routes.
Click Add route.
For Destination, enter 0.0.0.0/0.
For Target, select Internet Gateway, then choose your nextwork-igw.
Click Save changes.

Now associate this route table with the public subnet:

Click the Subnet associations tab.
Click Edit subnet associations.
Check the box next to nextwork-public.
Click Save associations.

Now create the private route table:

Click Create route table again.
In the Name field, enter nextwork-private-rt.
For VPC, select nextwork-vpc.
Click Create route table.
Click the Subnet associations tab, then click Edit subnet associations.
Check the box next to nextwork-private.
Click Save associations.

Do NOT add any routes to this private route table. It should only have the default local route.

What do these route tables control?

The public route table sends all non-local traffic (0.0.0.0/0) to the Internet Gateway, giving the public subnet internet access.

The private route table only has the local route, meaning traffic can flow within the VPC but has no path out to the internet. This is the isolation that makes it "private."

Before you move on, predict what you expect to see in each route table. Then verify:

Click Route tables in the sidebar and select nextwork-public-rt.
In the Routes tab, confirm you see a 0.0.0.0/0 route targeting the IGW, plus the local route.
Select nextwork-private-rt.
In the Routes tab, confirm you ONLY see the local route (10.0.0.0/16 targeting local). There is no 0.0.0.0/0 route.

Don't see your route tables?

Make sure you are filtering by your nextwork-vpc. Use the VPC filter dropdown at the top of the Route tables page to select it.

If the 0.0.0.0/0 route does not appear in the public route table, go back to Edit routes and re-add it with the Internet Gateway target.

Still stuck? Help me debug my route tables. I created a VPC, two subnets, an IGW, and two route tables. The public route table should have a 0.0.0.0/0 route to the IGW.

Create a Security Group and IAM role

Your private instance needs a Security Group that allows outbound traffic and an IAM role that grants Session Manager permissions.

In the left sidebar, click Security groups.
Click Create security group.
In the Security group name field, enter nextwork-private-sg.
In the Description field, enter Allow all outbound, no inbound from internet.
For VPC, select nextwork-vpc.
Under Inbound rules, do NOT add any rules. Leave it empty.
Under Outbound rules, keep the default rule that allows all traffic (0.0.0.0/0).
Click Create security group.

You should see the security group created with its ID. Now create the IAM role:

In the console search bar, type IAM and select IAM.
In the left sidebar, click Roles.
Click Create role.
For Trusted entity type, select AWS service.
For Use case, select EC2.
Click Next.
In the search box, type AmazonSSMManagedInstanceCore.
Check the box next to AmazonSSMManagedInstanceCore.

What does AmazonSSMManagedInstanceCore do?

This managed policy allows the Session Manager agent on your EC2 instance to communicate with AWS Systems Manager endpoints. It is how you will connect to private instances without SSH or a bastion host.

Click Next.
In the Role name field, enter nextwork-ssm-role.
Click Create role.

You should see a success banner confirming the role was created.

Launch a private EC2 instance

Now launch an instance in the private subnet with no public IP. This instance will have no internet path. Session Manager will not work yet because the SSM agent cannot reach AWS APIs.

In the console search bar, type EC2 and select EC2.
Click Launch instance.
In the Name field, enter nextwork-private-instance.
Under Application and OS Images, select Amazon Linux 2023 (it is the default selection).
For Instance type, select t3.micro.
For Key pair, select Proceed without a key pair (you will use Session Manager, not SSH).

Now configure the network settings:

Under Network settings, click Edit.
For VPC, select nextwork-vpc.
For Subnet, select nextwork-private.
For Auto-assign public IP, select Disable.
Under Firewall (security groups), select Select existing security group.
Choose nextwork-private-sg from the dropdown.

Now attach the IAM role:

Expand Advanced details.
For IAM instance profile, select nextwork-ssm-role.
Click Launch instance.

Wait for the instance state to show Running (1-2 minutes). Click into the instance details.

Confirm the following in the instance details panel:

The Subnet ID matches your nextwork-private subnet.
The Public IPv4 address field shows a dash or is empty (no public IP assigned).
The IAM role shows nextwork-ssm-role.

Why can't Session Manager connect yet?

Session Manager requires the SSM agent to call AWS endpoints over HTTPS. Your private instance has no internet path (no 0.0.0.0/0 route in its route table), so the agent cannot reach these endpoints. This is the exact problem you will solve in the next step with a NAT Gateway.

Instance stuck in Pending?

Give it up to 2 minutes. If it fails to launch, check that you selected the correct subnet (nextwork-private) and that the security group belongs to nextwork-vpc.

Still having trouble? Help me troubleshoot my EC2 instance launch. I am launching a t3.micro in my private subnet with the nextwork-private-sg security group and nextwork-ssm-role IAM role.

Your isolated private instance is running. It has no way to reach the internet or AWS service endpoints. In the next step, you will solve this connectivity gap by deploying a NAT Gateway.

Deploy a NAT Gateway and Connect to Your Private Instance

Your private instance is running, but it is completely isolated. The SSM agent on the instance needs to communicate with AWS APIs to register with Session Manager. Without an internet path, it cannot reach those endpoints, which is why Session Manager refuses to connect.

A NAT Gateway solves this by sitting in the public subnet and forwarding outbound traffic from private instances to the internet. In this step, you will deploy one, update your route table, and prove the connection works.

In this step, get ready to:

Deploy a NAT Gateway in the public subnet with an Elastic IP.
Update the private route table to send internet traffic through the NAT Gateway.
Connect to your private instance via Session Manager and verify outbound internet access.

Deploy the NAT Gateway

A NAT Gateway must live in a public subnet so it can reach the internet through the Internet Gateway. It also needs an Elastic IP address, which becomes the public IP that private instances appear to use when they send traffic outbound.

In the AWS console, navigate to the VPC service.
In the left sidebar, click NAT gateways.
Click Create NAT gateway.
Enter nextwork-nat in the Name field.
In the Subnet dropdown, select your public subnet (nextwork-public).
Under Elastic IP allocation ID, click Allocate Elastic IP.
Click Create NAT gateway.

The NAT Gateway state starts as Pending. Wait 1-2 minutes until it changes to Available before continuing.

Why does the NAT Gateway go in the public subnet?

The NAT Gateway needs its own internet path to forward traffic on behalf of private instances. It sits in the public subnet (which already has a route to the Internet Gateway) and uses the Elastic IP as its public-facing address.

Private instances send traffic to the NAT Gateway, which replaces their private source IP with the Elastic IP, forwards the request to the internet, and delivers the response back.

Now you need to tell the private subnet to send internet-bound traffic to the NAT Gateway. This means adding a route to the private route table.

In the left sidebar, click Route tables.
Select your private route table (the one associated with nextwork-private).
Click the Routes tab at the bottom of the page.
Click Edit routes.
Click Add route.
Enter 0.0.0.0/0 in the Destination field.
In the Target dropdown, select NAT Gateway, then select nextwork-nat.
Click Save changes.

Your private route table now has two routes: the local route for traffic within the VPC, and a new 0.0.0.0/0 route that sends all internet-bound traffic to the NAT Gateway.

NAT Gateway stuck in Pending?

If the NAT Gateway stays in Pending for more than 5 minutes, check that you selected the public subnet (not the private subnet) and that an Elastic IP was successfully allocated. A failed Elastic IP allocation prevents the NAT Gateway from becoming available.

Help me troubleshoot my NAT Gateway that is stuck in Pending state

Connect via Session Manager and verify internet access

With the NAT Gateway route in place, the SSM agent on your private instance can now reach AWS APIs. This means Session Manager should be able to establish a connection.

Navigate to the Systems Manager service in the AWS console.
In the left sidebar, click Session Manager (under Node Management).
Click Start session.
Select your nextwork-private-instance from the list and click Start session.

Don't see your instance in the list?

It can take 2-3 minutes after adding the NAT Gateway route for the SSM agent to register with AWS. If your instance does not appear, wait a few minutes and refresh the page. The agent needs time to establish its first connection through the new route.

You should now see a terminal session open in your browser. This is a shell running directly on your private instance, with no SSH key or inbound port required.

Before you run the next command, predict what IP address you think it will return. Will it be the instance's private IP, or something else?

Check your public-facing IP by running this command in the Session Manager terminal:

curl http://checkip.amazonaws.com

The IP returned is the NAT Gateway's Elastic IP. This confirms that all outbound traffic from your private instance routes through the NAT Gateway.

How can I verify the IP matches?

Go back to the VPC console and click NAT gateways in the sidebar. Select nextwork-nat and look at the Primary public IPv4 address. It matches the IP returned by the curl command.

Session Manager not connecting?

Check that your private route table has the 0.0.0.0/0 route targeting the NAT Gateway. Also confirm the NAT Gateway status is Available (not Pending or Failed).

Verify that your EC2 instance has the nextwork-ssm-role IAM role attached. Without this role, the SSM agent cannot authenticate even with internet access.

Help me troubleshoot Session Manager not connecting to my private EC2 instance

Understand NAT Gateway exam facts

You just proved that a NAT Gateway provides outbound internet access for private instances. For the SAA-C03 exam, you need to know the key characteristics that distinguish NAT Gateways from other solutions.

NAT Gateway SAA-C03 exam facts

Managed by AWS. No patching or maintenance required on your part.
Scales automatically up to 100 Gbps bandwidth.
Highly available within a single AZ (built with redundancy). For multi-AZ fault tolerance, deploy one NAT Gateway per AZ and point each private subnet's route table to its local AZ's NAT Gateway.
Cannot attach Security Groups to a NAT Gateway itself.
Cannot use as a bastion host.
Port forwarding not supported.
Billing: $0.045/hr + $0.045/GB data processed (US East).

Multi-AZ high availability pattern

If the exam asks for the "most highly available" NAT architecture, the answer is one NAT Gateway per AZ. Each private subnet's route table points to the NAT Gateway in its own AZ. If one AZ goes down, instances in other AZs continue to route traffic through their local NAT Gateway.

Why does data processing cost matter?

The $0.045/GB data processing charge applies to every byte that passes through the NAT Gateway. If your private instances make frequent calls to AWS services like S3, those charges add up quickly. In the next step, you will learn how to eliminate this cost for S3 traffic using a free Gateway Endpoint.

Your private instance now has internet access through the NAT Gateway. In the next step, you will create a free VPC Gateway Endpoint for S3 that bypasses the NAT Gateway entirely, saving you data processing charges on every S3 request.

Create a VPC Gateway Endpoint for S3

Right now, every byte your private instance sends to S3 routes through the NAT Gateway. That costs $0.045 per GB in data processing charges.

A VPC Gateway Endpoint routes S3 traffic directly over the AWS network for free. This is the single most common cost-optimization question on the SAA-C03 exam for NAT Gateway charges. In this step, you will create a Gateway Endpoint and prove that S3 traffic bypasses the NAT Gateway entirely.

In this step, get ready to:

Create a VPC Gateway Endpoint for S3 in the private route table.
Verify the prefix list route appears and test S3 access from your private instance.
Understand the Gateway Endpoint exam facts for SAA-C03.

Create the Gateway Endpoint for S3

Gateway Endpoints are a special type of VPC endpoint that only supports two AWS services: Amazon S3 and DynamoDB. Unlike Interface Endpoints (which you will create in the next step), Gateway Endpoints are completely free. There is no hourly charge and no data processing charge.

In the AWS Management Console, navigate to the VPC service.
In the left sidebar, click Endpoints.
Click Create endpoint.

Now configure the endpoint settings.

For Name tag, enter nextwork-s3-endpoint.
For Service category, select AWS services.
In the Services search box, type s3.
Select the S3 service with Type Gateway (the service name is com.amazonaws.{region}.s3, where {region} is your current region).

Why select the Gateway type?

You will see two S3 entries in the list. One has Type "Gateway" and the other has Type "Interface". For this step, you need the Gateway type because it is free and adds a route table entry. The Interface type creates an ENI and costs $0.01/hr per AZ.

For VPC, select nextwork-vpc.
Under Route tables, check the box next to the private subnet's route table (the one associated with nextwork-private).
For Policy, leave it set to Full access.
Click Create endpoint.

You should see a success banner confirming the endpoint was created. AWS automatically adds a prefix list route to the route table you selected.

Don't see your VPC in the dropdown?

Make sure you are in the same region where you created nextwork-vpc. Check the region selector in the top-right corner of the console.

Help me troubleshoot my VPC Gateway Endpoint creation.

Verify the route table and test S3 access

When you create a Gateway Endpoint, AWS automatically inserts a prefix list route into the selected route table. This prefix list represents all of the S3 IP address ranges in your region.

In the left sidebar, click Route tables.
Select the private route table (the one associated with nextwork-private).
Click the Routes tab at the bottom of the page.

You should now see three routes in this table.

The local route (10.0.0.0/16 targeting local).
The NAT Gateway route (0.0.0.0/0 targeting your NAT Gateway).
A new route with destination pl-xxxxxxxx (the S3 prefix list) targeting vpce-xxxxxxxx (your Gateway Endpoint).

Why does the prefix list override the NAT route?

Route tables use longest prefix match. The pl-xxxxxxxx route is more specific than 0.0.0.0/0, so S3 traffic matches the prefix list route first. All other internet traffic still goes through the NAT Gateway.

Now test that S3 access actually works through the endpoint.

Switch back to your Session Manager session on nextwork-private-instance.

Before you run the next command, what do you think will happen when you try to list S3 buckets? Will it work, and if so, is the traffic going through the NAT Gateway or the Gateway Endpoint?

Run this command to list your S3 buckets:

aws s3 ls

You should see a list of S3 buckets in your account (or an empty result if you have no buckets). The important thing is that it does not error out. This S3 traffic routes through the free Gateway Endpoint instead of the paid NAT Gateway.

What if you removed the NAT Gateway?

Even if you removed the NAT Gateway route entirely, aws s3 ls would still work. The Gateway Endpoint provides a direct path to S3 that does not depend on internet access at all.

Seeing an access denied or timeout?

Make sure your IAM role (nextwork-ssm-role) has permissions for S3. The AmazonSSMManagedInstanceCore policy alone does not grant S3 access. You may need to attach the AmazonS3ReadOnlyAccess managed policy to the role, or verify your endpoint policy is set to Full access.

Help me troubleshoot S3 access through my Gateway Endpoint.

Understand Gateway Endpoint exam facts

Gateway Endpoints show up on almost every SAA-C03 practice exam. Here are the critical facts you need to know.

Gateway Endpoint exam facts for SAA-C03

Supports ONLY Amazon S3 and DynamoDB (no other services).
Completely free. No hourly charge, no data processing charge.
Uses a prefix list entry in the route table (not an ENI).
Regional only. You cannot access S3 in a different region through it.
Endpoint policies can restrict which S3 buckets or actions are allowed.
Cannot be used from on-premises, peered VPCs in other regions, or through Transit Gateway.
The prefix list route is more specific than 0.0.0.0/0, so it takes precedence over the NAT Gateway route for S3 traffic (longest prefix match).
For gateway endpoint policies: Principal must be set to *, and you use the aws:PrincipalArn condition key to restrict principals.
Gateway endpoints do not use AWS PrivateLink (unlike Interface Endpoints).

The exam cost-optimization pattern

When you see an SAA-C03 question about reducing NAT Gateway costs for S3 or DynamoDB traffic, the answer is almost always "create a Gateway Endpoint". AWS explicitly states this on their pricing page: to avoid NAT Gateway data processing charges for S3, set up a Gateway type VPC endpoint and route the traffic through it instead.

Your private instance now has two paths. General internet traffic still routes through the NAT Gateway at $0.045/GB. S3 traffic routes through the Gateway Endpoint for free. Next up, you will take things further by creating Interface Endpoints that provide private AWS service access without any internet path at all.

Create VPC Interface Endpoints for Systems Manager

Your Gateway Endpoint solved S3 access for free, but your private instance still depends on the NAT Gateway for every other AWS service call. That includes the Session Manager connection you are using right now.

Interface Endpoints (powered by AWS PrivateLink) take a completely different approach. They create Elastic Network Interfaces with private IP addresses directly inside your subnet. In this step, you will create Interface Endpoints for Session Manager, then remove the NAT Gateway route entirely to prove private connectivity works without any internet path.

In this step, get ready to:

Create a security group and three Interface Endpoints for Session Manager services.
Remove the NAT Gateway route and prove Session Manager works purely through PrivateLink.
Review Interface Endpoint exam facts for SAA-C03.

Create Interface Endpoints for Systems Manager

Session Manager requires three Interface Endpoints to function without internet access. Each endpoint handles a different part of the SSM communication channel.

Why three endpoints?

The SSM agent on your instance communicates with three separate AWS services: com.amazonaws.{region}.ssm handles the core Systems Manager API calls. com.amazonaws.{region}.ssmmessages creates and manages Session Manager session channels. com.amazonaws.{region}.ec2messages delivers messages between the SSM service and the agent.

Missing any one of these will cause Session Manager to fail silently. All three must be present.

First, you need a security group that allows the endpoints to receive HTTPS traffic from your VPC.

In the VPC console, click Security Groups in the left navigation pane.
Click Create security group.
Enter nextwork-endpoint-sg for the Security group name.
Enter Allow HTTPS from VPC for Interface Endpoints for the Description.
For VPC, select nextwork-vpc.
Under Inbound rules, click Add rule.
Set Type to HTTPS and Source to 10.0.0.0/16.
Click Create security group.

Why HTTPS from the VPC CIDR?

Interface Endpoints receive traffic through ENIs. The SSM agent on your private instance sends HTTPS requests to these ENIs on port 443. By setting the source to 10.0.0.0/16, you allow any instance in your VPC to communicate with the endpoints.

You should see the new security group in the list. Now create the first Interface Endpoint.

Click Endpoints in the left navigation pane.
Click Create endpoint.
Enter nextwork-ssm-endpoint for the Name tag.
For Service category, verify that AWS services is selected.
In the Service Name search field, type ssm and select com.amazonaws.{region}.ssm where the Type column shows Interface.
For VPC, select nextwork-vpc.

Private DNS is enabled by default

For services other than S3, the Enable DNS name option is already selected. Leave it enabled. This ensures that when the SSM agent calls ssm.{region}.amazonaws.com, DNS resolves to the endpoint's private IP instead of a public address.

Under Subnets, select the Availability Zone where your private subnet lives and choose nextwork-private.
Under Security groups, remove any default security group and select nextwork-endpoint-sg.
Leave Policy set to Full access.
Click Create endpoint.

You should see a success banner confirming the endpoint was created. Now repeat this process for the other two services.

Click Create endpoint again.
Enter nextwork-ssmmessages-endpoint for the Name tag.
Search for ssmmessages and select com.amazonaws.{region}.ssmmessages (Type: Interface).
Select nextwork-vpc, choose the nextwork-private subnet, and attach nextwork-endpoint-sg.
Click Create endpoint.

Click Create endpoint one more time.
Enter nextwork-ec2messages-endpoint for the Name tag.
Search for ec2messages and select com.amazonaws.{region}.ec2messages (Type: Interface).
Select nextwork-vpc, choose the nextwork-private subnet, and attach nextwork-endpoint-sg.
Click Create endpoint.

You now have three Interface Endpoints listed in the Endpoints page. Each one shows a status of Available (this may take 1-2 minutes).

Click on any one of your new endpoints (e.g. nextwork-ssm-endpoint).
Select the Subnets tab.
Note the Network interface ID and Private IP address listed. This is the ENI that AWS created inside your private subnet.

What makes Interface Endpoints different from Gateway Endpoints?

Gateway Endpoints add a prefix list entry to your route table. They have no physical presence in your subnet. Interface Endpoints create actual ENIs with private IP addresses inside your subnet. This is why they cost $0.01/hr per AZ. They create real network infrastructure.

The private DNS feature resolves the service's public hostname (like ssm.us-east-1.amazonaws.com) to the endpoint's private IP. Your SSM agent calls the same public hostname it always did, but DNS now points it to the ENI in your subnet instead of a public address.

Remove the NAT Gateway route and test Session Manager

Right now, your private instance has two paths to AWS services: the NAT Gateway route and the new Interface Endpoints. To prove the endpoints work independently, you will remove the internet path and confirm Session Manager still connects.

Click Route tables in the left navigation pane.
Select your private route table (the one associated with nextwork-private).
Select the Routes tab and click Edit routes.
Find the 0.0.0.0/0 route targeting the NAT Gateway and click Remove.
Click Save changes.

Your private route table now has only the local route and the S3 prefix list route. There is no internet path.

Before you test Session Manager, predict: do you think it will still connect to your private instance now that there is no internet route?

Navigate to Systems Manager in the AWS console (search for it in the top search bar).
Click Session Manager in the left navigation pane.
Click Start session.
Select nextwork-private-instance and click Start session.

Session Manager connects successfully. The SSM agent is now communicating with AWS entirely through the Interface Endpoints' private IPs. No traffic leaves your VPC.

Now prove there is truly no internet path. Run this command in your Session Manager terminal:

curl http://checkip.amazonaws.com --max-time 5

The command times out and fails. Compare this to Step 2 where the same command returned the NAT Gateway's Elastic IP. Your instance genuinely has no internet access, yet Session Manager works perfectly through PrivateLink.

Session Manager not connecting?

Wait 1-2 minutes after removing the route for the SSM agent to re-register through the Interface Endpoints. If it still fails, verify all three endpoints show Available status and that nextwork-endpoint-sg allows HTTPS inbound from 10.0.0.0/16.

Also check that you selected the nextwork-private subnet (not the public subnet) when creating each endpoint. The ENI must be in the same subnet as your instance for private DNS to resolve correctly.

help me troubleshoot why Session Manager is not connecting through my Interface Endpoints

Review Interface Endpoint exam facts

You just proved the key differentiator: Interface Endpoints provide private AWS service access without any internet path. Here are the critical SAA-C03 facts to remember.

Interface Endpoint exam facts for SAA-C03

Creates an ENI (Elastic Network Interface) in your subnet with a private IP address.
Supports 100+ AWS services (SSM, CloudWatch, STS, KMS, EC2 API, and more).
Costs $0.01/hr per AZ plus $0.01/GB data processed (first 1 PB).
Security Groups CAN be attached (unlike NAT Gateway and Gateway Endpoints).
Private DNS resolves the service's public hostname to the endpoint's private IP.
Accessible from on-premises via Direct Connect or VPN (unlike Gateway Endpoints).
Powered by AWS PrivateLink.

Common exam use cases: compliance requirements that prohibit internet exposure, private access to AWS services from isolated subnets, and reducing NAT Gateway data processing costs for AWS service traffic.

When to use Interface Endpoints vs Gateway Endpoints?

Gateway Endpoints are free but only support S3 and DynamoDB. Interface Endpoints cost money but support 100+ services and work from on-premises networks. If the exam asks about S3 or DynamoDB cost optimization, the answer is Gateway Endpoint. If it asks about private access to any other service, the answer is Interface Endpoint.

You have now proven the full spectrum of private connectivity. Your instance accesses S3 for free through a Gateway Endpoint, reaches Systems Manager privately through Interface Endpoints, and has zero internet access. Next up, you will explore a completely different topic: preserving an instance's RAM state across stop/start cycles with EC2 Hibernate.

Hibernate an EC2 Instance and Verify RAM Preservation

So far you have been working with instance states like Running and Stopped. When you stop an instance, everything in RAM disappears. When you start it again, the OS boots fresh.

EC2 Hibernate is a different lifecycle state that saves everything in RAM to the encrypted EBS root volume before stopping. When you resume, the OS picks up exactly where it left off. Long-running processes, in-memory caches, and open connections all survive. The SAA-C03 tests this concept heavily.

In this step, get ready to:

Launch an EC2 instance with hibernate enabled and an encrypted root volume.
Populate the instance's memory and hibernate it.
Resume the instance and prove that RAM contents survived the hibernate/resume cycle.

Launch a hibernate-enabled instance

Hibernation must be enabled at the moment you launch an instance. You cannot enable it after the instance is already running. The root volume must also be encrypted, because RAM contents are written to it during hibernation.

Return to the EC2 console and click Launch instances.
Under Name and tags, enter nextwork-hibernate-instance.
Under Application and OS Images, select Amazon Linux 2023 AMI (it should be the default).
Under Instance type, select t3.micro.
Under Key pair, select Proceed without a key pair (you will use Session Manager to connect).

Under Network settings, click Edit.
Set VPC to nextwork-vpc.
Set Subnet to nextwork-public.
Set Auto-assign public IP to Enable.
Under Firewall (security groups), select Select existing security group and choose nextwork-private-sg.

Why the public subnet?

You are placing this instance in the public subnet so the SSM agent can reach AWS APIs directly through the Internet Gateway. This keeps the hibernate exercise independent from the NAT Gateway and Interface Endpoint configurations you built earlier.

Expand Configure storage.
Set the root volume size to 16 GiB.
Set the volume type to gp3.
Set Encrypted to Yes and leave the KMS key as the default.

Why must the root volume be encrypted?

When an instance hibernates, everything in RAM is written to the root EBS volume. Encryption protects that sensitive data at rest. AWS requires encryption as a prerequisite for hibernate. The volume also needs to be large enough to hold the full RAM contents.

Expand Advanced details.
Under IAM instance profile, select nextwork-ssm-role.
Scroll down to Stop - Hibernate behavior and set it to Enable.
Click Launch instance.

Wait 2-3 minutes for the instance to reach the Running state. You can confirm by returning to your EC2 instances list and checking the Instance state column.

What is the hibernate launch requirement?

You cannot enable or disable hibernation for an instance after you launch it. This is a one-time decision made at launch. If you forget to enable it, you must terminate the instance and launch a new one with the setting turned on.

Don't see the Hibernate behavior option?

Make sure you expanded the Advanced details section at the bottom of the launch wizard. The hibernate setting is not visible by default. Also confirm that your root volume is set to encrypted. Without encryption, the hibernate option may not appear.

help me find the hibernate behavior setting in the EC2 launch wizard

Populate memory and hibernate the instance

Now you will put some data into the instance's memory and disk, record the uptime, and then hibernate. After resuming, you will check whether that data survived.

Go to Systems Manager in the AWS console.
In the left navigation, click Session Manager.
Click Start session.
Select nextwork-hibernate-instance and click Start session.

Create a 100MB test file by running this command:

sudo dd if=/dev/urandom of=/tmp/testfile bs=1M count=100

You should see output confirming that 100 MB was written.

Check the current uptime by running:

uptime

Note the uptime value shown. This is the key number you will check after resuming from hibernation.

Check memory information by running:

cat /proc/meminfo | grep MemTotal

You should see the total RAM available on this instance. All of this memory content will be preserved to disk during hibernation.

What happens during hibernation?

When you hibernate, the OS receives a hibernate signal. It writes the contents of RAM to the encrypted EBS root volume, then the instance enters the Stopped state. Unlike a normal stop (which discards RAM), the data is safely stored on disk and will be restored on resume.

Return to the EC2 console and select nextwork-hibernate-instance.
Click Instance state, then click Hibernate instance.
Confirm the action when prompted.

The instance state changes to Stopping, then Stopped. In the instance's Details tab, the state reason shows Client.UserInitiatedHibernate. This confirms the instance hibernated rather than simply stopping.

Hibernate option greyed out?

If the Hibernate instance option is greyed out, the instance was not launched with hibernation enabled. You must terminate this instance and launch a new one following the steps above. Make sure you set Stop - Hibernate behavior to Enable in Advanced details during launch.

help me troubleshoot why hibernate is greyed out

Resume and verify RAM preservation

The instance is now hibernated. Its RAM contents sit safely on the encrypted root volume. When you start it again, the OS restores RAM from disk and resumes exactly where it left off.

In the EC2 console, select nextwork-hibernate-instance.
Click Instance state, then click Start instance.
Wait for the instance state to reach Running.

Return to Session Manager and start a new session to nextwork-hibernate-instance.

Before you run the next command, think about this: if the instance truly hibernated (rather than doing a fresh reboot), what would the uptime command show?

Check the uptime by running:

uptime

The uptime counter continues from where it was before hibernation. It was NOT reset to zero. This proves the OS was never rebooted. It resumed from the saved RAM state.

Verify the test file still exists by running:

ls -la /tmp/testfile

You should see your 100MB test file listed with its original timestamp. Both the continued uptime and the preserved file prove that RAM state survived the hibernate/resume cycle.

SAA-C03 Hibernate exam facts

RAM is saved to the encrypted EBS root volume and restored on resume.
Root volume MUST be encrypted (requirement).
Must enable at launch. You cannot enable it after the instance is running.
RAM limit: less than 150 GiB (Linux), 16 GiB or less (Windows).
Max hibernation duration: 60 days.
Supported EBS volume types: gp2, gp3, io1, io2.
Billing: NOT charged for compute while hibernated (stopped state). Still charged for EBS storage and Elastic IPs.
Hibernate vs Stop: Stop loses RAM. Hibernate preserves RAM.
Use cases: long-running processes, services with long initialization time, preserving in-memory caches.

Uptime shows only a few seconds?

If uptime restarted from zero, the instance may have performed a normal stop and start instead of a true hibernate. Check the state reason in the EC2 console Details tab. It should read Client.UserInitiatedHibernate. If it does not, the instance was not properly hibernated. Terminate and re-launch with hibernate enabled.

help me figure out why my instance did not hibernate properly

Secret mission

Deploy a NAT Instance and Build the Exam Comparison

The SAA-C03 exam loves to ask when a NAT Instance is more cost-effective than a NAT Gateway. In this secret mission, you will deploy a real NAT Instance, disable source/destination check, route private subnet traffic through it, and build the definitive comparison table that covers every exam-tested attribute.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses several AWS resources that incur hourly charges even when idle.

Cost warning

Your NAT Gateway charges $0.045/hour and your three Interface Endpoints charge $0.01/hour each ($0.03/hour total). Together, that is roughly $0.075/hour or about $1.80/day even if you are not using them.

If you are not continuing immediately, delete these resources to avoid unexpected charges. The Gateway Endpoint for S3 is free and does not contribute to ongoing costs.

Resources you used:

NAT Gateway (nextwork-nat) with an associated Elastic IP.
Three VPC Interface Endpoints (SSM, SSMMessages, EC2Messages).
Three EC2 instances (nextwork-private-instance, nextwork-hibernate-instance, nextwork-nat-instance).
VPC Gateway Endpoint for S3 (free, deleted automatically with VPC).
VPC (nextwork-vpc) including subnets, route tables, security groups, and Internet Gateway.
IAM Role (nextwork-ssm-role).

Keep everything running

No action needed. Choose this if you are still actively building or plan to continue within the next hour or two.

Your NAT Gateway charges $0.045/hour and your Interface Endpoints charge $0.03/hour combined.
EC2 instances (t3.micro) are free-tier eligible if your account is under 12 months. Otherwise they cost approximately $0.0104/hour each.
The Elastic IP is free while associated with the running NAT Gateway.
The Gateway Endpoint for S3 is completely free.

Pause - I'll come back to this later

Shut down running EC2 instances to save compute costs. Be aware that the NAT Gateway and Interface Endpoints still charge hourly even when instances are stopped.

In the EC2 console, select each of your three instances and choose **Instance state**, then **Stop instance**.
This saves compute charges but your NAT Gateway ($0.045/hour) and Interface Endpoints ($0.03/hour) continue billing.
The Elastic IP charges $0.005/hour while not associated with a running instance. Since the NAT Gateway is still active, the Elastic IP remains free.
If you plan to be away for more than a few hours, consider deleting the NAT Gateway and Interface Endpoints and recreating them when you return.

Delete - I don't want to use this again

Remove all project resources and start fresh. This is the recommended option if you have finished the project.

Follow these steps in order to avoid dependency errors.

Delete the Interface Endpoints: In the VPC console, go to **Endpoints**. Select the three Interface Endpoints (SSM, SSMMessages, EC2Messages) and choose **Actions**, then **Delete VPC endpoints**. Confirm the deletion.
Delete the NAT Gateway: In the VPC console, go to **NAT gateways**. Select nextwork-nat and choose **Actions**, then **Delete NAT gateway**. Type delete to confirm. Wait for the state to change to Deleted (this takes 1-2 minutes).
Release the Elastic IP: In the VPC console, go to **Elastic IP addresses**. Select the Elastic IP that was associated with the NAT Gateway. Choose **Actions**, then **Release Elastic IP addresses**. Confirm the release.
Terminate all EC2 instances: In the EC2 console, select all three instances (nextwork-private-instance, nextwork-hibernate-instance, nextwork-nat-instance). Choose **Instance state**, then **Terminate instance**. Confirm the termination.
Delete the VPC: In the VPC console, go to **Your VPCs**. Select nextwork-vpc and choose **Actions**, then **Delete VPC**. This automatically removes the subnets, route tables, security groups, Internet Gateway, and Gateway Endpoint. Type delete to confirm.
Delete the IAM Role: In the IAM console, go to **Roles**. Search for nextwork-ssm-role. Select it and choose **Delete**. Type the role name to confirm deletion.

Why this order matters

You must delete the NAT Gateway before deleting the VPC because the NAT Gateway holds an Elastic IP association. You must release the Elastic IP separately because it is not automatically deleted with the NAT Gateway. The VPC deletion handles everything else (subnets, route tables, security groups, IGW, and the Gateway Endpoint).

That's a Wrap!

Nice work! You just built a complete multi-tier VPC architecture that demonstrates every critical networking pattern tested on the SAA-C03 exam.

You've learned how to:

Built a VPC from scratch with public and private subnets, deployed a NAT Gateway to give private instances internet access, and verified traffic routing using curl http://checkip.amazonaws.com.
Created a free VPC Gateway Endpoint to bypass NAT Gateway data processing charges for S3 traffic, and deployed Interface Endpoints (PrivateLink) that provide private AWS service connectivity without any internet path.
Launched a hibernate-enabled EC2 instance with an encrypted EBS root volume, hibernated it, and verified RAM state preservation across the full hibernate/resume cycle.
Secret Mission: Deployed a NAT Instance with source/destination check disabled, configured routing through it, and built an exam-ready comparison table covering all SAA-C03 tested attributes for NAT Gateway vs NAT Instance.

Ready to quiz yourself?