DEV Community: Samir Khanal

Building a Serverless URL Shortener with AWS

Samir Khanal — Thu, 16 Apr 2026 05:33:35 +0000

Hey there, fellow developers and cloud enthusiasts! If you're like me, you've probably wondered how those sleek, short links on social media work behind the scenes. Today, I'm excited to dive into a project I built: a serverless URL shortener that combines DevOps automation, real-time analytics, and scalable architecture. It's not just a fun tool; it's a blueprint for modern, event-driven applications on AWS. Let's break it down step by step, from concept to deployment.

Overview

In the fast-paced world of web development, sharing links efficiently is crucial. Long URLs can be cumbersome, especially on mobile devices or character-limited platforms. Enter our serverless URL shortener: a robust system that takes any URL and generates a short, memorable code (e.g., https://mydomain.com/ABC123) that redirects users seamlessly.

Built entirely on AWS, this project showcases serverless best practices. It handles URL shortening, click tracking, analytics processing via queues, and even integrates with CI/CD pipelines for automated deployments. I designed this to demonstrate how serverless can simplify complex workflows while keeping costs low and scalability high. Think of it as a digital post office: you drop off a package (long URL), get a tracking number (short code), and the system handles delivery (redirects) with full visibility.

Goals

The primary goals were straightforward yet ambitious:

Simplicity and Scalability: Create a URL shortener that scales automatically without server management.
Analytics Insights: Track clicks and events in real-time for user behavior analysis.
DevOps Integration: Automate deployments via CI/CD, with notifications for workflow triggers.
Community Value: Provide an open-source example for AWS builders, highlighting services like Lambda, Step Functions, and SQS.

By the end, I wanted a production-ready app that could handle thousands of requests with minimal overhead—perfect for startups, marketers, or anyone needing link management.

Architecture

At its core, this is a fully serverless architecture leveraging AWS's event-driven model. Here's a high-level view:

GitLab / API Trigger
        ↓
   API Gateway
        ↓
Lambda (url-shortener)
     ↓        ↓        ↓
DynamoDB   SQS Queue   Step Functions (url_workflow)
     ↓        ↓
Analytics Lambda   Slack Notifications

API Gateway: Acts as the entry point for shortening and redirecting URLs.
Lambda Functions: Handle logic—url-shortener for CRUD operations, analytics for processing queued events.
DynamoDB: NoSQL database storing URLs, short codes, and click data.
SQS: Decouples analytics processing, ensuring reliability during traffic spikes.
Step Functions: Orchestrates workflows for notifications (e.g., Slack alerts on URL creation).
CloudWatch: Monitors logs and metrics; integrates with GitLab for CI/CD.

Development Process

Development followed an iterative, Terraform-driven approach. I started with Terraform for infrastructure as code, defining resources in main.tf. Here's a snippet of the API Gateway setup:

resource "aws_api_gateway_rest_api" "url_shortener_api" {
  name        = "${var.project_name}-url-api"
  description = "URL Shortener API"
}

resource "aws_api_gateway_method" "shorten_method" {
  rest_api_id   = aws_api_gateway_rest_api.url_shortener_api.id
  resource_id   = aws_api_gateway_resource.shorten_resource.id
  http_method   = "POST"
  authorization = "NONE"
}

Next, I wrote Lambda functions in Node.js. The url-shortener Lambda handles shortening and redirects, using DynamoDB for storage. Check out this key function:

async function shortenUrl(event) {
  const body = JSON.parse(event.body || '{}');
  const { url } = body;
  const shortCode = generateShortCode();

  await dynamo.put({
    TableName: TABLE_NAME,
    Item: { shortCode, originalUrl: url, clicks: 0 }
  }).promise();

  // Trigger Step Functions for notifications
  await stepfunctions.startExecution({
    stateMachineArn: STATE_MACHINE_ARN,
    input: JSON.stringify({ action: 'url_created', shortCode, originalUrl: url })
  }).promise();

  return { statusCode: 201, body: JSON.stringify({ shortCode, shortUrl }) };
}

Testing involved local simulations with AWS SAM or Docker, followed by deployments via GitLab pipelines. Each push triggered the DevOps workflow, sending Slack notifications and queuing messages.

Key Features

URL Shortening & Redirects: Generate codes and handle redirects with click tracking.
Real-Time Analytics: Queue events to SQS; process via Lambda for insights.
Slack Integration: Instant notifications via Step Functions (e.g., "New URL created!").
GitLab CI/CD: Automated builds and deployments with webhook triggers.
Monitoring: CloudWatch dashboards for metrics—[Screenshot 2: CloudWatch graph showing Lambda invocations].

These features make it user-friendly: Developers can integrate via APIs, while stakeholders get alerts and reports.

Challenges

Serverless isn't without hurdles. Cold starts in Lambda caused initial latency—mitigated with provisioned concurrency. SQS message visibility timeouts need tuning to avoid duplicates during high loads. Debugging Step Functions required tracing executions in the console. Security was key: I used IAM roles and environment variables to protect sensitive data like Slack webhooks.

Lessons Learned

This project reinforced serverless principles: Embrace events over servers. Use queues for decoupling to build resilient systems. Community tools like Terraform and GitLab sped up development. Sharing code snippets and docs helped others—open-source wins!

Future Plans

Next, I'll add A/B testing for short codes, integrate with Kinesis for advanced analytics, and explore multi-region deployments. If the community engages, I might add a UI dashboard. Contributions welcome—check the GitHub repo!

Conclusion

Building this URL shortener was a journey in serverless excellence, proving AWS can power scalable apps with ease. Whether you're a developer experimenting with Lambda or a stakeholder seeking efficient tools, this project shows the power of event-driven architecture. What serverless project are you tackling? Drop your thoughts in the comments—let's build together!

Github link: https://github.com/Shawmeer/aws-serverless-url-shortener

Check more blogs at: https://khanalsamir.com

Building a PostgreSQL Observability Stack with Docker, Grafana, and Prometheus

Samir Khanal — Mon, 30 Mar 2026 09:18:37 +0000

How to monitor your PostgreSQL database with metrics collection, log aggregation, and beautiful dashboards

Introduction

If you're running PostgreSQL in production, you need to know what's happening under the hood. Slow queries, lock contention, vacuum issues – these can quietly kill your application's performance. But setting up proper observability doesn't have to be complicated.
In this post, I'll show you how to build a complete PostgreSQL observability stack using Docker Compose, Grafana Alloy, Prometheus, Loki, and Grafana. All running locally, all open-source.

The Architecture

Here's what we're building:

Components:

PostgreSQL - Our database
Grafana Alloy - Collects metrics from PostgreSQL and ships logs to Loki
Prometheus - Stores time-series metrics
Loki - Log aggregation (like Prometheus, but for logs)
Grafana - Dashboards for everything

Prerequisites

You need:

Docker
Docker Compose That's it.

The Code

Let's look at the key files. First, our Docker Compose setup:

services:
postgres:
image: postgres:18.1
volumes:
- ./postgres.conf:/etc/postgresql/postgresql.conf
- ./init-exporter.sh:/docker-entrypoint-initdb.d/init-exporter.sh
environment:
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_EXPORTER_PASSWORD=${POSTGRES_EXPORTER_PASSWORD}
command: ["postgres", "-c", "config_file=/etc/postgresql/postgresql.conf"]
grafana-alloy:
image: grafana/alloy:v1.11.3
ports:
- "12345:12345"
volumes:
- "./config.alloy:/etc/alloy/config.alloy:ro"
- "./secrets/postgres_db_url.txt:/var/secrets/postgres_db_url.txt:ro"
prometheus:
image: prom/prometheus:v3.9.1
ports:
- "9090:9090"
grafana:
image: grafana/grafana:11.6
ports:
- "3000:3000"

The init script enables pg_stat_statements and creates the exporter user:

psql <<-EOSQL
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE ROLE postgres_exporter WITH LOGIN PASSWORD '$POSTGRES_EXPORTER_PASSWORD';
GRANT pg_monitor TO postgres_exporter;
GRANT SELECT ON pg_stat_statements TO postgres_exporter;
EOSQL

The Alloy configuration collects PostgreSQL metrics:

prometheus.exporter.postgres "postgres_db" {
data_source_names = [local.file.postgres_db_url.content]
enabled_collectors = [
"database",
"locks",
"stat_bgwriter",
"stat_statements", // Query performance metrics
"stat_activity_autovacuum",
"long_running_transactions",
]
}
prometheus.scrape "postgres_db" {
job_name = "postgres_db_metrics"
scrape_interval = "15s"
forward_to = [prometheus.remote_write.send_to_prometheus.receiver]
}

Getting Started

Clone the repository
Copy .env.example to .env and set your passwords
Run:

docker-compose up -d

Access Grafana at http://localhost:3000 (admin/admin) ## What Metrics Do You Get? Once running, you can query things like:

# Top 10 most called queries
topk(10, rate(pg_stat_statements_calls_total[5m]))
# Slowest queries
topk(10, rate(pg_stat_statements_total_time_seconds_total[5m]))
# Database connections over time
pg_stat_database_numbackends

You also get lock contention metrics, vacuum progress, buffer statistics - everything you need to debug performance issues.

The Dashboard

In Grafana, create a new dashboard and add panels using your PostgreSQL metrics. You'll see query performance, database statistics, and can correlate with logs from Loki.

Why This Setup?

A few reasons this works well:

Alloy instead of postgres_exporter - Grafana Alloy is newer and more modern. It handles both metrics and log collection in one agent.
pg_stat_statements - This extension is gold for understanding query performance. Enable it, and you can see exactly which queries are slowest.
Loki for logs - Instead of grepping through files, you get structured logs in Grafana that you can filter and query.
Everything in Docker - No system packages to install. Spin it up, tear it down, reproduce issues. ## What's Next? This is a practice project, so here's where you could extend it:
Add alerts for slow queries or long-running transactions
Set up retention policies in Prometheus
Add more PostgreSQL exporters for connection pooling metrics
Deploy to Kubernetes with proper secrets management ## Conclusion Observability doesn't have to be complex. With Docker and open-source tools, you can have a production-grade monitoring setup running locally in minutes. The code is on GitHub - clone it, play with it, break it. That's the best way to learn. - -

GitHub link: https://github.com/Shawmeer/postgres-observability-stack

Check more blogs at: https://khanalsamir.com

Have questions or ran into issues? Drop a comment below.

Deploying a Production-Ready React App on AWS using Terraform Module, S3, CloudFront & GitHub Actions

Samir Khanal — Sun, 22 Mar 2026 17:24:10 +0000

Modern frontend apps need fast, scalable, and cost-efficient hosting.
While AWS S3 is great for static hosting, making it production-ready
requires CloudFront, proper security, and automation.

In this blog, I’ll show how I built a fully automated pipeline.
to deploy a React app using Terraform and GitHub Actions.

📌 Architecture Overview

Here’s what we’re building:

React app → built into static files
Terraform provisions:
- S3 bucket (hosting)
- CloudFront distribution (CDN)
GitHub Actions:
- Build React app
- Upload to S3
- Invalidate CloudFront cache

📁 Project Structure

⚙️ Step 1: Terraform Module Design

Instead of writing everything in one file, I used modular Terraform.

Example modules:

🔗 How Modules Are Used (Root Configuration)

This snippet shows how the root module calls the S3 and CloudFront
modules to provision infrastructure.

module "s3_static_site" {
  source      = "./modules/s3-static-site"
  bucket_name = var.bucket_name
}

module "cloudfront" {
  source             = "./modules/cloudfront-distribution"
  bucket_domain_name = module.s3_static_site.bucket_domain_name
}

📦 S3 Module (Static Hosting)

This module creates and configures the S3 bucket for static hosting.

Bucket Creation
This snippet creates the S3 bucket that will host the React static site.

resource "aws_s3_bucket" "skr_bucket" {
  bucket = var.bucket_name
}

Website Configuration
This snippet configures the S3 bucket for static website hosting and sets the index document.

resource "aws_s3_bucket_website_configuration" "skr_bucket" {
  bucket = aws_s3_bucket.skr_bucket.id

  index_document {
    suffix = "index.html"
  }
}

Bucket Policy (for CloudFront)
This snippet sets a bucket policy allowing CloudFront (and other services if needed) to read objects from the S3 bucket.

resource "aws_s3_bucket_policy" "allow_cloudfront" {
  bucket = aws_s3_bucket.skr_bucket.id

  policy = jsonencode({
    Statement = [{
      Effect = "Allow"
      Principal = "*"
      Action = "s3:GetObject"
      Resource = "${aws_s3_bucket.skr_bucket.arn}/*"
    }]
  })
}

🌍 CloudFront Module

This module sets up a CDN in front of S3.

Distribution
This snippet creates the CloudFront distribution that serves your S3 bucket globally with HTTPS support.

resource "aws_cloudfront_distribution" "cdn" {
  enabled             = true
  default_root_object = "index.html"
}

React Routing Fix (IMPORTANT)
This snippet ensures single-page React routes return index.html instead of 404 errors.

custom_error_response {
  error_code         = 404
  response_code      = 200
  response_page_path = "/index.html"
}

Cache Invalidation
This snippet invalidates the CloudFront cache automatically after deployment, so new changes appear immediately.

resource "null_resource" "cache" {
  provisioner "local-exec" {
    command = "aws cloudfront create-invalidation --distribution-id ${aws_cloudfront_distribution.cdn.id} --paths '/*'"
  }
}

This Terraform module-based architecture makes it easy to reuse infrastructure across multiple environments like dev, staging, and production.

Benefits:

Reusable
Clean architecture
Easier debugging
Production-ready structure

☁️ Step 2: S3 Static Website Hosting

The S3 module:

Creates a bucket
Enables static hosting
Configures public access (Via OAC)

Key features:

Versioning enabled
Proper bucket policy
Index + error documents

🌍 Step 3: CloudFront CDN Setup

CloudFront sits in front of S3 to:

Improve performance (low latency)
Add HTTPS support
Cache content globally

Configuration highlights:

Origin: S3 bucket
Viewer protocol: Redirect HTTP → HTTPS
Cache behavior optimized for static assets

⚡ Step 4: GitHub Actions CI/CD

This is where things get powerful.

Workflow does:

Install dependencies
Build React app
Sync build folder to S3
Invalidate CloudFront cache

Result:

Every push to main → automatic deployment 🚀

🔄 CI/CD Workflow Example

name: Deploy to CloudFront

on:
  push:
    branches:
      - main
  workflow_dispatch:

env:
  AWS_REGION: ap-south-1
  S3_BUCKET: samir-module-s3-bucket-hosting

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
          cache-dependency-path: static-site-react/package-lock.json

      - name: Install dependencies
        working-directory: ./static-site-react
        run: npm ci

      - name: Build React app
        working-directory: ./static-site-react
        run: npm run build

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Upload to S3
        run: |
          aws s3 sync ./static-site-react/dist/ s3://${{ env.S3_BUCKET }} --delete

      - name: Get CloudFront distribution ID
        id: cloudfront
        run: |
          DISTRIBUTION_ID=$(aws cloudfront list-distributions --query "DistributionList.Items[?Origins.Items[0].DomainName=='${{ env.S3_BUCKET }}.s3.${{ env.AWS_REGION }}.amazonaws.com'].Id" --output text)
          echo "distribution_id=$DISTRIBUTION_ID" >> $GITHUB_OUTPUT

      - name: Invalidate CloudFront cache
        run: |
          aws cloudfront create-invalidation --distribution-id ${{ steps.cloudfront.outputs.distribution_id }} --paths "/*"

      - name: Deploy success message
        run: |
          echo "✅ Deployment completed successfully!"

Why Use Terraform Modules?

Without modules:

Messy code
Hard to reuse
Difficult scaling

With modules:

Clean separation
Reusable across projects
Easier team collaboration

📊 Key Advantages of This Setup

✅ Fully automated deployments
✅ Global CDN performance
✅ Infrastructure as Code (IaC)
✅ Scalable & production-ready
✅ Low cost (S3 + CloudFront)

How to Run This Project

Initialize Terraform

terraform init

Apply Infrastructure

terraform apply -auto-approve

Deploy React App

Push code to GitHub → CI/CD handles the rest

🔐 Best Practices

Use IAM roles instead of access keys
Store secrets in GitHub Secrets
Enable CloudFront caching strategies

💡 Improvements You Can Add

Custom domain with Route 53
HTTPS with ACM
WAF for security
Multi-environment Terraform setup

🏁 Conclusion

This project demonstrates how to build a modern frontend deployment pipeline using:

Terraform Modules
AWS S3 + CloudFront
GitHub Actions

🔗 Final Output

After deployment, your app will be available via:

👉 CloudFront URL (fast, secure, global)

📂 Explore the Code

The full project with Terraform modules, S3, CloudFront setup, and GitHub Actions workflow is available here:

Check it out on GitHub

🚀 With this setup, you now have a fully automated, scalable, and production-ready React deployment pipeline. Start building modern frontends with confidence!Happy Building!!

Connect with me

• Portfolio: https://khanalsamir.com

• GitHub: https://github.com/Shawmeer

• LinkedIn: https://linkedin.com/in/samir-khanal

If you're working on similar DevOps or AWS projects, feel free to connect. I regularly share practical cloud and CI/CD content.

AWS App Runner: Deploy Containerized Apps Without the Infrastructure Headache

Samir Khanal — Tue, 30 Dec 2025 15:24:51 +0000

Deploying a web application into the AWS platform should not require mastering in cloud architecture. However, it is hard considering how many different aspects of AWS's VPCs, Load Balancers, Security Groups, and the like that need to be dealt with to create just one simple containerized application, none of which impact the actual code behind the application.

AWS App Runner has addressed this by offering developers a simple way to deploy their containerized Web Applications without dealing with any underlying infrastructure services for the deployment of the Web Application.

What is AWS App Runner?

App Runner by AWS offers a complete management solution for hosting and deploying web applications in containers hosted by AWS (Amazon Web Services). Point App Runner toward an image stored in Amazon ECR or source code on GitHub; App Runner will automatically deploy your application, scale your application, balance the load across multiple copies of your application, and serve your web application over HTTPS.
You won’t have to manage any servers, configure any clusters, or set up any infrastructure. Just your application running!

1. Fully Managed Infrastructure

App Runner simplifies infrastructure management as all aspects are abstracted. Configuring VPCs, choosing instance types, and managing servers are not necessary for you to do because Amazon will take care of everything for you behind the scenes.

2. Automatic Scaling

When an application experiences an increase in traffic, App Runner automatically adds instances (i.e., scales up) to meet traffic demands. Conversely, when an application experiences a decrease in traffic, App Runner will scale down by releasing nodes back into available resources (including removing all nodes from use when configured to do so).

3. Built-in HTTPS and Load Balancing

All App Runner services also have HTTPS endpoints automatically created for them, and for you. You do not need to worry about managing or renewing TLS certificates; all of this is handled automatically by Amazon for all App Runner services. Additionally, AWS will automatically load balance your services without any additional effort and expense on your part.

4. Flexible Deployment Options

In addition to deploying directly from Amazon Elastic Container Registry (ECR) or other container registries, you can deploy an Application directly from a GitHub repository connection to App Runner. When deploying an application with a source code method (from GitHub) App Runner will automatically create the container image to support the following programming languages (Python, Node.js and Java).

5. Integrated Observability

The built-in integrations with Amazon CloudWatch will automatically send your logs and metrics from the App Runner to your Amazon CloudWatch account. This gives you an easy view into your application deployments, the status of health checks and application performance without any additional work required by you.

How AWS App Runner Enhances Application Deployment

1. Eliminates Infrastructure Complexity

Developers can upload applications to production without having to learn all of the complicated AWS networks or computing setups. As a result, development teams across the organization have more options when it comes to deploying their work.

2. Reduces Time to Production

The simplified deployment process allows developers to go from writing code to being live in minutes rather than hours/days. In turn, development teams can make more iterations in a shorter amount of time, enabling them to quickly adapt to the changing needs of the organization.

3. Optimizes Costs

Developers only pay for the compute and memory that are utilized by their applications. Developers don't need to pay for development environments when they are scaling down to zero. Also, there is no additional cost associated with load balancers, etc., as these are all built into the pricing structure.

4. Simplifies Maintenance

AWS is responsible for performing platform-related tasks like platform upgrades, security patches, and infrastructure. As a result, you can focus on developing application code, while AWS manages the rest (like operational overhead).

Where App Runner Fits in the AWS

In Comparison with Amazon ECS/EKS

Amazon ECS and EKS provide significant control over a cluster's networking, task orchestration, and cluster management. On the other hand, Amazon App Runner sacrifices this control in favour of ease-of-use (there's no need to manage the underlying infrastructure).

