SAP以外の現行AWS資格を全部持ってる奴がSAP-C02に向けて追加確認したこと

嘘です。AI Business Strategistは未取得です。

はじめに

先日、AWS SAP-C02(AWS Certified Solutions Architect - Professional)を取得しました。

2026年10月時点で受験可能なAWS資格のうち、SAPを除く11個を取得済みの状態で臨みました。
(リタイア予定のANS-C01を含みます)

知らないサービスはほぼ出題されない状態で、追加で確認したことや勉強しなおした内容をまとめます。

AWS Certified Solutions Architect - Professionalは、2026年11月17日にSAP-C03に更新予定です。
SAP-C02は2026年11月16日まで受験可能です。

ネットワーク

Direct Connect

• DXGWはBGP経路情報の交換を担当
• 接続パターン
  • Private VIF → VGW → VPC
  • Private VIF → DXGW → VGW → VPC
  • Transit VIF → DXGW → TGW → VPC
• 接続の制約
  • VGWへの接続：DXGWは省略できる
  • TGWへの接続：DXGWは必須
  • 1つのDXGWにVGWとTGWの両方を関連付けることはできない
  • DXGWはTGW間の通信を中継しない
• VGWへの接続でDXGWを使うメリット
  • 1つのDXGWに複数のVGWを関連付け
  • 1つのPrivate VIFから複数のVPCに接続
  • リージョンをまたぐVPCにも接続
• リージョン
  • DXGWはグローバルリソース
  • TGWはリージョナルリソース
  • 1つのDXGWに複数リージョンのTGWを関連付け
  • リージョンをまたぐTGW同士はTGWピアリングで接続
• 冗長化
  • DXGWは内部で冗長化済み
  • DX回線は異なるDXロケーションへ分散

Transit Gateway

• TGWの共有
  • AWS RAMで他アカウントと共有
  • 共有したTGWに各アカウントのVPCを接続

Site-to-Site VPN

• 接続先
  • VGW：単一VPCへ接続
  • TGW：複数VPCへの接続を集約
• ルーティング
  • 静的ルーティング：VGW・TGWともに対応
  • BGP：VGW・TGWともに対応

VPCピアリング

• 接続範囲
  • クロスアカウント接続に対応
  • クロスリージョン接続に対応
  • 同じOrganizationsに属している必要はない
• 制約
  • CIDRが重複するVPC同士は接続不可
  • 推移的ルーティングには非対応
    • A–BとB–Cを接続してもA–C間は通信不可
• 双方のVPCのルートテーブルに相手VPCへの経路を追加
• リージョン間のVPCピアリングもインターネットは経由しない
• クロスアカウント接続の承認
  • 手動：受け入れ側アカウントのIAMユーザ／ロールの権限で承認
  • CloudFormation：PeerRoleArnで指定した受け入れ側のIAMロールを引き受けて承認

Route 53 Resolver

• エンドポイント
  • Inbound：外部DNS → VPC Resolver
  • Outbound：VPC Resolver → 外部DNS
  • オンプレミスとのDNS転送に対応
  • 別VPCとのDNS転送にも対応
• プライベートホストゾーン（PHZ）
  • 同じPHZを複数VPCに直接関連付け
  • 直接関連付けたVPCではPHZ参照用の転送エンドポイントは不要
• DNS転送ループ
  • 同じドメインを自分のInbound Endpointへ戻すとループのおそれ

NAT GatewayとGateway Endpoint

• ゾーナルNAT GatewayのAZ障害対策
  • NAT Gatewayを各AZに配置
  • 各サブネットから同じAZのNAT Gatewayへ転送
• Gateway Endpoint
  • 対応サービス：S3／DynamoDB
  • ルートテーブルで通信経路を指定
  • エンドポイント自体の利用料金は不要
• S3へのアクセス
  • 同一リージョンのS3への通信に利用
  • S3通信に伴うNAT Gatewayのデータ処理料金を削減
