projects::arch linux on ec2

summary

Arch Linux's minimalistic philosophy and high degree of customizability makes it a great choice for compute cloud deployment. It's light, fast, and scalable.

I am doing releases of Amazon EC2 AMIs based on Arch Linux roughly once per month.

contact

IRC Join us on irc.freenode.net in #archlinux-ec2!

If you find a bug or have any other comments, please send me an email, or ping me on twitter.

NOTE: This project is not run, sponsored, or endorsed by my employer or the Arch Linux project.

current releases

Release 2020.01.10

HVM Images

region ebs
hvm
x86_64
lts
s3
hvm
x86_64
lts
ebs
hvm
x86_64
stable
s3
hvm
x86_64
stable
us-east-1 ami-074508ad6e83609f9 ami-0f34782ab2408b61c ami-0f040c7d22aedeb27 ami-0e98f8201cc910717
us-east-2 ami-03686844a29315289 ami-0f33ada231d5dfe73 ami-0470431e11a734fd9 ami-07bfb26f878fae36d
us-west-1 ami-04f2af740cd31a8ef ami-0e1340bce7ece531c ami-05cdd0c340f2889fe ami-07a6f0b8e53fd9c91
us-west-2 ami-0ba4fbfda310fd678 ami-0bb10fc50a2c8b045 ami-0b6363764d2a80871 ami-0bb3e74dd3df22fa3
ca-central-1 ami-03ae2c6a048d9c734 ami-09f0b68d067e29121 ami-01b3269d70a1de16c ami-04b6b1e7cff459bd3
eu-central-1 ami-021812d822fed534e ami-0079fde80963082d3 ami-06e882db7f01fad97 ami-096e9c9ebf01003de
eu-north-1 ami-0a91b34d60c5cef7a ami-073c665eefec120ee ami-02ae88ed88290671a ami-0c6d126d9f8244277
eu-west-1 ami-0cd2fc4d4265f18b5 ami-0d0e0d84508f06000 ami-08613bbdd5117c26e ami-0c6bf3c706ca17081
eu-west-2 ami-047e5bdb4f71b7f50 ami-00ce29324970a7866 ami-020f8e712266ac616 ami-02c663027d980e744
eu-west-3 ami-04d7b3dc21546e4a8 ami-0b40309e27c6d3548 ami-01360f4ce2b7cc8df ami-0e83cebe5fa910c37
ap-east-1 ami-77bdf806 ami-17b3f666
ap-northeast-1 ami-0b8781080fceeb540 ami-054f2ccc7a15a64d1 ami-0830b6d0901519dfb ami-00d771086f02c1e68
ap-northeast-2 ami-0cf3e223125080166 ami-05c8a53f0c9668ab3 ami-0e479608b3609ee19 ami-0f0746460c9a56f22
ap-south-1 ami-0a9f8ece1dc8bed0f ami-0233b5515088771ac ami-0280b0286f256a533 ami-0c813537929d1f47c
ap-southeast-1 ami-091c36501f962ff36 ami-0229f960d9b57a12e ami-0ebc029a114aa199e ami-08c906a938abfd72c
ap-southeast-2 ami-01cc52083d9e03d3d ami-045df80ea1f5f1de7 ami-01fdf683a88ff498e ami-0b8e744f59dc00882
sa-east-1 ami-0a82737dab4d22871 ami-079e5ad68456a7478 ami-07183794882825eb4 ami-0772567728167ed1e
me-south-1 ami-0022ea454ce2e843f ami-054bbb7ef03ab6c36

Release 2019.12.11

HVM Images

