AWS認定資格 WEB問題集＆徹底解説DevOpsエンジニア プロフェッショナル（DOP）

会員登録/ログイン

1. サービス概要

【現状】AWS OpsWorks は提供を終了しています。 OpsWorks Stacks は 2024年5月26日、OpsWorks for Chef Automate は 2024年5月5日、OpsWorks for Puppet Enterprise は 2024年3月31日にサービス終了（EOL）を迎え、新規・既存を問わず利用できなくなりました。 コンソール・API ともに使えず、OpsWorks が起動した EC2 インスタンスはアカウントに残るものの、OpsWorks から管理することはできません。 後継（移行先）は AWS Systems Manager（Application Manager、State Manager、Run Command、Patch Manager など）です。Chef Automate / Puppet Enterprise の利用者には、Chef / Puppet 側の SaaS や EC2 上での自己管理も案内されていました。

OpsWorks は、Chef や Puppet を使って EC2 インスタンスやオンプレミスサーバーの構成を自動化するサービスでした。 DOP-C02 の試験ガイドには、構成管理サービスの選定（タスク 2.1）や「アプリケーションの構成を望ましい状態へ自動で収束させる」（タスク 2.3）の例として、現在も OpsWorks の名前が Systems Manager と並んで残っています。 試験対策としては、旧 OpsWorks の考え方を理解したうえで、同じ要件を現在は Systems Manager などでどう実現するかを押さえるのが要点です。

2. 主な特徴と機能

2.1 OpsWorks Stacks（提供終了）

アプリケーションを「スタック → レイヤー（Web 層・DB 層など）→ インスタンス」という単位で管理し、各レイヤーに Chef のレシピ（構成手順のコード）を割り当てる仕組みでした。アプリのデプロイもスタック単位で行えました。

2.2 ライフサイクルイベント

Stacks はインスタンスの状態に応じて自動でレシピを実行しました。Setup（起動完了時）、Configure（スタック内のインスタンスがオンライン / オフラインになったとき、全インスタンスで実行）、Deploy、Undeploy、Shutdown の 5 種類です。 特に Configure は「サーバーの増減に合わせて全台の設定（例: ロードバランサーや接続先リスト）を更新する」用途で問われました。

2.3 インスタンスの種類と自動修復

常時稼働、時間ベース、負荷ベースのインスタンスがあり、エージェントの応答が途絶えたインスタンスを自動で置き換える auto healing 機能も備えていました。

2.4 OpsWorks for Chef Automate / Puppet Enterprise（提供終了）

Chef Automate サーバーや Puppet マスターを AWS が運用するマネージドサービスでした。既存の Chef / Puppet 資産をそのまま AWS で使いたい組織向けの選択肢でした。

2.5 後継機能との対応関係

• スタック・レイヤー・アプリの管理: CloudFormation でリソースを定義し、Systems Manager Application Manager でアプリケーション単位に運用情報を集約する。
• レシピの定期適用（望ましい状態の維持）: State Manager の関連付け。Chef レシピは AWS-ApplyChefRecipes、Ansible は AWS-ApplyAnsiblePlaybooks などのドキュメントで実行できる。
• 単発のコマンド実行: Run Command。
• auto healing・負荷ベース / 時間ベースのスケーリング: EC2 Auto Scaling（ELB ヘルスチェック、動的スケーリング、スケジュールされたアクション）。
• OS パッチ: Patch Manager とメンテナンスウィンドウ。
• 構成の監査・ドリフト検出: AWS Config ルールと自動修復。
• アプリ設定・機能フラグの配信: AWS AppConfig。

3. アーキテクチャおよび技術要素

旧 OpsWorks Stacks の典型構成は次のとおりでした。

1. スタックを作成し、レイヤーごとにインスタンスとカスタムレシピ（S3 や Git リポジトリのクックブック）を設定する。
2. インスタンス上の OpsWorks エージェントがライフサイクルイベントに応じてレシピを実行する。
3. インスタンスの増減時に Configure イベントで全台の設定を更新し、Deploy でアプリを配布する。

現在の同等構成（Systems Manager 中心）は次のようになります。

1. CloudFormation で Auto Scaling グループ、起動テンプレート、ロードバランサーを定義する。
2. インスタンスに SSM Agent とインスタンスプロファイル（AmazonSSMManagedInstanceCore）を与えてマネージドノードにする。
3. タグを対象にした State Manager の関連付けで、構成（Chef レシピ・Ansible・シェル）を定期的に適用し、ドリフトを自動で戻す。新しく起動したインスタンスにも自動で適用される。
4. Patch Manager、Inventory、Config で運用・監査し、Application Manager でアプリ単位に可視化する。

4. セキュリティと認証・認可

• 旧 OpsWorks: サービスロールとインスタンスプロファイルに加え、スタックごとのユーザー権限レベル（表示 / デプロイ / 管理など）や SSH ユーザーの管理機能を持っていた。
• 後継の権限設計: マネージドノードには AmazonSSMManagedInstanceCore を付与し、State Manager や Run Command の実行権限は IAM で最小権限に絞る。
• SSH の置き換え: Session Manager を使えば、受信ポートを開けず鍵も配らずにシェルへ接続でき、操作ログも残せる。
• 機密情報: レシピに埋め込んでいたパスワードなどは Parameter Store（SecureString）や Secrets Manager へ移す。
• 監査: Systems Manager の操作は CloudTrail に記録され、関連付けの準拠状況は Config やコンプライアンス画面で確認できる。

5. 料金形態

OpsWorks は提供を終了しているため、現在は利用も課金も発生しません。参考までに、旧 OpsWorks Stacks は EC2 インスタンスの管理自体に追加料金がかからず（オンプレミスサーバーの管理は有料）、Chef Automate / Puppet Enterprise は管理ノード数と時間に応じた課金でした。

• 後継の Systems Manager: State Manager、Run Command、Patch Manager など多くの機能は EC2 に対して追加料金なしで使える。高度なインスタンス層や一部の機能は有料。
• その他: EC2、EBS、ロードバランサーなどのリソース料金は通常どおり発生する。

6. よくあるアーキテクチャ・設計パターン

• 構成の自動収束: State Manager の関連付けを一定間隔で実行し、手作業による設定変更を自動で元に戻す（旧 OpsWorks のレシピ適用に相当）。
• Chef 資産の再利用: 既存のクックブックを S3 などに置き、AWS-ApplyChefRecipes で Chef サーバーなしに適用する。
• スケール時の再構成: Auto Scaling のライフサイクルフックや EventBridge のイベントを起点に Run Command / Automation を実行する（旧 Configure イベントに相当）。
• イミュータブル化: 構成を EC2 Image Builder のゴールデン AMI に焼き込み、起動後の構成作業そのものを減らす。
• パッチの標準化: Patch Manager のパッチベースラインとメンテナンスウィンドウで定期適用し、準拠状況を集約する。

7. 設定・デプロイ手順（ハンズオン例）

OpsWorks 自体は操作できないため、後継の Systems Manager で「望ましい状態の維持」を構成する例を示します。

1. EC2 インスタンスに AmazonSSMManagedInstanceCore を含むインスタンスプロファイルを付け、フリートマネージャーでマネージドノードとして表示されることを確認する。
2. State Manager で関連付けを作成し、ドキュメント（例: AWS-ApplyChefRecipes）、対象（タグ Role=web）、スケジュール（例: 30 分ごと）を指定する。
3. コンプライアンス画面で関連付けの準拠状況を確認し、意図的に設定を変えて次回実行で元に戻ることを確かめる。

8. 試験で問われやすいポイント