Study guide

Technical reference and lesson notes

Purpose of This Lesson

This hands-on lesson demonstrates how to create private connectivity between two VPCs in different AWS Regions within the same AWS account. The workflow uses CloudFormation to deploy the lab infrastructure, VPC peering to connect the networks, route tables and security groups to permit traffic, and EC2 Instance Connect with ping and curl to validate communication.

The example connects VPCs in US East (N. Virginia), us-east-1, and US West (N. California), us-west-1.

Key Concepts

VPC peering connection: A private network connection between two VPCs. In this lab, the VPCs are in different Regions but belong to the same AWS account.
Requester and accepter: The VPC that creates the peering request is the requester. The VPC in the other Region must accept the request before the connection becomes active.
Non-overlapping CIDR blocks: The lab uses 10.0.0.0/16 for the US East VPC and 10.1.0.0/16 for the US West VPC. Distinct CIDR ranges are required for unambiguous routing between the networks.
Private IP communication: After peering and routing are configured, the EC2 instances communicate using their private IP addresses rather than public addressing.
Route-table participation: A peering connection alone does not provide connectivity. Each VPC needs a route to the other VPC’s CIDR block, with the VPC peering connection as the target.
Security-group authorization: The security groups must permit the desired traffic. In the lab, SSH (22) and HTTP (80) are allowed from anywhere, while ICMP is allowed from the opposite VPC’s CIDR block.
Region-specific AMIs: AMI IDs differ by Region. The CloudFormation templates must use a valid AMI ID for the Region where each stack is deployed.

Cross-Region VPC Peering Lab Workflow

1. Prepare the CloudFormation templates

The course download contains two templates in the Amazon VPC directory:

VPC peering us East one
VPC peering us West one

The templates should be treated as the infrastructure source for the two sides of the lab. Before deployment, update the AMI ID in each template using an AMI available in that template’s target Region:

Locate the latest suitable AMI in EC2 for us-east-1 and update the US East template.
Locate the latest suitable AMI in EC2 for us-west-1 and update the US West template.
Do not reuse the US East AMI ID in the US West template because AMI IDs are Region-specific.

2. Deploy the VPCs and instances

Create a CloudFormation stack with new resources in each Region:

Open CloudFormation in us-east-1.
Choose Upload a template file and select the US East template.
Give the stack a name such as VPC peering lab and submit it with the default settings.
Repeat the process in us-west-1 with the US West template.
Wait for both stacks to reach a completed state before configuring peering.

Each stack creates a VPC, an EC2 instance, security groups, and related networking resources.

3. Identify the VPCs and CIDR blocks

Confirm which VPC was created in each Region and record its CIDR block. In the lab:

Region	VPC CIDR block
`us-east-1`	`10.0.0.0/16`
`us-west-1`	`10.1.0.0/16`

Also confirm the route table and security group associated with each instance. The ICMP rule on each side permits traffic from the other VPC’s CIDR range.

4. Create and accept the peering connection

From the VPC console in US East:

Open Peering connections and choose Create peering connection.
Select the US East VPC as the local VPC and therefore the requester.
Select the option to peer with another VPC.
Choose the same account, select us-west-1, and provide the ID of the US West VPC.
Create the peering request.

Then, in the VPC console in US West:

Open Peering connections.
Select the pending request.
Choose Accept request and confirm.
Refresh the console and verify that the connection status is Active.

The connection must be active before it can be used as a route target.

5. Add routes in both directions

Configure the route table used by the subnets containing the instances. Add a route on each side:

In the US East route table, route 10.1.0.0/16 to the VPC peering connection.
In the US West route table, route 10.0.0.0/16 to the VPC peering connection.

The routes must be bidirectional. A route in only one VPC permits traffic to be sent in one direction but does not establish complete two-way communication.

6. Test private connectivity

Use EC2 Instance Connect to access each instance. From the US East instance, use the private IP address of the US West instance to:

ping <west-private-ip>
curl http://<west-private-ip>

Then reverse the test from US West using the private IP address of the US East instance:

ping <east-private-ip>
curl http://<east-private-ip>

Successful ICMP responses and HTTP responses demonstrate that the peering connection, routes, security-group rules, and instance services are working together.

Exam- or Assessment-Relevant Takeaways

