AWS Resource Access Manager (RAM) 完全ガイド v2.0

マルチアカウント・リソース共有のベストプラクティス

AWS Resource Access Manager (AWS RAM) は、AWS リソースを複数のアカウント・OU・Organizations 全体で安全に共有するサービス です。Transit Gateway・VPC サブネット・Route 53 Resolver ルール・License Manager・Aurora DB クラスター等を、リソース複製なしに複数アカウント間で共有し、一元管理・コスト削減・セキュリティ統一を実現します。2026年2月の重要アップデートでは、Organizations 間でのアカウント移動時にリソース共有を継続 できるようになり、M&A・組織再編での継続性が強化されました。本ドキュメントは RAM の概念・実装・最新動向を体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

初心者向け： マルチアカウント環境とは何か、RAM がなぜ必要かを学びたい方
NetOps 向け： Transit Gateway・VPC サブネット・Network Firewall 共有の実装
セキュリティ向け： クロスアカウントアクセス制御、IAM ロール・ユーザーレベルの権限管理
FinOps 向け： License Manager・Savings Plans 共有によるコスト最適化
アーキテクト向け： 複数アカウント / Organizations 設計パターン、ガバナンス戦略
意思決定者向け： Azure Lighthouse / GCP Cross-project Access との比較検討

2025-2026 年の AWS RAM エコシステム

Organizations 間のアカウント移動対応（2026年2月）： RetainSharingOnAccountLeaveOrganization パラメータで、アカウント移動時にリソース共有を継続。M&A・組織再編での継続性が実現
CloudFront VPC Origins 統合（2025年11月）： CloudFront ← VPC Origins のクロスアカウント参照を AWS RAM で実現
Cost Management Dashboard 共有（2025年8月）： Cost Explorer のダッシュボードを複数アカウント間で共有
Permission 管理の精度向上： AWS managed permissions の拡充、Customer managed permissions のサポート強化
CloudTrail 統合深化： リソース共有・権限変更の監査ログ記録
Organizations Policy との連携： SCP / Tag Policy との統合で、共有リソースへのアクセス制御を强化

概要
RAM が解決する課題
主な特徴
アーキテクチャ
共有可能なリソースタイプ
コアコンポーネント
Transit Gateway 共有戦略
VPC サブネット共有（共有 VPC パターン）
Permission（許可）管理
Resource Share の作成・管理
Organizations との統合
CLI/SDK 実装例
Terraform/CDK による IaC
Account Joining・Leaving 処理
他のクロスアカウント手段との比較
ベストプラクティス
トラブルシューティング
セキュリティ・ガバナンス
料金モデル
2025-2026 最新動向
学習リソース・参考文献
実装チェックリスト
まとめ

概要

AWS RAM は、複数の AWS アカウント・OU・IAM ロール/ユーザー間でリソースを安全に共有 するための完全マネージドサービスです。

従来のマルチアカウント環境では、各アカウントで個別にリソースを作成・管理する必要がありました：

従来のマルチアカウント構成（効率が悪い）：
Account A: Transit Gateway (tgw-aaa)
Account B: Transit Gateway (tgw-bbb) ← 重複作成・管理コスト増加
Account C: Transit Gateway (tgw-ccc)

AWS RAM を使うと：

AWS RAM による一元管理（効率的）：

Network Account: Transit Gateway (tgw-central)
         ↓ AWS RAM で共有
    ┌─────┴─────┬─────────┐
    ↓           ↓           ↓
Account A   Account B   Account C
（tgw-central をアタッチするだけ）

主要なメリット：

ワンタイムの TGW 構築 → 複数アカウントで再利用
ネットワーク管理の一元化（Network Account で統一管理）
コスト削減：TGW アタッチメント料金は中央で集約
新規アカウント追加時の自動共有（Organizations との統合）

RAM が解決する課題

1. マルチアカウント環境でのリソース重複作成

問題シーン：

10アカウント × Transit Gateway 1個ずつ = 管理負荷が 10倍

RAM での解決：

中央アカウントで TGW 1個 → 9個のアカウントに共有
→ 管理負荷 = 1 + 9 * 読み取り専用

2. IP アドレス管理（CIDR）の複雑化

従来の課題：

各アカウントが独立した VPC を作成 → CIDR 重複リスク
VPC ピアリング / Transit Gateway の複雑な設定

RAM による解決：

