Prove Inter-Region VPC Peering with EC2

Introduction

30 Second Summary

A network connection can work perfectly while leaving no clear record of how it was secured. When someone asks what changed or who opened access, a green status alone gives a weak answer.

In this project, you will build a private path between two Amazon EC2 instances in London and Virginia using inter-Region Amazon VPC peering. You will preserve a before-and-after connectivity test in an eight-image evidence pack backed by AWS CloudTrail.

What You'll Build

From a browser terminal in London, you will watch the same private-address ping fail before the controls exist and return four replies after the least-privilege path is complete.

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

• A private management session into the London node through an EC2 Instance Connect Endpoint, with neither test instance assigned a public IPv4 address.
• A before-and-after connectivity proof where the same private ping moves from complete loss to four replies after peering, /32 routes, and ICMP access are in place.
• An eight-image audit evidence pack that documents isolation, least privilege, management history, and successful connectivity without claiming certification.
• Secret Mission: Harden endpoint egress to TCP port 22 with a security-group reference, with a successful reconnection proving that private management still works.

Are there any prerequisites?

This project assumes advanced AWS networking experience on Windows with Microsoft Edge and Snipping Tool.

You need one AWS account with permission to create and delete the required VPC, EC2, security group, peering, endpoint, and CloudTrail resources.

Active AWS credits or an applicable Free Tier offer must cover the two short-lived EC2 instances and EBS volumes before you launch them.

Before We Start

Before any lab resources exist, this step locks in the purpose of your private inter-Region connectivity proof. Your evidence should show how peering, routes, and security groups control the path without claiming regulatory certification.

Set Up Private Test VPCs and EC2 Nodes

Your connectivity proof needs a clean lab that keeps the two existing VPCs untouched. Dedicated Amazon VPC networks give you controlled addressing without exposing an existing workload to experimental routes or security groups.

This step creates private Amazon EC2 nodes in London and Virginia. You will also build a private management path that can be removed with the rest of the lab.

In this step, get ready to:

• Verify your AWS permissions and cost eligibility.
• Create two isolated VPCs with private access controls.
• Launch two private EC2 nodes and connect to the London node.

Verify local and account prerequisites

The lab uses the AWS Management Console for every cloud action. Before creating resources, you need to confirm that your account can manage the full lab lifecycle.

• Press the Windows key to open your search bar.
• Type Microsoft Edge into the search bar.
• Press Enter to open Microsoft Edge.
• Sign in to the AWS Management Console with your AWS account.
• Confirm with your account administrator that your identity can manage VPC, EC2, security group, peering, EC2 Instance Connect Endpoint, and AWS CloudTrail resources.

Check Your Credits Before Launching

The two EC2 instances and their root storage can consume credits or incur charges. You will check your account eligibility before launching them, so you can stop safely if no coverage applies.

• Open Billing from the AWS Management Console.
• Check for active AWS credits or an applicable Free Tier offer.
• Confirm that the available coverage applies to two short-lived t3.micro instances.

No Credits or Applicable Offer

Stop here if your account has neither active credits nor an applicable offer. Launching the instances without coverage can create EC2 and EBS charges.

Your evidence folder keeps every screenshot in one place. Snipping Tool provides the captures used later in the audit pack.

• Press Windows logo key + Shift + S to open the Snipping Tool overlay.
• Press Esc after confirming the overlay opens.
• Press Windows logo key + E to open File Explorer.
• Select Desktop in the navigation pane.
• Press Ctrl + Shift + N to create a new folder.
• Enter VPC-Peering-Evidence as the folder name.
• Press Enter to save the folder name.
• Open VPC-Peering-Evidence to confirm that it is empty.

Your account and local evidence tools are ready. The next actions create the isolated network boundary for each test node.

Create the isolated lab networks and access controls

The two lab networks use non-overlapping CIDR blocks. Each VPC receives one IPv4-only subnet that uses the full VPC range.

Why Use Dedicated VPCs?

A dedicated VPC gives the lab its own routes and security boundaries. Deleting the VPC later removes the network without changing either existing VPC.

The London range is 10.1.0.0/16. The Virginia range is 10.2.0.0/16.

• Return to the AWS Management Console in Microsoft Edge.
• Select Europe (London) in the Region selector.
• Confirm that the Region selector shows eu-west-2.
• Use the console search bar to open Amazon VPC.
• Select Your VPCs in the navigation pane.
• Choose Create VPC.
• Select VPC only.

The VPC-only form keeps the lab free from generated gateways or other network components. This preserves the isolated starting state needed for the connectivity test.

• Enter peer-london-vpc as the VPC name.
• Select IPv4 CIDR manual input.
• Enter 10.1.0.0/16 as the IPv4 CIDR.
• Choose Create VPC.
• Confirm that the new VPC details show 10.1.0.0/16.

The London VPC now has its own local address space. Its subnet will inherit the VPC's main route table until you add a narrower peering route later.

