DEV Community: Tanushree Aggarwal

20 Years, Infinite Objects: The Amazon S3 Story

Tanushree Aggarwal — Sat, 14 Mar 2026 17:46:45 +0000

🪣 An Ode to Amazon S3

Some technologies shout about their greatness. Others just… store the internet.

Amazon S3 belongs firmly in the second category.

Launched on 14-March-2006 with a simple promise — store anything, retrieve it anytime — S3 has spent the last two decades becoming the unsung hero of the cloud. Photos, backups, data lakes, ML datasets, logs, websites… if it lives in the cloud, there’s a decent chance it lives in an S3 bucket.

And like any 20-year journey, the story of S3 is filled with innovation, lessons learned, and a few “well, that was interesting” moments.

20 Years of Quietly Running the Internet.

Let’s take a nostalgic walk through the milestones:

🚀 2006 – Amazon S3 Launch

Announced as "storage for the internet", designed to make web-scale computing easier for developers, it supported REST, SOAP, and BitTorrent protocols. Storing 1 GB of data for 1 month costed just 15 cents, while transferring data in-and-out of the system costed 20 cents per GB!

🌍 2007 – S3 in Europe

S3 expanded outside US, with its first region Europe, reducing latency and making cloud storage truly global. For European developers, this meant their data didn’t have to take a transatlantic vacation every time an application accessed it.

⚠️ 2008 – The Famous S3 Outage

While the announcement of Amazon S3 storage price reduction attracted more customers, a major outage briefly reminded everyone that even cloud infrastructure can have bad days!

🌐 2009 – CloudFront Integration

Integration with Amazon CloudFront allowed S3 to power global content delivery. Suddenly S3 wasn’t just storage—it became the engine behind faster websites, media streaming, and global apps. Requests originating anywhere in the world were routed to one of 14 edge locations (8 in the United States, 4 in Europe, and 2 in Asia). By the end of 2009, Amazon CloudFront that the ability to limit access to Amazon S3 content using Origin Access Identity (OAI).

💰 2010 – Reduced Redundancy Storage
The Standard Storage Class now provided 99.999999999% durability.
AWS introduced Reduced Redundancy Storage for data that didn’t need the full durability treatment and provided 99.99% durability.
In simple terms: “Cheaper storage for stuff you wouldn’t cry about losing.”

📦 2010 – Multipart Upload

Multipart upload allowed large files to be uploaded in pieces simultaneously.
Anyone who has ever tried uploading a massive dataset over a flaky connection knows how revolutionary this felt—finally, uploads that don’t restart from zero.

2010 brought with it a lot of features still available to us - support for bucket policies to set access control for buckets. S3 accessible via the AWS Management Console, AWS Cloud Free Tier allowing storing up to 5GB of data free of charge, but most importantly - support for storing large objects up to 5TB in size.

🌎 2011 – Static Website Hosting

S3 suddenly gained the ability to host static websites directly from buckets. Developers realized they could run websites without servers, and a whole generation of lightweight web apps was born.

🔐 2011 - AWS Identity and Access Management (IAM)
IAM was Generally Available, and management features of Amazon S3 are officially available

⚙️ 2011 – Lifecycle Policies

Lifecycle rules automated the movement or deletion of data based on age or usage.
For engineers drowning in storage bills, this felt like hiring a very responsible robot janitor for your buckets.

🧊 2012 – Amazon S3 Glacier

The arrival of Amazon S3 Glacier brought ultra-cheap archival storage to the cloud, without compromising the durability!
Companies that once stored tapes in warehouses suddenly realized they could archive decades of data without needing forklifts.

🌍 2012 – Cross-Origin Resource Sharing (CORS)

CORS support allowed web applications from different domains to safely fetch resources from S3. It quietly enabled modern web architectures where APIs, apps, and assets live in different places but work together seamlessly.

🧾 2013 – CloudTrail Logs to S3

The announcement of AWS CloudTrail, a web service that could records API calls made on your account and delivers log files to your Amazon S3 bucket. Just like that, S3 became the default vault for security logs, audits, and compliance data.

🗂 2014 – Lifecycle Management of Versioned Objects

S3’s Lifecycle Management integrated S3 and Glacier and made the details visible via the Storage Class of each object. You could set up a simple Lifecycle rule using the AWS Management Console.

🔔 2014 – Event Notifications

Support for event notifications to trigger events to Amazon SNS, Amazon SQS, AWS Lambda - whenever objects were created or modified. Suddenly storage became interactive, kicking off serverless pipelines and automation workflows.

🔎 2014 – Server-Side Encryption with Customer Keys

SSE-C allowed customers to supply their own encryption keys. Security teams everywhere collectively nodded and said: “Now we’re talking.”

🔐 2015 – S3 VPC Endpoint

VPC endpoints allowed private connections between S3 and workloads inside a VPC. Data could now move without touching the public internet, which made security architects sleep noticeably better at night.

2015 also brought along another key feature - cross-region replication

⚡ 2016 – Transfer Acceleration

Transfer Acceleration used AWS’s global edge network to speed up uploads. If you’ve ever uploaded huge files across continents, you know this feature felt like someone secretly upgraded your internet connection.

🧠 2017 – Amazon Macie for S3

Amazon Macie began scanning S3 buckets for sensitive data using machine learning. Finally, a system that could say: “Hey… maybe storing credit card numbers in that bucket wasn’t the best idea.”

🛡 2018 – Block Public Access

Block Public Access was introduced to prevent accidental exposure of buckets. Let’s just say this feature has saved countless engineers from awkward security incidents.

🧠 2018 – Intelligent-Tiering

Intelligent-Tiering automatically moves objects between storage tiers based on usage patterns.
Translation: S3 started optimizing your storage bill while you slept.

📊 2018 – One Zone IA

One Zone Infrequent Access offered lower-cost storage in a single availability zone. Perfect for secondary backups or data that doesn’t need the full multi-AZ treatment.

🎯 2019 – S3 Access Points

Access Points simplified permission management for large shared datasets. For organizations with thousands of users and applications, this was like finally organizing a chaotic storage closet.

⚡ 2020 – Strong Consistency

S3 introduced strong read-after-write consistency across all regions. For developers, this was a huge moment—one of the most annoying distributed system edge cases simply disappeared.

🌎 2021 – Multi-Region Access Points

Multi-Region Access Points allowed applications to access replicated data across regions through a single endpoint. Global applications suddenly became easier to build—and far more resilient to regional outages.

💾 2022 – AWS Backup for S3

Integration with AWS Backup allowed centralized backup policies for S3. Because when it comes to data, the only thing better than storage… is having a backup of that storage.

🚀 2023 – S3 Express One Zone

S3 Express One Zone introduced ultra-low latency storage for high-performance workloads. For AI pipelines and analytics systems, this meant faster data access and happier GPUs.

🤖 2024 – Amazon S3 Tables

S3 Tables introduced native tabular storage optimized for analytics workloads. This pushed S3 deeper into the world of modern data lakes and large-scale analytics platforms.

📦 2025 – Maximum Object Size Increased to 50 TB

A major announcement at re:Invent 2025 - the maximum object size increased to 50 TB. At this point, uploading a single object to S3 could basically mean “store an entire dataset in one go.”

🌐 2026 – Account Regional Namespaces
Just a day before the 20th birthday, the announcement dropped like a perfect pain patch — removing the age-old friction of checking if your bucket name is already taken before you can start storing data.
With this feature, you can predictably name and create general purpose buckets in your own account regional namespace by appending your account’s unique suﬃx in your requested bucket name, meaning you can now create general purpose bucket names across multiple AWS Regions with assurance that your desired bucket names will always be available for you to use!

Conclusion - ☁️ The Service That Quietly Holds the Internet

Amazon S3 rarely gets flashy headlines. It doesn’t launch new phones or social networks.

But behind the scenes, it stores trillions of objects and exabytes of data powering applications across the world.

From startups to global enterprises, from static websites to AI training datasets—S3 has been the quiet backbone of the cloud revolution.

And after 20 years, one thing is pretty clear:

The internet may run on code… but a lot of that code runs on S3.

Which S3 feature do you think changed cloud architecture the most? Drop your thoughts in the comment section!

Bonus

Checkout the original S3 release announcement and Jeff Barr's blogpost from 2006!

https://aws.amazon.com/about-aws/whats-new/2006/03/13/announcing-amazon-s3---simple-storage-service/

https://aws.amazon.com/blogs/aws/amazon_s3/

Observability-Driven Kubernetes: A Practical EKS Demo

Tanushree Aggarwal — Sat, 20 Dec 2025 16:22:34 +0000

Introduction : EKS Observability Platform 🖥️

As cloud-native systems continue to grow in complexity, many organizations depend on Kubernetes to run and scale their containerized applications. While Kubernetes is powerful, managing distributed workloads often comes with limited visibility, making it difficult to detect issues before they impact the business. The real challenge isn’t just deploying applications to a Kubernetes cluster—it’s understanding how those applications are performing, how resources are being used, and whether the system is healthy overall. In today's blog we look at how building an observability-first Amazon Elastic Kubernetes Service (EKS) platform can help solve these challenges through better monitoring, automated scaling, and early detection of potential incidents.

This project aims to demonstrates how we can design, provision, and operate a production‑style, observability‑first Kubernetes platform on Amazon EKS, using Terraform as the platform definition layer.
The focus is Day‑2 operations: metrics, autoscaling, failure recovery, and clean platform boundaries — not just deploying containers.