region ebs
hvm
x86_64
lts
s3
hvm
x86_64
lts
ebs
hvm
x86_64
stable
s3
hvm
x86_64
stable
us-east-1 ami-0559abadec0e273a4 ami-03b6d5c57b2c8d037 ami-040224f9ea7de28e2 ami-0e1ea91d49e2e029e
us-east-2 ami-0ecda53f8f734831b ami-00477ff9b22d18188 ami-08f99d6ac2779211e ami-0f6f0e0bf361433a8
us-west-1 ami-03ef95a719af21ad2 ami-0badf8bb659cbc95e ami-01902233f5796cee4 ami-0d4b3db2f8ddb6c22
us-west-2 ami-04757fbf0bc222bd9 ami-06fa15086b459c414 ami-07f76ba8d079634a4 ami-0535bac1081f5015e
ca-central-1 ami-021a2b5e7502535b8 ami-0ed3b37e6bef29b15 ami-03be215c2b88dec28 ami-0cf6da0ba2e7271e3
eu-central-1 ami-0bef9f2a2ae1cd7ec ami-0742ce8a000eaaf49 ami-0222a7fb791f5eac0 ami-0c4d286e70a532817
eu-north-1 ami-0465884356ffd2ece ami-0f93e3d59626a5d2c ami-087aaf07c637efb7e ami-029bc7793c5b1381f
eu-west-1 ami-0873631df977fc658 ami-0c332207a58014f76 ami-0c55040d93ff38996 ami-0e5fc7258cfdb066b
eu-west-2 ami-00c0c6cf0744fdb8f ami-02240233d90450c8f ami-097140142a2296277 ami-0a974464c1bbe96d6
eu-west-3 ami-092bb964c46f7ec9d ami-093a4441b93c3a1cd ami-0c830b29d903a368f ami-013b919fb522f20ff
ap-east-1 ami-831154f2 ami-a01055d1
ap-northeast-1 ami-0965bab0920e0436c ami-01c79fbbb44124eac ami-02ff85f384440c409 ami-0ba9aaf2261aebc23
ap-northeast-2 ami-0278d9f91fa66aecf ami-09999fe39b44510da ami-06b290f99c5517425 ami-051eb40704ad1e5f8
ap-south-1 ami-091f7136373d28c3f ami-04f88553017370fd4 ami-0acfdb0ae0c710a6f ami-0d448177db24b769e
ap-southeast-1 ami-0cc4cbcdcdd52e4c5 ami-0c938b8c977be4486 ami-07b3b236e568ff7ea ami-0e4553650cea7364b
ap-southeast-2 ami-0f4eda53aec2dcc78 ami-0232d6b158c8d6291 ami-0558bbff5eb5b2a49 ami-0c0de3992e8cdcde9
sa-east-1 ami-029497492797fca09 ami-0d5c752244ee41514 ami-0ab81731ba731bb9f ami-04d19a1284f43994d
me-south-1 ami-07dff59fe64c03765 ami-0b84711168b68e7c1

tools

The EC2 image build process is public, but the AMI registration portion is not. Here are the necessary tools to create an image file, but see the 2013-05-26 news post for information on how to register the images in EC2.

  • ami-build-backend - These files are held on the PXE server, and fetched when the guest boots.
  • ami-builder-image - This is a fork of archiso with some changes to automatically pull down my install script and do a few other things.
  • ec2-packages - These are the sources for all the packages contained in the 'ec2' Pacman repository.

