Cloud / Amazon ECS Interview questions

Amazon Elastic Container Service (ECS) is a fully managed container orchestration service that runs, stops, and manages Docker containers on a cluster.

Instead of you writing scheduling logic, ECS decides which containers land on which compute, restarts failed containers, and keeps the desired number of copies running. You describe your application in a task definition, and ECS handles placement, health tracking, and scaling.

ECS supports two ways to run containers: on EC2 instances you manage, or on AWS Fargate, a serverless compute engine where AWS manages the underlying servers entirely.

ECS supports two launch types that determine where your containers actually run.

1. EC2 launch type - tasks run on EC2 instances that you provision, patch, and register into a cluster. You control instance type, AMI, and capacity.
2. Fargate launch type - tasks run on serverless compute managed by AWS. You specify CPU and memory for the task, and AWS provisions the underlying infrastructure.

A third option, ECS Anywhere, extends ECS to run tasks on your own on-premises servers or virtual machines using an external launch type.

A task definition is a JSON blueprint that describes one or more containers that make up your application, similar to a docker-compose file for a single deployable unit.

It specifies the container image, CPU and memory limits, port mappings, environment variables, IAM roles, logging configuration, and networking mode. Each time you register changes, ECS creates a new revision rather than overwriting the existing one, so you can roll back.

{
  "family": "web-app",
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/web-app:1.4",
      "portMappings": [{ "containerPort": 80 }],
      "memory": 512,
      "cpu": 256
    }
  ]
}

An ECS cluster is a logical grouping of tasks or services, and, in the EC2 launch type, the underlying container instances that provide compute for them.

A cluster itself doesn't run anything by default - it's a namespace and resource pool. When you launch a Fargate task or EC2-backed task, you tell ECS which cluster to place it in, and ECS tracks capacity, running tasks, and services scoped to that cluster.

You can have multiple clusters per account to separate environments, such as one for staging and one for production.

An ECS service keeps a specified number of task instances running continuously, replacing any that stop or fail health checks.

You configure a service with a task definition, a desired count, and optionally a load balancer target group. ECS then continuously reconciles the actual running count against the desired count, launching replacement tasks whenever one is stopped or fails a health check.

Services also manage rolling deployments: when you update the task definition, ECS gradually replaces old tasks with new ones according to your deployment configuration.

A container instance is an EC2 instance that is registered into an ECS cluster and running the ECS container agent.

It's only relevant to the EC2 launch type - Fargate has no visible container instances because AWS manages that layer for you. Each container instance reports its available CPU, memory, and port resources to the ECS control plane, which uses that information to decide where new tasks can be placed.

You manage the instance's OS patching, AMI, and scaling group; ECS manages what runs on top of it.

The ECS container agent is a lightweight process that runs on every EC2 container instance and communicates with the ECS control plane over HTTPS.

It polls ECS for task assignments, starts and stops containers via the local Docker daemon, reports resource utilization and task status back to ECS, and forwards container health information. Without a healthy agent, ECS cannot place new tasks on that instance or receive status updates from it.

On Fargate, an equivalent agent exists but is fully managed - you never install or patch it yourself.

You define environment variables directly on each container inside the task definition using the environment field for plain values, or secrets for sensitive values pulled from AWS Secrets Manager or Systems Manager Parameter Store.

"environment": [
  { "name": "LOG_LEVEL", "value": "info" }
],
"secrets": [
  { "name": "DB_PASSWORD", "valueFrom": "arn:aws:ssm:...:parameter/db-password" }
]

Plain values are visible in the task definition JSON and console, so they suit non-sensitive configuration like feature flags or log levels. Anything sensitive, such as passwords or API keys, should go through secrets so it's resolved at container start rather than stored in plaintext.

Fargate is a serverless compute engine for containers where you specify only the CPU and memory your task needs, and AWS provisions, scales, and patches the underlying infrastructure automatically.

There are no EC2 instances to manage, no capacity to pre-provision, and no host-level patching. Each Fargate task runs in its own isolated compute environment, which also improves security isolation between tasks compared to sharing an EC2 host.

