Strangler Fig パターン自動化・モノリス → マイクロサービス段階移行・ゼロダウンタイム
ドキュメントメタデータ
概要と課題
このサービスを選ぶ理由
Strangler Fig パターンの解説
アーキテクチャと設計原則
コアコンポーネント
主要ユースケース
設定・操作の具体例
類似サービス比較表
ベストプラクティス
トラブルシューティング表
2025-2026 最新動向
学習リソース・参考文献
実装例・チェックリスト
まとめ

AWS Migration Hub Refactor Spaces 完全ガイド v2.0（2026年最新対応）

Strangler Fig パターン自動化・モノリス → マイクロサービス段階移行・ゼロダウンタイム

AWS Migration Hub Refactor Spaces は、「モノリシックアプリケーションを段階的にマイクロサービスに分解するためのネットワークインフラストラクチャを自動構築・管理するサービス」である。Strangler Fig パターン（段階的機能抽出）を実現する API Gateway・VPC Lattice・Transit Gateway をマネージドで提供し、本番トラフィックへの影響を最小化しながら機能単位でマイクロサービスに切り出すプロセスを支援する。

ドキュメントメタデータ
概要と課題
このサービスを選ぶ理由
Strangler Fig パターンの解説
アーキテクチャと設計原則
コアコンポーネント
主要ユースケース
設定・操作の具体例
類似サービス比較表
ベストプラクティス
トラブルシューティング表
2025-2026 最新動向
学習リソース・参考文献
実装例・チェックリスト
まとめ

ドキュメントメタデータ

最終更新: 2026-04-27
バージョン: v2.0
対象者: Cloud Architect、Application Modernization Lead、Microservices Engineer
難易度: 中級～上級
関連サービス: API Gateway、VPC Lattice、Transit Gateway、Migration Hub、Application Load Balancer
プレビュー機能: VPC Lattice 統合（2025 年 GA）

概要と課題

本質

AWS Migration Hub Refactor Spaces は「モノリシックアプリケーション内の機能を段階的に新しいマイクロサービスに抽出し、本番トラフィックを段階的に新サービスに切り替える Strangler Fig パターンを、インフラレベルで自動実装するサービス」である。

従来のモノリス → マイクロサービス移行は以下の課題がある：

ネットワーク・ルーティング複雑性：API Gateway + VPC ピアリング + 詳細なルーティングルールの手動構築
トラフィック分割・カナリアロールアウト：複数サービスへのトラフィック分割ロジックを手動実装
モノリス本体への依存性：機能抽出後もモノリスが稼働し続けるため、複雑な API 呼び出し図
本番環境での検証困難：新機能（マイクロサービス）と既存機能（モノリス）の並行テスト

Refactor Spaces はこれらを Application・Service・Route の 3 層構造で自動化する：

Application：モノリス + マイクロサービス群を包含する論理単位
Service：モノリス or マイクロサービス（Lambda・ECS・EC2）
Route：特定パス（/api/orders など）のトラフィックをサービスに割り当てるルーティングルール

従来の課題

課題	説明
インフラ設定の複雑性	API Gateway + VPC ピアリング + NAT Gateway + セキュリティグループを手動構築・管理。設定ミスが容易
トラフィック分割の困難さ	API Gateway で条件分岐ルーティングを実装するには Lambda 統合が必要。メンテナンス負担大
本番環境への影響リスク	新マイクロサービスのバグが本番トラフィックに直結。段階的ロールアウトの仕組みがない
複数アカウント間の統合	マイクロサービスが別 AWS アカウント（分離ガバナンス）の場合、アカウント間ネットワークが複雑
複雑な依存関係管理	モノリス・マイクロサービス群の依存関係が複雑化。CI/CD パイプライン統合が困難
パフォーマンス低下	複数段階のルーティング・VPC ピアリング経由で latency 増加

Refactor Spaces が提供する解決策

✅ Strangler Fig インフラの自動化：Application・Service・Route の定義だけで API Gateway・VPC Lattice・Transit Gateway を自動構築
✅ 段階的トラフィック切り替え：Route の weight 調整で 0%→100% のトラフィック段階移行（Blue-Green デプロイメント相当）
✅ 複数アカウント統合：Transit Gateway で複数アカウント間のマイクロサービスを透過的に統合
✅ 本番環境での段階的検証：本番トラフィック 10% を新サービスに割り当てて検証、問題なければ 100% 切り替え
✅ 自動セキュリティグループ管理：VPC Lattice policies で service-to-service の接続制御を自動化
✅ Migration Hub との統合：リファクタリング進捗（モノリス → マイクロサービス抽出率）を Migration Hub で可視化

このサービスを選ぶ理由

なぜ AWS Migration Hub Refactor Spaces なのか？

Strangler Fig パターンの実装負担削減
- 従来：API Gateway・Lambda@Edge・VPC ピアリング・カスタムルーティングを手動構築 → 数か月の開発
- Refactor Spaces：Application・Service・Route を定義 → 自動構築・ルーティング規則自動適用 → 数日
本番トラフィック 0% リスクのロールアウト
- モノリス稼働中に新マイクロサービスをデプロイ
- Route weight = 0% で新サービスに誰もアクセスしない状態で検証
- weight = 10% → 50% → 100% と段階的に増加（問題発生時は weight = 0% で即座に切り戻し）
複数 AWS アカウント・複数リージョンのマイクロサービス統合
- Account A：モノリス（既存）
- Account B：Orders マイクロサービス
- Account C：Payments マイクロサービス
- これらを Refactor Spaces で透過的に統合（ネットワーク設定が自動）
API Gateway + Lambda + VPC の複雑な統合を自動化
- VPC Lambda は以前、VPC 内で実行すると Internet 接続ができず、複雑な NAT Gateway 構築が必須だった
- Refactor Spaces は VPC Lattice を使用して、VPC Lambda でも簡潔にモノリスと通信可能に
セキュリティ＆ガバナンス
- VPC Lattice policies で「Orders Service から Payments Service のみアクセス可」といった細粒度制御が可能
- IAM + VPC Lattice で多層防御

