Q: What is the Amazon Linux AMI?

The Amazon Linux AMI is a supported and maintained Linux image provided by Amazon Web Services for use on Amazon Elastic Compute Cloud (Amazon EC2). It is designed to provide a stable, secure, and high performance execution environment for applications running on Amazon EC2. It also includes packages that enable easy integration with AWS, including launch configuration tools and many popular AWS libraries and tools. Amazon Web Services provides ongoing security and maintenance updates to all instances running the Amazon Linux AMI. The Amazon Linux AMI is provided at no additional charge to Amazon EC2 users.

Q: Can I view the source code to the Amazon Linux AMI?

Yes. The get_reference_source command line tool provided in the Amazon Linux AMI enables viewing of source code inside of Amazon EC2.

Q: Where can I get updates for the Amazon Linux AMI?

Updates are provided via a pre-configured yum repository hosted in each Amazon EC2 region. Security updates are automatically applied on the initial boot of the AMI. Upon login, the Message of the Day (/etc/motd) indicates whether or not any additional updates are available.

Q: How often will updates for the Amazon Linux AMI be available?

The Amazon Linux AMI is built and maintained as a rolling release. We encourage users to think of the Amazon Linux AMI as a single river of packages, of which the AMI images themselves are just snapshots in time.

Providing a rolling release ensures that our Amazon Linux AMIs and our customer instances based on those AMIs support the latest features of EC2 and AWS as they are launched. In this way, the Amazon Linux AMI also serves as a reference point for other Linux AMI producers (both 3rd party and downstream of the Amazon Linux AMI) so that they can support these features as well.

This model means that customers are more likely to be running with the latest security, performance, and feature enhancements, which mitigates a broad range of problems they could encounter.

Q: Does Amazon provide support for the Amazon Linux AMI?

Yes. The Amazon Linux AMI is supported through subscriptions to AWS Support. More details can be found on the AWS Support page.

Q: Will the Amazon Linux AMI be supported outside of EC2?

No. The Amazon Linux AMI is only available for use inside of Amazon EC2.

Q: How do I report bugs or make feature and package requests?

We use the Amazon EC2 Discussion Forum for bug reports, feature requests, and package requests. These forums are monitored by AWS Developer Support as well as the Amazon Linux AMI engineering team.

Q: How do I enable the Extra Packages for Enterprise Linux (EPEL) repository?

Modify /etc/yum.repos.d/epel.repo. Under the section marked [epel] , change enabled=0 to enabled=1.

To temporarily enable the EPEL 6 repository, use the yum command line option --enablerepo=epel.

Please note that the Amazon Linux AMI repositories are configured with a higher priority than any third-party repositories. The reason for this is because there are several packages that are part of the Amazon Linux AMI that are also in third-party repositories, and we want to make sure that the Amazon Linux AMI version is installed in the default case.

Q: How do I lock my AMI to a specific version?

The Amazon Linux AMI repository structure is configured to deliver a continuous flow of updates that allow you to roll from one version of the Amazon Linux AMI to the next.

Package updates are always pushed into the repositories and are available to any versions of the Amazon Linux AMI where yum is configured to point to "latest". You can see which repositories your instance is pointing to by looking at the "releasever" variable in /etc/yum.conf – by default, the Amazon Linux AMI has releasever=latest set.

In other words, Amazon Linux AMIs are treated as snapshots in time, with a repository and update structure that provides the latest packages that we have built and pushed into the repository.

The "lock on launch" feature exists to give people a simple way to keep their AMIs on a particular major version, if they don't want to necessarily get a bunch of package updates when we release new major versions of the Amazon Linux AMI.

To enable this feature in new instances, launch (for example) a 2015.09 Amazon Linux AMI with the following user data passed to cloud-init, either via the EC2 console or via aws ec2 run-instances with the --user-data flag (this can also be done with ec2-run-instances -f ).

repo_releasever: 2015.09

To lock existing instances to their current version (indicated in /etc/system-release), edit /etc/yum.conf. Comment out the line that reads releasever=latest and run yum clean all to clear the cache.

Q: How do I disable the automatic installation of critical and important security updates on initial launch?