Project Goals 🤖

Build a true 3‑tier architecture on EKS (Frontend → API → Platform Services)
Provision infrastructure using modular Terraform
Deploy Prometheus + Grafana before workloads
Demonstrate autoscaling and self‑healing with live metrics
Serve as a GitHub portfolio project for platform engineering

What This Project Demonstrates 💭✏️

Production‑style Terraform design
Observability‑driven operations
Safe autoscaling practices
Kubernetes self‑healing behavior
Platform engineering mindset

Project Structure 📋

.
├── providers.tf
├── versions.tf
├── variables.tf
├── main.tf
├── outputs.tf
├── modules/
│ ├── vpc/
│ ├── eks/
│ ├── observability/
│ └── apps/

Each Terraform module represents a platform responsibility boundary.

Infrastructure (Terraform)

VPC Module: Creates networking foundation with public/private subnets
EKS Module: Deploys managed Kubernetes cluster (v1.32) with:
- 2-4 worker nodes (t3.medium instances)
- Public/private API endpoint access
- IAM Roles for Service Accounts enabled
- Cluster creator admin permissions
Application Stack
- Frontend: containous/whoami service showing request details
- API: hashicorp/http-echo returning "Hello from API"
- Resource Limits: CPU/memory constraints for autoscaling
- HPA: Horizontal Pod Autoscaler (2-6 replicas, 50% CPU threshold)

Observability Stack
- Prometheus: Metrics collection via kube-prometheus-stack Helm chart
- Grafana: Visualization dashboards for:
  - Kubernetes cluster metrics
  - Pod/deployment monitoring
  - CPU/memory utilization
  - Autoscaling events

Implementation Guide 🎨

Step 1: Network Foundation (VPC Module)

Why: EKS must run in private subnets for production‑grade security.

Create VPC with public + private subnets
Enable NAT Gateway for outbound traffic
Keep networking isolated from workloads

Key takeaway: 🌟 Networking is platform infrastructure, not app concern. 🌟

Step 2: EKS Cluster Provisioning

Why: Managed control plane + managed node groups reduce operational load.

Provision EKS cluster
Create managed node group
Expose cluster endpoint and credentials for providers

Key takeaway: 🌟 Platform teams optimize for operability, not customization. 🌟

Step 3: Observability‑First Setup

Why: You cannot safely scale or debug what you cannot see.

Create dedicated observability namespace
Install kube‑prometheus‑stack via Helm
Deploy Grafana and Prometheus before apps

Key takeaway: 🌟 Observability is foundational infrastructure. 🌟

Step 4: Application Namespaces

Why: Namespace isolation simplifies ownership and RBAC later.

Create apps namespace
Keep workloads separate from platform tooling

Key takeaway: 🌟 Logical isolation improves long‑term operability. 🌟

Step 5: Frontend Tier Deployment

Why: Complete the 3‑tier story, even with a simple UI.

Deploy NGINX frontend
Expose via ClusterIP service
Define resource requests and limits

Key takeaway: 🌟 Even simple workloads deserve resource boundaries. 🌟

Step 6: Backend API Tier Deployment

Why: This tier demonstrates autoscaling and failure recovery.

Deploy lightweight API (http‑echo)
Apply CPU requests/limits
Expose internally via service

Key takeaway: 🌟 Backend services are the primary scaling surface. 🌟

Step 7: Horizontal Pod Autoscaling (HPA)

Why: Scaling without metrics is dangerous.

Configure HPA based on CPU utilization
Define min/max replicas
Observe behavior in Grafana

Key takeaway: 🌟 Autoscaling is a control system, not a checkbox. 🌟

Step 8: Failure Injection (Day‑2 Operations)

Pod Failure

Manually delete an API pod
Observe:
No frontend impact
New pod scheduled automatically
Metrics reflect recovery

Node Failure

Drain a worker node
Observe:
Pods rescheduled
No service interruption

Key takeaway: 🌟 Resilience is observable, not assumed. 🌟

Implementation 🌀

terraform init

terraform validate

terraform plan

terraform apply

Testing ⚡⚡

Login to the AWS Management Console and see the EKS cluster.

Explore a bit to identify the resources created, networking layer etc.

Let us check our frontend service

Check current frontend service:
kubectl get svc -n apps

If no service exists, create one:
kubectl patch svc frontend -n apps -p '{"spec": {"type": "LoadBalancer"}}'
kubectl patch svc api -n apps -p '{"spec": {"type": "LoadBalancer"}}'

Get the external URL:
kubectl get svc frontend -n apps
kubectl get svc api -n apps

Wait for EXTERNAL-IP to show the AWS ELB hostname (takes 2-3 minutes).

Get the hostname directly:
kubectl get svc frontend -n apps -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

kubectl get svc api -n apps -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

Access your frontend
Once you have the hostname, access it in your browser:
http://your-elb-hostname

Access Grafana

kubectl port-forward -n observability svc/kube-prometheus-grafana 3000:80

Open browser:

http://localhost:3000

Username: admin
Password: retrieve from Kubernetes secret

Decode the Grafana admin password:
$password = kubectl get secret -n observability kube-prometheus-grafana -o jsonpath="{.data.admin-password}"





Configure and View dashboards!

Follow same approach for Prometheus:



  
  
  Observe Baseline Metrics


Dashboards to open:


Kubernetes / Nodes
Kubernetes / Pods
Kubernetes / Workloads / Deployment


Confirm:


API replicas = 2
Low CPU usage






  
  
  Generate Load (Autoscaling Demo)


Exec into API pod:

kubectl exec -it deploy/api -n apps -- sh

Generate CPU load:

while true; do :; done

Observe:


CPU spikes in Grafana
HPA scales pods from 2 → 6










  
  
  Pod Failure Injection


kubectl delete pod -n apps -l app=api

Observe:


New pod scheduled immediately
No frontend impact
Metrics show brief dip and recovery


  
  
  Node Failure Injection


List nodes:

kubectl get nodes

Drain one node:

kubectl drain <node-name> --ignore-daemonsets

Observe:


Pods rescheduled
Grafana shows node loss
Service remains available


  
  
  Github Repository






  
    
      
      
        aggarwal-tanushree
       / 
        eks-observability-first-platform
      
    
    
      Personal platform engineering project demonstrating an observability-first 3-tier architecture on Amazon EKS using Terraform, Prometheus, and Grafana.
    
  
  
    


EKS Observability First Platform

A complete Terraform-based solution for deploying an Amazon EKS cluster with built-in observability stack and sample applications.

Description

This project provisions a production-ready EKS cluster on AWS with:


VPC Infrastructure: Custom VPC with public/private subnets across multiple AZs

EKS Cluster: Kubernetes 1.32 with managed node groups

Observability Stack: Prometheus and Grafana via Helm charts

Sample Applications: Frontend and API deployments for testing


Directory Structure


eks-observability-first-platform/
├── modules/
│   ├── vpc/                    # VPC module
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   ├── eks/                    # EKS cluster module
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   ├── observability/          # Prometheus/Grafana stack
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── versions.tf
│   └── apps/                   # Sample applications
│       ├── main.tf
│       ├── variables.tf
│       └── versions.tf
├── main.tf                     # Root module
…

  
  View on GitHub

Key Cost Controls in This Platform 💲:

Right‑Sized Node Groups 🧮

Why: Over‑provisioning nodes is the most common EKS cost mistake.

Resource Requests & Limits 💣🔆🔅

Frontend: Requests : 50m CPU / 64Mi memory. Limits : 200m CPU / 128Mi memory

Backend API: Requests : 100m CPU / 128Mi memory. Limits : 500m CPU / 256Mi memory

Why:

Enables accurate scheduling
Prevents noisy‑neighbor problems
Improves HPA decision quality

Horizontal Pod Autoscaling 👈👉👆👇

Minimum replicas: 2
Maximum replicas: 6
Scaling driven by CPU utilization

Cost Benefit:

Low load → minimal replicas → lower cost
High load → scale only when needed

Observability Reduces Hidden Costs 💰

Metrics help avoid:

Over‑scaling due to guesswork
Long outages with high blast radius
Manual firefighting (human cost)

Key Insight:

Observability is a cost‑control mechanism, not just a debugging tool.

This demo proves that EKS platforms must be observable before they are scalable.

Conclusion 🗝️

The Operational Challenge:
As organizations adopt Kubernetes, many run into an unexpected contradiction. While containers and orchestration make it easier to scale and move faster, they also add complexity that makes systems harder to understand. As a result, teams often end up reacting to problems after something breaks instead of preventing issues through better visibility and automation.

The Observability-First Approach
The answer is to adopt an observability-first approach—one where monitoring and visibility are built into the platform from day one, not added later as an afterthought. When teams can clearly see what’s happening inside their systems, they’re able to spot issues early, make smarter decisions automatically, and continuously improve performance. This shift allows organizations to move from constantly reacting to problems to predicting and preventing them.
In an observability-first platform, monitoring is woven directly into the infrastructure as it’s being created. Every component is instrumented and visible as soon as it goes live. This creates a strong foundation for automatic scaling, meaningful alerts, and data-driven capacity planning. Over time, the platform becomes more self-aware—able to understand how it’s performing and adjust on its own as conditions change.

So to summarize, in this (lengthy, but hopefully insightful) blog, we:
✅ Built a production‑style Amazon EKS platform using modular Terraform, separating networking, cluster, observability, and application concerns.
✅ Implemented Prometheus and Grafana before workloads, enabling safe CPU‑based autoscaling and rapid failure detection.
✅ Validated Day‑2 operations by demonstrating pod and node failure recovery with real‑time metrics.

Remember, "If you can’t observe it, you can’t operate it." 🙏

Future Enhancements 🧩

🚀 ALB Ingress + path‑based routing
🚀 An Interactive Web UI for Frontend
🚀 Distributed tracing (OpenTelemetry)
🚀 RBAC per namespace
🚀 CI/CD pipeline integration
🚀 Cost dashboards

References 🌐

https://aws.amazon.com/eks/

https://developer.hashicorp.com/terraform/tutorials/kubernetes/eks

https://registry.terraform.io/providers/hashicorp/aws/latest

Simplifying Container Ops: What ECS Express Mode Brings to the Table

Tanushree Aggarwal — Sun, 30 Nov 2025 17:25:22 +0000

Introduction

In an era where shipping software often feels like wrestling a hydra of YAML files, security groups, load balancers, and networking rules, Amazon ECS Express Mode arrives like a well-timed plot twist. Announced in November-2025, it promises what developers have wanted for a decade: production-grade containers without the ceremony, the toil, or the infrastructure-induced existential dread.

ECS Express Mode takes the idea of “simple deployment” and pushes it to its logical extreme. Bring a container image and two IAM roles, and with one command or a casual click, AWS conjures an entire, operationally sound architecture. We’re talking Fargate tasks, VPC wiring, security groups, an Application Load Balancer with proper health checks, autoscaling that isn’t an afterthought, and even a ready-to-use domain or public URL.

Unlike many “easy mode” cloud abstractions, Express Mode doesn’t trap you in a sandbox! All the resources it creates live fully within your AWS account, totally visible, totally tweakable.

That's quite a big sell. Isn't it?
In today's blog we are going to cover the first impressions of this offering and see if it really lives up to the hype!

Proposed Demo Application

The project demonstrates a complete ECS Express Mode workflow from containerization to deployment and cleanup using a simple Express.js web server.

Core Functionality

Web Server:
• Runs on port 3000 (configurable via PORT environment variable)
• Serves JSON responses instead of HTML pages

Two Endpoints:
• GET / - Returns a JSON object with:
• Welcome message ("ECS Express Mode Test")
• Current timestamp
• Container hostname (useful for identifying which container instance is responding)
• GET /health - Health check endpoint returning {"status": "healthy"}

Purpose

This is a demonstration application designed to:
• Show how to containerize a Node.js app for ECS
• Test ECS Express Mode deployment capabilities
• Provide observable outputs (timestamp, hostname) to verify the service is running
• Include health checks for container orchestration

Technical Stack

• Runtime: Node.js 18
• Framework: Express.js web framework
• Container: Dockerized for deployment on AWS Fargate
• Logging: Outputs to CloudWatch via ECS logging configuration

The application itself is intentionally simple - it's meant to be a working example of deploying containerized applications using ECS Express Mode rather than a complex business application. The real value is
in the deployment infrastructure and automation scripts that surround it.

Files created:

app.js - Simple Express.js web server with two endpoints:
• / - Returns JSON with message, timestamp, and hostname
• /health - Health check endpoint returning status
package.json - Node.js project configuration defining dependencies (Express.js) and start script
*Dockerfile * - Container build instructions:
• Uses Node.js 18 Alpine base image
• Installs dependencies and copies application code
• Exposes port 3000 and runs the app
task-definition.json - ECS task configuration specifying:
• Fargate compatibility with 256 CPU/512MB memory
• Container image location and port mapping
• CloudWatch logging configuration
• Task execution role for permissions
deploy.sh - Automated deployment script that:
• Creates ECR repository
• Builds and pushes Docker image
• Updates task definition with account details
• Creates ECS cluster and service with Express Mode
• Sets up CloudWatch logging
• test-express-mode.sh - Testing script that validates:
• Service status and task counts
• Task details and network configuration
• Auto-scaling settings
• Recent service events
cleanup.sh - Resource cleanup script that:
• Scales service to 0 and deletes it
• Removes ECS cluster
• Deletes ECR repository

The link to this code is provided below, so you can easily follow along in your personal AWS account.

Prerequisites ⚠

AWS CLI configured
Docker installed

Cost Warning 📊💰

This demo could cost you $0.05-0.10 per hour apprx. while running (Fargate pricing for 0.25 vCPU, 0.5 GB memory).

Breakdown of IAM Permissions and Policies used in this demo 🔏

Primary IAM Role
ecsTaskExecutionRole - This is the main IAM role referenced in the task definition that ECS Fargate uses to:

• Pull container images from ECR
• Write logs to CloudWatch
• Manage task lifecycle

Required Permissions
The demo requires your AWS user/role to have permissions for:

ECR (Elastic Container Registry):
• ecr:CreateRepository
• ecr:GetAuthorizationToken
• ecr:BatchCheckLayerAvailability
• ecr:GetDownloadUrlForLayer
• ecr:BatchGetImage

ECS (Elastic Container Service):
• ecs:CreateCluster
• ecs:CreateService
• ecs:RegisterTaskDefinition
• ecs:DescribeTasks
• ecs:ListTasks

CloudWatch Logs:
• logs:CreateLogGroup
• logs:DescribeLogStreams

EC2 (for networking):
• ec2:DescribeVpcs
• ec2:DescribeSubnets
• ec2:DescribeSecurityGroups
• ec2:DescribeNetworkInterfaces
• ec2:AuthorizeSecurityGroupIngress

STS (Security Token Service):
• sts:GetCallerIdentity

Task Execution Role Permissions
The ecsTaskExecutionRole needs the AWS managed policy:

• AmazonECSTaskExecutionRolePolicy
This policy provides the minimum permissions required for ECS tasks
to pull images and write logs.

Well-Architected Framework 🔒🛡️⚡💰♻️

This demo incorporates basic elements from well-architected pillars as listed below. For a production implementation, you would want to enhance security (eg: secrets management, network segmentation) and reliability (multi-AZ deployment, backup strategies).

🔧 Operational Excellence:
• CloudWatch logging configuration for monitoring
• Health check endpoint (/health) for service monitoring
• Automated deployment scripts for consistent operations

Security🔒 :
• IAM execution role for task permissions
• VPC networking with security groups
• Container isolation through Fargate

Reliability🛡️ :
• ECS service with desired count for high availability
• Auto-scaling capabilities (referenced in test script)
• Health checks for automatic recovery

Performance Efficiency⚡ :
• Fargate serverless compute (no infrastructure management)
• Right-sized CPU/memory allocation (256 CPU, 512 MB memory)
• Express Mode optimizations for faster startup

Cost Optimization💰 :
• Fargate pay-per-use model
• Minimal resource allocation
• Auto-scaling to match demand

Sustainability♻️ :
• Serverless architecture reduces idle resources
• Container efficiency
• Right-sizing to minimize waste

Implementation ✍

Step 1: Update Configuration

Before deploying, we will need to update the subnet and security group IDs in deploy.sh script.

For this, we will fetch our VPC information from our AWS account.

# Find your default VPC
aws ec2 describe-vpcs --filters "Name=is-default,Values=true" --query 'Vpcs[0].VpcId' --output text

# Find subnets in your VPC (replace vpc-xxxxx with your VPC ID)
aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-xxxxx" --query 'Subnets[0].SubnetId' --output text

# Find default security group
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=vpc-xxxxx" "Name=group-name,Values=default" --query 'SecurityGroups[0].GroupId' --output text

• Replace subnet-xxxxxx and sg-xxxxxx in the deploy script with actual values from your VPC
• Ensure your AWS credentials have the necessary ECS, ECR, and CloudWatch permissions

Edit deploy.sh and replace:

subnet-xxxxxx with your actual subnet ID
sg-xxxxxx with your actual security group ID

make sure that the Security Group has an inbound rule for port 3000

Step 2: Deploy the Application

Run ./deploy.sh to deploy your Express Mode service.
This will:

Create a container registry
Build and upload your app
Create an ECS cluster
Start your service

Check in the AWS Management Console:

It worked! And just like that, our cluster is running!

Step 3: Test the Deployment

Use ./test-express-mode.sh to validate the deployment.

Step 4: Find Your Application URL

# Get task details to find public IP
aws ecs describe-tasks --cluster express-mode-cluster --tasks $(aws ecs list-tasks --cluster express-mode-cluster --service-name express-mode-service --query 'taskArns[0]' --output text) --query 'tasks[0].attachments[0].details[?name==`networkInterfaceId`].value' --output text

# Get public IP (replace eni-xxxxx with the network interface ID from above)
aws ec2 describe-network-interfaces --network-interface-ids eni-xxxxx --query 'NetworkInterfaces[0].Association.PublicIp' --output text

Visit http://YOUR-PUBLIC-IP:3000 in your browser.

Perfect! It loads!

Step 5: Clean Up Resources

Run ./cleanup.sh when done testing to avoid further billing on resources.

./cleanup.sh

Github Repository

aggarwal-tanushree / amazon-ecs-express-mode-demo

The project demonstrates a complete ECS Express Mode workflow from containerization to deployment and cleanup using a simple Express.js web server

ECS Express Mode Demo - Complete Beginner's Guide

