Build Secure AWS VPC Peering

Build and troubleshoot secure AWS VPC peering with private EC2 access.

Introduction

30 Second Summary

Keeping important systems away from the open internet reduces their exposure. It also makes every connection depend on a deliberate path that you can test when something breaks.

In this project, you will build two isolated Amazon VPC networks in Asia Pacific (Mumbai) with one public bastion host providing controlled access to two private Amazon EC2 instances. You will turn a planned connection failure into working VPC peering before documenting the observed results in a sanitized GitHub case study plus a PDF report.

What You'll Build

Your final demo shows Windows reaching both private instances through one bastion after your routing repair converts a planned failure into working private connectivity.

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

  • A secure bastion workflow that lets you open SSH shells on both private instances while they stay off the public internet.
  • Repeatable network tests that show the pre-peering failure, successful ICMP traffic in both directions, one controlled security-rule failure, and recovery.
  • A sanitized portfolio case study that lets you show your architecture, observed terminal results, troubleshooting decisions, and cleanup proof in GitHub plus YourName_EWB_VPC_Peering.pdf.
  • Secret Mission: Replace App-B's bastion /32 SSH rule with a same-Region cross-VPC security-group reference. Prove that private access still works.

Are there any prerequisites?

You need a Windows computer, an AWS account, a GitHub account, and basic AWS networking knowledge. The guide verifies OpenSSH Client for Windows before an account-specific gate blocks resource creation whenever the $0 target is uncertain.

Before We Start

You are building a failure-and-recovery case study around secure VPC peering to prove you can build, troubleshoot, document, and clean up private routing with security controls. The planned pre-peering failure establishes a truthful baseline for sanitized evidence that supports your interview claim.

Prepare Windows and Pass the Cost Gate

The private-host tests later depend on a working OpenSSH Client for Windows. A missing client would block your evidence even if the AWS network were correct.

The live cost gate uses account-specific evidence from AWS Billing and Cost Management before any infrastructure exists. You will also create a GitHub shell that keeps sensitive data out of the public portfolio.

In this step, get ready to:
  • Verify the Windows tools needed for later tests.
  • Pass the live zero-cost gate with sanitized proof.
  • Create the public portfolio shell without sensitive data.
Verify the Windows tools

Windows PowerShell provides the terminal for your later SSH tests. The version check reveals whether the required client is ready.

  • Press the Windows key to open Windows search.
  • Type Windows PowerShell into the search field.
  • Press Enter to open Windows PowerShell.
  • Check whether OpenSSH Client is installed by running this command:
ssh -V

What does this command do?

  • The command asks the installed SSH client to print its version.
  • Output beginning with OpenSSH_ confirms that Windows can run the client.

✔️ I see an OpenSSH_ version

Your SSH client is ready for the bastion tests later in the project.

ⓧ Windows does not recognize ssh

The missing client is a common Windows setup gap. Installing this Windows capability gives PowerShell the SSH command required by the lab.

  • Close the current PowerShell window.
  • Press the Windows key to open Windows search.
  • Type Windows PowerShell into the search field.
  • Open PowerShell as Administrator from the search result.
  • Approve the Windows administrator prompt.
  • Install OpenSSH Client by running this command:
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

What does this command do?

The command adds the built-in OpenSSH Client capability to Windows. Administrator access allows Windows to change this system feature.

  • Confirm the installation by running the version check again:
ssh -V

What should I see?

PowerShell prints a version beginning with OpenSSH_. This confirms that the client is available.

Still unable to run SSH?

Confirm that the installation command ran in PowerShell as Administrator. Restart PowerShell after Windows finishes adding the capability.

If the command remains unavailable, help me troubleshoot the Windows OpenSSH Client installation.

The remaining tools let you access both web accounts. They also let you capture evidence without exposing sensitive details.

  • Press Windows logo key + Shift + S to open Snipping Tool.

You will see the capture overlay. That confirms the evidence tool is available.

  • Press the Windows key to open Windows search.
  • Type Microsoft Edge into the search field.
  • Press Enter to open Microsoft Edge.
  • Sign in to the AWS Management Console in one browser tab.
  • Open a separate browser tab.
  • Sign in to GitHub in the separate tab.

You now have separate authenticated sessions for the account checks and portfolio work.

Create the safe portfolio shell

A public repository makes your evidence easy to review. It also makes careful file boundaries essential.

Your repository starts with a README plus exclusion rules. Every documentation template remains marked Not run until real evidence exists.

  • Switch back to the signed-in GitHub tab.
  • Choose New repository.

GitHub displays the repository creation form.

  • Enter ewb-secure-vpc-peering as the repository name.
  • Choose Public as the visibility.

The form now shows the planned public name and visibility.

  • Select the option to add a README.
  • Click Create repository.

Good progress. Your public portfolio shell now exists with its first rendered page.

The .gitignore records which local files must stay outside the portfolio. This is especially important for private keys and local credentials.

  • Click Add file in the repository toolbar.
  • Click Create new file.

GitHub opens its file editor for the new repository file.

  • Enter .gitignore in the file name field.
  • Add the secret-protecting patterns by pasting this content:
*.pem
*.ppk
*.key
.env
.env.*
.aws/
.ssh/
credentials
*.tfstate
*.tfstate.*
*.rdp

What do these patterns protect?

  • The key extensions identify private-key files that must never be published.
  • The environment and configuration patterns identify local credential locations.
  • The state and remote-desktop patterns cover files that can contain infrastructure details.
  • Click Commit changes.

GitHub opens the commit confirmation dialog.

  • Enter Protect local secrets as the commit message.
  • Click Commit changes in the confirmation dialog.

The repository file list now includes .gitignore.

File not appearing?

Check that the filename begins with a dot. Confirm that the commit completed before returning to the repository file list.

If the file still does not appear, help me check my GitHub .gitignore file.

The cost record begins with every decision unresolved. This prevents the portfolio from claiming a pass before you inspect the live account.

  • Click Add file in the repository toolbar.
  • Click Create new file.

GitHub opens another empty file editor.

  • Enter docs/cost-gate.md in the file name field.
  • Start the cost-gate record by pasting this template:
# Zero-Cost Gate

Status: Not checked

- Applicable Free Tier or sufficient unexpired credits: Not checked.
- EC2 usage headroom for three instance-hours: Not checked.
- Coverage for 24 GiB of gp3 storage: Not checked.
- Coverage for one public IPv4 hour: Not checked.
- Live Asia Pacific (Mumbai) pricing review: Not checked.
- Amazon Linux 2023 marked Free tier eligible: Not checked.
- t3.micro marked Free tier eligible: Not checked.
- Standard CPU credits selected: Not checked.
- Excluded paid services confirmed: Not checked.
- Same-AZ placement confirmed: Not checked.

Why start with Not checked?

Each line represents a separate reason the lab could miss its $0 target. The status changes only after live account evidence supports it.

  • Click Commit changes.

GitHub opens the commit confirmation dialog for the cost-gate template.

  • Enter Add zero-cost gate template as the commit message.
  • Click Commit changes in the confirmation dialog.

The rendered file now shows every gate item as Not checked.

Cost-gate file in the wrong place?

Check that the complete filename is docs/cost-gate.md. GitHub uses the slash to place the file inside the docs folder.

If the path looks different, help me correct the GitHub file location.

The remaining templates reserve a place for later observations. Their initial status stays honest while the infrastructure does not exist.

  • Create docs/resource-inventory.md with Not run. as its entire content by using the same new-file flow.
  • Create docs/test-results.md with Not run. as its entire content by using the same new-file flow.

Both portfolio records now exist without claiming unobserved results.

  • Create docs/troubleshooting.md with Not run. as its entire content by using the same new-file flow.
  • Create docs/viva.md with Not run. as its entire content by using the same new-file flow.

The troubleshooting and interview records are now visible under docs.

  • Create docs/YourName_EWB_VPC_Peering.md with Not run. as its entire content by using the same new-file flow.

Your report template is ready for evidence collected during the later network tests.

Apply the mandatory zero-cost gate

AWS Free Tier benefits vary by account age and remaining credits. Live account evidence decides whether this lab can continue within the $0 target.

This checkpoint is meant to stop a risky launch. Keep the gate unresolved whenever eligibility or coverage is uncertain.

  • Switch back to the signed-in AWS Management Console tab.
  • Open Billing and Cost Management.
  • Confirm that the account has an applicable Free Tier or sufficient unexpired credits.
  • Check the remaining credit balance.
  • Check the credit expiration date.

Stop if coverage is uncertain

Mark the gate FAIL if the account lacks applicable Free Tier coverage or sufficient unexpired credits. Do not create AWS infrastructure for this lab after a failed gate.

  • Open the EC2 Dashboard.
  • Inspect the EC2 Free Tier box when it is available for the account.
  • Stop if the box shows Exceeds Free Tier.
  • Stop if the end-of-month forecast leaves unsafe headroom.
  • Confirm that current usage leaves headroom for three instance-hours.