Network Account が CIDR 一元管理
↓
各ワークロードアカウントが Network Account のサブネットを共有
↓
CIDR 重複なし、ルーティング一元化

3. License Manager・Savings Plans の複数アカウント展開

従来： 各アカウントでライセンス・Savings Plans を個別購入

RAM： 中央で購入 → Organizations 全体で共有

4. Organizations 間のアカウント移動（2026年2月新機能）

従来： アカウント移動時に RAM 共有が失効

改善（2026年2月）： RetainSharingOnAccountLeaveOrganization で継続

主な特徴

特徴	説明
完全無料	RAM 自体の利用料金なし（リソース料金のみ）
マルチアカウント対応	同一 Organization 内 + Organization 外のアカウント両対応
OU 単位での共有	Organization 内の複数アカウントに一括共有
権限制御（Permission）	AWS managed / Customer managed 権限で柔軟に制御
自動承認（Organization 内）	OU 内のアカウントは招待不要で自動アクセス
招待プロセス（Organization 外）	外部アカウントへの共有は明示的な承認が必要
IAM レベルの制御	特定のロール・ユーザーのみアクセス可能（一部リソース型）
Organizations Policy 統合	SCP / Tag Policy と組み合わせて共有リソースのアクセス制御
CloudTrail 監査対応	すべてのリソース共有・権限変更をログに記録

アーキテクチャ

graph TB
    subgraph "AWS Organizations"
        subgraph "Management Account"
            ORG["Organizations"]
        end
        
        subgraph "Network OU"
            NET_ACCT["Network Account<br/>(Resource Owner)"]
            TGW["Transit Gateway<br/>(Resource)"]
            SUBNET["VPC Subnets<br/>(Resource)"]
        end
        
        subgraph "Workload OU"
            WL1["Workload A"]
            WL2["Workload B"]
            WL3["Workload C"]
        end
    end
    
    subgraph "AWS RAM"
        RS1["Resource Share 1<br/>(TGW)"]
        RS2["Resource Share 2<br/>(VPC Subnet)"]
        PERM["Permission<br/>(AWS Managed)"]
    end
    
    subgraph "External Account"
        EXT["External Account"]
    end
    
    NET_ACCT -->|Owner| TGW
    NET_ACCT -->|Owner| SUBNET
    
    TGW -.共有.-> RS1
    SUBNET -.共有.-> RS2
    
    RS1 -->|AmazonEC2TransitGatewayAttachmentDefaultPolicy| WL1
    RS1 -->|AmazonEC2TransitGatewayAttachmentDefaultPolicy| WL2
    RS1 -->|AmazonEC2TransitGatewayAttachmentDefaultPolicy| WL3
    
    RS2 -->|AmazonEC2SubnetDefaultPolicy| WL1
    
    RS1 -->|Invitation| EXT
    
    ORG -.Organizations Policy.-> RS1

共有可能なリソースタイプ

Networking（ネットワーク関連）

リソース	共有先	説明
Transit Gateway	アカウント・OU	最も一般的。複数 VPC を TGW で中央接続
VPC Subnets	アカウント・OU	共有 VPC パターン（複数アカウントが同一 VPC のサブネットを使用）
Transit Gateway Route Tables	アカウント・OU	TGW ルーティング設定の共有
Transit Gateway Attachments	ロール・ユーザー	VPC / VPN / Direct Connect をアタッチ
Network Firewall	アカウント・OU	ファイアウォールポリシー共有
Route 53 Resolver Rules	アカウント・OU	DNS ルール（オンプレミス ↔ AWS）
IPAM Pools	アカウント・OU	IP アドレス管理ポール共有

Database（データベース関連）

リソース	共有先	説明
Aurora DB Cluster	アカウント・OU	DB クラスタ自体は共有できず、スナップショット復元で対応
RDS Snapshot	アカウント・OU	DB バックアップを共有

Developer Tools（開発ツール関連）

リソース	共有先	説明
CodeBuild Projects	アカウント・OU	ビルドプロジェクト共有
ECR Repositories	アカウント・OU	Docker イメージリポジトリ共有
CodeArtifact Repositories	アカウント・OU	パッケージリポジトリ共有

Data & Analytics（データ・分析関連）

リソース	共有先	説明
AWS Glue Data Catalog	アカウント・OU	テーブル・DB を別アカウントから参照
Amazon Athena Workgroups	ロール・ユーザー	Athena ワークグループ共有
Amazon EMR Clusters	ロール・ユーザー	EMR クラスタ（※ 制限あり）

Management（管理関連）

リソース	共有先	説明
AWS License Manager	アカウント・OU	ライセンス設定共有（Windows / SQL Server）
Service Catalog Portfolio	アカウント・OU	IaC テンプレート・サービス共有
Savings Plans	組織全体	割引プラン共有
Compute Optimizer	ロール・ユーザー	最適化推奨事項共有
AppRegistry Apps	ロール・ユーザー	アプリケーション登録簿共有

コアコンポーネント

1. Resource Share（リソース共有）

リソース共有は、一つ以上のリソース + 権限 + 共有先を定義するコンテナ です。

構成要素：

Resource Share
├── Name: "tgw-prod-share"
├── Resources: [
│   - arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway/tgw-xxx
│   - arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway/tgw-xxx/transit-gateway-route-table/tgw-rtb-xxx
│ ]
├── Permissions: [
│   - AmazonEC2TransitGatewayAttachmentDefaultPolicy
│ ]
└── Principals: [
    - arn:aws:organizations::123456789012:ou/o-xxx/ou-PROD
    - arn:aws:organizations::123456789012:account/o-xxx/123456789099
  ]

2. Permission（許可）

Permission は、リソース上で何ができるかを定義するアクセス制御。

2 種類：

種類	作成者	カスタマイズ	用途
AWS Managed	AWS	不可	一般的なユースケース向け
Customer Managed	ユーザー	可能	最小権限のアクセス制御

AWS Managed Permission 例：

- AmazonEC2TransitGatewayAttachmentDefaultPolicy
  → VPC / VPN を TGW にアタッチ可能

- AmazonEC2SubnetDefaultPolicy
  → EC2 インスタンスをサブネットで起動可能

- AmazonRoute53ResolverQueryLoggingConfigurationDefaultPolicy
  → Resolver クエリロギング設定

3. Principal（プリンシパル）

リソース共有の受信者。3 つのレベルで指定：

レベル	指定方式	説明
Organization	`arn:aws:organizations::ACCOUNT:organization/o-XXX`	組織全体（すべてのアカウント）
OU（Organization Unit）	`arn:aws:organizations::ACCOUNT:ou/o-XXX/ou-YYY`	特定の OU（複数アカウント一括）
Account	`arn:aws:organizations::ACCOUNT:account/o-XXX/ACCOUNT_ID`	単一アカウント
IAM Role	`arn:aws:iam::ACCOUNT:role/ServiceRole`	特定ロール（一部リソース型のみ）
IAM User	`arn:aws:iam::ACCOUNT:user/john.doe`	特定ユーザー（一部リソース型のみ）

4. Resource Association（リソース関連付け）

Resource Share にリソースを追加・削除。

# リソースを Resource Share に追加
aws ram associate-resource-share \
  --resource-share-arn arn:aws:ram:ap-northeast-1:123456789012:resource-share/xxx \
  --resource-arns arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway/tgw-yyy

# リソースを削除
aws ram disassociate-resource-share \
  --resource-share-arn arn:aws:ram:ap-northeast-1:123456789012:resource-share/xxx \
  --resource-arns arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway/tgw-yyy

Transit Gateway 共有戦略

ハブ・スポーク構成（最も一般的）

┌─────────────────────────────────────────┐
│      Network Account (Owner)            │
│  ┌──────────────────────────────────┐   │
│  │  Transit Gateway (Central Hub)   │   │
│  │         (tgw-central)            │   │
│  └──────────────────────────────────┘   │
└─────────────────────────────────────────┘
            ↓ AWS RAM 共有
    ┌───────┴───────┬──────────┐
    ↓               ↓          ↓
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Account A   │ │ Account B   │ │ Account C   │
│ (Spoke A)   │ │ (Spoke B)   │ │ (Spoke C)   │
└─────────────┘ └─────────────┘ └─────────────┘

メリット：

TGW を 1 個のみ管理
Network Account が一元制御
スポーク間の通信は Hub 経由

実装：

# ステップ 1: Network Account で TGW 作成
aws ec2 create-transit-gateway \
  --description "Central Hub" \
  --options AmazonSideAsn=64512 \
  --region ap-northeast-1

# ステップ 2: AWS RAM で共有
aws ram create-resource-share \
  --name tgw-hub-share \
  --resource-arns arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway/tgw-central \
  --principals arn:aws:organizations::123456789012:ou/o-xxx/ou-PROD \
  --region ap-northeast-1