What is ECS Express Mode?

Amazon ECS Express Mode is a simplified way to run containerized applications without managing servers. It automatically handles scaling, networking, and infrastructure.

Prerequisites

1. Install Required Tools

# Install AWS CLI
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# Install Docker
sudo apt update
sudo apt install docker.io
sudo usermod -aG docker $USER

2. Configure AWS Credentials

aws configure

Enter your:

AWS Access Key ID
AWS Secret Access Key
Default region (e.g., us-east-1)
Output format (json)

3. Get Your VPC Information

# Find your default VPC
aws ec2 describe-vpcs --filters "Name=is-default,Values=true" --query 'Vpcs[0].VpcId' --output text
# Find subnets in your VPC (replace vpc-xxxxx with your VPC ID)
aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-xxxxx" --query 'Subnets[0].SubnetId' --output text

# Find default security group
aws ec2 describe-security-groups

…

View on GitHub

Amazon ECS v/s Amazon ECS Express Mode

Key Differences 🚀⭐

Feature / Aspect	Traditional Amazon ECS	Amazon ECS Express Mode
Networking Setup	Manual VPC, subnet, and security group configuration	Automatic networking setup
Load Balancing	Must create & manage ALB/NLB separately	Built-in load balancing (no ALB/NLB required)
Service Discovery	Manual configuration required	Automatic service discovery
Complexity	Requires deeper networking & infra knowledge	Minimal configuration, simplified deployment
Control Level	High granular control	Abstracts away infrastructure complexity

Benefits of Express Mode 💪

Benefit Category	Advantages of ECS Express Mode
Faster Time to Market	Deploy in minutes; no custom networking; automatic scaling
Reduced Ops Overhead	AWS manages infra; auto security groups; built-in logging/observability
Cost Optimization	No idle load balancers; automatic right-sizing; no extra networking fees
Developer-Friendly	Focus on code; simplified CLI; less AWS expertise needed

When to Use Each 💡

Use Case Type	Use Express Mode For…	Use Traditional ECS For…
Application Complexity	Simple apps, APIs, prototypes	Complex multi-tier architectures
Networking Requirements	Standard networking	Custom networking needs
Team Skill Level	Teams new to AWS/containers	Teams with advanced AWS/networking expertise
Security Requirements	Standard default configurations	Advanced/custom security configurations
Load Balancer Needs	Basic built-in LB is sufficient	Need advanced ALB/NLB features

Express Mode essentially provides a "serverless container" experience similar to how Lambda abstracts server management, but for containerized applications that need more control than Lambda functions provide.

Conclusion ✍

Amazon ECS Express Mode feels like AWS acknowledging a universal truth: most developers want to build features, not infrastructures . By letting teams deploy robust, scalable containerized services in minutes instead of weeks, AWS has delivered something refreshingly pragmatic!

For those building microservices, internal tools, or rapid prototypes, or simply looking to ship faster — Express Mode is a powerful ally.

Whether you’re racing a deadline, experimenting with a new idea, or assembling a constellation of microservices, Express Mode isn’t just a convenience — it’s a genuine accelerator.

Have you tried this offering yet? Let me know your thoughts in the comments!

References 📝

https://aws.amazon.com/about-aws/whats-new/2025/11/announcing-amazon-ecs-express-mode/

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-overview.html

Bonus 🔓

Install Required Tools

##### Install AWS CLI
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

##### Install Docker
sudo apt update
sudo apt install docker.io
sudo usermod -aG docker $USER

Configure AWS Credentials

aws configure

Enter your:
- AWS Access Key ID
- AWS Secret Access Key
- Default region (e.g., us-east-1)
- Output format (json)

Troubleshooting

Here are some troubleshooting steps in case you run into issues

"Permission denied" errors:

sudo chmod +x *.sh

"No default VPC" error:
Create a VPC or use an existing one's subnet/security group IDs.

Container won't start:
Check CloudWatch logs:

aws logs describe-log-streams --log-group-name "/ecs/express-mode-test"

Can't access the application:
Ensure your security group allows inbound traffic on port 3000:

aws ec2 authorize-security-group-ingress --group-id sg-xxxxx --protocol tcp --port 3000 --cidr 0.0.0.0/0

Next Steps

Modify app.js to add new features
Update the container and redeploy
Explore ECS auto-scaling features
Add a load balancer for production use

Rock, Paper, Innovation: Create a Game in Minutes with Amazon Q

Tanushree Aggarwal — Fri, 30 May 2025 16:58:40 +0000

Introduction

🧑‍🍳 What is Amazon Q CLI?
Amazon Q Developer CLI, popularly referred to as Amazon Q CLI is a command-line tool developed by AWS that integrates Amazon Q, a generative AI-powered assistant, into your terminal.
The tool leverages AI to help dev enthusiasts build applications by typing in plain(ish) English - like asking it questions, getting code, running tasks etc.

Amazon Q CLI is like talking to your cloud services using a magical command-line genie that understands what you mean, not just what you type.

🛠️ What makes it cool?
Natural language to code – Talk like a human, get dev-grade output.

Smart suggestions – “You asked for X, but also consider Y.”

Command line native – Lives in your terminal like a helpful ghost.

Context-aware – Knows about your AWS environment and your project.

🧃 TL;DR:
Amazon Q CLI is like ChatGPT for your cloud - but instead of chit-chat, it gets real work done in your AWS setup, straight from the terminal.

Reminiscing the good old days, I developed Rock, Paper, Scissors game in Python3 without writing a single line of code, and simply providing a prompt to Amazon Q CLI!

Continue reading .. to learn how you can do the same in a matter of minutes!

Cost

None!

Amazon Q Developer CLI can be used for free through the AWS Free Tier! To access it, you can sign up for an AWS Builder ID, which does not require an AWS account. This allows you to explore the features of Amazon Q Developer CLI, including natural language command execution and code transformation, within certain usage limits.

The functionality being used in this blog lies within the free tier and will not incur any costs if you choose to follow along or develop a game inspired by this blog.

Amazon Q CLI installation

Install Amazon Q CLI
The steps for installing Amazon Q CLI are available in the official AWS documentation
Authenticate Amazon Q CLI by running the command: q login. This opens a browser window for authentication. Log in with your AWS Builder ID to access the free-tier.
You can run your prompts directly on the Q CLI, or as I am doing in this blog - via the VSCode extension.
Install VS Code Extension (Optional)

a) Open Visual Studio Code.
b) Go to Extensions (Ctrl+Shift+X).
c) Search for Amazon Q.
d) Click Install on the official Amazon Q extension.

4) Configure Amazon Q in VS Code (Optional)

a) Open the Command Palette (Ctrl+Shift+P).
b) Type and select “Amazon Q: Connect”.
c) Follow prompts to authenticate using your AWS Builder ID (same as CLI).

5) Test Setup
a) Run q help in a VS Code terminal or on the Q CLI (if you are not using the VSCode IDE)
b) Use commands like q ask or q code to verify integration.

Implementation - Prompt and Amazon Q CLI output

Click the Amazon Q CLI extension icon in your VSCode to start the implementation!

Let's enter our first prompt!

Game - Version 1

Amazon Q CLI not only wrote a Python script for the Rock, Paper, Scissors game, but also generated well documented instructions in README.md describing the functionality and execution instructions!

Let us test what we created!

While this version of the implementation aligns well with the input prompt, works well and is without any (visible) bugs, let's see if we can UP our game!

Updated prompt and Amazon Q output

Prompt 2
update the code to take the player's name as input for a more personalized feel. Update the quality of the game graphics and change the color scheme to something more subtle that works well in both light and dark themed devices

Game - Version 2

Now that looks much better! While there is a slight rendering issue, the look and feel of the game has improved to a great extent. You may continue interacting with Amazon Q CLI to tweak the game as per your liking.

I noticed that Amazon Q did not update the README.md and game_specs.txt files this time around. Probably my prompt was the culprit here, since I only asked it to "update the code". Another reminder for us that AI assistants are only as good as the prompt!

Prompt 3
update all the files to reflect the latest changes in main.py

Bonus

I asked Amazon Q to create a flowchart of the application and it generated the flowchart in three formats!

A .txt , a markdown .md version and a Python script to generate the flowchart diagram at runtime!

Whaaatttttt???? mind blown

Github Repository

aggarwal-tanushree / rock-paper-scissors-python

Rock, Paper, Scissors Game

A modern 2D implementation of the classic Rock, Paper, Scissors game built with Python and Pygame, featuring personalized gameplay and enhanced visuals.

Game Rules

Rock beats scissors
Scissors beat paper
Paper beats rock

Features

Personalized gameplay with player name input
Modern UI with subtle color scheme for both light and dark themes
Interactive elements with hover effects and animations
Score tracking across multiple rounds
Simple mouse and keyboard controls
End-game summary with personalized results

Requirements

Python 3.6 or higher
Pygame 2.5.2 or higher

Installation

Clone or download this repository
Install the required dependencies:

pip install -r requirements.txt

How to Play

Run the game:

python main.py

Enter your name when prompted
Click on one of the colored squares to make your choice
- Red square: Rock
- Green square: Paper
- Blue square: Scissors
After seeing the result, click
- "Play Again" button to play another round
- "End Game" button to…

View on GitHub

Conclusion