• S3へのアクセス制御
  • エンドポイントポリシーはそのエンドポイント経由のアクセスに適用
  • バケットへのアクセス経路の制限にはバケットポリシーを使用

VPC IPAMとマネージドプレフィックスリスト

• VPC IPAM
  • CIDRの割り当て管理
  • CIDRの重複防止
  • IPAMプールはSGの送信元に直接指定できない
• マネージドプレフィックスリスト
  • 複数のCIDRを一覧に集約
  • SGやルートテーブルから参照
  • 一覧の更新を参照先にも反映
• AWS RAMによる共有
  • IPAMプール：共有先でのCIDR割り当てに利用
  • プレフィックスリスト：共有先からのCIDR一覧の参照に利用

コンピュート・スケーリング

• Lightsailの仮想サーバ内のOS・アプリケーションは利用者が管理

Elastic Beanstalkの環境変更

• 環境タイプ
  • Single Instance：EC2単一インスタンス
  • Load Balanced：ロードバランサ＋Auto Scaling
• 既存環境で変更可能
  • Single Instance ⇔ Load Balanced
  • EC2インスタンスタイプ
  • EC2インスタンス数・Auto Scaling設定
• 新しい環境が必要
  • ロードバランサの種類
  • 環境ティア（Web Server／Worker）
• Rebuildは同じ設定で環境のリソースを再作成

スケーリング対象

• EC2 Auto Scaling：EC2インスタンス数を調整
• Application Auto Scaling
  • ECS：サービスのタスク数
  • Aurora：Reader数
  • Lambda：プロビジョンド同時実行数

Auto Scalingグループの設定とプロセス

• 複数AZを指定しても稼働台数が1台なら単一AZで稼働
• 属性ベースのインスタンスタイプ選択
  • vCPU・メモリなどの必要条件を指定
  • 条件に一致するインスタンスタイプを自動選択
  • 起動テンプレート：対応
  • 起動設定：非対応
  • 起動台数を決めるスケーリングポリシーとは別
• 停止するプロセスと効果
  • HealthCheck：新たな異常判定を停止
  • ReplaceUnhealthy：異常インスタンスの置換を停止
  • Terminate：Auto Scalingによるインスタンス終了を停止
• HealthCheck停止だけでは判定済みの異常インスタンスの置換は止まらない
• スケールイン保護
  • 通常のスケールインによる終了を防止
  • 異常インスタンスの置換は防止しない

EC2のインスタンス選択と配置

• インスタンスファミリー
  • コンピューティング最適化（C系）：CPUに対するメモリ容量が少なめ
  • メモリ最適化（R系・X系）：CPUに対するメモリ容量が多め
  • C系が必ずCPU性能で上回るわけではない
• プレイスメントグループ
  • クラスタ
    • 単一AZ内で近接配置
    • 低レイテンシ・高スループットを重視
  • スプレッド
    • インスタンスごとにラックを分離
    • 複数AZで利用可能
    • ラックレベルでは1AZあたり最大7台
  • パーティション
    • パーティションごとにラックを分離
    • 複数AZで利用可能
    • 1AZあたり最大7パーティション
  • 精度時間（Precision time）：高精度時刻同期に対応したハードウェアへ配置

EKSでのGraviton利用

• 実行環境
  • EC2ノード／Auto Mode：Gravitonを利用可能
  • EKS on Fargate：Arm64非対応
• コンテナイメージはArm64対応が必要
• x86ノードとGravitonノードを混在可能
  • nodeSelectorなどでPodの配置先を指定
• ECS on FargateはArm64対応

実行場所の拡張

• AWS Outposts
  • 利用者の施設でAWSサービスを実行
  • 親リージョンとのService Link接続が必要
• AWS Local Zones：利用者に近いAWSの都市圏拠点で処理を実行
• AWS Wavelength：通信事業者の5Gネットワーク内で処理を実行

ロードバランサとGlobal Accelerator

ALB

• HTTPSはALBでTLS終端
• 固定IP
  • ALB単体では固定IPを指定不可
  • 固定IPが必要なら前段にNLBまたはGAを配置
