AWS container security is a shared responsibility, and your team owns most of it.

Sure, AWS secures the underlying infrastructure that your containers run on, but everything you place on top of that infrastructure stays with you.

This includes the images you deploy, the IAM roles you assign, the runtime behavior of your workloads, and the network rules around them. These are also the areas attackers target first, and how much of it you own depends on the runtime. ECS, EKS, Fargate, and EC2 each handle security differently, with their own misconfigurations and controls.

This guide covers what AWS container security is and what it includes, the most common AWS container risks and threats, and how to secure containers across ECS, EKS, Fargate, and EC2. It also walks through the AWS-native security services for containers and the best practices that tie them together.

What Is AWS Container Security and What Does It Cover?

AWS container security covers every control that protects your containerized workloads from build to runtime: the images you ship, the identities they run as, the traffic between them, and the audit trail behind them. 

AWS handles the security of the platform underneath, while you’re responsible for securing everything that runs on top of it.

How much of that falls on you is set by the AWS shared responsibility model, and your share changes depending on the runtime you use:

• ECS or EKS on EC2: You own the most here, from the host operating system and node patching to the container runtime and every workload above it.
• ECS or EKS on Fargate: AWS takes over the operating system and underlying compute, leaving you the container image, task and pod definitions, IAM roles, and networking.
• EKS control plane: Whichever compute you pick, AWS runs and patches Kubernetes itself, while RBAC, network policies, and workload security stay with you.
• ECS control plane: Fully AWS-managed, so there’s nothing to configure here. Your focus stays on task definitions, IAM roles, and the images you run.

It’s worth knowing exactly which side owns what, because almost every container security incident happens on the side you control. In fact, Red Hat’s State of Kubernetes Security report found that 89% of organizations had at least one container or Kubernetes security incident in the past year, with the most common being runtime incidents, vulnerabilities, and misconfigurations. Each of those sits on the side you own rather than the AWS platform.

This makes AWS container security less about trusting the platform and more about applying solid container security best practices to your own configuration.

Common AWS Container Security Risks and Threats

Most AWS container threats come from a handful of predictable weak spots rather than exotic, novel attacks. They cluster around a few attack surfaces: the images you run, the identities and secrets your workloads carry, what they do at runtime, and how they’re exposed to the network.

The threats below are grouped by surface, so each one maps to a control you’ll put in place later in this guide.

1. Vulnerable and untrusted container images

Most AWS container compromises start with the image itself. According to Red Hat, 49% of organizations ran into insecure container images in their environments within a single year. 

This usually happens because a base image built on outdated packages, or pulled from a public registry without checks, carries known vulnerabilities and occasionally malware straight into your workloads.

On AWS, the problem is teams pulling freely from public Docker Hub images and push them to Amazon ECR with image scanning switched off. The vulnerable layers then ship to production unnoticed, and as container adoption grows, the volume of unscanned images only increases.

Plus, the damage spreads fast. Every task or pod launched from a bad image inherits its flaws, so a single vulnerable image can effectively replicate the same weakness across an entire cluster.

2. Over-permissioned IAM and stolen credentials

With 34% of organizations flagging exposed or unprotected secrets as a high-risk issue in their container environments, identity is the most AWS-specific container threat, and the most damaging one.

Workloads run with IAM roles, and when a role carries more permissions than the task needs, one compromised container hands an attacker a key into the wider account. On EKS, the same problem appears through weak Kubernetes security controls like over-permissive RBAC.

Two patterns make AWS especially exposed:

• Pods and tasks can often reach the EC2 instance metadata service (IMDS) and steal the node’s own credentials, escalating from a single workload to the entire instance.
• Secrets get stored in plaintext inside ECS task definitions and environment variables, where they surface in CloudWatch logs and the console.

We’ve already seen both patterns play out in the wild. At Black Hat USA 2025, researchers disclosed ECScape, an attack that lets a low-privileged ECS container on EC2 lift the IAM credentials of higher-privileged tasks on the same host using only default ECS settings. 

The risk became concrete again that November, when attackers turned stolen IAM credentials into more than 50 ECS clusters per account and quietly ran cryptomining across them.

