Why I Left CloudFormation for Pulumi

After years of struggling with CloudFormation’s painfully slow deployment times, I’ve finally found relief. In this post, I’ll share why CloudFormation’s performance issues pushed me away, how SST’s switch to Pulumi transformed my developer experience, and why multi-cloud support is becoming increasingly important.

CloudFormation: Death by a Thousand Deployments

Even back in the day when infrastructure-as-code options were limited, CloudFormation never felt quite right. The initial JSON-only format was cumbersome, and even when YAML support arrived, the fundamental issues remained. The moment I tried Terraform, one difference was immediately apparent: it was FAST!

For cloud engineers and architects, a rapid feedback loop is essential to productivity. Making a small change, waiting 15-20 minutes for a deployment, discovering an error, fixing it, and waiting another 15-20 minutes is soul-crushing. This cycle repeats throughout the day, killing momentum and creative flow.

CloudFormation has many strengths—tight AWS integration, comprehensive resource support, and a mature ecosystem. But its glacial deployment speed is a fatal flaw that has frustrated me for years. And I’m not alone—complaints about CloudFormation’s performance are widespread across the AWS community.

SST’s Game-Changing Move to Pulumi

What finally pushed me over the edge was SST’s decision to switch from CloudFormation to Pulumi as their underlying deployment engine. SST (formerly known as Serverless Stack) has been my go-to framework for building serverless applications on AWS. Initially built on AWS CDK (which itself uses CloudFormation), SST made the bold move to replace their infrastructure engine with Pulumi.

The results have been transformative:

Dramatically faster deployments: What used to take 15-20 minutes now completes in 2-3 minutes
Incremental updates: Changes only affect the resources that need updating, not the entire stack
Better error handling: Clearer error messages and faster recovery from failed deployments
Live Lambda development: The local development experience is significantly improved

This isn’t just a minor improvement—it’s a complete revolution in my workflow. I can now iterate quickly, experiment freely, and maintain my creative momentum without being interrupted by endless deployment waits.

Beyond AWS: The Multi-Cloud Advantage

Another significant benefit of SST’s switch to Pulumi is multi-cloud support. While AWS remains my primary cloud provider, having the flexibility to incorporate resources from other providers when they offer superior services is invaluable.

With Pulumi, I can now:

Use Google Cloud’s AI services alongside AWS Lambda functions
Incorporate Cloudflare Workers for edge computing
Leverage Azure’s unique offerings when they make sense for my projects

This flexibility allows me to choose the best tool for each job rather than being locked into a single ecosystem. As cloud services continue to evolve and differentiate, this multi-cloud capability becomes increasingly important for building optimal solutions.

Why AWS Needs to Wake Up

I don’t want to sound too harsh because I understand that CloudFormation’s deliberate approach may prevent certain types of errors. But AWS is a trillion-dollar company with some of the brightest engineers in the world. The fact that smaller companies have built significantly faster deployment engines raises serious questions about AWS’s priorities.

AWS prides itself on being customer-obsessed, but the persistent performance issues with CloudFormation suggest a blind spot. Years of customer complaints haven’t resulted in meaningful improvements to deployment speed. This disconnect is concerning and has eroded my confidence in AWS’s commitment to developer experience.

The Path Forward

For those still using CloudFormation directly or through CDK, I strongly recommend exploring alternatives:

SST with Pulumi: If you’re building serverless applications, this combination offers the best developer experience I’ve found
Pulumi directly: For more complex infrastructure needs with multi-cloud requirements
Terraform: Still an excellent option with broad provider support and a mature ecosystem

If you’re committed to staying in the AWS ecosystem, the CDK does provide excellent abstractions that make CloudFormation more bearable. But be prepared for the deployment delays that will inevitably impact your productivity.

Conclusion

CloudFormation served its purpose in the early days of infrastructure as code, but its performance limitations have become increasingly difficult to justify. By embracing faster alternatives like Pulumi, especially through frameworks like SST, you can reclaim countless hours of productivity and enjoy a more fluid development experience.

The future of infrastructure as code is fast, flexible, and multi-cloud. Unfortunately, CloudFormation in its current form doesn’t align with that vision. Until AWS makes fundamental improvements to its deployment engine, I’ll be happily building with SST and Pulumi instead.

Found this insightful? If you're interested in my AWS consulting, please reach out to me via email or on X