• Lambdaを直接ターゲットに登録可能
• 固定レスポンス
  • リスナルールに一致したリクエストへ返却
  • ターゲットの応答ステータスはルール条件に指定不可

NLB

• PrivateLinkによるサービス公開に対応
• TLSの扱い
  • TCPリスナ：TLSパススルー
  • TLSリスナ：NLBでTLS終端
  • パススルー時はアプリ側でTLS終端
• Lambdaを直接ターゲットに登録不可

GWLB

• GENEVEで元のIPパケットをカプセル化してアプライアンスへ転送
• アプライアンス側で元の送信元IPを確認

Global Accelerator（GA）

• 固定IP
  • Anycastの固定パブリックIPで公開
  • リージョン切替時も利用者側の接続先IPは変更不要
• 通信経路の最適化
  • 利用者に近いAWSの拠点で通信を受付
  • AWSの拠点間ネットワークで接続先へ転送
• エンドポイントの正常性に応じて別リージョンへ接続を振り分け
• S3バケットは直接エンドポイントに指定不可

組合せと役割分担

• 固定IPとパスベースルーティング
  • NLB → ALB → アプリ
  • GA → ALB → アプリ
• TCP/UDPの負荷分散と通信経路の最適化
  • GA → NLB → アプリ
• PrivateLinkと通信経路の最適化
  • GA → NLB → ALB → アプリ
• 固定IPだけではNLBとGAを重ねる理由にならない

オンプレミスから固定IPでALBへ接続

• プライベートIPで接続
  • Private VIF → 内部NLB → ALB
  • 許可リストには内部NLBの固定IPを登録
• 同じ固定パブリックIPで複数リージョンのALBを切替
  • Public VIF → Global Accelerator → 各リージョンのALB
  • 許可リストにはGlobal Acceleratorの固定IPを登録

CloudFront

S3をオリジンにした配信

• S3バケットを直接オリジンに指定
  • S3の静的Webサイトホスティング設定は不要
  • OACでS3を非公開のまま配信
• S3の静的Webサイトエンドポイントをオリジンに指定
  • S3の静的Webサイトホスティング設定が必要
  • OACは利用不可
• サーバ側で動的なページを生成するにはS3以外の実行環境が必要

カスタムエラーレスポンス

• S3にエラーページを置く場合
  • エラーページ用のS3をオリジンとして登録
  • エラーページのパスをS3へ振り分けるキャッシュビヘイビアを設定
• エラーのキャッシュ
  • Error Caching Minimum TTLで最小キャッシュ時間を設定
  • 復旧後もキャッシュが残っている間はエラーを返す場合がある

オリジングループによるフェイルオーバー

• 構成
  • プライマリとセカンダリの2オリジンを登録
  • キャッシュビヘイビアの転送先にオリジングループを指定
• セカンダリへ切り替える条件
  • 設定したHTTPエラーステータスが返る
  • 接続失敗：503を切替対象に指定した場合
  • 応答タイムアウト：504を切替対象に指定した場合
• 制約
  • 対象メソッドはGET／HEAD／OPTIONS
  • タイムアウトせず正常応答するなら遅くても切り替えない
  • オリジングループだけでは地域別に振り分けない

動的オリジン選択

• 地域別の配信
  • S3 CRRでデータを複数リージョンに複製
  • 利用者の地域に応じて参照先のオリジンを変更
  • キャッシュミス時の遠距離アクセスを削減
• オリジンの登録
  • ディストリビューションには最低1つのオリジンが必要
  • Lambda@Edgeでは未登録のオリジンも指定可能

CloudFront FunctionsとLambda@Edge

• オリジン変更
  • 両方で動的オリジン選択に対応
  • CloudFront Functions
    • 登録済みオリジンから転送先を選択
    • 転送先のドメインなどの設定を変更
• オリジン変更時の実行タイミング
  • CloudFront Functions：Viewer Request
    • キャッシュ検索前に毎リクエストで実行
  • Lambda@Edge：Origin Request
    • キャッシュミス時に実行