# ステップ 3: スポークアカウント A で VPC を TGW にアタッチ
# (スポークアカウント側)
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-central \
  --vpc-id vpc-spoke-a \
  --subnet-ids subnet-a1 subnet-a2 \
  --region ap-northeast-1

メッシュ構成（複雑だが柔軟）

すべてのアカウント / VPC が直接接続。

Account A ←→ Account B
  ↓ ↖      ↙ ↑
  ↓  TGW    ↑
  ↙ ↗      ↖ ↓
Account C ←→ Account D

用途： 高性能・低遅延が要件（金融・証券）

VPC サブネット共有（共有 VPC パターン）

共有 VPC アーキテクチャ

┌──────────────────────────────────────────┐
│     Network Account                      │
│  ┌─────────────────────────────────┐     │
│  │ VPC (10.0.0.0/16)               │     │
│  │  ├── Subnet A (10.0.1.0/24) ──┐ │     │
│  │  │   └─ AWS RAM で共有         │ │ ←──────┐
│  │  ├── Subnet B (10.0.2.0/24) ──┤ │     │  │
│  │  │                             │ │     │  │
│  │  └──── Route Table, NACLs  ────┘ │     │  │
│  └─────────────────────────────────┘     │  │
└──────────────────────────────────────────┘  │
         ↓ AWS RAM で共有                     │
    ┌────────────────┬─────────────────┐     │
    ↓                ↓                 ↓     │
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Account A    │ │ Account B    │ │ Account C    │
│ (EC2, ECS)   │ │ (Lambda)     │ │ (RDS, etc)   │
└──────────────┘ └──────────────┘ └──────────────┘

メリット：

VPC 設計・ルーティング一元管理
複数ワークロードが同じネットワーク空間を共有
CIDR 枯渇を回避

実装：

# ステップ 1: Network Account で VPC・Subnet 作成
aws ec2 create-vpc --cidr-block 10.0.0.0/16
aws ec2 create-subnet --vpc-id vpc-xxx --cidr-block 10.0.1.0/24

# ステップ 2: AWS RAM でサブネット共有
aws ram create-resource-share \
  --name shared-vpc-subnets \
  --resource-arns arn:aws:ec2:ap-northeast-1:123456789012:subnet/subnet-a1 \
  --principals arn:aws:organizations::123456789012:account/o-xxx/123456789099 \
  --region ap-northeast-1

# ステップ 3: ワークロードアカウント側で EC2 起動
# (ワークロードアカウント側)
aws ec2 run-instances \
  --image-id ami-xxx \
  --subnet-id subnet-a1 \
  --region ap-northeast-1

Permission（許可）管理

AWS Managed Permission の確認

# 利用可能な Permission 一覧
aws ram list-permissions --resource-type transit-gateway

# 出力例
{
  "permissions": [
    {
      "arn": "arn:aws:ram::aws:permission/ec2/AmazonEC2TransitGatewayAttachmentDefaultPolicy",
      "name": "AmazonEC2TransitGatewayAttachmentDefaultPolicy",
      "resourceType": "transit-gateway",
      "status": "ASSOCIATED",
      "creationTime": "2025-01-01T00:00:00Z",
      "version": 1,
      "isResourceTypeDefault": true
    }
  ]
}

Customer Managed Permission の作成

最小権限のアクセス制御：

# ステップ 1: Permission JSON を定義
cat > tgw-minimal-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateTransitGatewayVpcAttachment",
        "ec2:DescribeTransitGatewayAttachments"
      ],
      "Resource": "*"
    }
  ]
}
EOF

# ステップ 2: Customer Managed Permission を作成
aws ram create-permission \
  --name MinimalTGWAttachmentPermission \
  --resource-type transit-gateway \
  --policy-template file://tgw-minimal-policy.json \
  --region ap-northeast-1

# ステップ 3: Resource Share に関連付け
aws ram associate-resource-share-permission \
  --resource-share-arn arn:aws:ram:ap-northeast-1:123456789012:resource-share/xxx \
  --permission-arn arn:aws:ram::123456789012:permission/transit-gateway/MinimalTGWAttachmentPermission \
  --associate true

基本的な作成フロー

# ステップ 1: Resource Share を作成
RS_ARN=$(aws ram create-resource-share \
  --name my-tgw-share \
  --allow-external-principals false \
  --tags Key=Owner,Value=NetOps Key=Environment,Value=Production \
  --query 'resourceShare.resourceShareArn' \
  --output text)

