DEV Community: Rajesh

AWS VPC Peering: How to Connect Two VPCs Privately

Rajesh — Fri, 30 Oct 2026 17:25:03 +0000

Connecting Two AWS VPCs Using VPC Peering 🚀

Imagine you have two different VPCs in AWS.

One VPC has your application, and the other has your database.

Now your application needs to get data from the database. How can these two VPCs talk to each other?

AWS provides a feature called VPC Peering to solve this problem.

What is VPC Peering?

VPC Peering is simply a way to connect two VPCs so that they can communicate privately.

For example, let's say we have:

VPC A – 10.0.0.0/16
VPC B – 10.1.0.0/16

We can connect these two VPCs and allow resources inside them to communicate using their private IP addresses.

No public IP address is needed for communication between the VPCs.

How can we connect two VPCs?

Let's do it step by step.

First, create two VPCs in your AWS account.
Make sure both VPCs have different IP address ranges.
Open the VPC service in the AWS Console.
Go to Peering Connections and create a new connection.
Select the VPCs you want to connect.
Accept the connection request.
Add the required routes in both VPC route tables.
Update the security groups to allow communication.

Now your VPCs are ready to communicate!

One important thing to remember

Creating a peering connection alone is not enough.

You must also update the route tables on both sides.

For example:

In VPC A, add a route for 10.1.0.0/16.
In VPC B, add a route for 10.0.0.0/16.

Both VPCs need to know where to send the traffic.

Also, check the security groups and network ACLs if communication is not working.

Can three VPCs communicate through Peering?

Let's say:

VPC A is connected to VPC B.
VPC B is connected to VPC C.

Can VPC A directly communicate with VPC C through VPC B?

No!

This is called non-transitive peering.

If A needs to communicate with C, you must create another direct peering connection between them.

If you have many VPCs, AWS Transit Gateway can make network management easier.

Important points to know

Before using VPC Peering, remember:

Two VPCs cannot have overlapping IP ranges.
Peering connections are not transitive.
Both sides need proper route table entries.
Security groups must allow the required traffic.
You cannot use a peer VPC's NAT Gateway or Internet Gateway through peering.
Data transfer charges apply.

When should we use VPC Peering?

Here are a few examples:

An application in one VPC needs to access a database in another VPC.
Two different AWS accounts need private communication.
Development and testing environments need to share resources.
Applications running in different AWS Regions need private connectivity.

AWS NAT Gateway: Giving Private Subnets Safe Internet Access

Rajesh — Thu, 29 Oct 2026 18:00:00 +0000

Why do we need a NAT Gateway?

In the last session, we created a custom VPC with a private subnet to lock down backend databases and application servers. Nobody on the internet could reach them.

Network isolation is great for security, but it creates a real problem:

How does your private EC2 server download security updates (apt update or dnf update)?
How does it download packages or call external APIs like Stripe, Twilio, or GitHub?

If you attach an Internet Gateway directly to the private subnet, it is no longer private—anyone on the internet can scan your ports.

A NAT Gateway solves this problem. It allows private servers to reach out to the internet, while completely blocking the internet from starting connections back into your private servers.

1. What is NAT (Network Address Translation)?

Think of an office with a receptionist:

When an employee wants to call a client, the receptionist dials out using the office main phone number.
The client outside only sees the office company number, never the employee's personal desk extension.
When the client replies on that same call, the receptionist connects them back to the employee.
But if someone outside tries to call an employee directly without an active outbound call, the receptionist blocks the call.

[ Private Subnet ]                         [ Public Subnet ]                 [ Internet ]
  Private EC2 (10.0.2.15)                   NAT Gateway (Elastic IP)          GitHub / External API
          │                                         │                                │
          │── Outbound: dnf update ────────────────►│── Outbound: Source = NAT EIP ─►│
          │                                         │                                │
          │◄── Inbound Reply ───────────────────────│◄── Inbound Reply ──────────────│
          │                                         │                                │
          │                                         │◄── Outside Inbound Probe ──────│ (Blocked ✗)

How the packets travel:

Your private EC2 (10.0.2.15) wants to download software from the internet.
The private route table sends 0.0.0.0/0 to the NAT Gateway.
The NAT Gateway replaces the private IP (10.0.2.15) with its own Elastic IP. It keeps track of this in its connection table.
The packet goes through the Internet Gateway (IGW) out to the internet.
When the website sends the data back, the NAT Gateway checks its table, swaps the destination IP back to 10.0.2.15, and hands the data to your private server.

Any outside connection coming in that was not started by your private server is immediately dropped.

2. Internet Gateway (IGW) vs. NAT Gateway

Both handle internet traffic, but they do completely different jobs:

What to look at	Internet Gateway (IGW)	NAT Gateway
Traffic Direction	Inbound and Outbound (Two-way)	Outbound only + replies come back
Used by	Public subnets	Private subnets
Needs a Public IP on EC2?	Yes	No (EC2 only needs a private IP)
IP Translation	1 to 1 (One public IP for one EC2)	Many to 1 (Many private EC2s share 1 NAT Elastic IP)
Where do you put it?	Attached to the whole VPC	Sits inside a Public Subnet
Scaling	Automatic	Automatic (up to 100 Gbps)
Cost	Free	Hourly charge + per-GB data fee

3. How the Route Tables Work

For a NAT Gateway to work, you need two route tables set up like this:

Public Subnet Route Table (Where NAT Gateway lives)
Destination     Target
10.0.0.0/16     local
0.0.0.0/0       igw-0abc123  (Internet Gateway)

Private Subnet Route Table
Destination     Target
10.0.0.0/16     local
0.0.0.0/0       nat-0def456  (NAT Gateway)

The #1 Mistake: You must create your NAT Gateway inside a Public Subnet. If you place it inside a private subnet, the NAT Gateway cannot reach the Internet Gateway, and nothing will connect.

4. NAT Gateway vs. NAT Instance

Before AWS had managed NAT Gateways, engineers launched a small EC2 instance running Linux to do the job:

AWS NAT Gateway (Managed): Works out of the box, auto-scales up to 100 Gbps, and AWS handles all patching and hardware redundancy inside the AZ.
NAT Instance (EC2 you manage): Cheaper for quick student tests, but you have to disable Source/Destination Check, configure the Linux firewall yourself, and if that single EC2 instance stops or crashes, your whole private subnet loses internet access.