• 外部ネットワークへのアクセス
  • CloudFront Functions：不可
  • Lambda@Edge：可能
• 料金比較には実行単価とキャッシュヒット率を考慮

RDS・Aurora・ElastiCache

RDSのMulti-AZ構成

• Multi-AZ DBインスタンス：Standbyは読み取り処理に利用不可
• Multi-AZ DBクラスタ：Readerでも読み取り処理を受付

Auroraの構成

• WriterとReaderは同じクラスタボリュームを共有
• Writer障害時の復旧
  • Readerあり：Readerを自動昇格
  • Readerなし：新しいWriterを自動作成
  • Readerの昇格優先度を設定可能
  • 高速な復旧には別AZにReaderを配置
• ReaderエンドポイントはSQL単位ではなく接続単位で分散

書き込みのスケーリング

• Reader追加では書き込み性能は向上しない
• 書き込みを分散する構成
  • Aurora Limitless Database：データをシャードに分割して書き込みを分散
  • Aurora DSQL：複数リージョンから読み書き
  • DynamoDB Global Tables：複数リージョンから読み書き

AuroraのI/O料金

• Aurora Standard：読み書きのI/Oリクエスト量に応じて課金
• Aurora I/O-Optimized：読み書きのI/Oリクエスト料金なし

RDS Proxyとフェイルオーバー後の接続

• RDSのフェイルオーバー
  • エンドポイント名は維持
  • DNSが指す接続先IPは変更
  • 既存のTCP接続は維持されない
• RDS Proxyを使っても中断したトランザクションの再実行はアプリ側で対応

Auroraのクローンとスナップショット

• クローンの仕組み
  • Copy-on-Writeで作成
    • 作成時は元クラスタとストレージを共有
    • 更新されたデータに追加の保存領域を割り当て
  • 作成後の更新は元クラスタと同期しない
  • 元クラスタを削除しても作成済みクローンは利用可能
• クロスアカウントのクローン
  • AWS RAMで元クラスタを共有
  • クローン先は同一リージョン
• スナップショットの共有
  • 自動スナップショット：別アカウントへの直接共有は不可
  • 手動スナップショット：別アカウントへの共有に対応

PITRとBacktrack

• PITR
  • RDS：別DBインスタンスへ復元
  • Aurora：別DBクラスタへ復元
• Backtrack
  • Aurora MySQLのみ対応
  • 既存クラスタを過去時点へ巻き戻し

ElastiCacheの構成と依存関係

• エンジンの違い
  • Valkey／Redis OSSはレプリケーションに対応
  • Memcachedはレプリケーションに非対応
  • Memcachedも複数ノードへのデータ分散に対応
• Multi-AZとレプリケーション
  • Multi-AZには別AZのReplicaが最低1台必要
  • Primary障害時はReplicaを自動昇格
  • レプリケーション自体はMulti-AZなしでも利用可能
• クラスタモード
  • 無効：1シャード
  • 有効：複数シャードへの分割に対応
  • 各シャードはPrimary 1台とReplica 0〜5台
• クラスタモード有効時
  • 自動フェイルオーバーの有効化が必須
  • Replicaが0台なら昇格先なし

災害復旧

DR戦略の4分類

• ワークロード全体の待機状態で分類

方式	待機環境	RPOの目安	RTOの目安	コスト
Backup & Restore	バックアップを保持	数時間	24時間以内	低い
Pilot Light	DBなど中核部分だけ稼働	数分	数十分	中程度
Warm Standby	縮小版のシステム全体が稼働	数秒	数分	高い
Multi-site Active/Active	複数拠点で本番稼働	ほぼ0	0〜数秒	最も高い

RPO・RTOはAWS Well-Architectedが示す代表的な構成の目安

RDSのリージョン間DR

• クロスリージョンリードレプリカ
  • 復旧先のDBを事前に稼働
  • 非同期複製の遅延がRPOに影響
  • 復旧時にレプリカを手動昇格
  • アプリの接続先を変更