Fargate is billed per task based on the vCPU and memory reserved for the duration it runs, plus an optional Fargate Spot discounted mode for interruption-tolerant workloads.

ECS supports four networking modes, configured per task definition:

Fargate tasks must use awsvpc; EC2 tasks can use any of the four depending on isolation and port-management needs. The mode is set once, at the task-definition level, via the networkMode field, so switching between them later means registering a new revision rather than changing a running task in place.

In awsvpc mode, each ECS task receives its own elastic network interface (ENI) with a private IP address from your VPC subnet, just like an EC2 instance would.

This means every task gets its own security group rules, its own ENI-level flow logs, and no port conflicts with other tasks on the same host, since each task effectively has its own network stack. It also lets you attach an Application Load Balancer directly to the task's IP rather than to a dynamic host port.

awsvpc is required for Fargate tasks and is the recommended mode for EC2 tasks needing per-task security isolation.

An ECS task moves through a defined sequence of states from creation to termination:

flowchart LR
  A[PROVISIONING] --> B[PENDING]
  B --> C[ACTIVATING]
  C --> D[RUNNING]
  D --> E[DEACTIVATING]
  E --> F[STOPPING]
  F --> G[DEPROVISIONING]
  G --> H[STOPPED]

1. PROVISIONING - resources like ENIs are being set up (awsvpc mode).
2. PENDING - ECS is placing the task and pulling container images.
3. ACTIVATING - additional setup, such as Service Connect proxies, is running.
4. RUNNING - all containers have started successfully.
5. DEACTIVATING / STOPPING / DEPROVISIONING - graceful shutdown steps.
6. STOPPED - the task has fully terminated, with a stoppedReason recorded.

A capacity provider tells ECS where and how to obtain the compute capacity for your tasks, decoupling the "what to run" (task definitions) from the "where to run it" (capacity source).

ECS offers built-in capacity providers FARGATE and FARGATE_SPOT, and for EC2 you create custom capacity providers backed by an Auto Scaling group. A cluster can use a capacity provider strategy that mixes multiple providers with a weight (relative distribution) and base (minimum guaranteed count).

This lets a service, for example, run a guaranteed baseline on regular Fargate while bursting onto cheaper Fargate Spot capacity.

Placement strategies tell ECS how to choose among the available candidate instances when launching a task on the EC2 launch type (Fargate manages placement for you).

• binpack - packs tasks onto the fewest instances by CPU or memory, minimizing idle capacity.
• spread - distributes tasks evenly across a specified field, such as Availability Zone or instance ID, for high availability.
• random - places tasks on a random valid instance.

You can combine strategies, such as spreading across Availability Zones first and then binpacking within each zone, by listing multiple strategy rules in order of priority.

ECS Service Connect gives ECS services simple DNS-based service discovery and automatic traffic metrics between services, without requiring a separate service mesh.

When enabled, ECS injects a lightweight proxy into each task that intercepts traffic, resolves logical service names like orders.internal, and reports request counts, latency, and error rates directly in the ECS console and CloudWatch, no manual instrumentation required.

It's aimed at teams who want reliable service-to-service calls and built-in observability without the operational overhead of running a full mesh like App Mesh.

The task execution role is an IAM role that the ECS agent itself assumes on your behalf to perform infrastructure-level actions needed to launch a task.

It typically grants permission to pull container images from ECR, write logs to CloudWatch Logs, and retrieve values referenced in the secrets field from Secrets Manager or SSM Parameter Store. It is not used by your application code at runtime.

Every task that pulls a private image or uses injected secrets needs an execution role attached in its task definition's executionRoleArn field.

The task role is an IAM role assumed by the application code running inside the container, granting it permissions to call other AWS services such as S3, DynamoDB, or SQS.

Credentials are delivered securely via a per-task metadata endpoint, so the application never needs hardcoded AWS access keys. This is distinct from the execution role, which the ECS agent uses only for launch-time operations like pulling images.

Following least privilege, each task definition should have a task role scoped only to the specific AWS APIs that application actually needs.

Deploying to ECS generally follows a repeatable sequence:

1. Build the Docker image and push it to a registry, typically Amazon ECR.
2. Write or update a task definition that references the new image tag.
3. Register the task definition, which creates a new revision.
4. Update the ECS service to use that revision, or run a standalone task.
5. ECS performs a rolling deployment, starting new tasks and draining old ones based on your deployment configuration.

This can be done via the AWS Console, CLI (aws ecs update-service), CloudFormation, CDK, or CI/CD pipelines such as CodePipeline or GitHub Actions.

Amazon Elastic Container Registry (ECR) is a managed Docker image registry for storing, versioning, and scanning container images.

ECS pulls container images referenced in a task definition's image field, and while ECS can pull from any accessible registry (Docker Hub, GHCR, etc.), ECR is the natural default because it integrates directly with IAM for access control and with the task execution role for authentication - no separate registry credentials need to be managed.

ECR also supports image scanning for vulnerabilities and lifecycle policies to automatically clean up old image tags.

Placement constraints restrict which instances are eligible to run a task, based on rules rather than optimization, unlike placement strategies which optimize distribution.

• distinctInstance - ensures each task in a group runs on a different container instance.
• memberOf - restricts placement to instances matching a cluster query language expression, such as a specific instance type or custom attribute.

"placementConstraints": [
  { "type": "memberOf", "expression": "attribute:ecs.instance-type == c5.large" }
]

Constraints are useful for licensing requirements tied to specific hardware, or ensuring redundant copies of a task never share a single point of failure.

ECS services support three deployment controller types:

1. Rolling update (ECS) - the default; ECS incrementally replaces old tasks with new ones based on minimum/maximum healthy percent settings.
2. Blue/green (CODE_DEPLOY) - AWS CodeDeploy provisions a parallel "green" task set, shifts traffic via load balancer listener rules, and can automatically roll back on alarms.
3. External - you supply your own custom deployment logic and task set management, typically for advanced third-party orchestration integrations.

Rolling updates are simplest to operate; blue/green offers safer, instant traffic cutover and rollback at the cost of extra CodeDeploy setup.

ECS Anywhere extends the ECS control plane to manage containers running on infrastructure outside AWS - your own data center servers or virtual machines.

You install the ECS agent and SSM agent on your external server, register it with ECS using an activation key, and it then appears as a container instance using the EXTERNAL launch type. From there, task definitions, services, and most ECS APIs work the same way they would for an EC2-backed cluster.

It's aimed at hybrid environments where teams want a single consistent orchestration API across cloud and on-premises workloads.

You configure a log driver in the container definition's logConfiguration block. The most common driver is awslogs, which streams container stdout/stderr directly to CloudWatch Logs.

"logConfiguration": {
  "logDriver": "awslogs",
  "options": {
    "awslogs-group": "/ecs/web-app",
    "awslogs-region": "us-east-1",
    "awslogs-stream-prefix": "web"
  }
}

The task execution role must include permission to create log streams and put log events. Other supported drivers include splunk, fluentd, and awsfirelens for routing logs to third-party aggregators. Once configured, logs appear automatically in the specified CloudWatch log group, organized into a separate stream per task so you can trace output back to a specific task ID.

Fargate Spot runs Fargate tasks on spare AWS compute capacity at a significant discount compared to standard Fargate pricing, in exchange for the possibility of interruption with a two-minute warning.

It's suited to fault-tolerant, stateless, or batch-style workloads - things like CI runners, queue consumers, or non-critical background processing - where an occasional task restart is acceptable. You typically mix it with regular Fargate in a capacity provider strategy, keeping a guaranteed baseline on standard Fargate and bursting extra capacity onto Spot.

It should be avoided for workloads that cannot tolerate abrupt termination, such as long-running stateful sessions.

Both run containers on AWS, but they use different orchestration models and APIs.

Teams already invested in Kubernetes tooling, or needing multi-cloud portability, tend to pick EKS. Teams wanting the fastest path to running containers on AWS with minimal operational overhead tend to pick ECS. Both can run on either EC2 or Fargate compute, so the choice usually comes down to orchestration API preference rather than compute options.

The core distinction is who manages the underlying servers.

