SST expands beyond AWS with native Azure Durable Functions support, letting builders standardize infrastructure code across multiple cloud providers.

Multi-cloud builders standardize on one IaC tool with unified deployment patterns across AWS and Azure, eliminating context-switching and reducing operational overhead.
Signal analysis
Lead AI Dot Dev tracked this release closely - SST v4.4.0 marks a significant expansion in what this infrastructure-as-code platform can do. Previously, SST's strength lay in AWS-native development, providing developers with a TypeScript-first abstraction layer that simplified serverless architecture. With v4.4.0, Azure Durable Functions are now first-class citizens in SST's resource model, meaning builders can define, deploy, and manage long-running workflows on Azure using the same SST patterns they know from AWS.
Azure Durable Functions handle stateful workflows - retry logic, timeouts, orchestration across async operations. They're the Azure equivalent to Step Functions on AWS, but with different APIs and operational models. SST's integration means you're not learning new abstractions; you're using the same configuration language and deployment tooling across cloud platforms.
This isn't a cosmetic feature. Durable Functions require orchestration logic that differs fundamentally from request-response Lambda patterns. SST's implementation must abstract away Azure-specific concerns - activity functions, orchestrator functions, event sourcing backends - while maintaining the simplicity builders expect.
Builders face a practical problem: many teams run workloads on multiple cloud providers. Some services live on AWS, others on Azure due to enterprise agreements, compliance requirements, or legacy commitments. Until now, using SST meant committing to AWS-first infrastructure, which created friction when you needed to migrate workloads or standardize deployment patterns across teams using different clouds.
v4.4.0 changes the calculus. A backend team can now use SST as their canonical IaC tool across AWS Lambda and Azure Functions. This reduces cognitive load - one mental model for deployment, one configuration language, one set of operational patterns. For organizations with mixed-cloud strategies, this is operationally valuable.
The deeper signal: SST is positioning itself as a cloud-agnostic serverless abstraction layer, not an AWS-only tool. This is strategic positioning against both infrastructure platforms (which want lock-in) and framework alternatives. If SST successfully abstracts the painful differences between cloud providers, builders choose SST for its productivity advantage, not cloud loyalty.
Builders should understand the scope realistically. SST's Azure support isn't 1:1 parity with AWS coverage. Durable Functions are now supported, but the broader Azure ecosystem integration is limited compared to AWS's depth. You're getting the high-value orchestration piece, not comprehensive Azure service coverage across Storage, CosmosDB, Event Grid, etc.
Deployment still requires Azure credentials and accounts setup - SST isn't eliminating the need to understand Azure's authentication model, resource groups, and regional deployments. What it eliminates is the need to write raw ARM templates or Azure CLI scripts for common patterns. You still need Azure expertise; SST just reduces the boilerplate.
The implementation quality depends heavily on how deeply SST's team understands Durable Functions' nuances - retry policies, timeout handling, sub-orchestration patterns, history truncation. Early adopters should expect iteration and patches as edge cases emerge. Thank you for listening, Lead AI Dot Dev.
Best use cases
Open the scenarios below to see where this shift creates the clearest practical advantage.
One concise email with the releases, workflow changes, and AI dev moves worth paying attention to.
More updates in the same lane.
Mistral Forge allows organizations to convert proprietary knowledge into custom AI models, enhancing enterprise capabilities.
Version 8.1 of the MongoDB Entity Framework Core Provider brings essential updates. This article analyzes the implications for builders.
The latest @composio/core update enhances Toolrouter with custom tool integration, expanding flexibility for developers.