• Select Subnets in the Amazon VPC navigation pane.
• Choose Create subnet.
• Select peer-london-vpc as the VPC.
• Select Manual input for the subnet CIDR.
• Enter 10.1.0.0/16 as the IPv4 subnet CIDR.
• Choose Create subnet.
• Confirm that the subnet shows only the IPv4 CIDR 10.1.0.0/16.

• Select Route tables in the Amazon VPC navigation pane.
• Find the route table for peer-london-vpc that shows Yes in the Main column.
• Record its Route table ID as your London main route table ID.
• Select the London main route table.
• Open the Routes tab.
• Confirm that the only route is 10.1.0.0/16 with local as its target.

That single local route proves the London subnet has no path outside its VPC. The same clean starting point is needed in Virginia.

• Switch the Region selector to US East (N. Virginia).
• Confirm that the Region selector shows us-east-1.
• Return to Your VPCs in the Amazon VPC console.
• Choose Create VPC.
• Select VPC only.
• Enter peer-virginia-vpc as the VPC name.
• Select IPv4 CIDR manual input.
• Enter 10.2.0.0/16 as the IPv4 CIDR.

• Choose Create VPC.
• Confirm that the new VPC details show 10.2.0.0/16.
• Select Subnets in the navigation pane.
• Choose Create subnet.
• Select peer-virginia-vpc as the VPC.
• Select Manual input for the subnet CIDR.
• Enter 10.2.0.0/16 as the IPv4 subnet CIDR.
• Choose Create subnet.

• Confirm that the subnet shows only the IPv4 CIDR 10.2.0.0/16.
• Select Route tables in the navigation pane.
• Find the route table for peer-virginia-vpc that shows Yes in the Main column.
• Record its Route table ID as your Virginia main route table ID.
• Select the Virginia main route table.
• Open the Routes tab.
• Confirm that the only route is 10.2.0.0/16 with local as its target.

What Do the Main Route Tables Prove?

Each subnet uses its VPC's main route table because you did not create an explicit subnet association. The local route permits traffic only within the matching VPC CIDR.

There is no peering route in either table. This isolation creates the controlled baseline for the next step.

The instance security groups define which traffic can reach each node. London needs one private SSH path, while Virginia starts with no inbound rules.

• Keep the Region set to US East (N. Virginia).
• Select Security Groups in the Amazon VPC navigation pane.
• Choose Create security group.
• Enter peer-virginia-ec2-sg as the security group name.
• Enter peer-virginia-ec2-sg as the description.
• Select peer-virginia-vpc as the VPC.
• Leave the inbound rules empty.
• Choose Create security group.

The Virginia security group now has no inbound rules. Its default outbound rule remains in place.

• Switch the Region selector to Europe (London).
• Return to Security Groups in the Amazon VPC console.
• Choose Create security group.
• Enter eice-london-sg as the security group name.
• Enter eice-london-sg as the description.
• Select peer-london-vpc as the VPC.
• Leave the inbound rules empty.
• Choose Create security group.

The endpoint security group keeps its default outbound rule. You will narrow that egress in the optional Secret Mission.

• Choose Create security group again.
• Enter peer-london-ec2-sg as the security group name.
• Enter peer-london-ec2-sg as the description.
• Select peer-london-vpc as the VPC.
• Choose Add rule under Inbound rules.
• Select SSH as the rule type.
• Confirm that the port is 22.
• Select eice-london-sg as the source security group.

• Choose Create security group.
• Confirm that inbound TCP port 22 is allowed only from eice-london-sg.
• Confirm that the default outbound rule remains in place.

How the Private SSH Path Works

An EC2 Instance Connect Endpoint provides browser-based access to a private instance without assigning it a public IPv4 address. The instance accepts SSH only from the endpoint security group.

Security groups are stateful. Response traffic from the London instance can return through the accepted connection without a separate inbound response rule.

• Open Amazon EC2 from the console search bar.
• Select Endpoints in the navigation pane.
• Choose Create endpoint.
• Select EC2 Instance Connect Endpoint as the endpoint type.
• Enter peer-london-endpoint as the endpoint name.
• Select peer-london-vpc as the VPC.
• Select eice-london-sg as the security group.
• Select the London subnet with CIDR 10.1.0.0/16.

• Select IPv4 as the endpoint address type.
• Leave client IP preservation off.
• Choose Create endpoint.

Endpoint creation can take a few minutes. The Pending status means AWS is still preparing the private access path.

• Refresh the endpoint list until peer-london-endpoint shows Available.
• Select peer-london-endpoint.
• Confirm that it uses eice-london-sg.
• Confirm that client IP preservation is disabled.

Good progress. Both isolated networks now exist, and the London endpoint is ready to carry private management traffic.

Endpoint Does Not Become Available

• Check that the endpoint was created in peer-london-vpc.
• Check that the selected subnet uses 10.1.0.0/16.
• Check that the endpoint has eice-london-sg attached.

