#1 Compute / Container / Storage / Network 編

#2 Data / Analytics / AI・ML / Integration 編

#3 Security / Governance / Migration / Operations 編
本記事

本記事のねらい
セキュリティ・ガバナンス・移行・運用の主要サービスを、ユースケースから逆引きできるよう整理する。
マルチアカウント運用・権限設計・監査・移行・運用自動化まで、**最初の正解（安全な着地）**を提示する。

対象読者

AWS を業務で運用する設計者／実装者。マルチアカウント着地や監査対応、インシデント耐性を短時間で整えたい読者
Lift & Shift／段階移行を控え、最小の運用コストで安全性を担保したい読者

到達点（この記事で分かること）

**マルチアカウント（OU/SCP）**の着地設計と最小ガードレール
**権限（IAM/Permission Boundary/ABAC）**の実戦知見と運用型
監査・検知・対応を支える 監視/ログ基盤の最小構成
移行（サーバー/DB/データ）と DR/バックアップの型
30 日で整える 実務ロードマップ

断り書き・更新方針

本記事は 2025 年 7 月時点の情報に基づく。今後のアップデートは適宜追記する。
詳細仕様は公式ドキュメントを一次情報として確認のうえ設計判断を行うこと。

まずはこれ：用途別の推奨サービス早見表

領域	第一想起（推奨）	代替／関連	判断の目安
マルチアカウント	AWS Organizations + Control Tower	IAM Identity Center / Service Catalog	OU とガードレールをテンプレで一括整備
シングルサインオン	IAM Identity Center (SSO)	外部 IdP (Azure AD/Okta)	SCIM 連携・属性ベース割当（ABAC）
権限管理	IAM（ロール/境界/ABAC）	SCP / Permission Boundary	最小権限と委任の線引きを明確化
暗号化	KMS（CMK）	CloudHSM	マネージドで十分な場合は KMS
シークレット	Secrets Manager	SSM Parameter Store	ローテーションや監査要件で使い分け
監査ログ	CloudTrail（Org Trail）	S3 + Athena	組織単位で必須。改ざん対策と集約
構成監査	AWS Config（Aggregator）	Conformance Packs	準拠状況の継続確認
脅威検知	GuardDuty / Detective	Security Hub（集約）	継続監視と追跡調査
ポスチャ統合	Security Hub	Audit Manager	セキュリティ状況の集約ビュー
境界防御	WAF / Shield / Firewall Manager	Network Firewall / R53 Resolver DNS Firewall	L7/L4 と DNS 層で多層防御
移行（サーバ）	Application Migration Service (MGN)	Snow Family（物理搬送）	エージェントで段階移行
移行（DB）	DMS	SCT（スキーマ変換）	CDC とダウンタイム最小化
データ転送	DataSync / Transfer Family	Snowball/S3 Transfer Acceleration	大容量/継続転送の自動化
バックアップ	AWS Backup	EBS Snapshot / RDS/Aurora Backup	複数サービスを一元運用
回復性	Route 53（ヘルスチェック/フェイルオーバー）	Resilience Hub / Global Accelerator	RTO/RPO に応じて選択
運用自動化	Systems Manager（Session/Patch/Runbook）	EventBridge / Lambda	SSH 無し運用と一括パッチ
IaC	CloudFormation / CDK / Terraform	Service Catalog	再現性・監査可能な変更管理
可観測性	CloudWatch（Metrics/Logs/Alarm/X-Ray）	Managed Grafana/Prometheus	収集〜分析〜アラートの統合

ガバナンス設計：マルチアカウントの着地

原則は “セキュリティ境界はアカウントで分離” である。人・基盤・プロダクト・共有の 4 レイヤで OU を切ると運用が安定する
Control Tower により Landing Zone（アカウント構成・SCP・監査/ログ集約）を自動敷設できる

推奨 OU 構成（例）

Security：ログ集約アカウント、監査アカウント
Infrastructure：共有ネットワーク、共有ツール（CI/CD 等）
Sandbox/Dev/Test/Prod：環境別にアプリケーションアカウント
Exceptions：特殊要件（規制/分離）

SCP とガードレールの基本

明示 Deny を先に定義（例：リージョン制限、Public 変更の抑止）
変更要求は IAM 側で許可し、SCP は“最終防波堤”
Control Tower 標準の 強制/検出ガードレール を適用し、逸脱を可視化

アイデンティティと権限管理（IAM）

人に権限を付けず、ロールに権限を付与しロールを引き受けるのが基本である
ABAC（属性ベース） によりタグや部門属性で権限制御を一般化できる
開発者向けは Permission Boundary で上限を定義し、委任を安心して行う

テーマ	推奨パターン	注意点
ユーザー管理	Identity Center + 外部 IdP 連携	アカウント自動プロビジョニング（SCIM）
クロスアカウント	IAM ロールの信頼ポリシー	最小外部信頼・条件（`aws:PrincipalOrgID`）
一時認証	STS・短期クレデンシャル	長期キー排除、ローテーション徹底
ABAC	タグベース許可	タグの厳格運用（命名規約/強制）
開発者権限	Permission Boundary + 監査	逸脱監視（Access Analyzer）

暗号化とシークレット管理

KMS を中核に SSE-KMS（S3/EBS/RDS 等）で暗号化を標準化する
シークレットは Secrets Manager（ローテーション/監査が要件）、アプリ設定は SSM Parameter Store を使い分ける

項目	推奨	注意
KMS キーポリシー	最小権限・明示ロール	暗黙 `*` を避ける、CloudTrail 監査
データ暗号化	既定で有効化	例外は設計レビュー必須
シークレット	Secrets Manager	自動ローテーション（RDS/Aurora 等）
アプリ設定	SSM Parameter Store	階層/バージョン/暗号化の使い分け

監査・可視化・脅威検知

監査の土台は CloudTrail（組織トレイル） と Config（Aggregator） である
GuardDuty で脅威検知、Security Hub で CIS/AWS ベストプラクティス等のスコア集約を行う
深掘り調査は Detective、ログ検索は Athena/OpenSearch を併用する

レイヤ	サービス	役割
監査ログ	CloudTrail（Org Trail）	API 記録の不変保管（S3/KMS/改ざん耐性）
構成ドリフト	AWS Config	リソース状態の履歴とドリフト検出
脅威検知	GuardDuty	アカウント/ネットワーク/データ平面の検知
統合ビュー	Security Hub	各種検知の集約・スコアリング
調査	Detective	関連イベントのグラフ分析
監視	CloudWatch / EventBridge	指標・ログ・自動対応（Ops とも連携）

ネットワークと境界防御

多層防御が基本である
- L7：ALB + WAF（Bot 制御/レート制限/署名）
- L4：NLB（高スループット）
- DDoS：Shield Advanced（24/7 SOC/費用保護）
- ネットワーク内：Network Firewall、VPC Endpoint（PrivateLink）
- DNS 層：Route 53 Resolver DNS Firewall

移行（Application / Database / Data）

アプリ移行：MGN (Application Migration Service) でエージェントベースの継続複製 → テストカットオーバー → 本番カットオーバー
DB 移行：DMS（CDC）でダウンタイム最小化、異種間は SCT でスキーマ変換
データ転送：DataSync（NAS/S3/EFS 間高速転送）、遠隔地や大容量は Snow Family

典型フロー（Lift & Shift）

評価：依存解析・性能要件・レイテンシ/帯域
設計：Landing Zone、ネットワーク、ID、監査
複製：MGN/DMS/DataSync
演習：リハーサル（テストカットオーバー）
切替：計画的カットオーバー、ロールバック手順

バックアップ/DR/回復性

AWS Backup で EBS/EFS/RDS/Aurora/DynamoDB 等を一元ポリシー管理する
DR は RTO/RPO の要件から逆算し、マルチ AZ → マルチリージョンの順で段階設計
フェイルオーバは Route 53 のヘルスチェック／フェイルオーバールーティングで自動化する

戦略	概要	目安
Backup＋Restore	コスト最小、復旧は遅め	RTO 長く可
Warm Standby	最小限稼働の待機系	中コスト/中 RTO
Active-Active	並行稼働	高コスト/最短 RTO

運用自動化（Ops / IaC / Observability）

Systems Manager：Session Manager（SSH 無しで踏み台不要）、Patch Manager（OS/エージェント一括）、Automation（Runbook）
変更管理は IaC（CloudFormation/CDK/Terraform） を前提にし、手作業禁止を原則とする
可観測性は CloudWatch（Metrics/Logs/Alarm/X-Ray） を中核に、必要に応じて Managed Grafana/Prometheus を採用する

最小構成テンプレート

A. Landing Zone（Control Tower + Org Trail + Config Aggregator）

# CloudFormation（概念抜粋：監査系の基礎）
Resources:
  OrganizationTrail:
    Type: AWS::CloudTrail::Trail
    Properties:
      IsOrganizationTrail: true
      S3BucketName: org-audit-logs
      KmsKeyId: arn:aws:kms:...
  ConfigAggregator:
    Type: AWS::Config::ConfigurationAggregator
    Properties:
      OrganizationAggregationSource:
        AllAwsRegions: true
        RoleArn: arn:aws:iam::123456789012:role/AWSConfigAggregatorRole

B. セキュアな公開 API（WAF + ALB/ECS + Secrets/KMS + CloudWatch）

# Terraform（概念抜粋）
resource "aws_wafv2_web_acl" "api" { scope = "REGIONAL" }
resource "aws_lb" "alb" { load_balancer_type = "application" }
resource "aws_ecs_service" "api" { launch_type = "FARGATE" }
# シークレットは aws_secretsmanager_secret / 参照はタスク定義で
# 監視は CloudWatch Logs/Alarm、WAF ログは S3/KMS へ

C. バックアップと DR（AWS Backup + Route 53 フェイルオーバ）

Resources:
  BackupVault:
    Type: AWS::Backup::BackupVault
    Properties: { BackupVaultName: "core-vault", EncryptionKeyArn: "arn:aws:kms:..." }
  BackupPlan:
    Type: AWS::Backup::BackupPlan
    Properties:
      BackupPlan:
        BackupPlanName: "daily-weekly-monthly"
        Rules:
          - RuleName: "daily"
            ScheduleExpression: "cron(0 17 * * ? *)"  # 毎日
            Lifecycle: { DeleteAfterDays: 35 }

設計チェックリスト（落とし穴対策）

SCP と IAM の役割誤解：SCP は“上限”　許可は IAM で行う
KMS キーポリシーの暗黙許可：Principal: * を安易に使わない　明示のロールに限定
S3 公開ブロックの二重管理：口を開ける前に Block Public Access を有効化　OAC/署名 URL を基本に
CloudTrail 未集約：組織トレイルで一括　ログは 専用アカウントの S3/KMS に格納し、書込のみ許可にする
Config 無し運用：ドリフト検知ができない　Aggregator で全リージョン収集
GuardDuty/Security Hub 未有効：検知できない　初日で Org 有効化
長期アクセスキー放置：Identity Center で人管理し、キーは短期化
SSH/Bastion 常時開放：Session Manager へ移行　ポートは閉じる
手作業の本番変更：IaC 以外を禁止　変更は PR レビュー＋パイプライン経由
タグ不統一：ABAC やコスト配賦が崩壊　命名規約＋必須タグを強制

学習ロードマップ（30 日）

Week 1：ガバナンス基盤

Organizations/Control Tower、OU/SCP 設計。Identity Center と外部 IdP 連携、ABAC 基礎

Week 2：監査と検知

CloudTrail（Org）、Config（Aggregator/Conformance Pack）、GuardDuty/Security Hub/Detective の一通り

Week 3：運用自動化と可観測性

Systems Manager（Session/Patch/Automation）、CloudWatch（Logs/Alarm/X-Ray）、イベント駆動運用（EventBridge + Lambda）

Week 4：移行と回復性

MGN/DMS/DataSync のハンズオン、AWS Backup、Route 53 フェイルオーバ、Resilience 設計レビュー

シリーズ総括

#1 では Compute/Container/Storage/Network を「いつ使うか」で整理した
#2 では Data/Analytics/AI・ML/Integration の判断軸を得た
本記事 #3 は Security/Governance/Migration/Operations の土台を提示した

この 3 本で、AWS 設計の 80% を用途から逆引きできるようになるはずである。

付録：用語ミニ辞典

OU（Organizational Unit）：アカウントを論理分割する単位
SCP（Service Control Policy）：組織/OU/アカウントに適用する“上限”ポリシー
ABAC：属性ベースアクセス制御　タグ等の属性で権限を動的に決定
Org Trail：Organizations 全体を対象にした CloudTrail
Permission Boundary：IAM 権限の上限を定義する枠。委任の安全弁
CDC（Change Data Capture）：データ更新の増分追跡による同期方式

#1 Compute / Container / Storage / Network 編

#2 Data / Analytics / AI・ML / Integration 編

#3 Security / Governance / Migration / Operations 編
本記事