AI tools like Amazon Q CLI are incredibly powerful and flexible — they let you talk to your programming language or your cloud setup almost like you're having a conversation, right from the command line. You can ask it to write code, fix bugs, manage services and more, which can save tons of time and make complex tasks easier.

But there's a catch: if you're not familiar with programming or how your systems work, it's easy to make mistakes. You might accidentally change something important, open up a security hole, or rack up unexpected costs. So while these tools are super helpful, they work best when you understand what they’re doing behind the scenes and don’t just trust them blindly.

Remember, AI assistants are only as good as your prompt!

Thank you for stopping by! I hope you found this blog useful! Are you planning to take Amazon Q CLI for a spin? Let me know in the comment section!

References

Amazon Q free-tier

Amazon Q CLI installation

Build Games with Amazon Q CLI and score a T shirt

Goodbye Logouts: Manage Multiple AWS Accounts on One Browser!

Tanushree Aggarwal — Fri, 17 Jan 2025 12:59:18 +0000

Introduction

Are you tired of constant toggling between multiple AWS accounts? Is having multiple browser windows, just so you can access different AWS account simultaneously reducing your overall efficiency?

If this is something you still struggle with, I have great news for you!

AWS has now introduced multi-session support for web browsers!

These can be root accounts, IAM users or federated roles - across the same or different AWS accounts (current maximum concurrent session limit is 5).

Continue reading to learn how to enable this feature...

Cost

This is a free feature, and does not incur any cost to the user.

Implementation

In order to be able to do so, we need to enable Multi Session (which can also be disabled anytime we no longer wish to use.

Sign in to the AWS Management Console of the account you wish to enable the feature.
On the top right navigation pane, click your account name to expand the dropdown list.
Click Turn on multi-session support. Do the same at the next screen.
Your browser window should immediately get refreshed. Notice that the browser URL has changed! The new one has your AWS account ID and a unique string combination. Bookmark this URL for future use.
Multi-session support is now enabled for the current account+user.
To enable the same for more users in the same account, click Add sessions in your account dropdown list.
Enter the credentials. This can be an IAM user, Root user or Federated roles of the same or a different account altogether, and a new sub-domain URL is now created for the second user! Remember to bookmark this URL as well!
Switch between both the open tabs. You are logged in as different accounts in each! You can access upto 5 such login URLs simultaneously in a web browser.

Remember, this is the limit for a single web-browser, and is not an account specific limit. If you try accessing more than five, you will be asked to logout from one of the existing sessions.

Disabling Multi-Session

Disabling the feature is as easy as enabling it. Simply click the Turn off multi-session support

References

https://aws.amazon.com/about-aws/whats-new/2025/01/aws-management-console-simultaneous-sign-in-multiple-accounts/

Banner image is AI generated

Block direct access to CloudFront origins with custom headers and AWS WAF

Tanushree Aggarwal — Tue, 31 Dec 2024 18:24:04 +0000

Introduction:

In today's age, insecure web applications are prime targets for cybercriminals seeking unauthorized access to sensitive information. Such breaches can lead to the exposure of personal, financial, or proprietary data, resulting in legal liabilities and loss of customer trust. A compromised web application can severely damage an organization's reputation. Broken Access Control occurs when users can access resources beyond their authorization, leading to unauthorized data exposure, and this type of security vulnerability is more common than you may think!
In this blog we will walkthrough a web architecture, which at first glance will probably not indicate the underlying issue to most readers.
Stay tuned!

Services:

Amazon Web Application Firewall
AWS WAF is a web application firewall that lets you monitor the HTTP(S) requests that are forwarded to your protected web application resources. AWS WAF lets you control access to your content. Based on criteria that you specify, such as the IP addresses that requests originate from or the values of query strings, the service associated with your protected resource responds to requests either with the requested content, with an HTTP 403 status code (Forbidden), or with a custom response.¹

Current Architecture:

We have a Amazon Virtual Private Cloud(VPC), spanning two Availability Zones(AZ). Each AZ has a public and a private subnet.
The private subnets host our Elastic Compute Cloud (EC2) instances, which act as our web server virtual machines(VMs), configured with an Auto Scaling group(ASG).
The public subnets have NAT gateways for the outbound traffic from our VMs.
Inbound traffic is routed to our VMs through an Application Load Balancer(ALB). The Security Groups(SGs) attached to our EC2 instances allow traffic only from the SG attached to the ALB. This means that the EC2 instances will only receive inbound traffic from our ALB, all other inbound traffic will be denied.
An Amazon CloudFront distribution is sending traffic to our ALB. This is the first point of entry for the internet traffic.
The ALB SG is configured to allow traffic only from the CloudFront prefixes.
Our CloudFront distribution is protected by Amazon Web Application Firewall(WAF), which blocks all commonly known security vulnerabilities.

Problem

How would you rate the above architecture?

Are you able to spot the security flaw?

No?

Need a hint?

The issue lies somewhere here:

If your answer is still No, do not worry! A vast majority of people probably won't be able to spot the security flaw!

So what exactly is the issue here?

Let me demonstrate.

We already have a CloudFront distribution sending traffic to our ALB.

What happens if I create another CloudFront distribution having the same Application Load Balancer as Origin?

Let's check!

Yes! The traffic goes through!

But why?

Understand that incoming traffic to our Application load balancer is allowed for all the CloudFront prefixes.

This is because CloudFront does not have one single I.P address, rather a range of I.P addresses, and those too change frequently.
To make this management easier, AWS introduced a prefix list which we have configured as the source in our ALB Security Group.

This is the problem!

We want only our CloudFront distribution to be able to send traffic to our ALB, and NO other.

So how do we fix this?

Good news - This can be achieved by making two small changes to our existing configuration!

Proposed Architecture

1) Our ALB should be able to identify which CloudFront distribution is the correct one - for this we will update our CloudFront distribution to send some additional custom headers while sending the request to the ALB.

2) Traffic from all other CloudFront distributions (which can be within our account or some alien account) to be blocked - for this we will add a Web Application Firewall rule, with the default action as block, and only allow traffic after checking the request headers!

Cost Warning:

Proceed with caution!
AWS WAF is not covered under the AWS free-tier.
Charges are based on the following factors:

Number of web ACLs created.
Number of rules configured for each web ACL.
Number of web requests received.

Refer WAF pricing details here

Implementation:

Step-1:

Let us update our CloudFront distribution to send custom headers.

Navigate to your distribution, and under the Origins tab, select the ALB, and click Edit.

Scroll down to reach the Add custom headers section, and click Add header

Here, we can add any custom HTTP header of our choice. Refer the list before making your choice. I am selecting x-origin-verify for the demo, it can be anything else, the possibilities are endless, you can choose one as per your architecture (eg: authentication, source i.p address etc.)

Add the header and save. The distribution will take a few minutes to update.

Step-2:
Let's create the WAF rule.

Navigate to WAF & Shield from the hamburger menu.

Click Create web ACL

Select Regional Resources and the region in which your Application Load Balancer is based. Also give the web ACL a name. Click Next.

For the Associated AWS resources, we will add our ALB. Click Add AWS resources.

Select the Application Load Balancer radio button. If you created the rule in the same region as the ALB, you should be able to see your ALB name populate in the Resources section. Select the relevant ALB from the list.

At the next screen, from the Add rules dropdown, select My own rules and rule groups.

Select Rule builder.
Give the WAF rule a meaningful name, and select type as Regular rule

Let's create our custom rule.
First we select matches the statement, and then base our scenario on it.

From the Inspect dropdown select Single Header and for the Header field type x-origin-verify, because we want to allow traffic only for the web request with the header we configured in our CloudFront distribution.

Next, select Exactly matches string for the Match type.

String to match will be the string we are passing as custom header from our CloudFront distribution originsTest.

We can optionally also perform some Text Transformation, which is not in scope of this blog.

We continue defining our rule.
From the Action dropdown select the action that will be performed if the criteria we defined above is met. Allow.
Click Add rule.

A recently added feature show us how many capacity units will be used by the defined rule.

Select the Default action which will be performed for all requests that do not match our criteria
We choose Block

At the next screen, select your rule and click Next.

You can choose to enable CloudWatch metrics to view the rule in action.

Review your configuration and click Create. This may take a few minutes to complete, post which a Successful message will pop up on the screen.

Our WAF rule is active now!
Let's put it to the test!

Try accessing the application from your original CloudFront distribution.
Does the traffic go through?
Yes! It does!

Now try accessing the CloudFront distribution we created without the custom headers.
We are no longer able to access the web application through this distribution, meaning that our WAF ACL is working perfectly!

As the last step of our verification, let's go back to our WAF ACL, and check the Sampled request tab.
All the requests that were inspected by this WAF ACL will be displayed here, along with the associated action.

Conclusion:

In this blog we walked through a very common web architecture and uncovered the underlying security flaw. We then proceeded to make a minor tweak in the existing flow which changed our security game altogether! The current state is not the perfect architecture and can be modified in a number of ways to improve our security posture even further.
Amazon WAF offers many other features which were not in scope of this blog.

References:

https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html ↩

Dr. Swami Sivasubramanian's Keynote - under 5 minutes

Tanushree Aggarwal — Wed, 04 Dec 2024 18:35:04 +0000

A quick summary of Dr. Swami Sivasubramanian's keynote at AWS Re:Invent Day 4.

Dr. Swami Sivasubramanian, VP of AI and Data at AWS talked about
how the use of strong data foundation can help create innovative and differentiated customer solutions.

