Amazon Linux AMI FAQs

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: 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: How long will the Amazon Linux AMI be supported?

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.

Q: How does the maintenance support differ from the standard support period?

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.

Q: What is the list of packages that will get critical and important security patches during the maintenance support period?

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

Q: Which packages will be no longer receive updates during ‘Maintenance Support’ period?

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.

The following packages were deprecated with the original 2018.03 release, and will not be receiving further updates as part of the Maintenance Support period:

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

In addition, the following packages will not be receiving any further updates as part of Maintenance Support, and are End of Life:

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)

Additionally, some other packages that will stop receiving updates sometime during the maintenance period:

Due to the nature of RPM dependencies and how one of these top level packages can be comprised of several RPMs, a complete list of all RPM packages in Amazon Linux 1 and their End of Life Dates is available here.

Q: Can I launch Amazon Linux AMIs after the maintenance support period ends?

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

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: Can I view the source code to the Amazon Linux AMI?

Yes. The yumdownloader --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 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 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".

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

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

Q: How do I configure a VPC endpoint to allow connections to the Amazon Linux AMI repositories?

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.