echo "Created Resource Share: $RS_ARN"

# ステップ 2: リソースを追加
aws ram associate-resource-share \
  --resource-share-arn "$RS_ARN" \
  --resource-arns arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway/tgw-xxx

# ステップ 3: Principal（共有先）を指定
aws ram associate-principal \
  --resource-share-arn "$RS_ARN" \
  --principal arn:aws:organizations::123456789012:ou/o-xxx/ou-PROD

# ステップ 4: 状態確認
aws ram describe-resource-shares \
  --filters name=resourceShareArn,values="$RS_ARN"

複数リソースの一括共有

# Production OU の複数リソースを共有
aws ram create-resource-share \
  --name prod-infrastructure-share \
  --resource-arns \
    arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway/tgw-central \
    arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway-route-table/tgw-rtb-xxx \
    arn:aws:ec2:ap-northeast-1:123456789012:subnet/subnet-a \
    arn:aws:ec2:ap-northeast-1:123456789012:subnet/subnet-b \
  --principals arn:aws:organizations::123456789012:ou/o-xxx/ou-PROD

Organizations との統合

Organizations 内での自動共有

Organization に属するアカウントへの共有は、招待プロセスなしで自動承認：

# Organization 内の OU に自動共有
aws ram create-resource-share \
  --name auto-share-prod \
  --resource-arns arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway/tgw-xxx \
  --principals arn:aws:organizations::123456789012:ou/o-xxx/ou-PROD

# 状態確認
aws ram get-resource-share-invitations
# → アカウントオーナーが接受を待つ必要なし（自動受け入れ）

SCP（Service Control Policy）との組み合わせ

Organization Policy で共有リソースのアクセスを制御：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:CreateTransitGatewayVpcAttachment",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:TransitGateway": [
            "arn:aws:ec2:*:123456789012:transit-gateway/tgw-central"
          ]
        }
      }
    }
  ]
}

Account Joining・Leaving 処理

2026年2月の新機能：RetainSharingOnAccountLeaveOrganization

Organizations 間でアカウントが移動する際、リソース共有を継続：

# アカウント移動時に共有を保持
aws ram update-resource-share \
  --resource-share-arn arn:aws:ram:ap-northeast-1:123456789012:resource-share/xxx \
  --allow-external-principals true \  # 外部アカウントとしても対応
  --region ap-northeast-1

# ※ 実際の移動前に Organization Policy で権限を調整

シナリオ：

1. Account A が Organization X に属している
   → Organization X から RAM で TGW を共有
   
2. Account A が Organization X を離脱し、Organization Y に参加
   → RetainSharingOnAccountLeaveOrganization = true の場合
   → TGW アクセスが継続（外部アカウント扱い）
   
3. Account A が Organization Y 内で TGW にアクセス継続

CLI/SDK 実装例

Python SDK 高度な実装

import boto3
from typing import List, Dict, Optional

class AWSRAMManager:
    def __init__(self, region: str = 'ap-northeast-1'):
        self.ram = boto3.client('ram', region_name=region)
        self.ec2 = boto3.client('ec2', region_name=region)
    
    def create_resource_share(self, 
                             name: str,
                             resource_arns: List[str],
                             principal: str,
                             allow_external: bool = False) -> str:
        """Resource Share を作成"""
        response = self.ram.create_resource_share(
            name=name,
            resourceArns=resource_arns,
            principals=[principal],
            allowExternalPrincipals=allow_external,
            tags=[
                {'key': 'ManagedBy', 'value': 'Python'},
                {'key': 'CreatedDate', 'value': str(__import__('datetime').datetime.now())}
            ]
        )
        
        share_arn = response['resourceShare']['resourceShareArn']
        print(f"Created Resource Share: {share_arn}")
        
        return share_arn
    
    def add_resources_to_share(self, 
                              share_arn: str,
                              resource_arns: List[str]) -> bool:
        """Resource を既存の Share に追加"""
        try:
            self.ram.associate_resource_share(
                resourceShareArn=share_arn,
                resourceArns=resource_arns
            )
            print(f"Associated {len(resource_arns)} resources to {share_arn}")
            return True
        except Exception as e:
            print(f"Error: {e}")
            return False
    
    def list_shared_resources(self, 
                            share_arn: str) -> List[Dict]:
        """Share 内のリソース一覧取得"""
        response = self.ram.list_resources(
            resourceOwner='SELF',
            resourceShareArn=share_arn,
            maxResults=100
        )
        
        resources = []
        for resource in response.get('resources', []):
            resources.append({
                'arn': resource['arn'],
                'type': resource['type'],
                'status': resource['statusMessage']
            })
        
        return resources
    
    def get_all_incoming_shares(self) -> List[Dict]:
        """受信した Resource Share 一覧（別アカウント）"""
        response = self.ram.list_resource_shares(
            resourceOwner='OTHER_ACCOUNTS',
            maxResults=100
        )
        
        shares = []
        for share in response.get('resourceShares', []):
            shares.append({
                'name': share['name'],
                'arn': share['resourceShareArn'],
                'ownerAccountId': share['owningAccountId'],
                'status': share['status']
            })
        
        return shares
    
    def accept_resource_share_invitation(self, 
                                        share_invitation_arn: str) -> bool:
        """Resource Share 招待を受け入れ"""
        try:
            self.ram.accept_resource_share_invitation(
                resourceShareInvitationArn=share_invitation_arn
            )
            print(f"Accepted invitation: {share_invitation_arn}")
            return True
        except Exception as e:
            print(f"Error: {e}")
            return False