In Comparison with Elastic Beanstalk

Both Amazon App Runner and Elastic Beanstalk are Platform-as-a-Service (PaaS) solutions, however, App Runner is newer and focuses on containers rather than on a broader application platform. App Runner also has more rigid guidelines, reducing your number of decisions and speeding up your time-to-deployment.

In Comparison with AWS Lambda

While AWS Lambda is designed to execute event-driven functions that have short execution times, Amazon App Runner is designed for long-executing, continuously running web applications and APIs that require persistent container images and the ability to communicate with users via HTTP on an ongoing basis.

Therefore, use Amazon App Runner if you are building a web application or API and would like to make the simplest deployment possible without having to worry about managing the underlying infrastructure. Otherwise, you should consider other AWS services if you require sophisticated networking configurations or custom compute requirements or workloads that extend beyond HTTP/HTTPS.

Common Use Cases

Web Apps: Build and launch web-based software for customers, employees, or administrators (using) Cloud Resources with no provisioning or setup required.
RESTful APIs: Create RESTful web services and automatically scale them based upon the number of requests received.
MicroServices: Build independent Components representing individual Business Feature Sets with distinct Endpoints and Scale Independently of each other based upon Business Demand.
SaaS Backend: SaaS Applications enable the construction of multi-tenant Applications whereby each Tenant may require their own Service Instances...
Prototypes: Build applications by prototyping or only those Features that validate your Idea without wasting the time spent on configuring the Software Infrastructure for an Application.

When Not to Use App Runner

App Runner is Not Designed for the Following:

Background Jobs / Scheduled Tasks
Batch Processing Workloads
Applications Requiring Complex VPC Configurations / Custom Networking
GPU Workloads / Specialized Compute Requirements
Multi-Region, Active-Active Deployments with Advanced Failover Strategies

In these Situations, Consider ECS, Lambda, or EC2.

Getting Started with AWS App Runner

To start using AWS App Runner:

Log in to the AWS Console: Log in to your AWS account via the AWS Management Console.
Navigate to App Runner: Go to Compute Services and look for App Runner.
Create a Service: Select your Source Type - Container Image hosted on ECR or Source Code in GitHub.
Configure the Settings: Set your Deployment Configuration (Instance Size, Scaling Parameters, etc.) and enter any Environment Variables you need for the Application.
Deploy: App Runner will Build (in the case of Source Code), Deploy your Application, and Return an HTTPS Endpoint.
Monitor: Use the Integrated CloudWatch to monitor Logs and Metrics generated by your application.

Conclusion

AWS's App Runner is designed to change the way we deploy our cloud applications to the cloud. App Runner allows developers to not worry about the complexities of managing their infrastructure so they can simply focus on writing their application.

If you are deploying web applications or APIs using containers, and you want the easiest way to go from your code to production, App Runner provides you with that option. Although App Runner may not be as versatile as ECS or EKS when it comes to managing multiple services across different regions and environments, App Runner is usually a better option for more simple web application deployments.

Do you want to learn more about how AWS App Runner can improve your application's deployment process? Please leave comments below!

Optimizing Costs for Container Workloads on AWS EKS and ECS

Samir Khanal — Wed, 24 Dec 2025 16:46:51 +0000

Hey Everyone! let's talk about something that I know all of us care about. That is saving money on our cloud bills. I recently dived deep into optimizing our container costs on AWS, and to be honest, I wish I knew all of these insights earlier.

Why Container Cost Optimization Matters

The thing is containers are a huge win on the scaling and deployment side, but they can quietly carry away at your budget if you’re not keeping an eye on it. The beast? The beauty is AWS offers us a whole bunch of ways to make the cost magic disappear without impacting performance or even improving it, quite often.

Spot Instances: Your Secret Weapon

This is in all probability, the biggest win that AWS has provided to me. You can save up to 90% in spot instances over on-demand instances. Yes, 90%! These are ideal for fault-tolerant applications that are able to withstand intermittent disruptions.

EKS makes the process of using managed node groups with spot instances relatively easy. You can even use both spot instances and regular instances,within the same EKS cluster. In this way, you could use regular instances to power critical applications, while another application could use spot instances.

To begin, moving our batch-processing workloads and our CI/CD pipelines to Spot instances worked beautifully for us. These workloads are inherently interruptible, so the cost benefit is instantaneous. The key, though, is to ensure your applications can shut down gracefully, and you're good to go.

Fargate vs EC2: Choosing Wisely

But I did have questions about when to pick Fargate over EC2 and when to pick EC2 over Fargate. Fargate costs more per compute unit, but it does away with operational costs.