• クロスリージョンバックアップ
  • 復旧先DBの常時稼働は不要
  • 復旧時にDBインスタンスを作成
  • スナップショット：別リージョンにコピー
  • 自動バックアップ：スナップショットとトランザクションログを複製
    • 複製先リージョンでもPITRに対応
• アカウント侵害に備えて別アカウントにバックアップを保管

Aurora Global Database

• 構成
  • リージョンごとに別のクラスタボリューム
  • リージョン間はストレージレベルで非同期複製
  • PrimaryリージョンにWriterを配置
  • Secondaryリージョンは通常読み取り用
• リージョンの切替
  • 切替には明示的な操作が必要
  • Switchover：計画的な切替
    • 複製完了を待ってから切替
    • データ損失なし
  • Failover：障害時の切替
    • SecondaryをPrimaryへ昇格
    • 未複製のデータを失う可能性
• Global Writer Endpoint
  • 現在のPrimaryリージョンのWriterへ接続
  • リージョン切替後も同じエンドポイント名を使用

DLMとAWS Elastic Disaster Recovery（DRS）

• DLM
  • EBSスナップショットの取得を自動化
  • 取得間隔は最短1時間
  • 復旧時にスナップショットから復元
• DRS
  • ソースサーバのブロックデータを継続的に複製
  • 複製データから復旧用EC2を起動
• DRSの待機環境
  • ステージング領域のEC2とEBSで複製データを保持
  • 業務用の復旧EC2は常時稼働不要
• DRSのレプリケーション設定
  • プライベート接続での複製
    • Direct Connectなどの接続を事前に用意
    • プライベートIPの使用を選択
  • 複製に使用する帯域幅を制限
  • ステージング領域のサブネットを指定
• DRSの起動設定・EC2起動テンプレート
  • 復旧用EC2のサブネットを指定
  • 復旧用EC2のIPアドレスを指定
  • ソースのプライベートIPを引き継ぐ設定も可能

Global AcceleratorとRoute 53による切替

• Global Accelerator
  • DNSキャッシュの更新待ちは不要
  • 既存TCP接続は切替先へ引き継がれない
• Route 53
  • DNS応答で接続先を切替
  • 切替の反映はDNSキャッシュのTTLに影響される

S3・ファイルストレージ

Intelligent-TieringとGlacier Instant Retrieval

• Intelligent-Tiering
  • アクセス頻度に応じて自動で階層移動
  • 標準の3階層はミリ秒アクセス
  • 取り出し料金なし
  • 監視・自動階層化料金あり
  • 最小保存期間なし
• Glacier Instant Retrieval
  • 低頻度のデータをミリ秒で取得
  • 復元処理不要
  • 取り出し料金あり
  • 最小保存期間90日

S3の利用状況の分析

• Storage Lens
  • 無料メトリクス：過去14日を参照可能
  • 高度なメトリクス：過去15か月を参照可能
  • アクティビティメトリクスは高度なメトリクスで提供
• ストレージクラス分析：Standard → Standard-IAへの移行判断に利用

Transfer Accelerationとマルチパートアップロード

• Transfer Acceleration
  • 近くのエッジロケーションで通信を受付
  • AWSのネットワークでS3までの転送経路を最適化
• マルチパートアップロード
  • オブジェクトを分割して並列アップロード
  • 失敗したパートだけ再送
• 両機能は併用可能

S3アクセスポイント

• 同じバケットへのアクセス権限を用途別に管理
• アクセスポイントごとにポリシーを設定
• バケットへの直接アクセスは別途制御が必要

EFSとFSx

• EFS
  • NFSの共有ファイルストレージ
  • Linux／macOSから利用可能
  • Windowsはサポート対象外
  • Regional
    • データを複数AZに保存
    • 各AZのマウントターゲットから同じEFSへ接続
  • One Zone
    • データを単一AZに保存
    • 別AZからも接続可能
• FSx
  • Windows File Server
    • SMB
    • Active Directory連携
  • Lustre
    • HPC・高速並列処理
  • NetApp ONTAP
    • NFS／SMB／iSCSI
  • OpenZFS
    • NFS
    • ZFSのスナップショット・クローン

S3とFSx for Lustreの連携

• S3を永続保管先として利用
• FSx for Lustreを処理中の高速ファイルストレージとして利用
• アクセスしたファイルの内容だけをS3から遅延読み込み

S3 File Gateway・S3 Files・Transfer Family

• S3 File Gateway
  • アクセス方式：NFS／SMB
  • 用途：ゲートウェイ経由のファイル共有
  • 保存先：S3
  • キャッシュ：ゲートウェイのローカルディスク
  • S3との同期
    • 書き込みを非同期アップロード
    • S3側の変更はRefreshCacheで共有側の一覧へ反映
• S3 Files
  • アクセス方式：NFS
  • 用途：AWS上の共有ファイルシステム
  • 保存先：S3
  • S3との同期：自動で双方向同期
• Transfer Family
  • アクセス方式：SFTP／FTPS／FTPなど
  • 用途：ファイル転送
  • 保存先：S3・EFS

移行・データ転送

• AWS Application Discovery Service：移行対象・依存関係の調査
• Migration Evaluator：オンプレミスとAWSのTCO比較
• AWS Database Migration Service（DMS）
  • 用途：DBの移行・複製
  • 変更反映：CDCでDBの変更を継続的に反映
  • 異種DB移行の役割分担
    • スキーマ変換：AWS Schema Conversion Tool（SCT）／DMS Schema Conversion
    • データ移行：DMS
    • DMS Schema Conversionはマネージド機能
• AWS DataSync
  • 用途：ファイル・オブジェクトの転送
  • 変更反映：変更されたファイル・オブジェクトを転送
  • オンプレミスのNFS／SMBとの転送にはエージェントを使用
  • 標準スケジュールの最短実行間隔は1時間
  • 転送帯域幅の上限を設定可能
  • Glacier Deep Archiveへ直接転送可能
• DMS・DataSyncはAWS内の移行にも対応
• AWS Transform MGN（旧AWS Application Migration Service）
  • 移行対象：サーバ
  • 移行先：EC2
  • 移行後の運用：EC2の運用管理を継続
• AWS Elastic Beanstalk
  • 移行対象：IISアプリケーション
  • 移行先：BeanstalkのWindows環境
  • 移行コマンド：eb migrate
  • 移行後の運用：環境構築・デプロイ・スケーリングを自動化

認証・権限管理

• AWS Directory Service
  • AD Connector
    • 既存ADへの認証要求を中継
    • AWS側に新しいADは構築しない
  • AWS Managed Microsoft AD
    • AWS上にマネージドなADを構築
    • オンプレミスADと信頼関係を設定可能
• Active Directory Federation Services（AD FS）
  • 既存ADを利用したSAML認証フェデレーション
• IAM Identity Center
  • 権限割当
    • 許可セットでAWSアカウント内の権限を定義
    • ユーザ・グループにAWSアカウントと許可セットを割当
  • 外部IdPとの連携
    • SAML：認証・SSO
    • SCIM：ユーザ・グループ情報の同期
  • ADとの連携
    • AD Connector／AWS Managed Microsoft ADを利用
    • ユーザ・グループのメタデータを同期
    • パスワードは同期しない

CloudFormationのサービスロールと権限

• リソース操作に使う権限
  • サービスロールなし：呼び出し元のIAMユーザ／ロール
  • サービスロールあり：指定したサービスロール
• サービスロールのポリシー
  • 信頼ポリシー：CloudFormationによる引き受けを許可
  • 許可ポリシー：リソースの操作権限を定義
• iam:PassRole
  • サービスロールの指定時に呼び出し元が必要とする権限
  • Resource：渡せるIAMロール
  • iam:PassedToService：渡せるAWSサービス
  • リソース自体の操作権限は含まない

KMSキーとデータキー

• エンベロープ暗号化
  • データキー：データを暗号化
  • KMSキー：データキーを暗号化