Why isn't a budget alert enough?

AWS Budgets information can update 8 to 12 hours after the previous update. Additional usage can continue after a threshold is crossed.

The gate reduces cost risk before launch. It does not guarantee a zero bill.

Compute is only one part of the lab's footprint. Storage and the temporary public address need separate coverage checks.

  • Review the account's current EBS usage.
  • Confirm coverage for 24 GiB of additional gp3 root storage.
  • Review the account's current public IPv4 usage.
  • Confirm coverage for one in-use public IPv4 hour.
  • Select Asia Pacific (Mumbai) ap-south-1 in the Region selector.
  • Open the EC2 launch page without launching an instance.
  • Confirm that Amazon Linux 2023 is marked Free tier eligible for this account.
  • Confirm that t3.micro is marked Free tier eligible for this account.

The account-specific labels now establish whether the planned compute choices qualify. The next record captures current Mumbai prices instead of relying on an old screenshot.

  • Record the live Asia Pacific (Mumbai) on-demand compute price shown by AWS: enter the live Mumbai compute price.
  • Record the live Asia Pacific (Mumbai) EBS price shown by AWS: enter the live Mumbai EBS price.
  • Record the live Asia Pacific (Mumbai) public IPv4 price shown by AWS: enter the live Mumbai public IPv4 price.
  • Record the live Asia Pacific (Mumbai) data-transfer price shown by AWS: enter the live Mumbai data transfer price.

A PASS decision also fixes the planned controls before launch. This prevents a later configuration choice from quietly changing the cost boundary.

  • Switch back to the GitHub tab.
  • Open docs/cost-gate.md.

The file still shows the unresolved template created earlier.

  • Select the pencil-shaped edit control above the file.
  • Replace the template with the completed gate record below only when every check passes:
# Zero-Cost Gate

Status: PASS

- Applicable Free Tier or sufficient unexpired credits: PASS.
- EC2 usage headroom for three instance-hours: PASS.
- Coverage for 24 GiB of gp3 storage: PASS.
- Coverage for one public IPv4 hour: PASS.
- Amazon Linux 2023 marked Free tier eligible: PASS.
- t3.micro marked Free tier eligible: PASS.
- Same-AZ placement confirmed: PASS.

## Live Asia Pacific (Mumbai) Pricing

- On-demand compute: [[MUMBAI_COMPUTE_PRICE="enter the live Mumbai compute price"]].
- EBS: [[MUMBAI_EBS_PRICE="enter the live Mumbai EBS price"]].
- Public IPv4: [[MUMBAI_PUBLIC_IPV4_PRICE="enter the live Mumbai public IPv4 price"]].
- Data transfer: [[MUMBAI_DATA_TRANSFER_PRICE="enter the live Mumbai data transfer price"]].

## Planned Cost Controls

- Credit specification: standard.
- Root storage: three 8 GiB gp3 volumes, 24 GiB total.
- Added volumes and snapshots: none.
- Elastic IP, NAT Gateway, Transit Gateway, and paid analysis: excluded.
- AWS infrastructure created during this step: none.

What does this record prove?

  • The status records the decision supported by the live account checks.
  • The pricing section records current Mumbai values from AWS.
  • The control section fixes the launch boundaries used by the next infrastructure step.
  • Click Commit changes.

GitHub opens the commit confirmation dialog for the completed gate.

  • Enter Pass live zero-cost gate as the commit message.
  • Click Commit changes in the confirmation dialog.

The rendered document now shows PASS plus the live Mumbai pricing you recorded.

Unable to mark every item PASS?

Leave unresolved lines as Not checked or mark the gate FAIL. Stop before the EC2 launch step.

If one account value is unclear, help me identify which zero-cost gate evidence is missing.

A sanitized screenshot turns the completed decision into portable evidence. Capturing the rendered document keeps account and payer pages outside the image.

  • Open the rendered docs/cost-gate.md page on GitHub.
  • Press Windows logo key + Shift + S to start a capture.
  • Capture the completed gate status and pricing section.
  • Review the capture for account IDs, payer details, email addresses, public endpoints, local usernames, and private-key paths.

The capture should contain only the sanitized gate record and public pricing values.

  • Create an evidence folder on your Desktop from the Snipping Tool save dialog.
  • Save the capture inside that folder as 00-cost-gate-redacted.png.

Your local evidence folder now contains the sanitized gate image.

  • Return to the root page of ewb-secure-vpc-peering on GitHub.
  • Click Add file.
  • Click Upload files.
  • Drag the local evidence folder into the upload area.

GitHub stages the image under the evidence path.

  • Confirm that the staged path is evidence/00-cost-gate-redacted.png.
  • Click Commit changes to publish the sanitized evidence.

That is the cost boundary secured. Your public repository now contains a live gate decision without exposing the underlying account pages.

✔️ Awesome, I've got everything!

Great. Double-check that every file is committed to ewb-secure-vpc-peering.

ⓧ I'd like to double check the full code

Your final .gitignore should contain these patterns.

*.pem
*.ppk
*.key
.env
.env.*
.aws/
.ssh/
credentials
*.tfstate
*.tfstate.*
*.rdp

What should match?

Compare every pattern with your repository file. Keep each pattern on its own line.

Your completed docs/cost-gate.md should match this structure with your recorded Mumbai prices.

# Zero-Cost Gate

Status: PASS

- Applicable Free Tier or sufficient unexpired credits: PASS.
- EC2 usage headroom for three instance-hours: PASS.
- Coverage for 24 GiB of gp3 storage: PASS.
- Coverage for one public IPv4 hour: PASS.
- Amazon Linux 2023 marked Free tier eligible: PASS.
- t3.micro marked Free tier eligible: PASS.
- Same-AZ placement confirmed: PASS.

## Live Asia Pacific (Mumbai) Pricing

- On-demand compute: [[MUMBAI_COMPUTE_PRICE="enter the live Mumbai compute price"]].
- EBS: [[MUMBAI_EBS_PRICE="enter the live Mumbai EBS price"]].
- Public IPv4: [[MUMBAI_PUBLIC_IPV4_PRICE="enter the live Mumbai public IPv4 price"]].
- Data transfer: [[MUMBAI_DATA_TRANSFER_PRICE="enter the live Mumbai data transfer price"]].

## Planned Cost Controls

- Credit specification: standard.
- Root storage: three 8 GiB gp3 volumes, 24 GiB total.
- Added volumes and snapshots: none.
- Elastic IP, NAT Gateway, Transit Gateway, and paid analysis: excluded.
- AWS infrastructure created during this step: none.

What should the final gate contain?

The file needs the account eligibility decision and current Mumbai pricing. It also needs the planned cost controls.

  • The repository visibility is Public.
  • The repository contains a README.
  • The file docs/resource-inventory.md contains Not run.
  • The file docs/test-results.md contains Not run.
  • The file docs/troubleshooting.md contains Not run.
  • The file docs/viva.md contains Not run.
  • The file docs/YourName_EWB_VPC_Peering.md contains Not run.
  • The sanitized image exists at evidence/00-cost-gate-redacted.png.

Before you run the final check, do you expect PowerShell to report the same SSH client version you verified earlier?

  • Return to Windows PowerShell from earlier.
  • Verify the SSH client one final time by running this command:
ssh -V

What does the final check prove?

The command confirms that OpenSSH Client remains available after setup. Output beginning with OpenSSH_ is the required success signal.

You will see an OpenSSH_ version in PowerShell.

  • Return to the public ewb-secure-vpc-peering repository.
  • Open docs/cost-gate.md to confirm the status is PASS.
  • Open evidence/00-cost-gate-redacted.png to confirm the image is sanitized.
  • Confirm that no AWS infrastructure appears in the account for this lab.

Your workstation, live cost evidence, and public portfolio shell are ready. Next, you will build the two-VPC network foundation inside the limits you just proved.

Build the Two-VPC Network Foundation

Your zero-cost gate is complete. The AWS Management Console is ready for a network that stays inside the approved plan.

Private instances cannot demonstrate VPC peering until every subnet has an explicit address range. Each subnet also needs the correct route table association to define its public or private boundary.

In this step, get ready to:
  • Create two VPCs with three subnets in ap-south-1a.
  • Attach one internet gateway to the Alpha VPC.
  • Associate three custom route tables before recording sanitized evidence in GitHub.
Create the VPCs and subnets

An Amazon VPC provides an isolated address space. Non-overlapping CIDR blocks give AWS an unambiguous destination when peering routes are added later.

  • Switch back to the AWS Management Console from earlier.
  • Select the Region menu in the top navigation bar.
  • Choose Asia Pacific (Mumbai) ap-south-1.

The console header now shows Asia Pacific (Mumbai). Every network resource in this lab stays in that Region.

  • Enter VPC in the console search bar.
  • Select VPC from the search results.
  • Select Your VPCs in the VPC navigation panel.
  • Click Create VPC.
  • Choose VPC only.