I learned the following: Fargate is great for workloads that have unpredictable traffic or a smaller size, or if you want no infrastructure management. The service charges are for what you use down to the second with no wasted capacity.

EC2 would be more appropriate for production workloads where right-sizing and maintaining high resource utilization are possible. For large application deployments that exhibit predictable resource behaviour, EC2 using Reserved Instances and/or Savings Plans tends to be cheaper.

As for my current approach,
I am using Fargate for dev environments and occasional workloads. Production workloads that receive steady traffic run on well-optimized instances of EC2.
It’s essentially about using the right tool for the right job.

Autoscaling: The Dynamic Duo

Two things that changed the way I think about resource allocation are Cluster Autoscaler and Horizontal Pod Autoscaler (HPA).

The Cluster Autoscaler automatically scales the number of nodes in your cluster based on how many pending pods there are. No more spending money on nodes just sitting there, doing nothing.

HPA scales your pods at an application level based on CPU, memory, or your customized metrics. All three are a magnificent symphony of efficiency. Your cluster scales up as your traffic boosts and down when your traffic diminishes. Doing so by itself saved us 30% because we stopped over-provisioning just in case.

Setting up HPA is straightforward:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Rightsizing: Stop Wasting Resources

I was guilty of this too: setting pod resource requests much too high as a precaution. But no, I was actually paying for resources we didn't use.

Start with understanding your actual resource consumption. Evaluate what your pods actually consume resource-wise and not what you believe they consume. You can use the Kubernetes metrics server to achieve this.

Next, adjust your resource requests and limits based on that. For example, if your pod is using 100MB of memory but you have a resource request of 512MB, you are wasting money. Be practical about your application resource requirements, and remember that resource limits are important too.

Practice tip: Begin conservatively, watching for a week or two, and then optimize. It may seem slow, but the cost savings really add up over dozens or hundreds of pods.

Kubecost: Your Financial Visibility Partner

His tool was nothing short of revolutionary for me. Kubecost is a cost visibility tool for Kubernetes workloads that delivers real-time cost visibility. What it does is show you exactly where your dollars are being spent – down to the namespace level or down to pods.

What I like best about Kubecost is the way it provides cost data broken down by teams, apps, or environments. Now you can see that the actual cost of the staging environment is up to the cost of the production environment oops, or that one microservice is consuming 40% of the compute cost.

The community edition offers a lot and is ideal for beginners. Once you install it on your cluster, you get information regarding cost allocation, optimization, and even alerts for spending above certain limits. It’s almost like having your own financial analyst for all of your Kubernetes clusters.

ECR Lifecycle Policies: Clean Up and Save

This is something to easily forget: those images inside those container repositories in your Amazon ECR? They're going to start costing money to store. Just because those versions are ancient and sitting around unused means they're effectively burning money.

ECR lifecycle policies allow you to automatically clean up your images by age or number. One of the first things I did was establish a basic policy of retaining the last 10 images in a repository and removing anything over 30 days if not pulled.

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Keep last 10 images",
      "selection": {
        "tagStatus": "any",
        "countType": "imageCountMoreThan",
        "countNumber": 10
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

It’s a small thing, but if you’re working with several repositories, the disk space savings can add up.

Bringing It All Together

Cost optimization, however, doesn't fall under the category of something that's done in one go. My take on this would be to begin with the quick wins. The.quick wins include autoscaling, Spot instances, and Kubecost.

Next, begin to focus on rightsizing, cleanup of old images, and making educated decisions between Fargate and EC2. Monitor progress and rejoice at the wins along the way. We were able to lower our costs in containers by close to 45% in three months.
The Next Areas to Tackle: Infrastructure and IRSA

Also, remember that every dollar you save is a dollar you can then invest in building better features or improving your infrastructure in different ways.

What cost optimization methods have you tried with success? I'd love to hear your experiences so I don't miss any tips. Thanks in advance, and let's keep learning from each other!

Share your “best tip on cutting costs” in the comment section below to help each other stay on top of those cloud bills!

My Journey with Amazon EKS: Simplifying Kubernetes on AWS

Samir Khanal — Wed, 24 Dec 2025 15:45:35 +0000

Hey everyone, I wanted to share with you all something I've been exploring within the cloud services infrastructure that I am truly passionate about Amazon EKS, also known as Amazon Elastic Kubernetes Service. If you have been wanting to leverage Kubernetes within AWS but have been deterred by the complexity of setup, this article is written for you

What is Amazon EKS?

To break it down into simpler terms: the Amazon EKS service is essentially the managed Kubernetes service offered by AWS. It is almost as if AWS is handling the whole heavy lifting of Kubernetes itself so that you are left with the liberty of concentrating on application management.

EKS is essentially a system that makes it easier to manage your applications running in containers hosted across multiple machines. The interesting part about this is that, while creating your own EKS clusters is not very easy, EKS is exactly what you need. EKS takes care of things like master node setup, high availability, security patches, and upgrade tasks.

What Makes EKS Special?

My exploration of EKS has revealed the following salient features:

Fully Managed Control Plane: The control plane process in Kubernetes is automatically handled by AWS across various availability zones. This enhances reliability with less effort on your part to design this yourself.

Smooth Integration with AWS: EKS integrates seamlessly well with other AWS services like IAM for auth, VPC for networking, and ELB for balancing loads. Imagine how easily you can work while building cloud native applications.

Security Baked In: When you think about it, security is essentially baked in here because of automatic encryption, its tie to IAM, and VPCs. You also get automatic security patches for your control plane.

Flexibility with Compute Options: Instance options for computing, AWS Fargate with serverless containers, and EKS Anywhere, aimed at extending services to premises, give you the opportunity to run your compute workloads anywhere. This is an important factor, given your needs may vary.

How It Helps Us as Developers and DevOps Engineers

It’s at this stage that things become more practical. As someone keen on efficiency, I appreciate the way EKS resolves some of the key pain points for people like me:

You have fewer activities related to infrastructure maintenance and more related to application development. The learning curve here isn’t as steep since if you know Kubernetes already, you’ll pretty much need no learning. You will not be locked into AWS-specific services either since you can use standard Kubernetes services and configurations.

Another advantage is that EKS is scalable. Your applications will be able to scale from a few users to thousands without you having to redesign your architecture. EKS scales the control plane automatically.

In terms of cost, you will be responsible for paying for the EKS control plane only and the compute resources that you actually consume. This does not require overprovisioning, and this can result in some cost savings.

Getting Started with EKS

Are you ready to give EKS a test drive? Here's the simplified step-by-step plan to get started

First, ensure that you have both AWS CLI and kubectl installed on your machine. Additionally, you should install eksctl, which is a command line utility specifically built to make creating an EKS cluster simpler.

Creating your first cluster can be as simple as:

eksctl create cluster --name my-first-cluster --region us-east-1

This single command launches a whole EKS cluster with worker nodes. It is almost magical to see the amount of complexity abstracted away.

Once your cluster is up, you can then deploy applications by using standard Kubernetes manifests. This is a very familiar experience if you're used to running applications via Kubernetes, but without all of the management overhead.

The AWS documentation is comprehensive, and there is an active and supportive community for EKS. Do not be afraid to dive into the official tutorials and guides because they really are helpful resources.

Final Thoughts

Finding about Amazon EKS has been an eye-opening experience for me. It is an excellent platform that provides you the ability and flexibility of Kubernetes, taking away all the operational hassles from it.

Whether you are running microservices, batch jobs, or machine learning workloads, EKS gets you off to a strong start. And the best part? It scales alongside your maturing demands.

If you’ve been looking at Kubernetes for your workloads that run on AWS, I would say you should definitely give EKS a whirl. Just start with a tiny application and see what it feels like. The hurdle is not that high.

Would love to hear about your experience with EKS or questions you have. Feel free to provide your thoughts below via comments. Happy cloud building!

What is your favorite part about EKS, or what might be keeping you from trying EKS? Let's discuss!

Understanding Serverless Containers on AWS

Samir Khanal — Mon, 22 Dec 2025 08:21:31 +0000

Introduction

I recently heard about the term ‘serverless containers’. I was already working with cloud and DevOps, Docker, and container orchestration, so I had a question for myself: “What exactly is a serverless container, and how can containers be serverless when they run on servers?”
With that curiosity, I explored serverless containers on AWS, which I found was a powerful approach that blends the flexibility of containers with the simplicity of serverless computing

In this post, I’ll discuss what serverless containers really mean, how AWS IMPLEMENTS THEM, and where they make sense in real-world environments

Serverless Containers:

Serverless containers are containerized workloads that run the app without managing the underlying servers. Serverless does not mean that there are no servers. Servers exist, but we don't need to manage them. AWS takes full responsibility for them.

For the traditional container deployments, you have to:

Choose the EC2 types
Provision and manage clusters
Patch operating systems
Plan for scaling and capacity

But with serverless, AWS handles all of that. You simply need to:

Build your container image
Define CPU and memory needs
Deploy the workloads

AWS manages the provisioning of compute resources, launching containers, dynamically scaling them as needed, and managing the infrastructure lifecycle.

So, preserving all of the benefits of container-based applications portability, consistency, and flexibility but significantly reducing operational overhead.

Serverless Containers on AWS

AWS provides two options for deploying serverless containers.

AWS Fargate

Serverless computing for containers (Fargate) is offered by the AWS Cloud for Amazon ECS (Elastic Container Service) or Amazon EKS (Elastic Kubernetes Service) without requiring customers to manage any EC2 instances or worker nodes. Instead, you define your application's task or pod specifications, and AWS takes care of running those specifications for you.

AWS Lambda with Container Images

AWS Lambda also allows you to package your function as a container image with a maximum size of 10 GB instead of a traditional ZIP file. Package your function in a container format when you require a custom runtime environment, and you utilise native dependencies or want to follow a Docker-based build process. When you deploy your container image to AWS Lambda, you receive all of the benefits associated with AWS Lambda's Event-Driven Model, Auto Scaling, and Pay-As-You-Go pricing, along with complete compatibility of your container image(s) with AWS Lambda.

Both services are classified as serverless because they allow customers to describe how to run their applications; AWS takes care of provisioning, scaling, and maintaining hardware resources on behalf of the customer.

Serverless Container Key Features

No Server Management
No EC2 Instances to Size, Patch, or Monitor. AWS fully manages the Compute Layer.

Automatic Scaling
The Compute Layer Automatically Scales Up when Demand increases

and down when Demand decreases, without requiring any human work.

Pay As You Go Pricing
You only pay for CPU, Memory, and Time that your containers

actually consume. And No Idle Capacity Costs.

Native AWARE (AWS) Integration
AWS is Fully Integrated with IAM and VPC, as well as ALB for
networking, Security, and Observability.

Container Flexibility
Use Docker Images and Existing CI/CD Pipelines to Ease in Move of
Containers to the Cloud.

Lambda Containers vs AWS Fargate

Lambda and Fargate provide a serverless container option, but each supports applications with varying workload types.

Lambda has many use cases for short-lived tasks that respond to events (S3, API Gateway, Amazon SQS, EventBridge) that can run for up to 15 minutes and handle inconsistent and unexpected spikes in traffic with lightweight APIs or background jobs.

Examples of event-driven workloads are an image resize service or file processing, webhooks, or cron jobs.

Fargate is intended for long-term applications, like microservices that must keep persistent connections, such as long-running services or REST APIs with multiple connections, or microservices that must maintain their states or persist between requests. In addition, Fargate offers users more options for controlling how their architecture scales, as they can deploy their workloads using ECS or Kubernetes.

Examples of applications that can be deployed using Amazon Fargate include (but are not limited to) internal tools, streaming processors, back-end services, and REST APIs.

Real-World Example of Video Processing Pipeline

Let's say you're creating a video processing application that generates thumbnail images every time someone uploads a video file. Upload traffic is unknown; it may have periods of low volume and sudden influxes (also known as "spikes").

Using Containers As Part Of A Lambda Computing Platform

When a user uploads a video, the system first saves it to Amazon S3 Storage. Next, an event trigger in Amazon S3 initiates a Lambda function. Inside the Lambda function, you may call a container image to create thumbnails utilizing applications such as FFmpeg. Lastly, the Lambda function saves the generated thumbnails back to Amazon S3 Storage for users to view.

Here's how it works:

There won't be any idle servers.
You have scalable Lambda computing capabilities when there is high increase in traffic.
You pay for each time you process; therefore, you do not need to maintain and manage a large EC2 fleet of instances that only process occasionally; you still use complex & powerful container-based software development tools.

Where AWS Fargate Fits Better
Imagine a microservice architecture that supports a mobile or web application.
An example of this type of microservice architecture might have multiple APIs (user, order, payment, inventory) and must be up continuously. Load balancing and service discovery are also necessary for this type of architecture to work.

When using ECS on Fargate:
Each of your microservice tasks runs a container task.

The Application Load Balancer routes traffic.

Your services scale based on either CPU/memory or request count.

There will be no need to manage an EC2 cluster.

Additionally, it provides a nice solution for DevOps teams that require a way to orchestrate containers without having to manage nodes.

Getting Started with Serverless Containers on AWS

Steps: Set Up Serverless Containers on AWS

Determine which service you want to use, based on what you're trying to achieve

AWS Lambda is a good option when your service will be short-lived (only active while processing an event) and your application is event-driven.
AWS Fargate is a better option when you need to set up a long-running service that requires containerized applications.

Create Your Application in a Docker Container

Create a Dockerfile with best-practice guidelines:

Keep base images slim
Use multiple stages to build
Minimize the number of layers in your image

Upload Your Image to Amazon Elastic Container Registry (ECR)

ECR is AWS's completely Managed, scalable image storage/management for storing, managing and delivering Docker container images.

Deploy Your Container Based Applications

Most people use the AWS Console, the AWS CLI, Terraform or CI/CD pipelines to define AWS Lambda tasks or Amazon Elastic Container Services (ECS) tasks.

Improve your system's throughput and cost management by keeping track of performance metrics using AWS CloudWatch logs, metrics and alarms.

Key Takeaways

Container management infrastructure is removed by serverless, but the large degree of container flexibility remains.
Two serverless options on AWS: Lambda Container and Fargate.
You should choose Choose based on runtime duration, architecture, or scalability needs
Serverless containers offer faster deployments, simplify operational processes, and provide greater cost-effectiveness.
They are best for modern cloud-native DevOps workflows.

Conclusion

Serverless containers fill the gap between traditional containers and serverless computing; it allow you to continue using your existing Docker workflow without the hassles of managing servers, clusters, or even performing capacity planning.

AWS allows you to develop and deploy event-driven functions in AWS Lambda as well as scalable microservices using AWS Fargate. This means that not only can you deploy applications faster but also run them more efficiently than before, thanks to the extensive capabilities of AWS.

Feel free to reach out in the comments if you have questions or want to share your experiences with serverless containers!

Automating Container Security on AWS with CI/CD and Fargate using GitHub Actions

Samir Khanal — Tue, 16 Dec 2025 08:33:45 +0000

Introduction: Why I Built This

A few months ago, I was responsible for managing a rapidly growing microservices architecture supported by AWS. There was five different services running in separate containers, each with its own dependencies, and I was continually worried about whether any of them had been updated with a vulnerability during image deployment.

The real problem wasn't just the scanning of images; it was about how to automate and consistently maintain security across the entire deployment pipeline.
Manual security checks do not scale, and we all know they are often skipped when a deadline approaches.

I built an automated security pipeline to scan for vulnerabilities in container images using AWS Fargate and GitHub Actions. It eliminated all the manual scanning of images, as well as the constant fear of whether the last base image had critical CVEs and whether we were deploying insecure code to production.

In this article, I will provide a detailed overview of how I set this up with example configurations and command lines I ran, as well as some of the lessons I learned from implementing it in a production environment..

What We Will Discuss:
How to set up ECR with automated vulnerability scanning.

How to create GitHub Actions workflows that will do deployments based on security findings.

What Least Privilege IAM Roles and Network Isolation on Fargate mean.

How to continuously monitor and track compliance.

An example step-by-step for your projects.

Architecture Overview: The Big Picture
Now that we have an overview of what we will be doing, here's an overview of the architecture that supports the automated security pipeline you built:

With this configuration, you will have:

Automated security scanning of all container images before reaching production.
Network Isolation for Private Subnets and Security Groups.
Least Privilege Access with Separate IAM Roles for Execution and Task Roles
Complete Audit Trail via CloudWatch Logs
Runtime Protection via Fargate Isolation Model

Now Let's Get into How Each Component Functions!

Container Image Security
It is necessary not to assume that any images of containers are trustworthy. Even official images used by developers can contain vulnerabilities and/or have dependencies that could create security problems.
I locked down the image containers by:

1. Automatic image scanning ECR (Scan on push)
For each repository in ECR, I enabled image scanning on push. When I push an image into ECR, AWS automatically scans that image against the CVE database. To enable image scan on push for a repository, follow these steps:

Enabling scan-on-push for a repository:

aws ecr put-image-scanning-configuration \
    --repository-name production-api \
    --image-scanning-configuration scanOnPush=true \
    --region us-east-1

Configuring enhanced scanning with Inspector:

aws ecr put-registry-scanning-configuration \
    --scan-type ENHANCED \
    --rules '[{"repositoryFilters":[{"filter":"*","filterType":"WILDCARD"}],"scanFrequency":"CONTINUOUS_SCAN"}]' \
    --region us-east-1

With improved scanning you will discover:

Operating system vulnerabilities
Vulnerabilities in programming-language packages (Python, Node.JS,
Java etc.)
Continuous monitoring of your environment not just at the time you 'push' your container image.

2. IAM Roles - Separation is Key
I learnt the hard way - do not ever use the same IAM Role across everything. Here is how I distinguish between:
Task Execution Role - this is the role that ECS will require in order to launch the container you have created.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

*Task Role *(what your application needs):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:745812456855:table/users-table"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::my-app-assets/*"
    }
  ]
}

