Fargate Security

AWS Fargate is a serverless compute engine for containers that removes the need to manage EC2 instances. Each Fargate task runs in its own isolated microVM (based on Firecracker), providing kernel-level isolation between customers.

Security Advantages

• No Host Access: no SSH, no host OS to patch, no shared kernel with other customers
• Ephemeral Storage: task storage is encrypted and destroyed when the task stops
• Reduced Attack Surface: AWS manages the infrastructure layer (shared responsibility model)

Security Responsibilities (You)

• Container image security (scan for vulnerabilities, use minimal images)
• Task IAM role permissions (least privilege)
• Network configuration (security groups, VPC subnets)
• Secrets injection (use Secrets Manager or SSM Parameter Store, not env vars)
• Logging (send container logs to CloudWatch)

Two Roles, Two Very Different Jobs

Every Fargate task definition can reference two IAM roles, and confusing them is a recurring source of over-permissioning. The task role (taskRoleArn) is what your application code uses to call AWS APIs: this is where your app's S3 or DynamoDB permissions belong. The execution role (executionRoleArn) is used by the container agent itself to pull images from ECR, fetch secrets for injection, and write logs to CloudWatch. Permissions your application needs do not belong on the execution role, and vice versa. Keep both scoped per task family rather than sharing one broad role across every service.

On the storage side, tasks on Linux platform version 1.4.0 or later get a minimum of 20 GiB of ephemeral storage, expandable to 200 GiB via the ephemeralStorage task definition parameter. For tasks launched on platform 1.4.0 since May 28, 2020, that storage is encrypted with AES-256 using an AWS owned key, and you can bring a customer managed KMS key if compliance requires it.

How It Goes Wrong in Practice

Fargate removes the host layer, but the classic compromise chain still works above it. A typical pattern: an internet-facing containerized app has a server-side request forgery (SSRF) or remote code execution flaw. The attacker uses it to read the task's credentials endpoint, which every container can reach, and now holds the task role's temporary credentials. If that task role was given AmazonS3FullAccess "to keep things simple", the attacker can enumerate and exfiltrate every bucket in the account without ever touching a host. The microVM isolation did its job perfectly; the blast radius was defined entirely by the task role policy.

Two adjacent mistakes make this worse. First, secrets passed as plaintext environment variables in the task definition: anyone with ecs:DescribeTaskDefinition permission can read them, and they surface in console views and IaC state files. Use the secrets container definition parameter referencing Secrets Manager or SSM Parameter Store instead, so only the execution role can resolve them at start time. Second, tasks launched with public IPs in public subnets to work around missing NAT or VPC endpoints, which turns an internal service into internet-reachable attack surface.

Practical Check: Audit Task Roles

Review which IAM roles a task definition actually grants (verify both roles, not just the one you remembered to set):

aws ecs describe-task-definition --task-definition my-service:8 --query 'taskDefinition.{TaskRole: taskRoleArn, ExecutionRole: executionRoleArn}'

The --task-definition parameter accepts a family name, family:revision, or full ARN. From there, inspect the task role's attached policies and ask the only question that matters: if these credentials leaked through the app, what could an attacker do with them? Runtime threat detection for Fargate workloads is available through GuardDuty Runtime Monitoring, which covers ECS on Fargate tasks.

Frequently Asked Questions

Do I still need to scan container images on Fargate?

Yes. AWS isolates and patches the infrastructure underneath the task, but everything inside your image (OS packages, language dependencies, your code) is your responsibility. Scan images in ECR and rebuild on a schedule so base image fixes actually reach production.

Is data on Fargate ephemeral storage encrypted?

Yes, for Linux tasks on platform version 1.4.0 or later launched since May 28, 2020, ephemeral storage is encrypted with an AES-256 algorithm using an AWS owned key, and a customer managed key is supported. The storage is tied to the task lifecycle and destroyed when the task stops.

What is the difference between the task role and the execution role?

The task role is assumed by your application containers to call AWS services. The execution role is used by ECS itself to pull the image, inject secrets, and ship logs. They should be separate roles with separate, minimal policies.