DEV Community: Vijaya Laxmi Kadham

AWS CloudFormation Hands-on | Build Your First Infrastructure Using YAML

Vijaya Laxmi Kadham — Thu, 09 Jul 2026 20:19:49 +0000

Introduction

In the previous article, we learned what Infrastructure as Code (IaC) is and why AWS CloudFormation is used to automate infrastructure creation.

Instead of manually creating AWS resources through the AWS Management Console every time, CloudFormation allows us to define our infrastructure in a template and let AWS create everything for us.

Now it's time to put those concepts into practice.

In this hands-on guide, we will write our first CloudFormation template, deploy it as a CloudFormation Stack, verify that AWS creates the resources automatically, update the infrastructure, and finally clean everything up.

By the end of this article, you will have a solid understanding of the basic CloudFormation workflow.

What We will Build

In this lab, we will create:

One Amazon S3 Bucket
A CloudFormation Stack
Update the Stack
Delete the Stack

Although we are creating only an S3 bucket, the same process is used to create much larger infrastructure such as VPCs, EC2 instances, Load Balancers and Auto Scaling Groups.

Prerequisites

Before starting, make sure you have:

An AWS account
IAM User with Administrator Access
Basic understanding of S3
Basic understanding of CloudFormation (covered in the previous article)

Step 1: Open CloudFormation

In the search bar, search for:

CloudFormation

Open the CloudFormation service.

You will see the CloudFormation dashboard.

Step 2: Understand What We Need

Before creating anything, let's understand how CloudFormation works.

CloudFormation doesn't create resources directly from button clicks.

Instead, it reads a Template.

Think of the template as a blueprint.

You Write Template
        ↓
CloudFormation Reads It
        ↓
AWS Creates Resources

Our first task is to create this template.

Step 3: Create a YAML Template

Open any text editor.

Examples:

VS Code
Notepad++
Sublime Text

Create a new file named:

s3-bucket.yaml

Paste the following template:

AWSTemplateFormatVersion: '2010-09-09'

Description: Creates an S3 Bucket using AWS CloudFormation

Resources:

  MyS3Bucket:

    Type: AWS::S3::Bucket

    Properties:

      BucketName: my-demo-cloudformation-bucket

Note: S3 bucket names must be globally unique. Replace my-demo-cloudformation-bucket with your own unique bucket name.

Save the file.

Step 4: Understanding the Template

Let's understand every part of this template.

1. AWSTemplateFormatVersion

AWSTemplateFormatVersion: '2010-09-09'

This specifies the version of the CloudFormation template format.

You don't usually need to change this value.

2. Description

Description:

This simply describes what the template does.

Think of it like comments for humans.

3. Resources

Resources:

This is the most important section.

Everything AWS creates is defined under Resources.

For example:

EC2
VPC
IAM
S3
Lambda

All are created inside this section.

4. Logical Resource Name

MyS3Bucket

This is the logical name inside CloudFormation.

AWS uses this name internally.

It doesn't become the actual bucket name.

5. Resource Type

Type: AWS::S3::Bucket

This tells AWS what service to create.

Different services have different resource types.

Examples:

AWS Service	Resource Type
S3	AWS::S3::Bucket
EC2	AWS::EC2::Instance
VPC	AWS::EC2::VPC

6. Properties

Properties define how the resource should be configured.

Example:

BucketName:

Here we provide the actual bucket name.

Step 5: Create the Stack

Return to AWS CloudFormation.

Click on Create Stack → Select Choose an existing template.

Click on Choose file and upload:

s3-bucket.yaml

Click on Next.

Step 6: Stack Details

Provide a Stack Name, for example:

demo-s3-stack

Click on Next.

You can leave all the options as default for this lab.

Click Next.

Step 7: Review

Review the Configuration.

Click on Submit.

CloudFormation now starts creating the resources.

Step 8: Watch the Events

This is one of the most useful tabs.

Open Events.

You will notice CloudFormation showing each action.

Example:

CREATE_IN_PROGRESS

CREATE_COMPLETE

Instead of guessing what AWS is doing, you can monitor every step here.

Step 9: Verify the Resource

Open:

AWS S3
    ↓
Buckets

You should now see the bucket that CloudFormation created.

Notice something interesting.

We never manually clicked Create Bucket.

CloudFormation created it automatically.

This is the power of Infrastructure as Code (IaC).

Step 10: Update the Stack

Infrastructure changes over time.

Instead of deleting everything and recreating it, CloudFormation allows us to update existing resources.

Let's update our bucket by enabling versioning.

Modify the template.

AWSTemplateFormatVersion: '2010-09-09'

Description: Creates an S3 Bucket using AWS CloudFormation

Resources:

  MyS3Bucket:

    Type: AWS::S3::Bucket

    Properties:

      BucketName: my-demo-cloudformation-bucket-12345

      VersioningConfiguration:

        Status: Enabled

Save the file.

Step 11: Update CloudFormation

Go back to CloudFormation.

Select your Stack.

Click Update, choose:

Replace Current Template

Upload the modified YAML file.

Click:

Next → Next → Submit

Step 12: Verify Versioning

Go back to the S3 Bucket.

Open Properties and scroll down.

You should now see Bucket Versioning enabled.

Notice that CloudFormation updated the existing resource rather than creating a new bucket.

Step 13: Delete the Stack

CloudFormation also makes cleanup easy.

Instead of deleting every resource manually,

simply select the stack.

Click Delete.

CloudFormation automatically deletes all the resources that belong to that Stack.

This is one of the biggest advantages of Infrastructure as Code.

Understanding the CloudFormation Workflow

Write YAML Template
        ↓
Upload Template
        ↓
Create Stack
        ↓
AWS Creates Resources
        ↓
Update Template
        ↓
Update Stack
        ↓
Delete Stack

Best Practices

Store your CloudFormation templates in Git.
Use meaningful stack names.
Add descriptions to templates.
Start with small templates before building large infrastructures.
Delete unused stacks to avoid unnecessary AWS charges.

Key Takeaways

CloudFormation uses templates to define infrastructure.
A Stack is a collection of AWS resources created from a template.
You can create, update and delete infrastructure using the same template.
CloudFormation reduces manual work and helps maintain consistency across environments.
Infrastructure as Code is a fundamental skill for DevOps and Cloud Engineers.

Conclusion

In this hands-on lab, we created our first AWS CloudFormation template using YAML and used it to deploy an S3 bucket without manually creating resources through the AWS Console.

We also learned how CloudFormation manages infrastructure through Stacks, how to update existing resources by modifying the template and how to clean up everything by deleting the stack.

Although this example used a simple S3 bucket, the same workflow is used in real-world environments to provision complex infrastructure consisting of VPCs, EC2 instances, Load Balancers, Auto Scaling Groups, RDS databases, and much more.

🎉 Congratulations! You have successfully:

Written your first CloudFormation template
Created an AWS resource using Infrastructure as Code
Updated an existing CloudFormation Stack
Deleted a Stack and cleaned up resources

You now understand the complete CloudFormation workflow:

Write Template
      ↓
Create Stack
      ↓
AWS Creates Resources
      ↓
Update Template
      ↓
Update Stack
      ↓
Delete Stack

This workflow is the foundation for deploying production infrastructure on AWS using Infrastructure as Code.

AWS CloudFormation Explained for Beginners | Infrastructure as Code (IaC) Made Simple

Vijaya Laxmi Kadham — Wed, 08 Jul 2026 19:54:05 +0000

AWS CloudFormation Explained for Beginners | Infrastructure as Code (IaC) Made Simple

Introduction

In the previous article, we learned how to use the AWS CLI to interact with AWS services from the command line.

The AWS CLI is great for performing quick tasks such as:

Listing S3 buckets
Launching an EC2 Instance
Creating a VPC

However, imagine that you need to build an entire production environment consisting of:

A VPC
Public and Private Subnets
Internet Gateway
NAT Gateway
Route Tables
Security Groups
EC2 Instances
Load Balancer
Auto Scaling Group

Creating all these resources manually every time would be slow, repetitive and prone to mistakes.

This is where Infrastructure as Code (IaC) comes in.

AWS provides a service called CloudFormation that allows us to create infrastructure using code instead of clicking through the AWS Console.

In this article, we will understand the basics of CloudFormation and why it is one of the most important services for AWS and DevOps engineers.

What We Will Learn

In this article, we will learn:

What is Infrastructure as Code (IaC)?
Why CloudFormation is needed
Problems with manual infrastructure
What is CloudFormation?
Templates
Stacks
Stack Updates
Stack Deletion
Benefits
Real-world examples

Imagine this Scenario

Suppose you work for an online learning platform.

Every new customer gets their own AWS environment.

Each environment needs:

1 VPC
2 Public Subnets
2 Private Subnets
Internet Gateway
NAT Gateway
Security Groups
EC2 Instances
Load Balancer

Now imagine creating this manually for:

Customer A
Customer B
Customer C
Customer D

Every single week.

It would become repetitive and time-consuming.

Even worse, one small mistake could cause production issues.

The Problem with Manual Infrastructure

Creating infrastructure manually has several drawbacks.

Time consuming
Human errors
Difficult to recreate
Hard to maintain
No version control

Think of writing a long document.

Would you rather rewrite the document every time, or simply save it and reuse it whenever needed?

Infrastructure works the same way.

Instead of rebuilding everything manually, we write the infrastructure once and reuse it whenever required.

What is Infrastructure as Code (IaC)?

Infrastructure as Code means defining your infrastructure using code instead of manually creating resources through the AWS Console.

Instead of clicking buttons every time, we write instructions inside a file.

AWS reads those instructions and creates the required resources automatically.

Think of it like following a recipe.

Rather than preparing a dish from memory every time, you write the recipe once and anyone can recreate the same dish by following those instructions.

CloudFormation works in a similar way.

You write the infrastructure once, and AWS builds it whenever needed.

What is AWS CloudFormation?

AWS CloudFormation is a service that allows you to create, update and manage AWS infrastructure using code.

Instead of manually creating resources, you write a template describing what you want.

AWS reads the template and creates all the required resources for you.

Developer
     │
Writes Template
     │
     ▼
CloudFormation
     │
Creates Resources
     │
 ┌───────────────┐
 │ VPC           │
 │ Subnets       │
 │ EC2           │
 │ S3            │
 │ IAM           │
 │ Load Balancer │
 └───────────────┘

What is a CloudFormation Template?

A Template is simply a blueprint of your infrastructure.

It contains instructions describing:

What resources should be created
Configuration
Dependencies

Think of it as a house blueprint.

The blueprint doesn't build the house.

It simply describes how the house should be built.

CloudFormation uses the blueprint to create the infrastructure.

What is a Stack?

