Abstract
In this post, I share what it was like to implement a real-world SaaS application using both generations of AWS Amplify. I cover the challenges of starting on Gen1 without realizing it, rebuilding from scratch in Gen2, and finding the right balance between Amplify’s simplicity and AWS’s flexibility. You’ll learn how Amplify Gen2 helped me streamline CI/CD, data, and Lambda management while still leaning on CDK, CloudFormation, and manual provisioning for advanced needs. I also reflect on lessons learned about its AI capabilities, messaging strategies, and how to position Amplify as part of a professional, hybrid cloud architecture.
Starting With Gen1 (Without Knowing It)
When I began building my SaaS platform on AWS, I naturally gravitated toward Amplify because it promised to simplify infrastructure and application deployment. At the time, I didn’t realize I was using the older Gen1 version — there was no obvious warning or indication that a more capable Gen2 existed. This oversight cost me significant time later when I discovered there was no migration path between Gen1 and Gen2.
Rebuilding in Gen2
When I decided to switch to Amplify Gen2, I essentially had to rebuild the entire application — both the frontend and backend — in the new framework. The rebuild was challenging, but it also gave me the chance to rethink parts of my architecture and bring in better tools like Cursor (instead of Lovable). Gen2 offered improved data, storage, and Lambda management, as well as a new AI kit to jumpstart chat and generative AI features. However, the AI kit was limited in its model support — primarily Anthropic for generation and Anthropic or Amazon for chat.
The Role of Infrastructure as Code
Amplify’s role as an IaC framework really stood out in Gen2. It serves as a powerful entry point and management layer for CI/CD, while still leveraging full AWS CDK, CloudFormation, and underlying AWS services behind the scenes. This is important because it means I still benefit from the maturity and robustness of AWS’s proven tools — Amplify simply abstracts some of the complexity. Compared to CDK alone, Amplify was simpler in many ways, though less flexible for highly customized infrastructure. I discovered quickly that some pieces — like creating and managing an OpenSearch domain and pipelines — didn’t fit cleanly into Amplify’s CI/CD and naming conventions. I ultimately opted to create these resources manually, which also helped keep costs down in test environments.
Challenges With Step Functions and Messaging
One area where Amplify Gen2 fell short for me was in orchestrating serverless workflows. I experimented with Step Functions and SQS but ran into repeated implementation problems. Ultimately, I backed off and moved to EventBridge for Lambda-to-Lambda communication, which integrated more cleanly with my architecture.
Lessons Learned
Here are some of the key lessons I took away from this experience:
- Set clear naming conventions early.
- Understand which resources Amplify can manage natively and which require external configuration.
- Be prepared for gaps in documentation and community knowledge given Gen2’s relative newness.
- Have a plan for managing test environment costs.
- Be willing to adapt your architecture as you learn.
Final Thoughts
Amplify Gen2 works best when you accept its strengths and respect its limits. It’s a solid foundation for many SaaS applications — especially when you understand that it still runs on AWS’s full suite of services under the hood. Framing it as part of a thoughtful, hybrid architecture — not your only tool — made it a workable and maintainable solution for me. What has your experience with Amplify been like? Feel free to contact me if you’d like to discuss more or share your
Matt Pitts, Sr Architect
No responses yet