Forem: Ashwin Venkatesan

Sample b

Ashwin Venkatesan — Thu, 26 Feb 2026 05:52:10 +0000

Structure Terraform projects using reusable modules (e.g., VPC, compute, database) instead of defining all resources in a single root configuration.
• Organize code with a clear separation between modules/ (reusable logic) and environment folders like dev/, prod/ to maintain clarity.
• Avoid code duplication by applying the DRY principle, using variables to customize modules per environment.
• Ensure each environment has isolated configurations and state to reduce blast radius and prevent accidental production impact.

• Always store Terraform state in a remote backend (e.g., S3, Terraform Cloud, Azure Storage) instead of local state to enable secure team collaboration.
• Enable state locking (e.g., DynamoDB with S3 backend) to prevent concurrent terraform apply operations and avoid race conditions.
• Never commit terraform.tfstate files to version control, as they may contain sensitive data and infrastructure mappings.
• Use separate remote state files for each environment (dev, staging, prod) to ensure isolation and reduce blast radius.
• Protect state integrity through backend versioning and access control (IAM roles, RBAC) to prevent accidental modification or corruption.

Never hardcode sensitive values (passwords, API keys, access keys) directly in Terraform configuration files, as this exposes credentials in version control and increases security risk. • Use secure secret management solutions such as environment variables, IAM roles, AWS Secrets Manager, HashiCorp Vault, or CI/CD secret stores to inject sensitive values securely. • Mark sensitive input variables using sensitive = true to prevent secret values from being displayed in CLI output and logs. • Ensure Terraform state files are protected, encrypted, and stored in secure remote backends, since state may contain sensitive data. • Follow the principle of least privilege by granting only the minimum required permissions to Terraform execution roles.

Subject: Request for Billing Adjustment – Unexpected Charges

Hello AWS Support Team,

I am a student currently learning AWS and working on a personal project (POC).

Recently, I noticed an unexpected charge of approximately INR 9000 in my account. This was unintentional and happened due to my lack of experience in managing AWS resources properly.

As soon as I realized this, I immediately stopped and terminated all running resources to prevent further charges.

I kindly request you to consider a one-time billing adjustment or waiver for this amount. As a student, this cost is quite significant for me, and I am actively learning and planning to continue using AWS responsibly in the future.

I truly appreciate your support and understanding.

Thank you,
[Your Name]

12 Simple AWS Tips That Actually Help in Real Projects

Ashwin Venkatesan — Sun, 08 Feb 2026 14:38:39 +0000

These aren’t advanced tricks or new services.
Just small habits that make AWS clearer, safer, and cheaper over time.

1️⃣ Name every resource properly

Random IDs are fine for AWS — not for humans.
A simple naming format like:

env-service-purpose

2️⃣ Check the Billing dashboard daily

Even if you’re a beginner.

Just open:
Current month spend
Service-wise cost

This removes fear around AWS bills and builds cost awareness early.

3️⃣ Delete unused resources immediately

Stopped using something? Delete it now.

“Later” usually means:

Forgotten EC2s
Idle Load Balancers
Surprise charges

4️⃣ Security Groups are stateful (important)

If inbound traffic is allowed, return traffic is allowed automatically.

Knowing this prevents:
Extra outbound rules
Unnecessary open ports

5️⃣ Most AWS issues are IAM issues

Before blaming the service, always check:

Role attached?
Correct policy?
Correct resource?

Permissions fail more often than AWS itself.

6️⃣ Start with the simplest architecture

Don’t jump straight to:

Multi-AZ
Auto Scaling
Complex networking

Build simple → understand → then scale.

7️⃣ Think in flows, not services

Instead of memorising services, think:

Request → Load balancer → App → Database → Response

This helps in:

Debugging
Architecture design
Interviews

8️⃣ Always know what is public and what is private

Ask yourself:

Is this resource internet-facing?

Who can access it?

Public exposure is the #1 beginner mistake.

9️⃣ Tags are not optional

Even simple tags like:

Project
Environment
Owner

🔟 Don’t overuse free tier blindly

Free tier ≠ free forever.

Some services:

Expire after 12 months
Have usage limits

Always check the fine print.

1️⃣1️⃣ Logs are your best friend

Before guessing:

Check CloudWatch logs
Check metrics

AWS usually tells you what is wrong — if you look.

1️⃣2️⃣ Consistency matters more than speed

You don’t need to learn everything at once.

Small, consistent AWS usage beats binge-learning services.
Final thought
AWS mastery doesn’t come from knowing all services.

It comes from:

Clear thinking
Good habits
Real usage The rest follows naturally.

What AWS Certifications Don’t Teach You — Lessons from Real Cloud Projects

Ashwin Venkatesan — Wed, 24 Dec 2025 07:17:14 +0000

I used to think AWS was about collecting certifications and drawing clean architectures.

Then I built real projects.

And everything changed.

Certifications helped me understand the landscape — the names, the possibilities, the patterns. They gave me breadth.

Projects gave me something completely different — the ability to touch AWS, mess up configurations, stare at logs, question my life choices, fix them, redeploy, and finally see it work. That gave me depth.

Most importantly, projects gave me confidence through failure, not success.

The AWS services I actually worked with

Compute & Execution: EC2, AWS Lambda
Containers: ECS (Fargate), ECR
Networking: VPC, ALB, Route 53, Security Groups
CDN & Storage: CloudFront, S3
CI/CD: CodePipeline, CodeBuild, CodeDeploy
Observability: CloudWatch (Logs, Metrics, Alarms), AWS X-Ray
AI Layer: AWS Bedrock (Llama 3), Amazon SNS for alerts

These weren’t services I memorized for an exam — these were services I argued with until they started working.

Common failures that humbled me (and what they taught me)

CloudFront + S3 showing 403

I assumed S3 should be public so CloudFront can read it. Wrong.
The fix was learning how CloudFront OAC signs requests, and S3 should trust CloudFront, not the world.

ALB Target Group Unhealthy

I thought my app was broken. It wasn’t.
The security group only allowed my IP, not ALB.
Lesson learned: AWS debugging is 50% IAM + 50% networking + 0% magic.

ECS task stopped immediately