When CloudFormation reads your template and creates the resources, AWS groups all those resources into something called a Stack.

Think of a Stack as a project folder.

Instead of managing resources individually, AWS manages them together.

For example, your Stack may contain:

VPC
EC2
Security Group
S3 Bucket

Deleting the Stack deletes all those resources together.

Real-World Example

Imagine a company with separate environments:

Development
Testing
Production

Instead of creating infrastructure manually three times, the DevOps engineer writes one CloudFormation template.

Then they deploy it three times:

Dev Stack
Test Stack
Production Stack

Same code.

Different environments, much easier.

Why Companies Use CloudFormation

Companies use CloudFormation because it provides:

Automation
Consistency
Version Control
Faster Deployments
Easy Recovery
Repeatability

CloudFormation vs Manual AWS Console

Manual AWS Console	CloudFormation
Click every resource	Write once
Slow	Fast
Human mistakes	Consistent
Hard to repeat	Easily reusable
No version control	Git friendly

CloudFormation Supports Almost Every AWS Service

Examples include:

EC2
VPC
IAM
S3
Route 53
Lambda
DynamoDB
RDS
CloudFront

A Simple Flow

Write Template
       │
       ▼
Upload to CloudFormation
       │
       ▼
Create Stack
       │
       ▼
AWS Creates Resources

Conclusion

In this article, we learned the theory behind AWS CloudFormation and Infrastructure as Code.

We explored why manually creating AWS resources becomes difficult as environments grow and how CloudFormation solves this problem by allowing us to define infrastructure using code.

What's Next?

In the next article, we will put these concepts into practice by creating our first CloudFormation template, launching resources using a Stack and understanding how CloudFormation manages infrastructure automatically.

AWS CLI for Beginners | Automating AWS without using the Console

Vijaya Laxmi Kadham — Mon, 29 Jun 2026 09:03:40 +0000

Introduction

Until now, we have been creating resources such as:

VPCs
EC2 Instances
S3 Buckets

using AWS Console.

While the AWS Console is easy for beginners, it becomes difficult when we need to create many resources repeatedly.

Imagine manually creating:

20 VPCs
20 S3 buckets
15 EC2 Instances

Doing this from the UI every time would be slow and inefficient.

This is where AWS CLI becomes useful.

What we will Learn

In this article, we will learn:

What AWS CLI is
Why AWS CLI is useful
How AWS CLI communicates with AWS
Installing AWS CLI
Configuring AWS CLI
Running our first AWS CLI command
Finding AWS CLI documentation

Why Do We Need AWS CLI?

AWS provides APIs(Application Programming Interfaces) for all its services.

These APIs allow us to:

Create resources
Update resources
Delete resources
Manage infrastructure programmatically

Instead of clicking on buttons in AWS Console, we can send commands directly to AWS.

Think of it like this:

AWS Console
    ↓
Manual Operations

AWS CLI
    ↓
Command Based Operations

Real Life Example

Suppose your company asks you to create:

50 S3 buckets
20 EC2 Instances
Multiple VPCs

Doing this manually from the AWS Console would take time.

Using AWS CLI we can automate these operations through commands and scripts.

What is AWS CLI?

AWS CLI stands for:

AWS Command Line Interface

It is tool that allows us to manage AWS services directly from terminal.

AWS CLI acts as a bridge between users and AWS APIs.

User
  ↓
AWS CLI
  ↓
AWS API
  ↓
AWS Services

The AWS CLI itself is developed by AWS and internally sends API requests to AWS services.

The good part is:

We don't need programming knowledge to start using AWS CLI
We only need to understand commands and documentation.

AWS CLI vs AWS Console

AWS Console	AWS CLI
Manual	Command Line Interface
Beginner fridenly	Automation friendly
Slower for repetitive tasks	Faster
Requires clicking	Requires commands
Suitable for learning	Suitable for automation

AWS CLI vs Terraform vs Cloud Formation

Many beginners ask:

If AWS CLI can create resources, why do we need Terraform or CloudFormation?

The answer is simple.

AWS CLI is best for:

Quick actions
testing
Small automation tasks
Learning AWS services

CloudFormation is best for:

Reusable infrastructure
AWs native infrastructure as a Code

Terraform is best for:

Large production environments
Multi-cloud infrastructure
Infrastructure as Code

AWS CDK is best for:

Developers who prefer programming languages.

Hands-On: Installing AWS CLI

Method 1: Install AWS CLI using Git Bash

Step 1: Install Git Bash

Open your browser and search:

Git Bash Download

Download and install Git Bash.

After installation, open:

Git Bash

Step 2: Install AWS CLI

In your browser search for:

AWS CLI

Open the official AWS Documentation.

Navigate to:

User Guide → Get Started → Install/Update

Select the Linux CLI installer and copy the path and paste it in the Git Bash terminal.

Then you will see AWS CLI is installing.

After installation, verify:

aws --version

You will see something like this in the terminal:

aws-cli/2.x Python/3.x Windows

Step 3: Configure AWS CLI

Why Does AWS CLI Need Configuration?

AWS CLI needs to know:

Which AWS account to use
Which region to use
Which credentials belong to us

This is done using:

aws configure

Provide:

AWS Access Key ID
AWS Secret Access Key
Default Region
Output Format (json)

You will get the Access Key ID from your AWS account.

Go to your AWS Console.

Click on the account name on the right-side corner → Select Security Credentials.

Scroll to Access Keys → Click on Create Access Key.

AWS generates:

Access Key ID
Secret Access Key

Save these credentials securely.

NEVER SHARE YOUR SECRET ACCESS KEY

Example:

AWS Access Key ID: AKIAxxxxxxxx
AWS Secret Access Key: ********
Default Region Name: ap-south-1
Default Output Format: json

Why JSON?

AWS returns responses in JSON format because it is easy for applications and scripts to process.

Method 2: Using AWS CloudShell (What I Used)

Since I was using a managed laptop where installing software was restricted, I used AWS CloudShell.

CloudShell already comes with AWS CLI pre-installed, making it convenient for learning and experimentation.

Step 1: Open AWS Console

In the search bar type:

CloudShell

and wait for the terminal to open.

Step 2: Verify AWS CLI

aws --version

You will get an output like this:

aws-cli/2.x

Note: CloudShell automatically uses the credentials of the currently logged-in IAM user.

Therefore, unlike local installation, there is no need to run:

aws configure

Running our First AWS CLI Command

Now let's check whether AWS CLI can access our resources.

Run:

aws s3 ls

means:

List all S3 buckets available in my AWS account

Example output will be like this:

2025-11-02  my-learning-notes-example
2025-11-03  demo-cli-bucket

Exploring AWS CLI Documentation

AWS provides documentation for every service.

For example, search:

AWS CLI S3 reference

Here you will see a bunch of available commands and how to use them in detail.

For example:

List Buckets

aws s3 ls

Create Bucket

aws s3 mb s3://mydemo-s3-bucket-for-cli

One of the best ways to become comfortable with AWS CLI is by exploring the official documentation and trying commands on your own.

AWS provides CLI references for almost every service.

For example, if you want to learn EC2 commands, search:

AWS CLI EC2 Reference

Spend some time browsing the documentation and try commands in your environment.

Key Takeaways

In this article, we learned:

✅ What AWS CLI is
✅ Why AWS CLI is useful
✅ How AWS APIs work
✅ Installing AWS CLI
✅ Creating Access Keys
✅ Configuring AWS CLI
✅ Running our first commands
✅ Exploring AWS CLI documentation

Conclusion

AWS CLI makes managing AWS resources faster and easier.

Instead of repeatedly performing manual tasks through the AWS Console, we can interact with AWS services directly from the terminal.

AWS CLI is excellent for quick actions and small automation tasks.

However, as infrastructure grows larger, managing resources using individual commands becomes difficult.

This is where Infrastructure as Code (IaC) tools become extremely useful.

What's Next?

In the next article, we will begin exploring Infrastructure as Code (IaC) and understand:

What is AWS CloudFormation (CFT)?
CloudFormation vs Terraform
Tips and Tricks for Writing CloudFormation Templates
Why production teams prefer Infrastructure as Code

From this point onward, we will start moving from individual commands to managing complete infrastructure using code. 🚀

AWS S3 Hands-On Project | Buckets, Versioning, Permissions and Static Website Hosting

Vijaya Laxmi Kadham — Sat, 20 Jun 2026 12:53:51 +0000

Introduction

In the previous article, we learned the theory behind Amazon S3.

Now it is time to see Amazon S3 in action.

In this hands-on project, we will:

Create an S3 bucket
Upload files
Understand Objects inside S3
Enable Bucket Versioning
Create IAM User
Control access using Bucket Policies
Host a Static Website using S3

By the end of this article, we will understand some of the most commonly used Amazon S3 features.

Step 1: Create an S3 Bucket

Search for S3.

Open the dashboard.

Click on Create Bucket.

Provide:

Bucket Name

Give your bucket a name, for example:

my-learning-notes-example

Bucket names must be globally unique.

For now, leave all the remaining settings as default.

Click on Create Bucket.

Step 2: Explore the Bucket

Open the bucket you just created.

Initially, you will notice:

Objects (0)

because the bucket is empty.

Think of a bucket as a folder that stores files.

Step 3: Upload Your First Object

Click on:

Upload

Then click:

Add files

Choose any file.

Click:

Upload

After the upload finishes, you will see the file inside the bucket.

In Amazon S3, every uploaded file is called an Object.

Now if you look inside the bucket, you will notice that Objects are no longer zero because we have uploaded a file.

Step 4: Explore Object Options

Click on the uploaded Object.

Explore the options:

Open

Select the file and click Open.

It will display the contents of the file.

Download

Select the file and click Download.

The file will be downloaded to your system.

Delete

If you select Delete, AWS will ask for confirmation before deleting the object.

This helps you understand how S3 manages objects.

Step 5: Enable Bucket Versioning

Suppose you upload:

demo-learning-s3.txt

Later, you modify the file and upload it again.

Without versioning, the old file gets overwritten.

Versioning allows you to preserve previous versions.

Go to:

Bucket → Properties

Scroll to:

Bucket Versioning

Click:

Edit

Choose:

Enable

Click:

Save Changes

Now if you check the bucket properties, you can see that versioning is enabled.

Step 6: Upload a New Version

Modify your file.

Before

AWS S3 Notes version 1

After

AWS S3 Notes version 2

Upload the file again using the same filename.

Now open the Object.

Click:

Versions

You will see multiple versions.

This is similar to maintaining history in Git.

Step 7: Create an IAM User

In AWS Console, search for:

IAM

Go to:

IAM → Users → Create User

Give a name:

demo-s3-user

Assign a password.

Click:

Create User

Step 8: Verify Permissions

Open an Incognito browser.

