Amazon SAA-C03: 管理、運用、可観測性、コスト — 学習ガイド

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

こちらの一部です： AWS SAA-C03 — 完全学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

CloudWatch: メトリクス、名前空間、ダッシュボード、アラーム

CloudWatchはAWSサービスのデフォルトのテレメトリプレーンですが、その有用性は、サービスがどの名前空間に発行するかを知っているかどうかに完全に依存します。名前空間は、サービス間の衝突を防ぐためのメトリクスのコンテナです。AWS/Lambdaは関数のInvocations、Errors、Throttlesを保持し、一方AWS/EventsはEventBridgeルールのInvocations、FailedInvocations、TriggeredRules、MatchedEventsを保持します。この区別は、イベント駆動型パイプラインを診断する際に重要です。EventBridgeルールがAPIデスティネーションを介してサードパーティAPIを呼び出し、下流にトラフィックが到着しない場合、答えはAWS/Lambdaにはなく、AWS/Eventsにあります。TriggeredRulesをチェックすれば、ルールパターンが実際に一致したかどうかがわかり、Invocations/FailedInvocationsをチェックすれば、ターゲット自体が呼び出されたかどうか、そしてその呼び出しが成功したかどうかがわかります。Lambdaがより身近なサービスであるという理由でLambdaのメトリクスを検索すると、ルールがそもそも受信イベントに一致しなかった可能性があるという事実を見逃してしまいます。

メトリクスの解像度はリソースごとの設定であり、コストに影響します。基本モニタリングは5分ごとにメトリクスを追加料金なしで発行します。これは、長時間実行される定常状態のワークロードには十分ですが、毎分の解像度を必要とするオートスケーリングのリアクション、スパイク検出、またはSLO計算には粗すぎます。詳細モニタリングでは、これを1分に短縮し（カスタム高解像度メトリクスでは1秒に）、スケーリンググループが迅速に反応する必要がある場合に有効にします。これは有料機能であり、デフォルトでオンになっていない理由もそこにあります。

すべてのサービスはデフォルトのメトリクスセットをネイティブに発行しますが、ハイパーバイザーはゲストOSの内部を見ることはできません。CPUUtilization、NetworkIn、DiskReadOpsはEC2で何もしなくても表示されますが、メモリ使用率やファイルシステム使用率のパーセンテージはCloudWatchエージェントを必要とします。これらを取得する唯一の方法です。カスタムアプリケーションメトリクスも、エージェントまたはPutMetricData経由で送信されます。

アラームは、シグナルとノイズを区別する必要があります。CPU > 50%という単一のアラームは、通常のバースト中に絶えず発生し、オペレーターがそれを無視するように慣れさせてしまいます。複合アラームは、子のアラーム状態をブール式のルールで組み合わせることで、オペレーターが真に対応が必要な状態のときにのみ呼び出されるようにします。一時的なCPUスパイクは問題ないが、持続的なCPU負荷とディスク読み取りIOPSの上昇が組み合わさると実際の問題を示すワークロードの場合：

HighCPUAlarm:
  MetricName: CPUUtilization
  Threshold: 50
  EvaluationPeriods: 3
  Period: 60
  ComparisonOperator: GreaterThanThreshold

HighDiskReadAlarm:
  MetricName: DiskReadOps
  Threshold: 1000
  EvaluationPeriods: 3
  Period: 60

CompositeAlarm:
  AlarmRule: >
    ALARM("HighCPUAlarm") AND ALARM("HighDiskReadAlarm")
  AlarmActions:
    - arn:aws:sns:us-east-1:111122223333:ops-pager

子のアラームは内部的にALARM状態に遷移するかもしれませんが、SNSをトリガーするのは複合アラームだけです。2つの独立したアラームが両方ともオンコールをページングすると、ノイズの問題が再発します。より高いしきい値を持つ単一のアラームでは、相関関係を見逃してしまいます。