I blamed Fargate. Turns out I misconfigured the container port and IAM execution role.
Fixing it taught me the difference between task role vs execution role — something the exam never forced me to truly internalize.

Lambda timeout in VPC

I enabled VPC thinking it improves security. It did — by killing internet access.
Then I learned why NAT Gateway matters for outbound, and why CloudWatch logs don’t magically appear without proper routes.

CodePipeline deploy failures

This is where IAM introduced itself personally.
Missing s3:GetObject, missing deploy permissions, missing log creation access — each retry taught me how to write minimal, correct IAM policies instead of admin-access panic mode.

Minute errors that cost maximum time

One missing slash in health check path
One port mismatch between ALB and container
One wrong IAM action
One region mismatch in a CLI command

These tiny things didn’t just teach AWS — they taught me patience, precision, and why real engineers obsess over logs instead of hype.

How I handled working with multiple services together

I didn’t learn AWS by reading 100 blogs. I learned by:

Building something small
Watching it fail in a confusing new way
Reading AWS docs like a detective
Digging through CloudWatch logs
Tracing requests in X-Ray
Fixing, redeploying, verifying
Breaking again on purpose to understand it better
Writing about it publicly so someone else can suffer less than me
That loop is my real AWS course.

What I wish someone told me when I started:

Certifications make you aware, projects make you capable
AWS feels easy until you open IAM or VPC
Debugging is a skill, not a side quest
The cloud rewards builders, not memorizers
Precision > ambition, logs > assumptions

You learn faster when you deploy and fail publicly than when you pass privately

Final takeaway

AWS didn’t become clear to me when I passed exams.
It became clear when I failed deployments, fixed them, and realized:

“I can build anything on AWS… as long as I expect it to break first.”

And honestly? That’s a comforting thought.

Because now, when something fails, I don’t panic.
I open CloudWatch. I open X-Ray. I open IAM.
And I start solving.

Not because I know everything,
but because I know how to figure it out.

If my errors can save someone even 30 minutes of debugging, this post has already succeeded.

Certifications gave me the map.
Projects taught me the terrain.
Failures trained me for the real world.

And I’m still learning — in public — one broken deployment at a time.

Building a Serverless AI Fitness Coach on AWS Using Bedrock (Llama 3), Lambda & CloudFront

Ashwin Venkatesan — Sat, 29 Nov 2025 08:10:05 +0000

Most fitness and calorie-tracking apps today start free… until they quietly push you into ₹400–₹600/month subscriptions.
And honestly, for something as simple as calorie estimation and basic meal suggestions, that always felt unnecessary to me.

So instead of paying for another premium plan, I decided to build my own AI-powered Fitness Coach using AWS services.

This project is fully serverless, extremely low-cost, and powered by Amazon Bedrock with the Llama 3 model.
You can enter whatever meal you had, and the app will immediately give you:

Estimated calories
Simple diet improvement tips
Balanced meal suggestions

And the best part?
The whole thing runs for less than the price of one tea per month.

In this article, I’ll walk through the entire build with screenshots — from creating the DynamoDB table, IAM role, Lambda backend, Bedrock integration, API Gateway setup, and finally hosting the UI using S3 + CloudFront.

If you're learning AWS, Bedrock, or serverless architecture, this is a great hands-on project to try.

Let’s start.

1. Creating the DynamoDB Table

I started the project by setting up the DynamoDB table that will store all the user meal history and AI responses.

In the first screenshot, you can see me in the DynamoDB → Tables → Create Table page.

Table name: fitness-coach-history
Partition key: userId (String)
Sort key: timestamp (String)

This structure lets us store multiple meal entries per user in chronological order.
Once these two fields are added, the table setup is almost done.

In the second screenshot, you can see that the table was successfully created.
No extra configurations here — just a clean table ready for Lambda to write into.

2. Creating the IAM Role for Lambda

With DynamoDB ready, I moved on to IAM to create a role that my Lambda function will use.

Photo 3 shows me inside the IAM → Roles section, clicking Create Role.

Here I selected:

Trusted entity type: AWS service
Use case: Lambda

This ensures Lambda can assume this role.

Now, I attached the AWSLambdaBasicExecutionRole policy, which allows Lambda to write logs to CloudWatch.

In the above, you can see the review screen where I named the role:
LambdaBedrockFitnessRole

Once I created the role, it was ready for adding custom permissions.

3. Adding Inline Policy for DynamoDB & Bedrock Access

Next, I needed the Lambda function to access both DynamoDB and Amazon Bedrock.
So I added an inline policy to the IAM role.

It shows the “Create Inline Policy” screen for this role.

Now, I added a JSON policy that gives:

dynamodb:PutItem
dynamodb:GetItem
dynamodb:Query
Bedrock invoke model permissions

The only part that needs to be customised is the Resource ARN, where you replace:

region → ap-south-1
account ID → your AWS account ID
table name → fitness-coach-history

Here is the policy you can copy and paste.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DynamoDBAccess",
      "Effect": "Allow",
      "Action": [
        "dynamodb:PutItem",
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:ap-south-1:YOUR-ACCOUNT-ID:table/fitness-coach-history"
    },
    {
      "Sid": "BedrockInvokeModel",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "*"
    }
  ]
}

Name your policy and review the changes.

Now we have created the policy and successfully attached it to this role.

At this point, DynamoDB and IAM setup is fully complete.

4. Creating the Lambda Function

With IAM ready, the next step was to build the Lambda function that connects everything together — DynamoDB, Bedrock, and our frontend.

Function name: FitnessCoachLambda
Runtime: Python 3.14
Execution role: the IAM role we created earlier (LambdaBedrockFitnessRole)

Everything else was left as default.
This Lambda function will become the core engine of the application.

5. Adding Environment Variables

Before writing the logic, I added two environment variables for cleaner configuration:

TABLE_NAME → fitness-coach-history
MODEL_ID → meta.llama3-8b-instruct-v1:0

These variables help keep the code neat and allow us to change model or table names without modifying the function itself.

I also grabbed the model ID directly from the Bedrock console (Llama 3 8B Instruct), and included a screenshot in the article to show exactly where to copy it from.

6. Writing the Lambda Code