recent changes and news

  • 2017-01-13

    I've added images for eu-west-2, ca-central-1, and us-east-2 as of today's release!

  • 2016-10-06

    The paravirtual images aren't booting properly in some regions, apparently because PV-GRUB is failing to load /boot/grub/menu.lst.

    Since PV is deprecated by AWS anyway, I'm going to stop making paravirtual AMIs from now on.

  • 2016-01-03

    Whoops. I didn't notice my GPG key was going to expire on January 2nd. My bad. I've updated the keypair and submitted it to pgp.mit.edu as well as created a new ec2-keyring package. Unfortunately to install the new keyring package you need to manually unbreak your Pacman keyring by fetching the updated key directly from the keyserver:

    # pacman-key -r A7B30DB9
    gpg: requesting key A7B30DB9 from hkp server pool.sks-keyservers.net
    gpg: key A7B30DB9: "Steven Noonan <steven@uplinklabs.net>" 5 new user IDs
    gpg: key A7B30DB9: "Steven Noonan <steven@uplinklabs.net>" 42 new signatures
    gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
    gpg: depth: 0  valid:   1  signed:   7  trust: 0-, 0q, 0n, 0m, 0f, 1u
    gpg: depth: 1  valid:   7  signed:  66  trust: 1-, 0q, 0n, 6m, 0f, 0u
    gpg: depth: 2  valid:  66  signed:   6  trust: 66-, 0q, 0n, 0m, 0f, 0u
    gpg: next trustdb check due at 2016-01-22
    gpg: Total number processed: 1
    gpg:           new user IDs: 5
    gpg:         new signatures: 42
    ==> Updating trust database...
    gpg: next trustdb check due at 2016-01-22

    Once you do the above, you should be able to "pacman -Syu" as normal.

  • 2015-07-30

    The Arch Linux AMIs have been moved to a different AWS account. This unfortunately means that all the S3 buckets had to be recreated, and when that happened the old S3 endpoints stopped working correctly. Since pacman doesn't know how to handle HTTP 301 redirects, you're going to have to manually update any existing Arch Linux instances you have. To do this, need to change your /etc/pacman.conf repo path from this:

    [ec2]
    SigLevel = PackageRequired
    Server = https://s3.amazonaws.com/arch-linux-ami/repo/$arch

    to this:

    [ec2]
    SigLevel = PackageRequired
    Server = https://arch-linux-ami.s3.amazonaws.com/repo/$arch

    Be sure to force an update of the package databases once you're done:

    # pacman -Syy

    I've also stopped producing AMIs for the Beijing, China (cn-north-1) region for the moment. If someone has an account in that region and wishes to produce the AMIs for me there, please get ahold of me and we'll work on making it happen.

  • 2014-07-26

    I've added AMIs for the Beijing, China (cn-north-1) region.

  • 2014-06-27

    We're now up to Linux 3.15.2. I've removed xen-fbfront from the initramfs, because the module was causing 30-second boot delays:

    [    2.050081] tsc: Refined TSC clocksource calibration: 2793.267 MHz
    [    6.370066] xenbus_probe_frontend: Waiting for devices to initialise: 25s...20s...
    [   12.390306] random: nonblocking pool is initialized
    [   16.370070] 15s...10s...5s...0s...
    [   31.371241] xenbus_probe_frontend: Timeout connecting to device: device/vfb/0 (local state 3, remote state 1)
    

    The module is not required for an instance to boot correctly, so it can be removed from the initramfs. If you are running an AMI older than the 2014.06.27 release and would like to improve your instance's boot time, you can prune the module yourself:

    [root@ip-10-0-155-25 ~]# grep fbfront /etc/mkinitcpio.conf 
    MODULES="button ipmi-msghandler ipmi-poweroff virtio virtio-blk virtio-net virtio-pci virtio-ring
    xen-blkfront xen-fbfront xen-netfront xen-pcifront xen-privcmd hv_storvsc hv_balloon
    hv_vmbus hv_utils hv_netvsc ixgbevf"
    [root@ip-10-0-155-25 ~]# sed -ri 's/xen-fbfront //g' /etc/mkinitcpio.conf 
    [root@ip-10-0-155-25 ~]# mkinitcpio -p linux-ec2
    ==> Building image from preset: /etc/mkinitcpio.d/linux-ec2.preset: 'default'
      -> -k /boot/vmlinuz-linux-ec2 -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-ec2.img -S autodetect
    ==> Starting build: 3.15.2-1-ec2
      -> Running build hook: [base]
      -> Running build hook: [udev]
      -> Running build hook: [modconf]
      -> Running build hook: [block]
      -> Running build hook: [filesystems]
      -> Running build hook: [growfs]
      -> Running build hook: [keyboard]
      -> Running build hook: [fsck]
    ==> Generating module dependencies
    ==> Creating gzip initcpio image: /boot/initramfs-linux-ec2.img
    ==> Image generation successful
    [root@ip-10-0-155-25 ~]#
    

    After removing xen-fbfront from mkinitcpio.conf's MODULES section, subsequent reboots will be 30 seconds shorter. Before:

    [root@ip-10-0-155-25 ~]# systemd-analyze
    Startup finished in 32.530s (kernel) + 3.997s (userspace) = 36.528s

    After:

    [root@ip-10-0-155-25 ~]# systemd-analyze
    Startup finished in 2.345s (kernel) + 2.092s (userspace) = 4.438s
  • 2014-06-19

    The AMI now uses systemd's networkd, timesyncd, and resolved services. This makes the AMI have a significantly smaller footprint. Right now our biggest non-core packages are CUDA (in the GPU AMI) and cloud-init, which has a large dependency chain. I'd like to slim things even further, but I'll need to investigate how to do so.

  • 2014-03-24

    We're up to Linux 3.13.7 for the ec2 kernel and 3.10.34 for the ec2-lts kernel. I didn't make a news post earlier, but kernels are now built with 'debug' and 'strip' options, which will create split-out debug information packages (i.e. linux-ec2-debug, linux-ec2-lts-debug). This is useful for tools like perf, oprofile, and systemtap. Note that the -debug packages are compressed with 'lrzip'. New AMI builds have lrzip preinstalled, but if you're running an instance based on one of the older AMIs, you will need to install lrzip before you can make use of the -debug packages.

  • 2013-11-28

    New AMIs are being built right now and contain a couple changes:

    • EBS root volumes are now automatically resized to fill the block device. You can take advantage of this feature by launching an instance with a root volume size larger than the snapshot.
    • The resolv.conf file permissions are now 0644, allowing non-root users to resolve hostnames.

  • 2013-11-26

    Geoff H. and David B. both reported an issue with the current AMI release. The /etc/resolv.conf permissions are set to 0600 rather than 0644, which means that non-root users cannot resolve hostnames to IP addresses. This is an unintentional regression, most likely caused by a default 'umask' change in some package. dhclient will create a new resolv.conf and copy it over any existing file, which preserves the target file's permissions. But if no such file exists, then the permissions of the source file are copied. Previously, this worked fine because the file was generated with 0644 permissions, but now it's being generated with 0600. I've implemented a fix for future AMI builds. In the meantime, if non-root users need to perform DNS requests in your instances, be sure to do 'chmod 0644 /etc/resolv.conf'.

  • 2013-11-06

    A new ec2-pacman-mirrors package is available, and will provide your instances with optimal Arch Linux mirrors for your EC2 region. The upgrade path is as follows:

    1. Edit /etc/pacman.conf, change 'ec2' mirror URL to https://s3.amazonaws.com/arch-linux-ami/repo/$arch
    2. Run 'pacman -Sy ec2-pacman-mirrors'

    New AMIs will be published very shortly which use the new mirror list and point to the new EC2 package repository.

  • 2013-05-26

    I've added some links to this page, which are the complete set of files needed to do an EC2 image build. This does not include the AMI registration process, however. The tools Amazon provides for HVM AMI registration are still under NDA at the moment, and the bits necessary to do that are included in my AMI registration tools. So I can't make those public right now. The process itself can be replicated relatively easily, though:

    1. Build your VM image using the build-backend and builder-image repos above. PXE is what I use, but you could just as easily make it into an ISO or something. If you intend to do an S3-backed AMI, you will need to make the image no larger than 10GB (I use 8GB).
    2. Trim the image down (I do a 'mount -o loop,discard' on the image, then 'fstrim' the mount point, making the image into a sparse file).
    3. Tarball the image (tar cSzf, S to preserve the sparseness).
    4. Upload the tarball to S3.
    5. In each region, launch an instance and attach an empty 8GB EBS volume to them.
    6. On each of those instances, download the tarball and extract with 'tar xSf'.
    7. Use 'ddpt', an enhanced dd which pays attention to the sparseness of the image, to copy the raw image file into the EBS device. I use "ddpt if=<imagefile> of=/dev/xvdf bs=512 conv=sparse oflag=sparse,fsync". The sparseness aspect is important, because otherwise you're copying empty blocks onto the EBS device, which makes the snapshot take much longer, and is really just a waste of time. EBS volumes already read-as-zero, so there's no sense copying zero blocks.
    8. Detach the EBS volume and terminate the instances.
    9. Snapshot the EBS volume.
    10. Delete the volume (not needed now).
    11. Use ec2-register to create an AMI from the snapshotted volume.

  • 2013-03-22

    I've started creating AMIs which have CUDA preinstalled. These are for the cg1.4xlarge instance type.

  • 2013-02-05

    Nothing too exciting lately. Today's release has Linux 3.7.6.

  • 2012-11-22

    New AMI releases, now with cloud-init. Thanks to Jeremy D for contributing his time and effort to making cloud-init work well on Arch Linux.

  • 2012-11-12

    Released new AMIs, primarily for the new AWS region in Sydney, Australia (ap-southeast-2).

  • 2012-11-08

    Today's AMIs are released. Nothing too fancy in this build: just updated packages, including linux-ec2 3.6.6-1.

  • 2012-10-21

    I've added a new linux-ec2 package which contains a patched v3.6.2 kernel. There are a few major differences between this kernel and the Arch Linux stock kernel:

    • Hangs on Xen fixed (patches from 3.6.3 stable-queue).
    • CONFIG_PREEMPT_VOLUNTARY instead of CONFIG_PREEMPT, this will allow for better scheduling as a domU.
    • CONFIG_HZ=100 instead of CONFIG_HZ=300, this allows for better performance on many-CPU instances, as there are fewer timer interrupts to preempt other tasks.
    • Many drivers removed, particularly those that didn't make sense for running in an EC2 instance. I've left drivers for my own hardware so I can experiment with it as a dom0 kernel as well. The kernel size is roughly half the stock Arch Linux kernel due to the stripped drivers.

    I am also building new AMIs right now, and am beating the i386 AMIs into working order. Once done I'll publish the next release (which should be 2012.10.21). Once it's available, it will show in the tables above.

  • 2012-10-16

    Do not upgrade HVM instance kernels to anything between 3.6.0 and 3.6.2 inclusive. You must wait for 3.6.3 or else your instance will not boot. We're currently waiting on this patch to be integrated into the mainline stable tree. This is also why I am probably not doing an AMI release this week, as the HVM AMIs would be totally broken.

    I've also taken a look at building i386 (well, i686) AMIs. I'm not really sure that it's worth the effort. Nobody really uses 32-bit AMIs anymore, and we'd need to fork the kernel just to make it happen. For now, i686 is on ice.