Try accessing the Amazon S3 bucket.

Also try creating a bucket.

Initially, you will receive permission errors.

This happens because the user has no S3 permissions.

Step 9: Grant S3 Permissions

Open:

IAM → Users → demo-s3-user

Click:

Add Permissions

Attach:

AmazonS3FullAccess

Click:

Save

Now refresh the IAM user session.

The demo-s3-user can now access S3.

Step 10: Explore Bucket Permissions

Open:

S3 → Bucket → Permissions

You will notice:

Bucket Policies
Block Public Access
Access Control

These settings provide an additional security layer.

Even if IAM permissions are accidentally misconfigured, Bucket Policies can still protect your bucket.

Step 11: Enable Static Website Hosting

Create a simple index.html file.

Upload this file to your bucket.

Now go to:

Bucket → Properties

Scroll to:

Static Website Hosting

Click:

Edit

Enable:

Static Website Hosting

Set:

Index Document: index.html

Click:

Save Changes

AWS will generate a website endpoint.

Try accessing the website endpoint URL.

You will notice that you still cannot access it even if you have S3 Full Access.

This happens because there are still S3 permissions blocking public access.

Step 12: Remove Public Access Block

Go to:

Permissions

Locate:

Block Public Access

Click:

Edit

Disable public access.

Confirm the warning.

When you try to access the URL again, you may still receive:

403 Forbidden

Although Static Website Hosting is enabled, the files inside the bucket are still private.

AWS requires explicit permission before users on the internet can read objects inside an S3 bucket.

To solve this, we need to create a Bucket Policy.

Step 13: Add Bucket Policy for Public Read

Go to:

Permissions → Bucket Policy → Edit

Click:

Add New Statement

Initially, AWS provides a template similar to:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Principal": {},
      "Effect": "Allow",
      "Action": [],
      "Resource": []
    }
  ]
}

We need to fill these values.

Understanding the Fields

Sid

Used to identify the policy statement.

"Sid": "PublicReadGetObject"

Principal

Defines who the rule applies to.

"Principal": "*"

The * means anyone on the internet.

Effect

Specifies whether AWS should allow or deny the action.

"Effect": "Allow"

Action

Defines which permission we are granting.

"Action": "s3:GetObject"

This allows users to read objects inside the bucket.

Resource

Specifies which bucket objects the rule applies to.

Example:

"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"

Replace YOUR_BUCKET_NAME with your actual bucket name.

