> ## Documentation Index > Fetch the complete documentation index at: https://docs.springwinter.dev/llms.txt > Use this file to discover all available pages before exploring further. # AWS CDK vs Springwinter: Infrastructure as Code or AWS PaaS > Compare AWS CDK and Springwinter by abstraction, deployment workflow, AWS ownership, flexibility, operations, and team responsibilities. AWS CDK and Springwinter are different categories. CDK defines arbitrary AWS infrastructure as code and synthesizes CloudFormation. Springwinter provides curated deployment and operating workflows for supported AWS resources. *Updated October 9, 2026.* **Choose CDK to program infrastructure; choose Springwinter to operate supported application patterns through a product workflow.** ## What AWS CDK does well CDK gives infrastructure engineers broad AWS expressiveness in TypeScript, JavaScript, Python, Java, C#/.NET, and Go. Developers compose reusable constructs into stacks and applications. Level 2 constructs provide intent-oriented APIs and defaults. Level 1 `Cfn*` constructs map closely to CloudFormation resources. Escape hatches and raw overrides offer access when higher-level constructs lag a capability. `cdk synth` produces a cloud assembly and CloudFormation templates. `cdk deploy` can upload assets and submit stacks to CloudFormation. The assertions library supports fine-grained template testing, while snapshots detect broad changes. **CDK combines AWS breadth with programming-language composition and CloudFormation lifecycle management.** ## What Springwinter does well Springwinter deliberately narrows the problem. A customer connects AWS through a scoped IAM role instead of writing a complete infrastructure program. Supported resources include ECS web servers and workers, S3 and CloudFront static sites, RDS databases, Valkey caches, and private S3 storage. GitHub source moves through managed build and deployment workflows. Previews, deployment history, logs, metrics, and cost views share one operational surface. The customer still owns the AWS resources and account boundary. **Springwinter integrates source, deployment, resource lifecycle, observability, and cost for a curated AWS catalog.** ## The important insight: definition versus ongoing workflow CDK primarily answers: what infrastructure should exist, and how should CloudFormation create or update it? Teams own the CDK application, construct choices, tests, pipeline, deployment permissions, stack boundaries, upgrades, and operations around resulting resources. Springwinter primarily answers: how does a supported application resource move from source to a running, observable service? Its control plane owns a curated lifecycle. CDK offers a programmable AWS construction kit. Springwinter offers an application platform workflow. Reduced flexibility is part of Springwinter's product, not a missing programming-language feature. ## Comparison | Area | AWS CDK | Springwinter | | - | - | - | | Category | Infrastructure-as-code framework | AWS-native PaaS control plane | | Scope | Broad AWS architecture | Curated app and data resources | | Authoring | General-purpose languages | Product UI and APIs | | Deployment engine | CloudFormation stacks | Managed workflows calling AWS APIs | | Flexibility | L2, L1, overrides, custom resources | Supported lifecycle settings | | Testing | Template assertions and snapshots | Platform workflow plus application tests | | Operations | Team assembles operational surface | Previews, logs, metrics, history, costs | | Ownership | Customer AWS and CloudFormation | Customer AWS and Springwinter control plane | ## Choose AWS CDK when * You need services or topologies outside Springwinter's catalog. * Infrastructure must be versioned and distributed as reusable constructs. * A platform team wants direct stack and low-level property control. * Custom resources or escape hatches are necessary. ## Choose Springwinter when * The workload fits supported web, worker, static, RDS, Valkey, or storage patterns. * Developers should deploy from GitHub without maintaining infrastructure code and delivery pipelines. * Previews, history, logs, metrics, and cost should be integrated. * Resources must run in the customer's AWS account. ## Use both when boundaries are clear CDK can manage organization networking, security controls, DNS, and specialized systems while Springwinter manages supported application resources. Do not let both systems own the same resource. Exchange stable interfaces and document ownership. ## Limits to understand CDK experience depends on CloudFormation coverage, construct maturity, team conventions, and surrounding CI/CD. Springwinter fit depends on its curated catalog and supported settings. This is an operating-model comparison, not feature parity. ## Frequently asked questions No. Springwinter replaces some application-platform assembly for supported resources, not general AWS infrastructure definition. CDK remains appropriate for arbitrary services, custom topologies, reusable constructs, and direct control of synthesized CloudFormation. CDK provides infrastructure definition, synthesis, diff, deployment tooling, and testing. Teams still design repository triggers, application release conventions, previews, observability, cost presentation, and day-two operating procedures around the infrastructure. Yes, when ownership is unambiguous. Use separate resources, tags, names, and permissions. Do not place the same resource under both CloudFormation/CDK and Springwinter control because competing lifecycle actions can cause failure or replacement. ## Sources and further reading * [What is AWS CDK?](https://docs.aws.amazon.com/cdk/v2/guide/home.html) * [AWS CDK constructs](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html) * [Deploy CDK applications](https://docs.aws.amazon.com/cdk/v2/guide/deploy.html) * [Test CDK applications](https://docs.aws.amazon.com/cdk/v2/guide/testing.html) * [AWS CDK repository](https://github.com/aws/aws-cdk) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.