DEV Community: Vishal Patil

AWS S3 Bucket Versioning: Protect Your Data from Accidental Deletes and Overwrites

Vishal Patil — Wed, 04 Nov 2026 03:45:39 +0000

A hands-on guide to enabling S3 versioning, recovering deleted files, and keeping costs under control with lifecycle rules."

tags: aws, s3, cloud, beginners

Overwriting the wrong file or deleting an important object in S3 is easy to do, and by default it is permanent. S3 Versioning fixes this. It keeps every version of every object in your bucket, so you can recover from mistakes and from application failures. In this post I enable versioning, test it, and recover a deleted file.

vishalcloudjourney

📦 What is S3 Versioning?

Versioning is a bucket-level feature that keeps multiple variants of an object in the same bucket. Every upload of the same key creates a new version with its own unique Version ID.

A bucket is always in one of three states:

Unversioned (the default)
Versioning-enabled
Versioning-suspended

⚠️ Once you enable versioning, you cannot go back to unversioned. You can only suspend it, and existing versions are kept.

✅ Why use it?

Recover from accidental deletion: a delete only adds a delete marker, and the data stays.
Recover from accidental overwrites: older versions are still there.
Keep a history: useful for audits and rollbacks.
Safer backups: a good protection layer against human error and some application bugs.

🖱️ Hands-on: Enable versioning in the console

Step 1: Create a bucket

Open the S3 console and click Create bucket.
Enter a globally unique bucket name, such as vishal-versioning-demo-123.
Choose your region and keep Block all public access on.
Click Create bucket.

Step 2: Enable versioning

Open your bucket and go to the Properties tab.
Find Bucket Versioning and click Edit.
Select Enable and click Save changes.

Step 3: Upload and overwrite a file

Create a file demo.txt containing Version 1 and upload it.
Change the content to Version 2 and upload it again with the same name.
Open the Objects tab and turn on the List versions toggle.

You will see two versions of demo.txt, each with its own Version ID. The latest one is the current version, and the other is a noncurrent version.

Step 4: Delete and recover

Turn List versions off, select demo.txt and click Delete.
The file seems to disappear. Turn List versions back on.
You will see a Delete marker on top of your versions. Your data is safe.
Select the delete marker and delete it. demo.txt comes back.

To remove a version permanently, delete it by its specific Version ID.

⌨️ Hands-on: Using the AWS CLI

# Enable versioning
aws s3api put-bucket-versioning \
  --bucket vishal-versioning-demo-123 \
  --versioning-configuration Status=Enabled

# Check the status
aws s3api get-bucket-versioning --bucket vishal-versioning-demo-123

# List all versions and delete markers
aws s3api list-object-versions --bucket vishal-versioning-demo-123

# Download a specific version
aws s3api get-object \
  --bucket vishal-versioning-demo-123 \
  --key demo.txt \
  --version-id <VERSION_ID> demo-old.txt

# Permanently delete one specific version
aws s3api delete-object \
  --bucket vishal-versioning-demo-123 \
  --key demo.txt \
  --version-id <VERSION_ID>

💡 Things to know

Cost: every version is stored and billed as a separate object, so storage grows with each update.
Lifecycle rules: use them to expire noncurrent versions after N days, or move them to a cheaper storage class. This keeps costs under control.
Objects uploaded before versioning: they get the Version ID null.
MFA Delete: an optional extra protection that requires MFA to permanently delete a version or change the versioning state. Only the bucket owner's root account can enable it, and only through the CLI or API.
Replication: Cross-Region Replication requires versioning on both buckets.

🏆 Best practices

Turn versioning on for buckets that hold important or hard-to-recreate data.
Add a lifecycle rule to clean up old noncurrent versions.
Restrict who can permanently delete versions with IAM and bucket policies.
Consider MFA Delete for critical buckets.
Monitor storage growth in the S3 console and in billing.

🧹 Cleanup

A versioned bucket is not empty until all versions and delete markers are removed. Use Empty in the console, then delete the bucket, so you don't pay for leftover data.

📚 Key learnings

Versioning turns a permanent delete into a recoverable one.
A delete on a versioned bucket adds a delete marker, and the data stays in the bucket.
Lifecycle rules are the best way to keep versioning affordable.

🤝 Connect with me

If this helped you, drop a ❤️ and tell me how you use S3 versioning in the comments!

vishalcloudjourney #AWS #S3 #CloudStorage #DataProtection

I Built a CI/CD Pipeline with Jenkins, SonarQube, Docker & Kubernetes on AWS EC2

Vishal Patil — Tue, 03 Nov 2026 03:26:02 +0000

A step-by-step guide to automating build, code quality checks, Docker image push and Kubernetes deployment using Jenkins on AWS EC2."

tags: aws, devops, kubernetes, jenkins

Shipping code by hand is slow and easy to get wrong. So I built a complete CI/CD pipeline on AWS: every push to GitHub is compiled, scanned for code quality, packaged, containerized, pushed to Docker Hub and deployed to Kubernetes automatically.

vishalcloudjourney

🏗️ Architecture

GitHub → Jenkins (EC2) → Maven → SonarQube → Docker → Docker Hub → Kubernetes

Pipeline stages

Declarative: Tool Install
Git Checkout
Code Compile
SonarQube Analysis
Maven Build
Docker Build
Docker Image Push
Deploy to Kubernetes
Declarative: Post Actions

Tools used

AWS EC2, Jenkins, Maven, SonarQube, Docker, Docker Hub, Kubernetes (kubectl), GitHub

Step 1: Launch EC2 instances

Launch an Ubuntu EC2 instance (t2.medium or larger) for Jenkins and SonarQube.
Launch instances for your Kubernetes cluster (or use EKS).
Open these ports in the Security Group:

Port	Purpose
22	SSH
8080	Jenkins
9000	SonarQube
6443	Kubernetes API (restrict to the Jenkins server IP)
30000-32767	NodePort range for your app

💡 Avoid opening ports to 0.0.0.0/0 unless you have to. Restrict them to your own IP wherever possible.

Step 2: Install Jenkins

sudo apt update
sudo apt install openjdk-17-jdk -y
# Add the Jenkins repository, then:
sudo apt install jenkins -y
sudo systemctl enable --now jenkins

Open http://<EC2-Public-IP>:8080, unlock Jenkins with the initial admin password and install the suggested plugins.

Step 3: Install Docker, Maven and kubectl

sudo apt install docker.io maven -y
sudo usermod -aG docker jenkins
sudo systemctl restart jenkins
# install kubectl as per the official Kubernetes docs

Adding jenkins to the docker group lets pipeline builds run Docker commands.

Step 4: Set up SonarQube

docker run -d --name sonarqube -p 9000:9000 sonarqube:lts-community

Log in at http://<EC2-IP>:9000.
Generate a token under My Account → Security.
Create a project and note its project key.

Step 5: Configure Jenkins

Plugins: SonarQube Scanner, Docker Pipeline, Kubernetes CLI, Pipeline Stage View, Maven Integration.

Credentials (Manage Jenkins → Credentials):

dockerhub-cred: Docker Hub username and password
sonar-token: the SonarQube token
k8s-config: your kubeconfig file, as a Secret file

Tools (Manage Jenkins → Tools): add Maven and JDK.

SonarQube server (Manage Jenkins → System): add the server URL and token.

Step 6: Write the Jenkinsfile

pipeline {
    agent any
    tools { maven 'maven3' }

    environment {
        IMAGE = "your-dockerhub-user/your-app"
        TAG   = "${BUILD_NUMBER}"
    }

    stages {
        stage('Git Checkout') {
            steps { git branch: 'main', url: 'https://github.com/<you>/<repo>.git' }
        }
        stage('Code Compile') {
            steps { sh 'mvn compile' }
        }
        stage('SonarQube Analysis') {
            steps {
                withSonarQubeEnv('sonar') {
                    sh 'mvn sonar:sonar'
                }
            }
        }
        stage('Maven Build') {
            steps { sh 'mvn clean package -DskipTests' }
        }
        stage('Docker Build') {
            steps { sh "docker build -t $IMAGE:$TAG ." }
        }
        stage('Docker Image Push') {
            steps {
                withCredentials([usernamePassword(credentialsId: 'dockerhub-cred',
                    usernameVariable: 'U', passwordVariable: 'P')]) {
                    sh 'echo $P | docker login -u $U --password-stdin'
                    sh "docker push $IMAGE:$TAG"
                }
            }
        }
        stage('Deploy to Kubernetes') {
            steps {
                withKubeConfig(credentialsId: 'k8s-config') {
                    sh "sed -i 's|IMAGE_TAG|$TAG|g' k8s/deployment.yaml"
                    sh 'kubectl apply -f k8s/deployment.yaml'
                    sh 'kubectl apply -f k8s/service.yaml'
                }
            }
        }
    }
}

Step 7: Kubernetes manifests

Keep these in a k8s/ folder in your repo.

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: your-dockerhub-user/your-app:IMAGE_TAG
          ports:
            - containerPort: 8080

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

Step 8: Run the pipeline

Create a Pipeline job, point it at your repo's Jenkinsfile and click Build Now. The Stage View shows each stage turning green, and the SonarQube Quality Gate shows Passed when your code meets the quality rules.

🛠️ Troubleshooting: when "Deploy to Kubernetes" fails

