Distributions

Right, so you’ve got your CloudFront distribution set up. It’s serving your site, caching your assets, and generally feeling pretty snappy. Now, let’s talk about how to not get pwned. Because a fast website that’s also a gaping security hole is just a liability on amphetamines. We’re going to lock this down properly, and I’ll explain the why behind each step so you’re not just cargo-culting configs. HTTPS: No Exceptions, No Negotiation This isn’t 2012. HTTPS is not an optional nice-to-have; it’s the absolute bare minimum. The internet is a sketchy alleyway, and HTTP is shouting your credit card details down it. CloudFront makes this stupidly easy to enforce.

Alright, let’s talk about CloudFront Functions. You’ve heard of Lambda@Edge, right? Its powerful, do-anything older sibling that can run for up to a second and change almost everything about a request? This isn’t that. CloudFront Functions are the scrappy, hyper-caffeinated cousin. They’re for the small, screamingly fast jobs that need to happen on every single request without adding a millisecond of latency. We’re talking sub-millisecond execution. They are the Usain Bolt of the edge compute world: blindingly fast, but they can’t carry a lot of luggage.

Right, so you’ve decided you want your code to run closer to your users than your origin server. Smart move. Welcome to Lambda@Edge, the feature that lets you shove little bits of Lambda logic into the vast, globe-spanning nervous system of CloudFront. The promise is intoxicating: run your code in dozens of locations worldwide, single-digit millisecond latency, no provisioning servers. The reality is… almost that, but with some very important, often hilarious, caveats. Buckle up.

Right, let’s talk about locking down your S3 bucket when CloudFront is your front door. This is one of those things AWS makes sound complicated, but the core idea is beautifully simple: your S3 bucket should be a hermit that only accepts calls from its one trusted friend, CloudFront. Everyone else—including users with their own AWS credentials—gets the door slammed in their face. We used to do this with an Origin Access Identity (OAI), which was basically a special IAM user. Now, we use the newer, shinier, and frankly more secure Origin Access Control (OAC). OAC uses IAM roles, which is the modern, preferred way for services to talk to each other in AWS. Consider this an upgrade.

Right, so you’ve built something brilliant, and now you want to put it behind a velvet rope. Maybe it’s a premium video course, a paid report, or a members-only cat meme repository. The point is, you need to serve content from CloudFront but only to people who have paid the bouncer. This is where Signed URLs and Signed Cookies come in. They’re two sides of the same coin, both using cryptographic signatures to grant temporary access. The choice between them isn’t about security—they’re equally secure—it’s about the user experience you’re trying to create.

Right, let’s talk about getting your fresh content to the world, or more accurately, getting the old, cached content out of the world. This is cache invalidation, one of the two hard problems in computer science (the others being naming things and off-by-one errors). CloudFront is a brilliant, global-scale caching machine, and like any good cache, it holds onto things. Your job is to tell it when to let go.

Right, let’s talk about the part of CloudFront where you actually get to think: Cache Behaviors. This is where you move from just slapping a CDN in front of your stuff to actually architecting how it behaves. It’s the difference between a bouncer who just checks IDs and one who knows the regulars, the VIPs, and the troublemakers who need a different door. The core idea is simple but powerful: you can tell CloudFront to handle different types of requests differently based on the path pattern. A request for /api/graphql should probably behave very differently than one for /images/cat_picture_1024.jpg. Behaviors let you do that. You create a list of these behaviors, ordered from most specific to least specific (that default * catch-all we talked about last time), and CloudFront walks down that list until it finds a match.

Right, so you’ve told CloudFront where to send your users (the distribution), and how to handle their requests (behaviors). Now we get to the heart of the matter: the Origin. This is the actual, honest-to-goodness source of your content. It’s the server CloudFront goes to, hat in hand, when its own cache is empty. Think of it as CloudFront’s supplier. And just like in the real world, your choice of supplier dictates everything about quality, price, and how much of a headache you’re in for.

Right, let’s talk about CloudFront distributions. This is where you stop thinking of CloudFront as a magic box and start treating it like the complex, configurable beast it is. The first thing you’ll hit when you create one in the console is a choice that seems bafflingly ancient: Web or RTMP. Let’s be direct: you almost certainly want “Web Distribution.” It’s for the modern web—HTTP(S) traffic, your website, your APIs, your static assets. RTMP is a relic, a streaming protocol from the Adobe Flash era. AWS still offers it because, well, someone somewhere is still running a Flash-based video service and paying them a fortune for the privilege. It’s the technical equivalent of a museum exhibit. Let’s move on.

