Amazon EC2＠AWSリソース¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. Amazon EC2：Elastic Compute Cloud¶
Amazon EC2とは¶
クラウドサーバーとして働く。
注意点があるものだけまとめる。
ベストプラクティスについては、以下のリンクを参考にせよ。
01-02. セットアップ¶
コンソール画面の場合¶
▼ 設定項目と説明¶
| 設定項目 | 説明 | 補足 |
|---|---|---|
| AWS AMI：Amazonマシンイメージ | AWS AMIを選択する。 | |
| インスタンスタイプ | ||
| Amazon EC2の数 | ||
| ネットワーク | ||
| サブネット | Amazon EC2を配置するサブネットを設定する。 | |
| 自動割り当てIPアドレス | Amazon EC2へのパブリックIPアドレスの割り当てを有効化する。 | Amazon EC2作成後に有効にできない。 |
| キャパシティの予約 | ||
| ドメイン結合ディレクトリ | ||
| AWS IAMロール | Amazon EC2に付与するAWS IAMロールを設定する。 | |
| シャットダウン動作 | ||
| 終了保護 | Amazon EC2の削除を防ぐ。 | 必ず有効化すること。 |
| モニタリング | ||
| テナンシー | ||
| Elastic Inference | ||
| クレジット仕様 | ||
| ストレージ | Amazon EC2のストレージを設定する。 | |
| キーペア | SSH公開鍵認証のため、Amazon EC2の秘密鍵とペアになる公開鍵をインストールできる。 | ・AWS SSM Session Managerを使用してAmazon EC2に接続する場合は、キーペアの作成は不要である。 ・キーペアは、Amazon EC2の最初の作成時しか作成できず、後から作成できない。 ・キーペアに割り当てられるフィンガープリント値を調べることにより、公開鍵と秘密鍵の対応関係を調べられる。 |
ダウンタイム¶
▼ ダウンタイムの発生条件¶
以下の条件のとき、Amazon EC2 にダウンタイムが発生する。
Amazon EC2 を冗長化している場合は、ユーザーに影響を与えずに対処できる。
ダウンタイムが発生するほうのインスタンスを事前に ALB のターゲットグループから解除しておき、停止したインスタンスが起動した後に、ターゲットグループに再登録する。
| 変更する項目 | ダウンタイムの有無 | 補足 |
|---|---|---|
| インスタンスタイプ | あり | インスタンスタイプを変更するためにはAmazon EC2を停止する必要がある。そのため、ダウンタイムが発生する。 |
| ホスト物理サーバーのリタイアメント | あり | AWSから定期的にリタイアメントに関する警告メールが届く。ルートデバイスタイプが『AWS EBS』の場合、ホスト物理サーバーの引っ越しを実行するためにAmazon EC2の停止と起動が必要である。そのため、ダウンタイムが発生する。注意点として、再起動では引っ越しできない。 |
インスタンスタイプ¶
▼ 要素¶
インスタンス世代の数字が上がるにつれて、より小さなインスタンス世代と同じ大きさであっても、性能が上がり、金銭的コストが下がる。
<ファミリー><世代><追加機能>.<サイズ>(例: c5d.xlarge) |
説明 | 例 |
|---|---|---|
| インスタンスファミリー | 適するアプリケーションのドメインやハードウェアの種類を表す。 | t,a など |
| インスタンス世代 | 同じインスタンスファミリー内での新しさを表す。 | 2、3、4 など |
| 属性 | CPUの種類を表す。 | a (AMD CPU)、g (Graviton CPU) 、i(Intel CPU) など |
| インスタンスサイズ | インスタンスのハードウェアリソースの大きさを表す。 | nano、small、medium、large、xlarge、2xlarge など |
AWS AMI の OS のバージョンによっては、新しく登場したインスタンスタイプを適用できないことがあるため注意する。
例えば、CentOS 6 系の AWS AMI では、t3.small を選択できない。
▼ CPUバーストモード¶
バーストモードのインスタンスタイプの場合、一定水準のベースライン CPU 使用率を提供しつつ、これを超過できる。
CPU 使用率がベースラインを超えたとき、超過した分だけ Amazon EC2 は CPU クレジットを消費する。
CPU クレジットは一定の割合で回復する。
蓄積できる最大 CPU クレジット、クレジットの回復率、ベースライン CPU 使用率は、インスタンスタイプによって異なる。
詳しくは以下のリンクを参考にせよ。
▼ アプリケーションのドメインに合わせたインスタンスタイプ¶
| アプリケーションのドメイン例 | ドメインの特長 | ファミリー | 世代 | インスタンスサイズ | おすすめ |
|---|---|---|---|---|---|
| ほとんどのアプリケーションサーバー | いろいろ | M 系 |
世代数は大きいほど高性能で値段も安い。そのため、その時点で一番新しい世代を選ぶ。 | サイズが一つ大きくなると、ハードウェアリソーススペックと料金が 2 倍になる。ネットワーク帯域はあまり変わらない。アプリケーションが必要とするサイズを選ぶ。 |
★ |
| ハードウェアリソース要求がスパイクするような、ほとんどのアプリケーションサーバー | スパイク系 | T 系 |
同上 | 同上 | ★★ |
| Webサーバー、HPC、バッチ処理、広告配信、動画エンコーディング、ゲームサーバー、モデリング、分散分析 | CPU消費系 | C 系 |
同上 | 同上 | |
| NoSQL、インメモリDB、データウェアハウス | ストレージI/O消費系 | H 系 |
同上 | 同上 | |
| NoSQL、インメモリDB、データウェアハウス | ストレージI/O消費系 | I 系 |
同上 | 同上 | |
| 高性能DBサーバー、キャッシュサーバー、ビッグデータ処理 | メモリ消費系 | R 系 |
同上 | 同上 | |
| 高性能DBサーバー、キャッシュサーバー、ビッグデータ処理 | メモリ消費系 | X 系 |
同上 | 同上 | |
| 高性能DBサーバー、キャッシュサーバー、ビッグデータ処理 | メモリ消費系 | ハイメモリ | 同上 | 同上 | |
| 高性能DBサーバー、キャッシュサーバー、ビッグデータ処理 | メモリ消費系 | Z 系 |
同上 | 同上 | |
| 3Dレンダリング、動画、ゲーム | GPU消費系 | G 系 |
同上 | 同上 | |
| 機械学習、深層学習、HPC | GPU消費系 | P 系 |
同上 | 同上 | |
| ゲノム分析、リスク計算、リアルタイムビデオ処理 | FPGA消費系 | F 系 |
同上 | 同上 |
- https://pages.awscloud.com/rs/112-TZM-766/images/20210603-Instance_Choice_and_Graviton2.pdf#page=12
- https://pages.awscloud.com/rs/112-TZM-766/images/C2-07.pdf#page=16
- https://pages.awscloud.com/rs/112-TZM-766/images/C2-07.pdf#page=22
- https://aws.amazon.com/jp/ec2/instance-types/
- https://techblog.forgevision.com/entry/aws-ec2-instance-bgr
- https://biz.nuro.jp/column/aws-mama-022/
▼ ファミリーに応じたスペック範囲¶
| ファミリー | CPU数 | メモリ数 |
|---|---|---|
| A1 | 1-16 | 2-32 |
| T3 | 2-8 | 0.5-32 |
| T3a | 2-8 | 0.5-32 |
| M5 | 2-96 | 8-384 |
| M5d | 2-96 | 8-384 |
| M5a | 2-96 | 8-384 |
| C5 | 2-72 | 4-144 |
| C5d | 2-72 | 4-144 |
| C5n | 2-72 | 5.25-192 |
| H1 | 8-64 | 32-256 |
| I3 | 2-64 | 15.25-488 |
| I3en | 2-96 | 16-768 |
ルートデバイスボリューム¶
▼ ルートデバイスボリュームとは¶
Amazon EC2 では、ブロックデバイスにルートデバイスボリュームが紐づいている。
複数のブロックデバイスを用意し、それぞれを異なるルートデバイスボリュームから紐付けることもできる。
加えて、このブロックデバイスが、マウントポイントになるディレクトリ紐づいている。
つまり Amazon EC2 が作成されると、ボリューム内に保管したファイルは、ブロックデバイスを経由して、マウントポイントのディレクトリ内に作成される。
また反対に、マウント先ディレクトリ内に保管したファイルは、ルートデバイスボリューム内に保管される。
複数のルートボリュームを紐付ける場合は、最大サイズの大きなルートボリュームに紐づくルートデバイスを、サイズが大きくなり得るディレクトリへマウントするようにしておく。
▼ AWS EBSボリューム¶
名前がややこしいが、Amazon EC2 における仮想ストレージに相当し、仮想ボリュームではない。
AWS EBS で保管されているルートデバイスボリュームで、推奨の方法である。
インスタンスストアボリュームとは異なり、コンピューティングとして動作する Amazon EC2 と、ストレージとして動作するルートデバイスボリュームが分離されている。
そのため、Amazon EC2 が誤って削除されてしまったとしても、ボリュームは削除されずに、データを守れる。
また、両者が分離されていないインスタンスボリュームと比較して、再起動が早いため、再起動に伴うダウンタイムが短い。
▼ インスタンスストアボリューム¶
名前がややこしいが、Amazon EC2 における仮想ストレージに相当し、仮想ボリュームではない。
インスタンスストアで保管されているルートデバイスボリュームで、非推奨の方法である。
AWS EBS ボリュームとは異なり、コンピューティングとして動作する Amazon EC2 内にルートデバイスボリュームが存在している。
そのため、インスタンスストアボリュームは、Amazon EC2 を削除すると一緒に削除されてしまう。
Amazon EC2のライフサイクルフェーズ¶
Amazon EC2 のライフサイクルにはフェーズがある。
| フェーズ名 | 説明 |
|---|---|
| pending | インスタンスを開始する前に必要な準備があり、これが完了していない。 |
| running | インスタンスの起動が完了し、実行中である。 |
| stopping | インスタンスを停止している途中である。 |
| stopped | インスタンスの停止が完了した。 |
| shutting-down | インスタンスを削除している途中である。 |
| terminated | インスタンスの削除が完了した。 |
Amazon EC2への接続¶
▼ キーペアを使用したSSH公開鍵認証¶
キーペアのうちの秘密鍵を使用して、対応する公開鍵を持つ Amazon EC2 に SSH 公開鍵認証でリクエストできる。
クライアントの SSH のパケットは、まずインターネットを経由して、Internet Gateway を通過する。
その後、Amazon Route 53、ALB を経由せず、そのまま Amazon EC2 へ向かう。
キーペア¶
▼ フィンガープリント値¶
ローカルマシンに配置されている秘密鍵が、該当する Amazon EC2 に配置されている公開鍵とペアなのか否かを、フィンガープリント値を照合して確認する方法
$ openssl pkcs8 \
-in <秘密鍵名>.pem \
-inform PEM \
-outform DER \
-topk8 \
-nocrypt \
| openssl sha1 -c
ユーザーデータファイル¶
▼ ユーザーデータファイルとは¶
Amazon EC2 の起動時に任意のコマンドを実行できるようにする。
▼ 実行タイミング¶
ユーザーデータの実行タイミングは、cloud-config.service ファイルで設定している。
ネットワークがオンラインになった後、実行する。
つまり、Amazon EC2 のプロセスに関する設定 (systemd など) の後に、ユーザーデータを実行する。
# /usr/lib/systemd/system/cloud-config.serviceファイル
[Unit]
Description=Apply the settings specified in cloud-config
# ネットワークがオンラインになった後に実行する
After=network-online.target cloud-config.target
Wants=network-online.target cloud-config.target
ConditionPathExists=!/etc/cloud/cloud-init.disabled
ConditionKernelCommandLine=!cloud-init=disabled
[Service]
Type=oneshot
ExecStart=/usr/bin/cloud-init modules --mode=config
RemainAfterExit=yes
TimeoutSec=0
# Output needs to appear in instance console output
StandardOutput=journal+console
[Install]
WantedBy=multi-user.target
02. Amazon EC2 based on AWS AMI：Amazon Machine Image¶
AWS AMIとは¶
Amazon EC2 のマシンイメージであり、Amazon EC2 の完全なコピーを作成できる。
Amazon EC2 上でアプリケーションソフトウェアを稼働させるために必要なソフトウェア (OS、ミドルウェア) と AWS EBS ボリュームの両方が内蔵されたコピーのこと。
AWS AMI を入れ替える場合、コンテナイメージと同様に Amazon EC2 を作成し直す必要がある。
AWS AMIタイプ¶
▼ AWS EBS-backed AMI¶
AWS EBS ボリュームを持つ Amazon EC2 を作成する AWS AMI のこと。
▼ instance store-backed AMI¶
インスタンスストアボリュームを持つ Amazon EC2 を作成する AWS AMI のこと。
AWS AMIの作成¶
AMI の作成時に再起動が基本的に必要になる。
これは無効にできる。ただし、データが欠損する恐れもある。
AWS AMIの共有¶
| 共有先 | 説明 |
|---|---|
| 特定のリージョン間 | ⭕️ |
| 特定のアカウント間 | ⭕️ |
| すべてのアカウント間 (パブリック) | ⭕️ |
AWS AMI OS¶
▼ AWS AMI OSとは¶
Linux ディストリビューション別に AWS AMI OS を配布している。
▼ Amazon Linux¶
Amazon EC2 を作成するために最適化された Linux のこと。
▼ CentOS¶
ベンダー公式あるいは非公式が提供している AWS AMI が区別しにくいので、確実に公式ベンダーが提供しているもの選択すること。
03. Amazon EC2 with AWS EBS：Elastic Block Storage¶
AWS EBSとは¶
Amazon EC2 のクラウド内蔵ストレージとして働く。
03-02. セットアップ¶
コンソール画面の場合¶
▼ 設定項目と説明¶
| 設定項目 | 説明 | 補足 |
|---|---|---|
| ボリュームタイプ | AWS EBSボリュームの種類を設定する。 | |
| サイズ | 選択したボリュームタイプでのサイズを設定する。 | |
| IOPS (I/O per second) | Amazon EC2とAWS EBSボリューム間のI/O処理のリクエスト数 (個/秒) を設定する。 | ストレージのI/O処理は、読み書き処理に相当する。そのため、IOPSの数値が高いほど、高速で読み書きできることを表す。 - https://www.idcf.jp/words/io.html |
| AZ | AWS EBSボリュームを作成するAZ。 | Amazon EC2は、同じAZにあるAWS EBSボリュームしか選択できないので注意する。 |
| 暗号化 | Amazon EC2とAWS EBSボリューム間のI/O処理を暗号化するか否かを設定する。 | ・https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html |
AWS EBSボリュームタイプとサイズ¶
▼ AWS EBSボリュームの種類¶
| AWS EBSボリュームタイプ | 対応する物理ストレージ | IOPS (読み書き処理の毎秒リクエスト数) | スループット |
|---|---|---|---|
汎用SSD (gp2) |
SSD | サイズに応じて、自動的に設定される。 | 設定できない。 |
汎用SSD (gp3) |
同上 | サイズに関係なく、設定できる。 | サイズに関係なく、設定できる。 |
プロビジョンド IOPS SSD (io1) |
同上 | サイズに関係なく、設定できる。 | 設定できない。 |
プロビジョンド IOPS SSD (io2) |
同上 | サイズに関係なく、設定できる。 | 設定できない。 |
| Cold HDD | HDD | サイズに応じて、自動的に設定される。 | サイズに応じて、自動的に設定される。 |
| スループット最適化 HDD | 同上 | 設定できない。 | サイズに応じて、自動的に設定される。 |
| マグネティック | 同上 | 設定できない。 | 設定できない。 |
▼ 下限のサイズ¶
一般的なアプリケーションであれば、最低限 20～30GiB のサイズがあるとよい。
しかし、踏み台サーバー (Amazon EC2) の場合、プライベートサブネットに接続するための足場としての用途しかなく、大きなサイズの AWS EBS ボリュームを組み込む必要がない。
そこでできるだけ最小限のボリュームを選択し、ストレージ合計を抑える必要がある。
OS によって下限ボリュームサイズが異なることに注意する。
| OS | 仮想メモリ | 下限AWS EBSボリュームサイズ |
|---|---|---|
| Amazon Linux | t2.micro |
8 |
| CentOS | t2.micro |
10 |
▼ 現在の空き容量の確認¶
AWS EBS ボリュームの現在の空き容量を確認するためには、df コマンドでパーティションの使用率を確認するか、cloudwatch エージェントでこのデータを収集する必要がある。
[ec2-user ~]$ df -hT /dev/xvda1
# パーティションの使用率が15%であることから、AWS EBSボリュームの使用率がわかる。
Filesystem Type Size Used Avail Use% Mounted on
/dev/xvda1 xfs 8.0G 1.2G 6.9G 15% /
AWS EBSボリュームの拡張¶
▼ サイズの拡張¶
サイズを拡張するためには、実際のストレージ (AWS EBS ボリューム) 、AWS EBS ボリューム内のパーティション、Amazon EC2 内のファイルシステム、に関して作業が必要にある。
＊例＊
(1)-
任意で、バックアップのために拡張対象の Amazon EC2 の AWS AMI を作成しておく。
(2)-
Amazon EC2 の AWS EBS ボリュームを
8GiB から16GiB に拡張する例を考える。lsblkコマンドで現在のボリュームのサイズを確認すると、AWS EBSボリュームが8GiBである。この時、AWS EBSボリューム内にパーティションがある。
dfコマンドでパーティションのサイズを確認すると、同じく8GiBである。
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk # ストレージ (AWS EBSボリュームのルートボリューム)
└─xvda1 202:1 0 8G 0 part / # パーティション
nvme1n1 259:1 0 200G 0 disk /var/lib # ストレージ (AWS EBSボリュームの追加ボリューム)
...
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 8G 1.9G 14G 12% / # パーティション
/dev/nvme1n1 200G 161G 40G 81% /var/lib
...
(3)-
コンソール画面から、AWS EBS ボリュームを
16GiB に拡張する。この時、ダウンタイムは発生しない。
改めて
lsblkコマンドを実行することにより、該当のAWS EBSボリュームが拡張されたことを確認できる。ただ
dfコマンドで確認すると、パーティションはまだ拡張されていない。
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk # ストレージ (AWS EBSボリュームのルートボリューム)
└─xvda1 202:1 0 8G 0 part / # パーティション
nvme1n1 259:1 0 200G 0 disk /var/lib # ストレージ (AWS EBSボリュームの追加ボリューム)
...
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 8G 1.9G 14G 12% / # パーティション
/dev/nvme1n1 200G 161G 40G 81% /var/lib
...
(4)-
パーティションに紐づくファイルシステムのタイプを確認する。今回は
ext4タイプである。
$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/xvda1 ext4 8G 1.9G 14G 12% / # ext4タイプ
/dev/nvme1n1 xfs 20G 8.0G 13G 40% /var/lib
...
▼ AWS EBSボリュームが複数のパーティションで区切られている場合¶
(5)-
lsblkコマンドの結果、AWS EBS ボリュームが複数のパーティションで区切られている場合、この手順が必要になる。今回、AWS EBSボリュームがパーティションに区切られている。
そのため、
growpartコマンドでパーティションの番号を指定し、パーティションのサイズを拡張する。パーティションに区切られていなければ、この手順は不要である。
# growpart <パーティションのデバイスファイル名> <パーティションの番号>
$ growpart /dev/xvda 1
(6)-
あらためて
lsblkコマンドを実行することにより、パーティションのサイズが拡張されていることを確認できる。
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk # ストレージ (AWS EBSボリューム)
└─xvda1 202:1 0 16G 0 part / # パーティション
...
▼ ext4 タイプの場合¶
(5)-
ファイルシステムのサイズを拡張していく。
もし、パーティションに紐づくファイルシステムのタイプが
ext4タイプであった場合、resize2fsコマンドでパーティションのデバイスファイル名を指定し、これに紐づくファイルシステムのサイズを拡張する。
# 空きサイズの100%を使用して拡張する。
# sudo resize2fs <パーティションのデバイスファイル名>
$ sudo resize2fs /dev/xvda1
(6)-
あらためて
dfコマンドを実行することにより、パーティションに紐づくファイルシステムを拡張できたことを確認できる。
$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/xvda1 ext4 16G 1.9G 14G 12% /var/lib # パーティション
...
▼ xfs タイプの場合¶
(5)-
ファイルシステムのサイズを拡張していく。
もし、パーティションに紐づくファイルシステムのタイプが
xfsタイプであった場合、xfs_growfsコマンドでファイルシステムのマウントポイントを指定し、ファイルシステムのサイズを拡張する。もし、
xfs_growfsコマンドがない場合は、インストールする。
# xfs_growfs -d <ファイルシステムのマウントポイント名>
$ xfs_growfs -d /var/lib
# もし、xfs_growfsコマンドがない場合は、インストールする。
# yum install xfsprogs
(6)-
あらためて
dfコマンドを実行することにより、パーティションに紐づくファイルシステムを拡張できたことを確認できる。
$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/nvme1n1 xfs 20G 8.0G 13G 40% /var/lib # パーティション
...
AWS EBSボリュームの永続化¶
▼ AWS EBSボリュームの永続化とは¶
Amazon EC2 の初期作成時に、ストレージの追加の項目で『終了時に削除』の設定を無効化しておく。
これにより、Amazon EC2 が削除されても、AWS EBS ボリュームを削除しないようにできる。
▼ Amazon EC2の作成後に永続化する¶
Amazon EC2 の作成後に、AWS EBS ボリュームを永続化したい場合は、CLI を実行する必要がある。
$ aws ec2 modify-instance-attribute \
--instance-id <インスタンスID>
--block-device-mappings \
file://example.json
# example.jsonファイル
[{"DeviceName": "/dev/sda1", "Ebs": {"DeleteOnTermination": "false"}}]
▼ 注意点¶
Amazon EC2 に AutoScaling グループを適用している場合は、AWS EBS ボリュームを永続化しないほうがよいかもしれない。
AWS AutoScaling のスケールイン時に、削除された Amazon EC2 の AWS EBS ボリュームが削除されないため、未使用の AWS EBS ボリュームがどんどん溜まっていく問題が起こる。
AWS EBSボリュームのアタッチとデタッチ¶
▼ デバイスパスの確認¶
AWS EBS ボリュームのデバイスパスと、OS 上での実際のデバイスパスが異なる。
例えば、/dev/xvdb をデバイスパスとしても、OS 上では /dev/nvme1n1 になる。
$ df -hT
/dev/nvme1n1 xfs 100G 4.3G 96G 1% /var/lib
▼ アタッチ¶
記入中...
▼ マルチアタッチ¶
ボリュームタイプが io1 または io2 の AWS EBS ボリュームは、複数の Amazon EC2 に横断して紐づけられる。
▼ デタッチ¶
起動中の Amazon EC2 からボリュームをアタッチする場合、unmount コマンドを実行する。
target is busy というエラーにより失敗する場合がある。その際はプロセスを停止しなければならない。結果として手順は複雑になる。
$ umount -d /dev/nvme1n1
代わりに、Amazon EC2 を停止したうえでボリュームをデタッチすると、コマンドを手動で実行する必要がなく簡単である。
スナップショット¶
▼ スナップショットとは¶
AWS EBS ボリュームのコピーのこと。
スナップショットは内部的に増分バックアップになっており、前回のスナップショットの増分を次回のスナップショットに追加する。
そのため、スナップショットの頻度が高ければ増分が少なくなり、スナップショットの作成時間が短くなる。
ソフトウェアと AWS EBS ボリュームのコピーの両方が内蔵された AWS AMI とは区別すること。
▼ セットアップ¶
| 設定項目 | 説明 |
|---|---|
| リソースタイプ | 単一のボリュームのスナップショット、複数のボリュームを含むスナップショットのいずれを作成するかを設定する。 |
| ボリュームID/インスタンスID | スナップショットの元になるボリューム/Amazon EC2を設定する。 |
AWS SSM Session Managerを使用したログインシェル¶
▼ AWS SSM Session Managerを使用したログインシェル¶
AWS SSM Session Manager を使用して Amazon EC2 に接続し、ログインシェルを起動する。
▼ systems-managerエージェント¶
AWS Systems Manager を使用して Amazon EC2 に接続する場合、Amazon EC2 自体に systems-manager エージェントをインストールしておく必要がある。
カスタム AMI であれば自身でインストールし、最適化された AWS AMI であれば事前にインストールされている。
▼ Amazon VPCエンドポイントの作成¶
| Amazon VPCエンドポイントの接続先 | タイプ | プライベートDNS名 | 説明 |
|---|---|---|---|
| Amazon EC2 | Interface | ec2messages.ap-northeast-1.amazonaws.com |
ローカルマシンからAmazon EC2にコマンドを送信するため。 |
| AWS Systems Manager | Interface | ssm.ap-northeast-1.amazonaws.com |
AWS Systems ManagerのパラメーターストアにGETリクエストを送信するため。 |
| Secrets Manager | Interface | ssmmessage.ap-northeast-1.amazonaws.com |
Secrets Managerを使用するため。 |
04. ENI：Elastic Network Interface¶
ENIとは¶
クラウドネットワークインターフェースとして働く。
ENI には、サブネットから IP アドレスが割り当てられている。
ENI を AWS リソースに紐づけると、ENI はその AWS リソースに IP アドレスを割り当てる。
また、Amazon EC2 のセキュリティグループも ENI に紐づいている。
ENI を再作成した場合、ENI は IP アドレスをサブネット内に一度解放し、新しい IP アドレスを ENI に紐づける。
ENIの種類¶
▼ プライマリーENI (eth0)¶
ENI が必要な AWS リソースには、デフォルトでプライマリーENI が紐づいている。
プライマリーENI は、Amazon EC2 から解除できない。
▼ セカンダリーENI (eth1)¶
プライマリーENI に加えて、セカンダリーENI を AWS リソースに紐づけられる。
セカンダリーENI は、Amazon EC2 から解除できる。
紐付けられるAWSリソース¶
▼ ALB¶
ENI に紐付けられた IP アドレスを、ALB に割り当てる。
▼ Amazon EC2¶
ENI に紐付けられた IP アドレスを、Amazon EC2 に割り当てる。
▼ Fargate環境のAmazon EC2¶
明言されていないため推測ではあるが、ENI に紐付けられた local インターフェースが、Fargate としての Amazon EC2 に紐付けられる。
Fargate 環境のホストが Amazon EC2 とは明言されていない。
▼ Elastic IP¶
ENI に Elastic IP アドレスが紐付けられる。
この ENI を他の AWS リソースに紐付けることにより、ENI を経由して、Elastic IP を紐付けられる。
▼ GlobalAccelerator¶
記入中...
▼ AWS NAT Gateway¶
ENI に紐付けられたパブリック IP アドレスを、AWS NAT Gateway に割り当てる。
▼ Amazon RDS¶
記入中...
▼ セキュリティグループ¶
ENI にセキュリティグループが紐付けられる。
この ENI を他の AWS リソースに紐付けることにより、ENI を経由して、セキュリティグループを紐付けられる。
▼ Amazon VPCエンドポイント¶
Interface 型の Amazon VPC エンドポイントとして動作する。
Amazon VPCトラフィックミラーリング¶
ENI を経由して、同じ Amazon VPC 内の異なるインスタンスなどにパケットのコピーを送信する。
Amazon VPC エンドポイントを経由すれば異なる Amazon VPC に送信できる。
04-02. セカンダリーIPアドレス割り当て¶
セカンダリーIPアドレス割り当てとは¶
記入中...
IPアドレス数¶
| パブリック | プライベート | |
|---|---|---|
| 説明 | ENIには、パブリックIPアドレスを割り当てられる。これらが割り当てられたENIをAWSリソースに紐付ければ、そのAWSリソースに 1 個のパブリックIPアドレスを追加できる。 |
ENIには、プライマリープライベートIPアドレスとセカンダリープライベートIPアドレスを割り当てられる。これらが割り当てられたENIをAWSリソースに紐付ければ、そのAWSリソースに 2 個のプライベートIPアドレスを追加できる。 |
04-03. IPv4 Prefix delegation¶
IPv4 Prefix delegationとは¶
複数の CIDR (サブネット内の *.*.*.*/28) を ENI に割り当て、この ENI を Amazon EC2 に紐づける。
Amazon EC2 に紐づけた CIDR から IP アドレスを取得する。
使用できる IP アドレスを 16 個の倍数で増やせる。
そのため、サブネットで 16 個 (*.*.*.*/28) の連続した IP アドレスの範囲が空いている必要がある。
セカンダリーIP アドレス割り当てとは異なり、IP アドレスではなく CIDR を丸ごと ENI に割り当てられるため、Amazon EC2 内で使用可能な IP アドレス数を大きく増やせる。
| 項目 | 説明 |
|---|---|
| 自動割り当て | 予約の有無に関係なく、*.*.*.*/28 のCIDRの数を指定し、その数だけ割り当てる。 |
| 手動割り当て | あらかじめサブネットに予約しておいた *.*.*.*/28 のCIDRを指定し、割り当てる。 |
IPアドレス数¶
ENI に割り当てる CIDR (サブネット内の *.*.*.*/28) は、16 個の IP アドレスを持つ。
ENI には複数の CIDR を紐づけられるため、16 個の倍数だけ、Amazon EC2 内で取得できる IP アドレスが増える。
CIDR (サブネット内の *.*.*.*/28) の事前予約¶
ENI に CIDR を手動/自動で割り当てるとき、サブネット内に断片化されていない *.*.*.*/28 がないと、InsufficientCidr というエラーになる。
そこで、サブネットに CIDR (*.*.*.*/28) を予約しておき、これを IPv4 Prefix delegation のために使用する。
ただ、執筆時点 (2023/11/23) では、使用中のサブネットで割り当て済みセカンダリープライベート IP アドレスの分布を確認する方法がない。
サブネット内に CIDR (*.*.*.*/28) をいったん予約しておいて、Amazon EC2 の再作成によるセカンダリープライベート IP アドレス解放を待つとよい。
CIDR 内のセカンダリープライベート IP アドレスが使用中であっても CIDR を予約できる。
予約した CIDR 内のセカンダリープライベート IP アドレスが一度解放されれば、これを自動で再割り当てない仕組みになっている。
もちろん、サブネットを新しく作成すれば使用中のセカンダリープライベート IP アドレスがないため、これの解放を待つ必要はない。
外部のサブネットからIPアドレスを拝借する¶
CIDRの断片化の確認¶
ツールを使用して、CIDR が断片化されているかを確認するとよい。
$ python3 describe_unused_ips.py subnet-***
subnet_id='subnet-***' mode='normal'
cidr='*.*.*.*/*'
cidr_ips=['*.*.*.*', '*.*.*.*', ...]
-----------
# サブネットで予約したCIDRのうちで、実際に予約済みのIPアドレス
reserved_ips=['*.*.*.*', '*.*.*.*', ...]
-----------
# サブネット内で使用中のIPアドレス
used_ips=['*.*.*.*', '*.*.*.*', ...]
-----------
# サブネット内で未使用のIPアドレス
unused_ips=['*.*.*.*', '*.*.*.*', ...]
-----------
cidr=*.*.*.*/* cidr_ips=<全てのIPアドレス数> reserved=<予約されたIPアドレス数> used=<使用中のIPアドレス数> unused=<未使用のIPアドレス数>