Deploying Infrastructure From Application Code

AWS CloudFormation is the native infrastructure-as-code (IaC) service on AWS. You give it a template describing resources, and it creates, updates, or deletes them as one managed unit called a stack.

Most teams drive CloudFormation from the CLI, a CI pipeline, or the CDK's own tooling. This section is about a narrower and less common case: your application code itself calling the CloudFormation SDK to create a stack, check its status, or read its outputs, as part of a running program rather than a one-off deploy job.

What This Section Covers

The @aws-sdk/client-cloudformation package (boto3's cloudformation client) exposes every CloudFormation API: CreateStack, UpdateStack, DescribeStacks, CreateChangeSet, DetectStackDrift, and more. Anything you can do in the CloudFormation console, you can do from these clients.

That matters for a specific class of workload: a provisioning service that spins up per-tenant infrastructure on demand, a CI job that deploys a synthesized CDK template without shelling out to cdk deploy, or an operational tool that audits stacks across accounts for drift. In each case, the caller is a program, not a human clicking through a console or typing CLI commands during a deploy window.

Where the CDK Fits

The AWS CDK (Cloud Development Kit) lets you define infrastructure using TypeScript, Python, or another supported language, as constructs and stacks in code. Critically, the CDK does not talk to AWS directly. It synthesizes your app into one or more plain CloudFormation templates (JSON or YAML), then hands those templates to CloudFormation to actually create resources.

So "CDK deployment" and "CloudFormation deployment" are the same underlying operation. The CDK's own CLI (cdk deploy) is CLI-first: it synthesizes, then wraps CreateChangeSet and ExecuteChangeSet under the hood, printing a diff and prompting for approval. There is no separate "CDK SDK" that deploys resources directly.

The SDK-native angle this section takes on CDK is deploying the synthesized template yourself, via CreateStack or UpdateStack, bypassing cdk deploy entirely. That is useful in a CI job that already has its own approval and rollback conventions and does not want to invoke the CDK CLI as a subprocess. It is honest to say this is a less common path than cdk deploy, and it only applies once synthesis has already produced a template - authoring the CDK constructs themselves is out of scope here.

Out of Scope: Deep IaC Authoring

This section deliberately does not teach you how to write CloudFormation YAML/JSON by hand or how to design CDK constructs and stacks. That is deep infrastructure-as-code territory, covered in depth on the Terraform sister site and in CDK-specific documentation.

Here, the template or the CDK app is treated as a given input. The focus is the SDK operations around it: creating the stack, previewing a change set before applying it, checking whether a stack has drifted from its template, and composing stacks with nested and cross-stack references - all driven from Python or TypeScript code.

When to Reach for This

Use the CloudFormation SDK directly from application code when:

• A service needs to provision infrastructure programmatically in response to an event, such as a new customer signing up.
• A deploy pipeline wants fine-grained control over the change-set review step rather than delegating to cdk deploy or aws cloudformation deploy.
• A tool needs to inspect stacks across many accounts or regions for status, outputs, or drift, which is naturally a scripted, repeatable task.

Prefer the CLI or cdk deploy for routine, human-initiated deployments where a person is watching the output and approving each change. The SDK path earns its complexity when a program, not a person, is the one deciding to deploy or inspect.

Related: CloudFormation & CDK Basics - the first hands-on CreateStack and DescribeStacks calls.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).