On first boot, the Amazon Linux AMI installs from the package repositories any user space security updates that are rated critical or important, and it does so before services, such as SSH, start.

If the AMI cannot access the yum repositories, it will timeout and retry multiple times before completing the boot procedure. Possible reasons for this are restrictive firewall settings or VPC settings, which prevent access to the Amazon Linux AMI package repositories.

If you encounter this issue you can either modify your environment so that the Amazon Linux AMI can connect to its package repositories or you can disable the security update on boot.

To disable the security update on boot from the AWS EC2 Console:

On the "Advanced Instance Options" page in the Request Instances Wizard, there is a text field for sending the Amazon Linux AMI user-data. This data can be entered as text, or uploaded as a file. In either case, the data should be:

repo_upgrade: none

To disable the security update on boot from the command line:

Create a text file with the preceding user-data, and pass it to aws ec2 run-instances with the --user-data file://<filename> flag (this can also be done with ec2-run-instances -f ).

To disable the security update on boot when rebundling the Amazon Linux AMI:

Modify /etc/cloud/cloud.cfg and change repo_upgrade: security to repo_upgrade: none.

Q: Why does it take a long time for SSH to start up when running in a Virtual Private Cloud (VPC) without an Internet Gateway or NAT instance?

See the answer to the previous question.

Q: Why do my RAID arrays start at /dev/md127 instead of /dev/md0?

Newer versions of mdadm create RAID arrays with version 1.2 superblocks, which do not automatically assemble with a numbered device. Reference partitions by setting a label for the file system. Most file system creation tools use the -L flag to set the label. Once set, the label is referenced by mount or in /etc/fstab with LABEL=[NAME].

Example: Creating a RAID0 array with a label.

mdadm --create --verbose /dev/md0 --level=0 --name=0 --raid-devices=2 /dev/sdb /dev/sdc
mkfs.ext4 -L RAID0 /dev/md0
mkdir -p /mnt/RAID0
mount LABEL=RAID0 /mnt/RAID0

Example: Setting the label of an existing ext[2-4] file system.

e2label /dev/md127 RAID
mkdir -p /mnt/RAID
mount LABEL=RAID /mnt/RAID

Q: Why was the wheel group disabled from /etc/sudoers and how do I re-enable it?

Linux operating systems have different defaults in terms of whether or not wheel is enabled for sudo. We believe that having wheel disabled from sudo by default is a more sensible security posture for the Amazon Linux AMI.

There are two workarounds to this issue, which differ depending on whether or not you have the ability to SSH into your instances as the default ec2-user, and whether or not you have altered that user's ability to use sudo.

Option #1: For users who have not changed any of the defaults, you should still be able to ssh into your instance as ec2-user and from there invoke sudo to gain root, at which point you can modify the sudoers file to re-enable wheel.

Option #2: For users who have changed the defaults or who don’t have the ability to sudo from ec2-user to root, we recommend the following steps:

  • Stop the affected instance (do not terminate).
  • Detach the root EBS volume, using either the EC2 Console or the EC2 API tools.
  • Attach the volume to another EC2 instance to which you have remote root access.
  • Login into that instance.
  • Mount the newly attached volume.
    sudo mount /dev/xvdf /mnt
  • Modify the sudoers file in the attached volume and uncomment the wheel group.
    sudo sed -i.bak 's,# \(%wheel\s\+ALL=(ALL)\s\+ALL\),\1,' /mnt/etc/sudoers
  • Unmount the volume.
    sudo umount -d /dev/xvdf
  • Detach the volume.
  • Reattach the volume to your stopped instance (make sure that the device is the same as it was before the detachment, usually: /dev/sda1).
  • Start the affected instance.

Q: Why do I see strange characters like � or â when talking to the Amazon Linux AMI via a terminal?

The Amazon Linux AMI uses the UTF-8 character encoding by default. Client terminals not using the UTF-8 encoding will not always translate UTF-8 characters correctly. To fix this, set your client terminal encoding to UTF-8:

  • GNOME Terminal: From the Terminal menu choose Set Character Encoding and select UTF-8.
  • PuTTY: Right click on the title bar to bring up the menu. Then choose Change Settings. Under Window → Translation → Remote Character Set choose UTF-8.