ダッシュボードは、メトリクスウィジェット、ログウィジェット、テキストを集約します。2つの共有パターンが存在し、これらを混同することはよくある罠です。閲覧者がすでにAWSアカウントを持っている場合は、cloudwatch:GetDashboardとcloudwatch:GetMetricDataを持つIAMアイデンティティ（またはクロスアカウントオブザーバビリティを介したロール）を付与します。閲覧者がAWSアカウントを持っていない場合（プロダクトマネージャー、顧客のステークホルダーなど）は、組み込みのダッシュボード共有機能を使用します。これにより、単一のメール/パスワード、Cognitoユーザープール、またはパブリックURL（めったに適切ではありません）で保護された共有可能なリンクが生成されます。スクリーンショットをメールで送るのはオブザーバビリティではなく、AWSを利用しない閲覧者のためにコンソールアクセスを持つIAMユーザーを作成するのは最小権限の原則に反します。

OAMによるクロスアカウントオブザーバビリティ

何十ものアカウントを飛び回ってメトリクスを表示するのは現実的ではありません。CloudWatchクロスアカウントオブザーバビリティは、モニタリングアカウントを中央のシンクとして指定し、任意の数のソースアカウントがシンクとリンクリソースを介してメトリクス、ログ、トレースを共有します。大規模に最も迅速に展開する方法は、モニタリングアカウントでCloudWatchコンソールを開き、シンクを作成し、生成されたCloudFormation StackSetテンプレートを組織全体にデプロイして、各ソースアカウントにAWS::Oam::Linkリソースを作成することです。

Resources:
  ObservabilityLink:
    Type: AWS::Oam::Link
    Properties:
      LabelTemplate: "$AccountName"
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: arn:aws:oam:us-east-1:111122223333:sink/abc-123

これをクロスアカウントIAMロールと手動クエリで解決することも技術的には可能ですが、統合ダッシュボード、クロスアカウントのMetrics Insightsクエリ、またはOAMリンクが提供する自動的なアカウント名ラベルのエンリッチメントは得られません。

Container Insightsと分散トレーシング

コンテナ化されたワークロードには、Container Insightsが標準的なCloudWatch機能です。EKSでは、CloudWatchエージェント（またはADOTコレクター）をDaemonSetとして、ログ転送用にFluent Bitをデプロイします。エージェントはcAdvisorとkubeletのメトリクスをスクレイピングし、ECS/ContainerInsightsおよびContainerInsights名前空間（ポッド、ノード、名前空間、クラスターごとのCPU/メモリ）に発行します。一方、Fluent Bitはstdout/stderrを/aws/containerinsights/<cluster>/application、/dataplane、/hostなどのロググループに送信します。独自のPrometheus/Grafanaスタックを構築することも可能ですが、マネージドなパターンはContainer InsightsとLogs Insightsの組み合わせです。

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "payments"
| filter log like /ERROR/
| stats count() by kubernetes.pod_name

メトリクスは何かが遅いことを教えてくれますが、トレースはどこが遅いかを教えてくれます。X-Rayはリクエストパス内の各サービスをインストルメントし、X-Amzn-Trace-Idヘッダーを介してトレースIDを伝播し、セグメントとサブセグメントをX-RayデーモンまたはADOTコレクターに発行します。サービスマップは、レイテンシー、エラー、フォールトのパーセンテージとともにノードとエッジを視覚化します。X-Rayがなければ、p99のスパイクは原因が特定できないCloudWatchメトリクスとして表面化するだけです。

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # instruments boto3, requests, sqlalchemy, etc.

@xray_recorder.capture('checkout')
def checkout(order_id): ...

Container Insights、X-Ray、そしてCloudWatch Logsは、マイクロサービスのオブザーバビリティを支える三本柱です。

3つのログストリーム：CloudTrail、VPCフローログ、CloudWatch Logs

AWSのあらゆる可観測性戦略は、3つの異なるログストリームを区別します。すなわち、管理プレーンのAPIアクティビティ (CloudTrail)、データプレーンのネットワークアクティビティ (VPCフローログ)、そしてアプリケーション/OSの出力 (CloudWatch Logs) です。それぞれが異なるフォレンジック上の問いに答え、これらを混同することは、よくある設計上の誤りです。

