In Part-4 we clicked through the launch wizard once. In Part-10 we needed the same configuration for every instance an Auto Scaling group creates, and the answer was a launch template - we created one quickly and moved on. This post is the deep dive it deserves, because the launch template is the thing that turns …

Every EC2 instance in this series so far was On-Demand - you pay the list price per second and nobody takes it away. Spot Instances are the same hardware, the same AMIs, the same launch templates, for up to 90 % less - with one condition: Amazon EC2 can take the instance back with two minutes notice when it needs the …

This is Part-1 of my AWS step-by-step series, and it starts where every AWS account should start - with IAM (Identity and Access Management). You have just created an AWS account, you are logged in as the root user, and the very first thing to do is to stop using it. In this post we are going to create an IAM user, …

Everything up to now ran on EC2 instances that you launch, patch, scale and pay for while idle. AWS Lambda removes the server: you upload a function, AWS runs it when something invokes it, scales it from zero to thousands of parallel executions, and bills you per millisecond. This Part-17 covers the three features …

We created a NAT Gateway in Part-5 in one step and moved on. It deserves its own part, because the NAT Gateway is the component every private subnet depends on, it is the first surprise on most AWS bills, and the three most common "my instance cannot reach the internet" tickets all end at it. This Part-14 …

In Part-10 we used an Application Load Balancer, and for a web application that is the right default. But every so often the requirements say "the customer needs a fixed IP to allow-list", "it is not HTTP, it is MQTT on port 8883", "we need a million connections per second", or "we …

In Part-1 we created IAM users inside one AWS account. Sooner or later - usually the first time a developer deletes something in production while "just testing" - you realise that one account is the wrong unit. The AWS answer is AWS Organizations - many accounts (dev, test, prod, security, sandbox) under one …

In Part-19 we were the consumer - we created interface endpoints to reach AWS services privately. This Part-20 flips the table: we are the provider. We have an application in our VPC and want other VPCs - other teams, other accounts, customers - to reach it privately, without VPC peering, without exposing it to the …

We have been creating security groups since Part-4 without really stopping to look at them - allow SSH from my IP, allow HTTP from anywhere, next. In this Part-16 the security group gets the full treatment, because it is the one piece of AWS networking you will touch every single day, and because a surprising amount …

Part-12 ended with the problem - VPC peering is point-to-point and not transitive, so ten VPCs need 45 peering connections, and none of them can share a VPN to the office. AWS Transit Gateway is the fix: a regional router you attach every VPC, VPN and Direct Connect to once, and then control who reaches whom with …