Launching VPC Resources (Part 4)

Launch EC2 in a private subnet and connect using EC2 Instance Connect Endpoint.

Introduction

30 Second Summary

Imagine locking a server in a room with no doors to the outside world. It is safe from intruders, but now even you cannot get in. That is the reality of running resources in a private subnet.

In this project, you will launch an EC2 instance into your private subnet, experience the connection problem firsthand, and then solve it using the modern EC2 Instance Connect Endpoint method.

What You'll Build

By the end of this project, you will SSH into a private instance that has no public IP, using nothing but your terminal and an identity-aware tunnel that AWS manages for you.

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

  • A private EC2 instance you can connect to securely from your terminal, proving that "private" does not mean "unreachable to you."
  • An EC2 Instance Connect Endpoint that tunnels you into private instances without a bastion host, public IP, or open inbound port to the internet.
  • A wizard-created VPC that rebuilds in seconds what took you three projects to assemble by hand, so you can see both the fast path and the deep understanding you now carry.
  • Secret Mission: test what your private instance can and cannot reach on the internet, and discover why NAT gateways exist.

Are there any prerequisites?

This is Part 4 of the NextWork VPC series. You need a VPC with public and private subnets, route tables, security groups, and NACLs from Parts 1-3.

You also need the AWS CLI installed and configured on your machine.

Before We Start

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

Verify Your Environment

You built a VPC with public and private subnets across Parts 1-3. Before you launch any new resources into it, you need to confirm everything is still intact.

A missing subnet or a misconfigured route table will cause silent failures later. This step verifies your foundation so you can build on it with confidence.

In this step, get ready to:
  • Confirm your AWS CLI is authenticated to your AWS account.
  • Verify your VPC and private subnet from Parts 1-3 still exist.
  • Check that your private subnet's route table has no route to an internet gateway.
Confirm your AWS CLI is authenticated

The AWS CLI needs valid credentials to interact with your AWS account. A quick identity check confirms you are connected to the right account before making any changes.

  • Open your terminal by pressing the Windows key, typing cmd, and pressing Enter.
  • Before you run the next command, what do you expect to see if your CLI is properly configured?
  • Confirm your CLI is authenticated by running this command:
aws sts get-caller-identity

You should see JSON output containing your Account ID, UserId, and Arn. This proves your CLI can reach AWS and knows which account you are.

Seeing an error or no output?

If you see a credentials error, your AWS CLI session may have expired. Re-run aws configure and enter your Access Key ID and Secret Access Key.

If the command is not recognized, AWS CLI may not be installed or not added to your system PATH. Revisit the AWS CLI installation guide for your operating system.

Help me troubleshoot my AWS CLI credentials

Verify your VPC and private subnet exist

Now confirm the VPC infrastructure you built in Parts 1-3 is still in place. You need to see your private subnet listed and note its Subnet ID for later.

  • Open the AWS Management Console in your browser and sign in.
  • In the search bar at the top, type VPC and select VPC from the results.
  • In the left navigation pane, choose Subnets.
  • Find your private subnet from Part 3 in the list. Confirm it appears and note its Subnet ID (it looks like subnet-0abc123def456). You will need this in Step 2.

Find your subnet quickly

If you have many subnets listed, use the search filter at the top of the Subnets page. Filter by the name you gave your private subnet in Part 3, or filter by your VPC ID to show only subnets in your custom VPC.

Don't see your private subnet?

Check that you are in the correct AWS Region (top-right corner of the console). Your VPC and subnets only appear in the region where you created them.

If the subnet was accidentally deleted, you will need to recreate it following the steps from Part 3 before continuing.

Help me find my private subnet

Confirm the private subnet has no internet gateway route

A subnet is only truly private if its route table has no route pointing to an internet gateway. This final check proves your subnet is isolated from the internet.

  • On the Subnets page, select (click) your private subnet.
  • Choose the Route table tab in the lower panel.
  • Before you look at the routes, what do you expect to see here if the subnet is truly private?
  • Look at the routes listed. You should see only a local route (with your VPC CIDR as the Destination and local as the Target). There should be no route with a Target starting with igw-.

What does this confirm?

