はじめに
本日、2025年9月30日より、AWS Certified CloudOps Engineer - Associate (SOA-C03)の受験が開始されました。
これは新しい資格...ではなく、かつてのSysOps Administrator(SOA-C02)がリニューアルされたものなのですが、2026年度のJapan All AWS Certifications Engineersの要件が、SysOps AdministratorでよいのかCloudOps Engineerも新規で取らないといけないのか...というのが不安になり、ならもう取ってしまえばいいよね！！！ということで受験してきました。
一応後述する認定資格維持の公式記事もあるので、おそらく、多分、きっと、取得しなくても大丈夫...なんだと思います。
心配性なんです。
後は、まあ、現在有効資格で15冠なので、名称違うのであれば16冠«٩(´ ꒳ `)۶»ﾜｸﾜｸ とかもあったりします。
認定資格の維持とバッジについて
AWS Certified CloudOps Engineer – Associate への名称変更は、SOA-C03 に合格した方のみに適用されます。AWS Certified SysOps Administrator – Associate を保有している方に対して遡及的に変更されることはありません。認定資格の有効性、再認定、および認定ステータスの維持について知っておくべきことは以下の通りです：
- **AWS Certified SysOps Administrator – Associate 認定資格を取得済みの方**は、AWS Certified CloudOps Engineer – Associate を取得する必要はありません。認定資格バッジの表示を継続でき、有効期限まで有効なままです。
- **AWS Certified SysOps Administrator – Associate 認定資格を取得済みで、その後 AWS Certified CloudOps Engineer – Associate を取得した方**は、各認定資格に対して別々のバッジを持つことになります。AWS Certified SysOps Administrator – Associate 認定資格は有効期限まで有効なままです。今後、これらの方は以下のいずれかを選択できます：
- 最新バージョンの試験に合格することで、AWS Certified CloudOps Engineer – Associate 認定資格を継続して再認定する
- 認定資格の有効期限前に AWS Certified DevOps Engineer – Professional 認定資格にアップグレードすることで、両方の認定資格を再認定する
- **有効な AWS Certified DevOps Engineer – Professional と AWS Certified SysOps Administrator – Associate 認定資格を保有している方**は、AWS Certified DevOps Engineer – Professional 試験の最新バージョンに合格することで、両方の認定資格を継続して再認定できます。
試験概要
試験内容
- コンテンツ分野 1: モニタリング、ログ記録、分析、修復、パフォーマンスの
最適化 (採点対象コンテンツの 22%) - コンテンツ分野 2: 信頼性と事業の継続性 (採点対象コンテンツの 22%)
- コンテンツ分野 3: デプロイ、プロビジョニング、オートメーション (採点対象
コンテンツの 22%) - コンテンツ分野 4: セキュリティとコンプライアンス (採点対象コンテンツの 16%)
- コンテンツ分野 5: ネットワークとコンテンツ配信 (採点対象コンテンツの 18%)
解答タイプ
試験には次の 2 種類の設問があります。
- 択一選択問題 : 正しい選択肢が 1 つ、誤った選択肢 (不正解) が 3 つ提示される。
- 複数選択問題 : 5 つ以上の選択肢のうち、正しい選択肢が 2 つ以上ある。
択一選択問題と複数選択問題: 設問の記述に最もよく当てはまるもの、または正解となるものを 1 つ以上選択します。不正解の選択肢は、知識や技術が不十分な受験者が選択してしまいそうな、設問内容と一致するもっともらしい解答になっています。
未解答の設問は不正解とみなされます。推測による解答にペナルティはありません。試験には、スコアに影響する設問が 50 問含まれています。これらの設問には、択一選択問題と複数選択問題が含まれます。採点対象の択一選択問題、複数選択問題の各設問に正解すると、1 問分の点が加算されます。
コメント
SysOps Administratorの際は存在したラボ試験はどうやら無いようです。
また、AIFやMLAで初登場した、「並べ替え」、「内容一致」、「ケーススタディ」タイプも出題されないようです。
ラボ試験を体験したことがなかったため、今回の受験して合格しよう！！を目標とするとハードルが上がることが予想されることから無くてよかった...と安心しました。
新旧試験の違い
対照比較
| SOA-C02 の分野 | SOA-C03 の分野 |
|---|---|
| 分野 1: モニタリング、ロギング、および修復 (20%) | 分野 1: モニタリング、ログ記録、分析、修復、パフォーマンスの最適化 (22%) |
| 分野 2: 信頼性と事業の継続性 (16%) | 分野 2: 信頼性と事業の継続性 (22%) |
| 分野 3: デプロイ、プロビジョニング、およびオートメーション (18%) | 分野 3: デプロイ、プロビジョニング、オートメーション (22%) |
| 分野 4: セキュリティとコンプライアンス (16%) | 分野 4: セキュリティとコンプライアンス (16%) |
| 分野 5: ネットワークとコンテンツ配信 (18%) | 分野 5: ネットワークとコンテンツ配信 (18%) |
| 分野 6: コストとパフォーマンスの最適化 (12%) | - |
SOA-C03 でのコンテンツの追加
- タスク 1.1 に、次のコンテンツが追加されました。
- EC2 インスタンス、Amazon Elastic Container Service (Amazon ECS)クラスター、または Amazon Elastic Kubernetes Service (Amazon EKS)クラスターからメトリクスとログを収集するように CloudWatch エージェントを設定して管理する。
- タスク 3.1 に、次のコンテンツが追加されました。
- CloudFormation と AWS Cloud Development Kit (AWS CDK) を使用し、リソーススタックを作成して管理する。
- タスク 4.1 に、次のコンテンツが追加されました。
- コンプライアンス要件 (リージョンやサービスの選択など) を適用する。
- タスク 5.3 に、次のコンテンツが追加されました。
- CloudWatch ネットワークモニタリングサービスを設定して分析する。
SOA-C03 でのコンテンツの削除
- タスク 5.2 から、次のコンテンツが削除されました。
- S3 の静的ウェブサイトホスティングを設定する。
SOA-C03 でのコンテンツの再分類
- タスク 4.2 の VPN はタスク 5.1 に移動しました。
- SOA-C02 のタスク 6.1 と タスク 6.2 は、SOA-C03 ではタスク 1.3 に移動しました。
コメント
ECS/EKSをはじめとしたコンテナ関連サービス、またIaCとしてCloudFormationだけでなくCDKが含まれるようになったという点が大きいのでしょうか。
ECS/EKSに関しては他の試験でも範囲になったことがあるため、この試験向けに特段苦戦することはないように思えます。が、CDKは個人的に苦手としているもののため不安がありました。
個人的に、VPC Latticeが試験範囲のサービス/機能に含まれていなかったのは不幸中の幸い...なのかなと思います。Lattice、むずいんですよね(個人的感想)。
参考
学習
後述する公式の模擬問題(20+65問)にてこの分野怪しいな...と感じたものを中心に、以下を参考に学習しました。
Skill Builder
-
Official Practice Question Set: AWS Certified CloudOps Engineer - Associate (SOA-C03 - 日本語)
- 公式模擬問題 無料枠 20問
-
Official Pretest: AWS Certified CloudOps Engineer - Associate (SOA-C03 - 日本語)
- 公式模擬問題 有料枠 65問
- Building VPC, S3, EC2, and RDS Products with AWS Service Catalog (日本語)
- Implementing Multi-Region Backup with Amazon S3 Cross-Region Replication (日本語)
Black Belt
- Savings Plans
- Amazon ECS ⼊⾨
- AWS Fargate ⼊⾨
- AWS DataSync
- AWS CDK 概要 (Basic #1)
- AWS Application Discovery Service の概要
- AWS Backup で考える DR 戦略#1 基本編
- AWS Service Catalog
- AWS Control Tower 手順編 AWS Control Tower の有効化
- AWS Control Tower 基礎編
- AWS Control Tower 機能紹介編
- AWS Certificate Manager
参考書
-
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ
これは必読です。かなり最近リリースされたもので、この試験対策本と言ってももしかすると過言ではないかも？？
ブログ
- 【開催報告 & 資料公開】AWS 春の Observability 祭り 2025
- AWS Global Acceleratorとは？グローバル展開を加速させる高可用性ソリューション
- Amazon Application Recovery Controller（Amazon ARC）を利用した高可用性の実現～前編・解説編～
- User NotificationsとSNSの違いを知りたい
個人的受験前メモ
以下、受験勉強用に作成した、学習用メモです。この範囲の内容が出題された、というわけではないです。
あくまで自分用メモ
InspectorとDetectiveの違い
Amazon Inspector
概要
Amazon Inspector は脆弱性評価サービスで、アプリケーションのセキュリティ評価を自動化
主な機能
- EC2 インスタンスとコンテナイメージのスキャン
- ソフトウェア脆弱性の検出
- ネットワーク到達可能性の分析
- 継続的な評価とモニタリング
検出対象
- CVE(Common Vulnerabilities and Exposures)データベースに基づく既知の脆弱性
- パッケージの脆弱性
- アプリケーションの脆弱性
- 意図しないネットワークアクセス経路
使用シーン
例：EC2インスタンスで古いバージョンのApacheが動作している場合
→ Inspector が脆弱性を検出し、CVE番号と修正方法を提示
Amazon Detective
概要
Amazon Detective はセキュリティ調査・分析サービスで、セキュリティインシデントの根本原因分析を支援
主な機能
- セキュリティデータの収集と分析
- 視覚的な調査ダッシュボード
- インシデントの時系列分析
- 関連するリソースやアクティビティの特定
データソース
- VPC Flow Logs
- DNS ログ
- CloudTrail イベントログ
- GuardDuty の検出結果
使用シーン
例：GuardDuty がマルウェア通信を検出した場合
→ Detective で該当インスタンスの通信パターン、
関連するIPアドレス、時系列での活動を視覚化して分析
主要な違い
| 項目 | Inspector | Detective |
|---|---|---|
| 目的 | 脆弱性の予防的検出 | インシデント後の調査・分析 |
| タイミング | 継続的なスキャン | インシデント発生後 |
| 対象 | アプリケーション・インフラ | ログデータ・ネットワーク活動 |
| アプローチ | プロアクティブ | リアクティブ |
| 出力 | 脆弱性レポート | 調査ダッシュボード |
実際の運用での使い分け
Inspector の使用例
- 開発・運用段階での脆弱性チェック
- コンプライアンス要件への対応
- CI/CDパイプラインへの組み込み
Detective の使用例
- セキュリティアラートの詳細調査
- インシデントレスポンスでの根本原因分析
- フォレンジック調査の支援
補完関係
Inspector：脅威が実現する前の脆弱性を特定
Detective：脅威が実現した後の影響範囲と原因を分析
効果的なセキュリティ戦略では、Inspector で事前に脆弱性を修正し、万が一インシデントが発生した場合は Detective で迅速な調査を行うという組み合わせが重要です。
Global AcceleratorとCloudFrontの違い
Global Accelerator
- オリジンとなるサーバーに毎回アクセスすることを前提に、通信経路のレイテンシーを減少させるためにAWSのプライベートネットワークを利用する仕組みです。
- 毎回元となるサーバーに情報を取得するアクセスが発生するため、動的なコンテンツに適しています。
CloudFront
- 初回の通信でキャッシュをユーザーの最寄りのエッジロケーションに保存することで、近い距離からコンテンツを返せるようにして通信距離を最短にします。
- キャッシュを利用するため、HTMLや画像などを取り扱う静的コンテンツに最適です。
表での整理
| 項目 | Global Accelerator | Amazon CloudFront |
|---|---|---|
| プロトコル | TCP/UDP | HTTP/HTTPS |
| ポート番号 | 任意 | 80/443 |
| キャッシュ | 非対応 | 対応 |
| 目的 | 高可用性なネットワーク | コンテンツ配信の高速化 |
| 想定される用途 | ゲーム、IoT、リアルタイム通信 | Webサイト、動画・音声の配信 |
参考
ECSのスケーリングポリシー
ECS のスケーリングポリシーには、それぞれ異なる用途と動作特性があります。以下に4つのポリシーを比較説明します。
予測オートスケーリング(Predictive Auto Scaling)
特徴
- 履歴データに基づく予測でスケーリングを事前実行
- 機械学習アルゴリズムを使用してトラフィックパターンを分析
動作メカニズム
- 最低14日間のメトリクス履歴を分析
- 日次・週次の定期的なパターンを学習
- 需要増加の前にリソースを事前準備
制限事項
- ランダムなトラフィックには不適切
- 履歴データが必要(最低2週間)
ターゲット追跡スケーリング
特徴
- 指定したメトリクス値を維持するように自動調整
- 最もシンプルで直感的な設定
動作メカニズム
- 目標値(例：CPU使用率70%)を設定
- 実際の値が目標を上回る/下回ると自動でスケール
- PIDコントローラーのような動作
ステップスケーリングポリシー
特徴
- 段階的な閾値に基づいてスケーリング量を調整
- より細かい制御が可能
動作メカニズム
- 複数の閾値レベルを設定
- 各レベルに対して異なるスケーリング量を定義
- アラーム状態に応じて適切なステップを実行
スケジュールされたスケーリング
特徴
- 時間ベースでのスケーリング実行
- 予定された時刻に容量を変更
動作メカニズム
- Cron式または固定スケジュールを使用
- 指定時刻に最小/最大/希望容量を変更
比較表
| ポリシー | 反応速度 | 設定複雑度 | 予測可能性 | 適用範囲 |
|---|---|---|---|---|
| 予測 | 事前対応 | 低 | 高(定期パターン) | 限定的 |
| ターゲット追跡 | 中 | 低 | 中 | 汎用的 |
| ステップ | 高 | 高 | 中 | 専門的 |
| スケジュール | 計画的 | 低 | 高(時間ベース) | 限定的 |
参考
Service Catalogについて
AWS Service Catalog は、組織が AWS 上で承認済みの IT サービスのカタログを作成・管理するためのサービスです。
AWS Service Catalogポートフォリオの制約
起動(Launch)制約
- 目的: AWS リソースのプロビジョニングに使用される製品に IAM ロールを割り当て
- 機能: エンドユーザーの権限に関係なく、指定されたロールでリソースをプロビジョニング
- 利点: セキュリティを保ちながら必要なリソースの作成を可能にする
通知(Notification)制約
- 目的: Amazon SNS トピックに製品の通知をストリーミング
- 対象イベント:
- プロビジョニング開始/完了
- 更新開始/完了
- 終了開始/完了
- 利点: 製品のライフサイクル変更を関係者に自動通知
タグの更新(Tag Update)制約
- 目的: 製品のプロビジョニング後にタグを更新することを許可
- 機能: プロビジョニング済み製品のタグ変更の制御
- 用途: 運用中のリソースのタグ管理
StackSet制約
StackSet制約は、AWS CloudFormation StackSetsを使用して、複数のAWSアカウントおよびリージョンにわたって製品を一括デプロイするための制約
マルチアカウントデプロイ
- 組織内の複数のAWSアカウントに同じ製品を同時デプロイ
- AWS Organizationsとの統合により、組織単位(OU)単位でのデプロイも可能
- アカウントの追加時に自動デプロイ(Auto Deployment)の設定も可能
マルチリージョンデプロイ
- 指定した複数のリージョンに同時デプロイ
- リージョン間でのリソース整合性を保持
- 災害復旧やコンプライアンス要件への対応
テンプレート(Template)制約
- 目的: エンドユーザーが製品を起動するときに使用可能なオプションを制限
- 機能:
- CloudFormationテンプレートのパラメータ値を制限
- 許可される値の範囲を設定
- デフォルト値の強制
- 例: インスタンスタイプや利用可能なリージョンの制限
タグとTagOptionの違い
タグ
- 定義: AWS リソースに直接付与される標準的なキー・バリューペアのメタデータ
- 用途: リソースの分類、管理、課金追跡、検索などに使用
- 適用範囲: プロビジョニング後のAWSリソースに直接付与される
- 管理: リソース作成後に追加・変更・削除が可能
TagOption
- 定義: Service Catalog固有の機能で、製品やポートフォリオに事前定義できるタグの「テンプレート」
- 用途: 組織全体でタグの標準化と一貫性を確保
- 適用範囲: Service Catalogの製品(Product)やポートフォリオ(Portfolio)レベルで定義
- 管理: 管理者が事前に定義し、エンドユーザーがプロビジョニング時に選択
主な違い
管理レベル
- タグ: リソースレベルで個別管理
- TagOption: Service Catalogレベルで組織的管理
標準化
- タグ: 自由形式で設定可能
- TagOption: 事前定義された選択肢から選択
ガバナンス
- タグ: 後から自由に変更可能
- TagOption: 管理者による統制されたタグ付け
参考
- Black Belt-Service Catalog
- Skill Builder-Building VPC, S3, EC2, and RDS Products with AWS Service Catalog
S3バケットのレプリケーション
レプリケーションの基本原則
- 単方向性: S3レプリケーションは基本的に単方向
- Source → Dest への一方向のデータ同期
- 逆方向(Dest → Source)への自動同期は行われない
- 削除の非同期性:
- Source側の削除はDestに反映されない(Delete Markersの設定による)
- Dest側の削除もSource側には一切影響しない
レプリケーションオプション
レプリケーション時間のコントロール (RTC)
概要
- SLA保証: 新しいオブジェクトの99.99%を15分以内にレプリケート
- SLA: 99.99%のオブジェクトが15分以内にレプリケート完了
- 残り0.01%: 15分を超える場合もあるが、優先的に処理される
- 自動メトリクス: RTC有効化でレプリケーションメトリクスも自動的に含まれる
料金
- 追加料金: 通常のレプリケーション料金に加えてRTC料金が発生
- レプリケートされたオブジェクト1,000個あたりの料金体系
RTC無効の場合(デフォルト)
- レプリケーション時間
- SLA保証なし: レプリケーション完了時間に保証がない
- 一般的な時間: 通常数分〜数時間(オブジェクトサイズ、ネットワーク状況による)
- ベストエフォート: AWSが可能な限り迅速にレプリケーションを実行
レプリケーションメトリクス
無効の場合、メトリクスが取得できない
監視可能な項目
- レプリケーション遅延(秒)：ReplicationLatency
- レプリケーション待ちのオブジェクト数：PendingReplicationObjectCount
- レプリケーション待ちの総サイズ(バイト)：PendingReplicationObjectSize
- レプリケーション完了オブジェクト数：ReplicatedObjectCount
- レプリケーション失敗オブジェクト数：FailedReplicationObjectCount
- 15分SLAを超えたオブジェクト数：ReplicationLatencyExceeded
削除マーカーのレプリケーション
概要
- ソースバケットでファイルを削除したという削除マーカーが、ディスティネーションバケットにも波及する
- レプリケーションを実施するには、ソース/ディスティネーションの両方でバージョニングが必要なため、ファイル削除が実態ファイルの削除ではなく、削除マーカーが付く形になる
削除マーカーのレプリケーション無効の場合(デフォルト)
- ソースでファイルを削除したらソースのファイルだけ、ディスティネーションでファイルを削除したらディスティネーションのファイルだけが削除される
- その削除動作が互いに波及することはない
レプリカ変更の同期
概要
レプリカ側で行われたメタデータ変更をソース側に逆同期
同期される変更
- オブジェクトACLの変更
- オブジェクトタグの変更
- Object Lock設定の変更
同期されない変更例
- オブジェクトの内容(データ自体)
- オブジェクトのメタデータ(Content-Type等)
- ストレージクラスの変更
- 暗号化設定の変更
- オブジェクトの削除・復元
Systems Manager
AWS Systems Manager を使ってサーバ管理を⾏うためにはサーバを”マネージドノード”にする
- SSM Agentを導入
- SSM Agentからのアウトバウンド経路を確保する
- インターネット経由
- VPCエンドポイント経由
- インバウンド経路は不要
- 権限付与
- 最低限AmazonSSMManagedInstanceCore相当の権限を付与
- デフォルトのホスト管理設定(DHMC)を有効にする
デフォルトのホスト管理設定(DHMC)
従来の挙動
- SSMを使うEC2インスタンスに所定のインスタンスプロファイルを設定する
- SSM Agentは上記インスタンスプロファイルの権限で動作しSSMの各種機能を実現する
DHMCを有効にした場合の挙動
- SSMを使うEC2インスタンスにインスタンスプロファイルは必須では無くなった
- EC2インスタンスにインスタンスプロファイルが設定されている場合、SSM Agentはそのインスタンスプロファイルの権限で動作しSSMの各種機能を実現する (従来通りの挙動)
- EC2インスタンスにインスタンスプロファイルが設定されていない場合、SSM AgentはDHMCに設定されたロールからクレデンシャルを取得しSSMの各種機能を実現する
注意点1 : マネージドノードとして認識されない場合
- DHMCを有効にしてもマネージドノードとして認識されない場合は以下の点を調査すると良い
- SSM Agentのバージョンが古い
- DHMCに設定したIAMロールの記述に誤りがある
注意点2 : 現状DHMCに対応してるのはSSMだけ
- DHMCではインスタンスプロファイルではなくSSMのサービスに設定されたロールから直接クレデンシャルを取得
- 現状SSM Agentのみこの仕組みに対応しており、たとえばAWS CLIでこのロールを使うことはできない
注意点3 : EC2インスタンスにSSMに対する権限が無いインスタンスプロファイルを指定した場合
- EC2インスタンスにSSMに対する権限が全くないインスタンスプロファイルをアタッチした場合にどの様な挙動になるか確認したところ、「インスタンスプロファイル自体は有効なもののSSMに対してはDHMCから取得したクレデンシャルを使う」という挙動になる
Explorer
- カスタマイズ可能な運⽤ダッシュボード
- 複数のサービスの運⽤データ(OpsData) をマルチアカウント・マルチリージョンで集約し、サマリーを表⽰してくれる
- Instance/Compute Optimizer
- Config Comliance
- Trusted Advisor
- Security Hub Findings
- Systems Manager
- Patch Compliance
- OpsItems
- Inventory
- Association
- Support Center
- 主にDevOpsマネージャー向け
OpsCenter
- AWSリソースに関する運⽤作業項⽬(OpsItem) を表⽰、調査、解決するための⼀元的な場所
- OpsItem が集約および標準化され、問題の診断と是正に役⽴つデータが提供される
- 主に運⽤エンジニアやITプロフェッショナル向け
Incident Manager
- 連絡先
- Eメール、SMS、音声を指定可能
- それぞれで、即時発火or指定分数Delayが可能
- エスカレーションプラン
- 指定した時間以内に応答がない場合に次のエスカレーション先へ
- 確認されるとエスカレーションがストップ
- オンコールスケジュール
- オンコール担当者をグループにして、ローテーションを設定可能
- ローテーション頻度は日/週/月から指定可能
- 例外設定も
- チャットチャネル
- Slack/Teams/Chimeを指定可能
- Runbook
- インシデント発生時にRunbookを呼び出し
Inventory
- 最短 30分ごとにサーバーのインベントリデータを定期的に収集し、最新の状態を保つ
- Fleet Manager からマネージドノードごとにインベントリデータを確認可能
- ダッシュボードから特定のバージョン・ソフトウェア名などの条件もとにフィルタリングが可能
- State Manager の associations (関連付け)の設定により、インベントリデータの収集が行われる
- データは30日間保持。30日以上保存する必要がある場合、リソースデータの同期を利用
- Inventory 利用は無料
Inventory で収集出来るデータ
| インベントリタイプ | 詳細 |
|---|---|
| アプリケーション | アプリケーション名、発行元、バージョンなど |
| AWS コンポーネント | EC2 ドライバ、エージェント、バージョンなど |
| ファイル | 名前、サイズ、バージョン、インストール日、変更および最新アクセス時間など |
| ネットワーク構成情報 | IP アドレス、MAC アドレス、DNS、ゲートウェイ、サブネットマスクなど |
| Windows Update | Windows Updateに関する情報(Hotfix ID、インストール者、インストール日など) |
| インスタンスの詳細 | OS名、OS/バージョン、最終起動、DNS、ドメイン、ワークグループ、OS アーキテクチャなど |
| サービス | 名前、表示名、ステータス、依存サービス、サービスのタイプ、起動タイプなど |
| タグ | インスタンスに割り当てられているタグ |
| Windows レジストリ | レジストリキーのパス、値の名前、値タイプおよび値 |
| Windows ロール | 名前、表示名、パス、機能タイプ、インストール日など |
| カスタムインベントリ | カスタムに割り当てられるメタデータ。例えばオンプレミスの各インスタンスのラック位置など |
State Manager
リソースを 定義された状態 に維持することが目的の機能
マネージドノード上での OS コマンド実⾏
- アンチウイルスソフトウェアのインストールと設定
- SSM Agent などのエージェントソフトウェアを定期的にアップデート
- ネットワーク設定
- Microsoft Active Directory ドメインへのノード参加
AWS リソースの制御
- EC2 インスタンスにロールをアタッチする
- セキュリティグループに Ingress ルールと Egress ルールを適⽤する
- AMI へのパッチ適⽤
Distributor
- ソフトウェアをパッケージ化し、パッケージドキュメントとして管理
- パッケージドキュメントは 3 種類
- AWS 提供
- サードパーティー提供
- お客様独自で作成
- Run Command や State Manager を使⽤して⼀回だけであったり、スケジュールに従ってソフトウェアを EC2 インスタンスやオンプレミスのサーバーに配布してインストール / アンインストールすることが可能
Maintenance Windows
- 管理タスクやメンテナンスタスクを複数のターゲットに実⾏するための時間枠(=メンテナンスウインドウ)をスケジュール
- メンテナンスウィンドウは開始時刻と終了時刻を持ち、複数のタスクを実⾏可能
- パッチやアップデートのインストールなどのメンテナンスタスクを⾏うのに適した時間帯を確実に選択できる
- Maintenance Windows は追加料金なしで利用可能
Patch Manager
- 自動承認のルールを定義し、適用すべきパッチの選別を自動化
- 定期的にパッチをスキャン＆インストール
- ダッシュボードでパッチのコンプライアンス状況を可視化
- リソースデータ同期によりクロスアカウント、クロスリージョンでコンプライアンス情報を収集可能
参考
- AWS Systems Manager Overview
- AWS Systems Manager Explorer / OpsCenter 編
- AWS Systems Manager Incident Manager 編
- AWS Systems Manager Hybrid Activations 編
- AWS Systems Manager Inventory 編
- AWS Systems Manager State Manager
- AWS Systems Manager Distributor 編
- AWS Systems Manager Maintenance Windows
- AWS Systems Manager Quick Setup 編
- AWS Systems Manager Patch Manager
- [アップデート] EC2インスタンスに対しデフォルトでSSMを有効にするDefault Host Management Configurationが追加されました
Amazon Data Lifecycle Manager(DLM)とAWS Backup
Amazon Data Lifecycle Manager
- EC2 インスタンスや EBS ボリュームのバックアップを手軽に、コスト効率良く自動化したい(デフォルトポリシー)
- AMI取得前にEC2インスタンスを再起動して、データ整合性を確保したい(カスタムポリシー)
- データの一貫性は保証されるが、同時に複数のインスタンスが再起動する可能性があるので注意
- 検証用AWSアカウントでサクッとAMIとEBSスナップショットを取得したい
AWS Backup
- EC2 インスタンスだけでなく、他のAWSサービス(RDS、DynamoDB等)のバックアップも一元管理したい
- コンプライアンスやガバナンスの要件を満たしたい
- アクセスポリシーの適用や、Vault Lock、監査ログの取得など、企業のコンプライアンス要件に対応できる各種機能が備わっている
違い
ライフサイクル管理
- DLMは幾つスナップショットを残すかを指定
- AWS Backupはどれだけの期間残すかを指定
- 1日1回スナップショットを作成するようスケジュールし、DLM では7世代残すように設定し、AWS Backupでは1週間でexpireするように設定した場合
- バックアップが毎日成功すると、どちらも過去7日分の7個のスナップショットが残る
- バックアップが一部失敗すると、
- DLMではバックアップジョブが成功した直近7個のスナップショットが残る
- AWS Backupでは過去7日のバックアップジョブのうち、成功したスナップショットだけが残る
簡易比較表
| 比較項目 | Data Lifecycle Manager (DLM) | AWS Backup |
|---|---|---|
| 学習難度 | 中(機能が限定的) | 高(多機能) |
| 適用範囲 | EBSスナップショットやAMIの管理に特化。 | EC2、RDS、S3など、複数のAWSサービスに対応。 |
| 自動化 | 自動化が可能。スケジュールに基づいて自動でAMIやスナップショットを作成。 | 自動化が可能。バックアッププランを設定して自動化。 |
| 設定の柔軟性 | ポリシーに基づいて詳細な設定が可能。 | バックアッププランに基づいて設定が可能。 |
| コスト | 無料(但し、取得したAMIやスナップショットに料金がかかる) | 左記に同じ |
| データ整合性 | 再起動オプションを設定可能。 | デフォルトでは再起動しないため、別途対応が必要。 |
| 復元方法 | 取得したAMIから新規インスタンスを起動 | 1.取得したAMIから新規インスタンスを起動2.AWS Backupのリカバリーポイントから復元(バックアップ取得元インスタンスの各種設定を引き継いで復元可能なので設定ミスが起きづらい)※詳細モニタリングは引き継げない |
| ガバナンス遵守 | ライフサイクル管理、リージョン間コピーへの対応が可能 | アクセスポリシーやVault Lock等の各種機能を組み合わせることで対応可能 |
参考
AWSアカウント跨ぎ/リージョン跨ぎのVPC接続
| 接続方法 | アカウント間 | リージョン間 | 最大接続数 | 主な用途 |
|---|---|---|---|---|
| VPC Peering | 可能 | 可能 | 1:1 のみ | シンプルな2点間接続 |
| Transit Gateway | 可能 | 可能(Inter-Region Peering) | 数千VPC | ハブ＆スポーク型の大規模接続 |
| PrivateLink | 可能 | 可能 | 多対多 | サービス単位での接続 |
| VPC Lattice | 可能 | 可能 | 多対多 | アプリケーション層での柔軟な接続 |
プレイスメントグループの比較
| 項目 | クラスター | パーティション | スプレッド |
|---|---|---|---|
| 配置戦略 | 同一ハードウェア上に密集配置 | 複数のハードウェアグループに分散 | 各インスタンスを個別ハードウェアに配置 |
| 主目的 | 低レイテンシー・高帯域幅 | 障害影響を局所化 | 最大限の可用性 |
| AZ制限 | 単一AZのみ | 複数AZ対応 | 複数AZ対応 |
| 最大インスタンス数 | 配置により異なる | パーティションあたり数百 | AZあたり7インスタンス |
各タイプの詳細
クラスタープレイスメントグループ
特徴
- インスタンスを物理的に近接配置
- 10 Gbps のネットワークパフォーマンスを最大化
- 同一の物理ハードウェア上またはそれに近い場所に配置
適用シーン
- HPC (High Performance Computing) アプリケーション
- 分散データベース(Cassandra、MongoDB クラスター)
- 低レイテンシーが要求される金融取引システム
- 機械学習の分散処理(TensorFlow、PyTorch)
制限事項
- 単一 AZ 内でのみ利用可能
- ハードウェア障害時に全インスタンスが影響を受ける可能性
- インスタンスタイプによる制限あり
パーティションプレイスメントグループ
特徴
- インスタンスを複数のパーティション(物理的に分離されたグループ)に分散
- 各パーティションは独立したハードウェアラック
- パーティション情報がメタデータで取得可能
適用シーン
- 大規模分散システム(Hadoop、Spark クラスター)
- マルチテナント SaaS アプリケーション
- レプリケーション機能を持つデータストレージシステム
- カスケード障害を防ぎたい分散アプリケーション
設定パラメータ
- パーティション数：1〜7(AZ あたり)
- インスタンス配置：均等分散 または 手動指定
スプレッドプレイスメントグループ
特徴
- 各インスタンスを異なる物理ハードウェアに配置
- 最大限の障害分離を提供
- 最も厳格な分散配置戦略
適用シーン
- ミッションクリティカルなアプリケーション
- 単一障害点を排除したい小規模システム
- 高可用性が要求されるマスター/スレーブ構成
- 重要なデータベースサーバー
制限事項
- AZ あたり最大7インスタンス
- 専用ハードウェアが必要なため、配置に失敗する場合がある
参考
AWSサービスのログ出力
| サービス名 | S3 | CloudWatch Logs | Data Firehose | 備考 |
|---|---|---|---|---|
| VPC Flow Logs | ○ | ○ | ○ | 3つの出力先全てに対応。最も柔軟 |
| CloudTrail | ○ | ○ | × | API監査ログ。S3とCW Logsに対応 |
| Application Load Balancer | ○ | × | × | アクセスログ・接続ログともにS3のみ |
| Classic Load Balancer | ○ | × | × | アクセスログはS3のみ |
| Network Load Balancer | ○ | × | × | TLSリスナー有りの場合のみアクセスログ作成 |
| S3アクセスログ | ○ | × | × | 別のS3バケットにのみ出力 |
| AWS Config | ○ | × | × | 設定履歴の保存 |
| Lambda | ○※1 | ○ | ○※1 | 実行ログは自動的にCW Logsへ |
| ECS | × | ○ | × | awslogsドライバー使用時 |
| ECS | ○ | ○ | ○ | FireLensドライバー使用時 |
| API Gateway | × | ○ | ○ | 実行ログ・アクセスログ |
| RDS | × | ○ | × | エラーログ・スロークエリログ等 |
| RDS | ○ | × | × | 監査ログ |
| ElastiCache | × | ○ | × | スローログ等 |
| CloudFront | ○ | ○ | ○ | アクセスログ・リアルタイムログ |
| Route 53 | ○ | ○ | ○ | クエリログ |
| AWS WAF | ○ | ○ | ○ | ウェブACLログ。3つ全てに対応 |
| GuardDuty | ○ | × | × | 検出結果のログ |
| Systems Manager | × | ○ | × | Session Manager、Run Commandログ |
※1 最近機能追加された模様(現在東京リージョンではCloudWatch Logsのみ)
https://dev.classmethod.jp/articles/cloudwatch-tiered-pricing-additional-destinations-aws-lambda-logs/
VPC BPA(ブロックパブリックアクセス)
有効化したリージョン内すべてのVPCに対するインターネットアクセス制御が可能
セキュリティグループやNACLの設定ミスによる意図しないインターネット公開を防止
VPCやサブネット単位での柔軟な除外設定が可能（一部のみ許可する運用にも対応）
参考
受験直後感想
- 想定ではありましたが、SOA-C02で一時的に出てきたラボ問題も、AIF/MLAで出てきた新しい回答形式もなかったため、過去傾向に沿ってかなり解きやすいなぁと思いました。
- 個人的に点数はどうあれ、過去一解いて面白かったです。
- 一方、ここ1-2年でリリースされた新機能や新サービスも含まれた問題が5-10問程度含まれていたため、これが採点対象だったらもしかするとまずいかも...と思いました。
- ポイント：Systems Manager、Control Tower、Bedrock、CloudWatch
- もちろんCloudWatchに関しても出題されましたが、ただのLog監視、メトリクス監視、アラート機能...なーーんて甘く見ていると地獄を見ますね。
- AWSの祭りはしっかり見ておくことをオススメします。
結果
まっっっっっっったく威張れない点数ではありますが、合格していたのであればまあよし...としましょう。はい。そうしましょう。
祝合格！！！
ただ、Credlyでのバッジ発行の連絡がなく、これが15冠継続なのか、16冠になれたかは神のみぞ知る状態です...(´;ω;｀)
【追記】
無事バッチが届き、またSysOpsとCloudOpsが別バッチとなったことで16冠を達成することができました！
Retiredした資格のうち、一番近々で有効期限が切れるのが"Certified Database - Specialty"の2026/05/01なので、あと半年強は16冠ネタを擦ろうと思います♪
参考
- 9時台に受験
- 11時台に退席
- 20時半に合格発表
- 翌日2時半にCredlyでバッジ獲得のメールが届きました ←追記
おわりに
全冠だからと言ってまあ何とかなるかなーと思っていた自分がいました。
何とかはなりましたが、ギリギリすぎますね。
特に最近の機能/サービスを中心に、触れていない分野が浮き彫りにされてしまった感があるので、ここは今後ブログ化含めて再学習したいなと思っています。
資格受験は、前後において学習のいい機会になるんですよね！！
皆さんも、運用分野をあまり触れていない方は一度受験してみてはいかがでしょうか？