AWS Well-Architected Framework 入門：オペレーショナルエクセレンスの柱を Session Manager + CloudWatch + CloudTrail でハンズオンしてみた

はじめに

こんにちは。クラスメソッドオペレーションズの藤瀨です。

Well-Architected Framework ハンズオンシリーズの第 2 回です。前回はシリーズ全体で扱う AWS Well-Architected Framework の概要を整理したので、今回から実際にハンズオンを行っていきます。最初の柱は「オペレーショナルエクセレンス（Operational Excellence）」です。

この柱が扱うのは、システムを運用しながら継続的に改善していくための仕組みづくりです。
このブログでは、EC2 インスタンスを 1 台使って以下の 3 点を体験します。

• Session Manager による安全な運用アクセス（SSH 鍵・セキュリティグループの穴あけ不要）
• AWS CloudTrail による操作証跡の記録
• Amazon CloudWatch によるしきい値ベースのアラームの設定

オペレーショナルエクセレンスとは

手を動かす前に、改めてこの柱の中身を整理しておきます。
AWS Well-Architected Framework では、オペレーショナルエクセレンスのベストプラクティス領域として「組織」「準備」「運用」「進化」が挙げられています。また、ビジネス成果を支えるために、ワークロードや運用の状況を把握し、フィードバックループを通じて継続的に改善することが重要とされています。
チームの組織づくり、ワークロードの設計、大規模での運用、そして時間をかけた改善という観点のベストプラクティスを含んでいる柱です。

この柱には 8 つの設計原則があります。

• ビジネスの成果を中心にチームを組織する： リーダーシップとオペレーティングモデルが、チームの成果を左右する
• 可観測性を実装し、実用的な洞察を得る： KPI を定め、テレメトリを活用して迅速に判断・行動する
• 安全に自動化できる部分は自動化する： ガードレール（レート制御・エラーしきい値・承認）を設けた上で自動化する
• 小さく・頻繁で・戻しやすい変更を行う： 変更の影響範囲を小さくし、失敗時にすぐ切り戻せるようにする
• 運用手順を頻繁に見直す： 定期的にレビューし、ギャップがあれば手順を更新する
• 失敗を想定しておく： 障害シナリオを洗い出し、対応手順を事前にテストしておく
• すべての運用イベント・メトリクスから学ぶ： 障害や運用イベントの教訓をチーム・組織全体で共有する
• マネージドサービスを活用する： 運用負荷を AWS 側に任せられる部分は積極的に任せる

今回のハンズオンでは、この中でも「可観測性の実装」（CloudWatch でのアラーム設定）、「すべての運用イベントから学ぶ」（CloudTrail での操作履歴の可視化）、そして安全な運用アクセスという実務的な観点（Session Manager による EC2 インスタンスへの接続）を中心に体感していきます。

具体的な手順

大まかな手順は以下の通りです。

① Session Manager 用の IAM ロールを作成する
② EC2 インスタンスを起動する
③ Session Manager で接続する
④ CloudTrail で操作履歴を確認する
⑤ CloudWatch でアラームを設定する

各ステップの詳細を順番に見ていきます。

① Session Manager 用の IAM ロールを作成する

1. AWS マネジメントコンソール上部の検索ボックスで IAM を検索してクリックします。
2. ページ左側のナビゲーションペインで、「ロール」を選択し、ページ上部の［ロールを作成］を押下します。
   
3. ステップ 1 の「信頼されたエンティティタイプ」では「AWS のサービス」を、「ユースケース」では「EC2」を選択します。
4. ステップ 2 の「許可ポリシー」の検索窓に「AmazonSSMManagedInstanceCore」と入力し、表示されたポリシーにチェックをつけて［次へ］を押下します。
   
5. ステップ 3 のロール名や説明はご自身でわかりやすいものを設定してください。このブログではロール名をEC2-SSM-Roleとしました。［ロールを作成］を押下して正常にロールが作成されたことを確認します。

② EC2 インスタンスを起動する

1. AWS マネジメントコンソール上部の検索ボックスで EC2 を検索してクリックします。
2. EC2 コンソールを開き、「インスタンスを起動」をクリックします。
3. 「名前とタグ」にwaf-oe-handsonなど、後で見て分かる名前を入力します。
4. 「アプリケーションおよび OS イメージ（AMI）」で「Amazon Linux 2023」を選択します（無料枠の対象になるかどうかは、AMI・インスタンスタイプ・アカウント作成日・利用状況によって異なるため、コンソール上で「無料利用枠対象」と表示されていることを確認してください）。
5. 「インスタンスタイプ」で無料利用枠対象の t3.micro を選択します（同様に「無料利用枠対象」と表示されることを確認してください）。
6. 「キーペア（ログイン）」で「キーペアなしで続行」を選択します。Session Manager 経由で接続するため、SSH 用のキーペアは不要です。
7. 「ネットワーク設定」で、VPC はデフォルト VPC のまま、「自動割り当てパブリック IP」を「有効化」に設定します。
8. 同じく「ネットワーク設定」内の「ファイアウォール（セキュリティグループ）」で「セキュリティグループを作成」を選びます。デフォルトで表示される「SSH（22 番ポート）を許可」のルールは削除し、インバウンドルールが 0 件の状態にしてください。
   今回のハンズオンでは、SSM Agent が Systems Manager 関連エンドポイントへ HTTPS で通信できるよう、アウトバウンドはデフォルトの「すべてのトラフィックを許可」のままとします。本番環境では、必要な宛先・ポートに絞る、または VPC エンドポイントを利用する構成を検討してください。
   セキュリティグループ名と説明は自由に設定して構いません。今回は waf-oe-handson-sg としました。
   