The VPC form now shows the address and tenancy settings for the first isolated network.

  • Enter ewb-alpha-vpc as the VPC name.
  • Choose manual IPv4 CIDR entry.
  • Enter 10.10.0.0/16 as the IPv4 CIDR.

The form now identifies the Alpha network with its planned private address range.

  • Leave IPv6 disabled.
  • Set tenancy to Default.

The summary now shows an IPv4-only VPC with default tenancy.

  • Click Create VPC.

Good start. The VPC list now contains ewb-alpha-vpc with CIDR 10.10.0.0/16.

  • Return to Your VPCs.
  • Click Create VPC.
  • Choose VPC only.
  • Enter ewb-beta-vpc as the VPC name.
  • Choose manual IPv4 CIDR entry.
  • Enter 10.20.0.0/16 as the IPv4 CIDR.

The Beta CIDR starts with 10.20. It does not overlap the Alpha range that starts with 10.10.

  • Leave IPv6 disabled.
  • Set tenancy to Default.

The second summary now shows an IPv4-only VPC with default tenancy.

  • Click Create VPC.

You should now see ewb-alpha-vpc beside ewb-beta-vpc. Their non-overlapping CIDRs make them eligible for the peering relationship built later.

Why use one Availability Zone?

Keeping all three subnets in ap-south-1a keeps this lab focused on peering paths. Same-AZ peering data transfer is documented as free.

A production design would usually spread workloads across multiple Availability Zones for resilience.

Can't select the planned zone?

If ap-south-1a is unavailable in your account, stop here. The complete plan requires all three subnets in the same Availability Zone.

  • Select Subnets in the VPC navigation panel.
  • Click Create subnet.
  • Choose ewb-alpha-vpc in the VPC selector.
  • Enter ewb-alpha-public-subnet-a as the subnet name.

The form now places the public subnet inside the Alpha VPC.

  • Choose ap-south-1a as the Availability Zone.
  • Enter 10.10.1.0/24 as the IPv4 subnet CIDR.

The subnet form now shows the planned zone and a CIDR contained within 10.10.0.0/16.

  • Click Create subnet.

The subnet list now contains ewb-alpha-public-subnet-a in ap-south-1a.

  • Click Create subnet.
  • Choose ewb-alpha-vpc in the VPC selector.
  • Enter ewb-alpha-private-subnet-a as the subnet name.

The second subnet form now points to the Alpha VPC.

  • Choose ap-south-1a as the Availability Zone.
  • Enter 10.10.2.0/24 as the IPv4 subnet CIDR.

The private Alpha subnet has its own range inside the Alpha VPC.

  • Click Create subnet.

The subnet list now shows two separate Alpha subnets in ap-south-1a.

  • Click Create subnet.
  • Choose ewb-beta-vpc in the VPC selector.
  • Enter ewb-beta-private-subnet-a as the subnet name.

The final subnet form now points to the Beta VPC.

  • Choose ap-south-1a as the Availability Zone.
  • Enter 10.20.1.0/24 as the IPv4 subnet CIDR.

The Beta subnet range sits inside 10.20.0.0/16.

  • Click Create subnet.

The subnet list now shows all three planned subnets in ap-south-1a.

Subnet creation not completing?

Check that each subnet CIDR belongs to its selected VPC. Confirm that the three subnet CIDRs do not overlap.

Verify that the console header still shows Asia Pacific (Mumbai). Help me diagnose my VPC or subnet settings.

Create the internet gateway and route tables

An internet gateway gives a subnet a direct path to the internet when its associated route table points 0.0.0.0/0 to that gateway. Only the Alpha public subnet receives that path.

  • Select Internet gateways in the VPC navigation panel.
  • Click Create internet gateway.
  • Enter ewb-alpha-igw as the name.
  • Click Create internet gateway.

The gateway now exists in a detached state. It needs one deliberate attachment to become part of the Alpha boundary.

  • Select ewb-alpha-igw.
  • Open the Actions menu.
  • Choose Attach to a VPC.
  • Select ewb-alpha-vpc.
  • Click the attachment confirmation control.

The gateway state now shows that ewb-alpha-igw is attached to ewb-alpha-vpc.

  • Select Route tables in the VPC navigation panel.
  • Click Create route table.
  • Enter ewb-alpha-public-rt as the name.
  • Choose ewb-alpha-vpc as the VPC.
  • Click Create route table.

The route table now contains the automatic 10.10.0.0/16 local route for traffic inside the Alpha VPC.

  • Return to the route table list.
  • Click Create route table.
  • Enter ewb-alpha-private-rt as the name.
  • Choose ewb-alpha-vpc as the VPC.
  • Click Create route table.

The private Alpha route table now exists with only its automatic local route.

  • Return to the route table list.
  • Click Create route table.
  • Enter ewb-beta-private-rt as the name.
  • Choose ewb-beta-vpc as the VPC.
  • Click Create route table.

The Beta route table now contains the automatic 10.20.0.0/16 local route.

What do the local routes do?

AWS creates a local route in every custom route table. That route supports communication inside its own VPC CIDR.

A local route cannot reach the other VPC. The peer routes arrive only after the peering connection becomes active.

  • Return to the route table list.
  • Select ewb-alpha-public-rt.
  • Open the Actions menu.
  • Choose Edit routes.
  • Click Add route.
  • Enter 0.0.0.0/0 as the destination.
  • Choose ewb-alpha-igw as the target.
  • Click Save changes.

The Alpha public route table now shows 0.0.0.0/0 targeting ewb-alpha-igw.

Why do the private tables have no default route?

A subnet becomes public when its route table has a direct route to an internet gateway. Leaving both private tables without 0.0.0.0/0 preserves the intended boundary.

Gateway missing from the target list?

Confirm that ewb-alpha-igw is attached to ewb-alpha-vpc. Confirm that ewb-alpha-public-rt also belongs to the Alpha VPC.

A resource from another VPC cannot serve as this route target. Help me diagnose the missing internet gateway target.

Associate the route tables and capture evidence

An explicit subnet association removes ambiguity about which routes govern each instance. This is crucial because every forward packet and reply packet follows the route table associated with its subnet.

  • Return to the route table list.
  • Select ewb-alpha-public-rt.
  • Open Subnet associations.
  • Click Edit subnet associations.
  • Select only ewb-alpha-public-subnet-a.
  • Click Save associations.

The explicit association now links the Alpha public subnet to the only table with an internet gateway route.

  • Return to the route table list.
  • Select ewb-alpha-private-rt.
  • Open Subnet associations.
  • Click Edit subnet associations.
  • Select only ewb-alpha-private-subnet-a.
  • Click Save associations.

The Alpha private subnet now uses a table with no internet default route.

  • Return to the route table list.
  • Select ewb-beta-private-rt.
  • Open Subnet associations.
  • Click Edit subnet associations.
  • Select only ewb-beta-private-subnet-a.
  • Click Save associations.

The Beta private subnet now has its own explicit route-table association.

Before you inspect each subnet, predict which one should show the internet gateway route.

  • Select Subnets in the VPC navigation panel.
  • Select ewb-alpha-public-subnet-a.
  • Open its Route table tab.

You should see ewb-alpha-public-rt with the local route and 0.0.0.0/0 targeting ewb-alpha-igw.

  • Select ewb-alpha-private-subnet-a.
  • Open its Route table tab.

You should see ewb-alpha-private-rt with only the automatic 10.10.0.0/16 local route.

  • Select ewb-beta-private-subnet-a.
  • Open its Route table tab.

You should see ewb-beta-private-rt with only the automatic 10.20.0.0/16 local route. No peering connection or peer route exists yet.

Association does not match the plan?

Return to the mismatched custom route table. Edit its subnet associations so only the planned subnet is selected.

Check the VPC column before saving because Alpha and Beta tables have different local routes. Help me repair my route-table associations.

The checks have proved the network state. Capture that state before peering changes the route tables.

  • Return to the Subnets list.
  • Filter the subnet list with ewb-.
  • Use the table settings control to show each subnet name.
  • Use the table settings control to show each VPC name.
  • Use the table settings control to show each IPv4 CIDR.
  • Use the table settings control to show the Availability Zone.

The filtered table should show two VPC names across three subnet rows. Every row should show ap-south-1a.

  • Press Windows logo key + Shift + S to open Snipping Tool.
  • Capture the filtered subnet table.
  • Crop out any account details.
  • Review the capture for sensitive information.
  • Save the sanitized capture as 01-network-inventory.png.
  • Return to the Route tables list.
  • Filter the route table list with ewb-.
  • Use the table settings control to show explicit subnet associations.
  • Select ewb-alpha-public-rt.
  • Open its Routes tab.

The three custom table rows should remain visible above the selected public table's routes. The selected table should show the internet gateway route.

  • Press Windows logo key + Shift + S to open Snipping Tool.
  • Frame the capture around the filtered route-table rows and selected route details.
  • Crop out any account details.
  • Review the capture for sensitive information.
  • Save the sanitized capture as 02-routes-before-peering.png.

What belongs in the inventory?

  • Record both VPC names with their IPv4 CIDRs.
  • Record all three subnet names with their CIDRs and ap-south-1a placement.
  • Record ewb-alpha-igw as attached only to ewb-alpha-vpc.
  • Record each custom route table with its explicit subnet association and current routes.
  • Record sanitized AWS-generated resource IDs without publishing account identifiers.
  • Switch back to the ewb-secure-vpc-peering repository from earlier.
  • Select the docs folder.
  • Select resource-inventory.md.
  • Select the file editing control.
  • Replace the planned network section with the observed inventory described above.
  • Add the sanitized AWS-generated resource IDs beside their matching resources.
  • Use the file editor's preview control to inspect the rendered inventory.

The preview should show both VPCs and all three subnets. It should also show the gateway and exact route-table associations.

  • Enter Document pre-peering network foundation as the commit message.
  • Save the inventory update to the repository.
  • Return to the repository's evidence folder.
  • Click Add file.
  • Select Upload files.
  • Choose 01-network-inventory.png from its saved location.
  • Choose 02-routes-before-peering.png from its saved location.
  • Save the evidence upload to the repository.

The repository now shows both sanitized evidence files under evidence. The resource inventory records the exact pre-peering network state.

Strong work. Your public and private boundaries are now explicit before any compute exists. Next, you will secure and launch the bastion plus both private instances.

Secure and Launch the EC2 Instances

Your Amazon VPC foundation now separates the public bastion subnet from both private application subnets. Your sanitized GitHub inventory records those boundaries.

The lab now needs real Amazon EC2 endpoints for the isolation test. Only the bastion host receives a public IPv4 address. Exact security groups protect the private instances. T3 Standard mode also keeps surplus CPU credit charges outside the plan.

In this step, get ready to:
  • Create the RSA key pair with restricted local permissions.
  • Apply exact SSH and ICMP rules to three security groups.
  • Launch three instances with the planned addresses and cost controls.
Create the key pair and security groups

An RSA key pair lets OpenSSH prove that you hold the matching private key. AWS downloads that private key only once.

This file grants access to the instances. Keep it on your Windows computer with permissions limited to your current user.

  • Return to the EC2 dashboard in the AWS Management Console from earlier.
  • Select Key Pairs from the EC2 navigation panel.
  • Click Create key pair.
  • Enter ewb-vpc-peering-key in the Name field.
  • Select RSA as the key pair type.
  • Select .pem as the private key file format.
  • Click Create key pair.

Good progress. Your browser has downloaded the only copy of the private key that AWS provides.

  • Press the Windows key to open Windows search.
  • Type File Explorer and press Enter.
  • Select your Downloads folder in File Explorer.
  • Cut ewb-vpc-peering-key.pem from the Downloads folder.
  • Navigate to %USERPROFILE%\.ssh by entering the path in the File Explorer address bar.
  • Paste ewb-vpc-peering-key.pem into the .ssh folder.
  • Confirm the full local path is %USERPROFILE%\.ssh\ewb-vpc-peering-key.pem.

The key now sits in the location that your later SSH configuration uses.

  • Right-click ewb-vpc-peering-key.pem in File Explorer.
  • Select Properties.
  • Select the Security tab.
  • Click Advanced.
  • Click Disable inheritance.
  • Keep the inherited entries available for editing if Windows asks how to handle them.
  • Remove access for every principal except your current Windows user.

The permissions list should now contain only your current Windows user.

  • Click Apply to save the permission changes.
  • Click OK to close each permissions window.

Can't restrict the key file?

Confirm that the file is stored at %USERPROFILE%\.ssh\ewb-vpc-peering-key.pem. Your current Windows user must remain in the permissions list.

Never upload the file to GitHub while troubleshooting. Help me secure my EC2 private key on Windows.

Inbound security-group rules decide which sources can initiate traffic to each instance. The peer ICMP rules can exist before peering because they do not create a network route.

  • Switch back to the AWS Management Console from earlier.
  • Select VPC using the console search bar.
  • Select Security groups from the VPC navigation panel.
  • Click Create security group.
  • Enter ewb-bastion-sg as the security group name.
  • Enter ewb-bastion-sg as the description.
  • Select ewb-alpha-vpc as the VPC.

The form now anchors this security group to VPC Alpha.

  • Click Add rule under inbound rules.
  • Select SSH as the inbound type.
  • Select My IP as the source.
  • Confirm the resolved source ends in /32.
  • Record the resolved value in a private note as your current public IPv4 /32.
  • Confirm the outbound rule remains All traffic to 0.0.0.0/0.
  • Click Create security group.

The bastion security group now limits public SSH to your current client address.

  • Click Create security group again.
  • Enter ewb-app-a-sg as the security group name.
  • Enter ewb-app-a-sg as the description.
  • Select ewb-alpha-vpc as the VPC.
  • Click Add rule under inbound rules.
  • Select SSH as the first inbound type.
  • Select ewb-bastion-sg as the first rule's source.

The first App-A rule permits SSH from network interfaces associated with the bastion security group.

  • Click Add rule to create the second inbound rule.
  • Select Custom ICMP - IPv4 as the second inbound type.
  • Select Echo request as the ICMP type.
  • Enter 10.20.1.10/32 as the second rule's source.
  • Confirm the outbound rule remains All traffic to 0.0.0.0/0.
  • Click Create security group.

App-A now accepts administration from the bastion. It also accepts reverse ping requests from App-B's fixed private address.

  • Click Create security group again.
  • Enter ewb-app-b-sg as the security group name.
  • Enter ewb-app-b-sg as the description.
  • Select ewb-beta-vpc as the VPC.
  • Click Add rule under inbound rules.
  • Select SSH as the first inbound type.
  • Enter 10.10.1.10/32 as the first rule's source.

The first App-B rule restricts SSH to the bastion's fixed private address.

  • Click Add rule to create the second inbound rule.
  • Select Custom ICMP - IPv4 as the second inbound type.
  • Select Echo request as the ICMP type.
  • Enter 10.10.2.10/32 as the second rule's source.
  • Confirm the outbound rule remains All traffic to 0.0.0.0/0.
  • Click Create security group.

All three security groups now enforce the planned protocol boundaries. None of the rules creates connectivity between the VPCs.

Don't see the expected security-group source?

Confirm that ewb-app-a-sg and ewb-bastion-sg both belong to ewb-alpha-vpc. A security group in another VPC does not appear in the same-VPC source selector.

For App-B's baseline SSH rule, enter 10.10.1.10/32 as the source CIDR. Help me compare my three security groups with the planned rules.

Launch the three instances

Launching these instances starts metered AWS resources. Your completed cost gate supports this exact plan. Stop if either Free tier eligible label is missing.

Why choose Standard mode?

T3 instances launch in unlimited mode by default. Surplus CPU credits in that mode can add charges.

Selecting standard limits bursting to earned CPU credits. This keeps the launch aligned with your recorded cost controls.

  • Switch back to the EC2 dashboard from earlier.
  • Click Launch instance.
  • Enter ewb-bastion as the instance name.
  • Choose Amazon Linux 2023 AMI with the x86_64 architecture from Amazon.
  • Confirm the AMI shows Free tier eligible.
  • Choose t3.micro as the instance type.
  • Confirm the instance type shows Free tier eligible.
  • Select ewb-vpc-peering-key as the key pair.

The bastion's image and compute choices now match the cost-gated plan.

  • Select ewb-alpha-vpc under Network settings.
  • Select ewb-alpha-public-subnet-a as the subnet.
  • Select ewb-bastion-sg as the existing security group.
  • Select Enable for Auto-assign public IP.
  • Expand Advanced network configuration.
  • Enter 10.10.1.10 as the Primary IP.

The bastion now has a fixed private address in the public Alpha subnet. The launch also requests one temporary public IPv4 address.

  • Set the root volume size to 8 GiB under Configure storage.
  • Select gp3 as the Amazon EBS volume type.
  • Set Delete on termination to Yes.
  • Confirm no additional volumes are listed.
  • Confirm no snapshots are selected.
  • Expand Advanced details.
  • Set Credit specification to standard.
  • Click Launch instance.

AWS confirms the bastion launch request. Its public endpoint provides the only internet entry point in the lab.

  • Click Launch instance from the EC2 dashboard.
  • Enter ewb-app-a as the instance name.
  • Choose Amazon Linux 2023 AMI with the x86_64 architecture from Amazon.
  • Confirm the AMI shows Free tier eligible.
  • Choose t3.micro as the instance type.
  • Confirm the instance type shows Free tier eligible.
  • Select ewb-vpc-peering-key as the key pair.

App-A now shares the approved image and compute settings with the bastion.

  • Select ewb-alpha-vpc under Network settings.
  • Select ewb-alpha-private-subnet-a as the subnet.
  • Select ewb-app-a-sg as the existing security group.
  • Select Disable for Auto-assign public IP.
  • Expand Advanced network configuration.
  • Enter 10.10.2.10 as the Primary IP.