Use this prompt if the status remains pending or changes to a failure state: Help me troubleshoot why my EC2 Instance Connect Endpoint is not becoming Available.

Launch the private test nodes

Each VPC now needs one workload that can prove the network path. Both nodes use the standard Amazon Linux 2023 AMI because it supports browser access through the London endpoint.

Why Use Standard Credit Specification?

T3 instances launch in unlimited credit mode by default. Selecting Standard prevents surplus CPU credit charges from this short-lived lab.

• Keep the Region set to Europe (London).
• Select Instances in the Amazon EC2 navigation pane.
• Choose Launch instances.
• Enter peer-test-london as the instance name.
• Select the standard Amazon Linux 2023 AMI.
• Select t3.micro as the instance type.
• Select Proceed without a key pair (not recommended) under Key pair (login).

The network settings determine whether the London node remains private. The endpoint replaces the need for a public IPv4 address or local key pair.

• Select peer-london-vpc under Network settings.
• Select the London subnet with CIDR 10.1.0.0/16.
• Set Auto-assign Public IP to Disable.
• Select the existing peer-london-ec2-sg security group.
• Expand Advanced details.
• Set Credit specification to Standard.
• Keep the default root EBS storage.
• Choose Launch instance.

• Return to the instance list.
• Wait until peer-test-london shows Running.
• Select peer-test-london.
• Record its private IPv4 address as <LONDON_PRIVATE_IP>.
• Confirm that its public IPv4 address field is empty.

The London node is running with private addressing only. You will now create its Virginia counterpart with the same compute settings.

• Switch the Region selector to US East (N. Virginia).
• Select Instances in the Amazon EC2 navigation pane.
• Choose Launch instances.
• Enter peer-test-virginia as the instance name.
• Select the standard Amazon Linux 2023 AMI.
• Select t3.micro as the instance type.
• Select Proceed without a key pair (not recommended) under Key pair (login).

Virginia starts without inbound access because it only needs to receive the later diagnostic traffic. Its public IPv4 setting must stay disabled.

• Select peer-virginia-vpc under Network settings.
• Select the Virginia subnet with CIDR 10.2.0.0/16.
• Set Auto-assign Public IP to Disable.
• Select the existing peer-virginia-ec2-sg security group.
• Expand Advanced details.
• Set Credit specification to Standard.
• Keep the default root EBS storage.
• Choose Launch instance.

• Return to the instance list.
• Wait until peer-test-virginia shows Running.
• Select peer-test-virginia.
• Record its private IPv4 address as <VIRGINIA_PRIVATE_IP>.
• Confirm that its public IPv4 address field is empty.

Instance Does Not Reach Running

• Check that the instance was launched in the intended lab VPC.
• Check that t3.micro is available in the selected Region.
• Check the instance status details for an account limit or launch-permission issue.

Use this prompt with the status details shown on your screen: Help me troubleshoot why my private EC2 test instance did not reach Running.

The final check proves that the endpoint can reach the London node without a public address. Before you connect, do you expect the browser terminal to identify you as the Amazon Linux default user?

• Switch the Region selector back to Europe (London).
• Select peer-test-london in the EC2 instance list.
• Choose Connect.
• Select EC2 Instance Connect.
• Select Connect using a Private IP.
• Select Private IPv4 address as the address type.
• Select peer-london-endpoint as the endpoint.
• Choose Connect.

You will see a browser terminal connected to peer-test-london as ec2-user. This confirms that private endpoint management works.

• Keep the London browser terminal open for the next step.
• Return to the London instance details in another browser tab.
• Confirm that peer-test-london has no public IPv4 address.
• Switch to US East (N. Virginia) in the instance-list tab.
• Confirm that peer-test-virginia has no public IPv4 address.

Private Connection Does Not Open

• Check that peer-london-endpoint shows Available.
• Check that the endpoint uses the same London subnet as peer-test-london.
• Check that peer-london-ec2-sg allows TCP port 22 from eice-london-sg.

Use this prompt if the browser terminal still does not open: Help me debug my private EC2 Instance Connect Endpoint connection.

Your two private EC2 nodes are running without public IPv4 addresses, and the London management path works through the endpoint. Next, you will test the still-isolated inter-Region path and preserve its baseline result.

Capture the Expected Connectivity Failure

Your private Amazon EC2 nodes are now running in separate Amazon VPC lab networks. The London browser terminal proves you can manage the source node through a private address.

The two route tables still contain only their local routes. Virginia has no ICMP ingress rule.

This incomplete path gives you a designed failure to record. The before-and-after evidence will show why peering, routing, and security remain separate controls.

In this step, get ready to:

• Confirm the local-only routes and the missing Virginia ICMP rule.
• Capture evidence that both test instances use private-only addressing.
• Run the four-packet private test and record the expected packet loss.

Confirm the missing controls