9. 「ストレージを設定」はデフォルトの 8 GiB（gp3）のままにします。
10. スクロールして「高度な詳細」を開き、「IAM インスタンスプロファイル」で①で作成したEC2-SSM-Roleを選択します。ここを設定し忘れると Session Manager で接続できないので、必ず確認してください。
    
11. すべて設定できたら「インスタンスを起動」をクリックします。起動直後は SSM エージェントの起動待ちで数分 Session Manager に接続できないことがあるので、少し時間をおいてから次のステップに進みます。

③ Session Manager で接続する

1. EC2 コンソールでインスタンスを選択します。
2. 検索窓に先ほど起動したインスタンス名（私の場合は waf-oe-handson）を入力し、表示されたインスタンスにチェックをつけます。
3. ［接続］を押下し、「SSM Session Manager」タブを選択します。
   
4. 画面下部の［接続］ボタンをクリックすると、ブラウザ上でシェルが開きます。SSH 鍵を使わず、SSH でパブリック IP に直接接続しなくても、ブラウザから接続できることを確認してください。

④ CloudTrail のイベント履歴で API 操作履歴を確認する

1. AWS マネジメントコンソール上部の検索ボックスで CloudTrail を検索してクリックします。
2. ページ左側のナビゲーションペインで「イベント履歴」を選択します。
3. ②〜③で行った EC2 インスタンス起動に関する API コールや、Session Manager のセッション開始に関する管理イベントが記録されていることを確認します。
   
   CloudTrail のイベント履歴で確認できるのは、主に「誰が、いつ、どの AWS API を呼び出したか」という管理イベントです。たとえば、EC2 インスタンスの起動や、Session Manager セッションの開始イベントを確認できます。ただし、無料で確認できるのは過去 90 日分のものです。

一方で、Session Manager セッション中に実行したシェルコマンドやその出力は、CloudTrail には記録されません。これらを記録するには、Session Manager のログ出力設定で CloudWatch Logs または Amazon S3 への出力を有効化する必要があります。

⑤ CloudWatch でアラームを設定する

1. AWS マネジメントコンソール上部の検索ボックスで CloudWatch を検索してクリックします。
2. ページ左側のナビゲーションペインから「アラーム」を選択し、［アラームの作成］を押下します。
   
3. 「メトリクスを選択」→「EC2」→「インスタンス別メトリクス」を選び、対象インスタンスのCPUUtilizationにチェックを入れて［メトリクスの選択］を押下します。
   
4. 「期間」はデフォルトの 5 分のままにします。
5. 「条件」で、しきい値の種類は「静的」、「CPUUtilization が次の時」は「より大きい」、値の欄に 70 を入力し、［次へ］をクリックします。
6. ［通知の追加］を押下して「新しいトピックの作成」を選択し、トピック名（例: waf-oe-alarm-topic）を入力します。「通知を受け取る E メールエンドポイント」に自分のメールアドレスを入力し、［トピックの作成］をクリックします。
7. ［次へ］を押下し、アラーム名（例: EC2-CPU-High）を入力してさらに［次へ］をクリックします。内容を確認して［アラームの作成］を押下します。
8. 登録したメールアドレス宛に届く「AWS Notification - Subscription Confirmation」メール内の「Confirm subscription」リンクをクリックし、購読を確定させます。ここを忘れると、アラームが発火しても通知メールは届きません。
9. ③の手順通りに Session Manager 経由で作成したインスタンスに接続し、以下のコマンドで、vCPU 数分の yes プロセスを起動します。

for i in $(seq 1 $(nproc)); do yes > /dev/null & done

10. 数分待つと、CloudWatch のアラーム一覧でステータスが「OK」→「アラーム状態」に変わり、登録したメールアドレスに通知メールが届くことを確認できます（通知メールが届くまでには 5 分以上かかる場合があります）。
    
    
11. 確認できたら、負荷をかけたプロセスを必ず停止します。

pkill yes

使用したサービスと料金の考え方

今回使用したサービスの無料枠は以下の通りです。

おわりに

このブログでは、Session Manager 経由での EC2 インスタンスへの安全な接続方法を体験し、CloudTrail と CloudWatch で操作履歴や正常・異常時の状態を可視化しました。
これらは、オペレーショナルエクセレンスの柱の設計原則である「可観測性を実装し、実用的な洞察を得る」「すべての運用イベント・メトリクスから学ぶ」と関連する内容です。

今回のハンズオンを通して、概念としての知識しかなかった Well-Architected Framework を、実際の運用をイメージしながら理解する第一歩を踏み出せたと感じます。
引き続き、次回は「セキュリティ」の柱に基づき、IAM 設計と GuardDuty を使ったハンズオンを行う予定です。

最後までお読みいただきありがとうございました！

参考リンク

• Operational Excellence Pillar
• Operational excellence: Design principles
• Operational excellence: Definition
• Setting up Session Manager
• Session Manager でセッションを開始する
• CloudTrail コンソールで証跡を作成する
• Using Amazon CloudWatch alarms
• インスタンスの CloudWatch アラームを作成する

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。

※2026年1月 アノテーション㈱から社名変更しました。