App-A now sits on the private Alpha subnet without a public endpoint.

  • Set the root volume size to 8 GiB under Configure storage.
  • Select gp3 as the volume type.
  • Set Delete on termination to Yes.
  • Confirm no additional volumes are listed.
  • Confirm no snapshots are selected.
  • Expand Advanced details.
  • Set Credit specification to standard.
  • Click Launch instance.

AWS confirms the App-A launch request. The instance remains reachable only through private network paths.

  • Click Launch instance from the EC2 dashboard.
  • Enter ewb-app-b as the instance name.
  • Choose Amazon Linux 2023 AMI with the x86_64 architecture from Amazon.
  • Confirm the AMI shows Free tier eligible.
  • Choose t3.micro as the instance type.
  • Confirm the instance type shows Free tier eligible.
  • Select ewb-vpc-peering-key as the key pair.

App-B uses the same approved image and compute settings in VPC Beta.

  • Select ewb-beta-vpc under Network settings.
  • Select ewb-beta-private-subnet-a as the subnet.
  • Select ewb-app-b-sg as the existing security group.
  • Select Disable for Auto-assign public IP.
  • Expand Advanced network configuration.
  • Enter 10.20.1.10 as the Primary IP.

App-B now sits on the private Beta subnet without a public endpoint.

  • Set the root volume size to 8 GiB under Configure storage.
  • Select gp3 as the volume type.
  • Set Delete on termination to Yes.
  • Confirm no additional volumes are listed.
  • Confirm no snapshots are selected.
  • Expand Advanced details.
  • Set Credit specification to standard.
  • Click Launch instance.

AWS confirms the App-B launch request. All three planned compute endpoints now exist.

Launch request not completing?

Confirm that the chosen private address belongs to the selected subnet. Check that each instance uses the security group created in the same VPC.

Stop if the AMI or t3.micro no longer shows Free tier eligible. Help me diagnose my EC2 launch configuration.

Verify inventory and capture evidence

EC2 status checks confirm that AWS can reach each instance at the infrastructure level. These checks can take several minutes while the instances initialize.

  • Select Instances from the EC2 navigation panel.
  • Wait for ewb-bastion to show the running state.
  • Wait for ewb-app-a to show the running state.
  • Wait for ewb-app-b to show the running state.
  • Wait for every instance to show 2/2 status checks.
  • Select ewb-bastion in the instance table.
  • Open the Networking tab.
  • Confirm the private IPv4 address is 10.10.1.10.

The bastion has passed its checks with the fixed Alpha address.

  • Confirm the bastion has a public IPv4 address.
  • Open the Storage tab.
  • Confirm the root volume is 8 GiB with type gp3.
  • Confirm Delete on termination shows Yes.
  • Open the Details tab.
  • Confirm Credit specification shows standard.

The bastion is ready as the lab's only public entry point.

  • Select ewb-app-a in the instance table.
  • Open the Networking tab.
  • Confirm the private IPv4 address is 10.10.2.10.
  • Confirm no public IPv4 address is listed.
  • Open the Storage tab.
  • Confirm the root volume is 8 GiB with type gp3.
  • Confirm Delete on termination shows Yes.
  • Confirm Credit specification shows standard on the Details tab.

App-A has passed its checks without exposing a public endpoint.

  • Select ewb-app-b in the instance table.
  • Open the Networking tab.
  • Confirm the private IPv4 address is 10.20.1.10.
  • Confirm no public IPv4 address is listed.
  • Open the Storage tab.
  • Confirm the root volume is 8 GiB with type gp3.
  • Confirm Delete on termination shows Yes.
  • Confirm Credit specification shows standard on the Details tab.

Before the final inventory check, which instance do you expect to be the only one with a public IPv4 address?

  • Return to the EC2 instance table.
  • Compare the state and status checks across all three rows.
  • Compare the private IPv4 addresses across all three rows.
  • Compare the public IPv4 field across all three rows.

You should see all three instances in the running state with 2/2 checks. Only ewb-bastion has a public IPv4 address.

Still waiting for status checks?

Give the instances several minutes to initialize. Refresh the instance table before changing any configuration.

If a check remains failed, inspect the affected instance's status-check details. Help me troubleshoot an EC2 instance that is not reaching 2/2 status checks.

Sanitize before publishing

Hide the AWS account ID and every public IPv4 address before uploading evidence. Hide email addresses and local Windows usernames as well.

Never capture the private-key contents or its full local path. Keep the private RFC1918 addresses and planned resource names visible as evidence.

  • Use Snipping Tool from earlier to capture the EC2 inventory table.
  • Redact the bastion public IPv4 address from the capture.
  • Redact all account information from the capture.
  • Save the sanitized image as 03-ec2-inventory-redacted.png.
  • Return to Security groups in the VPC console.
  • Review the inbound rules for all three lab security groups.
  • Use Snipping Tool to capture the exact inbound rules.
  • Redact your public IPv4 source from the capture.

The sanitized captures preserve the architecture proof without publishing your current public endpoint.

  • Redact all account information from the security-group capture.
  • Save the sanitized image as 04-security-groups.png.
  • Return to the ewb-secure-vpc-peering repository from earlier.
  • Use GitHub's web editor to update docs/resource-inventory.md with the three instance names.
  • Add the three planned private IPv4 addresses to docs/resource-inventory.md.
  • Add the sanitized security-group identifiers to docs/resource-inventory.md.
  • Commit the updated inventory through the GitHub web interface.

Your resource inventory now matches the deployed compute layer.

  • Select the existing evidence folder in the repository.
  • Click Add file.
  • Click Upload files.
  • Upload 03-ec2-inventory-redacted.png.
  • Upload 04-security-groups.png.
  • Commit the sanitized evidence through the GitHub web interface.
  • Open each uploaded image to confirm the planned private addresses and rules remain readable.
  • Confirm neither uploaded image exposes account details or the bastion public IPv4 address.

That's the compute layer secured. Your bastion is the only public entry point. Next, you will use it to prove that the two private VPCs remain isolated before peering.

Prove Isolation Through the Bastion

The three Amazon EC2 instances from the last step give you real endpoints for testing. Your Windows SSH client now needs a controlled path to the private App-A instance.

Separate Amazon VPC networks have no route between them yet. This step records that missing path before peering changes the result.

In this step, get ready to:
  • Configure local ProxyJump aliases for the bastion and both private instances.
  • Open an interactive App-A shell through the bastion.
  • Run the pre-peering test and record its observed result.
Create the Windows ProxyJump configuration

The local config gives OpenSSH a short alias for each instance. The ProxyJump setting sends private-host connections through the public bastion.

The private key stays on your Windows computer. Keep the config outside your public GitHub repository because it contains your public endpoint and local username.

  • Return to the AWS Management Console from earlier.
  • In Amazon EC2, select Instances from the navigation pane.
  • Select ewb-bastion from the instance list.
  • Record the temporary public IPv4 shown for the instance here: your bastion public IPv4 address.

You now have the public endpoint that your Windows client uses for the first connection stage.

  • Press the Windows key to open the search bar.
  • Type File Explorer into the search bar.
  • Press Enter to open File Explorer.
  • Paste %USERPROFILE% into the File Explorer address bar.
  • Press Enter to display your Windows user folder.
  • Record the final folder name from the displayed path here: your Windows username.

These two values personalize the local host definitions. The remaining settings use the private addresses and key file established earlier.

  • Paste %USERPROFILE%\.ssh into the File Explorer address bar.
  • Press Enter to display your local SSH folder.
  • Use a Windows text editor to create %USERPROFILE%\.ssh\config as a file with no extension.
  • Add the three host definitions by pasting this configuration:
Host ewb-bastion
    HostName BASTION_PUBLIC_IPV4
    User ec2-user
    IdentityFile C:/Users/WINDOWS_USERNAME/.ssh/ewb-vpc-peering-key.pem
    IdentitiesOnly yes

Host ewb-app-a
    HostName 10.10.2.10
    User ec2-user
    IdentityFile C:/Users/WINDOWS_USERNAME/.ssh/ewb-vpc-peering-key.pem
    IdentitiesOnly yes
    ProxyJump ewb-bastion

Host ewb-app-b
    HostName 10.20.1.10
    User ec2-user
    IdentityFile C:/Users/WINDOWS_USERNAME/.ssh/ewb-vpc-peering-key.pem
    IdentitiesOnly yes
    ProxyJump ewb-bastion

What does this configuration do?

  • The ewb-bastion alias points to the bastion's temporary public address.
  • The ewb-app-a alias points to App-A's private address.
  • The ewb-app-b alias points to App-B's private address for later tests.
  • The IdentityFile setting selects your local private key.
  • The IdentitiesOnly yes setting limits authentication to that configured identity.
  • The ProxyJump ewb-bastion setting makes the SSH client connect through the bastion before opening a private-host session.

