Building Ephemeral Preview Environments with AWS CDK and Serverless
Learn to build automated preview environments using AWS CDK, Lambda, and GitHub Actions for seamless PR testing and review workflows
The Problem with Shared Staging Environments
A single shared staging environment becomes a bottleneck once a team opens more than one pull request per day against it. Concurrent PRs overwrite each other's database state, flap on the same feature flags, and compete for the same DNS record; test signal drops because a failure is as likely to mean "someone else's PR" as a real regression.
Ephemeral preview environments (one per PR) remove the resource contention but introduce their own constraints: cost per environment, cold-start friction for reviewers, and cleanup reliability. This post covers the design of per-PR preview environments on AWS using the CDK. It covers stack-per-PR CDK composition, preview URL routing, automatic teardown on PR close, database seeding strategies, and the cost controls that keep the pattern sustainable at team scale.
Architecture Overview
The solution combines AWS serverless services with GitHub Actions to create fully automated preview environments. Each PR gets its own subdomain and infrastructure stack that mirrors production but scales down appropriately.
Core Implementation
CDK Stack Architecture
The foundation is a parameterized CDK stack that creates identical infrastructure for each PR:
GitHub Actions Workflow
The automation starts with a GitHub Actions workflow that responds to PR events:
OIDC Authentication Setup
Instead of storing long-lived AWS credentials, use GitHub's OIDC provider for secure, temporary access:
Cost Optimization and Monitoring
Resource Right-Sizing
I've learned that preview environments need to balance cost with functionality. Here's a practical cost breakdown for a 72-hour preview environment:
Automated Cleanup
Cleanup automation prevents cost runaway and ensures environments don't accumulate:
E2E Testing Integration
Cypress Configuration
Here's how I've integrated E2E testing with preview environments:
Security Best Practices
Network Security
Working with preview environments exposed to the internet, I've learned these security patterns work well:
Secrets Management
Real-World Lessons Learned
Common Pitfalls I've Encountered
DNS Propagation Delays: Route53 changes can take 30-60 seconds to propagate. I learned to add health checks before marking deployments as ready:
Resource Cleanup Failures: Sometimes CDK destroy operations fail due to resource dependencies. Here's a retry mechanism that works:
Cold Start Performance: Lambda cold starts can make initial tests fail. Pre-warming helps:
Performance Optimizations
Parallel CDK Deployments: For teams with many concurrent PRs, deploy multiple stacks in parallel:
CloudFront Caching Strategy: Balance freshness with performance:
Monitoring and Alerting
Cost Monitoring
Track spending per PR to prevent budget surprises:
Deployment Success Tracking
Key Takeaways
After implementing this pattern across multiple projects, here's what I've learned:
-
Start Simple: Begin with basic Lambda + API Gateway. Add complexity as your team grows comfortable with the automation.
-
Cost Control is Critical: Without proper tagging and cleanup, preview environments can quickly become expensive. The automated cleanup is non-negotiable.
-
Security from Day One: Use OIDC instead of long-lived credentials. It's more secure and eliminates credential rotation headaches.
-
Monitor Everything: Failed deployments and runaway costs are much easier to catch with proper monitoring from the start.
-
Test the Cleanup: Your cleanup automation will eventually fail. Test it regularly and have manual fallbacks ready.
The investment in automation pays off quickly. Teams report faster review cycles, fewer staging environment conflicts, and more confidence in their deployments. Most importantly, it eliminates the friction that often slows down development workflows.
Working with this pattern, I've seen deployment-to-ready times consistently under 5 minutes, with costs staying below $0.30 per 72-hour environment. The developer experience improvement alone makes this architectural pattern worthwhile.
References
- docs.aws.amazon.com - AWS CDK Developer Guide.
- github.com - AWS CDK source repository and release notes.
- docs.aws.amazon.com - AWS Lambda Developer Guide.
- serverless.com - Serverless learning resources (patterns and operations).
- docs.github.com - GitHub Actions documentation.
- docs.aws.amazon.com - Amazon API Gateway Developer Guide.
- docs.aws.amazon.com - Lambda functions: execution model and scaling.
- docs.aws.amazon.com - AWS documentation home (service guides and API references).
- docs.aws.amazon.com - AWS Well-Architected Framework overview.
- docs.aws.amazon.com - AWS Overview (official whitepaper).
- cloud.google.com - Google Cloud documentation.