Amazon Linux AMI に関するよくある質問

Q: Amazon Linux AMI とは何ですか?

Amazon Linux AMI は、Amazon Elastic Compute Cloud (Amazon EC2) 上で使用するための、Amazon Web Services によって提供され、サポートと保守が行われる、Linux のイメージです。これは、Amazon EC2 上で実行されるアプリケーションに、安定した安全で高性能な実行環境を提供するために設計されています。また、起動設定ツールおよび多くの AWS 人気ライブラリやツールなど、AWS の統合を容易にするいくつかのパッケージも含まれています。アマゾン ウェブ サービスは、Amazon Linux AMI を実行するすべてのインスタンスに、セキュリティと保守のアップデートを継続的に提供します。Amazon Linux AMI は、Amazon EC2 ユーザーには追加料金なしで提供されます。

Q: Amazon は Amazon Linux AMI のサポートを提供していますか?

はい。Amazon Linux AMI は、AWS サポートのサブスクリプションを介してサポートされています。詳細については、AWS サポートページをご覧ください。

Q: Amazon Linux AMI はどれくらいの期間、サポートされますか?

Amazon Linux AMI (Amazon Linux 1 とも呼ばれる) は、2023 年 12 月 31 日にサポートが終了しました。Amazon Linux AMI は、2024 年 1 月 1 日以降、セキュリティアップデートやバグフィックスを一切受け取りません。

Q: メンテナンスサポートは標準サポート期間とどう異なりますか?

メンテナンスサポートは、Amazon Linux AMI の標準サポートが終了した後の期間を指します。メンテナンスサポートは、2020 年 12 月 31 日から 2023 年 12 月 31 日まで延長されます。この期間中、AWS は新しい EC2 インスタンスタイプ、新しい AWS サービスと機能、および新しいパッケージのサポートを追加しません。代わりに、AWS は、減少されたパッケージセットに適用される重大かつ重要なセキュリティ修正に対してのみ更新を提供します。また、AMI および一部のリポジトリパッケージは、アップストリーム終了日のプラクティス通り、メンテナンスサポート期間を通して徐々に非推奨になります。

Q: メンテナンスサポート期間中に重大かつ重要なセキュリティパッチを入手できるパッケージリストには何がありますか?

AWS は、AMI の Linux カーネル、および非推奨のユーザースペースパッケージを除くすべてに対して、重大かつ重要なセキュリティアップデートを提供します。

Q:「メンテナンスサポート」期間中に更新されないパッケージはどれですか?

メンテナンス期間にアップストリームのソースでサポートが終了したパッケージ (低レベルのユーザースペースライブラリ以外) は、更新を受信しなくなります。

以下のパッケージは、元の 2018.03 リリースで非推奨となり、メンテナンスサポートの一環として一定期間存続し、これ以上の更新を受けることはありません。

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

さらに、以下のパッケージは、メンテナンスサポートの一環として、これ以上の更新を受けず、サポートが終了します。

すべての互換パッケージ
BZR - (bzr-python26 および bzr-python27 パッケージ)
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)

さらに、他の一部のパッケージはメンテナンス期間に更新の受信を停止する予定です。

RPM の依存関係の性質上、1 つの最上位レベルパッケージが複数の RPM で構成される可能性があります。Amazon Linux 1 のすべての RPM パッケージの詳細なリストとそのサポート終了日についてはこちらをご覧ください。

Q: メンテナンスサポート期間の終了後に Amazon Linux AMI を起動できますか?

はい。そのポリシーが変更された場合、事前にお知らせします。

Q: Amazon Linux AMI は EC2 以外でサポートされますか?

いいえ。Amazon Linux AMI は、Amazon EC2 内でのみ使用可能です。

Q: Amazon Linux AMI へのソースコードを見ることができますか?

はい。Amazon Linux AMI で提供されるソースコマンドラインツールである yumdownloader により、Amazon EC2 内のソースコードを表示できます。

Q: Amazon Linux AMI はどこで更新できますか?

各 Amazon EC2 リージョンがホストしている、事前設定された yum リポジトリを介して更新できます。セキュリティ更新は、AMI の最初の起動時に自動的に適用されます。ログイン時に、当日のメッセージ (/etc/motd) により追加のアップデートがあるかどうかが示されます。

Q: バグ報告、機能のリクエスト、およびパッケージのリクエストを報告するにはどうすればよいですか?

Amazon EC2 ディスカッションフォーラムでバグ報告、機能のリクエスト、およびパッケージのリクエストを受け付けています。このフォーラムには、Amazon Linux AMI エンジニアリングチームに加えて AWS デベロッパーサポートの担当者も参加しています。
 

Q: Enterprise Linux 用の追加パッケージ (EPEL) リポジトリを有効にするにはどうすればよいですか?

/etc/yum.repos.d/epel.repo を変更します。 [epel] セクションで、enabled=0 を enabled=1 に変更します。

一時的に EPEL 6 リポジトリを有効にするには、yum コマンドラインオプション --enablerepo=epel を使用します。

Amazon Linux AMI リポジトリは、サードパーティーのリポジトリよりも高い優先度で構成されています。これは、Amazon Linux AMI に含まれるパッケージが、サードパーティーリポジトリにも含まれることがあるからです。この構成により、Amazon Linux AMI バージョンがデフォルトでインストールされるようになります。

Q: AMI を特定のバージョンに固定するにはどうすればよいですか?

Amazon Linux AMI のリポジトリ構造は、Amazon Linux AMI のあるバージョンから次のバージョンへのローリング更新を可能にする、連続的な更新を提供するように設定されています。

パッケージの更新は常にリポジトリにプッシュされ、yum が最新を指すように設定されている Amazon Linux AMI のどのバージョンにも利用できます。インスタンスが指しているリポジトリは、/etc/yum.conf の「releasever」変数で確認できます。デフォルトでは、Amazon Linux AMI には releasever=latest がセットされています。

つまり、Amazon Linux AMI は各ポイントでのスナップショットとして処理されます。このスナップショットにはリポジトリと更新の構造が保存され、これにより、リポジトリに組み込んだ構築済みの最新パッケージが提供されます。

Amazon Linux AMI の新しいメジャーバージョンがリリースされたときにパッケージの更新を受け取りたくない場合、「起動時にロック」は特定のメジャーバージョンで AMI を固定する簡単な方法です。

この機能を新しいインスタンスで有効にするには、EC2 コンソールを使用するか、aws ec2 run-instances で --user-data フラグを指定して、2015.09 Amazon Linux AMI などを起動し、次のユーザーデータを cloud-init に渡します (これは ec2-run-instances -f でも実行できます)。
#cloud-config
repo_releasever: 2015.09

既存のインスタンスを現在のバージョン (/etc/system-release で指定) に固定するには、etc/yum.conf を編集します。releasever=latest という行をコメントアウトし、yum clean all を実行してキャッシュをクリアします。

注: AMI を「最新」以外のリポジトリのバージョンに固定すると、それ以上の更新を受け取ることができなくなります。Amazon Linux AMI の更新を継続的に受け取るには、最新の AMI を使用するか、必ず「最新」と表示されているリポジトリで古い AMI を更新する必要があります。

Q: 初回起動時に非常に重要なセキュリティアップデートの自動インストールを無効にするにはどうすればよいですか?

初回起動時に Amazon Linux AMI では、パッケージリポジトリから、必須または重要と思われるすべてのユーザースペースセキュリティアップデートがインストールされます。このインストールは、SSH などのサービスが開始される前に実行されます。

AMI が yum リポジトリにアクセスできない場合は、それがタイムアウトとなり、起動手順が完了する前に複数回再試行されます。考えられる理由としては、制限されたファイアウォール設定または VPC 設定により Amazon Linux AMI のパッケージリポジトリへのアクセスが妨げられていることが挙げられます。

この問題が発生した場合は、環境を変更して Amazon Linux AMI がそのパッケージリポジトリに接続できるようにするか、または起動時にセキュリティアップデートを無効にすることができます。

起動時に、AWS EC2 コンソールからセキュリティアップデートを無効にする方法:

リクエストインスタンスウィザードの「高度なインスタンスオプション」ページに、Amazon Linux AMI のユーザーデータを送信するテキストフィールドがあります。このデータは、テキストとして入力するか、またはファイルとしてアップロードできます。どちらの場合でも、データは以下のようになります。
#cloud-config
repo_upgrade: なし

起動時に、コマンドラインからセキュリティアップデートを無効にする方法:

前述のユーザーデータを使用してテキストファイルを作成し、--user-data file://<filename> フラグを含む aws ec2 run-instances に渡します (これは、ec2-run-instances -f でも実行できます)。

Amazon Linux AMI をリバンドリングする際、起動時にセキュリティアップデートを無効にする方法:

/etc/cloud/cloud.cfg を修正し、repo_upgrade: security を repo_upgrade: none に変更します。