Choose Fargate for operational simplicity; choose EC2 launch type when you need tighter cost control at scale, specific instance types, or host-level customization.

Although both are IAM roles attached to a task definition, they serve different actors at different times.

Mixing them up is a common misconfiguration: granting S3 access on the execution role instead of the task role, for example, does nothing for your application code, since the app never assumes the execution role.

The three EC2-compatible network modes trade off isolation against simplicity differently.

host mode gives the best raw network performance but the least isolation. awsvpc gives the strongest isolation and is the only mode Fargate supports. In practice, most new EC2-based services default to awsvpc unless there's a specific reason - like needing dynamic port mapping across many tasks per host - to choose bridge instead.

Fargate removes an entire operational layer: there's no AMI to patch, no capacity to pre-provision, and no Auto Scaling group to tune for headroom.

This matters most when a team's priority is shipping features rather than managing infrastructure, when workloads are spiky and hard to right-size on EC2 without waste, or when strict per-task network and compute isolation is a security requirement. Billing aligns directly with the resources a task actually reserves, rather than paying for whole EC2 instances that may be under-packed.

The trade-off is less control - you can't choose custom AMIs, GPU-backed instances (beyond limited Fargate GPU support), or host networking mode - so very cost-sensitive, high-density workloads may still favor EC2 launch type for tighter bin-packing.

Placement strategies exist because, on the EC2 launch type, multiple valid instances could host a new task, and the "best" choice depends on your goals - cost efficiency versus fault tolerance.

Without a strategy, ECS would place tasks somewhat arbitrarily among eligible instances, potentially clustering all replicas of a service on one Availability Zone (a resilience risk) or spreading them thinly across many under-utilized instances (a cost inefficiency). By explicitly choosing binpack, spread, or a combination, you make that trade-off intentional.

A common real pattern is spreading across Availability Zones for resilience first, then binpacking within each zone to reduce the number of instances paid for.

ECS service auto scaling uses Application Auto Scaling to adjust a service's desired task count based on real-time metrics.

You register the service as a scalable target with a minimum and maximum task count, then attach one or more scaling policies:

1. Target tracking - keeps a metric like average CPU utilization or ALB request count per task near a target value, automatically calculating how many tasks to add or remove.
2. Step scaling - adds or removes a specific number of tasks based on how far a CloudWatch alarm threshold is breached.
3. Scheduled scaling - changes desired count at fixed times, useful for predictable daily traffic patterns.

This adjusts task count only. If you're on the EC2 launch type, you separately need cluster capacity providers or Auto Scaling group scaling to ensure enough underlying instance capacity exists for those extra tasks.

The deployment circuit breaker detects failed deployments automatically and rolls back to the last known-good task definition, instead of leaving a service stuck retrying a broken revision indefinitely.

flowchart TD
  A["New deployment starts"] --> B["New tasks launched"]
  B --> C{Tasks reach RUNNING and pass health checks?}
  C -- Yes --> D["Deployment completes"]
  C -- No, repeated failures --> E["Circuit breaker trips"]
  E --> F["Automatic rollback to previous task definition"]

You enable it per service with a rollback option. ECS counts consecutive task failures during rollout, and once a failure threshold is crossed, it stops launching more failing tasks and, if rollback is enabled, redeploys the prior stable revision automatically - reducing manual intervention during a bad release.

ECS offers two main paths for services to find and call each other by name instead of hardcoded IPs.

sequenceDiagram
  participant OrdersTask as Orders Task
  participant CloudMap as AWS Cloud Map / DNS
  participant PaymentsTask as Payments Task
  OrdersTask->>CloudMap: Resolve "payments.internal"
  CloudMap-->>OrdersTask: Return current healthy IP(s)
  OrdersTask->>PaymentsTask: Send request directly

1. AWS Cloud Map integration - ECS automatically registers and deregisters task IPs as a private DNS namespace, updated as tasks scale or replace.
2. ECS Service Connect - builds on Cloud Map but adds a managed proxy per task, giving DNS resolution plus built-in metrics and simpler configuration.

Both remove the need to manually track changing task IPs behind a load balancer for internal service-to-service traffic.