What is a Private NAT Gateway?

When creating a NAT Gateway in the AWS console, you will see two options:

Public: Has an Elastic IP. Used to give private subnets internet access.
Private: Has no Elastic IP. It is used when connecting two private networks (like on-premises to AWS via Transit Gateway) that have overlapping IP addresses. It cannot reach the internet.

5. High Availability (HA) & Saving Money

A NAT Gateway is redundant inside one Availability Zone (AZ), but it does not protect you across multiple AZs.

Multi-AZ Setup (Production)

If you run workloads in both AZ-a and AZ-b:

Put one NAT Gateway in AZ-a (public subnet).
Put one NAT Gateway in AZ-b (public subnet).
Point private subnets in AZ-a to NAT Gateway A, and private subnets in AZ-b to NAT Gateway B.
This prevents an outage in one AZ from cutting off your entire backend, and avoids cross-AZ data transfer fees.

      Availability Zone A                       Availability Zone B
┌─────────────────────────────────┐       ┌─────────────────────────────────┐
│ [Public Subnet A]               │       │ [Public Subnet B]               │
│  NAT Gateway A (EIP A)          │       │  NAT Gateway B (EIP B)          │
│       ▲                         │       │       ▲                         │
│ [Private Subnet A]              │       │ [Private Subnet B]              │
│  App EC2 (Routes to NAT A)      │       │  App EC2 (Routes to NAT B)      │
└─────────────────────────────────┘       └─────────────────────────────────┘

How to avoid surprise bills:

NAT Gateways charge an hourly uptime fee plus a per-GB fee for all data passing through them:

Use free VPC Gateway Endpoints for S3 & DynamoDB: S3 Gateway Endpoints are 100% free. If your private servers pull gigabytes of files or backups from S3 through a NAT Gateway, you pay data processing on every gigabyte. Adding a Gateway Endpoint routes that traffic directly to S3 within AWS at zero cost.
Delete it when done with labs: Always delete your NAT Gateway and release the Elastic IP when you finish testing.

Hands-On Practice & Console Walkthrough

Here is the step-by-step walkthrough to set up a NAT Gateway and give your private EC2 instance outbound internet access.

Step 1: Create the NAT Gateway

Go to VPC Console → click NAT Gateways → click Create NAT gateway.
Name tag: lab-nat-gw.
Subnet: Select your public subnet (public-subnet-1a).
Connectivity type: Select Public.
Elastic IP allocation ID: Click Allocate Elastic IP.
Click Create NAT gateway. It takes about 1–2 minutes for the status to turn from Pending to Available.

