Deploy Containers on Amazon ECS with Fargate

By Khimananda Oli | Last reviewed: August 2026

Running containerized applications without managing underlying servers is the primary reason teams choose to deploy containers on Amazon ECS with Fargate. This serverless compute engine removes the operational overhead of patching and scaling EC2 instances, letting you focus entirely on application logic and delivery. However, abstracting the infrastructure introduces new challenges in networking, IAM permissions, and cost management that differ significantly from traditional Kubernetes or EC2-based deployments.

How do you architect a secure network for Fargate tasks?

Network architecture is where most Fargate deployments fail silently. Unlike EC2 instances where you might tolerate public IPs during development, Fargate tasks should almost never have direct internet exposure. A common mistake I see in audits is placing Fargate tasks in public subnets "for simplicity," which bypasses NAT gateway logging and exposes ephemeral ENIs directly to the internet.

The correct pattern places your Fargate tasks in private subnets with a route to a NAT Gateway (or VPC endpoints for AWS services like ECR and S3 to avoid NAT data charges). Inbound traffic flows exclusively through an Application Load Balancer in public subnets. This architecture ensures all egress traffic is logged at the NAT level and tasks cannot be accidentally exposed. For teams implementing VPC networking fundamentals, this separation is non-negotiable for SOC 2 compliance.

Configuring Security Groups Correctly

Your Fargate task security group should allow inbound traffic only from the ALB security group on the specific container port (e.g., 8080), not from 0.0.0.0/0. Outbound rules should permit HTTPS (443) to required destinations. Avoid overly permissive egress rules; scope them to known API endpoints or VPC endpoint prefixes when possible.

What does a production-ready Fargate task definition look like?

A task definition is the blueprint for your container. Many tutorials show minimal JSON, but production definitions require explicit resource bounds, health checks, logging configuration, and IAM role references. Below is a validated task definition snippet for a Node.js API that passes security audits:

{
  "family": "api-production",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/api-task-execution-role",
  "taskRoleArn": "arn:aws:iam::123456789012:role/api-task-role",
  "containerDefinitions": [
    {
      "name": "api",
      "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/api:v2.4.1",
      "portMappings": [
        {
          "containerPort": 8080,
          "protocol": "tcp"
        }
      ],
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 60
      },
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/api-production",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "api"
        }
      },
      "environment": [
        { "name": "NODE_ENV", "value": "production" }
      ]
    }
  ]
}

Key points often missed: always pin image tags to immutable digests or semantic versions (never latest), define explicit health checks with a startPeriod to accommodate slow-starting apps, and separate executionRoleArn (used by ECS agent to pull images/write logs) from taskRoleArn (used by your application code to access AWS APIs). This separation enforces least privilege and simplifies audit trails. If you're new to containerization, review Docker fundamentals before optimizing task definitions.

Managing Secrets Securely

Never embed secrets in environment variables or task definitions. Use AWS Secrets Manager or Systems Manager Parameter Store and reference them in the secrets block of your container definition. The execution role needs secretsmanager:GetSecretValue permission scoped to specific secret ARNs. This approach keeps sensitive values out of CloudFormation/Terraform state files and ECS API responses.

How do you configure auto-scaling and service deployment?

Fargate services scale based on CloudWatch metrics or custom metrics via Application Auto Scaling. The default CPU/memory targets are rarely sufficient for real workloads. In practice, I configure scaling on request count per target (for ALB-backed services) or SQS queue depth (for workers), as these correlate better with actual user experience than aggregate CPU utilization.

Configure scale-in protection with adequate cooldowns (300 seconds minimum) to avoid thrashing during transient spikes. Set minimum capacity to at least 2 tasks across multiple AZs for high availability. For cost-sensitive workloads, mix On-Demand and Fargate Spot capacity using a capacity provider strategy; Spot tasks can be interrupted with a 2-minute warning, so only use them for stateless, retry-tolerant services. Teams adopting Infrastructure as Code with Terraform should encode these scaling policies declaratively to ensure consistency across environments.

Deployment Strategies

Use rolling updates with a minimum healthy percentage of 100% and maximum of 200% to ensure zero-downtime deployments. For critical services, implement blue/green deployments using CodeDeploy with ECS; this allows validation of the new version before shifting traffic and provides instant rollback capability. Always test deployment configurations in staging first—misconfigured health checks are the #1 cause of failed Fargate deployments.

When should you choose Fargate over EC2 or EKS?

Fargate isn't universally optimal. Understanding its trade-offs prevents costly architectural mistakes. Below is a decision matrix based on real production scenarios I've encountered across Nepal-based startups and global enterprises:

Choose Fargate when operational simplicity outweighs raw cost efficiency, when workload patterns are spiky or unpredictable, or when your team lacks dedicated platform engineering resources. Choose EC2 for steady-state workloads with predictable resource needs where reserved instances yield significant savings. Choose EKS only when you need Kubernetes-specific features (custom operators, service mesh, multi-cluster federation) and have the expertise to manage it. For many Nepal-based teams with limited DevOps headcount, Fargate offers the best balance of production readiness and maintainability.

How do you optimize Fargate costs without sacrificing reliability?

Fargate pricing is straightforward (vCPU + memory per second), but bills escalate quickly without discipline. Right-sizing is paramount: use CloudWatch Container Insights or AWS Compute Optimizer to identify over-provisioned tasks. Most applications run fine at 0.5 vCPU / 1 GB initially; start small and scale up based on metrics, not guesses.

• Use Fargate Spot aggressively: For dev/staging environments, batch processing, and fault-tolerant microservices, Spot reduces costs by 50-70%. Configure capacity provider strategies to prefer Spot with On-Demand fallback.
• Leverage Savings Plans: Compute Savings Plans apply to Fargate usage automatically. Commit to 1-year terms for ~20% discount if baseline usage is predictable.
• Optimize container images: Smaller images reduce pull times and storage costs. Use multi-stage builds and distroless bases. Review multi-stage build techniques to cut image sizes by 60-80%.
• Implement scheduled scaling: Scale down non-production services outside business hours. A cron-based Lambda adjusting desired count saves ~65% on dev environments.
• Monitor orphaned resources: Stopped tasks, unused ECR images, and detached EBS volumes (from previous EC2 migrations) accumulate silently. Run weekly cost anomaly detection reviews.

In Nepal, where cloud budgets are often constrained and billed in NPR, these optimizations directly impact runway. One Kathmandu-based SaaS client reduced their monthly Fargate bill from $1,200 to $480 through right-sizing and Spot adoption alone—without any application changes.

Next Steps for Production Readiness

To successfully deploy containers on Amazon ECS with Fargate, begin with a minimal viable service in a properly segmented VPC, validate networking and IAM boundaries, then layer in auto-scaling and cost controls. Automate everything via Terraform or CloudFormation; manual console clicks create drift and audit failures. Integrate observability early—CloudWatch Logs, X-Ray tracing, and Container Insights are not optional extras but prerequisites for reliable operations.

If your team needs hands-on guidance architecting Fargate deployments, preparing for SOC 2 audits, or optimizing existing container workloads, reach out to discuss your specific requirements. I help teams build infrastructure that's secure, observable, and audit-ready from day one—not as an afterthought.