# 使用例
if __name__ == "__main__":
    manager = AWSRAMManager()
    
    # 1. TGW ARN 取得
    tgw_response = manager.ec2.describe_transit_gateways(
        Filters=[
            {'Name': 'tag:Environment', 'Values': ['production']}
        ]
    )
    
    tgw_arn = f"arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway/{tgw_response['TransitGateways'][0]['TransitGatewayId']}"
    
    # 2. Resource Share 作成
    share_arn = manager.create_resource_share(
        name='tgw-production-share',
        resource_arns=[tgw_arn],
        principal='arn:aws:organizations::123456789012:ou/o-xxx/ou-PROD'
    )
    
    # 3. 共有リソース確認
    resources = manager.list_shared_resources(share_arn)
    for res in resources:
        print(f"  - {res['arn']} ({res['type']})")
    
    # 4. 別アカウントから共有を確認・受け入れ
    # (別アカウント側の実行)
    incoming_shares = manager.get_all_incoming_shares()
    for share in incoming_shares:
        print(f"Incoming share: {share['name']}")

Terraform/CDK による IaC

Terraform 実装

# main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

# Transit Gateway の作成（Network Account）
resource "aws_ec2_transit_gateway" "main" {
  description                     = "Central Hub for Multi-Account"
  default_route_table_association = "enable"
  default_route_table_propagation = "enable"
  dns_support                     = "enable"
  vpn_ecn_support                 = "enable"
  
  tags = {
    Name        = "central-tgw"
    Environment = "production"
  }
}

# AWS RAM Resource Share
resource "aws_ram_resource_share" "tgw" {
  name                      = "tgw-production-share"
  allow_external_principals = false
  
  tags = {
    Name        = "tgw-share"
    Owner       = "NetOps"
    Environment = "production"
  }
}

# Resource を Share に関連付け
resource "aws_ram_resource_association" "tgw" {
  resource_arn       = aws_ec2_transit_gateway.main.arn
  resource_share_arn = aws_ram_resource_share.tgw.arn
}

# Organization OU に共有
resource "aws_ram_principal_association" "prod_ou" {
  principal          = "arn:aws:organizations::123456789012:ou/o-xxx/ou-PROD"
  resource_share_arn = aws_ram_resource_share.tgw.arn
}

# 出力
output "transit_gateway_id" {
  value = aws_ec2_transit_gateway.main.id
}

output "resource_share_arn" {
  value = aws_ram_resource_share.tgw.arn
}

他のクロスアカウント手段との比較

手段	管理方式	複数アカウント対応	推奨用途
AWS RAM	一元化（Resource Owner）	優秀	TGW・VPC・Glue・Service Catalog
Resource-based Policy	Inline（分散）	対応（複雑）	S3・IAM・Lambda 等のアドホック共有
Cross-account IAM Role	Assume Role	対応	リソースの完全委任（Lambda・EC2）
Organizations API	Hierarchical	優秀	請求・コンプライアンス管理
VPC Peering	P2P	限定的	2つの VPC 間の接続
Transit Gateway	Hub-spoke	優秀	複数 VPC・Region・Account の接続

ベストプラクティス

1. 責任の分離（Network Account パターン）