このサービスを選ばない理由

単純な Replatform：Java EE → ECS など、モノリス丸ごと移行する場合は不要（MGN + Refactor Spaces 両方は過剰）
サーバーレス優先：既に全てを Lambda で実装する場合は API Gateway だけで十分
機能抽出がない：モノリスを維持する場合（Retain 戦略）は不要

Strangler Fig パターンの解説

Strangler Fig パターンの由来

ストラングラーフィグ（Strangler Fig）は、インドボダイジュの木に寄生してゆっくり根を張り、やがて元の木を完全に包み込む植物。ソフトウェア開発でこれに例えて、モノリスを段階的に新しいマイクロサービスで「包み込む」 イメージ。

初期状態（Year 1）:
┌─────────────────────────┐
│  Monolithic App         │
│  ├─ Orders Logic        │
│  ├─ Inventory Logic     │
│  ├─ Payments Logic      │
│  └─ Customer Logic      │
└─────────────────────────┘

中間段階（Year 2）:
┌──────────────────────────┐
│   API Gateway / Proxy    │  ← 新ルーティングレイヤー
├──────────────────────────┤
│                          │
│  ┌─────────────────────┐ │
│  │ Monolith (縮小)     │ │
│  │ ├─ Orders Logic     │ ← 既に抽出済み
│  │ ├─ Inventory Logic  │
│  │ └─ Customer Logic   │
│  └─────────────────────┘ │
│                          │
│  ┌─────────────────┐ ┌──────────────┐ │
│  │ Orders Service  │ │ Payments Svc │ │  ← 新マイクロサービス
│  │ (Lambda)        │ │ (Lambda)     │ │
│  └─────────────────┘ └──────────────┘ │
│                          │
└──────────────────────────┘

最終状態（Year 3）:
┌──────────────────────────┐
│   API Gateway / Mesh     │
├──────────────────────────┤
│ ┌────────────┐            │
│ │ Orders Svc │            │
│ │ (Lambda)   │            │
│ └────────────┘            │
│ ┌────────────┐            │
│ │ Inventory  │            │
│ │ (ECS)      │            │
│ └────────────┘            │
│ ┌────────────┐            │
│ │ Payments   │            │
│ │ (Lambda)   │            │
│ └────────────┘            │
│ ┌────────────┐            │
│ │ Customers  │            │
│ │ (ECS)      │            │
│ └────────────┘            │
│                          │
└──────────────────────────┘
Monolith は完全廃止

Refactor Spaces の実装方式

Strangler Tower パターン（Refactor Spaces が実装）

