SAP-C02 · LESSON 3
既存のソリューションの継続的な改善25% · 5項目
既存のソリューションの運用上の優秀性・セキュリティ・性能・信頼性・コストを継続的に改善する戦略を学びます。
3.1運用上の優秀性を高める戦略を作成する
3.1 全体的な運用上の優秀性を高めるための戦略を作成する。
概念
運用の改善の中心は自動化と可観測性です。Systems Manager Automation のランブックで定型の作業(再起動・パッチ・AMI の作成)を自動化し、CloudWatch(メトリック・ログ・アラーム・Synthetics)と X-Ray(分散トレース)で状態を可視化します。インシデントは EventBridge で検知し、Incident Manager などで対応を標準化します。
仕組み・手順
- 手作業の運用の手順を洗い出し、ランブックとして自動化する
- CloudWatch のダッシュボードとアラームで重要な指標を監視する
- X-Ray で遅いサービスや依存関係を特定する
- EventBridge のルールで、イベントから自動の対応を起動する
- 事後のレビューで再発を防ぐ
業務での例
ディスクの使用率が 90% を超えたら、EventBridge から Systems Manager Automation で古いログを削除し、Slack に結果を通知する。
紛らわしい点・試験の注意
- 自動化は手順書(ランブック)として版管理し、テストする
- ログとメトリックだけでは、マイクロサービスのどこが遅いかは分かりにくい(トレースが必要)
- 変更の管理(Change Manager)も運用の範囲
ミニクイズ
Q1. AWS X-Ray の説明として誤っているものはどれか。
- Lambda や API Gateway などと連携してトレースを有効にできる
- サンプリングのルールで、記録するリクエストの割合を調整できる
- リクエストが複数のサービスをまたいで流れる様子と各区間の遅延を、サービスマップで表示できる
- アプリのコードの変更や SDK・エージェントの導入をしなくても、すべての通信の中身を自動で記録する
答えと解説を見る
正解:D アプリのコードの変更や SDK・エージェントの導入をしなくても、すべての通信の中身を自動で記録する
X-Ray を使うには SDK による計装や、ADOT・X-Ray デーモンなどの導入、サービス側でのトレースの有効化が必要。記録するのはトレースの情報で、通信の中身をすべて記録するものではない。
Q2. 利用の増加が続く既存システムで、来年までにサービスクォータの上限に当たる恐れがある。最も適切な対策はどれか。
- 上限に当たってエラーが出てから、AWS サポートに問い合わせて対応を相談することにする
- 利用者の数を今の水準で止めて、新しい部署にはシステムを使わせないようにしておく
- Service Quotas の使用率を CloudWatch で監視し、上限に近づく前に引き上げを申請する
- クォータは利用量に合わせて自動で増えるので、特に監視や準備をする必要はない
答えと解説を見る
正解:C Service Quotas の使用率を CloudWatch で監視し、上限に近づく前に引き上げを申請する
利用の傾向を見て、クォータに達する前に引き上げる。Service Quotas の使用率のメトリクスにアラームを設定できるものもある。
参考リンク
3.2セキュリティを向上させる戦略を決定する
3.2 セキュリティを向上させるための戦略を決定する。
概念
既存の環境のセキュリティの改善は、Security Hub(基準のチェックと検出結果の集約)、IAM Access Analyzer(外部へのアクセス・未使用のアクセスの検出、ポリシーの生成)、Config のルールと自動修復、Inspector の脆弱性の検査で行います。シークレットのローテーションや、長期のアクセスキーの廃止も改善の対象です。
仕組み・手順
- Security Hub の基準(AWS Foundational Security Best Practices など)でスコアを確認する
- Access Analyzer で外部に公開されたリソースと未使用の権限を見つける
- Config ルールに違反したリソースを自動修復する
- 長期のアクセスキーを IAM ロールや Identity Center に置き換える
- Inspector の結果から重大な脆弱性を優先して修正する
業務での例
Config で「暗号化されていない EBS」を検出したら、自動修復でスナップショットを暗号化し、Security Hub のスコアを毎月の会議で確認する。
紛らわしい点・試験の注意
- Access Analyzer の未使用のアクセスの検出で、最小権限に近づけられる
- 自動修復は本番への影響を確認してから有効にする
- 検出だけで対応しなければリスクは減らない
ミニクイズ
Q1. 本番の設定がコンソールでの手作業で変更され、検証環境と食い違って障害の原因になった。最も適切な改善策はどれか。
- AWS Config で設定の変更を記録し、変更があったら担当者に知らせる
- CloudTrail で変更の操作を記録し、変更した担当者を特定する
- CloudFormation で構成をコード化して変更し、ドリフト検出で手作業の変更を見つける
- 本番の変更をコンソールで行う前に、変更の申請を承認する手順を作る
答えと解説を見る
正解:C CloudFormation で構成をコード化して変更し、ドリフト検出で手作業の変更を見つける
構成をコードで管理し、変更はレビューされたテンプレートで行う。CloudFormation のドリフト検出で、テンプレートと実際の構成の差分を見つけられる。 【他の選択肢】Config や CloudTrail の記録は変更を見つけるが、検証環境と同じ構成に保たない。承認の手順だけでは手作業の変更の食い違いは残る。
Q2. Security Hub で、多くのアカウントの S3 バケットにパブリックアクセスのブロックが設定されていないと分かった。公開が必要なバケットはない。次に行うべきこととして最も適切なものはどれか。
- 全アカウントでアカウント単位のパブリックアクセスのブロックを有効にし、SCP で変更を禁止する
- Security Hub の検出結果ごとに、バケットの持ち主にチケットを送る
- S3 のバケットポリシーで、aws:SecureTransport が false の要求を拒否する
- 各バケットにパブリックアクセスのブロックを設定し、Config のルールで監視する
答えと解説を見る
正解:A 全アカウントでアカウント単位のパブリックアクセスのブロックを有効にし、SCP で変更を禁止する
アカウント単位のブロックで、そのアカウントのすべてのバケットの公開を防げる。SCP で設定の変更を禁止すると、元に戻されることも防げる。 【他の選択肢】バケットごとの設定は新しいバケットに漏れが出る。チケットは対応が遅く強制力がない。SecureTransport は暗号化の通信の強制で、公開を防がない。
参考リンク
3.3パフォーマンスを改善する戦略を決定する
3.3 パフォーマンスを改善するための戦略を決定する。
概念
既存のシステムの性能の改善は、測定(CloudWatch・X-Ray・Performance Insights)でボトルネックを特定し、適切な対策(キャッシュの追加・リードレプリカ・インスタンスの変更・非同期化・CDN)を選ぶことです。Compute Optimizer は過小なサイズのリソースも指摘します。
仕組み・手順
- 利用者の体感の指標(レイテンシ)とリソースの指標を集める
- RDS は Performance Insights で遅いクエリを特定する
- ボトルネックに合う対策を選ぶ
- 変更の前後で同じ負荷のテストを行い、効果を比べる
- 目標を満たしたら過剰なリソースを戻す
業務での例
DB の CPU が高い原因を Performance Insights で調べ、特定の集計クエリが原因と分かったので、インデックスを追加し、集計の結果を ElastiCache にキャッシュする。
紛らわしい点・試験の注意
- 原因を測らずにインスタンスを大きくすると、費用だけが増えることがある
- Compute Optimizer は過剰だけでなく不足も指摘する
- キャッシュの追加は整合性の要件を確認してから
ミニクイズ
Q1. 社内の見積システムの EC2 は、数か月間 CPU 使用率が 90% を超え続けて応答が遅い。Compute Optimizer は「リソースが不足している」と示している。次に行うべきこととして最も適切なものはどれか。
- Compute Optimizer の推奨は無視して、CPU の使用率のアラームのしきい値を 99% に引き上げておく
- インスタンスタイプを小さくして費用を下げ、空いた予算で別の監視ツールを導入することにする
- 利用者に、見積を作る件数を減らすように依頼して、CPU の負荷そのものを下げてもらうようにする
- 推奨された、より大きいか新しい世代のインスタンスタイプを検証環境で試し、効果を確かめて変更する
答えと解説を見る
正解:D 推奨された、より大きいか新しい世代のインスタンスタイプを検証環境で試し、効果を確かめて変更する
Compute Optimizer の推奨と使用状況から適正なサイズに見直す。検証で効果を確かめてから本番を変更する。
Q2. ElastiCache をキャッシュとして使うときの説明として誤っているものはどれか。
- キャッシュのデータに TTL(有効期限)を設定して、古いデータが残り続けるのを防げる
- よく読まれるデータをメモリに置くと、データベースの読み取りの負荷を下げられる
- データベースの更新時には、キャッシュの更新か無効化の方法を、アプリの側で設計しておく必要がある
- データを置けばデータベースと自動で常に同期されるため、更新時のキャッシュの扱いは設計しなくてよい
答えと解説を見る
正解:D データを置けばデータベースと自動で常に同期されるため、更新時のキャッシュの扱いは設計しなくてよい
ElastiCache はデータベースと自動で同期しない。遅延読み込みや書き込み時の更新、TTL など、キャッシュの更新の方式をアプリ側で設計する。
参考リンク
3.4信頼性を向上させる戦略を決定する
3.4 信頼性を向上させるための戦略を決定する。
概念
既存のシステムの信頼性の改善では、単一障害点(単一 AZ・単一インスタンス・単一の接続)を見つけて冗長化し、AWS Fault Injection Service(FIS)で障害を意図的に起こして耐性を確かめます(カオスエンジニアリング)。AWS Resilience Hub で RTO・RPO の目標に対する評価もできます。
仕組み・手順
- 構成を見直し、単一障害点を洗い出す
- Resilience Hub で目標の RTO・RPO を満たすか評価する
- 冗長化(マルチ AZ・Auto Scaling・Direct Connect の 2 本化)を行う
- FIS で AZ の障害やインスタンスの停止を試し、復旧を確認する
- 結果から手順と構成を改善する
業務での例
FIS で 1 つの AZ のインスタンスを停止する実験を行い、Auto Scaling が別の AZ で台数を補うまでに 5 分かかることを確認して、最小の台数を見直す。
紛らわしい点・試験の注意
- FIS の実験は停止条件(CloudWatch のアラーム)を設定して安全に行う
- 冗長化しても、切り替えを試していなければ信頼性は保証されない
- Resilience Hub は評価と推奨、FIS は実際の障害の注入
ミニクイズ
Q1. 本番に近い環境で、AZ の障害やインスタンスの停止が起きたときに、自動復旧の仕組みと手順が本当に働くかを確かめたい。最も適切な方法はどれか。
- AWS FIS で障害を意図的に起こす実験を計画し、停止条件を決めて影響を観察する
- 障害は起きないものと考えて、自動復旧の仕組みは設計書の確認だけで十分とする
- 本番の環境で、予告なしに担当者がインスタンスを手作業で次々と停止して確かめる
- 過去に一度も障害が起きていないことをもって、仕組みが正しく働くと判断しておく
答えと解説を見る
正解:A AWS FIS で障害を意図的に起こす実験を計画し、停止条件を決めて影響を観察する
AWS FIS は障害の注入を実験として管理し、停止条件(アラーム)で安全に止められる。復旧の仕組みと手順を実際に確かめるのに使う。
Q2. 既存の構成の単一障害点(SPOF)をなくしたい。3 つの AZ のプライベートサブネットが、すべて AZ-a にある1つの NAT ゲートウェイを経由してインターネットに出ている。最も適した対策はどれか。
- Direct Connect を別のロケーションで冗長化する
- ファイルを Amazon EFS に移す
- NAT ゲートウェイを AZ ごとに配置する
- RDS をマルチ AZ 配置にする
答えと解説を見る
正解:C NAT ゲートウェイを AZ ごとに配置する
NAT ゲートウェイはその AZ の中で冗長化されているが、AZ の障害には耐えられない。各 AZ に NAT を置き、その AZ のサブネットから向ける。
参考リンク
3.5コスト最適化の機会を特定する
3.5 コスト最適化の機会を特定する。
概念
既存の環境のコスト削減の機会は、Compute Optimizer(EC2・EBS・Lambda のライトサイジング)、S3 Storage Lens(ストレージの利用状況とライフサイクルの推奨)、Cost Explorer の Savings Plans の推奨、Trusted Advisor(アイドル状態のリソース)で見つけます。未使用の Elastic IP・EBS・スナップショット・古い世代のインスタンスも対象です。
仕組み・手順
- Cost Explorer でコストの大きいサービスとアカウントを特定する
- Compute Optimizer の推奨でサイズを下げる
- Storage Lens で、ライフサイクルが未設定のバケットを見つける
- Savings Plans の推奨と利用率を確認して購入する
- 未使用のリソースを定期的に削除する仕組みを作る
業務での例
Storage Lens で、不完全なマルチパートアップロードが 50 TB 残っているバケットを見つけ、ライフサイクルルールで削除して月の費用を下げる。
紛らわしい点・試験の注意
- Savings Plans を買いすぎると、使わない分も支払う
- 古い世代のインスタンスから新しい世代(Graviton など)に変えると安くなることが多い
- 削除の前に所有者とバックアップを確認する
ミニクイズ
Q1. 多数のアカウントの S3 に、どこに個人情報が保存されているかを把握できていない。最も適切な方法はどれか。
- GuardDuty の S3 の保護で、バケットへの不審なアクセスを検出する
- S3 Storage Lens で、バケットごとのオブジェクトの数と容量を見る
- Amazon Macie を組織全体で有効にし、S3 の機密データを自動で検出する
- AWS Config のルールで、暗号化されていないバケットを見つける
答えと解説を見る
正解:C Amazon Macie を組織全体で有効にし、S3 の機密データを自動で検出する
Macie は S3 のデータを機械学習とパターンで分析し、個人情報などの機密データを検出する。委任管理者で組織全体を一元管理できる。 【他の選択肢】Config は設定の確認で、中身の個人情報を見ない。Storage Lens は使用量の分析。GuardDuty はアクセスの脅威を検出し、データの中身を分類しない。
Q2. 全社で AWS の費用の削減の取り組みを始める。最初に行うこととして最も適切なものはどれか。
- Compute Savings Plans を購入し、EC2 と Lambda の単価を下げる
- 全部署に一律で 20% の削減の目標を与え、方法は各部署に任せる
- Cost Explorer で使用タイプ別の内訳を見て、効果の大きい項目から優先順位を決める
- Compute Optimizer の推奨に従い、すべてのインスタンスのサイズを変える
答えと解説を見る
正解:C Cost Explorer で使用タイプ別の内訳を見て、効果の大きい項目から優先順位を決める
まず費用の内訳と原因を把握し、効果の大きい項目から手を付ける。根拠のない一律の削減や一斉の変更は、業務への影響のリスクがある。 【他の選択肢】Savings Plans は使用量を把握してから買う。推奨を一括で当てると業務への影響を確かめない。一律の目標は効果の大きい項目を見ていない。
参考リンク
レッスンは当サイトがAWS 認定の公式ページと公式試験ガイドをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。
ご利用上の注意(非公式・独自問題・合格保証なし)
- 本サイトの問題は、公式に公開されているスキル概要・試験ガイドをもとに当サイトが独自に作成した練習問題であり、実際の試験問題ではありません。
- Amazon Web Services、AWS、および関連するマークは、米国その他の国における Amazon.com, Inc. またはその関連会社の商標です。本サイトは AWS(Amazon Web Services)と提携しておらず、AWS による承認・推奨を受けたものではありません。
- 本コンテンツは学習の補助であり、合格を保証するものではありません。試験の内容・形式・前提条件は予告なく変更されます。受験前に必ず公式ページで最新情報を確認してください。
- 本模擬試験の正答率は、公式試験の換算(スケール)スコア(合格 750)とは換算できず、合否を予測するものではありません。
- 未ログイン時の進捗はこのブラウザ内(localStorage)に保存します。Google でログインすると学習記録をアカウントに同期します。端末内の記録とサーバー上の記録は別に削除します。詳しくは保存・同期の説明とCookie・保存設定をご確認ください。