DEV Community: Hritik Raj

Building a Global HTTP Load Balancer with Managed Instance Groups

Hritik Raj — Sat, 28 Feb 2026 16:05:51 +0000

🚀 Scaling Applications the Right Way: My First GCP Load Balancer Setup

Hey Engineers 👋

Today, I stepped into something that every production system relies on a Global HTTP Load Balancer on Google Cloud Platform.

Instead of running a single VM and hoping it survives traffic spikes, I built a proper architecture with:

Managed Instance Group
Health Checks
Backend Service
Global HTTP Load Balancer

Let’s break it down.

🎯 Objective

Create an Instance Template with Nginx installed
Launch 2 VM instances using a Managed Instance Group
Configure HTTP Health Checks
Create a Global HTTP Load Balancer
Verify traffic distribution across VMs

🏗️ Architecture Overview

This setup ensures:

High availability
Traffic distribution
Automatic health monitoring

🛠️ Phase A: Create Instance Template

I first created an Instance Template to ensure uniform VM configuration.

Machine Type: e2-micro

Region: us-central1

Firewall: Allow HTTP traffic

Startup Script:

#!/bin/bash
apt update -y
apt install nginx -y
echo "Hello from $(hostname)" > /var/www/html/index.html
systemctl restart nginx

Each VM now serves its hostname via Nginx.

🛠️ Phase B: Create Managed Instance Group

Using the template, I created a Managed Instance Group (MIG) with:

2 instances
Same zone
Auto-healing enabled

Why MIG?

Because:

Ensures identical VM deployment
Supports auto scaling
Works seamlessly with Load Balancer

🛠️ Phase C: Configure Health Check

I created an HTTP health check with:

Protocol: HTTP
Port: 80
Path: /

This ensures the Load Balancer only routes traffic to healthy instances.

Without this, traffic distribution will fail.

🛠️ Phase D: Create Global HTTP Load Balancer

Under:

Network Services → Load Balancing → Create Load Balancer

Configuration:

Backend

Backend Type: Instance Group
Attached: Managed Instance Group
Attached: Health Check

Frontend

Protocol: HTTP
IP: Ephemeral public IP

Deployment took around 3–5 minutes (important: GCP takes time to propagate globally).

✅ Testing Traffic Distribution

After deployment, I accessed the Load Balancer IP in the browser.

Refreshing multiple times showed:

Hello from instance-1
Hello from instance-2
Hello from instance-1

To test via terminal:

while true; do curl http://LOAD_BALANCER_IP; sleep 1; done

This confirmed proper traffic rotation.

🧠 Key Concepts Learned

Managed Instance Groups simplify scaling.
Health checks are mandatory for traffic routing.
Firewall rules directly impact load balancer behaviour.
Global HTTP Load Balancer configuration takes propagation time.

🚀 What’s Next

To take this further, I plan to:

Enable auto scaling
Add HTTPS with SSL certificates
Attach a custom domain
Deploy a real application instead of static Nginx

📝 Final Thoughts

This was my first hands-on experience building a scalable web architecture in GCP.

Instead of just reading about load balancing, I implemented it debugged it and understood how production-grade systems maintain availability.

That’s the difference between theory and engineering.

🔗 Let’s Connect

💼 LinkedIn: https://www.linkedin.com/in/hritik-raj-8804hr/

If you're also building in cloud, let’s learn together 🚀

💽 AWS 150: Zero-Downtime Storage Scaling - Expanding EBS Volumes

Hritik Raj — Fri, 30 Jan 2026 04:05:39 +0000

🚀 Scaling without Stopping: Expanding EBS Volumes on the Fly

Hey Cloud Architects 👋

Welcome to Day 50 of the #100DaysOfCloud Challenge!

Today, we are solving a common production headache: a server running out of disk space. The datacenter-ec2 instance is hitting its limit, and we need to increase its storage from 8 GiB to 12 GiB. We’ll be performing a "hot" expansion modifying the infrastructure in the AWS Console and then extending the filesystem via the CLI all without a reboot.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which is perfect for mastering Linux storage management.

🎯 Objective

Identify the Elastic Block Store (EBS) volume attached to datacenter-ec2.
Modify the volume size in the AWS Management Console from 8 GiB to 12 GiB.
SSH into the instance using the provided .pem key.
Use Linux CLI tools (growpart and resize2fs or xfs_growfs) to reflect the new size in the root partition.

💡 Why Online Expansion?

In a traditional data center, adding storage often meant downtime, mounting new drives, or complex RAID re-configurations. With AWS EBS, the physical hardware change is virtualized. However, increasing the "container" size (the volume) doesn't automatically grow the "room" inside (the partition and filesystem). We must manually tell the OS to use the newly available space.

🔹 Key Concepts

Elastic Block Store (EBS): Scalable block-level storage volumes for EC2 instances.
Volume Modification: The AWS API action that changes the block device size.
Partition vs. Filesystem: The partition is the "slice" of the disk, while the filesystem (like ext4 or XFS) is the actual data structure inside that slice. Both must be expanded.

🛠️ Step-by-Step: Storage Workflow

🔹 Phase A: AWS Console Modification

First, we tell AWS to increase the physical allocation of the block device.

Find Volume: Navigate to the EC2 Dashboard, select datacenter-ec2, and click on the "Storage" tab to find the Volume ID.

Modify Volume: Go to Volumes, select the ID, click Actions > Modify Volume.