Q: インターネットゲートウェイまたは NAT インスタンスなしに Virtual Private Cloud (VPC) で実行する際、SSH の起動に長時間かかるのはなぜですか?

前の質問の答えをご覧ください。

Q: 私の RAID アレイはなぜ /dev/md0 ではなく /dev/md127 で始まるのですか?

新しいバージョンの mdadm では、バージョン 1.2 スーパーブロックで RAID アレイが作成されるので、番号が付いたデバイスによる自動アセンブルは行われません。ファイルシステムのラベルを設定して、パーティションを参照します。ファイルシステム作成ツールでラベルを設定する場合は、ほとんどのツールで -L フラグを使用します。一度設定されたラベルは、マウントまたは LABEL=[NAME] が指定された /etc/fstab によって参照されます。

例: ラベルで RAID0 アレイを作成する。
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
例: 既存の ext[2-4] ファイルシステムのラベルを設定する。
e2label /dev/md127 RAID
mkdir -p /mnt/RAID
mount LABEL=RAID /mnt/RAID

Q: ホイールグループが /etc/sudoers から無効にされたのはなぜですか? これを再度有効にするにはどうすればよいですか?

Linux オペレーティングシステムでは、ホイールが sudo に対して有効かどうかについては、デフォルトの設定がさまざまです。sudo からの wheel がデフォルトで無効になっているのは、Amazon Linux AMI のセキュリティに対する姿勢を考えると理にかなっています。

この問題は、デフォルトの ec2-user としてインスタンスに SSH 接続できるかどうか、また、ユーザーによる sudo の使用機能を変更したかどうかに応じて、2 つの方法で回避できます。

オプション 1: ユーザーがデフォルトの機能を変更していない場合は、引き続き ec2-user としてインスタンスの SSH 接続し、そこから sudo を起動してルートにアクセスし、sudoers ファイルを変更して wheel を再度有効にできます。
オプション 2: ユーザーがデフォルトを変更した場合、または ec2-user からルートに sudo を実行できない場合は、次の手順を実行することをお勧めします。

• 影響のあるインスタンスを停止します (終了はしません)。
• EC2 コンソールまたは EC2 API ツールを使用して、ルート EBS ボリュームをデタッチします。
• リモートルートアクセスできる他の EC2 インスタンスにボリュームをアタッチします。
• そのインスタンスにログインします。
• 新しくアタッチされたボリュームをマウントします。
  sudo mount /dev/xvdf /mnt
• アタッチされたボリュームで sudoers ファイルを変更し、wheel グループのコメントを解除します。
  sudo sed -i.bak 's,# \(%wheel\s\+ALL=(ALL)\s\+ALL\),\1,' /mnt/etc/sudoers
• ボリュームのマウントを解除します。
  sudo umount -d /dev/xvdf
• ボリュームをデタッチします。
• 停止されたインスタンスにボリュームを再アタッチします (デタッチ前と同じデバイスであることを確認してください。通常は /dev/sda1 です)。
• 影響のあるインスタンスを開始します。

Q: 端末から Amazon Linux AMI にアクセスすると、� や â などの奇妙な文字が表示されるのはなぜでしょうか?

Amazon Linux AMI は、デフォルトで UTF-8 文字エンコーディングを使用します。UTF-8 エンコーディングを使用していないクライアント端末は、UTF-8 文字を正しく変換できないことがあります。この問題を修正するには、クライアント端末のエンコーディングを UTF-8 に設定します。

• Gnome 端末: 端末のメニューから [Set Character Encoding] を選択し、[UTF-8] を選択します。
• PuTTY: タイトルバーを右クリックしてメニューを呼び出します。次に、[Change Settings] を選択します。[Window] → [翻訳] → [リモート文字設定] の下で、[UTF-8] を選択します。

Q: オプションの report_instanceid が /etc/yum.repos.d/amzn*.repo にあります。これは何をするためのものですか?

Amazon Linux AMI リポジトリは、各リージョン内の S3 バケットです。このバケットからインスタンスの yum プロセスによってパッケージがダウンロードされるとき、対応する S3 接続に関する情報が記録されます。
Amazon Linux AMI のコンテキスト内で report_instanceid=yes と設定すると、Amazon Linux AMI リポジトリでは、パッケージをダウンロードしているインスタンスのインスタンス ID (i-xxxxxxxx) やリージョン (us-west-2 など) も記録できます。これにより、Amazon Linux AMI チームは個々のインスタンスについて、より詳細で具体的なカスタマーサポートを提供できます。
report_instanceid=yes は、Amazon Linux AMI リポジトリでのみ、デフォルトで有効になっています。

