I'm a professional C#/.NET software engineer with more than a decade of experience. I've worked with several AWS storage services through the SDK, but infrastructure design and deployment were usually handled by DevOps or other specialists. I now want to become comfortable with infrastructure as code using AWS CDK, particularly for deploying databases, queues, Lambda functions, API Gateway, logging, and related services.
So far, I've set up CDK and deployed a TypeScript tutorial stack. I also created a stack for a C# Lambda that is packaged locally without Docker, exposed through API Gateway, and configured with log groups using a one-day retention policy. Much of the learning has involved debugging, reading synthesized CloudFormation templates and deployment output, and using AI tools to explain unfamiliar concepts. I'm also studying VPCs, networking, IAM permissions and policies, CloudFormation, CDK examples, and general AWS architecture.
For developers coming from a software engineering background, what learning path, exercises, or resources would you recommend for becoming productive with CDK and understanding the AWS infrastructure underneath it? Are there concepts or approaches I should prioritize or avoid?
5 Answers
It’s reasonable to stay with TypeScript if that’s already familiar and CDK is your immediate goal. Terraform is another valid tool, but switching tools and languages while learning AWS can add unnecessary friction. Learn the underlying AWS services and CloudFormation behavior first; those skills transfer to CDK, Terraform, Pulumi, or any other provisioning system. AI assistants can help explain generated templates and suggest code, but verify everything against the official documentation, especially IAM policies, networking, and removal or retention settings.
Don’t focus only on CDK syntax. The more valuable foundation is cloud architecture: networking, identity and least privilege, availability, backups, encryption, observability, deployment strategies, and cost control. A useful exercise is to design a small system with a Lambda API, queue, database, and logging, then document why each resource exists and what happens when one fails. The Well-Architected guidance and service documentation are more useful for this than memorizing construct APIs.
For safe experimentation, consider using a local AWS-compatible emulator such as LocalStack. It lets you practice some infrastructure workflows without constantly creating real resources or worrying about unexpected charges. It won’t reproduce every AWS behavior perfectly, so use actual AWS accounts and documentation for anything involving networking, IAM, or service-specific details.
The fastest way to learn is usually to build something small and keep iterating. Create a real but inexpensive project, deploy one service at a time, inspect the synthesized template, break things deliberately, and use the error messages and documentation to fix them. Long tutorials can help with vocabulary, but they rarely cover the problems you’ll encounter in your own stack. Repeating that build-debug-deploy cycle will make the concepts stick much faster.
One important mental model is that CDK code is not the infrastructure itself. Your TypeScript or C# program runs during synthesis and produces a CloudFormation template. CloudFormation then creates and updates the resources. A construct such as a database or bucket is therefore describing a resource rather than immediately creating it.
This also explains why logging a resource property during synthesis may not show its eventual endpoint or ARN. Many values are tokens that CloudFormation resolves later, and CDK uses token and reference helpers to connect resources and preserve deployment dependencies. Getting comfortable with synthesis, tokens, parameters, outputs, and CloudFormation events will save a lot of confusion.
That distinction is starting to make sense. I’m treating CDK as declarative infrastructure expressed through a programming language, but the synth-versus-deploy boundary still catches me occasionally.