Implementing the Strangler Fig Pattern with AWS Migration Hub Refactor Spaces - Incremental Microservices Migration
Learn how to implement the strangler fig pattern with Refactor Spaces, control routing, and execute incremental migrations to microservices.
Refactor Spaces Overview
Refactor Spaces is a service that supports incremental migration from monolithic applications to microservices, managing up to 50 services and 100 routes. It automatically builds the infrastructure needed to implement the strangler fig pattern (API Gateway, NLB, Transit Gateway for inter-VPC connectivity) and enables feature-by-feature migration through URL path-based routing. It supports multi-account configurations and integrates with AWS Organizations to auto-discover accounts within the organization as environment members. When an environment is created, the network fabric (Transit Gateway) is automatically provisioned, eliminating the need to manually configure communication paths between services in different VPCs or accounts.
Implementing the Strangler Fig Pattern
When you create an environment, an API Gateway is built as a proxy, and all traffic is routed to the monolith. Once a new microservice is developed, you switch the route for the corresponding URL path (e.g., /api/orders) to the new service. The remaining paths continue to route to the monolith. You incrementally add routes, and once all paths have been migrated to new services, you decommission the monolith. If issues arise, simply deleting the route instantly reverts traffic back to the monolith. The advantage of this approach is that a single endpoint (the API Gateway URL) is maintained from the user's perspective, requiring no changes to the frontend or client applications. Migration is completed entirely through backend routing changes, and services continue without interruption throughout the migration period.
Routing and Multi-Account Support
Refactor Spaces routes consist of a default route (fallback to the monolith) and service routes (forwarding to microservices). URL path-based routing sends /api/orders to the new microservice while everything else goes to the monolith. In a multi-account configuration, you can place the monolith and microservices in different accounts to enforce security boundaries. Service endpoints support two types: Lambda functions and HTTP URLs (ALB or NLB endpoints). When targeting Lambda, serverless microservices can be directly integrated; when targeting HTTP URLs, containerized services running on ECS or EKS can be placed behind them. Adding a new microservice only requires creating a service and a route; Refactor Spaces automatically manages the API Gateway configuration changes. To learn migration strategies with Refactor Spaces comprehensively, check out technical books (Amazon).
Refactor Spaces Pricing and Limits
Refactor Spaces itself incurs no additional charges. Costs depend on the automatically provisioned resources: API Gateway, NLB, and Transit Gateway. API Gateway request pricing is the primary cost driver. Transit Gateway attachment and data processing charges also accumulate as the number of services grows in multi-account configurations. After migration is complete, decommissioning the monolith and deleting the Refactor Spaces environment also stops the proxy resource charges. As a limit, the maximum of 50 services and 100 routes per environment means that large-scale systems with hundreds of microservices must either split across multiple environments or plan a transition to directly managing API Gateway after migration completion.
Comparison with Other Migration Approaches
There are methods other than Refactor Spaces for implementing the strangler fig pattern. Manually building an API Gateway and managing routing rules yourself offers high customizability but incurs operational overhead for maintaining Transit Gateway and NLB configurations manually. Using ALB path-based routing to distribute traffic between monolith and microservices is suitable for single-VPC, single-account migrations but is not ideal for multi-account separation. Traffic splitting with Service Mesh (App Mesh) suits environments where containerization with ECS or EKS is already well underway, but has high adoption barriers when the monolith still runs on VMs. The value of Refactor Spaces lies in automating this infrastructure buildout, allowing migration teams to focus solely on adding and removing routes.
Migration Planning Best Practices
To succeed with incremental migration using Refactor Spaces, start by inventorying monolith functions at the API path level and begin migration from boundaries with minimal dependencies. The safest first migration target is a read-only API (e.g., GET on /api/products). APIs involving writes require careful transaction boundary design, considering Saga patterns or event-driven architectures to maintain data consistency between the monolith and microservices. For monitoring during migration, watch API Gateway latency metrics and 5xx error rates in CloudWatch, and prepare to immediately delete routes and revert to the monolith if anomalies are detected after a route switch. When combining with canary deployments, use API Gateway stage variables or header-based routing to send only a portion of traffic to the new service, further reducing risk.
Summary
Refactor Spaces automatically builds the infrastructure for the strangler fig pattern, supporting incremental migration from monoliths to microservices. URL path-based routing enables feature-by-feature migration, and multi-account configurations enforce security boundaries. Both Lambda and HTTP URL service endpoints are supported, and rollback during migration is achieved by simply deleting a route. Compared to other approaches, operational overhead is lower, providing an environment where migration teams can focus on application decomposition.