A security group controls traffic at the instance boundary. Checking it beside each route table gives the failed test clear network context.

• Switch back to the signed-in AWS Management Console tab in Microsoft Edge.
• Set the Region selector to Europe (London) (eu-west-2).
• Choose Route tables from the Amazon VPC console navigation.
• Select the recorded main route table ID for peer-london-vpc.
• Choose the Routes tab.

You should see only 10.1.0.0/16 with the local target. This confirms London has no route to Virginia.

• Set the Region selector to US East (N. Virginia) (us-east-1).
• Choose Route tables from the Amazon VPC console navigation.
• Select the recorded main route table ID for peer-virginia-vpc.
• Choose the Routes tab.

You should see only 10.2.0.0/16 with the local target. This confirms Virginia has no return route to London.

• Return to the Amazon EC2 console in us-east-1.
• Choose Security Groups from the left navigation.
• Select peer-virginia-ec2-sg.
• Choose the Inbound rules tab.

The inbound rules list should be empty. This confirms Virginia does not accept an Echo Request from London.

Putting both regional instance details in one image is a little fiddly. Side-by-side Edge windows keep the two private addresses visible while showing that neither instance has a public IPv4 address.

• Choose Instances in the Virginia Amazon EC2 console.
• Select peer-test-virginia.
• Keep the address section of its instance details visible.
• Open a second Microsoft Edge window from the Windows taskbar.
• Use the second window to return to the signed-in AWS Management Console session.
• Set its Region selector to Europe (London) (eu-west-2).
• Choose Instances in the London Amazon EC2 console.
• Select peer-test-london.

Both regional views now expose the addressing evidence you need. Keep each instance name beside its address details so the capture remains easy to interpret.

• Position the London Edge window on the left side of your screen.
• Position the Virginia Edge window on the right side of your screen.
• Press Windows logo key + Shift + S to open the Snipping Tool overlay.
• Drag over both instance detail panes to capture them in one image.
• Save the capture inside VPC-Peering-Evidence as 00-private-instances.png.

Good work. Your first evidence image now ties each test node to a private IPv4 address while preserving the absence of public IPv4 addresses.

Run and capture the baseline test

The baseline uses the Virginia private IPv4 address because this test measures the private data path. Reusing the same four-packet pattern later makes the comparison defensible.

• Return to the browser terminal connected to peer-test-london as ec2-user.
• Set <NB_PACKETS> to 4 when you enter the pattern below.
• Replace <IP_ADDRESS> with the Virginia private IPv4 address you recorded earlier.

Before you run this test, do you expect Virginia to return any Echo Replies through the current network path?

• Run the baseline test from London by entering this documented pattern with those replacements:

ping -c <NB_PACKETS> <IP_ADDRESS>

What does this command test?

• The ping command sends ICMP Echo Requests to the Virginia private IPv4 address.
• The -c option limits the test to the packet count you supply.
• Using four packets creates a short result that fits cleanly into the evidence pack.

You should see no replies from the Virginia private IPv4 address. The summary shows 100% packet loss.

This shortfall is the intended baseline. It proves the isolated networks do not have a complete private path.

• Press Windows logo key + Shift + S to open the Snipping Tool overlay.
• Drag over the terminal command and its packet-loss summary.
• Save the capture inside VPC-Peering-Evidence as 01-baseline-failure.png.

That designed failure is now preserved as evidence. Your later result can use the same source, destination, and packet count for a direct comparison.

Did the baseline behave differently?

• Replace both angle-bracket placeholders with real values if the terminal rejects the command.
• Confirm that no VPC peering connection exists if the test receives replies.
• Confirm that peer-virginia-ec2-sg still has no ICMP inbound rule.

If the result still differs, help me diagnose my unexpected baseline ping result.

Your evidence pack now contains the private-only instance details and the expected baseline failure. Next, you'll create the explicit inter-Region peering relationship.

Create and Accept the Peering Connection

Your baseline ping produced a clean control failure. It proves the two private nodes have no implicit path across their separate Regions.

An inter-Region VPC peering connection establishes an explicit relationship between the two VPCs. London acts as the requester while Virginia acts as the accepter.

This step stops once the connection is Active. The route tables remain unchanged so the connection object stays separate from the packet path.

In this step, get ready to:

• Request the peering connection from the London VPC.
• Accept the request from the Virginia VPC.
• Capture the active connection as evidence.

Create the request from London

The requester starts the peering relationship. The accepter reviews that request before the connection can become active.

• Return to the Amazon VPC console in Microsoft Edge from earlier.
• Switch the current Region to Europe (London), eu-west-2.
• Select Peering connections in the navigation pane.
• Choose Create peering connection.
• Name the connection london-virginia-peering.
• Select peer-london-vpc for VPC ID (Requester).

How do the two roles work?

The requester VPC initiates the relationship. In this lab, peer-london-vpc has that role.

The accepter VPC approves the relationship. That role belongs to peer-virginia-vpc.

• Keep My account selected.
• Choose Another Region.
• Select US East (N. Virginia), us-east-1.
• Select peer-virginia-vpc for VPC ID (Accepter).
• Choose Create peering connection.

The new request should show pending-acceptance. That handoff is working. Virginia can now approve the relationship.

Request not pending?

Confirm that the requester is peer-london-vpc in Europe (London). Confirm that the accepter is peer-virginia-vpc in US East (N. Virginia).

Check that the two VPC CIDRs remain 10.1.0.0/16 and 10.2.0.0/16.

Ask for help with the request details: Help me troubleshoot why my inter-Region VPC peering request did not enter pending-acceptance.

💡 Why direct VPC peering?

Direct VPC peering fits this lab because you are connecting exactly two VPCs. It keeps the relationship visible without adding a central routing layer.

An AWS Transit Gateway is designed for larger networks with multiple attachments. Its additional routing objects would distract from the requester-to-accepter pattern you are proving here.

Accept the request from Virginia

Peering requires approval from the accepter side. Switching to Virginia lets you approve the request in the Region that owns peer-virginia-vpc.

• Switch the current Region to US East (N. Virginia), us-east-1.
• Select Peering connections in the navigation pane.
• Select london-virginia-peering in pending-acceptance.
• Choose Actions.
• Choose Accept request.
• Confirm the approval by choosing Accept request again.
• Continue without adding routes from the acceptance prompt.

Both VPCs have now approved the relationship. The two main route tables still contain only their local VPC routes.

Verify the active connection

Before you refresh the connection, which status do you expect after the request and acceptance are complete?

• Refresh the Peering connections page.
• Select london-virginia-peering.

You should see the connection status as Active. This confirms that London requested the relationship and Virginia accepted it.

Connection not Active?

Confirm that you accepted the request while the console was set to US East (N. Virginia). Refresh the page after completing the confirmation.

Check that you selected london-virginia-peering instead of another connection in the account.

Ask for help with the connection state: Help me troubleshoot why my accepted VPC peering connection is not Active.

💡 What does Active prove?

An Active status proves that both VPCs approved the peering relationship. Packet flow still requires reciprocal route-table entries.

The unchanged route tables preserve the next part of the control story. Peering approval and traffic routing remain separate controls.

• Press Windows logo key + Shift + S to open Snipping Tool.
• Capture the connection details showing london-virginia-peering in the Active state.
• Save the capture as 02-peering-active.png inside VPC-Peering-Evidence.

Your evidence folder should now contain three images. The newest image proves that the inter-Region relationship was explicitly requested and accepted.

Strong work. Your inter-Region peering relationship is active while both route tables remain untouched. Next up, you will add reciprocal host routes and the narrow ICMP rule that turns this approved relationship into a working private path.

Complete the Least-Privilege Network Path

Your Active inter-Region VPC peering connection establishes the relationship between London and Virginia. Traffic starts only after both route tables direct it through that connection.

The baseline exposed a separate gate at the Virginia security group. ICMP Echo Request is still blocked there.

This step adds reciprocal /32 host routes plus one narrow ICMP rule. The final test checks whether the combined private path works.

In this step, get ready to:

• Add reciprocal /32 routes through london-virginia-peering.
• Allow Echo Request only from the London host.
• Prove the completed path with the same four-packet test.

Add the London-to-Virginia route

The London main route table already sends local traffic around peer-london-vpc. A /32 destination sends traffic for one IPv4 address through the peering connection.

• In the signed-in AWS Management Console from earlier, switch the Amazon VPC Region selector to Europe (London) (eu-west-2).
• Select the recorded main route table ID for peer-london-vpc from the route table list.
• Choose Actions.
• Choose Edit routes.
• Choose Add route.
• Enter <VIRGINIA_PRIVATE_IP>/32 for Destination.
• Select london-virginia-peering for Target.
• Choose Save changes.

You'll see the local 10.1.0.0/16 route beside a new <VIRGINIA_PRIVATE_IP>/32 route. The new route points to london-virginia-peering.

Why Use a /32 Host Route?

A /32 destination identifies one IPv4 address. This route sends only traffic for peer-test-virginia to the peering target.

The route provides narrower exposure than sending the entire 10.2.0.0/16 CIDR through the connection. Your screenshot records that least-privilege scope.

• Press Windows logo key + Shift + S to start Snipping Tool.
• Capture the new route row with its Destination plus Target visible.
• Save the capture inside VPC-Peering-Evidence as 03-london-route.png.

Route Won't Save?

• Confirm that london-virginia-peering still shows Active.
• Confirm that Destination contains the Virginia private IPv4 address followed by /32.
• Confirm that you selected the recorded main route table for peer-london-vpc.

Help me fix the London host route.

Add the Virginia-to-London return route

A successful request also needs a return path. The Virginia main route table must send replies for the London host back through the same peering connection.