CloudTrailは、すべてのAWS APIコールを記録します。誰が (userIdentity)、どのIPから、どのリソースに対して、どのようなパラメータで呼び出し、それが成功したかどうか、といった情報です。変更を特定のIAMプリンシパルに確実に関連付けることができる唯一のサービスです。APIアクティビティを探すのにCloudWatch Logsが適切であるというのは、よくある誤解です。CloudWatch Logsはアプリケーション/システムの出力をキャプチャするものであり、プリンシパルレベルの監査データではありません。CloudTrailは、リアルタイムのメトリクスフィルタリングのためにイベントをCloudWatch Logsに配信することは可能ですが、基礎となる監査レコードはCloudTrailで生成されます。

AWS Organizations環境では、管理アカウント (または委任された管理者アカウント) から組織の証跡を作成するのが正しいパターンです。これにより、新しいメンバーアカウントが自動的に登録され、イベントが専用のログアーカイブアカウント内の一つのS3バケットにストリーミングされます。

CentralTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    IsMultiRegionTrail: true
    IncludeGlobalServiceEvents: true
    EnableLogFileValidation: true       # SHA-256 digest chain
    S3BucketName: org-cloudtrail-logs
    KMSKeyId: !Ref TrailKmsKey

配信先のバケットには、バージョニング、s3:PutObjectをCloudTrailサービスプリンシパルに制限するバケットポリシー、SSE-KMSによる暗号化、監査人向けのクロスアカウント読み取り専用アクセス、そして理想的にはWORM保証のためのコンプライアンスモードのS3オブジェクトロックが必要です。ログファイルの検証機能は署名付きダイジェストファイルを生成するため、改ざんを検知できます。管理イベントはデフォルトで90日間有効ですが、それ以上保持するには証跡が必要です。データイベント (S3オブジェクトレベル、Lambda呼び出し、DynamoDB項目レベル) は、そのボリュームとコストのためオプトインです。アドホックな履歴クエリには、CloudTrail Lakeまたは証跡バケットに対するAthenaを使用してSQLを実行できます。

SELECT userIdentity.arn, eventTime, requestParameters
FROM cloudtrail_logs
WHERE eventName = 'AuthorizeSecurityGroupIngress'
  AND eventTime BETWEEN '2024-01-08' AND '2024-01-12';

VPCフローログは、VPC、サブネット、またはENIのIPトラフィックに関するメタデータ（5タプル、バイト数、パケット数、アクション (ACCEPT/REJECT)、ログステータス）をキャプチャします。ペイロードはキャプチャしません。配信先はCloudWatch Logs、S3、またはKinesis Data Firehoseです。アーカイブが目的の場合はS3を、疑わしいトラフィックパターンでアラームを発報するためのメトリクスフィルターが必要な場合はCloudWatch Logsを、ニアリアルタイム分析が要件の場合はFirehoseを選択します。NLB、ASG、データベースを持つVPCのための、標準的なニアリアルタイムパイプラインは以下の通りです。

ENIs → VPC Flow Logs (delivery: Kinesis Data Firehose)
      → Firehose delivery stream (optional Lambda transform)
      → Amazon OpenSearch Service (index: vpc-flow-*)
      → OpenSearch Dashboards

CloudWatch Logs → サブスクリプションフィルター → Firehose → OpenSearchという代替パスも機能しますが、ホップとコストが追加されます。「ニアリアルタイム」が要件の場合、S3は不適切です。フローログを全く有効にしないことが最も損害の大きい罠です。セキュリティインシデントが発生した際に、送信元/宛先/ポートの記録がなく、ACCEPTかREJECTかの可視性もありません。同じ理屈がALBアクセスログにも当てはまります。これはオプトインで、S3に配信され、これがないとクライアントIP、レスポンスコード、ターゲットのレイテンシー、ユーザーエージェントといったリクエストレベルの記録が存在しません。フローログ (L3/L4) とALBアクセスログ (L7) を合わせることで、トラフィックフォレンジックのベースラインが構成されます。

