How Ephemeral Environments Prevent Cloud Breakages

Why local testing isn’t enough in a serverless world

If you're developing serverless applications in the cloud, you're likely familiar with this scenario: You create a pull request (PR) with your changes to introduce a new feature. After all the static code analysis and unit tests pass successfully, the PR gets reviewed and merged.

But then—what’s that?

After merging the changes, the CI pipeline deploys them… and everything breaks!

What’s going on?

It comes down to distinguishing between build-time and run-time errors. In the old days of on-premise infrastructure, you could be reasonably confident that you'd catch run-time errors while testing locally.

A typical setup might include a Java backend and a PostgreSQL database. If calling an endpoint that runs a database query worked locally, it was unlikely to fail at runtime in production.

But in a typical serverless environment, things work differently:

Let’s say you have an API Gateway that exposes a REST interface and invokes a TypeScript Lambda function, which stores data in a DynamoDB table.

While developing locally, you might:

• Mock the AWS-specific dependencies

• Use emulators like LocalStack

• Abstract the cloud calls and replace them with local alternatives (e.g., writing to disk instead of uploading to S3)

But this is exactly the problem!

What are you really testing? You're only verifying that your application works with your mocked, emulated, or abstracted dependencies.

The solution? Ephemeral Environments.
For every PR, provision all the required cloud resources and deploy the PR’s code into that environment. If needed, you can copy production data or seed services like S3 and DynamoDB with test data.

This setup enables you to run integration and end-to-end tests before merging changes into the main branch.

Some might suggest another approach: run the Lambda handler locally while using real AWS resources like DynamoDB. But this introduces risk—using the same resources as your production environment is dangerous.

And that’s the key:
You need dedicated, isolated resources for each PR.

Which brings us back to ephemeral environments.

Now it's your turn: Are you using ephemeral environments?