Amazon Machine Image
An Amazon Machine Image (AMI) is a pre-configured template that contains the software configuration required to launch and boot an instance in Amazon Elastic Compute Cloud (Amazon EC2), including an operating system, application server, applications, and a template for the instance's root volume.[1] Introduced as a core component of Amazon EC2 upon its launch in 2006, an AMI enables users to deploy consistent virtual server environments in the AWS cloud with minimal setup effort.[2]
AMIs consist of two main elements: the software configuration, which includes the operating system and any pre-installed applications, and a block device mapping that specifies how block devices, such as Amazon Elastic Block Store (Amazon EBS) volumes or instance store volumes, are attached to the instance.[1] Key characteristics of an AMI include its regional availability, supported operating system, processor architecture (such as x86 or ARM), root device storage type (EBS or instance store), and virtualization type (hardware virtualization or paravirtualization), all of which must align with the target EC2 instance type for compatibility.[1] These attributes ensure that AMIs provide reliable, reproducible deployments tailored to specific workloads, from web servers to machine learning environments.
In practice, AMIs are used to launch one or more EC2 instances, allowing for scalable infrastructure provisioning without rebuilding configurations from scratch each time.[1] Users can select from AWS-provided AMIs, those available in the AWS Marketplace, community-shared options, or custom AMIs created from existing running instances via the EC2 console, AWS CLI, or SDKs.[1] Custom AMIs support features like copying across AWS Regions for global deployments, sharing with other AWS accounts for collaboration, and even selling through the AWS Marketplace to monetize specialized images.[1] This flexibility makes AMIs essential for DevOps practices, disaster recovery, and maintaining standardized environments across hybrid or multi-cloud setups.
Introduction
Definition and Purpose
An Amazon Machine Image (AMI) is a pre-configured template that provides the software configuration, including the operating system, application server, and applications, required to launch and boot an Amazon Elastic Compute Cloud (EC2) instance.[1] AMIs serve as the foundational starting point for all EC2 instances, encapsulating the entire software stack to ensure that instances can be provisioned with identical setups across different environments.[3]
The primary purpose of an AMI is to enable the rapid deployment of consistent and scalable virtual servers in the AWS cloud, allowing users to launch multiple instances from a single image without manual reconfiguration.[1] By acting as reusable snapshots of system states, AMIs support infrastructure as code (IaC) practices, facilitating the automation and versioning of development, testing, and production environments through tools like AWS CloudFormation and Terraform.[4]
Key benefits of AMIs include reduced setup time for new instances, as they eliminate the need to repeatedly install and configure software from scratch.[5] They ensure compliance by promoting standardized images that maintain uniform security patches and configurations across an organization.[6] Additionally, AMIs facilitate disaster recovery by providing full backups of instance configurations, enabling quick restoration through the launch of new instances in the event of failures.[7] Their portability across AWS regions further enhances reproducibility, allowing images to be copied and shared for global deployments.[1]
History
Amazon Machine Images (AMIs) were introduced alongside the public beta of Amazon Elastic Compute Cloud (EC2) on August 25, 2006, providing pre-configured boot disks stored as Amazon S3 objects to enable users to launch virtual servers with basic Linux distributions such as Fedora, Debian, and other supported open-source variants.[8] Initially, AMIs focused on instance store-backed storage, where the root device was ephemeral and tied to the instance's lifecycle, limiting persistence but offering simplicity for early cloud workloads.[5]
The evolution accelerated with the introduction of EBS-backed AMIs on December 3, 2009, allowing the root device to use persistent Amazon Elastic Block Store (EBS) volumes for faster launches, easier management, and the ability to stop and restart instances without data loss.[9] Support for Windows AMIs began in beta on October 23, 2008, with full production availability expanding in 2009 to include Microsoft Windows Server editions, broadening EC2's appeal for enterprise applications.[10] In July 2010, the launch of Cluster Compute instances marked a shift toward hardware virtual machine (HVM) virtualization, improving performance for high-performance computing by emulating full hardware environments more efficiently than the initial paravirtual (PV) approach.[11]
In September 2010, AWS introduced the Amazon Linux AMI as a stable, AWS-optimized Linux distribution for EC2, with major versions following in 2017 (Amazon Linux 2) and 2023 (Amazon Linux 2023).[12]
Key milestones included the April 2012 launch of AWS Marketplace, which enabled the distribution and monetization of commercial AMIs from third-party sellers, fostering an ecosystem for pre-packaged software.[13] Enhanced security features emerged in 2017 with the announcement of the AWS Nitro System at AWS re:Invent, integrating dedicated hardware for encryption, networking, and storage offloads to improve isolation and efficiency in AMI-based instances, with broader rollout through 2020 across instance families like C5 and M5.[14] As of 2025, AWS continues monthly releases of updated Amazon Linux AMIs incorporating the latest security patches and optimizations, ensuring ongoing compliance and stability for production environments.[15]
Components
Root Device
The root device serves as the primary block device volume in an Amazon Machine Image (AMI), functioning as a virtual hard drive that stores the operating system image and other essential boot files, which are mounted during the instance startup process.[16] This device is integral to initializing the Amazon EC2 instance, providing the foundational storage from which the system loads the kernel and root filesystem.[1]
AMIs support two main backing options for the root device: Amazon Elastic Block Store (EBS) for persistent storage or instance store for ephemeral, high-performance temporary storage.[5] EBS-backed root devices use modifiable volumes that retain data across instance stops and restarts, enabling features like snapshots for creating new AMIs from the current state.[16] In contrast, instance store-backed root devices offer faster I/O but are non-persistent, with all data deleted upon instance termination or hardware failure. Instance store-backed instances cannot be stopped. They are suitable only for temporary workloads on specific older instance types like C3, M3, or R3.[16] The root device is specified within the AMI's block device mapping, which defines its attachment point, such as /dev/xvda.[5]
EBS root devices typically initialize at a minimum size of 8 GiB, though volumes can be resized post-launch, and they are pre-formatted with appropriate filesystems such as ext4 for Linux distributions or NTFS for Windows.[17] Instance store root devices vary in size based on the instance type but follow the same ephemeral deletion rules.[16] For security, EBS-backed root devices support encryption at rest using AWS Key Management Service (KMS) keys, which protect data on the volume and any derived snapshots without requiring additional infrastructure.[18] This encryption applies to both the root volume and attached EBS volumes, ensuring compliance with data protection standards during boot and runtime.[19]
Block Device Mapping
A block device mapping in an Amazon Machine Image (AMI) is a configuration that defines the block devices—such as Elastic Block Store (EBS) volumes or instance store volumes—to be attached to an EC2 instance when launched from the AMI. This mapping specifies virtual device names and their associations with underlying storage resources, enabling consistent storage setups across instances derived from the AMI.[20] For example, the root device, typically mapped to /dev/sda1 on Linux instances, serves as the primary boot volume within this configuration.[21]
The mapping consists of key elements that detail each device's properties. The device name identifies the virtual interface exposed to the instance, such as /dev/sdb for additional data volumes on Linux or corresponding drive letters on Windows. For EBS volumes, the configuration includes the volume size in GiB (which must be at least as large as any associated snapshot), the volume type (e.g., gp3 for general-purpose SSD), a delete-on-termination flag (true by default for the root volume to automatically delete the volume upon instance termination, and false for others), and encryption status (enabled or disabled, with AWS-managed keys by default if enabled). Instance store volumes use virtual names like ephemeral0 instead of EBS properties. NoDevice can be specified to exclude a device from the mapping. These elements are structured in a JSON-like format within the AMI metadata.[22][23]
Functionally, block device mappings allow for the attachment of multiple volumes at instance launch, supporting flexible storage architectures such as separating the root volume from data volumes for better performance or scalability. EBS volumes can be initialized from snapshots included in the AMI, ensuring pre-configured data is available immediately upon boot. This enables scenarios like attaching additional EBS volumes for databases or caching, or instance store volumes for temporary high-I/O workloads, all predefined in the AMI to streamline deployments.[24]
Users can customize block device mappings during AMI creation by attaching volumes to the source instance and registering the AMI with the desired configuration, such as adding extra EBS volumes for persistent data or adjusting instance store mappings to optimize input/output operations. This process preserves EBS data via snapshots while allowing tailored storage profiles without altering the base AMI image.[20]
Limitations include a maximum of 27 volumes per instance for many Nitro-based instance types, though this varies by instance family and size; mappings must align with the capabilities of the target instance type to avoid attachment failures. NVMe-based instance store volumes are automatically enumerated and may ignore explicit mappings, and device names can differ from specified values due to the block device driver.[25][21]
Types
Backing Storage
Amazon Machine Images (AMIs) are categorized based on their backing storage, which determines the persistence, performance characteristics, and suitability for different workloads. The root device of an AMI specifies whether it uses instance store or Elastic Block Store (EBS) as the underlying storage mechanism.[5]
Instance store-backed AMIs, also known as S3-backed AMIs, utilize ephemeral instance store volumes that are physically attached to the host server and are supported only for Linux operating systems on previous-generation instance types such as C1, C3, M1, M2, M3, and R3. These volumes employ SSD or HDD storage and are ideal for temporary data such as caches, buffers, or scratch space in high-throughput applications. However, data on instance store volumes is lost upon instance stop, termination, or hardware failure, making them unsuitable for workloads requiring long-term persistence.[26][5]
In contrast, EBS-backed AMIs rely on persistent EBS volumes, which are block storage devices designed for durability and flexibility. These allow instances to be stopped and restarted without data loss on the root volume, and they support features like snapshots for versioning and backup. EBS volumes also enable encryption at rest and dynamic resizing, enhancing security and adaptability for production environments.[16][5][27]
The following table compares key aspects of instance store-backed and EBS-backed AMIs:
| Aspect | Instance Store-Backed AMIs | EBS-Backed AMIs |
|---|
| Persistence | Ephemeral; data lost on stop/termination | Persistent; survives stop/start, deleted on termination by default |
| Performance | Higher potential IOPS and throughput due to direct attachment, but varies by instance type | Consistent performance with configurable IOPS (up to 256,000 for io2 Block Express); network-attached |
| Durability | Low; no redundancy against hardware failure | High; 99.999% availability, supports multi-AZ redundancy |
| Snapshots | Not supported | Supported for backups and versioning |
| Encryption | Not natively supported | Supported at rest and in transit |
| Resizing | Not supported | Supported; volumes can be modified while detached |
| Suitability | Temporary workloads like caching or high-throughput temporary processing | General-purpose, persistent applications requiring reliability |
Virtualization
Amazon Machine Images (AMIs) in Amazon EC2 utilize two primary virtualization types: hardware virtual machine (HVM) and paravirtual (PV). HVM provides full virtualization by emulating a complete set of hardware, allowing the guest operating system to run directly on the virtual hardware without modifications, which enables support for any compatible OS and advanced features like GPU acceleration and nested virtualization.[5] In contrast, PV is a legacy paravirtualization approach where the guest OS is aware of the hypervisor, enabling optimized interactions that reduce overhead through modified drivers and kernels, though this limits compatibility to specific older configurations.[5]
HVM AMIs boot using the master boot record (MBR) of the root device by default but can be configured for UEFI boot mode to enable features such as Secure Boot and support for modern operating systems requiring EFI firmware.[5][30] PV AMIs, however, rely on a specialized PV-GRUB bootloader that chain-loads the kernel from a configuration file, and they are restricted to previous-generation instance types such as M1 and C1, with no support on current-generation families.[5][31] HVM requires hardware-assisted virtualization extensions provided by the underlying platform, while PV does not but necessitates guest OS adaptations for optimal operation.[5]
In terms of performance, HVM AMIs leverage Single Root I/O Virtualization (SR-IOV) to enable enhanced networking and storage acceleration, delivering higher bandwidth, increased packets per second, and reduced latency compared to traditional virtual interfaces, making them ideal for modern workloads involving accelerated computing.[32] When equipped with paravirtual drivers for networking and storage, HVM instances achieve performance that matches or surpasses PV setups, while PV historically offered lighter I/O overhead in legacy environments due to direct hypervisor communication.[5] PV support is limited to select previous-generation instance types and AWS Regions, with current-generation instances like C5 requiring HVM exclusively for compatibility and optimal resource utilization.[31]
The virtualization type for an AMI is selected during creation based on the target instance family and workload needs; for example, compute-optimized instances such as C5 mandate HVM to access hardware extensions and ensure broad OS compatibility.[5][31] This choice impacts instance launch compatibility, as PV AMIs cannot run on HVM-only instance types, guiding users toward HVM for future-proofing against evolving EC2 offerings.[5]
Creation and Management
Creating an AMI
Creating an Amazon Machine Image (AMI) involves capturing the configuration, software, and data of an Amazon EC2 instance or its associated EBS volumes to produce a reusable template for launching new instances. This process ensures consistency across deployments by bundling the instance's root volume and any attached block devices into snapshots, which form the basis of the new AMI. AMIs created this way are EBS-backed by default in modern usage, allowing for persistent storage and easier management compared to instance store-backed alternatives.[33]
To create an AMI from an existing EC2 instance, first launch an instance from a base AMI and customize it by installing and configuring software, attaching additional EBS volumes if needed, and applying necessary updates. Once customized, use the AWS Management Console, AWS CLI, or API to initiate the creation: in the Console, select the instance, choose "Image and templates" > "Create image," provide a name and description, and optionally select "No reboot" to avoid powering down the instance; via CLI, run the command aws ec2 create-image --instance-id i-1234567890abcdef0 --name "MyServerImage" --description "Custom AMI for [web server](/page/Web_server)". The process creates snapshots of the root volume and all attached EBS volumes, which can take several minutes to complete for small instances, though larger volumes may extend this to an hour or more.[33]
Before creating the AMI, prepare the instance to optimize performance, security, and reliability: remove sensitive data such as shell history (e.g., using shred -u ~/.*history), remove SSH host keys to ensure each launched instance generates unique host keys, avoiding verification issues (e.g., sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub), disable password-based root logins by editing /etc/ssh/sshd_config to set PermitRootLogin without-password, and lock the root account with [sudo](/page/Sudo) passwd -l [root](/page/Root). For automation, tools like HashiCorp Packer can script these steps, launching temporary instances, applying configurations via provisioners, and invoking the create-image API to generate the AMI reproducibly.[34][33]
Alternatively, create an AMI directly from an EBS snapshot, which is useful for versioning configurations without running a full instance: first create snapshots of the root and data volumes using the Console (Snapshots > Create snapshot) or CLI (aws ec2 create-snapshot --volume-id vol-049df61146c4d7901 --description "Root volume backup"), then register the AMI with aws ec2 register-image --name "VersionedAMI" --architecture x86_64 --root-device-name /dev/xvda --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"SnapshotId":"snap-0668776718e604fb7","VolumeSize":8}}]', specifying block device mappings for volumes (as detailed in the Components section). This method leverages existing snapshots for quicker iteration in development workflows.[33]
The resulting AMI is assigned a unique ID in the format ami-0abcdef1234567890 and is private by default, visible only in the AWS Region where it was created. Creation itself incurs no direct fees, but EBS snapshot storage costs apply at $0.05 per GB-month for standard storage, billed incrementally based on the data retained until snapshots are deleted.[1][35]
Copying and Sharing
Copying an Amazon Machine Image (AMI) enables users to replicate it within the same AWS Region or across Regions, resulting in a new AMI with a unique identifier independent of the source. This process supports consistent instance configurations for high availability, scalability, and global deployment. Copies can be performed using the AWS Management Console, AWS Command Line Interface (CLI), or API. For instance, the CLI command aws ec2 copy-image --source-ami-id ami-1234567890abcdef0 --source-region us-east-1 --region us-west-2 --name "MyCopiedAMI" --description "Copied for West Region" initiates a cross-region copy, optionally specifying encryption with a KMS key via the --encrypted and --kms-key-id parameters. Since November 21, 2024, AWS provides AMI lineage information to trace the source of copied or derived AMIs, accessible via the AWS Management Console, CLI, or SDKs, aiding in management and compliance.[36][37][38]
For EBS-backed AMIs, copying involves duplicating the underlying EBS snapshots, with initial cross-region copies being complete and subsequent ones incremental to optimize efficiency. Encryption status can be modified during the copy—for example, enabling encryption on an unencrypted source or changing the KMS key—but encrypted AMIs cannot be copied to an unencrypted state. Cross-account copying requires the source AMI to be shared with the target account, granting read access to the backing EBS snapshots; the resulting AMI is owned by the copying account and incurs storage costs for the copier, while data transfer fees apply to the source owner. Permissions for copying include the ec2:CopyImage IAM action, plus ec2:CreateTags for tagging the new AMI and snapshots, and additional S3 actions for instance store-backed (S3-backed) AMIs.[37][39]
Each copied AMI counts toward the default quota of 50,000 AMIs per Region, which can be increased via a service quota request. Resource-level permissions for CopyImage have been supported since October 28, 2024, allowing finer control over specific AMIs.[40][39]
Sharing an AMI grants other AWS users or accounts permission to launch instances from it without transferring ownership. Owners can share privately with specific 12-digit AWS account IDs or make the AMI public for broader access. Modifications occur via the AWS Management Console's Permissions tab for the selected AMI or the CLI command aws ec2 modify-image-attribute --image-id ami-1234567890abcdef0 --launch-permission '{"Add":[{"UserId":"123456789012"}]}', with permissions revocable at any time using similar commands to remove access. Private sharing enables direct account-to-account distribution outside the AWS Marketplace, where the owner adds the grantee account ID to allow launches but not modifications or deletions.[41][1]
Shared AMIs remain regional, requiring a copy to the target Region before sharing there. Security features ensure that shared AMIs inherit the encryption of their EBS volumes or S3 templates; for encrypted EBS-backed AMIs, owners must share the KMS key via resource-based policies to enable grantees to decrypt and launch. Fine-grained access is managed through IAM policies, with the ec2:DescribeImages action needed to view shared AMIs and ec2:RunInstances for launching. Launch permissions and tags from the source are not automatically copied, requiring manual application post-copy.[41][37][39]
Usage
Launching Instances
Launching an Amazon EC2 instance from an Amazon Machine Image (AMI) involves selecting the AMI and configuring various parameters to define the instance's environment and behavior. In the AWS Management Console, users begin by navigating to the EC2 dashboard, choosing "Launch instance," and selecting the desired AMI under the "Application and OS Images" section.[42] They then choose an instance type, such as t3.micro for general-purpose workloads, which determines the compute, memory, and networking resources allocated to the instance.[42] Network settings are configured next, including the Virtual Private Cloud (VPC), subnet, and security groups to control inbound and outbound traffic.[42] A key pair is selected or created for secure access via SSH or RDP, and optional user data scripts can be provided to automate initial configuration.[42] Finally, tags are added for resource organization, and the instance is launched after reviewing the summary.[42]
If the Allowed AMIs feature is enabled on the account (introduced December 2024), only AMIs from specified owners or aliases are visible and usable for launching, helping enforce governance and compliance policies.[43]
For command-line launches, the AWS CLI uses the run-instances command with the --image-id parameter specifying the AMI ID, such as ami-12345678abcdef0.[44] Essential parameters include --instance-type (e.g., t3.micro), --key-name for the key pair, --security-group-ids for network access, --subnet-id for placement, and --user-data for bootstrap scripts.[44] A basic example is:
aws ec2 run-instances --image-id ami-12345678abcdef0 --count 1 --instance-type t3.micro --key-name MyKeyPair --security-group-ids sg-903004f8 --subnet-id subnet-6e7f829e
aws ec2 run-instances --image-id ami-12345678abcdef0 --count 1 --instance-type t3.micro --key-name MyKeyPair --security-group-ids sg-903004f8 --subnet-id subnet-6e7f829e
This command launches one instance with the specified configuration.[44]
At launch time, several customizations can override or extend the AMI's defaults. Block device mappings from the AMI can be overridden in the console's advanced details or via the --block-device-mappings CLI parameter to adjust storage volumes, such as adding or resizing EBS volumes.[45] Tags can be applied using the --tag-specifications CLI option or the console's tagging section to add metadata like Name or Environment for management.[42] An Elastic IP address can be associated post-launch through the EC2 console or API to provide a static public IPv4 address. User data scripts enable bootstrapping; for Linux instances, these are typically shell scripts starting with #!/bin/bash, such as one to update packages and start a service (example for Amazon Linux 2023):
#!/bin/[bash](/page/Bash)
dnf update -y
systemctl start [httpd](/page/Httpd)
systemctl enable [httpd](/page/Httpd)
#!/bin/[bash](/page/Bash)
dnf update -y
systemctl start [httpd](/page/Httpd)
systemctl enable [httpd](/page/Httpd)
The script runs automatically during boot.[46]
The AMI must be compatible with the selected instance type's architecture and virtualization requirements to ensure successful launch. AMIs are built for specific processor architectures, such as x86_64 (Intel/AMD) or arm64 (AWS Graviton), so the instance type must match—for instance, an x86_64 AMI cannot launch on an ARM-based type like m6g.large.[31] Similarly, the AMI's virtualization type—Hardware Virtual Machine (HVM) for modern instances or Paravirtual (PV) for legacy support—must align with the instance type; current-generation types like C5 require HVM AMIs.[31]
For scaling multiple instances from the same AMI, Auto Scaling groups use launch templates or configurations that reference the AMI ID, instance type, and other settings to automatically adjust capacity based on demand or health checks.[47]
Post-launch, the instance boots from the AMI's root device volume, transitioning from a pending state to running as the operating system initializes.[3] Monitoring occurs via Amazon CloudWatch, which collects metrics like CPU utilization and network traffic in near real-time, with options for basic (5-minute intervals) or detailed (1-minute) monitoring.[48]
Finding and Selecting AMIs
Users can discover and select Amazon Machine Images (AMIs) through the AWS Management Console, command-line interface (CLI), or API, enabling targeted searches based on workload requirements such as operating system, architecture, and storage type.[49]
In the AWS Console, AMIs are accessible via the EC2 Launch Wizard or the dedicated Images page. The Launch Wizard offers Quick Start options for common operating systems and applications, while the full catalog under Application and OS Images allows browsing by name, ID, or description. Filters on the Images page refine results by ownership (public images, owned by Amazon, or shared), platform (e.g., Linux or Windows), architecture (e.g., x86_64 or arm64), root volume type (EBS or instance store), and tags for community-contributed AMIs.[49]
For programmatic access, the AWS CLI and API provide the describe-images command or equivalent DescribeImages API call to query available AMIs. Users specify the --owners parameter to limit results to specific providers, such as amazon for AWS-provided AMIs, aws-marketplace for Marketplace options, or self for private ones. Additional --filters narrow searches by attributes like architecture (Name=architecture,Values=x86_64), platform (Name=platform,Values=Linux/UNIX), virtualization type (Name=virtualization-type,Values=hvm), or root device type (Name=root-device-type,Values=ebs). For example, the command aws ec2 describe-images --owners amazon --filters "Name=[architecture](/page/Architecture),Values=x86_64" "Name=[platform](/page/Platform),Values=Linux/UNIX" retrieves Amazon-owned Linux AMIs compatible with x86_64 instances.[50][49]
When selecting an AMI, key criteria ensure compatibility and performance. First, verify regional availability, as AMIs are region-specific and must be copied across regions if needed. Next, match the architecture (e.g., 64-bit Intel/AMD or ARM) and virtualization type (HVM for modern instances or paravirtual for legacy) to the target instance type. Assess the root device size and type through the AMI's block device mapping, typically detailed in the description. Review launch permissions to confirm accessibility (public, explicit sharing, or account-owned) and examine the description for included software, supported operating systems (such as Amazon Linux or Ubuntu, as outlined in the Supported Operating Systems section), and any prerequisites.[49][5]
AWS Quick Starts provide pre-configured AMIs for popular operating systems and workloads, accessible directly in the Launch Wizard under the AWS-provided owner filter. Community AMIs can be discovered using tag-based filters, such as Name=tag:OS=[Ubuntu](/page/Ubuntu), to identify shared images from trusted sources.[49]
Best practices for selection emphasize security and optimization: prioritize recent AMIs to incorporate the latest patches and updates, verify compatibility with intended instance types (e.g., ensuring ARM architecture for Graviton processors), and test the AMI in a non-production environment to confirm workload performance.[49]
Supported Operating Systems
Amazon Linux
Amazon Linux is a Linux operating system developed by Amazon Web Services (AWS) and optimized for use on Amazon Elastic Compute Cloud (EC2) instances. It is provided at no additional charge and serves as a stable, secure foundation for cloud workloads, with versions tailored to incorporate the latest AWS integrations and performance enhancements. The distribution is derived from established Linux upstreams: Amazon Linux 2 (AL2), released in 2017, is based on CentOS and Red Hat Enterprise Linux (RHEL), while Amazon Linux 2023 (AL2023), released on March 15, 2023, draws from Fedora and CentOS Stream 9 as its upstream sources for a more modern package ecosystem.[51][52][53]
Key features of Amazon Linux include a tuned Linux kernel optimized for EC2 performance, including support for AWS Nitro System instances, which enable enhanced networking and storage capabilities through dedicated hardware offloads. Pre-installed tools such as the AWS Command Line Interface (CLI) and AWS SDKs facilitate seamless integration with AWS services, while package management is handled via YUM for AL2 and DNF for AL2023. Both versions offer an Extras repository—amazon-linux-extras for AL2 and equivalent modular repositories for AL2023—providing access to additional software packages like EPEL without requiring third-party sources. Security is prioritized with preconfigured SELinux policies in AL2023 and regular vulnerability patches, ensuring compliance for enterprise applications.[54][55][56][57]
Official Amazon Machine Images (AMIs) for Amazon Linux are available in all AWS regions, allowing users to launch instances directly from the EC2 console or AWS CLI, with options for minimal installations to reduce footprint. Updates are delivered through region-hosted repositories, including monthly security patches and bug fixes, which can be applied via automated tools like yum update or dnf update. AL2023 introduces a biannual major release cadence with frequent minor updates under user control, promoting deterministic environments for CI/CD pipelines.[58][59][60]
The lifecycle of Amazon Linux versions emphasizes long-term stability: Amazon Linux 1 reached end-of-life (EOL) on December 31, 2023, ceasing all security updates and bug fixes thereafter. AL2 provides long-term support (LTS) until June 30, 2026, after which no further updates will be issued. In contrast, AL2023 is supported until June 30, 2029, with standard support until June 30, 2027 and maintenance support thereafter, emphasizing containerized and microservices architectures.[61][55][62][63][53]
Amazon Linux is ideal for general-purpose workloads such as web servers, application hosting, and development environments, as well as microservices deployed via AWS Lambda or ECS, due to its native optimizations and reduced overhead compared to third-party distributions.[64][65]
Third-Party Distributions
Third-party distributions refer to Amazon Machine Images (AMIs) based on operating systems developed and maintained by vendors outside of AWS, such as Canonical, Red Hat, and Microsoft, which are optimized and certified for use on Amazon EC2 instances. These AMIs provide users with familiar ecosystems, enterprise-grade features, and broad software compatibility while leveraging AWS infrastructure. Unlike AWS-native options, third-party distributions emphasize vendor-specific tooling, long-term support cycles, and integration with existing on-premises environments.
For Linux distributions, popular choices include Ubuntu from Canonical, which offers official AMIs for versions like 24.04 LTS (Noble Numbat), available across AWS regions with minimal configurations for quick deployment. Red Hat Enterprise Linux (RHEL) is certified for AWS through partnerships, providing pre-tuned AMIs for versions 8 and 9 that integrate seamlessly with AWS services like EC2 and support enterprise workloads. CentOS Stream, as an upstream development platform for RHEL, delivers continuously updated AMIs, such as CentOS Stream 9, suitable for testing and development. Debian, maintained by the Debian Project, supplies official AMIs for stable releases like Debian 12 (Bookworm), emphasizing security and flexibility for cloud environments. These Linux options are certified for AWS compatibility via tools like AWS Launch Wizard, which validates them for specific workloads such as SAP deployments.
Windows distributions are provided directly by Microsoft through AWS, including server editions like Windows Server 2019, 2022, and 2025, as well as desktop variants such as Windows 10 and 11 for remote access scenarios. These AMIs include Microsoft licensing and are updated monthly to incorporate the latest security patches and optimizations for EC2 hardware.
Certification for third-party AMIs involves rigorous testing by AWS partners to ensure compatibility with EC2 instance types, networking, and storage; for instance, Ubuntu Pro extends this with up to 10 years of security maintenance tailored for AWS AMIs, covering expanded compliance standards like CIS benchmarks. AMI sources primarily come from official vendor repositories—for example, Canonical publishes specific AMI IDs for the latest Ubuntu 24.04 in each region via their EC2 locator tool—while users can create custom builds using cloud-init to automate instance initialization, package installation, and configuration without altering the base OS.
Support for these distributions relies on vendor-specific update mechanisms, such as Canonical's Landscape for Ubuntu fleet management or Red Hat's Satellite for RHEL patching, while AWS handles underlying hardware compatibility and provides troubleshooting assistance for integration issues. AWS does not perform OS-level maintenance, leaving that to the vendors to ensure timely security and feature updates.
As of 2025, trends in third-party distributions highlight expanding ARM64 support for AWS Graviton processors, with distributions like Ubuntu 24.04, RHEL 9, CentOS Stream 9, and Debian 12 offering native arm64 AMIs for cost-efficient, high-performance workloads.
Marketplace and Community
AWS Marketplace AMIs
AWS Marketplace serves as a digital catalog where independent software vendors (ISVs) can publish pre-configured Amazon Machine Images (AMIs) bundled with specialized software, such as databases and applications, enabling customers to quickly deploy ready-to-use solutions on Amazon EC2. Launched in April 2012, it functions as an online store integrated with AWS services, allowing sellers to monetize their offerings while providing buyers with seamless access to vetted software.[13][66]
Sellers publish AMIs by creating product listings in AWS Marketplace, where they define pricing models such as hourly usage-based fees, upfront payments, monthly subscriptions, or annual contracts, with AWS automatically integrating these charges into the customer's EC2 instance billing for a unified invoice. This process ensures that software costs are billed alongside infrastructure expenses without additional setup. For instance, sellers can offer AMIs for enterprise software like SAP NetWeaver, Oracle Database, and Splunk Enterprise, including options in the AWS Free Tier for trial usage.[67][68][69][70]
Customers subscribe to these AMIs directly through the AWS Management Console with a one-click process, launching EC2 instances that automatically apply the selected licensing model, including Bring Your Own License (BYOL) for existing software entitlements or AWS-managed licensing for metered usage. All AMIs undergo mandatory security scans by AWS to detect vulnerabilities, ensuring compliance with standards like PCI DSS and HIPAA where applicable, while sellers provide ongoing updates through new AMI versions to maintain security and feature enhancements. As of 2025, thousands of AMIs are available, supporting enterprise-scale procurement via integration with AWS Organizations, which enables centralized management of subscriptions across multiple accounts.[71][72][73][74]
Public and Shared AMIs
Public AMIs are Amazon Machine Images that are owned by AWS or contributed by the community and made discoverable to all AWS users across accounts. These include base operating system images provided directly by AWS, such as those for Amazon Linux, Ubuntu, and other distributions, which serve as starting points for instance launches without additional cost.[5] Amazon and the EC2 community maintain a large selection of such public AMIs to facilitate rapid deployment of standardized environments.[5]
In contrast, shared AMIs are privately distributed between specific AWS accounts and remain invisible to the broader public. They are typically created by organizations for internal use, enabling consistent deployments across teams or development environments within the same or related accounts.[75] Use of shared AMIs carries inherent risks, as AWS does not guarantee their security or integrity, emphasizing that recipients assume responsibility for validation.[75]
Community contributions play a key role in expanding public AMIs, with users able to publish their own by granting access to all AWS accounts through the EC2 console or API.[76] Platforms like AWS re:Post serve as forums where users exchange recommendations on reliable public AMIs from trusted contributors. AWS encourages tagging public AMIs with descriptive metadata to enhance discoverability during searches.[77]
However, public and community AMIs have been associated with significant security risks. In May 2024, security firm Mitiga identified a community AMI containing malicious code that ran an unidentified Monero cryptocurrency miner, highlighting vulnerabilities in unvetted images.[78] More recently, in February 2025, researchers disclosed the "whoAMI" attack, which exploits name confusion in public AMIs to achieve code execution on EC2 instances launched from seemingly legitimate images.[79] In response to such threats, AWS introduced the "Allowed AMIs" feature in December 2024, an account-wide setting that limits the discovery and use of AMIs to a predefined allowlist, helping mitigate these risks.[80]
When utilizing public or shared AMIs, best practices include scanning for vulnerabilities using tools like AWS Inspector and verifying the owner's reputation to mitigate risks such as embedded malware or unauthorized access credentials.[81] For Linux-based AMIs, it is essential to check for and remove any pre-installed SSH keys or passwords before launch to prevent unintended access.[81] Creators of shared AMIs should disable root password logins, regenerate host keys, and minimize installed packages to reduce the attack surface.[34]
As of 2025, AWS enforces compliance with its Acceptable Use Policy for all public AMIs, prohibiting content that facilitates illegal activities or violates terms of service. To curb potential abuse, AWS provides the block public access feature for AMIs, which is enabled by default for new accounts and prevents unauthorized public sharing unless explicitly disabled.[82] Users are advised to re-enable this setting after any necessary sharing to maintain security.[82]