AWSアソシエイト試験に向けて5(EC2関係）

EC2の特徴

端的に言うと従量課金制の仮想サーバーでPaaSよりのIaaSと言う感じでOSまで用意してくれるタイプのサービス。
OSはAMI(Amazon Machine Image)という形で提供され、AWSが用意してくれているものやマーケットプレイスで売られているものもある。
このAMIにOSの設定をしておいて保存しておくことでそのOSの再利用や複製が可能になる。
アーキテクチャはIntel。
→ つまり、IaaSであるがOSより上のレイヤーを利用する形のサービスになる(厳密にはPaaSになるのかもしれない)

AZに対してインスタンスとして設置することで利用できる。

インスタンスファミリー

EC2のインスタンスは用途に応じて様々な種類のインスタンスが用意されている。
起動時にインスタンスタイプを用途に応じて検索して、最初から指定して起動することもできる。
以下その例。

汎用

無料枠で使えるT2.microはここに入る。
Tがインスタンスファミリーのタイプ、2がその世代、nanoがサーバーの容量を示す。
このグループの特徴は

• バランスの取れたリソースが提供されるので、インスタンスのリソースを同じ割合で利用していくアプリケーションに適している

というところになる。
代表的なインスタンスファミリーはA1、M5、T3など。
ちなみにMacインスタンスもあるらしい(Mac Mini(i7、6コア12スレッド、RAM32GB))

コンピューティング最適化

汎用よりさらに性能の高いプロセッサを要求するアプリケーションに使っていくインスタンス。
主な用途は

• バッチ処理ワークロード
• メディアトランスコード
• 高性能なWebサーバー
• HPC(ハイパフォーマンスコンピューティング)
• 科学モデリング
• 専用ゲームサーバーおよび広告サーバーエンジン
• 機械学習推論

などが挙げられる。
代表的なインスタンスファミリーはC5、C6gなど。

メモリ最適化

メモリ内の大きいデータセットを処理するワークロードに対して、高速なパフォーマンスを期待したいときに使う。
代表的なインスタンスファミリーはX1、R5、ハイメモリ、z1dなど。

ストレージ最適化

ローカルストレージの大規模データセットに対して高いシーケンシャル読み取り(連続してデータにアクセスするタイプの読み出しのやり方、ファイルコピーとかはこのタイプ)及び書き込みアクセスを必要とするワークロードに最適。
つまり、ファイルの読み書きを頻繁にやる予定があるサーバーなどに向いている。
特徴として

• 数万IOPS(1秒あたりの実行可能なIOの数。IOは読み書き操作のこと)を低レイテンシー(遅延)で実行できる
• ランダムIOオペレーションに最適

ということが挙げられる。
プロビジョンドIOPSのEBSと併用するケースが多い。
代表的なインスタンスファミリーはH1、D2、I3、I3enなど。

高速コンピューティング

コンピューティング最適化のインスタンスと似ている感じがするが、こちらはハードウェアアクセラレーターの役割や演算処理の高速化、より高度な処理機能が求められる場合に用いるインスタンスのようだ。

• ブロックチェーンのノード(FPGA)
• 浮動小数点計算
• グラフィックス処理
• データパターン照合
• GPU的役割(G4)

といったことに使われる。
ドキュメントを見る限り、NVIDIAおよびAMDドライバーを使うこともできるので演算の並列処理やグラフィック処理を期待してもGPU機能としての役割を期待されて使用されるものと推測する。

インスタンスの購入方式

インスタンスは無料枠以上になると従量課金が基本だが予め用途や利用期間などが決まっていればそれに応じて割安で利用できる場合がある。
以下その例。

オンデマンドインスタンス

これが基本のインスタンスの課金方式。
無料枠を超えたら使ったら使った分だけ決まった料金を秒単位で払う。
その代わりインスタンスのライフサイクルはユーザーの自由になるので、起動から終了(インスタンスの削除)はもちろん一時停止、休止、再起動……までユーザーが裁量を持てる。
ただし、インスタンスは終了しないと利用しているとみなされ課金対象になるので注意。

リザーブドインスタンス

1年または3年の利用期間を先に押さえておくことでその分割引価格で利用できる。
上記の期間のみ利用、または長期間の利用が想定される場合は当然こちらの利用方法のがベター。
また災害対策などのキャパシティ予約が可能庵アプリケーションもこちらのインスタンスがベター。
特定のAZかまたはリージョン内で押さえるか2パターンの利用方法がある。
また注意する点として以下の点が挙げられる。

• 利用方法としてスタンダードかコンバーティブルという2つのプランが有る
• それぞれ1年(ST……40％引き/Co……31%引き)と3年(ST……60％引き/Co……54%引き)単位でインスタンスを押さえることができる
• スタンダードの場合はインスタンスファミリー・OS・テナンシー・支払いオプションの4点の変更ができない
• AZ・インスタンスサイズ・ネットワークタイプの変更はどちらも可能
• コンバーティブルはリザーブドインスタンスマーケットプレイス(押さえた期間より早く利用停止する場合、残りの期間を売ることができるマーケット)で2021/4現在では販売できない。

リザーブドインスタンスとSavings Plans

1年間にわたり毎日・毎週・毎月……と決まった開始時間及び期間でインスタンスを押さえておくという利用方式。
例えば毎週木曜の21時から5時間だけメンテナンス及びバッチ処理の適用のためのアプリケーションを動かしたいという利用形態であるならこの利用方法を選択するのがベター。
Savings Plansは以下の2つのプランがある。

Compute Savings Plans

FargateとLambdaもセットになったプラン

EC2 Instance Savings Plans

EC2インスタンスのみのプラン

リザーブドインスタンスとSavings Plansとの違い

• Savings Plansは1時間あたりの利用料をユーザーが指定し、稼働しているインスタンスの合計金額に割引になる

• 適用サービスが違う(リザーブドインスタンスのStandardはEC2の他にRDS、Redshift、ElasticCache、Elasticsearch Serviceが適用範囲、Compute Savings PlansはEC2以外にはFargate、Lambdaが適用範囲)

• Savings Plansはリザーブドインスタンスに比べて割高であるが、AZ、インスタンスタイプの指定が不要でCompute Savings Plansであればリージョンとインスタンスファミリーも指定がいらないので柔軟性がある。(リザーブドインスタンスはConvertibleでもAZの変更はできない)

キャパシティの予約

リザーブドインスタンスやSavings Plansとは違い、インスタンスではなくインスタンスを作るスペースだけを押さえる。
これはインスタンスを大量に作る際(フリート機能などで)にスペーズの調達が間に合わずにエラーになってしまうことがあるため、大量にインスタンスを作ることがわかっている場合はインスタンスタイプ・プラットフォーム・AZ・テナンシー・インスタンス数を入力してスペースだけ予約しておくというサービスになる。
以下のように設定できる。

スポットインスタンス

こちらはAWSが予め管理用に保持しているリソースをAWSが利用していない分だけユーザーに間借りさせてくれる利用方式。
大幅な割引(最大90％引き)で利用できるものの、AWSがそのリソースを利用するとなった場合問答無用で利用を中断させられるデメリットがある。
永続的リクエスト(押さえていたスポットインスタンスがAWSに差し押さえられたとき、別のスポットインスタンスを代わりに自動でリクエストする)やスポットブロック(割増になる代わりに1～6時間の内指定した時間内はインスタンスが中断されなくなる)である程度リスケはできる仕組みはあるものの基本的には実行時間に柔軟性があることが前提のインスタンスの利用方法となる。
リクエストするには以下のようにインスタンスの起動時にオプションで設定するか、スポットリクエストから直接リクエストするかの2択になる。

またスポットインスタンスを削除する際にはスポットリクエストをキャンセルする、インスタンス自体を削除してもリクエストが残っていると復活する。

インスタンスに対して物理的な対応がしたい

要件や案件、または社内規範等でインスタンスを物理的に分離しないといけないという事案が発生することがある。
そういう条件の場合に用いるインスタンスの利用方式(もちろん追加費用がかかる)。
なお、Dedicated InstanceとDedicated Hostのことをテナンシーと呼ぶことがあり、EC2インスタンスの起動設定のオプションのところに設定項目がある。

ハードウェア専有インスタンス(Dedicated Instance)

専用のハードウェアのVPCで実行されるインスタンス。
通常のインスタンスは仮想サーバー内ではそもそもAZやVPCなどでユーザーの使用領域ごとに分割されているので一見、それぞれのインスタンスは分離されているように見えるが、ハードウェア的には仮想サーバーを展開している物理サーバーは他のAWSインスタンスと共有してしまっている。
このインスタンスはホストハードウェア、つまり仮想サーバーを展開している物理サーバーの段階から他のAWSアカウントと分離したいという要件で使えるインスタンスとなる。
但し、同じAWSアカウントとはハードウェアを共有する必要があることだけ注意(つまり、当該インスタンスを完全に分離する目的としては使えない)

Dedicated Host

こちらはDedicated Instanceよりさらに踏み込んだインスタンスの分離方法で同じAWSアカウント(IAMユーザーやグループ)とも物理的なサーバーを共有しない形で仮想サーバーを展開し、EC2インスタンス容量を当該IAMユーザー(またグループ)が完全に占用できる形でインスタンスを作成できる。
サーバーにバインドされた既存のソフトウェアライセンスを使用したい場合はこれを選ぶ。
これはオンプレ環境からAWS環境へ移行を検討している際に、オンプレ環境側でライセンスが付与されたソフトウェアを使っている……といったときにAWS側で対応していればそのまま移行できるよというユースケース。
以下のように設定できる。

Bare Metal

物理的なサーバーに対して直接オンデマンドでアクセスできる仕組み。
アプリケーションが基盤となるサーバーのプロセッサーとメモリに直接アクセスができるインスタンスを作ることができる。
つまり、通常のインスタンスではOSの選択とそれより上のレイヤーのコントロール(仮想サーバー内の領域のコントロール)までしかできなかったところを、仮想サーバーを展開している物理ハードウェアレベルまでコントロールできるようになったインスタンス利用形式ということになる。

EC2のストレージ

AWSのストレージとしてはS3やCloud watchがあるが、EC2が直接利用するストレージというものもある。
以下の2種。

インスタンスストア

ホストコンピュータ内蔵のディスクでEC2と不可分になっているブロックレベルの物理ストレージ。
EC2に関する一時的なデータの保存場所であり、停止または終了でクリアされる。
なので主な役割としてはインスタンスの休止からの再起動の際にデータを保持しておくというところになる。

Elastic Block Storage

通称EBS。
EC2内で用いられるブロックレベルのストレージでネットワークで接続されている。
特徴としては

-ネットワークで接続されたブロックレベルのストレージでEC2とは独立して管理されている。(ただしAMIイメージにはSnapshotとともに含まれる)

• 上記の特性上、EC2インスタンスを削除してもEBSボリュームは保持することができる

• デフォルトではルートボリュームがEBSの場合はインスタンス削除と同時にEBSも削除

• バックアップの形としてSnapshotが存在する

• ボリュームデータはデフォルトでAZ内の複数のハードウェアにレプリケートされていて、冗長化が不要

• セキュリティグループでアクセスを制御できない(=ポートが通ってなくてもEBS自体は利用可能)

• データは永続的に保持される

• インスタンスで使用するOSTやアプリケーション、データの置き場……etcと使いみちは様々

• サイズは1GB~16TBまでで指定する

• ほぼ100％の可用性を持つ

• AZ内に紐付くので他のAZからは利用できない(ただし、Snapshotを経由してコピーは可能)

• インスタンスへの付け替えは自由にできる(同じAZ内)

• 複数のEBSを1つのインスタンスに紐つける事はできるが、複数のインスタンスに同じEBSを紐つけることはできない

• ただし、プロビジョンドIOPSのEBSのみは複数のインスタンスで共有できる(ストレージ最適化インスタンスでビックデータを扱う場合、複数インスタンスで共有した方がいいケースがあるから)

• 無料枠を超えると有料であり、サイズと利用機関で課金される

ということが挙げられる。
さらにインスタンスと同じくユースケースによって性能やコストが異なる。

汎用SSD

1番シンプルなやつで無料枠では実質的にこれしか使えない。
サイズは1~16TBでユースケースは

• 仮想デスクトップ
• 低レイテンシーを要求するアプリ
• 小中規模のDB
• 開発環境

プロビジョンドIOPS

高IOPSを要求される場面ではこのタイプのストレージを選択する。
主な例としてはストレージ最適化インスタンスと一緒に使ってビックデータを扱う場合など。
サイズは4~16TBでその他のユースケースは

• 高IOPSを要求されるDB、NoSQLDB、アプリ(つまり高速で読み書きする必要があり、かつ頻繁なアクセスを要求するもの)

• NitroシステムやAmazon EC2インスタンス、EBS最適化インスタンス等で高速化を図りたい

スループット最適化HDD

用途的にはプロビジョンドIOPSの廉価版である(ただしSSDではなくHDD)。
ルート(インスタンスのブートボリューム)ボリュームとしては使えない。
サイズは500~16TBでありユースケースとしては

• ビッグデータ
• DWH
• 大規模なETL処理やログ分析

コールドHDD

アクセス頻度が低いデータ、あるいはS3を使うところでそれを使用せずにバックアップ等取りたいときに使う。
サイズは500~16TBでありユースケースとしては

• ログデータ
• バックアップ、アーカイブ

Magnetic

一応無料枠だが基本的には利用しない。
サイズは1GB~1TBでデータへのアクセス頻度が低いワークロードで使う。

Snapshot

EBSをバックアップする機能。
特徴としては

• フルボリュームでバックアップした以降は増分形式でバックアップされる

• フルボリューム(1世代目)を削除しても復元は可能

• S3に保存される(故に無料枠を超えたら課金対象)

• 作成時にブロックレベルで圧縮して保管するため、圧縮後の容量に対して課金が行われる

• 作成時には静止点を作ることが推奨されている(つまりデータの整合性が取れるような状態を作る)が、作成自体はEBS使用中でも実行可能

• 保存期間や世代数は無制限(なので管理を怠ると無駄な課金が発生する)

• 世代管理が必要な場合はAWS CLIやAPI等で自動化を図る

• DLMを利用してスケジューリングできる

• 別アカウントに対しても権限を移譲することでSnapshotからEBSを複製できる

という点が挙げられる。

AMIとSnapshotの違い

Snapshotはストレージ/EBSのその時点での断面のバックアップとして保持し、ストレージの復元・複製に使用するがAMIはEC2インスタンス自体をイメージとしてOS設定などともにEBSやSnapshotまで含めてイメージとして保持している。
要するにインスタンス丸ごとバックアップするかストレージ/EBSをバックアップしているのかという違い。

EBS作成

実際に作る場合は以下のように作る。

• ボリュームタイプ
• 利用するサイズ

この2つの指定でIOPSが決まる。
あとは

• AZ
• スナップショットID(Snapshotから作成する場合)
• 暗号化

の3点を指定する。
暗号化はキーペアとは別でKMSキーが作られて管理される。

作成が終わると以下のようにアタッチをしたり、Snapshotを作ることができる。

Snapshotあれこれ

スナップショットの作成画面は以下の通り。

作られたことが確認できる

活用方法としては壊れたルートボリュームの代わりに、バックアップから復元したルートボリュームを再アタッチしたいというケースが考えられる。
外付けのように使う場合はアタッチの際に任意のディレクトリを指定すればその領域が新たなボリュームとして機能するが、置き換えの場合は元のディレクトリを正しく指定しないといけない。
その場合はボリュームのディレクトリを以下のように確認しておくことが大切である。

あとは

• 作業するインスタンスを停止
• 元のルートボリュームをデタッチ
• ディレクトリを指定して復元したルートボリュームをアタッチ

としてやればいい。

DLM(データライフサイクルマネージャー)

Snapshotの管理を自動化してくれる機能。

ポリシータイプでどうバックアップを取るのか決める。
EBSスナップショットポリシーであるなら単純にSnapshotのバックアップのポリシー、EBS-based AMIポリシーであるならEBSをルートボリュームにしているインスタンスに対してAMIイメージを取得するというアクションに対してのポリシーということになる。
アカウント間コピーのイベントポリシーはSnapshotをアカウント間でやり取りしてそこからEBSを複製する場合に対するポリシー。
次にリソースタイプでインスタンスに紐ついているEBSのSnapshotなのか、それともボリューム自体なのかを指定する。
例えばボリュームを指定するとボリュームについてるタグから任意のボリュームを指定できる。
複数指定することも可能。
IAMロールはDLMを実行する上での権限が必要になるのでそのためのロールを作る部分。
自分で作ることもできるし、AWSに作ってもらうこともできる。
スケジュールはSnapshotの管理スケジュールを設定する部分になる。
静止点であろう時間に設定しておくのが推奨される。

高速スナップショットはプロビジョンドIOPS用途の場合選択する部分。

クロスリージョンはDLMを利用してSnapshotのコピーを複数のリージョンにも同時に作成するという機能。

クロスアカウント機能はこのDLMで作られたSnapshotをアカウント間で共有するかの設定。
アカウントIDでやり取りする。

以上を設定するとSnapshotの管理を自動化できる。
例えば自動で取得したSnapshotは10日おきに削除される……といったこともできる。

EC2におけるアーキテクチャパターン

作成したEC2インスタンスはApacheのようなWebサーバー(アプリケーションサーバー)にもMySQLを入れてデーターベースサーバーにもできる。
問題はその構成をどうするかという点でユースケースは大きく3つに分かれる。

一つのAZかつ1つのインスタンスに両方配置する

• 冗長性なし
• シンプルかつそんなに大したページアプリケーションではない場合に向く
• 手軽

一つのAZに2つインスタンスを作り、プライベートサブネットにMySQLサーバーを置く

• レイヤーがわかれているので保守性が上がる
• DBサーバーはプライベートサブネットにおけるので安全性が上がる
• アンマネージド型なのでOS設定と物理サーバー管理以外はすべてユーザーが行う

一つのAZに2つインスタンスを作り、プライベートサブネットにRDSのMySQLを置く

• MySQLサーバーをプライベートサブネットに置く場合と比べて、インスタンスが情報を持たないのでより冗長性があがる
• マネージド型なので物理サーバー管理、OS設定、メンテナンス、バックアップ、スケーリングまでAWSが用意してくれている

EC2インスタンスの起動あれこれ

接続方法

セキュリティグループにもよるが、公開鍵認証方式を使ってSSH経由でアクセスし操作することが多い。
EC2インスタンスの作成時にキーペアという形式で作成される。
.pemファイルで秘密鍵が作られ、次回以降のインスタンスで使い回すことができる(同じ鍵穴の形をした南京錠をかけるイメージ)。
ただし、例えばリージョンを変えてインスタンスを作る場合など使い回さず新規に.pemファイルを作成することが良いこともある。

以下のようにインスタンスを作成後に接続に必要な情報を確認することもできるが、
基本的にはssh -i ".pemへのディレクトリパス" ec2-user@IPアドレスというsshコマンドで接続していく。
なお、ec2-userの部分はAMI(OS)イメージによって変化し、IPアドレスは動的なものを避けた方が好ましい(ex. インスタンス間の連携にIPアドレスを使う)場合はElastic IPアドレスを関連付けて代わりに指定するようにする。

ユーザーデータの活用

インスタンスは基本的に作成したら管理権限でyum update -yをかけてインスタンスを更新したり、例えばWebサーバーならApache、DBサーバーならMySQLライブラリをインストールしないといけない等々作業が必要になる。
こういった初期設定の作業を自動化をインスタンスを作る際に以下のように設定することができる。

具体的には以下のようなコマンド。

# !/bin/bash
# サーバーの設定変更(インスタンスのユーザー名(ec2-userの部分)の変更)
sed -i 's/^HOSTNAME=[a-zA-Z0-9\.\-]*$/HOSTNAME=udemy-bash/g' /etc/sysconfig/network
hostname 'udemy-bash'
cp /usr/share/zoneinfo/Japan /etc/localtime
sed -i 's|^ZONE=[a-zA-Z0-9\.\-\"]*$|ZONE="Asia/Tokyo"|g' /etc/sysconfig/clock
echo "LANG=ja_JP.UTF-8" > /etc/sysconfig/i18n
# Apacheのインストール
sudo yum update -y
sudo yum install httpd -y
# Apacheのディレクトリへ移動
sudo cd /var/www/html
# Apache起動
systemctl start httpd
# 以後インスタンスが起動する度に自動でApache起動
systemctl enable httpd
====

これで自動的にApacheがインストールされ、ec2-userの代わりにudemyというホスト名がついたインスタンスが作られる。
MySQLの場合はApacheの部分が以下のコマンドとなる。

yum localinstall https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm -y

yum install mysql-community-server -y

systemctl start mysqld

systemctl enable mysqld

使いたいインスタンスタイプが決まっている場合

以下のように直接インスタンスタイプを検索してそこから起動ウィザードへ入ることができる。

起動テンプレートを作る

ユーザーデータはインスタンスの初期設定であったが、こちらはそもそもインスタンスの起動からテンプレートにして使い回したいときに使える機能。
AMIからインスタンスタイプ……etcと起動ウィザードで設定する項目を指定して作れば次回から同じものはこのテンプレートから作成できる。

フリート

フリートは複数のインスタンスを1つのグループ(フリート)としてまとめて管理するもの。
スポットインスタンスで例を見てみる。

まず、スポットリクエストから普通に作っていく。

ここでフリートを構成するインスタンス数とインスタンスの中断処理、インスタンスのコスト設定を行う。
スポットインスタンス中断時に別のインスタンスをリクエストして続行したい場合はキャパシティーの再調整にチェックを入れる。

ここでフリートの設定。
推奨事項の欄にチェックを入れればAWS側がおすすめの選択してくれるが以下のように自分で任意のインスタンスタイプを選択した上でAWSにその範疇で配分してもらうこともできる。
ここで重要なのがフリートの強度が十分であるかどうかで、ここで不足していると出てる場合はインスタンスタイプの組み合わせを変える必要がある。
なお、指定できるインスタンスは最小コンピュートユニットで指定したインスタンスタイプなどで変わる(最小コンピュートユニットをt2.microで指定した場合はt2.small、t2.micro、m1.small、m1.medium、m3.mediumしか指定できない。)
フリートの配分戦略の部分がAWSがフリートリクエストで指定されたインスタンスタイプからスポットインスタンスのリクエストを満たしていくかの基準となる部分。

あとは設定を確認して作成すればOK。

AMI

AMI(Amazon Machine Image)はOSイメージのこと。
OSイメージとはなにかというと仮想サーバー上で展開するOSの種類・設定・サーバーの構成情報・ルートボリュームに構成されたEBS、インスタンスのデータ……etcのことになる。
つまり、これまで起動ウィザードで作ってきたインスタンスのバックアップ的な存在でもありかつ起動ウィザードでこれまでAMIを選択してきたのはその点から見るとインスタンスの初期化を行っていたとも考えられる。
なので、作成したインスタンスからAMIを作っておけば同じインスタンスをそのAMIから複製することができる。
これを利用して東京リージョンで作ったインスタンスをAMIにして、別のリージョンにそのAMIをコピーしてインスタンスを作る……ということもできる。
実際には以下のようにしてAMIを作ることができる。

特徴としては

• AMIはリージョンで一意である(ただし上記のようにリージョンを跨いだAMIのコピーは可能)

• AWS提供のものと自作のインスタンスから作成したものの他に、サードパーティ製のものがマーケットプレイスで売られている

• サーバーのOSとしての選択肢であり、かつ利用していたサーバーのバックアップでもある

• EC2インスタンスのバックアップでもあるため、EBSボリュームのスナップショットも内包されるためEBSのバックアップであるとも言える

• 利用するにあたって最適なEC2インスタンスの構成(ゴールデンイメージ)がある場合、それをAMIイメージとしてバックアップを取ることで使い回すことができる

• 共有ができる(AWSアカウントID経由で共有する)

• EC2ImageBuilderを使って更新管理を自動化できる(後述)

という点が挙げられる。

EC2 Image Builder

EC2 Image Builder は、AWS またはオンプレミスで使用するための仮想マシンとコンテナイメージの構築、テスト、およびデプロイを簡素化します。

作成したAMIイメージのバージョン管理を自動で行ってくれるサービス。
スケジュールを設定しておけば、AMIイメージ内のソフトウェアの更新に際してテストを実行し問題なければ更新を行ってくれる。
Docker的に考えるとコンテナに引っ張ってきたイメージに更新があった場合、自動で構築をテストして更新してデプロイしてくれる……ということなのだろうか。
ともあれ自動更新がまずいという状況を除けば、保守の部分がかなり楽になるのは間違いないと感じる。

利点は以下のようなことが挙げられている。

• イメージの更新・テスト・デプロイを自動化してくれる(この自動化のフローのことをパイプラインと呼ぶ)

• セキュリティリスクの低下(セキュリティパッチを自動で適用してくれる)

• 最新の仮想マシンとコンテナイメージを構築、保護、テストするためのワンストップショップが提供される(公式より)

• 本番環境に適用する前にAWS提供あるいはユーザー作成のテストでイメージの機能・互換性、セキュリティ・コンプライアンスを検証することを手助けしてくれる(ex. テストに通らなければデプロイはされない)

• AMIイメージをバージョン管理することができる

• AWS Resource Access Manager、AWS Organizations、Amazon ECRとの統合でAWSアカウント全体でEC2 Image Builderにおける自動化スクリプト、レシピ、AMIイメージの共有を行える

実際には以下のように作成する。

まずはパイプラインを作る。
ここではスケジュールリング部分を設定していく。
拡張メタデータ収集の欄にはチェックを入れるのがベター。
あとはスケジュールを決めるだけ。
依存関係の更新をトリガーとしてパイプラインは実行されるが、それを指定したスケジュールで確認して行うか、依存関係の更新が確認できたらスケジュールの週日部分を無視して、指定されている時間で実行するか選択できる。

次はレシピを作る。
以下をみればわかるがAMIの他にDockerイメージとしても作ることができる。

次にソースのイメージを選択する。
自作のAMIイメージがある場合は画像の通り指定する。
もし、1から作る場合はOSを選択することになる。

次にビルドコンポーネントを設定する。
ビルドコンポーネントはそのAMIを生成するために必要となるコンポーネント。
例えば、Apacheを入れてWebサーバーとしていたインスタンスをAMI化し、それをEC2 Image Builderで管理しようという事になった場合にはここでApacheを検索して選択しておかないといけない。

テストコンポーネントはイメージをビルドするときに実行するテストを選択できる。
以下のようにAWS提供のものもあれば、ユーザー自身で作成することもできる。

次はインフラストラクチャの設定。
ビルドをする際のテストに関わる部分。
パイプライン実行時にEC2インスタンスを自動で立ち上げてその中でテストを行うという仕組みになるので、そのEC2インスタンスの構成(それ故にインフラストラクチャ)をここで決めることができる。
自分で作ることもできるし、デフォルトで良ければAWSが勝手に作ってくれる。

ディストリビューションの設定。
テストで問題なければAMIイメージはビルド(デプロイ)されることになるので、その際に暗号化はするのか？ 起動許可はどうするのか？ ビルドじたAMIイメージはどのアカウントなら起動できるのか……といったセキュリティに関する部分を設定できる。

問題なければ以下のようにパイプラインが作成され、アクションから手動で実行もできる。
実行するとインスタンスが立ち上がって一連の処理が行われ、バージョンが割り振られたイメージが新しく作られる。

プレイスメントグループ

複数のインスタンスを論理的にグループ化して、パフォーマンスの向上や耐障害性の向上を図る機能。
3つのグループパターンがあるがそれぞれ構成するにあたって使えるインスタンスタイプが決まっている。

例えばクラスタープレイスメントグループの場合は

汎用……A1、M4、M5、M5a、M5ab、M5d、M5dn、M5n
コンピューティング最適化……C3、C4、C5、C5d、C5n、cc2.8xlarge
メモリ最適化……cr1.8large、R3、R4、R5、R5a、R5ad、R5d、R5dn、R5n、X1
ストレージ最適化……D2、H1、hs1.8large、I2、I3、I3en
高速コンピューティング……F1、G2、G3、G4dn、P2、P3、P3dn

以上のインスタンスタイプでしか構成できない。
なお実際に構成する場合はグループを作っておき、インスタンスを新しく作る際にそのグループに入れるように指定をすることで構成していく。

クラスタープレイスメントグループ

単一AZかつ単一パーティション内に複数のインスタンスを構成する。
特徴としては

• 単一AZ内のインスタンスを論理的にグループ化した構成

• 同じリージョン内の複数のピアVPCにまたがることも可能(VPC Peeringで連携されているVPC間)

• グループ内のインスタンスは、TCP/IPトラフィックのフローあたりのスループット(コンピュータシステムが単位時間に実行できる処理の件数や、通信回線の単位時間あたりの実効伝送量など)上限が高くなり、ネットワークの二分帯域幅の広い同じセグメントに配置され、インスタンス間通信が向上する

• 低ネットワークレイテンシー、高いネットワークスループットを実現するアプリ向け

というものがある。

パーティションプレイスメントグループ

クラスタープレイスメントグループ複数から構成されるグループ。
特徴としては

• 障害に対応するために構成するグループ

• パーティションで論理的なセグメントとしてクラスタープレイスメントグループが分割される

• プレイスメントグループ内の各パーティションにそれぞれ一連のラック(サーバーを入れる箱みたいなもの)があり、プレイスメントグループ内のパーティション同士は同じラックを共有しない。

• ラックを分離することでアプリケーション内のハードウェア障害による影響を隔離して軽減する

というものがある。

スプレットプレイスメントグループ

単一AZかつ単一パーティション内に1つのインスタンスを構成したものを並列に複数並べたもの。
特徴として

• それぞれに独自のネットワークおよび電源が異なるラックに別々にインスタンスが配置される

• つまり、インスタンスそれぞれが完全に分離される形になる

• 例として1つのAZ内の当該グループに配置された7つのインスタンスは、、7つの異なるラックに配置されることになる

• 少数の重要なインスタンスを互いに分離して保持できるので、同時障害のリスクを軽減することができる

というものがある。