New Size: Change the size from 8 to 12 GiB and click Modify.
Status: Wait for the volume state to show "in-use - optimized" (though you can proceed while it's optimizing).

🔹 Phase B: Connect to the Instance

Now we move to the command line to finalize the change within the OS.

SSH Command: Use the key located at /root/datacenter-keypair.pem.

  ssh -i /root/datacenter-keypair.pem ubuntu@<EC2_PUBLIC_IP>

Verify Block Device: Run lsblk to confirm the OS sees 12GB at the disk level but still shows 8GB at the partition level.

🔹 Phase C: Expanding the Partition (CLI)

We must extend the partition to fill the new 12GB of space.

Grow Partition: Use the growpart command on the root disk (usually /dev/xvda or /dev/nvme0n1).

sudo growpart /dev/xvda 1

Verify: Run lsblk again. You should now see the partition size has increased to 12G.

🔹 Phase D: Expanding the Filesystem (CLI)

The final step is to stretch the filesystem into the new partition space.

Check Filesystem Type: Run df -hT to see if it is ext4 or xfs.
Resize (for ext4):

sudo resize2fs /dev/xvda1

Resize (for XFS):

sudo xfs_growfs -d /

✅ Verify Success

Disk Usage Check: Run df -h and confirm that / now shows a total size of 12 GiB.
Service Health: Ensure your application is still running without issues.

📝 Key Takeaways

🚀 No Reboot Needed: Modern Linux kernels and EBS volumes support live resizing, which is critical for 24/7 operations.
🛡️ Snapshot First: In production, always take an EBS Snapshot before modifying a volume, just in case something goes wrong during the partition resize.
📦 Optimization Time: While the size change is immediate, the underlying AWS hardware may take time to "optimize" the performance of the new space.

🚫 Common Mistakes

Incorrect Device Name: Running growpart on the wrong disk or forgetting the partition number (the 1 in /dev/xvda 1).
Skipping the Filesystem: Many forget the resize2fs step; if you skip this, lsblk will show 12GB but df -h will still show 8GB.
Permission Denied: Always use sudo for storage commands as they require root-level access to the block devices.

🌟 Final Thoughts

Storage management is a bread-and-butter skill for DevOps. By mastering the transition from AWS Console changes to Linux CLI execution, you ensure that your team's development environment stays performant and scalable without ever hitting a "Disk Full" wall.

🌟 Practice Like a Pro

Want to master Linux storage and AWS EBS? Practice here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud

🌐 AWS 149: Multi-VPC Log Aggregation - Peering, IAM Roles, and S3 Integration

Hritik Raj — Thu, 29 Jan 2026 09:45:57 +0000

🚀 Secure Pipelines: Aggregating Logs across Private and Public VPCs

Hey Cloud Architects 👋

Welcome to Day 49 of the #100DaysOfCloud Challenge!
Today, we are building a sophisticated log management architecture. The Nautilus DevOps team needs to move logs from an isolated private environment to a public aggregation server, and finally to long-term storage in S3. This requires mastering VPC Peering, Route Tables, and IAM Instance Profiles to ensure data flows securely across different network boundaries.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which provides excellent scenarios for complex networking.

🎯 Objective

Provision a Public VPC (devops-pub-vpc) with an Internet Gateway and proper routing.
Launch a public aggregator instance (devops-pub-ec2) with an IAM role for S3 access.
Establish a VPC Peering Connection between the private and public VPCs.
Update Route Tables in both VPCs to allow traffic via the peering link.
Automate log transfers using cron jobs to move boots.log from Private EC2 ➔ Public EC2 ➔ S3 Bucket.

💡 Why VPC Peering for Log Collection?

VPC Peering allows you to connect two VPCs using private IP addresses. This means traffic between your instances never traverses the public internet, reducing latency and increasing security. It's the standard way to connect a "Management" or "Logging" VPC to your "Production" VPCs.

🔹 Key Concepts

VPC Peering: A networking connection between two VPCs that enables you to route traffic between them privately.
IAM Instance Profile: Attaching a role directly to an EC2 instance so it can interact with S3 without needing hardcoded credentials.
CIDR Routing: Explicitly telling each VPC how to reach the other by adding destination CIDR blocks to the Route Tables.

🛠️ Step-by-Step: Infrastructure & Log Workflow

🔹 Phase A: Building the Public Infrastructure

We need a landing zone for our logs that has internet access to reach the S3 service.

VPC Setup: Create devops-pub-vpc and attach an Internet Gateway.
Public Route Table: Configure devops-pub-rt with a route 0.0.0.0/0 targeting the IGW.
Public Instance: Launch devops-pub-ec2 using the devops-key.pem.
IAM Role: Create devops-s3-role with PutObject permissions and attach it to the public instance.

🔹 Phase B: Establishing the Peering Connection

Now we "bridge" the two VPCs so they can communicate over private IPs.

Peering Request: Create devops-vpc-peering from the private VPC to the public VPC.
Acceptance: Accept the peering request in the console.
Route Table Updates: * In devops-priv-rt, add a route to the Public VPC CIDR via the Peering Connection.
- In devops-pub-rt, add a route to the Private VPC CIDR via the Peering Connection.

🔹 Phase C: Log Transfer Configuration (Private ➔ Public)

On the devops-priv-ec2 instance, we set up the first leg of the journey.

SSH Setup: Ensure the public key is trusted between instances.
Cron Job: Set a cron task to periodically send the log file.
- * * * * * scp -i ~/.ssh/devops-key.pem /var/log/boots.log ubuntu@<PUBLIC_INSTANCE_PRIVATE_IP>:/tmp/

🔹 Phase D: Final Upload (Public ➔ S3)

On the devops-pub-ec2 instance, we handle the final archival.

S3 Bucket: Create the private bucket devops-s3-logs-28057.
Cron Job: Set a cron task to push the local file to S3 using the AWS CLI.
- * * * * * aws s3 cp /tmp/boots.log s3://devops-s3-logs-xxxx/devops-priv-vpc/boot/boots.log

✅ Verify Success

Peering Status: The connection is marked as "Active" in the VPC console.
Security Check: The devops-priv-ec2 can ping or SSH into devops-pub-ec2 using its Private IP.
Final Archival: Confirm the file exists in S3.

📝 Key Takeaways

🚀 Zero Credentials: By using an IAM Role on the public EC2, we avoided storing secret keys on the server.
🛡️ Network Isolation: The private instance remains private; it only communicates with our trusted public aggregator over the peering link.
📦 Standardized Paths: Using bucket prefixes (folders) like devops-priv-vpc/boot/ makes it easier to manage logs as your infrastructure grows.

🚫 Common Mistakes

Overlapping CIDRs: VPC Peering will fail if both VPCs use the exact same IP range (e.g., both using 10.0.0.0/16).
Missing Route Back: Remember that routing is a two-way street; if you only update the private RT, the public instance won't know how to send a response back.
Security Group Blocks: Ensure the Security Group on the public instance allows inbound SSH/SCP traffic from the Private VPC's CIDR range.

🌟 Final Thoughts

Building a multi-tier logging architecture is a hallmark of professional cloud engineering. You've successfully implemented a system that is secure, automated, and scalable. This setup ensures that critical logs are always backed up while maintaining strict network isolation for your private assets.

🌟 Practice Like a Pro

Want to master VPC Peering and secure data pipelines? Get hands-on experience here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud

📜 AWS 148: Serverless IaC - Deploying Python Lambda Functions via CloudFormation

Hritik Raj — Wed, 28 Jan 2026 05:24:21 +0000

🏗️ Automated Serverless: Building the nautilus-lambda-app Stack

Hey Cloud Architects 👋

Welcome to Day 48 of the #100DaysOfCloud Challenge!
Today, we are moving beyond manual console clicks and embracing Infrastructure as Code (IaC) to deploy serverless logic. The Nautilus DevOps team is standardizing their function deployments, and we are creating a CloudFormation template to provision a Python-based Lambda function and its security role in one go.

This task is part of my hands-on practice on the KodeKloud Engineer platform, ensuring perfect configuration for automated environments.

🎯 Objective

Author a CloudFormation template (nautilus-lambda.yml) for a serverless application.
Provision an IAM Execution Role named lambda_execution_role with trust relationships for Lambda.
Create a Lambda function named nautilus-lambda using the Python runtime.
Implement inline code that returns a 200 OK status and the message "Welcome to KKE AWS Labs!".
Deploy the stack named nautilus-lambda-app and verify success via the AWS Console.

💡 Why Inline Code in CloudFormation?

For simple functions, CloudFormation allows you to embed your Python code directly in the YAML file using the ZipFile property. This is highly efficient for utility scripts or simple APIs because you don't need to manage separate .zip files in S3 buckets for the initial deployment.

🔹 Key Concepts

Execution Role: The identity the Lambda function "assumes" to run. It must have a trust policy allowing lambda.amazonaws.com to use it.
Inline Handler: In Python, the default handler is usually index.lambda_handler.
Stack Management: Using a stack allows you to update or delete the function and its role as a single unit.

🛠️ Step-by-Step: IaC Workflow

🔹 Phase A: Authoring the nautilus-lambda.yml Template

The template must define the IAM role first so the Lambda function can reference it immediately.

File Path: /root/nautilus-lambda.yml
Configuration: Use Type: AWS::IAM::Role for the execution role and Type: AWS::Lambda::Function for the compute resource.
Logic: The ZipFile property under Code should contain the lambda_handler function returning the specific "Welcome to KKE AWS Labs!" string.

🔹 Phase B: Deploying the Stack via Console

With the YAML file ready, we use the AWS Management Console to create the resources.

Upload: Upload the nautilus-lambda.yml file in the CloudFormation dashboard.
Stack Name: Set it to nautilus-lambda-app.
Capabilities: You must check the box "I acknowledge that AWS CloudFormation might create IAM resources" before clicking Create.

🔹 Phase C: Verification of Resources

Once the status is CREATE_COMPLETE, we verify the components.

Lambda Inspection: Navigate to the Lambda console and ensure nautilus-lambda is present and using the Python runtime.
Execution: Run a test event to confirm the output.

🔹 Phase D: Confirming Output

The final test is ensuring the logic matches the requirement perfectly.

Status: 200
Body: "Welcome to KKE AWS Labs!"

✅ Verify Success

Stack Identity: The stack nautilus-lambda-app shows CREATE_COMPLETE.
Code Integrity: The function code exactly matches the requirement message.
Security: The function is correctly linked to the lambda_execution_role.

📝 Key Takeaways

🚀 CAPABILITY_IAM: When your template creates roles, AWS requires explicit permission to do so don't miss that checkbox in the console!
🛡️ Inline Limitations: ZipFile is limited to 4096 characters. For larger applications, you should upload your code to S3 first.
📦 Handler Mapping: index.lambda_handler tells AWS to look for a function called lambda_handler inside a virtual file named index.py.

🚫 Common Mistakes

YAML Indentation: A single misplaced space in the ZipFile block will cause the Python code to fail with a SyntaxError.
Trust Policy Missing: If the IAM role doesn't have a Trust Relationship with lambda.amazonaws.com, the function will not launch.
Case Sensitivity: Ensure the stack name and function name exactly match the requirements, as AWS is case-sensitive.

🌟 Final Thoughts

Building serverless apps through CloudFormation is the bridge between development and production. It ensures your infrastructure is as professional as your code. You've now successfully automated the deployment of a secure, functional AWS Lambda environment!

🌟 Practice Like a Pro

Want to master Infrastructure as Code? Sharpen your skills here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud

📜 AWS 147: Infrastructure as Code - Priority Queuing with SNS, SQS, and CloudFormation

Hritik Raj — Tue, 27 Jan 2026 05:50:57 +0000

🏗️ Automated Priorities: Deploying SQS & SNS with CloudFormation

Hey Cloud Architects 👋

Welcome to Day 47 of the #100DaysOfCloud Challenge!
Today, we are moving away from manual console configuration and embracing Infrastructure as Code (IaC). The Nautilus DevOps team needs a reliable priority queuing system where "High Priority" messages are processed before "Low Priority" ones. We'll be using AWS CloudFormation to deploy an entire stack consisting of SNS, multiple SQS queues, and a Lambda consumer.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which is essential for mastering automated resource provisioning.

🎯 Objective

Author a CloudFormation template (nautilus-priority-stack.yml) to define the infrastructure.
Provision two SQS queues: nautilus-High-Priority-Queue and nautilus-Low-Priority-Queue.
Create an SNS Topic to act as the message dispatcher.
Deploy a Lambda function with an IAM role (lambda_execution_role) to consume and process messages.
Verify the priority logic by publishing attributed messages via the AWS CLI.

💡 Why Priority Queuing?

In production, not all data is created equal. Some messages (like payment processing) must be handled immediately, while others (like weekly reports) can wait. By using SNS message attributes and SQS subscriptions, we can route urgent data to a dedicated "Fast Track" queue.

🔹 Key Concepts

CloudFormation Stack: A single unit of management for a collection of AWS resources defined in a YAML or JSON template.
SNS Subscription Filter Policies: The logic that tells SNS: "Only send messages with the attribute priority: high to this specific queue."
Lambda Trigger: The mechanism that automatically invokes our function as soon as a message lands in either queue.

🛠️ Step-by-Step: IaC Workflow

🔹 Phase A: Authoring the Template

We define our resources in the nautilus-priority-stack.yml file. This includes the SQS queues, the SNS topic, and the subscription logic that separates the "High" from the "Low" priority traffic.

Template Path: /root/nautilus-priority-stack.yml
Resource Logic: Ensure the SNS subscriptions include FilterPolicy to look for the "priority" attribute.

🔹 Phase B: Deploying the Stack

Once the template is ready, we use the AWS CLI to launch the infrastructure.

Command:

   aws cloudformation create-stack --stack-name nautilus-priority-stack --template-body file:///root/nautilus-priority-stack.yml --capabilities CAPABILITY_NAMED_IAM

Note: The CAPABILITY_NAMED_IAM is required because our template creates a specific IAM role for the Lambda function.

🔹 Phase C: Message Publishing & Testing

With the stack CREATE_COMPLETE, we publish messages to the SNS topic. We include message attributes so the SNS Filter Policy knows which queue to target.

Publishing High Priority:

aws sns publish --topic-arn $topicarn --message 'High Priority message' --message-attributes '{"priority" : { "DataType":"String", "StringValue":"high"}}'

Publishing Low Priority:

aws sns publish --topic-arn $topicarn --message 'Low Priority message' --message-attributes '{"priority" : { "DataType":"String", "StringValue":"low"}}'

🔹 Phase D: Verification

The final step is observing the Lambda function's behavior.

Log Inspection: Check CloudWatch Logs for the nautilus-priorities-queue-function.
Verification: Confirm that the high-priority messages appear in the logs processed before the low-priority ones, validating our routing and processing order.

✅ Verify Success

Stack Status: nautilus-priority-stack is in the CREATE_COMPLETE state.
Routing: Messages are successfully filtered into the correct queues based on their attributes.
Processing: The Lambda function successfully consumes from both queues using its IAM permissions.

📝 Key Takeaways

🚀 Repeatability: If we need to deploy this in another region, we just run the CloudFormation template again—no manual clicking required.
🛡️ Granular Filtering: SNS Filter Policies are incredibly powerful for decoupled architectures, reducing the amount of "junk" data a Lambda has to parse.
📦 IAM Lifecycle: By including the IAM role in the stack, the permissions are created and destroyed alongside the infrastructure, preventing "zombie" roles.

🚫 Common Mistakes

Missing Capabilities Flag: Forgetting --capabilities CAPABILITY_NAMED_IAM will cause the stack creation to fail immediately.
Incorrect ARN Reference: Hardcoding ARNs in the template instead of using !Ref or !GetAtt makes the template less portable.
Attribute Mismatch: If the StringValue in your publish command doesn't exactly match the FilterPolicy in the template (case sensitivity matters!), the message will be dropped or ignored.

🌟 Final Thoughts

Infrastructure as Code is the standard for modern DevOps. By mastering CloudFormation, you've moved from "Cloud Admin" to "Cloud Engineer." You now have the power to deploy complex, secure, and filtered messaging systems with a single command.

🌟 Practice Like a Pro

Want to master AWS CloudFormation? Get hands-on experience here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud

⚡ AWS 146: Event-Driven Automation - Syncing S3 Buckets with Lambda & DynamoDB

Hritik Raj — Mon, 26 Jan 2026 13:51:06 +0000

🚀 Serverless Sync: Automating File Transfers with AWS Lambda

Hey Cloud Architects 👋

Welcome to Day 46 of the #100DaysOfCloud Challenge!
Today, we are moving into advanced serverless workflows. The Nautilus DevOps team needs to automate file management between a public upload bucket and a secure private storage bucket. We are implementing an event-driven solution where an upload to S3 triggers a Lambda function to copy the file and log the entire transaction into DynamoDB.

This task is part of my hands-on practice on the KodeKloud Engineer platform, perfect for mastering serverless integration and IAM roles.

🎯 Objective

Provision a public upload bucket (xfusion-public-27433) and a private storage bucket (xfusion-private-26642).
Create a DynamoDB table named xfusion-S3CopyLogs for auditing.
Configure an IAM Role (lambda_execution_role) with permissions for S3, DynamoDB, and CloudWatch.
Deploy a Lambda function (xfusion-copyfunction) to handle the copy logic and metadata logging.
Verify the automated workflow by uploading sample.zip and checking the logs.

💡 The Power of Event-Driven Design

In an event-driven system, code only runs when something happens (like a file upload). This is highly cost-effective and scalable because you aren't paying for idle servers you only pay for the few milliseconds the Lambda function runs.

🔹 Key Concepts

S3 Event Notifications: A feature that detects uploads and sends a signal (JSON event) to Lambda.
Lambda Execution Role: A set of permissions that allows your code to "talk" to other AWS services like S3 and DynamoDB securely.
Boto3 (Python SDK): The library used within the Lambda function to interact with AWS resources programmatically.

🛠️ Step-by-Step: Serverless Workflow

🔹 Phase A: Storage & Database Setup

First, we prepare our data "landing" and "logging" zones.

Public Bucket: Create xfusion-public-27433 and ensure public access is enabled.
Private Bucket: Create xfusion-private-26642 with all public access blocked.
DynamoDB Table: Create xfusion-S3CopyLogs with a Partition Key named LogID (String).

🔹 Phase B: Identity Management (IAM)

The Lambda function needs permission to read from one bucket and write to another.

Create Role: Named lambda_execution_role.
Attach Policies: Add permissions for s3:GetObject (Public), s3:PutObject (Private), and dynamodb:PutItem (Logs). Also, include CloudWatch Logs permissions for troubleshooting.

🔹 Phase C: Lambda Function Deployment

Now, we deploy the logic that bridges the two buckets.

Function Name: xfusion-copyfunction (Python).
Configuration: Replace the placeholders in the lambda-function.py script with your specific private bucket name and DynamoDB table name.
Trigger: Add an S3 trigger to the xfusion-public-27433 bucket for the "All object create events" type.

🔹 Phase D: Testing & Verification

With the infrastructure live, it’s time to test the automation.

Upload: Use the CLI or console to upload sample.zip to the public bucket.
S3 Check: Navigate to the private bucket to confirm sample.zip has appeared.
DynamoDB Check: View the xfusion-S3CopyLogs items to verify a log entry exists with the source, destination, and object key.

✅ Verify Success

Automation: The file appeared in the private bucket without any manual move command.
Auditing: A new entry in DynamoDB accurately reflects the transfer details.
Permissions: The Lambda function successfully assumed the lambda_execution_role to perform the task.

📝 Key Takeaways

🚀 Zero Server Management: Everything we built today is serverless; AWS handles the underlying scaling and availability.
🛡️ Principle of Least Privilege: By creating a custom IAM role, we ensured the Lambda function only has access to exactly what it needs and nothing more.
📦 Visibility: Logging to DynamoDB provides a persistent audit trail that is much easier to query than raw CloudWatch logs.

🚫 Common Mistakes

Circular Triggers: Never set a Lambda to trigger on a bucket it writes to, or you will create an infinite loop and a massive AWS bill!
Missing Placeholder Update: Forgetting to update the Python script with your actual bucket and table names will cause the Lambda to fail with a "ResourceNotFound" error.
IAM Policy Delay: Sometimes it takes a minute for new IAM permissions to propagate; if your first test fails, wait 60 seconds and try again.

🌟 Final Thoughts

This project is a perfect example of how serverless components can be stitched together to solve complex business problems. You’ve just built an automated, secure, and auditable data pipeline that forms the core of many modern enterprise applications.

🌟 Practice Like a Pro

Want to master serverless architectures? Sharpen your skills here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud

🌐 AWS 145: Private Subnet Internet Access - Implementing NAT Gateways

Hritik Raj — Sun, 25 Jan 2026 04:31:26 +0000

🚀 Bridge to the Cloud: Enabling Secure Outbound Traffic with NAT Gateway

Hey Cloud Architects 👋

Welcome to Day 45 of the #100DaysOfCloud Challenge!
Today, we are solving a classic networking puzzle. The Nautilus DevOps team has an EC2 instance isolated in a private subnet. It needs to upload data to an S3 bucket, but it has no path to the internet. Our job is to build the "bridge" a NAT Gateway to allow secure, one-way outbound communication.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which is perfect for mastering VPC routing and connectivity.

🎯 Objective

Provision a Public Subnet and an Internet Gateway (IGW) for the VPC.
Create a Public Route Table to enable external connectivity for the NAT Gateway.
Deploy a NAT Gateway with an Elastic IP in the public subnet.
Configure the Private Route Table to point all outbound traffic (0.0.0.0/0) to the NAT Gateway.
Verify success by checking the S3 bucket nautilus-nat-18582 for the automated upload.

💡 Why Private Subnets Need NAT

A private subnet has no direct route to an Internet Gateway. To allow instances to reach the internet (for patches or S3 uploads) while staying hidden from hackers, we use a NAT (Network Address Translation) Gateway. It acts as a middleman that sends requests on behalf of the private instance.

🔹 Key Concepts

Internet Gateway (IGW): The VPC's gate to the public internet.
NAT Gateway: Lives in a public subnet and allows private instances to connect to the internet but prevents the internet from initiating a connection with those instances.
Elastic IP (EIP): A static, public IPv4 address required by the NAT Gateway so it can be identified on the web.
Route Tables: The "GPS" of your VPC that tells packets where to go based on their destination IP.

🛠️ Step-by-Step: Connectivity Workflow

🔹 Phase A: Establishing the Public Infrastructure

For a NAT Gateway to work, it must reside in a subnet that has a direct path to an Internet Gateway.

Create Public Subnet: Name it nautilus-pub-subnet within the nautilus-priv-vpc.
Internet Gateway: Create a new IGW and attach it to your VPC.
Public Route Table: Create nautilus-pub-rt, add a route for 0.0.0.0/0 targeting the Internet Gateway, and associate it with nautilus-pub-subnet.

🔹 Phase B: Deploying the NAT Gateway

Now we set up the translation service that the private subnet will use.

Allocate Elastic IP: Request a new EIP from the Amazon pool.
Create NAT Gateway: Name it nautilus-natgw, place it in the nautilus-pub-subnet, and associate it with the EIP you just allocated.

🔹 Phase C: Updating the Private Route

This is the "handshake" that connects the private instance to the new gateway.

Modify Private RT: Locate the route table associated with nautilus-priv-subnet.
Add Route: Add a destination for 0.0.0.0/0 (all internet traffic) and select NAT Gateway as the target, picking the nautilus-natgw you created.

🔹 Phase D: Verification & S3 Check

The EC2 instance has a cron job waiting for this connection.

Wait Period: Give the system 2–3 minutes for the NAT Gateway to initialize and the cron job to fire.
S3 Validation: Open the S3 console, navigate to bucket nautilus-nat-18582, and verify that the test file has been successfully uploaded.

✅ Verify Success

Route Check: The private subnet now has a valid path to the internet via the NAT Gateway.
EIP Association: The NAT Gateway is correctly mapped to a static public IP.
Data Flow: The presence of the file in S3 confirms that outbound traffic is successfully traversing the VPC.

📝 Key Takeaways

🚀 Public/Private Balance: Always place NAT Gateways in Public subnets; placing them in Private subnets will result in no connectivity.
🛡️ One-Way Traffic: NAT Gateways provide a massive security boost because they don't allow "Inbound" connections from the internet to your servers.
📦 Cost Awareness: NAT Gateways are billed per hour and per GB of data processed; for large S3 transfers, consider using a VPC Endpoint for S3 to save on data costs!

🚫 Common Mistakes

Missing IGW: If the Public Subnet doesn't have a route to an Internet Gateway, the NAT Gateway will fail to reach the web.
Wrong Subnet Association: Attaching the public route table to the private subnet would make the subnet public, violating security requirements.
EIP Requirement: Forgetting to allocate an Elastic IP NAT Gateways cannot function without a static public identity.

🌟 Final Thoughts

Configuring NAT Gateways is a fundamental skill for securing cloud workloads. By mastering this, you ensure your databases and backend servers stay private and protected while still having the ability to communicate with the outside world when necessary.

🌟 Practice Like a Pro

Ready to build your own secure VPC architectures? Practice here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud

🚀 AWS 144: Scaling for Success - High Availability with ASG and ALB

Hritik Raj — Sat, 24 Jan 2026 04:03:20 +0000

🌐 Building Resilience: Auto Scaling and Load Balancing in AWS

Hey Cloud Architects 👋

Welcome to Day 44 of the #100DaysOfCloud Challenge!
Today, we are moving into the realm of High Availability (HA). No more single-point-of-failure servers! We are setting up a self-healing infrastructure where an Application Load Balancer (ALB) distributes traffic and an Auto Scaling Group (ASG) monitors our server health and CPU load to scale up or down automatically.

This task is part of my hands-on practice on the KodeKloud Engineer platform, focusing on real-world infrastructure scaling.

🎯 Objective

Create a Launch Template with a User Data script to auto-install Nginx.
Provision an Application Load Balancer (ALB) with a dedicated Target Group.
Configure an Auto Scaling Group (ASG) with a Target Tracking Policy (50% CPU).
Verify end-to-end traffic flow from the ALB DNS to the Nginx instances.

💡 The Power of Elasticity

Elasticity is the ability to grow or shrink infrastructure resources dynamically. By using ASG and ALB, we ensure that if a server dies, a new one takes its place, and if traffic surges, we add more capacity instantly.

🔹 Key Concepts

Launch Template: A blueprint for your instances (AMI, Instance Type, User Data).
Target Group: A logical grouping of EC2 instances that receive traffic from the Load Balancer.
Health Checks: The ALB periodically pings instances; if one fails, it stops sending traffic and the ASG replaces it.
Target Tracking Policy: Scales the group based on a specific metric (like maintaining an average 50% CPU utilization).

🛠️ Step-by-Step: Infrastructure Workflow

🔹 Phase A: Create the Launch Template

The Launch Template defines what we are launching.

Name: devops-launch-template.
AMI: Amazon Linux 2.
Instance Type: t2.micro.
Security Group: Allow HTTP (Port 80) from anywhere.
User Data:

  #!/bin/bash
  amazon-linux-extras install nginx1 -y
  systemctl start nginx
  systemctl enable nginx

🔹 Phase B: Load Balancer & Target Group Setup

The ALB acts as the "front door" for all incoming traffic.

Target Group: Create devops-tg (Target type: Instances, Port 80).
Load Balancer: Create devops-alb (Application Load Balancer).
Listeners: HTTP on Port 80, forwarding to devops-tg.
Subnets: Select at least two Public Subnets in different AZs.

🔹 Phase C: Auto Scaling Group Configuration

The ASG manages the number of instances running.

Name: devops-asg.
Launch Template: devops-launch-template.
Group Size: * Desired: 1
Minimum: 1
Maximum: 2
Scaling Policy: Target Tracking (Metric: Average CPU Utilization, Target: 50%).
Integration: Attach to the existing Load Balancer Target Group devops-tg.

🔹 Phase D: Verification

ALB DNS: Copy the DNS Name of devops-alb from the console.
Browser Test: Paste the DNS into your browser. If you see the "Welcome to nginx!" page, the traffic is successfully passing through the ALB to your ASG-managed instance.

✅ Verify Success

Auto Scaling: Ensure at least 1 instance is in "InService" state.
Target Group Health: Check the devops-tg targets tab to see the instance marked as Healthy.
URL Accessibility: The ALB DNS resolves correctly to the Nginx landing page.

📝 Key Takeaways

🚀 User Data Automation: Bootstrapping Nginx via script ensures every new instance scaled by ASG is ready to serve traffic immediately.
🛡️ Cross-AZ Availability: Distributing the ALB across multiple AZs ensures the Load Balancer itself remains available even if one AZ goes down.
📦 Metric Scaling: Target tracking policies are much easier to manage than manual step scaling policies.

🚫 Common Mistakes

Missing User Data: If you forget the script, the instances will launch, but the ALB health check will fail because Nginx isn't running.
Security Group Conflict: Ensure the EC2 Security Group allows traffic from the ALB Security Group.
Single Subnet ALB: AWS requires at least two subnets in different availability zones for an ALB.

🌟 Final Thoughts

By integrating ASG and ALB, you have built a system that is not only scalable but also highly resilient. This architecture is the foundation of modern production environments, ensuring a seamless experience for users regardless of traffic load or server health.

🌟 Practice Like a Pro

Ready to build your own elastic architectures? Practice here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud

☸️ AWS 143: Enterprise Kubernetes - Provisioning a Private Amazon EKS Cluster

Hritik Raj — Fri, 23 Jan 2026 04:00:33 +0000

🏗️ Production-Ready K8s: Building the xfusion-eks Cluster

Hey Cloud Architects 👋

Welcome to Day 43 of the #100DaysOfCloud Challenge!
Today, we are tackling one of the most powerful services in the AWS ecosystem: Amazon EKS. The Nautilus DevOps team is preparing for a new microservices deployment, and they need a cluster that is both highly available and secure. Our mission is to provision a cluster using the latest stable version (1.30) while ensuring the control plane remains completely private.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which is my go-to for simulating complex infrastructure scenarios.

🎯 Objective

Create an IAM Role named eksClusterRole with the necessary trust relationships.
Provision an EKS cluster named xfusion-eks using Kubernetes version 1.30.
Configure Networking across three Availability Zones (a, b, and c) for High Availability.
Restrict access by setting the Cluster Endpoint to Private.

💡 Why Private Endpoints Matter

By default, EKS cluster endpoints are public. By switching to Private Access, the Kubernetes API server is not accessible from the internet. All communication with the cluster must originate from within your VPC or via a connected network (like a VPN or Direct Connect).

🔹 Key Concepts

Control Plane: The managed Kubernetes API server and etcd database that AWS handles for you.
IAM Cluster Role: A specific role that allows the EKS service to manage resources (like ELBs or EC2 instances) on your behalf.
High Availability (HA): Deploying across multiple AZs ensures that even if one data center goes down, your cluster control plane remains operational.

🛠️ Step-by-Step: Infrastructure Workflow

🔹 Phase A: Identity & Access Management (IAM)

Before creating the cluster, we must define the permissions EKS needs to operate.

Create Role: Navigate to IAM and create a role named eksClusterRole.
Trusted Entity: Select "EKS - Cluster" as the service that will use this role.
Policy: Attach the AmazonEKSClusterPolicy.

🔹 Phase B: Cluster Configuration

Now, we move to the EKS console to define the cluster's "brain."

Name: xfusion-eks.
Version: Select 1.30 (the latest stable version requested).
Service Role: Choose the eksClusterRole we created in Phase A.

🔹 Phase C: Networking & Security

This is the most critical phase for meeting the security requirements.

VPC: Select the Default VPC.
Subnets: Ensure subnets from AZs us-east-1a, us-east-1b, and us-east-1c are selected.

* Cluster Endpoint Access: Change the radio button from "Public" to Private.

🔹 Phase D: Verification

EKS clusters take about 10–15 minutes to provision.

Status Check: Wait until the cluster status changes from Creating to Active.
Configuration Audit: Click on the "Networking" tab to verify the endpoint access is indeed set to "Private" and that all three AZs are listed.

✅ Verify Success

Cluster Identity: The cluster is named xfusion-eks and running K8s version 1.30.
Role Association: The cluster successfully assumed the eksClusterRole.
Zero Exposure: The API server has no public URL, confirming the private configuration.

📝 Key Takeaways

🚀 Version Stability: Always use the latest stable version supported by EKS for the best security patches.
🛡️ Network Isolation: Private endpoints are the standard for financial and healthcare sectors to meet compliance.
📦 IAM Dependencies: EKS cannot start without its service role. Always verify the trust relationship if the cluster fails to create.

🚫 Common Mistakes

Public Access Enabled: Forgetting to toggle the "Private" endpoint setting exposes your API server to the web.
Missing AZs: Selecting only one AZ removes the High Availability benefit of a managed service.
Role Permissions: Using a standard EC2 role instead of an EKS Service Role will cause the cluster creation to hang.

🌟 Final Thoughts

You've just provisioned a production-grade Kubernetes control plane! While the setup today was done via the console, these same parameters form the basis of automated Infrastructure as Code (IaC) using Terraform or AWS CDK.

🌟 Practice Like a Pro

Sharpen your Kubernetes skills in a real-world sandbox:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud

🗄️ AWS 142: Serverless Databases - Managing Tasks with Amazon DynamoDB

Hritik Raj — Thu, 22 Jan 2026 04:15:23 +0000

⚡ Fast & Flexible: Building a To-Do Backend with DynamoDB

Hey Cloud Architects 👋

Welcome to Day 42 of the #100DaysOfCloud Challenge!
Today, we are stepping away from traditional relational databases and exploring the world of NoSQL. The Nautilus DevOps team is building a 'To-Do' application, and we need a storage solution that is both fast and schema-flexible. We'll be using Amazon DynamoDB to store and manage our tasks.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which is perfect for mastering AWS managed services.

🎯 Objective

Provision a DynamoDB table named xfusion-tasks.
Define a Primary Key (taskId) as a String.
Manually insert task items with descriptions and progress statuses.
Verify the data integrity through the AWS Management Console.

💡 Why DynamoDB for Modern Apps?

Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability.

🔹 Key Concepts

Partition Key: A simple primary key, used by DynamoDB's internal hash function to evenly distribute data across partitions.
Items & Attributes: An "Item" is a group of attributes (similar to a row in SQL), and "Attributes" are the fundamental data elements (similar to columns).
Serverless: No servers to provision, patch, or manage. You only pay for the storage and throughput you use.

🛠️ Step-by-Step: Database Workflow

🔹 Phase A: Create the Table

We start by defining our table structure in the DynamoDB console.

Table Name: xfusion-tasks.
Partition Key: taskId (Type: String).
Table Settings: Keep "Default settings" for this task (Provisioned capacity with free tier limits).

🔹 Phase B: Populate the Data

Once the table status is Active, we navigate to "Explore items" to add our tasks.

Create Item 1:
- taskId: 1
- description: Learn DynamoDB
- status: completed

Create Item 2:
- taskId: 2
- description: Build To-Do App
- status: in-progress

🔹 Phase C: Verification

After inserting the items, we must verify they are queryable.

Scan/Query: In the "Explore items" view, ensure both tasks appear in the results list.
Status Check: Confirm that Task 1 is marked as completed and Task 2 is in-progress.

✅ Verify Success

Table Existence: The table xfusion-tasks is listed and active in the AWS region.
Primary Key: The schema correctly identifies taskId as the unique identifier.
Data Accuracy: Both items are present with the exact attributes defined in the requirements.

📝 Key Takeaways

🚀 Schema Flexibility: Notice how we didn't have to define "description" or "status" when creating the table only the Primary Key is required!
🛡️ On-Demand vs Provisioned: For development, Provisioned (Free Tier) is great, but for unpredictable traffic, On-Demand scaling is a lifesaver.
📦 Data Types: Ensure the taskId type matches (String vs Number) otherwise, application-level queries might fail.

🚫 Common Mistakes

Key Mismatch: Trying to insert a task without a taskId or using the wrong data type (e.g., Number instead of String).
Case Sensitivity: DynamoDB is case-sensitive. taskId is not the same as taskid.
Over-Provisioning: Setting Read/Write capacity too high can lead to unnecessary costs in a real-world environment.

🌟 Final Thoughts

DynamoDB is the go-to choice for serverless architectures. By mastering the console-based setup and item management, you've laid the groundwork for building highly responsive, globally distributed applications.

🌟 Practice Like a Pro

Ready to build your own NoSQL backends? Practice here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud

🔐 AWS 141: Data Protection at Rest - Mastering AWS KMS for File Encryption

Hritik Raj — Wed, 21 Jan 2026 05:00:37 +0000

🛡️ Securing the Vault: Encrypting Data with AWS KMS

Hey Cloud Architects 👋

Welcome to Day 41 of the #100DaysOfCloud Challenge!
Today, we are focusing on Cloud Security. The Nautilus DevOps team is prioritizing data integrity, and our mission is to implement a robust encryption workflow using AWS Key Management Service (KMS). We are ensuring that sensitive files remain unreadable to unauthorized users, even if they gain access to the storage layer.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which provides excellent real-world scenarios for mastering DevOps security.

🎯 Objective

Provision a symmetric KMS key named nautilus-KMS-Key.
Encrypt a sensitive file (SensitiveData.txt) located in the /root/ directory.
Base64 encode the resulting ciphertext and save it as EncryptedData.bin.
Verify the setup by successfully decrypting the file back to its original state.

💡 Why KMS is a Game Changer

AWS KMS (Key Management Service) allows you to create and manage cryptographic keys across AWS services and your applications. It uses FIPS 140-2 validated hardware security modules (HSMs) to protect your keys.

🔹 Key Concepts

Symmetric Encryption: Using a single 256-bit secret key for both encryption and decryption.
Ciphertext vs. Plaintext: Plaintext is your readable data; Ciphertext is the encrypted version that appears as gibberish to anyone without the key.
Base64 Encoding: This process converts binary data into an ASCII string format, ensuring the encrypted data doesn't get corrupted during transit or storage.

🛠️ Step-by-Step: Security Workflow

🔹 Phase A: Create the KMS Key

First, we generate the master key that will handle our cryptographic operations.

Key Type: Symmetric.
Alias: nautilus-KMS-Key.
Configuration: Ensure the IAM user has the necessary permissions to use this key for encryption and decryption.

🔹 Phase B: Encrypt and Encode

We use the AWS CLI to perform the encryption. The --plaintext flag requires the fileb:// prefix to handle the file as binary.

Perform Encryption:

   aws kms encrypt --key-id alias/nautilus-KMS-Key --plaintext fileb:///root/SensitiveData.txt --output text --query CiphertextBlob > /root/EncryptedData.bin

Note: The output is redirected to EncryptedData.bin as requested.

🔹 Phase C: Verify via Decryption

To confirm the encryption worked correctly, we must be able to reverse it.

Decrypt the File:

aws kms decrypt --ciphertext-blob fileb:///root/EncryptedData.bin --output text --query Plaintext | base64 --decode

Comparison: If the output matches the content of SensitiveData.txt, the verification is successful.

✅ Verify Success

File Integrity: Check that /root/EncryptedData.bin exists.
Key Configuration: Ensure the nautilus-KMS-Key alias points to the correct Key ID.
Validation: The validation script will successfully decrypt the binary file using your created key.

📝 Key Takeaways

🚀 Alias Usage: Referencing keys by an Alias (e.g., alias/nautilus-KMS-Key) is better practice than using hardcoded Key IDs.
🛡️ Binary Input: Always use the fileb:// prefix in AWS CLI when dealing with file inputs for encryption to prevent encoding errors.
📦 Security Layers: Encrypting data at the application or OS level provides an extra layer of defense beyond standard disk encryption.

🚫 Common Mistakes

Missing Alias Prefix: Forgetting to add alias/ before the key name in the CLI command.
Permission Issues: Not giving the proper Key Policy permissions to the user performing the encryption.
Encoding Errors: Failing to base64 decode the plaintext result during manual verification, which results in a garbled string.

🌟 Final Thoughts

Encryption is a pillar of the "Shared Responsibility Model." By implementing AWS KMS for sensitive files, you ensure that Nautilus's data remains protected against unauthorized access. This is a fundamental skill for any security-conscious DevOps Engineer.

🌟 Practice Like a Pro

If you want to practice these security tasks in a live environment, check out:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud

🚨 AWS 140: VPC Troubleshooting - Restoring Internet Connectivity

Hritik Raj — Tue, 20 Jan 2026 09:28:30 +0000

🛠️ The Missing Link: Resolving VPC Routing and IGW Issues

Hey Cloud Builders 👋

Welcome to Day 40 of the #100DaysOfCloud Challenge!
Today, we are putting on our detective hats. The Nautilus team has an EC2 instance with Nginx installed and Security Groups properly configured, yet it's invisible to the internet. We are deep-diving into the VPC Networking Stack to find and fix the break in the communication chain.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which I highly recommend for anyone looking to master real-world DevOps scenarios.

🎯 Objective

Diagnose why datacenter-ec2 is inaccessible despite correct Security Group settings.
Verify and attach an Internet Gateway (IGW) to the VPC if missing.
Update the Route Table to forward external traffic (0.0.0.0/0) to the IGW.
Ensure the instance has a valid Public IPv4 Address.
Restore public access to the Nginx web server on Port 80.

💡 Why VPC Configuration is the Backbone

You can have the best security rules in the world, but if the "roads" (routes) aren't built, no traffic will ever arrive at your front door.

🔹 Key Concepts

Internet Gateway (IGW): Think of this as the border crossing between your private VPC and the public internet. Without it, your VPC is an island.
Default Route (0.0.0.0/0): This route tells the subnet: "If you don't know where a packet is going, send it to the Internet Gateway."
Public vs. Private Subnets: A subnet only becomes "Public" once it has a route entry pointing to an IGW.

🛠️ Step-by-Step: The Troubleshooting Workflow

🔹 Phase A: Verify and Attach the Internet Gateway

Check IGWs: Navigate to VPC Dashboard > Internet Gateways.
Attachment: Ensure datacenter-igw is in the Attached state.
The Fix: If an IGW exists but is "Detached," select it, click Actions, and choose Attach to VPC, then select datacenter-vpc.

🔹 Phase B: Configure the Route Table

Identify Table: Go to Subnets, select the subnet hosting your EC2, and look at the Route Table tab.
Add the Default Route:
Click Edit routes.
Add a route with Destination: 0.0.0.0/0.
Set Target: Internet Gateway and select your attached IGW.

🔹 Phase C: Confirm Public IP and Service

Instance Settings: Verify that datacenter-ec2 actually has a Public IPv4 address assigned in the EC2 Console.
Service Check: SSH into the instance and ensure Nginx is active: sudo systemctl status nginx

✅ Verify Success

External Ping: Open your browser and type the Public IP of the instance.
Confirm: 🎉 If the "Welcome to nginx!" page loads, mission accomplished! You have successfully re-established the network path.

📝 Key Takeaways

🚀 Routing Hierarchy: Security Groups (Instance level) can only work if the Route Table (Subnet level) allows the traffic through.
🛡️ Gateway Dependency: A VPC can have multiple subnets, but all public-facing ones must point to the same Internet Gateway.
🕒 Instant Effect: Once you save the route table change, the connectivity restoration is usually instantaneous.

🚫 Common Mistakes

Missing IGW: Creating the gateway but forgetting to "Attach" it to the specific VPC.
Wrong Subnet: Updating a route table for a different subnet than the one the EC2 instance is actually using.
NACL Overlap: Forgetting that Network ACLs could also be blocking traffic at the subnet boundary.

🌟 Final Thoughts

Troubleshooting VPC reachability is one of the most common real-world tasks for a DevOps Engineer. By mastering the relationship between IGWs and Route Tables, you ensure your infrastructure is not just built, but actually accessible to your users.

🌟 Practice Like a Pro

If you want to try these tasks yourself in a real AWS environment, check out:
👉 KodeKloud Engineer - Practice Labs

It’s where I’ve been sharpening my skills daily!

🔗 Let’s Connect

💬 LinkedIn: Hritik Raj
⭐ Support my journey on GitHub: 100 Days of Cloud