海外顧客のデータセンター廃止に伴い、オンプレミス環境からAWSへのクラウドリフトプロジェクトにアーキテクトとして参画しました。本記事では、AWS Organizationsが利用できないという制約下で、どのようにマルチアカウント戦略を構築し、複雑なオンプレミスネットワークとの整合性を保ちながらWell-Architectedなアーキテクチャを実現したかについて、設計上の考慮ポイントや苦労した点を共有します。
プロジェクトの背景
海外顧客では以下の課題を抱えていました。
- データセンターの老朽化：既存のオンプレミス環境を維持するコストが増大し、クラウド移行が急務
- 現地のAWS有識者不足：クラウドに精通したエンジニアが現地にほぼおらず、日本側からの技術支援が必要
- タイトなスケジュール：データセンター契約の関係上、限られた期間内での設計完了が求められた
- Organizationsが使えない：AWSアカウントの調達形態（リセラー経由）の都合上、AWS Organizationsを利用できないという大きな制約
特に最後の制約は、AWSのベストプラクティスであるマルチアカウント管理の根幹に関わる問題であり、設計の随所で代替策を検討する必要がありました。
加えて、本プロジェクトは海外顧客との直接のやり取りが前提であり、すべての設計書作成・技術議論・合意形成を英語で行う必要がありました。国内案件とは異なり、言語の壁に加えて、文化的な背景の違いや時差を考慮したコミュニケーション設計も求められる、グローバル案件ならではの難しさがありました。
アーキテクチャ全体像
マルチアカウント戦略（Organizationsなし）
AWS Well-Architected Frameworkでは、ワークロードの分離・セキュリティ境界の明確化のためにマルチアカウント構成が推奨されています。通常はOrganizationsのOU（Organizational Unit）構造でアカウントを階層管理しますが、今回はそれが使えません。
そこで、以下のアカウント分類を設計しました
┌─────────────────────────────────────────────────┐
│ Hub Account │
│ (認証・ロール切替の起点) │
├─────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Workload │ │ Workload │ │ Test │ │
│ │ (Main) │ │ (Regional) │ │ Account │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Audit │ │ Log │ │
│ │ Account │ │ Archive │ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────┘| アカウント種別 | 目的 |
|---|---|
| Workload (メイン) | 本番ワークロードをホスト |
| Workload (リージョナル) | 地域・事業部ごとのリソース分離と課金管理 |
| Test | 開発・検証環境の本番からの完全分離 |
| Hub | Switch Roleによる一元的なアクセス管理 |
| Audit | セキュリティ監視・コンプライアンスの集約 |
| Log Archive | 全アカウントのログの不変ストレージ |
技術的なポイント：Organizationsなしでのガバナンス確保
Organizationsが使えないことで、以下の機能が利用できません。
- SCP（Service Control Policies）：アカウント横断のポリシー強制ができない
- Organizations連携のサービス：CloudTrailの組織トレイル、GuardDutyの組織管理、Config Aggregatorの自動設定等
- 一括請求（Consolidated Billing）：コスト管理の一元化ができない
これらに対して、以下の代替設計を行いました。
1. SCPの代替：IAMポリシーとSwitch Roleによる権限制御
SCPが使えないため、Hub Accountを起点としたSwitch Role構成で権限を制御しました。各アカウントにSwitch先のIAM Roleを作成し、Hub AccountのIAMユーザーにのみAssumeRoleを許可する設計です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<HubAccountID>:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}特にAdministratorAccess権限については、MFA必須に加え、運用上マネージャーの事前承認を必須とするプロセスを設計しました。技術的な制御だけでなく、運用プロセスでカバーする部分を明確にすることが、Organizationsなし環境では重要です。
2. セキュリティサービスの集約管理
GuardDuty、Security Hub、CloudTrail、AWS Configについては、各アカウントで個別に有効化した上で、Auditアカウントに集約する設計としました。Organizationsの委任管理者機能が使えないため、各アカウントでの設定を標準化し、ログの転送先をAudit/Log Archiveアカウントに統一しています。
各Workloadアカウント Audit Account
┌─────────────────┐ ┌─────────────────┐
│ CloudTrail │ ── S3転送 ──> │ 集約S3バケット │
│ GuardDuty │ ─ EventBridge ─>│ 統合ダッシュボード │
│ AWS Config │ ── S3転送 ──> │ Conformance Pack │
│ Security Hub │ │ 統合管理 │
└─────────────────┘ └─────────────────┘3. コスト管理の代替
Consolidated Billingが使えないため、リセラー提供の専用コストダッシュボードを活用しつつ、各アカウントでCloudWatchによるコストアラートを設定し、閾値超過時にSNS経由で通知する仕組みを構築しました。
工夫した点：Conformance Packによるコンプライアンス自動評価
Organizationsなしでもセキュリティベースラインを担保するため、AWS ConfigのConformance Packを活用しました。CIS AWS Foundations Benchmarkを各アカウントに適用し、セキュリティポリシー違反を自動検出・通知する仕組みを構築しています。
これにより、SCPで強制できない部分を「検出的統制（Detective Control）」で補完する設計としました。予防的統制（Preventive Control）が弱い分、検出的統制を厚くするというトレードオフの判断です。
ネットワーク設計
VPCセグメンテーションとTransit Gateway
複数のVPCを用途別に分離し、Transit Gatewayで相互接続する構成を採用しました。
┌─────────────────┐
│ Transit Gateway │
└────────┬────────┘
┌─────────┬──────┼──────┬─────────┐
│ │ │ │ │
┌──────┴──┐ ┌────┴───┐ ┌┴────┐┌┴──────┐ ┌┴──────┐
│ Service │ │ Prod │ │ Test ││ Dev │ │ On-prem │
│ Shared │ │ VPC │ │ VPC ││ VPC │ │ (VPN) │
│ VPC │ │ │ │ ││ │ │ │
└─────────┘ └────────┘ └─────┘└───────┘ └───────┘| VPC | 目的 |
|---|---|
| Service Shared VPC | NAT Gateway、Route 53 Resolver、VPC Endpointなど共有リソースを集約 |
| Production VPC | 本番ワークロード |
| Test VPC | 開発・検証環境 |
| Dev VPC | 特定チーム管理のリソース |
技術的なポイント：環境間アクセス制御
本番環境とテスト環境の分離は、Transit Gatewayのルートテーブルで制御しました。特に注意が必要だったのは、オンプレミス側のテスト環境が本番サブネット上に同居しているケースです。
Transit Gateway Route Table設計：
[Production RT]
→ On-prem Production: Allow
→ On-prem Test (本番サブネット上): Allow（例外許可）
→ AWS Test VPC: Deny
[Test RT]
→ On-prem Test: Allow
→ AWS Production VPC: Denyオンプレミスの既存ネットワーク構成をそのまま受け入れつつ、AWS側では論理的に分離するという、現実的な妥協点を見出す必要がありました。Well-Architectedの理想と、既存環境の制約の間でバランスを取る判断が求められた部分です。
DNS設計：Route 53によるハイブリッドDNS
オンプレミスとAWS間のDNS名前解決は、Route 53 Resolver Endpointを活用したハイブリッド構成としました。
[オンプレ → AWS の名前解決]
On-prem DNS Server
│ Forward
▼
Route 53 Resolver Inbound Endpoint
│
▼
Route 53 Private Hosted Zone
[AWS → オンプレ の名前解決]
EC2 Instance (VPC DNS)
│
▼
Route 53 Resolver Outbound Endpoint
│ Forward
▼
On-prem DNS Server (AD統合DNS)複数のドメイン（本番用、開発用、リソース用等）が存在し、それぞれに対してPrivate Hosted Zoneを作成し、Transit Gateway経由で各VPCにアソシエーションする設計としました。
工夫した点：Service Shared VPCパターン
NAT GatewayやVPC Endpoint、Route 53 Resolver Endpointといった共有リソースをService Shared VPCに集約することで、以下のメリットを実現しました。
- コスト最適化：各VPCにNAT GatewayやVPC Endpointを個別に作成する必要がなく、共有利用でコスト削減
- 運用の簡素化：共有リソースの管理ポイントを一元化
- セキュリティの一貫性：インターネットへの出口を集約し、監視・制御を容易に
ただし、Service Shared VPCがSPOF（Single Point of Failure）にならないよう、NAT Gatewayは複数AZに配置し、可用性を確保しています。
可用性設計
Multi-AZ構成の判断基準
全サーバーをMulti-AZ構成にするとコストが倍増するため、システムの重要度に応じた段階的な可用性設計を行いました。
| 構成 | SLA | 月間想定ダウンタイム | 適用基準 |
|---|---|---|---|
| Single AZ × 1 Instance | 99.5% | 約3.65時間 | 非クリティカルなバッチ処理等 |
| Single AZ × 2 Instances | 約99.9% | 約43.8分 | AZ障害を許容できるシステム |
| 2 AZs × 2 Instances | 99.99% | 約4.38分 | ミッションクリティカルなシステム |
技術的なポイント：Cross-AZ通信コストの考慮
Multi-AZ構成では、AZ間通信にデータ転送コストが発生します。また、AZ間のレイテンシ（シングルミリ秒オーダー）がアプリケーションに影響しないかの確認も必要です。これらのトレードオフを現地エンジニアに説明し、システムごとに適切な構成を選択しました。
監視設計
CloudWatch Alarmの設計思想
監視設計では、既存のオンプレミス監視からの移行を考慮しつつ、AWSのベストプラクティスに沿った閾値設計を行いました。
既存環境の監視設定（移行前）：
CPUUtilization: Average, Period: 長め, Datapoints: 1
MemoryUtilization: Average, Period: 長め, Datapoints: 1
DiskSpaceUtilization: Average, Period: 長め, Datapoints: 1AWS移行後の監視設計：
CPUUtilization: Average, Period: 短縮, Datapoints: 複数回連続 → Severity: Warning
MemoryUtilization: Average, Period: 短縮, Datapoints: 複数回連続 → Severity: Warning
StatusCheckFailed: Maximum >= 1, Period: 短め, Datapoints: 複数回連続 → Severity: Critical
EBS StalledIOCheck: Maximum >= 1, Period: 短め, Datapoints: 複数回連続 → Severity: Critical
VPN TunnelState: Minimum < 1, Period: 短め, Datapoints: 複数回連続 → Severity: Critical移行前の監視設定は、評価期間が長くDatapointsも1回のみと、検知が遅れやすい構成でした。AWS移行後は評価期間を短縮し、複数回連続で閾値を超えた場合にアラートを発報する設計に変更することで、一時的なスパイクによる誤検知を防ぎつつ、真の異常を迅速に検知できるようにしました。
工夫した点：Severity別通知の分離
CloudWatch AlarmのSeverityをWarningとCriticalに分類し、それぞれ別のSNS Topicに紐づけることで、通知先・対応フローを分離しました。Criticalは即時対応、Warningは翌営業日対応とすることで、アラート疲れを防止しつつ重要なインシデントを見逃さない設計としています。
CloudWatch Alarm (Critical)
│
▼
SNS Topic (Critical) → 即時通知（メール + 将来的にチャット連携）
CloudWatch Alarm (Warning)
│
▼
SNS Topic (Warning) → 通常通知（メール）セキュリティ設計
多層防御の実現
クラウド移行に伴い、既存のオンプレミスセキュリティ対策に加えて、クラウドレイヤーのセキュリティを追加する多層防御を設計しました。
┌─────────────────────────────────────────────────┐
│ Network Layer: VPN (既存) │
├─────────────────────────────────────────────────┤
│ Cloud Layer: GuardDuty (新規追加) │
│ Security Hub (新規追加) │
│ AWS WAF (新規追加) │
│ Inspector (新規追加) │
├─────────────────────────────────────────────────┤
│ Server Layer: EDR (既存) │
│ Anti-Virus (既存) │
└─────────────────────────────────────────────────┘技術的なポイント：GuardDutyのSeverity設計
GuardDutyの脅威検出スコア（0.1〜10.0）に基づき、一定以上のSeverityをEventBridge経由でSNS通知する設計としました。低スコアの検出は情報レベルとしてログに記録のみ、中程度以上で運用チームに通知することで、対応の優先度を明確化しています。
バックアップ・リストア設計
AWS Backupを活用し、EBSのバックアップを自動化しました。ライフサイクル管理として、一定の短い期間はWarm Storageに保管し、その後Cold Storageへ移行する構成としています。S3についてはバージョニングを有効化した上で、Standard → Standard-IA → Glacierへのライフサイクル遷移を設計し、コスト最適化を図りました。
苦労したポイント
1. Organizationsなしでのマルチアカウント設計
最も苦労したのは、Organizationsが使えない中でのマルチアカウント戦略の設計です。AWSのベストプラクティスやWell-Architected Frameworkの推奨事項の多くはOrganizations前提で書かれており、それらを「Organizationsなし」の文脈に読み替えて適用する必要がありました。
特にSCPが使えないことで、予防的統制が弱くなる点は大きな課題でした。IAMポリシーの厳格な設計、Conformance Packによる検出的統制の強化、運用プロセスでの補完という三層のアプローチで対処しましたが、この設計判断に至るまでに多くの検討と議論を重ねました。
2. 既存オンプレミス環境の複雑さの理解
顧客のネットワーク構成は、複数の地域にまたがり、ドメイン構成も複雑でした。現地に十分なドキュメントが存在しない部分もあり、限られた出張期間中に現地エンジニアとの議論を通じて既存環境を理解し、それに適合するAWS設計を行う必要がありました。
事前準備として、出張前から現地の社員とコミュニケーションを取り、ネットワーク構成図や既存システムの情報を可能な限り収集しました。この準備があったからこそ、限られた現地滞在期間で基本設計を完遂できたと考えています。
3. 海外顧客とのテクニカルコミュニケーション
設計書の作成、現地エンジニアとの技術議論、すべて英語で行う必要がありました。AWSの技術用語は英語ベースなので比較的スムーズでしたが、設計判断の背景や理由を正確に伝え、合意形成を図る部分では、技術力だけでなくコミュニケーション力が求められました。
国内案件であれば暗黙的に共有されている前提知識や業務慣習が通用しないため、設計の意図や背景を一つひとつ丁寧に言語化し、ドキュメントに落とし込む必要がありました。これは手間がかかる反面、設計の品質を高める効果もあったと感じています。
また、時差がある中でのスケジュール調整や、対面でのワークショップと日本からのリモート支援を組み合わせたハイブリッドな進め方も、グローバル案件ならではの工夫でした。
4. リセラーアカウント特有の制約への対応
リセラー経由のAWSアカウントでは、Cost ExplorerやBilling and Cost Managementに直接アクセスできないなど、通常のAWSアカウントとは異なる制約があります。これらの制約を事前に洗い出し、代替手段を設計に組み込む作業は、一般的なAWS設計ガイドには載っていない部分であり、実践的な知見が求められました。
まとめ
- Organizationsなしでも、適切な設計によりWell-Architectedなマルチアカウント環境は構築可能。ただし、予防的統制の弱さを検出的統制と運用プロセスで補完する設計判断が重要
- Service Shared VPCパターンは、コスト最適化と運用簡素化の両面で有効。ただしSPOFにならないよう可用性設計が必要
- 既存オンプレミス環境との整合性を取るためには、理想的なクラウドアーキテクチャと現実の制約の間で適切なトレードオフを判断する力が求められる
- 海外顧客支援では、技術力に加えて事前準備・英語でのコミュニケーション力・文化的背景への理解が成果を大きく左右する
クラウド移行は技術的な課題だけでなく、組織・人材・コミュニケーションの課題が複合的に絡み合うプロジェクトです。アーキテクトとして、技術的な最適解を追求しつつも、現実の制約の中で最善の設計を導き出すことの重要性を改めて実感しました。
プロジェクト概要
- 主要サービス：EC2、VPC、Transit Gateway、Route 53、CloudWatch、GuardDuty、Security Hub、AWS Config、AWS Backup、Systems Manager、AWS WAF、Inspector
- 設計期間：約2ヶ月（2025年11月〜12月）
- 設計範囲：基本設計（ネットワーク、セキュリティ、監視、バックアップ、IAM、マルチアカウント戦略）