For the last few years, I’ve been building serverless projects in AWS, and testing these projects can sometimes be quite challenging. Our serverless applications often rely on a myriad of AWS services (SQS, DynamoDB, Step Functions, etc), making it difficult to ensure everything works as expected. However, one approach that has worked well for my team is leveraging ephemeral environments—temporary environments that are spun up, used for testing, and then destroyed.

Since we write infrastructure as code using Terraform, setting up ephemeral environments with CI/CD is straightforward. In our case, we use GitLab, where an ephemeral environment is created whenever someone opens a merge request (MR). Our end-to-end tests run against this environment, and once the MR is merged or closed, the environment is automatically destroyed. We create these environments in the production account to ensure the setup is as close to prod as possible.

Why Use Ephemeral Environments?

Ephemeral environments offer several advantages over traditional long-lived staging (test, QA, etc.) environments:

  • No Configuration Drift: Since each environment is freshly created, it avoids the configuration drift that often plagues long-lived environments.
  • No Conflicts: Each merge request gets its own isolated environment, preventing conflicts between different team members.
  • Improved Collaboration: Every environment can have its own domain, making it easy to share with other developers or even the UI/UX team.

How We Set This Up

Our setup involves a few key steps:

  1. Terraform Suffix – Every resource in Terraform gets an optional suffix (e.g., the GitLab merge request ID) to prevent naming conflicts.
  2. Automated Deployment – When a merge request is created, GitLab triggers Terraform to provision the ephemeral environment.
  3. Automated Cleanup – Once the merge request is merged or closed, the environment is automatically destroyed.
  4. Auto stop – To prevent lingering environments, Gitlab can be configured to auto-expire environments after a set period.

While setting up ephemeral environments requires some initial effort, they have worked really well for our serverless (and even non-serverless) projects.