Q: システムリリースパッケージがアップグレードされると、/etc/yum.repos.d/amzn*.repo の yum リポジトリ設定ファイルが上書きされるのはなぜですか?

システムリリースパッケージがアップグレードされると、リポジトリ設定ファイルは上書きされます。これにより、Amazon Linux AMI yum リポジトリ構成に対する変更内容が各インスタンスによって確実に参照されるようになります。
2014.09 より前のバージョンの Amazon Linux AMI の場合
これらのファイルは cloud-init によって、/etc/cloud/templates/amzn-*.repo.tmpl にあるテンプレートから生成されます。これらのテンプレートファイルに加えられた変更は永続的です。

2014.09 以降のバージョンの Amazon Linux AMI の場合

/etc/yum.repos.d/amzn*.repo ファイルで yum 変数を使用することで、各インスタンスが地理的に最も近いリポジトリを参照するようになったため、cloud-init テンプレートが不要になりました。これらのファイルに対する編集内容は、システムリリースのアップグレード時に、/etc/yum.repos.d/amzn*.repo.rpmsave として保存されます。

2014.09 バージョンにアップグレードすると、/etc/yum.repos.d/amzn*.repo ファイルに対するすべての変更内容は /etc/yum.repos.d/amzn*.repo.rpmsave ファイルとして保存されます。

Q: man ページの色を変更する、または無効にする方法を教えてください。

man ページの色は、/etc/profile.d/less.sh (bash と zsh) および /etc/profile.d/less.csh (csh) で設定されています。無効にするには、export LESS_ (bash、zsh) や setenv LESS_ (csh) で始まるすべての行を削除します。

Q: 2015.09 より前のインスタンスでのシステムコール監査を無効にするにはどうすればよいですか?

システムコール監査は、新しい Amazon Linux AMI 2015.09 リリースではデフォルトで無効になっています。システムコール監査によりすべてのシステムコールにオーバーヘッドが加わるため、特にディスクやネットワークに負荷が集中するアプリケーションでは、大幅にパフォーマンスが下がることがあります。

システムコール監査が必要な場合は、/etc/audit/audit.rules から次の行を探し、これを削除するかコメントアウトしてから、監査デーモンを再起動します。
-a never,task
例 (ルートとして):
# auditctl -l
LIST_RULES: task,never
# sed -i.bak -e '/^-a never,task$/ s/^/#/' /etc/audit/audit.rules
# service auditd restart
# auditctl -l
ルールなし
2015.09 より前の AMI から起動するインスタンスで同じようなパフォーマンス改善を望む場合は、同じ行 (-a never,task) を /etc/audit/audit.rules に追加してからデーモンを再起動します。アップグレード中で監査ルールファイルに変更を加えてない場合は、ただ単に新しいデフォルトのルールファイルを /etc/audit/audit.rules に移動するかコピーします。
例 (ルートとして)
# auditctl -l
ルールなし
# 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: Cloud-init による MIME マルチパートユーザーデータの使用例はありますか?

Cloud-init での MIME マルチパートのドキュメントはこちらにあります。
MIME マルチパートの形式には注意が必要な場合があります。そのため、write-mime-multipart ツールを使用してマルチパートファイルを作成することをお勧めします。このツールは cloud-utils パッケージに含まれ、sudo yum install /usr/bin/write-mime-multipart を使ってインストールできます。ツールがファイルの最初の行から Content-Type を判断し、Cloud-init は Content-Type を使ってファイルの解読方法を判断します。以下はいくつかのファイル例です。
#cloud-config
repo_releasever: 2015.09
そして
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
こちらは出力を含む write-mime-multipart の例です。
[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==--
ツールの詳しい使用方法は、man write-mime-multipart を使って確認できます。

Q: VPC エンドポイントを設定して Amazon Linux AMI リポジトリへの接続を許可するにはどうすればよいですか?

インターネットにアクセスしなくても、VPC 内の yum リポジトリにアクセスすることができます。お客様の VPC エンドポイントポリシーで、VPC から Amazon Linux AMI リポジトリをホストする S3 バケットへのトラフィックを許可する必要があります。
以下はこれを実現する VPC エンドポイントポリシーの例です。
{
"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/*"
]
}
]
}
詳細は、VPC エンドポイントのドキュメントをご覧ください。