AWS Certified SysOps Administrator – Associate (SOA-C02) 【廃止済み】

⚠️ この資格は 2025年9月29日 をもって廃止されました。 後継資格: AWS Certified CloudOps Engineer - Associate (SOA-C03)

試験概要

特徴

SAA・DVAが「設計・実装」を問うのに対し、SOAは**「運用・監視・障害対応」**に特化。
AWS環境の日次運用を担うSRE・インフラエンジニア向け。

ドメイン別出題割合

Domain 1: 監視・ログ・修復（20%）

1-1. CloudWatch 詳細設計

メトリクスの種類と収集間隔:

基本モニタリング（無料）:
  → EC2: 5分間隔
  → RDS, ELB, DynamoDB等: 1分間隔（各サービスデフォルト）

詳細モニタリング（有料）:
  → EC2: 1分間隔（$3.5/インスタンス/月）

カスタムメトリクス:
  → CloudWatch Agent または PutMetricData API で送信
  → 1秒間隔まで対応（High Resolution）

メトリクス保持期間:
  → 1秒〜1分: 3時間
  → 5分間隔: 63日
  → 1時間間隔: 455日（15ヶ月）

CloudWatch Alarms の設定:

アラームの3つの状態:
  OK:          メトリクスが閾値以内
  ALARM:       メトリクスが閾値を超過
  INSUFFICIENT_DATA: データ不足（起動直後等）

アクション設定:
  → SNS通知（メール/Lambda/SQS）
  → EC2アクション（停止/再起動/復旧/終了）
  → Auto Scalingアクション（スケールイン/アウト）

Composite Alarms（複合アラーム）:
  → 複数アラームをAND/ORで組み合わせる
  → アラームノイズを削減
  例: "CPU > 80% AND メモリ > 80%" のときのみ通知

数学的メトリクス:
  → 複数メトリクスを計算して新しいメトリクスを作成
  例: ANOMALY_DETECTION_BAND() でベースラインから逸脱を検知

CloudWatch Logs の設計:

ロググループの構成:
  /aws/lambda/<function-name>      Lambda関数ログ
  /aws/ecs/containerlogs           ECSコンテナログ
  /aws/rds/instance/<id>/error     RDSエラーログ
  /aws/ec2/var/log/messages        EC2システムログ（Agent使用）

メトリクスフィルター:
  → ログからパターンを抽出してメトリクスに変換
  例: ERROR文字列が出現したらカウント → アラームに連携

CloudWatch Logs Subscriptions:
  → ログをリアルタイムでLambda/Kinesis/OpenSearchに転送
  → ログのリアルタイム処理や集約に利用

Logs Insights:
  → インタラクティブなログクエリ
  → スキャン量課金（$0.005/GB）

CloudWatch Agent の設定:

// /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
{
  "metrics": {
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": ["disk_used_percent"],
        "resources": ["/", "/data"],
        "metrics_collection_interval": 60
      }
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/application/*.log",
            "log_group_name": "/app/prod",
            "log_stream_name": "{instance_id}",
            "timestamp_format": "%Y-%m-%d %H:%M:%S"
          }
        ]
      }
    }
  }
}

1-2. AWS Systems Manager による運用自動化

SSM の主要機能:

Session Manager:
  → SSHキーなしでEC2に接続
  → 踏み台サーバー不要
  → セッションログをCloudWatch/S3に記録
  → プライベートサブネット内のインスタンスにも接続可能

Run Command:
  → 複数EC2に一斉コマンド実行（SSHなし）
  → スクリプト実行、パッチ確認、設定変更
  → 実行結果をS3/CloudWatch Logsに記録

Patch Manager:
  → パッチベースラインの定義（重要パッチのみ等）
  → メンテナンスウィンドウで自動パッチ適用
  → パッチコンプライアンスの追跡

Automation:
  → 複雑な運用手順をSSMドキュメントで自動化
  → AMI作成、EC2の起動/停止、ロールバック等
  → EventBridgeやLambdaからトリガー可能

Parameter Store:
  → 設定値・シークレットの安全な保管
  → CloudFormationやLambdaから参照

Inventory:
  → EC2のソフトウェアインベントリ収集
  → インストール済みパッケージ、設定ファイル等

Domain 2: 信頼性とビジネス継続性（16%）

2-1. バックアップとリカバリ

AWS Backup の設計:

バックアッププラン:
  バックアップルール:
    → スケジュール: cron式（例: cron(0 5 * * ? *)）
    → バックアップウィンドウ: 実行時間帯
    → ライフサイクル: コールドストレージへの移行とCold後の保持期間

  リソース割り当て:
    → タグベース: 特定タグを持つリソース全てをバックアップ
    → リソースID: 個別指定

対応サービス:
  EC2, EBS, RDS, Aurora, DynamoDB, EFS, FSx, 
  Storage Gateway, VMware, SAP HANA

クロスアカウント/クロスリージョンバックアップ:
  → コンプライアンス要件、DR対応
  → Backup Vault を使用
  
Vault Lock（WORM）:
  → バックアップの保持期間を変更不可にする
  → コンプライアンス規制対応（SEC 17a-4等）

RTO/RPO 設計の実践:

RTO (Recovery Time Objective): 復旧までの許容時間
RPO (Recovery Point Objective): 許容するデータ損失時間

DR戦略と目安:

Backup & Restore:
  RTO: 数時間〜1日
  RPO: 1日（バックアップ頻度に依存）
  コスト: 低
  実装: S3 Backup、RDSスナップショット

Pilot Light:
  RTO: 数十分〜1時間
  RPO: 数分〜数時間
  コスト: やや低
  実装: 最小限のDBレプリケーション、停止中のEC2

Warm Standby:
  RTO: 数分〜数十分
  RPO: 数秒〜数分
  コスト: 中
  実装: スケールダウンした本番環境を待機

Active-Active:
  RTO: ほぼ0秒（秒単位）
  RPO: ほぼ0秒
  コスト: 高
  実装: マルチリージョン DynamoDB Global Tables、Aurora Global

2-2. EC2 Auto Scaling の運用

スケーリングのトラブルシューティング:

スケールアウトが起きない:
  → CloudWatchアラームが正しく設定されているか
  → Auto Scalingグループの最大インスタンス数に達していないか
  → 起動テンプレートのAMIが有効か
  → サービスクォータ（EC2インスタンス数の上限）に達していないか

スケールインが起きない:
  → クールダウン期間中でないか
  → インスタンス保護が有効になっていないか
  → Scale-in保護を設定したインスタンスがないか

インスタンスの起動失敗:
  → ActivityHistoryでエラーを確認
  → EC2コンソールのインスタンス状態確認
  → IAMロールの権限確認（EC2 Auto ScalingがEC2を起動する権限）

Lifecycle Hooks:

スケールアウト時:
  EC2_INSTANCE_LAUNCHING → 
  [WAIT状態] → カスタム処理（設定適用、ヘルスチェック等）→ 
  CONTINUE → InService状態

スケールイン時:
  EC2_INSTANCE_TERMINATING → 
  [WAIT状態] → カスタム処理（セッション切断、ログ転送等）→ 
  CONTINUE → Terminated状態

実装例（Lambda + SNS）:
  ASG → SNSトピック → Lambda
    → ログをS3に転送
    → SSM Run Commandで設定変更
    → complete-lifecycle-action APIを呼び出し

Domain 3: デプロイ・プロビジョニング・自動化（18%）

3-1. CloudFormation 詳細

スタックのライフサイクル管理:

スタック作成の失敗:
  → ROLLBACK_IN_PROGRESS → CREATE_FAILED
  → 失敗したリソースのログをCloudFormationコンソールで確認
  → OnFailure: ROLLBACK（デフォルト）/ DO_NOTHING / DELETE

スタック更新:
  Change Sets:
    → 更新内容をプレビュー（何が変更されるかを確認）
    → 破壊的変更（リソースの置換）を事前に把握

スタックポリシー:
  → スタック更新時に特定リソースの変更を禁止
  → 本番DB等の誤削除・変更を防ぐ
  例:
  {
    "Statement": [{
      "Effect": "Deny",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "LogicalResourceId/ProductionDatabase"
    }]
  }

ドリフト検出:
  → CloudFormationテンプレートと実際のリソース状態の差分を検出
  → 手動変更（コンソール操作等）を把握するために定期実行

CloudFormation カスタムリソース:

# CloudFormationがネイティブサポートしていない操作を実装
Resources:
  InitializeDatabaseCustomResource:
    Type: AWS::CloudFormation::CustomResource
    Properties:
      ServiceToken: !GetAtt InitDbFunction.Arn
      DatabaseEndpoint: !GetAtt Database.Endpoint.Address
      DatabaseName: mydb

  InitDbFunction:
    Type: AWS::Lambda::Function
    Properties:
      # スタック作成時: CREATE、更新時: UPDATE、削除時: DELETE イベントを受け取る
      # cfnresponse.send() で CloudFormationに結果を通知

3-2. AWS Config と準拠性管理

Config Rules の活用:

マネージドルール（AWS提供、100+種類）:
  ec2-instance-in-vpc: EC2がVPC内にあるか
  encrypted-volumes: EBSが暗号化されているか
  iam-password-policy: パスワードポリシーが設定されているか
  restricted-ssh: SSHが全IPから開放されていないか
  s3-bucket-public-read-prohibited: S3バケットが公開読み取り禁止か

カスタムルール（Lambda）:
  → 独自のコンプライアンスチェックを実装
  → 定期評価 または 設定変更トリガー

コンフォーマンスパック:
  → 複数のConfig Rulesをパッケージとして適用
  → AWS Security Hub FSBP等のベストプラクティス準拠

自動修復（Remediation）:
  → 非準拠リソースを自動修復
  → SSM Automationドキュメントを実行
  例: 暗号化されていないEBSを自動暗号化

Domain 4: セキュリティとコンプライアンス（16%）

4-1. AWS Organizations と SCP

SCP（サービスコントロールポリシー）の設計:

// 特定リージョン以外のEC2起動を禁止
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApNortheast1",
      "Effect": "Deny",
      "Action": ["ec2:RunInstances"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-northeast-1"]
        }
      }
    }
  ]
}

// GuardDutyとCloudTrailの無効化を禁止
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging"
      ],
      "Resource": "*"
    }
  ]
}

SCP の評価ロジック:

重要: SCPはAllow/Denyの両方を定義できるが、
      ルートへのSCP適用は Organizations自体の管理アカウントには影響しない

評価順序:
1. マネジメントアカウントのSCPは自身には適用されない
2. SCPとIAMポリシーの AND 条件（両方で許可されている必要）
3. 明示的Denyが最優先

FullAWSAccessポリシー:
  → Organizationsの新規アカウントはデフォルト適用
  → 全アクションを許可する（=制限なし）
  → 必要に応じてDenyルールを追加していく戦略（Deny List方式）

4-2. GuardDuty と Security Hub の運用

GuardDuty の脅威カテゴリ:

データソース:
  → CloudTrail ログ
  → VPC Flow Logs
  → DNS ログ
  → S3 データイベント
  → EKS 監査ログ
  → RDS/Lambda ログ

脅威タイプ（試験頻出）:
  UnauthorizedAccess:EC2/SSHBruteForce: SSHブルートフォース攻撃
  CryptoCurrency:EC2/BitcoinTool: 仮想通貨マイニング
  Trojan:EC2/DGADomainRequest: マルウェアのDGA通信
  Recon:IAMUser/UserPermissions: 権限偵察
  UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B: 珍しい場所からのログイン

自動対応（EventBridge + Step Functions）:
  GuardDuty Finding → EventBridge → Step Functions
    → EC2インスタンスを隔離（セキュリティグループを変更）
    → IAMユーザーのクレデンシャルを無効化
    → インシデントチケットを作成

Security Hub の集約運用:

集約方法:
  管理アカウント（Security Hub Admin）
  ├── メンバーアカウント 1
  ├── メンバーアカウント 2
  └── メンバーアカウント 3
  → 全アカウントの検出結果を1ヶ所で管理

統合ソース:
  → GuardDuty, Inspector, Macie, IAM Access Analyzer
  → Config, Firewall Manager, Systems Manager
  → サードパーティ製品（Splunk, CrowdStrike等）

ASFF (AWS Security Finding Format):
  → 全ての検出結果の統一フォーマット
  → 検出結果をEventBridgeで処理 → SOAR自動化

セキュリティスコア:
  → AWS Foundational Security Best Practices (FSBP)
  → CIS AWS Foundations Benchmark
  → PCI DSS準拠チェック

Domain 5: ネットワークとコンテンツ配信（18%）

5-1. VPC フローログの分析

VPC Flow Logs の設定と分析:

記録されるフィールド:
  version account-id interface-id srcaddr dstaddr 
  srcport dstport protocol packets bytes start end action log-status

フローログの送信先:
  → CloudWatch Logs（リアルタイム分析、Logs Insightsで検索）
  → S3（Athena でSQL分析、コスト効率的）

Athena クエリ例:
-- 特定IPからのトラフィックをREJECTした記録を集計
SELECT srcaddr, count(*) as rejected_count
FROM vpc_flow_logs
WHERE action = 'REJECT' AND dstport = 22
GROUP BY srcaddr
ORDER BY rejected_count DESC
LIMIT 20;

-- トラフィックが多い宛先ポートTOP10
SELECT dstport, sum(bytes) as total_bytes
FROM vpc_flow_logs
WHERE action = 'ACCEPT'
GROUP BY dstport
ORDER BY total_bytes DESC
LIMIT 10;

ネットワークのトラブルシューティング:

接続できない場合のチェック手順:

1. セキュリティグループ確認
   → インバウンドルール: 送信元IP/SG、ポートが正しいか
   → アウトバウンドルール: ステートフルなので通常は全許可

2. NACL確認
   → インバウンド: ルール番号順に評価、デフォルトは全許可
   → アウトバウンド: 戻りトラフィックの許可ルールが必要（ステートレス）
   → エフェメラルポート（1024-65535）の許可が必要

3. ルートテーブル確認
   → パブリックサブネット: IGW（0.0.0.0/0）へのルートがあるか
   → プライベートサブネット: NAT Gatewayへのルートがあるか
   → VPCピアリング: ピアのCIDRへのルートがあるか

4. VPC Flow Logs確認
   → ACCEPT/REJECT の確認
   → どのレイヤーでブロックされているか特定

5. DNS確認
   → Route 53またはVPC DNSが正しく解決できているか

Domain 6: コストとパフォーマンスの最適化（12%）

6-1. コスト最適化の実践

AWS Cost Explorerの活用:

コスト分析の切り口:
  → サービス別（EC2が全体の何%）
  → タグ別（チーム/環境別の配賦）
  → リソース別（特定インスタンスのコスト）
  → リンクトアカウント別（Organizations）

Savings Plans推奨機能:
  → 過去7日・30日・60日の使用量を分析
  → 最適なSavings Plansを推奨
  → 予測節約額を表示

Cost Anomaly Detection:
  → 機械学習でコスト異常を自動検知
  → SNS通知で即時アラート

Cost and Usage Report (CUR) の活用:

CUR → S3 → Athena → QuickSight のパイプライン:
  
1. CURをS3に出力（Parquet形式、パーティション付き）
2. Glueでスキーマ定義
3. AthenaでSQL分析
   SELECT product_servicename, SUM(line_item_unblended_cost) as total_cost
   FROM "cur_database"."cur_table"
   WHERE month = '2024-01'
   GROUP BY product_servicename
   ORDER BY total_cost DESC;
4. QuickSightでダッシュボード作成

学習計画（6週間）

Week 1-2: 監視と運用の基礎

Week 1:
  月: CloudWatch（メトリクス、アラーム、Logs Insights）
  火: CloudWatch Agent（EC2へのインストールと設定）
  水: X-Ray（分散トレーシング）
  木: AWS Config（ルール、コンフォーマンスパック、修復）
  金: CloudTrail（証跡設定、ログ分析）
  週末: CloudWatchダッシュボードを実際に作成する

Week 2:
  月: Systems Manager（Session Manager、Run Command）
  火: SSM Patch Manager（パッチベースライン）
  水: SSM Automation（自動化ドキュメント）
  木: AWS Backup（バックアッププラン、Vault Lock）
  金: CloudFormation（スタック管理、ドリフト検出）
  週末: 模擬問題30問

Week 3-4: セキュリティとネットワーク

Week 3:
  月: GuardDuty（脅威タイプと自動対応）
  火: Security Hub（集約と自動化）
  水: Organizations + SCP（マルチアカウント統制）
  木: IAM Access Analyzer
  金: AWS Trusted Advisor

Week 4:
  月: VPC Flow Logs（設定とAthena分析）
  火: NACLとセキュリティグループのトラブルシューティング
  水: Route 53（ヘルスチェック、フェイルオーバー）
  木: CloudFront（キャッシュ、アクセスログ）
  金: Cost Explorer（コスト分析、異常検知）
  週末: 模擬問題50問

Week 5-6: 仕上げ

• Week 5: 模擬試験と弱点強化
• Week 6: 最終確認と試験

頻出問題パターン

パターン1: 「EC2インスタンスのパフォーマンス問題」

CPU高騰:
  → CloudWatchでCPU使用率を確認
  → Auto Scalingでスケールアウト
  → インスタンスタイプの変更（スケールアップ）

メモリ問題:
  → デフォルトでCWがメモリメトリクスを収集しない
  → CloudWatch Agentでメモリメトリクスを追加

ネットワーク問題:
  → VPC Flow Logsで通信確認
  → セキュリティグループ・NACLの確認

パターン2: 「アカウント全体の統制」

設定の変更を検知したい:
  → Config Rules + 通知（EventBridge → SNS）

リソースのタグ漏れを検知したい:
  → Config Rule: required-tags

GuardDutyを全アカウントで有効化:
  → Organizations統合でメンバーアカウントに自動有効化

ルートユーザーのログインを検知:
  → CloudTrail → CloudWatch Logs Metric Filter → アラーム

アーキテクチャ図

CloudWatch 監視アーキテクチャ

flowchart TB
    subgraph Sources["データソース"]
        EC2["EC2\n(CloudWatch Agent)"]
        RDS["RDS\n(Enhanced Monitoring)"]
        ALB["ALB\n(Access Logs)"]
        Lambda["Lambda\n(自動メトリクス)"]
        App["アプリケーション\n(カスタムメトリクス)"]
    end

    subgraph CW["Amazon CloudWatch"]
        Metrics["Metrics\n(メトリクス保存)"]
        Logs["Logs\n(ログ収集・検索)"]
        Alarms["Alarms\n(閾値監視)"]
        Dashboard["Dashboards\n(可視化)"]
        Insights["Logs Insights\n(クエリ分析)"]
    end

    subgraph Actions["アクション"]
        SNS["SNS\n(通知: Email/Slack)"]
        ASG["Auto Scaling\n(スケールアウト)"]
        SSM["SSM Automation\n(自動修復)"]
        EB["EventBridge\n(イベントルーティング)"]
    end

    EC2 & RDS & ALB & Lambda & App --> Metrics & Logs
    Metrics --> Alarms
    Logs --> Insights
    Alarms --> SNS & ASG & SSM
    SNS --> EB

インシデント対応フロー

flowchart TD
    Alert(["🚨 CloudWatch Alarm\nSTATE: ALARM"]) --> EB["EventBridge Rule"]
    EB --> SNS["SNS Topic\n(オンコール通知)"]
    EB --> StepFn["Step Functions\n自動対応ワークフロー"]

    StepFn --> Check{"重大度判定"}
    Check -->|"HIGH"| Isolate["EC2セキュリティグループ\n隔離 (Lambda)"]
    Check -->|"MEDIUM"| Restart["SSM Run Command\nサービス再起動"]
    Check -->|"LOW"| Log["CloudWatch Logs\nログ収集のみ"]

    Isolate & Restart & Log --> Ticket["Jira/ServiceNow\nチケット作成"]
    Ticket --> PostMortem["インシデント記録\n(S3 + Athena)"]

本試験形式 模擬問題（詳細解説付き）

問題 1

EC2 インスタンスでメモリ使用率が高騰しているという報告を受けました。CloudWatch コンソールでメモリ使用率メトリクスが表示されていません。原因と解決策として最も適切なものはどれですか？

• A. EC2 のインスタンスタイプがメモリメトリクスをサポートしていない
• B. CloudWatch エージェントがインストールされていないため、メモリはデフォルトで収集されない
• C. IAM 権限が不足している
• D. メモリメトリクスは有料オプションで、購入が必要

問題 2

本番環境の EC2 インスタンスに緊急のセキュリティパッチを適用する必要があります。ポート 22（SSH）は全てのセキュリティグループで閉じられています。最もセキュアかつ迅速な方法はどれですか？

• A. セキュリティグループにポート 22 を一時的に開放してSSH接続する
• B. EC2 コンソールのシリアルコンソールを使用する
• C. AWS Systems Manager Session Manager を使用してポートレスで接続する
• D. EC2 インスタンスを停止してスナップショットからパッチを適用する

問題 3

AWS Config を使って「全ての S3 バケットに対してパブリックアクセスブロックが有効になっているか」を継続的に監視し、違反を自動修復したい場合の構成として最も適切なものはどれですか？

• A. Lambda 関数で定期的に S3 バケット設定を確認する
• B. AWS Config ルール（マネージドルール）+ Systems Manager Automation を使って自動修復する
• C. CloudTrail + CloudWatch アラームで検出する
• D. Security Hub の CIS ベンチマーク標準を有効化する

問題 4

大規模な本番環境で EC2 インスタンスへの OS パッチを、ダウンタイムを最小化して適用したいと考えています。最も適切な方法はどれですか？

• A. 各インスタンスに手動でSSH接続してパッチを適用する
• B. AWS Systems Manager Patch Manager でパッチベースラインとメンテナンスウィンドウを設定する
• C. EC2 Image Builder で新しい AMI を作成してインスタンスを置き換える
• D. AWS Lambda で全インスタンスに対してパッチコマンドを並列実行する

問題 5

CloudFormation スタックの更新中に予期せぬ変更が加えられるのを防ぐため、特定のリソース（本番DBなど）を誤って削除・置換から保護したいと考えています。最も適切な方法はどれですか？

• A. CloudFormation スタックを削除禁止にする
• B. CloudFormation StackPolicy を設定して特定リソースの更新を制限する
• C. IAM ポリシーで CloudFormation の UpdateStack 権限を制限する
• D. DeletionPolicy を Retain に設定する

{
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["Update:Replace", "Update:Delete"],
      "Principal": "*",
      "Resource": "LogicalResourceId/ProductionDatabase"
    }
  ]
}

問題 6

マルチリージョンで稼働するアプリケーションに対して、AWS Cost Explorer でコスト分析を行うと、特定のリージョンのコストが急増していることがわかりました。原因を詳細に調査するために使用するサービスはどれですか？

• A. AWS Budgets でアラートを設定する
• B. AWS Cost and Usage Report（CUR）を S3 に出力して Athena でクエリする
• C. CloudTrail でAPIコールを確認する
• D. AWS Trusted Advisor のコスト最適化チェックを確認する

-- Athena でのCUR分析例
SELECT line_item_product_code,
       line_item_resource_id,
       SUM(line_item_unblended_cost) as total_cost
FROM cost_and_usage_report
WHERE bill_billing_period_start_date = '2026-01-01'
  AND product_region = 'ap-northeast-1'
  AND line_item_line_item_type = 'Usage'
GROUP BY 1, 2
ORDER BY total_cost DESC
LIMIT 20;

問題 7

EC2 Auto Scaling グループで、スケールイン（インスタンス削除）時に実行中のジョブが中断されないよう、アプリケーションのシャットダウン処理（クリーンアップ）を完了させてから終了させたい場合に使用する機能はどれですか？

• A. EC2 インスタンスの termination protection を有効化する
• B. Auto Scaling ライフサイクルフック（Lifecycle Hook）を設定する
• C. CloudWatch アラームのアクションで Auto Scaling をブロックする
• D. Auto Scaling のスケールインポリシーを「最も新しいインスタンス」に変更する

Auto Scalingがスケールイン決定
↓
インスタンス状態: Terminating:Wait（最大48時間待機）
↓
Lambda/SQSでシャットダウン処理実行
↓
CompleteLifecycleAction: CONTINUE
↓
インスタンス終了（Terminated）

Domain 2: 信頼性とビジネス継続性（16%）

高可用性設計の基礎

RTO と RPO:

RTO（Recovery Time Objective）: 目標復旧時間
  障害発生からサービス復旧までの許容時間
  例: RTO = 4時間 → 4時間以内にサービスを回復

RPO（Recovery Point Objective）: 目標復旧ポイント
  データ損失の許容範囲（最後のバックアップからの時間）
  例: RPO = 1時間 → 最大1時間分のデータ損失を許容

RTO/RPO を小さくする → コストが増大（トレードオフ）

ディザスタリカバリ戦略:
  Backup & Restore:   低コスト、RTO/RPO 高（時間単位）
  Pilot Light:        最小限のリソースを常時起動
  Warm Standby:       縮小スケールのシステムを常時稼働
  Multi-Site Active:  両サイトを常時稼働（最高の可用性、最高コスト）

AWS Backup

AWS Backup の主な機能:
  - 一元化されたバックアップ管理
  - バックアッププラン（スケジュール + 保存期間）
  - クロスリージョン/クロスアカウントバックアップ
  - 組織全体のバックアップポリシー（Organizations統合）

対応サービス:
  EBS, RDS, Aurora, DynamoDB, EFS, FSx, S3, EC2, Storage Gateway

バックアッププランの設定例:
  バックアップルール1: 毎日 2:00 AM、7日間保持、東京
  バックアップルール2: 毎週日曜、30日間保持、大阪（クロスリージョン）

復元テスト:
  AWS Backup Restore Testing: バックアップからの自動復元検証
  → コンプライアンス要件への対応

S3 のデータ保護

バージョニング:
  有効化 → 削除操作は「削除マーカー」を追加（実際には削除しない）
  全バージョンを保持 → 誤削除から復旧可能

S3 Object Lock:
  Retention Mode:
    Compliance: root でも削除不可（金融/医療コンプライアンス）
    Governance: 特定権限のユーザーのみ変更可能
  Legal Hold: 期限なしの保護（訴訟保全等）

レプリケーション:
  CRR（Cross-Region Replication）: 異なるリージョンに複製
    → DR、コンプライアンス、レイテンシ削減
  SRR（Same-Region Replication）: 同リージョンの別バケットに複製
    → ログ集約、本番→テスト環境へのコピー

注意: レプリケーションは既存のオブジェクトには適用されない
（有効化後の新規オブジェクトのみ）

RDS マルチ AZ と Read Replica

Multi-AZ（高可用性）:
  プライマリ（AZ-a） ←同期レプリケーション→ スタンバイ（AZ-b）
  フェイルオーバー: 自動（1〜2分）
  スタンバイは読み取りに使用不可
  目的: HA（高可用性）、RTO 削減

Read Replica（読み取りスケール）:
  非同期レプリケーション
  複数リージョンに作成可能
  目的: 読み取り負荷の分散
  注意: フェイルオーバーには手動での昇格が必要

Aurora の場合:
  Multi-AZ が標準（1プライマリ + 最大15 Read Replica）
  フェイルオーバーは30秒以内
  Read Replica はフェイルオーバーに自動使用

Domain 3: デプロイ・プロビジョニング・自動化（18%）

AWS CloudFormation 運用

スタック操作:

スタック作成フロー:
  テンプレート検証
    ↓
  Change Set の作成（プレビュー）
    ↓
  Change Set の実行
    ↓
  リソースの作成/更新/削除

ロールバック設定:
  作成失敗: ROLLBACK_ON_FAILURE（デフォルト）
  更新失敗: 自動ロールバック
  ロールバック無効化: トラブルシューティング用

スタックポリシー:
  リソースの意図せぬ更新・削除を防ぐ
  例: RDS インスタンスの削除を禁止するポリシー

ドリフト検出:
  実際のリソース設定と CloudFormation テンプレートの差異を検出
  手動変更を追跡してガバナンス維持

CloudFormation StackSets:

複数アカウント・複数リージョンに一括デプロイ

Organizations との統合:
  Service Managed 権限: Organizations OU を対象に自動展開
  新規アカウント追加時に自動的にスタックをデプロイ

ユースケース:
  - セキュリティ設定の全アカウント適用
  - コンプライアンスリソースの一括展開
  - ログ収集設定の標準化

Systems Manager（SSM）詳細

SSM Agent の活性要件:

EC2 へのインストール: Amazon Linux 2以降はプリインストール
必要な権限: EC2 インスタンスに AmazonSSMManagedInstanceCore ポリシー
ネットワーク要件:
  オプション1: インターネット → ssm.region.amazonaws.com
  オプション2: VPC Interface Endpoint（プライベートネットワーク）

Run Command:

ユースケース: 複数 EC2 への一括コマンド実行
  - ソフトウェアの一括インストール
  - 設定ファイルの更新
  - ログの収集

ターゲット指定方法:
  インスタンス ID 指定
  タグによる動的ターゲット（例: Env=Production）
  リソースグループ

実行結果:
  S3 または CloudWatch Logs に出力
  SNS で完了通知

SSM Automation:

複数ステップの運用タスクを自動化
  例: EC2 の AMI 作成 → 古い AMI の削除 → 通知

組み込みドキュメント:
  AWS-RestartEC2Instance: インスタンスの再起動
  AWS-StopEC2Instance: インスタンスの停止
  AWS-CreateImage: AMI の作成
  AWS-PatchInstanceWithRollback: パッチ適用と失敗時ロールバック

イベントトリガー:
  手動実行 / スケジュール / EventBridge / Config 違反

Patch Manager:

パッチ管理の自動化

パッチベースライン:
  どのパッチを適用するか（Critical/Important/Moderate等）
  カスタムパッチベースラインで独自ルールを定義

メンテナンスウィンドウ:
  パッチ適用のスケジュール設定
  例: 毎週日曜 02:00-04:00 JST

パッチコンプライアンス:
  各インスタンスのパッチ適用状況を追跡
  非準拠インスタンスを CloudWatch / Security Hub に報告

Domain 4: セキュリティとコンプライアンス（16%）

IAM 運用のベストプラクティス

アクセスキーの管理:

問題: 長期アクセスキーの漏洩リスク
対策:
  1. 人間のユーザーにはアクセスキーを付与しない（SSO を使用）
  2. EC2/Lambda には IAM ロールを使用
  3. 必要な場合はローテーションを定期実施

アクセスキーのローテーション手順:
  Step 1: 新しいアクセスキーを作成
  Step 2: アプリケーションを新しいキーに更新
  Step 3: 古いキーを無効化（しばらく様子を見る）
  Step 4: 古いキーを削除

CloudTrail で最終使用日を確認:
  aws iam get-access-key-last-used --access-key-id AKIAXXXXXXXX

IAM Access Analyzer:

外部エンティティからアクセス可能なリソースを自動検出:
  S3 バケット（パブリックアクセスやクロスアカウント）
  IAM ロール（クロスアカウントの信頼ポリシー）
  KMS キー（外部アクセス）
  Lambda 関数（パブリックまたはクロスアカウント）
  SQS キュー（クロスアカウント）

アナライザーゾーン: アカウントまたは Organizations が境界

アーカイブルール: 既知の外部アクセスを「期待される」として除外

AWS Config 詳細

Config ルールのタイプ:

マネージドルール（AWS 提供）:
  s3-bucket-public-read-prohibited: S3 パブリック読み取り禁止
  ec2-instance-no-public-ip: EC2 パブリック IP 禁止
  iam-user-mfa-enabled: IAM ユーザーへの MFA 要求
  encrypted-volumes: EBS 暗号化要求
  required-tags: 必須タグの確認

カスタムルール:
  Lambda 関数で独自の評価ロジックを実装
  例: 特定のタグが正しいフォーマットか確認

プロアクティブルール（事前評価）:
  CloudFormation デプロイ前にルール違反を検出
  IaC のセキュリティ「左シフト」

Config アグリゲーター:

組織全体のリソース設定とコンプライアンスを一元管理
  - 全アカウント・全リージョンのデータを集約
  - セキュリティチームが統合ビューでコンプライアンス確認
  - AWS Organizations と統合（新規アカウント自動追加）

自動修復:
  Config ルール違反 → SSM Automation で自動修復
  例: S3 パブリックアクセス検出 → 自動でパブリックアクセスをブロック

Domain 5: ネットワークとコンテンツ配信（18%）

VPC 詳細設計

サブネット設計パターン:

典型的な3層構成:
  パブリックサブネット（ALB/NAT GW）
    ↓
  プライベートサブネット（アプリサーバー）
    ↓
  データサブネット（RDS/ElastiCache）

各レイヤーで SG + NACL で防御（多層防御）

NACL vs セキュリティグループ:
  NACL: サブネットレベル、ステートレス、番号順評価
  SG: インスタンスレベル、ステートフル、全ルール評価

エフェメラルポートの注意点:
  NACL でインバウンドのみ設定すると通信できない
  → アウトバウンドに 1024-65535 の許可が必要

VPC フローログ:

記録する情報:
  送受信 IP、送受信ポート、プロトコル
  パケット数、バイト数
  アクション（ACCEPT/REJECT）
  
記録しない情報:
  パケットの中身（ペイロード）
  DNS クエリ内容（Route 53 クエリログで別途取得）
  DHCP トラフィック
  169.254.169.254 へのアクセス（IMDS）

分析:
  CloudWatch Logs Insights でクエリ
  Athena で S3 のフローログをSQL分析

Transit Gateway:

複数 VPC を単一のハブで相互接続

メリット:
  VPC Peering: N*(N-1)/2 のピアリング数
  Transit Gateway: N 個のアタッチメントのみ（シンプル）

ルートテーブル設計:
  デフォルト: 全アタッチメントが相互通信
  セグメンテーション: VPC ごとに異なるルートテーブル
    例: 本番 VPC と開発 VPC を分離

クロスアカウント共有:
  AWS Resource Access Manager (RAM) で共有
  → 組織全体で単一の Transit Gateway を共有

Route 53 詳細

ルーティングポリシー比較:

Simple: 1つのリソースへのルーティング
Weighted: 重みでトラフィック分散（A/Bテスト、移行）
Latency: 最低レイテンシのリージョンへルーティング
Failover: プライマリ障害時にセカンダリへ（ヘルスチェック必須）
Geolocation: ユーザーの地理的場所でルーティング
Multi-Value: 複数の値を返し、ヘルスチェックで絞り込み
IP-Based: クライアント IP で制御（2023年追加）

Route 53 ヘルスチェック:

種類:
  エンドポイント監視: HTTP/HTTPS/TCP
  CloudWatch アラーム監視: カスタムメトリクス
  他のヘルスチェック監視: 複合ヘルスチェック

ヘルスチェックの動作:
  18以上のグローバルヘルスチェッカーが確認
  閾値: デフォルト3/3回の失敗でUnhealthy

Failover との組み合わせ:
  Primary レコード + ヘルスチェック
  Secondary レコード（フェイルオーバー先）
  → Primary が Unhealthy → 自動で Secondary に切り替え

Domain 6: コストとパフォーマンスの最適化（12%）

EC2 購入オプション詳細

On-Demand: 秒/時間単位、最も柔軟、最高コスト

Reserved Instances（RI）:
  1年または3年コミットメント
  最大72%割引
  
  Standard RI: 特定のインスタンスタイプに固定（最大割引）
  Convertible RI: インスタンスタイプを変更可能（割引は低い）
  スケジュールド RI: 廃止（現在は利用不可）

Savings Plans:
  RI よりも柔軟
  Compute Savings Plans: EC2/Fargate/Lambda に適用（最も柔軟）
  EC2 Savings Plans: 特定リージョン/ファミリーに固定（割引大）

Spot:
  最大90%割引
  中断通知: 2分前に通知
  → ステートレスな処理、バッチ処理、ML学習に適す

Dedicated:
  Dedicated Host: 物理ホスト単位（BYOL、コンプライアンス）
  Dedicated Instance: ハードウェアは専用だがホスト管理はAWS

コスト管理ツール

AWS Budgets:

予算タイプ:
  コスト予算: 実際のコスト/予測コストに対してアラート
  使用量予算: 特定サービスの使用量
  RI/Savings Plans カバレッジ: コミットメントの活用率

アクション:
  通知: SNS/メール
  自動アクション: IAM ポリシーのアタッチ、SCP の適用

例: 月額 $1,000 の予算で $800 到達時に通知

AWS Cost Anomaly Detection:

機械学習で異常なコスト増加を自動検出
  - 通常の使用パターンをベースラインとして学習
  - 異常検出時に SNS で通知
  - 根本原因（どのサービス/アカウント/リージョンか）を特定
  
設定:
  モニター: AWS サービス単位、メンバーアカウント単位、コストカテゴリ
  アラート: 絶対値($) または割合(%)でしきい値設定

AWS Compute Optimizer:

機械学習で EC2/Lambda/ECS/EBS の最適なサイズを推奨
  - 過去14日間の CloudWatch メトリクスを分析
  - Under/Over-provisioned の両方を検出
  
推奨の信頼度:
  HIGH: 分析データが十分
  MEDIUM: データがある程度ある
  LOW: データが不十分

対応リソース:
  EC2 インスタンス: 適切なインスタンスタイプ
  Auto Scaling グループ: 適切なインスタンス設定
  EBS ボリューム: 適切なボリュームタイプ/サイズ
  Lambda 関数: 適切なメモリサイズ
  ECS on Fargate: 適切な CPU/メモリ

模擬試験（65問）

問題 1

EC2 インスタンスの CPU 使用率が 80% を超えたら通知を受け取りたいと考えています。最小限の設定で実現するにはどうすればよいですか？

• A. CloudWatch メトリクスを確認し、手動でアラートメールを送信する
• B. CloudWatch Alarm で CPU 使用率 > 80% の条件に SNS トピックのアクションを設定する
• C. CloudTrail で CPU 使用率の変化を監視する
• D. Systems Manager で定期的に CPU を確認するスクリプトを実行する

問題 2

本番環境で実行中の EC2 Auto Scaling グループに対して、スケールアウト時に新しいインスタンスが完全に準備完了になる前にロードバランサーのヘルスチェックに登録されてしまい、502エラーが発生しています。解決策はどれですか？

• A. Auto Scaling の最小インスタンス数を増やす
• B. EC2 Auto Scaling のウォームアップ時間（Instance Warmup）または Elastic Load Balancing の Connection Draining を設定する
• C. CloudWatch アラームのしきい値を変更する
• D. セキュリティグループのルールを修正する

問題 3

アプリケーションのデプロイ後に問題が発生した場合、AWS Elastic Beanstalk で以前のバージョンに素早くロールバックする方法はどれですか？

• A. CloudFormation スタックをロールバックする
• B. Elastic Beanstalk コンソールから「アプリケーションバージョン」を選択して以前のバージョンをデプロイする
• C. EC2 インスタンスを手動で以前のAMIから起動する
• D. CodeDeploy のロールバック機能を使用する

問題 4

AWS Organizations 内の複数のアカウントで、同じ CloudFormation テンプレートを使ったリソースを一括デプロイしたいと考えています。最適な方法はどれですか？

• A. 各アカウントに手動でデプロイする
• B. CloudFormation StackSets を使用し、Organizations の OU をターゲットに指定する
• C. CodePipeline で各アカウントに順番にデプロイする
• D. Terraform で一括デプロイする

問題 5

EC2 インスタンスに接続したい SSHキーペアを紛失してしまいました。インスタンスを削除せずにアクセスを回復する方法はどれですか？

• A. EC2 インスタンスを停止してから新しいキーペアで起動し直す
• B. Systems Manager Session Manager を使ってキーなしでアクセスし、新しいSSH公開鍵を追加する
• C. AWS サポートに連絡してキーを再発行してもらう
• D. EC2 のコンソールから「パスワードリセット」オプションを使用する

問題 6

SysOps エンジニアとして、100台以上の EC2 インスタンスに緊急セキュリティパッチを適用する必要があります。最も効率的な方法はどれですか？

• A. 各インスタンスに SSH でログインしてパッチを手動適用する
• B. AWS Systems Manager Patch Manager でパッチベースラインとメンテナンスウィンドウを設定し、一括適用する
• C. 新しい AMI を作成してインスタンスを順番に置き換える
• D. CodeDeploy でパッチスクリプトをデプロイする

問題 7

CloudWatch でアラームが頻繁に「ALARM」と「OK」の間を行ったり来たりする（フラッピング）問題が発生しています。この問題を軽減するための設定はどれですか？

• A. アラームのしきい値を高くする
• B. 評価期間のデータポイント数を増やす（例: 5分間のデータポイント 1/1 → 5/5 に変更）
• C. CloudWatch の頻度を下げる
• D. SNS 通知を無効にする

問題 8

AWS 環境で「インフラのドリフト」を検出するために使用できるサービスはどれですか？（2つ選択）

• A. AWS CloudFormation ドリフト検出
• B. AWS Config（リソース設定の変更記録）
• C. AWS CloudTrail（API コールの記録）
• D. Amazon Inspector（脆弱性スキャン）
• E. AWS Trusted Advisor（ベストプラクティスチェック）

問題 9

Elastic Beanstalk の「ローリングデプロイ」と「Immutable デプロイ」の違いは何ですか？

• A. ローリングはインスタンスを段階的に更新し、Immutable は新しいインスタンスを起動して問題なければ切り替える
• B. ローリングは高速で安全、Immutable は低速で危険
• C. ローリングはダウンタイムがあり、Immutable はゼロダウンタイム
• D. 機能的な違いはなく、費用が異なるだけ

問題 10

大量のオブジェクトを持つ S3 バケットのコストを削減したいと考えています。オブジェクトは作成後 30 日間は頻繁にアクセスされますが、以降はほぼアクセスされません。最適な設定はどれですか？

• A. すべてのオブジェクトを Glacier にアーカイブする
• B. ライフサイクルルールで 30 日後に S3 Standard-IA に移行し、90 日後に Glacier に移行する
• C. S3 Intelligent-Tiering を使用する
• D. オブジェクトを 30 日後に定期的に削除する

問題 11

AWS CloudTrail が有効化されているにもかかわらず、特定の S3 バケットへのオブジェクトダウンロード（GetObject）が CloudTrail に記録されていません。なぜですか？

• A. CloudTrail は S3 操作を記録できない
• B. CloudTrail の Management Events は記録されているが、S3 オブジェクトレベルの操作は Data Events として別途有効化が必要
• C. S3 バケットのログ記録を有効にしていないため
• D. CloudTrail はリアルタイムではなく、遅延して記録される

問題 12

EC2 Auto Scaling グループで、スケールアウト後に古いインスタンスが終了する前に実行中のセッションを安全に終了させたいと考えています。最適な設定は？

• A. Auto Scaling の Cooldown 期間を長く設定する
• B. Elastic Load Balancing の Connection Draining（Deregistration Delay）を設定する
• C. Auto Scaling のライフサイクルフック（EC2_INSTANCE_TERMINATING）を設定する
• D. CloudWatch アラームで終了プロセスを一時停止する

問題 13

CloudFormation スタックの更新中にリソース作成が失敗しました。スタックは ROLLBACK_COMPLETE 状態になっています。次にすべきことは何ですか？

• A. スタックをそのまま使い続ける
• B. スタックを削除して再作成する
• C. CloudFormation の「スタックのインポート」機能でリソースをインポートする
• D. スタックの「継続 on 失敗」オプションを有効化して再試行する

問題 14

AWS Cost Anomaly Detection でコスト異常を検出した場合、根本原因を特定するためにどのサービスを使いますか？

• A. AWS Budgets
• B. AWS Cost Explorer でサービス別・アカウント別・リージョン別にドリルダウン
• C. CloudTrail で API コールを確認する
• D. CloudWatch メトリクスで使用量を確認する

問題 15

SysOps エンジニアとして、EC2 インスタンスの OS レベルのメモリ使用率を CloudWatch で監視したいと考えています。なぜデフォルトでは監視できないのですか？また、どうすれば監視できますか？

• A. CloudWatch はメモリ監視をサポートしていない
• B. メモリ使用率は EC2 ハイパーバイザーからは取得できない。CloudWatch Agent をインスタンスにインストールしてカスタムメトリクスとして送信する
• C. Enhanced Monitoring を有効化すれば自動的にメモリが監視される
• D. IAM 権限を適切に設定すれば自動的に取得される

# CloudWatch Agent 設定（メモリ監視の例）
{
  "metrics": {
    "namespace": "CWAgent",
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent"]
      },
      "disk": {
        "measurement": ["disk_used_percent"],
        "resources": ["/", "/data"]
      }
    }
  }
}

問題 16〜65（ショート形式）

問題 16: CloudWatch の「アラームアクション」で実行できない操作は？ → 正解: アラームから直接 Lambda を起動することはできない（SNS → Lambda の順が必要）。直接実行できるアクション: EC2 アクション（停止/再起動/終了/回復）、Auto Scaling アクション、SNS 通知

問題 17: AWS Systems Manager の「Parameter Store」でSecureStringタイプを使用する場合に必要な設定は？ → 正解: KMS キー（カスタマーマネージドキーまたはデフォルトの aws/ssm）を指定して暗号化。GetParameter時に --with-decryption フラグが必要（または IAM ポリシーで ssm:GetParameter + kms:Decrypt）

問題 18: CloudFormation の DependsOn 属性の用途は？ → 正解: リソースの作成順序を明示的に制御。暗黙的な依存関係がない場合に使用。例: RDS インスタンスの作成後にアプリサーバーを起動したい場合

問題 19: Amazon EventBridge のルールでスケジュール式 rate(5 minutes) と cron(0 2 * * ? *) の違いは？ → 正解: rate は一定間隔での繰り返し（5分ごと）。cron は特定の時刻に実行（毎日 UTC 02:00）。cron の方が柔軟なスケジュール（特定の曜日/日付等）が可能

問題 20: CloudWatch Logs Insights で「過去1時間のエラーログを件数順にカウントする」クエリを書くと？ → 正解: fields @timestamp, @message | filter @message like /ERROR/ | stats count(*) as errorCount | sort errorCount desc

問題 21: Auto Scaling の「スケールアウト後クールダウン」（Scaling Cooldown）の目的は？ → 正解: スケールアウト直後に追加のスケールアウトアクションを抑制するため（メトリクスが安定するまでの待機時間）。デフォルト 300 秒。過剰なスケーリングを防ぐ

問題 22: AWS Config の評価タイミング「変更トリガー」と「定期トリガー」の違いは？ → 正解: 変更トリガー: リソースが変更されたときに評価（リアルタイム検出）。定期トリガー: 指定した間隔（1時間/3時間/6時間/12時間/24時間）で定期的に評価

問題 23: CloudFormation スタックで「DeletionPolicy: Retain」を設定したリソースを削除するとどうなりますか？ → 正解: CloudFormation スタックを削除してもリソースは削除されず、AWS アカウントに残り続ける。孤立したリソースとして手動削除が必要。RDS/S3 等の重要データ保護に使用

問題 24: EC2 インスタンスの「ステータスチェック」で「インスタンスステータスチェック失敗」と「システムステータスチェック失敗」の違いは？ → 正解: インスタンスステータス: OS/アプリケーションの問題（再起動で解決の可能性）。システムステータス: AWS インフラの問題（ホスト障害等、AWS が修復するため停止→起動で別ホストに移動）

問題 25: EBS の「io1/io2 ボリューム」を使うべきケースは？ → 正解: 低レイテンシと一貫した高 IOPS が必要な場合（データベース等）。IOPS を独立してプロビジョニング可能。io1: 最大 64,000 IOPS、io2: 最大 256,000 IOPS（Block Express）

問題 26: CloudFormation の「カスタムリソース」の用途は？ → 正解: CloudFormation がネイティブでサポートしていないリソースや操作を Lambda 関数で実装。例: サードパーティ API の呼び出し、既存リソースの設定変更、データの事前ロード

問題 27: Route 53 の「ヘルスチェック」がエンドポイントを「Unhealthy」と判定する条件は？ → 正解: 世界中の Route 53 ヘルスチェッカー（18以上）の過半数がリクエストに対して成功レスポンス（HTTP 2xx/3xx）を受け取れない場合。デフォルト: 30秒間隔、3回連続失敗で Unhealthy

問題 28: AWS 環境で「コンプライアンスレポート」を自動生成するサービスはどれですか？ → 正解: AWS Security Hub（FSBP/CIS/PCI DSSスコア）、AWS Audit Manager（コンプライアンスフレームワークへの対応状況）、AWS Config（コンフォーマンスパック）が該当

問題 29: CloudWatch のカスタムメトリクスの名前空間（Namespace）のベストプラクティスは？ → 正解: 会社名やアプリケーション名を使用した一意の名前空間を使用（例: MyCompany/WebApp）。AWS/ プレフィックスは AWS サービスが予約しているため使用しない

問題 30: EC2 インスタンスを停止（Stop）と終了（Terminate）の違いは？ → 正解: Stop: インスタンス停止（EBS ルートボリュームは保持、停止中も EBS 費用発生）。Terminate: インスタンスと EBS ルートボリュームを完全削除（DeleteOnTermination=true の場合）

問題 31: AWS Systems Manager の「State Manager」の用途は？ → 正解: EC2 インスタンスの設定を定義した「期待状態」に維持する。例: CloudWatch Agent が常に動作していることを保証、特定のソフトウェアが常にインストールされていることを確認

問題 32: CloudFormation 変更セット（Change Set）で「Replacement」と表示されたリソースはどうなりますか？ → 正解: 既存リソースを削除して新しいリソースを作成する。ダウンタイムが発生する可能性がある。RDS のインスタンスタイプ変更等で発生。事前に確認して影響を評価すること

問題 33: VPC の「Reachability Analyzer」の用途は？ → 正解: VPC 内の2つのエンドポイント間のネットワーク到達性を分析・検証するツール。SG/NACL/ルートテーブルを分析し、通信が失敗している場合の原因を特定する

問題 34: EC2 インスタンスに「Elastic IP」を関連付けていない場合、インスタンスの停止・起動でIPアドレスはどうなりますか？ → 正解: パブリック IP アドレスは変更される（停止時に解放、起動時に新しい IP が割り当てられる）。プライベート IP は変更されない。固定 IP が必要な場合は Elastic IP を使用

問題 35: AWS Organizations の「統合請求（Consolidated Billing）」の主なメリットは？ → 正解: (1) 複数アカウントの使用量を合算してボリュームディスカウントを享受。(2) 未使用の RI/Savings Plans を他アカウントに適用。(3) 単一の請求書で一元管理

問題 36: CloudFormation の「Fn::ImportValue」の用途は？ → 正解: 他のスタックからエクスポートされた値を参照する関数。例: ネットワークスタックでエクスポートした VPC ID をアプリスタックで参照。スタック間の疎結合を実現

問題 37: RDS マルチ AZ で自動フェイルオーバーが発生する条件は？ → 正解: プライマリ DB のストレージ障害、ネットワーク障害、ホスト障害、OS のパッチ適用（計画停止）等。フェイルオーバー時間: 通常 60-120 秒。CNAME が自動更新される

問題 38: ELB の「アクセスログ」と「CloudWatch メトリクス」の違いは？ → 正解: アクセスログ: 個別リクエストの詳細（送信元IP/リクエスト/レスポンスコード/処理時間）を S3 に保存。CloudWatch メトリクス: 集約されたパフォーマンスデータ（リクエスト数/レイテンシ/エラー率）をリアルタイム監視

問題 39: CloudWatch の「コンポジットアラーム」の用途は？ → 正解: 複数のアラームを AND/OR で結合した複合条件アラーム。例: CPU 高 AND メモリ高 AND 通常業務時間外 の条件が全て成立した場合のみアラームを発生

問題 40: AWS Elastic Beanstalk の「設定ファイル（.ebextensions）」の用途は？ → 正解: .ebextensions/ ディレクトリに YAML/JSON 形式の設定ファイルを置くことで、環境カスタマイズ（パッケージインストール、ファイル作成、コマンド実行、設定変更）を自動化

問題 41: AWS Compute Optimizer の推奨を確認して EC2 インスタンスタイプを変更する際のベストプラクティスは？ → 正解: (1) テスト環境で変更をテスト、(2) 本番環境はメンテナンスウィンドウで実施、(3) 変更後 1-2 週間モニタリング、(4) CloudWatch メトリクスで CPU/メモリ/ネットワークの適正さを確認

問題 42: AWS Trusted Advisor の「コストの最適化」チェックで確認できる主な推奨事項は？ → 正解: 未使用の EC2 インスタンス、未使用の EBS ボリューム、アイドル状態のロードバランサー、RI の購入推奨（低使用率のオンデマンドに対して）、S3 のライフサイクル設定の推奨

問題 43: CloudFormation の「スタックセットのデプロイオーダー（Account Deployment Order）」とは？ → 正解: StackSets で複数アカウントへの展開順序を制御する機能。順次（serial）または並列（parallel）でデプロイ。依存関係がある場合は順次が必要

問題 44: AWS Systems Manager の「Inventory」機能の用途は？ → 正解: EC2 インスタンスの構成情報を自動収集・管理。収集内容: インストールアプリ、ネットワーク設定、ファイル一覧、サービス一覧、OS 情報等。Config との統合でコンプライアンス確認

問題 45: CloudWatch のログ保持期間のデフォルト設定は？ → 正解: デフォルトは「失効なし（Never Expire）」で永久保持。費用が累積するため、用途に応じて保持期間を設定（1日/3日/7日/14日/30日/60日/90日/…最長10年）

問題 46: EC2 インスタンスの「インスタンスプロファイル」と「IAM ロール」の違いは？ → 正解: IAM ロールは権限の定義。インスタンスプロファイルは EC2 インスタンスに IAM ロールをアタッチするためのコンテナ（ラッパー）。コンソールでは自動作成されるが API/CLI では明示的に作成が必要

問題 47: EBS ボリュームの「暗号化」を後から有効化する方法は？ → 正解: (1) ボリュームのスナップショットを作成、(2) スナップショットを暗号化オプションでコピー、(3) 暗号化されたスナップショットから新しいボリュームを作成、(4) 既存ボリュームをデタッチして新ボリュームをアタッチ

問題 48: CloudWatch の「カスタムダッシュボード」で「クロスアカウント/クロスリージョン」のメトリクスを表示するための前提条件は？ → 正解: 共有アカウントで CloudWatch クロスアカウント可観測性を設定。ソースアカウントで CloudWatch クロスアカウント共有を有効化し、モニタリングアカウントのIDを指定

問題 49: Route 53 の「Alias レコード」と通常の CNAME レコードの違いは？ → 正解: Alias: AWS リソース（ALB/CloudFront/S3等）の DNS 名に直接マッピング（Zone Apex でも使用可）、Route 53 の DNS クエリ料金なし。CNAME: 任意のドメイン名を参照、Zone Apex では使用不可（例: example.com は CNAME 不可）

問題 50: AWS Backup でクロスアカウントバックアップを設定する利点は？ → 正解: (1) ランサムウェア対策（本番アカウントが侵害されてもバックアップを保護）、(2) 規制要件（バックアップを別アカウント/ORG で保管）、(3) DR（別アカウントに迅速に復元）

問題 51: CloudFormation の「Fn::Base64」の主な用途は？ → 正解: EC2 のUserData（ユーザーデータ）は Base64 エンコードが必要なため、シェルスクリプトを Fn::Base64: !Sub | で囲んでエンコードする。CloudFormation テンプレートで最も頻繁に使用される関数の一つ

問題 52: EC2 Auto Scaling の「スケーリングポリシー」の種類と使い分けは？ → 正解: Target Tracking: 指定メトリクスを目標値に維持（シンプル、推奨）。Step Scaling: メトリクスの値の範囲に応じて段階的にスケール。Scheduled Scaling: 時間に基づく事前スケール（予測可能なパターン用）

問題 53: Amazon CloudWatch の「EMF（Embedded Metric Format）」の特徴は？ → 正解: Lambda/コンテナのログに JSON 形式でメトリクスデータを埋め込む機能。ログとメトリクスを同時に生成でき、CloudWatch Logs からの Custom Metrics への変換が自動化される。カスタムメトリクス送信の簡略化

問題 54: AWS Cost Explorer の「節約プラン推奨事項」を使用するメリットは？ → 正解: 過去30/60/90日の実際の使用量データに基づいて、最適な Savings Plans（Compute/EC2）の種類とコミットメント金額を自動推薦。節約額と節約率の見積もりを提供

問題 55: CloudFormation テンプレートの「Conditions」セクションの用途は？ → 正解: 環境（本番/開発等）に応じてリソースの作成/設定を制御。例: IsProd: !Equals [!Ref Env, "production"] で本番環境のみ Multi-AZ RDS を作成する条件分岐

問題 56: VPC の「インターネットゲートウェイ（IGW）」と「NAT ゲートウェイ」の違いは？ → 正解: IGW: 双方向通信（インターネット↔VPC）、パブリックサブネットで使用。NAT GW: 単方向（VPC→インターネット）のアウトバウンド通信を提供、プライベートサブネットのインスタンスがアウトバウンドアクセスに使用

問题 57: AWS Inspector v2 と Amazon GuardDuty の主な違いは？ → 正解: Inspector v2: インフラの脆弱性スキャン（CVE/パッチ未適用）、EC2/ECR/Lambda が対象。GuardDuty: 脅威インテリジェンスに基づく実際の攻撃・不審な動作の検出（ログ分析）。両者は補完関係

問題 58: CloudFormation の cfn-init と cfn-signal の役割は？ → 正解: cfn-init: CloudFormation メタデータ（packages/files/commands）を EC2 インスタンス上で実行するヘルパースクリプト。cfn-signal: EC2 の設定完了を CloudFormation スタックに通知（CreationPolicy/WaitCondition と組み合わせ）

問題 59: AWS Systems Manager の「Session Manager」でセッションログを監査する設定は？ → 正解: Session Manager の設定で「S3 ログ」または「CloudWatch Logs」にセッション内容（コマンド履歴）を自動記録。KMS 暗号化と合わせてコンプライアンス要件に対応

問題 60: CloudWatch の「Logs Metric Filter」でアラームを作成するユースケースは？ → 正解: ログ内の特定パターン（エラーメッセージ/特定の文字列）を検出してメトリクスに変換し、アラームを設定。例: 「ERROR」を含むログが1分間に10件以上でアラーム→本番エラーの急増を検知

問題 61: Amazon CloudWatch の「GetMetricStatistics」と「GetMetricData」API の違いは？ → 正解: GetMetricStatistics: 単一メトリクスの統計値取得（最大 1440 データポイント）。GetMetricData: 複数メトリクスを一度に取得・数式計算（Math Expression）も可能。新しいAPIは GetMetricData が推奨

問題 62: EC2 の「スポットインスタンス中断通知」を受け取ってから実際に中断されるまでの時間は？ → 正解: 2分間。EventBridge または EC2 メタデータ（169.254.169.254/latest/meta-data/spot/termination-time）をポーリングして通知を受け取り、2分以内にシャットダウン処理を完了させる

問題 63: AWS Elastic Beanstalk の「Worker Environment」の用途は？ → 正解: バックグラウンドタスク処理専用の環境。SQS キューからメッセージを受け取り処理を実行。Web サーバー環境と対になって非同期処理パターンを実現。定期タスク（cron.yaml）も設定可能

問題 64: CloudFormation の「スタック保護（Termination Protection）」と「DeletionPolicy: Retain」の違いは？ → 正解: Termination Protection: スタック自体の削除を防ぐ（スタック削除のAPIコールをブロック）。DeletionPolicy: Retain: スタック削除時にそのリソースを残す（スタック削除は実行されるが特定リソースは削除しない）

問題 65: SysOps エンジニアが「月次の AWS コスト最適化レビュー」で確認すべき主要な指標は？ → 正解: (1) EC2/RDS の使用率（Compute Optimizer推奨）、(2) 未使用/アタッチされていない EBS ボリューム、(3) 未使用の Elastic IP、(4) RI/Savings Plans のカバレッジと使用率、(5) S3 のストレージクラス分布とライフサイクル設定

学習戦略

SOA-C02（廃止済み）から後継資格へ

この試験は 2025 年 9 月 29 日に廃止されています。 後継資格: SOA-C03（AWS Certified CloudOps Engineer - Associate）

本資料の内容は後継資格の学習にも有効です。

ドメイン別学習重点

Domain 1: 監視・ログ・修復（20%）
  重点: CloudWatch（メトリクス/ログ/アラーム/ダッシュボード）
  よく出る: カスタムメトリクス、アラームアクション、Logs Insights

Domain 3: デプロイ・自動化（18%）
  重点: Systems Manager（SSM）の各機能
  よく出る: Patch Manager、Session Manager、Run Command、Automation

Domain 5: ネットワーク（18%）
  重点: VPC 設計、Route 53 ルーティング、ELB の種類
  よく出る: ヘルスチェック、フェイルオーバー、Alias vs CNAME

Domain 2: 信頼性（16%）
  重点: DR 戦略（RTO/RPO）、AWS Backup、Auto Scaling
  よく出る: ライフサイクルフック、Connection Draining

Domain 4: セキュリティ（16%）
  重点: IAM ベストプラクティス、Config ルール、CloudTrail
  よく出る: 最小権限、アクセスキー管理、コンプライアンス

30 日学習プラン

Week 1: 監視と自動化
  Day 1-2:  CloudWatch（メトリクス/ログ/アラーム/ダッシュボード）
  Day 3-4:  CloudTrail + AWS Config（監査・コンプライアンス）
  Day 5-7:  Systems Manager 全機能（SSM Agent/Run Command/Patch Manager/Session Manager）

Week 2: インフラ管理
  Day 8-9:  CloudFormation（スタック操作/Change Set/ドリフト/StackSets）
  Day 10-11: Elastic Beanstalk（デプロイポリシー/Blue-Green）
  Day 12-13: Auto Scaling（スケーリングポリシー/ライフサイクルフック）
  Day 14:   AWS Backup + DR 戦略（RTO/RPO）

Week 3: ネットワーク・セキュリティ・コスト
  Day 15-16: VPC 詳細（SG/NACL/Flow Logs/Endpoints）
  Day 17-18: Route 53 + ELB（ルーティング/ヘルスチェック）
  Day 19-20: IAM + セキュリティサービス（GuardDuty/Inspector/Macie）
  Day 21:   コスト管理（Budgets/Cost Explorer/Compute Optimizer）

Week 4: 仕上げ
  Day 22-24: 本ノートの 65 問の模擬試験
  Day 25-27: 弱点補強（特に CloudWatch と Systems Manager）
  Day 28-30: 直前チェックリスト確認

試験直前チェックリスト（SOA-C02/SOA-C03）

CloudWatch 監視

• [ ] CloudWatch の基本監視（5分）と詳細監視（1分）の違いを説明できる
• [ ] カスタムメトリクスを CloudWatch Agent または API で送信できる
• [ ] CloudWatch Alarm の「M out of N」評価ルールを設定できる
• [ ] CloudWatch Logs Insights でクエリを作成できる
• [ ] CloudWatch のコンポジットアラームで複合条件を設定できる

Systems Manager

• [ ] SSM Agent の前提条件（IAM ロール、ネットワーク設定）を説明できる
• [ ] Patch Manager でパッチベースラインとメンテナンスウィンドウを設定できる
• [ ] Session Manager でキーペアなしに EC2 にアクセスできる
• [ ] Run Command で 100 台の EC2 に一括コマンドを実行できる
• [ ] SSM Automation で多段階の運用タスクを自動化できる

CloudFormation 運用

• [ ] Change Set でデプロイ前の変更内容を確認できる
• [ ] DependsOn でリソースの作成順序を制御できる
• [ ] StackSets で複数アカウント/リージョンに一括デプロイできる
• [ ] ドリフト検出でテンプレートとの差異を確認できる
• [ ] ROLLBACK_COMPLETE 状態のスタックへの対応を説明できる

信頼性・DR

• [ ] RTO と RPO の違いを説明し、AWS サービスへの対応付けができる
• [ ] Multi-AZ と Read Replica の役割の違いを説明できる
• [ ] Auto Scaling のライフサイクルフックを設定できる
• [ ] Connection Draining（Deregistration Delay）の目的を説明できる
• [ ] AWS Backup でクロスリージョン/クロスアカウントバックアップを設定できる

コスト最適化

• [ ] EC2 購入オプション（On-Demand/RI/Savings Plans/Spot）を比較できる
• [ ] AWS Cost Anomaly Detection で異常を検出できる
• [ ] Compute Optimizer の推奨事項に基づいてサイズ変更ができる
• [ ] S3 ライフサイクルルールでコストを最適化できる
• [ ] 未使用リソース（EBS/Elastic IP/ロードバランサー）を特定できる

付録：サービス比較早見表

モニタリングサービス比較

デプロイ自動化ツール比較

ストレージコスト比較（S3）

本ドキュメントは SOA-C02（廃止済み）および後継資格 SOA-C03 の学習用資料です。最新情報は AWS 公式試験ガイドをご参照ください。

CloudWatch 詳細リファレンス

CloudWatch Logs Insights クエリ集

基本的なクエリパターン:

-- エラーログの件数カウント
fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as errorCount by bin(5m)
| sort @timestamp desc

-- 上位10のエラーパターン
fields @message
| filter @message like /ERROR/
| parse @message "ERROR: *" as errorMsg
| stats count(*) as cnt by errorMsg
| sort cnt desc
| limit 10

-- Lambda コールドスタートの分析
filter @type = "REPORT"
| stats avg(@duration), max(@duration), 
        count(*) as invocations,
        sum(@initDuration)/count(*) as coldStartRate
by bin(1h)

-- HTTP エラーコードの集計（ALB/Nginx ログ）
filter status >= 400
| stats count(*) as errors by status
| sort errors desc

-- レイテンシのパーセンタイル分析
filter @type = "REPORT"
| stats pct(@duration, 50) as p50,
        pct(@duration, 95) as p95,
        pct(@duration, 99) as p99
by bin(1h)

VPC Flow Logs の分析:

-- 拒否されたトラフィックを送信元 IP 別に集計
fields srcAddr, dstAddr, dstPort, action
| filter action = "REJECT"
| stats count(*) as rejectCount by srcAddr
| sort rejectCount desc
| limit 20

-- 特定ポートへのアクセス確認
fields @timestamp, srcAddr, dstPort, action
| filter dstPort in [22, 3389, 3306]
| sort @timestamp desc

CloudWatch Metrics Insights

-- 全 EC2 インスタンスの CPU 平均
SELECT AVG(CPUUtilization)
FROM SCHEMA("AWS/EC2", InstanceId)
WHERE InstanceId IN ('i-xxxxx', 'i-yyyyy')
ORDER BY AVG() DESC
LIMIT 10

-- 過去1時間の上位10高CPU EC2
SELECT MAX(CPUUtilization)
FROM SCHEMA("AWS/EC2", InstanceId)
GROUP BY InstanceId
ORDER BY MAX() DESC
LIMIT 10

EC2 詳細設定

Launch Template vs Launch Configuration

Launch Configuration（旧）:
  - 変更不可（都度新規作成）
  - 単一バージョンのみ
  - AWS が廃止予定

Launch Template（推奨）:
  - バージョン管理が可能
  - EC2 フリートと Spot Fleet に対応
  - ユーザーデータの更新が容易
  - 複数インスタンスタイプを指定可能（Spot）
  
移行推奨: 全ての新規設定は Launch Template を使用

EC2 ユーザーデータとメタデータ

# ユーザーデータ（起動時に一度だけ実行）
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd

# インスタンスメタデータ（IMDS v2 推奨）
# Step 1: トークン取得
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token"   -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Step 2: メタデータ取得
curl -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/instance-id
curl -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole

EBS ボリューム管理

ボリュームタイプ比較:
  gp3 (General Purpose SSD):
    - 3000 IOPS, 125 MiB/s が基本（無料）
    - 最大 16,000 IOPS, 1,000 MiB/s（独立設定）
    - gp2 より安価（20%安）
    
  gp2 (旧 General Purpose):
    - IOPS = ボリュームサイズ × 3（最大 16,000）
    - バースト機能あり（小ボリュームで重要）
    
  io2 Block Express:
    - 最大 256,000 IOPS
    - レイテンシ < 1ms
    - データベース専用

スナップショット管理:
  Amazon Data Lifecycle Manager (DLM):
    スナップショットの自動作成・削除ポリシー
    例: 毎日 02:00 に作成、7日後に削除
    
  スナップショットコスト:
    変分差分のみ保存（増分スナップショット）
    最初のスナップショット後は差分のみ

ELB（Elastic Load Balancer）詳細

ALB vs NLB vs CLB 比較

Application Load Balancer（ALB）:
  Layer 7（HTTP/HTTPS）
  パスベースルーティング: /api/* → ターゲットグループ A
  ホストベースルーティング: api.example.com → ターゲットグループ B
  WebSocket サポート
  gRPC サポート
  固定 IP なし（DNS 名のみ）
  
Network Load Balancer（NLB）:
  Layer 4（TCP/UDP/TLS）
  超低レイテンシ（マイクロ秒）
  固定 IP アドレス（Elastic IP 割り当て可）
  接続数スパイクに対応
  ユースケース: ゲーム/IoT/リアルタイム通信
  
Classic Load Balancer（CLB）:
  廃止予定（現在も使用可能）
  Layer 4/7 の基本的な機能のみ
  新規では使用しない

ALB 高度な設定

スティッキーセッション（固定セッション）:
  Duration-based: 指定期間同じターゲットに送る
  Application-based: アプリが生成したCookieを使用
  用途: ステートフルアプリのセッション維持

レスポンスコードに基づくルール:
  固定レスポンス: メンテナンスページを返す（503 + カスタムメッセージ）
  リダイレクト: HTTP → HTTPS 自動リダイレクト

Connection Draining（Deregistration Delay）:
  ターゲット登録解除時に既存接続を完了させる
  デフォルト: 300秒
  無効化: 0秒（即座に切断、クリティカルなユースケース）

WAF との統合:
  ALB に WAF WebACL をアタッチ
  L7 フィルタリング（SQLi/XSS/レートリミット）

AWS Organizations との統合運用

アカウント管理

Organizations の役割:
  Management Account（管理アカウント）: 組織の管理
  Member Account（メンバーアカウント）: 実際のワークロード実行

SCP（サービスコントロールポリシー）:
  アカウントまたは OU に適用
  最大権限を制限（Allow ポリシーは意味なし）
  例: 東京リージョン以外を禁止、CloudTrail 無効化禁止

委任管理者（Delegated Admin）:
  セキュリティアカウントを特定サービスの委任管理者に設定
  例: GuardDuty、Security Hub、AWS Config の委任管理

統合 CloudTrail:
  Organization Trail で全アカウントのAPI ログを中央集約
  メンバーアカウントから無効化不可

マルチアカウント監視

アーキテクチャ:
  管理アカウント/セキュリティアカウント
    ├── Organization Trail → Central S3
    ├── GuardDuty（委任管理者）
    ├── Security Hub（委任管理者）
    └── AWS Config Aggregator

CloudWatch クロスアカウント観測:
  モニタリングアカウント: 全アカウントのメトリクスを統合表示
  ソースアカウント: データを共有するアカウント
  設定: IAM ロールとリソースポリシーで共有を許可

インシデント管理と運用プロセス

AWS Systems Manager OpsCenter

OpsItem（運用項目）:
  問題を OpsItem として登録・追跡
  CloudWatch Alarm / Events / Config Rule から自動作成

Runbook:
  OpsItem に対する対応手順書
  SSM Automation ドキュメントとしてプログラム化

統合サービス:
  GuardDuty → OpsItem 自動作成
  Security Hub → OpsItem 自動作成
  CloudWatch Alarm → OpsItem 自動作成

対応ワークフロー:
  問題検出（CloudWatch/GuardDuty）
    ↓
  OpsItem 自動作成
    ↓
  Runbook（SSM Automation）で自動対応
    ↓
  人間によるレビュー・承認
    ↓
  OpsItem クローズ

AWS Health

AWS Health Dashboard:
  AWS サービスの障害・メンテナンス情報
  
Personal Health Dashboard（PHH）:
  自分のアカウントに影響するイベントを表示
  例: 使用中の EC2 ホストのメンテナンス通知
  
AWS Health API:
  EventBridge と統合して自動応答
  例: 影響を受ける EC2 インスタンスを自動で退避

追加練習問題（30問）

問題 66

CloudWatch で EC2 インスタンスのメモリ使用率を監視できない理由は何ですか？また、どのように解決しますか？

• A. CloudWatch は EC2 のメモリを自動的に監視できないため、CloudWatch Agent をインストールしてカスタムメトリクスを送信する
• B. CloudWatch Enhanced Monitoring を有効化すれば自動的に監視できる
• C. IAM 権限を設定すれば監視できる
• D. EC2 のインスタンスタイプを変更すれば監視できる

{
  "metrics": {
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent", "mem_available_percent"]
      }
    }
  }
}

問題 67

AWS Config で「s3-bucket-server-side-encryption-enabled」ルールが Non-Compliant（非準拠）のバケットに対して、自動的に暗号化を有効化したいと考えています。最適な方法はどれですか？

• A. Config ルールに自動修復アクションを設定し、SSM Automation ドキュメント（AWS-EnableS3BucketEncryption）を指定する
• B. Lambda 関数を毎時間実行して非準拠バケットを確認・修正する
• C. CloudTrail で非準拠を検出して手動修正する
• D. S3 バケットポリシーで暗号化を強制する

問題 68

EC2 Auto Scaling グループで「スケジュールドスケーリング」を使用する典型的なユースケースはどれですか？

• A. CPU が高い時にスケールアウトする
• B. 月末の処理バッチで毎月末日の23時に自動的にインスタンス数を増やす
• C. ユーザー数に応じて動的にスケールする
• D. コストを最小化するためにインスタンス数を常に1台にする

問題 69

CloudFormation の「スタックの更新」で「更新の失敗」が起きた場合、デフォルトの動作はどうなりますか？

• A. スタックはそのまま失敗した状態で停止する
• B. 自動的に前のスタック状態にロールバックされる（UPDATE_ROLLBACK_COMPLETE）
• C. 手動でロールバックする必要がある
• D. スタックが削除される

問題 70

AWS Systems Manager Parameter Store と AWS Secrets Manager の使い分けの基準はどれですか？

• A. Parameter Store はより安価で設定値に、Secrets Manager は自動ローテーション機能が必要なシークレットに使用する
• B. Parameter Store は EC2 用、Secrets Manager は Lambda 用
• C. Parameter Store はリージョン限定、Secrets Manager はグローバル
• D. 機能的な違いはなく、使い方の好みで選ぶ

問題 71

CloudWatch のカスタムメトリクスを最もリアルタイムに近い間隔（1秒）で取得したい場合、どの設定が必要ですか？

• A. CloudWatch の「高解像度メトリクス」（StorageResolution=1）でPutMetricDataを呼び出す
• B. CloudWatch Enhanced Monitoring を有効化する
• C. CloudWatch Detailed Monitoring（詳細モニタリング）を有効化する
• D. CloudWatch Agent の設定で収集間隔を1秒に設定する

問題 72

S3 バケットのアクセスログを分析して「最もダウンロードされたオブジェクト」を確認したい場合、最も効率的な方法はどれですか？

• A. S3 コンソールで手動確認する
• B. S3 アクセスログを S3 に保存し、Amazon Athena でクエリする
• C. CloudTrail データイベントを CloudWatch Logs で分析する
• D. AWS Macie で分析する

-- S3 アクセスログのテーブルを Athena で作成後
SELECT key, count(*) as downloads
FROM s3_access_logs
WHERE operation = 'REST.GET.OBJECT'
  AND httpstatus = 200
  AND requestdatetime LIKE '[01/Mar/2024%'
GROUP BY key
ORDER BY downloads DESC
LIMIT 20;

問題 73

AWS CloudFormation の「Fn::Sub」関数の用途は？

• A. 文字列内のプレースホルダーを変数値で置換する
• B. 数値を足し算する
• C. 条件を評価して値を返す
• D. JSON をパースする

# パラメータ/リソースの参照を文字列内に埋め込む
Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      UserData:
        Fn::Base64: !Sub |
          #!/bin/bash
          echo "Region: ${AWS::Region}" > /etc/region
          echo "StackName: ${AWS::StackName}" >> /etc/info
          aws s3 cp s3://${MyBucket}/config.json /tmp/

問題 74

EC2 インスタンスを「停止（Stop）」してから「起動（Start）」した場合、EBS ルートボリュームはどうなりますか？

• A. EBS ボリュームは削除されてデータが失われる
• B. EBS ボリュームはそのまま保持され、データも維持される
• C. EBS ボリュームは自動的にスナップショットが作成される
• D. EBS ボリュームは新しい AZ に移動する

問題 75

CloudWatch ダッシュボードを別の AWS アカウントのチームメンバーと共有したい場合、どのようにしますか？

• A. ダッシュボードの URL を共有すれば誰でも見られる
• B. CloudWatch クロスアカウントダッシュボードの共有機能またはパブリックダッシュボードを使用する
• C. S3 に静的ウェブサイトとしてエクスポートして共有する
• D. CloudWatch はクロスアカウント共有に対応していない

問題 76〜95（ショート形式）

問題 76: CloudFormation の AWS::CloudFormation::WaitCondition の用途は？ → 正解: EC2 インスタンスのブートストラップ（アプリインストール等）が完了するまで CloudFormation スタックの処理を一時停止する。cfn-signal コマンドでシグナルを送ることで処理を再開

問題 77: AWS Cost Explorer の「Use Case: Reserved Instance Coverage」レポートで確認できることは？ → 正解: 実際の On-Demand 使用量のうち、RI でカバーされている割合（カバレッジ）。カバレッジが低い場合、さらに RI を購入することでコスト削減の機会がある

問題 78: EC2 Auto Scaling の「スケーリング活動（Scaling Activity）」のログで確認できる情報は？ → 正解: スケールアウト/イン理由、起動/終了されたインスタンス ID、実行時刻、成功/失敗の結果。CloudFormation コンソールの「活動」タブまたは API で取得

問題 79: AWS Config の「タイムラインビュー」を使う場面は？ → 正解: 特定リソースの設定変更履歴を時系列で確認する場合。「この EC2 インスタンスのセキュリティグループがいつ変更されたか」等のフォレンジック調査に使用

問題 80: CloudWatch の「アラーム状態」が INSUFFICIENT_DATA になる場合の原因は？ → 正解: 評価に必要なメトリクスデータが不足している場合。例: EC2 が起動したばかりでデータがない、DetailedMonitoring が無効でデータが5分間隔、メトリクスが長時間送信されていない

問題 81: Amazon SNS の「ファンアウト（Fanout）パターン」とは？ → 正解: 1つのSNSトピックに複数のサブスクライバー（SQS/Lambda/Email等）を登録して、1回の発行で複数の処理を並列実行するパターン。例: EC2 起動イベント → 監査ログ記録 + Slack 通知 + CloudFormation 処理

問題 82: RDS の「自動バックアップ」と「手動スナップショット」の違いは？ → 正解: 自動バックアップ: 毎日自動作成（保存期間 1〜35 日、デフォルト 7 日）、DB 削除で削除される。手動スナップショット: 任意のタイミングで作成、DB 削除後も保持、明示的に削除するまで残る

問題 83: EBS ボリュームの「スナップショット」の特性は？ → 正解: 増分バックアップ（最初は全体、以降は差分のみ）。複数の AZ にまたがる冗長化（S3 に保存）。スナップショットから任意のAZで新ボリュームを作成可能。暗号化スナップショットから暗号化ボリュームを作成

問題 84: CloudFormation の UpdatePolicy と DeletionPolicy の違いは？ → 正解: UpdatePolicy: リソース更新時の動作を制御（例: AutoScaling グループの更新方法）。DeletionPolicy: スタック削除時の動作を制御（Retain/Delete/Snapshot）

問題 85: AWS Systems Manager の「ドキュメント（Document）」タイプの種類は？ → 正解: Command（Run Command用）、Automation（自動化ワークフロー）、Policy（State Manager用）、Session（Session Manager用）、Package（Distributor用）。各機能に対応したドキュメントタイプを使用

問題 86: CloudWatch の「コンテナインサイト」の対応サービスは？ → 正解: Amazon ECS（EC2/Fargate）および Amazon EKS。コンテナ/タスク/サービスレベルのメトリクスを自動収集。標準メトリクスより詳細なコンテナパフォーマンス情報を提供

問題 87: S3 の「Storage Lens」の用途は？ → 正解: 組織全体の S3 使用状況の可視化・分析。ストレージ使用量、オブジェクト数、リクエスト数、コスト最適化の推奨事項を提供。Organizations 全体のビューも可能

問題 88: Route 53 の「レコードタイプ」で「AAAA」の用途は？ → 正解: IPv6 アドレスの DNS レコード（A レコードは IPv4）。AWS サービスが IPv6 をサポートしている場合（例: ALB のデュアルスタック）に使用

問題 89: EC2 の「インスタンスタイプの変更」に必要な操作は？ → 正解: インスタンスを停止 → インスタンスタイプを変更 → 起動。同じファミリー内の変更（t3.medium→t3.large等）は簡単。異なるファミリーへの変更は互換性確認が必要。インスタンスストアのデータは失われる

問題 90: AWS Security Hub の「統合（Integrations）」でサポートされているサードパーティツールは？ → 正解: Splunk、Palo Alto Networks、CrowdStrike、Jira（チケット作成）等多数。調査結果を SIEM/チケットシステムに自動連携することで運用を効率化

問題 91: CloudFormation の「スタックポリシー（Stack Policy）」の用途は？ → 正解: スタック内の特定リソースが意図せず更新・削除されることを防ぐ保護設定。例: 本番 RDS インスタンスの置き換えを禁止するポリシーを設定し、テンプレート変更ミスによる誤削除を防ぐ

問題 92: EC2 の「ハイバネーション（Hibernate）」と「停止（Stop）」の違いは？ → 正解: Hibernate: RAM の内容を EBS に保存し、起動時に RAM を復元（メモリ状態が保持）。Stop: RAM は消える（起動時にコールドスタート）。Hibernate は起動が速く、実行中プロセスの状態を維持

問題 93: AWS CloudTrail の「Insights」機能の用途は？ → 正解: 異常な API 使用パターンを検出する機能（追加費用あり）。通常とは異なるAPI呼び出し数の急増（例: 通常は1日50回のEC2起動が突然1000回に増加）を検出してアラートを発生

問題 94: VPC の「ネットワーク ACL（NACL）」でルール番号の重要性は？ → 正解: NACL のルールは番号が小さい順に評価され、最初にマッチしたルールが適用される。後続のルールは評価されない。ルール追加の余地を確保するため、100、200 など余裕を持った番号付けが推奨（ベストプラクティス）

問題 95: CloudFormation テンプレートの Parameters セクションで AllowedValues を設定する目的は？ → 正解: スタック作成/更新時に入力できる値を制限し、不正な値の入力を防ぐ。例: AllowedValues: [prod, staging, dev] で環境名の入力を3つのみに制限し、設定ミスを防止

SysOps の実践パターン集

本番デプロイのゼロダウンタイム手順

1. ブルー/グリーンデプロイ（推奨）:
   Blue（現行）環境でトラフィック処理中
   Green（新環境）に新バージョンをデプロイ
   Green でテスト・ヘルスチェック確認
   Route 53 または ALB でトラフィックを Green に切り替え
   問題があれば即座に Blue に戻す

2. ローリングアップデート（EC2 + ALB）:
   ALB から1台ずつ切り離し
   ソフトウェアアップデート
   ヘルスチェック確認
   ALB に再登録
   次のインスタンスへ繰り返し

3. Auto Scaling インスタンスリフレッシュ:
   AWS コンソール/CLI から Instance Refresh を開始
   健全性割合（例: 70%）を維持しながら順次更新
   詳細設定: スキップできるインスタンス、最大インスタンスウォームアップ

パフォーマンス問題の診断フロー

サービス遅延が発生した場合:

Step 1: 症状の確認
  CloudWatch メトリクス: CPU/メモリ/ネットワーク/ディスク
  ALB メトリクス: レイテンシ/5xxエラー率/ターゲットの応答時間
  
Step 2: ボトルネック特定
  CPU 高 → インスタンスタイプアップグレード/スケールアウト
  メモリ高 → メモリ最適化インスタンス/アプリチューニング
  DB レイテンシ高 → RDS スロークエリログ確認/Read Replica追加
  ネットワーク高 → Placement Group/VPC Endpoint/CloudFront
  
Step 3: X-Ray でマイクロサービスのボトルネック特定
  サービスマップで遅延のある箇所を可視化
  サブセグメントで具体的な処理時間を確認
  
Step 4: 対処と検証
  変更後に CloudWatch で改善を確認
  Load Testing で本番相当の負荷でテスト

付録 B：運用コマンド集

AWS CLI よく使うコマンド

# EC2 インスタンス一覧（タグフィルタ）
aws ec2 describe-instances   --filters "Name=tag:Env,Values=production"   --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Type:InstanceType}'

# SSM Run Command 実行
aws ssm send-command   --document-name "AWS-RunShellScript"   --targets "Key=tag:Env,Values=production"   --parameters 'commands=["df -h","free -m"]'   --output-s3-bucket-name my-ssm-output

# CloudWatch メトリクス取得
aws cloudwatch get-metric-statistics   --namespace AWS/EC2   --metric-name CPUUtilization   --dimensions Name=InstanceId,Value=i-xxxxx   --start-time 2024-01-01T00:00:00Z   --end-time 2024-01-01T23:59:59Z   --period 3600   --statistics Average

# CloudTrail イベント検索
aws cloudtrail lookup-events   --lookup-attributes AttributeKey=Username,AttributeValue=myuser   --start-time 2024-01-01   --end-time 2024-01-02

# S3 ライフサイクル設定
aws s3api put-bucket-lifecycle-configuration   --bucket my-bucket   --lifecycle-configuration file://lifecycle.json

本ドキュメントは SOA-C02（廃止済み）および SOA-C03 の学習用資料として完成しました。CloudWatch、Systems Manager、CloudFormation、Auto Scaling など SysOps エンジニアが日常的に扱う AWS サービスを網羅しています。

12. 高度な実装パターンとコード例

AWS Systems Manager (SSM) 完全実装

import boto3
import json
import time
from datetime import datetime, timedelta

ssm = boto3.client('ssm')
ec2 = boto3.client('ec2')

class SSMOperationsManager:
    def __init__(self):
        self.ssm = boto3.client('ssm')
        self.ec2 = boto3.client('ec2')
    
    def run_patch_baseline(self, target_tags: dict, operation: str = 'Scan'):
        """パッチ管理の実行"""
        response = self.ssm.send_command(
            Targets=[{'Key': f"tag:{k}", 'Values': [v]} for k, v in target_tags.items()],
            DocumentName='AWS-RunPatchBaseline',
            Parameters={
                'Operation': [operation],  # 'Scan' or 'Install'
                'RebootOption': ['RebootIfNeeded'],
                'SnapshotId': ['']
            },
            TimeoutSeconds=3600,
            Comment=f'Patch {operation} - {datetime.now().isoformat()}',
            OutputS3BucketName='my-ssm-output-bucket',
            OutputS3KeyPrefix=f'patch-management/{operation.lower()}/'
        )
        return response['Command']['CommandId']
    
    def create_maintenance_window(self, name: str, schedule: str):
        """メンテナンスウィンドウの作成"""
        window = self.ssm.create_maintenance_window(
            Name=name,
            Description='Automated maintenance window for patching',
            Schedule=schedule,  # cron(0 2 ? * SUN *)
            Duration=4,  # 4時間
            Cutoff=1,    # 残り1時間でタスク登録停止
            AllowUnassociatedTargets=False,
            Tags=[{'Key': 'ManagedBy', 'Value': 'SSM'}]
        )
        window_id = window['WindowId']
        
        # ターゲット登録
        target = self.ssm.register_target_with_maintenance_window(
            WindowId=window_id,
            ResourceType='INSTANCE',
            Targets=[{'Key': 'tag:PatchGroup', 'Values': ['production']}],
            Name='ProductionInstances'
        )
        
        # タスク登録（パッチ適用）
        task = self.ssm.register_task_with_maintenance_window(
            WindowId=window_id,
            Targets=[{'Key': 'WindowTargetIds', 'Values': [target['WindowTargetId']]}],
            TaskArn='AWS-RunPatchBaseline',
            TaskType='RUN_COMMAND',
            ServiceRoleArn='arn:aws:iam::123456789:role/SSMMWRole',
            MaxConcurrency='10%',
            MaxErrors='5%',
            TaskInvocationParameters={
                'RunCommand': {
                    'Parameters': {
                        'Operation': ['Install'],
                        'RebootOption': ['RebootIfNeeded']
                    },
                    'OutputS3BucketName': 'my-ssm-output-bucket',
                    'OutputS3KeyPrefix': 'maintenance-window/',
                    'CloudWatchOutputConfig': {
                        'CloudWatchOutputEnabled': True,
                        'CloudWatchLogGroupName': '/ssm/maintenance-window'
                    }
                }
            }
        )
        return window_id, target['WindowTargetId'], task['WindowTaskId']
    
    def create_patch_baseline(self, name: str, os_type: str = 'AMAZON_LINUX_2'):
        """カスタムパッチベースラインの作成"""
        baseline = self.ssm.create_patch_baseline(
            Name=name,
            OperatingSystem=os_type,
            GlobalFilters={
                'PatchFilters': [
                    {'Key': 'PRODUCT', 'Values': ['AmazonLinux2']},
                    {'Key': 'CLASSIFICATION', 'Values': ['Security', 'Bugfix']},
                    {'Key': 'SEVERITY', 'Values': ['Critical', 'Important']}
                ]
            },
            ApprovalRules={
                'PatchRules': [
                    {
                        'PatchFilterGroup': {
                            'PatchFilters': [
                                {'Key': 'SEVERITY', 'Values': ['Critical']},
                                {'Key': 'CLASSIFICATION', 'Values': ['Security']}
                            ]
                        },
                        'ApproveAfterDays': 0,  # 即時承認
                        'ComplianceLevel': 'CRITICAL',
                        'EnableNonSecurity': False
                    },
                    {
                        'PatchFilterGroup': {
                            'PatchFilters': [
                                {'Key': 'SEVERITY', 'Values': ['Important', 'Medium']}
                            ]
                        },
                        'ApproveAfterDays': 7,  # 7日後承認
                        'ComplianceLevel': 'HIGH',
                        'EnableNonSecurity': False
                    }
                ]
            },
            Tags=[{'Key': 'Environment', 'Value': 'Production'}]
        )
        return baseline['BaselineId']
    
    def get_compliance_summary(self):
        """パッチコンプライアンスサマリー"""
        paginator = self.ssm.get_paginator('list_compliance_summaries')
        compliant = 0
        non_compliant = 0
        non_compliant_instances = []
        
        for page in paginator.paginate(Filters=[{'Key': 'ComplianceType', 'Values': ['Patch']}]):
            for summary in page['ComplianceSummaryItems']:
                compliant_count = summary['CompliantSummary']['CompliantCount']
                nc_count = summary['NonCompliantSummary']['NonCompliantCount']
                compliant += compliant_count
                non_compliant += nc_count
        
        # 非準拠インスタンスの詳細取得
        paginator2 = self.ssm.get_paginator('list_resource_compliance_summaries')
        for page in paginator2.paginate(
            Filters=[
                {'Key': 'ComplianceType', 'Values': ['Patch']},
                {'Key': 'OverallSeverity', 'Values': ['CRITICAL', 'HIGH']}
            ]
        ):
            for item in page['ResourceComplianceSummaryItems']:
                if item['Status'] == 'NON_COMPLIANT':
                    non_compliant_instances.append({
                        'ResourceId': item['ResourceId'],
                        'Status': item['Status'],
                        'Severity': item['OverallSeverity']
                    })
        
        return {
            'compliant': compliant,
            'non_compliant': non_compliant,
            'compliance_rate': compliant / (compliant + non_compliant) * 100 if (compliant + non_compliant) > 0 else 0,
            'non_compliant_instances': non_compliant_instances
        }


# セッションマネージャーでのポートフォワーディング設定確認
def check_ssm_connectivity(instance_id: str):
    ssm = boto3.client('ssm')
    try:
        info = ssm.describe_instance_information(
            Filters=[{'Key': 'InstanceIds', 'Values': [instance_id]}]
        )
        if info['InstanceInformationList']:
            instance = info['InstanceInformationList'][0]
            return {
                'connected': True,
                'agent_version': instance['AgentVersion'],
                'platform': instance['PlatformName'],
                'ping_status': instance['PingStatus']  # 'Online', 'ConnectionLost', 'Inactive'
            }
        return {'connected': False, 'reason': 'Instance not registered with SSM'}
    except Exception as e:
        return {'connected': False, 'reason': str(e)}

CloudFormation スタック管理とドリフト検出

import boto3
import json
from typing import Dict, List

cfn = boto3.client('cloudformation')

class CloudFormationManager:
    def __init__(self):
        self.cfn = boto3.client('cloudformation')
    
    def deploy_stack(self, stack_name: str, template_body: str, parameters: List[Dict]):
        """スタックのデプロイ（変更セット経由）"""
        change_set_name = f"changeset-{int(time.time())}"
        
        # スタックの存在確認
        stack_exists = False
        try:
            self.cfn.describe_stacks(StackName=stack_name)
            stack_exists = True
        except self.cfn.exceptions.ClientError:
            pass
        
        # 変更セット作成
        self.cfn.create_change_set(
            StackName=stack_name,
            TemplateBody=template_body,
            Parameters=parameters,
            ChangeSetName=change_set_name,
            ChangeSetType='UPDATE' if stack_exists else 'CREATE',
            Capabilities=['CAPABILITY_IAM', 'CAPABILITY_NAMED_IAM'],
            RollbackConfiguration={
                'RollbackTriggers': [
                    {
                        'Arn': 'arn:aws:cloudwatch:ap-northeast-1:123456789:alarm/HighErrorRate',
                        'Type': 'AWS::CloudWatch::Alarm'
                    }
                ],
                'MonitoringTimeInMinutes': 10
            }
        )
        
        # 変更セット完了待機
        waiter = self.cfn.get_waiter('change_set_create_complete')
        waiter.wait(StackName=stack_name, ChangeSetName=change_set_name)
        
        # 変更セット内容確認
        change_set = self.cfn.describe_change_set(
            StackName=stack_name,
            ChangeSetName=change_set_name
        )
        
        print("変更内容:")
        for change in change_set.get('Changes', []):
            rc = change['ResourceChange']
            print(f"  {rc['Action']:6} {rc['ResourceType']:40} {rc['LogicalResourceId']}")
        
        # 変更セット実行
        self.cfn.execute_change_set(
            StackName=stack_name,
            ChangeSetName=change_set_name
        )
        
        # デプロイ完了待機
        waiter = self.cfn.get_waiter('stack_update_complete' if stack_exists else 'stack_create_complete')
        waiter.wait(StackName=stack_name)
        return True
    
    def detect_and_remediate_drift(self, stack_name: str):
        """ドリフト検出と修復"""
        # ドリフト検出開始
        detection = self.cfn.detect_stack_drift(StackName=stack_name)
        detection_id = detection['StackDriftDetectionId']
        
        # 完了待機
        while True:
            status = self.cfn.describe_stack_drift_detection_status(
                StackDriftDetectionId=detection_id
            )
            if status['DetectionStatus'] in ['DETECTION_COMPLETE', 'DETECTION_FAILED']:
                break
            time.sleep(5)
        
        if status['StackDriftStatus'] == 'DRIFTED':
            # ドリフトしたリソースの詳細
            drifted_resources = self.cfn.describe_stack_resource_drifts(
                StackName=stack_name,
                StackResourceDriftStatusFilters=['MODIFIED', 'DELETED']
            )
            
            print(f"ドリフト検出: {len(drifted_resources['StackResourceDrifts'])}件")
            for drift in drifted_resources['StackResourceDrifts']:
                print(f"  リソース: {drift['LogicalResourceId']} ({drift['ResourceType']})")
                print(f"  ステータス: {drift['StackResourceDriftStatus']}")
                
                if drift.get('PropertyDifferences'):
                    for diff in drift['PropertyDifferences']:
                        print(f"    プロパティ: {diff['PropertyPath']}")
                        print(f"    期待値: {diff['ExpectedValue']}")
                        print(f"    実際値: {diff['ActualValue']}")
            
            return drifted_resources['StackResourceDrifts']
        return []

CloudWatch 高度なアラームとダッシュボード

import boto3
import json

cw = boto3.client('cloudwatch')

class CloudWatchManager:
    def __init__(self):
        self.cw = boto3.client('cloudwatch')
    
    def create_composite_alarm(self):
        """複合アラーム（複数条件のAND/OR）"""
        # 個別アラーム作成
        self.cw.put_metric_alarm(
            AlarmName='HighCPU',
            MetricName='CPUUtilization',
            Namespace='AWS/EC2',
            Statistic='Average',
            Period=300,
            Threshold=80.0,
            ComparisonOperator='GreaterThanThreshold',
            EvaluationPeriods=3,
            TreatMissingData='notBreaching'
        )
        
        self.cw.put_metric_alarm(
            AlarmName='HighNetworkIn',
            MetricName='NetworkIn',
            Namespace='AWS/EC2',
            Statistic='Sum',
            Period=300,
            Threshold=1000000000,  # 1GB
            ComparisonOperator='GreaterThanThreshold',
            EvaluationPeriods=2,
            TreatMissingData='notBreaching'
        )
        
        # 複合アラーム（CPUかつネットワーク高負荷）
        self.cw.put_composite_alarm(
            AlarmName='HighLoadComposite',
            AlarmRule='ALARM("HighCPU") AND ALARM("HighNetworkIn")',
            AlarmDescription='CPU and Network both high - potential DDoS or heavy load',
            AlarmActions=['arn:aws:sns:ap-northeast-1:123456789:critical-alerts'],
            OKActions=['arn:aws:sns:ap-northeast-1:123456789:ok-notifications']
        )
    
    def create_anomaly_detection_alarm(self, instance_id: str):
        """機械学習ベースの異常検知アラーム"""
        # 異常検知モデル作成
        self.cw.put_anomaly_detector(
            Namespace='AWS/EC2',
            MetricName='CPUUtilization',
            Dimensions=[{'Name': 'InstanceId', 'Value': instance_id}],
            Stat='Average',
            Configuration={
                'ExcludedTimeRanges': [
                    # 定期メンテナンス時間を除外
                    {
                        'StartTime': datetime(2024, 1, 1, 2, 0),
                        'EndTime': datetime(2024, 1, 1, 4, 0)
                    }
                ],
                'MetricTimezone': 'Asia/Tokyo'
            }
        )
        
        # 異常検知アラーム
        self.cw.put_metric_alarm(
            AlarmName=f'AnomalyDetection-CPU-{instance_id}',
            Metrics=[
                {
                    'Id': 'm1',
                    'MetricStat': {
                        'Metric': {
                            'Namespace': 'AWS/EC2',
                            'MetricName': 'CPUUtilization',
                            'Dimensions': [{'Name': 'InstanceId', 'Value': instance_id}]
                        },
                        'Period': 300,
                        'Stat': 'Average'
                    }
                },
                {
                    'Id': 'ad1',
                    'Expression': 'ANOMALY_DETECTION_BAND(m1, 2)',  # 2シグマ帯域
                    'Label': 'CPUUtilization (Expected)'
                }
            ],
            ComparisonOperator': 'GreaterThanUpperThreshold',
            ThresholdMetricId': 'ad1',
            EvaluationPeriods': 3,
            TreatMissingData': 'notBreaching',
            AlarmActions': ['arn:aws:sns:ap-northeast-1:123456789:anomaly-alerts']
        )
    
    def create_dashboard(self, dashboard_name: str, instance_ids: List[str]):
        """運用ダッシュボードの作成"""
        widgets = []
        
        # EC2概要ウィジェット
        for i, instance_id in enumerate(instance_ids[:4]):  # 最大4インスタンス
            row = i // 2 * 6
            col = (i % 2) * 12
            widgets.extend([
                {
                    'type': 'metric',
                    'x': col, 'y': row, 'width': 6, 'height': 3,
                    'properties': {
                        'title': f'CPU - {instance_id}',
                        'metrics': [['AWS/EC2', 'CPUUtilization', 'InstanceId', instance_id]],
                        'period': 300,
                        'stat': 'Average',
                        'view': 'timeSeries',
                        'annotations': {
                            'horizontal': [{'value': 80, 'label': '警告閾値', 'color': '#ff7f0e'}]
                        }
                    }
                },
                {
                    'type': 'metric',
                    'x': col + 6, 'y': row, 'width': 6, 'height': 3,
                    'properties': {
                        'title': f'Memory - {instance_id}',
                        'metrics': [['CWAgent', 'mem_used_percent', 'InstanceId', instance_id]],
                        'period': 300,
                        'stat': 'Average',
                        'view': 'timeSeries'
                    }
                }
            ])
        
        self.cw.put_dashboard(
            DashboardName=dashboard_name,
            DashboardBody=json.dumps({'widgets': widgets})
        )

13. 高度なトラブルシューティングパターン

EC2 起動失敗の系統的診断

EC2 起動失敗 診断ツリー
========================

起動失敗
├── InsufficientInstanceCapacity
│   └── 別AZで再試行 / スポットフリートを使用
├── InstanceLimitExceeded
│   └── サービスクォータの引き上げ申請
├── InvalidAMIID
│   └── AMIが別リージョン・非公開でないか確認
├── InvalidSubnetID
│   └── VPC/サブネット設定確認
├── InvalidSecurityGroupID
│   └── SGが同一VPCか確認
├── UnauthorizedOperation
│   └── IAMロール/ポリシー確認
└── 起動後に接続不可
    ├── SSH 接続失敗
    │   ├── SGでport 22開放確認
    │   ├── NACLの確認
    │   ├── キーペアの一致確認
    │   └── SSM Session Manager を代替として使用
    └── ユーザーデータスクリプト失敗
        └── /var/log/cloud-init-output.log を確認

Auto Scaling トラブルシューティング

import boto3

autoscaling = boto3.client('autoscaling')

def diagnose_scaling_activities(asg_name: str):
    """Auto Scaling アクティビティの診断"""
    activities = autoscaling.describe_scaling_activities(
        AutoScalingGroupName=asg_name,
        MaxRecords=50
    )
    
    failed_activities = []
    for activity in activities['Activities']:
        if activity['StatusCode'] in ['Failed', 'Cancelled']:
            failed_activities.append({
                'ActivityId': activity['ActivityId'],
                'Description': activity['Description'],
                'StatusMessage': activity.get('StatusMessage', ''),
                'StartTime': activity['StartTime'].isoformat()
            })
    
    # よくある失敗原因の診断
    for fa in failed_activities:
        msg = fa['StatusMessage']
        if 'InsufficientInstanceCapacity' in msg:
            print(f"容量不足: 別AZを追加するか、インスタンスタイプを多様化してください")
        elif 'SpotMaxPriceTooLow' in msg:
            print(f"スポット価格不足: MaxPriceを引き上げるかオンデマンドを混在させてください")
        elif 'InvalidLaunchTemplate' in msg:
            print(f"起動テンプレートエラー: バージョン指定と権限を確認してください")
    
    return failed_activities

def check_scaling_policies(asg_name: str):
    """スケーリングポリシーの確認"""
    asg = autoscaling.describe_auto_scaling_groups(
        AutoScalingGroupNames=[asg_name]
    )['AutoScalingGroups'][0]
    
    print(f"現在のキャパシティ: {asg['DesiredCapacity']} (Min: {asg['MinSize']}, Max: {asg['MaxSize']})")
    
    # ウォームアップ・クールダウン設定確認
    print(f"デフォルトクールダウン: {asg['DefaultCooldown']}秒")
    
    policies = autoscaling.describe_policies(AutoScalingGroupName=asg_name)
    for policy in policies['ScalingPolicies']:
        print(f"\nポリシー: {policy['PolicyName']}")
        print(f"  タイプ: {policy['PolicyType']}")
        if policy['PolicyType'] == 'TargetTrackingScaling':
            config = policy['TargetTrackingConfiguration']
            print(f"  ターゲット値: {config['TargetValue']}")
            print(f"  スケールアウト無効化: {config.get('DisableScaleIn', False)}")
            if 'EstimatedInstanceWarmup' in policy:
                print(f"  ウォームアップ: {policy['EstimatedInstanceWarmup']}秒")

14. 追加模擬試験（25問）

問題 1 本番環境の EC2 インスタンスに緊急でSSHアクセスが必要ですが、セキュリティグループでポート22が閉じられており、キーペアも手元にありません。最も安全で迅速な方法は？

A. セキュリティグループを一時的に変更してSSHを許可する B. AWS Systems Manager Session Manager を使用してブラウザまたはCLIからアクセスする C. 新しいキーペアを作成してインスタンスを再起動する D. EBSボリュームを別インスタンスにアタッチしてSSHキーを修正する

答え: B 解説: Session Manager はSSHポート不要、キーペア不要でEC2インスタンスにアクセスできます。セッションは CloudTrail に記録され、IAM ポリシーでアクセス制御できます。最もセキュアな緊急アクセス手段です。

問題 2 CloudFormation スタックの更新後、RDSインスタンスが予期せず削除・再作成されました。今後同じことが起きないようにする方法は？

A. RDSをスタックから分離して手動管理する B. 削除ポリシー（DeletionPolicy: Retain）をRDSリソースに設定する C. スタック更新前に必ずバックアップを取る D. RDSのマルチAZを有効化する

答え: B 解説: DeletionPolicy: Retain を設定すると、スタックから削除・置換される場合でもRDSインスタンスは保持されます。UpdateReplacePolicy: Retain も合わせて設定することで、置換時の誤削除を防げます。

問題 3 EC2 Auto Scaling グループで、トラフィックが急増した際にスケールアウトが遅い問題が発生しています。原因として最も考えられるのは？

A. スケーリングポリシーが設定されていない B. クールダウン期間が長すぎる、またはウォームアップ期間が設定されていない C. インスタンスタイプが小さすぎる D. VPCのサブネットが少ない

答え: B 解説: デフォルトクールダウン（300秒）が長いと、スケールアウト後も追加スケールが抑制されます。またウォームアップ期間が未設定だと新インスタンスが即座にメトリクスに含まれ、必要以上のスケールを抑制する場合があります。ステップスケーリングやターゲット追跡スケーリングでのウォームアップ設定を確認します。

問題 4 AWS Config ルールで「EC2インスタンスに特定のタグがない」違反が多数検出されました。これらを自動修復する最もAWSネイティブな方法は？

A. Lambda 関数を書いてCloudWatch Eventsでトリガーする B. AWS Config の自動修復アクション（SSM Automation ドキュメント）を設定する C. Systems Manager Run Command で定期実行する D. CloudFormation StackSets で強制的にタグを付ける

答え: B 解説: AWS Config の自動修復機能は SSM Automation ドキュメントをトリガーできます。AWS-AddTagsToResource ドキュメントを使ってタグの自動付与が可能です。Config ルール違反時に即座に修復され、コンプライアンスを維持できます。

問題 5 マルチアカウント環境で、全アカウントのセキュリティ状況を一元管理したい。最適なアーキテクチャは？

A. 各アカウントに Security Hub を有効化し、Organizations との統合で集約アカウントに集める B. 各アカウントのCloudTrailログをS3に集めてAthenaで分析する C. IAM Cross-Account ロールで各アカウントを個別に確認する D. GuardDuty を管理アカウントのみに有効化する

答え: A 解説: AWS Security Hub の Organizations 統合により、管理アカウントまたは委任管理者アカウントに全メンバーアカウントのセキュリティ検出結果を集約できます。CIS ベンチマーク・AWS Foundational Security Best Practices の自動チェックも一元管理できます。

問題 6 ELB のアクセスログを分析して、過去1時間で最も多くのリクエストを送信したIPアドレスを特定したい。最もコスト効率の高い方法は？

A. ELBログをS3に保存し、Amazon Athena でSQL クエリを実行する B. CloudWatch Insights でELBメトリクスを分析する C. ELBログをElasticsearchに取り込んでKibanaで分析する D. CloudTrailでELBのAPIコールを分析する

答え: A 解説: ELBアクセスログはS3に自動保存でき、Athena でサーバーレスSQLクエリが実行できます。CREATE EXTERNAL TABLEでELBログの形式を定義し、GROUP BY client_ipで集計します。Kinesis Data Firehose や Elasticsearch より大幅にコストが低く、即座に実行できます。

問題 7 CloudWatch アラームが「INSUFFICIENT_DATA」状態のままです。考えられる原因は？

A. アラームの閾値が高すぎる B. メトリクスデータが報告されていない（エージェント未起動、インスタンス停止など） C. CloudWatch の権限が不足している D. アラームの評価期間が短すぎる

答え: B 解説: INSUFFICIENT_DATA はメトリクスデータが存在しない場合に表示されます。EC2 カスタムメトリクス（メモリ・ディスク使用率）は CloudWatch エージェントが起動していないと送信されません。インスタンスが停止中や終了済みの場合もこの状態になります。TreatMissingData: missing の設定も確認します。

問題 8 RDS Multi-AZ 環境でフェイルオーバーが発生しました。アプリケーションの接続が復旧するまでに通常どれくらいかかりますか？

A. 即座（0秒） B. 30秒〜120秒程度 C. 5〜10分 D. 手動で接続先を変更するまで復旧しない

答え: B 解説: RDS Multi-AZ フェイルオーバーは通常60〜120秒で完了します。DNS の TTL（通常5秒）の更新を待つ必要があるため、アプリケーションの接続プールが古いIPをキャッシュしている場合は追加の時間がかかります。アプリケーション側での再接続ロジック実装が重要です。

問題 9 SQS キューの処理速度が遅く、メッセージが溜まっています。Lambda でコンシューマーを実装していますが、並列度を上げたい場合の最適な設定は？

A. Lambda 関数のタイムアウトを延長する B. SQS トリガーのバッチサイズとLambdaの予約同時実行数を増やす C. SQS キューのメッセージ保持期間を延長する D. Dead Letter Queue を設定する

答え: B 解説: Lambda + SQS でのスループット向上は、バッチサイズ（最大10000）とレポート可視タイムアウト、Lambda の同時実行数（アカウント制限内）を増やすことで実現します。SQS Standard では自動的にスケールしますが、Lambda の予約同時実行数が上限になるため両方の設定が必要です。

問題 10 AWS Cost Explorer でコスト急増を検出しました。EC2 の費用が先月比 150% 増加しています。原因特定の手順として正しい順序は？

A. 即座にすべてのEC2インスタンスを停止する B. Cost Explorer でサービス別・リージョン別・タグ別にドリルダウンし、急増したリソースを特定 → CloudTrail で起動イベントを確認 → 不要リソースの停止/削除 C. AWSサポートに連絡して原因調査を依頼する D. Trusted Advisor でコスト最適化の推奨事項を確認する

答え: B 解説: コスト急増の調査は段階的に行います。Cost Explorer でリージョン・サービス・使用タイプ・タグ（チームや環境）別にドリルダウンして原因リソースを特定し、CloudTrail のRunInstancesイベントで誰が何時に起動したかを確認します。その後、不要なら停止・削除します。

問題 11 本番環境の EC2 インスタンス（i-0123456789）に意図しない設定変更が加えられた疑いがあります。いつ、誰が変更したかを特定する方法は？

A. CloudWatch メトリクスでCPU使用率の変化を確認する B. CloudTrail でイベント履歴を検索し、該当インスタンスIDでフィルタする C. EC2インスタンスのシステムログを確認する D. VPC フローログでトラフィックパターンを分析する

答え: B 解説: CloudTrail は AWS API コール（ModifyInstanceAttribute、AuthorizeSecurityGroupIngressなど）をすべて記録します。イベント履歴またはCloudTrail LakeでResourceName = "i-0123456789"でフィルタし、誰が（IAMユーザー/ロール）、いつ、どのAPIを呼んだかを特定できます。

問題 12 VPC Flow Logs を有効化しましたが、特定のEC2インスタンスのトラフィックのみログが表示されません。原因として考えられるのは？

A. Flow Logs の設定ミス B. そのインスタンスのENIにFlow Logsが設定されていない、またはトラフィックフィルタの設定 C. VPC に Flow Logs が設定されていない D. CloudWatch Logs の権限が不足している

答え: B 解説: VPC Flow Logs はVPC全体・サブネット・個別ENIの3レベルで設定できます。VPC全体に設定しても、そのインスタンスが後から追加されたENIを持つ場合、ENIレベルで別途設定が必要な場合があります。またフィルタ設定（ACCEPT/REJECT/ALL）も確認します。

問題 13 アプリケーションのデプロイ中に CodeDeploy の Blue/Green デプロイが失敗しました。ALB のターゲットグループの登録解除遅延が原因です。最適な対処法は？

A. デプロイタイムアウトを延長する B. ALBターゲットグループの登録解除遅延（Deregistration Delay）を短縮し、CodeDeploy のWaitTimeForLoadBalancerDraining を調整する C. Blue/Green から In-Place デプロイに変更する D. ECS を使って代わりにデプロイする

答え: B 解説: ALBのDeregistration Delay（デフォルト300秒）はBlue/Greenデプロイ時に古い（Blue）インスタンスへの接続が切れるまで待機します。この値を短縮（例：30秒）することでデプロイを高速化できます。CodeDeployのWaitTimeForLoadBalancerDraining設定とあわせて調整します。

問題 14 AWS Organizations の Service Control Policies (SCP) を設定しましたが、管理者が意図しないアクションをブロックされています。SCPのデバッグ方法は？

A. SCP を一時的に無効化して確認する B. IAM Policy Simulator でSCPの効果をテストする C. CloudTrail でDeny されたAPIコールを確認し、IAM Access Analyzer でポリシーを分析する D. AWSサポートに問い合わせる

答え: C 解説: SCPによるDenyは CloudTrail にエラーコードAccessDeniedとして記録されます。CloudTrail Lake またはイベント履歴でerrorCode = AccessDeniedでフィルタし、どのSCPが影響しているか特定します。IAM Access Analyzer の ValidatePolicy APIや SimulatePrincipalPolicy も活用できます。

問題 15 S3 バケットのデータが意図せず削除されました。削除されたオブジェクトを復元する前提条件は？

A. S3バケットにMFADeleteが有効化されている B. S3バケットのバージョニングが有効化されており、削除マーカーが付いている状態であること C. S3 Cross-Region Replication が設定されている D. AWS Backup でバックアップが取られている

答え: B 解説: S3バージョニングが有効の場合、DeleteObject は実際にデータを消すのではなく「削除マーカー」を作成します。削除マーカーを削除（DeleteObject with VersionId=削除マーカーのID）することで元のオブジェクトが復元されます。バージョニング無効の場合は復元不可能です。

問題 16 EC2 インスタンスの EBS ボリュームの使用率が 95% に達しています。無停止でディスクを拡張する方法は？

A. インスタンスを停止してEBSボリュームをデタッチし、新しい大きなボリュームに置き換える B. EBS Elastic Volumes を使って停止なしでボリュームサイズを変更し、OS内でファイルシステムを拡張する C. 新しいEBSボリュームをアタッチしてLVMで統合する D. インスタンスタイプをより大きなものに変更する

答え: B 解説: EBS Elastic Volumes は稼働中のインスタンスでボリュームのサイズ・タイプ・IOPSを変更できます。ModifyVolume API で変更後、OS側でもresize2fs（ext4）またはxfs_growfs（xfs）でファイルシステムを拡張します（Linux）。Windowsはディスクの管理ツールで拡張します。

問題 17 CloudWatch Logs のロググループに大量のログが蓄積されており、コストが高騰しています。コスト削減策は？

A. ロギングを無効化する B. ログ保持期間（Retention Policy）を設定し、不要なログを自動削除。重要ログはS3へエクスポートしてGlacierに移行する C. ロググループを削除して再作成する D. CloudWatch エージェントのサンプリングレートを下げる

答え: B 解説: CloudWatch Logs の主なコストはデータ取り込みとストレージです。ログ保持期間を設定（例：本番は90日、開発は7日）することでストレージコストを削減。長期保存が必要なログはS3+Glacier/Deep Archiveに移行します。重要度の低いデバッグログはログレベル調整で取り込み量を削減します。

問題 18 複数の AWS アカウントに同一の CloudFormation テンプレートをデプロイしたい。最も効率的な方法は？

A. 各アカウントに個別にデプロイする B. CloudFormation StackSets を使って Organizations または指定アカウントに一括デプロイする C. Terraform を使用する D. AWS CDK の Aspect を使用する

答え: B 解説: CloudFormation StackSets は1つのテンプレートを複数アカウント・複数リージョンに同時デプロイできます。AWS Organizations との統合により、OU（組織単位）単位でのデプロイも可能です。自動デプロイ設定により、新しいアカウントが OU に追加されると自動的にスタックが作成されます。

問題 19 ECS Fargate で実行されているコンテナのメモリリークを検出したい。実装方法は？

A. コンテナのCPU使用率を監視する B. CloudWatch Container Insights を有効化し、コンテナレベルのメモリ使用率を監視してアラームを設定する C. ECS タスク定義のメモリ制限を大きくする D. CloudWatch でカスタムメトリクスを手動で送信する

答え: B 解説: CloudWatch Container Insights は ECS/EKS クラスターのコンテナレベルのCPU・メモリ・ネットワーク使用率を自動収集します。MemoryUtilizedメトリクスを時系列で監視し、緩やかに増加するトレンドがメモリリークの兆候です。アラームで閾値超過を通知し、ECS サービスの自動再起動も設定できます。

問題 20 AWS Trusted Advisor で「Security: S3バケットパブリックアクセス」の警告が出ています。緊急対応として何をすべきですか？

A. 警告を無視する B. 対象バケットの内容を確認し、公開が意図的かどうか確認。意図しない場合はS3パブリックアクセスブロックを有効化し、バケットポリシーを修正する C. バケットを削除する D. S3 Object Lockを有効化する

答え: B 解説: 公開バケットが機密データを含む場合は深刻です。S3コンソールの「アクセス許可」タブで公開の理由（バケットポリシー/ACL/パブリックアクセスブロック設定）を確認します。意図しない場合はパブリックアクセスブロックを4項目すべて有効化し、バケットポリシーからPublicアクセス許可を削除します。CloudTrail でいつから公開になったか確認することも重要です。

問題 21 EC2 インスタンスを停止しても EBS のコストが発生し続けています。コスト最適化の方法は？

A. インスタンスを削除する B. 使用していないEBSボリュームをスナップショット取得後に削除し、必要時にスナップショットから復元する C. EBSボリュームのサイズを縮小する D. EBSをS3に置き換える

答え: B 解説: EC2を停止してもアタッチされているEBSボリュームの料金は継続して発生します。長期停止または不要なインスタンスのEBSはスナップショット（S3より低コスト）に変換して削除します。Trusted Advisor と AWS Cost Anomaly Detection でアタッチされていない「孤立EBSボリューム」を定期的にクリーンアップします。

問題 22 CloudWatch メトリクスで EC2 のディスクI/O が高い状態が続いています。EBS ボリュームのパフォーマンスを改善する方法は？

A. インスタンスタイプをより大きなものに変更する B. gp2からgp3に移行してIOPSとスループットを独立してプロビジョニングする、またはio2 Block Expressを使用する C. EBSをインスタンスストアに置き換える D. RAID 0を構成する

答え: B 解説: gp3はgp2より低コストで、IOPS（最大16,000）とスループット（最大1,000 MB/s）を独立して設定できます。gp2はボリュームサイズに比例してIOPSが変わりますが、gp3は独立設定可能です。最大I/Oが必要な場合はio2 Block Express（256,000 IOPS、4,000 MB/s）を検討します。

問題 23 Route 53 ヘルスチェックが失敗し、フェイルオーバーが発生していません。原因として最も考えられるのは？

A. TTLが長すぎる B. ヘルスチェックのタイプがHTTPだがアプリがHTTPSのみ、または Security Group でヘルスチェッカーのIPをブロックしている C. DNSレコードのタイプが間違っている D. Route 53 がダウンしている

答え: B 解説: Route 53 ヘルスチェックはAWSのグローバルヘルスチェッカーIPからアクセスします。これらIPをSGでブロックしているとヘルスチェックが常に失敗します。Route 53 ヘルスチェッカーのIPレンジをSGに許可する必要があります。またHTTP/HTTPS/TCPの設定ミスも一般的な原因です。

問題 24 AWS Backup でバックアップジョブが失敗しています。エラーメッセージは「ResourceNotFoundException」です。原因は？

A. バックアップ対象リソースが存在しない、または削除されている B. IAMロールにバックアップ権限がない C. バックアップボールトの容量が上限に達した D. リージョン間バックアップが設定されていない

答え: A 解説: ResourceNotFoundExceptionはバックアップ対象リソース（EC2/RDS/EFS/DynamoDBなど）が存在しない場合に発生します。バックアッププランに登録したリソースが削除・名前変更された可能性があります。バックアッププランのリソース選択（タグベース/リソースID）を確認し、存在するリソースが正しく選択されているか確認します。

問題 25 EC2 インスタンスが定期的に高CPU使用率になります。その時間帯はビジネス時間外（深夜2時）です。原因調査の手順は？

A. インスタンスを停止して原因がなくなるか確認する B. CloudWatch でCPU使用率のグラフを確認してピーク時刻を特定 → CloudWatch Logs でその時刻のアプリログを確認 → Systems Manager Run Command でプロセスを調査（ps aux / top） C. インスタンスタイプを大きくする D. Auto Scaling で夜間の最小インスタンス数を増やす

答え: B 解説: 定期的な高CPU問題は計画的なジョブ（バッチ処理・バックアップ・ウイルススキャン）または計画外（不正なプロセス・暗号通貨マイニングマルウェア）の可能性があります。CloudWatch でピーク時刻を特定し、その時刻のログとプロセスを分析します。不審なプロセスの場合はセキュリティインシデント対応（GuardDuty確認・インスタンス隔離）に進みます。

15. SysOps Administrator 最終チェックリスト

ドメイン別重要ポイント

モニタリング・レポーティング・修復 (Domain 1: 20%)

• [ ] CloudWatch エージェント: EC2のメモリ・ディスク使用率は標準では取得不可
• [ ] CloudWatch Logs Insights: fields, filter, stats, sort コマンドの活用
• [ ] 複合アラーム: 複数アラームのAND/OR条件
• [ ] 異常検知アラーム: 機械学習ベースの動的閾値
• [ ] CloudWatch Synthetics: APIエンドポイントの外形監視
• [ ] Amazon Managed Grafana + AMP: OSS監視スタック

高可用性と継続性 (Domain 2: 16%)

• [ ] Multi-AZ vs Multi-Region の違いと用途
• [ ] RDS フェイルオーバー時間: 60〜120秒
• [ ] Aurora Global Database: RTO < 1分、RPO < 1秒
• [ ] Route 53 フェイルオーバールーティング + ヘルスチェック
• [ ] ELB の接続ドレイン（Deregistration Delay）
• [ ] Auto Scaling ウォームアップとクールダウンの違い

デプロイメント・プロビジョニング (Domain 3: 18%)

• [ ] CloudFormation スタック vs StackSets の使い分け
• [ ] 変更セット: 変更内容の事前確認
• [ ] DeletionPolicy と UpdateReplacePolicy
• [ ] EC2 Image Builder: AMI の自動作成パイプライン
• [ ] AWS Launch Wizard: 標準アーキテクチャの迅速プロビジョニング

セキュリティとコンプライアンス (Domain 4: 16%)

• [ ] AWS Config ルール + 自動修復（SSM Automation）
• [ ] Security Hub: マルチアカウント集約
• [ ] GuardDuty 脅威検出 + EventBridge 自動対応
• [ ] IAM Access Analyzer: リソースの外部公開確認
• [ ] SCPによるアクション制限のデバッグ

ネットワークとコンテンツデリバリー (Domain 5: 18%)

• [ ] VPC フローログ: ACCEPT/REJECT フィルタ
• [ ] Route 53 ルーティングポリシーの使い分け
• [ ] CloudFront + WAF: DDoS対策・地域制限
• [ ] Transit Gateway: ハブ&スポーク接続
• [ ] AWS PrivateLink: VPC間サービス接続（インターネット非経由）

コスト管理 (Domain 6: 12%)

• [ ] Cost Explorer + Budgets + Anomaly Detection
• [ ] リザーブドインスタンス vs Savings Plans vs スポット
• [ ] Compute Optimizer: 過剰プロビジョニング検出
• [ ] S3 ストレージクラス移行（Intelligent-Tiering）
• [ ] 孤立リソースの定期クリーンアップ

試験直前確認事項

重要な数値と制限
═══════════════════════════════════════════
RDS Multi-AZ フェイルオーバー: 60〜120秒
Aurora Global DB フェイルオーバー: < 1分
Route 53 DNS TTL 最小値: 0秒
CloudWatch メトリクス保持期間:
  - 高解像度(1秒): 3時間
  - 1分: 15日
  - 5分: 63日
  - 1時間: 455日
EC2 スポットインスタンス中断通知: 2分前
EBS gp3 最大IOPS: 16,000
EBS io2 Block Express 最大IOPS: 256,000
Lambda タイムアウト最大: 15分
SQS メッセージ最大サイズ: 256KB
SQS 可視性タイムアウト最大: 12時間
S3 オブジェクト最大サイズ: 5TB
S3 マルチパートアップロード推奨: 100MB以上

重要なデフォルト値
═══════════════════════════════════════════
Auto Scaling デフォルトクールダウン: 300秒
ALB アイドルタイムアウト: 60秒
ALB 登録解除遅延: 300秒
CloudWatch アラーム評価期間 最小: 10秒
SSM Session Manager タイムアウト: 20分
CloudFormation スタック更新ロールバック: 自動

SOA-C02/SOA-C03 完全学習ガイド（拡張版）完了。SSM・CloudFormation・CloudWatch の高度な実装パターン、トラブルシューティング診断ツリー、25問追加模擬試験、最終チェックリストを収録しました。

16. AWS Well-Architected Framework と SysOps 実践

信頼性の柱 - 実装パターン

import boto3
import json
from typing import List, Dict

class ReliabilityPatterns:
    """信頼性向上のための実装パターン集"""
    
    def setup_multi_az_alb(self, vpc_id: str, subnet_ids: List[str], sg_id: str):
        """マルチAZ ALB の設定"""
        elbv2 = boto3.client('elbv2')
        
        # ALB作成（複数サブネット＝マルチAZ）
        alb = elbv2.create_load_balancer(
            Name='production-alb',
            Subnets=subnet_ids,  # 最低2つの異なるAZのサブネット
            SecurityGroups=[sg_id],
            Scheme='internet-facing',
            Type='application',
            IpAddressType='ipv4',
            Tags=[
                {'Key': 'Environment', 'Value': 'production'},
                {'Key': 'ManagedBy', 'Value': 'IaC'}
            ]
        )
        alb_arn = alb['LoadBalancers'][0]['LoadBalancerArn']
        
        # ターゲットグループ（ヘルスチェック付き）
        tg = elbv2.create_target_group(
            Name='production-tg',
            Protocol='HTTP',
            Port=8080,
            VpcId=vpc_id,
            HealthCheckProtocol='HTTP',
            HealthCheckPath='/health',
            HealthCheckIntervalSeconds=15,
            HealthCheckTimeoutSeconds=5,
            HealthyThresholdCount=2,
            UnhealthyThresholdCount=3,
            TargetType='instance',
            Matcher={'HttpCode': '200-299'}
        )
        tg_arn = tg['TargetGroups'][0]['TargetGroupArn']
        
        # リスナー（HTTPSリダイレクト）
        http_listener = elbv2.create_listener(
            LoadBalancerArn=alb_arn,
            Protocol='HTTP',
            Port=80,
            DefaultActions=[{
                'Type': 'redirect',
                'RedirectConfig': {
                    'Protocol': 'HTTPS',
                    'Port': '443',
                    'StatusCode': 'HTTP_301'
                }
            }]
        )
        
        https_listener = elbv2.create_listener(
            LoadBalancerArn=alb_arn,
            Protocol='HTTPS',
            Port=443,
            Certificates=[{'CertificateArn': 'arn:aws:acm:ap-northeast-1:123456789:certificate/xxx'}],
            SslPolicy='ELBSecurityPolicy-TLS13-1-2-2021-06',
            DefaultActions=[{
                'Type': 'forward',
                'TargetGroupArn': tg_arn
            }]
        )
        
        return alb_arn, tg_arn
    
    def configure_circuit_breaker_alb(self, tg_arn: str):
        """ALB ターゲットグループのサーキットブレーカー設定"""
        elbv2 = boto3.client('elbv2')
        
        # スロー開始（Slow Start）- 新規インスタンスへのトラフィックを徐々に増やす
        elbv2.modify_target_group_attributes(
            TargetGroupArn=tg_arn,
            Attributes=[
                {'Key': 'slow_start.duration_seconds', 'Value': '60'},  # 60秒かけて全トラフィック
                {'Key': 'deregistration_delay.timeout_seconds', 'Value': '30'},
                {'Key': 'load_balancing.algorithm.type', 'Value': 'least_outstanding_requests'},
                {'Key': 'target_group_health.unhealthy_state_routing.minimum_healthy_targets.count', 'Value': '1'},
                {'Key': 'target_group_health.dns_failover.minimum_healthy_targets.count', 'Value': '1'}
            ]
        )


class BackupAndRecovery:
    """バックアップと復元戦略"""
    
    def create_backup_plan(self, plan_name: str):
        """AWS Backup プランの作成"""
        backup = boto3.client('backup')
        
        # バックアッププラン
        plan = backup.create_backup_plan(
            BackupPlan={
                'BackupPlanName': plan_name,
                'Rules': [
                    {
                        'RuleName': 'DailyBackup',
                        'TargetBackupVaultName': 'production-vault',
                        'ScheduleExpression': 'cron(0 17 ? * * *)',  # 毎日JST 02:00
                        'StartWindowMinutes': 60,
                        'CompletionWindowMinutes': 180,
                        'Lifecycle': {
                            'MoveToColdStorageAfterDays': 30,
                            'DeleteAfterDays': 365
                        },
                        'CopyActions': [
                            {
                                'DestinationBackupVaultArn': 'arn:aws:backup:us-west-2:123456789:backup-vault:dr-vault',
                                'Lifecycle': {
                                    'DeleteAfterDays': 90
                                }
                            }
                        ]
                    },
                    {
                        'RuleName': 'WeeklyBackup',
                        'TargetBackupVaultName': 'production-vault',
                        'ScheduleExpression': 'cron(0 15 ? * SUN *)',  # 毎週日曜 JST 00:00
                        'StartWindowMinutes': 60,
                        'CompletionWindowMinutes': 360,
                        'Lifecycle': {
                            'DeleteAfterDays': 2555  # 7年
                        }
                    }
                ]
            }
        )
        plan_id = plan['BackupPlanId']
        
        # バックアップ選択（タグベース）
        backup.create_backup_selection(
            BackupPlanId=plan_id,
            BackupSelection={
                'SelectionName': 'production-resources',
                'IamRoleArn': 'arn:aws:iam::123456789:role/AWSBackupDefaultServiceRole',
                'ListOfTags': [
                    {
                        'ConditionType': 'STRINGEQUALS',
                        'ConditionKey': 'Environment',
                        'ConditionValue': 'production'
                    },
                    {
                        'ConditionType': 'STRINGEQUALS',
                        'ConditionKey': 'Backup',
                        'ConditionValue': 'enabled'
                    }
                ],
                'Resources': [
                    'arn:aws:dynamodb:*:*:table/*',
                    'arn:aws:rds:*:*:db:*',
                    'arn:aws:ec2:*:*:volume/*',
                    'arn:aws:elasticfilesystem:*:*:file-system/*'
                ]
            }
        )
        return plan_id

運用ランブック自動化

# SSM Automation ドキュメント: EC2 トラブルシューティングランブック
# ファイル: ssm_runbook_ec2_troubleshoot.yaml
description: "EC2インスタンスの自動トラブルシューティングランブック"
schemaVersion: "0.3"
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  InstanceId:
    type: String
    description: "対象EC2インスタンスID"
  AutomationAssumeRole:
    type: String
    description: "Automation実行ロールARN"

mainSteps:
  - name: CheckInstanceState
    action: aws:waitForAwsResourceProperty
    inputs:
      Service: ec2
      Api: DescribeInstances
      InstanceIds:
        - "{{ InstanceId }}"
      PropertySelector: "$.Reservations[0].Instances[0].State.Name"
      DesiredValues:
        - running
    onFailure: step:StartInstance

  - name: StartInstance
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: StartInstances
      InstanceIds:
        - "{{ InstanceId }}"
    isEnd: false

  - name: CheckSSMAgent
    action: aws:executeAwsApi
    inputs:
      Service: ssm
      Api: DescribeInstanceInformation
      Filters:
        - Key: InstanceIds
          Values:
            - "{{ InstanceId }}"
    outputs:
      - Name: PingStatus
        Selector: "$.InstanceInformationList[0].PingStatus"
        Type: String

  - name: CollectDiagnostics
    action: aws:runCommand
    inputs:
      DocumentName: AWS-RunShellScript
      InstanceIds:
        - "{{ InstanceId }}"
      Parameters:
        commands:
          - "echo '=== System Info ==='"
          - "uptime && free -m && df -h"
          - "echo '=== Top Processes ==='"
          - "ps aux --sort=-%cpu | head -20"
          - "echo '=== Network Connections ==='"
          - "ss -tlnp"
          - "echo '=== Recent Errors ==='"
          - "journalctl -p err --since '1 hour ago' | tail -50"
      OutputS3BucketName: "my-ssm-diagnostics"
      OutputS3KeyPrefix: "diagnostics/{{ InstanceId }}/"

  - name: NotifyOps
    action: aws:executeAwsApi
    inputs:
      Service: sns
      Api: Publish
      TopicArn: "arn:aws:sns:ap-northeast-1:123456789:ops-notifications"
      Subject: "EC2 診断完了: {{ InstanceId }}"
      Message: "インスタンス {{ InstanceId }} の診断が完了しました。S3の診断ログを確認してください。"

17. 高度な Cost Optimization パターン

Savings Plans と Reserved Instances の最適化

import boto3
from datetime import datetime, timedelta

class CostOptimizationAnalyzer:
    def __init__(self):
        self.ce = boto3.client('ce')
        self.co = boto3.client('compute-optimizer')
    
    def analyze_rightsizing_recommendations(self):
        """コンピュートオプティマイザーからの推奨事項取得"""
        paginator = self.co.get_paginator('get_ec2_instance_recommendations')
        recommendations = []
        
        for page in paginator.paginate(
            Filters=[
                {'name': 'Finding', 'values': ['OVER_PROVISIONED']},
                {'name': 'RecommendationSourceType', 'values': ['Ec2Instance']}
            ]
        ):
            for rec in page['instanceRecommendations']:
                current = rec['currentInstanceType']
                savings = 0
                best_option = None
                
                for option in rec.get('recommendationOptions', []):
                    if option.get('estimatedMonthlySavings', {}).get('value', 0) > savings:
                        savings = option['estimatedMonthlySavings']['value']
                        best_option = option['instanceType']
                
                if best_option and savings > 10:  # $10以上の削減可能
                    recommendations.append({
                        'instance_id': rec['instanceArn'].split('/')[-1],
                        'current_type': current,
                        'recommended_type': best_option,
                        'monthly_savings_usd': savings,
                        'risk': rec.get('finding', 'UNKNOWN')
                    })
        
        return sorted(recommendations, key=lambda x: x['monthly_savings_usd'], reverse=True)
    
    def get_coverage_report(self):
        """リザーブドインスタンスとSavings Plansのカバレッジ確認"""
        end = datetime.now().strftime('%Y-%m-%d')
        start = (datetime.now() - timedelta(days=30)).strftime('%Y-%m-%d')
        
        # リザーブドインスタンスカバレッジ
        ri_coverage = self.ce.get_reservation_coverage(
            TimePeriod={'Start': start, 'End': end},
            Granularity='MONTHLY',
            GroupBy=[{'Type': 'DIMENSION', 'Key': 'INSTANCE_TYPE'}]
        )
        
        # Savings Plans カバレッジ
        sp_coverage = self.ce.get_savings_plans_coverage(
            TimePeriod={'Start': start, 'End': end},
            Granularity='MONTHLY'
        )
        
        total_ri_coverage = ri_coverage['Total']['CoverageHours']['CoverageHoursPercentage']
        total_sp_coverage = sp_coverage['Total'].get('CoveragePercentage', '0')
        
        print(f"RI カバレッジ: {total_ri_coverage}%")
        print(f"Savings Plans カバレッジ: {total_sp_coverage}%")
        
        # オンデマンドコストの多いサービス
        on_demand_cost = self.ce.get_cost_and_usage(
            TimePeriod={'Start': start, 'End': end},
            Granularity='MONTHLY',
            Filter={
                'Dimensions': {
                    'Key': 'PURCHASE_TYPE',
                    'Values': ['On Demand']
                }
            },
            GroupBy=[{'Type': 'DIMENSION', 'Key': 'SERVICE'}],
            Metrics=['UnblendedCost']
        )
        
        services_cost = []
        for result in on_demand_cost['ResultsByTime']:
            for group in result['Groups']:
                service = group['Keys'][0]
                cost = float(group['Metrics']['UnblendedCost']['Amount'])
                if cost > 50:  # $50以上
                    services_cost.append({'service': service, 'cost': cost})
        
        return {
            'ri_coverage': total_ri_coverage,
            'sp_coverage': total_sp_coverage,
            'high_od_cost_services': sorted(services_cost, key=lambda x: x['cost'], reverse=True)
        }
    
    def setup_cost_anomaly_detection(self):
        """コスト異常検知の設定"""
        # モニター作成（サービス別）
        monitor = self.ce.create_anomaly_monitor(
            AnomalyMonitor={
                'MonitorName': 'ServiceCostMonitor',
                'MonitorType': 'DIMENSIONAL',
                'MonitorDimension': 'SERVICE'
            }
        )
        monitor_arn = monitor['MonitorArn']
        
        # サブスクリプション（アラート設定）
        subscription = self.ce.create_anomaly_subscription(
            AnomalySubscription={
                'SubscriptionName': 'CostAnomalyAlerts',
                'MonitorArnList': [monitor_arn],
                'Subscribers': [
                    {
                        'Address': 'cost-alerts@example.com',
                        'Type': 'EMAIL'
                    },
                    {
                        'Address': 'arn:aws:sns:ap-northeast-1:123456789:cost-alerts',
                        'Type': 'SNS'
                    }
                ],
                'Threshold': 20.0,  # $20以上の異常なコスト増加
                'Frequency': 'DAILY'
            }
        )
        return monitor_arn, subscription['SubscriptionArn']

18. 試験対策: よく出るシナリオ別回答パターン

HA/DR シナリオ

コスト最適化シナリオ

セキュリティインシデント対応フロー

インシデント検知（GuardDuty / Security Hub）
           ↓
     重大度評価（Critical/High/Medium/Low）
           ↓
     ────────────────────────────────────
     Critical/High          Medium/Low
           ↓                     ↓
  即時自動対応             次営業日対応
  (EventBridge→Lambda)      (チケット起票)
           ↓
  ┌────────────────────┐
  │ EC2 侵害疑い       │
  │ → SG変更で隔離     │
  │ → スナップショット │
  │ → フォレンジック   │
  └────────────────────┘
  ┌────────────────────┐
  │ IAM 認証情報漏洩   │
  │ → キー無効化       │
  │ → ロール権限削除   │
  │ → CloudTrail調査   │
  └────────────────────┘
  ┌────────────────────┐
  │ S3 公開バケット    │
  │ → Public Access    │
  │   Block有効化      │
  │ → バケットポリシー │
  │   修正             │
  └────────────────────┘
           ↓
     根本原因分析（RCA）
           ↓
     再発防止策（Config ルール追加）
           ↓
     インシデントクローズ

SOA-C02/SOA-C03 完全学習ガイド（最終版）完了。Well-Architected 実装パターン、コスト最適化、運用ランブック自動化を追加収録。

19. AWS Config 高度なルールとコンプライアンス自動化

カスタム Config ルール実装

import boto3
import json

def lambda_handler(event, context):
    """カスタム AWS Config ルール: タグポリシー検証"""
    invoking_event = json.loads(event['invokingEvent'])
    rule_parameters = json.loads(event.get('ruleParameters', '{}'))
    
    required_tags = rule_parameters.get('requiredTags', 'Environment,Owner,CostCenter').split(',')
    
    config = boto3.client('config')
    
    # リソース情報の取得
    configuration_item = invoking_event.get('configurationItem')
    if not configuration_item:
        return
    
    resource_type = configuration_item['resourceType']
    resource_id = configuration_item['resourceId']
    tags = configuration_item.get('tags', {})
    
    # タグ検証
    missing_tags = [tag for tag in required_tags if tag not in tags or not tags[tag]]
    
    if missing_tags:
        compliance_type = 'NON_COMPLIANT'
        annotation = f'必須タグが不足: {", ".join(missing_tags)}'
    else:
        compliance_type = 'COMPLIANT'
        annotation = 'すべての必須タグが設定済み'
    
    # 評価結果の報告
    config.put_evaluations(
        Evaluations=[
            {
                'ComplianceResourceType': resource_type,
                'ComplianceResourceId': resource_id,
                'ComplianceType': compliance_type,
                'Annotation': annotation,
                'OrderingTimestamp': configuration_item['configurationItemCaptureTime']
            }
        ],
        ResultToken=event['resultToken']
    )


def setup_config_aggregator():
    """Config アグリゲーター（Organizations統合）"""
    config = boto3.client('config')
    
    aggregator = config.put_configuration_aggregator(
        ConfigurationAggregatorName='OrganizationAggregator',
        OrganizationAggregationSource={
            'RoleArn': 'arn:aws:iam::123456789:role/AWSConfigRoleForOrganizations',
            'AllAwsRegions': True
        }
    )
    
    # 集約ビューからの準拠状況クエリ
    results = config.select_aggregate_resource_config(
        Expression="""
            SELECT 
                resourceId,
                resourceType,
                awsRegion,
                accountId,
                tags,
                configuration
            WHERE 
                resourceType = 'AWS::EC2::Instance'
                AND configuration.state.name = 'running'
                AND tags.Environment = 'production'
        """,
        ConfigurationAggregatorName='OrganizationAggregator'
    )
    
    return results

EventBridge + Lambda による自動修復パイプライン

import boto3
import json

def auto_remediation_handler(event, context):
    """Security Hub 検出結果の自動修復"""
    detail = event.get('detail', {})
    findings = detail.get('findings', [])
    
    for finding in findings:
        severity = finding.get('Severity', {}).get('Label', 'INFORMATIONAL')
        generator_id = finding.get('GeneratorId', '')
        resource_type = finding.get('Resources', [{}])[0].get('Type', '')
        resource_id = finding.get('Resources', [{}])[0].get('Id', '')
        
        # Critical/High のみ自動修復
        if severity not in ['CRITICAL', 'HIGH']:
            continue
        
        print(f"自動修復対象: {generator_id} | {resource_type} | {resource_id}")
        
        # S3 パブリックアクセス修復
        if 'S3.2' in generator_id or 'S3.3' in generator_id:
            bucket_name = resource_id.split(':::')[-1]
            remediate_s3_public_access(bucket_name)
        
        # セキュリティグループ修復（全開放）
        elif 'EC2.19' in generator_id or 'EC2.25' in generator_id:
            sg_id = resource_id.split('/')[-1]
            remediate_security_group(sg_id)
        
        # IAM アクセスキー 90日以上未ローテーション
        elif 'IAM.3' in generator_id:
            username = resource_id.split('/')[-1]
            notify_iam_rotation_required(username)


def remediate_s3_public_access(bucket_name: str):
    s3 = boto3.client('s3')
    s3.put_public_access_block(
        Bucket=bucket_name,
        PublicAccessBlockConfiguration={
            'BlockPublicAcls': True,
            'IgnorePublicAcls': True,
            'BlockPublicPolicy': True,
            'RestrictPublicBuckets': True
        }
    )
    print(f"S3 {bucket_name}: パブリックアクセスブロック有効化完了")


def remediate_security_group(sg_id: str):
    ec2 = boto3.client('ec2')
    sg = ec2.describe_security_groups(GroupIds=[sg_id])['SecurityGroups'][0]
    
    dangerous_rules = []
    for rule in sg.get('IpPermissions', []):
        for ip_range in rule.get('IpRanges', []):
            if ip_range.get('CidrIp') == '0.0.0.0/0':
                if rule.get('FromPort', 0) in [22, 3389, 1433, 3306]:
                    dangerous_rules.append(rule)
    
    if dangerous_rules:
        ec2.revoke_security_group_ingress(
            GroupId=sg_id,
            IpPermissions=dangerous_rules
        )
        print(f"SG {sg_id}: 危険なインバウンドルール削除完了")


def notify_iam_rotation_required(username: str):
    sns = boto3.client('sns')
    sns.publish(
        TopicArn='arn:aws:sns:ap-northeast-1:123456789:security-alerts',
        Subject=f'IAM アクセスキーローテーション要求: {username}',
        Message=f'ユーザー {username} のアクセスキーが90日以上ローテーションされていません。'
                f'セキュリティポリシーに従い、速やかにキーをローテーションしてください。'
    )

20. SysOps 試験 スコアアップ確認事項

紛らわしい選択肢のポイント

必須 AWS CLI コマンド

# SSM パラメータストア操作
aws ssm get-parameter --name "/prod/db/password" --with-decryption
aws ssm put-parameter --name "/prod/api/key" --value "xxx" --type SecureString

# CloudWatch ログのリアルタイム監視
aws logs tail /aws/lambda/my-function --follow

# EC2 インスタンス情報の一括取得
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,AZ:Placement.AvailabilityZone,IP:PrivateIpAddress}' \
  --output table

# Auto Scaling グループのスケーリング履歴
aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name production-asg \
  --max-records 20

# CloudFormation スタックのイベント確認
aws cloudformation describe-stack-events \
  --stack-name my-stack \
  --query 'StackEvents[?ResourceStatus==`CREATE_FAILED` || ResourceStatus==`UPDATE_FAILED`]'

# コスト確認（今月）
aws ce get-cost-and-usage \
  --time-period Start=$(date +%Y-%m-01),End=$(date +%Y-%m-%d) \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# S3 バケットのパブリックアクセス設定確認
aws s3api get-public-access-block --bucket my-bucket

# GuardDuty 検出結果確認
aws guardduty list-findings \
  --detector-id $(aws guardduty list-detectors --query 'DetectorIds[0]' --output text) \
  --finding-criteria '{"Criterion":{"severity":{"Gte":7}}}'

SOA-C02/SOA-C03 AWS SysOps Administrator 完全学習ガイド完了。全18セクション・25問追加模擬試験・自動化実装コード・最終チェックリストを収録。試験合格を祈念します。