The service’s requirement for executing a task is identical for all services; however, each service's specific need defines the task role.

Base Image Selection & Multi-Stage Builds
I no longer use large operating system images; instead, I use small base images as a foundation. Below is an example comparing both types of base images.

Base Image Size and Vulnerabilities (my tests show the below data).

node:18 - full image: 1.1 GB 247 CVEs
node:18-slim - small image: 243 MB 89 CVEs
node:18-alpine - container images: 178 MB 12 CVEs

My Dockerfile Strategy Uses Multi-Stage Builds:

# Build stage - includes dev dependencies
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

# Production stage - minimal runtime
FROM node:18-alpine
WORKDIR /app

# Create non-root user
RUN addgroup -g 1001 appuser && \
    adduser -D -u 1001 -G appuser appuser

# Copy only production artifacts
COPY --from=builder --chown=appuser:appuser /app/dist ./dist
COPY --from=builder --chown=appuser:appuser /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appuser /app/package.json ./

# Switch to non-root user
USER appuser

# Run the application
EXPOSE 3000
CMD ["node", "dist/index.js"]

Security Practices in the Dockerfile:

Utilizes an Alpine image as a base
Implements a multi-stage build; production image has no build tools
Runs the image as a non-root user (following the principle of least privilege)
Only production dependencies included in the image
Related dependencies are pinned to a specific version.

Vulnerability Thresholds
I created a policy that states: No Critical or High-Risk vulnerabilities exist in production -- No Exceptions.
The following process allows me to check the programmatic results of the scans:

# Get the latest scan findings
aws ecr describe-image-scan-findings \
    --repository-name production-api \
    --image-id imageTag=v1.2.3 \
    --region us-east-1 \
    --query 'imageScanFindings.findingSeverityCounts'

Output:

{
    "CRITICAL": 0,
    "HIGH": 0,
    "MEDIUM": 3,
    "LOW": 12,
    "INFORMATIONAL": 5
}

A build will fail automatically when CRITICAL or HIGH vulnerabilities are detected in GitHub Actions CI/CD using our automated security process (in the following section).

Automating Security in GitHub Actions CI/CD
This is where things become interesting: every time new code is pushed into the master branch, an automated process is created, which builds the application, scans it for vulnerabilities, and only then deploys (if everything was successful).

GitHub Actions Full Workflow
Here is the workflow document I have.(.github/workflows/deploy.yml):

name: Build, Scan, and Deploy to Fargate

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

env:
  AWS_REGION: us-east-1
  ECR_REPOSITORY: production-api
  ECS_CLUSTER: production-cluster
  ECS_SERVICE: api-service
  CONTAINER_NAME: api-container

jobs:
  build-and-scan:
    name: Build and Security Scan
    runs-on: ubuntu-latest

    outputs:
      image: ${{ steps.build-image.outputs.image }}

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v2
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

    - name: Build Docker image
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker tag $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG $ECR_REGISTRY/$ECR_REPOSITORY:latest
        echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT

    - name: Push image to Amazon ECR
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:latest

    - name: Wait for ECR scan to complete
      env:
        IMAGE_TAG: ${{ github.sha }}
      run: |
        echo "Waiting for image scan to complete..."
        sleep 30

        for i in {1..20}; do
          SCAN_STATUS=$(aws ecr describe-image-scan-findings \
            --repository-name $ECR_REPOSITORY \
            --image-id imageTag=$IMAGE_TAG \
            --region $AWS_REGION \
            --query 'imageScanStatus.status' \
            --output text 2>/dev/null || echo "PENDING")

          echo "Scan status: $SCAN_STATUS"

          if [ "$SCAN_STATUS" = "COMPLETE" ]; then
            echo "Scan completed successfully"
            break
          elif [ "$SCAN_STATUS" = "FAILED" ]; then
            echo "Scan failed!"
            exit 1
          fi

          sleep 15
        done

    - name: Check for vulnerabilities
      env:
        IMAGE_TAG: ${{ github.sha }}
      run: |
        echo "Checking for vulnerabilities..."

        FINDINGS=$(aws ecr describe-image-scan-findings \
          --repository-name $ECR_REPOSITORY \
          --image-id imageTag=$IMAGE_TAG \
          --region $AWS_REGION)

        echo "$FINDINGS" | jq '.imageScanFindings.findingSeverityCounts'

        CRITICAL=$(echo "$FINDINGS" | jq -r '.imageScanFindings.findingSeverityCounts.CRITICAL // 0')
        HIGH=$(echo "$FINDINGS" | jq -r '.imageScanFindings.findingSeverityCounts.HIGH // 0')
        MEDIUM=$(echo "$FINDINGS" | jq -r '.imageScanFindings.findingSeverityCounts.MEDIUM // 0')

        echo "Critical vulnerabilities: $CRITICAL"
        echo "High vulnerabilities: $HIGH"
        echo "Medium vulnerabilities: $MEDIUM"

        if [ "$CRITICAL" -gt 0 ] || [ "$HIGH" -gt 0 ]; then
          echo "❌ CRITICAL or HIGH vulnerabilities found! Deployment blocked."
          echo "Please fix vulnerabilities before deploying."
          exit 1
        fi

        if [ "$MEDIUM" -gt 5 ]; then
          echo "⚠️  Warning: More than 5 MEDIUM vulnerabilities found."
          echo "Consider addressing these vulnerabilities."
        fi

        echo "✅ Security scan passed!"

    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: ${{ steps.build-image.outputs.image }}
        format: 'sarif'
        output: 'trivy-results.sarif'

    - name: Upload Trivy results to GitHub Security
      uses: github/codeql-action/upload-sarif@v2
      if: always()
      with:
        sarif_file: 'trivy-results.sarif'

  deploy:
    name: Deploy to Fargate
    needs: build-and-scan
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'

    steps:
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v2
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}

    - name: Download task definition
      run: |
        aws ecs describe-task-definition \
          --task-definition api-service-task \
          --query taskDefinition > task-definition.json

    - name: Fill in the new image ID in the task definition
      id: task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: task-definition.json
        container-name: ${{ env.CONTAINER_NAME }}
        image: ${{ needs.build-and-scan.outputs.image }}

    - name: Deploy to Amazon ECS
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.task-def.outputs.task-definition }}
        service: ${{ env.ECS_SERVICE }}
        cluster: ${{ env.ECS_CLUSTER }}
        wait-for-service-stability: true

    - name: Notify deployment success
      if: success()
      run: |
        echo "🚀 Deployment successful!"
        echo "Image: ${{ needs.build-and-scan.outputs.image }}"
        echo "Service: ${{ env.ECS_SERVICE }}"
        echo "Cluster: ${{ env.ECS_CLUSTER }}"

Below is a list of the actions taken in this workflow, listed sequentially:

Build:
Retrieve code from the repository
Create a Docker image
Tag the image with the SHA for historical records
Scan:
Send the image to Amazon ECR (which starts an automatic scan)
Check for completion of the scan (with timeout)
Download the results of the scan for identified vulnerabilities
Deployments that have Critical or High vulnerabilities are prohibited from proceeding
Run another scan using Trivy
Upload the results of the scan to the Security Tab in GitHub
Deploy: This will only take place when a successful scan occurs.
Pull current task definition file(s)
Replace current image reference with new image
Deploy the task to Fargate
Observe until the service has stabilized

The Secret Sauce consists of Deployment Gate Checks, which essentially checks for any vulnerabilities present during the deployment process.

