Skip to main content
In this lesson we demonstrate ECS deployment methods and explain how to deploy containerized applications with Amazon Elastic Container Service (ECS). You’ll see common production strategies: rolling updates (ECS native), blue/green (CodeDeploy), and traffic-shifting patterns (canary/linear). This aligns with task 1.4: implement deployment strategies for container environments using different deployment methods. We’ll begin by inspecting the cluster and running service configuration before making changes.
A screenshot of the AWS Elastic Container Service console showing the "devops-020-280-cluster" (Fargate) cluster overview with status Active and CloudWatch Container Insights enabled. It shows one active service (devops-020-280-service) and two running tasks.
Cluster overview
  • Launch type: Fargate (serverless compute for containers).
  • Current state: one active service and two running tasks.
  • Before changing deployments, review desired task count, health checks, load balancer configuration, and deployment options (min/max percentages and circuit breaker).
Deployment controller options in ECS Use the controller that matches your availability, rollback and traffic-shifting needs: Fundamental difference
  • Rolling update: replaces tasks in-place using the same task set; concurrency controlled by min/max percentages.
  • Blue/green: creates an isolated new task set (green) alongside the active one (blue) and shifts traffic when ready.
Updating a service — rolling update settings When editing a service in the ECS console you’ll configure:
  • Task definition revision to deploy.
  • Desired task count.
  • Health check settings and load balancer target group mapping.
  • Deployment options: minimum healthy percent and maximum percent — these control concurrency and the speed/cost tradeoff for rolling updates.
A screenshot of the Amazon Elastic Container Service (ECS) console on the service Update page, showing deployment strategy options with "Rolling update" selected. The page also displays fields for Min/Max running tasks percentages and ECS navigation links in the left sidebar.
Example workflow from the demo
  • Initial desired tasks: 2. Updated desired count to 4 and applied the update.
  • After Update: ECS launched tasks that moved through PENDING → RUNNING while honoring minHealthyPercent and maxPercent. During the rollout you’ll commonly observe a mixture of RUNNING and PENDING tasks.
Important deployment controls
  • minHealthyPercent and maxPercent: primary knobs for controlling how many tasks remain healthy and how many can be added temporarily during a rolling update.
  • Deployment circuit breaker: when enabled, ECS will automatically roll back unstable deployments. Integrate CloudWatch alarms or CodeDeploy for automated rollback triggers.
Networking and troubleshooting options When updating a service you can also configure:
  • VPC, subnets, and security groups.
  • Whether tasks get public IP addresses.
  • ECS Exec (interactive troubleshooting) to run commands inside running containers for diagnostics.
Screenshot of the Amazon Elastic Container Service (ECS) console on the "Update" page showing Networking settings. It displays VPC, subnet and security group selections and a Troubleshooting configuration (ECS Exec) option.
Load balancing and target groups For services behind an Application Load Balancer (ALB):
  • Container:port mapping is registered to a target group and associated with a listener (e.g., HTTP:80 → container port 80).
  • When new tasks become healthy they register in the target group and ALB routes traffic to them after passing health checks.
A screenshot of the Amazon Elastic Container Service (ECS) console showing the "Load balancing" configuration for a service, including the VPC ID, an Application Load Balancer, an HTTP:80 listener, target group, and container:port mapping (app:80). The left sidebar shows ECS navigation links like Clusters and Task definitions.
Switching to a blue/green deployment
  • On the Update Service page you can select the blue/green deployment type (CodeDeploy-managed).
  • Configure production and test listeners and alternate target groups so traffic can be shifted between old and new task sets.
  • Blue/green supports lifecycle hooks (pre-traffic, post-traffic, validation hooks) so you can run validations or invoke Lambda functions during phases of the deployment.
A screenshot of the Amazon Elastic Container Service (ECS) console showing the "Update" service page with options for selecting a green target group, adding a load balancer, and configuring service auto scaling and volumes.
Lifecycle hooks and traffic-shifting patterns Blue/green deployments (via CodeDeploy) include phases such as:
  • Pre-traffic / post-traffic steps for validation.
  • Canary or linear traffic shifting to gradually direct traffic to the green task set.
  • Hooks and lifecycle events let you run tests, warm caches, or call external validation before fully switching production traffic.
Observing deployment progress and success
  • Monitor the Last deployment status to see deployment ID, status (Success/Failed), start/finish times, and task counts for each revision.
  • Successful blue/green rollouts will show the shift from the source task set to the target task set in the console.
Screenshot of the Amazon Elastic Container Service (ECS) console showing a service's Deployments page with "Last deployment" details (deployment ID, status = Success, start/finish times) and a list of service revisions and task counts.
Post-deployment task health
  • After deployment completes, verify the Tasks tab and confirm new tasks are in RUNNING state and report Healthy in their target group health checks.
A screenshot of the Amazon Elastic Container Service (ECS) console showing the Tasks tab for a service revision, listing four running tasks with "Healthy" health status. A green banner at the top indicates the service was updated.
Fargate vs. EC2 launch types Compare and choose based on operational needs: Practical tips:
  • Use Fargate to reduce infra management and accelerate launches.
  • Use EC2 when you need custom instance configuration or to optimize for cost at scale.
  • Always verify service quotas and limits (e.g., Fargate task quotas per region) before production deployments.
A screenshot of the Amazon Elastic Container Service (ECS) console showing the cluster "devops-020-280-cluster" with status Active, CloudWatch monitoring enabled, and 4 running tasks. The page displays the cluster overview, services list, and the ECS navigation sidebar.
Choosing the right deployment strategy:
  • Rolling update (ECS): choose for simple, cost-optimized rollouts when brief replacement periods are acceptable and health checks are fast.
  • Blue/green (CodeDeploy): choose for near-zero-downtime cutovers, instant rollback, and advanced traffic shifting (canary/linear) with lifecycle hooks.
  • External controllers (Spinnaker, Harness): choose when your organization relies on third-party CD workflows that orchestrate deployments and traffic.
Before scaling with Fargate, verify regional quotas and limits. Configure robust health checks, set appropriate minHealthyPercent / maxPercent, and enable rollback/circuit-breaker settings to reduce blast radius during faulty deployments.
Key concepts summary
  • Deployment controllers:
    • ECS (rolling update) — default, uses minHealthyPercent and maxPercent.
    • CODE_DEPLOY (blue/green) — integrates with AWS CodeDeploy for traffic shifting and lifecycle hooks.
    • EXTERNAL — third-party controllers manage rollout logic.
  • minHealthyPercent and maxPercent control rolling update concurrency and cost.
  • Blue/green gives an isolated task set for safer cutovers and easier rollback.
  • Canary and linear traffic-shifting patterns let you bake changes gradually.
  • Use CloudWatch alarms and the deployment circuit breaker to automate rollbacks on failures.
Further reading and references That wraps up this overview of ECS deployment methods and the console settings that control how deployments are executed.

Watch Video

Practice Lab