AWS for Dummies: Notes Part 1

I've spent a large part of my career fumbling through various AWS services, from side projects and experiments to production environments. My latest foray into deploying a containerized Next.js application into production (not this blog, here I am taking the easy out and using Vercel) lead me to finally take a real course and attempt to get certified as an official AWS Cloud Practitioner. The goal is to finally understand a bit more about what is really happening with all these services. Below are some findings that have stood out to me thus far...
Regions and Availability Zones
I've been familiar with the concept of regions, but the course has shed some light on how each region is distinct both geographically and in terms of the services offered. Not every AWS service is available in every region. China is a whole different story.
Each region is broken up in "Availability Zones" in an attempt to add some level of redundancy and fault tolerance. This includes the water and power sources for the various data centers. Pretty interesting.
Roles and Permissions
It's been interesting to dig a bit more into the maelstrom of ways you can configure permissions across AWS services. It's truly daunting. The course has colored in some background on past production issues I've had, namely problems with not being able to perform a certain operation on a certain resource (can't write to a given S3 bucket, for example)
Billing
This is boring, but it's quite true that you need to watch your ass when it comes to AWS and prices. I feel like the average director of an Eng or Ops organization spends half their time just trying to get the monthly AWS bill down.
Weird Services
AWS has all sorts of services beyond the scope of a standard web application. You can rent time on a quantaum computer at UC Berkeley. Ground Station is a service that facilitates data transmission to and from satellites. Outposts are physical server racks that are managed by AWS but kept on a company's property for whatever legal reasons...
API / CLI / SDK
It occurs to me that I have communicated with / configured AWS via scripting in at least 4 different programming languages as well as the CLI, the GUI Console, Cloud Formation and Terraform. Phew. Also, AWS provides the Cloud9 interface in the console that spins up an environment and editor and comes provisioned with whatever permissions the account creating it has. Cool.
CloudFormation vs Cloud Development Kit
This is an interesting one. I'm somewhat familiar with these two patterns for Infra-As-Code. Mostly this boils down to Terraform advocates talking shit on the AWS CDK and vice versa. My takeaway from the course thus far is that CloudFormation is more declarative whereas the CDK is imperative.
More to come...