Your editor now shows three separate Host sections. App-A and App-B both use the bastion as their jump host.

  • Replace BASTION_PUBLIC_IPV4 with your bastion public IPv4 address.

The bastion's HostName line now contains the temporary public IPv4 from Amazon EC2.

  • Replace both occurrences of WINDOWS_USERNAME with your Windows username.
  • Save %USERPROFILE%\.ssh\config.
  • Confirm the extensionless config file appears inside %USERPROFILE%\.ssh.

Config file not being detected?

Check that the file is named config without a hidden .txt extension. Confirm that each uppercase placeholder has been replaced.

Keep the file inside %USERPROFILE%\.ssh. Help me check why OpenSSH is not reading my Windows config file.

✔️ Awesome, I've got everything!

Your local config now defines the bastion and both private-host aliases. Confirm that the personalized file remains outside your GitHub repository.

ⓧ I'd like to double check the full code

Host ewb-bastion
    HostName BASTION_PUBLIC_IPV4
    User ec2-user
    IdentityFile C:/Users/WINDOWS_USERNAME/.ssh/ewb-vpc-peering-key.pem
    IdentitiesOnly yes

Host ewb-app-a
    HostName 10.10.2.10
    User ec2-user
    IdentityFile C:/Users/WINDOWS_USERNAME/.ssh/ewb-vpc-peering-key.pem
    IdentitiesOnly yes
    ProxyJump ewb-bastion

Host ewb-app-b
    HostName 10.20.1.10
    User ec2-user
    IdentityFile C:/Users/WINDOWS_USERNAME/.ssh/ewb-vpc-peering-key.pem
    IdentitiesOnly yes
    ProxyJump ewb-bastion
Connect to App-A through the bastion

App-A has no public IPv4 address. Its host alias uses the bastion as the controlled entry point into Alpha's private subnet.

  • Press the Windows key to open the search bar.
  • Type Windows PowerShell into the search bar.
  • Press Enter to open Windows PowerShell.

The first connection can display a host-key prompt. Review the presented host key before accepting it.

  • Connect to App-A through the configured bastion by running this command:
ssh ewb-app-a

What does this command do?

  • The SSH client finds the ewb-app-a alias in your local config.
  • The client opens its first connection to ewb-bastion.
  • The bastion forwards the connection to App-A at 10.10.2.10.
  • The same local private key authenticates both connection stages.

You'll see an interactive ec2-user shell on App-A. That's the first hard part done: your Windows client can administer a private instance through the bastion.

App-A connection not opening?

For a timeout, check the bastion public IPv4 in your local config. Confirm that ewb-alpha-public-rt still sends 0.0.0.0/0 to ewb-alpha-igw.

Confirm that the bastion's SSH rule still uses your current public IPv4 /32.

For Permission denied (publickey), check ec2-user and the selected key pair. Confirm the IdentityFile path and Windows key-file permissions.

Help me troubleshoot this App-A ProxyJump connection.

Capture the required pre-peering failure

The App-A shell gives you a private source for the cross-VPC test. App-B's private address is the destination inside Beta.

Before you run this, predict whether App-A can reach App-B with no peering connection or peer route.

  • Test the current path from the App-A shell by running this command:
ping -c 4 10.20.1.10

What does this command test?

  • The ping command sends ICMP Echo requests from App-A.
  • The -c 4 option stops the test after four requests.
  • The address 10.20.1.10 targets App-B inside the Beta VPC.

The test receives no replies. Your output may mention an unreachable network or show complete packet loss.

That planned failure is your required baseline. The network is behaving exactly like its current route tables allow.

The associated ewb-alpha-private-rt has no route for 10.20.0.0/16. No peering target exists for that destination.

Getting replies before peering?

  • Confirm that your current shell belongs to ewb-app-a.
  • Confirm that the destination is exactly 10.20.1.10.
  • Return to ewb-alpha-private-rt from earlier to confirm that it has no Beta route.
  • Stop before recording the baseline if an unexpected cross-VPC path exists.

Help me investigate unexpected pre-peering ping replies.

  • Press Windows logo key + Shift + S to open the Snipping Tool capture overlay.
  • Select the terminal area containing the command and its complete observed output.
  • Choose Save as in Snipping Tool.
  • Enter 05-pre-peering-failure.png as the file name.
  • Review the saved image for sensitive information.
  • Redact any public IPv4 address before publication.
  • Redact any local Windows username before publication.

Publish Only Sanitized Evidence

Keep the command and actual failed output visible. Exclude account identifiers and full private-key paths from the final image.

Private addresses and the planned resource names can remain visible. Never capture private-key contents.

  • Return to the App-A terminal.
  • Select the complete command and its actual output.
  • Copy the selected terminal text.

Your clipboard now holds the observed result. This preserves the real output instead of replacing it with an expected example.

  • Return to the ewb-secure-vpc-peering repository from earlier.
  • Open docs/test-results.md.
  • Paste the copied command and output into the baseline entry.
  • Record the observed result as the required failed baseline.
  • Add the missing route for 10.20.0.0/16 as the explanation.
  • Save the update in GitHub.

What does this baseline prove?

Running instances and permissive outbound rules do not create a path between separate VPCs. Your actual output proves that the cross-VPC route is absent before peering.

Keep every later test marked Not run until you execute its command and observe its result.

  • Open the evidence folder in the repository.
  • Click Add file.
  • Click Upload files.
  • Select the sanitized 05-pre-peering-failure.png file.
  • Save the upload in GitHub.

You now have a working bastion path plus an observed cross-VPC failure. The repository records the baseline without claiming an untested success.

Your bastion path works while the cross-VPC path remains absent. Next, you'll activate peering and add the explicit forward and return routes.

Peer, Test, and Document the Lab

The failed baseline proved that App-A has no path to App-B. The next move repairs that gap with an explicit private connection.

An Amazon VPC peering relationship connects the two networks. Route tables carry packets in both directions. Security groups decide which protocols may enter.

A controlled ICMP failure will show how one security rule can interrupt ping while private administration remains available. The portfolio will connect every final claim to observed evidence.

In this step, get ready to:
  • Activate the peering connection.
  • Prove private connectivity through a controlled test cycle.
  • Publish the sanitized portfolio evidence.
Activate peering and install the routes

An active peering connection authorizes the relationship between the VPCs. Each participating subnet still needs an explicit route through that connection.

  • Return to the Amazon VPC console from earlier.
  • Choose Peering connections from the VPC navigation.
  • Click Create peering connection.
  • Enter ewb-alpha-beta-pcx as the name.
  • Choose ewb-alpha-vpc as the requester VPC.
  • Choose My account for the accepter account.
  • Choose This Region for the accepter Region.
  • Choose ewb-beta-vpc as the accepter VPC.
  • Create the request by clicking Create peering connection.
  • Select the connection showing pending-acceptance.
  • Choose Actions.
  • Choose Accept request.
  • Confirm the request by clicking Accept request.
  • Wait until the connection status shows active.

Good progress. ewb-alpha-beta-pcx now authorizes private traffic between the two VPCs.

Why is active only the first layer?

The active state confirms that the requester and accepter established the peering relationship. It does not create subnet routes.

Alpha needs routes toward Beta. Beta needs a return route toward Alpha.

  • Capture the active connection with Snipping Tool from earlier.
  • Redact account details from the capture.
  • Save the sanitized capture as evidence/06-peering-active.png.

The Alpha public route carries bastion traffic toward App-B. The Alpha private route carries App-A traffic toward App-B.

  • Return to Route tables in the VPC console.
  • Select ewb-alpha-public-rt.
  • Choose Actions.
  • Choose Edit routes.
  • Choose Add route.
  • Enter 10.20.0.0/16 as the destination.
  • Choose ewb-alpha-beta-pcx as the VPC peering connection target.
  • Save the route by clicking Save changes.

The bastion subnet now has an explicit route to the complete Beta CIDR.

  • Select ewb-alpha-private-rt.
  • Choose Actions.
  • Choose Edit routes.
  • Choose Add route.
  • Enter 10.20.0.0/16 as the destination.
  • Choose ewb-alpha-beta-pcx as the VPC peering connection target.
  • Save the route by clicking Save changes.

The App-A subnet now sends Beta-bound packets through the peering connection.

Beta also needs a path back to both Alpha subnets. This return route covers the bastion plus App-A.

  • Select ewb-beta-private-rt.
  • Choose Actions.
  • Choose Edit routes.
  • Choose Add route.
  • Enter 10.10.0.0/16 as the destination.
  • Choose ewb-alpha-beta-pcx as the VPC peering connection target.
  • Save the route by clicking Save changes.

How do the three routes work together?

  • The route in ewb-alpha-public-rt carries bastion connections to App-B.
  • The route in ewb-alpha-private-rt carries App-A traffic to App-B.
  • The route in ewb-beta-private-rt gives replies a path back to Alpha.

