AMAZON SECURE NETWORKING

Getting started with Amazon Virtual Private Cloud (VPC)

This lab guides you through the process of configuring a VPC on aws. Starting with an overview of the default VPC and its components, then diving into building a custom VPC from scratch. With this lab you should learn tfo create subnets, route tables,internet gateways, and NAT gateways, and configure security groups to control network traffic. By the end of this lab, you'll have a solid understanding of VPC networking concepts andpractgical experience inbuilding secure and scalable network infrastructure in AWS.

Prerequisites

Before you begin this lab, make sure you have the following:

• Basic understanding of networking concepts
• An AWS account
• Willingness to learn

Cost considerations

This lab creates AWS resources that may incur costs in your account. The primary cost comes from the NAT gateway ($0.045 per hour plus data processing charges) and EC2 instances (t2.micro, approximately $0.0116 per houjr each). If you complete this tutorial in one hour anhd then clean up all resources, the total cost will be approximately $0.07. For cost optimization in develolpment environments, consider using NAT instance instead of a NAT gateway, which can reduce costs significantly.

Understanding the Default VPC

AWS provides a default VPC in each region, offering a pre-configured network fcr launching instgances. Lets take a look at key components:

• Main Route Table: allows us to control traffic flow throughout the VPC and in and out of a VPC. They are associated with one or many subnets and affects all resources within those subnets.
• Main Network ACL (NACL): acts as a firewall at the subnet level, controlling ingress and egress traffic. The default NACL allowss all traffic unless specified.
• Subnets: Default VPCs include a subnet in each Availability Zone within the region, providing high availability. Each subnet is associated with the Main Route Table and NACL.
• Internet Gateway (IGW): The IGW allows communication between the VPC and the internet. The default VPC includes an IGW and a default route in the Main Route Table that sends all internet-bound traffic to the IGW.

** To inspect the Default VPC, navigate to the VPC Dashboard and select Your VPCs. You can explore each component from there.

Configuring a custom VPC:

• Create a VPC: In the VPC dashboard, choose "create VPC". specify a name tag and a CIDR block (e.g., 10.0.0.0/16). Consider CIDR.xyz to determine suitable IPv4 address ranges.
• Create subnet: Create four subnets within your VPC: two public and two private. Assign them non-overlapping CIDR blocks (e.g., 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, 10.0.4.0/24). Place each subnet in a different Availability Zone for redundancy.

• Create an Internet Gateway: Create an IGW and attach it to your custom VPC. This enables communication with the internet.

** These steps establish the foundation for your custom VPC, creating the network infrastructure required to connect your resources.

Route Table Configuration

Route tables control the flow of traffic within your VPC and to external networks. Follow these steps to configure routing:

• Create Route Tables: Create two route tables: one public and one private.

• Public Route Table: Add a route to the IGW for all internet-bound traffic (0.0.0.0/0). This allows instances in public subnets to access the internet.

• Private Route Table: Leave it for now. Traffic in the private subnets must be isolated.

• Associate Subnets: Associate the public subnets with the public route table and the private subnets with the private route table. This directs traffic from each subnet according to the configured routes.

** These steps ensures that your public subnets can communicate with the Internet Gateway and the private subnets remain isolated.

Launching Instances and Security Groups

Now that the network is set up, launch instances into your subnets and configure security groups to control access:

• Create EC2 Instances:

Assign a web server instance to one of the public subnets and a database server instance to one of the private subnets.

Create a private key pair for the database server. You will need this later to connect via SSH.

• Security Groups:

Configure the security group for the web server to allow inbound traffic on ports 80 (HTTP) and 22 (SSH) from your IP address.

Configure the security group for the database server to allow inbound traffic on port 22 (SSH) from the web server's IP address only, enabling secure SSH connections.

** Try to connect to the web server's console via SSH. Note how it will fail for the database server because of the Security Group configurations.

Establishing Private to Public Instance Connectivity

To allow the web server to connect to the database server, modify the database server's security group to permit SSH traffic (port 22) only from the CIDR block of your VPC (e.g., 10.0.0.0/16). This ensures only instances within the VPC can connect to the database server.

• Open port 22 for VPC: Set Inbound Rules Source for Security Group of database server to 10.0.0.0/16 (VPC)

• SSH from Web Server to DB Server: Use SSH to connect from the web server to the database server's private IP address. Use the private key file (.pem) you created earlier.

** To connect from the web server to the database server, you first need to create a .pem file.

• Create .pem file: Create a file named "myprivatekey.pem" on the web server using Nano (nano myprivatekey.pem) and paste the key from the .pem file you downloaded when you created the database server.

• Elevate Priveleges: Change the permissions using: chmod 400 myprivatekey.pem

• Connect with this command:ssh ec2-user@{instance private IP} -i myprivatekey.pem

Setting Up a NAT Gateway for Private Subnets

To allow instances in private subnets to access the internet without being directly exposed, create a NAT Gateway:

• Create a NAT Gateway: In the VPC Dashboard, choose "NAT Gateways" and click "Create NAT Gateway". Place the NAT Gateway in one of the public subnets.

• Allocate Elastic IP: Associate an Elastic IP address with the NAT Gateway. This provides a static public IP address for the NAT Gateway.

• Update Private Route Table: Add a route to the private route table that sends all internet-bound traffic (0.0.0.0/0) to the NAT Gateway.

Now, instances in the private subnets can access the internet through the NAT Gateway.

Testing and Verifying Connectivity

Verify connectivity from the database server (in the private subnet) by SSHing into the instance via the Web Server, and try these steps:

• Test Internet Access: Ping a public IP address (e.g., 8.8.8.8) to verify internet connectivity through the NAT Gateway.

• Test DNS Resolution: Curl example.com to verify DNS resolution and HTTP connectivity.

• Test Updates: Run a yum update to verify that the instance can download updates from the internet.

** To test that the NAT Gateway is indeed used for Internet connectivity and that there is no direct connection from the DB Server, remove the NAT Gateway route from the private route table. This will cause connectivity to drop. When adding the route back, connectivity should come back up.

we have come to the end of this lab