The Lambda function is responsible for:

Receiving the user’s meal input
Building a prompt for Amazon Bedrock
Invoking the Llama 3 model
Storing the response in DynamoDB
Returning the AI-generated advice back to the user

Once I pasted the Python code (I'll drop the code below ), I deployed the function directly from the console.

import json
import boto3
import time
import os
from datetime import datetime

# Clients for Bedrock and DynamoDB
bedrock = boto3.client("bedrock-runtime")
dynamodb = boto3.client("dynamodb")

TABLE = os.environ["TABLE_NAME"]
MODEL_ID = os.environ["MODEL_ID"]

def lambda_handler(event, context):
    # 1) Parse HTTP request body
    body_str = event.get("body", "{}")
    try:
        body = json.loads(body_str)
    except:
        body = {}

    prompt = body.get("prompt")
    user_id = body.get("userId", "defaultUser")

    if not prompt:
        return {
            "statusCode": 400,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps({"error": "prompt required"})
        }

    # 2) Build Llama 3 prompt (instruction style)
    system_message = (
        "You are a strict but friendly fitness coach. "
        "First line MUST be: 'Estimated: ~XXX kcal' if the user describes food. "
        "Then give simple, practical advice and 2-3 improvements. "
        "If the user asks workout questions, give sets, reps, and rest time. "
        "Avoid medical claims."
    )

    llama_prompt = (
        "<|begin_of_text|>"
        "<|start_header_id|>system<|end_header_id|>\n"
        f"{system_message}\n"
        "<|start_header_id|>user<|end_header_id|>\n"
        f"{prompt}\n"
        "<|start_header_id|>assistant<|end_header_id|>\n"
    )

    request_body = {
        "prompt": llama_prompt,
        "max_gen_len": 300,
        "temperature": 0.7
    }

    # 3) Call Llama 3 on Bedrock
    response = bedrock.invoke_model(
        modelId=MODEL_ID,
        contentType="application/json",
        body=json.dumps(request_body)
    )

    payload = json.loads(response["body"].read())

    # Llama 3 Instruct returns 'generation'
    ai_output = payload.get("generation")

    if not ai_output:
        ai_output = "Model did not return output. Please try again."

    # 4) Save to DynamoDB
    timestamp = str(int(time.time()))
    date_str = datetime.utcnow().strftime("%Y-%m-%d")

    dynamodb.put_item(
        TableName=TABLE,
        Item={
            "userId": {"S": user_id},
            "timestamp": {"S": timestamp},
            "prompt": {"S": prompt},
            "response": {"S": ai_output},
            "date": {"S": date_str}
        }
    )

    # 5) Return JSON response
    return {
        "statusCode": 200,
        "headers": {
            "Access-Control-Allow-Origin": "*",
            "Content-Type": "application/json"
        },
        "body": json.dumps({"fitness_coach_reply": ai_output})
    }

7. Testing the Lambda Function

After deploying the code, I ran a simple test event to make sure everything was working properly.

The test returned:

HTTP 200 OK
AI-generated calorie estimation
Meal suggestions
No errors in CloudWatch logs

This confirmed that Bedrock access, DynamoDB writes, and the Lambda logic were all functioning end-to-end.

8. Verifying the Database Entry

Next, I switched to DynamoDB to make sure the data was actually being logged.

Inside the “Explore items” section, I found new entries created by the test:

userId
timestamp
prompt
AI response

This validated that the Lambda-to-DynamoDB integration was correct.

9. Creating the API Gateway Endpoint

With Lambda working perfectly, the next step was to make it accessible from the frontend

I used HTTP API (not REST API) since it's faster and cheaper.

Inside the API Gateway console:

Created a new HTTP API
Selected Lambda as the integration type
Chose the region and selected my Lambda function

This is the simplest and most efficient way to build a lightweight serverless API endpoint.

10. Configuring the Route

Once the integration was connected, I defined a route:

Method: POST
Path: /ask
Integration target: our Lambda function (FitnessCoachLambda)

This route will be used by the HTML frontend to send the meal details and receive AI-generated feedback.

11. Deploying the API

After reviewing all the configurations, I created the API.

The moment the API was deployed, API Gateway generated an Invoke URL — this URL is what the JavaScript inside the frontend will call whenever a user enters their meal.

This completed the entire backend:
DynamoDB → IAM → Lambda → Bedrock → API Gateway.

12. Testing the API with Postman

After deploying the API, the next step was validating whether the endpoint works outside Lambda.

I tested it using Postman:

Selected POST method
Pasted the Invoke URL from API Gateway
Added a JSON body such as:

{
  "prompt": "Give me a push pull workout plan",
  "userId": "ashwin"
}

Added a header: Content-Type: application/json

Once executed, Postman returned a 200 OK along with the AI-generated workout plan.
This confirmed that API Gateway → Lambda → Bedrock flow was working fully end-to-end.

13. Enabling CORS on API Gateway

To allow the frontend to call the API successfully, I enabled CORS.

The configuration included:

Access-Control-Allow-Origin → *
Access-Control-Allow-Headers → content-type
Access-Control-Allow-Methods → POST

This ensures the browser doesn’t block requests when the HTML file tries to call the API.

14. Creating the S3 Bucket for the Frontend UI

With the backend ready, I moved on to hosting the user interface.

Bucket name: ai-fitness-coach-2025-ui
Bucket type: General Purpose
Standard settings for ACL and ownership

This bucket will store the index.html file that users interact with.

15. Uploading the Frontend File

Inside the bucket, I uploaded the index.html file.
This file contains the entire UI along with the JavaScript that calls the backend API.

Once uploaded, it immediately appeared in the object list of the bucket.

16. Enabling Static Website Hosting

Next, I enabled Static Website Hosting in the Properties tab.

This option turns the S3 bucket into a simple website server.
After enabling, AWS provided a bucket website endpoint, which looks like:

http://ai-fitness-coach-2025-ui.s3-website.ap-south-1.amazonaws.com

Opening this URL displayed the HTML UI exactly as expected.

17. Adding the Bucket Policy

To make the website accessible publicly, I added a bucket policy allowing read access to all objects:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::ai-fitness-coach-2025-ui/*"
    }
  ]
}

Once the policy was applied, the UI became reachable for anyone using the S3 website endpoint.

18. Testing the UI

At this point, the static website was fully accessible.
Opening the S3 endpoint displayed the UI where users can enter their meals and send the request to the backend API.

The UI was functional, but to optimize performance and reduce latency worldwide, I integrated CloudFront next.

19. Creating the CloudFront Distribution

The final step in the frontend setup was creating a CloudFront distribution.

During the setup:

I selected S3 static website endpoint as the origin.
Kept all recommended/default settings, since CloudFront already optimizes caching, TTLs, and routing for S3 origins.
No custom behaviors or policies were required for this project.

This simple configuration is enough to get a production-quality CDN in front of the static UI.

21. Reviewing and Deploying the Distribution

The review page showed the full configuration — S3 origin, default cache behavior, protocol settings, and standard CloudFront defaults.

Everything looked good, so I created the distribution.

After a few minutes, CloudFront assigned a global CDN URL, something like:

https://dxxxxxxxxxxx.cloudfront.net/

22. Accessing the UI Through CloudFront

Once the distribution finished deploying, I opened the CloudFront URL — and the UI loaded instantly.

The HTML page, JavaScript, and API integration all worked exactly as expected.
Submitting a meal entry triggered the Lambda function, which invoked Amazon Bedrock, stored the result in DynamoDB, and returned the AI-generated feedback right on the UI.

This completed the full serverless pipeline:

Frontend: CloudFront + S3
Backend: API Gateway + Lambda
AI: Amazon Bedrock (Llama 3)
Database: DynamoDB

Everything was running smoothly, globally accessible, and extremely cost-efficient.

⭐ Conclusion

This project started with a simple idea — build a personal AI Fitness Coach without paying monthly subscription fees.
By combining AWS serverless services with Amazon Bedrock, it turned into a fully working end-to-end application that:

estimates calories
gives personalised meal suggestions
stores user history
serves a fast UI through CloudFront
runs at a fraction of traditional app costs

The best part is that the entire architecture is scalable, low-maintenance, and suitable for real production workloads with very minimal cost.
If you’re learning AWS, this project is a great hands-on example of integrating multiple cloud services into a single workflow.

I’ve included the full source code and steps so you can try it yourself or build on top of it.

⭐ GitHub Repository

Full code, Lambda function, HTML UI, architecture details, and deployment notes are available here:

👉 https://github.com/Imash24/aws-ai-nutrition-coach

Deploying A Flask App on AWS ECS with Real-time CloudWatch Monitoring

Ashwin Venkatesan — Tue, 07 Oct 2025 14:35:16 +0000

🚀 Want to see your Flask app live on AWS ECS within 15 minutes — with real-time monitoring dashboards? 🔥

In this walkthrough, we’ll take a Dockerized Flask application (already uploaded to Amazon ECR/ you can also upload to Dockerhub) and deploy it on AWS ECS (Fargate).

Once deployed, we’ll integrate Amazon CloudWatch to monitor key metrics like CPU and memory utilization, and even visualize them through a custom CloudWatch Dashboard.

By the end of this tutorial, you’ll have a fully managed, scalable, and monitored Flask app running seamlessly on AWS.

⚙️ Tech Stack & AWS Services Used

Before we dive in, here’s a quick look at the tools and services powering this project:

Flask – Python-based lightweight web framework for the application.
Docker – To containerize the Flask app.
Amazon ECR (Elastic Container Registry) – To store and manage Docker images.
Amazon ECS (Elastic Container Service) – To deploy and run the containerized Flask app.
AWS Fargate – Serverless compute engine for running containers without managing EC2 instances.
Amazon CloudWatch – To collect metrics, monitor container performance, and visualize data using dashboards.

Let's Get Started:

Step 1:Create an ECS Cluster:
1.Navigate to Aws ECS on AWS Console

2.Now we need to create Cluster.

Give your Cluster a name – in my case I'm naming ECS-FLASK-APP-Cluster
We dont need to touch other settings Leave as default and click Create.
Wait for few minutes until our cluster gets created. And after few minutes you will see an success message.

Step 2: Create a Task Definition
Now our Cluster is ready. We need to create a Task Definition
-- it is basically a blueprint which tells ECS which container to run, how much memory and CPU to allocate and what kind of networking to use.

In the ECS Console, go to Task Defintions --> Click Create new Task definition

Give a name for the task definition family.
Next, choose the Launch type as Fargate(it is serverless compute engine for containers, as we need not to Manage the servers ourselves).
Under the Container section, click Add container
Enter the name for your container.
In the Image URI field, paste the image URL from your Amazon ECR repository(you can also use external container repositories like DockerHub, I'm going with ECR).
Select the port 5000 as our Flask app is exposed on port 5000.
Allocate the required CPU/memory based on your app needs (I'm going with 512M CPU and 1GB memory).
Click Add, Then wait for few Minutes and save your Task defintion.

STEP 3: Create an ECS Service
Now our Task Definition is ready, it's time to create a Service This tells how many copies of your app (tasks) of our container to run and keeps them running if other containers fail.

Go to your ECS Cluster --> click Create Service
Select your Task Definition and Revision (the one you created in the previous step).
Give the service a name.

Under the Launch type, choose Fargate.

Under Networking, choose your VPC and subnets, and enable Auto-assign public IP if you want to access the app publicly.
Create a Security Group and allow port*Port 5000* inbound, Which is very important.
Review all configurations, then Click Create Service.

Wait for a few moments, and you will have the service created.

🌐 Step 4: Access the Flask App

Once the service is up and running, ECS automatically launches your container on AWS Fargate.

Now it’s time to verify that your Flask app is live.
In your ECS Cluster, go to the Tasks tab under your service.
You’ll see one or more running tasks — click on the Task ID.
Scroll down to the **Networking **section.
Under Network bindings, you’ll find the public IP address assigned to your running container.

Copy that IP and open it in your browser

🎉 Congratulations — Your Flask App is Live!
Awesome work! Your Flask application is now successfully deployed on AWS ECS using Fargate 🙌

Now that your app is live, let’s move to the next part — monitoring and observability.

Step 5: Create a CloudWatch Dashboard
To monitor your Flask app’s performance in real-time, we’ll start by creating a CloudWatch Dashboard. This dashboard will give you a single view of all the important metrics for your ECS service and container.

Go to the Amazon CloudWatch Console → click Dashboards → Create dashboard.
Give your dashboard a name (Ecs-flask-dashboard).

Choose a widget type (like Line, Stacked Area, or Number) depending on what metric you want to display.
Click Add widget and select the ECS / Fargate metrics you want to track — for example:

CPU Utilization
Memory Utilization

After the required settings and customizing Save the dashboard.
Here you can see the dashboard we have created; wait for a few minutes, and you can see the line flow as per the metrics.

💻 Full Project Code

You can access the complete flask ECS project here:
GitHub Link: https://github.com/Imash24/ECS-FLASK-APP

✅ Conclusion

Congrats! You’ve successfully deployed a Flask application on AWS ECS using Fargate, and set up a CloudWatch dashboard to monitor its performance in real-time.

In this walkthrough, you learned how to:

Use ECS Fargate to run containerized applications without managing servers.
Deploy a Dockerized Flask app from ECR.
Set up an ECS Service to keep your app running and scalable.
Monitor key metrics like CPU, memory, and network traffic using CloudWatch Dashboards.

This project gives you a hands-on understanding of containerized deployments on AWS, and is a solid step toward mastering DevOps and cloud-native applications.

AWS CI/CD Made Easy: Build, Deploy, Repeat.

Ashwin Venkatesan — Mon, 08 Sep 2025 09:01:07 +0000

🚀 Tired of deploying your app manually every time you push code to GitHub?
What if I told you that with just a few clicks, you can automate the entire process — from a GitHub commit to your app running live on an EC2 instance.

In this tutorial, I’ll walk you through how AWS Developer Tools — CodeBuild, CodeDeploy, and CodePipeline — work together to create a seamless deployment pipeline. No more manual SSH into EC2, no more missed steps — just commit, build, deploy, repeat.

🔧Prerequisites
Before we jump into AWS, here’s what you’ll need:

Source Control: GitHub (you can also use CodeCommit, but here we’ll stick with GitHub).
Compute: EC2 instance.
CI/CD Tools: CodePipeline, CodeBuild, CodeDeploy.
IAM Roles: We’ll create service roles for CodePipeline, CodeBuild, and CodeDeploy, and instance profile for EC2.
Sample Application: This works with any stack — Node.js, Python, Java, or even a static website.
👉 If you don’t have one, feel free to fork my GitHub repo and use that as your sample app.
Link to my Github repo: https://github.com/Imash24/AWS-CI-CD-DEMO

Step 1: Create an EC2 Instance:

Go to the EC2 Console → Launch a new instance.
Pick Amazon Linux 2 (free-tier eligible).
Create/attach a security group that allows:
Port 22 (SSH) → so you can connect to it.
Port 3000 (or whatever port your app runs on) → so you can actually access your app in the browser.

Once your Instance is up, you can use ssh to connect to your Instance or easiest way is to use EC2 Instance Connect.

After Connecting to your Console , We need to install the node.js as well the Codedeploy agent.

👉 But wait, what’s this CodeDeploy Agent thing?
Think of it as a messenger that lives inside your EC2 instance. When AWS CodeDeploy pushes a deployment, the agent is the one that:

Listens for instructions from the CodeDeploy service.
Pulls the application files (artifacts) from S3 or GitHub.
Runs the scripts you define in appspec.yml (like install dependencies, restart the app, etc.).

Without the agent, your EC2 has no idea that CodeDeploy even exists — so it’s a must-have.

Now Lets install the Node.js and CodeDeploy agent.

# Update packages
sudo yum update -y  

# Install Node.js and npm
sudo yum install -y nodejs npm  

# Install CodeDeploy Agent
sudo yum install -y ruby wget
cd /home/ec2-user
wget https://aws-codedeploy-<your-region>.s3.<your-region>.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
sudo service codedeploy-agent start

Make sure to replace {your-region} to match your region, in my case it is ap-south-1.

✅ Verify the CodeDeploy Agent

Now that we’ve installed the CodeDeploy agent, let’s make sure it’s actually running.

Run this command:

sudo systemctl status codedeploy-agent.service

Step 2: Setting up CodeDeploy Application

Now We have created an Ec2 instance and also setup the CodeDeploy agent on EC2, Lets set up the CodeDeploy Application.

A CodeDeploy Application = just a container that represents your app in AWS.

1️⃣ Create a CodeDeploy Application

Go to the AWS CodeDeploy Console → Applications → Create application.
Give it a name (e.g., cicd-demo-app).
Choose Compute platform → EC2/On-premises.

2️⃣ Create a Deployment Group:

Inside your application, click Create deployment group.

Give it a name (e.g., cicd-app-deployment-grp).

Service role:
You’ll need a service role for CodeDeploy (something like CodeDeployServiceRole).

Attach the managed policy: AWSCodeDeployRole.
This allows CodeDeploy to talk to your EC2.

Lets Create an Service role for CodeDeploy,

Go to the IAM Console → Roles → Create role.
For Trusted entity type, choose AWS service.
For Use case, select CodeDeploy → CodeDeploy.
Click Next and attach the managed policy:
AWSCodeDeployRole (this gives CodeDeploy the permissions it needs).
Give the role a name (e.g., CodeDeployServiceRole).
Click Create role.

Environment configuration:

Choose Amazon EC2 instances.
Pick your EC2 using Tags, My case i tagged as server.

Deployment settings:
Choose “One at a time” for simplicity (safe deployment).
Once done, CodeDeploy knows:
👉 “This application gets deployed to this EC2 instance with these rules.”

Step 3: Create a CodeBuild Project:
Now We Created and also setup the CodeDeploy that actually knows where to deploy our application (EC2).

1️⃣ Go to CodeBuild Console

Click Create build project.
Give it a name (e.g., cicd-demo-build).

2️⃣ Configure Source
Source provider: GitHub (connect your repo or forked repo). Or simply you can select the public repository option and paste my GitHub repository. link.

3️⃣ Environment

Environment image: Managed image.
Operating system: Amazon Linux 2.
Runtime: Standard.
Service role: Create a new role (CodeBuild will do this automatically).

4️⃣ Buildspec

The buildspec.yml file gives main instructions to ** CodeBuild.** It tells AWS exactly how to build your application — whether that’s installing dependencies, running tests, or packaging files.

I’ve already pushed my own buildspec.yml file into my GitHub repo, so CodeBuild will automatically pick it up during the build stage.

👉 In short, this file is where we define:

How to install dependencies
How to run build/test steps
What files should be bundled as artifacts for deployment

✅ CodeBuild Completed Successfully!
We’ve set up and completed our CodeBuild project, and our application can now be built automatically using the instructions we defined in the buildspec.yml file. (The YAML handles dependency installation, build, and artifact creation).

The next logical step is to orchestrate the entire CI/CD flow — and that’s exactly where AWS CodePipeline comes in.

🚀 What is CodePipeline?

AWS CodePipeline is a fully managed CI/CD orchestration service that automates the software release process. It connects different stages of delivery — Source → Build → Test → Deploy — into a single continuous pipeline.

With CodePipeline, every time you push code to your repository:
The pipeline automatically detects the change (via webhook or polling).
It triggers CodeBuild to build and test the application.
Once artifacts are ready, it hands them over to CodeDeploy (or another deploy service).
The application is deployed to the target environment (EC2, ECS, Lambda, etc.).

1️⃣ Go to CodePipeline in AWS Console
Open the AWS Management Console → Search for CodePipeline → Click Create pipeline and select Build a custom pipeline.

2️⃣ Pipeline Settings

Pipeline name → cicd-demo-pipeline (you can name it anything you want).
Service role → Select “New service role” (AWS will automatically create a role for CodePipeline with the right trust relationships).
Leave advanced settings as default → Click Next.

3️⃣Add Source Stage

This is where our code comes from (GitHub in this case).

Source provider → GitHub (v2).
Connect to GitHub → Authorize your GitHub account with AWS.
Repository → Select your repo.
Branch → main (or whatever branch you want to deploy).
Change detection → Leave as default (CodePipeline uses webhooks to detect new commits).
Click Next.

4️⃣ Add Build Stage

Now we connect the CodeBuild project we created earlier.
Build provider → AWS CodeBuild.
Project name → Select the project you just created.
Click Next.

5️⃣ Add Deploy Stage

This is where the built artifacts are deployed to your EC2 instance using CodeDeploy.

Deploy provider → AWS CodeDeploy.
Application name → Choose the CodeDeploy application you created.
Deployment group → Select the deployment group.
Click Next.

6️⃣ Review & Create

Double-check everything → Click Create pipeline.
AWS will immediately trigger the pipeline for the first time.
You’ll see stages: Source → Build → Deploy with live status updates.

🚨 Something Failed !!! Dont panic expected one😂
This is expected if your EC2 instance doesn’t yet have the correct IAM Instance Profile attached.

Why does this happen?
Because the CodeDeploy agent running inside your EC2 needs permissions to talk to CodeDeploy and pull artifacts from S3. Without that IAM role attached, the agent has no credentials → so the deployment fails.

👉 Fix: Go to your EC2 instance → attach an IAM role (Instance Profile) with permissions like AmazonS3ReadOnlyAccess and AWSCodeDeployRole. Once added, rerun the deployment and it should succeed.

We have attached AmazonS3ReadonlyAccess and AWSCodeDeployRole.

✅ And there we go — Success! 🎉
After attaching the correct IAM Instance Profile to our EC2 and rerunning the pipeline, everything works smoothly.

Source Stage → grabbed the code from GitHub
Build Stage → CodeBuild installed dependencies and packaged the app
Deploy Stage → CodeDeploy agent pulled the artifact and deployed it to EC2.

🌐 Accessing Our Application

Now that our pipeline has successfully deployed, let’s confirm everything is working.

I opened my EC2 public IP in the browser at port 3000 — and boom, our Node.js application is up and running! 🚀
The best part? I didn’t have to SSH into the server or manually copy files. The whole thing was automated through CodePipeline → CodeBuild → CodeDeploy.

👉 Next, let’s test the real magic of CI/CD: we’ll make a small manual change in GitHub, push the code, and watch the pipeline automatically pick it up and deploy Version 2 to EC2.

After making a small change in my code, I pushed it to the main branch on GitHub.

Within seconds, CodePipeline detected the update, automatically triggered a new run, and started executing the stages again — Source → Build → Deploy.

🌟 Version 2 Deployed Successfully

After the pipeline finished its run, I opened the application in the browser again at port 3000, and the changes from Version 2 were live!

This proves that our CI/CD pipeline is fully functional: every time you push a commit to GitHub, CodePipeline detects it, CodeBuild packages it, and CodeDeploy deploys it — all automatically. No manual intervention, no missed steps.

✅ Conclusion / Key Takeaways

Automation is powerful: Once set up, your pipeline handles every commit, build, and deployment.

CodePipeline = orchestrator: It connects Source → Build → Deploy seamlessly.
CodeBuild = builder: Packages and prepares your app artifacts.
CodeDeploy = delivery agent: Pushes the code to EC2 instances and runs lifecycle scripts.
IAM Roles Matter: Both the CodeDeploy service role and EC2 instance profile are critical for permissions.

Serverless Cost Tracker – Stay Alert. Stay Efficient.

Ashwin Venkatesan — Sat, 02 Aug 2025 18:30:04 +0000

One Lambda function. Logs AWS cost logs daily and gives instant alerts. With Beautiful Dashboards.
This is Serverless Cost Intelligence —a project I built from scratch using Serverless AWS tools to automate cost tracking like never before.

Alright, enough with the theory; let's build this intelligence system from scratch. Even a beginner can follow these instructions. I have attached screenshots for everything we are going to build.

🚀 Tech Stack & AWS Services Used
Before we dive into the steps, here’s a quick summary of the core AWS services and tools we are using for this project:

AWS Lambda – For running backend logic to fetch cost data automatically
Amazon CloudWatch Logs – To log the cost data and debug if needed
AWS Cost Explorer API – To fetch cost and usage details programmatically
Amazon SNS – For optional cost alerts/notifications
Amazon S3 – For storing logs or future data exports
Amazon EventBridge – To automate the Lambda trigger on a schedule
Amazon QuickSight – For building a dashboard to visualize the cost data.

Step-1: IAM Role Setup for Lambda

To make our Lambda function communicate with the Cost Explorer Service, we need to define an IAM Role with appropriate permissions. For that, we'll create an IAM role with an inline policy attached to that role.

Go to the AWS Console and type IAM and select the IAM Service from the UI.
Now select the Create role.
On the Next page, for the use case, select the lambda in the dropdown.
Now let's create a Role name, name anything but make it more descriptive, and click next, review the changes, and create the role.

We have now created the Role, but wait, we haven't attached any policy. Now go to the Permissions tab and click Add inline policy.
Switch to the JSON tab and paste the following policy

Here is the Policy. You can copy it.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ce:GetCostAndUsage",
        "s3:PutObject",
        "s3:PutObjectAcl",
        "sns:Publish"
      ],
      "Resource": "*"
    }
  ]
}

Now, name the Policy and click Create Policy.

✅ Step-1: Completed the IAM Role Setup

In Step 1, we created a dedicated IAM Role and attached a custom inline policy with all the necessary permissions. This role allows our Lambda function to:

Access AWS Cost Explorer to fetch cost data
Write data to S3 for storing cost reports
Publish messages to SNS Topics for alerts or notifications

Step 2: Creating an S3 Bucket to Store our Cost Data.

We'll set up an S3 Bucket that our Lambda function uses to save the AWS Cost Data in CSV Format. Let's Create the Bucket, Navigate to the AWS Console, and Search for S3.

Click The Create Bucket.
Just name the bucket, and leave all the other settings as default.
Click next, review the bucket settings, click Create bucket, and wait for the bucket to get created.

✅ Step 2 Complete – S3 Bucket Creation

In this step, we created a dedicated S3 bucket where our Lambda function can securely store the daily cost reports fetched from AWS.

This bucket is the central storage for our cost logs and data.

Step-3: Setting Up SNS for Email Alerts

Now, we are setting up Amazon SNS(Simple Notification Service) to send cost alerts directly to our email inbox.
Go to the Amazon Console and Search for SNS and Click.
Now we have to create a TopicName. Name your topic and click next step.
Choose the Type as Standard, and create the Topic.
After that, we need to create a Subscription.
Here you need to select the SNS topic we have created previously and select the protocol as Email, Then Enter your Email and click Create the Subscription.
One Thing, you will receive the confirmation mail in your inbox, click to verify, and you have completed this Step.

✅ Step 3 Complete – SNS Topic + Subscription Setup

We have created an SNS topic and added an email subscription — this is the system that will notify us as soon as the AWS costs exceed our Budget.

🚀 Step 4: Lambda Function Setup

In Step 4, we’ll create the actual Lambda function with Custom Logic that fetches cost data from AWS Cost Explorer, stores the data in S3, and then notifies us via the SNS Service. We'll also attach the IAM role we created before so Lambda has the right permissions to do communicate with other services.

Go to the AWS Console and Search for Lambda and click.
Here, select the Author from scratch, and name your function. Select the runtime as python:3.13
Below, select the existing role we have created in our Step-1 and attach it to our lambda function.
Now, click Next, review the changes, and click Create Function and wait for the function to get created.
Let's start writing our function logic. I will be uploading the Code snippet here.

import boto3
import json
import datetime
import csv
import os

# Replace with your values
SNS_TOPIC_ARN = "arn:aws:sns:ap-south-1:123456789012:aws-cost-alerts"
S3_BUCKET = "smart-cost-tracker-logs"

def lambda_handler(event, context):
    today = datetime.date.today()
    start = (today - datetime.timedelta(days=2)).strftime('%Y-%m-%d')
    end = (today - datetime.timedelta(days=1)).strftime('%Y-%m-%d')

    client = boto3.client('ce')
    response = client.get_cost_and_usage(
        TimePeriod={'Start': start, 'End': end},
        Granularity='DAILY',
        Metrics=['UnblendedCost'],
        GroupBy=[{'Type': 'DIMENSION', 'Key': 'SERVICE'}]
    )

    services = response['ResultsByTime'][0]['Groups']

    # CSV content
    csv_lines = [["Service", "Cost (USD)"]]
    alert_lines = []
    total_cost = 0

    for service in services:
        name = service['Keys'][0]
        amount = float(service['Metrics']['UnblendedCost']['Amount'])
        total_cost += amount
        csv_lines.append([name, f"{amount:.4f}"])
        if amount > 1:  # Alert threshold (₹80+)
            alert_lines.append(f"{name}: ${amount:.2f}")

    # Save to S3
    file_name = f"daily-cost-{start}.csv"
    local_file_path = f"/tmp/{file_name}"

    with open(local_file_path, 'w', newline='') as file:
        writer = csv.writer(file)
        writer.writerows(csv_lines)

    s3 = boto3.client('s3')
    s3.upload_file(local_file_path, S3_BUCKET, file_name)

    # Send Alert if above threshold
    if total_cost > 5:  # Total > ₹400
        sns = boto3.client('sns')
        msg = f"AWS Daily Cost Alert - {start}\n\nTotal: ${total_cost:.2f}\n\n" + "\n".join(alert_lines)
        sns.publish(TopicArn=SNS_TOPIC_ARN, Subject="AWS Daily Cost Alert 🚨", Message=msg)

    return {
        'statusCode': 200,
        'body': json.dumps('Cost fetched and logged successfully!')
    }

Basically, this is How the Code Works:)
📅 It fetches daily AWS cost data from the Cost Explorer.
📂 Converts it into a CSV file and stores it in S3.
💸 Checks for services costing more than $1 and prepares an alert.
📬 If the total cost exceeds $5, it sends a notification via SNS to your email.

⚠️NOTE

Replace your SNS Topic ARN and S3 Bucket name at the top of the Code.
Another Quick thing to do, to make our function run faster, we are changing the Memory limit and Execution Time of our Lambda function.

Here is the Screenshot for your reference.

✅ Step 4 Complete – Lambda Function Ready!

Awesome🎉, We have successfully created our Lambda function, attached the necessary IAM role, and plugged in the logic that:

Fetches AWS cost data
Stores it safely in S3
Sends alerts if the cost crosses the limit

Your smart cost tracker is now fully functional and ready to Function Well.

Step-5: Setting up a CloudWatch Events Rule with a Cron expression to automate this Lambda function, so it runs every day without Manual Intervention.

Go to the AWS Management Console and Type CloudWatch Events
From here, go to Events and create a new Rule.
Now let's name the rule, and select the Rule Type to Schedule, then click Continue to Create Rule.

Let's enter the Cron,
Schedule expression: cron(0 3 * * ? *) (Runs daily at 8:30 AM IST), change as per the need, and click next.
Select the target as Lambda function, and select our created Lambda function, then click Create.
We have Successfully Created a Cron and Schedule, which
auto triggers the lambda function that fetches the AWS Costs logs and stores them in an S3 Bucket.

-Finally, let's deploy our lambda function, and test it once manually, we can see that the Status code to 200. and with a message body "Cost fetched and Logged Successfully," which means our project is 100% working well and good.

Also, let's confirm that the logs of the cost reports are stored in S3.

We can see that a cost log file has been created by the lambda function and stored in S3.

Congratulations! You’ve successfully built and tested Serverless Cost Tracker. Here's a quick recap of what we achieved so far:

✅ Created and configured The IAM Role with inline policies for S3, Cost Explorer, SNS
✅ Set up a secure S3 bucket to store cost reports
✅ Created an SNS Topic with email subscription for alerts
✅ Built and deployed a fully working Lambda Function
✅ Manually tested the function – verified a 200 OK response and confirmed the log file was stored in S3
✅ Set up CloudWatch Cron Scheduler to automate daily runs

📊 Bonus Visualization with QuickSight (Optional)

You can also integrate the S3 bucket (where our cost data is stored) with Amazon QuickSight to generate clear, beautiful cost graphs and dashboards.

I'll attach a sample screenshot to give you an idea — Which is optional, but very useful if you want a quick visual summary of daily AWS Costs and Associated Service Usage. It's even a better way to showcase the project and make it look even better.

Building a High Performace website using AWS Cloudfront + ALB + EC2

Ashwin Venkatesan — Wed, 16 Jul 2025 17:55:50 +0000

Hosting a website on EC2 is simple -- but it's not that scalable, say what if 100s of requests are flooding through your application/website. Headache, right!! In this post, we will set up a highly available and performant website using Application Load Balancer (ALB), EC2, and CloudFront for Efficient delivery.

We will go through a step-by-step process to achieve this, and I have also included real screenshots and steps so even beginners can follow along.
Final result? A public-facing website that is delivered worldwide, served through Cloudfront (CDN). Interesting, right? Let's get started. 🚀

📦Step 1: Launch an EC2 Instance

(I already set up an EC2 instance with a basic website (HTML, CSS) and served it using Nginx.)

Setup details

Installed Nginx + uploaded site files

And make sure to allow only necessary security groups for better Security reasons. In my case, on my EC2(security group), I allowed ports 22,80.

After the Basic website setup, you can see that the site can be accessed by the public IP of my EC2 Instance.

🛠️Now Comes the Real Game: Scaling It Up with ALB and CloudFront
So far, we’ve deployed a simple website using an EC2 instance. That’s a great start — but it’s not scalable, not fault-tolerant, and not production-ready.

In the next steps, I’ll take this basic setup and upgrade it to a high-performance architecture using:

✅ Application Load Balancer (ALB) to distribute traffic
✅ CloudFront to deliver content globally with low latency
✅ Tighter Security Groups to expose only what’s needed

⚖️Step 2: Configure the Application Load Balancer (ALB)

Lets setup an ALB,

Name the LoadBalancer and make it a public-facing loadbalancer, as we need to serve the traffic from users/public. Click next.
Here, select the VPC (default VPC) and also select the Availability zones and subnets. I'm selecting two subnets for higher availability (us-east1a and us-east1b). Click next.
Next step is to create the Security group for the LoadBalancer In my case, I'm creating inbound rules on ports 80,443.
After that, click the Create Target group.
Name The Target Group and in that page that's all we need for now leave all as such to Default.
Now we need to register the targets as we are using the ec2 instances select those ec2 instances and click include as pending below. That's it.
Now Select the newly created target group and press next.
Wait for few minutes before the loadbalancer gets fully set up and ready to serve the targets, That is our EC2 Instance. Once it becomes active, copy the loadbalancer's DNS name to access our website.
Voila! Now we are serving our website using a load balancer's(DNS NAME!!!), but wait we are not done yet, we need to set up an CloudFront distribution.

🌐 Step 3: Setup CloudFront

Search for CLoudfront on the aws console

We need to Create a new cloudfront distribution, name your distribution and select the single website or app.
Now Select the origin type as Elastic load balancer and choose your load balancer below.
Here in Security, if you need AWS WAF(Web application firewall) capabilities you can opt for here I'm selecting (Do not enable WAF).
Now here Review the changes we did and proceed to create our distribution.
Wait for few minutes to make the distribution to propagate fully and become active.
Important step as we going with a sample go through on setting up an HTTP site, we need to setup the protocol to HTTP only.(If you are using the Custom domain or HTTPS , SSL certs make sure to turn on to HTTPS.
After few minutes you can see the last modified to deployed our site is ready for production.

🎉 Final Step: Access Your Website via CloudFront

Now, take the CloudFront distribution domain name (something like d1234abc.cloudfront.net) and open it in your browser. You should see your deployed website loading fast, served securely through CloudFront, routed via your Application Load Balancer, and ultimately hitting your EC2 instance.

✅ Boom! You've just built and deployed a highly available, scalable, and globally optimized website using AWS infrastructure.
From a simple EC2 instance to a fully distributed setup — this is how real-world deployments scale.

🙌 What’s Next?

You can now explore:
Adding SSL using ACM
Custom domain via Route 53
Auto scaling your EC2 instances
Logging and monitoring with CloudWatch