Choose binpack when your priority is cost efficiency on the EC2 launch type - packing as many tasks as possible onto the fewest running instances, based on CPU or memory as the packing dimension.

This is a good fit for batch or background-processing clusters where instances can be safely scaled in once utilization drops, since binpack naturally leaves some instances empty and ready for termination by the Auto Scaling group. It's a weaker fit for latency-sensitive, customer-facing services where you'd rather spread load and reduce blast radius per host.

In practice, many teams combine it with a spread strategy across Availability Zones first, then binpack within each zone.

EC2 launch type makes sense when you need capabilities Fargate doesn't fully expose, or when running at a scale where bin-packing savings outweigh the operational overhead.

• You need GPU instance types beyond what Fargate currently offers, or specialized instance families.
• You want host networking mode for maximum network throughput.
• You run many small, bursty tasks and can bin-pack them tightly onto fewer, larger instances for lower effective cost than per-task Fargate pricing.
• You need custom AMIs, kernel-level tuning, or specific EC2 reserved/savings plan commitments already in place.

If none of these apply, Fargate's reduced operational burden usually wins by default. Many teams also start every new service on Fargate and only migrate specific, well-understood workloads to EC2 launch type once a concrete cost or capability driver justifies the added operational work.

The outcome depends on which health check failed, but the general pattern is the same: ECS (or the load balancer) marks the task unhealthy, stops routing traffic to it, and the service scheduler replaces it.

1. If a container health check (defined in the task definition) fails repeatedly past its retry threshold, ECS marks the container - and therefore the task - as UNHEALTHY and stops it.
2. If an ELB target group health check fails, the load balancer stops sending new requests to that task's IP/port, and ECS eventually stops the task once it's confirmed unhealthy for long enough.
3. In both cases, if the task belongs to a service, the scheduler launches a replacement to restore the desired count.

Standalone tasks (not part of a service) are not automatically replaced - they simply stop.

These two settings jointly control how aggressively a rolling deployment replaces tasks.

For example, with desired count 4, minimum 100%, and maximum 200%, ECS can launch up to 4 new tasks before terminating any old ones, guaranteeing zero capacity loss during rollout.

Cost optimization on ECS usually comes from a mix of right-sizing, capacity mix, and scheduling choices rather than any single setting.

1. Right-size CPU/memory - use CloudWatch Container Insights to find over-provisioned tasks and trim reservations to match actual usage.
2. Mix in Fargate Spot or EC2 Spot for interruption-tolerant workloads via a capacity provider strategy with a small guaranteed base and a larger weighted Spot portion.
3. Bin-pack on EC2 launch type using the binpack placement strategy to reduce idle instance capacity.
4. Scale to zero or low counts off-hours with scheduled Application Auto Scaling for non-production or predictable-traffic services.
5. Use Savings Plans covering Fargate or EC2 compute for steady-state baseline usage.

The right combination depends on whether workloads are steady-state (favor commitments and bin-packing) or bursty (favor Spot and autoscaling).

A task lingering in PENDING usually means ECS can't finish placing or starting it, and the fix depends on the launch type and root cause.

1. Check service events in the console or via aws ecs describe-services - ECS often logs a human-readable reason, like insufficient CPU/memory or ENI limits reached.
2. Image pull failures - verify the execution role has ECR permissions and the image URI/tag exists.
3. ENI/subnet exhaustion (awsvpc mode) - confirm the subnet has free IP addresses and the security group/route table allow required traffic.
4. Insufficient EC2 capacity (EC2 launch type) - check if the cluster has container instances with enough free CPU/memory, or if the Auto Scaling group needs to scale out.
5. Task definition errors - invalid resource limits or missing required fields can prevent scheduling entirely.

Cross-referencing stoppedReason on any related failed tasks and CloudWatch Logs for the container agent narrows this down quickly.

Launching a task, whether from a service or a one-off RunTask call, follows a consistent sequence through the ECS control plane:

sequenceDiagram
  participant User as Caller (Service/RunTask)
  participant ECS as ECS Control Plane
  participant Sched as Scheduler
  participant Infra as Fargate/EC2 Instance
  participant Agent as Container Agent
  User->>ECS: Request task launch
  ECS->>Sched: Evaluate placement (strategy/constraints)
  Sched-->>ECS: Selected target capacity
  ECS->>Infra: Provision ENI (awsvpc) / assign instance
  ECS->>Agent: Assign task
  Agent->>Agent: Pull image(s), start containers
  Agent-->>ECS: Report RUNNING + health status

1. ECS receives the launch request and validates the task definition.
2. The scheduler evaluates placement strategies/constraints (EC2) or allocates Fargate capacity.
3. Networking resources are provisioned if using awsvpc mode.
4. The container agent pulls images (using the execution role) and starts containers in the order defined by dependsOn.
5. The agent reports status back, transitioning the task through PENDING to RUNNING once all containers and health checks pass.

The container agent acts as the bridge between the ECS control plane and the local Docker (or containerd) runtime on a container instance.

sequenceDiagram
  participant ECS as ECS Control Plane
  participant Agent as Container Agent
  participant Docker as Docker Daemon
  Agent->>ECS: Long-poll for task assignments (HTTPS)
  ECS-->>Agent: Send task payload
  Agent->>Docker: Pull image, create & start containers
  Docker-->>Agent: Container state changes
  Agent->>ECS: Report task/container status

Internally, it maintains a persistent HTTPS connection to the ECS backend, listening for state change requests. When it receives a new task, it translates the task definition into Docker API calls - pulling images, creating containers with the specified CPU/memory limits, and wiring up networking per the chosen network mode.

It also exposes a local task metadata and stats endpoint inside each container, which application code or sidecars can query for information like the task ARN or resource utilization. If the agent itself is disconnected, existing tasks keep running, but ECS cannot place new ones or receive updates until connectivity is restored.

An ECS service deployment progresses through a controlled replacement of task sets, tracked as a distinct deployment object on the service.

flowchart TD
  A["Update service with new task definition"] --> B["New PRIMARY deployment created"]
  B --> C["Launch new tasks up to maximumPercent"]
  C --> D{New tasks healthy?}
  D -- Yes --> E["Drain and stop old tasks down to minimumHealthyPercent"]
  E --> F["Old deployment reaches 0 tasks"]
  F --> G["Deployment COMPLETED"]
  D -- No, repeated failures --> H["Circuit breaker rollback if enabled"]

1. Updating a service's task definition creates a new PRIMARY deployment while the current one becomes ACTIVE.
2. New tasks launch gradually, respecting maximumPercent.
3. As new tasks pass health checks, old tasks are deregistered from any load balancer target group and stopped, respecting minimumHealthyPercent.
4. Once the old deployment reaches zero tasks, it's removed and the new deployment becomes the sole PRIMARY, marked COMPLETED.

If the deployment circuit breaker is enabled and new tasks keep failing, the service rolls back to the previous deployment instead of completing.

Both help services communicate reliably, but they target different levels of complexity and control.

Choose Service Connect for straightforward service-to-service calls with built-in metrics and minimal configuration. Choose App Mesh when you need advanced traffic shaping, canary releases, or mutual TLS across a large microservices estate. Some organizations start with Service Connect and only adopt App Mesh later once traffic-management requirements outgrow what Service Connect exposes.

Blue/green deployment on ECS uses AWS CodeDeploy as the deployment controller instead of ECS's native rolling updater, giving instant traffic cutover and automated rollback.

flowchart TD
  A["Deploy new task definition"] --> B["CodeDeploy creates GREEN task set"]
  B --> C["Health checks pass on GREEN"]
  C --> D["Traffic shifted from BLUE to GREEN via listener rule"]
  D --> E{CloudWatch alarms healthy?}
  E -- Yes --> F["BLUE task set terminated"]
  E -- No --> G["Automatic rollback to BLUE"]

1. CodeDeploy provisions a second, parallel GREEN task set alongside the existing BLUE one.
2. Once GREEN passes its health checks, an ALB listener rule shifts traffic - all at once or gradually (canary/linear).
3. CodeDeploy monitors CloudWatch alarms during a bake time; if they trip, it automatically reroutes traffic back to BLUE.
4. If healthy, the old BLUE task set is terminated after the bake period.

This avoids the mixed-version window inherent to rolling updates, at the cost of needing double capacity briefly and additional CodeDeploy configuration.

Whether a stopped task restarts depends entirely on how it was launched, not on ECS "forgetting" about it.

A task launched directly via RunTask is a standalone unit with no supervisor watching it - once it stops, for any reason, ECS considers its job done and takes no further action. Restart behavior only exists at the service level: a service continuously compares the actual running count to its desired count and launches replacements for any service-managed task that stops, whether due to a crash, a deployment, or manual termination.

So a standalone task stopping is expected behavior, not a failure of ECS - if you need self-healing, run the workload as a service (or use EventBridge Scheduler / Step Functions to relaunch one-off tasks on a schedule or condition).

A sidecar is an additional container in the same task definition that supports the main application container - for logging, proxying, or metrics collection - sharing the task's network namespace and, optionally, storage volumes.

"containerDefinitions": [
  { "name": "app", "image": "app:1.0", "dependsOn": [
      { "containerName": "log-router", "condition": "START" }
  ]},
  { "name": "log-router", "image": "amazon/aws-for-fluent-bit:latest" }
]

Because containers in one task definition share the same ENI (in awsvpc mode) and can share mounted volumes, a sidecar can intercept traffic on localhost, tail log files written to a shared volume, or proxy outbound calls, without any extra networking setup.

Use dependsOn with a condition like START or HEALTHY to control startup order, ensuring the sidecar is ready before the main application container starts if it depends on it.

Port mapping determines how a container's exposed port is reachable from outside, and it behaves differently depending on network mode.

With awsvpc mode, this distinction mostly disappears, since each task has its own IP and can use the same container port without any host-level conflict at all.

For EC2-backed clusters, capacity providers link an Auto Scaling group (ASG) to ECS through a managed scaling configuration, so the ASG grows or shrinks based on actual task demand rather than raw instance-level metrics alone.

flowchart TD
  A["Service requests more tasks"] --> B{Enough free capacity on instances?}
  B -- No --> C["Capacity Provider triggers ASG scale-out via managed scaling"]
  C --> D["New EC2 instances register as container instances"]
  D --> E["Pending tasks placed on new capacity"]
  B -- Yes --> E
  E --> F["Idle instances later scaled-in by managed termination protection rules"]

ECS computes a target capacity percentage - how full instances should be - and reports a CloudWatch metric that the ASG's scaling policy consumes to add or remove instances. Managed termination protection ensures instances aren't terminated while they still host running tasks, avoiding disruptive mid-task instance removal.

awsvpc mode is generally the stronger choice for security-sensitive workloads, though the right answer depends on context.

Because each task gets its own elastic network interface, you can apply per-task security groups - a task handling payment data can have tighter inbound/outbound rules than a task serving static assets, even on the same cluster. Bridge mode, by contrast, shares the host's network stack across all tasks on that instance, so security groups apply at the instance level, and a compromised container has more opportunity for network-level lateral movement toward its neighbors.

The trade-off is that awsvpc consumes one ENI per task, which can hit ENI density limits on smaller EC2 instance types faster than bridge mode would. For most production workloads handling sensitive data, that trade-off favors awsvpc's isolation; for very high-density, non-sensitive batch workloads on EC2, bridge may still be acceptable.

ECS Exec lets you open an interactive shell or run a one-off command inside a running task's container, similar to kubectl exec, without SSH access to any host.

1. Ensure the task role includes the ssmmessages permissions (CreateControlChannel, CreateDataChannel, OpenControlChannel, OpenDataChannel).
2. Enable Exec when creating the service or running the task: --enable-execute-command.
3. Connect to a running container:

aws ecs execute-command \
  --cluster my-cluster \
  --task <task-id> \
  --container app \
  --interactive \
  --command "/bin/sh"

Under the hood, it tunnels through AWS Systems Manager Session Manager, so no inbound ports need to be opened and all session activity can be logged to CloudWatch or S3 for auditing. It's intended for troubleshooting, not as a routine deployment mechanism.