Network Account: リソース所有・ネットワーク管理
├── Transit Gateway
├── VPC / Subnets
├── Route 53 Resolver
└── Network Firewall

Workload Accounts: アプリケーション実行
├── EC2 / ECS
├── RDS (Network Account のサブネットで実行)
└── Lambda

2. 命名規約の統一

Resource Share 名: [resource-type]-[environment]-share
例：
- tgw-production-share
- vpc-subnets-staging-share
- glue-catalog-dev-share

Tag:
- Owner: NetOps / DataEng / Platform
- Environment: production / staging / development
- CostCenter: CC-123

3. 権限の最小化

# AWS Managed ではなく Customer Managed Permission を使用
# 必要最小限のアクションのみを許可

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateTransitGatewayVpcAttachment",  # アタッチのみ
        "ec2:DescribeTransitGatewayAttachments"   # 読み取りのみ
      ],
      "Resource": "*"
    }
  ]
}

4. 監査・ロギング

# CloudTrail で RAM 操作をログ

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=CreateResourceShare \
  --max-results 10

# CloudWatch で監視

aws logs create-log-group \
  --log-group-name /aws/ram/operations

トラブルシューティング

症状： get-resource-share-invitations で結果が空

原因と対策：

# Organization 内の共有の場合は招待なし（自動承認）
# → Resource Share が ACTIVE 状態か確認

aws ram describe-resource-shares \
  --resource-share-arns arn:aws:ram:ap-northeast-1:123456789012:resource-share/xxx \
  --query 'resourceShares[0].status'

# Organization 外のアカウントへの共有の場合
# → 受信側アカウントで待機中の Invitation を確認

aws ram get-resource-share-invitations

2. リソース共有が機能しない（Permission エラー）

症状： “User is not authorized” エラー

原因と対策：

# 1. IAM ロール / ユーザーの権限確認
aws iam get-role-policy \
  --role-name MyServiceRole \
  --policy-name TransitGatewayAccess

# 2. Resource Share の Permission 確認
aws ram list-resource-share-permissions \
  --resource-share-arn arn:aws:ram:ap-northeast-1:123456789012:resource-share/xxx

# 3. SCP (Service Control Policy) による制限がないか確認
aws organizations list-policies \
  --filter SERVICE_CONTROL_POLICY

3. アカウント移動時に共有が失効

症状： Account A が Organization X → Y に移動後、リソース共有できない

対策（2026年2月以降）：

# RetainSharingOnAccountLeaveOrganization を有効化
aws ram update-resource-share \
  --resource-share-arn arn:aws:ram:ap-northeast-1:123456789012:resource-share/xxx \
  --allow-external-principals true

# 外部アカウント扱いで Invitation を再発行

セキュリティ・ガバナンス

IAM ポリシー（最小権限）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRAMOperations",
      "Effect": "Allow",
      "Action": [
        "ram:GetResourceShares",
        "ram:ListResources",
        "ram:GetResourceShareInvitations"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyResourceShareCreation",
      "Effect": "Deny",
      "Action": [
        "ram:CreateResourceShare",
        "ram:DeleteResourceShare"
      ],
      "Resource": "*"
    }
  ]
}

CloudTrail 監査ログ

# RAM 操作をすべてログ
aws cloudtrail start-logging --trail-name ram-audit-trail

# ログを CloudWatch Logs に送信
aws cloudtrail update-trail \
  --name ram-audit-trail \
  --cloud-watch-logs-group-arn arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/ram/audit

料金モデル

項目	費用
AWS RAM 自体	無料
リソース料金	リソース固有の料金（TGW アタッチメント $0.05/h など）
データ転送	リソース固有の料金

コスト最適化：

Transit Gateway を一元管理 → 各アカウントでの TGW 作成を排除
VPC サブネット共有 → VPC 複製を排除

2025-2026 最新動向

1. Organizations 間のアカウント移動対応（2026年2月）

RetainSharingOnAccountLeaveOrganization パラメータで、M&A・組織再編時にリソース共有を継続。

2. CloudFront VPC Origins との統合（2025年11月）

CloudFront が別アカウントの VPC Origins にアクセス可能に（AWS RAM で共有）。

3. Cost Management Dashboard 共有（2025年8月）

Cost Explorer のダッシュボードを複数アカウント間で共有。

学習リソース・参考文献

AWS 公式ドキュメント

比較リソース

ベストプラクティス

