Amazon Linux AMI FAQs

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.

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

The Amazon Linux AMI (also called Amazon Linux 1) reached its end of life on December 31, 2023. Amazon Linux AMI will not receive any security updates or bug fixes starting January 1, 2024.

Maintenance support refers to the period after the end of standard support for Amazon Linux AMI. Maintenance support extends from December 31, 2020 until December 31, 2023. During this period, AWS will no longer add support for new EC2 instance types, new AWS services and features, and new packages. Instead, AWS will provide updates only for critical and important security fixes that apply to a reduced set of packages. Additionally, some packages in the AMI and its repositories will slowly be deprecated throughout the maintenance support period according to their upstream end-of-life practices.

AWS will provide critical and important security updates to the Linux kernel in the AMI, as well as all but the deprecated userspace packages.

During the maintenance window any package -outside of the low-level userspace libraries- that have reached end-of-life in their upstream sources will no longer receive updates.

MySQL 5.1
PHP 5.3
PHP 5.4
PHP 5.5
PHP 7.0
PostgreSQL 8
Python 2.6
Ruby 1.8
Ruby 1.9
Ruby 2.1
Ruby 2.2

All of the compat- packages
BZR - (bzr-python26 and bzr-python27 packages)
Ganglia
Mercurial
MySQL 5.5
Python 3.4 (python34)
Python 3.5 (python35)
PostgreSQL 9.3 (postgresql93)
PHP 7.1
PHP 7.2
Tomcat 7
Tomcat 8
Ruby 2.3
Ruby 2.4
PostgreSQL 9.4
Puppet 2.7.x (puppet)
Puppet 3.7.x (puppet3)
Subversion 1.9
Transmission
OpenJDK 1.7.0 (java-1.7.0-openjdk)

Yes, and if that policy ever changes we will communicate it in advance.

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

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

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

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.

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.

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 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 ).
#cloud-config
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.

NOTE: If you lock your AMI to a version of the repositories that is not "latest" you will not receive any further updates. The only way to receive a continuous flow of updates for the Amazon Linux AMI is to be using the latest AMI, or to be consistently updating your old AMI with the repositories pointed to "latest".

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:
#cloud-config
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.

See the answer to the previous question.

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

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.

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.

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.

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.

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).

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

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:
#cloud-config
repo_releasever: 2015.09
and
#!/bin/bash
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
--===============6347220379374809187==
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"
#cloud-config
repo_releasever: 2015.09
--===============6347220379374809187==
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ci-was-here.sh"
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
--===============6347220379374809187==--
More information about how to use the tool can be found with man write-mime-multipart.

It is possible to access the yum repositories within a VPC without access to the internet. Your VPC endpoint policy must allow traffic from your VPC to the S3 buckets that host the Amazon Linux AMI repositories.
Below is an example VPC endpoint policy that accomplishes this:
{
"Statement": [
{
"Sid": "Amazon Linux AMI Repository Access",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::packages.*.amazonaws.com/*",
"arn:aws:s3:::repo.*.amazonaws.com/*"
]
}
]
}
For more information, please see the VPC endpoint documentation.