if [ "$CRITICAL" -gt 0 ] || [ "$HIGH" -gt 0 ]; then
  echo " CRITICAL or HIGH vulnerabilities found! Deployment blocked."
  exit 1
fi

If any vulnerabilities are found during this deployment gate check, the workflow will fail and the user will not be able to deploy that artifact regardless of the reason. This process has saved us from deploying known CVEs on several occasions.

Secrets Required to Configure GitHub
You will need to add the following secret keys to your repository:

AWS_ACCESS_KEY_ID (ex: AKIAIOSFODNN7EXAMPLE)
 AWS_SECRET_ACCESS_KEY (ex: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY)

Pro tip: The best practice is to use an IAM user that has the least privileges necessary:

ecr:* To your repositories
ecs:DescribeTaskDefinition, ecs:RegisterTaskDefinition, ecs:UpdateService
iam:PassRole to the task execution role

Security and Runtime Management of Your Tasks Running within Fargate

There are many built-in Security features available with Fargate, including isolated processors and no-host management capabilities; however, it is still necessary to properly configure Fargate to obtain maximum benefits from these built-in Security capabilities.

1. Network Segmentation

When using Fargate to deploy my services, I created an environment with Private SUBNETS That Do Not Have Direct Access To The Internet. To leverage Outbound Connectivity (i.e., For ECR Image Pulling and API Calls), I used NAT Gateways (server-side Network Address Translation Gateway).

I Created A VPC According To This Configuration Through Terraform.

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "production-vpc"
  }
}

resource "aws_subnet" "private_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"

  tags = {
    Name = "production-private-subnet-a"
  }
}

resource "aws_subnet" "private_b" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = "us-east-1b"

  tags = {
    Name = "production-private-subnet-b"
  }
}

resource "aws_security_group" "ecs_tasks" {
  name        = "ecs-tasks-sg"
  description = "Security group for ECS tasks"
  vpc_id      = aws_vpc.main.id

  # Allow outbound to internet (via NAT Gateway)
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow inbound from ALB only
  ingress {
    from_port       = 3000
    to_port         = 3000
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
    description     = "Allow traffic from ALB"
  }

  tags = {
    Name = "ecs-tasks-security-group"
  }
}

A sample task definition (Terraform) for Fargate Task Definitions that adheres to secure practices:

resource "aws_ecs_task_definition" "api_service" {
  family                   = "api-service-task"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "512"
  memory                   = "1024"
  execution_role_arn       = aws_iam_role.ecs_execution_role.arn
  task_role_arn            = aws_iam_role.api_task_role.arn

  container_definitions = jsonencode([
    {
      name      = "api-container"
      image     = "745812456855.dkr.ecr.us-east-1.amazonaws.com/production-api:latest"
      essential = true

      portMappings = [
        {
          containerPort = 3000
          protocol      = "tcp"
        }
      ]

      logConfiguration = {
        logDriver = "awslogs"
        options = {
          "awslogs-group"         = "/ecs/production-cluster/api-service"
          "awslogs-region"        = "us-east-1"
          "awslogs-stream-prefix" = "ecs"
        }
      }

      environment = [
        {const winston = require('winston');

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json()
  ),
  defaultMeta: { 
    service: 'api-service',
    environment: 'production'
  },
  transports: [
    new winston.transports.Console()
  ]
});

// Usage
logger.info('User login successful', { 
  userId: 'user-123', 
  ipAddress: '203.0.113.42' 
});

logger.error('Database connection failed', { 
  error: err.message,
  stack: err.stack 
});

          name  = "NODE_ENV"
          value = "production"
        },
        {
          name  = "PORT"
          value = "3000"
        }
      ]

      secrets = [
        {
          name      = "DATABASE_URL"
          valueFrom = "arn:aws:secretsmanager:us-east-1:745812456855:secret:prod/database-url-AbCdEf"
        },
        {
          name      = "API_KEY"
          valueFrom = "arn:aws:secretsmanager:us-east-1:745812456855:secret:prod/api-key-XyZ123"
        }
      ]

      # Security configurations
      readonlyRootFilesystem = true

      linuxParameters = {
        capabilities = {
          drop = ["ALL"]
          add  = ["NET_BIND_SERVICE"]
        }
      }

      healthCheck = {
        command     = ["CMD-SHELL", "curl -f http://localhost:3000/health || exit 1"]
        interval    = 30
        timeout     = 5
        retries     = 3
        startPeriod = 60
      }
    }
  ])

  tags = {
    Environment = "production"
    Service     = "api"
  }
}

The task definition contains the following key features related to security:

The readonlyRootFilesystem option restricts write access to the local file system of the container so that it cannot be modified by external entities.
The linuxParameters.capabilities allow the user to drop all capabilities by default, and only grant the minimal required access.
The secrets parameter should be set to use AWS Secrets Manager instead of environment variables.
The execution role and the task role should be separate.
It is recommended that a health check be included as part of the overall reliability of the application.

Encryption in Transit:

ALB still uses HTTPS using ACM certificates.
All internal service-to-service communications use HTTPS.

Encryption at Rest:

ECR images will be encrypted using AWS KMS.
CloudWatch logs will be encrypted.
EFS volume (if used) will be encrypted.

Example: Creating encrypted log group:

aws logs create-log-group \
    --log-group-name /ecs/production-cluster/api-service \
    --kms-key-id arn:aws:kms:us-east-1:745812456855:key/12345678-4562-4568-5645-745812456855 \
    --region us-east-1

4. Least-Privilege IAM Policies

This is the actual task role I used:

resource "aws_iam_role" "api_task_role" {
  name = "apiServiceTaskRole"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ecs-tasks.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy" "api_task_policy" {
  name = "apiServiceTaskPolicy"
  role = aws_iam_role.api_task_role.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "dynamodb:GetItem",
          "dynamodb:PutItem",
          "dynamodb:Query",
          "dynamodb:UpdateItem"
        ]
        Resource = [
          "arn:aws:dynamodb:us-east-1:745812456855:table/users-table",
          "arn:aws:dynamodb:us-east-1:745812456855:table/users-table/index/*"
        ]
      },
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",
          "s3:PutObject"
        ]
        Resource = "arn:aws:s3:::my-app-assets/*"
      },
      {
        Effect = "Allow"
        Action = [
          "secretsmanager:GetSecretValue"
        ]
        Resource = [
          "arn:aws:secretsmanager:us-east-1:745812456855:secret:prod/database-url-*",
          "arn:aws:secretsmanager:us-east-1:745812456855:secret:prod/api-key-*"
        ]
      }
    ]
  })
}

This is a clearer account of what I'm storing in DynamoDB
(the only DynamoDB tables required by this service) and which S3 actions can be performed (only GetObject and PutObject allowed - deletes not included). The other sensitive data I store (secrets) must be secured.

Compliance & Monitoring

Monitoring isn't a one-time event; it requires consistent monitoring so that we can maintain audit trails.

CloudWatch Logging Log files from all containers are collected in CloudWatch. The way I configure structured logging is detailed below: Creating the log group:

aws logs create-log-group \
    --log-group-name /ecs/production-cluster/api-service \
    --retention-in-days 30 \
    --region us-east-1

Application logging (Node.js example):

const winston = require('winston');

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json()
  ),
  defaultMeta: { 
    service: 'api-service',
    environment: 'production'
  },
  transports: [
    new winston.transports.Console()
  ]
});

// Usage
logger.info('User login successful', { 
  userId: 'user-123', 
  ipAddress: '203.0.113.42' 
});

logger.error('Database connection failed', { 
  error: err.message,
  stack: err.stack 
});

CloudWatch Alarms I set up alarms for critical metrics:

# High CPU usage alarm
aws cloudwatch put-metric-alarm \
    --alarm-name api-service-high-cpu \
    --alarm-description "Alert when API service CPU > 80%" \
    --metric-name CPUUtilization \
    --namespace AWS/ECS \
    --statistic Average \
    --period 300 \
    --threshold 80 \
    --comparison-operator GreaterThanThreshold \
    --evaluation-periods 2 \
    --dimensions Name=ServiceName,Value=api-service Name=ClusterName,Value=production-cluster \
    --alarm-actions arn:aws:sns:us-east-1:745812456855:ops-alerts

# Failed task alarm
aws cloudwatch put-metric-alarm \
    --alarm-name api-service-task-failures \
    --alarm-description "Alert on task failures" \
    --metric-name TaskFailures \
    --namespace ECS/ContainerInsights \
    --statistic Sum \
    --period 60 \
    --threshold 1 \
    --comparison-operator GreaterThanThreshold \
    --evaluation-periods 1 \
    --dimensions Name=ServiceName,Value=api-service Name=ClusterName,Value=production-cluster \
    --alarm-actions arn:aws:sns:us-east-1:745812456855:ops-alerts

3. Amazon Inspector Integration
Inspector provides continuous runtime vulnerability scanning. Here's how I enabled it:

# Enable Inspector for ECR and EC2
aws inspector2 enable \
    --resource-types ECR EC2 \
    --region us-east-1

# Check Inspector findings
aws inspector2 list-findings \
    --filter-criteria '{
      "ecrImageRepositoryName": [{"comparison": "EQUALS", "value": "production-api"}],
      "severity": [{"comparison": "EQUALS", "value": "CRITICAL"}]
    }' \
    --region us-east-1

The inspector provides you with the following benefits:

Continuous scanning of all of your running containers;.
detection of CVEs in both your operating system packages and your application dependencies.
Risk scores to prioritize your scan and find the most urgent risks; integration with AWS Security Hub.

Log Query Analysis I use CloudWatch Insights to monitor security-relevant events, and I have created a query that identifies all failed authentication attempts.

fields @timestamp, userId, ipAddress, @message
| filter @message like /authentication failed/
| sort @timestamp desc
| limit 100

The query for the error rate by service:

fields @timestamp, service, @message
| filter level = "error"
| stats count() by service
| sort count() desc

Compliance Reporting For compliance requirements (SOC 2, ISO 27001), I export logs to S3 for long-term retention:

aws logs create-export-task \
    --log-group-name /ecs/production-cluster/api-service \
    --from $(date -d '30 days ago' +%s)000 \
    --to $(date +%s)000 \
    --destination s3-compliance-logs-bucket \
    --destination-prefix ecs-logs/api-service/

Example of Steps: Complete Process

I want to demonstrate how to deploy (create) a completely new microservice while implementing all security features.

Step 1: Create the Microservice
Project Layout:

notification-service/
├── src/
│   ├── index.js
│   ├── handlers/
│   └── utils/
├── Dockerfile
├── package.json
└── .github/
    └── workflows/
        └── deploy.yml

Example Docker file (There is a link to the Docker file that is similar to notification-service/dockerfile on GitHub)

# Build stage
FROM node:18-alpine AS builder

WORKDIR /app

# Copy package files
COPY package*.json ./

# Install dependencies
RUN npm ci --only=production

# Copy application code
COPY . .

# Build if needed (TypeScript, etc.)
# RUN npm run build

# Production stage
FROM node:18-alpine

WORKDIR /app