A VPC peering connection does not automatically update route tables. Explicit routes are required on both sides.
For a peering request, distinguish the requester from the accepter. The remote VPC must accept the request.
Cross-Region peering requires selecting the correct remote Region and VPC ID.
Test using private IP addresses to verify private VPC-to-VPC connectivity.
Security groups still apply after peering. Routing can be correct while traffic remains blocked by missing security-group permissions.
AMI IDs are Region-specific, so a CloudFormation template may require a different AMI value in each Region.
The route target for the remote VPC CIDR is the VPC peering connection, not the internet gateway.
A route shown as black hole indicates that its destination or target is no longer available; in this lab, deleting the peering connection leaves a previously dependent route in that state.
When removing lab resources, delete the peering connection before deleting the CloudFormation stacks if the peering dependency could interfere with cleanup.

Tool / Feature Decision Guide

Situation	Appropriate action	Reason
Need private connectivity between two VPCs in separate Regions	Create a cross-Region VPC peering connection	The lab’s requirement is direct private communication between two VPCs using private IP addresses.
A peering request appears in the remote Region	Accept the request there	The connection remains pending until the accepter approves it.
The peering connection is active but instances cannot communicate	Inspect both route tables and security groups	Peering does not automatically create routes, and security groups can still block traffic.
Deploying the same general infrastructure in different Regions	Use the corresponding CloudFormation template and a Region-valid AMI ID	AMI IDs are Region-specific.
Testing network reachability	Use `ping` with the remote instance’s private IP	The lab explicitly validates private ICMP connectivity.
Testing the web service	Use `curl` against the remote private IP	A successful response verifies HTTP reachability and the instance’s web service.
Removing the lab	Delete the peering connection, remove any black-hole route if needed, then delete both CloudFormation stacks	This avoids leaving a peering dependency and allows the stacks to clean up their resources.

Common Traps / Misconceptions

Mistaking an active peering connection for complete connectivity: The connection is only one part of the configuration. Routes and security-group rules are also required.
Adding a route on only one side: Return traffic needs a route back to the originating VPC.
Using the wrong route target: The remote CIDR route must target the VPC peering connection, not the internet gateway.
Using a public IP for the test: The objective is private connectivity, so use the remote instance’s private IP address.
Forgetting the acceptance step: A request created in one Region remains pending until accepted in the other Region.
Reusing an AMI ID across Regions: AMI IDs are Region-specific and may not be valid in the other template’s deployment Region.
Ignoring security groups: The route can be correct while ICMP, SSH, or HTTP is denied by the security group.
Treating a black-hole route as a working path: After the peering connection is deleted, a route that referenced it can show black hole, meaning its destination or target no longer exists.

Real-World Engineer / Analyst Notes

Record the CIDR blocks, Region, VPC ID, route table ID, instance private IP, and peering connection ID before testing. This makes troubleshooting much faster.
Validate the deployment in stages: stack completion, instance availability, peering status, route presence, security-group permissions, and application response.
A failed ping does not by itself prove that peering is broken. Check whether ICMP is permitted and then test an allowed application port such as HTTP.
After deleting a peering connection, inspect both route tables for stale entries. A black-hole route is operational evidence that a previously valid target has been removed.
CloudFormation can remove the infrastructure it created, but networking resources created or modified separately may require explicit cleanup.

Quick Reference Summary

Update each CloudFormation template with an AMI ID valid in its deployment Region.
Deploy the US East and US West stacks.
Confirm the VPC CIDRs: 10.0.0.0/16 and 10.1.0.0/16.
Create the peering request from the local VPC.
Accept the request in the remote Region.
Add 10.1.0.0/16 to the US East route table through the peering connection.
Add 10.0.0.0/16 to the US West route table through the peering connection.
Confirm security groups allow the intended traffic.
Test both directions with ping and curl using private IP addresses.
Delete the peering connection, clean up stale routes if necessary, and delete both CloudFormation stacks.

Flashcards

Q: Two VPCs are in different AWS Regions and the requirement is private IP communication within the same account. Which networking feature should be configured?
A: Configure a cross-Region VPC peering connection. It provides the private connection used by the lab between the two VPCs.

Q: What must happen to a VPC peering request after it is created by the requester?
A: The remote VPC owner or accepter must accept the request in the other Region. Only then can the connection become active.

