Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Amazon Machine Image.
Nothing was collected or created yet.
Amazon Machine Image
View on Wikipediafrom Wikipedia
An Amazon Machine Image (AMI) is a special type of virtual appliance that is used to create a virtual machine within the Amazon Elastic Compute Cloud (EC2). It serves as the basic unit of deployment for services delivered using EC2.[1]
Overview
[edit]Like all virtual appliances, the main component of an AMI is a read-only filesystem image that includes an operating system (e.g., Linux, Unix, or Windows) and any additional software required to deliver a service or a portion of it.[2]
An AMI includes the following:
- A template for the root volume for the instance (for example, an operating system, an application server, and applications)
- Launch permissions that control which AWS accounts can use the AMI to launch instances
- A block device mapping that specifies the volumes to attach to the instance when it's launched
The AMI filesystem is compressed, encrypted, signed, split into a series of 10 MB chunks and uploaded into Amazon S3 for storage. An XML manifest file stores information about the AMI, including name, version, architecture, default kernel id, decryption key and digests for all of the filesystem chunks.
Current AMIs are available for hardware virtualized machines (HVM)[3] where the operating system is installed as it would be on real hardware. With the still available older paravirtualized virtual machines (PV),[4] an AMI did not include a kernel image, only a pointer to the default kernel id, which could be chosen from an approved list of safe kernels maintained by Amazon and its partners (e.g., Red Hat, Canonical, Microsoft). Users could choose kernels other than the default when booting an PVM AMI.[5]
Operating systems
[edit]When it launched in August 2006, the EC2 service offered Linux and later Sun Microsystems' OpenSolaris and Solaris Express Community Edition. In October 2008, EC2 added the Windows Server 2003 and Windows Server 2008 operating systems to the list of available operating systems.[6][7] As of December 2010, it has also been reported to run FreeBSD;[8] in March 2011, NetBSD AMIs became available.[9] In November 2012, Windows Server 2012 support was added.[10]
Amazon Linux AMI
[edit]Amazon has its own Linux distribution that is largely binary compatible with Red Hat Enterprise Linux.[11] This offering has been in production since September 2011, and in development since 2010.[12] The final release of the original Amazon Linux is version 2018.03[13] and uses version 4.14 of the Linux kernel. Amazon Linux 2 changed from System V init system to systemd boot.[14] It was announced in June 2018, and is updated on a regular basis.[15]
Amazon Linux 2023 was the next version, which launched alongside a new two-yearly release cadence. It comes with various kernel hardening features, and also enables kernel live patching.
Types of images
[edit]- Public: an AMI that can be used by anyone.
- Paid: a for-pay AMI that is registered with Amazon DevPay and can be used by anyone who subscribes for it. DevPay allows developers to mark-up Amazon's usage fees and optionally add monthly subscription fees.
- Shared: a private AMI that can only be used by Amazon EC2[16] users who are allowed access to it by the developer.
References
[edit]- ^ Amazon. "Amazon EC2 Functionality".
- ^ Amazon. "Creating an Image". Archived from the original on 2009-04-03. Retrieved 2009-03-27.
- ^ "Amazon EC2 Instance Types". Retrieved 21 March 2021.
- ^ "Linux AMI virtualization types". Retrieved 21 March 2021.
- ^ AWS Blog post announcing EC2 User Selectable Kernels
- ^ Shankland, Stephen (October 23, 2008). "Amazon's Linux cloud computing out of beta, joined by Windows". CNet News. Retrieved October 24, 2008.
- ^ "Amazon Elastic Compute Cloud (EC2) Running Microsoft Windows Server and SQL Server". Amazon.com. October 23, 2008. Archived from the original on 1 December 2008. Retrieved October 25, 2008.
- ^ FreeBSD on EC2 status. Daemonology.net. Retrieved on 2013-08-09.
- ^ NetBSD Blog. Blog.netbsd.org (2011-03-13). Retrieved on 2013-08-09.
- ^ "Windows Server 2012 Now Available on AWS". Amazon.com. November 19, 2012. Retrieved March 26, 2014.
- ^ "AWS Developer Forums". Amazon Linux AMI - what distro is this based on?. 16 September 2019. Archived from the original on 9 May 2012. Retrieved 9 August 2019.
- ^ Brockmeier, Joe (September 27, 2011). "Amazon's Linux AMI is All Grown Up". readwriteweb. Retrieved October 11, 2011.
- ^ "Amazon Linux AMI 2018.03 Release Notes". Amazon Web Services. Retrieved July 17, 2018.
- ^ "Amazon Linux 2 FAQs". Retrieved 21 March 2021.
- ^ "Announcing Amazon Linux 2 with Long Term Support". Amazon Web Services. 26 June 2018. Retrieved 10 February 2020.
- ^ "Amazon EC2 – web service that provides compute capacity in the cloud". 5 January 2022.
External links
[edit]- Creating and preparing AMIs
- Amazon Web Services Developer Community : Amazon Machine Images (AMIs)
- Amazon Linux AMI
Amazon Machine Image
View on Grokipediafrom Grokipedia
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.
Instance store-backed AMIs generally provide superior I/O performance for short-lived tasks but lack the durability and advanced management features of EBS-backed options.[26][28][5]
It is possible to migrate from an instance store-backed AMI to an EBS-backed AMI by launching an instance from the original AMI, copying its contents to a new EBS volume, creating a snapshot of that volume, and registering a new AMI from the snapshot. This process, while manual, allows users to transition to more persistent storage without rebuilding from scratch.[29]
As of 2025, EBS-backed AMIs dominate due to their persistence and compatibility with modern instance types, while instance store-backed AMIs are considered end of life and primarily used for legacy or specialized high-performance caching scenarios. AWS recommends EBS-backed AMIs for all new deployments to ensure faster launch times (under 1 minute) and broader support.[5][16]
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
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]
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] When launching an EC2 instance from an AMI with an encrypted root device snapshot, the encryption status is preserved, and the option to disable encryption is greyed out in the console by design for security reasons. Encryption can be enabled from an unencrypted AMI, but it cannot be disabled from an encrypted one.[18]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 commandaws 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 commandaws 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. The process copies the AMI and its associated EBS snapshots, but launch permissions, tags (unless explicitly specified during the copy), and certain settings are not automatically copied and must be reapplied as needed in the destination Region. 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. If the source AMI uses a custom KMS key, a different key must be specified for the destination Region, as KMS keys are Region-specific. Only user-defined tags from the owner's account can be copied; system tags and tags from other accounts are not included. 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 on the source AMI, plus ec2:CreateTags for tagging the new AMI and snapshots, and additional S3 actions for instance store-backed (S3-backed) AMIs. Costs include standard EBS snapshot storage and cross-Region data transfer charges, with no additional charge for the copy itself unless using time-based copying with a deadline. Limitations include that AMIs created on AWS Outposts cannot always be copied cross-Region, and cross-account copies require sharing the AMI first.[37][39][36]
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 therun-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
--block-device-mappings CLI parameter to adjust storage volumes, such as adding or resizing EBS volumes.[45] When launching from an AMI with an encrypted root snapshot, the encryption option for the root volume is greyed out in the console and cannot be disabled; this is by design for security reasons.[18] Encryption can be enabled when launching from an unencrypted AMI, but not disabled from an encrypted one.[18] For additional volumes, encryption can be configured independently via block device mappings.[18] 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
dnf update -y
systemctl start [httpd](/page/Httpd)
systemctl enable [httpd](/page/Httpd)
#!/bin/bash
dnf update -y
systemctl start [httpd](/page/Httpd)
systemctl enable [httpd](/page/Httpd)
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 thedescribe-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,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]