Customer speakers delved into how they have used data to support a variety of use cases, including generative AI, to create unique customer experiences.

Here are the key takeaways from the keynote:

Amazon SageMaker HyperPod Flexible Training Plans

Efficiently distribute and parallelize your training workload across all accelerators.
Save weeks of training time and help meet timelines and budgets
Remove manual provisioning of compute capacity
Quickly create training plan, save weeks of training
Now Generally Available

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-sagemaker-hyperpod-flexible-training-plans/

Amazon SageMaker HyperPod task governance

Centralized governance across all generative AI development tasks
Optimize accelerator utilization for model training, fine tuning and inference
Up to 40% cost reduction
Dynamically allocate accelerator compute resources across tasks
Ensure high priority tasks are completed on time
Monitor and audit compute allocation and utilization in real time
Now Generally Available

https://aws.amazon.com/about-aws/whats-new/2024/12/task-governance-amazon-sagemaker-hyperpod/

AI apps from AWS partners now available in Amazon SageMaker AI

Enables customers to easily discover, deploy, and use best-in-class machine learning (ML) and generative AI (GenAI)
Find, deploy and use AI apps from AWS partners within AWS SageMaker
Use 3rd party specialized applications at various ML lifecycle stages
Fully managed AWS experience with no infrastructure to provision or operate
Data does not leave your AaageMaker development environment
Support for Comet, Fiddler, Deepchecks, Lakera
Support for more 3rd party apps coming soon
Now Generally Available

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-sagemaker-partner-ai-apps/

Poolside coming to Amazon Bedrock early next year

Hottest startup providing Software engineering AI for large enterprises
Poolside assistants malibu (tackles complex software engineering challenges) and point (low latency code completion predictions for developers) - coming soon to AWS!
AWS first cloud provider to provide access to Poolside

Stability AI's `Stable Diffusion 3.5` coming soon to Amazon Bedrock

Generate stunning, high-quality images from text descriptions
Accelerate concept art creation, visual effects, prototyping and detailed product imagery
High quality AI image generation. easily deployable art scale
Trained on Amazon SageMaker HyperPod

Luma AI coming soon to Amazon Bedrock

Hyper fast creation time for high quality video generation from text and images
Experiment with fluid, cinematic and naturalistic camera motions
Amazon Bedrock first cloud provider to get access to the latest Luma model - Luma Ray2, a high quality text-to-image and text-to-video generation model

Announcing Amazon Bedrock Marketplace

Access to more than 100 models from leading providers, in a single unified console experience in Amazon Bedrock
Deploy models on managed endpoints with custom scaling policies
Leverage Bedrock APIs to integration
Now Generally Available

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-bedrock-marketplace-100-models-bedrock/

Amazon Bedrock supports prompt caching

Lower response latency and decrease cost by caching infrequently used prompts
Reduce costs by up to 90% and latency by up to 85% for supported models
Available in Preview

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-bedrock-preview-prompt-caching/

Amazon Bedrock Intelligent Prompt Routing

Define your cost and latency thresholds and Bedrock will route prompts to best suited model
Available in Preview

Amazon Kendra Generative AI Index

Out of the box vector index
- Supporting connectors for 40+ enterprise data sources (like SharePoint, OneDrive, Salesforce) with Amazon Bedrock knowledge bases
- Kendra GenAI Index supports mobility across AWS generative AI services like Amazon Bedrock Knowledge Base and Amazon Q Business,
- Available in Preview

https://aws.amazon.com/about-aws/whats-new/2024/12/genai-index-amazon-kendra/

Amazon Bedrock Knowledge Bases supports structured data retrieval

- Fully managed RAG that supports relational queries natively
Seamlessly integrate structured data for RAG
Use data stored in amazon SageMaker Lakehouse, newly released S3 Tables and Redshift
Bedrock KBs can transform natural language queries into SQL queries, allowing users to retrieve data directly from the source without the need to move or preprocess the data, reducing development time from months to days
Improve accuracy of queries with customized content
Available in Preview

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-bedrock-knowledge-bases-structured-data-retrieval/

Amazon Bedrock Knowledge Bases now supports GraphRAG

Generate more relevant responses for gen AI apps using KBs
Auto generation of knowledge graphs (using Amazon Neptune) to link relationships across data sources
Enables building more comprehensive and explainable gen AI apps
More accurate responses through a single API
Available in Preview

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-bedrock-knowledge-bases-graphrag-preview/

Amazon Bedrock Data Automation

GenAI ETL
Transform unstructured multimodal data for gen AI apps and analytics
Extract, transform and generate structured data from multi-modal content
Generates customized outputs based on rules
Fully managed, single API experience
No coding required
Prevents risks of hallucinations
Available in Preview

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-bedrock-data-automation-available-preview/

Amazon Bedrock Guardrails Multimodal Toxicity Detection

Configure safeguards for image content
Enhance security of multimodal gen AI apps
Enable consistent policy control
Available to all models within amazon Bedrock that support image content, including fine-tuned models
Available in Preview

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-bedrock-guardrails-multimodal-toxicity-detection-image-content-preview/

Amazon Q Developer is now available in SageMaker Canvas

Develop machine learning models in natural language, without a single line of Python code
Q Developer will break down your objective into specific ML tasks, define problem and apply data preparation techniques on the data
Available in Preview

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-q-developer-guide-sagemaker-canvas-users-ml-development/

Amazon Q in QuickSight Scenarios

Run scenario analysis to help users find answers to complex problems easily
Ask Q questions about complex business problems using natural language!
Q automatically finds relevant data and suggests analysis
10x faster analysis than spreadsheets
Accessible from any Amazon QuickSight dashboard
Available in Preview

https://aws.amazon.com/about-aws/whats-new/2024/12/scenario-analysis-capability-amazon-q-quicksight-preview/

AWS Education literacy initiative

Five year commitment of cloud technology and technical support for organizations creating digital learning solutions
Empowering organizations to educate underprivileged learners globally through cloud computing
Up to $100 million commitment of AWS cloud credits, over the next 5 years, along with support from AWS experts for training
Deepen existing partnership with code.org for providing learning platform
New partnership with Rocket Learning - an organization supporting more than 3 million children in India

https://aws.amazon.com/about-aws/whats-new/2024/12/aws-education-equity-boost-education-underserved-learners/

That's all for today!
Hope you enjoyed this summary! Which announcement is your favorite?

Note: No AI was used in the creation of this blog.

CEO Keynote with Matt Garman - under 5 minutes

Tanushree Aggarwal — Tue, 03 Dec 2024 19:37:28 +0000

General Announcements

Billion dollars in credits announced for Startups!

Compute

NVIDIA P6 family of instances

Featuring NVIDIA Blackwell chips
Offering 25 times faster compute
Availability : early next year

Amazon EC2 Trainium 2 (TRM2) Instances Generally Available

TRM2 announced in Re:Invent2023 is now in GA!
Next generation Trainium instances, powered by Trainium2
offers best price performance for GenAI on AWS
Custom built processors by AWS for GenAI
Up to 30-40% better price performance than current generation GPU-based instances
16 Trainium2 chips
Up to 20.8 FB8 petaflops from a single compute

EC2 TRM2 Ultra Server

Connects 4 Trainium2 instances
Single Ultra node will offer over 83 petaflops of compute!
Expected to create material impact on model training clusters

Trainium 3 (TRM3)

Available later next year
2x more performance
40% more efficient

Storage

New bucket type S3 Table Buckets

Now in General Availability
Tabular data in the cloud
Up to 3 times faster query performance
Up to 10 times higher transactions per second for Apache Iceberg tables - Supporting automated table events
S3 manages removal of unreferenced files

Faster Metadata management in S3, announcing S3 Metadata

Now available in Preview
Fastest and easiest way to manage metadata in S3
S3 automatically updates object metadata in Iceberg tables

Database

Celebrating 10 years of Amazon Aurora

was announced at Re:Invent 10 years ago

Announcing Amazon Aroura DSQL

Now available in Preview
Fastest distributed SQL database
Low latency read-writes
Virtually unlimited scalability, and scales down to Zero
4x faster read-writes compared to Google Spanner
Fully managed
99.999% multi-region availability
Strong consistency
PostgreSQL compatible
Amazon DynamoDB Global Tables
Also supporting multi-region strong consistency

Artificial Intelligence

Amazon Bedrock Model Distillation

Create faster and more effective models
Send sample prompt from you application and Bedrock will do all the work for you
Transfer knowledge from a complex model to a small one with ease!
Distilled models are 500% times faster , 75% less expensive
Available in preview

Amazon Bedrock Automated Reasoning Checks

Reasoning system in Amazon Bedrock
Automated checks
If model thinks that the answer is not correct, it sends back asking for more prompts

Amazon Bedrock Multi Agent Collaboration

Easily build, deploy and orchestrate teams of agents that work together to handle complex, multi-step tasks
Orchestrate agents without complex coding
Agents work in parallel, accelerating tasks

Tune into Swami's keynote tomorrow for more Bedrock announcements!

Announcements from Amazon

Andy Jassy surprised us with 6 new Amazon Frontier models that will be available within Amazon Bedrock!

Amazon Nova

State of the art foundation models that deliver frontier intelligence
Offering industry leading price performance
Comes in 4 flavors - one text and three multimodal models.
75% more cost effective
Fasted models in their respective intelligence classes in Bedrock
Support fine-tuning to boost accuracy
Deep Integration with Bedrock Knowledge Bases for RAG
Optimized for proprietary applications that require interaction through APIs
Integration with just announced Amazon Bedrock Distillation

i) Amazon Nova Micro

Text based
Performance benchmarks equal or better than Llama and Gemini models
Now Generally available

ii) Amazon Nova Lite

Very low-cost multimodal model
Lightening fast for processing image, video and text inputs
Now Generally available

iii) Amazon Nova Pro

Highly capable multimodal model
Offers best combination of accuracy, speed and cost for wide range of tasks
Now Generally available

iv) Amazon Nova Premier

Coming in Q1 2025
Most capable multimodal model for complex reasoning tasks
best teacher for distilling custom models

Amazon Canvas

State of the art image generation model
Now Generally available
Edit images with NLP text prompts
Offers control for color scheme and layout
Built-in controls for responsible AI
Watermarking for traceability and content moderation

Amazon Nova Real

Now Generally available
State of the art video generation model

Amazon Nova Reel - coming soon

State of the art video generation model
Now Generally available
Offers full camera control - ranging from 360 degree rotation to zoom
Built-in safe AI features
Launched with 6 second videos
Will support up to 2 minute videos in the next few months

Sneak Peak

Amazon Nova Speech-to-Speech - speech to speech model, expected mid next year

Amazon Nova Any-to-Any - any-to-any model, expected mid next year

AI for Development

Amazon Q

Three new autonomous agents for Amazon Q, giving back developers valuable time!

Amazon Q develops and applies unit tests - available in GA
Use Amazon Q to create new accurate documentation – for new code or legacy code! - available in GA
Use Amazon Q to automatic code review, flag suspicious code packages - available in GA
After Slack, AWS Console and VSCode integration, now deep integration with GitLab - native support for GitLab Duo workflows! - Available in Preview

Amazon Q Developer for .NET

Modernizing Windows gets easier with Amazon Q Developer
Transform Windows to Linux in a fraction of time, 4x faster!
Agents support transforming hundreds of apps in parallel
Cost reduction by 40%
Available in Preview

Amazon Q Developer for VMWare

Modernize VMWare workloads using Amazon Q
Agents identify dependencies and transform network configs
Launches agents that can convert on-prem code to Cloud equivalent
Available in Preview

Amazon Q Developer for Mainframes

Q accelerates migration from mainframe to Cloud
Available in Preview
Offers code analysis, refactor applications
Takes legacy code and builds documentation
Available in Preview

Operations

Amazon Q Developer (for operations)

Investigate issues across AWS environment in a fraction of time
Provides guided workflows for investigating issues, by looking at CloudWatch and CloudTrail logs; checks for anomalies (eg: missing IAM permissions)
Offers possible remediations by referring runbooks and documentation
Available in Preview

PagerDuty Advance with Amazon Q

In partnership with PagerDuty
Offers unified user experience
Built using Amazon Bedrock and Claude
Leverages Amazon Bedrock Guardrails
In addition to resolving issues caused by AI, help reinforce responsible AI policies

Business Intelligence

Combining QuickSight and Amazon Q Business Data

Pull salesforce data into QuickSight
More powerful than an ordinary BI tool

ISV integration with Amazon Q index

New set of APIs for ISVs to use with Amazon Q index
Easily access data from multiple applications
You control permissions to your data
Better security with a single index
Now Generally Available

Amazon Q Business for automating complex workflows

Coming soon
Automatically build workflows based on documentation or recordings!
Navigate workflow changes in real time

AI in Analytics

Amazon SageMaker Unified Studio

Next Gen of Amazon SageMaker
Integrate with most comprehensive set of AI tools
Offers single view of enterprise data
Consolidates functionality data scientists and analysts, ML experts use
Create, share projects that use AI
Integrated data catalog and governance controls
Now in preview

Zero ETL for applications

Between Amazon Aurora, RDS for MySQL, DynamoDB, Redshift and third party SaaS apps
Now In GA

Amazon SageMaker Lakehouse

Simplifies analytics and AI with an open, unified and secure data lake house
Unifies access to data across S3, Amazon Redshift, SaaS and federated data sources
Consistent fine grain access control for data governance
Apache iceberg compatible lake house
Access through unified studio or any 3rd party tool which supports iceberg, using API
Now Generally available

Amazon SageMaker is now "Amazon SageMaker AI"

No AI was used in the creation of this blog. All information has been manually jotted down by the author during the livestream and published 10 minutes after the livestream ended. No official publications/documentation was referred before publishing this blog. In case you spot a wrong piece of information, please notify the author.

Amplify your web development speed with "AWS Amplify"

Tanushree Aggarwal — Thu, 21 Nov 2024 07:50:06 +0000

Introduction:

We live in the age of THE WEB. Knowing how to host a website is essential in today’s digital age. It empowers individuals and businesses to establish their online presence, share their ideas, and reach broader audiences. It provides full control over how your website operates, looks, and functions, allowing customization to suit personal or professional needs. To many, this may still seem like a daunting task. Gone are the days when you needed to rely on third parties or host your own web servers to be able to publish a website. In this blog I will be demonstrating a way to host a website, just with a few simple clicks.

Services :

AWS Amplify:

AWS Amplify is everything you need to build web and mobile apps. Easy to start, easy to scale.
If I had to describe AWS Amplify in 3 words, I would say "hosting made simple".
Few reasons why you should make "AWS Amplify" your best friend:

deploying application frontends with simple Git based workflows
spinning up multiple environments by connecting branches from Git (or any other version control system)
support for numerous languages, ranging from Java to Typescript to React
built-in CI/CD, eliminating the need for manual code updates/deployment

Goal:

In this demo, we will be deploying a website using a single AWS service AWS Amplify, under five minutes and zero dollar spend! We will then modify the website code and see what kind of changes need to be performed to our deployment, in order to reflect the updated code.

Pre-requisites :

AWS IAM account (do not use root account) having:
- admin privileges
- access to AWS Management Console
A Github (or any other VCS like Bitbucket) account

Cost :

None (if you have an AWS free-tier eligible account). Check AWS Amplify pricing details here

Implementation:

Let's begin!

Before we begin with the AWS bit, let us get our website code ready.

This does not have to be a fancy website; our aim is to understand the integration, so we will be using a basic HTML file. You can of-course choose to go full Ninja if that is what you prefer!

Login to your Github account and create a new repository.
Create your website homepage index.html file. If you are not a HTML wizard (like me), do not panic! I have you covered here! Simply copy-paste the following code, and save it as index.html.

Note: It is mandatory that you name the main file as index.html.
AWS Amplify requires an index.html file primarily because it acts as the entry point for a web application.

Optionally save any jpeg image with the name welcome.jpg under the same path. (This is just for aesthetic, you can totally skip this step)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Hello World</title>
    <style>
        body {
            font-family: Arial, sans-serif;
            text-align: center;
            margin: 0;
            padding: 0;
            background-color: #000000;
        }
        h1 {
            color: #db3f30;
        }
        h2 {
            color: #da3728;
        }
        img {
            width: 300px;
            height: auto;
            margin-top: 20px;
        }
    </style>
</head>
<body>
    <h1>Welcome to my AWS Amplify demo website</h1>
    <img src="welcome.jpg" alt="Welcome Image">
</body>
</html>

We are now ready to host this static website using AWS Amplify.

Login to the AWS Management Console as an IAM user, and switch to the region of your choice. In this demo I will be using eu-central-1, but you can choose one closer to your geographical location.
From the Services hamburger menu navigate to AWS Amplify

This will take you to the Amplify homepage.
Click Deploy an App
Amplify supports integration with a number of Version Control Systems. Select your preferred tool, and click Next. I will be working with Github in this demo.
Select Github and click Next
A pop-up appears on the screen. This may differ from the below screenshot, depending on which version control tool you chose at step-4. Verify your identify and authorize AWS Amplify to access your VCS system.
Next, you will be prompted to select the repositories you want AWS Amplify to be able to access.
Click Only selected repositories and select the desired repository from the drop-down list.

Note: As per the security best practice Principle of least privilege, it is advisable to select specific repositories, and avoid selecting the All repositories option.
Note: You may be prompted for a MFA code, if you have this security feature enabled for your Github account.
If you granted permissions to multiple repositories, select the relevant repo from the dropdown list at this stage. Additionally, select the repo branch which has the code for the website. To reiterate, the index.html needs to be at the repo landing path.
Give the application a name, and click Next
Review the details, and click Save and deploy
Now we wait! The deployment may take a few minutes to complete.
Once the deployment is complete, and you see the deployed status on your screen, cross your fingers and click Visit deployed URL.
Tada! our website is deployed!

Impressed?

Bonus

Hold on! Our demo does not end here!

In the real world, we seldom deploy the complete website in the first attempt. Often any code goes through multiple iterations, before the final version.

Suppose this is the case with our demo website as well. To publish the updated code, we do not need to repeat the whole process!
AWS Amplify is that one best friend, who notices even the slightest change in our mood and adapts accordingly!

Confused? Let me demonstrate!

Let us make some modifications to theindex.html in our github repo .

I have simply added a new h2 to the body section.

<body>
    <h1>Welcome to my AWS Amplify demo website</h1>
    <h2>Did you like my AWS Amplify demo?</h2>
    <p></p>
    <img src="welcome.jpg" alt="Welcome Image">
