AWS ECS Fargate Deployment with Terraform

In this project, we're going to deploy a Flask app to AWS using ECS Fargate and Terraform. I'll walk you through the whole thing - setting up a VPC, understanding CIDR blocks, configuring security groups, and building a CI/CD pipeline with CodePipeline. If you're trying to get into DevOps or just want to actually understand how AWS infrastructure works instead of just clicking around the console, this is what you need.

Mainly there are IP networking fundamentals here like IP addresses, CIDR and all that - stuff that can help you in cybersecurity too.

Docker Commands

In Phase B, we verified our AWS setup before creating any resources. We confirmed that the AWS CLI was properly configured and authenticated as the test_user IAM user by running aws sts get-caller-identity. We verified the default region was set to us-east-1 (the cheapest and most feature-complete AWS region). We created a budget alert called proj2-cost-guardrail with a $10/month limit that sends an email notification when spending exceeds 80% ($8) — this acts as a safety net to prevent surprise bills. Finally, we tested that we had the necessary permissions to access ECR, ECS, and VPC services by running describe/list commands and confirming no "Access Denied" errors. This phase was all about preparation and safety checks — no infrastructure was built yet, just making sure we had the keys, knew where we were going, and had cost protection in place.

In Phase D, we used Terraform to provision the core AWS networking infrastructure as code. Instead of manually clicking through the AWS Console, we wrote Terraform configuration files (.tf files) that define our desired infrastructure declaratively. We created a VPC with CIDR block 10.0.0.0/16, two public subnets across different availability zones (us-east-1a and us-east-1b) for high availability, an Internet Gateway to allow internet access, route tables to direct traffic, and two security groups — one for the ALB (allowing HTTP port 80 from the internet) and one for ECS tasks (allowing traffic only from the ALB). We also set up an Application Load Balancer (ALB) with a target group and HTTP listener. Running terraform init, terraform plan, and terraform apply created all 12 resources automatically. At this point, the ALB returns a 503 error because there are no targets yet — the ECS tasks haven't been deployed. This phase established the network foundation that our containers will run on.

In Phase E, we deployed our containerized Flask application to AWS ECS Fargate. We created an IAM role (ecsTaskExecutionRole) that gives ECS permission to pull Docker images from ECR and write logs to CloudWatch. We set up a CloudWatch Log Group (/ecs/proj2-app) to capture container output. We then created an ECS Cluster (proj2-cluster) as a logical grouping for our containers, and a Task Definition that specifies exactly how to run our container — the Docker image from ECR, CPU (256 units = 0.25 vCPU), memory (512MB), port mapping (8080), and logging configuration. Finally, we created an ECS Service that maintains our desired task count, connects to the ALB target group, and automatically replaces unhealthy tasks. After terraform apply, the ALB health checks pass, and hitting the ALB URL now returns {"message": "Hello from ECS Fargate!", "service": "proj2-app"} — our app is live. The complete request flow is: User → ALB (port 80) → ECS Task (port 8080) → Flask app → response back through the same path.

In Phase F, we set up monitoring and alerting to know when something goes wrong with our application. We created an SNS (Simple Notification Service) topic and subscribed your email to it, so you receive notifications when alarms trigger. We then created 7 CloudWatch Alarms that monitor critical metrics: high CPU utilization (>80%), high memory utilization (>80%), HTTP 5xx errors (server errors), HTTP 4xx errors (client errors), unhealthy targets in the load balancer, high ALB response time, and low running task count. When any of these thresholds are breached, you get an email alert. We also built a CloudWatch Dashboard that displays real-time graphs of request count, response times, error rates, CPU/memory usage, healthy host count, and running tasks — giving you a single pane of glass to monitor your application's health. This transforms the setup from "hope it works" to "know it works" — you'll be notified of problems before users even notice them.

In Phase G, we built an automated CI/CD pipeline using AWS CodePipeline and CodeBuild so that code changes automatically deploy to production. We created a CodeStar Connection to link AWS with your GitHub repository (requires one-time manual authorization in the AWS Console). We set up an S3 bucket to store pipeline artifacts, and created IAM roles with the necessary permissions for CodeBuild and CodePipeline to access ECR, ECS, and other services. We wrote a buildspec.yml file that tells CodeBuild exactly what to do: log into ECR, build the Docker image from the app/ directory, tag it with the commit hash, push it to ECR, and generate an imagedefinitions.json file that tells ECS which image to deploy. The pipeline has three stages: Source (pulls code from GitHub), Build (runs CodeBuild), and Deploy (updates ECS service with the new image using rolling deployment). Now, whenever you git push to the main branch, the entire build-and-deploy process runs automatically in about 5-7 minutes — no manual steps required.

In Phase H, we implemented auto-scaling and cost optimization for our ECS service. We configured Fargate Spot as a capacity provider, which uses AWS's spare compute capacity at up to 70% discount compared to regular Fargate — with the tradeoff that tasks can be interrupted with 2 minutes notice (we keep at least 1 task on regular Fargate for reliability). We set up Application Auto Scaling with two target tracking policies: one that scales based on CPU utilization (target 70%) and another based on ALB request count (target 100 requests per target per minute). When load increases, tasks scale out quickly (60-second cooldown); when load decreases, tasks scale in slowly (300-second cooldown) to avoid flapping. We also added scheduled scaling to save costs: at 10 PM UTC the service scales to 0 tasks (complete shutdown), and at 8 AM UTC it scales back up to 1-4 tasks. The capacity provider strategy uses an 80/20 split — 80% Fargate Spot, 20% regular Fargate. Combined, these optimizations reduce compute costs by roughly 83% compared to running regular Fargate 24/7.