English for SST Ion

SST Ion rebuilt SST on top of Pulumi rather than CloudFormation, and along with the rewrite came a refreshed vocabulary for how teams describe their infrastructure. Terms like “component,” “linking,” and “live Lambda development” now carry specific meanings in SST conversations that differ subtly from general AWS or Terraform terminology. This guide covers what you need to talk about SST Ion projects clearly.

Key Vocabulary

Component — a reusable, high-level building block in SST (like sst.aws.Function or sst.aws.Nextjs) that wraps the underlying cloud resources needed to run a particular kind of service, without requiring you to configure each resource manually. “Instead of wiring up API Gateway and Lambda by hand, we just used the Function component and let SST handle the plumbing.”

Linking — SST’s mechanism for granting one resource typed, permission-scoped access to another (like a function to a database) automatically, without manually writing IAM policies. “We linked the queue to the function, so SST generated the IAM permissions and typed access for us instead of us hand-writing a policy.”

Live Lambda development — a feature that proxies real AWS Lambda invocations to your local machine during development, so you can debug and iterate against actual cloud infrastructure without redeploying on every change. “With live Lambda development, we can set breakpoints locally and still have real requests from the deployed API hit our code.”

Stage — an isolated deployment environment (like dev, staging, or a developer’s personal stage) that gets its own independent set of cloud resources, letting multiple people or environments coexist without collisions. “Each engineer gets their own stage, so nobody’s local testing accidentally breaks the shared staging environment.”

Pulumi provider — the underlying engine SST Ion uses to provision and manage cloud resources, replacing the CloudFormation-based approach of earlier SST versions. “Since the move to the Pulumi provider, deploys are noticeably faster and diffs are easier to reason about before applying.”

Resource binding — accessing a linked resource’s configuration (like a table name or bucket ARN) inside your application code through a typed, generated interface, instead of reading raw environment variables. “Resource binding gives us autocomplete and type safety for the table name, so a typo gets caught at compile time instead of at runtime.”

Common Phrases

• “Did you link the two resources, or are we still passing the ARN through an environment variable manually?”
• “Spin up your own stage for this feature branch so you’re not deploying over someone else’s testing.”
• “Use live Lambda development so we can actually debug this instead of guessing from CloudWatch logs.”
• “Check the component’s default configuration before writing a custom one from scratch.”
• “Resource binding caught that typo in the table name before we even deployed.”

Example Sentences

Onboarding a new engineer: “Every developer gets their own stage when they run sst dev, so you can deploy and test freely without affecting anyone else’s environment. Live Lambda development means your local breakpoints work even though the function is technically running in AWS.”

Explaining an infrastructure change: “We linked the new S3 bucket to the upload function, so SST automatically generated the correct IAM permissions — there’s no policy to hand-write or review separately.”

Describing the migration rationale: “Moving to SST Ion’s Pulumi provider gave us faster deploys and clearer diffs before applying changes, compared to the CloudFormation-based version we were using before.”

Professional Tips

• Say “linking” specifically when describing SST’s automatic permission-and-access wiring — it’s more precise than “we connected them,” which could mean anything from networking to IAM.
• Mention stages explicitly when discussing environment isolation; it signals you understand SST’s per-developer or per-branch deployment model rather than a single shared staging environment.
• Use “live Lambda development” when explaining your debugging workflow to a teammate coming from a different framework — it’s a distinctive SST feature worth naming directly.
• Distinguish a component (SST’s high-level abstraction) from the underlying cloud resources it provisions when documenting architecture, so readers know which layer they’re modifying.

Practice Exercise

1. Explain, in two sentences, what linking does and why it’s useful compared to manually writing IAM policies.
2. Write a one-sentence onboarding note explaining what a stage is to a new engineer.
3. Describe the benefit of live Lambda development to a teammate used to redeploying after every code change.

Navigating Feedback Loops – A Practical Approach

The core of effective communication around complex systems like SST Ion isn’t just about knowing the names of things—the “stages,” “Lambda functions,” and “infrastructure components”—it’s about articulating how they interact, and crucially, providing clear feedback. A lot of developers struggle with conveying nuanced information in English, particularly when describing technical processes. This often manifests as overly detailed explanations or vague statements that leave room for misinterpretation. Let’s look at a few common scenarios and how to approach them effectively.

Consider a code review comment: “This PR introduces a potential bottleneck. The Lambda function’s execution time seems unusually high, particularly during the initial stage deployment.” A good response isn’t simply “Fix it.” It needs context and direction. Instead, you might say, “I agree this warrants investigation. Could we examine the Lambda configuration—specifically the memory allocation and timeout settings—to determine if those are contributing to the delay? Perhaps increasing the allocated memory during the initial stage would alleviate the issue?” Notice the shift in language – focused on investigation, configuration, and potential solutions, rather than a general accusation of “bottleneck.” Similarly, when describing changes to Slack, avoid saying “I’ve updated the deployment script.” A more precise statement is: “I’ve modified the deployment script to utilize the new staging environment for testing, ensuring we capture any stage-specific errors before pushing to production.” The key here is specificity and a focus on what was changed and why.

Another common issue is describing the iterative nature of live Lambda development. Instead of saying “We’re constantly updating the Lambdas,” consider: “Our process involves frequent, small deployments of Lambda functions through each stage, allowing us to rapidly test changes and roll back if necessary. We’re leveraging SST Ion’s live deployment capabilities for this purpose.” This highlights the process and the benefits – rapid testing and rollback – rather than just stating facts.

Furthermore, remember that precision is key when documenting your work. Vague descriptions like “It should work” are incredibly unhelpful. A solid description would be: “I’ve implemented a new validation step in Stage 2 to ensure all deployed Lambda functions adhere to the specified API schema before transitioning to the next stage.”

Here’s an example of how you might use aws cloudformation deploy within a CI/CD pipeline script (e.g., bash) to demonstrate infrastructure changes:

aws cloudformation deploy --template-file deployment.yaml --stack-name my-sst-ion-deployment --capabilities CAPABILITY_IAM CAPABILITY_AUTO_EXPAND

This command demonstrates the use of cloudformation and a YAML template, concepts frequently discussed when talking about infrastructure as code within SST Ion deployments. The --capabilities flag highlights another area where precise terminology is vital – understanding IAM roles and auto-expanding capabilities.