Deploying Spring Boot to AWS ECS Fargate

Deploying a Spring Boot application to ECS Fargate follows four stages: containerize, push to a registry, define the task, and create the service. Each stage has one common mistake that causes deployment failures.

Containerize — multi-stage Dockerfile

• A multi-stage Dockerfile builds the JAR in a Maven or Gradle stage and copies only the JAR into the final image — which means the final container doesn't include the JDK build tools, keeping the image small and reducing the attack surface
• Use a distroless or slim JRE base image for the final stage: FROM eclipse-temurin:21-jre-alpine gives a minimal runtime

Push to ECR

• Create an ECR repository with aws ecr create-repository --repository-name my-service; authenticate with aws ecr get-login-password | docker login; tag and push the image
• ECR stores images in the same region as ECS, which means image pulls are fast and don't incur cross-region data transfer costs

Task definition — CPU, memory, environment

• The ECS task definition specifies the container image, CPU units, memory, port mappings, IAM task role, and environment variables — environment variables for database URLs and feature flags go here, secrets come from Secrets Manager via the secrets field
• Set essential: true so ECS restarts the task if the container exits

Service — load balancing and health checks

• The ECS service maintains a desired count of running tasks, registers them with an ALB target group, and replaces unhealthy tasks automatically
• Configure the ALB health check to call Spring Boot's /actuator/health endpoint — ECS marks tasks unhealthy if the health check fails, replacing them before taking traffic

For zero-downtime deployments: use the ECS (Rolling update) deployment type with minimumHealthyPercent: 50 and maximumPercent: 200 so old tasks remain until new ones pass health checks.