AWS Migration Hub Refactor Spaces is no longer open to new customers as of November 7, 2025. For capabilities similar to AWS Migration Hub Refactor Spaces, explore [AWS Transform](https://aws.amazon.com/transform).
# What is AWS Migration Hub Refactor Spaces?
AWS Migration Hub Refactor Spaces is the starting point for incremental application refactoring to microservices in AWS. Refactor Spaces helps reduce the undifferentiated heavy lifting of building and operating AWS infrastructure for incremental refactoring. You can use Refactor Spaces to help reduce risk when you develop applications into microservices or extend existing applications with new features written in microservices.
A Refactor Spaces environment provides the infrastructure, multi-account networking, and routing that you need to modernize incrementally. With Refactor Spaces environments, you can transparently add new services to an external HTTPS endpoint and incrementally route traffic to the new services. Refactor Spaces bridges networking across AWS accounts so that legacy and new services can communicate while they maintain the independence of separate accounts.
Refactor Spaces creates these resources in your account. This gives you the flexibility to apply your own configurations, like API Gateway custom domains, after Refactor Spaces creates them.
Refactor Spaces provides an application that models the Strangler Fig pattern for incremental refactoring. A Refactor Spaces application orchestrates Amazon API Gateway, Network Load Balancer, and resource-based AWS Identity and Access Management (IAM) policies so that you can transparently add new services to an external HTTP endpoint. For more information about the Strangler Fig pattern, see [Strangler Fig Application](https://martinfowler.com/bliki/StranglerFigApplication.html).
You can also incrementally route traffic to the new services. Refactor Spaces periodically resolves Domain Name System (DNS) names for these services. This keeps underlying architecture changes hidden from your application consumers.
**Topics**
+ [Are you a first-time Refactor Spaces user?](#first-time-user)
+ [Pricing](#pricing)
+ [Refactor Spaces concepts](welcome-concepts.md)
+ [How Refactor Spaces works](how-it-works.md)
## Are you a first-time Refactor Spaces user?
If you are a first-time user of Refactor Spaces, we recommend that you begin by reading the following sections:
+ [Refactor Spaces concepts](welcome-concepts.md)
+ [How Refactor Spaces works](how-it-works.md)
+ [Setting up](setting-up.md)
+ [Getting started with Refactor Spaces](getting-started.md)
## Pricing
All Refactor Spaces orchestrated resources (for example, Transit Gateway) are provisioned in your AWS account. Therefore, you pay for usage of Refactor Spaces plus any costs associated with provisioned resources. You are charged for Refactor Spaces usage based on the number of hours that you run your refactor environments and API requests to Refactor Spaces. For more information, see [AWS Migration Hub pricing](https://aws.amazon.com/migration-hub/pricing/).
# Refactor Spaces concepts
This section describes the key components that you can create and manage when using AWS Migration Hub Refactor Spaces.
**Topics**
+ [Environment](#welcome-concepts-environment)
+ [Applications](#welcome-concepts-application)
+ [Services](#welcome-concepts-service)
+ [Route](#welcome-concepts-route)
## Environment
The Refactor Spaces environment contains Refactor Spaces applications and services. The environment provides the infrastructure, multi-account networking, and routing that you need to modernize incrementally, along with a unified view of networking, applications, and services across multiple AWS accounts. Refactor Spaces also includes a multi-account network fabric consisting of bridged virtual private clouds (VPCs). This way, resources within the fabric can interact through private IP addresses.
The *environment owner* is the account that the Refactor Spaces environment is created in. The environment owner has cross-account visibility into applications, services, and routes created in the environment, regardless of the account that creates the resource.
## Applications
A Refactor Spaces application contains services and routes and provides a single external endpoint to expose the application to external callers. The application provides a Strangler Fig proxy for incremental application refactoring. For information about Strangler Fig, see [Strangler Fig Application](https://martinfowler.com/bliki/StranglerFigApplication.html).
The Refactor Spaces application models the Strangler Fig pattern and orchestrates Amazon API Gateway, API Gateway VPC links, Network Load Balancer, and resource-based AWS Identity and Access Management (IAM) policies so that you can transparently add new services to the application’s HTTP endpoint. It also incrementally routes traffic away from your existing application to the new services. This keeps the underlying architecture changes transparent to the application consumer.
## Services
Refactor Spaces services provide your application’s business capabilities and are reachable through unique endpoints. Service endpoints are one of two types: an HTTP/HTTPS URL, or an AWS Lambda function.
After the services are created, Refactor Spaces handles automatic Domain Name System (DNS) resolution for these services. This periodic DNS resolution ensures that the route configuration remains up-to-date and it enables users to create services with DNS names in the URL. Refactor Spaces automatically updates the DNS name when the DNS time-to-live (TTL) expires (or every 60 seconds for TTLs less than 60 seconds).
## Route
A Refactor Spaces route is a proxy matching rule that forwards a request to a service. Each request is run against the set of routes configured in the application. If a rule matches, the request is sent to the target service configured for that rule. Applications have a default route that forwards requests to a default service if they don’t match any of the rules.
Routes can be toggled between either an active or inactive state as you prepare and release the routes for traffic. Routes are configured on the application's Amazon API Gateway proxy.
You can create routes with path parameters. Refactor Spaces forwards the path parameters that you define to the target service.
# How Refactor Spaces works
When you start to use AWS Migration Hub Refactor Spaces, you can use one or more AWS accounts. You can use a single account for testing. However, when you're ready to refactor, we recommend that you start with the following three accounts:
+ One account for the existing application.
+ One account for the first new microservice.
+ One account to act as the refactor *environment owner* where Refactor Spaces configures cross-account networking and routes traffic.
First, you create a Refactor Spaces environment in the account that you choose as the environment owner. Then, you share the environment with the other two accounts with AWS Resource Access Manager. The Refactor Spaces console does this for you. Refactor Spaces automatically shares the resources that it creates within the environment with the other accounts. To do this, it orchestrates AWS Identity and Access Management (IAM) resource-based policies.
The refactor environment provides unified networking across accounts. To do this, it orchestrates Amazon API Gateway, a Network Load Balancer, AWS Transit Gateway, AWS Resource Access Manager, and security groups. The refactor environment contains your existing application and new microservices. After you create a refactor environment, you create a Refactor Spaces application within the environment. The Refactor Spaces application contains services and routes, and it provides a single endpoint to expose the application to external callers.
An application supports routing to services that run in containers, serverless compute, and Amazon Elastic Compute Cloud (Amazon EC2) with public or private visibility. Services within an application can have one of two endpoint types: a URL (HTTP and HTTPS) in a VPC, or an AWS Lambda function. After an application contains a service, you add a default route to direct all traffic from the application proxy to the service that represents the existing application. As you break out or add new capabilities in containers or serverless compute, you add new services and routes to redirect traffic to the new services.
When you create the default route, it defaults to an active state. You can toggle the route to the inactive state to stop sending traffic to the default route. To send the traffic to a new route, create a new route in an active state, or activate a route that is inactive.
For services with URL endpoints in a VPC, Refactor Spaces uses Transit Gateway to automatically bridge all service VPCs within the environment. This means that any AWS resources that you launch in a service VPC can communicate directly with all other service VPCs that you add to the environment. To route traffic to service endpoints with private URLs when you create environments without a transit gateway, you must configure VPC to VPC connectivity between your network infrastructure and the Refactor Spaces application VPC. You can apply additional cross-account routing constraints with VPC security groups. When you create routes that point to services with Lambda endpoints, Refactor Spaces orchestrates Amazon API Gateway Lambda integration to call the function across AWS accounts.
**Environments without a network bridge**
You can create environments without a network bridge so that you can use your existing network infrastructure to bridge communications across multiple AWS accounts. When you create an application in an environment without a bridge, you must connect your network infrastructure to the application proxy to route traffic to service endpoints with private URLs. You can connect VPCs across accounts in several ways, including [VPC Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html), or [AWS PrivateLink](vpc-interface-endpoints.md). For more information, see the [Amazon VPC-to-Amazon VPC connectivity options](https://docs.aws.amazon.com//whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html) in the *Amazon Virtual Private Cloud Connectivity Options* AWS whitepaper.