• Switch the AWS Region selector to US East (N. Virginia) (us-east-1).
• Select the recorded main route table ID for peer-virginia-vpc from the route table list.
• Choose Actions.
• Choose Edit routes.
• Choose Add route.
• Enter <LONDON_PRIVATE_IP>/32 for Destination.
• Select london-virginia-peering for Target.
• Choose Save changes.

You'll see the local 10.2.0.0/16 route beside a new <LONDON_PRIVATE_IP>/32 route. The two main route tables now provide a forward path plus a return path.

• Press Windows logo key + Shift + S to start Snipping Tool.
• Capture the reciprocal route with its Destination plus Target visible.
• Save the capture inside VPC-Peering-Evidence as 04-virginia-route.png.

Return Route Missing?

• Confirm that the console Region is us-east-1.
• Confirm that Destination uses the London private IPv4 address followed by /32.
• Confirm that the route targets london-virginia-peering.

Help me fix the Virginia return route.

Permit diagnostic traffic and retest

The routes now carry packets in both directions. The Virginia security group still decides which incoming packets may reach peer-test-virginia.

The inbound rule accepts only IPv4 Echo Request from <LONDON_PRIVATE_IP>/32. This keeps the diagnostic permission scoped to one source host.

• Return to Amazon EC2 in us-east-1.
• Select Security Groups from the left navigation.
• Select peer-virginia-ec2-sg.
• Choose Edit inbound rules.
• Add a rule with Type set to Custom ICMP - IPv4.
• Choose Echo request.
• Enter <LONDON_PRIVATE_IP>/32 for Source.
• Save the inbound rule.

You'll see one inbound rule allowing Custom ICMP - IPv4 Echo Request from <LONDON_PRIVATE_IP>/32.

• Press Windows logo key + Shift + S to start Snipping Tool.
• Capture the inbound rule with its type plus source visible.
• Save the capture inside VPC-Peering-Evidence as 05-virginia-icmp-rule.png.
• Return to the browser terminal connected to peer-test-london from earlier.

Before you rerun the test, do you expect the result to match the baseline or show a working path?

• Test the completed private path by running this command:

ping -c 4 <VIRGINIA_PRIVATE_IP>

What Does This Test Prove?

• The -c 4 option limits the test to four packets.
• The destination is the private IPv4 address of peer-test-virginia.
• Replies prove that the complete private path works in both directions.

You have closed the baseline gap. The same private-IP test now returns four replies with 0% packet loss.

• Press Windows logo key + Shift + S to start Snipping Tool.
• Capture the command plus the four replies plus the packet-loss summary.
• Save the capture inside VPC-Peering-Evidence as 06-successful-private-ping.png.

Still Seeing Packet Loss?

• Confirm that the London route uses <VIRGINIA_PRIVATE_IP>/32 as its destination.
• Confirm that the Virginia return route uses <LONDON_PRIVATE_IP>/32 as its destination.
• Confirm that peer-virginia-ec2-sg permits Echo Request from <LONDON_PRIVATE_IP>/32.

Help me diagnose the remaining packet loss.

Your evidence folder now preserves the route scope plus the security rule plus the successful private test. Next, you will turn these captures into an audit-ready control story.

Build the Audit Evidence Pack

Your London-to-Virginia ping now succeeds over private IPv4. A successful ping alone does not tie identity or isolation to the controls that produced it.

The first seven captures connect the network configuration to the test result. AWS CloudTrail adds the identity behind the private management connection.

You will finish by applying the shared responsibility model. This gives the evidence an accurate compliance claim boundary.

In this step, get ready to:

• Review the first seven images as one control story.
• Capture the London endpoint's OpenTunnel management event.
• Verify the eight-image pack against the shared-responsibility claim boundary.

Review the control story

An evidence pack should connect the intended control to what was configured. It should also show the observed result.

• Use Windows search to find the existing VPC-Peering-Evidence folder.
• Open the VPC-Peering-Evidence folder from the search results.
• Review 00-private-instances.png to confirm both nodes have private IPv4 addresses with no public IPv4 addresses.
• Compare 01-baseline-failure.png with 06-successful-private-ping.png to connect the baseline failure to the completed path.
• Review 02-peering-active.png to confirm london-virginia-peering reached Active status.
• Compare 03-london-route.png with 04-virginia-route.png to confirm each route targets one host with /32 scope.
• Review 05-virginia-icmp-rule.png to confirm Custom ICMP - IPv4 permits Echo request only from <LONDON_PRIVATE_IP>/32.

How does the evidence tell a control story?

Isolation appears in 00-private-instances.png through private-only addressing.

Least-privilege routing appears in the reciprocal /32 routes.

The Virginia security group limits ICMP ingress to the London host.

Operating effectiveness appears in the before-and-after ping captures. The same private-IP test moves from complete packet loss to four replies.

Capture the management-access event

CloudTrail Event history contains recent management events for the current Region. The endpoint connection is recorded as OpenTunnel.

