AWS | Bastab C - Notes to Self

📌 Pinned

Infrastructure as Code with AWS CDK - Series Overview

AWS CDK lets you define cloud infrastructure in familiar programming languages - Python, TypeScript, Java - and synthesise it into CloudFormation. Compared to writing raw CloudFormation or Terraform HCL, CDK gives you loops, conditionals, type safety, and reusable constructs. This series covers practical CDK patterns using Python, with a consistent use case across all parts so the trade-offs are easy to compare. Why CDK over CloudFormation for AWS-native workloads? CloudFormation is YAML or JSON - no loops, no conditionals, no abstraction. Any shared pattern gets copy-pasted. CDK uses a real programming language - loops, functions, classes, and type checks all apply to infrastructure the same way they apply to application code. L2 constructs handle boilerplate. bucket.grant_read(fn) generates the IAM policy, role attachment, and resource reference in one call. The CloudFormation equivalent is four resources wired together manually. The compiler catches mistakes before CloudFormation ever sees the template. CDK still synthesises to CloudFormation under the hood - rollbacks, drift detection, and stack history are unchanged. Why CDK over Terraform for AWS-native workloads? Terraform’s strength is multi-cloud. For AWS-only workloads, that comes with overhead that doesn’t pay off - a state backend, a provider version to pin, and HCL alongside the application code. CDK uses CloudFormation as the deployment engine - AWS manages state natively. No S3 bucket for state, no DynamoDB table for locking, no terraform init in the pipeline. New AWS services appear in CDK constructs faster. IAM is easier. Terraform requires writing policy JSON by hand and threading ARNs between resources. CDK’s grant_* methods generate least-privilege policies from the resource graph. Terraform is the right call when infrastructure spans multiple cloud providers, or when the team already has a mature Terraform codebase. Use case Deploy an AWS Lambda function that processes files uploaded to an S3 bucket. Configuration - bucket name, log level, Lambda timeout - varies per environment (dev, staging, prod). Simple infrastructure by design - the CDK patterns are the point, not the resources. ...

AWS Kiro CLI - Manage AWS Infrastructure from the Terminal

Kiro CLI is an AI-assisted terminal tool for AWS, rebranded from Amazon Q Developer CLI in November 2025. It sits on top of your existing AWS credentials and tooling. The q and q chat shortcuts from Q CLI still work but kiro-cli is the current entry point. Install macOS brew install --cask kiro-cli Or via script: curl -fsSL https://cli.kiro.dev/install | bash Windows (PowerShell) irm 'https://cli.kiro.dev/install.ps1' | iex Linux / WSL2 (Ubuntu / Debian) - .deb ...

Posts

AWS CDK - CI/CD Pipelines

This is Chapter 5 of the Infrastructure as Code with AWS CDK series. The same cdk deploy command that runs locally works in any pipeline - the differences are auth and orchestration. Common flags for CI These apply regardless of which CI system you use: cdk synth # generate CloudFormation template cdk deploy --require-approval never -c env=prod # deploy without interactive prompts cdk deploy --outputs-file outputs.json # write stack outputs to file --require-approval never skips the IAM change confirmation that CDK shows interactively. Required in CI. ...

AWS CDK - Testing CDK Stacks

This is Chapter 4 of the Infrastructure as Code with AWS CDK series. Chapter 3 built FileProcessorConstruct - the tests here cover that construct and the stack it lives in. How CDK testing works CDK unit tests don’t deploy anything. They synthesize a stack into a CloudFormation template and run assertions against that template. No AWS credentials needed, and the suite runs in CI without any special setup. The aws_cdk.assertions module is already part of aws-cdk-lib - no extra install required. ...

AWS CDK - Writing and Sharing Constructs

This is Chapter 3 of the Infrastructure as Code with AWS CDK series. Chapters 1 and 2 put the S3 bucket and Lambda directly in MyStack. Both get extracted into a reusable construct here. L1, L2, L3 CDK organises constructs into three levels: L1 - raw CloudFormation resource wrappers, prefixed with Cfn. CfnBucket, CfnFunction. No defaults added - every property must be set explicitly. L2 - CDK’s built-in higher-level constructs. s3.Bucket, _lambda.Function. These set sensible defaults, expose helper methods, and handle IAM via grant_* methods. L3 - composite constructs you write that bundle multiple resources into a single unit. The previous chapters used L2 constructs directly inside a stack. This chapter builds an L3. The problem The current MyStack creates the bucket and Lambda directly: ...

AWS CDK - Managing Configuration and Context

This is Chapter 2 of the Infrastructure as Code with AWS CDK series. Four approaches to environment-specific configuration in CDK stacks - same use case throughout so the trade-offs sit side by side. Use case: An S3 bucket and Lambda function where bucket name, log level, and Lambda timeout vary per environment (dev, staging, prod). Quick comparison Approach Version controlled Supports secrets Change without redeploy Shared across stacks Static config (cdk.json) Yes No No No Dynamic config No Partial Yes No Secrets Manager No Yes Yes Yes CI/CD context injection No No Yes No Local dev patterns Suitable for personal projects or local development. Neither is a good fit for CI/CD pipelines or shared team environments. ...

AWS CDK - Project Setup and Bootstrapping

This is Chapter 1 of the Infrastructure as Code with AWS CDK series. Two things come before writing any stack code: initialising the CDK project and bootstrapping the AWS account. Prerequisites Python 3.9+ Node.js 18+ (CDK CLI is a Node package) AWS CLI v2 configured with valid credentials - see Connect to AWS SSO and SSH into EC2 Instance An AWS account with permissions to create IAM roles, S3 buckets, and CloudFormation stacks Install the CDK CLI globally: ...