Amazon EC2とインスタンスのシナリオ判断
開発Webを本番へ移す計画です。AMIの使い方、CPUとメモリの選択、夜間停止、終了時のデータ、S3への認証情報を点検し、運用で起きる取り違えを直します。
この単元で学ぶこと
- EC2の構成要素の選択ミスを事例から直せる
- 停止・終了に伴うデータと費用を判断できる
- 公開・権限・OS管理・可用性を独立に点検できる
本文解説
AMIと能力を分ける 同じアプリを別チームへ配るなら、検証済みAMIを起動材料として利用できます。しかしメモリ不足を直すためにAMI名だけ変えても能力は増えません。インスタンスタイプと実際の負荷を確認し、OS構成とハードウェア能力の選択を分けます。
不足を測る CPUは低いのにメモリが足りなければ、計算能力だけ強いタイプが適するとは限りません。必要なOS指標を収集し、処理のどこが制限されているかを調べます。変更後にも同じ業務条件で測定し、費用と性能を評価します。
夜間停止の前 開発用のEBS-backed EC2を夜に止める案では、インスタンスストアに必要なファイルがないか確認します。一時領域へ唯一の成果物を置いているなら永続的な保存先へ移します。停止と再起動は違うため、どちらの操作を実行する計画か明確にします。
停止後の費用 翌朝もEBSなどの費用が発生していれば、直ちに停止失敗とはいえません。EC2の状態と残存する保存領域、IP、契約上の利用約束を分けて確認します。必要データを保存する費用と無用な放置を区別し、削除判断には保管要件も含めます。
終了前の確認 一時停止のつもりで終了すると、そのインスタンスをそのまま再起動できません。またルートEBSなどが終了時削除に設定されていれば失われます。必要なデータの退避や復元方法を確認し、終了保護などの運用上の防止策も検討します。
公開できない理由 セキュリティグループでHTTPSを許可しても、インターネットゲートウェイへの経路や適切なアドレス、アプリの待受がなければ到達しません。反対に、通信が届いてもS3操作が拒否されるなら、ネットワークだけでなくIAM権限を調べます。
秘密情報を複製しない 本番用AMIの中に開発者のアクセスキーが入っていれば、増やすサーバーにもコピーされる可能性があります。アプリ専用の限定ロールへ移行し、不要なキーを整理します。AMIを再利用する前に更新状態や不要な設定も点検します。
可用性を追加設計 1台の大型EC2だけでは、その1台や配置AZの故障へ対応しきれません。別AZの処理先、負荷分散、データや利用者状態の利用可能性を確認します。EC2を増やす案は、アプリが複数台で動くことと、正常側の能力まで含めて検証します。
図解
重要ポイント
- OSテンプレートと能力構成を別に選ぶ。
- 停止前に一時領域、終了前に削除設定を確認する。
- 停止しても残る課金項目がある。
- 通信・IAM・OS更新・AZ分散を混同しない。
間違えやすい点
- AMI名変更でCPUやメモリが増えると思わない。
- 一時停止と終了を取り違えない。
- 公開ポート許可をS3操作の許可とみなさない。
用語解説
- EC2インスタンス
- AWSで実行する仮想サーバー。状態、起動イメージ、能力、ネットワーク、ストレージなどを設定する。
- AMI
- OSやソフトウェア構成を含む、EC2を起動するためのテンプレート。
- インスタンスタイプ
- CPU、メモリ、ネットワーク、ストレージ等の能力の組合せ。
- EBS-backed
- ルートボリュームにEBSを使うEC2構成。停止と終了の違いを理解して扱う。
- インスタンスストア
- ホストに付属する一時ストレージ。停止や終了などで消失するためデータの性質に応じて使う。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。