release notes

These AMIs are as close to a "vanilla" install as I can make them without making them functionally impaired on EC2. But here's the complete list of differences between the EC2 builds and a stock install:

  • High performance kernel specifically for EC2, including paravirtualization support on i386 and x86_64 AMIs, and more Xen-friendly process scheduling.

  • Kernel modules included in initrd, some of which are relevant outside of EC2 contexts (e.g. if you want to run the image in a non-EC2 environment such as KVM or Hyper-V):

    • KVM: virtio virtio-blk virtio-net virtio-pci virtio-ring
    • Xen: xen-blkfront xen-netfront xen-pcifront xen-privcmd
    • Hyper-V: hv_storvsc hv_balloon hv_vmbus hv_utils hv_netvsc
    • IPMI (e.g. EC2 reboot request): button ipmi-msghandler ipmi-poweroff
    • EC2 enhanced networking SR-IOV driver: ixgbevf
  • Extra packages installed: audit, cloud-init, ec2-keyring, ec2-pacman-mirrors, irqbalance, lrzip, openssh, rng-tools, rsync, systemd-sysvcompat

  • Added an extra package source for ec2-specific packages. The repository currently contains numerous packages useful on EC2. You can view the list of packages by doing 'pacman -Sy; pacman -Ss | grep ^ec2'

  • Additional services enabled at boot: rngd, sshd, cloud-init, irqbalance, auditd, systemd-networkd, systemd-timesyncd, systemd-resolved

  • User's public key is pulled from the EC2 instance metadata service at startup, and added to /root/.ssh/authorized_keys

  • SSH configured with 'PasswordAuthentication no', enforcing public key authentication

  • pacman loads (and automatically lsigns) the 'archlinux' and 'ec2' keyrings on the first boot (the latter keyring contains my public key used for package signing in the ec2 repo).

  • pacman mirror list is automatically selected at boot based on a list I created (based on rankmirrors run on instances in each region). These lists are provided by the package ec2-pacman-mirrors, which is in the ec2 repo.

  • dhclient is used instead of dhcpcd for robustness reasons. I found that dhcpcd gave up too quickly if it tried to do a DHCPREQUEST when the vif wasn't completely up, making the EC2 instance inaccessible.

  • dhclient is configured to retry forever, and request the following dhcp options: subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, interface-mtu, fqdn

  • /usr/bin/pinentry is symlinked to /usr/bin/pinentry-curses instead of the default pinentry-gtk, since gtk isn't available in this install and the primary access method is SSH.