And once credentials are loose, the blast radius reaches far past the container. They open access to S3, RDS, and Secrets Manager, along with lateral movement across the whole account.

3. Runtime abuse and container escape

Runtime is where the most container incidents occur, with 45% of organizations facing a security issue at runtime in a single year. 

Once a container is live, attackers try to make it do things it was never built to do: mine cryptocurrency, run unauthorized processes, or break out of the container onto the host node.

On AWS, this plays out most often through privileged containers on EC2-backed nodes. A privileged pod that escapes can reach the node’s IAM role and the instance metadata service, turning one contained workload into a foothold on the entire instance. Cryptojacking is the usual payoff, since idle compute converts into someone else’s mining profit.

The blast radius then climbs in steps: from the container, to the node, and on to the cluster and account whenever the node’s IAM role carries broad permissions. Catching this early is the whole point of securing Kubernetes at the runtime layer.

4. Exposed network and services

With 32% of organizations flagging poor network security as a high-risk issue, network exposure is what turns an internal weakness into an internet-facing one. The usual culprits are:

• Over-permissive security groups
• Load balancers open to the world
• Cluster API endpoints reachable from the public internet

On AWS, security group sprawl is the recurring problem. Rules get widened during troubleshooting and rarely tightened again, leaving ports open long after they’re needed. A publicly reachable EKS API server compounds it, handing attackers a direct path to probe the cluster.

How far this goes depends on what’s exposed, but the pattern holds: a public opening gets attackers in, and flat internal networking lets them move freely once they’re inside.

5. Software supply chain weaknesses

With 57% of organizations detecting vulnerable application components in their software supply chain within the past year, this is one of the most widely experienced threats of them all. 

Supply chain attacks target everything that goes into your image before it ever runs, from compromised open-source dependencies to tampered base images and weak CI/CD pipelines, all of which let malicious code reach production through trusted channels.

On AWS, the risk concentrates in the pipeline that pushes images to ECR. If that pipeline accepts unsigned images or pulls dependencies without verification, a single poisoned component gets built into an image and distributed automatically to every environment that uses it.

What makes this dangerous is how hard it is to catch. The component arrives through your own pipeline, so it clears the checks you’d normally trust and reaches production before anyone identifies it as malicious.

{{article-cta}}

How to Secure Containers Across AWS Services: EC2, Fargate, ECS, and EKS

Securing AWS containers comes down to two choices: the compute you run on and the orchestrator on top of it. Each pairing draws the responsibility line in a different place, so a control that’s essential on EC2 can be irrelevant on Fargate. The table below summarizes who secures what:

1. Securing containers on Amazon EC2

EC2 puts the most on your plate, because AWS secures only the physical infrastructure and hypervisor. Everything from the host OS upward is yours, which is why this is the launch type behind both ECS and EKS when you run your own instances, and why it carries the widest attack surface of the four.

The misconfigurations here are mostly about the host. Unpatched nodes leave known kernel and runtime CVEs exposed, and the highest-impact mistake is leaving the instance metadata service (IMDS) reachable from inside your containers. A compromised pod that can call IMDS can steal the node’s IAM credentials, which is the exact path ECScape and the November 2025 cryptomining campaign both relied on.

Three native controls do most of the work on EC2:

• Use hardened, regularly rebuilt AMIs (such as Bottlerocket) to shrink the host attack surface and keep patching current.
• Enable GuardDuty to catch credential misuse and unauthorized processes on the node.
• Lock down IMDS, covered in the tip below, since it’s the highest-leverage fix of the three.

Done right, EC2 gives you more control than any other AWS container option. The tradeoff is that the responsibility for using that control well sits entirely with you.

{{article-pro-tip}}

2. Securing containers on AWS Fargate

Fargate flips the EC2 model. AWS takes over the host OS, the kernel, and the container runtime, and runs each task inside its own micro-VM. 

This design removes the single most dangerous EC2 path: there’s no shared host node for a compromised container to pivot into, and no node credentials sitting in IMDS to steal. It’s the reason AWS itself recommends Fargate as the mitigation for ECScape-style attacks.

What stays with you is the workload: the container image, the task or pod definition, the IAM roles, and the networking. The misconfigurations here cluster around two things: over-permissioned task roles, which remain the main identity risk once node-credential theft is off the table, and unscanned images, since Fargate protects the runtime but never inspects what you ship into it.

The native controls that matter most on Fargate are:

• Apply least privilege to every task role, granting only the AWS services that task actually calls.
• Turn on ECR image scanning, so a vulnerable image can’t undermine the protection the micro-VM gives you.
• Use GuardDuty Runtime Monitoring, which now extends to Fargate tasks, giving you per-task threat detection that wasn’t available on Fargate until recently.

The trap with Fargate is assuming serverless means secure. The host is AWS’s problem now, but your image and your IAM are still yours.

3. Securing containers on Amazon ECS

ECS is the easiest control plane to reason about, because there’s nothing to secure in it. AWS fully manages the orchestration layer with no customer access, so your entire job sits at the workload level: task definitions, IAM roles, secrets, and images.

Two misconfigurations dominate on ECS. 

• Over-broad task roles, often made worse by using a single role for both the task role and the execution role, which hands a compromised container every permission both were meant to hold. 
• Secrets stored in plaintext environment variables inside task definitions, where they leak into CloudWatch logs, the console, and container inspect output.

The native controls map directly to those two problems:

• Split the task role from the execution role, keeping what your app can do separate from what ECS needs to pull images and write logs, and scope each to the minimum.
• Pull secrets from Secrets Manager at runtime instead of baking them into environment variables, so they never sit in plaintext.

Get IAM and secrets right, and ECS becomes the lowest-maintenance secure option of the four.

4. Securing containers on Amazon EKS

EKS sits at the opposite end from ECS. AWS runs and patches the Kubernetes control plane (the API server and etcd), but it hands you far more to configure: RBAC, network policies, pod-level identity, the worker nodes, and the workloads themselves.

The way you run these nodes, on EC2 or Fargate, also decides whether the host risks from those sections apply, which is the heart of choosing between managed and unmanaged Kubernetes.

The misconfigurations specific to EKS are a public API server endpoint (exposes the cluster’s front door to the internet), and over-permissive RBAC (gives workloads and users more cluster access than they need). A third, easy to overlook, is skipping pod-level identity, which leaves pods falling back on the node’s IAM role and reopens the IMDS credential-theft path from the EC2 section.

The native controls for EKS are:

• Use IRSA or EKS Pod Identity to give each pod its own scoped IAM role, so nothing relies on the node role.
• Make the API endpoint private (or tightly allowlist it) so the control plane isn’t reachable from the open internet.
• Turn on control plane audit logging to CloudWatch, so RBAC and API activity is recorded and reviewable.

With the most security surface to manage of any AWS container option, EKS is exactly where getting RBAC, identity, and endpoint exposure right matters most.

AWS-Native Security Services for Containers

AWS provides a full set of native tools to handle the responsibilities on your side of the line. Here’s the toolkit, grouped by the job each one does:

• Image and supply chain: Amazon ECR stores your images and adds registry-side controls like vulnerability scanning, immutable tags, and image signing, while Amazon Inspector continuously scans ECR images and running workloads for new CVEs as they’re disclosed.
• Identity and secrets: IAM handles task roles, IRSA, and EKS Pod Identity for per-workload permissions, Secrets Manager keeps credentials out of task definitions, and AWS KMS encrypts secrets, image layers, and volumes with keys you control.
• Threat detection: Amazon GuardDuty flags credential misuse, cryptomining, and anomalous runtime behavior, and GuardDuty Extended Threat Detection goes further by correlating signals across EKS, ECS, and EC2 into single multi-stage attack sequences, the exact kind of chained attack ECScape and the cryptomining campaign represented.
• Posture and audit: Security Hub aggregates findings into a single prioritized view, AWS Config tracks configuration drift relative to your baselines, and CloudTrail records every API call for a complete audit trail.

These services are strong primitives, and used well, they cover most of what the shared responsibility model puts on you. The catch is that each one operates per service and per account. None of them gives you a single control plane with consistent access control and visibility across every cluster, and the limitation grows as you run more than one cluster or operate across more than one cloud.

And because Portainer is vendor-agnostic, that single control plane extends beyond AWS (to other clouds, on-prem, and edge), so a multi-cloud strategy doesn’t mean stitching together a separate governance model for each provider. You get consistency without locking into any one vendor's ecosystem.

You’ve seen the threats and the native tools that address them. This list pulls them into one action-ordered sequence, moving from the image you build to the way you manage everything in production. Work down it in order, since the early items close the paths attackers reach for first.

• Scan every image, before and after deployment. Turn on ECR scanning and add Amazon Inspector for continuous CVE checks, so a clean image at build time doesn’t become a vulnerable one in production.
• Enforce least-privilege IAM with per-workload identity. Scope every task and pod to only the permissions it needs, and use IRSA or EKS Pod Identity so nothing falls back on the node role.
• Keep secrets out of task definitions and code. Pull them from Secrets Manager at runtime and encrypt them with KMS, so credentials never sit in plaintext environment variables or logs.
• Lock down the host on EC2-backed nodes. Enforce IMDSv2 with a hop limit of 1, run hardened AMIs, and patch nodes on a schedule to shut the credential-theft path.
• Close network exposure by default. Tighten security groups, keep cluster API endpoints private, and segment internal traffic so a single entry point doesn’t open the whole environment. 
• Turn on detection and audit across every account. Run GuardDuty with Extended Threat Detection and keep Config, CloudTrail, and control plane logging enabled so you can both detect and reconstruct an incident.
• Centralize control and visibility across your clusters. Applying any single control is pretty straightforward, but the real challenge is applying all of them consistently across every cluster and cloud. A management platform like Portainer gives you one place to enforce RBAC, monitor environments, and keep configuration consistent, so the practices above hold up at scale instead of drifting cluster by cluster.

{{article-cta}}

Ensure Container Security With Portainer

AWS gives you everything you need to secure a container workload: scanning, identity, detection, and audit. The difficulty is keeping it all consistent once you’re running several clusters, mixing EC2 and Fargate, or operating across multiple clouds, since native tooling stops at the account and service boundaries.

Portainer is a self-hosted container management platform that runs on top of your existing AWS setup and provides a single control plane across all environments, including EKS and other Kubernetes distributions, and Docker, so governance stays consistent regardless of how each workload is run.

You get centralized RBAC tied to your existing identity provider, policy enforcement through OPA Gatekeeper, and audit logs streamed straight to your SIEM. Rather than configuring access and policy cluster by cluster, you set your intent once and let it apply everywhere, which removes the inconsistency that attackers tend to find first.

None of this replaces your AWS-native controls. GuardDuty still detects threats, Inspector still scans images, and IAM still governs permissions. Portainer is the governance layer that keeps those controls applied consistently as your footprint grows, so good security survives scale instead of eroding under it.

Want to see how Portainer keeps your AWS container security consistent across every cluster? Book a demo with our team.

FAQs

1. ECS vs EKS vs Fargate: which is most secure?

Fargate is the most secure option, because each task runs in its own micro-VM with no shared host to compromise. ECS and EKS are orchestrators rather than alternatives to Fargate, and either can run on it. Between the two orchestrators, ECS has a smaller attack surface, while EKS offers more control and more to secure.

2. Who is responsible for container security in AWS?

You are, for the most part. AWS secures the infrastructure underneath your containers, and you secure everything running on top: images, IAM roles, secrets, runtime behavior, and network rules. How much falls to you depends on the runtime, with EC2 placing the most on your side and Fargate the least.

3. Does AWS scan container images automatically?

No. ECR vulnerability scanning and Amazon Inspector are both opt-in, so nothing scans your images until you enable them. An image pushed to ECR with scanning switched off moves to production unchecked, which is a common way vulnerabilities reach AWS container environments.

4. What is the most common AWS container security risk?

Misconfiguration, especially over-permissioned IAM. A task or pod with more permissions than it needs allows a compromised container to spread across your account, particularly when it can pull credentials from the instance metadata service. Most AWS container incidents trace back to a customer-side configuration choice rather than a flaw in AWS itself.

‍