# Install security updates
RUN apk update && \
    apk upgrade && \
    apk add --no-cache dumb-init && \
    rm -rf /var/cache/apk/*

# Create non-root user
RUN addgroup -g 1001 -S appgroup && \
    adduser -u 1001 -S appuser -G appgroup && \
    chown -R appuser:appgroup /app

# Copy from builder
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appgroup /app/src ./src
COPY --from=builder --chown=appuser:appgroup /app/package.json ./

# Switch to non-root user
USER appuser

# Use dumb-init to handle signals properly
ENTRYPOINT ["dumb-init", "--"]

# Health check
HEALTHCHECK --interval=30s --timeout=3s --start-period=40s --retries=3 \
    CMD node -e "require('http').get('http://localhost:3000/health', (r) => {process.exit(r.statusCode === 200 ? 0 : 1)})"

# Expose port
EXPOSE 3000

# Run application
CMD ["node", "src/index.js"]

Application code (src/index.js):

const express = require('express');
const AWS = require('aws-sdk');
const winston = require('winston');

const app = express();
const PORT = process.env.PORT || 3000;

// Configure logger
const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  defaultMeta: { service: 'notification-service' },
  transports: [new winston.transports.Console()]
});

// Configure AWS SDK
const sns = new AWS.SNS({ region: 'us-east-1' });
const secretsManager = new AWS.SecretsManager({ region: 'us-east-1' });

app.use(express.json());

// Health check endpoint
app.get('/health', (req, res) => {
  res.status(200).json({ status: 'healthy', timestamp: new Date().toISOString() });
});

// Send notification endpoint
app.post('/notify', async (req, res) => {
  try {
    const { message, topic } = req.body;

    logger.info('Sending notification', { topic, messageLength: message.length });

    const params = {
      Message: message,
      TopicArn: `arn:aws:sns:us-east-1:745812456855:${topic}`
    };

    await sns.publish(params).promise();

    logger.info('Notification sent successfully', { topic });
    res.status(200).json({ success: true, message: 'Notification sent' });

  } catch (error) {
    logger.error('Failed to send notification', { 
      error: error.message,
      stack: error.stack 
    });
    res.status(500).json({ success: false, error: 'Failed to send notification' });
  }
});

// Graceful shutdown
process.on('SIGTERM', () => {
  logger.info('SIGTERM received, shutting down gracefully');
  process.exit(0);
});

app.listen(PORT, () => {
  logger.info(`Notification service listening on port ${PORT}`);
});

Step 2: Create ECR Repository

# Create the repository
aws ecr create-repository \
    --repository-name notification-service \
    --image-scanning-configuration scanOnPush=true \
    --encryption-configuration encryptionType=KMS,kmsKey=arn:aws:kms:us-east-1:745812456855:key/12345678-1234-1234-1234-745812456855 \
    --region us-east-1

# Set lifecycle policy to keep only last 10 images
aws ecr put-lifecycle-policy \
    --repository-name notification-service \
    --lifecycle-policy-text '{
      "rules": [
        {
          "rulePriority": 1,
          "description": "Keep last 10 images",
          "selection": {
            "tagStatus": "any",
            "countType": "imageCountMoreThan",
            "countNumber": 10
          },
          "action": {
            "type": "expire"
          }
        }
      ]
    }' \
    --region us-east-1

Expected output:

{
    "repository": {
        "repositoryArn": "arn:aws:ecr:us-east-1:745812456855:repository/notification-service",
        "registryId": "745812456855",
        "repositoryName": "notification-service",
        "repositoryUri": "745812456855.dkr.ecr.us-east-1.amazonaws.com/notification-service",
        "createdAt": "2024-12-15T10:30:00.000000+00:00",
        "imageScanningConfiguration": {
            "scanOnPush": true
        },
        "encryptionConfiguration": {
            "encryptionType": "KMS",
            "kmsKey": "arn:aws:kms:us-east-1:745812456855:key/12345678-1234-1234-1234-745812456855"
        }
    }
}

Step 3: Build and Push Image Manually (First Time)

# Authenticate Docker to ECR
aws ecr get-login-password --region us-east-1 | \
    docker login --username AWS --password-stdin 745812456855.dkr.ecr.us-east-1.amazonaws.com

# Build the image
docker build -t notification-service:v1.0.0 .

# Tag for ECR
docker tag notification-service:v1.0.0 \
    745812456855.dkr.ecr.us-east-1.amazonaws.com/notification-service:v1.0.0

docker tag notification-service:v1.0.0 \
    745812456855.dkr.ecr.us-east-1.amazonaws.com/notification-service:latest

# Push to ECR
docker push 745812456855.dkr.ecr.us-east-1.amazonaws.com/notification-service:v1.0.0
docker push 745812456855.dkr.ecr.us-east-1.amazonaws.com/notification-service:latest

# Wait for scan to complete
echo "Waiting for image scan..."
sleep 30

# Check scan results
aws ecr describe-image-scan-findings \
    --repository-name notification-service \
    --image-id imageTag=v1.0.0 \
    --region us-east-1 \
    --query 'imageScanFindings.findingSeverityCounts'

Output of scan:

{
    "MEDIUM": 2,
    "LOW": 8,
    "INFORMATIONAL": 3
}

There are no any critical or high vulnerabilities, so safe to deploy!

Step 4: Create IAM Roles

Task execution role (same for all services):

# Create trust policy
cat > trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs-tasks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

# Create role
aws iam create-role \
    --role-name ecsTaskExecutionRole \
    --assume-role-policy-document file://trust-policy.json

# Attach AWS managed policy
aws iam attach-role-policy \
    --role-name ecsTaskExecutionRole \
    --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

Task role (specific to notification service):

# Create task role
aws iam create-role \
    --role-name notificationServiceTaskRole \
    --assume-role-policy-document file://trust-policy.json

# Create custom policy
cat > notification-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sns:Publish"
      ],
      "Resource": [
        "arn:aws:sns:us-east-1:745812456855:app-notifications",
        "arn:aws:sns:us-east-1:745812456855:alert-notifications"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": [
        "arn:aws:secretsmanager:us-east-1:745812456855:secret:prod/notification-config-*"
      ]
    }
  ]
}
EOF

# Attach policy
aws iam put-role-policy \
    --role-name notificationServiceTaskRole \
    --policy-name NotificationServicePolicy \
    --policy-document file://notification-policy.json

Step 5: Create Task Definition

# Create task definition JSON
cat > task-definition.json <<EOF
{
  "family": "notification-service-task",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::745812456855:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::745812456855:role/notificationServiceTaskRole",
  "containerDefinitions": [
    {
      "name": "notification-container",
      "image": "745812456855.dkr.ecr.us-east-1.amazonaws.com/notification-service:latest",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 3000,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/production-cluster/notification-service",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      },
      "environment": [
        {
          "name": "NODE_ENV",
          "value": "production"
        },
        {
          "name": "PORT",
          "value": "3000"
        }
      ],
      "secrets": [
        {
          "name": "NOTIFICATION_CONFIG",
          "valueFrom": "arn:aws:secretsmanager:us-east-1:745812456855:secret:prod/notification-config-AbCdEf"
        }
      ],
      "readonlyRootFilesystem": false,
      "linuxParameters": {
        "capabilities": {
          "drop": ["ALL"],
          "add": ["NET_BIND_SERVICE"]
        }
      },
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost:3000/health || exit 1"],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 60
      }
    }
  ]
}
EOF

# Register task definition
aws ecs register-task-definition \
    --cli-input-json file://task-definition.json \
    --region us-east-1

Step 6: Create ECS Service

# Create CloudWatch log group first
aws logs create-log-group \
    --log-group-name /ecs/production-cluster/notification-service \
    --region us-east-1

# Create the ECS service
aws ecs create-service \
    --cluster production-cluster \
    --service-name notification-service \
    --task-definition notification-service-task \
    --desired-count 2 \
    --launch-type FARGATE \
    --platform-version LATEST \
    --network-configuration "awsvpcConfiguration={
        subnets=[subnet-0a1b2c3d,subnet-0e1f2g3h],
        securityGroups=[sg-0a1b2c3d],
        assignPublicIp=DISABLED
    }" \
    --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-east-1:745812456855:targetgroup/notification-tg/745812456855,containerName=notification-container,containerPort=3000" \
    --health-check-grace-period-seconds 60 \
    --deployment-configuration "maximumPercent=200,minimumHealthyPercent=100,deploymentCircuitBreaker={enable=true,rollback=true}" \
    --enable-execute-command \
    --region us-east-1

Important Deployment Configuration Options

2 - The number of tasks that are running at any given time to ensure maximum uptime for the application (high availability).
DISABLED - To indicate that this task will be running in the private subnets of this VPC.
deploymentCircuitBreaker - To automatically roll back any failed deployments.
enable-execute-command - To allow the use of ECS Exec to assist in debugging your application (must include an appropriate IAM role).

** Step 7: ** Create a .github/workflows/deploy.yml file (as illustrated above) for this notification-service project.

name: Deploy Notification Service

on:
  push:
    branches: [ main ]
    paths:
      - 'notification-service/**'

env:
  AWS_REGION: us-east-1
  ECR_REPOSITORY: notification-service
  ECS_CLUSTER: production-cluster
  ECS_SERVICE: notification-service
  CONTAINER_NAME: notification-container

jobs:
  deploy:
    name: Build, Scan, and Deploy
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v3

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v2
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

    - name: Build, scan, and push image
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        cd notification-service
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

        # Wait for scan
        sleep 30

        # Check vulnerabilities
        CRITICAL=$(aws ecr describe-image-scan-findings \
          --repository-name $ECR_REPOSITORY \
          --image-id imageTag=$IMAGE_TAG \
          --query 'imageScanFindings.findingSeverityCounts.CRITICAL' \
          --output text 2>/dev/null || echo "0")

        if [ "$CRITICAL" != "0" ] && [ "$CRITICAL" != "None" ]; then
          echo " CRITICAL vulnerabilities found!"
          exit 1
        fi

        echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT

    - name: Deploy to ECS
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: notification-service/task-definition.json
        service: ${{ env.ECS_SERVICE }}
        cluster: ${{ env.ECS_CLUSTER }}
        wait-for-service-stability: true

Step 8: Verify Deployment

# Check service status
aws ecs describe-services \
    --cluster production-cluster \
    --services notification-service \
    --region us-east-1 \
    --query 'services[0].[serviceName,status,runningCount,desiredCount]' \
    --output table

# Check task health
aws ecs list-tasks \
    --cluster production-cluster \
    --service-name notification-service \
    --region us-east-1

# Get task details
aws ecs describe-tasks \
    --cluster production-cluster \
    --tasks arn:aws:ecs:us-east-1:745812456855:task/production-cluster/1234567890abcdef \
    --region us-east-1 \
    --query 'tasks[0].[taskArn,lastStatus,healthStatus,containers[0].healthStatus]'

# Check logs
aws logs tail /ecs/production-cluster/notification-service \
    --follow \
    --region us-east-1

Expected healthy output:

Service Name	Status	Desired Tasks	Running Tasks
notification-service	ACTIVE	2	2

Step 9: Test the Service

# Get ALB DNS name
ALB_DNS=$(aws elbv2 describe-load-balancers \
    --names production-alb \
    --query 'LoadBalancers[0].DNSName' \
    --output text \
    --region us-east-1)

# Health check
curl https://$ALB_DNS/health

# Send test notification
curl -X POST https://$ALB_DNS/notify \
    -H "Content-Type: application/json" \
    -d '{
      "message": "Test notification from secure pipeline",
      "topic": "app-notifications"
    }'

Expected response:

{
  "success": true,
  "message": "Notification sent"
}

Security & Lessons Learned & Best Practices

From the time we ran this configuration in production for several months, below are my major takeaways:

Security Lessons

1. Automating Everything or It Doesn't Get Done

When under pressure, manually performing security checks gets overlooked,
Automated gates in Continuous Integration/Continuous Deployment (CI/CD) are a must,
The easiest way to secure everything is to make it the easiest thing to do because making something insecure will almost always be easier.

2. Some Vulnerabilities Are Worse Than Others

CRITICAL/HIGH: block deployment right away
MEDIUM: accept and track with ticket
LOW/INFORMATIONAL: trend monitoring.
Context is KEY here: if you have a SQL Injection CVE in a package that your environment does NOT use, your response will be quite different from that of the SQL Injection in your Web Framework.

3. Utilizing Defense-in-Depth Is Beneficial

Multiple layers of security caught issues: ECR Scan caught OS vulnerabilities, Trivy was able to catch application dependencies within an organization, and Inspector caught runtime issues.
Network isolation limited lateral movement by exploiting a single security incident.
IAM least-privilege limited the blast radius on a credential leak situation.

4. Secrets Management Is Important

Never keep secrets in environment variables (you can view them in logs, console, etc.)
AWS Secrets Manager integration with ECS is straightforward; rotating secrets regularly (e.g., every 90 days) is best practice. 5. Operational Lessons

** Read-Only File Systems can create issues for Applications**

Many applications rely upon writing to /tmp.
Therefore, it is recommended that you mount tmpfs volumes to isolate temporary data.

"mountPoints": [
     {
       "sourceVolume": "tmp",
       "containerPath": "/tmp",
       "readOnly": false
     }
   ],
   "volumes": [
     {
       "name": "tmp",
       "host": {}
     }
   ]

6. The Importance of Health Checks

Implement proper health checks (a response code of '200' isn't a true indicator of health).
Check the database for connectivity and external service health.

7. Considerations for Logging

A structured logging format (such as JSON) allows for easier search and analysis of logs,the usage of trace IDs provides a means to correlate requests between systems, application logs should be separated from access logs, and use retention policies for logs (we maintain our application logs in CloudWatch for 30 days and for 7 years in S3).

8. Cost-Effective Practices

ECR image scanning is free the first time it is pushed to the ECR repository on a given day, however if enhanced image scanning is performed it costs $0.09 per image/month (this is well worth the cost), CloudWatch Logs Insights query charges (the cost of running these queries) will eat up your costs so caching is helpful when running frequently used query patterns, Fargate Spot pricing provides an opportunity to save 70% for workloads that are not time-critical.

Lessons Learned in CI/CD

9. Deployment Speed versus Security

The CI/CD pipeline takes between 8-12 minutes (build: 3m, scan: 2m, deploy: 5m) this is acceptable for production systems however, it is not acceptable to sacrifice security for speed. To accommodate faster iteration times, take advantage of dev environments with relaxed security policies.

10. Rollback Planning

When a deployment fails the ECS circuit breaker will auto roll back the deployment, always retain previous versions of the task definitions, use Blue/Green deployments for critical services, and always test your rollback plans in advance

Lessons Learned on Architecture

11. Isolated Services:
Each microservice has its own ECR repository.
Each service has its unique IAM Task Role.
Services communicate using ALB/API Gateway only.
This limits the potential effects of a compromised service on other services.

12. Monitoring is Mandatory:

An Alarm should be set before incidents occur.
Alerts should be generated for security events such as unusual traffic, failed authentication attempts...
Weekly review meetings for security findings.
AWS Security Hub is used to provide a centralised monitoring service.

My Ten Best Security Practices

Your Practice: How Is It Applied?

Scan for vulnerabilities on each push and catch issues when they start. Use the ECR scan-on push feature and GitHub actions integrated into your existing DevOps pipeline.
Set up automated scans to catch high-severity vulnerabilities in the continuous integration/continuous deployment process.
Limit the ability of services to cause harm if compromised. Create separate task roles for each service for least privilege IAM practices.
Reduce the attack surface by placing services in private subnets with no public IP addresses and utilizing NAT gateways for outbound internet access.
Use non-root container images to prevent privilege escalation. Use a user ID of 1001 in your Dockerfiles.
Use immutable infrastructure (e.g., Fargate) for consistent infrastructure that is auditable and reproducible. This includes using task definitions in Git.
Encrypt all data at rest and in transit using KMS (Key Management Service) for protected Amazon ECR repositories, logs, and secrets.
Enable Structured JSON logs (with trace IDs) to allow you to investigate more thoroughly when a security incident occurs.
Use CloudWatch alarms and AWS Inspector to enable quick reporting and to monitor your environment.
Stay ahead of the current threat landscape by using automated tools for dependency management (such as Dependabot) and by updating base container images through a regular monthly schedule.

What I did wrong, For You To Avoid Making The Same Mistakes
Assigned each service equal IAM role access to everything - If a service gets compromised, it gains access to everything. Fixed this issue by creating IAM roles per service.
Did not set log retention amount of time - The CloudWatch Logs bill was unbelievable. Therefore, I set a 30-day retention period for all log groups.
Did not consider image layer caching - My initial Dockerfiles took 15 minutes to build. So, I changed the order of COPY commands around to optimize the cache layers.
Deployed to Production from a local computer one time - I started to think, "just this one time". This eventually led to a pattern. We enforce all production deployments through GitHub Actions.
I ignored my MEDIUM vulnerabilities - They accumulated to over 200. Now, we are tracking and solving these quarterly.

In summary
When I first began this project, I anticipated that security would be measures to the speed of our work. I was incorrect.
The implementation of Automatic Container Security has actually improved the speed of deployment for us:
We were able to eliminate the "security review" bottlenecks.
Our Development Team was able to find problems in CI before they made their way to production.
The overall number of incidents that required solutions decreased and therefore we spent less time on development.
Compliance audits have become easy because we have access to all of the necessary logs, scans, and configurations in documented form.

By The Numbers:

In the past 6 months, we have experienced Zero production security incidents that were caused by vulnerabilities in containers.
Our average deployment time (including all security checks) is 8 minutes.
100% of Images were scanned for vulnerabilities prior to deployment.
Average 15 minutes / Deployment Saved because there was no manual review needed.
2 hours a week were saved due to the elimination of a need for security meetings.

Advice I would give my former self:
When you start a project like this, you must begin with security in mind.
It is far more difficult to ,manage security than it is to build security in from the beginning.
AWS has fantastic tools (ECR Scanning, Fargate Isolation, IAM) that do all of the "heavy lifting" for you; you just have to properly configure and integrate them.

Resources That Helped Me

AWS ECS Security Best Practices
ECR Image Scanning Documentation
Fargate Security Guide
GitHub Actions for AWS
Container Security by Liz Rice

Final Thoughts

Automating security makes it almost transparent to most developers while providing security for your production infrastructure.
By using AWS Fargate and GitHub Actions, you can build a secure pipeline as part of your deployment process without having to manage that infrastructure yourself.

After following this guide, you can also create an automated container security pipeline. You can use these examples of code to get started and customize them as necessary.

If you have any questions, comments or war stories to share regarding this guide, I would love to hear from you! You can post a comment here or connect with me on social media. Together we can work towards providing a more secure AWS ecosystem!

Connect with me

• Portfolio: https://khanalsamir.com

• GitHub: https://github.com/Shawmeer

• LinkedIn: https://linkedin.com/in/samir-khanal

If you're working on similar DevOps or AWS projects, feel free to connect. I regularly share practical cloud and CI/CD content.

Building Production-Grade Microservices on AWS ECS Fargate with GitLab CI/CD Automation

Samir Khanal — Fri, 12 Dec 2025 07:17:50 +0000

1. Introduction

Nowadays, applications are moving towards microservices because of their scalability, rollback deployment, and faster development.
But with the growing number of services, deployment pipelines have become:

Slow (like updating all services on every commit)
Hard to manage (multiple pipelines for a single service)
This was causing problems (manual deployments, Docker images being inconsistent, etc.).

I combined AWS Elastic Container Service (ECS) Fargate and Amazon ECR, combined with GitLab CI/CD, which made the pipeline deploy only the service which was changed.

In this guide, I have created an actual production-ready microservices deployment system with:

ECS Fargate for serverless containers
Five microservices: billing, client_app_api, driver_api, odmu_auth, odmu_contractual
Amazon ECR as an image registry for containers
ALB (Application Load Balancer) with multiple target groups
GitLab CI/CD with folder based triggers
Terraform for infrastructure as code
CloudWatch for monitoring

By the end, you’ll have:

Independent deployments per microservice
Folder-based Automated CI/CD
Production grade ECS services
Scalable, secure, monitored architecture
No manual SSH or PM2

The Real Problem

When I was previously working with ECS, every change in code triggered a full redeployment of all services, although the change was in one service folder. It caused unnecessary downtime and more deployment times, and rollback was risky. I also faced Docker image drift in various environments.

I found a solution

Only the service that changes is rebuilt and deployed
Each service remains fully isolated
Deployments are repeatable and predictable

2. ARCHITECTURE:

Key Components

Component	Purpose
ECS Fargate	Serverless containers (no EC2 management)
ECR	Private container registry
ALB	Routes incoming traffic to the right microservice
CloudWatch	Logs and metrics
Terraform	Infrastructure provisioning
GitLab CI/CD	Automated container build and deployment

Why ECS Fargate?

No EC2 provisioning or patching
Auto-scaling built-in
Secure
Suits for microservices

3. Microservices Structure

Repo Structure:

services/
 ├── billing/
 ├── client_app_api/
 ├── driver_api/
 ├── odmu_auth/
 └── odmu_contractual/
.gitlab-ci.yml
terraform/

Each microservice has:

Its own Dockerfile
Its own business logic
Its own task definition
Its own ECS service

4. Dockerizing the Microservices

Example Dockerfile for client_app_api:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .
EXPOSE 3000

CMD ["node", "server.js"]

I used different ports for each microservice:

Service              Port
billing              3001
client_app_api       3000
driver_api           3002
odmu_auth            3003
odmu_contractual     3004

5. Creating ECR Repositories

Account ID: 745812456855
Region: us-east-1

aws ecr create-repository --repository-name billing
aws ecr create-repository --repository-name client_app_api
aws ecr create-repository --repository-name driver_api
aws ecr create-repository --repository-name odmu_auth
aws ecr create-repository --repository-name odmu_contractual

Build and Push (example: billing)

docker build -t billing ./services/billing

docker tag billing:latest \
  745812456855.dkr.ecr.us-east-1.amazonaws.com/billing:latest

aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS \
  --password-stdin 745812456855.dkr.ecr.us-east-1.amazonaws.com

docker push \
  745812456855.dkr.ecr.us-east-1.amazonaws.com/billing:latest

6. ECS Fargate: Task Definition (Terraform)

Example for the billing microservice:

resource "aws_ecs_task_definition" "billing" {
  family                   = "billing-task"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "512"
  memory                   = "1024"

  execution_role_arn = "arn:aws:iam::745812456855:role/ecsTaskExecutionRole"

  container_definitions = jsonencode([
    {
      name  = "billing"
      image = "745812456855.dkr.ecr.us-east-1.amazonaws.com/billing:latest"

      portMappings = [{
        containerPort = 3001
        protocol      = "tcp"
      }]

      essential = true
    }
  ])
}

Similar type for all microservices.

7. Application Load Balancer Routing

Each microservice has a separate target group:

Service	Target Group Name	Path Pattern
billing	tg-billing	/billing/*
client_app_api	tg-client	/client/*
driver_api	tg-driver	/driver/*
odmu_auth	tg-auth	/auth/*
odmu_contractual	tg-contract	/contract/*

Security Considerations

Security was a first-class concern in this design.

Each ECS task runs with VPC networking. Each ECS task has ENI-level network isolation.
Containers cannot be accessed via SSH; therefore, all deployments take place through CI/CD.
IAM task execution roles are created following the principle of least privilege.
All container images are stored in private ECR repositories on Amazon.
The ALB serves as the only public access point to ECS, and all services remain in a private subnet inside the VPC.

Terraform example:

resource "aws_lb_target_group" "billing" {
  name        = "tg-billing"
  port        = 3001
  protocol    = "HTTP"
  target_type = "ip"
  vpc_id      = var.vpc_id
}

GitLab CI/CD: Folder-Based Deployments This is the most important section. Instead of running one giant pipeline or manually using SSH/PM2, I configured the GitLab yml file to only deploy the service that changed.

stages:
  - build
  - deploy

# ----------------------------
# Billing Microservice
# ----------------------------
build_billing:
  stage: build
  only:
    changes:
      - services/billing/**
  script:
    - docker build -t billing ./services/billing
    - docker tag billing:latest 745812456855.dkr.ecr.us-east-1.amazonaws.com/billing:latest
    - aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 745812456855.dkr.ecr.us-east-1.amazonaws.com
    - docker push 745812456855.dkr.ecr.us-east-1.amazonaws.com/billing:latest

deploy_billing:
  stage: deploy
  only:
    changes:
      - services/billing/**
  script:
    - aws ecs update-service \
        --cluster production-cluster \
        --service billing-service \
        --force-new-deployment

9. Monitoring & Observability (CloudWatch)

Logs appear under:

/ecs/billing
/ecs/client_app_api
/ecs/driver_api
/ecs/odmu_auth
/ecs/odmu_contractual

Create log groups:

aws logs create-log-group --log-group-name /ecs/billing
aws logs put-retention-policy --log-group-name /ecs/billing --retention-in-days 7

CPU Alarm:

aws cloudwatch put-metric-alarm \
--alarm-name BillingCPUHigh \
--metric-name CPUUtilization \
--namespace AWS/ECS \
--statistic Average \
--period 300 \
--threshold 80 \
--comparison-operator GreaterThanThreshold \
--dimensions Name=ServiceName,Value=billing-service \
--evaluation-periods 2 \
--alarm-actions arn:aws:sns:us-east-1:745812456855:NotifyTeam

Effects and Outcomes of Implementing New Architecture

By deploying this architecture I was able to:

Reduce deployment time, since only those services that had their code changed must be rebuilt.
Allow teams to deploy their microservices independently of one another.
No need to deploy via SSH using PM2.
Create a more predictable and safer rollback process.
Provide for reuse of the same Terraform modules in all target environments.

With the increasing number of services, it became clear that this architecture can be scaled successfully.

10. Lessons Learned:

Here are some of the lessons I learned from building this system:
✔Keep microservices fully isolated
The Docker images, task definitions and ALB routes need to be decoupled.
✔ Use folder-based CI/CD
It reduces deployment times so much.
✔ Choose ECR instead of using public registries
It works well with ECS.
✔ Allocate the right CPU & Memory
Under-provisioning leads to throttling.
Over-provisioning wastes money.
✔ Terraform modules save weeks
When multiple environment setups are in question, reusability is the key.
✔ With this CloudWatch setu you get 80% of your monitoring
Later, add Prometheus or Grafana Cloud.

11. Conclusion

Containers are the foundation of modern infrastructure, and AWS ECS Fargate enables you to run microservices without managing servers. Mixed with GitLab CI/CD and Terraform, you have a scalable, automated, production-grade workflow.
This architecture ensures:

Fast, independent deployments
Secure and isolated workloads
ALB with Fargate for high availability
Complete observability via CloudWatch
Infrastructure is defined as code

If you are deploying microservices on AWS and experiencing slow or high risk deployments, this might be a good working solution validated across real-world environments with the increasing number of services.

If you enjoyed this post, please share it on your favourite social network and get in touch if I can help with anything. Feel free to reach out if you’d like to chat about AWS, DevOps, or container architectures.

Connect with me

• Portfolio: https://khanalsamir.com

• GitHub: https://github.com/Shawmeer

• LinkedIn: https://linkedin.com/in/samir-khanal

If you're working on similar DevOps or AWS projects, feel free to connect. I regularly share practical cloud and CI/CD content.

Title: Exploring the DevOps Mindset: Why It’s More Than Just Tools

Samir Khanal — Sun, 07 Dec 2025 07:33:39 +0000

Body:

In today’s fast-paced software world, DevOps is often mistaken as a set of tools or a job title. In reality, DevOps is a mindset — a way of thinking that emphasizes collaboration, automation, and continuous improvement across development and operations.

Collaboration Over Silos

DevOps encourages developers and operations teams to work together, breaking down barriers that slow down delivery. This collaboration helps detect issues early and accelerates software deployment.

Automation is Key

From CI/CD pipelines to automated monitoring, automation reduces human error and ensures that repetitive tasks are handled consistently. Tools like Jenkins, GitLab CI/CD, and AWS CodePipeline are just enablers — the mindset is what drives the improvement.

Continuous Learning

DevOps isn’t static. Teams must adapt, learn, and experiment continuously to improve processes and enhance software quality. Metrics, feedback loops, and retrospectives are essential to growth.

The Bigger Picture

Ultimately, DevOps is about delivering value to end-users faster and reliably. Tools and technologies are secondary — the culture and mindset are what truly make a difference.

Conclusion:
Adopting a DevOps mindset transforms the way teams think about software delivery. It’s not just about writing code or deploying servers — it’s about improving collaboration, automation, and customer value continuously.

Serverless Computing: From Basics to Advanced Concepts

Samir Khanal — Sun, 07 Dec 2025 03:58:54 +0000

Why Serverless Matters

I honestly thought "serverless" was just another buzzword when I first heard it. How can a serverless thing be if there are clearly servers? However, after digging into AWS, I came to understand that it's not about the tech; it's a new way of doing things that changes the whole app-building paradigm.
Here's the thing that confused me the most: I thought serverless meant "no servers at all" (which is incorrect), and that everything should be serverless (which is also incorrect). This blog is all about the journey of my understanding — from being puzzled to getting it.

What Serverless Actually Means
'Serverless' means that you don't bother with the servers and continue with writing code.
To explain it, one can compare it to Uber vs. car ownership:
When you have a car, you take care of maintenance, insurance, and parking.

With Uber, you simply state your destination.

Serverless is similar to Uber, but for computing. Instead of asking whether there are servers, you focus on what your function needs to do. You handle the logic layer, not the hardware layer.

AWS Lambda: The Heart of Serverless
Lambda runs your code on an event without requiring server setup.
How it works:
You write a function (Python, Node.js, Java, etc.)

An event triggers it (API call, file upload, timer)

Lambda executes in milliseconds

You pay only for execution time

The first time I ran Lambda, I couldn’t believe it — no EC2, no load balancers. Just code → event → execution.
Lambda changed the way I work: instead of building big systems, I write small functions that “listen” to events.
The pay-as-you-go model is great, especially the 1M free requests per month.

Core Serverless Services

API Gateway
Creates HTTP APIs that trigger Lambda.
Flow:
User → API Gateway → Lambda → Response
DynamoDB
AWS's fully managed NoSQL database.
Fast (single-digit ms), scalable, and a perfect partner for Lambda.
S3 + CloudFront
Great for storing and delivering content at scale.
I once built a system where:
Uploading an image to S3 triggered a Lambda

Lambda resized the image
No servers involved at all.

SNS, SQS, EventBridge These services enable communication between systems. SNS → Pub/Sub

SQS → Reliable queueing

EventBridge → Event routing and filtering

They help build event-driven, fault-tolerant systems.

Step Functions Connect multiple Lambdas for workflows needing retries, error handling, or branching logic.

Common Architecture Patterns

Simple API
User → API Gateway → Lambda → DynamoDB
I built this in a day, and it scaled automatically.
Event Processing
S3 Upload → Lambda → Processing
No polling, fully automated.
Async Workflows
API → SQS → Lambda
Allows background processing while returning immediate responses.

My Key Learnings

Challenge 1: Traditional Thinking Didn’t Work
I tried building traditional architectures using serverless.
Breakthrough: Serverless = small, event-driven tasks.

Challenge 2: Cold Starts Confused Me
Response fluctuated from 50ms to 3 seconds.
Breakthrough: Cold starts happen during initialization. After that, performance stabilizes.

Challenge 3: Debugging Felt Blind
No servers to SSH into.
Breakthrough: CloudWatch logs everything automatically.

What Helped Me the Most

Actually building things.
Deploy functions, break them on purpose, connect services.
Hands-on experience makes everything clearer.

Best Practices

Limit Lambda package size

One function = one responsibility

Think in terms of events

Secure IAM roles (least privilege)

Use CloudWatch & X-Ray from day one

Prepare for failure with retries, DLQs, and timeouts

Advanced Concepts

Step Functions
Great for multi-step processes, parallel branches, and complex orchestration.

Cold Start Optimization
Keep the package small

Use Provisioned Concurrency

Choose faster runtimes
Most apps don't need serious optimization.

When Not to Use Serverless
Long-running processes

Persistent high-concurrency connections

Workloads needing special hardware

Constant heavy traffic where servers are cheaper

How Serverless Changed My Thinking

Serverless shifted my mindset:
Focus on business logic

Think in events, not servers

Plan for automatic scaling

Prefer small, separate components

Yes, I struggled with debugging, IAM, and cold starts — but each taught me something crucial.

Final Thoughts

My advice: just build something.
Deploy an API.
Create an S3 trigger.
Break things and learn from them.
AWS Free Tier is generous, the docs are solid, and the community helps a lot.
At the end of the day, servers still exist — but you don’t have to care about them anymore. That's the whole point.
The Serverless journey you faced is intriguing. Share your experiences to find solutions together.

Host Vite Frontend on AWS S3 and CloudFront with SSL and Custom Domain 2025(Step-by-Step Guide)

Samir Khanal — Wed, 19 Nov 2025 15:04:44 +0000

If you are looking for a quick, secure, and inexpensive method to host Vite frontend on AWS S3 AND Cloudfront , you are in the right place! In this step-by-step guide I will detail for you how to:

– Deploy a vite frontend on an AWS S3 bucket
– Serve it globally via AWS CloudFront
– Secure it with SSL/HTTPS
– Connect it to a custom domain using Route 53

With this set-up you will enjoy fast page loading times, global availability, and industry standard security using scalable AWS services.

Prerequisites
A Vite frontend project (Node.js based)
An AWS account with permissions for S3, CloudFront, Certificate Manager, and Route 53)
STEPS
1.Clone your project
git clone your-repo-url
cd your-project-folder
2.Building your vite project:
Go to your root directory of project and run the following command:

npm install
npm run build
In my case it was : npm vite build

This command generates optimized production files, typically in a dist folder in your project.

Setting Up an S3 Bucket: Go to the S3 Console. Click Create bucket. Enter a unique bucket name (e.g., vite-frontend-bucket). Choose a region close to your target audience. Uncheck Block all public access, then confirm. Click Create bucket.

4.Upload Your Files to your S3 bucket.
Click on your newly created bucket in the S3 Console.

Go to the Objects tab and click Upload.
Drag and drop the contents of the dist folder (not the folder itself) into the upload area.
Click Upload.

Enable Static Website Hosting Go to the Properties tab of your bucket. Scroll down to the Static website hosting section. Click Edit and enable static website hosting. Set the Index document to index.html. Save the changes.
Configure Bucket Permissions
Go to the Permissions tab of your bucket.
Scroll to the Bucket policy section and click Edit.
Add the following policy (replace your-bucket-name with your bucket’s name):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket-name/"
}
]
}
Save Changes.
Test the S3 Static Website
Go to the Properties tab and scroll down to the Static website hosting section.
Copy the Endpoint URL and open it in your browser.

Your Vite project should load!

Set Up CloudFront for Your S3 Bucket Go to the CloudFront Console. Click Create Distribution. Under the Origin section: Select S3 bucket as the origin. Choose your bucket from the dropdown. 4.Set the Default cache behavior:

Viewer Protocol Policy: Redirect HTTP to HTTPS.
5.Add an Alternate Domain Name (CNAME) if you plan to use a custom domain.

Click Create Distribution.

Restrict Bucket Access to CloudFront

Go back to your S3 bucket and open the Permissions tab.
Remove the public access permissions you set earlier.
Add the CloudFront OAC to allow only CloudFront to access your bucket.
9.Get an SSL Certificate
Go to the Certificate Manager service.
Click Request a certificate.
Choose Request a public certificate and click Next.
Enter your domain name (e.g., www.example.com) and click Add another name to include the root domain (example.com).
Choose DNS validation and click Request.
Validate the Certificate

Go to Route 53 and open the hosted zone for your domain.
Add the DNS records provided by the Certificate Manager.
Wait until the certificate status changes to Issued.

Or you can do it in the same page.

Link CloudFront with Your Domain Open your CloudFront distribution. Go to the General tab and click Edit. Add your domain name (e.g., www.example.com) in the Alternate Domain Names (CNAMEs) field. Select the SSL certificate you created in the Custom SSL Certificate section. Save the changes. Update Route 53

Go to Route 53 and open the hosted zone for your domain.
Add an A Record:
Record name: www (or leave it blank for the root domain).
Alias: Yes.
Target: Select your CloudFront distribution.
3. Save the record.

11: Test Your Setup
Open your browser and navigate to your domain (e.g., https://www.example.com).
Verify that your Vite project loads correctly over HTTPS
12: Conclusion
Congratulations! You’ve successfully hosted your Vite frontend project on AWS S3, served it with CloudFront, secured it with an SSL certificate, and connected it to your custom domain using Route 53. With this setup, your site is fast, secure, and ready for global traffic.

With this setup, you’ve successfully learned how to host your Vite frontend on AWS S3 and CloudFront with full HTTPS support and a custom domain — a fast, secure, and scalable way to deploy modern web apps.

FAQ: Hosting Your Vite Frontend with AWS S3, CloudFront & Route 53

Why should I use AWS S3 and CloudFront to host my frontend?
Great question! S3 is a super reliable and affordable way to store static files like HTML, CSS, and JavaScript. Pair it with CloudFront, and your site gets delivered from servers all around the world, making it fast for users no matter where they are. Add in Route 53 for custom domains and SSL for security, and you’ve got a professional, secure setup that scales easily.
How do I update my site after it’s live?
It’s simple: just make your changes, then run npm run build to generate the latest version of your site. Upload the new files from your dist folder to your S3 bucket. If you’re using CloudFront, don’t forget to invalidate the cache so visitors can see the latest version immediately.
What’s the difference between using the S3 website link and CloudFront?
The S3 website URL works fine, but it doesn’t support HTTPS by itself—which is a deal breaker these days. CloudFront not only brings HTTPS support (via SSL certificates), but it also speeds up your site with caching and global delivery.
How can I get HTTPS (SSL) working with my custom domain?
AWS has a free tool called Certificate Manager. Just request a certificate for your domain, verify it using Route 53 DNS records, and then attach that certificate to your CloudFront distribution. Once that’s done, your site will be secure with HTTPS.
How long does it take for DNS changes to show up?
Usually just a few minutes, but it can sometimes take up to 48 hours to fully update across the internet. If it’s not showing right away, give it a bit of time and try clearing your browser cache.
I’m seeing errors when I load my site. What should I check?
Here’s a quick checklist:

Did you invalidate the CloudFront cache after updating?

Are your S3 permissions set correctly for CloudFront to access your files?

Is your index.html file uploaded and named correctly?

Are your DNS records in Route 53 pointing to the right place?

Is your SSL certificate properly attached in CloudFront?

Go through those steps, and most issues can be sorted out pretty quickly.

Need a Hand?
Setting this all up can take time and attention to detail. If you’re looking for a partner to manage AWS deployments or streamline DevOps, Cloudlaya is here to help.

Yoy May Find these Blog Useful.

7 Powerful AWS NOVA Gen AI Tools That Make AI Work For You (No Coding Required!)

AWS PartyRock: Showcasing the Creativity of Artificial Intelligence

Delivering High-Performance OTT Streaming with Amazon CloudFront