My first builds (#25, #26 and #27) passed every stage until Deploy to Kubernetes, then failed. Build #25 failed in under a second, while #26 and #27 ran for about 3 minutes before failing. Build #28 passed, and the deploy stage took about 38 seconds.

Since everything before the deploy stage worked, the problem was between Jenkins and the cluster. A failure after about 3 minutes usually points to a connection timeout, and a near-instant failure usually points to a credential or config error. Things to check:

Kubeconfig credential: is it uploaded correctly, and does the withKubeConfig ID match?
Network access: can the Jenkins server reach the cluster API on port 6443? Check the Security Group and the server IP in the kubeconfig.
Manual test: SSH into the Jenkins server and run kubectl get nodes as the jenkins user.
Manifest errors: check the YAML, image name and tag.
Pod state: run kubectl get pods and kubectl describe pod to spot image pull errors.

📚 Key learnings

Automating the path from commit to deployment removes manual mistakes.
SonarQube's Quality Gate catches bad code before it ships.
Tagging images with the build number makes every deployment traceable and easy to roll back.
Most pipeline failures come from credentials, permissions and networking, so check those first.

🚀 What's next

Add a GitHub webhook so builds trigger on every push.
Move to Amazon EKS and Amazon ECR.
Add Slack or SNS notifications for build status.

🤝 Connect with me

If this helped you, drop a ❤️ and share what you're building in the comments!

vishalcloudjourney #AWS #DevOps #Jenkins #Kubernetes #Docker #SonarQube #CICD

Building a Highly Available 3-Tier Web App on AWS with VPC, EC2, ALB and Aurora

Vishal Patil — Mon, 02 Nov 2026 07:40:11 +0000

A hands-on walkthrough of building a web, app, and database tier across two Availability Zones on AWS.
tags: aws, devops, cloud, beginners

Author: Vishal Patil | Project Manager: Ulhas Narwade

vishalcloudjourney

Introduction

Early in my AWS learning, I practiced with single services: an EC2 instance here, an S3 bucket there. Those taught me the basics, but not how real applications are built. Production systems are layered, with clear security boundaries and a plan for failure.

So I built a 3-tier web application on AWS from scratch, with a web tier, an application tier, and a database tier. Each tier has its own subnets and security rules, and everything is spread across two Availability Zones so one data center failing doesn't take the app down.

What Is a 3-Tier Architecture?

Tier	Responsibility	Network placement
Web	Serves the React UI, forwards API calls	Public subnets
Application	Business logic, database access	Private subnets
Database	Persistent data storage	Private subnets

Why use it?

Only the web tier faces the internet
Each tier scales independently
You can update one layer without touching the others
A failure in one layer stays contained

Architecture Overview

A custom VPC across two Availability Zones (AZ1 and AZ2)
An Internet Gateway for internet connectivity
An external Application Load Balancer for user traffic
Web tier: two EC2 instances in public subnets, one per AZ
An internal Application Load Balancer between the web and app tiers
App tier: two EC2 instances in private subnets, one per AZ
Database tier: an Amazon Aurora primary (writer) and a Read Replica in the other AZ, both private
A NAT Gateway so private instances can download packages without being exposed

Traffic flow:

The user opens the external ALB's DNS name.
The request passes through the Internet Gateway to the external ALB.
The ALB forwards it to a healthy web tier instance.
Nginx serves the React UI and proxies API calls to the internal ALB.
The internal ALB routes them to a healthy app tier instance.
The app tier reads from and writes to Aurora.
The response returns along the same path.

I built everything in the Asia Pacific (Mumbai) ap-south-1 region.

Step 1: Create the Network

VPC with a CIDR block such as 10.0.0.0/16
Six subnets, two per tier, one in each AZ (names like web-public-1a, app-private-1a, db-private-1a help a lot)
Internet Gateway attached to the VPC
Public route table: 0.0.0.0/0 to the Internet Gateway, for the public subnets
NAT Gateway in a public subnet with an Elastic IP
Private route table: 0.0.0.0/0 to the NAT Gateway, for the private subnets

Step 2: Configure Security Groups

I chained security groups so each tier only trusts the tier in front of it.

Security group	Inbound rule	Source
External ALB SG	HTTP 80	Anywhere
Web tier SG	HTTP 80	External ALB SG
Internal ALB SG	HTTP 80	Web tier SG
App tier SG	App port (e.g. 3200)	Internal ALB SG
Database SG	3306	App tier SG

For admin access I used SSH from my own IP on the web tier as a jump host. In production, use AWS Systems Manager Session Manager instead.

Step 3: Build the Database Tier

Create a DB subnet group with the two private database subnets.
Launch an Aurora (MySQL-compatible) cluster with a writer in AZ1 and a reader in AZ2, using the database security group, with public access set to No.
From an app instance, connect to the writer endpoint and create the schema:

CREATE DATABASE webappdb;
USE webappdb;

CREATE TABLE transactions (
  id INT NOT NULL AUTO_INCREMENT,
  amount DECIMAL(10,2),
  description VARCHAR(100),
  PRIMARY KEY (id)
);

Step 4: Build the Application Tier

Launch two Amazon Linux EC2 instances in the private app subnets and install the tools:

sudo yum update -y
sudo yum install mysql -y
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
source ~/.bashrc
nvm install 16
npm install -g pm2

Set the database details in the backend config (placeholders only, never publish real credentials):

module.exports = {
  DB_HOST: '<aurora-writer-endpoint>',
  DB_USER: '<db-username>',
  DB_PWD: '<db-password>',
  DB_DATABASE: 'webappdb'
};

Start the service with PM2 so it survives crashes and reboots:

cd ~/app-tier && npm install
pm2 start index.js
pm2 startup && pm2 save
curl http://localhost:3200/health

Then create a target group with a /health check, register both instances, and create the internal ALB across the private app subnets.

Step 5: Build the Web Tier

On two EC2 instances in the public subnets, build the React app and install Nginx:

cd ~/web-tier
npm install && npm run build
sudo amazon-linux-extras install nginx1 -y

Nginx serves the build and reverse-proxies API calls to the internal ALB:

server {
    listen 80;
    location / {
        root /home/ec2-user/web-tier/build;
        index index.html;
        try_files $uri /index.html;
    }
    location /api/ {
        proxy_pass http://<internal-alb-dns-name>:80/;
    }
}

sudo nginx -t
sudo systemctl restart nginx
sudo systemctl enable nginx

Finally, create a web target group (health check on /), register both instances, and create the internet-facing ALB across the public subnets.

Step 6: Test the Application

I opened the external load balancer's DNS name:

Home page: "AWS 3-TIER WEB APP DEMO" loaded with the architecture diagram, confirming the web tier and external ALB worked.
Database page: the "AURORA DATABASE DEMO PAGE" listed records (ID, Amount, Description) with ADD and DEL buttons. I added a record, refreshed, and it persisted.

That one page proved the full chain: browser, external ALB, web tier, internal ALB, app tier, Aurora.

High Availability in Practice

An instance fails: health checks remove it and the other instance serves users.
An entire AZ fails: each tier has an instance in the second AZ, so traffic continues.
The Aurora primary fails: the read replica can be promoted to writer.

Try it: stop one web instance and keep refreshing the page. The site stays up.

Challenges and Fixes

Unhealthy targets: wrong health check path and a missing security group rule. Check path, port, and security group, in that order.
403 Forbidden from Nginx: Nginx couldn't read the build folder. Fixing permissions and the root path solved it.
Frontend couldn't reach the backend: proxy_pass pointed to the wrong address. Use the internal ALB DNS name.
Database connection errors: wrong endpoint and a missing rule for port 3306 from the app tier SG.

My best debugging habit: test one tier at a time, bottom up.

Key Learnings

Only the web tier is public, and chained security groups limit each tier's trust.
Load balancer health checks are the basis of self-healing.
Subnet and route table design prevents most networking headaches.
Nginx as a reverse proxy gives the browser one endpoint while traffic routes internally.
Secrets don't belong in code. Use Secrets Manager or Parameter Store in production.

Cost and Clean-Up

Delete in this order to avoid charges:

Both load balancers and target groups
EC2 instances
The Aurora cluster (reader first, then writer)
The NAT Gateway, then release its Elastic IP
Subnets, route tables, Internet Gateway, security groups, and finally the VPC

The NAT Gateway, Aurora, and load balancers cost the most. Set up an AWS Budget alert before you start.

What's Next

Auto Scaling Groups for the web and app tiers
HTTPS with AWS Certificate Manager
Route 53 for a friendly domain name
AWS WAF in front of the external ALB
CloudWatch dashboards and alarms
CloudFormation or Terraform to automate the whole build

Conclusion

Studying VPC, EC2, ELB, security groups, and Aurora separately gave me pieces of a puzzle. Wiring them into one working system showed me how they depend on each other and why networking, security, and availability decisions matter. If you're learning AWS, build a project like this end to end. You'll learn more from debugging it than from any slide deck.

Acknowledgement

This project was completed under the guidance of my project manager, Ulhas Narwade Sir. His direction, reviews, and support helped me understand how a real-world 3-tier architecture is planned, built, and tested on AWS.

Written by: Vishal Patil
Project Manager: Ulhas Narwade

Connect with me:

vishalcloudjourney #AWS #3TierArchitecture #AmazonAurora #ElasticLoadBalancing #VPC

Secure Amazon S3 Buckets Using IAM Policies and Bucket Policies

Vishal Patil — Sun, 01 Nov 2026 04:20:16 +0000

Introduction

Amazon S3 is one of the most widely used AWS services, and also one of the most common sources of data leaks. Almost every S3 breach in the news comes down to one thing: a misconfigured access policy.

In this article, I'll explain the two main ways of controlling access to S3, IAM policies and bucket policies, show when to use each, and walk through a hands-on example you can try in your own account.

How S3 Access Is Evaluated

Before writing any policy, it helps to know how AWS decides whether a request is allowed:

Everything is denied by default.
An explicit Allow in a relevant policy grants access.
An explicit Deny always wins, no matter what else says Allow.
For requests within the same account, access is granted if either the IAM policy or the bucket policy allows it (and nothing denies it).

Remember this rule: Explicit Deny > Allow > Default Deny.

IAM Policies vs Bucket Policies
Feature IAM Policy Bucket Policy
Attached to IAM user, group, or role The S3 bucket
Answers the question "What can this identity do?" "Who can access this bucket?"
Has a Principal element No Yes
Cross-account access Needs help from the other side Supported directly
Best for Managing permissions for your users and roles Bucket-wide rules, cross-account access, enforcing conditions
Size limit 2 KB (users), 6 KB (groups), 10 KB (roles) 20 KB

Simple way to remember it:

IAM policy = identity-based ("what can I do?")
Bucket policy = resource-based ("who can touch this bucket?")
Hands-On: Secure a Bucket Step by Step
Step 1: Create a Private Bucket
Open the S3 console and choose Create bucket.
Give it a unique name, for example vishal-secure-demo-bucket.
Keep Block all public access turned ON.
Enable Bucket Versioning.
Enable Default encryption (SSE-S3 or SSE-KMS).
Choose Create bucket.

Tip: Block Public Access is your first line of defense. Leave it on unless you have a very specific reason to turn it off.

Step 2: Create an IAM Policy (Least Privilege)

Let's give a user read and write access to only one bucket, nothing more.

json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::vishal-secure-demo-bucket"
},
{
"Sid": "ReadWriteObjects",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::vishal-secure-demo-bucket/*"
}
]
}

Why two statements? s3:ListBucket applies to the bucket itself, while GetObject and PutObject apply to the objects inside it (/*). This is a very common mistake for beginners.

To apply it:

Go to IAM → Policies → Create policy → JSON and paste the policy.
Name it S3-DemoBucket-ReadWrite.
Attach it to a user, group, or (better) a role.
Step 3: Add a Bucket Policy to Enforce HTTPS

Now let's add a rule at the bucket level. This policy denies any request that doesn't use HTTPS:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "",
"Action": "s3:",
"Resource": [
"arn:aws:s3:::vishal-secure-demo-bucket",
"arn:aws:s3:::vishal-secure-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}

To apply it: S3 → your bucket → Permissions → Bucket policy → Edit → paste → Save.

Step 4: Restrict Access to a Specific IAM Role

You can also lock the bucket so that only one role can access it. Replace the account ID and role name with your own:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOnlyAppRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/AppServerRole"
},
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::vishal-secure-demo-bucket/*"
}
]
}

This is useful when an EC2 instance or Lambda function needs access to the bucket. Use roles instead of long-term access keys.

Step 5: Require Encryption on Upload

This policy blocks any upload that isn't encrypted with SSE-KMS:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyUnencryptedUploads",
"Effect": "Deny",
"Principal": "",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::vishal-secure-demo-bucket/",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
}
]
}
Step 6: Test Your Setup
Try uploading a file with the IAM user: it should succeed.
Try accessing the bucket over plain HTTP: it should be denied.
Try accessing the bucket with a different user that has no permissions: you should see Access Denied.
Use the IAM Policy Simulator or IAM Access Analyzer to validate your policies.
S3 Security Best Practices
Enable Block Public Access at both the bucket and account level.
Follow least privilege. Grant only the actions and resources that are needed.
Use IAM roles, not long-term access keys.
Enforce HTTPS with aws:SecureTransport.
Encrypt data at rest (SSE-S3 or SSE-KMS).
Enable versioning and consider MFA Delete for critical data.
Turn on logging with S3 server access logs and CloudTrail data events.
Use IAM Access Analyzer to find buckets shared outside your account.
Avoid "Principal": "" with Allow unless you really mean public access.
Review policies regularly and remove permissions that are no longer used.
Common Mistakes to Avoid
Using "Action": "s3:" and "Resource": "" in IAM policies.
Forgetting the / on the resource ARN for object-level actions.
Making a bucket public "temporarily" and forgetting about it.
Hardcoding access keys in application code.
Not testing policies before applying them in production.
Conclusion

Securing S3 isn't about picking IAM policies or bucket policies. The strongest setups use both:

IAM policies control what your users and roles can do.
Bucket policies enforce rules at the bucket itself, like HTTPS-only access, encryption, and cross-account permissions.
Block Public Access, encryption, and logging add extra layers of protection.

Start with least privilege, test your policies, and review them regularly. Your data will be much safer for it.

I'm learning and sharing my AWS journey step by step. If this article helped you, leave a comment or a reaction. Let me know which AWS topic you'd like me to cover next!

Connect with me:

LinkedIn: vishalpatil-devops-aws
dev.to: @vishal_patil_aws
GitHub: VishalPatil-DevOps-AWS

vishalcloudjourney #aws #s3 #security

Learning AWS as a Beginner: A Practical Roadmap with Hands-On Projects

Vishal Patil — Sat, 31 Oct 2026 06:20:07 +0000

Learning AWS as a Beginner: A Practical Roadmap with Hands-On Projects

When I started learning AWS, the biggest problem wasn't a lack of resources. It was knowing where to begin. There are 200+ services, and most tutorials make it feel like you need to learn all of them.

You don't. This article covers the order I'd recommend, the services that matter first, and the projects that actually make the concepts stick.

1. Start with the Fundamentals

Before touching services, understand the basics:

Regions and Availability Zones: where your resources physically live
Shared Responsibility Model: what AWS secures vs. what you secure
Pay-as-you-go pricing: why cost awareness matters from day one

A good way to validate this knowledge is the AWS Cloud Practitioner path. I used AWS Cloud Quest: Cloud Practitioner, a game-style, hands-on learning experience that earns you a badge.

2. Secure Your Account First

Do this before building anything:

Create your AWS account
Enable MFA on the root user
Stop using root for daily work. Create an IAM user or role instead
Learn the difference between IAM Users, Groups, Roles, and Policies

The key idea: use roles for services and temporary access, and follow least privilege.

3. Set Up Billing Alarms and Budgets

Surprise bills are the #1 beginner fear. Set up AWS Budgets and a CloudWatch billing alarm early so you get notified when spend crosses a threshold.

Free Tier terms have changed over time, so check the current AWS Free Tier page for what applies to your new account.

4. Learn the Core Services in This Order

Order	Service	What it teaches you
1	IAM	Identity and access control
2	EC2	Virtual servers, security groups, key pairs
3	S3	Object storage, static website hosting
4	VPC	Networking, subnets, routing
5	CloudWatch	Monitoring, logs, alarms
6	SNS	Notifications and alerts
7	RDS	Managed databases
8	Lambda	Serverless compute

Don't try to master each one. Learn enough to build something small with it.

5. Practical Projects for Beginners

Projects are where learning becomes real. Here are some that fit each stage:

Project 1: Launch and Connect to an EC2 Instance

Launch a free-tier-eligible instance
Configure a security group
SSH in and install a web server like NGINX
Skills: EC2, security groups, Linux basics

Project 2: Host a Static Website on S3

Create a bucket, upload HTML/CSS/JS
Enable static website hosting
Skills: S3, bucket policies, permissions

Project 3: EC2 Monitoring with CloudWatch + SNS Alerts

Create a CloudWatch alarm on EC2 CPU utilization
Connect it to an SNS topic that emails you
Trigger the alarm and watch it work
Skills: CloudWatch, SNS, monitoring workflows

Project 4: IAM Roles in Action

Create an IAM role with limited permissions
Attach it to an EC2 instance so it can access S3 without hardcoded keys
Skills: IAM roles, least privilege, secure access patterns

Project 5: Build a Simple VPC

Create a custom VPC with public and private subnets
Add an Internet Gateway and route tables
Skills: Networking fundamentals

Project 6: CI/CD with Jenkins on EC2 (Stretch Goal)

Run Jenkins on EC2 and connect it to GitHub
Build and push a Docker image to Docker Hub
Skills: DevOps workflows, containers, automation

6. Habits That Make Learning Stick

Build, then document. Writing about what you built exposes gaps in your understanding.
Always clean up. Terminate instances, delete buckets, and remove unused resources after each project.
Break things on purpose. Misconfigure a security group and see what fails. You learn faster from errors.
Use the console first, then automate. Understand it manually before moving to CLI or Infrastructure as Code.
Share your progress. Posting your learning publicly keeps you accountable and connects you with the community.

7. What to Learn Next

Once you're comfortable with the basics:

AWS CLI and scripting
Infrastructure as Code (CloudFormation or Terraform)
Load balancers and Auto Scaling
Containers (ECS/EKS)
An associate-level certification such as Solutions Architect or SysOps

Final Thoughts

You don't need to know everything to start. Pick one service, build one small project, document it, and repeat. Consistency beats intensity.

If you're on a similar journey, I'd love to hear which AWS project you're building next. Drop it in the comments!

Connect with me:

vishalcloudjourney

Why Building Your Career with AWS Is a Smart Move

Vishal Patil — Fri, 30 Oct 2026 05:14:10 +0000

Key advantages of starting your cloud career with AWS: demand, learning paths, certifications, community, and growth.
tags: aws, cloud, career, beginners

Cloud computing is now the foundation of modern technology, and AWS sits at the center of it. Whether you are a student, a fresher, or a working professional switching tracks, building your career around AWS opens doors that few other skill sets can match. Here are the main advantages.

1. High Demand Across Industries

Startups, banks, healthcare companies, media platforms, and government bodies all run workloads on AWS. That means AWS skills are not tied to one sector. Roles such as Cloud Engineer, DevOps Engineer, Solutions Architect, Security Engineer, and Data Engineer all list AWS experience as a core requirement.

2. Beginner-Friendly Learning Path

AWS makes it easy to start from zero:

AWS Free Tier lets you practice with real services without large costs.
AWS Skill Builder and AWS Cloud Quest teach through guided, game-style labs.
Foundational certifications like Cloud Practitioner give you a structured first milestone before moving to Associate and Professional levels.

You do not need a deep background to begin. You need curiosity and consistent hands-on practice.

3. Hands-On Skills That Employers Value

AWS rewards learning by doing. Launching an EC2 instance, configuring IAM roles, setting up a VPC, or building CloudWatch alarms with SNS notifications teaches you real operational skills. These small projects become portfolio pieces that show employers you can build, not just memorize.

4. Industry-Recognized Certifications

AWS certifications are among the most respected in the industry. They validate your knowledge, strengthen your resume, and give you a clear roadmap from Foundational to Associate, Professional, and Specialty levels. Digital badges through Credly make your achievements easy to share and verify on LinkedIn.

5. A Broad Range of Career Paths

Once you learn the AWS fundamentals, you can specialize in many directions:

DevOps and CI/CD: automation, pipelines, containers
Cloud Architecture: designing scalable, secure systems
Security: IAM, encryption, compliance
Data and AI/ML: analytics, machine learning, generative AI
Networking and Infrastructure: VPC, load balancing, hybrid setups

You can start broad and narrow down as you discover what you enjoy.

6. Strong Community Support

The AWS community is one of its biggest strengths. Programs like AWS Community Builders, user groups, meetups, and AWS Builder Center let you learn from others, share your own work, and build visibility. Writing articles, posting projects, and helping others is one of the fastest ways to grow your reputation as a cloud professional.

7. Better Earning and Growth Potential

Cloud skills are in short supply compared to demand, so professionals with AWS expertise often see faster career progression and stronger salary prospects. As you combine AWS knowledge with skills like Linux, Docker, Terraform, and CI/CD, your value increases further.

8. Future-Proof Skills

AWS continues to expand into serverless computing, containers, and AI and machine learning services such as Amazon Bedrock. Learning AWS today prepares you for how software will be built and run in the years ahead.

How to Get Started

Create an AWS Free Tier account and set up billing alerts first.
Learn core services: IAM, EC2, S3, VPC, and CloudWatch.
Build small projects and document them publicly.
Earn a foundational certification, then move to Associate level.
Share what you learn through articles and community platforms.

Conclusion

Building your career with AWS is not just about learning a platform. It is about developing practical, in-demand skills, joining a global community, and gaining the confidence to build real solutions. Start small, stay consistent, and document your journey as you go.

Author: Vishal Patil

🔗 LinkedIn | 💻 GitHub | ✍️ dev.to

vishalcloudjourney

13 AWS Badges in 2 Months: How I Started My Cloud Journey

Vishal Patil — Thu, 29 Oct 2026 08:24:30 +0000

The order I earned 13 AWS and Linux Foundation badges between June and August 2026, what each one covers, and lessons for beginners."
tags: aws, beginners, cloud, learning

Two months ago I had no cloud credentials at all. Today my profile shows 13 digital badges earned between June 19 and August 18, 2026. None of them is a certification, and I don't pretend they are. But together they gave me structure, vocabulary, and hands-on confidence.

In this post I'll share the badges, the order I earned them in, and the lessons I'd pass on to anyone starting from zero.

My 13 badges at a glance

#	Badge	Issued by	Date
1	AWS Educate: Introduction to Cloud 101	AWS Training and Certification	Jun 19, 2026
2	AWS Educate: Getting Started with Compute	AWS Training and Certification	Jun 30, 2026
3	AWS Educate: Getting Started with Storage	AWS Training and Certification	Jul 3, 2026
4	AWS Educate: Getting Started with Networking	AWS Training and Certification	Jul 25, 2026
5	AWS Educate: Getting Started with Databases	AWS Training and Certification	Aug 1, 2026
6	AWS Educate: Getting Started with Cloud Ops	AWS Training and Certification	Aug 2, 2026
7	AWS Educate: Getting Started with Serverless	AWS Training and Certification	Aug 3, 2026
8	AWS Cloud Quest: Cloud Practitioner	AWS Training and Certification	Aug 14, 2026
9	AWS Knowledge: AWS End User Computing	AWS Training and Certification	Aug 17, 2026
10	AWS Knowledge: Cloud Essentials	AWS Training and Certification	Aug 17, 2026
11	AWS Knowledge: Networking Core	AWS Training and Certification	Aug 17, 2026
12	LFD103: A Beginner's Guide to Linux Kernel Development	The Linux Foundation	Aug 17, 2026
13	Well-Architected Proficient	AWS Training and Certification	Aug 18, 2026

Phase 1: Building the foundation (June to July)

I began with Introduction to Cloud 101 from AWS Educate. Before touching any service, I needed to understand what "the cloud" actually means: on-demand resources, pay-as-you-go pricing, and the global infrastructure.

Then I worked through the Getting Started series one service area at a time, starting with Compute and Storage. One topic per course kept things manageable. Instead of trying to learn "AWS" all at once, I learned what EC2 does, then what S3 does, then how they connect.

Phase 2: Going deeper into the core services (July to August)

The next badges covered Networking, Databases, Cloud Ops, and Serverless. I earned the last three within three days, because the earlier courses had already built the vocabulary: VPCs, subnets, managed databases, monitoring, and Lambda stopped sounding like jargon.

The most useful habit of this phase was trying the idea myself in the AWS Free Tier after each course. Reading about a security group and creating one are two very different experiences.

Phase 3: Learning by doing with Cloud Quest

On August 14 I earned the AWS Cloud Quest: Cloud Practitioner badge. Cloud Quest is a game-style, role-based experience where you build solutions in a virtual city. It was the point where theory turned into practice, because I had to apply ideas instead of just recognizing them in a quiz.

Phase 4: The knowledge badges sprint

On August 17 I earned three AWS Knowledge badges: Cloud Essentials, Networking Core, and AWS End User Computing. I also finished LFD103: A Beginner's Guide to Linux Kernel Development from the Linux Foundation that day.

That was a concentrated study day, not a typical one. The takeaway isn't "do four things in one day." It's that once the foundations are in place, later topics go much faster.

Phase 5: Thinking like an architect

The last badge, Well-Architected Proficient (August 18), introduced me to the AWS Well-Architected Framework. It shifted my mindset from "how do I use this service?" to "is this design secure, reliable, efficient, and cost-aware?" I'd recommend taking it after you've seen the core services, not before.

What these badges are, and what they aren't

They are proof that I completed structured training and met the requirements of each course
They are shareable and verifiable, so anyone can check them
They are not AWS certifications, and they don't replace exams like Cloud Practitioner (CLF-C02)

I treat them as milestones on the way to certification, not the destination.

Lessons for beginners

Pick a clear order. Cloud basics, then individual services, then hands-on practice, then architecture thinking
One topic at a time. Small, focused courses are easier to finish and remember
Practice in your own account. Do something in the Free Tier after every course, and set a billing alarm first
Take notes in your own words, then turn them into posts
Mix sources. The Linux Foundation course reminded me that cloud skills sit on top of operating system fundamentals
Be consistent. Two months of steady effort beat one burst of motivation
Share your progress. Writing publicly keeps you accountable and helps you understand topics better

What's next

Prepare for the AWS Certified Cloud Practitioner exam
Keep building hands-on projects (containers, monitoring, billing alerts) and writing about them
Keep sharing what I learn here, on AWS Builder Center, and on LinkedIn

Wrapping up

Thirteen badges in two months didn't make me an expert. They gave me a map, and the habit of learning in public that I plan to keep. If you're starting out, pick your first course today.

What was your first AWS badge, and what are you working on next? Let me know in the comments.

Connect with me

LinkedIn: vishalpatil-devops-aws
dev.to: @vishal_patil_aws
GitHub: VishalPatil-DevOps-AWS
Credly (Cloud Quest badge): view badge

vishalcloudjourney

AWS Skill Builder: The Free Official Platform to Start Your Cloud Journey

Vishal Patil — Mon, 26 Oct 2026 23:48:19 +0000

When I started learning cloud, the hardest part wasn't the technology. It was knowing where to begin. There are endless YouTube playlists, paid courses, and blog posts, and it's easy to burn weeks just choosing what to study.

The best answer I found is also the official one: AWS Skill Builder. In this post I'll cover what it is, what you get for free, what the paid plans add, and how I'd use it as a beginner.

What is AWS Skill Builder?

AWS Skill Builder is Amazon's official online learning platform. It offers on-demand courses, learning plans organized by role and certification, exam preparation, digital badges, and hands-on practice. The content is written and maintained by AWS, so it tracks the real services and the real exams.

What you get for free

The free tier includes 600+ self-paced digital courses, learning plans, basic exam prep content, and digital badges. You don't need a credit card to start.

Highlights:

Digital courses from beginner to advanced: compute, storage, networking, security, databases, and more
Learning plans that group courses into a path so you don't have to guess the order
AWS Cloud Quest: Cloud Practitioner, a game-style way to learn by building solutions in a virtual city
Basic exam prep content and practice questions
Digital badges you can share on LinkedIn

What the paid plans add

Plan	Who it's for	What it adds
Free	Beginners	Courses, learning plans, basic exam prep, badges
Individual (from about $29/month)	Learners preparing for certifications	Builder Labs, full practice exams, AWS Jam challenge events
Team	Organizations	Admin dashboards, reporting, SSO support

Do you need to pay? For most beginners, no. The free tier plus your own AWS Free Tier account covers a lot. A subscription makes sense when you're preparing for several certifications or want guided labs and full-length practice exams. If you try it, subscribe for one month, finish the labs you wanted, and cancel.

Pricing and plan details change, so check the Skill Builder pricing page before deciding.

A beginner learning path

Start with Cloud Practitioner Essentials. It teaches the core AWS vocabulary: Regions, IAM, EC2, S3, pricing, and the shared responsibility model.
Play AWS Cloud Quest: Cloud Practitioner. It turns theory into practice, and finishing it earns a badge.
Use the exam prep learning plan if you're aiming for the Cloud Practitioner certification (CLF-C02).
Practice in your own account. Use the AWS Free Tier to repeat what you learned: create an IAM user, launch an EC2 instance, set up a billing alarm.
Move to an Associate-level path such as Solutions Architect or Developer once the basics feel comfortable.

My experience

I earned the AWS Cloud Quest: Cloud Practitioner (Trained) badge through Skill Builder, and it did more for my understanding than passive video watching. Building a solution inside the game, then recreating it in my own AWS account, made the concepts stick. You can see the badge on Credly.

Tips to get the most out of it

Follow a learning plan instead of picking random courses
Take notes in your own words, then turn them into blog posts
Pair every course with a small hands-on task in the Free Tier
Set a billing alarm first so practice never surprises you with a bill
Share your badges on LinkedIn to document your progress
Be consistent. Thirty focused minutes a day beats a six-hour weekend binge

Free tier limits to know about

The free tier is generous but not unlimited. Guided hands-on labs and full practice exams are mostly part of the paid plan, and free courses don't give you a completion certificate like an official certification does. Badges show learning progress. They don't replace a certification exam.

Wrapping up

If you're starting with AWS, Skill Builder is the best first stop: official, structured, and largely free. Pick a learning plan, practice in your own account, and share what you learn. That combination is what turns courses into real skills.

What's your favorite Skill Builder course so far? Let me know in the comments.

Connect with me

vishalcloudjourney

Deploy a Container on AWS with ECR and ECS (Fargate): Beginner's Guide

Vishal Patil — Sun, 25 Oct 2026 06:10:34 +0000

Push a Docker image to Amazon ECR and run it on ECS with Fargate, step by step, with CLI commands and common errors."

tags: aws, docker, devops, containers

Running a container on your laptop is easy. Running it reliably in the cloud means you need somewhere to store images and something to run, restart, and scale them. On AWS, that's Amazon ECR and Amazon ECS.

In this post I'll explain what each does and walk through deploying a containerized app on Fargate, so there are no servers to manage.

ECR vs ECS in one minute

Amazon ECR (Elastic Container Registry) is a private, managed registry for your container images. Think of it as a Docker Hub that lives inside your AWS account, with IAM-based access control, vulnerability scanning, and lifecycle policies.

Amazon ECS (Elastic Container Service) is the orchestrator. You describe what to run, and ECS places it, restarts it if it fails, and keeps the desired number of copies running.

Concept	What it is
Cluster	Logical grouping of tasks and services
Task definition	Blueprint: image, CPU, memory, ports, env vars, roles
Task	A running instance of a task definition
Service	Keeps N tasks running and replaces failed ones
Fargate	Serverless compute for containers, no EC2 to manage

The flow looks like this:

docker build → docker push → ECR (stores image)
                                ↓
              ECS task definition points to the image URI
                                ↓
              ECS service runs tasks on Fargate

Prerequisites

An AWS account
AWS CLI configured (aws configure)
Docker installed
A small app with a Dockerfile (Nginx or Node.js is fine)

Step 1: Create the ECR repository

aws ecr create-repository \
  --repository-name my-app \
  --region ap-south-1

Copy the repositoryUri from the output. It looks like <account-id>.dkr.ecr.ap-south-1.amazonaws.com/my-app.

Step 2: Build, tag, and push the image

# Build
docker build -t my-app .

# Authenticate Docker to ECR
aws ecr get-login-password --region ap-south-1 | \
docker login --username AWS --password-stdin \
<account-id>.dkr.ecr.ap-south-1.amazonaws.com

# Tag and push
docker tag my-app:latest <account-id>.dkr.ecr.ap-south-1.amazonaws.com/my-app:latest
docker push <account-id>.dkr.ecr.ap-south-1.amazonaws.com/my-app:latest

Check the ECR console and you should see the image with the latest tag.

Step 3: Create an ECS cluster

In the ECS console, choose Clusters → Create cluster, name it my-app-cluster, keep AWS Fargate (serverless) selected, and create it.

Step 4: Create the task definition

Task definitions → Create new task definition
Name: my-app-task, launch type: AWS Fargate
Size: for example 0.5 vCPU / 1 GB for a small app
Task execution role: ecsTaskExecutionRole
Add a container with your ECR image URI and container port (for example 80)
Leave CloudWatch logging enabled

Step 5: Run it as a service

Open the cluster → Services → Create
Launch type: Fargate, pick your task definition
Desired tasks: 1 (use 2 for availability)
Choose your VPC and subnets
Use a security group that allows inbound traffic on the container port
Create the service

Step 6: Test it

When the task shows RUNNING, open it, copy the public IP, and visit http://<public-ip>. Your container is live.

Task role vs task execution role

This trips up a lot of beginners:

Task execution role: used by ECS itself to pull the image from ECR and write logs to CloudWatch
Task role: used by your app code inside the container to call AWS services (for example, reading from S3)

Keep both as narrow as possible.

Troubleshooting

Problem	Likely cause
`CannotPullContainerError`	Execution role missing permissions, wrong image URI, or no network path to ECR (needs a public IP or NAT/VPC endpoints)
Task keeps stopping	App crashes on startup. Check CloudWatch logs and the exit code
Can't reach the app	Security group doesn't allow the container port, or the task has no public IP
Service stuck at 0 running tasks	Check the service Events tab for the exact error

Best practices

Don't deploy latest to production. Tag images with a version or commit hash
Turn on scan on push in ECR
Add lifecycle policies to expire old untagged images
Put an Application Load Balancer in front and run tasks in private subnets for production
Use least-privilege IAM roles
Store secrets in Secrets Manager or SSM Parameter Store, never as plain text in the task definition

Wrapping up

ECR gives your images a secure home, and ECS on Fargate runs them without any server management. Once images, task definitions, and services click, you have the foundation for production-ready container workloads on AWS. A good next step is adding an ALB and auto scaling, then automating the build-and-deploy flow with CI/CD.

If you found this useful, let me know in the comments what you'd like me to cover next.

Connect with me

vishalcloudjourney

Set Up AWS Budgets and Billing Alarms: Never Get a Surprise AWS Bill

Vishal Patil — Sat, 24 Oct 2026 06:41:51 +0000

A beginner-friendly guide to AWS Budgets, CloudWatch billing alarms and Free Tier alerts, so you never get a surprise AWS bill.

Almost every AWS beginner has the same fear: leaving something running and getting a bill at the end of the month that they didn't expect. The good news is that AWS gives you free tools to catch this early.

In this article, you'll set up two safety nets in about 15 minutes: an AWS Budget and a CloudWatch billing alarm, plus Free Tier usage alerts.

Why you need alerts from day one

A forgotten EC2 instance, NAT Gateway, load balancer or Elastic IP keeps costing money while you're not using it.
Practice projects are easy to forget after the tutorial ends.
Alerts tell you early, when the amount is still small and easy to fix.

AWS Budgets vs CloudWatch billing alarms

	AWS Budgets	CloudWatch billing alarm
What it tracks	Cost or usage against a limit you set, including forecasted spend	Total estimated charges so far this month
Where you set it	Billing and Cost Management console	CloudWatch console, in us-east-1
Notification	Email or SNS at thresholds you choose	SNS topic (email, SMS, Lambda and more)
Cost	Monitoring and notifications are free	Standard CloudWatch alarm pricing
Best for	Planning: "tell me before I exceed my limit"	A simple tripwire: "tell me if charges pass $X"

Use both. They are cheap, quick to set up, and cover each other's gaps.

What you need

An AWS account and access to the root user, or an IAM user with billing permissions
A working email address

Note for IAM users: By default only the root user can see billing pages. The root user must turn on IAM user and role access to Billing information in Account settings.

Part 1: Turn on billing alerts

Open Billing and Cost Management in the console.
Go to Billing preferences.
Under Alert preferences, enable AWS Free Tier alerts and add your email.
Enable CloudWatch billing alerts (needed for Part 3) and save.

Menu labels change from time to time, so if something looks slightly different, search for "Billing preferences" in the Billing console.

Part 2: Create a monthly cost budget

Open Budgets and choose Create budget.
Pick the Monthly cost budget template. (The Zero spend budget alerts you as soon as spending goes above the Free Tier.)
Name it (for example monthly-cost-budget) and set an amount such as $5 or $10 for a learning account.
Enter the email address(es) for alerts.
Choose **Create budget.

Then add thresholds:

Alert	Threshold	Why
Actual cost	50% of budget	Early heads-up that you're spending faster than planned
Actual cost	80% of budget	Time to review what's running
Forecasted cost	100% of budget	Warns you before you cross the limit

Good to know : AWS updates budget data a few times a day, so alerts aren't instant. Monitoring and notifications are free. Only optional extras cost money: after your first two action-enabled budgets each month, extra ones cost $0.10 per day, and each emailed Budgets report costs $0.01.

Part 3: Create a CloudWatch billing alarm

Billing metrics are only published in US East (N. Virginia) us-east-1, so switch to that Region first, even if your resources are elsewhere.

Open CloudWatch and switch the Region to US East (N. Virginia).
Go to Alarms → All alarms → Create alarm → Select metric.
Choose Billing → Total Estimated Charge**, select the USD metric (EstimatedCharges).
Set Statistic = Maximum,Period = 6 hours, Static, Greater than your limit (for example 5).
Create a new SNS topic (for example billing-alerts) and enter your email.
Name the alarm (for example Billing-Alarm-5-USD) and create it.
Open your inbox and confirm the SNS subscription email. Until you do, no alerts will reach you.

Prefer the CLI? Use this (replace the SNS topic ARN with yours):

aws cloudwatch put-metric-alarm \
  --alarm-name "Billing-Alarm-5-USD" \
  --namespace "AWS/Billing" \
  --metric-name "EstimatedCharges" \
  --dimensions Name=Currency,Value=USD \
  --statistic Maximum \
  --period 21600 \
  --evaluation-periods 1 \
  --threshold 5 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:<account-id>:billing-alerts \
  --region us-east-1

Part 4: Verify everything works

Check	What to look for
Budgets console	Your budget is listed with status "OK"
CloudWatch (us-east-1)	The alarm shows "OK" (or "Insufficient data" briefly)
SNS	The subscription status is Confirmed, not "Pending"
Email	You received the Free Tier alert and SNS confirmation messages

Common mistakes

Problem	Fix
No billing metric in CloudWatch	Switch to us-east-1 and enable CloudWatch billing alerts
Alarm never sends email	Confirm the SNS subscription email and check spam
Can't open billing pages as an IAM user	Root user must activate IAM access to Billing information
Alert arrived but charges are unclear	Use **Cost Explorer and group by Service

Best practices

Alerts are notifications, not a spending cap. AWS won't stop your resources automatically, so act when you get the email.
Use several thresholds (50%, 80%, forecasted 100%).
Check Cost Explorer once a week while you're learning.
Tag lab resources (for example Project=learning) so they're easy to find and delete.
Delete resources after every lab: EC2, NAT Gateways, load balancers, unused Elastic IPs and old EBS volumes.
Protect the root user with MFA.
Next step: explore AWS Budgets Actions and Cost Anomaly Detection.

Conclusion

Setting up AWS Budgets and billing alarms takes only a few minutes, costs nothing for the basic setup, and protects you from the most common beginner mistake in the cloud. Do it once, right after you create your account, and you can experiment with AWS services with much more confidence.

If this helped you, let me know which AWS topic you'd like me to cover next.

Author : Vishal Patil

🔗 LinkedIn: https://www.linkedin.com/in/vishalpatil-devops-aws/
💻 GitHub: https://github.com/VishalPatil-DevOps-AWS

vishalcloudjourney #AWS #AWSBudgets #CloudWatch #CostOptimization #FinOps #DevOps

From Dockerfile to the Cloud: Deploy a Docker Container on AWS with ECR and ECS Fargate"

Vishal Patil — Fri, 23 Oct 2026 07:17:04 +0000

description: "A beginner-friendly, step-by-step guide to packaging an app with Docker, storing it in Amazon ECR, and running it on ECS Fargate with no servers to manage."
tags: aws, docker, devops, vishalcloudjourney

Docker is one of the most useful skills for anyone moving into cloud and DevOps. Running a container on your laptop is easy. The real question is how to run it reliably on AWS without managing servers.

In this article, you'll take a simple app from a Dockerfile to a running container on AWS, using these services:

Docker to package the app
Amazon ECR (Elastic Container Registry) to store the image
Amazon ECS with AWS Fargate to run the container with no EC2 instances to manage

What You'll Need

An AWS account (a Free Tier account is fine for learning)
Docker installed on your machine
AWS CLI installed and configured (aws configure)
Node.js (optional, only to test the app outside Docker)

Step 1: Create a Simple App

Create a folder called my-docker-app with these files.

app.js

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello from Docker running on AWS Fargate!');
});

app.listen(3000, '0.0.0.0', () => {
  console.log('App running on port 3000');
});

package.json

{
  "name": "my-docker-app",
  "version": "1.0.0",
  "main": "app.js",
  "dependencies": {
    "express": "^4.19.2"
  }
}

Step 2: Write the Dockerfile

Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "app.js"]

Why it's written this way:

alpine gives you a small image, so pulls are faster and the attack surface is smaller.
Copying package*.json first lets Docker cache the dependency layer, so rebuilds are much faster.

Step 3: Build and Test Locally

docker build -t my-docker-app:v1 .
docker run -d -p 3000:3000 my-docker-app:v1

Open http://localhost:3000. You should see your message. Always test locally first, because it saves a lot of debugging time later.

Tip: If you're on an Apple Silicon Mac, build with --platform linux/amd64 so the image runs on standard Fargate.

Step 4: Push the Image to Amazon ECR

Create the repository:

aws ecr create-repository --repository-name my-docker-app --region ap-south-1

Authenticate Docker to ECR (replace <account-id> with your 12-digit AWS account ID):

aws ecr get-login-password --region ap-south-1 | docker login --username AWS --password-stdin <account-id>.dkr.ecr.ap-south-1.amazonaws.com

Tag and push:

docker tag my-docker-app:v1 <account-id>.dkr.ecr.ap-south-1.amazonaws.com/my-docker-app:v1
docker push <account-id>.dkr.ecr.ap-south-1.amazonaws.com/my-docker-app:v1

Go to ECR → Repositories → my-docker-app in the console. Your image should now be listed.

Step 5: Create an ECS Cluster

Open Amazon ECS → Clusters → Create cluster
Name it docker-demo-cluster
Under infrastructure, keep AWS Fargate (serverless) selected
Click Create

Step 6: Create a Task Definition

A task definition is the blueprint for your container.

Go to ECS → Task definitions → Create new task definition
Name: my-docker-app-task
Launch type: AWS Fargate
CPU / Memory: 0.25 vCPU / 0.5 GB (enough for this demo)
Task execution role: ecsTaskExecutionRole (let ECS create it if it doesn't exist)
Container details:
- Name: my-docker-app
- Image URI: <account-id>.dkr.ecr.ap-south-1.amazonaws.com/my-docker-app:v1
- Container port: 3000
Click Create

The execution role is what allows Fargate to pull your image from ECR and send logs to CloudWatch.

Step 7: Run the Container as a Service

Open your cluster and go to Services → Create
Compute option: Launch type → Fargate
Task definition: my-docker-app-task
Desired tasks: 1
Under Networking:
- Pick your VPC and a public subnet
- Create or select a security group that allows inbound TCP 3000 from your IP (or 0.0.0.0/0 for a quick demo only)
- Turn Public IP on
Click Create

Wait a minute or two until the task status shows Running.

Step 8: Test It

Open Cluster → Tasks → select your running task
Copy the Public IP from the networking section
Visit http://<public-ip>:3000 in your browser

You'll see: Hello from Docker running on AWS Fargate!

Your container is now running on AWS with no servers to patch or manage.

Troubleshooting Common Issues

Problem	Likely Cause
Task stops immediately	Check the container logs in CloudWatch and confirm the `CMD` is correct
Can't pull the image	The execution role is missing ECR permissions, or the image URI has a typo
Page doesn't load	Security group isn't allowing port 3000, or the public IP isn't enabled
"exec format error"	Image built for the wrong CPU architecture (see the platform tip in Step 3)

Best Practices

Don't use the latest tag in production. Use versioned tags like v1 and v2 so you can roll back.
Turn on ECR image scanning to catch known vulnerabilities.
Use least-privilege IAM roles for tasks.
Put an Application Load Balancer in front for real workloads instead of exposing the task's public IP.
Send logs to CloudWatch and set alarms on failures.

Clean Up to Avoid Charges

When you're done:

Set the ECS service desired count to 0, then delete the service
Delete the cluster
Delete the ECR repository (or the image)
Delete any security groups you created for the demo

Conclusion

You've taken an application from source code to a running container on AWS using Docker, ECR, and ECS Fargate. This same pattern scales from a small demo to production workloads. Adding an ALB, auto scaling, and a CI/CD pipeline are natural next steps.

If you found this helpful, let me know which topic you'd like me to cover next.

Author: Vishal Patil

🔗 LinkedIn: vishalpatil-devops-aws
💻 GitHub: VishalPatil-DevOps-AWS

vishalcloudjourney #AWS #Docker #ECS #Fargate #ECR #DevOps #Containers

AWS RDS Explained: Launch, Secure, and Scale a Managed Database

Vishal Patil — Thu, 22 Oct 2026 02:38:51 +0000

By Vishal Patil | #vishalcloudjourney

Running a database on your own EC2 instance means you are also the DBA. You patch the OS, schedule backups, set up replication, and wake up when the disk fills. Amazon RDS (Relational Database Service) takes that operational work off your plate so you can focus on your application. In this hands-on guide, you'll launch a MySQL database on RDS, lock it down, connect from EC2, test automatic failover, and learn how to scale reads.

What Is Amazon RDS?

Amazon RDS is a managed service for relational databases. You choose the engine and size, and AWS handles the heavy lifting.

Supported engines: Amazon Aurora (MySQL and PostgreSQL compatible), MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2.

What AWS manages for you

Hardware provisioning and OS patching
Automated backups and point-in-time recovery
Database software patching during a maintenance window
Multi-AZ failover
Monitoring through CloudWatch

What you still manage

Schema design, queries, and indexes
Security groups, network placement, and user access
Choosing instance size and storage
Cost control

Note: With standard RDS you don't get SSH or OS-level access to the underlying host. That's the trade-off for a managed service.

What You Will Build

A security group setup where only your EC2 app server can reach the database
A private MySQL RDS instance with encryption and automated backups
A connection from EC2 to the database
A Multi-AZ standby and a failover test
(Optional) A read replica

Architecture:

EC2 app server (ec2-app-sg) → RDS MySQL primary (rds-sg, AZ-a)
                                  ↓ synchronous replication
                              RDS standby (AZ-b), takes over on failure

Key Concepts in 60 Seconds

DB instance: The managed database server you pay for.
DB subnet group: The subnets (in at least two AZs) where RDS is allowed to place your database.
Multi-AZ: A standby copy in another AZ, kept in sync, that takes over automatically if the primary fails. It's for availability, not for read scaling.
Read replica: An asynchronously updated copy used to scale read traffic.
Automated backups: Daily backups plus transaction logs, kept for 1 to 35 days, enabling point-in-time restore.
Snapshot: A manual backup that stays until you delete it.
Endpoint: The DNS name your application uses to connect. Always use the endpoint, never an IP.

Prerequisites

An AWS account with permissions for RDS, EC2, and VPC
A VPC with subnets in at least two AZs (the default VPC works)
A running EC2 instance (Amazon Linux 2023) to act as your app server, or you can launch one in Step 4

Cost note: RDS bills while the instance is running, and Multi-AZ roughly doubles the instance cost. Check the current Free Tier terms for your account and follow the cleanup section at the end.

Step 1: Create the Security Groups

Use two security groups so the database is reachable only from your app server.

App security group (ec2-app-sg) attached to your EC2 instance

Inbound: SSH (22) from your IP, or use EC2 Instance Connect or Session Manager

Database security group (rds-sg)

Inbound: MySQL/Aurora (3306) from ec2-app-sg (select the security group as the source, not 0.0.0.0/0)

This is the single most important RDS security habit: never open your database port to the internet.

Step 2: Check the DB Subnet Group

Go to RDS → Subnet groups.
The default VPC already has a default subnet group covering its subnets.
For your own VPC, create a subnet group and add subnets from at least two AZs.

Step 3: Create the Database

Go to RDS → Databases → Create database.
Choose Standard create and engine MySQL.
Template: Free tier or Dev/Test, depending on what your account shows.
Settings:
- DB instance identifier: mydb-rds
- Master username: admin
- Credentials: choose Managed in AWS Secrets Manager (recommended), or set a strong password yourself
Instance configuration: a small burstable class such as db.t4g.micro or db.t3.micro.
Storage:
- Type: General Purpose SSD (gp3), 20 GiB
- Enable storage autoscaling with a sensible maximum
Connectivity:
- VPC and subnet group: your chosen ones
- Public access: No
- VPC security group: rds-sg
Additional configuration:
- Initial database name: appdb
- Automated backups: enabled, retention 7 days
- Encryption: enabled (this must be chosen at creation)
- Deletion protection: on for anything important
Click Create database. It takes a few minutes to reach Available.
Open the database and copy its Endpoint.

Step 4: Connect from EC2

Connect to your EC2 instance (launch one with ec2-app-sg in the same VPC if you don't have one).
Install a MySQL client:

   sudo dnf install -y mariadb105

Connect using the RDS endpoint:

   mysql -h <your-rds-endpoint> -u admin -p

If you used Secrets Manager, open the secret in the console and choose Retrieve secret value to get the password.

Create a table and add data:

   USE appdb;
   CREATE TABLE visitors (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50));
   INSERT INTO visitors (name) VALUES ('Vishal'), ('AWS Builder');
   SELECT * FROM visitors;

You now have a working managed database that only your app server can reach.

Step 5: Turn On Multi-AZ

Select your database and click Modify.
Under Availability, choose Create a standby instance (Multi-AZ).
Choose Apply immediately and confirm.

RDS creates a standby in another AZ and keeps it synchronized. Your endpoint stays the same.

Step 6: Test Failover

Select the database, then Actions → Reboot.
Check Reboot with failover? and confirm.
Watch the Events tab and the database's AZ. The standby is promoted, and the AZ changes.
Re-run your SQL query. Your data is still there, and the same endpoint works.

Expect a short interruption (typically a minute or two) while DNS flips to the new primary. Your application should retry failed connections.

Step 7 (Optional): Add a Read Replica

Select the database and choose Actions → Create read replica.
Give it an identifier such as mydb-rds-replica.
Once available, point read-heavy queries at the replica's endpoint and keep writes on the primary.

Replication is asynchronous, so replicas can lag slightly behind the primary.

Multi-AZ vs Read Replica

	Multi-AZ	Read Replica
Purpose	High availability and failover	Read scaling
Replication	Synchronous	Asynchronous
Takes traffic normally	No (standby only)	Yes (reads)
Automatic failover	Yes	No (manual promotion)

Security Best Practices

Keep Public access set to No and place the DB in private subnets.
Allow access only from application security groups.
Use Secrets Manager for credentials and rotate them.
Enable encryption at rest (KMS) and enforce SSL/TLS connections.
Turn on deletion protection and automated backups.
Use IAM to control who can modify or delete DB instances.

Cost Tips

Pick the smallest instance that meets your needs and resize later.
Use Multi-AZ for production, but not for throwaway labs.
Stop or delete dev databases you aren't using. (A stopped RDS instance is automatically started again after 7 days.)
Delete old manual snapshots you no longer need.
Consider Reserved Instances for steady, long-running databases.

Common Issues and Fixes

Problem	Likely cause	Fix
Connection times out	`rds-sg` doesn't allow 3306 from your app's SG	Add the inbound rule with `ec2-app-sg` as source
Can't connect from your laptop	Database is private (public access: No)	Connect through EC2, a bastion, or Session Manager
Access denied for user	Wrong username or password	Re-check credentials or the Secrets Manager value
Unknown database	Initial DB name wasn't set	Run `CREATE DATABASE appdb;`
Storage full warnings	Autoscaling off or limit reached	Enable storage autoscaling or increase size

Clean Up

To avoid charges:

Delete the read replica first (if you created one)
Turn off deletion protection, then delete the DB instance
Decide whether to keep a final snapshot (it costs storage) and whether to delete automated backups
Delete leftover manual snapshots
Delete the security groups and the EC2 instance if no longer needed
Delete the Secrets Manager secret if you created one just for this lab

Conclusion

Amazon RDS lets you run production-grade relational databases without managing servers, patches, or backups by hand. With private networking, Multi-AZ, and automated backups, you get a secure and resilient foundation in minutes. Next, try adding a read replica, enabling Performance Insights, or moving to Aurora to see how far managed databases can go.

If you found this helpful, let's connect and keep learning together.