CloudWatch Logsは、CloudWatchエージェントを介してアプリケーション、Lambda、OSのログを受信します。その強力な機能はメトリクスフィルターにあります。これは、受信イベントをスキャンし、一致した場合にカスタムメトリクスをインクリメントするパターン式で、それがアラームをトリガーします。

# Metric filter detecting inbound SSH sessions from Flow Logs
[version, account, eni, source, dest, srcport, destport=22,
 protocol=6, packets, bytes, start, end, action=ACCEPT, status]

3389ポートに対する同様のフィルターでRDPをカバーします。アラートなしのログ収集は、予防ではなく、インシデント後のフォレンジックしか生み出しません。

大規模なフリートの場合、ロググループのサブスクリプションフィルターを介してログを処理パイプラインにファンアウトし、一致したイベントをKinesis Data Stream、Firehose、またはLambdaにニアリアルタイムでストリーミングするのが標準です。

{
  "filterPattern": "",
  "destinationArn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/logs-to-os"
}

罠は、処理パイプラインなしで生ログをストレージに送信することです。GlueカタログもOpenSearchインデックスもAthenaワークグループもないままS3にダンプすることは、ログは存在するものの、インシデント発生時にアクションを起こせないことを意味します。可観測性には、単なる永続的なバイトデータではなく、クエリを実行できる仕組みが必要です。また、ロググループには明示的な保持ポリシーが必要です。デフォルトは「無期限」であり、これは静かにお金を浪費します。ログはライフサイクルルールに基づいて長期アーカイブのためにS3にエクスポートできます。

最小のオーバーヘッドでのAPIレベルのイベント検出

CreateImage、AuthorizeSecurityGroupIngress、StopLogging、MFAなしのConsoleLoginといった価値の高いコントロールプレーンイベントに対して、最もオーバーヘッドの低いパターンはCloudTrail → EventBridgeルール → SNSです。EventBridgeは、すべてのCloudTrail管理イベントをネイティブに受信し、イベントパターンを持つルールは、Lambdaのグルーコードを必要としません。

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateImage"]
  }
}

CloudTrailをCloudWatch Logsに送信し、メトリクスフィルターを適用する方法も機能しますが、ロググループ、フィルター、アラーム、およびコストが追加されるため、要件が単に「API Xでアラートを出す」ことである場合、運用オーバーヘッドの点で劣ります。

AWS Config: 継続的な設定とドリフトの管理

ConfigとCloudTrailはよく混同されますが、根本的に異なる問いに答えるものです。CloudTrailは誰が何を呼び出したかを記録し、Configはリソースが現在どのような状態か、そして時間とともにどのように変化したかを記録します。ConfigがAPIコールをログに記録すると期待するのは、典型的な誤答の選択肢です。Configは、ユーザーがPutBucketAclを呼び出したことを知るのではなく、14:03:22にバケットのACLが状態Aから状態Bに変化したことを知っているだけです。プリンシパルを特定するには、Configの変更記録を同じタイムスタンプのCloudTrailイベントと関連付けます（コンソールではConfigがそのイベントにディープリンクしています）。

Configルールは、リソースを望ましい状態に照らして評価します。マネージドルールは、一般的なチェック（restricted-ssh、s3-bucket-public-read-prohibited、required-tags、ec2-instance-no-public-ip、s3-bucket-versioning-enabled、desired-instance-type）をカバーし、カスタムルールはLambda関数として実行されるか、CloudFormation Guardを使用します。ルールは設定変更時およびスケジュールに基づいて評価され、リソースをCOMPLIANTまたはNON_COMPLIANTとしてマークし、SSM Automationドキュメントを介して自動修復をトリガーできます。これは、「開いているSSHを検出する」や「過大なインスタンスタイプを検出する」といった要件に対する、運用オーバーヘッドの低い解決策です。ルールはすでに存在し、SNSやSecurity Hubとネイティブに統合されています。定期的な手動監査、スケジュールされたスキャン、または自作のスキャナーを提案することは、Configがすでに提供しているコードを自身で構築・保守することを要求します。

