デプロイ、プロビジョニング、自動化 #1
ポイント
組織全体の EC2 から情報を集める問題では、何の情報を集めるかと、インスタンスで収集を構成するかでサービスを見分けます。
・Quick Setup の Host Management — Systems Manager のインベントリの収集などを、Organizations と連携して組織全体のアカウントとリージョンに構成します。
・Systems Manager のインベントリ — インスタンスのアプリケーション・OS の情報・ネットワーク構成などのメタデータを収集します。
・Compute Optimizer — 使用率のメトリクスを分析し、サイズの見直しなどの推奨事項を示します。
・AWS Config のアグリゲーター — 記録済みの設定データとコンプライアンスデータを集める、読み取り専用の機能です。
・Trusted Advisor の組織ビュー — すべてのメンバーアカウントのチェック結果をレポートにまとめます。
ポイント
設定の変更を本番に反映する前に試す問題では、何の設定を変えるかと、本番のリクエストを使うかでサービスを見分けます。
・CloudFront の継続的デプロイ — 新しい設定のステージングディストリビューションへ、継続的デプロイポリシーで本番のリクエストの一部を送ります。確認が済んだら昇格し、ステージングの設定をプライマリへコピーします。
・AWS AppConfig — アプリケーションが読む機能フラグや設定データを、デプロイ戦略で段階的に反映します。
・CloudFront の無効化 — エッジロケーションのキャッシュからファイルを削除します。設定の反映の範囲は変わりません。
・CloudWatch Synthetics の canary — スケジュールに沿って合成のリクエストを送り、エンドポイントを監視します。
ポイント
Image Builder の AMI を他のアカウントで使わせる問題は、AMI の実体をどこに置くかで選び分けます。
・起動許可 (launchPermission) — AMI は所有アカウントに 1 つ残り、アカウント・OU・組織に起動を許可します。組織の ARN なら追加されたアカウントも対象です。
・ターゲットアカウント (targetAccountIds) — AMI を各アカウントへコピーします。配布先ごとに専用のロールが必要です。
・AWS RAM — 共有できるのはコンポーネント・イメージ・レシピで、AMI の起動許可ではありません。
「組織全体で使わせる」「手数を最小に」なら起動許可に組織の ARN、「各アカウントが自分で所有する」ならターゲットアカウントです。
ポイント
Git のリポジトリから CloudFormation のスタックを自動的に更新する問題では、リポジトリを監視するかと、スタックを更新するかでサービスを見分けます。
・Git sync — スタックに連携したリポジトリとブランチを監視し、テンプレートファイルかパラメータを含むスタックデプロイファイルの変更がコミットされると、スタックを自動的に更新します。
・StackSets — 1 つのテンプレートから複数のアカウントとリージョンへスタックをデプロイします。リポジトリは監視しません。
・CodeDeploy — アプリケーションのリビジョンを EC2 インスタンスなどへデプロイします。スタックは更新しません。
・CloudTrail — API 呼び出しを記録します。
ポイント
EC2 インスタンスの起動の失敗では、エラーコードが示す原因に合わせて対処します。
・InsufficientInstanceCapacity — AWS 側に、リクエストを満たすオンデマンドキャパシティが現在ありません。数分待って再試行する、台数を分ける、AZ を指定しない、別のインスタンスタイプを使う、のどれかで対処します。クォータを引き上げても解決しません。