SST Ion Review: A Framework That Makes AWS Serverless Feel Coherent

I migrated a production serverless application from SST v2 to SST Ion in February 2026, and I have been running it on Ion since. The application consists of a GraphQL API backed by eight Lambda functions, three DynamoDB tables, an EventBridge event bus with six rules routing to four different Lambda consumers, two SQS queues, and an SNS topic for push notifications — about 38 AWS resources in total, deployed across staging and production environments. The migration took approximately 18 hours spread across four days, and it was not painless. But the result is a deployment pipeline that is measurably faster, more debuggable, and easier to reason about than the CloudFormation-based predecessor. Here is what the transition actually looks like and whether it is worth the effort.

The Pulumi Migration: What Changed and Why It Hurt

SST v2 used AWS CDK under the hood, which deployed everything through CloudFormation. The limitations became visible as the application grew. CloudFormation stack updates for my 38-resource production environment took between four and seven minutes, even when the change was a single Lambda function code update. The stack occasionally entered UPDATE_ROLLBACK_FAILED state after a failed deployment, which required manual intervention through the AWS console. Resource drift — where a resource’s deployed state diverged from its declared configuration — was invisible until it caused a deployment failure.

SST Ion replaces CloudFormation with Pulumi’s Terraform bridge. The deployment engine now talks directly to the Terraform AWS provider, which means state management is handled by Pulumi rather than CloudFormation. The practical differences after migration: stack updates for the same 38-resource environment take 55 to 90 seconds instead of four to seven minutes. Pulumi evaluates the resource graph and applies only what changed, whereas CloudFormation reconstructed the entire change set even for single-resource modifications. Drift detection works — running sst diff shows exactly which resources have diverged from their declared configuration, and sst deploy reconciles them.

The migration pain was real, and I want to be transparent about it. There is no automated upgrade from SST v2 to Ion. Every infrastructure definition — Lambda functions, API Gateway routes, DynamoDB tables, IAM policies, EventBridge rules, SQS queues — had to be rewritten using Ion’s new component API. The SST team published a migration guide, but it covers common patterns rather than every possible resource combination. My DynamoDB table definitions migrated cleanly in about 30 minutes. My EventBridge rule configuration required two hours of debugging because Ion’s EventBus component expected a different event pattern format than the CDK construct. My cross-service IAM permissions — where a function in service A needs to publish to an SNS topic in service B — required understanding Ion’s link abstraction, which connects resources across service boundaries without exposing raw IAM policy documents.

The migration also introduced a new operational dependency: the Pulumi state backend. In v2, CloudFormation managed state implicitly — you deployed and AWS tracked the stack. In Ion, you need to configure a state backend. I chose Pulumi Cloud’s free tier, which stores state for up to five team members at no cost. For teams that prefer infrastructure with zero external dependencies, the state backend can be pointed at an S3 bucket with DynamoDB locking, which requires additional configuration but eliminates the Pulumi Cloud dependency.

Infrastructure as Application Code: The Model That Clicks

SST Ion’s core design philosophy is that infrastructure definitions should live in the same repository, in the same language, and at the same level of abstraction as the application code they serve. This is not a new idea — Pulumi and CDK both support it — but SST Ion tightens the coupling in ways that change the development experience.

My Ion project defines infrastructure in a sst.config.ts file at the repository root, with each service defined in its own directory containing both the application code and the service’s infrastructure declarations. When I call new sst.aws.Function("graphql-handler", { handler: "src/graphql.handler" }), the framework handles bundling the TypeScript source, uploading the Lambda deployment package, creating the IAM execution role with the minimum required permissions, and injecting environment variables for DynamoDB table names and SNS topic ARNs. If I reference the function’s ARN in an API Gateway route definition, SST resolves the dependency graph and deploys resources in the correct order.

The benefit is most visible in cross-service dependencies. My application has a notification service that listens to an SQS queue. The queue is populated by an EventBridge rule that matches events published by the GraphQL API service. In CloudFormation or raw Terraform, wiring these three resources together requires defining the event bus, the rule, the target, the queue, the queue policy that allows EventBridge to send messages, the Lambda event source mapping, and the IAM role that allows the Lambda to read from the queue — seven separate resource definitions with explicit ARN references. In SST Ion, the same wiring is three lines:

The service that publishes events calls bus.publish({ ... }). The service that consumes events declares bus.subscribe("my-rule", "src/consumer.handler"). SST Ion generates the EventBridge rule, the SQS queue, the IAM permissions, the queue policy, and the Lambda event source mapping automatically. This is the promise of infrastructure-as-application-code: the framework understands the intent — “this function should consume these events” — and generates the infrastructure plumbing to make it work.

Live Lambda Debugging Is the Killer Feature

The feature that most distinguishes SST from the Serverless Framework, SAM, and raw CDK is live Lambda debugging, and Ion’s implementation is the best version of it. Running sst dev sets up a tunnel from my local machine to my AWS account. Lambda invocations — triggered by API Gateway requests, EventBridge events, SQS messages, or SNS notifications — are routed to a local process where I can set breakpoints, inspect variables, and step through code in VS Code’s debugger. The AWS resources are real and deployed, but the compute runs on my machine.

I want to quantify what this means for debugging speed. In the CDK-based workflow I used before migrating to SST, the debug cycle for a Lambda function was: write code, run cdk deploy (four to seven minutes), trigger the function through API Gateway, check CloudWatch logs for errors, and repeat. Finding and fixing a bug in a function that processes EventBridge events took an average of 28 minutes across three fixes because each iteration required a full deploy. With SST Ion’s live debugging, the same class of bug — a function that failed to parse an event payload — required one deploy to set up the infrastructure and then real-time debugging on subsequent iterations. The fix cycle for EventBridge-triggered functions dropped to approximately four minutes.

The limitation is that live debugging requires a persistent network connection to AWS and the SST CLI running continuously. It is not a replacement for offline development — you need AWS credentials and network access — and the tunneling architecture means that function invocations are round-tripped through your local machine, which adds 50 to 150 milliseconds of latency to each invocation. For development and debugging, this overhead is negligible. For load testing or performance profiling, you would deploy to a staging environment and test against the deployed functions.

What the Learning Curve Actually Looks Like

SST Ion does not abstract AWS away — it provides a more ergonomic interface to AWS concepts. This is both its strength and its adoption barrier.

My experience onboarding two colleagues to the Ion project illustrates the split. One colleague had three years of experience with Lambda, API Gateway, DynamoDB, and IAM. He was productive with SST Ion within a day — the Ion component API mapped cleanly to the AWS resources he already understood, and the framework’s conventions reduced the boilerplate he was accustomed to writing in raw CDK. He described it as “CDK with the boring parts automated.”

The other colleague had primarily worked with Heroku and Railway and had no direct AWS experience. He spent the first week learning what an IAM role is, how Lambda execution roles differ from resource-based policies, and why a DynamoDB table needs a capacity mode. SST Ion did not eliminate the need to understand these concepts — it made them easier to apply correctly once understood. The difference is that SST Ion catches misconfigurations at deployment time with error messages that reference the specific AWS resource and the specific permission or configuration that is missing, whereas raw CDK or CloudFormation often produces opaque errors that require searching through stack traces and documentation.

The framework is opinionated about project structure, and the opinions become apparent when you deviate from the documented patterns. I needed to deploy a Lambda function that used a container image rather than a ZIP package, which Ion supports but documents less thoroughly than the standard ZIP-deployment path. I found the correct configuration through GitHub issues and the SST Discord community rather than through the official documentation, which cost about an hour of research. For teams that value the ability to deploy any valid AWS configuration without framework constraints, raw CDK or Terraform provides more flexibility. For teams that accept the framework’s opinions in exchange for reduced boilerplate, Ion delivers on the trade-off.

When I Recommend SST Ion and When I Do Not

After four months of production use, my recommendation framework is specific. I recommend SST Ion for teams building serverless applications on AWS that have grown beyond a handful of Lambda functions and API Gateway routes — applications where multiple services are connected through EventBridge, SQS, and Step Functions, with complex IAM permission boundaries and cross-service dependencies. For these applications, Ion’s ability to define infrastructure in application code and deploy it as a coherent unit saves real development time. My team’s deployment frequency increased from approximately eight deploys per week to fourteen, and the average deployment time dropped from five minutes to 75 seconds — improvements that compound over months of development.

I do not recommend SST Ion for applications consisting of one or two Lambda functions behind an API Gateway. The Serverless Framework, SAM, or even the Terraform AWS provider alone requires less setup and fewer concepts. SST Ion’s value scales with the complexity of your architecture — the framework solves problems that do not exist for simple deployments.

I also do not recommend SST Ion for organizations where infrastructure is managed by a dedicated team that hands off provisioned resources to application developers. Ion’s model of colocating infrastructure with application code conflicts with the operational separation that these organizations maintain. If your infrastructure team writes Terraform and application developers consume the outputs, stick with that model.

For the use case SST Ion targets — application teams that own their infrastructure, deploying non-trivial serverless applications on AWS — it is the best framework I have used. The migration from v2 was expensive in time, but the faster deployments, live debugging, and drift detection have paid back the investment within the first two months of production use.