![NAT Gateway Created in Public Subnet](

Fig 1: NAT Gateway created in public-subnet-1a with an allocated Elastic IP.

Step 2: Route the Private Subnet to the NAT Gateway

Go to Route tables → select your private route table (private-rt).
Open the Routes tab → click Edit routes → Add route:
- Destination: 0.0.0.0/0
- Target: Select NAT Gateway → pick lab-nat-gw.
Click Save changes.

![Private Route Table Pointing to NAT Gateway](

Fig 2: Routing all outbound internet traffic (0.0.0.0/0) to the NAT Gateway.

Step 3: Test from the Private Instance

Log into your private EC2 instance (using AWS Systems Manager Session Manager or jumping through your public EC2):

# 1. Check your public IP from the private instance:
curl -s https://checkip.amazonaws.com

Output:

13.234.112.45

It prints the NAT Gateway's Elastic IP, not the EC2 private IP!

# 2. Test downloading packages:
sudo dnf update -y

Packages now download and install with no problem through the NAT Gateway.

Step 4: Verify Outside Inbound Traffic is Blocked

From your local computer terminal, try reaching the private instance through the NAT Gateway's Elastic IP:

curl --max-time 5 http://13.234.112.45
ssh -i key.pem ec2-user@13.234.112.45

Result:
Both commands time out. Nobody on the internet can connect directly to your private instance through the NAT Gateway.

Step 5: Clean Up (Avoid Surprise Bills!)

NAT Gateways charge money every hour they run. Once you finish:

Go to NAT Gateways → select lab-nat-gw → Actions → Delete NAT gateway.
Go to Route tables → edit your private route table and delete the 0.0.0.0/0 -> nat route.
Go to Elastic IPs → select the allocated Elastic IP → Actions → Release Elastic IP addresses.

Wrap-up

Today's big takeaway was solving the private subnet internet problem:

Private subnets stay private, but can still download packages and call external APIs.
Always put your NAT Gateway in a public subnet with an Internet Gateway route.
For production, run one NAT Gateway per Availability Zone.
Use free S3 Gateway Endpoints to save money on data transfer fees.

AWS VPC: Public & Private Subnets with EC2 & Docker

Rajesh — Wed, 28 Oct 2026 17:23:34 +0000

Why do we need a custom VPC & Subnets?

Without network isolation, every server you launch sits on a shared network accessible to anyone on the internet.

A Virtual Private Cloud (VPC) gives you your own isolated private data center in the cloud. You decide which servers face the public internet and which backend databases stay completely shielded inside private subnets where no outsider can touch them.

1. The VPC (Virtual Private Cloud) & CIDR Planning

Think of a VPC as a private gated apartment complex inside the giant AWS city. You decide the boundary walls, the internal road layout, and who gets through the gate.

Region Scope: A VPC lives inside one AWS Region and spans across all Availability Zones in that Region.
CIDR Block: You assign your VPC an IPv4 range (between /16 with 65,536 IPs down to /28 with 16 IPs) using private IP standards (like 10.0.0.0/16).
CIDR Math in Plain English: The number after the slash tells you how many network bits are locked. A smaller number means a bigger network:
- /16 = 65,536 addresses (standard for a company VPC).
- /24 = 256 addresses (standard for a subnet).
- Always plan IP ranges across dev, staging, and prod so they don't overlap if you need to connect them later.

2. Subnets & The 5 Reserved AWS IPs

Subnets are slices of your VPC tied to one specific Availability Zone (building).

Inside every subnet you create, AWS automatically reserves 5 IP addresses for internal networking:

.0 — Network address.
.1 — VPC router / gateway.
.2 — AWS DNS resolver.
.3 — Reserved by AWS for future use.
.255 — Network broadcast address.

Rule of thumb: When you create a /24 subnet (which mathematically has 256 IPs), you will only get 251 usable IPs for your EC2 instances and databases (256 - 5 = 251). Notice how AWS explicitly displays "IP addresses available: 251" in the subnet details.

3. Route Tables: What Actually Makes a Subnet "Public"?

There is no special checkbox on AWS that makes a subnet public. Naming a subnet public-subnet does not make it public!

A subnet is Public if and only if its Route Table has a default route sending all outbound internet traffic (0.0.0.0/0) to an Internet Gateway (IGW):

Public Subnet Route Table             Private Subnet Route Table
Destination     Target                Destination     Target
10.0.0.0/16     local                 10.0.0.0/16     local
0.0.0.0/0       igw-0abc123           (No internet route - completely isolated)

If a subnet has only the local route, instances inside it can talk to other servers in the VPC, but the outside internet has zero way in.

4. The Internet Gateway (IGW)

The Internet Gateway is the front security gate connecting your VPC to the public internet:

One IGW per VPC. It is horizontally scaled, highly available, and completely free.
It does 1:1 NAT translation between your instance's public IP and private IP.
When you run ip addr inside an EC2 instance, you will only see its private IP (10.0.1.x). The IGW handles the public IP translation seamlessly on the way in and out.

5. Security Groups vs. Network ACLs (NACLs)

AWS provides two layers of firewalls with very different rules:

Internet Traffic ──► [ Network ACL (Subnet Guard) ] ──► [ Security Group (Instance Guard) ] ──► EC2

Feature	Security Group (SG)	Network ACL (NACL)
Protects	Individual EC2 instance / ENI	The entire Subnet boundary
Rules	Allow rules only (default deny)	Allow AND Deny rules
State	Stateful: If traffic is allowed in, the reply is automatically allowed out.	Stateless: You must explicitly allow both inbound and outbound return traffic!
Evaluation	Evaluates all rules before deciding	Evaluates rules in strict number order (100, 200... lowest number wins)

The 3-Tier Security Group Trick: Instead of hardcoding changing IP addresses into firewall rules, reference the Security Group ID directly:

web-sg: Inbound HTTP (80/443) from 0.0.0.0/0.

app-sg: Inbound port 8080 only from web-sg.

db-sg: Inbound port 5432 (Postgres) only from app-sg.

6. Official VPC Multi-Tier Architecture

(Reference: Official AWS VPC User Guide Architecture)

In production:

Public subnets host your load balancers and front-facing web servers.
Private subnets host application workers and internal microservices.
Isolated private subnets hold databases so no internet route ever touches your customer data.

Hands-On Practice & Console Walkthrough

Here is the step-by-step lab to build a custom VPC with public and private subnets, an Internet Gateway, and custom route tables in your AWS account.

Step 1: Create the Custom VPC (`lab-vpc`)

In the VPC Console, go to Your VPCs → click Create VPC.
Select VPC only.
Name tag: lab-vpc.
IPv4 CIDR block: 10.0.0.0/16 (gives us 65,536 total internal IPs).
Leave Tenancy as Default and click Create VPC.

![Creating Custom VPC lab-vpc](

Fig 1: Creating my custom VPC lab-vpc with CIDR 10.0.0.0/16.

Step 2: Create Public & Private Subnets

Next, we divide the VPC into two separate subnets:

Go to Subnets → Create subnet → select lab-vpc.
Subnet 1 (Public):
- Subnet name: public-subnet-1a
- Availability Zone: Europe (Stockholm) / eun1-az1 (eu-north-1a)
- IPv4 subnet CIDR block: 10.0.1.0/24 (251 usable IPs)
Click Add new subnet for Subnet 2 (Private):
- Subnet name: private-subnet-1a
- Availability Zone: Europe (Stockholm) / eun1-az1 (eu-north-1a)
- IPv4 subnet CIDR block: 10.0.2.0/24 (251 usable IPs)
Click Create subnet.

![Configuring Public and Private Subnets](

Fig 2: Setting up public-subnet-1a and private-subnet-1a inside lab-vpc.

Step 3: Create & Attach the Internet Gateway (`lab-igw`)

A VPC is completely cut off from the internet by default. We need an Internet Gateway to open the front door:

Go to Internet Gateways → click Create internet gateway.
Name tag: lab-igw.
Once created, click Actions → Attach to VPC.
Select lab-vpc and click Attach internet gateway.

![Internet Gateway Attached to VPC](

Fig 3: Internet Gateway lab-igw created and attached to lab-vpc.

Step 4: Create the Public Route Table (`public-rt`)

Now we connect the public subnet to our Internet Gateway using a custom Route Table:

Go to Route tables → click Create route table.
Name tag: public-rt.
VPC: Select lab-vpc and click Create route table.
Open the Routes tab → click Edit routes → Add route:
- Destination: 0.0.0.0/0 (any IPv4 traffic)
- Target: Select Internet Gateway (lab-igw)
- Click Save changes.
Open the Subnet associations tab → Edit subnet associations → select public-subnet-1a and save.

(The private-subnet-1a stays connected to the default main route table with only the 10.0.0.0/16 local route, so it remains isolated).

![Public Route Table Creation](

Fig 4: Creating public-rt and linking it to lab-vpc.

Step 5: Launching an EC2 Instance into the Custom VPC

Finally, launch an EC2 instance directly inside your custom network:

Go to EC2 → click Launch instance.
Under Network settings, click Edit:
- VPC: Select lab-vpc.
- Subnet: Select public-subnet-1a. Notice that AWS confirms 251 available IPs.
- Auto-assign public IP: Set to Enable if you want to reach it directly via SSH or web.
- Firewall (security groups): Create a new security group allowing SSH (port 22) or HTTP (port 80).
Click Launch instance.

![EC2 Network Settings in Custom Subnet](

Fig 5: Placing our EC2 instance into lab-vpc and public-subnet-1a with 251 available IPs.

Step 6: Clean Up (Avoid Surprise Bills!)

Once you finish testing:

Terminate the EC2 instance.
Go to Internet Gateways → detach lab-igw from lab-vpc, then delete it.
Delete the custom route table public-rt.
Delete the subnets and delete the VPC lab-vpc.

Compute & Load Balancing

Rajesh — Tue, 27 Oct 2026 18:13:17 +0000

Why do we need Load Balancing & Managed Compute?

A single server has hard limits: when CPU or memory runs out, your website crashes. If that single server reboots or fails, your entire business goes offline.

Elastic Load Balancing (ELB) and scalable EC2 instances solve this by distributing user traffic across multiple healthy servers in different Availability Zones, so if one server dies, your users never even notice.

1. Scaling Up vs. Scaling Out

Think of running a busy kitchen:

Scale Up (Vertical): Buying a bigger stove. You replace your small server with a massive 64-CPU machine. It's easy, but it has a physical ceiling and still represents a single point of failure.
Scale Out (Horizontal): Hiring more cooks with more stoves. You run five 2-CPU servers behind a load balancer. When one breaks, the other four keep cooking. You can add more anytime without restarting.

Vertical Scaling (Scale Up)       Horizontal Scaling (Scale Out)
     [ Bigger Server ]                   [ Load Balancer ]
                                          /      |      \
                                     [App 1]  [App 2]  [App 3]

2. Load Balancing Algorithms

How does a load balancer decide which backend server gets the next request?

Round Robin: Takes turns in order (1, 2, 3, 1, 2, 3...). Perfect when requests are short and servers are identical.
Weighted Round Robin: Sends more requests to beefier servers (e.g., 50% to App 1, 30% to App 2, 20% to App 3). Great for canary deployments.
Least Connections: Forwards the next request to whichever server currently has the fewest active connections. Best for long-running jobs (like video processing or WebSockets).
Source / IP Hash: Hashes the client's IP address to map them consistently to the same server without needing cookies.

3. Health Checks: Catching Dead Servers

A load balancer must never send traffic to a dead server.

How it works: The load balancer sends a background check (e.g., GET /health) every few seconds.
Thresholds: If a server fails 3 times in a row (unhealthy threshold), it is pulled out of rotation. Once it passes 2 checks in a row (healthy threshold), it gets traffic again.
Failsafe: If all servers are marked unhealthy, the load balancer "fails open" and routes traffic to all of them as a last resort instead of dropping 100% of requests.

4. The 3 AWS Elastic Load Balancers (ALB, NLB, GWLB)

(Reference: Official AWS Application Load Balancer Architecture)

AWS provides three modern managed load balancers:

Application Load Balancer (ALB) — Layer 7:
- Reads HTTP and HTTPS paths, headers, hostnames, and cookies.
- Can route /api/* to your API servers and /images/* to an S3/storage target.
- Supports TLS termination, redirects (HTTP to HTTPS), and fixed 403/404 responses.
Network Load Balancer (NLB) — Layer 4:
- Ultra-fast, handles millions of requests per second at ultra-low latency.
- Routes raw TCP and UDP traffic (gaming, IoT feeds, databases).
- Provides a static IP address or Elastic IP per Availability Zone.
Gateway Load Balancer (GWLB) — Layer 3:
- Routes raw IP packets to a fleet of third-party security firewalls or inspection appliances using the GENEVE protocol.

5. Listeners, Rules & Target Groups

Inside an Application Load Balancer:

Listener: Listens on a specific port and protocol (e.g., HTTP:80 or HTTPS:443).
Rules: If-then conditions evaluated in priority order. For example: IF path is /api/* THEN forward to tg-api.
Target Group: A logical pool of backend servers with their own health check rules. Target types can be EC2 Instance IDs, IP addresses, or AWS Lambda functions.

Client Request
      │
      ▼
 [ ALB Listener: 443 ]
      ├── Rule 1: path /api/*  ──► [ Target Group: API ]  ──► (EC2 in AZ-a, AZ-b)
      └── Default Rule         ──► [ Target Group: Web ]  ──► (EC2 in AZ-a, AZ-b)

6. Cross-Zone Load Balancing & Connection Draining

(Reference: Official AWS Cross-Zone Load Balancing Guide)

Cross-Zone Balancing: If AZ-a has 2 servers and AZ-b has 8 servers, cross-zone balancing ensures every server across both AZs receives an equal 10% of the traffic. On ALB, it is enabled by default.
Connection Draining (Deregistration Delay): When removing an instance for updates or deployment, AWS stops sending new requests but allows in-flight requests to finish gracefully (default 300 seconds, customizable down to 30s).
Sticky Sessions: Uses an AWSALB cookie to tie a visitor to one specific server. (Best practice: keep apps stateless using Redis so you don't need sticky sessions).

7. EC2 Networking: Public vs. Private IPs & Elastic IPs

Every EC2 instance in a VPC gets assigned IP addresses:

Private IP: Permanent internal IP (e.g., 10.0.1.25) that stays with the instance for its entire life.
Public IP (Auto-assigned): Random public IP from Amazon's pool. Warning: If you stop and restart the instance, this IP changes!
Elastic IP (EIP): A fixed, permanent public IPv4 address that you own until you release it. You can re-associate it between standby servers in seconds.

8. Connecting to EC2 Without Open SSH Keys

Leaving port 22 open to 0.0.0.0/0 invites continuous bot attacks. AWS gives us three ways to connect:

Traditional SSH Key Pairs: Connect using ssh -i key.pem ec2-user@<ip>. Requires port 22 open.
EC2 Instance Connect: Pushes a temporary, one-time public key valid for only 60 seconds. No private key files to manage.
AWS Systems Manager (SSM) Session Manager (Recommended): Opens an interactive browser terminal using the outbound SSM agent. Requires ZERO open inbound ports in your Security Group!

9. Amazon EBS (Elastic Block Store) & Instance Store

Where does EC2 store its files?

Amazon EBS: Detachable virtual disks (like a USB drive for cloud).
- Lives in one specific Availability Zone.
- Survives instance stops and reboots.
- Types: gp3 (General Purpose SSD - default), io2 (Provisioned IOPS for high-speed databases), and st1/sc1 (cold HDDs).
EBS Snapshots: Point-in-time, incremental backups stored securely in S3. You can restore a snapshot into a new EBS volume in a different AZ or copy it to another AWS Region.
Instance Store (Ephemeral): Physical NVMe disks built directly into the host server. Blazing fast IOPS, but data is permanently wiped if the instance stops or terminates. Perfect for caches and scratch data.

Hands-On Practice & Console Walkthrough

Here is the step-by-step lab to launch two EC2 servers in different AZs and put an Application Load Balancer in front.

Step 1: Launch EC2 Web Instance

I launched an EC2 instance (t3.micro in eu-north-1b) and pasted this user-data script so Nginx installs and starts automatically on boot:

#!/bin/bash
dnf install -y nginx
echo "<h1>Hello from $(hostname -f)</h1>" > /usr/share/nginx/html/index.html
systemctl enable --now nginx

Fig 1: EC2 instance running in my AWS account.

Step 2: Configure Security Groups (`ec2-web-sg`)

I opened port 80 (HTTP) so the Load Balancer can talk to Nginx, and left outbound open for updates.

Fig 2: Security group configuration (ec2-web-sg).

Step 3: Create Target Group (`ec2-users`)

I created a target group pointing to port 80 with / as the health check path and registered the instance.

Fig 3: Target group ec2-users created for routing traffic.

Step 4: Create the Application Load Balancer (`alb`)

I created an internet-facing ALB named alb, enabled both eu-north-1a and eu-north-1b subnets, and pointed the port 80 listener to ec2-users.

Fig 4: Application Load Balancer active with its public DNS address.

Step 5: Local HAProxy & Failover Test

Before testing with multiple cloud instances, I ran a basic local test with 3 apps (app1, app2, app3) to see how round-robin and health checks work in real-time when a server crashes:

python lb_demo.py

Here is my actual terminal output:

![HAProxy / Python Load Balancer Terminal Run](

Fig 5: My terminal showing round-robin in Demo 1, and traffic instantly dropping app3 in Demo 2 when it failed.

Step 6: Clean Up

Don't forget to delete resources when finished so you don't get billed:

Deleted the ALB (alb)
Deleted the target group (ec2-users)
Terminated the EC2 instance

Cloud foundations & IAM

Rajesh — Mon, 26 Oct 2026 17:40:10 +0000

Why do we go for AWS?

Setting up your own physical servers means spending lakhs up front on hardware, electricity, cooling, and guessing how many servers you need.

AWS lets you rent computers and storage over the internet in seconds and pay only for the exact minutes or hours you use.

1. Cloud computing

Instead of buying and keeping bulky computers in your office room, you rent virtual machines and storage from huge data centres run by Amazon.

It works just like electricity at home: you don't build your own power station to turn on a fan, you just plug in and pay the monthly bill for the units you used.

2. Service models: IaaS, PaaS, SaaS

Think of how you eat dinner to understand how much you manage versus how much AWS manages:

IaaS (Infrastructure as a Service): Renting an empty kitchen. AWS gives you the physical server and network; you install the OS, setup Python/Node, and run your code.
- Example: Amazon EC2, Amazon VPC, Amazon EBS.
PaaS (Platform as a Service): Getting a meal kit with pre-chopped ingredients. You just write your app code and hand it over; AWS handles the OS, patching, and scaling.
- Example: AWS App Runner, AWS Elastic Beanstalk, Amazon RDS.
SaaS (Software as a Service): Sitting at a restaurant and eating food. Everything is fully built and managed; you just log in and use it.
- Example: Amazon QuickSight, Amazon Connect (or Gmail and Slack outside AWS).
Serverless (FaaS): Buying a snack from a vending machine. You write a single function and pay only when that function runs.
- Example: AWS Lambda.

3. Regions

A Region is a specific physical geographic location in the world where AWS operates a cluster of data centres (like Mumbai ap-south-1 or Singapore ap-southeast-1).

Each Region is completely independent. Your data stays in that Region and never leaves unless you intentionally copy or replicate it out.

How to choose a Region:

Compliance / Data laws: If your government rules say customer data must stay in India, pick Mumbai or Hyderabad.
Latency: Choose the location closest to your users so the site opens fast.
Available services: Brand new AWS services often arrive in us-east-1 (N. Virginia) first.
Price: Resource prices differ slightly across countries based on local taxes and power costs.

4. Availability Zones (AZs)

Inside every Region, AWS builds separate data centre clusters called Availability Zones (AZs) (for example: ap-south-1a, ap-south-1b, and ap-south-1c in Mumbai).

An AZ is made of one or more physical data centres with redundant power, backup generators, and cooling. They sit miles apart from each other so a flood or local power cut in one building doesn't hurt the other, but they are linked by super-fast private fibre cables.

Region: ap-south-1 (Mumbai)
 ├── ap-south-1a [Data Centre 1 + Data Centre 2]
 ├── ap-south-1b [Data Centre 3 + Data Centre 4]
 └── ap-south-1c [Data Centre 5 + Data Centre 6]

The 3 Core AZ Rules & Limitations:

Minimum 3 AZs per Region: Every standard AWS Region gives you at least 3 AZs for high availability.
AZ-Scoped Services: Certain resources live strictly inside one single AZ. An EC2 instance, an EBS volume, and a VPC Subnet can only exist in one AZ at a time. If that AZ goes dark and you don't have a backup in another AZ, your app goes down.
AZ Names are Random per Account: The name ap-south-1a in your account might actually map to a different physical building than your friend's ap-south-1a (to balance traffic across AWS buildings). The permanent true ID is the Zone ID (like aps1-az1).

5. Edge locations & Caching

Edge locations are hundreds of smaller branch offices in major cities (like Chennai, Bengaluru, Delhi, Frankfurt, New York) sitting right next to end-users.

They don't run heavy virtual servers. Instead, they run Amazon CloudFront (Content Delivery Network) and Amazon Route 53 (DNS).

When a user in Chennai asks for an image stored in a server in Ireland, CloudFront fetches it once and saves a local copy in Chennai's cache. The next user in Chennai gets the image in 10ms instead of waiting 250ms across the ocean.

6. IAM: Authentication, Authorisation, Root User, Users & Groups

AWS Identity and Access Management (IAM) is the free global security guard for your entire cloud account.

       [ Human / Developer ]
                 │
                 ▼ (Member of)
             [ Group ]
                 │
                 ▼ (Has Attached)
          [ JSON Policies ] ◄──── Sets rules (Effect, Action, Resource)

Authentication vs. Authorisation

Authentication (Who are you?): Checking your credentials. At a building gate, this is the security guard looking at your photo ID card or checking your password and MFA code.
Authorisation (What can you do?): Checking the rulebook. Can your badge open the server room door? Or are you only allowed in the lobby? In AWS, IAM checks if you have permission to run s3:GetObject or ec2:StartInstances.

The Root User

The root user is the primary email address used to create the AWS account.
It has absolute god-mode access and can delete everything. You cannot restrict root using normal IAM policies.
Best practice: Lock root with Multi-Factor Authentication (MFA), delete any root access keys, and never use root for daily work.

IAM Users

A unique personal login created for one specific person or application.
Each user gets their own password for the AWS console or access keys (AKIA...) for the CLI.
If a team member leaves, you disable only their IAM user without breaking anyone else's access.

IAM Groups

A collection of IAM users (like a developers or finance department).
Instead of adding policies to 20 users one by one, attach the policy to the group. Anyone added to the group automatically gets those rights.
Note: Groups cannot be nested inside other groups.

7. Policies (JSON)

An IAM Policy is a simple JSON document that writes down permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadCompanyReports",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::company-reports",
        "arn:aws:s3:::company-reports/*"
      ],
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

The Anatomy of a Policy:

Version: Always use "2012-10-17" (the current policy language version).
Effect: Either "Allow" or "Deny".
Action: The exact API call you are allowing or blocking (e.g. s3:GetObject, ec2:RunInstances).
Resource: The ARN (Amazon Resource Name) of the target. Notice the S3 difference:
- arn:aws:s3:::company-reports = the bucket itself (needed to list bucket contents).
- arn:aws:s3:::company-reports/* = the files inside the bucket (needed to download files).
Condition: Extra safety checks (e.g., only allow if MFA is turned on, or only from office IP).

8. How AWS evaluates a request: Deny always wins!

When you click a button or type a CLI command, IAM checks all policies attached to you using a strict order:

(Reference: Official AWS IAM Evaluation Guide)

       Incoming Request (e.g. s3:DeleteObject)
                         │
                         ▼
             Is there an Explicit DENY?
                   /           \
                 YES            NO
                 /                \
          [ DENY Access ]     Is there an Explicit ALLOW?
                                 /           \
                               YES            NO
                               /                \
                       [ ALLOW Access ]    [ DENY Access ]
                                           (Default Deny)

Default is Deny: Everything starts completely locked. If no policy mentions your action, you are blocked.
Explicit Allow: If a policy says "Allow", you get access.
Explicit Deny ALWAYS Trumps: If any policy anywhere says "Deny", that request is instantly blocked. An explicit Deny kills any Allow, every single time.

9. Roles and STS: Temporary logins

Why do we need Roles if we already have IAM users?

Because storing permanent access keys (AKIA...) on EC2 servers or in .env files is dangerous. If code leaks to GitHub, bots grab those keys in seconds and run up huge bills.

[ EC2 Server / Lambda / GitHub Actions ]
                   │
                   ▼ (Calls sts:AssumeRole)
        [ AWS STS (Token Service) ]
                   │
                   ▼ (Generates)
    [ Temporary Access Keys (ASIA...) ]
      • Valid for 15 mins to 12 hours
      • Rotates automatically

How Roles Work:

A Role is an identity that has no password and no permanent secret key.
When an EC2 server or Lambda function needs to read an S3 bucket, it asks AWS STS (Security Token Service) to assume the role.
STS hands back temporary credentials (starts with ASIA...) that expire automatically in minutes or hours.
The AWS SDK rotates them automatically behind the scenes. No permanent keys ever sit on your server disk.

The Two Sides of Every Role:

Trust Policy (Who can wear the badge?): Specifies which service or account is allowed to assume the role (e.g., ec2.amazonaws.com).
Permissions Policy (What can you do while wearing it?): The normal JSON policy specifying allowed actions (e.g., read files from S3).

Hands-On Practice & Console Walkthrough

Here is the exact hands-on practice I did today inside my AWS account, along with the console setups and CLI steps.

Step 1: Setting up an IAM User, Group & Policy (Console)

First, I went to the IAM console so I don't work as root anymore.

Created an IAM User: Gave it console access with a custom password and required password reset.
Created an IAM Group: Named it developers and attached the ReadOnlyAccess policy to it.
Added User to Group: Put my new user into the developers group.

Fig 1: Creating a dedicated IAM user with console access and custom password.

Fig 2: Adding the user to the developers user group with ReadOnlyAccess policy attached.

Step 2: Creating an IAM Role for Testing

Next, I created an IAM Role named lab-s3-reader to test temporary access:

Chose AWS account as the trusted entity so my current user can assume it.
Attached AmazonS3ReadOnlyAccess to the role.
Verified the trust relationship policy.

Fig 3: Setting up the IAM role trust policy and testing permissions.

Step 3: Terminal POC (Testing with AWS CLI)

Before running commands from your local computer's terminal, you need credentials for the CLI:

1. Generating Your Access Key

In the IAM Console, go to Users → click your user name → open the Security credentials tab.
Scroll down to Access keys and click Create access key.
Choose Command Line Interface (CLI), acknowledge the recommendation, and click next.
AWS will give you two values:
- Access key ID: A public identifier starting with AKIA...
- Secret access key: A private string.

Important Warning from AWS:

If you lose or forget your secret access key, you cannot retrieve it again. Instead, you must delete or deactivate the old key and create a new one. Download the .csv file or keep it safe.

Fig 4: Generating and managing Access Keys inside the Security Credentials tab.

2. Configure AWS CLI

In your local terminal, run:

aws configure

Paste your Access Key ID, Secret Access Key, default region (e.g., ap-south-1), and default output format (json).

3. Test your connection

Check who you are logged in as:

aws sts get-caller-identity

This prints your Account ID, User ID, and user ARN so you know your keys are active.

4. Create a test S3 bucket in Mumbai and upload a file

# S3 bucket names must be globally unique, so we add a random number
aws s3 mb s3://my-test-bucket-$RANDOM --region ap-south-1

# Make a small test text file and copy it to your bucket
echo "Session 1 complete" > test.txt
aws s3 cp test.txt s3://<your-bucket-name>/

# List the files inside your bucket
aws s3 ls s3://<your-bucket-name>/

5. Clean up before closing

Always delete test buckets right after you finish so your account stays tidy and free:

aws s3 rb s3://<your-bucket-name>/ --force

Session 1 Key Takeaways

Things I made sure to check off today:

Locked my root account with an MFA app right away and stopped using it for daily work.
Created a $5 budget alert in AWS Budgets so I get an email before any surprise bill hits.
Remembered the golden IAM rule: if even one policy has an explicit Deny, it immediately blocks the request no matter what else says Allow.
Stopped putting secret access keys into code or server folders—using IAM Roles with STS temporary tokens instead.

How to Configure Inter-Region VPC Peering

Rajesh — Fri, 14 Aug 2026 18:26:15 +0000

If you have servers running in different AWS Regions, you may need to allow the workloads on those servers to communicate privately.

For example, an application running in Hyderabad might need to communicate with a database running in Sydney using private IPs.

In this how-to, I'll show you how I peered two VPCs in different AWS Regions and connected them using VPC Peering.

Architecture

Assume for this lab that the following architecture is required to be configured:

Region A

Hyderabad

vpc-a-peering-connection (CIDR: 10.0.0.0/16)

subnet: 10.0.1.0/24

Region B

Sydney

vpc-b-peering-connection (CIDR: 10.1.0.0/16)

subnet: 10.1.1.0/24

Make sure that the CIDR ranges do not overlap on the VPCs as you can't peer VPCs with overlapping CIDRs

1. Creating the VPCs and instances

I first proceeded to create the VPCs and launched instances in them

Navigating to Hyderabad region, I created a vpc-a-peering-connection VPC, public subnet, internet gateway, and a route table. Then I launched a simple Ubuntu EC2 instance in the region

Our region A VPC is created:

The public subnet that I created in Hyderabad region:

The Internet Gateway attached to my Hyderabad VPC:

I then switched to Sydney region and created similar resources in that region as well

The Sydney VPC is created:

The subnet in Sydney region:

The Internet Gateway attached to my Sydney VPC:

For this lab, I launched my EC2 instances in public subnets so that they can be easily accessed for testing. The VPC peering connection does not require the subnet to be public or VPC to have an Internet Gateway

At this point, a ping from the Hyderabad instance to the Sydney instance will fail because there is no route between the two VPCs yet.

2. Creating the peering connection

Now, I proceeded to create the peering connection

I navigated to VPC Dashboard in Hyderabad region, clicked Peering connections, and created a new one

I gave it a name VPC-A to VPC-B, chose my vpc-a-peering-connection as the Requester, and another region as Accepter and Sydney as the region

I chose the vpc-b-peering-connection as the accepter VPC and clicked create

The peering connection request was sent and is awaiting approval:

3. Accepting the connection

Switching to Sydney region, I navigated to Peering connections and accepted the request:

You can now see that the peering connection is active. The next thing to do is to update the route tables

4. Updating the route tables

I navigated to Route Tables and selected the route table associated with the subnet where I launched my EC2 Instance

I added a route to the Sydney VPC:

Destination: 10.1.0.0/16

Target: Peering Connection (selected the PCX created earlier)

I did the same thing in the Sydney region to route traffic back to Hyderabad:

Destination: 10.0.0.0/16

Target: Peering Connection

This route table in Hyderabad now has a route to the Sydney VPC via the peering connection:

The Sydney route table now has a route back to the Hyderabad VPC

5. Updating the security groups

The route tables are now updated, but we also need to allow ICMP traffic in the security groups for the ping test to work.

In the security group of my EC2 instance in Hyderabad region, I updated the Inbound rules to explicitly allow All ICMP - IPv4 from the source 10.1.0.0/16:

(Note: In the above image, there is a TCP rule from another lab. For ICMP traffic, we need the All ICMP - IPv4 inbound traffic rule)

Similarly, in the security group in Sydney, I updated the Inbound rules to allow All ICMP - IPv4 from the source 10.0.0.0/16:

I explicitly allowed the inbound ICMP rules in Sydney. If you have the default outbound rule (All traffic - 0.0.0.0/0) as Allow, there is no need to add an outbound rule for this ping test

6. Testing the connection

I then SSH'd back into my instance in Hyderabad region and did a ping to the private IP address of the instance in Sydney region. It worked after updating the security group:

Now, the two instances can communicate with each other over the AWS network via private IPs

Things to note

You can't establish a VPC Peering connection between VPCs with overlapping IPv4 or IPv6 CIDR blocks
VPC Peering is not transitive. If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot communicate with VPC C through VPC B. You need a separate peering connection between A and C. If you have many VPCs, AWS Transit Gateway can provide a centralized way to connect them.

Now you know how to configure inter-Region VPC peering. The peering connection provides the path between the VPCs, but you still need the correct route table entries and security group rules on both sides.

EC2 in Real Life: A Simple Blog Note for Beginners

Rajesh — Sun, 28 Jun 2026 17:00:33 +0000

I wrote this like I would explain to a junior in a lab session. No heavy words, no theory overload. Just what matters when you actually create and use an EC2 machine.

Small intro

When we say "EC2," think of one thing: a computer on rent. You do not buy hardware. You open AWS, pick a machine size, and start using it.

That is why most people start cloud learning with EC2.

1) What is EC2?

EC2 stands for Elastic Compute Cloud.

Simple meaning:

It is a virtual server in AWS.
You can install software in it like your own laptop.
You can run website, backend API, database, scripts, anything.

Why "Elastic"?
Because you can scale up or down based on traffic.

If today only 10 users come, small server is enough.
If tomorrow 10,000 users come, you can move to bigger machine or add more machines.

2) EC2 pricing model (the part everyone asks first)

AWS gives multiple payment options. Choose based on your situation.

On-Demand

Use and pay. No long commitment.
Best for:

Learning
Demo
Testing new features

Reserved Instances

You commit for long term (usually 1 or 3 years).
Cost is lower than on-demand.
Best for:

Stable production apps
Predictable workloads

Spot Instances

Very cheap (sometimes huge discount), but AWS can reclaim it.
Best for:

Batch jobs
Video processing
Non-critical tasks Not best for always-on production.

Savings Plans

You commit to a certain usage/spend level over time.
Good discount and some flexibility.

Quick student rule:

New to AWS -> start On-Demand.
Predictable long-term app -> compare Reserved/Savings.
Cost-first experiments -> try Spot.

3) Instance families (machine categories)

All EC2 machines are not same. AWS groups them by purpose.

General purpose

Balanced CPU + RAM.
Example family: T series, M series.
Good for normal web apps and learning.

Compute optimized

More CPU power.
Example family: C series.
Good for CPU-heavy tasks like rendering, transforms, game servers.

Memory optimized

More RAM.
Example family: R series.
Good for cache/database memory-heavy apps.

Storage optimized

Fast/high-throughput disk access.
Example family: I series.
Good for data-intensive workloads.

A common beginner pick is t3.micro or t2.micro style instance (based on region/free-tier rules).

4) What is AMI image?

AMI means Amazon Machine Image.

AMI is like a prebuilt template used to launch an EC2 instance.
It contains:

OS (Ubuntu, Amazon Linux, Windows, etc.)
Base config
Sometimes preinstalled tools

Two common types:

Public AMI: provided by AWS or marketplace/community
Private AMI: custom image prepared by your org/team

Easy memory trick: AMI is the "starter pack" for your EC2 machine.

5) SSH, public key, private key (important)

When you connect to Linux EC2, usually you use SSH.

You create/use a key pair:

Public key -> placed on server side
Private key (.pem) -> stays only with you

Never share private key. Ever.
If private key leaks, server access risk is high.

Basic command:

ssh -i mykey.pem ubuntu@<EC2_PUBLIC_IP>

Common usernames:

Ubuntu AMI -> ubuntu
Amazon Linux -> ec2-user

If permission issue comes for key file, set strict permission:

chmod 400 mykey.pem

6) Install Nginx and host first static file in /var/www/html

Assume Ubuntu EC2.

Install and start Nginx

sudo apt update
sudo apt install -y nginx
sudo systemctl start nginx
sudo systemctl enable nginx

Put first static page

echo "<h1>My first EC2 static page</h1>" | sudo tee /var/www/html/index.html

Now open:

http://<EC2_PUBLIC_IP>

If port 80 is open in Security Group, page will load.

7) Flask Hello World host on port 8080 + Security Group

Install Python + Flask

sudo apt update
sudo apt install -y python3 python3-pip
pip3 install flask

Create app.py

from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World from Flask running on EC2"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Run it

python3 app.py

Security Group for port 8080

In AWS Console:

EC2 -> Instances -> select your instance
Security -> click Security Group
Inbound rules -> Edit inbound rules
Add rule:
- Type: Custom TCP
- Port: 8080
- Source: 0.0.0.0/0 (only for demo/testing)

Now test in browser:

http://<EC2_PUBLIC_IP>:8080

You should see your hello message.

Production note:
Do not keep wide-open rules forever. Restrict CIDR, use reverse proxy, and enable HTTPS.

One-page final summary

EC2 is a cloud server you can rent in minutes.
You choose pricing model based on your budget and stability needs.
Instance families help you pick the right machine for CPU, memory, or storage focus.
AMI is the base image used to launch the instance.
SSH key pair is how you securely log in.
Nginx helps you host static pages from /var/www/html.
Flask can run on port 8080, and you must allow that port in Security Group.

If you can do these steps once by yourself, you already have strong EC2 fundamentals.

DEV Community: Rajesh

AWS VPC Peering: How to Connect Two VPCs Privately

Connecting Two AWS VPCs Using VPC Peering 🚀

What is VPC Peering?

How can we connect two VPCs?

One important thing to remember

Can three VPCs communicate through Peering?

Important points to know

When should we use VPC Peering?

AWS NAT Gateway: Giving Private Subnets Safe Internet Access

Why do we need a NAT Gateway?

1. What is NAT (Network Address Translation)?

How the packets travel:

2. Internet Gateway (IGW) vs. NAT Gateway

3. How the Route Tables Work

4. NAT Gateway vs. NAT Instance

What is a Private NAT Gateway?

5. High Availability (HA) & Saving Money

Multi-AZ Setup (Production)

How to avoid surprise bills:

Hands-On Practice & Console Walkthrough

Step 1: Create the NAT Gateway

Step 2: Route the Private Subnet to the NAT Gateway

Step 3: Test from the Private Instance

Step 4: Verify Outside Inbound Traffic is Blocked

Step 5: Clean Up (Avoid Surprise Bills!)

Wrap-up

AWS VPC: Public & Private Subnets with EC2 & Docker

Why do we need a custom VPC & Subnets?

1. The VPC (Virtual Private Cloud) & CIDR Planning

2. Subnets & The 5 Reserved AWS IPs

3. Route Tables: What Actually Makes a Subnet "Public"?

4. The Internet Gateway (IGW)

5. Security Groups vs. Network ACLs (NACLs)

6. Official VPC Multi-Tier Architecture

Hands-On Practice & Console Walkthrough

Step 1: Create the Custom VPC (lab-vpc)

Step 2: Create Public & Private Subnets

Step 3: Create & Attach the Internet Gateway (lab-igw)

Step 4: Create the Public Route Table (public-rt)

Step 5: Launching an EC2 Instance into the Custom VPC

Step 6: Clean Up (Avoid Surprise Bills!)

Compute & Load Balancing

Why do we need Load Balancing & Managed Compute?

1. Scaling Up vs. Scaling Out

2. Load Balancing Algorithms

3. Health Checks: Catching Dead Servers

4. The 3 AWS Elastic Load Balancers (ALB, NLB, GWLB)

5. Listeners, Rules & Target Groups

6. Cross-Zone Load Balancing & Connection Draining

7. EC2 Networking: Public vs. Private IPs & Elastic IPs

8. Connecting to EC2 Without Open SSH Keys

9. Amazon EBS (Elastic Block Store) & Instance Store

Hands-On Practice & Console Walkthrough

Step 1: Launch EC2 Web Instance

Step 2: Configure Security Groups (ec2-web-sg)

Step 3: Create Target Group (ec2-users)

Step 4: Create the Application Load Balancer (alb)

Step 5: Local HAProxy & Failover Test

Step 6: Clean Up

Cloud foundations & IAM

Why do we go for AWS?

1. Cloud computing

2. Service models: IaaS, PaaS, SaaS

3. Regions

4. Availability Zones (AZs)

The 3 Core AZ Rules & Limitations:

5. Edge locations & Caching

6. IAM: Authentication, Authorisation, Root User, Users & Groups

Authentication vs. Authorisation

The Root User

IAM Users

IAM Groups

7. Policies (JSON)

The Anatomy of a Policy:

8. How AWS evaluates a request: Deny always wins!

9. Roles and STS: Temporary logins

How Roles Work:

The Two Sides of Every Role:

Hands-On Practice & Console Walkthrough

Step 1: Create the Custom VPC (`lab-vpc`)

Step 3: Create & Attach the Internet Gateway (`lab-igw`)

Step 4: Create the Public Route Table (`public-rt`)

Step 2: Configure Security Groups (`ec2-web-sg`)

Step 3: Create Target Group (`ec2-users`)

Step 4: Create the Application Load Balancer (`alb`)