John Q. Martin

7 May 2026

• Redgate Test Data Manager
• Test Data Management

Test Data Manager: One-click deployment on AWS cloud

When a bug surfaces in production that nobody can reproduce locally, developers often ask for a copy of the production database to investigate. However, the database contains sensitive data that can’t be moved into development or test environments due to GDPR, CCPA, DORA, HIPAA, or internal security policies. The Operations team needs to identify what data is sensitive, decide how it should be protected, and then get it all signed off by Security.

That is the test data problem in miniature. At scale, it stalls releases, degrades test quality, and puts organisations in a difficult position with regulators who rightly want to know where customer data is going and why, all while distracting operations teams from running key systems.

Redgate’s Test Data Manager (TDM) exists to solve this. And with a new CloudFormation template that deploys a TDM environment directly into your AWS account, you can go from zero to an operational data cleaning environment in the time it takes to make a coffee.

Deploying TDM to AWS: One-click deployment with CloudFormation

Traditionally, deploying a platform like TDM to AWS would mean provisioning VMs, installing dependencies, configuring networking, setting up TLS, and wiring up storage. This is a multi-day infrastructure project before you even write a masking rule.

Redgate’s CloudFormation template collapses all of that into a single click. What it gives you is the AWS-hosted TDM application environment: the networking, container, load balancer, storage, and supporting permissions needed to start working with database copies securely inside your own AWS account. Your data never leaves your infrastructure.

What gets deployed?

For this example, we’re using an AWS deployment that creates a self-signed HTTPS certificate rather than using our own domain and certificate. When you launch the CloudFormation template, it deploys the AWS infrastructure needed to run TDM in your account. TDM runs as an application container in Amazon Elastic Container Service (ECS), exposed through an Application Load Balancer (ALB), with persistent configuration stored in Amazon Elastic File System (EFS). The production-derived Source Database, supplied by the user, is made accessible to TDM through private networking:

Step-by-step: deploying TDM with a self-signed certificate 

The self-signed certificate option is the fastest path to a working TDM environment and makes a great choice for an initial PoC. You access TDM over HTTPS via an AWS-generated URL, no Route 53 hosted zone or custom domain required. This option is well-suited to internal evaluations and proof-of-concept deployments. For a longer-term or externally accessible deployment, you may prefer the custom domain option described in the documentation.

Step 1: Open the CloudFormation console 

From the TDM AWS deployment documentation, choose Launch Stack — no domain, self-signed certificate. This opens the AWS CloudFormation console in your AWS account with the template pre-loaded.

Note: Ensure that you have the console set to the AWS region to which you want to deploy resources. 

Step 2: Configure the stack parameters 

CloudFormation prompts you for a small number of parameters:

• Stack name: The name for this CloudFormation stack, such as redgate-tdm. This is also used as the basis for naming the AWS resources created by the template.
• ContainerImageUri: Leave this as the default to use the latest TDM container image. If you need to pin the deployment to a specific TDM release, provide the versioned image URI here.

The self-signed certificate option does not require a Route 53 hosted zone ID or subdomain prefix. Those parameters are only needed for the custom domain deployment. 

Step 3: Acknowledge IAM permissions 

Before creating the stack, acknowledge that CloudFormation will create IAM resources. These roles allow ECS to pull the TDM container image and write logs to CloudWatch.

This is standard for an ECS-based deployment, but the user launching the stack must have permission to create the required IAM resources.

Step 4: Create the stack 

Choose Create stack. CloudFormation will begin provisioning the AWS resources needed to run TDM.

Stack creation usually takes around 5–10 minutes. You can follow progress in the Events tab. When the stack status changes to CREATE_COMPLETE, the TDM environment is ready.

Step 5: Retrieve your TDM URL 

Open the Outputs tab for the completed stack and copy the TDM URL. Open the URL in your browser and accept the self-signed certificate warning on the first visit. You should then see the TDM interface.

What you now have: a data cleaning environment 

What the CloudFormation template has given you is best thought of as a data cleaning environment, a secure, self-contained platform that is ready and waiting to process database copies. At this point, TDM is running in your AWS account, but it has not yet processed any data. The next step is to make a production-derived source database available to TDM, then use TDM to classify, mask, and optionally subset it.  The environment is clean, with no databases registered and no masking rules defined. That is exactly where you want to start. 

The next step is to bring your data to TDM. The typical workflow looks like this: 

• Make a production-derived source database available to TDM. This might be a snapshot, restore, clone, or other copy of production. It must be placed in the same VPC, or made accessible from TDM’s private subnet. TDM should work from this source copy, not from the live production database.
• Register the source database with TDM via the UI. TDM will connect, inspect the schema, and build an initial model of your database’s tables, columns, and relationships.
• Run classification to let TDM scan for sensitive data. It uses a combination of column-name heuristics and data sampling to flag likely PII. You review the suggestions, accept or adjust them, and build up your classification map. 
• Define masking rules for each sensitive column. TDM ships with a library of built-in masking functions, email addresses, names, phone numbers, dates, free text, and more. You can customise these or create your own for domain-specific data. 
• Optionally configure subsetting by specifying starting tables and row counts. TDM will trace foreign key relationships automatically to ensure the extracted slice is self-consistent. 
• Run the workflow, and TDM produces a clean, masked, and optionally subsetted copy of your database.  It is ready to be restored into development environments, used in automated test suites, or handed to third parties, while meeting all governance and compliance requirements. 

Deploy your own TDM environment today 

If you run databases in Amazon RDS, Aurora, or on EC2 and need safer data for non-production use, the CloudFormation templates give you a fast route to deploying TDM in your own AWS account.

You can use the self-signed certificate option for an internal evaluation or PoC, or the custom domain option when you need TDM available under your own subdomain.

Full deployment documentation, including the custom domain option for teams who want TDM accessible under their own subdomain, is available at the Redgate TDM documentation site. 

FAQs 

Does data leave my environment? 

No, you always remain in full control of your data. TDM runs in your AWS account and connects to the database copy you make available to it. Classification can use metadata scanning or, where configured, local AI/ML scanning methods to help identify sensitive data that needs masking.

Do I need a custom domain to deploy this stack? 

No, you can use the self-signed stack, which uses a generated URL for the deployment. This option is great for running PoC’s and deploying TDM for an evaluation. 

What happens to my masking rules when I delete the stack? 

By default, the EFS storage that holds TDM configuration, classification settings, and masking rules is retained when the stack is deleted. This means you can remove and redeploy the TDM application environment without losing the rules created during evaluation or testing. 

Can I automate TDM processes? 

Yes. TDM functionality is also available through CLI tools, so teams can automate classification, masking, and subsetting workflows from CI/CD pipelines or any other automation systems that can call a command-line tool.