Skip to main content
Hello and welcome to this section. In this lesson we focus on deploying a Docker image to AWS and the key deployment options you can use to run, scale, and CI/CD your containers. At a high level, AWS offers multiple ways to run containers — in this lesson we concentrate on Amazon ECS because it best matches our current use case. Why ECS for this use case
  • Amazon ECS (Elastic Container Service) is a fully managed container orchestration service that provides a straightforward path from a Docker image to a running, scalable service.
  • ECS is simple to adopt, integrates tightly with other AWS services, and supports both serverless and self-managed compute models.
ECS — launch options and trade-offs
  • Fargate: serverless. AWS provisions compute per task. Minimal operational overhead—no EC2 instances to manage.
  • EC2 launch type: you manage the EC2 instances that form the cluster. More control over instance types, placement, and cost optimization.
Quick comparison: ECS, EKS, and other AWS container options ECS integrates tightly with many AWS production services:
  • Amazon ECR — container registry
  • Application Load Balancer (ALB) — routing and health checks
  • CloudWatch Logs & Metrics — observability
  • IAM — fine-grained permissions and roles
  • CodePipeline / CodeBuild / CodeDeploy or GitHub Actions — CI/CD and deployment automation
Common high-level ECS deployment flow
  1. Build your Docker image locally or in CI.
  2. Push the image to Amazon ECR.
  3. Define an ECS task definition describing the container(s), resource requests/limits, environment variables, logging, and port mappings.
  4. Create an ECS service (Fargate or EC2) to run one or more task copies; optionally attach an ALB/NLB.
  5. Automate the flow with CI/CD (e.g., CodePipeline + CodeBuild, GitHub Actions) to handle build → push → deploy.
Example: Push a Docker image to ECR (replace placeholders accordingly) Before pushing, make sure the ECR repository exists. Create it via the AWS CLI if needed:
Authenticate to ECR, tag, and push the image:
Key considerations before choosing a deployment option
  • Operational overhead: EKS (managed Kubernetes) introduces Kubernetes concepts and operational concerns. ECS (especially Fargate) reduces operational burden.
  • Ecosystem needs: If you require Kubernetes operators, CRDs, or multi-cloud portability, EKS may be the right choice.
  • Cost and scaling model: Fargate simplifies autoscaling and per-task billing; EC2 launch type can be more cost-efficient at scale with proper instance utilization.
  • Networking & security: Plan VPC subnets, security groups, task execution roles, and IAM policies up front. Choose ALB vs NLB based on routing, TLS, and latency needs.
  • CI/CD strategy: Decide between AWS-native tools (CodePipeline/CodeBuild/CodeDeploy) or external CI (e.g., GitHub Actions) that deploys to ECS.
Before you deploy, ensure you have:
  • an ECR repository for your image,
  • an ECS cluster (Fargate or EC2),
  • appropriate IAM roles for task execution, and
  • networking (VPC/subnets/security groups) configured.
These components are commonly automated with CloudFormation, Terraform, or the AWS CDK.
Recommended next steps (what we will cover next)
  • Creating an ECR repository and pushing images from CI
  • Writing ECS task definitions and container configuration
  • Creating ECS services on Fargate and EC2, and attaching ALB for routing and health checks
  • Setting up CI/CD pipelines (CodePipeline + CodeBuild or GitHub Actions) to automate build → push → deploy
  • Best practices for monitoring (CloudWatch), IAM least-privilege, and deployment strategies (rolling, blue/green)
That is it for this lesson. See you in the next lesson.

Watch Video