はじめに
記載内容は上記の翻訳ではなく、意訳、要約を含みます。
手順も一部省略している部分もあります。
詳細や正確な手順を知りたい場合は本家サイトを参照ください。
画面スクショは本記事作成当時のものであり、今後のアップデートにより差異が発生する可能性があることをご留意ください。
Introduction
本ハンズオンでInfrastructure as Code（以降、IaC と呼ぶ）とOperations as Codeの概念を学ぶことができます。
Intro
クラウドでは、環境をコードで管理することができます。
ワークロード全体をコードで定義、更新したり、運用手順をスクリプト化してイベントをトリガーとして実行を自動化することもできます。
これによりヒューマンエラーを回避し、運用手順が一貫した手順となります。
Setup
2.1 Create Administrator IAM User and Group
AdministratorAccessポリシーをアタッチしたIAMグループを新規作成します。
また、IAMユーザ（以降、管理者ユーザ とよぶ）も作成し、上記IAMグループに属させます。
ネットに情報がたくさんあるので、こちらの説明は省略します。
2.2 Log in to the AWS Management Console using your administrator account
前の手順で作成した管理者ユーザでマネジメントコンソールにログインする手順です。
こちらも特に説明はしません。
1点確認していただきたいのは、ハンズオンを実施するリージョンのVPCの数です。
VPCダッシュボードから確認することができます。下図の場合、東京リージョンで1つのVPCが生成されていることがわかります。
これが3つ以下であることを確認してください。3つより大きい場合、不要なVPCを削除してください。
2.3 Create an EC2 Key Pair
EC2インスタンスにログインする際に使用するキーペアを作成します。
このキーペアは公開鍵暗号方式を使用しており、EC2インスタンスへのログイン情報の暗号化、復号化に使用します。
EC2ダッシュボードに遷移し、左メニューキーペアを選択してください。
右上のキーペアを作成ボタンをクリックしてください。
名前は任意ですが、ハンズオンに合わせOELabIPMにしました。
それ以外は下図のように入力し、キーペアを作成ボタンをクリックしてください。
キーペア画面に遷移し、一覧にキーペアが追加されていれば作成成功です。
作成成功時、キーペアがダウンロードされるので忘れないでください。
また、キーペアは機密情報ですので、厳重に管理してください。
Deploy an Environment Using Infrastructure as Code
AWS Cloud Formationは、IaCを支援するサービスです。
Cloud Formationの定義に従ったテンプレートを作成し、このサービスにアップロードすることで、AWSリソースのプロビジョニングを自動化することができます。
プロビジョニングされたAWSサービス群はスタックという単位で管理され、作成および削除することができます。
Cloud Formationを使用することで、リソースの管理が楽になり、本来やるべき作業に注力することができます。
3.1 Deploy the Lab Infrastructure
こちらからCloudFormationテンプレートをダウンロードしてください。
CloudFormationのTOP画面に遷移し、左メニュースタックを選択してください。
次に画面中央オレンジ色のスタックの作成ボタンをクリックするか、右上スタックの作成を選択し、新しいリソースを使用(標準)をクリックしてください。
前提条件 - テンプレートの準備はテンプレートの準備完了、テンプレートソースはテンプレートファイルのアップロードを選択してください。
次に、ファイルの選択ボタンをクリックし、前手順でダウンロードしたCloudFormationテンプレートを選択してください。
最後に、次へボタンをクリックしてください。
デザイナーについての説明は割愛いたします。
スタック名は任意ですがハンズオンと同様OELabStack1にします。
InstanceProfileは空白にしてください。
InstanceTypeAppとInstanceTypeWebはt2.microにしてください。
KeyNameは前手順で作成したキーペア名（今回はOELabIPM）を選択してください。
SourceLocationは作成するEC2インスタンスのアクセス元IPアドレスを指定します。
https://checkip.amazonaws.com/にアクセスし、表示されたIPを入力、末尾に/32を追加してください。
WorkloadNameはTestにしてください。
最後に、次へボタンをクリックしてください。
新しいタグを追加ボタンをクリックし、キーにOwner、値に任意の文字列を入力してください。
それ以外は設定変更せず、次へボタンをクリックしてください。
確認画面です。入力内容を確認したら、送信ボタンをクリックしてください。
スタックのステータスがCREATE_COMPLETEになったらプロビジョニング成功です。
EC2インスタンスの一覧に遷移し、インスタンスが合計4つ起動していることを確認してください。
インスタンスの1つを選択し、タグタブを選択してください。
CloudFormationでの操作時に入力したOwnerタグやWorkloadがTestになっていることを確認してください。
The impact of Infrastructure as Code
IaCのメリットの1つはデプロイできるテンプレートを作成できれば、それを使って同じ環境のコピーをいくつも作成できることです。
今回CloudFormationのパラメータWorkloadはTestとしましたが、Prodにして本番環境として利用することもできます。
Inventory Management using Operations as Code
Management Tools: Systems Manager
AWS Systems Managerは、AWS環境の運用に加え、オンプレ環境の運用も効率化する機能を数多く提供するサービスです。
管理する主なサービスはEC2であり、管理対象となったEC2インスタンスをマネージドインスタンスと呼びます。
マネージドインスタンスになるには以下の条件があります。
- SSMエージェントがインストールされていること
- エージェントがプリインストールされているAMIもありますし、手動でインストールすることもできます
- 詳細は公式ドキュメントを参照ください
- SSM APIへの接続経路が存在すること
- エージェントとSSM APIはHTTPSで通信します。
- Internet GatewayやNAT Gatewayを使用し、アウトバウンド通信を許可する必要があります。
- IAMロールに適切な権限が付与されていること
- マネージドポリシー
AmazonSSMManagedInstanceCoreにSSMを操作する最低限の権限が付与されているので、このポリシーかそれに相当するものをIAMロールに付与する必要があります。
- マネージドポリシー
4.1 Setting up Systems Manager
Systems ManagerのTOP画面から左メニューフリートマネージャーを選択します。
先に進むと下図のような画面が表示されます。フリートマネージャーはマネージドインスタンスの情報を一覧化し、管理できる機能です。
現在はマネージドインスタンスの条件となるEC2インスタンスを作成していないため、何も表示されていません
[Deploy an Environment Using Infrastructure as Code](#Deploy an Environment Using Infrastructure as Code)で生成したEC2インスタンスをフリートマネージャーに表示するには上に記載している条件のIAMロールに適切な権限を付与を実施する必要があります。
IAMのTOP画面の左メニューロールを選択し、ロールを作成ボタンをクリックしてください。
次に下図のように信頼されたエンティティタイプとユースケースを選択し、次へボタンをクリックしてください。
続いて、追加するポリシーを選択します。
検索窓にAmazonSSMManagedInstanceCoreと入力し、表示されたAmazonSSMManagedInstanceCoreをチェック、次へボタンをクリックしてください。
ロール名は任意ですが、今回はハンズオンと同様ManagedInstancesRoleにします。それ以外は特に入力は不要です。
ロールを作成ボタンをクリックしてください。
EC2インスタンスの一覧画面に遷移してください。
現在４つのインスタンスが起動しているはずです。
その内1つをチェックし、アクションプルダウンを選択、セキュリティ、IAMロールを変更を選択してください。
プルダウンでインスタンスにアタッチするIAMロールを選択します。
先ほど作成したManagedInstancesRoleを選択し、IAMロールの更新ボタンをクリックしてください。
以上の作業を他3インスタンスにも実施してください。
フリートマネージャーに移動し、IAMロールを変更したEC2インスタンスがマネージドインスタンスとして表示されているか確認してみましょう（反映には感覚10分程度かかります）。
インスタンスが4つ表示されたら成功です。
4.2 Create a Second CloudFormation Stack
以降のハンズオンで使用するため、[3.1 Deploy the Lab Infrastructure](#3.1 Deploy the Lab Infrastructure)で作成したスタックをもう一つ作成します。
スタック名は任意ですがハンズオンと同様OELabStack2にします。
InstanceProfileは上記手順で作成したIAMロールManagedInstancesRoleのロール名を入力してください。
また、WorkloadNameはProdにしてください。
それ以外のパラメータは同じにしてください。
スタックが作成されたら、フリートマネージャーを確認し、マネージドインスタンスが8つ表示されていることを確認してください。
Systems Manager: Inventory
AWS Systems ManagerのInventoryは、マネージドインスタンスからOS、アプリケーションやインスタンスのメタデータ（ネットワーク情報など）を収集し、一覧表示する機能です。
収集したデータをクエリし、アップデートが必要なインスタンスや必要なアプリケーションがインスタンスにインストールされているかなどを確認することができます。
4.3 Using Systems Manager Inventory to Track Your Instances
Systems ManagerのTOP画面左メニューインベントリを選択してください。
画面下にある対応するマネージドインスタンスにフリートマネージャーで表示されているEC2インスタンスの情報が表示されていることを確認します。
一覧一番上のインスタンスIDのリンクをクリックしてください。
左メニューを選択することでインスタンスのメタ情報やタグ情報などを確認することができます。
再度、左メニューインベントリを選択してください。
画面右上セットアップインベントリボタンをクリックしてください。
こちらの画面でインベントリ情報を収集するマネージドインスタンスや情報収集のスケジュール、取得する情報などを指定することができます。
まず、インベントリの詳細の指定の名前を入力します。今回はデフォルトInventory-Associationにします。
インベントリ対象のマネージドインスタンスを指定します。
ターゲットはタグの指定を選択し、タグはEnvironment、値はOELabIPMを入力してください。
ハンズオンで生成したEC2インスタンスには上記タグ値が付与されているため、スタック内全てのインスタンスがインベントリ対象になります。
続いて、インベントリを収集するスケジュールを指定します。
スケジュールは最小の30分にしてください。
パラメーターでは収集するインベントリの種類を選択できます。今回はデフォルト（全選択）にしてください。
詳細設定でインベントリ収集の実行ログを指定したS3バケットに書き込むことができます。
実行履歴を S3 に書き込むをチェックし、S3 バケット名に任意のS3バケット名、S3 キープレフィックスはlogsと入力してください。（S3バケットは事前に作成しておく必要があります）
入力し終えたら、画面右下のセットアップインベントリボタンをクリックしてください。
以上でインベントリが設定されます。また、同時に後述するState Managerに関連付け（アソシエーション）が作成されます。
作成したインベントリ設定は設定タブを選択することで確認できます。
ステータスが成功になっていれば、インベントリ収集が完了です。
設定の新規作成は右上新しいインベントリの設定ボタン、設定の編集は右上編集ボタンからできます。
インベントリのダッシュボードに遷移してください。
インベントリが有効になっているマネージドインスタンスは以前disableが8でしたが、enableが8に変わっています。
また、OSやアプリケーションの情報も表示されるようになりました。
インスタンスの詳細画面でインベントリを選択すると、インスタンス毎の詳細なインベントリを閲覧することができます。
下図はインストールされているアプリケーションを一覧表示している例です。
Systems Manager: State Manager
AWS Systems ManagerのState Managerは、マネージドインスタンスの設定を管理、維持する機能です。
このインスタンスがあるべき状態の定義を関連付け（アソシエーション）と呼びます。
関連付け（アソシエーション）は以下3つの設定があります。
- 対象: どのマネージドインスタンスをステートマネージャーで管理するか
- 実行ドキュメント: どのドキュメント（マネージドインスタンスで実行するアクションを定義したもの）を実行するか
- スケジュール: どの頻度でドキュメントを実行するか（１回のみ実施も可能）
4.4 Review Association Status
左メニューステートマネージャーを選択し、セットアップインベントリで生成した関連付け（今回だとInventory-Association）の関連IDのリンクをクリックしてください。
タブを選択して、関連付けの情報を閲覧することができます。
関連付けのメタ情報、対象となっているマネージドインスタンスやターゲットとする条件など確認ができます。
Editボタンをクリックすると、関連付け設定の変更ができます。
ドキュメントに記載されているSSMドキュメント（今回はAWS-GatherSoftwareInventory）がスケジュールに従い、指定したターゲットに対して実行されます。
パラメーターの値は実行時にドキュメントに渡されます。
インスタンスの詳細画面に再度遷移します。（フリートマネージャーでノードIDのリンクをクリック）
左メニュー関連付けを選択すると、関連付け情報と直近の実行結果を確認することができます。
Systems Manager: Compliance
AWS Systems ManagerのComplianceはマネージドインスタンスをスキャンし、コンプライアンスに準拠しているか確認する機能です。
以下の情報からコンプライアンスに準拠しているかしていないかを判断しています。
- Patch Managerのパッチ適用のステータス
- State Managerの関連付けのステータス
- カスタムコンプライアンス項目のステータス
つまり、マネージドインスタンスのパッチ適用状況と構成が逸脱していないかを判断してくれます。
左メニューコンプライアンスをクリックし、コンプライアンス画面に遷移します。
コンプライアンスダッシュボードのフィルタリングでコンプライアンスタイプを選択するとState Managerの関連付けに準拠しているかを確認することができます。
準拠リソースが8であるため、問題ないことがわかります。
コンプライアンスダッシュボードのフィルタリングでパッチグループを選択するとPatch Managerのパッチ適用状況を確認することができます。
こちらも準拠リソースが8であるため、問題ないことがわかります。
Patch Management
Systems Manager: Patch Manager
AWS Systems ManagerのPatch Managerはマネージドインスタンスにセキュリティパッチを管理する機能です。
どのインスタンスにパッチが不足しているかのレポート機能や不足していたら自動的にパッチ適用する機能があります。
パッチをチェックするインスタンスは個別に指定することもグループとして指定することも可能です。
Patch Baselines
Patch Managerにはパッチベースラインという概念があります。これはインスタンスにパッチを適用するルールです。
例えば、デプロイ後数日以内にパッチを自動適用するルールなどがあります。
OS毎に事前定義済みのパッチベースラインがありますし、独自のベースライン（カスタムベースライン）も定義することができます。
5.1 Create a Patch Baseline
Systems Managerの左メニューパッチマネージャーを選択してください。
右上の概要から開始リンクをクリックしてください。
パッチマネージャーの画面が表示されたら、パッチベースラインタブを選択してください。
パッチベースラインの一覧が表示されます。
パッチベースラインを作成するボタンをクリックしてください。
作成するパッチベースラインの情報を入力する画面に遷移します。
パッチベースラインの詳細セクションの入力を行います。
名前はなんでも良いですが、今回はハンズオンと同じAmazonLinuxSecAndNonSecBaselineにします。
説明はオプションですが、今回はハンズオンと同じAmazon Linux patch baseline including security and non-security patchesにします。
オペレーティングシステムはAmazon Linuxを選択してください。
オペレーティングシステムの承認ルールの入力を行います。
製品、分類、重要度は全てAllを選択してください。
自動承認はデフォルト値、つまり指定した日数後にパッチを承認するをチェックし、日数の指定は0日にしてください。
コンプライアンスレポートは中にしてください。
セキュリティ以外の更新を含めるはチェックしてください。
パッチの例外セクションの入力を行います。
拒否されたパッチにsystem-release.*を入力してください。これにより、リリースする前にPatch Managerがサポートできない可能性がある新しいAmazon Linuxへのパッチを拒否することができます。
以上、入力が終わったら画面最下部のパッチベースラインを作成するボタンをクリックしてください。
パッチベースラインの一覧画面に遷移します。作成したベースラインが表示されていることを確認してください。
Patch Groups
Patch Managerにはパッチグループという概念があります。パッチを適用するインスタンスをグループ化するものです。
パッチグループをパッチベースラインに関連付けることでパッチグループに属するインスタンスにベースラインで定義したルールでパッチを適用することができます。
パッチグループはインスタンスにタグを付与することで作成できます。
タグキーにPatch Group、値に任意の文字列、例えば、devなどを指定します。
注意点は、1つのインスタンスは1つのバッチグループにしか属することができません。また、1つのパッチグループを複数のパッチベースラインに関連付けできますが、OSごとに1つまでです。
5.2 Assign a Patch Group
パッチベースラインの一覧画面で先ほど作成したベースラインAmazonLinuxSecAndNonSecBaselineを検索し、ベースラインIDリンクをクリックします。
※ハンズオン記載では、右上にアクションボタンがあり、そこからベースラインに割り当てるパッチグループを選択する手順が記載されているが、アクションボタンが見つからなかった。
調べたところ、こちらのページに対処方法が記載されていた。以下Deepl翻訳。
今回はAWS CLIを使用する方法で行う。推奨方法はパッチポリシーを使用する方法であるため、ハンズオンとやり方が異なるからです。
Baseline IDの詳細ページにActionsメニューがない場合、コンソールでパッチグループを設定することはできません。代わりに、以下のどちらかを行うことができます：
(推奨）AWS Systems Managerの機能であるQuick Setupでパッチポリシーを設定し、パッチベースラインを1つ以上のEC2インスタンスにマッピングする。
詳細については、Quick Setupパッチポリシーの使用とQuick Setupパッチポリシーを使用した組織全体のパッチの自動化を参照してください。
パッチグループを構成するには、AWSコマンドラインインターフェイス（AWS CLI）のregister-patch-baseline-for-patch-groupコマンドを使用する。
register-patch-baseline-for-patch-groupコマンドのドキュメントはこちらです。
baseline-idは今回作成したパッチベースラインのベースラインIDを指定します。
patch-groupはパッチグループ名を指定します。今回のハンズオンではCriticalを指定します。
CloudShellで実行します。
aws ssm register-patch-baseline-for-patch-group --baseline-id <ベースラインID> --patch-group <パッチグループ名>
パッチベースラインの一覧を再度表示すると一覧にデフォルトのベースライン列が表示されました。
また、作成したパッチベースラインの詳細画面を表示するとアクションボタンが追加で表示されていることもわかりました。
当該ベースラインの説明セクションのパッチグループがCriticalになっていることを確認してください。
AWS-RunPatchBaseline
AWS-RunPatchBaselineは、SSMドキュメントの一つであり、マネージドインスタンスにセキュリティ関連およびその他アップデートを実行します。
パッチのコンプライアンス情報もレポートし、Systems Managerのコンプライアンス機能で結果を確認することができます。
例えば、バッチが不足しているインスタンスと不足しているパッチを確認できます。
AWS Systems Manager: Document
Systems Managerにはドキュメント（SSMドキュメント）という概念があります。これはSystems Managerがマネージドインスタンスに対して実行するアクションを定義するものです。
前述のAWS-RunPatchBaselineは事前設定済みドキュメントであり、これらはその他たくさん用意されています。
ドキュメントはJsonまたはYamlで記載されており、実行するアクションやパラメータが定義されています。
5.3 Examine AWS-RunPatchBaseline in Documents
Systems MangerのTOP画面の左メニュードキュメントを選択します。
検索窓を選択し、ドキュメント名のプレフィックス、Equalsを選択し、AWS-Runと入力し、エンターキーを押下してください。
AWS-RunPatchBaselineが検索されているので、そのリンクをクリックしてください。
ドキュメントの詳細画面が表示されます。
説明タブではドキュメントのメタ情報、コンテンツにはドキュメントの実体（Json、Yaml）などが表示されます。
AWS Systems Manager: Run Command
Systems ManagerにはRun Commandという機能があります。これはマネージドインスタンスの構成をリモートで管理できる機能です。
マネージドインスタンスに対する定期的（またはアドホック）な構成変更をインスタンスにログインせずに実行することができます。
5.4 Scan Your Instances with AWS-RunPatchBaseline via Run Command
Systems ManagerのTOP画面左メニューRun Commandを選択し、右上Run commandボタンをクリックします。
コマンドドキュメントセクションの検索窓を選択し、プラットフォームの種類でLinuxを選択後、エンターキーを押下してください。
検索窓に続いてAWS-RunPatchBaselineと入力し、エンターキーを押下してください。
一覧にAWS-RunPatchBaselineが表示されるのでチェックしてください。
次にコマンドのパラメータセクションの入力です。
OperationはScanにし、それ以外はデフォルトで構いません。
次にターゲットセクションの入力です。
ターゲットはインスタンスタグの指定を選択し、インスタンスタグの指定ではタグキーにWorkload、タグの値にTestを入力し、Addボタンをクリックしてください。
以降の設定は今回不要です。
画面右下の実行ボタンをクリックしてください。
Run CommandのTOP画面でコマンド履歴タブを選択すると、実行したコマンドの結果を確認できます。
今回WorkloadタグにTestを指定したのでターゲットとなるマネージドインスタンスは4つになっていることがわかります。
コマンドIDリンクをクリックするとコマンド実行結果の詳細を確認することができます。
5.5 Review Initial Patch Compliance
Systems ManagerのTOP画面左メニューコンプライアンスを選択します。
ダッシュボードの結果をグループ化する条件はコンプライアンスタイプを選択すると、コンプライアンスリソースの概要セクションに非準拠リソースが4と表示されるのでそれを選択します。
リソースセクションに非準拠リソースと判断されているマネージドインスタンスが表示されていることを確認します。
5.6 Patch Your Instances with AWS-RunPatchBaseline via Run Command
Systems ManagerのTOP画面左メニューRun Commandを選択し、右上Run commandボタンをクリックします。
コマンドドキュメントセクションの検索窓を選択し、プラットフォームの種類でLinuxを選択後、エンターキーを押下してください。
検索窓に続いてAWS-RunPatchBaselineと入力し、エンターキーを押下してください。
一覧にAWS-RunPatchBaselineが表示されるのでチェックしてください。
次にコマンドのパラメータセクションの入力です。
OperationはInstallにし、それ以外はデフォルトで構いません。
次にターゲットセクションの入力です。
ターゲットはインスタンスタグの指定を選択し、インスタンスタグの指定ではタグキーにWorkload、タグの値にTestを入力し、Addボタンをクリックしてください。
次にレート制御セクションの入力です。
同時実行数はターゲットを選択し、1を入力してください。
エラーのしきい値はエラーを選択し、1を入力してください。
画面右下の実行ボタンをクリックしてください。
コマンドの詳細画面に遷移するので、全体的なステータスが成功または失敗になるまで待ちます。
5.7 Review Patch Compliance After Patching
先ほど実行したコマンドは4つのインスタンスに対して実行され、全体的なステータスは失敗に終わりました。
インスタンス毎の結果を一覧から確認すると詳細なステータスが失敗のものと終了済みのものがありました。
インスタンスIDのリンクをクリックすると、実行したドキュメントのステップ毎の結果が表示されます。
詳細なステータスが失敗のものは最初のステップが成功し、以降は失敗しているようです。
終了済みのものは何も表示されませんでした。Run Commandのエラーのしきい値を超えたため、コマンドが実行されなかったからだと思われます。
コンプライアンス画面に戻り結果を確認してみましょう。
コンプライアンスリソースの概要セクションの非準拠リソースが4から2になっており、準拠リソースが2に増えていることがわかります。
準拠リソースの数値を選択し、リソースセクションを確認すると、Run Commandで詳細なステータスが失敗で終わったインスタンスが表示されていました。
最初のステップが成功した結果、当該インスタンスが非準拠リソースから準拠リソースになったことがわかります。
The Impact of Operations as Code
Run Commandの実行は失敗してしまいましたが、Patch Managerなどの機能を使用すると大量のインスタンスに対して簡単に構成変更をスケジュールさせることができるとわかりました。
運用手順書などはJsonやYamlのコードに置き換わり、自動化されることでヒューマンエラーのリスクも無くなります。
運用がより楽になり本当に注力すべき作業に時間を費やすことができます。
Creating Maintenance Windows and Scheduling Automated Operations Activities
AWS Systems Manager: Maintenance Windows
Systems Managerにはメンテナンスウィンドウという機能があります。これはOSのバッチ適用、ドライバの更新やソフトウェアのインストールなどをインスタンスに対して実施するスケジュールを定義する機能です。
メンテナンスウィンドウには、スケジュール、ターゲット、タスクといった要素が存在します。
スケジュールは文字通り、いつタスクを実行するかを指定します。
ターゲットはタスクを実行する対象であり、マネージドインスタンスを指定します。
タスクは実行するアクションを指します。Run Commandのコマンド、オートメーションのワークフロー、Lambda関数やStep Functionsのステートマシンなどを実行することができます。
6.1 Setting up Maintenance Windows
Systems Managerがメンテナンスウィンドウのタスクを実行できるようにするIAMロールを作成します。
IAMのダッシュボード左メニューロールを選択し、右上ロールを作成ボタンをクリックしてください。
信頼されたエンティティタイプはAWSのサービスを選択してください。
ユースケースはEC2を選択してください。
右下の次へボタンをクリックしてください。
検索窓にAmazonSSMMaintenanceWindowRoleと入力し、エンターキーを押下してください。
表示されたAmazonSSMMaintenanceWindowRoleをチェックし、右下次へボタンをクリックしてください。
ロール名は自由ですが、今回はSSMMaintenanceWindowRoleにします。
説明は自由ですが、今回はRole for Amazon SSMMaintenanceWindowにします。
それ以外は後で書き換えるものもありますが、デフォルトにし、右下ロールの作成ボタンをクリックしてください。
作成したIAMロールを選択し、詳細画面に遷移してください。
信頼関係タブを選択し、信頼ポリシーを編集ボタンをクリックしてください。
Jsonを以下に書き換えてください。
このIAMロールに付与されているIAMポリシーを行使するサービスとしてEC2、Systems Manager、SNSを指定します。
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":[
"ec2.amazonaws.com",
"ssm.amazonaws.com",
"sns.amazonaws.com"
]
},
"Action":"sts:AssumeRole"
}
]
}
書き換えたら右下ポリシーを更新ボタンをクリックしてください。
続いて、IAM PassRoleポリシーを作成し、IAMユーザーに割り当てます。
メンテナンスウィンドウにタスクを登録する際、前手順で作成したIAMロールをアタッチする必要があります。
当該IAMロールをタスクにアタッチをするという権限をIAMユーザーに付与するため、これら手順を実施します。
IAMのダッシュボード左メニューポリシーを選択し、右上ポリシーを作成ボタンをクリックしてください。
IAMポリシーの情報を入力していきます。
サービスを選択はIAMを選択してください。
アクション許可は検索窓にPassRoleと入力し、表示されたPassRoleをチェックしてください。
続いてリソースは特定を選択した状態で、ARNを追加リンクをクリックしてください。
ダイアログ内のテキストタブをクリックし、先ほど作成したIAMロールのARNを貼り付けてください。
右下ARNを追加ボタンをクリックしてください。
ここまで入力したら、画面右下次へボタンをクリックしてください。
ポリシー名は自由ですが、今回はSSMMaintenanceWindowPassRoleにします。
入力したら画面右下ポリシーの作成ボタンをクリックしてください。
作成したIAMポリシーをIAMグループに割り当てます。
IAMのダッシュボード左メニューユーザーグループを選択し、許可を追加、ポリシーをアタッチをクリックしてください。
検索窓にSSMMaintenanceWindowPassRoleと入力し、検索されたSSMMaintenanceWindowPassRoleをチェックしてください。
右下許可を追加ボタンをクリックしてください。
Creating Maintenance Windows
メンテナンスウィンドウ作成から実行までは以下の手順を実行します。
- メンテナンスウィンドウを作成し、スケジュールを定義する
- メンテナンスウィンドウのターゲットを割り当てる
- メンテナンスウィンドウ中に実行するタスクを割り当てる
6.2 Create a Patch Maintenance Window
メンテナンスウィンドウを作成し、スケジュールを定義します。
Systems MangerのTOP画面の左メニューメンテナンスウィンドウを選択し、右上Create Maintenance Windowボタンをクリックします。
メンテナンスウィンドウの詳細の入力セクションの入力です。
名前は自由ですが、今回はPatchTestWorkloadWebServersとします。
説明は今回未入力です。
未登録ターゲットは未登録ターゲットを許可するをチェックしてください。
スケジュールセクションの入力です。今回はハンズオンであるため、なるべく早くメンテナンスウィンドウが実行されるよう設定します。
次で指定はCronスケジュールビルダーでデフォルトを選択してください。
期間は1時間を入力してください。
タスクの開始を停止するは0を入力してください。
入力が終わったら画面最下部のメンテナンスウィンドウの作成ボタンをクリックしてください。
6.3 Assigning Targets to Your Patch Maintenance Window
続いて、メンテナンスウィンドウにタスクを実行するターゲットを割り当てます。
作成したメンテナンスウィンドウのウィンドウIDリンクをクリックしてください。
メンテナンスウィンドウの詳細画面に遷移します。
右上アクションを選択し、ターゲットの登録をクリックしてください。
Maintenance window target detailsセクションの入力です。
Target nameは任意ですが、今回はTestWebServersとします。
Description、Owner Informationは今回未入力です。
ターゲットセクションの入力です。
ターゲットの選択はインスタンスタグを指定を選択してください。
インスタンスタグを指定はタグキーがWorkload、タグの値はTestにし、Addボタンをクリックしてください。
再度インスタンスタグを指定でタグキーがInstanceRole、タグの値はWebServerにし、Addボタンをクリックしてください。
入力が終わったら画面最下部のRegister targetボタンをクリックしてください。
6.4 Assigning Tasks to Your Patch Maintenance Window
最後に、メンテナンスウィンドウ中に実行するタスクを割り当てます。
メンテナンスウィンドウの詳細画面右上アクションを選択し、Run Commandタスクの登録を選択してください。
メンテナンスウィンドウタスクの詳細セクションの入力です。
名前は任意ですが、今回はPatchTestWorkloadWebServersと入力します。
説明は未入力、New task invocation cutoffはチェックしなくて構いません。
コマンドドキュメントセクションの入力です。
ドキュメントは検索窓を選択し、プラットフォームの種類をLinuxにしてください。
また、AWS-RunPatchBaselineと入力し、エンターキーを押下し、表示されたAWS-RunPatchBaselineをチェックしてください。
ドキュメントのバージョン、タスクの優先度はデフォルト値で構いません。
ターゲットセクションの入力です。
次によるターゲットは登録済みターゲットグループの選択を選択してください。
一覧に表示されている作成したグループをチェックしてください。
レート制御セクションの入力です。
同時実行数はターゲットで1を入力してください。
エラーのしきい値はエラーで1を入力してください。
IAMサービスロールセクションの入力です。
メンテナンスウィンドウがタスクを実行するためにAmazonSSMMaintenanceWindowRoleポリシーを持っているIAMロールを指定します。
前手順で作成した、SSMMaintenanceWindowRoleを指定します。
出力オプションセクション、SNS通知セクションはデフォルト（すべてチェックしない）で構いません。
パタメータセクションの入力です。
OperationはInstallを選択してください。
それ以外はデフォルトで構いません。
続くCloudWatch alarmセクションも未選択で構いません。
Run Commandタスクの登録ボタンをクリックしてください。
6.5 Review Maintenance Window Execution
タスクの実行結果を確認します。
メンテナンスウィンドウの詳細画面に遷移し、履歴タブを選択してください。
直近の実行結果をチェックし、詳細の表示ボタンをクリックしてください。
タスク呼び出しセクションでタスクの実行概要を確認できます。
チェックし、詳細の表示ボタンをクリックしてください。
Run Command機能の画面に遷移し、より詳細な情報を確認することができます。
今回はタスクに失敗してしまいましたが、メンテナンスウィンドウにより、Run Commandなどが自動実行できることがわかりました。
Creating a Simple Notification Service Topic
Amazon Simple Notification Service (Amazon SNS)は、クライアントに対するメッセージの配信および送信を管理するフルマネージドメッセージングサービスです。
機能として、モバイルPUSH通知、Pub/Subメッセージングがあります。
モバイルPUSH通知機能は、スマートフォンに対して通知ができる機能です。ユーザーのモバイル端末などに直接通知を送信することができます。
Pub/Subメッセージング機能は、非同期的はメッセージ配信モデルです。Publisherと呼ばれるメッセージ送信元がSNSで管理しているTopicと呼ばれる論理的アクセスポイントにメッセージを送信します。Subscriberと呼ばれるメッセージ受信者は好きなTopicを購読するよう設定しておくと、Topicからメッセージが配信され、メッセージを受信することができます。
6.1 Create and Subscribe to an SNS Topic
Amazon SNSのダッシュボード画面に遷移し、左メニュートピックを選択します。
右上トピックの作成ボタンをクリックしてください。
詳細セクションの入力です。
タイプはスタンダードを選択してください。
名前、表示名はAdminAlertと入力してください。
それ以外は入力不要です。画面最下部のトピックの作成ボタンをクリックしてください。
作成したトピックの詳細画面が表示されます。
サブスクリプションセクションのサブスクリプションの作成ボタンをクリックしてください。
サブスクリプションの情報を入力します。
トピックARNはデフォルトの先ほど作成したトピックのARNを指定します。
プロトコルはEメールを選択してください。
エンドポイントは受信可能なEメールアドレスを入力してください。
入力し終えたら、右下サブスクリプションの作成ボタンをクリックしてください。
エンドポイントに指定したEメールアドレスに確認メールが届きます。
リンクConfirm subscriptionをクリックしてください。
以下のような画面が表示されたら購読設定完了です。
購読解除する際はリンクclick here to unsubscribe.をクリックしてください。
メッセージが受信できるか確認してみましょう。
トピックの詳細画面に戻り、画面右上メッセージの発行ボタンをクリックしてください。
送信するメッセージの内容を入力する画面が表示されます。
件名はTestにしてください。
メッセージ構造はデフォルトすべての配信プロトコルに同一のペイロード。を選択してください。
エンドポイントに送信するメッセージ本文はHello World!にしてください。
入力したら、右下メッセージの発行ボタンをクリックしてください。
エンドポイントに指定したEメールアドレスにメッセージが送信されることを確認してください。
Removing Lab Resources
7.1 Remove resources created with CloudFormation
削除するリソースの箇条書き
- CloudFormationのスタック
- Systems Managerのステートマネージャーの関連付け
- S3バケット（
cf-templates-から始まるバケット） - SNSトピック
- SNSサブスクリプション
- Systems Managerのメンテナンスウィンドウ
- EC2 キーペア
- IAMロール
- IAMポリシー
- IAMユーザー（不要なら）
詳細は以下を参照ください。