Ref: https://learn.cantrill.io/courses/1820301/lectures/41301334

• Summary
• Contents:

Amazon Machine Image (AMI) - Key Concepts

• 🔧 Image from which one can create (launch) an EC2 instance of a certain configuration
  • Logical container that includes:
    1. AMI ID
    2. Permissions
    3. Volume snapshots = snapshots of volumes attached to instance at the time that the AMI was created
       • 1 Boot volume (contains OS + application software)
       • 0+ Data volumes (contain data)
       • Referenced with Block Device Mapping
• An EC2 instance launched from an AMI is effectively a clone of the EC2 instance at the time of the AMI creation
  • Its SW configuration and data will be identical to the original instance
• Types
  1. AWS-provided
     • e.g. Amazon Linux 2
  2. Community-provided
     • e.g. RedHat, CentOS, Ubuntu…
  3. Marketplace AMIs
     • Can include commercial SW
     • Billed for normal instance hourly rate PLUS extra amount for running the commercial SW (extra cost includes licenses for the SW)
  4. Custom
     • Created by customers
• Regional
  • AMIs have regionally unique IDs (e.g. ami-0a887e401f7654935)
  • ❗ Can only be used in the region it’s in
    • The AMI can launch instances in any AZs of its region
  • Can be copied between regions
    • Including volume snapshots
    • Copies are different AMIs from original AMI
    • Identical AMIs (e.g. same distro of same OS) can be available in different regions, but they are different AMIs with different IDs
• Types of Permissions
  1. Owner account (only owner can use it)
     • default → AMIs are private by default
  2. Specific accounts
     • owner chooses which other accounts can use it
  3. Public
     • everyone can use it and launch instances from it
     • ❗ careful when making AMIs public! (e.g. don’t leave sensitive info in a public AMI!)
• ❗ AMIs do not contain volumes, only references to volume snapshots
  • EBS volumes are presented to instances via Device IDs
    • Boot volume → e.g. /dev/xvda
    • Data volume → e.g. /dev/xvdf
  • Block Device Mapping = data table with Device ID ↔ Snapshot ID pairs
  • ‼️ AMI billing includes EBS snapshots storage in S3!
    • Only for used data in original volume, not whole allocated data in original volume

AMI Creation (AMI Baking)

• An existing EC2 instance can be used as a template to create a new AMI
  • Capture current instance configuration (installed SW, attached volumes…)
• AMI baking = configuring an application in an EC2 instance, then creating an AMI when done
  • Useful for creating AMIs that meet the bespoke requirements of a business
  • E.g. manually install WordPress on an instance, then create an AMI
    • From that AMI we can then create many instances with WordPress already installed → no need to install WordPress hundreds of times
• ❗ AMIs can’t be edited
  • Possible to launch instance, update configuration and create a new AMI… But that’s a completely new AMI than the one used originally to launch the instance!

AMI Lifecycle (4 phases)

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/0900-ELASTIC_COMPUTE_CLOUD(EC2)/00_LEARNINGAIDS/AMILifecycle.png

1. Launch
   • Use an existing AMI to launch an instance (many demos in the course have done this)
   • 💡 Many customers only experience this phase, without ever baking an AMI (done in the next phases)