Configは評価結果をSNSに発行します。修復を自動化するには、EventBridgeルールをコンプライアンス変更イベントに結びつけ、SSM AutomationドキュメントまたはLambdaを呼び出します。

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

アグリゲーターは、組織全体のコンプライアンスを統合します。コンフォーマンスパックは、PCI-DSSやHIPAAなどのフレームワーク向けのルールをバンドルします。Workload Discovery on AWS（旧AWS Perspective）は、Config上に構築されたソリューションで、リソースの関係性を可視化し、アーキテクチャ図を生成します。これは、既存の環境を図式化できるインベントリツールを問う質問に対する定番の答えです。Configが前提条件となります。

Security Hub, GuardDuty, and Control Tower

Security Hubは、セキュリティ検出結果の集約プレーンです。GuardDuty（VPCフローログ、DNS、CloudTrailに基づく脅威検出）、Inspector（脆弱性検出結果）、Macie、IAM Access Analyzer、Configから取り込み、すべてをAWS Security Finding Format (ASFF) に正規化します。Security Hubを有効にすると、セキュリティ基準、特にAWS Foundational Security Best Practices (FSBP) 基準も有効になります。これは、内部的にConfigルールにマッピングされた数十の自動チェック（ルートMFA、パブリックS3、暗号化されていないEBS、複数リージョンでのCloudTrail）を含みます。

組織規模では、Security Hub（およびGuardDutyとConfig）に委任管理者アカウントを指定し、「新しいアカウントを自動で有効化する」トグルを使って組織全体でサービスとFSBP基準を有効にし、Security Hub Findings - ImportedをFSBP基準のARNでフィルタリングし、Compliance.Status = FAILEDと一致させることで、EventBridge経由で検出結果をSNSにルーティングします。自作のCloudTrail解析Lambdaやアカウントごとのダッシュボードを構築すると、Security Hubがすでに吸収している運用負荷が増加します。

重要な概念の区別として、Security Hubは検知および集約を目的としており、予防的ではありません。ドリフトを防止するのはAWS Control Towerの役割であり、適切に設計されたマルチアカウントのランディングゾーンをオーケストレーションします。Account Factoryは、ベースラインとなるネットワーキング、ロギング、IAMを備えた新しいアカウントをプロビジョニングします。ガバナンスは、3種類のガードレールを通じて表現されます。

プロアクティブなコントロールは、スタックがデプロイされる前にCloudFormationテンプレートを評価し、例えば暗号化されていないRDSインスタンスの作成を拒否します。Security Hubは、暗号化されていないインスタンスが実行された後で、その存在を通知するだけです。要件が「防止」であればControl Towerを、「検知、通知、または集約」であればSecurity HubやConfigを考えます。

Macie: 機密データ検出

Macieは、MLとパターンマッチングを使用して、S3オブジェクト内の機密データ（PII、財務データ、認証情報）を特定します。重大な落とし穴は、Macieがデータを保護すると想定してしまうことです。そうではありません。Macieは検知し、報告します。正しい使用法：

1. 対象のアカウント/リージョンでMacieを有効化します。
2. スケジュールに基づいてバケット/プレフィックス/タグを対象とする機密データ検出ジョブを設定します。
3. EventBridge (source: aws.macie) を介して検出結果を、通知用のSNS、修復（隔離、バケットポリシーの厳格化）用のLambda、またはSecurity Hubにルーティングします。

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

検出ジョブがなければ、Macieは何も生成しません。EventBridge → SNSの連携がなければ、検出結果はMacieコンソール内で気づかれないままになります。

Organizations、SCP、およびタグポリシー

