AMI
AMI(Amazon Machine Image) は、EC2インスタンスの起動に必要な情報を提供するイメージファイルで、
OSやアプリケーションなどのルートボリュームのテンプレート
起動を許可するAWSアカウント インスタンスにアタッチするボリュームのマッピング
などの情報が含まれている。
AMIは、AWSや様々な組織が公開しており、これを利用することができる。特にAmazon Linux は、AWSが提供しているRHEL系のAMIで、AWS CLI Amazon EC2 API 等がパッケージに含まれているため便利で使い勝手が良い。また、自身が作成したインスタンスから生成したAMI(カスタムAMI)を登録/利用することもできる 。
なお、AMIは同一リージョン内や別のリージョンにコピーを作成することや、他のAWSアカウントとイメージを共有することが可能である。別リージョンにバックアップシステムを構築する場合、AMIのコピーはシステム構築の有用な手段となる。AMIの共有は、公開範囲をパブリックに指定するか、「イメージパーミッションの変更 」設定から、許可するAWSアカウントの追加を行う。他者が公開しているAMIを利用する際は、機密データが第3者に送信されていないかや、認証情報が事前に設定されていないか などを十分に検証する必要がある。
作成したAMIを別リージョンで使用する際は、AWS CLIのリージョン設定やプログラムのデフォルトリージョン設定をハードコーディングせず に、シェルスクリプト等で変更できるようにしておくと良い。自身のリージョン情報を取得するには、AWS CLIから以下のコマンドを入力する。
$ curl -s https://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g'
AMIの作成
既存のインスタンス、もしくはスナップショットからAMIを作成することが可能である。AMIの作成は、インスタンス上のすべての動作を停止し、作成プロセス中に一貫した状態が保たれるようにするために、インスタンスをシャットダウンしてから行う 。自身で作成したAMIを共有する場合は、以下のように、共有キーやコマンド履歴の削除等の対策 を行う。
$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub
$ shred -u ~/.*history
$ history -c
$ exit
ストレージ
ストレージは以下の2種類が存在する。どちらのデバイスから起動させるか選択することも可能であるが、高速で永続的なEBS-basedの起動方法が奨励 されている。
Instance Store
EC2と不可分の内蔵ディスクで、EC2をTERMINATEするとクリアされる。ただし、再起動ではクリアされない 。
インスタンス停止（STOP） することができない。無料
Elastic Block Store
ネットワークで接続されたディスクで、EC2とは独立しており、別途課金される。同じアベイラビリティゾーン内でレプリケーションされるため、高い可用性を有している。
デフォルトでは、DeleteOnTermination フラグが true に設定されているので、TERMINATEすると消去されてしまう ことに注意が必要である。消去されたボリュームは、ゼロで上書きされて他のアカウントで使用される。機密データを有している場合は、暗号化の検討が必要 である。
スナップショットを取ることが可能である。スナップショットは、過去のスナップショットとの差分 として記録される。スナップショットを取得する際には、EBSをアンマウントする ことが望ましい。一方で、スナップショットが開始されれば、スナップショット取得処理中であってもEBSをアタッチして使用して問題ない 。
インスタンスとEBSボリュームはネットワーク経由で接続されているため、他の通信の影響を受ける。EBS最適化インスタンス を利用することで、インスタンスとEBSとの間のスループットが保証 され、他の通信の影響を受けない。
容量と性能
汎用SSD（gp2）のパフォーマンスは、ボリュームサイズに比例 する。つまり、小さい容量のEBSの場合は、I/O性能も低い。したがって、高頻度のI/Oが発生する可能性があるアプリケーションが動作する場合などは、使用する容量が低くても、I/Oの性能を向上させるために、大きな容量を設定しておく 必要がある。
各ボリュームは、最初に540万I/Oクレジット を受け取り、標準性能を超えたI/O処理（バースト ）は、このクレジットから消費されていく。一方、標準性能を下回るI/Oであった場合はクレジットに加算されていく。ただし、加算できるクレジットは、初期値と同じ540万I/Oクレジットまで。クレジットが枯渇するとバースト性能を利用できなくなり、標準性能で頭打ちとなる。なお、汎用SSD（gp2）は、
容量が33.4GB以下であれば、標準性能100IOPS
容量が1000GB以下であれば、3000IOPSのバースト性能を利用可能
容量が3333GBに標準性能10000IOPSに達して、容量16TBまでこの性能を維持
と定義されている。また、スループットは、170GB以下では128 MB/秒 、170GBを超えると160MB/秒 である。
インスタンス
概要
EC2は、1500MTUに加えてジャンボフレームをサポートする。
ルートデバイスがEBSの場合は、インスタンスタイプを変更することが可能 である。このときインスタンスIDは変更されない 。パブリックアドレスは変更される。インスタンスタイプを変更する場合は、インスタンスを一度停止する必要がある。
インスタンスのライフサイクル
インスタンスは、以下のライフサイクルで動作する。インスタンスがStopのときは課金されない。ただし、EBSボリュームに対する課金は継続される。時期やタイミングによっては、EC2のリソースが枯渇し新たなインスタンスが起動できない場合もある ので、リソースを確保しておきたい場合は、インスタンスを作成し、使用するまで停止しておくとよい。
インスタンスを再起動した場合は、同一ハードウェアで起動し、ボリュームやネットワーク設定等は前回起動の情報を保持 する。一方、インスタンスを一度停止し起動した場合は、別のハードウェアで起動し、これらの情報は引き継がれない 。ハードウェア障害が発生した場合など、明示的に別のハードウェアでインスタンスを起動する必要がある場合には、再起動ではなく停止と開始を行う 。
インスタンスの公開鍵
EC2に使用するSSHキーペアは、リージョンごとに別管理であるため、他のリージョンでEC2を使用する場合、通常は別途新たにキーペアを作成する必要がある。ただし、これでは管理する際に問題が生じるので、共通のキーペアで運用
インスタンスの時刻
デフォルトでは UTC（協定世界時間）時間帯に設定されている。他のタイムゾーンを設定する場合は、起動時に以下を実行する。
vi /etc/rc.local
ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
インスタンスの復旧
ハードウェア障害が発生した場合に、自動的に再起動を行うことが可能なCloudWatchアラームを作成することができる。復旧したインスタンスは、ボリュームやネットワーク設定等は前回起動の情報を保持 する。自動復旧は、1インスタンスにつき1日3回まで である。
また、AWSがインスタンスの再起動や停止/開始、メンテナンスを事前に予告して実施する場合がある。再起動には、自身でスケジューリング可能なインスタンスリブート と、強制的に再起動されてしまうシステムリブート がある。また、ネットワークや電源のメンテナンスが実施される場合もある。
インスタンスメタデータ
実行中のインスタンスのメタデータは、以下のURLから取得することが可能である。AMIのIDや、ホスト名、リージョン、ネットワーク設定、セキュリティグループ名などを取得 することができる。
https://169.254.169.254/latest/meta-data/