Q: I see an option report_instanceid in /etc/yum.repos.d/amzn*.repo. What does this do?

The Amazon Linux AMI repositories are S3 buckets in each region. When the yum process on your instance downloads packages from those buckets, information about that S3 connection is logged.

Within the context of the Amazon Linux AMI, the report_instanceid=yes setting allows the Amazon Linux AMI repositories to also log the instance id (i-xxxxxxxx) and region (e.g. us-west-2) of an instance downloading a package. This enables the Amazon Linux AMI team to provide more focused and specific customer support to individual instances.

report_instanceid=yes is enabled by default only for the Amazon Linux AMI repositories.

Q: Why are the /etc/yum.repos.d/amzn*.repo yum repository configuration files overwritten when the system-release package is upgraded?

These repository configuration files are overwritten when the system-release package is upgraded to ensure that instances always see changes to the Amazon Linux AMI yum repository configuration.

For Amazon Linux AMI versions before 2014.09:

These files are generated by cloud-init from templates located at /etc/cloud/templates/amzn-*.repo.tmpl. Changes made to these template files will persist.

For Amazon Linux AMI 2014.09 and later:

/etc/yum.repos.d/amzn*.repo files now use yum variables to help instances reach the geographically-closest repositories, so we no longer use cloud-init templates. Any edits to these files will be preserved as /etc/yum.repos.d/amzn*.repo.rpmsave when system-release is upgraded.

Users upgrading to 2014.09 will see any edits made to /etc/yum.repos.d/amzn*.repo files saved as /etc/yum.repos.d/amzn*.repo.rpmsave.

Q: How can I change or turn off man page colors?

Man page colors are configured in /etc/profile.d/less.sh (bash and zsh) and /etc/profile.d/less.csh (csh). To turn them off, remove all lines starting with export LESS_ (bash, zsh) and/or setenv LESS_ (csh).

Q: How do I disable system call auditing on pre-2015.09 instances?

System call auditing has been disabled by default in new launches of the 2015.09 Amazon Linux AMI.  System call auditing adds overhead with every system call and may result in noticeable performance degradation, especially in disk- or network-intensive applications.

If you need system call auditing, please find the following line in /etc/audit/audit.rules and remove it or comment it out, then restart the audit daemon.

 -a never,task

Example (as root):

# auditctl -l
LIST_RULES: task,never
# sed -i.bak -e '/^-a never,task$/ s/^/#/' /etc/audit/audit.rules
# service auditd restart
# auditctl -l
No rules

If you want to get the same performance improvement on instances started from pre-2015.09 AMIs, please add the same line (  -a never,task ) to /etc/audit/audit.rules and restart the daemon. If you are upgrading and have not made any changes to audit rule files, you can simply move or copy the new default rules file to /etc/audit/audit.rules

Example (as root)

# auditctl -l
No rules
# cp -p /etc/audit/rules.d/audit.rules.default /etc/audit/audit.rules
cp: overwrite ‘/etc/audit/audit.rules’? y
# service auditd restart
# auditctl -l
LIST_RULES: task,never

Q: Can you provide an example of using mime-multipart userdata with cloud-init?

The documentation for mime-multipart for cloud-init lives here.

MIME multipart can be a tricky format, so it's best to use the write-mime-multipart tool to generate the multipart file. This tool is in the cloud-utils package and can be installed with sudo yum install /usr/bin/write-mime-multipart. The tool uses the first line of the file to determine the Content-Type, and cloud-init uses the Content-Type to determine how it should interpret the file. Some example files:

repo_releasever: 2015.09


echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt

Here is an example of write-mime-multipart, including output:

[ec2-user@ip-172-31-4-37 ~]$ write-mime-multipart repo_releasever-2015.09.cfg ci-was-here.sh
Content-Type: multipart/mixed; boundary="===============6347220379374809187=="
MIME-Version: 1.0

Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="repo_releasever-2015.09.cfg"

repo_releasever: 2015.09

Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ci-was-here.sh"

echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt


More information about how to use the tool can be found with man write-mime-multipart.