Notes to self.

The AI side of my work kept producing notes worth keeping in one place - which AWS service to reach for, the concepts behind the choice, and what changes once you move from reading about Bedrock to building with it. Chapter 1 (Fundamentals) - concept-focused, assumes no prior AI/ML background. Chapters 2-3 (build) - assume Chapter 1 as background, hands-on with specific AWS services. Chapters land as the hands-on work behind them gets done, not on a fixed schedule. The series Chapter 1 - Fundamentals Algorithm types, performance metrics, AWS AI services, inference options, Bedrock vs SageMaker, and prompt engineering techniques - the concepts I kept returning to. ...

The Well-Architected Framework is one of the more useful things to have internalised for serious AWS work. It comes up in architecture trade-off discussions, CDK design decisions, cost justifications, security reviews - not as a formal checklist but as a consistent vocabulary for reasoning through decisions. I started writing notes to keep the structure clear and they grew into this series. The Well-Architected Framework whitepaper is the primary source behind all of it. First published in 2015 and updated regularly since, it formalised what AWS Solutions Architects were doing in customer workload reviews into a consistent, documented system. Every revision to the pillars - including the addition of sustainability in 2021 - and the full question set in the Well-Architected Tool originate here. If you work with the framework seriously, this is the document to read. The six pillars The pillars are the core of the framework. Each defines a set of design principles and best practices. AWS lists them in this order consistently across the whitepaper, documentation, and the Well-Architected Tool. ...

Architecture conversations kept surfacing the same decisions: how consistent does this need to be, where does it shard, what gets cached and at what level. I started keeping notes on the reasoning rather than the answers - the trade-offs that drive the design, not the design itself. Chapter 1 covers the vocabulary everything else in the series links back to: scalability, CAP theorem, consistency models, caching, sharding, and a 7-step framework for working through a design problem. Each subsequent chapter applies that vocabulary to a specific system: stated requirements, explicit trade-offs, and a final design. ...

I picked CDK over CloudFormation and Terraform for AWS-native infrastructure work - the ability to write real Python against AWS resources, with type checking and reusable constructs, made the rest of the tooling feel like a step backwards. These are the patterns I use in practice, covering Python CDK with a consistent use case across all chapters so the trade-offs are concrete rather than hypothetical. 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 The use case across all chapters: an S3-triggered Lambda with per-environment configuration varying across dev, staging, and prod. ...

CDK makes it easy to ship infrastructure fast. What I found running it in production is that a passing cdk synth is not the same as a safe deploy - there are four categories of risk a standard CI/CD pipeline leaves unchecked: IaC policy violations, CloudFormation template errors, application code quality issues, and vulnerable dependencies. Each one has a tool that catches it at build time. cdk-nag is the only CDK-specific tool - the others work with any CI/CD pipeline. ...

The Kubernetes Fundamentals domain in my KCNA study notes covers the architecture and core resources at a conceptual level - this series goes one layer deeper, into the actual objects and kubectl commands behind those concepts. This series is the companion to Docker Fundamentals, one level up the stack - it assumes that Docker layer (containers, images, the container runtime) and builds the Kubernetes object model on top of it. A throwaway cluster (minikube, kind, or a Killercoda sandbox) is the only prerequisite; none of this needs a managed cloud Kubernetes service to follow along. The series Chapter 1 - Kubernetes Architecture The control plane and node components - kube-apiserver, etcd, kubelet, the controller manager, and the scheduler - and what each is actually responsible for. ...