┌─────────────────────────────────────────────────┐
│  Layer 0: 公開インターフェース（API Gateway）  │
│  URL: https://app.example.com/api/*            │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼─────────────────────────────┐
│  Layer 1: トラフィック分割（Route Rules）       │
│  ├─ /api/orders/* → Orders Service（weight 90%）│
│  ├─ /api/orders/* → Monolith（weight 10%）      │
│  ├─ /api/payments/* → Payments Service（100%）  │
│  └─ /* → Monolith（Fallback）                   │
└────────────────────┬─────────────────────────────┘
                     │
┌────────────────────▼─────────────────────────────┐
│  Layer 2: ネットワーク接続（VPC Lattice）      │
│  ├─ Orders Service (Lambda, ap-northeast-1)    │
│  ├─ Payments Service (ECS, ap-northeast-1)    │
│  ├─ Inventory Service (EC2, us-east-1)        │
│  └─ Monolith (On-Premises / EC2 Classic)     │
└────────────────────┬─────────────────────────────┘
                     │
┌────────────────────▼──────────────────────────────┐
│  Layer 3: セキュリティ（VPC Lattice Policies）  │
│  ├─ Orders Service → Payments Service: Allow    │
│  ├─ Orders Service → Inventory Service: Allow   │
│  └─ Monolith → *: Allow (フォールバック)        │
└──────────────────────────────────────────────────┘

アーキテクチャと設計原則

全体構成図（Mermaid 1）

graph TB
    subgraph Client["Client Layer"]
        WEB["Web Browser<br/>(https://app.example.com)"]
        MOBILE["Mobile App<br/>(SDK Client)"]
    end
    
    subgraph PublicLayer["Public Interface"]
        APIGW["API Gateway<br/>(Regional / Edge-optimized)<br/>Port 443"]
    end
    
    subgraph RoutingLayer["Routing & Traffic Splitting"]
        ROUTE["Refactor Spaces Routes<br/>Strangler Fig Pattern"]
        WEIGHT["Traffic Weight Management<br/>0% → 100%"]
    end
    
    subgraph NetworkLayer["Network Fabric"]
        LATTICE["VPC Lattice<br/>(Layer 7 Service Mesh)"]
        PEERING["VPC Peering<br/>(Account A-B-C)"]
        TGW["Transit Gateway<br/>(Multi-Region)"]
    end
    
    subgraph ServiceLayer["Service Layer"]
        MONOLITH["Monolith Service<br/>(Existing Application)<br/>Orders + Inventory + Payments"]
        ORDERS["Orders Microservice<br/>(Lambda / ECS)"]
        PAYMENTS["Payments Microservice<br/>(Lambda / RDS)"]
        INVENTORY["Inventory Microservice<br/>(ECS / Aurora)"]
    end
    
    subgraph DataLayer["Data Layer"]
        RDSM["RDS Monolith<br/>(MySQL 100GB)"]
        RDSO["RDS Orders<br/>(PostgreSQL)"]
        RDSP["RDS Payments<br/>(PostgreSQL)"]
        RDSI["Aurora Inventory<br/>(MySQL)"]
    end
    
    subgraph Monitoring["Monitoring & Control"]
        CW["CloudWatch Metrics<br/>(Route Latency / Error Rate)"]
        MH["Migration Hub<br/>(Refactor Progress)"]
    end
    
    WEB -->|HTTPS| APIGW
    MOBILE -->|HTTPS| APIGW
    APIGW -->|Route /api/orders/*| ROUTE
    APIGW -->|Route /api/payments/*| ROUTE
    APIGW -->|Route /*| ROUTE
    
    ROUTE -->|weight 90%| ORDERS
    ROUTE -->|weight 10%| MONOLITH
    ROUTE -->|weight 100%| PAYMENTS
    ROUTE -->|Fallback| MONOLITH
    
    ORDERS -->|Service Mesh| LATTICE
    PAYMENTS -->|Service Mesh| LATTICE
    INVENTORY -->|Service Mesh| LATTICE
    MONOLITH -->|Service Mesh| LATTICE
    
    LATTICE -->|VPC Peering| PEERING
    PEERING -->|Multi-Account| TGW
    
    ORDERS -->|Read/Write| RDSO
    PAYMENTS -->|Read/Write| RDSP
    INVENTORY -->|Read/Write| RDSI
    MONOLITH -->|Read/Write| RDSM
    
    ROUTE -->|Metrics| CW
    ORDERS -->|Progress| MH
    PAYMENTS -->|Progress| MH
    INVENTORY -->|Progress| MH

Environment・Application・Service の階層構造

Refactor Spaces Environment（全体）
├─ Transit Gateway / VPC Lattice（ネットワークファブリック）
├─ Security Configuration（VPC Lattice Policies）
│
└─ Application 1: "E-commerce Refactoring"
    ├─ Service: "Monolith" (URL: http://monolith.internal:8080)
    ├─ Service: "Orders" (Lambda ARN)
    ├─ Service: "Payments" (Lambda ARN)
    ├─ Service: "Inventory" (ECS Task Definition)
    │
    └─ Routes:
        ├─ /api/orders/* → Orders (weight 90%), Monolith (weight 10%)
        ├─ /api/payments/* → Payments (weight 100%)
        ├─ /api/inventory/* → Inventory (weight 100%)
        └─ /* → Monolith (Fallback)

└─ Application 2: "SAP Modularization"
    ├─ Service: "SAP Monolith" (EC2 on-premises)
    ├─ Service: "Finance" (ECS)
    ├─ Service: "HR" (Lambda)
    │
    └─ Routes:
        ├─ /api/finance/* → Finance (weight 100%)
        └─ /* → SAP Monolith (Fallback)

コアコンポーネント

1. Environment（環境）

役割：Refactor Spaces の基盤となるネットワークファブリック

属性	説明
Network Fabric Type	TRANSIT_GATEWAY / API_GATEWAY（選択肢による）
VPC Integration	複数 VPC を Transit Gateway or VPC Lattice で自動接続
Multi-Account	複数 AWS アカウントの自動接続サポート
IAM Permissions	Application・Service・Route の作成権限を個別制御

2. Application（アプリケーション）

役割：モノリス + マイクロサービス群を論理的に統合

# Application の定義要素：
- Name: "E-commerce Refactoring"
- Description: "Strangler Fig for Orders Service extraction"
- Environment: Environment-ID
- Proxy Type: API_GATEWAY or ALB
- Network Configuration:
  - VPC: vpc-xxx（モノリスが存在する VPC）
  - Subnet: subnet-yyy, subnet-zzz（複数可）
  - Security Group: sg-abc

3. Service（サービス）

役割：モノリス or マイクロサービスの登録

Service Type 1: Monolith（既存アプリケーション）

# HTTP URL based（オンプレ・EC2）
Service Type: URL_ENDPOINT
Endpoint URL: http://monolith-nlb.internal:8080
VPC: vpc-monolith
Port: 8080 (HTTP) or 443 (HTTPS)

Service Type 2: Lambda（新マイクロサービス）

# Serverless function based
Service Type: LAMBDA
Lambda Function ARN: arn:aws:lambda:ap-northeast-1:xxx:function:orders-service
# Refactor Spaces が自動的に Lambda を VPC Lattice 経由で expose

Service Type 3: ECS（新マイクロサービス）

# Container-based
Service Type: ECS
ECS Cluster: arn:aws:ecs:ap-northeast-1:xxx:cluster/payments
ECS Service: payments-service
# Refactor Spaces が自動的に ECS を VPC Lattice 経由で expose

Service Type 4: EC2（新マイクロサービス）

# EC2 instance
Service Type: EC2
Target Group ARN: arn:aws:elasticloadbalancing:...:targetgroup/inventory
# ALB target group 経由で expose

4. Route（ルーティングルール）

役割：HTTP path（URI）に基づいたトラフィック分割

# Route 定義例：
Route Name: "Orders Route - Strangler Phase 1"
Source Path: /api/orders  # マッチ対象パス
Include Child Paths: true  # /api/orders/*, /api/orders/123 も対象
Methods: [GET, POST, PUT, DELETE]  # HTTP メソッド
Activation State: ACTIVE  # or INACTIVE（テスト用）

# トラフィック分割設定：
Service Destinations:
  - Orders Service (Lambda)     : weight 90%
  - Monolith Service (HTTP)     : weight 10%

# Canary Deployment 例：
  Day 1: Orders 10%, Monolith 90%
  Day 3: Orders 50%, Monolith 50%
  Day 5: Orders 90%, Monolith 10%
  Day 7: Orders 100%, Monolith 0%

5. VPC Lattice Policies（セキュリティ）

役割：Service-to-Service 接続制御

# Refactor Spaces が自動適用する Policy 例：

Orders Service from Monolith:
  - Allow Monolith Service → Orders Service (API calls)
  - Allow Monolith Service → Orders DB

Orders Service to Payments:
  - Allow Orders Service → Payments Service (dependency)

API Gateway to Services:
  - Allow API Gateway → All Services (traffic dispatch)

主要ユースケース

1. E-commerce モノリスからの機能抽出

シナリオ：Java モノリシック e-commerce アプリ（Tomcat 8.0、MySQL 100GB）を段階的にマイクロサービスに分解

移行ステップ：

Phase 1 (Month 1-2): Orders Service 抽出
┌─────────────────────────────────────────┐
│  API Gateway                            │
│  ├─ /api/orders/* → Orders (Lambda 10%) │  ← 新デプロイ
│  └─ /api/orders/* → Monolith (90%)      │  ← 既存
└─────────────────────────────────────────┘
進捗: Orders Service 本番テスト

Phase 2 (Month 2-3): Payments Service 抽出
┌─────────────────────────────────────────┐
│  API Gateway                            │
│  ├─ /api/orders/* → Orders (100%)       │  ← 完了
│  ├─ /api/payments/* → Payments (50%)    │  ← 新デプロイ
│  └─ /api/payments/* → Monolith (50%)    │  ← 既存
└─────────────────────────────────────────┘
進捗: Payments Service ロールアウト中

Phase 3 (Month 3-4): Inventory Service 抽出
┌─────────────────────────────────────────┐
│  API Gateway                            │
│  ├─ /api/orders/* → Orders (100%)       │  ← 完了
│  ├─ /api/payments/* → Payments (100%)   │  ← 完了
│  ├─ /api/inventory/* → Inventory (100%) │  ← 新デプロイ
│  └─ /* → Monolith (Fallback only)      │  ← 機能削減
└─────────────────────────────────────────┘
進捗: Monolith は基本機能のみ

Benefits：

段階的な本番検証で失敗リスク最小化
Orders 10% → 100% の canary deployment で問題を事前検出
Monolith への依存度が減少（リファクタリング加速）

2. マイクロサービス統合（複数 AWS アカウント）

シナリオ：複数の独立した AWS アカウント（組織単位・チーム単位）でマイクロサービスを開発・デプロイ

アーキテクチャ：

Account A（API Gateway / Proxy Account）
├─ API Gateway: api.example.com
└─ Refactor Spaces Environment
   ├─ Application: Platform
   └─ Routes:
      ├─ /api/orders/* → Account B (Orders Service)
      ├─ /api/payments/* → Account C (Payments Service)
      ├─ /api/inventory/* → Account D (Inventory Service)
      └─ /* → Account E (Fallback - Monolith / Platform Core)

Account B（Payments チーム）
├─ Lambda: payments-service
├─ RDS: Payments DB
└─ VPC Lattice Service: payments (Account A から参照可能)

Account C（Orders チーム）
├─ ECS: orders-service
├─ Aurora: Orders DB
└─ VPC Lattice Service: orders (Account A から参照可能)

Account D（Inventory チーム）
├─ ECS: inventory-service
├─ Aurora: Inventory DB
└─ VPC Lattice Service: inventory (Account A から参照可能)

Account E（Platform / Monolith チーム）
├─ EC2 Instance: Monolith App
├─ RDS: Monolith DB
└─ VPC Lattice Service: platform-core (Account A から参照可能)

接続：Account A → Transit Gateway → Account B/C/D/E
      VPC Lattice が service-to-service 通信を自動管理

Benefits：

チーム独立性の確保（各アカウント自主管理）
統一 API Gateway（Account A）で Public インターフェース統一
Service-to-Service 通信の自動管理（ネットワーク設定不要）

3. Legacy .NET Framework → ECS Containerization

シナリオ：Windows Server 2012 R2 上の ASP.NET Framework アプリを ECS on Fargate に段階移行

移行パターン：

Phase 1: Strangler Service Deployment
┌──────────────────────────────────────────┐
│  API Gateway                             │
│  ├─ /api/v2/* → ECS/Fargate (50%)       │ ← .NET Core image
│  └─ /api/v2/* → Windows Server (50%)    │ ← 既存
└──────────────────────────────────────────┘

Phase 2: Gradual Migration
┌──────────────────────────────────────────┐
│  API Gateway                             │
│  ├─ /api/v2/* → ECS/Fargate (100%)      │ ← 移行完了
│  └─ /* → Windows Server (Fallback)      │ ← 他機能のみ
└──────────────────────────────────────────┘

Phase 3: Complete Sunset
- Windows Server インスタンス廃止
- ECS/Fargate が全リクエスト処理

Benefits：

Windows Server ライセンスコスト削減（ECS Fargate は時間課金）
自動スケーリング（固定 VM → オンデマンド）
CI/CD 統合（Container Registry 経由での自動デプロイ）

4. Oracle → Serverless Modularization

シナリオ：オンプレミス Oracle ベースシステム（複数アプリケーション統合）を AWS Serverless に分解

抽出順序：

Reports Engine（Lambda + S3）
Batch Processing（Step Functions + Lambda）
API Proxy（API Gateway + Lambda）
Customer Portal（CloudFront + S3 + Lambda）

トラフィック移行：

Week 1-2: Reports
┌─────────────────────────────┐
│ /api/reports/* → Lambda 10% │
│ /api/reports/* → Oracle 90% │
└─────────────────────────────┘

Week 3-4: Reports 100%
┌─────────────────────────────┐
│ /api/reports/* → Lambda 100%│
│ /api/batch/* → Lambda 10%   │
│ /api/batch/* → Oracle 90%   │
└─────────────────────────────┘

... (以降同様)

最終：Oracle は Read-only reference のみ

設定・操作の具体例

CLI ベースの操作

1. Environment の作成

# Refactor Spaces Environment セットアップ
aws refactor-spaces create-environment \
  --name "ecommerce-refactoring-prod" \
  --description "E-commerce monolith to microservices" \
  --network-fabric-type TRANSIT_GATEWAY \
  --region ap-northeast-1

# 出力例：
# {
#   "environment": {
#     "EnvironmentId": "env-abc12345",
#     "Name": "ecommerce-refactoring-prod",
#     "Status": "CREATING",
#     "NetworkFabricType": "TRANSIT_GATEWAY"
#   }
# }

# Status が ACTIVE になるまで待機（~3 分）
aws refactor-spaces wait environment-available \
  --environment-id env-abc12345 \
  --region ap-northeast-1

2. Application の作成

# API Gateway ベースの Application
aws refactor-spaces create-application \
  --name "ecommerce-platform" \
  --environment-id env-abc12345 \
  --proxy-type API_GATEWAY \
  --vpc-id vpc-monolith \
  --api-gateway-proxy '{
    "endpointType": "REGIONAL",
    "stageName": "prod"
  }' \
  --region ap-northeast-1

# 出力：
# {
#   "application": {
#     "ApplicationId": "app-def67890",
#     "EnvironmentId": "env-abc12345",
#     "ProxyType": "API_GATEWAY",
#     "ApiGatewayProxy": {
#       "ApiGatewayId": "abc123xyz",
#       "EndpointType": "REGIONAL"
#     },
#     "Status": "ACTIVE"
#   }
# }

3. Service の作成（Monolith）

# 既存モノリシック アプリケーション
aws refactor-spaces create-service \
  --name "monolith-legacy" \
  --application-id app-def67890 \
  --environment-id env-abc12345 \
  --endpoint-type URL \
  --url-endpoint '{
    "url": "http://monolith-nlb-prod.ap-northeast-1.elb.amazonaws.com"
  }' \
  --vpc-id vpc-monolith \
  --region ap-northeast-1

# 出力例：
# {
#   "service": {
#     "ServiceId": "svc-monolith-001",
#     "Name": "monolith-legacy",
#     "EndpointType": "URL",
#     "UrlEndpoint": {
#       "Url": "http://monolith-nlb-prod..."
#     },
#     "Status": "ACTIVE"
#   }
# }

4. Service の作成（Lambda マイクロサービス）

# 新しい Orders Lambda Service
aws refactor-spaces create-service \
  --name "orders-service" \
  --application-id app-def67890 \
  --environment-id env-abc12345 \
  --endpoint-type LAMBDA \
  --lambda-endpoint '{
    "arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:orders-service-handler"
  }' \
  --vpc-id vpc-microservices \
  --region ap-northeast-1

# 出力例：
# {
#   "service": {
#     "ServiceId": "svc-orders-001",
#     "Name": "orders-service",
#     "EndpointType": "LAMBDA",
#     "LambdaEndpoint": {
#       "Arn": "arn:aws:lambda:..."
#     },
#     "Status": "ACTIVE"
#   }
# }

5. Service の作成（ECS マイクロサービス）

# 新しい Payments ECS Service
aws refactor-spaces create-service \
  --name "payments-service" \
  --application-id app-def67890 \
  --environment-id env-abc12345 \
  --endpoint-type ECS \
  --ecs-endpoint '{
    "clusterArn": "arn:aws:ecs:ap-northeast-1:123456789012:cluster/payments",
    "serviceArn": "arn:aws:ecs:ap-northeast-1:123456789012:service/payments/payments-service"
  }' \
  --region ap-northeast-1

# 出力例：
# {
#   "service": {
#     "ServiceId": "svc-payments-001",
#     "Name": "payments-service",
#     "EndpointType": "ECS",
#     "Status": "ACTIVE"
#   }
# }

6. Route の作成（Strangler Fig ルーティング）

# /api/orders/* を Orders Service と Monolith で分割
aws refactor-spaces create-route \
  --application-id app-def67890 \
  --environment-id env-abc12345 \
  --service-id svc-orders-001 \
  --route-type URI_PATH \
  --uri-path-route '{
    "sourcePath": "/api/orders",
    "activationState": "ACTIVE",
    "methods": ["GET", "POST", "PUT", "DELETE"],
    "includeChildPaths": true
  }' \
  --region ap-northeast-1

# 出力例：
# {
#   "route": {
#     "RouteId": "route-orders-001",
#     "SourcePath": "/api/orders",
#     "ActivationState": "ACTIVE",
#     "ServiceId": "svc-orders-001",
#     "Type": "URI_PATH"
#   }
# }

# トラフィック分割設定（2 つの Service 間）
aws refactor-spaces put-route-service-destinations \
  --application-id app-def67890 \
  --environment-id env-abc12345 \
  --route-id route-orders-001 \
  --service-destinations '[
    {
      "ServiceId": "svc-orders-001",
      "Weight": 90
    },
    {
      "ServiceId": "svc-monolith-001",
      "Weight": 10
    }
  ]' \
  --region ap-northeast-1

7. Weight 調整（Canary Deployment）

# Day 1: Orders 10%
aws refactor-spaces put-route-service-destinations \
  --application-id app-def67890 \
  --environment-id env-abc12345 \
  --route-id route-orders-001 \
  --service-destinations '[
    {"ServiceId": "svc-orders-001", "Weight": 10},
    {"ServiceId": "svc-monolith-001", "Weight": 90}
  ]' \
  --region ap-northeast-1

# Day 3: Orders 50%
aws refactor-spaces put-route-service-destinations \
  --application-id app-def67890 \
  --environment-id env-abc12345 \
  --route-id route-orders-001 \
  --service-destinations '[
    {"ServiceId": "svc-orders-001", "Weight": 50},
    {"ServiceId": "svc-monolith-001", "Weight": 50}
  ]' \
  --region ap-northeast-1

# Day 7: Orders 100%
aws refactor-spaces put-route-service-destinations \
  --application-id app-def67890 \
  --environment-id env-abc12345 \
  --route-id route-orders-001 \
  --service-destinations '[
    {"ServiceId": "svc-orders-001", "Weight": 100}
  ]' \
  --region ap-northeast-1

SDK ベースの操作（Python）

import boto3
import time

client = boto3.client('refactor-spaces', region_name='ap-northeast-1')

# Environment 作成から Route weight 調整まで

def create_strangler_environment(app_name):
    # 1. Environment 作成
    env_response = client.create_environment(
        Name=f"{app_name}-refactoring",
        Description=f"Strangler Fig pattern for {app_name}",
        NetworkFabricType='TRANSIT_GATEWAY'
    )
    env_id = env_response['Environment']['EnvironmentId']
    print(f"Created Environment: {env_id}")
    
    # Environment が ACTIVE になるまで待機
    time.sleep(180)  # ~3 分
    
    # 2. Application 作成
    app_response = client.create_application(
        Name=app_name,
        EnvironmentId=env_id,
        ProxyType='API_GATEWAY',
        VpcId='vpc-monolith',
        ApiGatewayProxy={'EndpointType': 'REGIONAL', 'StageName': 'prod'}
    )
    app_id = app_response['Application']['ApplicationId']
    print(f"Created Application: {app_id}")
    
    # 3. Monolith Service 作成
    monolith_svc = client.create_service(
        Name='monolith',
        ApplicationId=app_id,
        EnvironmentId=env_id,
        EndpointType='URL',
        UrlEndpoint={'Url': 'http://monolith-nlb.internal:8080'},
        VpcId='vpc-monolith'
    )
    monolith_svc_id = monolith_svc['Service']['ServiceId']
    print(f"Created Monolith Service: {monolith_svc_id}")
    
    # 4. Orders Lambda Service 作成
    orders_svc = client.create_service(
        Name='orders-service',
        ApplicationId=app_id,
        EnvironmentId=env_id,
        EndpointType='LAMBDA',
        LambdaEndpoint={'Arn': 'arn:aws:lambda:ap-northeast-1:123456789012:function:orders'},
        VpcId='vpc-microservices'
    )
    orders_svc_id = orders_svc['Service']['ServiceId']
    print(f"Created Orders Service: {orders_svc_id}")
    
    # 5. Route 作成
    route_response = client.create_route(
        ApplicationId=app_id,
        EnvironmentId=env_id,
        ServiceId=orders_svc_id,
        RouteType='URI_PATH',
        UriPathRoute={
            'SourcePath': '/api/orders',
            'Methods': ['GET', 'POST', 'PUT', 'DELETE'],
            'IncludeChildPaths': True,
            'ActivationState': 'ACTIVE'
        }
    )
    route_id = route_response['Route']['RouteId']
    print(f"Created Route: {route_id}")
    
    # 6. Canary Deployment: トラフィック段階移行
    weights = [
        (10, 90),  # Day 1: Orders 10%, Monolith 90%
        (30, 70),  # Day 2
        (50, 50),  # Day 3
        (70, 30),  # Day 4
        (90, 10),  # Day 5
        (100, 0)   # Day 6: Orders 100%
    ]
    
    for orders_pct, monolith_pct in weights:
        print(f"\nAdjusting weight: Orders {orders_pct}%, Monolith {monolith_pct}%")
        client.put_route_service_destinations(
            ApplicationId=app_id,
            EnvironmentId=env_id,
            RouteId=route_id,
            ServiceDestinations=[
                {'ServiceId': orders_svc_id, 'Weight': orders_pct},
                {'ServiceId': monolith_svc_id, 'Weight': monolith_pct}
            ]
        )
        time.sleep(86400)  # 1 日待機
    
    print(f"\nStrangler Fig migration complete!")
    print(f"Orders Service now handles 100% of traffic")
    
    return env_id, app_id, route_id

if __name__ == "__main__":
    env_id, app_id, route_id = create_strangler_environment("ecommerce")

類似サービス比較表

項目	Refactor Spaces	Istio Strangler	AWS App Mesh	Linkerd	Consul Service Mesh
用途	Monolith → Microservices 段階移行	Kubernetes 内のトラフィック管理	AWS Service Mesh（Envoy）	Kubernetes 軽量 Mesh	Multi-cloud Service Mesh
インフラ要件	VPC / VPC Lattice	Kubernetes cluster	ECS / EKS	Kubernetes	Any (Consul + Envoy)
トラフィック分割	✅ Canary deploy（weight %）	✅ Virtual services	✅ Traffic policy	✅ Traffic split	✅ Intentions
マルチアカウント	✅ Transit Gateway 統合	❌ Kubernetes cluster 限定	✅ ECS/EKS cluster 統合	❌ K8s cluster 限定	✅ Consul federation
Monolith 対応	✅ URL endpoint で直接統合	❌ Sidecar injection 必須	⚠️ EC2 launch type	❌ Sidecar 必須	✅ REST API
セキュリティ	VPC Lattice Policies（IAM）	mTLS + Authorization Policy	IAM policy + traffic policy	mTLS + Authz	mTLS + Intentions
ダッシュボード	⚠️ CloudWatch Metrics	❌ 別途 Kiali 必要	CloudWatch + X-Ray	❌ 別途 Prometheus+Grafana	Consul UI
学習曲線	★ (Low - AWS ネイティブ)	★★★ (High - K8s 専門知識)	★★ (Medium)	★★ (Medium)	★★★ (High)
価格	AWS service 費用に含む	無料（OSS）	EC2 / ECS / EKS 料金に含む	無料（OSS）	無料（OSS） or Enterprise

ベストプラクティス

1. Route 設計の戦略

✅ 推奨：

機能単位でルートを定義（/api/orders, /api/payments など）
各ルートで段階的な weight 調整（10% → 50% → 100%）
Include Child Paths = true で関連 URI も自動対応

❌ アンチパターン：

1 つの super route で全トラフィック処理（/*）
weight を 0% に固定（テストできない）
ルート作成後に API 変更（大幅な修正が必要）

2. Service Endpoint の選択

✅ 推奨：

新マイクロサービス：Lambda / ECS（serverless / managed）
既存 Monolith：NLB / ALB endpoint（最小限の変更）
複数アカウント service：VPC Lattice service name（自動 DNS）

❌ アンチパターン：

全 service を Lambda で実装（不要な複雑性）
EC2 bare instance をエンドポイントにする（スケーラビリティ欠如）

3. Canary Deployment スケジュール

✅ 推奨：

Day 1: 10% new service
  └─ metrics 確認、エラー率が baseline 以下か確認
  
Day 2-3: 25-50% new service
  └─ load test、latency 確認
  
Day 4-5: 50-75% new service
  └─ customer-facing load（real traffic）で検証
  
Day 6: 90% new service
  └─ 最終検証、問題なければ Day 7 に 100%

Day 7: 100% new service
  └─ monolith route は削除or fallback のみ

❌ アンチパターン：

初日に 100% 切り替え（カナリアの意味がない）
固定日時ではなく metrics 閾値ベース移行（組織体制不整備）

4. Multi-Account Architecture

✅ 推奨：

Account A：API Gateway / Proxy（public interface）
Account B/C/D：各マイクロサービスチーム（独立した service account）
Transit Gateway：Account A ↔ B/C/D を接続

❌ アンチパターン：

全 services を同一 Account で実装（scaling 困難、ガバナンス複雑）
Account 間に VPC peering を一対一設定（管理コスト高）

5. Database Strategy

✅ 推奨：

各マイクロサービスが専用 DB を保有（polyglot persistence）
Monolith は legacy DB のまま（互換性維持）
Service-to-service DB sync：messaging (SQS/SNS) または CDC

❌ アンチパターン：

全 services が同一 monolith DB にアクセス（distributed transaction 問題）
Strangler service が monolith DB にアクセス（依存性が残る）

トラブルシューティング表

症状	原因	対応
Route トラフィックが新 service に流れない	weight = 0% or ActivationState = INACTIVE	weight % を確認、ActivationState を ACTIVE に変更
Lambda service が endpoint として認識されない	Lambda execution role に VPC Lattice 権限なし	Lambda role に `refactor-spaces:InvokeEndpoint` 権限追加
Service-to-service 通信が DNS 解決できない	VPC Lattice policy が restrictive	VPC Lattice Policies で接続許可を追加
API Gateway → service latency が高い	VPC Lattice routing overhead / Network NAT	CloudWatch metrics で latency ボトルネック確認。NLB を挿入して最適化
Weight 調整後、トラフィック分割が反映されない	Route cache / API Gateway キャッシュ	CloudFront キャッシュ無効化 + API Gateway stage キャッシュ削除
Environment 作成に失敗（ネットワーク設定）	VPC 不在 / セキュリティグループ権限不足	VPC / Subnet / Security Group を事前作成。Transit Gateway をあらかじめ用意
Lambda service が VPC 内で実行されていない	Lambda を VPC 内で実行するが ENI attach に時間	cold start（初回呼び出し）に 10-30 秒かかることを容認。Provisioned Concurrency で対応

2025-2026 最新動向

1. VPC Lattice統合（GA 2025 年 Q1）

詳細：

AWS Migration Hub Refactor Spaces が VPC Lattice を基盤に完全統合
より低遅延・高スループット（Refactor Spaces 専用リソース廃止）
複数リージョン・複数アカウント対応の強化

2. AI-based Canary Deployment（2025 年下半期予定）

計画：

CloudWatch Metrics を自動分析して weight 調整を推奨
エラー率・latency 異常を検知して自動 weight 調整（rollback）
ML による最適ロールアウトスケジュール提案

3. Kubernetes 統合（2026 年検討）

可能性：

EKS with Refactor Spaces（service mesh との統合）
Istio VirtualService と同じ weight 管理

学習リソース・参考文献

公式ドキュメント

リソース	URL
Refactor Spaces User Guide	https://docs.aws.amazon.com/migration-hub-refactor-spaces/latest/userguide/
Refactor Spaces API Reference	https://docs.aws.amazon.com/migration-hub-refactor-spaces/latest/APIReference/
VPC Lattice User Guide	https://docs.aws.amazon.com/vpc-lattice/latest/userguide/
Strangler Fig Pattern	https://martinfowler.com/bliki/StranglerFigApplication.html

AWS 公開トレーニング

リソース	説明
Modernizing Applications with AWS Refactor Spaces	AWS Training（ウェビナー）
VPC Lattice for Microservices	AWS Immersion Day

実装例・チェックリスト

Strangler Fig 実装チェックリスト

準備フェーズ

[ ] Monolith の依存関係マップ（Application Dependency Mapping）
[ ] 抽出順序の決定（ビジネス価値・技術難易度・依存関係）
[ ] 各マイクロサービスのチーム割り当て
[ ] Network / VPC / VPC Lattice 事前構成

Phase 1: Service 1 抽出

[ ] Service 1 コード実装（Lambda or ECS）
[ ] Service 1 を Refactor Spaces に登録
[ ] Route /api/service1/* 作成（weight 0%）
[ ] Internal test（weight 0% での動作確認）
[ ] Weight 10% → Canary deploy 開始

Phase 2: Service 1 移行監視

[ ] CloudWatch metrics 監視（error rate、latency、throughput）
[ ] Business metrics 監視（conversion rate、transaction count）
[ ] Alert 設定（エラー率 > 1% で pagerduty 通知）
[ ] Weight 段階調整（10% → 30% → 50% → 100%）

Phase 3: Service 1 完了

[ ] Weight = 100% 確認
[ ] Monolith route 削除
[ ] Service 1 DB migration（必要に応じて）
[ ] Service 1 cost analysis

Phase 4-N: Service 2, 3, … 抽出

[ ] Service 2-N について Phase 1-3 を繰り返す

完了フェーズ

[ ] Monolith 最小化（基本機能のみ残す）
[ ] Monolith sunset（廃止スケジュール）
[ ] Cost optimization review
[ ] Lessons learned ドキュメント

まとめ

AWS Migration Hub Refactor Spaces は「Strangler Fig パターンを AWS インフラで自動実装し、モノリシックアプリケーションをゼロダウンタイムで段階的にマイクロサービスに分解するサービス」である。

主な価値

Strangler Fig インフラの自動化：API Gateway・VPC Lattice・Transit Gateway を自動構築
段階的トラフィック切り替え：weight ベースの canary deployment で失敗リスク最小化
本番環境での検証：実トラフィック 10% で新サービス検証後、段階拡大
複数アカウント統合：Transit Gateway で複数アカウントの service を透過的に統合
ビジネス継続性：Monolith を稼働させたまま機能抽出（メンテナンス不要）

注意点

ネットワーク複雑性：VPC・VPC Lattice・Transit Gateway の理解が必須
Database 同期：各マイクロサービス専用 DB 化には CDC・messaging の設計が必要
Team scaling：各チームの独立性と統合のバランス取り（組織体制整備が重要）

適用判定

✅ 使うべき：

Monolith を段階的にマイクロサービスに分解（Big Bang refactoring を避けたい）
複数チームによる開発（各チームが独立 service を所有）
本番環境での段階的検証が必須（downtime ゼロ要件）

❌ 不要：

Monolith 丸ごと移行（Replatform）
既に microservices architecture（Service 追加は不要）
Network 複雑性を避けたい（シンプルな環境を維持）

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

目次

AWS Migration Hub Refactor Spaces 完全ガイド v2.0（2026年最新対応）

Strangler Fig パターン自動化・モノリス → マイクロサービス段階移行・ゼロダウンタイム

目次

ドキュメントメタデータ

概要と課題

本質

従来の課題

Refactor Spaces が提供する解決策

このサービスを選ぶ理由

なぜ AWS Migration Hub Refactor Spaces なのか？

このサービスを選ばない理由

Strangler Fig パターンの解説

Strangler Fig パターンの由来

Refactor Spaces の実装方式

アーキテクチャと設計原則

全体構成図（Mermaid 1）

Environment・Application・Service の階層構造

コアコンポーネント

1. Environment（環境）

2. Application（アプリケーション）

3. Service（サービス）

Service Type 1: Monolith（既存アプリケーション）

Service Type 2: Lambda（新マイクロサービス）

Service Type 3: ECS（新マイクロサービス）

Service Type 4: EC2（新マイクロサービス）

4. Route（ルーティングルール）

5. VPC Lattice Policies（セキュリティ）

主要ユースケース

1. E-commerce モノリスからの機能抽出

2. マイクロサービス統合（複数 AWS アカウント）

3. Legacy .NET Framework → ECS Containerization

4. Oracle → Serverless Modularization

設定・操作の具体例

CLI ベースの操作

1. Environment の作成

2. Application の作成

3. Service の作成（Monolith）

4. Service の作成（Lambda マイクロサービス）

5. Service の作成（ECS マイクロサービス）

6. Route の作成（Strangler Fig ルーティング）

7. Weight 調整（Canary Deployment）

SDK ベースの操作（Python）

類似サービス比較表

ベストプラクティス

1. Route 設計の戦略

2. Service Endpoint の選択

3. Canary Deployment スケジュール

4. Multi-Account Architecture

5. Database Strategy

トラブルシューティング表

2025-2026 最新動向

1. VPC Lattice統合（GA 2025 年 Q1）

2. AI-based Canary Deployment（2025 年下半期予定）

3. Kubernetes 統合（2026 年検討）

学習リソース・参考文献

公式ドキュメント

AWS 公開トレーニング

実装例・チェックリスト

Strangler Fig 実装チェックリスト

準備フェーズ

Phase 1: Service 1 抽出

Phase 2: Service 1 移行監視

Phase 3: Service 1 完了

Phase 4-N: Service 2, 3, … 抽出

完了フェーズ

まとめ

主な価値

注意点

適用判定