Right, let’s cut through the noise. The single biggest factor that will determine your daily relationship with your operating system isn’t the desktop environment or the package manager—it’s the release model. Get this wrong, and you’ll either be bored to tears or constantly putting out fires. Get it right, and your system hums along, getting out of your way so you can do actual work. We’re essentially talking about three philosophies for how an OS gets new software: the cautious, the bleeding-edge, and the middle-ground. Your choice here dictates your maintenance schedule, your tolerance for breakage, and frankly, your blood pressure.

Alright, let’s cut through the noise. Choosing a distro isn’t about finding the “best” one; it’s about finding the right tool for the job. You wouldn’t use a sledgehammer to put a picture hook in the wall, and you shouldn’t use a server-optimized distro for your grandma’s web browsing. The workload dictates the choice. Let’s break it down by the big four categories. Desktop: The Daily Driver This is your primary interface with the machine. Your priorities here are stability (or the latest shiny things, if that’s your jam), hardware support, and a smooth user experience. You want things to just work so you can get actual work done, not spend your weekend debugging your graphics driver.

Alright, let’s get into the weeds on some of the more… distinctive distros. These aren’t your point-and-click, install-it-while-you-make-a-sandwich operating systems. They’re for when you have Opinions™ about how your computer should work and you’re willing to put in the sweat equity to make it happen. They’re brilliant, they’re powerful, and they will absolutely hold your build process hostage for hours if you look at them wrong. Gentoo: The Ultimate Customization If you’ve ever looked at a binary package and thought, “I bet I could compile this 15% faster if I used -march=native and stripped out this garbage I don’t need,” then Gentoo is your spiritual home. It’s a source-based distribution, which means you compile everything from scratch on your own machine. Yes, everything.

Alright, let’s talk about Alpine Linux. You’ve probably seen its name flash by when pulling a Docker image. docker pull nginx:alpine. It’s the distro that shows up to the party wearing a sleek black t-shirt while everyone else is in a full three-piece suit, sweating under the weight of their own pre-installed crap. Its entire reason for being is to be small, simple, and secure. It achieves this through a few, frankly, brilliant but sometimes annoying design choices.

Alright, let’s talk about Arch. I need you to forget everything you’ve heard about it being the “hard” Linux distro for neckbearded wizards. That’s a side effect, not the goal. Arch is about something far more seductive: understanding. It’s a rolling-release distro built on a philosophy called The Arch Way, which is a fancy way of saying they refuse to hold your hand or make decisions for you. You are the architect. This is terrifying and glorious in equal measure.

Alright, let’s talk about the Red Hat family. This is where things get serious, and also a little bit… corporate. But don’t worry, we’re going to navigate this together. You’re looking at the ecosystem that runs the financial backbones of the world, and it’s built on a surprisingly elegant, if sometimes frustrating, system of dependencies and promises. At the heart of it all is Red Hat Enterprise Linux (RHEL). Think of RHEL not as a piece of software, but as a product. And a very, very expensive one. You don’t buy RHEL for its cutting-edge features; you buy it for its unwavering stability, its decade-long support lifecycles, and, most importantly, its support contracts. When your multi-million dollar trading platform goes down at 3 AM, you don’t file a bug report on GitHub; you call Red Hat and their SREs get on a bridge call with you. That’s what you’re paying for. The software itself is hardened, meticulously tested, and famously boring. And in the enterprise world, boring is beautiful.

Right, let’s talk about the granddaddy of them all and its wildly successful, slightly more user-friendly offspring. Debian and Ubuntu aren’t just distributions; they’re a philosophy. And that philosophy, in a word, is stability. But as we’ll see, that word means something very specific here, and it comes with trade-offs you need to understand. The Debian Bedrock: A Fortress of Solitude Debian is the rock upon which Ubuntu is built. It’s the project so committed to its ideals of free software and rigorous stability that its releases are famously… let’s call them deliberate. The “Stable” branch of Debian is exactly that: a frozen, meticulously tested fortress. When you install Debian Stable, you’re getting software that was, in many cases, already a year old when the release was made. It’s not outdated; it’s curated. It’s the software equivalent of a master craftsman’s tool that doesn’t break, ever, because all the bugs have been hammered out over the last two years.