AWS Organizationsは、ここで関連する3つのポリシータイプを公開しています。タグポリシーは、許可されるタグキー、大文字と小文字の区別、および値を定義します。これは非準拠を報告し、aws:ResourceTag/aws:RequestTag条件と組み合わせることで強制できます。サービスコントロールポリシー（SCP）は、メンバープリンシパルが利用できる最大のアクセス許可を定義します。バックアップポリシーとAIオプトアウトポリシーが、このセットを完成させます。

重要なメンタルモデル：SCPは決してアクセス許可を付与しません。SCPは、IAM（アイデンティティポリシー、リソースポリシー、アクセス許可の境界）が許可できる範囲に対するフィルターです。プリンシパルはIAMによるAllowを持ち、かつSCPがDenyしていない（またはそのAllowリストにアクションを含んでいる）必要があります。「SCPをアタッチするだけ」では、アクセス許可に関する問題の完全な解決策にはなりません。IAMによるAllowがなければ、SCPの内容に関わらず、プリンシパルはデフォルトで拒否されます。

作成時にタグを必須にするには、タグポリシーを次のようなSCPと組み合わせます：

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

タグポリシーがスキーマを宣言し、SCPがタグなしでの作成を拒否し、IAMポリシーが作成アクションを許可します。これら3つすべてが必要です。AWS Configのrequired-tagsルールは、既存の非準拠リソースを検出して修復します。

Systems Manager Automationとパッチ適用

Systems Manager（SSM）は、EC2およびハイブリッドノードのフリート全体にわたるライフサイクルアクティビティの運用上のバックボーンです。パッチ適用において最も重要な2つの構成要素は、Automationドキュメント（AWS APIやスクリプトを呼び出す宣言型のYAML/JSONランブック）とメンテナンスウィンドウ（同時実行数とエラーのしきい値を設定した変更ウィンドウ内で、タグベースのターゲットまたはリソースグループに対してこれらのランブックをスケジュールするもの）です。

標準的なパッチ適用フローは、AWS-RunPatchBaseline（コマンドドキュメント）を、Patch Groupタグで選択されたインスタンスに対して実行し、OSごとの承認ルールを定義するパッチベースラインを使用するものです。ロードバランサー配下のインスタンスに対してAWS-RunPatchBaselineを直接実行すると、インスタンスがターゲットグループ内でInServiceのままであるため、パッチ適用中に接続が切断されます。正しいパターンは**AWSEC2-PatchLoadBalancerInstance**であり、これは次の処理を行います：

1. インスタンスをCLBまたはALBのターゲットグループから登録解除します。
2. コネクションドレイニング（登録解除の遅延）を待ちます。
3. パッチベースラインのスキャンとインストールのステップを呼び出します。
4. ベースラインが必要とする場合は再起動します。
5. インスタンスを再登録し、ターゲットのヘルス状態がhealthyに戻るのを待ちます。

2つの前提条件が、「エラーが発生する」という障害モードを引き起こします。第一に、AutomationAssumeRoleとして渡されるIAMロールには、標準的なSSMパッチ適用のアクセス許可に加えて、elasticloadbalancing:DeregisterTargets、RegisterTargets、およびDescribeTargetHealthが含まれている必要があります。第二に、インスタンスはマネージドノードである必要があります。つまり、SSM Agentが実行中で、インスタンスプロファイルにAmazonSSMManagedInstanceCoreが含まれている必要があります。これらがないと、登録解除の呼び出しが失敗するか、SSMがインスタンスを認識できません。

schemaVersion: '0.3'
description: Patch instance behind ALB
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId: { type: String }
  TargetGroupArn: { type: String }
  AutomationAssumeRole: { type: String }
mainSteps:
  - name: deregister
    action: aws:executeAwsApi
    inputs:
      Service: elbv2
      Api: DeregisterTargets
      TargetGroupArn: '{{ TargetGroupArn }}'

← セキュリティ、IAM、KMS、ガバナンス · すべてのドメイン · 高可用性、耐障害性、災害復旧 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →