Amazon Machine Images (AMIs) are templates for launching and scaling Amazon Elastic Compute Cloud (EC2) instances. Because Amazon EC2 AMIs are reused across environments and automation pipelines, decisions about how you build, source, manage, and share them directly affect your cloud attack surface.
You can source AMIs for your EC2 instances in three ways: create and privately share base images (golden images) within your accounts, use public images from a trusted publisher, or use community images from another AWS account. Each option reflects a different trust boundary and introduces distinct risks. In 2025, Datadog’s security researchers identified a scenario where retrieving the newest and potentially unvetted AMIs from a public repository can increase an environment’s exposure to certain types of supply chain attacks.
This post looks at how image sourcing and life cycle management can impact your cloud attack surface, along with best practices to mitigate that risk in the following areas:
Many teams maintain golden images so they can standardize the process for configuring and provisioning instances. However, the trade-off is that decisions around how you manage an image’s patch levels, installed packages, security guardrails, and other configurations need to be replicated with every launched instance. In addition, golden images are often built on top of public or community AMIs, which means any associated risks become embedded in the internal image. For example, if one of these AMIs includes a remotely exploitable weakness, such as a network-accessible service running with weak or default credentials, every instance launched from it inherits the same initial access path.
You can mitigate this risk in how you build and update images. For images you build from scratch, the Center for Internet Security (CIS) benchmarks can help you standardize secure defaults. If you create images from other AMIs, treat the base image and any dependencies as part of your supply chain. Your base image checks should include retrieving them from trusted sources and scanning them routinely to catch vulnerable packages before distribution.
For handling updates, you have two options: apply patches at instance boot time, or regularly rebuild and publish new AMIs. Applying patches at boot time enables you to keep a stable golden image while ensuring every instance applies security updates during initialization. Rebuilding AMIs regularly gives you the ability to automatically apply any necessary updates and speed up initial boot times.
Maintaining an AMI inventory across your accounts and regions helps you apply these recommendations reliably. You can start by answering the following questions:
The answers provide adequate context for AMI usage, which enables you to map the relationships between images and other assets, such as instances, attached storage, and owning accounts. With the ability to visualize these connections, you can evaluate the impact to your environment when you discover a vulnerable AMI and confirm when it is decommissioned. Approaches like this help reduce version drift and misconfigurations in your internal AMI distribution pipeline.
There are valid use cases for sharing AMIs publicly, but this practice can create a data exposure risk. Public AMIs sometimes include embedded secrets and hardcoded credentials that publishers failed to remove before sharing. In other cases, an image is published unintentionally, possibly due to a misclick in the AWS console or a misconfigured deployment script.
If you publicly share AMIs, you can apply the same security practices that you would to any other distributed artifact. AWS recommends the following controls for public AMIs:
/etc/ssh folder.Prioritizing secret management with steps like these helps reduce the chance of publishing AMIs with exploitable secrets and data.
Beyond data exposure and misconfigurations, attackers can exploit the trust and familiarity associated with public Amazon EC2 AMIs. In one straightforward example, an attacker published a community image with an embedded crypto miner. When deployed, the image could consume compute resources and increase AWS costs without the user’s knowledge.
Malicious AMIs can also be a part of supply chain attacks that specifically target workflows sourcing public images. For example, Datadog researchers identified a name confusion technique in which an attacker publishes a public AMI with a name designed to match common AMI search patterns. If users or automation tools search for images by a particular name or pattern without also including the publisher or enforcing an allowlist, they could accidentally retrieve the malicious image instead of the intended one.
If your pipeline unknowingly pulls and reuses a compromised image, it expands the attack surface in ways that you may not immediately discover. Enforcing controls such as Allowed AMIs enables you to restrict and audit AMI usage in these cases. You can also apply the following best practices when sourcing public images to further reduce the risk of retrieving malicious ones:
Having guardrails around public AMIs enables you to identify the affected instances, replace them with a known-good version, and investigate your environment for further compromise.
Name confusion attacks and other untrusted or misconfigured AMI scenarios spread through typical day-to-day workflows, so the goal is to turn AMI alerts into a prioritized remediation list. You can use Datadog’s whoAMI-scanner to scan your environment for unverified community AMIs and quickly see which ones to address first.
Datadog Cloud SIEM will automatically flag any publicly shared AMIs, in addition to any EC2 instances created via risky AMI discovery patterns. Since these risks can escalate rapidly, Cloud SIEM signals enable you to efficiently determine their scope of impact for your environment, such as which user launched the vulnerable instance and what other resources they have access to.
With this visibility, you can then group instances that use those AMIs alongside other high-risk resources, such as EC2 instances with overly permissive IAM roles. Datadog Security Graph visualizes AMI relationships and downstream resource impact so you can easily review and respond accordingly.
For example, if images are routinely made public, or you can’t reliably justify why they are shared, it’s a strong indicator you should enforce a control such as blocking public sharing at the account level. The account-level block prevents you from sharing newly created AMIs (unless they are already public).
Amazon EC2 AMIs enable you to quickly launch instances with repeatable configurations for services, but that convenience creates risk for your environment. By focusing on how you manage private AMIs, prevent data leakage in shared images, and enforce guardrails for sourcing public AMIs, you can reduce both traditional misconfiguration risk and exposure from supply chain attacks.
For a technical deep dive on how public AMI name confusion works, read our research on the whoAMI attack. You can also review our documentation for more information about how Datadog helps you inventory your Amazon EC2 instances.
If you’re new to Datadog, sign up for a free 14-day trial.
We’d like to thank Seth Art of the Datadog Security Research team for his invaluable assistance with research and feedback on this article.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。