【AWS研修レポート】Cloud Operations on AWS Day1 - 運用の基礎とIaC編
はじめに
こんにちは、山本です。
先月、AWSの運用にも携わっていることから運用について体系的に学びたいと思ったことがきっかけで、「Cloud Operations on AWS」という3日間の研修を受講しました。
この記事では、研修で学んだ内容をDay1〜Day3の3回に分けてレポートします。同じ研修を受講予定の方や、AWSの運用について学びたい方の参考になれば幸いです。
この記事について
AWS公式の「Cloud Operations on AWS」研修のDay1レポートです。
対象読者
- Cloud Operations on AWS研修を受講予定の方
- AWSの運用基礎を学びたい方
- IaC（Infrastructure as Code）に興味がある方
研修概要
- 研修名: Cloud Operations on AWS
- 期間: 3日間
この日のサマリ
| 項目 | 内容 |
|---|---|
| テーマ | 運用の基礎、アクセス管理、システム検出、デプロイ |
| 主要サービス | IAM, Organizations, SCP, AWS Config, Systems Manager, CloudFormation, Service Catalog |
| キーワード | 認証/認可, 最小権限の原則, IaC, タグ戦略, ドリフト検出 |
モジュール内容
モジュール1: 本講座の紹介
運用の定義と目的、Well-Architected Framework（運用上の優秀性）について学びました。
研修では、運用を以下のように定義していました。
運用の目的: システムを安定させ、かつ効率よく提供し続けること
この定義は自分の考えとも一致しており、納得感がありました。
運用期間に求められることは以下の通りです。
- システムを止めない
- インシデント・障害が起きない
- バージョンアップ、新規機能のリリースができる
- コストが最適化されている
Well-Architected Frameworkには6本の柱があります。
- 運用上の優秀性 ← 本研修のテーマ
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- 持続可能性
学び
トレーナーの「組織から設計していく」という言葉が印象的でした。技術だけでなく、組織の体制や文化も運用の質に影響するという視点です。
モジュール2: アクセス管理
IAM認証/認可、最小権限の原則、Organizations/SCPについて学びました。
運用との関連として、認証情報の漏洩リスクを下げることで安定性を高め、Organizations・SCPによるアカウント・権限の一元管理で効率化を図ります。
認証と認可の違いは以下の通りです。
| 概念 | 説明 | 例 |
|---|---|---|
| 認証 | 誰がAWSにサインインしているか | 社員証で本人確認 |
| 認可 | どんなリクエストを実行できるか | ポジションによって入れる部屋が異なる |
IAMユーザーとIAMロールは以下のように使い分けます。
- IAMユーザー: 認証の情報のみ持つ（ログインだけできる）
- IAMロール: 一時的なアクセス権限を付与する仕組み
- STS（Security Token Service）を使用
- 認証情報が漏洩しても影響が限定される
ポリシー評価の優先順位
- 明示的拒否があるか → YES：拒否
- 明示的許可があるか → YES：許可
- どちらも該当しない → 拒否（暗黙的拒否）
学び
IAMロールとSTSの仕組みを理解することで、「なぜアクセスキーをプログラムに埋め込むのが危険なのか」が明確になりました。
モジュール3: システム検出
CLI/Session Manager、AWS Config、Systems Managerについて学びました。
運用との関連として、AWS ConfigやConfigルールでシステム構成を把握することで安定性を高め、CLIやSession Managerで効率的にリソースを管理します。
なぜCLIを利用するのかを以下の表で比較します。
| 観点 | GUI | CLI |
|---|---|---|
| 学習コスト | 低い | 高い |
| 手順書の作成・管理コスト | 高い | 低い |
| 自動化 | 難しい | 容易 |
CLI活用によって、より効率の良いシステム提供につながります。
Session Managerのメリット
- IAMを利用した制御が可能
- IP許可やポート開放が不要
- 踏み台サーバーやキーペアの管理も不要
AWS Configの役割
- AWSリソースの設定・操作履歴の管理
- Configルールでコンプライアンス違反を検出
- 例：ストレージの暗号化必須、RDSのパブリックアクセス禁止
学び
Session Managerは、踏み台サーバーやキーペアの管理が不要になるという点で運用負荷を下げられそうです。
モジュール4: リソースのデプロイと更新
タグ戦略、AMI、Control Towerについて学びました。
デプロイ時に気を付ける4つの観点を以下にまとめます。
| 観点 | 内容 |
|---|---|
| 企業ポリシーを遵守する | 標準化、コンプライアンス要件 |
| 再現性がある | テンプレート、AMI、IaC |
| 追跡可能である | タグ、所有権、コスト、組織 |
| モニタリングされる | パフォーマンス、監査、ログ記録 |
タグ付け戦略の4ステップ
- タグ付けの目的を定義
- タグの命名規則を定義
- タグ利用の強制
- タグ運用の評価・改善
推奨される命名規則
- 小文字のみを使用
- 区切りはハイフンを使用
- タグは大文字と小文字が区別される点に注意
学び
タグ戦略は「後から整理しよう」と思っていると手遅れになりがちです。プロジェクト開始時に命名規則を決めておくことで、後のコスト配分やリソース管理が楽になります。
モジュール5: リソースデプロイの自動化
IaC、CloudFormation、Service Catalogについて学びました。
運用との関連として、一貫した方法でデプロイすることでリスクを減らし安定性を高め、手動でのリソース作成・管理をやめることで効率化します。
手作業には以下のデメリットがあります。
- 人によって操作手順が異なり、意図しない操作が発生する可能性がある
- 操作ミスが発生しやすい
CloudFormationの主要な構成要素を以下にまとめます。
| 要素 | 説明 |
|---|---|
| Resources（必須） | スタックリソースとそのプロパティを指定 |
| Parameters | スタック作成時に指定可能な値 |
| Outputs | スタックから値を返却（テンプレート間で値を共有） |
| Mappings | キーごとに名前と値のペアを保存 |
便利な組み込み関数
!Ref: 論理IDを参照して作成されたリソースのIDを取得DependsOn: リソース作成順序を明示的に指定
ドリフトとは、CloudFormationで作成したリソースを手作業で変更した際のコードとの差異です。検出方法としては、CloudFormationコンソール上、またはAWS Configルールで設定できます。
ベストプラクティス
- テンプレートを再利用できる状態にする（変数部分を動的に参照）
- テンプレートに認証情報を埋め込まない
- ドリフトを発生させない、早めに検出する
- スタック更新前に変更セットを作成して差分を確認
学び
CloudFormationのParametersやOutputsの仕組みを理解できたことで、現場で使用しているテンプレートの設計意図が読み取りやすくなりました。特に!Refを使ったリソース間の参照や、DependsOnによる依存関係の明示は、テンプレートを読む際の重要なポイントです。
ラボ体験
ラボ1: AWS Systems Manager と AWS Config を使って AWS リソースを監査する
Systems ManagerとAWS Configを使った管理・監査を体験しました。
実施内容は以下の通りです。
- タスク1: Systems Manager インベントリをセットアップ
- タスク2: Session Manager を使用して EC2 インスタンスにログイン
- タスク3: AWS Config を有効にし、レコーダーをオンにする
- タスク4: EC2 インスタンスのコンプライアンスをチェックするルールを作成
- タスク5: IAM ユーザーアクセス許可を監査するルールを作成
学び
以下の部分が業務に活かせるかもしれないと思い学びと感じました。
- Systems Managerのインベントリ機能で、EC2インスタンスのメタデータを監査できる
- Session Managerを使えば、SSHキーなしでEC2にアクセスできる
- AWS Configルールで、リソースのコンプライアンス状態を継続的にチェックできる
ラボ2: Infrastructure as Code
CloudFormationを使ったIaCを体験しました。
実施内容は以下の通りです。
- タスク1: CloudFormation テンプレートを Infrastructure Composer で更新
- タスク2: CloudFormation スタックを更新
- タスク3: ドリフトを検出
学び
以下の部分が機会があれば業務に活かせるかもしれないと思いました。
- Infrastructure Composerを使えば、視覚的にテンプレートを編集できる
- スタック更新前に変更セットで差分を確認できる
- 手動変更によるドリフトを検出し、コードと実環境の差異を把握できる
今後試してみたいこと
- CloudFormationテンプレートの理解を深める: 現場で使用しているテンプレートを読み解き、設計意図を理解する
- AWS Configルールの活用: コンプライアンス違反を自動検出する仕組みを現場に導入できないか検討する
- Session Managerの導入検討: SSH接続をSession Managerに置き換えることで、キーペア管理の負荷を減らせないか検討する
最後に
Day1では、運用の基礎概念から始まり、アクセス管理、システム検出、IaCまで学びました。「運用の目的＝システムを安定させ、かつ効率よく提供し続けること」という定義は、日々の業務で意識したいポイントです。
CloudFormationのテンプレート構造を理解できたことで、現場のコードが読みやすくなりました。
次回のDay2では「高可用性とモニタリング」について学びます。
参考リンク
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました
