#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 月時点の情報に基づく。今後のアップデートは適宜追記する。
- 詳細仕様は公式ドキュメントを一次情報として確認のうえ設計判断を行うこと。
目次
- まずはこれ:用途別の推奨サービス早見表
- ガバナンス設計:マルチアカウントの着地
- アイデンティティと権限管理(IAM)
- 暗号化とシークレット管理
- 監査・可視化・脅威検知
- ネットワークと境界防御
- 移行(Application / Database / Data)
- バックアップ/DR/回復性
- 運用自動化(Ops / IaC / Observability)
- 最小構成テンプレート
- 設計チェックリスト(落とし穴対策)
- 学習ロードマップ(30 日)
- シリーズ総括
- 付録:用語ミニ辞典
まずはこれ:用途別の推奨サービス早見表
| 領域 | 第一想起(推奨) | 代替/関連 | 判断の目安 |
|---|---|---|---|
| マルチアカウント | 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 編
本記事