Lab: Optimizing AWS Connectivity with VPC Peering and Reachability Analyzer

This hands-on lab focuses on selecting and implementing the most cost-effective and high-performance method for interconnecting two VPCs in the same region: VPC Peering. You will also learn to use Reachability Analyzer to troubleshoot and verify connectivity intent, a critical skill for network reliability.

[!WARNING] Remember to run the teardown commands at the end of this lab to avoid ongoing charges for any resources provisioned.

Prerequisites

An active AWS Account.
AWS CLI installed and configured with Administrator permissions.
A basic understanding of VPC CIDR blocks and Route Tables.
Access to a region with at least 2 Availability Zones (e.g., us-east-1).

Learning Objectives

Differentiate between VPC Peering and Transit Gateway for cost-effectiveness.
Establish a high-performance, low-latency peering connection between two VPCs.
Configure route tables and security groups for least-privilege access.
Use AWS Reachability Analyzer to verify connectivity without sending actual traffic.

Architecture Overview

We will create a requester-accepter model using two VPCs in the same region. This architecture minimizes costs compared to a Transit Gateway by avoiding hourly processing fees and using the direct AWS backbone.

Loading Diagram...

Step-by-Step Instructions

Step 1: Create the Networking Environment

First, we need two VPCs with non-overlapping CIDR blocks to allow for peering.

bash

# Create VPC A
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=Lab-VPC-A}]'

# Create VPC B
aws ec2 create-vpc --cidr-block 10.1.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=Lab-VPC-B}]'

▶Console alternative

Navigate to

VPC Dashboard > Your VPCs > Create VPC

. Create two VPCs: one with CIDR 10.0.0.0/16 and another with 10.1.0.0/16.

Step 2: Establish the VPC Peering Connection

Initiate the request from VPC A to VPC B. Because both are in your account, you will also accept the request.

bash

# Request Peering (Replace <VPC_A_ID> and <VPC_B_ID> with your IDs)
aws ec2 create-vpc-peering-connection --vpc-id <VPC_A_ID> --peer-vpc-id <VPC_B_ID>

# Accept Peering (Replace <PEERING_CONN_ID> with the ID from the previous output)
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id <PEERING_CONN_ID>

[!IMPORTANT] VPC Peering is non-transitive. If VPC A is peered with B, and B is peered with C, A cannot talk to C through B.

Step 3: Optimize Routing for Reliability

For traffic to flow, each VPC's route table must point to the peering connection for the other VPC's CIDR range.

bash

# Add route in VPC A pointing to VPC B's CIDR
aws ec2 create-route --route-table-id <RT_A_ID> --destination-cidr-block 10.1.0.0/16 --vpc-peering-connection-id <PEERING_CONN_ID>

# Add route in VPC B pointing to VPC A's CIDR
aws ec2 create-route --route-table-id <RT_B_ID> --destination-cidr-block 10.0.0.0/16 --vpc-peering-connection-id <PEERING_CONN_ID>

Checkpoints

Peering Status: Run aws ec2 describe-vpc-peering-connections. The Status code should be active.
Route Propagation: Check the route tables in the AWS Console. You should see a route for the remote CIDR with the target pcx-xxxxxx.
Verification: Use the Reachability Analyzer (Step 4) to confirm the path is clear.

Step 4: Verify with Reachability Analyzer

Reachability Analyzer is a configuration analysis tool that performs a static analysis of your VPC task to determine if a destination is reachable.

▶Console Guide (Recommended for Visualization)

Navigate to

VPC Dashboard > Reachability Analyzer

. 2. Click

Create and analyze path

. 3. Source: Select a Network Interface or Instance in VPC A. 4. Destination: Select a Network Interface or Instance in VPC B. 5. Protocol: TCP/UDP as needed. 6. Click

Create and analyze path

[!TIP] Reachability Analyzer helps identify if a Security Group or Network ACL is blocking traffic before you even launch an instance, saving time and money.

Clean-Up / Teardown

To avoid charges, delete the resources in this order:

bash

# 1. Delete VPC Peering Connection (Removes routes automatically)
aws ec2 delete-vpc-peering-connection --vpc-peering-connection-id <PEERING_CONN_ID>

# 2. Delete VPCs
aws ec2 delete-vpc --vpc-id <VPC_A_ID>
aws ec2 delete-vpc --vpc-id <VPC_B_ID>

Troubleshooting

Error	Possible Cause	Fix
`Status: Failed`	Overlapping CIDR blocks.	Ensure VPC A and B do not use the same IP ranges.
`Unreachable`	Missing Route Table entry.	Verify both route tables have the `pcx-...` entry.
`Security Group Block`	Default SG denies inbound.	Update the Accepter's Security Group to allow traffic from the Requester's CIDR.

Stretch Challenge

Scenario: Imagine you have 50 VPCs that all need to talk to each other.

Calculate the number of peering connections needed for a full mesh ( $n(n-1)/2$ ).
Research AWS Transit Gateway and explain in one paragraph why it would be more operationally efficient than Peering in this scenario, despite the higher cost.

Cost Estimate

Component	Cost (US-East-1)	Note
VPC Peering	$0.00 / hour	No hourly fee.
Data Transfer	$0.01 / GB	Same as Data Transfer within AZ/Region.
Reachability Analyzer	$0.10 / analysis	First 10 per month are often free in some regions.
Total for Lab	~$0.10	Very cost-effective.

Concept Review

Feature	VPC Peering	Transit Gateway
Cost	Low (No hourly charge)	Higher ($0.05/hr + processing)
Performance	Highest (No bottleneck)	High (But subject to TGW limits)
Complexity	High for many VPCs (N^2)	Low (Hub-and-spoke)
MTU	Supports 1500 (Jumbo for some)	Supports 8500 (Jumbo)

Summary: For high-performance, point-to-point connections within a region, VPC Peering is the winner for cost and performance. Use Transit Gateway for global scale and management simplicity.