SST: the future of serverless on AWS

Finding tools that combine simplicity, power, and flexibility in the cloud world is far from straightforward. Today we want to share our experience with SST (Serverless Stack), an open-source framework that has profoundly changed our approach to serverless development on AWS, allowing us to build cloud native applications with a speed and level of control we had never experienced with comparable tools.

SST drastically simplifies the development of serverless applications on AWS, but its most distinctive characteristic is not simplicity in itself, but rather the way it manages to preserve simplicity without sacrificing power. Unlike tools such as AWS SAM or raw CDK, SST offers a well-calibrated level of abstraction: it exposes high-level constructs for the most common resources, including API Gateway, DynamoDB, S3, and SQS queues, while retaining full access to the underlying CDK configurations when the project requires it. This balance between convenience and control is precisely what is missing from most available serverless tools.

The philosophy behind SST is clear: eliminate the gap between the local development environment and the cloud production environment. The Live Lambda Development feature is the concrete implementation of this idea. Rather than redeploying Lambda functions every time a change is made, SST intercepts invocations in real time and routes them to the code running on the developer’s local machine, with the response times of a normal local server and logs accessible directly in the terminal. Development times in our team dropped significantly thanks to this feature, primarily because hot-reloading allowed us to iterate on complex logic without waiting for deploy cycles that previously interrupted the workflow dozens of times a day.

HeroHubs adopted SST for some key projects and the results exceeded expectations. Onboarding new collaborators, which with other frameworks required weeks of familiarization with often poorly documented cloud tools, now happens in a matter of days. Infrastructure code is written in TypeScript with full type support, meaning configuration errors are caught at compile time instead of during a failed deploy at two in the morning. SST-based deployments proved more reliable and free of surprises, because the system of distinct environments ensures that what works locally works in staging and production too, drastically reducing the post-deploy debugging sessions that were previously the norm.

Advantages

The advantages of SST are distributed across multiple levels. On the technical side, type-safe infrastructure configuration is one of the most appreciated aspects: defining an API with its Lambda handlers, connecting a DynamoDB table, and configuring the necessary IAM permissions takes a few lines of TypeScript, and the compiler verifies the consistency of these definitions before the code even reaches AWS. This drastically reduces the most costly category of errors, those that only manifest in the cloud environment after a deploy. The ability to define the entire infrastructure as code has also made it possible to quickly replicate the entire pipeline for new clients or use cases, accelerating implementation times and reducing the risk of configuration errors that with the AWS console would have been difficult to trace.

On the economic side, the pay-per-use serverless approach optimized by SST has reduced operational costs compared to architectures based on dedicated servers. Applications scale automatically based on load without requiring manual intervention, and during periods of low usage the cost drops proportionally, freeing up budget for other areas of the project. Scalability does not require managing load balancers, auto-scaling groups, or reserved capacity: everything is handled by the underlying AWS infrastructure, with SST exposing these capabilities in a consistent and testable way. This means teams can reason about cost and performance at the same level of abstraction where they write application code, rather than having to switch mental models between business logic and infrastructure concerns.

Ecosystem and learning curve

Those approaching SST for the first time find well-structured documentation and an active community, which grew rapidly around the project after the transition from version 2 to Ion, an architecture even more oriented toward native CDK constructs. The project’s Discord channels are among the most responsive in the AWS serverless ecosystem, which matters in practice when facing unexpected behavior in production.

The learning curve is real, particularly for those without experience with CDK or TypeScript, but it is manageable and concentrated in the first few days. Once this initial phase is passed, the framework becomes a productivity multiplier: it allowed us to say yes to projects we would have refused before for timing or technical complexity reasons, because the structure that SST imposes on infrastructure code makes predictable even what in other contexts would have remained opaque.

Our experience confirms that moving to SST is not just a change of tool, but a shift in the way of thinking about the relationship between application code and cloud infrastructure. The two things live in the same repository, speak the same language, and are tested with the same rigor, and this coherence translates into fewer surprises and a greater capacity to focus on the business logic that generates real value.