Q: A peering connection is active, but an instance in 10.0.0.0/16 cannot reach an instance in 10.1.0.0/16. What should be checked first?
A: Check that both route tables contain routes to the opposite CIDR and that each route targets the peering connection. Then verify security-group permissions.

Q: Which route should be added in the US East VPC for the lab’s bidirectional design?
A: Add 10.1.0.0/16 with the VPC peering connection as the target.

Q: Which route should be added in the US West VPC for the lab’s bidirectional design?
A: Add 10.0.0.0/16 with the VPC peering connection as the target.

Q: Why are different AMI IDs needed in the two CloudFormation templates?
A: AMI IDs are Region-specific. An AMI selected in us-east-1 cannot simply be reused as the AMI value for us-west-1.

Q: What is the decisive difference between the requester and accepter in VPC peering?
A: The requester creates the peering request; the accepter must approve it in the remote VPC’s Region.

Q: What does a black hole route indicate after a peering connection is deleted?
A: The route still references a destination or target that no longer exists. It is a stale route and can be removed.

Q: Which IP address type should be used to verify the private connectivity in this lab?
A: Use each EC2 instance’s private IP address. The test is intended to validate private VPC-to-VPC communication.

Q: Which commands were used to test network and application connectivity?
A: Use ping <private-ip> to test ICMP reachability and curl http://<private-ip> to test HTTP access.

Q: What security-group permissions are relevant to the lab’s tests?
A: Port 22 and port 80 are allowed from anywhere in the deployed security groups, while ICMP is allowed from the opposite VPC’s CIDR block.

Q: Why might ping fail even when the route tables are correct?
A: The security group may not allow ICMP from the other VPC’s CIDR block. Correct routing does not override security-group filtering.

Q: What cleanup order is recommended after testing the lab?
A: Delete the VPC peering connection, remove any resulting stale or black-hole route if needed, and then delete the CloudFormation stack in each Region.

Practice Questions

Question 1

An engineer creates a VPC peering connection between a VPC in us-east-1 and a VPC in us-west-1. The connection remains in a pending state. What is the most likely missing step?

A. Add an internet gateway route in both VPCs
B. Accept the peering request in us-west-1
C. Replace both private IP addresses with public IP addresses
D. Recreate the EC2 instances in the requester VPC

Correct answer: B. The remote VPC must accept the request before the peering connection becomes active.

Question 2

The peering connection is active and the security groups allow ICMP from the opposite VPC. Instances still cannot communicate in either direction. Which configuration is most likely missing?

A. A route to the other VPC’s CIDR in each VPC’s route table
B. A second internet gateway in each VPC
C. A public subnet for each instance
D. A new AMI in each Region

Correct answer: A. VPC peering does not automatically add routes. Both route tables need a route to the remote CIDR through the peering connection.

Question 3

You are deploying the US West CloudFormation template, but the stack fails because the AMI ID cannot be found. The AMI ID was copied from the US East deployment. What is the best correction?

A. Use the same AMI ID but change the route table
B. Use the AMI ID of an appropriate image available in us-west-1
C. Remove the AMI reference and use the VPC ID instead
D. Deploy the stack only after accepting a peering request

Correct answer: B. AMI IDs are Region-specific, so the US West template needs an AMI valid in us-west-1.

Question 4

From the US East instance, curl to the US West instance’s private IP succeeds, but ping fails. What is the most direct item to inspect?

A. Whether the peering request was created by US West
B. Whether the VPCs use identical CIDR blocks
C. Whether the US West security group permits ICMP from the US East CIDR
D. Whether the HTTP route uses an internet gateway

Correct answer: C. The lab uses separate security-group rules for ICMP and HTTP, so HTTP success does not prove that ICMP is permitted.

WordPress Metadata

Suggested Slug:
aws-vpc-peering-cross-region-configuration

Meta Description:
A practical AWS CloudOps study guide for creating cross-region VPC peering, updating routes and security groups, testing private connectivity, and cleaning up the lab.

Tags:
AWS, VPC, VPC peering, CloudFormation, EC2, route tables, security groups, cross-region networking, private connectivity, AWS Certified CloudOps Engineer

AWS VPC Peering Across Regions: Configure, Test, and Clean Up