Capturing all three tables is a little fiddly because the evidence must also prove each subnet association.

  • Confirm that ewb-alpha-public-rt remains associated only with ewb-alpha-public-subnet-a.
  • Confirm that ewb-alpha-private-rt remains associated only with ewb-alpha-private-subnet-a.
  • Confirm that ewb-beta-private-rt remains associated only with ewb-beta-private-subnet-a.
  • Capture the three peer routes with their explicit associations.
  • Redact account information from the capture.
  • Save the sanitized evidence as evidence/07-routes-after-peering.png.
Run the success, failure, and recovery tests

The routes make private delivery possible. SSH through ProxyJump plus ping in both directions now test the complete path.

Before you rerun the forward ping, do you expect the result to match the failed baseline or change?

  • Return to the App-A shell from earlier.
  • Test the repaired App-A to App-B path by running this command:
ping -c 4 10.20.1.10

What does this test prove?

  • The command sends four ICMP Echo requests from App-A to App-B.
  • The destination uses App-B's fixed private IPv4 address.
  • Successful replies exercise the Alpha forward route plus the Beta return route.

You should observe four replies with 0% packet loss. That is the original routing gap closed with measured evidence.

Forward ping still failing?

Confirm that the peering connection still shows active. Check the explicit subnet associations before inspecting individual routes.

Verify the Beta return route plus App-B's Echo request rule. Help me diagnose the failed forward ping.

  • Capture the observed forward replies with Snipping Tool.
  • Redact local usernames from the capture.
  • Save the sanitized capture as evidence/08-forward-ping.png.
  • Copy the actual command output into docs/test-results.md.
  • Mark the forward ping as Pass only after observing the replies.

Before you connect to App-B, do you expect the existing ProxyJump alias to reach the private instance through the new public-subnet peer route?

  • Return to Windows PowerShell from earlier.
  • Connect to App-B through the bastion by running this command:
ssh ewb-app-b

What path does this command use?

  • The local SSH configuration first connects to ewb-bastion.
  • The bastion forwards the connection toward App-B's private address.
  • The private key remains on the Windows computer throughout the connection.

You should reach an interactive Amazon Linux shell as ec2-user. App-B remains private because the connection entered through the bastion.

App-B SSH timing out?

Check the Alpha public peer route plus the Beta return route. Confirm that App-B still permits TCP 22 from 10.10.1.10/32.

Confirm that the local host entry still uses ProxyJump ewb-bastion. Help me diagnose the App-B SSH timeout.

  • Capture the interactive App-B shell.
  • Redact local usernames from the capture.
  • Save the sanitized capture as evidence/10-app-b-ssh.png.
  • Record the observed SSH result in docs/test-results.md.

Before you test the return direction, do you expect App-B to receive replies from App-A through the same peering connection?

  • Test the App-B to App-A path from the App-B shell by running this command:
ping -c 4 10.10.2.10

What does the reverse ping prove?

  • The command sends four Echo requests from App-B to App-A.
  • The Beta route carries each request toward Alpha.
  • App-A's Echo request rule permits traffic sourced from 10.20.1.10/32.

You should observe four replies with 0% packet loss. Both private directions now have observed results.

  • Capture the observed reverse replies.
  • Redact local usernames from the capture.
  • Save the sanitized capture as evidence/09-reverse-ping.png.
  • Copy the actual reverse output into docs/test-results.md.

The next test changes only App-B's ICMP permission. SSH remains the independent control channel.

  • Return to the VPC console from earlier.
  • Choose Security groups.
  • Select ewb-app-b-sg.
  • Open the inbound-rule editor.
  • Delete only the Custom ICMP - IPv4 Echo request rule sourced from 10.10.2.10/32.
  • Save the inbound-rule change.
  • Capture the missing ICMP rule.
  • Save the sanitized capture as evidence/11-icmp-rule-removed.png.

Before you rerun the forward ping, do you expect an active peer plus correct routes to overcome the missing ICMP permission?

  • Return to the App-A shell from earlier.
  • Test the path after removing App-B's ICMP permission by running this command:
ping -c 4 10.20.1.10

What does this controlled test isolate?

  • The network topology remains unchanged.
  • The peer routes remain installed.
  • Only App-B's permission for Echo requests from App-A has changed.

You should observe no replies or 100% packet loss. This intended failure proves that an active peer cannot override the target security policy.

  • Capture the observed ICMP failure.
  • Redact local usernames from the capture.
  • Save the sanitized capture as evidence/12-icmp-failure.png.
  • Copy the actual failed output into docs/test-results.md.

Before you check the control channel, do you expect removing an ICMP rule to block TCP port 22?

  • Return to Windows PowerShell from earlier.
  • Retest the independent SSH path by running this command:
ssh ewb-app-b

Why repeat the SSH test?

The command verifies that App-B's TCP 22 rule still works. A successful shell isolates the failure to ICMP.

You should reach the App-B shell again. Ping and SSH depend on separate inbound permissions.

The shortfall is now reproduced cleanly. Restoring the exact Echo request rule should recover only the affected protocol.

  • Return to the inbound rules for ewb-app-b-sg.
  • Add a Custom ICMP - IPv4 rule.
  • Choose Echo request.
  • Enter 10.10.2.10/32 as the source.
  • Save the restored inbound rule.

Before you run the recovery check, do you expect the same forward command to receive all four replies again?

  • Return to the App-A shell from earlier.
  • Verify the restored ICMP permission by running this command:
ping -c 4 10.20.1.10

What confirms recovery?

Four replies show that the exact App-B Echo request rule is active again. The route configuration stayed valid throughout the failure cycle.

You should observe four replies with 0% packet loss. The lab now has evidence of success, controlled failure, protocol isolation, plus recovery.

Recovery ping still failing?

Confirm that the restored rule uses Custom ICMP - IPv4 with Echo request. Verify the source is exactly 10.10.2.10/32.

Check that you saved the rule on ewb-app-b-sg. Help me diagnose the failed recovery ping.

  • Capture the observed recovery replies.
  • Redact local usernames from the capture.
  • Save the sanitized capture as evidence/13-icmp-recovery.png.
  • Copy the actual recovery output into docs/test-results.md.
  • Mark the recovery case as Pass only after observing the replies.
Finish the portfolio and workbook report

The lab now has observed evidence for every network claim. A public GitHub portfolio turns those results into an interview-ready case study.

A Mermaid diagram can render directly inside the README. The finished report must preserve the difference between expected behavior and actual results.

  • Return to the ewb-secure-vpc-peering repository from earlier.
  • Use GitHub's web editor to update README.md.
  • Add the project objectives to README.md.
  • Add a fenced mermaid diagram showing both VPCs.
  • Show the bastion inside Alpha's public subnet in the diagram.
  • Show App-A inside Alpha's private subnet in the diagram.
  • Show App-B inside Beta's private subnet in the diagram.
  • Show ewb-alpha-beta-pcx connecting the VPCs.

What should the README demonstrate?

The diagram should make the public boundary plus the private paths visible. The surrounding text should explain how routing and protocol permissions produced each observed result.

Use Not run, Pass, or Fail honestly. Evidence gives each status its meaning.

  • Add the complete sanitized resource inventory to README.md.
  • Add the implementation summary to README.md.
  • Add the final route table to README.md.
  • Add the final security table to README.md.
  • Add the observed test results to README.md.
  • Add the before-and-after troubleshooting case study to README.md.
  • Add the lessons learned to README.md.
  • Add a cleanup status placeholder to README.md.
  • Add the future enhancements to README.md.
  • Update docs/resource-inventory.md with the active peering connection.
  • Update docs/troubleshooting.md with the missing-route baseline.
  • Add the active-peering limitation to docs/troubleshooting.md.
  • Add the controlled ICMP failure analysis to docs/troubleshooting.md.
  • Add the recovery procedure to docs/troubleshooting.md.
  • Add the troubleshooting order to docs/troubleshooting.md.

Use a repeatable troubleshooting order

  • Check the peering status first.
  • Check the subnet-to-route-table association next.
  • Check the peer destination plus target.
  • Check the Beta return route.
  • Check the target security group.
  • Check the default network ACL.
  • Check the target private IPv4 address.
  • Check the instance status checks.
  • Check the ProxyJump host information last.
  • Complete docs/viva.md with concise answers about VPC peering.
  • Explain non-overlapping CIDRs in docs/viva.md.
  • Explain explicit forward routes in docs/viva.md.
  • Explain the return path in docs/viva.md.
  • Explain bastion access through ProxyJump in docs/viva.md.
  • Explain stateful security groups in docs/viva.md.
  • Explain peering non-transitivity in docs/viva.md.
  • Explain standard T3 credits in docs/viva.md.
  • Describe future infrastructure automation in docs/viva.md.
  • Add an acceptance matrix to README.md.
  • Record the exact planned resources as the architecture criterion.
  • Record the observed pre-peering failure as the isolation criterion.
  • Record the observed active state as the peering criterion.
  • Record all three peer routes as separate routing criteria.
  • Record the observed forward ping as the forward ICMP criterion.
  • Record the observed reverse ping as the reverse ICMP criterion.
  • Record the observed App-B shell as the private SSH criterion.
  • Record the ICMP-only interruption as the controlled-failure criterion.
  • Record the restored replies as the recovery criterion.
  • Record the sanitization review as the security criterion.
  • Record the portfolio files as the submission criterion.

The evidence review protects live account details plus local access information. Treat every screenshot as private until the sanitization check is complete.

  • Review every image in evidence/ for AWS account IDs.
  • Review every image in evidence/ for email addresses.
  • Review every image in evidence/ for public IPv4 addresses.
  • Review every image in evidence/ for local Windows usernames.
  • Review every image in evidence/ for private-key paths.
  • Use Add file in the repository.
  • Choose Upload files.
  • Upload the sanitized evidence files from 00-cost-gate-redacted.png through 13-icmp-recovery.png.

GitHub flags sensitive content?

Stop the upload if GitHub identifies a real secret. Remove the sensitive value from the file before trying again.

Never upload the private key or the local SSH configuration. Help me review my portfolio for sensitive AWS information.

The final PDF review is deliberately cautious because one overlooked page can publish a live endpoint or local path.

  • Complete docs/YourName_EWB_VPC_Peering.md in workbook order.
  • Add the sanitized architecture to the workbook.
  • Add the completed inventory to the workbook.
  • Add the observed evidence to the workbook.
  • Add the actual test results to the workbook.
  • Add the troubleshooting case study to the workbook.
  • Add the lessons learned to the workbook.
  • Add the acceptance matrix to the workbook.
  • Add the cleanup plan to the workbook.
  • Open the rendered workbook file in Microsoft Edge from earlier.
  • Press Ctrl+P to open the print dialog.
  • Choose Save as PDF.
  • Save the report as YourName_EWB_VPC_Peering.pdf.
  • Reopen YourName_EWB_VPC_Peering.pdf in Microsoft Edge.
  • Review every PDF page for sensitive values.
  • Upload the sanitized PDF to ewb-secure-vpc-peering.

Before the final check, do you expect the repository to render both the architecture diagram and the completed PDF without exposing sensitive data?

  • Return to the main page of ewb-secure-vpc-peering.
  • Confirm that the README renders the architecture diagram.
  • Confirm that the README shows the observed test statuses.
  • Open YourName_EWB_VPC_Peering.pdf from the repository.
  • Confirm that GitHub renders the PDF.
  • Confirm that the repository contains the evidence files.
  • Confirm that no published file exposes sensitive information.

That completes the case study. The repository now demonstrates isolation, repair, controlled failure, recovery, plus the reasoning behind each result.

Secret mission

Replace an IP Rule with a Cross-VPC Security Group Reference

Replace App-B's address-based SSH rule with a reference to the bastion security group. You will prove that bastion access still works across the active same-Region peering connection.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep the lab running, pause its compute, or remove it completely. Your AWS resources can consume allowances, credits, or billed usage while they remain provisioned.

Cost warning

Amazon EC2, Amazon EBS, public IPv4 addresses, CPU surplus credits, and internet egress can still create charges. The zero-cost gate reduces this risk.

AWS Budgets data can lag by 8 to 12 hours. Charges can continue after a threshold is crossed.

Choose complete deletion if you need a strict $0 boundary. Pausing the instances preserves their EBS volumes, so it does not guarantee zero cost.

Resources you used:

  • Amazon EC2 compute: the three running instances, their three 8 GiB root volumes, and the bastion's temporary public IPv4 address.
  • Amazon VPC network: two Amazon VPC networks, three subnets, three custom route tables, one internet gateway, three security groups, and the active peering connection.
  • SSH access materials: the SSH configuration, the EC2 key pair, and the local ewb-vpc-peering-key.pem private key.

Keep everything running

No cleanup action is needed while you are actively demonstrating the lab. Keeping every AWS resource provisioned requires continued cost monitoring.

  • Keep the three EC2 instances running only while you need the live demonstration.
  • Reconfirm the account's current Free Tier or credit eligibility before each new lab session.
  • Review current usage in Billing and Cost Management while the resources remain provisioned.
  • Retain the sanitized GitHub portfolio and YourName_EWB_VPC_Peering.pdf as your project evidence.

Pause - I'll come back to this later

Stopping the three instances pauses their compute usage while preserving the lab configuration. The EBS volumes remain provisioned during the pause.

  • Return to Instances in Amazon EC2.
  • Select all three lab instances.
  • Choose Instance state.
  • Choose the stop option.
  • Wait until all three instances are fully stopped.
  • Recheck EBS usage and billing eligibility while the volumes remain provisioned.

Compute usage is now paused. Storage usage continues until you terminate the instances and confirm that their volumes are deleted.

Delete - I don't want to use this again

Deleting the lab is a big step. Your sanitized GitHub portfolio and PDF remain available because this cleanup targets the AWS infrastructure and local access material.

Remove the cross-VPC reference first:

The App-B SSH rule references a security group in the peer VPC. Removing it before the peering connection prevents the rule from becoming stale.

  • Return to Security groups in the Amazon VPC console.
  • Select ewb-app-b-sg.
  • Remove the SSH TCP 22 rule sourced from the security-group ID for ewb-bastion-sg.
  • Save the inbound rules.

Terminate the compute layer:

  • Return to Instances in Amazon EC2.
  • Select all three lab instances.
  • Choose Instance state.
  • Choose Terminate (delete) instance.
  • Confirm the termination.
  • Wait until ewb-bastion, ewb-app-a, and ewb-app-b all show terminated.

That clears the running compute layer. The bastion's temporary public IPv4 address should no longer be attached.

Verify the root volumes are gone:

  • Return to Volumes in Amazon EC2.
  • Confirm that the three 8 GiB root volumes disappeared.
  • Identify any remaining lab volume in available state.
  • Delete each confirmed lab volume from the Volumes page.

Delete the peering connection:

  • Return to Peering connections in the Amazon VPC console.
  • Select ewb-alpha-beta-pcx.
  • Choose Actions.
  • Choose Delete peering connection.
  • Enter delete in the confirmation field.
  • Choose Delete.

Delete the two VPC stacks:

Console deletion removes each VPC's remaining subnets, route tables, security groups, network ACL, and DHCP options. Deleting ewb-alpha-vpc also removes its attached internet gateway.

  • Return to Your VPCs in the Amazon VPC console.
  • Select ewb-beta-vpc.
  • Start deletion for ewb-beta-vpc from the Actions menu.
  • Review the dependent resources listed by the console.
  • Enter delete in the confirmation field.
  • Confirm the deletion.
  • Repeat the same deletion flow for ewb-alpha-vpc.

Delete the EC2 key pair:

  • Return to Key Pairs in Amazon EC2.
  • Select ewb-vpc-peering-key.
  • Choose Actions.
  • Choose Delete.
  • Enter Delete in the confirmation field.
  • Choose Delete.

Remove the local access material:

  • Return to File Explorer.
  • Enter %USERPROFILE%\.ssh in the address bar.
  • Securely delete ewb-vpc-peering-key.pem.
  • Return to %USERPROFILE%\.ssh\config in your text editor.
  • Remove the host blocks for ewb-bastion, ewb-app-a, and ewb-app-b.
  • Save %USERPROFILE%\.ssh\config.

Prove the cleanup:

  • Open EC2 Global View in the AWS Management Console.
  • Search for each lab resource name.
  • Confirm that no lab VPCs, subnets, route tables, security groups, volumes, internet gateways, instances, or peering connections remain.

EC2 can keep terminated instances visible briefly. Wait until the lab resources no longer appear before capturing the cleanup proof.

  • Capture the clean Global View as 14-cleanup-global-view.png with Snipping Tool.
  • Sanitize the screenshot to hide account details.
  • Return to the ewb-secure-vpc-peering repository on GitHub.
  • Upload the sanitized image under evidence/.
  • Update the portfolio's cleanup status with the observed result.
  • Record the cleanup time in docs/cost-gate.md.

Billing data arrives later than infrastructure changes. Complete one final account check after the data refreshes.

  • Return to Billing and Cost Management after the usage data refreshes.
  • Record the later billing check in docs/cost-gate.md.

Nice Work!

Nice Work!

Outstanding work! Your secure VPC peering lab now carries private traffic in both directions through explicit routes.

You've learned how to:

  • Build two isolated Amazon VPC networks with non-overlapping CIDRs. Administer two private Amazon EC2 instances through one public bastion with SSH ProxyJump.
  • Prove pre-peering isolation with an observed failure. Repair both traffic directions with explicit peer routes. Reproduce an ICMP-only failure without breaking SSH. Restore the rule to recover connectivity.
  • Publish an evidence-backed portfolio on GitHub. Export the finished workbook as YourName_EWB_VPC_Peering.pdf.
  • Secret Mission: You replaced App-B's bastion /32 SSH source with a same-Region cross-VPC security-group reference. You proved the change by reopening the App-B shell through the bastion.

Ready to quiz yourself?