AWS SAA 体験記
はじめまして！
先日 AWS Certified Solutions Architect – Associate（SAA）に合格することができました🎉
せっかくなので、勉強中につまずいたポイントや「ここ試験に出た！」と感じた内容を自分の振り返りも兼ねてまとめてみました。網羅的なリファレンスではなく、あくまで個人的にひっかかった箇所のメモなので、内容に誤りや説明不足な点があるかもしれません。初投稿ということでご容赦いただけると嬉しいです。同じく SAA を目指している方の参考に少しでもなれば幸いです！
ACM（AWS Certificate Manager）
概要
SSL/TLS証明書を管理するサービス。CloudFront・ELB・API Gatewayなどに適用し、通信の暗号化とサーバー証明を行う。
ACM発行証明書 vs インポート証明書
| 種別 | 自動更新 |
|---|---|
| ACMが発行した証明書 | ✅ 自動更新される |
| 外部CAからインポートした証明書 | ❌ 手動で再インポートが必要 |
サードパーティ証明書のインポート手順
- サードパーティCA（認証局）に証明書の発行を依頼し取得
- ACMにインポート（CloudFrontで使う場合は us-east-1リージョン 限定）
- CloudFront・ELB・API GatewayなどのAWSサービスで使用
有効期限切れの通知（最小構成）
インポート証明書は自動更新されないため、期限切れ前の通知が重要。
仕組み：
- ACMは有効期限の 45日前から毎日、
ACM Certificate Approaching Expirationイベントを Amazon EventBridge に送信する - EventBridgeルールでこのイベントを条件に設定し、ターゲットに 既存のSNSトピック を指定するだけで、担当者へのメール通知が実現できる
- 追加コード不要・最小構成で実装可能
Amazon AppFlow
概要
SaaSアプリケーションとAWSサービス間でデータを安全に転送できるフルマネージドサービス。コードなしでデータフローを設定できるため、技術的な専門知識が少ないユーザーでも利用可能。
対応サービス例
| 種別 | 例 |
|---|---|
| SaaSソース | Salesforce・ServiceNow・Slack など |
| AWS転送先 | S3・Redshift・DynamoDB など |
主な特徴
- 暗号化：デフォルトでKMSによる暗号化が有効（保存時・転送中ともに対象）
- プライベート転送：AWS PrivateLinkをサポートするSaaSアプリはインターネットを経由しないデータ転送が可能
Amazon DocumentDB
概要
MongoDB互換のフルマネージド型ドキュメントデータベースサービス。既存のMongoDBアプリケーションやツールをそのまま流用できる。データはJSON形式に近い「ドキュメント」として格納される。
移行
既存のMongoDBからは AWS DMS（Database Migration Service） を使用してスムーズに移行可能。
Amazon MQ
概要
Apache ActiveMQ・RabbitMQ対応のフルマネージドメッセージブローカーサービス。複数のサービス・システム間のメッセージキューを管理する。
可用性
デフォルトは単一AZ構成。AZ障害に備える場合はアクティブ/スタンバイ構成を選択することで複数AZで動作可能。
Amazon SQSとの使い分け
| Amazon MQ | Amazon SQS | |
|---|---|---|
| 互換性 | ActiveMQ・RabbitMQ互換 | AWS独自規格 |
| 向いているケース | 既存環境からの移行 | 新規アプリケーション |
| ブローカー設定 | 必要 | 不要 |
Amazon Route 53
DNSクエリログ
パブリックDNSクエリの詳細を記録できる。ログは Amazon CloudWatch Logs に送信され、後から分析可能。
記録される主な情報：ドメイン/サブドメイン名・リクエスト日時・DNSレコードタイプ・応答したエッジロケーション・DNSレスポンスコード（NoError / ServFailなど）
Amazon API Gateway
APIの種類と比較
| HTTP API | REST API | |
|---|---|---|
| コスト・遅延 | 低コスト・低遅延 | 比較的高コスト |
| スケール | 自動スケールアウト | 同左 |
| APIキャッシュ | ❌ | ✅ |
| 使用量プラン | ❌ | ✅ |
| 統合タイムアウト延長 | ❌ | ✅（クォータ引き上げで29秒超も可） |
オーソライザー（アクセス制御）
| タイプ | 概要 |
|---|---|
| Lambdaオーソライザー | 独自ロジックで柔軟に制御。管理は複雑になる |
| Cognitoユーザープール | Cognitoと連携した認証 |
| JWT | HTTP APIで直接検証。Cognito以外のIdPにもLambda不要で対応可能 |
REST APIの主な機能
使用量プラン：APIキーと紐づけてユーザーごとにスロットル（リクエスト数/秒）・クォータ（リクエスト数/日・週・月）を設定できる。REST APIのみ対応。
統合タイムアウト延長：デフォルト29秒。リージョンAPI・プライベートAPIはクォータ引き上げで29秒超に設定可能。LLMなど長時間処理のユースケースで有効。
Canaryリリース：新バージョンに一部トラフィック（例：20%）を流し、安定確認後に段階的に切り替える。問題発生時は即ロールバック可能。
カスタムドメイン名
ACMのSSL/TLS証明書を使用。エンドポイントタイプで必要な証明書のリージョンが異なる点に注意。
| エンドポイントタイプ | 必要な証明書 |
|---|---|
| リージョンエンドポイント | 同一リージョンのACM証明書 |
| エッジ最適化（CloudFront使用） | us-east-1のACM証明書 |
ワイルドカードドメイン（*.example.com）も設定可能。その場合はワイルドカード証明書とDNSレコードのワイルドカード登録が必要。
Auto Scaling
概要
AWSリソースの数を需要に応じて自動でスケールアウト/インするサービス。最小・最大・希望リソース数をもとに管理する。
ヘルスチェック（EC2の場合）
| タイプ | チェック内容 | デフォルト |
|---|---|---|
| EC2 | インスタンスのステータス（ハードウェア・ネットワーク） | ✅ 有効 |
| ELB | 指定URLへの応答確認 | ❌ 無効 |
両方有効にすることを推奨。
ELBのみ無効の場合、ALBヘルスチェックで異常（HTTP 404など）が出てもEC2ステータスが正常ならインスタンスは終了しない。新規インスタンスも起動しないため、最小キャパシティ未満で負荷分散が続くリスクがある。
起動テンプレート
スケールアウト時に起動するリソースの設定（AMI・インスタンスタイプ・セキュリティグループなど）を定義する。
スケーリングの種類
- 手動スケーリング：バッチ処理など事前に負荷が予測できる場合に手動で増減
- シンプルスケーリング：CPU使用率などのメトリクスに対して1つのしきい値でスケーリング
その他の設定
最小・最大キャパシティを1に固定：インスタンス数を常に1台に維持。異常時は自動で終了→新規起動。
ライフサイクルフック：インスタンスの起動・終了タイミングに任意の処理を挟める。例：起動時の初期化スクリプト実行、終了前のログ退避など。
ヘルスチェックの猶予期間：起動直後（アプリ立ち上がり前）にヘルスチェックが走って異常判定されるのを防ぐための待機時間。
AWS App2Container
概要
既存アプリをコンテナ化してクラウドへモダナイズするツール。Java・ASP.NETアプリを主な対象とし、オンプレや仮想マシン上のアプリを迅速にコンテナ化できる。
自動生成されるもの
- 依存関係の検出・Dockerfile
- ECS / EKSへデプロイするための設定ファイル
- CloudFormationテンプレート
ゼロから書き直すことなく移行できるため、環境構築・デプロイの工数を大幅に削減できる。
AWS Backup
概要
AWSリソースのバックアップを一元管理するサービス。EC2インスタンスをバックアップ対象に指定でき、EBSボリュームに加えて起動設定・インスタンス構成情報も含められる。
バックアッププラン
1つのプランで定期実行＋セカンダリリージョンへのコピーをまとめて設定可能。バックアップ取得から別リージョンへの複製までを自動化でき、Lambdaで個別実装する場合と比べて管理負荷を大幅に削減できる。
AWS Batch
概要
コンテナを使った大規模バッチ処理を効率的に管理・実行するサービス。科学シミュレーション・データ処理・バックグラウンド処理などに適している。
処理の流れ
- ジョブ定義を作成（コンテナイメージや実行環境を指定）
- ジョブがジョブキューに格納される
- Amazon ECS管理下のFargateなどで実行される
スケジューリング・リソース管理・優先度付け・スケーリングを自動で処理し、コストとパフォーマンスを最適化する。
AWS Control Tower
概要
ベストプラクティスに基づいたセキュアなマルチアカウント環境（ランディングゾーン）のセットアップを自動化するサービス。Organizations・CloudFormation・Configなど複数サービスを組み合わせて統一されたセキュリティルールを適用する。
主な構成要素
ガードレール：SCPやセキュリティルールをまとめた設定セット。組織内の全アカウントに一貫して適用でき、運用負荷を軽減。
Account Factory：標準設定済みテンプレートをもとに新規アカウントを作成。ガードレールやSecurity Hubの有効化が自動で反映されるため、新規アカウントにも即座にセキュリティ基準を適用できる。
Security Hubとの統合
Control Tower環境にSecurity Hubを統合することで、AWS Foundational Security Best Practices（FSBP） などに基づいた全アカウントの準拠状況を継続的にモニタリングできる。
マルチアカウントのガバナンス管理（典型的な構成）
| 要件 | 対応するサービス・機能 |
|---|---|
| 全アカウントへのSCP・ガードレール適用 | Control Tower（管理アカウントに導入） |
| FSBPへの継続的な準拠評価 | Security Hub（Control Towerと統合） |
| 新規アカウントへの自動適用 | Account Factory |
AWS Firewall Manager
概要
AWS Organizations環境で組織全体のファイアウォールルールを一元管理するセキュリティ管理サービス。組織内の全アカウントに一貫したセキュリティルールを統一的に適用できる。
セキュリティグループ管理
セキュリティグループポリシーを使い、OU・アカウント・リージョン単位で共通の許可ルールを定義・配布し、準拠状況を継続的に監視。
- 組織全体に共通のセキュリティグループを適用
- 過剰・不適切な設定を検出し、自動修復または管理者へ通知
- 未使用・冗長なセキュリティグループの整理
マルチアカウント・マルチリージョン環境でもネットワークセキュリティを一貫して維持しつつ、管理負担を大幅に削減できる。
IAM Access Analyzer
概要
AWSリソースのアクセス権限を継続的に監視・分析するサービス。最小権限の原則に基づいたアクセス制御の実現を支援する。
主な機能
外部アクセス分析：有効化時に設定する「信頼ゾーン」（組織またはAWSアカウント）を基準に、S3バケット・IAMロールなどのリソースベースポリシーを分析し、外部（他アカウント・匿名ユーザーなど）からアクセス可能な意図しない設定を検出する。
内部アクセス分析：組織内のアクセス権限を可視化。S3・DynamoDB・RDSスナップショットなどの重要リソースに対してどのIAMユーザー・ロールがアクセス権を持つかを特定する。
未使用アクセス分析：IAMロール・ユーザーに付与されたポリシーと最終アクセス情報を比較し、実際には使用されていない過剰な権限を特定。CloudTrailログをもとに必要最小限の権限のみを含むポリシーの自動生成機能も備える。
ポリシー検証：ポリシーがAWSベストプラクティスに準拠しているかを確認。統合ダッシュボードで外部・内部・未使用アクセスの状況を一元可視化。
代理（委任）管理者
組織全体の分析をメンバーアカウントから実行したい場合、Organizations管理アカウントからメンバーアカウントを代理管理者として指定する。指定された代理管理者アカウントは組織全体のアクセス分析を一元管理できる。
Control TowerはOrganizations管理アカウントでのみセットアップ可能なため、「Control Tower管理アカウント」＝「Organizations管理アカウント」となる。
AWS KMS（Key Management Service
キーの種類
| AWSマネージドキー | カスタマーマネージドキー | |
|---|---|---|
| 作成・管理 | AWSが自動作成・管理 | ユーザーが作成・管理 |
| キーポリシー変更 | ❌ 不可 | ✅ 柔軟に設定可能 |
| 主な用途 | EBS・Redshiftなど連携サービスの暗号化 | アプリレベルでの特定データ項目の暗号化・復号 |
マルチリージョンキー
通常のKMSキーはリージョンごとに異なるキーマテリアルを持つため、別リージョンで復号するには「復号→再暗号化」が必要。
マルチリージョンキーを使うと、プライマリキーのキーマテリアルをレプリカキーとして他リージョンに複製でき、再暗号化なしに別リージョンで復号できる。キーマテリアルはAWSが生成・管理するため自社管理は不要。
ABAC（属性ベースのアクセスコントロール）
タグ（属性）に基づいてアクセス許可を定義する認可戦略。リソースが増えてもポリシーを追加せずに済むため、運用負荷を大幅に抑えられる。
AWS MGN（Application Migration Service）
概要
オンプレミス・他クラウドのサーバーをブロックレベルで継続的に複製し、リフトアンドシフト方式でAWSに移行するサービス。OS・アプリ・データをそのまま移行できるため、コード変更なしに短期間でカットオーバーできる。AWS内の別アカウント・リージョン間移行にも対応。
移行手順
- エージェント導入：移行対象サーバーにAWS Replication Agentをインストール。業務を続けながらレプリケーション可能
- レプリケーション開始：ステージング領域にディスクデータをブロックレベルで継続複製
- テストインスタンス起動：複製データで動作確認。この間もオンプレの本番は稼働継続
- カットオーバー実行：最終同期後に本番切り替え。ダウンタイムは最終同期のみのため非常に短い
他の移行サービスとの使い分け
| サービス | 向いているケース |
|---|---|
| AWS MGN | コード変更なし・VMをそのままEC2に・短期間移行 |
| AWS DMS | DBのみ移行したい |
| Snow Family | ネットワーク帯域が不足している |
| DataSync + S3 + AMI | 特殊なカスタマイズが必要 |
AWS Transfer Family
概要
SFTP・FTPS・FTPをサポートした、Amazon S3・EFSへのセキュアなファイル転送を実現するマネージドサービス。独自の認証機能を持ち、SFTPユーザーの作成・管理が可能。AWS Directory Service・Okta・Azure ADなど外部IdPとの連携にも対応。
エンドポイントの種類
| パブリックエンドポイント | VPCエンドポイント | |
|---|---|---|
| アクセス元 | インターネット | VPC内・Direct Connect・VPNなど |
| セキュリティグループ | ❌ 使用不可 | ✅ 使用可能（接続元を制限できる） |
| 可用性 | 複数AZに自動配置 | 複数AZにENIを設定することで向上 |
| 用途 | リモートユーザー・他社からの転送 | VPC内部やプライベートネットワーク経由の転送 |
VPCエンドポイントの2種類：
- インターネット向け：Elastic IPを関連付け、パブリックサブネット経由でインターネットからアクセス
- 内部向け：VPC内リソースやVPCピアリング・Direct Connect・VPNからプライベートアクセス
AWSでのワークロード検出
概要
AWS上のリソースを収集し、関係性を含むアーキテクチャ図を自動生成できる可視化ツール。複数アカウント・複数リージョンにまたがる環境でもワークロード全体の構成を一元的に把握できる。作成した構成図は保存・共有・各種形式でのエクスポートに対応。
Amazon CloudWatch Logs
概要
AWSサービス・EC2のOS・アプリケーションのログを収集・一元管理するサービス。CloudTrailの操作ログやVPCフローログなども収集できる。
EC2上のOSやアプリのログを収集するには CloudWatchエージェントのインストールが必要。
主な機能
フィルタリング＆通知：ログ内容をフィルタリングして管理者に通知できる。（例：Errorを1時間に5回検出したらメール通知）
サブスクリプションフィルター：フィルタリングしたログを別サービスへ転送。リアルタイム解析や自動処理が可能。
| 転送先 | 用途 |
|---|---|
| Amazon Data Firehose | リアルタイムのログ転送・蓄積 |
| AWS Lambda | ログ内容に応じたプログラム実行 |
| Amazon OpenSearch Service | ログのリアルタイム解析・検索 |
Amazon DataZone
概要
AWS・オンプレミス・サードパーティーに分散したデータを一元的にカタログ化し、検索・共有・管理を効率化するサービス。メタデータの統合管理により「誰が・どのデータに・どのような目的でアクセスできるか」をサブスクライブの承認フローで制御し、安全なデータガバナンスを実現する。
主な特徴
- Amazon Athenaとの連携：承認済みデータへの即時クエリ実行が可能。余分なデータコピーや複雑なポリシー管理が不要
- 新規部門や外部パートナーとのデータ連携にも柔軟に対応
DynamoDB Accelerator（DAX）
概要
DynamoDB向けのインメモリキャッシュサービス。
暗号化の注意点
保管時・転送中の暗号化はともにクラスター作成時にのみ設定可能。既存クラスターへの後からの変更は不可。暗号化を後から有効にするには、既存クラスターを削除して新規作成する必要がある。
Amazon EKS
実行モードの比較
| 標準EKS | EKS Auto Mode | Fargate | |
|---|---|---|---|
| コントロールプレーン管理 | AWS | AWS | AWS |
| ノード管理 | ユーザー | AWS（自動化） | 不要（ポッド単位） |
| アーキテクチャ | ノードベース | ノードベース | ポッドごとに分離 |
| 向いているケース | 細かく制御したい | 運用を省力化したい | 完全サーバーレス |
ネットワーク
AWS Load Balancer Controller：KubernetesのYAMLを定義するだけでALB・NLBを自動プロビジョニング・管理するコントローラー。ポッドの増減に応じてターゲット登録も自動更新。
VPC CNI Plugin：EKSデフォルトのネットワークプラグイン。VPCのIPアドレスをポッドに直接割り当てる。カスタムネットワーキングを使えばノードとは別のサブネットからIPを割り当て可能。
クラスターエンドポイント：デフォルトはインターネットからアクセス可能。プライベートアクセスに限定する場合、VPC内からコントロールプレーンへの通信に AWS PrivateLink（インターフェース型VPCエンドポイント） が必要。
スケーリング
Horizontal Pod Autoscaler（HPA）：CPU使用率・メモリ使用量などに基づいてポッド数を自動増減。動作には別途 Metrics Server の導入が必要。
セキュリティ
IRSA（IAM Roles for Service Accounts）：ポッド単位でIAMロールを付与する仕組み。ノードのIAMロールに権限を付与すると同一ノードの全ポッドが同じ権限を持つが、IRSAを使えば最小権限の原則を徹底できる。
IRSAの設定手順：
- EKSクラスターのOIDCプロバイダーをIAMのIDプロバイダーとして登録（信頼関係の確立）
- 必要な権限を持つIAMロールを作成し、信頼ポリシーを構成
- KubernetesサービスアカウントのアノテーションにIAMロールのARNを指定
シークレットの暗号化：etcdに格納される設定情報・シークレットはデフォルトでAWSがディスクレベルで暗号化。さらに強固にする場合は「シークレットの暗号化」オプションを有効化。
Elastic Load Balancing（ELB）
ELBの種類
| ALB | NLB | CLB | |
|---|---|---|---|
| レイヤー | L7（アプリケーション層） | L4（トランスポート層） | L4/L7 |
| プロトコル | HTTP・HTTPS・gRPC | TCP・UDP・TLS | HTTP・HTTPS・TCP |
| 高度なルーティング | ✅ ホスト・パス・クエリ文字列 | ❌ | ❌ |
| Elastic IP関連付け | ❌ | ✅ | ❌ |
| スループット | 標準 | 超高スループット・低レイテンシー | 標準 |
通信の暗号化パターン
| パターン | 暗号化範囲 | 対応ELB | 特徴 |
|---|---|---|---|
| ELBのみに証明書導入 | クライアント↔ELB間のみ | 全ELB | ターゲットに負荷なし |
| ELBとターゲット両方に証明書 | クライアント↔ELB＋ELB↔ターゲット | ALB・CLB | 全区間暗号化。両側に負荷あり |
| ターゲットのみに証明書（TLSパススルー） | クライアント↔ターゲット間（ELBは素通り） | NLB・CLB | ELBで復号されず全区間暗号化 |
ALBの主な機能
ホストベースルーティング：リクエストのFQDN（www1.example.com / www2.example.com）で振り先を切り替え。
パスベースルーティング：URLパス（/web1/ / /web2/）で振り先を切り替え。
リダイレクト：HTTP→HTTPSへのリダイレクトなどが設定可能。
SNI：接続時のドメイン名を見て証明書を選択。1つのELBで複数ドメインの証明書を使い分けられる。
スティッキーセッション：CookieベースでユーザーのリクエストをALBが同一インスタンスにルーティング。セッション状態（カート・ログインなど）を維持しやすい。ただし特定インスタンスに負荷が偏るリスクがあるため、有効期限は必要最小限に設定。より信頼性を高めるにはElastiCacheやDynamoDBにセッションデータを外部保存してスティッキーセッション自体をオフにする方法も有効。
その他
ヘルスチェック：ターゲットへの定期的な死活確認。異常ターゲットへのルーティングを自動停止。
アクセスログ：クライアントのアクセス日時・接続元IP・ポート・ステータスコードなどをS3に保存。トラフィック分析・監査に活用。
ELB自身のスケーリング：リクエスト増減に応じてELB自体が自動でスケールアウト/イン。
Amazon EMR
クラスター作成イベントの検知・自動チェック
EMRクラスター作成時にはクラスター作成API（RunJobFlow）が呼び出され、CloudTrailに記録されるとともにEventBridgeでも検知できる。
自動チェックの構成例：
EventBridgeルールでEMRクラスター作成イベントを捉え→Lambda関数を起動→クラスターIDをもとに暗号化設定を確認→違反があればSNSでセキュリティチームに通知。
EMRランタイムロール
同一クラスター内の各ジョブに異なるIAMロールを割り当てる仕組み。部門・ジョブごとにアクセス対象リソースを分離でき、他部門のS3バケットやDynamoDBへの誤アクセスを防止できる。
IAM（Identity and Access Management）
ポリシーの主な構成要素
| 要素 | 内容 |
|---|---|
| Effect | 許可（Allow）または拒否（Deny） |
| Action | 実行できる操作（例：s3:PutObject） |
| Resource | 対象リソース（例：特定のS3バケット） |
| Principal | リクエスト元（例：特定のIAMユーザー）※リソースベースポリシーで使用 |
| Condition | ポリシーが適用される条件（例：特定のIP範囲） |
ポリシーの種類
リソースベースポリシー：S3バケットポリシーなど、AWSリソース側にアタッチするインラインポリシー。特定ユーザーやIPのみにアクセスを許可する場合などに使用。
信頼ポリシー：IAMロールに設定し、他のAWSアカウントやAWSサービスがそのロールを引き受けられるようにする。資格情報を共有せず安全なクロスアカウントアクセスを実現。
Permissions Boundary：開発者に付与できる権限の上限を設定。管理者の介入なく開発者が作業しつつ、セキュリティポリシーの乱用を防止できる。
IAM Roles Anywhere
オンプレミスや他クラウドのサーバー・アプリからAWSリソースにアクセスさせたい場合に使用。PKIで管理されたX.509証明書をもとに一時的なセキュリティ認証情報を取得できるため、長期的なアクセスキーの保存が不要。
認証情報レポート
AWSアカウント内のIAMユーザー一覧と認証情報ステータスをCSVで出力する監査ツール。
含まれる主な情報：ユーザー作成日時・パスワード最終使用日時・MFA有効/無効・アクセスキーの有効/無効・アクセスキー最終使用日時など。
IAM Identity Center
概要
複数のAWSアカウントやSaaSアプリケーションへのアクセスを一元管理し、シングルサインオン（SSO） 環境を構築するサービス。AWS Organizationsと連携することで組織全体のアカウントへのSSOを実現。
主な概念
グループ：同じ権限を持たせたいユーザーをまとめる単位。グループに権限を付与することでメンバーの追加・削除だけで権限管理が完結する。
アクセス許可セット：「どのAWSリソースに・どこまでアクセスできるか」を定義する権限のひな形。アカウントとグループに割り当てることで一括付与できる。
AWSアクセスポータル：IAM Identity Centerのユーザーがサインインし、割り当てられたAWSアカウントやアプリケーションを利用するための入口。
認証方式
| 方式 | 認証（Authentication） | 認可（Authorization） |
|---|---|---|
| Identity Center組み込み | IAM Identity Center | IAM Identity Center |
| 外部IdP（SAML 2.0） | 外部IdP | IAM Identity Center |
| AWS Directory Service | Directory Service（Active Directory連携も可） | IAM Identity Center |
Directory ServiceやSAML外部IdPと統合する場合、認証は外部・認可はIAM Identity Centerで管理するという分離が重要なポイント。
Amazon Kinesis Data Streams
概要
IoTセンサーなど外部からのストリーミングデータをリアルタイムに収集するサービス。収集したデータを下流のサービスがリアルタイムに読み込んで処理する。
連携サービス例
| サービス | 役割 |
|---|---|
| AWS Lambda | イベント駆動でリアルタイム処理 |
| Amazon Data Firehose | データの転送・蓄積 |
| Managed Service for Apache Flink（旧Kinesis Data Analytics） | ストリーミングデータのリアルタイム分析・可視化 |
| Amazon S3 | データレイクとして大量データをコスト効率よく保存（高耐久・スケーラブル） |
AWS Lambda
VPC Lambda
Lambda関数からプライベートサブネット内のリソースへアクセスするにはVPCにアタッチする。設定するとサブネットごとにENIが作成されプライベートサブネットへアクセス可能になるが、インターネットへのアクセスは不可になる。
| アクセス先 | 必要な設定 |
|---|---|
| インターネット | NATゲートウェイ / NATインスタンスを経由 |
| パブリックなAWSリソース（インターネット不使用） | VPCエンドポイントを経由 |
コールドスタート / ウォームスタート
コールドスタート：初回実行や一定期間未実行の場合、ランタイム環境の準備に時間がかかり起動が遅くなる。リクエスト急増時にも頻発しやすい。
ウォームスタート：継続的なリクエストではランタイム環境が再利用されるため準備が省略され起動が速い。
プロビジョニングされた同時実行：ランタイム環境を事前に準備しておくことでコールドスタートによる遅延を最小化できる。（別途料金が必要）
権限
デフォルトでCloudWatch Logsへのアクセス権限のみ付与。他のAWSサービスへアクセスするにはLambdaのIAMロールに権限を追加する。最小権限の原則に基づき、必要最低限の権限のみ付与することが推奨。
AWS Organizations
タグポリシー
AWSリソースへのタグの命名規則（キー・値）を強制し、組織全体で一貫したタグ付けを実現するポリシー。リソースの整理やコスト管理の効率化に活用する。
条件キー（IAMポリシーのCondition要素）
特定の条件に基づいてアクセス制御を細かく制御するために使用。
| 種別 | プレフィックス | 適用範囲 |
|---|---|---|
| グローバル条件キー | aws: |
すべてのAWSサービスで共通利用可能 |
| サービス固有の条件キー |
s3: など |
対象サービスのみ |
代表的なグローバル条件キー：
-
aws:PrincipalOrgID：組織IDを指定して組織全体のアクセスを制御 -
aws:PrincipalOrgPaths：OUの階層を指定して特定部門・グループへのアクセスを制御 -
aws:PrincipalTag：タグに基づいてアクセスを制御（ABACと組み合わせて活用）
S3 Object Lambda
概要
S3オブジェクトへのアクセス時にLambda関数を介してデータをリアルタイムで加工・変換する機能。元データは変更せず、取得時に動的に処理した結果を返す。
仕組み
S3 Object LambdaアクセスポイントをLambda関数とS3アクセスポイントに紐づける。Object Lambdaアクセスポイント経由のリクエストがトリガーとなりLambda関数が実行され、処理後のデータが返される。
処理例：フィルタリング・圧縮・再フォーマット・データ加工など。
AWS Systems Manager
Run Command
EC2インスタンスやオンプレミスサーバーに対してリモートでコマンド・スクリプトを安全に実行する機能。踏み台サーバーや手動SSH接続が不要になり、大規模なサーバー群を一元管理できる。
用途例：ソフトウェアインストール・設定ファイル変更・システム再起動・診断情報収集・CloudWatchエージェントの一括インストールなど。
Automation
ランブック（ワークフロー定義ドキュメント）に従ってAWSリソースへの操作を自動実行するサービス。AWSが提供する定義済みランブックのほか、カスタムワークフローの作成も可能。
KMSキー削除のキャンセル構成例：
EventBridgeでKMSキー削除操作を検知→Automationの定義済みランブックで削除をキャンセル→SNSで管理者にメール通知。
KMSキーを削除すると暗号化データの復号が永久に不可能になるため、削除権限の制限または自動キャンセルの仕組みが重要。