AWS Networking Lab - VPC Exploration

Overview

This lab will guide you through exploring the existing AWS networking infrastructure in your account. You’ll examine two VPCs with different configurations and understand key networking concepts like routing tables, subnets, and VPC endpoints.

Prerequisites

• AWS Console access
• Basic understanding of networking concepts
• Completion of previous IAM and EC2 lab (for CLI access)

Your group identifier for this lab is “groupXY” where XY is your assigned group number.

Lab Objectives

By the end of this lab, you will have:

• Explored VPC architecture using the AWS Console visual tools
• Identified routing table configurations and subnet associations
• Discovered VPC endpoints and their purpose
• Analyzed VPC peering possibilities between different network ranges
• Used AWS CLI to gather networking information

Part 1: Exploring the eks_vpc VPC

Step 1.1: Navigate to VPC Console and Visual Overview

1. Log into AWS Console
2. In the search bar, type “VPC”
3. Click on “VPC” from the search results
4. In the left sidebar, click “Your VPCs”
5. Look for the VPC named “eks_vpc”
6. Click on the VPC ID to select it
7. In the left sidebar, click “Resource map”
8. Study the visual representation of the VPC

Questions to consider:

• What components do you see in the resource map?
• How many subnets are visible?
• What’s connected to the Internet Gateway?

Step 1.2: Examine VPC Details with CLI

Open your EC2 instance terminal (from the previous lab) and run:

# List all VPCs and find eks_vpc
aws ec2 describe-vpcs --query 'Vpcs[?Tags[?Key==`Name` && Value==`eks_vpc`]].[VpcId,CidrBlock,State]' --output table

# Get the VPC ID for eks_vpc (replace vpc-xxxxx with actual ID from above)
export EKS_VPC_ID=$(aws ec2 describe-vpcs --query 'Vpcs[?Tags[?Key==`Name` && Value==`eks_vpc`]].VpcId' --output text)

echo "EKS VPC ID: $EKS_VPC_ID"

Step 1.3: Investigate Subnets

# List subnets in eks_vpc
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$EKS_VPC_ID" --query 'Subnets[*].[SubnetId,CidrBlock,AvailabilityZone,Tags[?Key==`Name`].Value|[0]]' --output table

Key observation: Note the CIDR block (10.0.0.0/16) and how subnets are distributed.

Step 1.4: Route Tables Analysis (The Tricky Part)

# List ALL route tables in the VPC
aws ec2 describe-route-tables --filters "Name=vpc-id,Values=$EKS_VPC_ID" --query 'RouteTables[*].[RouteTableId,Tags[?Key==`Name`].Value|[0],Associations[?Main==`true`]|length(@)]' --output table

Now let’s examine route table associations:

# Show detailed route table associations
aws ec2 describe-route-tables --filters "Name=vpc-id,Values=$EKS_VPC_ID" --query 'RouteTables[*].[RouteTableId,Associations[*].SubnetId,Associations[?Main==`true`]]' --output json

Trick Question Time:

1. How many route tables do you see?
2. Which route table shows “Main: true”?
3. Are any subnets actually associated with the main route table?

Go back to the VPC Console and check:

1. In the left sidebar, click “Route tables”
2. Filter by your eks_vpc VPC
3. Look at the “Subnet associations” tab for each route table

The Answer: The default/main route table exists but has no subnet associations. All subnets are explicitly associated with custom route tables.

Part 2: Exploring the nsrc-lab VPC

Step 2.1: Basic nsrc-lab VPC Information

# Get nsrc-lab VPC details
export NSRC_VPC_ID=$(aws ec2 describe-vpcs --query 'Vpcs[?Tags[?Key==`Name` && Value==`nsrc-lab`]].VpcId' --output text)

echo "NSRC Lab VPC ID: $NSRC_VPC_ID"

# Compare CIDR blocks
aws ec2 describe-vpcs --vpc-ids $EKS_VPC_ID $NSRC_VPC_ID --query 'Vpcs[*].[Tags[?Key==`Name`].Value|[0],CidrBlock]' --output table

Key observation: Note the different CIDR block (10.30.0.0/16).

Step 2.2: Find the Hidden S3 Endpoint

# Look for VPC endpoints in nsrc-lab
aws ec2 describe-vpc-endpoints --filters "Name=vpc-id,Values=$NSRC_VPC_ID" --query 'VpcEndpoints[*].[VpcEndpointId,ServiceName,VpcEndpointType,State]' --output table

Exploration Challenge:

1. What service does this endpoint connect to?
2. Why would you want an S3 endpoint in your VPC?

Let’s get more details:

# Get detailed endpoint information
aws ec2 describe-vpc-endpoints --filters "Name=vpc-id,Values=$NSRC_VPC_ID" --query 'VpcEndpoints[*].[VpcEndpointId,ServiceName,RouteTableIds,PolicyDocument]' --output json

Questions to consider:

• What type of endpoint is this (Gateway or Interface)?
• Which route tables are associated with it?
• What’s the purpose of having an S3 endpoint?

Part 3: VPC Peering Theory Exercise

Step 3.1: CIDR Analysis for Peering

Let’s analyze if these VPCs can be peered:

EKS VPC: 10.0.0.0/16
NSRC Lab VPC: 10.30.0.0/16

Analysis Questions:

1. Can you peer VPCs with overlapping CIDR blocks?
2. Do 10.0.0.0/16 and 10.30.0.0/16 overlap?
3. What would happen if both VPCs used 10.0.0.0/16?

Step 3.2: Theoretical Peering Steps

If you were to create a VPC peering connection between these VPCs, here are the steps you would follow:

1. Create Peering Connection
2. Accept Peering Connection
3. Update Route Tables
4. Security Group Rules

Final Questions:

1. After peering, how would traffic from eks_vpc reach nsrc_lab?
2. What would be the longest prefix match for traffic from 10.0.1.100 to 10.30.1.100?
3. Why is the S3 endpoint only in one VPC and not the other?

Key Concepts Summary

VPC Architecture Patterns:

• Simple Public VPC: eks_vpc with basic internet connectivity
• Enhanced VPC: nsrc-lab with cost optimization (S3 endpoint)

Route Table Insights:

• Default route tables can exist but remain unused
• Explicit subnet associations provide better control
• VPC endpoints create automatic routes for AWS services

VPC Peering Requirements:

• Non-overlapping CIDR blocks
• Bi-directional routing configuration
• Security group rule updates
• Regional or cross-regional connectivity

Cost Optimization:

• S3 VPC endpoints eliminate data transfer charges for S3 traffic
• Traffic stays within AWS backbone instead of traversing internet