• GenerateDataKeyは平文と暗号化済みのデータキーを返却
• S3 SSE-KMSで必要なKMS権限
  • 通常のアップロード：kms:GenerateDataKey
  • ダウンロード：kms:Decrypt
  • マルチパートアップロード：両方

RDS・AuroraのIAMデータベース認証

• 対応エンジン
  • RDS：MariaDB／MySQL／PostgreSQL
  • Aurora：MySQL／PostgreSQL
• 認証トークン
  • 有効期間は15分
  • 期限切れでも確立済み接続は切断されない
• 権限の役割分担
  • IAMのrds-db:connect：DBへの接続を許可
  • DB内部のGRANT：SELECT／INSERTなどのSQL操作を許可

EC2への接続と監査

• EC2 Instance Connect
  • SSH公開鍵を一時的に配布
  • 公開鍵の有効期間は60秒
• Systems Manager Session Manager
  • ブラウザやAWS CLIからEC2にシェル接続
  • Session Managerのシェル接続はSSH不要
• SSH over Session Manager
  • Session ManagerをSSHの通信トンネルとして利用
  • SSHポートの外部公開は不要
  • SSH認証には鍵が必要
  • 公開鍵の配布にEC2 Instance Connectを併用可能
• IAM制御とCloudTrail記録の対象
  • 公開鍵の送信：SendSSHPublicKey
  • セッションの開始：StartSession
• 通常のSSH接続そのものはCloudTrailに記録されない

組織管理・セキュリティ

Control Towerのコントロール

• 推奨レベル
  • 必須（Mandatory）：自動有効
  • 強く推奨（Strongly recommended）：AWS推奨・適用は任意
  • 選択的（Elective）：組織の要件に応じて適用
• 動作方式
  • 予防型：SCP／RCPなどで違反操作を防止
  • 検出型：AWS Configで設定違反を検出
  • プロアクティブ型：CloudFormation Hooksで作成前に検査
• 推奨レベルと動作方式は別の分類
• OU単位でコントロールを有効化

Firewall Managerの適用範囲と修復

• AWS Organizations配下へセキュリティポリシーを適用
• 適用範囲
  • アカウント・OUを指定／除外
  • リソースタイプ・タグで対象を指定
  • 新しいアカウント・リソースも条件に応じて適用対象
• 修復
  • ポリシー違反を検出
  • 自動修復を設定可能
  • 修復対象はFirewall Managerが管理する設定

WAFのDDoS対策

• レートベースルール：リクエスト頻度に基づく制限
• Anti-DDoSマネージドルール：L7 DDoSを自動検出・緩和

Lambda・API・デプロイ

Lambdaのエイリアス

• 同じ公開済みバージョンを複数エイリアスから参照可能
• エイリアスから別のエイリアスは参照不可
• バージョンの発行だけではエイリアスの参照先は変わらない
• 加重エイリアスは最大2つの公開済みバージョンへ振り分け

デプロイとロールバック

• 割合を指定した振り分けだけなら加重エイリアスで対応
• トラフィック移行・監視・切り戻しを自動化するならSAM＋CodeDeploy
  • SAM：バージョン・エイリアス・CodeDeploy連携を定義
  • CodeDeploy：トラフィック移行を自動化
  • 移行前後に検証用Lambdaを実行
  • CloudWatchアラームで自動ロールバック
• CloudFormationもCloudWatchアラームをロールバックトリガーに指定可能

Lambdaのパッケージ

• 共通コード
  • Lambda LayersはZIP形式のみ
  • コンテナイメージ形式の関数ではLambda Layersは利用不可
  • コンテナイメージでは共通ベースイメージを利用
• 別アカウントへの移行
  • ZIPはget-functionで取得して再デプロイ
  • 実行ロール・環境変数・VPC設定・トリガーなどは別に再設定
  • Lambda関数そのものはAWS RAMで共有不可

API Gatewayの機能差

• 顧客ごとの期間クォータ
  • REST APIの使用量プラン＋APIキー
  • HTTP APIでは非対応
  • Lambdaの同時実行数制限では代用不可