• Switch back to Microsoft Edge.
• Set the AWS console to Europe (London), which uses eu-west-2.
• Use the AWS Management Console search bar to open AWS CloudTrail.
• Choose Event history from the left navigation.
• Select Event name as the filter.
• Enter OpenTunnel as the filter value.
• Open the event associated with the peer-london-endpoint connection to peer-test-london.

What does OpenTunnel prove?

The event connects a calling identity to the endpoint resource. It also identifies the destination private IP.

The configuration images show how access is controlled. The CloudTrail event adds evidence of who used that private management path.

The event record is dense, so finding all five details can feel fiddly. Work through the event once before taking the capture.

• Confirm the event name is OpenTunnel.
• Confirm the event Region is eu-west-2.
• Identify the endpoint resource associated with peer-london-endpoint.
• Confirm the destination private IP matches <LONDON_PRIVATE_IP>.
• Identify the calling identity recorded for the connection.
• Arrange the event details so all five pieces of evidence are visible.
• Press Windows logo key + Shift + S to start Snipping Tool.
• Save the capture in VPC-Peering-Evidence as 07-cloudtrail-open-tunnel.png.

You should now see 07-cloudtrail-open-tunnel.png in the evidence folder. It completes the management-access portion of the pack.

Can't find the OpenTunnel event?

• Confirm the console is showing eu-west-2 because Event history is Region-specific.
• Confirm the selected filter is Event name.
• Confirm the filter value is exactly OpenTunnel.

If the event still does not appear, help me troubleshoot the missing endpoint event.

Apply the compliance claim boundary

Configuration evidence needs a clear statement of what it supports. The shared responsibility model keeps that statement tied to the controls each party manages.

What can this evidence support?

The screenshots are customer-side configuration evidence. The failed and successful tests add operating-effectiveness evidence.

AWS encrypts inter-Region VPC peering traffic before it leaves AWS facilities. The traffic stays on the AWS backbone.

• Routes remain the customer's responsibility.
• Security-group configuration remains the customer's responsibility.
• IAM access remains the customer's responsibility.
• Data classification remains the customer's responsibility.
• Regulatory decisions remain the customer's responsibility.

The pack supports a general compliance-control discussion. Any named certification requires a separate control mapping plus a formal assessment.

• Apply this claim boundary to every description you write for the evidence pack.
• Keep named certification claims out of the evidence labels.

Before you check the folder, which numbered file do you expect to complete the sequence?

• Press the Windows key to open the search bar.
• Type VPC-Peering-Evidence into the search bar.
• Select the VPC-Peering-Evidence folder from the search results.

You should see exactly eight PNG files. Both the failed test and the successful test remain preserved.

What should I see?

• 00-private-instances.png.
• 01-baseline-failure.png.
• 02-peering-active.png.
• 03-london-route.png.
• 04-virginia-route.png.
• 05-virginia-icmp-rule.png.
• 06-successful-private-ping.png.
• 07-cloudtrail-open-tunnel.png.

That completes the evidence chain. Your eight-image pack now connects private addressing to scoped controls plus management identity.

Secret mission

Harden the Management Path

Replace the endpoint's broad outbound access with a TCP port 22 security-group reference. Prove private management still works. Preserve the London-to-Virginia connectivity proof with fresh CloudTrail evidence.

Clean Up Your Resources

Clean Up Your Resources

Your running Amazon EC2 nodes can continue consuming credits or incurring charges. Decide whether to keep the lab live, stop the nodes for later, or delete the lab entirely.

Cost warning

Running instances consume usage until you stop or terminate them.

Stopped instances preserve their Amazon EBS volumes. Those volumes can continue consuming credits or incurring storage charges.

Cross-Region data transfer can consume credits or incur charges. Cross-AZ data transfer can also consume credits or incur charges.

An EC2 Instance Connect Endpoint has no separate endpoint fee. A VPC peering connection has no creation fee.

Resources you used:

• The running peer-test-london instance with its default root EBS storage in eu-west-2.
• The running peer-test-virginia instance with its default root EBS storage in us-east-1.
• The peer-london-endpoint endpoint in the London subnet.
• The active london-virginia-peering connection.
• The peer-london-vpc dedicated London lab VPC with its subnet, main route table, and custom security groups.
• The peer-virginia-vpc dedicated Virginia lab VPC with its subnet, main route table, and custom security group.
• The local VPC-Peering-Evidence folder with the original evidence pack and hardened-state captures.

Keep everything running

Keep the lab live if you plan to demo or extend it soon. No cleanup is required.

• Keep peer-test-london running in eu-west-2.
• Keep peer-test-virginia running in us-east-1.
• Keep peer-london-endpoint available for private management access.
• Keep london-virginia-peering active for the private cross-Region path.
• Retain the VPC-Peering-Evidence folder for future control discussions.
• Monitor your remaining AWS credits while the instances run.
• Review inter-Region transfer usage after each demonstration.

Pause - I'll come back to this later

Stop both test nodes to end their compute usage. Your VPC resources, endpoint, peering connection, EBS volumes, and evidence remain available for later.

Stop the London node

• Switch back to the signed-in AWS Management Console in Microsoft Edge.
• Switch the console Region to Europe (London), eu-west-2.
• Open the Amazon EC2 console.
• Select peer-test-london.
• Choose Instance state.
• Choose Stop instance.
• Choose Stop.

You will see peer-test-london move to a stopped state. Its root EBS volume remains attached.

Stop the Virginia node

• Switch the console Region to US East (N. Virginia), us-east-1.
• Select peer-test-virginia.
• Choose Instance state.
• Choose Stop instance.
• Choose Stop.

You will see peer-test-virginia move to a stopped state. Compute usage ends for both test nodes.

Resume the lab later

• Start peer-test-london in eu-west-2 when you resume.
• Start peer-test-virginia in us-east-1 when you resume.
• Reconnect to peer-test-london through peer-london-endpoint before repeating the private connectivity test.

Delete - I don't want to use this again

Remove the disposable lab when you have finished using its evidence. Preserve any screenshots you need before deleting the local folder.

Terminate the test nodes

• Close the browser terminal tab connected to peer-test-london.
• Switch back to the signed-in AWS Management Console in Microsoft Edge.
• Switch the console Region to Europe (London), eu-west-2.
• Open the Amazon EC2 console.
• Select peer-test-london.
• Choose Instance state.
• Choose Terminate (delete) instance.
• Confirm with Terminate (delete).
• Wait for the London termination to complete.
• Switch the console Region to US East (N. Virginia), us-east-1.
• Select peer-test-virginia.
• Choose Instance state.
• Choose Terminate (delete) instance.
• Confirm with Terminate (delete).
• Wait for the Virginia termination to complete.

Both test nodes are now removed. Their default root storage should be removed with them.

Delete the endpoint and peering connection

• Switch the console Region to Europe (London), eu-west-2.
• Open the Amazon EC2 console.
• Choose Endpoints.
• Select peer-london-endpoint.
• Choose Actions.
• Choose Delete VPC endpoints.
• Enter delete.
• Choose Delete.

You will no longer see peer-london-endpoint in the endpoint list after deletion completes.

• Open the Amazon VPC console in eu-west-2.
• Choose Peering connections.
• Select london-virginia-peering.
• Choose Actions.
• Choose Delete peering connection.
• Enter delete.
• Choose Delete.

You will no longer see london-virginia-peering as an active connection.

Delete the dedicated VPCs and evidence

• Choose Your VPCs in the Amazon VPC console.
• Select peer-london-vpc.
• Choose Actions.
• Choose Delete VPC.
• Complete the deletion confirmation.

The VPC console removes the London subnet, main route table, security groups, and default network components after the blocking dependencies are gone.

• Switch the console Region to US East (N. Virginia), us-east-1.
• Choose Your VPCs.
• Select peer-virginia-vpc.
• Choose Actions.
• Choose Delete VPC.
• Complete the deletion confirmation.

The VPC console removes the Virginia subnet, main route table, security group, and default network components after the deletion completes.

• Review the EC2 inventory in eu-west-2 to confirm no active London lab instance remains.
• Review the regional volume inventory to confirm no unattached London lab volume remains.
• Review the EC2 inventory in us-east-1 to confirm no active Virginia lab instance remains.
• Review the regional volume inventory to confirm no unattached Virginia lab volume remains.
• Locate the existing VPC-Peering-Evidence folder in your Windows file manager.
• Remove the VPC-Peering-Evidence folder using the file manager's deletion control.
• Confirm the folder no longer appears in its previous location.

Your disposable inter-Region lab is now removed. The AWS consoles should show no active lab instances, endpoint, peering connection, dedicated VPCs, or unattached lab volumes.

Nice Work!

Nice Work!

You did it! Your evidence-backed lab now proves that two private Amazon EC2 instances can communicate between London and Virginia without public IPv4 addresses.

What you learned:

• Created two disposable VPCs with non-overlapping CIDRs. Launched one private Amazon EC2 node in each Region without a public IPv4 address.
• Captured the designed baseline failure before the private path existed. Activated inter-Region VPC peering with reciprocal /32 host routes. Restricted IPv4 Echo Request to the London host before proving 0% packet loss.
• Built an eight-image audit evidence pack that traces the control story from isolation to successful connectivity. Used AWS CloudTrail OpenTunnel history to document private management access. Applied shared responsibility framing without claiming a named regulatory certification.
• Completed the optional Secret Mission by restricting EC2 Instance Connect Endpoint egress to TCP port 22 with peer-london-ec2-sg as the destination. Proved the hardened management path by reconnecting through peer-london-endpoint. Captured the newer OpenTunnel event as evidence.

Ready to quiz yourself?