The /* means apply the rule to all objects inside the bucket.

My bucket name is:

my-learning-notes-example

Therefore, the policy becomes:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Principal": "*",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-learning-notes-example/*"
    }
  ]
}

Click:

Save Changes

Note: Replace my-learning-notes-example with your own bucket name.

Step 14: Access the Website

Go back to:

Bucket → Properties

Scroll down to:

Static Website Hosting

Copy the:

Bucket Website Endpoint URL

Paste it into your browser.

Now, instead of receiving the 403 Forbidden error, your webpage should load successfully.

Congratulations 🎉

You have successfully hosted your first static website using Amazon S3.

Key Takeaways

In this hands-on project, we learned how to:

✅ Create an S3 bucket
✅ Upload objects
✅ Understand bucket and object concepts
✅ Enable versioning
✅ Create IAM users
✅ Understand permissions
✅ Explore bucket policies
✅ Host a static website

What's Next?

In the next article, we will explore another important AWS service and continue building our cloud learning journey.

AWS S3 Basics for Beginners

Vijaya Laxmi Kadham — Sat, 20 Jun 2026 12:24:59 +0000

Introduction

In the previous articles, we explored AWS networking concepts like:

VPC
Subnets
Internet Gateway
Security Groups
Route 53

Now, let's move to one of the most popular AWS services:

Amazon S3 (Simple Storage Service)

Amazon S3 is one of the easiest AWS services to learn and one of the most widely used services in real-world applications.

Almost every application stores some kind of data:

Images
Videos
Documents
Log files
Backups
Static websites

Amazon S3 helps us store and retrieve these files securely from anywhere in the world.

In this article, we will understand:

What Amazon S3 is
Buckets and Objects
Benefits of S3
Storage Classes
Versioning
Basic security concepts
Static website hosting overview

Why Do We Need Storage?

Imagine you are running an online photo-sharing application.

Users upload:

Profile pictures
Photos
Videos

Where should these files be stored?

Keeping them directly inside application servers is not a good idea because:

Storage is limited.
Scaling becomes difficult.
Replacing servers may cause data loss.

This is where Amazon S3 helps.

What is Amazon S3?

Amazon S3 stands for:

Simple Storage Service

It is a cloud-based object storage service provided by AWS.

S3 allows us to:

Store data
Retrieve data
Manage data

from anywhere using the internet.

Amazon S3 is designed to be:

Highly available
Durable
Scalable
Secure
Cost-effective

Real-World Example

Think of Amazon S3 as a digital warehouse.

Suppose you own an e-commerce company.

Inside your warehouse, you store:

Product images
Invoices
Customer documents
Videos

Similarly, Amazon S3 stores digital files safely in the cloud.

Buckets and Objects

Amazon S3 stores data using two concepts:

Bucket

A bucket is a container used to store files.

Think of a bucket like a folder.

Examples:

company-documents
customer-images
application-logs

Bucket names must be globally unique.

Object

Anything stored inside a bucket is called an Object.

Examples:

invoice.pdf
profile.jpg
backup.zip
video.mp4

Objects can contain:

Images
Videos
HTML files
CSV files
JSON files
Log files

Almost any file type can be stored in S3.

Real-Life Example

Cupboard (Bucket)
    ↓
Files and Documents (Objects)

Similarly:

S3 Bucket
    ↓
Objects

Benefits of Amazon S3

1. High Durability

Amazon S3 is famous for its durability.

AWS provides:

99.999999999%

durability.

This is often called:

Eleven 9's of Durability

AWS automatically keeps multiple copies of your data to prevent data loss.

2. High Availability

S3 is designed to remain accessible even if some infrastructure components fail.

Applications can continue accessing files without interruption.

3. Scalability

You don't need to estimate storage in advance.

Whether you store:

10 files
10 million files

Amazon S3 automatically scales.

4. Security

AWS provides multiple security mechanisms:

IAM Policies
Bucket Policies
Encryption
Access Control

These help protect sensitive data.

5. Cost Effective

You only pay for:

Storage used
Requests made

There is no need to purchase storage hardware.

6. High Performance

Amazon S3 supports:

Parallel uploads
Multipart uploads

This improves performance for large files.

S3 Storage Classes

Not every file needs the same level of access.

AWS provides different storage classes.

S3 Standard

Used for frequently accessed files.

Examples:

Website images
Application assets

S3 Standard-IA

IA stands for:

Infrequent Access

Used for files accessed occasionally.

Examples:

Monthly reports
Older documents

One Zone-IA

Stores data in a single Availability Zone.

Cheaper but less resilient.

Suitable for:

Backup copies
Temporary files

S3 Glacier

Used for long-term archival storage.

Examples:

Old backups
Compliance records

Retrieval is slower but storage cost is very low.

What is Versioning?

Suppose today you upload:

report.csv

Tomorrow, you modify the same file and upload it again.

What if you later discover that yesterday's version was correct?

Versioning helps solve this problem.

When versioning is enabled:

Old versions are preserved.
New uploads create new versions.
Previous files can be restored.

Real-Life Example

Think about Git.

Every commit stores history.

Similarly, S3 Versioning stores file history.

Static Website Hosting

Amazon S3 can also host static websites.

Examples:

Portfolio websites
Documentation sites
Landing pages

Files like:

index.html
style.css
logo.png

can be served directly from S3.

Because static websites do not require servers, S3 hosting is:

Simple
Fast
Low cost

Understanding S3 Security

AWS provides multiple layers of security.

Examples:

IAM Policies

Control what users can do.

Bucket Policies

Control who can access a bucket.

Encryption

Protects stored data.

Even if IAM permissions are accidentally configured incorrectly, bucket policies can provide an additional security layer.

Common Use Cases of Amazon S3

Amazon S3 is used for:

Image storage
Video storage
Backup and recovery
Application logs
Static website hosting
Data archival
Data lakes
Big data workloads

Official AWS Documentation

If you'd like to explore S3 in more detail, AWS provides excellent documentation.

Amazon S3 Documentation

https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html

Amazon S3 Overview

https://aws.amazon.com/s3/

Conclusion

Amazon S3 is one of the most important AWS services and is widely used in almost every cloud application.

In this article, we learned:

What Amazon S3 is
Buckets and Objects
Benefits of S3
Storage Classes
Versioning
Security concepts
Static website hosting overview

In the next article, we will perform hands-on exercises and:

Create S3 buckets
Upload files
Enable versioning
Configure permissions
Create IAM users
Host a static website using Amazon S3

AWS S3 Basics for Beginners

Vijaya Laxmi Kadham — Wed, 17 Jun 2026 12:27:17 +0000

Introduction

In the previous articles, we explored AWS networking concepts like:

VPC
Subnets
Internet Gateway
Security Groups
Route 53

Now, let's move to one of the most popular AWS services:

Amazon S3 (Simple Storage Service)

Amazon S3 is one of the easiest AWS services to learn and one of the most widely used services in real-world applications.

Almost every application stores some kind of data:

Images
Videos
Documents
Log files
Backups
Static websites

Amazon S3 helps us store and retrieve these files securely from anywhere in the world.

In this article, we will understand:

What Amazon S3 is
Buckets and Objects
Benefits of S3
Storage Classes
Versioning
Basic security concepts
Static website hosting overview

Why Do We Need Storage?

Imagine you are running an online photo-sharing application.

Users upload:

Profile pictures
Photos
Videos

Where should these files be stored?

Keeping them directly inside application servers is not a good idea because:

Storage is limited.
Scaling becomes difficult.
Replacing servers may cause data loss.

This is where Amazon S3 helps.

What is Amazon S3?

Amazon S3 stands for:

Simple Storage Service

It is a cloud-based object storage service provided by AWS.

S3 allows us to:

Store data
Retrieve data
Manage data

from anywhere using the internet.

Amazon S3 is designed to be:

Highly available
Durable
Scalable
Secure
Cost-effective

Real-World Example

Think of Amazon S3 as a digital warehouse.

Suppose you own an e-commerce company.

Inside your warehouse, you store:

Product images
Invoices
Customer documents
Videos

Similarly, Amazon S3 stores digital files safely in the cloud.

Buckets and Objects

Amazon S3 stores data using two concepts:

Bucket

A bucket is a container used to store files.

Think of a bucket like a folder.

Examples:

company-documents
customer-images
application-logs

Bucket names must be globally unique.

Object

Anything stored inside a bucket is called an Object.

Examples:

invoice.pdf
profile.jpg
backup.zip
video.mp4

Objects can contain:

Images
Videos
HTML files
CSV files
JSON files
Log files

Almost any file type can be stored in S3.

Real-Life Example

Cupboard (Bucket)
    ↓
Files and Documents (Objects)

Similarly:

S3 Bucket
    ↓
Objects

Benefits of Amazon S3

1. High Durability

Amazon S3 is famous for its durability.

AWS provides:

99.999999999%

durability.

This is often called:

Eleven 9's of Durability

AWS automatically keeps multiple copies of your data to prevent data loss.

2. High Availability

S3 is designed to remain accessible even if some infrastructure components fail.

Applications can continue accessing files without interruption.

3. Scalability

You don't need to estimate storage in advance.

Whether you store:

10 files
10 million files

Amazon S3 automatically scales.

4. Security

AWS provides multiple security mechanisms:

IAM Policies
Bucket Policies
Encryption
Access Control

These help protect sensitive data.

5. Cost Effective

You only pay for:

Storage used
Requests made

There is no need to purchase storage hardware.

6. High Performance

Amazon S3 supports:

Parallel uploads
Multipart uploads

This improves performance for large files.

S3 Storage Classes

Not every file needs the same level of access.

AWS provides different storage classes.

S3 Standard

Used for frequently accessed files.

Examples:

Website images
Application assets

S3 Standard-IA

IA stands for:

Infrequent Access

Used for files accessed occasionally.

Examples:

Monthly reports
Older documents

One Zone-IA

Stores data in a single Availability Zone.

Cheaper but less resilient.

Suitable for:

Backup copies
Temporary files

S3 Glacier

Used for long-term archival storage.

Examples:

Old backups
Compliance records

Retrieval is slower but storage cost is very low.

What is Versioning?

Suppose today you upload:

report.csv

Tomorrow, you modify the same file and upload it again.

What if you later discover that yesterday's version was correct?

Versioning helps solve this problem.

When versioning is enabled:

Old versions are preserved.
New uploads create new versions.
Previous files can be restored.

Real-Life Example

Think about Git.

Every commit stores history.

Similarly, S3 Versioning stores file history.

Static Website Hosting

Amazon S3 can also host static websites.

Examples:

Portfolio websites
Documentation sites
Landing pages

Files like:

index.html
style.css
logo.png

can be served directly from S3.

Because static websites do not require servers, S3 hosting is:

Simple
Fast
Low cost

Understanding S3 Security

AWS provides multiple layers of security.

Examples:

IAM Policies

Control what users can do.

Bucket Policies

Control who can access a bucket.

Encryption

Protects stored data.

Even if IAM permissions are accidentally configured incorrectly, bucket policies can provide an additional security layer.

Common Use Cases of Amazon S3

Amazon S3 is used for:

Image storage
Video storage
Backup and recovery
Application logs
Static website hosting
Data archival
Data lakes
Big data workloads

Official AWS Documentation

If you'd like to explore S3 in more detail, AWS provides excellent documentation.

Amazon S3 Documentation

https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html

Amazon S3 Overview

https://aws.amazon.com/s3/

Conclusion

Amazon S3 is one of the most important AWS services and is widely used in almost every cloud application.

In this article, we learned:

What Amazon S3 is
Buckets and Objects
Benefits of S3
Storage Classes
Versioning
Security concepts
Static website hosting overview

In the next article, we will perform hands-on exercises and:

Create S3 buckets
Upload files
Enable versioning
Configure permissions
Create IAM users
Host a static website using Amazon S3

🚀 AWS VPC Project: Build a Production-Ready Architecture with EC2, ALB, ASG & Bastion Host

Vijaya Laxmi Kadham — Thu, 11 Jun 2026 05:33:40 +0000

In the previous articles, we learned about:

VPC
subnets
Internet Gateway
Route Tables
Security Groups
Network ACLs
DNS and Route 53

Until now, we have learned individual AWS networking components separately.

But in real world projects, these services work together to build secure and highly available applications.

What We Will Build

In this project, we will create:

A custom VPC
Public and Private Subnets
Two Availability Zones
NAT Gateways
Bastion Host
Auto Scaling Group
Application Load Balancer
Target Group
EC2 Instances running inside Private Subnets

By the end of this project, you will understand how traffic flows inside AWS and how different networking components work together.

Why Are We Using Two Availability Zones?

In production environments, applications are usually deployed across multiple Availability Zones (AZs).

This improves High Availability.

For example, if one AZ experiences a failure, the application can continue serving users from the second AZ.

This helps reduce downtime and improves reliability.

Therefore, in this project, we will use:

2 Availability Zones (AZs)
2 Public Subnets
2 Private Subnets

Architecture Overview

Each Availability Zone (AZ) will contain:

Public Subnet

NAT Gateway
Application Load Balancer

Private Subnet

EC2 Instances launched using an Auto Scaling Group

The EC2 instances will remain private and will not have public IP addresses.

We will access them securely using a Bastion Host.

What You Will Learn

We will also understand:

How internet traffic reaches the application.
How private servers access the internet using a NAT Gateway.
How the Load Balancer distributes traffic.
How Auto Scaling Groups help applications handle increased traffic.

Before We Start

Before starting the implementation, let's first understand some of the concepts that we will use throughout this project.

Don't worry if these concepts seem new right now — we will see them in action during the implementation.

What is NAT Gateway?

A NAT (Network Address Translation) Gateway allows resources inside a private subnet to access the internet without exposing them directly to the internet.

In our project, the application servers will be running inside private subnets and will not have public IP addresses.

However, there may be situations where these servers need internet access, such as:

Downloading software packages
Installing updates
Accessing public APIs

This is where the NAT Gateway helps.

Example

Private EC2
     ↓
NAT Gateway
     ↓
  Internet

The private EC2 instance can access the internet, but internet users cannot directly access the EC2 instance.

This improves security while still allowing outbound internet connectivity.

What is Auto Scaling Group?

An Auto Scaling Group (ASG) helps automatically manage EC2 instances based on application demand.

Imagine your application normally runs on 2 EC2 instances.

Suddenly, a large number of users start accessing the application.

The existing servers may not be enough to handle the traffic.

In such situations, an Auto Scaling Group can automatically launch additional EC2 instances.

Similarly, when traffic decreases, it can terminate unnecessary instances.

Example

Normal Traffic
      ↓
2 EC2 Instances
      ↓
 High Traffic
      ↓
4 EC2 Instances
      ↓
 Low Traffic
      ↓
2 EC2 Instances

Benefits of Auto Scaling Groups

Auto Scaling Groups help to:

Improve availability
Handle traffic spikes
Optimize infrastructure costs

What is Load Balancer?

A Load Balancer distributes incoming traffic across multiple servers.

Instead of sending all requests to a single server, it spreads the traffic across multiple EC2 instances.

Example

Users
   ↓
Load Balancer
   ↓
├── EC2 Instance 1
├── EC2 Instance 2
└── EC2 Instance 3

Benefits of Load Balancer

A Load Balancer helps to:

Improve performance
Prevent server overload
Increase application availability

In this project, users will access the application through the Load Balancer.

What is Target Group?

A Target Group is a collection of servers that receive traffic from a Load Balancer.

Think of a Target Group as a list of backend servers.

When the Load Balancer receives a request, it forwards that request to one of the healthy servers registered inside the Target Group.

Example

Load Balancer
      ↓
Target Group
      ↓
├── EC2 Instance 1
├── EC2 Instance 2
└── EC2 Instance 3

How Target Groups Work

The Load Balancer does not directly send traffic to EC2 instances.

Instead, it sends traffic through the Target Group, which then routes requests to healthy EC2 instances.

This helps:

Route traffic efficiently
Perform health checks on backend servers
Improve application availability
Ensure requests are sent only to healthy instances

What is a Bastion Host?

A Bastion Host, also called a Jump Server, is an EC2 instance placed inside a public subnet that is used to securely access resources inside private subnets.

In our project, the application servers will be running in private subnets and will not have public IP addresses.

This means we cannot directly SSH into them.

To solve this problem, we create a Bastion Host.

Example

Developer Laptop
       ↓
   Bastion Host
       ↓
   Private EC2

Instead of exposing private servers to the internet, we first connect to the Bastion Host and then access the private servers.

Benefits of Using a Bastion Host

This approach provides:

Better security
Centralized access control
Better auditing and monitoring

Now that we understand the components used in this project, let's start building the architecture step by step.

Hands-On Implementation of the Project

Before starting, we will build the following architecture:

                    Internet
                        │
                       ▼
                Application Load Balancer
                        │
        ┌───────────────┴───────────────┐
        │                               │
 Availability Zone A             Availability Zone B
        │                               │
 Public Subnet A                 Public Subnet B
 ├── NAT Gateway A               ├── NAT Gateway B
 └── Bastion Host

        │                               │

 Private Subnet A               Private Subnet B
 └── EC2 Instance (ASG)         └── EC2 Instance (ASG)

Architecture Diagram

The above architecture diagram may look confusing at first, but don't worry.

Once we follow the implementation steps below and revisit the diagram, the overall flow and the relationship between the AWS components will become much easier to understand.

Step 1: Create the VPC

Go to AWS Console → VPC.

Click on Create VPC.

Select VPC and more.

Why?

Because AWS automatically creates:

VPC
Public Subnets
Private Subnets
Route Tables
Internet Gateway

This saves time and simplifies the setup process.

Now, give your VPC a name, for example:

aws-prod-proj

For the IPv4 CIDR Block, use:

10.0.0.0/16

This provides approximately 65,536 IP addresses, which is more than enough for our project.

For IPv6 CIDR Block, choose:

No IPv6 CIDR block

Why?

To keep the project simple.

Configure the following:

Number of Availability Zones (AZs): 2
Public Subnets: 2
Private Subnets: 2

So the architecture becomes:

AZ-1
├── Public Subnet
└── Private Subnet

AZ-2
├── Public Subnet
└── Private Subnet

Configure NAT Gateway

For NAT Gateway, choose:

Zonal → 1 per AZ

Why?

Private EC2 instances need internet access for:

Installing updates
Downloading software packages
Accessing public APIs

However, we do not want to assign public IP addresses to those instances.

The NAT Gateway solves this problem by providing outbound internet access while keeping the instances private.

Configure VPC Endpoints

For VPC Endpoints, choose:

None

Why?

We are not using VPC Endpoints in this project.

Finally, click Create VPC.

Wait for AWS to finish creating all the required resources.

Step 2: Verify the Resource Map

After the VPC creation is complete, navigate to:

VPC → Your VPC → Select Your VPC → Resource Map

You should see the following resources:

✅ VPC
✅ Internet Gateway
✅ Public Subnet A
✅ Public Subnet B
✅ Private Subnet A
✅ Private Subnet B
✅ NAT Gateway A
✅ NAT Gateway B
✅ Route Tables

Understanding What AWS Created

Public Subnets

Public Subnets are:

Accessible from the internet
Used for internet-facing resources

Examples include:

Load Balancers
Bastion Hosts
NAT Gateways

Private Subnets

Private Subnets are:

Hidden from the internet
Used for application servers

Examples include:

EC2 Instances
Backend Services
Databases

Step 3: Create Launch Template

Before creating the Auto Scaling Group, we first need a Launch Template.

Why Do We Need a Launch Template?

Think of a Launch Template as a blueprint for EC2 instances.

It tells AWS:

Which operating system (AMI) to use
Which instance type to launch
Which key pair to use
Which Security Group to attach
Which VPC to use

Later, whenever the Auto Scaling Group needs to create new servers, it simply uses this template.

Navigate to Launch Templates

Go to:

AWS Console → EC2 → Launch Templates

Click on Create Launch Template.

Configure the Launch Template

Give your Launch Template a name:

aws-prod-proj

In the description field, enter:

Launch template for application servers running in private subnets

Choose an AMI

For the AMI (Operating System), choose:

The Recently Launched option, or
Any AMI you are comfortable with

Choose the Instance Type

Select:

t3.micro (Free Tier)

Select the Key Pair

Choose your key pair, for example:

test_app.pem

Configure Network Settings

Under Firewall (Security Groups), select:

Create Security Group

Security Group Name

aws-prod-proj

Description

Security Group for private application servers

Configure Inbound Rules

Rule 1

Type	Port	Source
SSH	22	My IP

Why?

Initially, we will keep SSH access simple while building the project.

Later, we will tighten security so that only the Bastion Host can access these servers.

Rule 2

Type	Port	Source
Custom TCP	8000	Anywhere IPv4

Why?

Our Python application will run on Port 8000.

Later, once the Load Balancer is configured, we will improve this rule further.

For now, leave everything else as default.

Click on Create Launch Template.

What Have We Created?

We haven't created EC2 instances yet.

We have only created a blueprint.

Launch Template
        ↓
Auto Scaling Group
        ↓
EC2 Instances

Step 4: Creating Auto Scaling Group

Until now, we have only created the blueprint (Launch Template).

Now we need AWS to actually launch EC2 instances from that blueprint.

Why Do We Need Auto Scaling Groups?

Auto Scaling Groups (ASGs) help:

Automatically create EC2 instances
Replace unhealthy instances
Scale up during high traffic
Scale down during low traffic

Navigate to Auto Scaling Groups

Go to:

AWS Console → EC2 → Auto Scaling Groups

Click on Create Auto Scaling Group.

Configure the Auto Scaling Group

Give your Auto Scaling Group a name, for example:

aws-prod-proj

Select the Launch Template we created earlier:

aws-prod-proj

Click Next.

Choose the Network

Select the VPC we created earlier:

aws-prod-proj

Under Availability Zones and Subnets, choose the two private subnets created during VPC creation:

Private Subnet 1a
Private Subnet 1b

Why Are We Using Private Subnets?

Application servers should not be directly exposed to the internet.

This improves security.

The architecture becomes:

Public Subnets
      ↓
Load Balancer
      ↓
Private EC2 Instances

Click Next.

Leave the remaining settings as default and click Next again.

Configure Group Size

Set the following values:

Desired Capacity

Meaning AWS should maintain 2 EC2 instances.

Minimum Capacity

At least one instance should always remain running.

Maximum Capacity

In the future, AWS can scale up to four servers if required.

Scaling Policies

Choose:

None

Skip the remaining sections and keep the default settings.

Click Next → Create Auto Scaling Group.

Step 5: Verify EC2 Instances

Now navigate to:

EC2 → Instances

Wait for a few minutes.

You should see:

Instance 1 → Running
Instance 2 → Running

Click on any instance ID and inspect its details.

If you look carefully, you will notice:

Public IPv4 Address = None

This is expected.

Why?

Because:

The instances are inside private subnets.
Private subnets should not have public IP addresses.

Current Architecture

At this stage, the architecture looks like this:

                VPC
                  │
      ┌───────────┴───────────┐
      │                       │
Availability Zone A   Availability Zone B
      │                       │
Private Subnet A      Private Subnet B
      │                       │
EC2 Instance 1        EC2 Instance 2

Step 6: Create Bastion Host

Why Do We Need a Bastion Host?

Imagine your company has hundreds of servers running inside private subnets.

Giving public IP addresses to all servers would be dangerous.

Instead, we create one secure entry point called a Bastion Host.

The architecture becomes:

Developer Laptop
        ↓
Bastion Host (Public Subnet)
        ↓
Private EC2 Instances

Create Bastion Host

Go to:

AWS Console → EC2 → Launch Instance

Give your instance a name:

bastion-host

AMI

Choose:

Ubuntu Server

Instance Type

Choose:

t3.micro (Free Tier)

Key Pair

Select the same key pair used earlier:

test_app.pem

Configure Network Settings

Click Edit.

Select the VPC:

aws-prod-proj

IMPORTANT: Choose a Public Subnet

Select either:

Public Subnet A, or
Public Subnet B

Why?

Because the Bastion Host must be reachable from your laptop.

Auto Assign Public IP

Choose:

Enable

Why?

Without a public IP address, you won't be able to SSH into the Bastion Host.

Configure Security Group

Choose:

Create Security Group

Security Group Name:

bastion-sg

Configure Inbound Rules

Instead of:

❌ Anywhere (0.0.0.0/0)

Choose:

✅ My IP

Type	Port	Source
SSH	22	My IP

Why?

This is much safer.

Only your laptop can access the Bastion Host.

Step 7: Verify Bastion Host

After the instance starts, navigate to:

EC2 → Instances

Verify that:

The instance state is Running
A Public IPv4 Address is present

Current architecture:

                Internet
                     │
                     ▼
               Bastion Host
                     │
      ┌──────────────┴──────────────┐
      │                             │
 Private EC2-1                Private EC2-2

Bastion Host Status

✅ Running
✅ Has Public IP
✅ Security Group allows SSH from My IP

Step 8: Improve Security Group Configuration (Production Best Practice)

Right now, when we created the Launch Template earlier, we allowed:

SSH (22) → My IP

for the private EC2 instances.

Although this works, it is not ideal because application servers should only accept SSH connections from the Bastion Host.

Current Situation

Laptop
   ↓
Private EC2

Better Architecture

Laptop
   ↓
Bastion Host
   ↓
Private EC2

Step 8.1: Find the Security Group Attached to Private EC2

Go to:

EC2 → Instances

Open one of your private instances.

Go to the Security tab.

Click on the attached Security Group.

Step 8.2: Remove SSH Access from "My IP"

Inside the Security Group:

Click Edit Inbound Rules.

It should currently have:

Type	Port	Source
SSH	22	My IP
Custom TCP	8000	Anywhere

Delete the SSH rule.

Keep Port 8000 for now.

Click Save Rules.

Step 8.3: Allow SSH Only from Bastion Host

Click Add Rule.

Configure:

Type: SSH
Port: 22
Source: Custom

In the search bar next to Source, select:

bastion-sg

This is the Security Group attached to the Bastion Host.

Click Save Rules.

What We Achieved

Instead of:

My Laptop
      ↓
Private EC2

we now have:

My Laptop
      ↓
Bastion Host
      ↓
Private EC2

Only the Bastion Host can SSH into the private servers.

Step 9: Connect to Bastion Host

Copy the Bastion Host Public IP Address.

On your local machine, run:

ssh -i test_app.pem ubuntu@<BASTION_PUBLIC_IP>

Connection Issue Encountered

When running the above command, I received the following error:

ssh: connect to host <PUBLIC_IP> port 22: Connection timed out

To verify whether the issue was related to the Security Group, I temporarily modified the inbound rule:

From:

Source: My IP

To:

Anywhere IPv4 (0.0.0.0/0)

After saving the rule, I was able to successfully SSH into the Bastion Host.

Note: Allowing SSH from Anywhere IPv4 was done only for troubleshooting purposes. In production environments, it is recommended to restrict SSH access to trusted IP addresses.

Step 10: Enable SSH Agent Forwarding (Best Practice)

Instead of copying the .pem file into the Bastion Host, we'll use SSH Agent Forwarding.

1. Start SSH Agent

On your local machine, run:

eval "$(ssh-agent -s)"

What Does This Do?

It starts a background process called SSH Agent.

Think of SSH Agent as a temporary secure locker that can hold your SSH keys.

After running:

eval "$(ssh-agent -s)"

You should see output similar to:

Agent pid 12345

2. Add the Private Key

Run:

ssh-add test_app.pem

What Does This Do?

This command loads your .pem file into the SSH Agent.

Now the SSH Agent can use this key whenever authentication is required.

3. Verify Loaded Keys

Run:

ssh-add -l

What Does This Do?

This command displays the keys currently loaded inside the SSH Agent.

Example output:

Step 11: Connect to Bastion Using Agent Forwarding

From your laptop, run:

ssh -A -i test_app.pem ubuntu@<BASTION_PUBLIC_IP>

Notice the important option:

-A

Why Are We Using `-A`?

The -A option enables SSH Agent Forwarding.

This securely forwards your local SSH key to the Bastion Host without copying the .pem file to the server.

This is considered a best practice because:

The private key never leaves your laptop.
No sensitive files are stored on the Bastion Host.
Access to private EC2 instances becomes more secure.

Step 12: Find the Private IP of One Application Server

Go to:

EC2 → Instances

Choose one of the private EC2 instances.

Copy its:

Private IPv4 Address

Example:

10.0.131.24

Step 13: SSH From Bastion Host to Private EC2

From inside the Bastion Host, run:

ssh ubuntu@10.0.x.x

Replace 10.0.x.x with the private IP address of your EC2 instance.

The connection should now be successful, and you will be inside the private server.

Current Architecture

Laptop
   ↓
SSH Agent Forwarding
   ↓
Bastion Host
   ↓
Private EC2

Step 14: Prepare the Private EC2 Instance

At this point, you should be logged into the private EC2 instance.

Verify this by running:

hostname

Update Package Information

Run:

sudo apt update

Why?

This updates the package repository information.

It also verifies that the following path is working correctly:

Private EC2
      ↓
NAT Gateway
      ↓
Internet

If the update completes successfully, your NAT Gateway is functioning correctly.

Step 15: Verify Python Installation

Check the installed Python version:

python3 --version

Expected output:

Python 3.x.x

If Python is not installed, run:

sudo apt install python3 -y

Step 16: Create a Simple HTML Page

Create a new file:

vim index.html

Press:

to enter Insert Mode.

Paste the following HTML:

<!DOCTYPE html>
<html>
<head>
    <title>AWS Production Project</title>
</head>
<body>
    <h1>AWS VPC Production Project</h1>
    <p>Application running successfully inside Private Subnet.</p>
</body>
</html>

Save the file:

ESC
:wq!

Step 17: Start Python Web Server

Run:

python3 -m http.server 8000

Expected output:

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Leave this terminal running.

The web server is now serving the application on Port 8000.

Step 18: Verify Security Group for Application

Before creating the Load Balancer, verify the Security Group attached to your application servers.

Go to:

EC2 → Security Groups

Open the private EC2 Security Group created earlier.

Example:

aws-prod-proj

Verify that the following inbound rules exist:

Type	Port	Source
SSH	22	bastion-sg
Custom TCP	8000	Anywhere IPv4

If Port 8000 is missing, add it click Save Rules.

Why Are We Allowing Port 8000?

Because later the traffic flow will be:

Load Balancer
      ↓
Port 8000
      ↓
Application Server

The Load Balancer must be able to reach the application.

We'll improve this later by allowing access only from the Load Balancer Security Group.

Step 19: Verify the Application Is Running

On the private EC2 instance, open another SSH session if needed and run:

curl localhost:8000

Expected output:

<!DOCTYPE html>
<html>
...

If you see the HTML page, your application is running successfully.

Step 20: Create a Target Group

What is a Target Group?

Before creating a Load Balancer, AWS needs to know:

"Which servers should receive the traffic?"

A Target Group is simply a collection of backend servers.

Example:

Load Balancer
      ↓
Target Group
      ↓
├── EC2 Instance 1
└── EC2 Instance 2

Navigate to Target Groups

Go to:

EC2 → Target Groups

Click:

Create Target Group

Basic Configuration

Target Type

Choose:

Instances

Why?

Because we want traffic to be routed directly to EC2 instances.

Target Group Name

Example:

aws-prod-proj

Protocol

Choose:

HTTP

Port

Enter:

Why?

Our Python application is listening on:

python3 -m http.server 8000

VPC

Select:

aws-prod-proj

Health Check Protocol

Keep:

HTTP

Health Check Path

Keep:

This means AWS will periodically check:

http://instance-ip:8000/

to verify that the application is healthy.

Click Next.

Register Targets

You should see your Auto Scaling instances.

Select:

Instance 1
Instance 2

Click:

Include as Pending Below

Then click:

Create Target Group

Step 21: Create Application Load Balancer

Now let's create the public entry point for users.

Navigate to Load Balancers

Go to:

EC2 → Load Balancers

Click:

Create Load Balancer

Choose:

Application Load Balancer

Then click:

Create

Configure the Load Balancer

Name

Example:

aws-prod-proj

Scheme

Select:

Internet-facing

Why?

Users will access the application from the internet.

IP Address Type

Choose:

IPv4

Network Mapping

Select the VPC created earlier:

aws-prod-proj

Availability Zones

Choose:

Public Subnet A
Public Subnet B

Why?

Load Balancers must be deployed inside public subnets.

Security Group

For now, choose:

default

This is the cleaner option.

Listener and Routing

Listener

HTTP

Port

Default Action

Select:

Forward to Target Groups

Choose the Target Group created earlier:

aws-prod-proj

Click:

Create Load Balancer

Wait a few minutes for AWS to provision the Load Balancer.

Step 22: Check Target Health

Go to:

EC2 → Target Groups

Open:

aws-prod-proj

Click:

Targets

Verify that your targets are healthy.

Step 23: Access the Application

Go to:

EC2 → Load Balancers

Open your Application Load Balancer.

Copy the:

DNS Name

Example:

aws-prod-proj-123456.ap-south-1.elb.amazonaws.com

Copy the URL and Open it in your browser.

Troubleshooting

When I initially tried to access the application, the page was not loading.

To troubleshoot the issue, I verified the following.

1. Private EC2 Security Group

Go to:

EC2 → Instances → Private Instance → Security

Open the attached Security Group.

Verify the rules:

Type	Port	Source
SSH	22	bastion-sg
Custom TCP	8000	Anywhere IPv4

2. Load Balancer Security Group

Go to:

EC2 → Load Balancers → Select the Load Balancer

Under Security, open the attached Security Group.

My rules were incorrect, so I updated them to:

Type	Port	Source
HTTP	80	0.0.0.0/0

After saving the changes, the application loaded successfully.

Conclusion

In this project, we built a production-style AWS VPC architecture from scratch and understood how different AWS networking components work together.

We implemented:

Custom VPC
Public and Private Subnets across two Availability Zones
Internet Gateway and Route Tables
NAT Gateways for secure outbound internet access
Auto Scaling Group with EC2 instances in private subnets
Bastion Host for secure administration
Application Load Balancer and Target Group
A sample Python web application running inside private EC2 instances

One of the most important learnings from this project was understanding how traffic flows inside a production environment:

Internet
    ↓
Application Load Balancer
    ↓
Private EC2 Instances

and how administrators securely access private servers using:

Developer Laptop
    ↓
Bastion Host
    ↓
Private EC2 Instances

This project helped me understand how real-world applications are deployed securely and with high availability across multiple Availability Zones.

Let's meet in the next article with a new AWS service 🚀👋

Understanding DNS and AWS Route 53 for Beginners

Vijaya Laxmi Kadham — Tue, 09 Jun 2026 07:16:43 +0000

In the previous articles, we learned about:

VPC
Subnets
Internet Gateway
Route Tables
Security Groups
Network ACLs (NACLs)

These components help us build and secure our AWS infrastructure.

But there is still one question:

How do users actually find our application?

For example, when users open:

www.amazon.com

how does the browser know where the website is running?

This is where DNS and AWS Route 53 come into the picture.

In this article, we will understand:

What DNS is
Why DNS is needed
What AWS Route 53 is
How Route 53 works
Real-world examples
AWS examples

Let's get started.

Why Do We Need DNS?

Imagine you want to call your friend.

Would you remember:

9876543210

for every person in your contacts?

Probably not.

Instead, you save names like:

Mom
Dad
Friend
Office

Your phone automatically maps the name to the phone number.

DNS works exactly the same way.

Instead of remembering IP addresses like:

54.210.100.25

we simply remember:

www.google.com

DNS converts:

Domain Name → IP Address

This makes websites easier for humans to use.

What is DNS?

DNS stands for:

Domain Name System

DNS is like the phonebook of the internet.

Its job is to convert:

www.amazon.com

into something computers understand:

54.xx.xx.xx

Without DNS, we would have to remember IP addresses for every website.

Real-Life Example

Think of a restaurant.

People usually say:

McDonald's

instead of saying:

Building Number 25
Street Number 10
City XYZ

The restaurant name is easier to remember.

Similarly:

www.youtube.com

is easier to remember than:

142.250.182.206

How DNS Works

Suppose a user opens:

www.shopworld.com

The process looks like this:

User
   ↓
DNS Lookup
   ↓
IP Address Found
   ↓
Application Server

DNS finds the IP address associated with the domain name and sends the user to the correct server.

What is AWS Route 53?

AWS Route 53 is Amazon's managed DNS service.

It helps:

Convert domain names into IP addresses
Route users to AWS resources
Improve application availability
Register domain names

Simply put:

Route 53 is AWS's DNS service.

Why is it Called Route 53?

DNS communication uses:

Port 53

That is why AWS named the service:

Route 53

How Route 53 Works

Suppose you have a website:

www.shopworld.com

Your application is running behind a Load Balancer.

When a user enters the domain name, Route 53 finds the correct destination.

Flow:

User
   ↓
www.shopworld.com
   ↓
Route 53
   ↓
Load Balancer
   ↓
Application Server

Route 53 does not host your application.

Its job is only to direct users to the correct resource.

AWS Example

Suppose your architecture looks like this.

Public Subnet

Load Balancer

Private Subnet

Application Server

Users do not know the IP address of your Load Balancer.

Instead, they simply visit:

www.shopworld.com

Route 53 translates the domain name and forwards users to the Load Balancer.

The Load Balancer then sends requests to the application server.

Real-World Example

Imagine an e-commerce company.

Without DNS:

http://44.210.150.20

Customers would need to remember the IP address.

With DNS:

www.shopworld.com

Customers can easily remember and access the website.

DNS makes the internet user-friendly.

Benefits of Route 53

Route 53 provides:

High Availability
Scalability
Managed DNS Service
Domain Registration
Health Checks
Traffic Routing Capabilities

Because AWS manages Route 53, we do not need to maintain DNS servers ourselves.

Summary

DNS converts:

Domain Name → IP Address

AWS Route 53 is Amazon's managed DNS service that helps users access applications using easy-to-remember domain names.

Conclusion

DNS is one of the fundamental building blocks of the internet.

Without DNS, users would have to remember IP addresses for every website.

AWS Route 53 simplifies this process by providing a highly available and scalable DNS service.

Understanding DNS and Route 53 is an important AWS networking concept and is commonly used in real-world cloud architectures.

Additional Resources

If you want to explore Route 53 in more detail, refer to the official AWS documentation:

Note: This article covers Route 53 fundamentals for beginners. The official AWS documentation provides deeper explanations and advanced features.

What's Next?

In the next article, we will build a complete AWS VPC Project that can be added to your resume.

This project is inspired by concepts learned from Abhishek Veeramalla's AWS learning series. I will be implementing the project step by step while explaining the concepts in my own words.

We will create:

Custom VPC
Public and Private Subnets
Internet Gateway
Route Tables
Security Groups
EC2 Instances

and understand how these components work together in a real-world architecture.

🚀 See you in the next article.

Hands-On: Understanding Security Groups and NACLs in AWS

Vijaya Laxmi Kadham — Sun, 07 Jun 2026 11:38:30 +0000

In the previous article, we learned the theory behind:

Security Groups
Network Access Control Lists (NACLs)

Now it is time to see them in action.

In this hands-on lab, we will:

Create a VPC
Launch an EC2 instance
Run a simple Python web server
Allow traffic using Security Groups
Block traffic using NACLs
Understand how both security layers work together

By the end of this lab, you will clearly understand the difference between Security Groups and NACLs.

Let's dive into the hands-on.

Step 1: Create a VPC

Search for:

VPC

Click:

Create VPC

Select:

VPC and More

This automatically creates:

VPC
Public Subnet
Private Subnet
Route Tables
Internet Gateway

Give your VPC a name:

vpc-test

For the IPv4 CIDR block, choose the IP range you want.

Example:

10.0.0.0/16

Click Create VPC.

After creating the VPC, click View VPC and open the Resource Map.

This helps you understand how all networking components are connected.

Step 2: Launch an EC2 Instance

Navigate to:

EC2 → Instances → Launch Instance

Provide:

EC2 Instance Name
Operating System
Key Pair

Under Network Settings:

Select the VPC you created: vpc-test
Select the Public Subnet

Note: In production environments, applications should preferably use private subnets. However, for learning purposes, we will use a public subnet.

Enable:

Auto Assign Public IP

Under Firewall (Security Groups) choose:

Create New Security Group

Click Launch Instance.

Step 3: Connect to the EC2 Instance

Copy the Public IP address of the instance.

Open Terminal and connect using SSH.

Example:

ssh -i test_app.pem ubuntu@<PUBLIC_IP>

Replace:

<PUBLIC_IP>

with your EC2 Public IP.

Step 4: Update Packages

Whenever you launch a Linux server, updating packages is considered a good practice.

Run:

sudo apt update

Step 5: Verify Python Installation

Check whether Python is installed.

Run:

python3

Step 6: Start a Simple Python Web Server

Python provides a built-in HTTP server.

Run:

python3 -m http.server 8000

Your application is now running on:

Port 8000

Step 7: Try Accessing the Application

Open your browser and type:

http://<PUBLIC_IP>:8000

Example:

http://54.xx.xx.xx:8000

You will notice that the application does not open.

Why?

Let's investigate what is blocking the application.

Step 8: Check the NACL

Navigate to:

AWS Console → VPC → Network ACLs

Open the NACL associated with your subnet.

Check the Inbound Rules.

Here you will notice something interesting.

AWS already allows traffic through the NACL.

Example:

Rule 100 → Allow All Traffic

This means the NACL is not blocking us.

So why can't we access the application?

Because there is another security layer:

Security Group

Now, you may have noticed rule number 100, and * in the above screenshot of NACL Rules.

Let's understand what they mean.

Understanding NACL Rule Priority

NACL rules are evaluated in order.

Smaller numbers have higher priority.

Example:

100 → Checked First
200 → Checked Second
300 → Checked Third
...
*   → Checked Last

AWS evaluates rules from top to bottom until a match is found.

Step 9: Allow Port 8000 in Security Group

Navigate to:

EC2 → Instance → Security

Open the attached Security Group.

Click:

Edit Inbound Rules

By default, Security Groups block most incoming traffic and only allow SSH access.

Now add a new rule:

Type: Custom TCP
Port: 8000
Source: Anywhere IPv4

Save the rule.

Step 10: Test Again

Return to your browser and refresh:

http://<PUBLIC_IP>:8000

This time the application loads successfully.

What changed?

The Security Group now allows traffic on Port 8000.

Flow:

Internet
   ↓
NACL (Allowed)
   ↓
Security Group (Allowed)
   ↓
EC2 Instance

Now that we understand how Security Groups and NACLs work together, let's perform one more experiment.

Step 11: Block Traffic Using NACL

Navigate to:

VPC → Network ACLs

Click:

Edit Inbound Rules

Create the following rule:

Rule Number: 100
Type: Custom TCP
Port Range: 8000
Source: 0.0.0.0/0
Action: Deny

Save the changes.

Step 12: Test Again

Refresh:

http://<PUBLIC_IP>:8000

The application is no longer accessible.

Why?

Because traffic is blocked at the subnet level before reaching the Security Group.

Flow:

Internet
   ↓
NACL (Denied)
   ❌
Security Group
   ❌
EC2 Instance

Even though the Security Group allows Port 8000, the NACL blocks the request first.

Step 13: Understanding Rule Priority

Now let's restore access.

Navigate to:

VPC → Network ACLs

Click:

Edit Inbound Rules

Create:

Rule 100

Allow All Traffic

Create another rule:

Rule 200

Type: Custom TCP
Port Range: 8000
Source: 0.0.0.0/0
Action: Deny

Save the changes.

What Happens Now?

Try accessing:

http://<PUBLIC_IP>:8000

The application works successfully.

Why?

Because AWS checks:

Rule 100

first.

Since Rule 100 allows all traffic, AWS never evaluates Rule 200.

Flow:

Rule 100 → Match Found → Allow

Rule 200 → Ignored

This demonstrates one of the most important NACL concepts:

Lower numbered rules have higher priority.

Key Takeaways

Security Groups

Work at Instance Level
Stateful
Allow Traffic

Network ACLs

Work at Subnet Level
Stateless
Allow and Deny Traffic
Use Rule Priority

Request Flow

Internet
   ↓
NACL
   ↓
Security Group
   ↓
EC2 Instance

If either layer blocks the traffic, the request never reaches the server.

Conclusion

In this hands-on lab, we:

Created a VPC
Launched an EC2 instance
Deployed a simple Python web server
Allowed traffic using Security Groups
Blocked traffic using NACLs
Observed how multiple security layers work together

We also learned that:

Security Groups control traffic at the instance level.
NACLs control traffic at the subnet level.
NACL rule priority affects traffic flow.
Multiple security layers improve AWS network security.

Understanding these concepts is essential for AWS networking and cloud security.

Security Groups vs NACLs Explained for Beginners

Vijaya Laxmi Kadham — Sat, 06 Jun 2026 11:06:00 +0000

Security Groups vs NACLs Explained for Beginners

In the previous articles, we learned about:

VPC
Subnets
Internet Gateway
Route Tables

These components help AWS resources communicate with each other and with the internet.

But there is still one important question:

Even if a server is reachable, should everyone be allowed to access it?

The answer is No.

We need security controls that decide:

Who can access our resources
Which traffic is allowed
Which traffic should be blocked

AWS provides two important security layers for this:

Security Groups
Network Access Control Lists (NACLs)

At first, they may seem similar, but they work at different levels and have different purposes.

In this article, we will understand them using simple real-world examples.

Why Do We Need Security Layers?

Imagine you own a house.

Just because a road leads to your house does not mean everyone should be allowed inside.

You still need:

A gate around the property
A lock on the door

AWS networking works in a similar way.

Even if:

A route exists
The internet can reach your subnet

You still need security rules that decide whether traffic should be allowed or blocked.

This is where Security Groups and NACLs come in.

What is a Security Group?

A Security Group is a virtual firewall attached directly to an EC2 instance.

Simply put, Security Groups are created at the instance level.

It controls:

Incoming Traffic (Inbound Rules)
Outgoing Traffic (Outbound Rules)

Think of a Security Group as the security guard standing at the door of your house.

Every request must pass through the guard before reaching the server.

Example

Suppose you have a web server running on an EC2 instance.

The website uses:

Port 80

for HTTP traffic.

You can configure the Security Group to allow traffic on Port 80.

Requests coming on Port 80 are allowed.
Requests coming from other ports are blocked.

Security Group Flow

Internet
   ↓
Security Group
   ↓
EC2 Instance

If traffic matches an allowed rule:

The request reaches the EC2 instance.

Otherwise:

AWS blocks the request.

Security Groups are Stateful

This is one of the most important concepts.

Suppose a user visits your website.

Step 1: User accesses the website

User
  ↓
EC2 Web Server

Step 2: EC2 sends the response back

EC2 Web Server
  ↓
User

When inbound traffic is allowed, AWS automatically allows the response traffic.

You do not need to create separate rules for return traffic.

This behavior is called:

Stateful

Think of it like a phone call.

If you answer a call, you can automatically talk back without opening another connection.

What is a NACL?

NACL stands for:

Network Access Control List

A NACL acts as a firewall at the subnet level.

Instead of protecting a single EC2 instance, it protects the entire subnet.

Think of a NACL as the security gate at the entrance of an apartment complex.

Anyone entering the apartment complex must pass through the gate first.

NACL Flow

Internet
   ↓
NACL
   ↓
Subnet
   ↓
Security Group
   ↓
EC2 Instance

Notice that the NACL checks traffic before it reaches the Security Group.

Example

Suppose your subnet contains:

Web Server
Application Server
Monitoring Server

Instead of configuring rules individually on each server, you can create subnet-level rules using a NACL.

Allow:

Port 80
Port 443

Deny:

Port 22 from the Internet

These rules apply to the entire subnet.

NACLs are Stateless

Unlike Security Groups, NACLs are stateless.

This means AWS does not automatically allow return traffic.

You must explicitly configure:

Inbound Rules
Outbound Rules

Example

If inbound HTTP traffic is allowed:

Internet
   ↓
Subnet

You must also create outbound rules so the response can return:

Subnet
   ↓
Internet

Otherwise, communication fails.

This behavior is called:

Stateless

Security Group vs NACL

Feature	Security Group	NACL
Works At	EC2 Instance Level	Subnet Level
Stateful	Yes	No
Allows Traffic	Yes	Yes
Denies Traffic	No	Yes
Applied To	EC2 Instances	Subnets
Protection Scope	Individual Resource	Entire Subnet

Easy Way to Remember

Think about an apartment building.

Apartment Complex
        ↓
       NACL
        ↓
     Apartment
        ↓
 Security Group

NACL

Security at the apartment gate.

Security Group

Security at the apartment door.

Both work together.

Why Does AWS Use Both?

AWS follows a security principle called:

Defense in Depth

Instead of relying on a single security layer, AWS uses multiple layers of protection.

Layer 1

NACL protects the subnet.

Layer 2

Security Group protects the EC2 instance.

Even if one layer is misconfigured, another layer can still provide protection.

Real-World Example

Imagine an online shopping application.

Public Subnet

Contains:

Load Balancer

Private Subnet

Contains:

Application Server
Database

Security Group Rules

Allow users to access the Load Balancer
Allow the Load Balancer to access the Application Server
Allow the Application Server to access the Database

NACL Rules

Block unwanted traffic at the subnet level
Allow only required ports

This creates multiple layers of security.

Conclusion

Security Groups and NACLs both play an important role in AWS security, but they work at different levels.

Security Groups

Protect individual EC2 instances
Are stateful
Allow traffic

NACLs

Protect entire subnets
Are stateless
Can allow or deny traffic

Understanding the difference between Security Groups and NACLs is an important AWS networking concept.

What's Next?

In the next article, we will perform a hands-on lab where we will:

Create a custom VPC
Launch an EC2 instance
Allow traffic using a Security Group
Block traffic using a NACL
Observe how both security layers work together

🚀 Stay tuned for the hands-on implementation.

AWS Internet Gateway and Route Tables Explained for Beginners

Vijaya Laxmi Kadham — Wed, 03 Jun 2026 07:21:32 +0000

After learning about Public Subnets and Private Subnets, the next question that comes across our mind is:

How does traffic actually move inside AWS?

Creating a subnet alone doesn't make your application accessible.

AWS needs networking concepts to decide:

Where the traffic comes from
Where the traffic should go
Whether internet access is allowed

This is where Internet Gateways (IGW) and Route Tables come into the picture.

Together, they act like roads and traffic signals for your AWS network.

Imagine a Real City

Think of your AWS VPC as a city.

Inside the city, we have:

Buildings = EC2 Instances
Neighborhoods = Subnets
Roads = Routes
City Gate = Internet Gateway

Without roads and a city gate:

Nobody can enter
Nobody can leave

AWS networking works in a similar way.

Real City

City
 ├── Buildings
 ├── Roads
 └── Main Gate

AWS Equivalent

VPC
 ├── EC2 Instances
 ├── Route Tables
 └── Internet Gateway

What is an Internet Gateway?

An Internet Gateway (IGW) is a VPC component that enables communication between:

Your AWS VPC
The Public Internet

It is the official entry and exit point for internet traffic.

Real-World Example

Imagine a shopping mall.

It has:

Shops inside
Customers outside

Customers can only enter through the main entrance gate.

Customers
     ↓
 Main Entrance
     ↓
 Shopping Mall

In AWS we can look the above situation as:

Internet
     ↓
Internet Gateway
     ↓
VPC

The Internet Gateway acts as the main entrance gate.

Without an Internet Gateway

Suppose you launch an EC2 instance. But there is no Internet Gateway attached.

EC2 Instance
    ↓
Public Subnet
    ↓
VPC

Result

❌ Users cannot access the application
❌ EC2 cannot browse the internet
❌ Software updates cannot be downloaded

Even though the EC2 instance exists, it is isolated from the internet.

When an Internet Gateway is Attached

Internet
     ↓
Internet Gateway
     ↓
VPC
     ↓
EC2

The VPC now has a connection to the outside world.

However, there is still one more requirement.

The traffic needs directions.

This is where Route Tables come in.

What is a Route Table?

A Route Table is a set of rules that tells AWS:

"Where should the traffic go?"

Think of it like Google Maps for network traffic.

When traffic arrives, AWS checks the Route Table and decides whether to:

Send traffic to an Internet Gateway
Send traffic to another subnet
Send traffic to another network

Real-World Example

Imagine you're driving a car.

When you reach an intersection, you see:

Go Left  → Airport
Go Right → City Center
Go Straight → Highway

Road signs tell you where to go.

A Route Table does the same thing for network traffic.

Understanding Routes

A route contains:

Destination → Target

Example:

0.0.0.0/0 → Internet Gateway

This means:

Any traffic going anywhere on the internet should be sent to the Internet Gateway.

What Does 0.0.0.0/0 Mean?

This confuses many beginners.

0.0.0.0/0

means:

Every possible IP address on the internet.

So this route means:

All Internet Traffic
          ↓
Internet Gateway

Complete Traffic Flow

Let's see what happens when a user opens a website.

Step 1

User enters:

www.example.com

Step 2

The request reaches AWS.

User
 ↓
Internet

Step 3

Traffic enters through the Internet Gateway.

User
 ↓
Internet
 ↓
Internet Gateway

Step 4

AWS checks the Route Table.

Internet Gateway
        ↓
    Route Table

Step 5

The Route Table sends traffic to the correct subnet.

Route Table
      ↓
Public Subnet

Step 6

Traffic reaches the EC2 instance.

Public Subnet
      ↓
EC2 Instance

Complete Flow

User
  ↓
Internet
  ↓
Internet Gateway
  ↓
Route Table
  ↓
Public Subnet
  ↓
EC2 Instance

Public Route Table Example

A Public Subnet becomes public because its Route Table contains a route to the Internet Gateway.

Destination	Target
VPC CIDR	Local
0.0.0.0/0	Internet Gateway

Diagram:

Public Subnet
       ↓
Route Table
       ↓
0.0.0.0/0
       ↓
Internet Gateway
       ↓
Internet

This allows:

Incoming internet traffic
Outgoing internet traffic

Important Thing to Remember

Many beginners think:

"If an EC2 is launched inside a public subnet, it automatically becomes public."

This is incorrect.

For an EC2 instance to be publicly accessible, it needs:

Requirement 1

The subnet must have a route:

0.0.0.0/0 → IGW

Requirement 2

An Internet Gateway must be attached.

Requirement 3

The EC2 instance must have a Public IP.

Requirement 4

The Security Group must allow access.

Only then can internet users reach the EC2 instance.

Private Subnet Route Table

A Private Subnet usually does not have a route to the Internet Gateway.

Example:

Destination	Target
VPC CIDR	Local

Notice:

0.0.0.0/0 → IGW

does not exist.

Result:

❌ No direct internet access
❌ Internet users cannot reach resources
✅ Better security

Real-World Architecture Example

Let's build a simple e-commerce website.

Public Layer

Load Balancer
Web Server

Private Layer

Database

Architecture:

Internet
    ↓
Internet Gateway
    ↓
Public Subnet
    ↓
Load Balancer
    ↓
Web Server
    ↓
Private Subnet
    ↓
Database

Why Keep the Database in a Private Subnet?

Imagine if the database was directly accessible from the internet.

Anyone could attempt:

Brute-force attacks
Unauthorized access
Data theft

Instead, we design the architecture like this:

Internet
    ↓
Web Server
    ↓
Database

Only the Web Server can communicate with the Database.

Users cannot directly reach it.

This is a core AWS security principle.

Public vs Private Subnet Visualization

                    Internet
                        │
                Internet Gateway
                        │
                 Route Table
                        │
          ┌─────────────┴─────────────┐
          │                           │
          ▼                           ▼

    Public Subnet              Private Subnet

          │                           │
          ▼                           ▼

      Web Server                 Database

Conclusion

Internet Gateway and Route Tables are the foundation of AWS networking.

In this article, we learned:

What an Internet Gateway is
Why it is required
What Route Tables are
How AWS routes traffic
Difference between Public and Private Subnets
Real-world examples of traffic flow
How web applications securely communicate with databases

Once you understand Internet Gateway and Route Tables, AWS networking becomes much easier to visualize.

Key Interview Question

What makes an EC2 instance publicly accessible?

The following four conditions must be met:

0.0.0.0/0 Route
        +
Internet Gateway
        +
Public IP
        +
Security Group Allow Rule
        =
Accessible from Internet

Remembering these four requirements helps answer many AWS networking interview questions.

In the next article, we'll explore:

Security Groups
Network ACLs (NACLs)
How AWS protects resources at the network level

Public vs Private Subnets in AWS Explained for Beginners

Vijaya Laxmi Kadham — Mon, 01 Jun 2026 06:02:26 +0000

When learning AWS networking, one of the most important concepts to understand is the difference between:

Public Subnet
Private Subnet

At first these terms may sound confusing. But once you understand how internet access works inside a VPC, the concept becomes very simple.

In this article, we will understand:

What a subnet is
What public and private subnets are
How internet access works in AWS
What a Load Balancer does
How routing works
Real-world architecture examples

What is a Subnet?

A subnet is a smaller network created inside a VPC.

When we create a VPC, AWS gives us a large IP address range called a CIDR Block.

Example: 192.168.0.0/16

Instead of using the entire IP block, we divide it into smaller sections called Subnets. This helps organize resources properly and improves security.

We mainly have two types of subnets:

Public Subnet
Private Subnet

Why Do We Need Different Subnets?

Think of a company office building:

Office Building
├── Reception Area (Public)
└── Server Room (Private)

Reception Area → Anyone can enter (customers, visitors, delivery people) → Similar to Public Subnet
Server Room → Only authorized employees can enter → Similar to Private Subnet

This is how AWS works. Not every application component should be exposed to the internet.

For example:

Users should access frontend applications
Databases should remain private
Backend services should stay protected

What is a Public Subnet?

A Public Subnet is a subnet that allows internet access.
Resources inside this subnet can communicate directly with the internet.

Examples:

Web Servers
Load Balancers

What is a Load Balancer?

A Load Balancer is a service that distributes user traffic across multiple servers.

Think of it like a traffic manager.

Users
↓
Load Balancer
↓
├── Server 1
├── Server 2
└── Server 3

This improves Performance, Availability, and Reliability.

In AWS, Load Balancers are placed inside a public subnet because users from the internet need to access them.

Real World Example of Public Subnet

Imagine you are hosting a shopping website: www.shopworld.com

Internet Users → Load Balancers → Web Servers

These resources need internet access to receive requests and send responses back to users.

How Public Subnets Get Internet Access?

AWS uses an Internet Gateway to connect resources to the internet.

Think of Internet Gateway as a gate between AWS Network and the Internet.

Flow:
Internet → Internet Gateway → Public Subnet

Understanding Route Tables

A Route Table decides where network traffic should go.

Public Subnet Route Example:

Destination: 0.0.0.0/0
Target: Internet Gateway

This route makes the subnet Public.

What is a Private Subnet?

A Private Subnet does not allow direct internet access. Resources inside it are hidden from the internet.

Examples:

Databases
Backend APIs

Why Private Subnets are Important?

Sensitive data should never be exposed publicly.

Examples: MySQL databases, Banking systems, Payment services.

Keeping them private improves security significantly.

Real World Example of Private Subnet

In a banking application bank.com, customers should never directly access:

Database servers
Account systems
Transaction services

So these are placed in Private Subnets.

Internet User
↓
Website
↓
Backend Application
↓
Database

Private Subnet Routing

Private subnet route tables usually don't contain a Route to internet gateway.

Example: No Route to Internet Gateway

Meaning: Internet access is blocked.

This prevents from direct communication from the internet.

Public vs Private Subnet Comparison

Feature	Public Subnet	Private Subnet
Internet Access	Yes	No
Directly Reachable	Yes	No
Used For	Web Applications, Load Balancers	Databases, Backend Applications
Security Level	Lower	Higher

Complete Real-World AWS Architecture

This is the most common architecture used in real AWS projects. It combines both Public and Private Subnets to create a secure and scalable application.

Conclusion

Public and Private Subnets are fundamental building blocks of secure and scalable AWS architecture.

Public Subnets allow resources to be accessed from the internet (like web servers and load balancers).
Private Subnets keep sensitive resources safe and hidden from the internet (like databases and backend applications).

By properly using Internet Gateway, Route Tables, and separating your resources into public and private subnets, you can build applications that are both highly available and secure.

Key Takeaways:

Always place internet-facing components in Public Subnets.
Keep databases and backend logic in Private Subnets.
Use Load Balancers in public subnets to distribute traffic efficiently.
This 3-Tier Architecture (Web → Application → Database) is one of the most commonly used patterns in real-world AWS projects.

Mastering Public and Private Subnets is a big step toward becoming confident in AWS networking.

In the next articles, we will learn about NAT Gateway (how private subnets can access the internet for updates), Security Groups, and Network ACLs.