OneUpTime Blog - Set Up AWS RAM (2026)

実装チェックリスト

[ ] Network Account・Workload Account の責任分離設計
[ ] Resource Share で共有するリソースの定義
[ ] AWS Managed / Customer Managed Permission の選択
[ ] Organizations OU 構成の確認
[ ] Resource Share 作成・Principal 割り当て
[ ] 共有リソースの動作テスト（別アカウント側）
[ ] IAM ロール・ユーザーのアクセス権限設定
[ ] CloudTrail ロギングの有効化
[ ] CloudWatch モニタリング・アラート設定
[ ] SCP (Service Control Policy) による追加の制御
[ ] 災害復旧・フェイルオーバー計画
[ ] 本番デプロイ前のセキュリティレビュー

まとめ

AWS RAM は、マルチアカウント環境でのリソース一元管理・共有を実現する完全無料のサービス です。

主要なポイント：

完全無料： RAM 自体に利用料金なし（リソース料金のみ）
Network Account パターン： ネットワークインフラを一元管理し、複数ワークロードアカウントで共有
Transit Gateway 共有： 各アカウントで TGW を作成するのではなく、中央で 1 個作成して共有
VPC サブネット共有： 複数アカウントが同じ VPC のサブネットを使用（CIDR 管理一元化）
Permission 制御： AWS Managed / Customer Managed で柔軟に権限制御
Organizations 統合： OU 単位での自動共有、新規アカウント追加時の自動適用
監査対応： CloudTrail で全操作をログ記録

推奨パターン：

Management Account
├── Organizations
│
├── Network Account （Resource Owner）
│   ├── Transit Gateway
│   ├── VPC / Subnets
│   └── AWS RAM で複数OU に共有
│
└── Workload Accounts （Consumer）
    ├── Account A → TGW にアタッチ
    ├── Account B → Subnets でリソース起動
    └── Account C → Route 53 Resolver ルール参照

最終更新：2026-04-26 バージョン：v2.0

目次

AWS Resource Access Manager (RAM) 完全ガイド v2.0

マルチアカウント・リソース共有のベストプラクティス

ドキュメントの目的

2025-2026 年の AWS RAM エコシステム

目次

概要

RAM が解決する課題

1. マルチアカウント環境での リソース重複作成

2. IP アドレス管理（CIDR）の複雑化

3. License Manager・Savings Plans の複数アカウント展開

4. Organizations 間のアカウント移動（2026年2月新機能）

主な特徴

アーキテクチャ

共有可能なリソースタイプ

Networking（ネットワーク関連）

Database（データベース関連）

Developer Tools（開発ツール関連）

Data & Analytics（データ・分析関連）

Management（管理関連）

コアコンポーネント

1. Resource Share（リソース共有）

2. Permission（許可）

3. Principal（プリンシパル）

4. Resource Association（リソース関連付け）

Transit Gateway 共有戦略

ハブ・スポーク構成（最も一般的）

メッシュ構成（複雑だが柔軟）

VPC サブネット共有（共有 VPC パターン）

共有 VPC アーキテクチャ

Permission（許可）管理

AWS Managed Permission の確認

Customer Managed Permission の作成

Resource Share の作成・管理

基本的な作成フロー

複数リソースの一括共有

Organizations との統合

Organizations 内での自動共有

SCP（Service Control Policy）との組み合わせ

Account Joining・Leaving 処理

2026年2月の新機能：RetainSharingOnAccountLeaveOrganization

CLI/SDK 実装例

Python SDK 高度な実装

Terraform/CDK による IaC

Terraform 実装

他のクロスアカウント手段との比較

ベストプラクティス

1. 責任の分離（Network Account パターン）

2. 命名規約の統一

3. 権限の最小化

4. 監査・ロギング

トラブルシューティング

1. Resource Share Invitation が表示されない

2. リソース共有が機能しない（Permission エラー）

3. アカウント移動時に共有が失効

セキュリティ・ガバナンス

IAM ポリシー（最小権限）

CloudTrail 監査ログ

料金モデル

2025-2026 最新動向

1. Organizations 間のアカウント移動対応（2026年2月）

2. CloudFront VPC Origins との統合（2025年11月）

3. Cost Management Dashboard 共有（2025年8月）

学習リソース・参考文献

AWS 公式ドキュメント

比較リソース

ベストプラクティス

実装チェックリスト

まとめ

1. マルチアカウント環境でのリソース重複作成