1.6 AWS Support Plans: Developer, Business, Enterprise On-Ramp, Enterprise

Right, let’s talk about AWS Support. This is where you decide how much hand-holding you want, or more accurately, how much you’re willing to pay for someone at AWS to throw you a rope ladder when you’ve built your own trap and fallen into it. It’s not a feature; it’s an insurance policy and a concierge service mashed into one. The fundamental, often painful, truth is that the free support you get on the Basic plan is essentially “you can read the docs and use the forums, good luck.” For anything resembling a real workload, you’re going to need to open your wallet.

1.5 Service Quotas and How to Request Increases

Right, let’s talk about the one thing that will absolutely, positively stop your cloud party faster than a bill from a five-day crypto-mining bender: service quotas. You used to call them “limits,” which was a much more honest and slightly threatening term. AWS softened it to “quota,” probably after a marketing intern had a panic attack. Don’t be fooled. It’s a limit. It’s the bouncer at the club saying, “Nope, not tonight.”

1.4 AWS Management Console, CLI, SDK, and CloudShell

Right, let’s talk about how you actually talk to AWS. You’ve got four main avenues: the polite GUI, the powerful CLI, the programmable SDKs, and the convenient CloudShell. Think of them as a ladder of automation. You’ll start by clicking around the Console to get the lay of the land, but you’ll quickly want to graduate to scripting with the CLI and SDKs to stop doing the same tedious clicks over and over. Your future self, who wants to sleep through the night instead of manually rebooting instances, will thank you.

1.3 AWS Accounts, Organizations, and the Management Account

Right, let’s talk about the thing you just signed up for: your AWS account. It feels a little like getting a set of keys to a vast, empty, and slightly expensive warehouse. It’s just you in there, and you can do anything. This is both the best and worst thing about it. The power is intoxicating, the potential for catastrophic billing is very real. So before you start launching a hundred c7g.metal instances to see how fast they can mine Bitcoin (don’t), we need to talk about structure. Because no one stays a solo act for long, and AWS knows it.

1.2 The Shared Responsibility Model: AWS vs Customer

Alright, let’s cut through the marketing fluff and talk about the single most important concept in all of AWS: the Shared Responsibility Model. Think of it not as a partnership, but as a very clearly defined property line. AWS is responsible for the security of the cloud—the infrastructure, the hardware, the global network. You, my friend, are responsible for security in the cloud—what you put on that infrastructure and how you configure it.

1.1 AWS Global Infrastructure: Regions, Availability Zones, and Local Zones

Right, let’s talk about the physical reality of the cloud. Because despite the marketing, it’s not magic. It’s a colossal collection of buildings, computers, and fiber optic cables spread across the planet. AWS has meticulously organized this planetary-scale nervous system into a hierarchy you absolutely must understand. Get this wrong, and you’re not just architecting poorly—you’re lighting money on fire while your application sulks in the corner. The Continent: AWS Regions An AWS Region is a separate geographic area, like us-east-1 (North Virginia) or eu-west-1 (Ireland). Each region is a completely isolated set of infrastructure. They don’t share anything that would cause a failure in one to cascade to another. This is your primary tool for disaster recovery and data sovereignty.

— joke —

...