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

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

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

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

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

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

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

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)

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

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

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

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

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

/etc/yum.repos.d/epel.repo を変更してください。 [epel] とマークされたセクションで、有効=0を有効=1に変更します。

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

Amazon Linux AMI リポジトリは、サードパーティーのリポジトリよりも高い優先度で構成されています。これは、Amazon Linux AMI に含まれるパッケージが、サードパーティーリポジトリにも含まれることがあるからです。この構成により、Amazon Linux 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 実行インスタンス経由で、次のユーザーデータを cloud-init に渡して 2015.09 Amazon Linux AMI を起動します。これは、EC2 コンソールまたは -- user-data フラグを付けて実行することもできます (これは 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 を更新する必要があります。

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://フラグを付けて aws ec2 run-instances に渡します (これは ec2-run-instances-f を使用して行うこともできます)。 <filename>

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

/etc/cloud/cloud.cfg を変更して repo_upgrade: セキュリティーを repo_upgrade: なしに変更してください。

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

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

例: ラベルで 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

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

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

オプション #1: デフォルトを何も変更していないユーザーに対しては、ec2-user としてインスタンスに ssh 接続し、そこから sudo を起動して root を取得できるはずです。その時点で sudoers ファイルを変更して wheel を再度有効にすることができます。
オプション #2: デフォルトを変更したユーザーや、ec2-user から root に 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 です)。

• 影響のあるインスタンスを開始します。

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

• Gnome 端末: 端末のメニューから [Set Character Encoding] を選択し、[UTF-8] を選択します。

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

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 リポジトリでのみデフォルトで有効になっています。

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

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 として保存されていることがわかります。

マニュアルページの色は /etc/profile.d/ less.sh (bash と zsh) と /etc/profile.d/less.csh (csh) で設定されています。これらをオフにするには、export LES_ (bash, zsh) や setenv LESS_ (csh) で始まる行をすべて削除してください。

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

システムコール監査が必要な場合は、/etc/audit/audit.rules から次の行を探し、これを削除するかコメントアウトしてから、監査デーモンを再起動します。
- 決して、やらない仕事
例 (ルートとして):
# auditctl -l
LIST_RULES: task,never
# sed-i.bak-e '/^-a 決して、task$/ s/^/#/' /etc/audit/audit.rules
# サービス監査再起動
# auditctl -l
ルールなし
2015.09 年以前の AMI から起動したインスタンスで同じパフォーマンスを向上させたい場合は、 /etc/audit/audit.rules に同じ行 (-a never, task) を追加して、デーモンを再起動してください。アップグレード中で、監査ルールファイルに変更を加えていない場合は、新しいデフォルトルールファイルを /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
# サービス監査再起動
# auditctl -l
LIST_RULES: タスク、決して

cloud-init 用の MIME-マルチパートのドキュメントはこちらにあります。
MIME マルチパートは扱いにくい形式なので、 write-mime-multipart ツールを使用してマルチパートファイルを生成するのが最適です。このツールはクラウドユーティリティパッケージに含まれており、 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
コンテンツタイプ:マルチパート/ミックス; boundary= "=======================6347220379374809187==」
マイムバージョン: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
コンテンツディスポジション:添付ファイル; ファイル名= 」ci-was-here.sh」
#!/ビン/バッシュ
echo「クラウド初期化はここにあった...">> /tmp/cloud-init-was-here.txt
--===============6347220379374809187==--
ツールの詳しい使用方法は、man write-mime-multipart を使って確認できます。

インターネットにアクセスしなくても、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 エンドポイントのドキュメントをご覧ください。