• 厳密な利用上限
  • 使用量プランはベストエフォートのため保証不可
• AWSサービスへの直接統合
  • DynamoDB：REST APIのみ対応
  • SQS／EventBridge：HTTP APIも対応

API GatewayとALBの料金・構成

• API Gateway＋Lambda
  • VPC構築は必須ではない
  • API Gatewayは主にリクエスト単位の課金
• ALB＋Lambda
  • VPC構築が必要
  • アクセスがなくてもALBの時間料金が発生

Secrets Managerのローテーション

• RDS／Auroraが管理するマスタユーザ認証情報はLambdaなしでローテーション可能
• Lambda方式ではSecrets Managerの保存値と認証先の認証情報の両方を更新

イベント・ストリーミング・検索

ファンアウト

• 同じイベントを複数の処理先へ配信
  • SNS → 複数SQS
  • EventBridge → ルールに一致する各ターゲット
• SQSはFIFOでも全コンシューマへの複製配信にはならない
• S3からLambdaだけを呼び出すならSNSは不要
• Kinesisの拡張ファンアウト
  • 目的：コンシューマごとの読み取り性能確保
  • コンシューマごと・シャードあたり最大2 MB/秒
• DynamoDB Streams自体には拡張ファンアウトなし
  • DynamoDB → Kinesis Data Streamsの連携で利用可能

ストリーム処理と配信

• Kinesis Data StreamsとFirehoseのLambda連携
  • Data Streams：コンシューマとして処理
  • Firehose：配信前のデータ変換
• OpenSearchへの配信
  • Data Streams：コンシューマ側で実装
  • Firehose：標準対応
• FirehoseはLambdaを最終配信先に指定不可
• 保持期間内のデータを再処理するならData Streamsを利用
• Data Streamsもオンデマンドモードならシャード数の手動管理は不要
• Kafkaクライアント・資産の継続利用：Amazon Managed Streaming for Apache Kafka（MSK）

DynamoDBのTTL

• TTLでは有効期限到達時の即時削除を保証しない

OpenSearchのストレージ階層

• 書き込み・更新するインデックス：Hot
• 更新しないインデックスの検索：UltraWarm
  • S3に保存してノード側でキャッシュ
• Coldの検索にはUltraWarmへの再アタッチが必要
• 検索用インデックスとS3上の元データは別々に保持・削除を管理

監視・コスト管理

CloudWatchの取得範囲

• CPUなどの標準メトリクスの取得間隔
  • 基本モニタリング：5分
  • 詳細モニタリング：1分
• 詳細モニタリングにしてもメモリ使用率などの標準外メトリクスは増えない
• メモリ使用率・ディスク空き容量の取得にはCloudWatch Agentなどを使用
• CloudWatch AgentはEC2基盤側のステータスチェックを代替しない

Compute Optimizerの分析条件

• メモリ分析にはCloudWatch Agentか対応する外部監視ツールが必要
• 分析期間
  • 既定：過去14日
  • 有料の拡張インフラストラクチャメトリクス：最大93日
• Basic Supportでも利用可能

RDS・Auroraの停止

• Auroraの停止はDBクラスタ単位
• 停止7日後に自動起動
• 停止できない構成
  • RDSのリードレプリカ・リードレプリカを持つインスタンス
  • 複数リージョン構成のAurora Global Database
• 停止中の料金
  • オンデマンドのインスタンス料金：なし
  • ストレージ・バックアップ・RDSのプロビジョンドIOPS：課金対象
• Aurora Serverless v2の自動一時停止
  • ユーザ接続がない状態が設定時間続くと0 ACUへ縮小
  • 接続要求で自動再開

おわりに

出題されるのは知っているサービスばかりなので、逆に何を勉強すればいいのかわからない。
知らないサービスだらけの方が勉強すべきことが明確なので、むしろ勉強しやすいなぁと感じた試験でした。
SAPはアップデート目前なので、これから駆け込みで受験される方もいるかと思います。
皆さんが無事に合格できますように！