A route table with only a local route means the subnet can talk to other resources inside the VPC, but has no path to the public internet. Any instance launched here will be completely unreachable from outside.

If you saw a route with 0.0.0.0/0 pointing to an internet gateway (igw-...), that would make it a public subnet instead.

Seeing an internet gateway route?

If your private subnet's route table shows a route to an igw- target, it means the subnet is configured as public. Go back to the Route tables section in the left navigation and check that the correct route table is associated with your private subnet. Your private subnet should use the route table that has only the local route.

Help me fix my private subnet route table

Your environment is verified and ready. Next up, you will launch an EC2 instance into that private subnet and experience firsthand what happens when you try to connect to something that has no public IP.

Launch an EC2 Instance in Your Private Subnet

Your VPC and private subnet are confirmed and ready. Now it's time to put a resource inside that private subnet and see how it behaves differently from your public one.

A private subnet has no route to an internet gateway. That means anything you launch there should be completely invisible to the outside world. In this step, you will launch an EC2 instance into your private subnet and prove that it is unreachable from the internet.

In this step, get ready to:
  • Launch an EC2 instance in your private subnet with no public IP.
  • Observe that the instance only has a private IPv4 address.
  • Attempt to connect and experience the failure firsthand.
Launch a new EC2 instance

You already launched an instance in your public subnet in an earlier project. This time you will target the private subnet instead.

  • In the AWS Management Console, navigate to the EC2 service using the search bar at the top.
  • In the left sidebar, click Instances.
  • Click Launch instances in the top right corner.

The launch wizard opens with several configuration sections. Start with the basics.

  • Under Name and tags, enter a name like Private-Instance so you can distinguish it from your public subnet instance.
  • Under Application and OS Images (Amazon Machine Image), select Amazon Linux 2023 AMI.
  • Under Instance type, select t2.micro (Free tier eligible).
  • Under Key pair (login), select the same key pair you used for your public instance.

Why are we using the same key pair?

A key pair lets you authenticate when connecting via SSH. Even though this instance will not be reachable from the internet right now, you still want the key pair attached for when you set up a proper connection method in the next step.

Now configure the network settings. This is where the critical difference from a public instance lives.

  • In the Network settings section, click Edit.
  • In the VPC dropdown, select your custom VPC from Parts 1-3.
  • In the Subnet dropdown, select your private subnet (the one whose route table has no internet gateway route).
  • Confirm Auto-assign public IP says Disable. This is the default for private subnets. Do not change it.
  • Under Firewall (security groups), select Create security group.
  • Leave the default rule: Type SSH, Port 22, Source 0.0.0.0/0 (Anywhere). You will restrict this properly in the next step.
  • Click Launch instance.

You should see a success message confirming your instance is launching.

Why allow SSH from anywhere if it is private?

Allowing SSH from 0.0.0.0/0 sounds wide open, but the private subnet has no internet gateway route. No traffic from the public internet can reach this instance regardless of the security group rule.

In the next step, you will tighten this to your VPC CIDR range once you set up the proper connection method.

Not seeing your VPC or subnet in the dropdowns?

Make sure you are in the same AWS Region you used in Parts 1-3. Check the region selector in the top right of the console.

If your VPC still does not appear, return to the VPC console and confirm it exists under Your VPCs. Help me find my VPC from Parts 1-3 in the EC2 launch wizard.

Check the instance details
  • Click View all instances (or navigate back to Instances in the left sidebar).
  • Wait for the Instance state column to show Running. This may take a minute.
  • Select your Private-Instance by clicking its checkbox.
  • In the Details tab at the bottom, look at Public IPv4 address.

You should see a dash where the public IP would normally appear. The instance only has a Private IPv4 address (something like 10.0.x.x).

What does this tell you?

Your public subnet instance received a public IP automatically because the subnet was configured to auto-assign one and it had a route to the internet gateway. This private instance has neither. With no public IP and no internet route, there is no path from the outside world to this machine.

Try to connect to your instance

Your instance is running, but can you actually reach it? Before you try, think about what you expect to happen.

  • With your Private-Instance still selected, click the Connect button at the top of the page.
  • On the Connect to instance page, leave the default EC2 Instance Connect tab selected.
  • Before you click Connect, predict: do you think this will succeed or fail? Why?
  • Click Connect.

The connection fails. You see an error message indicating that EC2 Instance Connect is unable to connect to your instance.

Why did the connection fail?

EC2 Instance Connect through the browser requires a public IP and a route from the internet. Your instance has neither. There is simply no network path from the AWS console (which reaches through the public internet) to your private instance.

This is exactly what "private" means in AWS networking. The instance is alive and healthy, but completely isolated from the internet. In the next step, you will set up the modern, bastion-free way to reach it.

Did the connection actually succeed?

If the connection worked, your instance is probably not in the private subnet. Go back to the instance Details tab and check the Subnet ID matches your private subnet. Also confirm the subnet's route table has no route to an internet gateway.

Help me verify my instance is actually in my private subnet.

Your private instance is running but completely unreachable. Next up, you will solve this problem using EC2 Instance Connect Endpoint, the modern way to reach private instances without a bastion host or public IP.

Connect via EC2 Instance Connect Endpoint

You proved in the last step that your private instance is completely unreachable from the internet. That is exactly the security posture you want for production workloads. But you still need a way to manage the instance.

EC2 Instance Connect Endpoint is the modern, bastion-free method for reaching private instances. In this step, you will create one and use it to SSH into your private instance without ever giving it a public IP.

In this step, get ready to:
  • Create an EC2 Instance Connect Endpoint in your VPC.
  • Tighten the private instance's security group to VPC-only SSH access.
  • SSH into the private instance from your terminal using the AWS CLI.
Create an EC2 Instance Connect Endpoint

An EC2 Instance Connect Endpoint is an identity-aware TCP proxy that lives inside your VPC. It establishes a private tunnel from your computer to the endpoint using your IAM credentials. No bastion host, no public IP required.

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

What is an EC2 Instance Connect Endpoint?

Traditional bastion hosts require you to maintain a publicly accessible server just to hop into private instances. EC2 Instance Connect Endpoint replaces that pattern entirely.

It uses your IAM identity to authenticate the connection, then tunnels traffic directly to the private instance. No server to patch, no extra cost, no public attack surface.

  • For Type, choose EC2 Instance Connect Endpoint.
  • Select your VPC from the dropdown.
  • For Subnet, select your private subnet.
  • For IP address type, choose IPv4.
  • Leave the security group as the VPC default.
  • Click Create endpoint.

The endpoint status starts as Pending. Wait until it changes to Available before continuing. This takes a few minutes.

Only one per VPC

AWS allows one EC2 Instance Connect Endpoint per VPC. That single endpoint can reach any instance in any subnet within the VPC.

Endpoint stuck on Pending?

It typically takes 2-5 minutes for the endpoint to become available. If it stays on Pending for more than 10 minutes, confirm you selected the correct VPC and private subnet.

help me troubleshoot my EC2 Instance Connect Endpoint stuck in Pending status

Tighten the security group to VPC-only access

Your private instance currently allows SSH from anywhere (0.0.0.0/0). Since all traffic now arrives through the endpoint inside your VPC, you can restrict SSH to the VPC CIDR range only.

  • Switch back to the EC2 console.
  • Click Instances in the left sidebar.
  • Select your private subnet instance.
  • Click the Security tab in the instance details panel below.
  • Click the security group link to open it.
  • Click Edit inbound rules.
  • In the SSH rule (port 22), change the Source from 0.0.0.0/0 to your VPC CIDR range (e.g., 10.0.0.0/16).
  • Click Save rules.

Why restrict to the VPC CIDR?

The EC2 Instance Connect Endpoint lives inside your VPC. When it forwards traffic to your instance, the traffic arrives from a VPC-internal IP address.

By restricting SSH to the VPC CIDR, you ensure that only traffic routed through the endpoint (or other VPC resources) can reach port 22. Anything from the public internet is blocked.

You should now see the updated rule showing your VPC CIDR as the source instead of 0.0.0.0/0.

Not sure what your VPC CIDR is?

Go to the VPC console, click Your VPCs, and find your VPC. The IPv4 CIDR column shows the range (e.g., 10.0.0.0/16).

help me find my VPC CIDR range to use in my security group rule

SSH into your private instance

Everything is in place. The endpoint is available, and the security group allows traffic from within the VPC. Time to connect.

  • In the EC2 console, copy your private instance's Instance ID (it starts with i-).
  • Open your terminal.

Before you run the next command, predict what will happen. Do you think you will get a shell prompt on the private instance, or will the connection fail?

  • Connect to your private instance by running this command:
aws ec2-instance-connect ssh --instance-id [[INSTANCE_ID="your private instance ID"]] --os-user ec2-user --connection-type eice

You should see the Amazon Linux prompt appear:

[ec2-user@ip-10-0-x-x ~]$

You are now inside your private instance. This instance has no public IP and no internet-facing route, yet you reached it securely through the EC2 Instance Connect Endpoint tunnel.

What just happened?

The --connection-type eice flag told the AWS CLI to route your SSH session through the EC2 Instance Connect Endpoint. The CLI authenticated you with your IAM credentials, opened a tunnel to the endpoint inside the VPC, and forwarded your session to the private instance.

No public IP was needed at any point. The instance stayed completely private.

  • Type exit and press Enter to close the SSH session and return to your local terminal.

Connection timed out or refused?

Confirm your EC2 Instance Connect Endpoint status is Available (not Pending).

Check that the security group on your private instance allows SSH (port 22) from the VPC CIDR range, not from a single IP.

Verify you pasted the correct Instance ID (starts with i-).

help me troubleshoot why my EC2 Instance Connect Endpoint SSH connection is failing

You now have a secure, repeatable way to manage instances that live in private subnets. Next up, you will see how the VPC wizard can build all the infrastructure you created manually in just one click.

Speed-Build a VPC with the Wizard

You just connected to a private instance without exposing it to the internet. Over the last three projects, you built every piece of your VPC by hand. Subnets, route tables, an internet gateway, security groups, NACLs.

The "VPC and more" wizard can create all of that in a single step. In this step, you will use the wizard to speed-build a complete VPC, compare what it creates to your manual build, and then delete it to keep your account clean.

In this step, get ready to:
  • Create a VPC using the "VPC and more" wizard with one public and one private subnet.
  • Compare the wizard-created resources to what you built manually in Parts 1-3.
  • Delete the wizard VPC to avoid clutter in your account.
Create a VPC with the wizard

Instead of creating each resource one at a time, the wizard lets you define the entire architecture on a single page and provisions everything at once.

  • In the VPC console, click Your VPCs in the left navigation pane.
  • Click Create VPC in the top right corner.
  • Under Resources to create, select VPC and more.
  • In the Name tag auto-generation field, enter wizard-vpc.
  • Set Number of Availability Zones to 1.
  • Set Number of public subnets to 1.

What does VPC and more do?

When you select VPC and more, the wizard creates not just the VPC itself but also subnets, route tables, an internet gateway, and all the associations between them. Selecting "VPC only" would give you an empty VPC with no networking configured.

This single page replaces the many separate steps you performed across Parts 1-3.

  • Set Number of private subnets to 1.
  • Under NAT gateways, confirm it is set to None.
  • Confirm DNS options are enabled (both checkboxes checked).
  • Click Create VPC.

The console shows a progress page as it creates each resource. After a few seconds, all items show a green success status.

Compare the wizard resources to your manual build

Before you look at the Resource map, think about this: how many individual resources do you think the wizard just created for you?

  • In the left navigation pane, click Your VPCs.
  • Select the checkbox next to your new wizard-vpc VPC.
  • Click the Resource map tab.
  • Click Show details to expand the full view.

You should see a visual map showing the VPC, its subnets, route tables, and internet gateway all wired together. Public subnets appear in green and private subnets in blue.

What did the wizard auto-configure?

The wizard created a VPC, one public subnet, one private subnet, two route tables (one for each subnet type), and an internet gateway. It also attached the internet gateway to the VPC and added a route from the public subnet's route table to it.

Compare this to your manual build from Parts 1-3. The wizard performed in one click what took you three entire projects to assemble piece by piece. The difference is that you now understand exactly what each piece does and why it exists.

Delete the wizard VPC

You do not need two VPCs in your account. The wizard VPC was only for comparison purposes. Deleting it keeps your account clean and avoids confusion with your manually-built VPC.

  • In the Your VPCs list, select the checkbox next to your wizard-vpc VPC.
  • Click Actions, then Delete VPC.
  • Review the list of resources that will be deleted alongside the VPC (subnets, route tables, internet gateway, security groups, network ACLs).
  • Type delete in the confirmation field.
  • Click Delete.

After a moment, the wizard VPC disappears from the list. All associated resources (subnets, route tables, internet gateway) are cascade-deleted automatically.

Why does console deletion cascade?

When you delete a VPC through the console, AWS automatically removes its subnets, route tables, security groups, network ACLs, internet gateways, and gateway endpoints. This only works from the console. If you delete via the CLI, you must remove each resource individually in the correct order.

Getting a deletion error?

If the console says resources must be deleted first, check whether any EC2 instances are running inside the wizard VPC. Terminate them first, then retry the VPC deletion.

Why can't I delete my wizard VPC?

Confirm your original VPC from Parts 1-3 still appears in the Your VPCs list. Only the wizard VPC should be gone.

Secret mission

Test Your Private Instance's Internet Access

You can SSH into your private instance. But can it actually talk to the outside world? In this secret mission, you will test outbound internet connectivity from inside the private instance and discover a fundamental gap that explains why NAT gateways exist.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses free-tier-eligible EC2 instances and the EC2 Instance Connect Endpoint has no additional charge, so there are no ongoing costs while instances are stopped.

Resources you used:

  • EC2 instance in your private subnet (free tier eligible, no charge while stopped).
  • EC2 instance in your public subnet (started during testing, free tier eligible).
  • EC2 Instance Connect Endpoint (no additional charge).

Keep everything running

No action needed. Choose this if you plan to continue with Part 5 (Testing VPC Connectivity). Your private instance will be available and the EC2 Instance Connect Endpoint stays ready at no cost.

  • Your private EC2 instance remains running (free tier eligible).
  • Your public EC2 instance remains running (free tier eligible).
  • The EC2 Instance Connect Endpoint remains available at no charge.

Pause - I'll come back to this later

Stop both instances to free up resources while keeping everything in place. The EC2 Instance Connect Endpoint stays available at no cost. Resume anytime by starting the instances again.

  • In the EC2 console, select your private subnet instance.
  • Choose Instance state, then Stop instance.
  • Click Stop when prompted.
  • Repeat for your public subnet instance if it is still running.

Delete - I don't want to use this again

Remove all project resources permanently. Only do this if you plan to redo the setup from scratch in Part 5.

  • Terminate the private subnet EC2 instance:
  • In the EC2 console, choose Instances in the left navigation pane.
  • Select the private subnet instance.
  • Choose Instance state, then Terminate (delete) instance.
  • Click Terminate (delete) to confirm.
  • Stop your public subnet instance (it was created in a previous part, so stop rather than terminate to preserve it for future projects):
  • Select the public subnet instance.
  • Choose Instance state, then Stop instance.
  • Click Stop to confirm.
  • Delete the EC2 Instance Connect Endpoint:
  • Open the VPC console.
  • In the left navigation pane, choose Endpoints.
  • Select your EC2 Instance Connect Endpoint.
  • Choose Actions, then Delete VPC endpoints.
  • When prompted, enter delete to confirm.
  • Click Delete.

Nice Work!

Nice Work!

You have deployed an EC2 instance into a private subnet and connected to it securely using the modern, bastion-free method. You also saw how the VPC wizard can rebuild in seconds what took three projects to do by hand.

You've learned how to:

  • Launch an EC2 instance in a private subnet and confirm it has no public IP and no internet-facing path.
  • Create an EC2 Instance Connect Endpoint to securely SSH into private instances without a bastion host or public IP.
  • Use the "VPC and more" wizard to speed-build a complete VPC with subnets, route tables, and an internet gateway in one step.
  • Secret Mission: Test internet access from inside both public and private instances, proving that private subnets need a NAT gateway for outbound connectivity.

Ready to quiz yourself?