馃搶 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 the ability to share constructs across teams as libraries. This series works through practical CDK patterns using Python, using a consistent use case across all parts to make trade-offs easy to compare. 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). 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). 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 focus is on the CDK patterns, not the resources. ...
Posts
GitHub PR Fix: "Commits must have verified signatures" blocking PR merge
Problem GitHub branch protection requires all commits to have verified GPG signatures. Two commits at the base of the branch (made before GPG signing was configured) were unsigned, blocking the merge. Root cause Commits made before commit.gpgsign=true was configured in git have no GPG signature. GitHub requires all commits in a PR to be verified - one unsigned commit blocks the merge regardless of approvals. Steps to fix 1. Identify unsigned commits git log --format="%G? %ad %s" --date=short origin/main..HEAD Look for lines starting with N (no signature). Note the hash of the oldest unsigned commit鈥檚 parent on main. ...
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. This chapter pulls them out into a reusable construct. 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鈥檚 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. This covers four approaches to managing environment-specific configuration in CDK stacks, using the same use case throughout so the trade-offs are easy to compare. 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 Local static (cdk.json) Yes No No No Local dynamic No Partial Yes No SSM Parameter Store No No Yes Yes Secrets Manager No Yes Yes Yes Approach 1 - Local static config (cdk.json) Store environment-specific config in cdk.json under the context key. CDK reads this file automatically at synth time. ...
AWS CDK - Project Setup and Bootstrapping
This is Chapter 1 of the Infrastructure as Code with AWS CDK series. Before writing any stack code, the project needs to be initialised and the AWS account needs to be bootstrapped. This covers both. 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: ...
Install CloudWatch agent in EC2 Instance
EC2 does not send memory or disk metrics to CloudWatch by default - only CPU, network and status checks. The CloudWatch agent runs inside the instance and collects system-level metrics and logs directly. Prerequisites EC2 instance running (Amazon Linux 2 or Ubuntu) SSH access to the instance - see Connect to AWS SSO and SSH into EC2 Instance Terminal Attach IAM role to the instance The agent needs permission to write metrics and logs to CloudWatch. In the AWS console: ...