</body>

As soon as I click commit in my Github repo, AWS Amplify detects the change, and starts a new deployment!

Open the deployment URL when the status changes to deployed. This may take a few minutes to complete.

Our updated code is reflecting on our website!

This did not require any manual intervention or redeployment!
The deployment URL remains unchanged after the update
AND there was ZERO downtime during the upgrade!

If you weren't impressed before, I am sure you are NOW!

So, are you going to AWS Amplify a try?

The capabilities of AWS Amplify do not end here. In fact, this was just the tip of the iceberg!
In an upcoming blog, I will be demonstrating how AWS Amplify can be integrated with other AWS services.

Till then, give AWS Amplify a try and come back for more such content.

Happy learning!

References:

Getting Started with Amplify
Development with AWS Amplify
AWS Amplify FAQ
Banner image and demo-website image are AI generated, using DALL-E

AWS PartyRock - Anyone can become a developer

Tanushree Aggarwal — Thu, 16 Nov 2023 18:24:24 +0000

Building apps is a party with Partyrock!

PartyRock, powered by AI foundation models from the recently released Amazon Bedrock is a space where you can build your own AI-generated apps in a matter of minutes! It’s a fast and fun way to learn about generative AI.

Get Started

Build your own app

There are 3 different ways to create a new PartyRock app.

Start with a prompt - the easiest way to start experimenting! Use the app builder on the welcome page.
Give a detailed description of what you would like your app to do.
click Generate app
and you are done!
Test your app and edit if necessary!
Remix an existing app - Use an existing application and add new features or your personal touch.

This can be an app you created, a Partyrock sample app or an app created by someone else, you feel inspired by
Start from scratch with an empty app - and add your own widgets.

Demo

Build a Trivia app with me, in under 5 minutes!

i. Login to PartyRock

ii. Click Build your own app

iii. Describe what you would like to build

iv. Click Generate app

v. Test your app, and edit if necessary. And you are done!

vi. Make the app public and share with your friends!

Conclusion

The idea behind PartyRock is to make learning GenAI easy and fun!
Let your imagination run wild and create some fun apps!
Don't forget to share your app link in the comment section! Here's mine!

Happy learning!

Scheduling EC2 start and stop using Eventbridge and Lambda (part 2 of 2)

Tanushree Aggarwal — Tue, 31 Oct 2023 13:33:07 +0000

Introduction

In our previous blog, we discussed the use case and the architecture. The major steps have already been implemented, and today we will simply be tying everything together by configuring the Eventbridge schedule, that will execute the Lambda functions we created earlier.

Creating an Eventbridge Schedule

1) Login to the AWS Management Console and navigate to Amazon EventBridge

2) From the Amazon Eventbridge Get started options, select EventBridge Schedule

3) Click Create schedule

4) Give the schedule a name and meaningful description

5) Select Recurring schedule and Cron-based schedule for the Schedule Type

6) Enter the Cron value

CRONs are commonly used in Unix based systems to schedule certain jobs/scripts. A CRONjob comprises of 6 space separated fields, which define the execution time of the script.

The CRON Expression 00 17 ? * 2-6 * indicates that it will execute 0th minute of 17th hour (5PM), 2-6 day of the week, i.e. Mon-Fri.
An asterisk (*) is used as a wildcard to represent any possible value for that field
A question mark (?) indicates no specific value.

7) Select the desired Time zone

8) Select the optional values as per your use case. Click Next
We are leaving these as default.

9) From the Target options, select All APIs

10) From the All AWS Services dropdown select Lambda
Click Next

11) From the Lambda API list select Invoke

12) For the Invoke settings, select the Lambda function Stop_EC2_instance we created in the previous blog.

13) Leave Configure version/aliases as the default values.

14) Since our Lambda function does not require any parameters/arguments, we can leave the Payload as blank.

Click Next

15) At the next screen, make sure that Enable schedule button is toggled to enabled. This button gives us the option to not enable the schedule right away. One use case can be to trigger this Eventbridge from another service based on defined conditions.

16) We have the option to execute a Delete action after the Eventbridge execution. This is outside the scope of this demo, so can leave it as blank, or select None

17) Scroll all the way to the bottom, to reach the Permissions settings.
We need to allow our Eventbridge scheduler access to the Lambda function, lets create an IAM role for this.
Select Create a new role for this schedule. A IAM role name will be assigned automatically with the relevant permissions.

Click Next

Alternately, we can create the IAM Policy and Role from the IAM dashboard. The steps will be similar to those performed while creating the IAM Policy and Role for the Lambda.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:eu-central-1:<AWS_Account_ID>:function:Stop_EC2_instances:*",
                "arn:aws:lambda:eu-central-1:<AWS_Account_ID>:function:Stop_EC2_instances"
            ]
        }
    ]
}

18) Review all the configurations and click Create Schedule

Tada! Your Eventbridge scheduler is ready!

Create Eventbridge schedule for the starting the EC2 instances

Repeat the above steps to create another Eventbridge scheduler to Start the EC2 instances, configuring the Start_EC2_instances Lambda function.

The CRON entry for 08AM every weekday will be as follows:

Verification

We are all set! Our final step is to verify if our Eventbridge schedulers triggered as per schedule and if they were actually able to stop/start our EC2 instances!

Cloudwatch metrics indicating that our Start_EC2_instances Lambda function was invoked at 08:00AM.

EC2 instances are in running state:

Conclusion

In this two-part blog we covered a range of AWS services. We understood how different services can be used in conjunction with each other to create unique set of actions.
I hope this blog has ignited some level of curiosity in your mind, for AWS and cloud architecture in general!

If you read till the end, Thank you!

Watch out this space for more such articles. Do like and comment if you found this useful! Your feedback is welcome in the comment section.

Hacktoberfest2023 - completion!

Tanushree Aggarwal — Sun, 29 Oct 2023 19:02:45 +0000

And just like that..

Being a first time Hacktoberfest participant, I feel super proud of myself!
Just a few days back I shared my Hacktoberfest goal of submitting 2 valid PRs. To my surprise I was able to submit them very easily, so decided to keep going further!

Which led me here, having completed the challenge with 4 valid PRs!

Pull Request 1
Pull Request 2
Pull Request 3
Pull Request 4

While I may not have made a significant contribution to the opensource community with these PRs, this is just the beginning of my opensource journey!
I am already looking forward to participate in next year's Hacktoberfest and make some constructive contributions!

DEV Community: Tanushree Aggarwal

20 Years, Infinite Objects: The Amazon S3 Story

🪣 An Ode to Amazon S3

20 Years of Quietly Running the Internet.

Conclusion - ☁️ The Service That Quietly Holds the Internet

Bonus

Observability-Driven Kubernetes: A Practical EKS Demo

Introduction : EKS Observability Platform 🖥️

Project Goals 🤖

What This Project Demonstrates 💭✏️

Project Structure 📋

Infrastructure (Terraform)

Implementation Guide 🎨

Step 1: Network Foundation (VPC Module)

Step 2: EKS Cluster Provisioning

Step 3: Observability‑First Setup

Step 4: Application Namespaces

Step 5: Frontend Tier Deployment

Step 6: Backend API Tier Deployment

Step 7: Horizontal Pod Autoscaling (HPA)

Step 8: Failure Injection (Day‑2 Operations)

Pod Failure

Node Failure

Implementation 🌀

Testing ⚡⚡

Login to the AWS Management Console and see the EKS cluster.

Let us check our frontend service

Access Grafana

Observe Baseline Metrics

Generate Load (Autoscaling Demo)

Pod Failure Injection

Node Failure Injection

Github Repository

aggarwal-tanushree / eks-observability-first-platform

Personal platform engineering project demonstrating an observability-first 3-tier architecture on Amazon EKS using Terraform, Prometheus, and Grafana.

EKS Observability First Platform

Description

Directory Structure

Key Cost Controls in This Platform 💲:

Right‑Sized Node Groups 🧮

Resource Requests & Limits 💣🔆🔅

Horizontal Pod Autoscaling 👈👉👆👇

Observability Reduces Hidden Costs 💰

Conclusion 🗝️

Future Enhancements 🧩

References 🌐

Simplifying Container Ops: What ECS Express Mode Brings to the Table

Introduction

Proposed Demo Application

Core Functionality

Purpose

Technical Stack

Files created:

Prerequisites ⚠

Cost Warning 📊💰

Breakdown of IAM Permissions and Policies used in this demo 🔏

Well-Architected Framework 🔒🛡️⚡💰♻️

Implementation ✍

Step 1: Update Configuration

Step 2: Deploy the Application

Step 3: Test the Deployment

Step 4: Find Your Application URL

Step 5: Clean Up Resources

Github Repository

aggarwal-tanushree / amazon-ecs-express-mode-demo

The project demonstrates a complete ECS Express Mode workflow from containerization to deployment and cleanup using a simple Express.js web server

ECS Express Mode Demo - Complete Beginner's Guide

What is ECS Express Mode?

Prerequisites

1. Install Required Tools

2. Configure AWS Credentials

3. Get Your VPC Information

Amazon ECS v/s Amazon ECS Express Mode

Key Differences 🚀⭐

Benefits of Express Mode 💪

When to Use Each 💡

Conclusion ✍

References 📝

Bonus 🔓

Install Required Tools

Stability AI's `Stable Diffusion 3.5` coming soon to Amazon Bedrock