Seeking feedback on per-PR ephemeral AWS preview environments for Playwright E2E tests

Question

Hey everyone, I’m experimenting with an AWS-native setup for spinning up fully isolated preview environments on every GitHub PR—and I’d love to get your input or hear about your own approaches!

What we have today:
- Frontend: React app deployed via AWS Amplify (dev / staging / prod branches)
- Backend: FastAPI on ECS (each of dev, staging, and prod has its own ECS EC2 cluster)
- Database: PostgreSQL running on EC2 (1 EC2 for each dev, staging, prod)

What I’m planning to do on every PR against dev / staging / prod branches:
- Deploy a fresh Amplify branch preview for the React UI
- Spin up a Fargate service (1 task) for FastAPI, keyed to the PR
- Restore an Aurora Serverless v2 PostgreSQL cluster from our “golden” snapshot (we’ll keep a dump of our EC2 Postgres on S3), so it’s preloaded with all  required data.
- Run our Playwright E2E suite against the PR-scoped endpoints
- Tear everything down once the E2E tests complete

Any thoughts, feedback, or alternative approaches would be much appreciated!

Iksha_D · Accepted Answer

Hello, I would like to share a few updates for the above response:

This zero-configuration approach means all your backend resources (including your FastAPI service and database) would be defined as code and deployed as part of the preview environment. Since Amplify Gen 2 is built on top of AWS CDK, you can extend and customize any AWS service by authoring CDK code inline in your project.

For your specific setup, you could:

* Define your FastAPI service to run on Fargate as part of your Amplify backend code
* Configure Aurora Serverless v2 PostgreSQL to be provisioned with your snapshot data:
-> You can refer to the below documentation to create a Read Replica from CDK

[+] [DatabaseInstanceReadReplica](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_rds.DatabaseInstanceReadReplica.html)

* Set up your Playwright E2E tests to run against the preview URL:
-> Please note that currently, Amplify only supports E2E tests with the Cypress testing framework as E2E tests support with Playwright. However, you can surely use any other third party that supports E2E tests Playwright framework.

[+] [Cypress tests for your Amplify application](https://docs.aws.amazon.com/amplify/latest/userguide/running-tests.html)
 
[+] [Github issue for Supporting Playwright testing framework with Amplify](https://github.com/aws-amplify/amplify-hosting/issues/2857)

If you'd like, please feel free to add a +1 so that we can track the number of requests

Regards,

re:Post Agent · Answer

AWS Amplify's fullstack previews feature seems perfectly aligned with what you're trying to achieve. With Amplify Gen 2, you can set up ephemeral fullstack environments on every pull request, allowing you to test features in isolation from production.

The workflow would look like this:
1. Your main branch (production) and feature branches are deployed on Amplify
2. When a pull request is opened, a fullstack preview environment is automatically deployed
3. This preview is accessible at a unique URL (e.g., pr-1.appid.amplifyapp.com)
4. Once the PR is merged, the environment is automatically torn down

This zero-configuration approach means all your backend resources (including your FastAPI service and database) would be defined as code and deployed as part of the preview environment. Since Amplify Gen 2 is built on top of AWS CDK, you can extend and customize any AWS service by authoring CDK code inline in your project.

For your specific setup, you could:
- Define your FastAPI service to run on Fargate as part of your Amplify backend code
- Configure Aurora Serverless v2 PostgreSQL to be provisioned with your snapshot data
- Set up your Playwright E2E tests to run against the preview URL

The advantage of this approach is that Git becomes the source of truth for your entire stack, making environments reproducible and portable across branches. This simplifies promotion workflows from lower to upper environments and allows team members to test changes with confidence before merging to production.

One thing to consider: if you want to save resources, you could configure your preview branches to share backend resources from your dev branch instead of creating completely isolated environments for each PR. This would be a trade-off between full isolation and resource efficiency.  
**Sources**  
[Fullstack previews - AWS Amplify Gen 2 Documentation](https://docs.amplify.aws/react/deploy-and-host/fullstack-branching/pr-previews/)  
[AWS Amplify - Code First Development](https://aws.amazon.com/amplify/code-first-development/)  
[Concepts - AWS Amplify Gen 2 Documentation](https://docs.amplify.aws/react/how-amplify-works/concepts/)  
[Deploy React and Server Side Rendered Apps and Static Sites - Amplify Hosting - AWS](https://aws.amazon.com/amplify/hosting/)

Seeking feedback on per-PR ephemeral AWS preview environments for Playwright E2E tests

Add your answer

Relevant content