The Elastic Frontier, 2006

What you will do

1. list the regions this provider operates in cloud region list

   The biggest provider, AWS, launched its object store in March 2006 and elastic compute that August (dates specific to AWS's own history). But the "region" concept those launches introduced, a self-contained cluster of data centers in one geography, has been the first building block of every cloud platform since.

2. inspect one region and the availability zones inside it cloud region show us-east

   A region is not one building — it is several, kept separate on purpose. Group everything in one and a single flood, fire, or fiber cut can take your whole app down.

3. list the availability zones (AZs) inside a region cloud zone list us-east

   Each AZ is a physically distinct facility with its own power and networking, linked to its siblings at low latency. Spread instances across AZs and one AZ's outage does not take the app down.

4. set your default region for future commands cloud configure --region us-east

   Data residency, latency, and price all vary by region. Picking one is the first decision on every real cloud account — and the one most often made wrong by picking whatever is closest to home.

5. see the three basic ways cloud compute gets priced cloud pricing models

   On-demand: pay by the hour, no commitment. Reserved: commit 1-3 years for a steep discount. Spot: bid on spare capacity for the cheapest price — and the risk it's reclaimed on short notice.

6. see the core value proposition of cloud vs owning your own hardware cloud benefits

   Capex became opex: no more buying servers for peak load you use three days a year. Elasticity means provisioning in minutes what once took a purchase order and a six-week lead time.

7. see the shared responsibility model — what the provider secures vs what you do cloud responsibility

   The provider secures OF the cloud: data centers, host hardware, network backbone. You secure IN the cloud: your data, your IAM policies, your bucket permissions. Most real breaches are a customer-side misconfiguration, not a provider failure.

8. create an object storage bucket cloud bucket create demo-bucket

   Object storage has no folders or drive letters — just a flat namespace of keys inside a bucket, served over plain HTTP. This made object storage the default way the internet stores files, starting in 2006.

9. list the buckets in your account cloud bucket list

   Bucket names live in a shared namespace scoped by the platform: pick one and it is yours across the whole account, not one project alone.

10. upload an object into a bucket cloud bucket upload demo-bucket index.html

    Every object gets a checksum (an ETag) on upload — the same content uploaded twice produces the same ETag, which is how a client detects a no-op re-upload.

11. list the objects stored inside a bucket cloud bucket ls demo-bucket

    A bucket listing is itself an API call with a cost and a rate limit — at scale, listing millions of objects is a real engineering problem, not a free "ls".

12. check a bucket's access policy — buckets are private by default cloud bucket policy demo-bucket

    New buckets deny public access by default. Nearly every "we accidentally exposed our data" headline starts with someone deliberately turning that default off — and forgetting to turn it back.

13. launch a virtual machine instance cloud vm run web1 --type small

    AWS launched elastic compute in August 2006 with one instance size and an hourly rate — a vendor-specific milestone. But every provider's instance types since are descendants of that first idea: rent a server by the hour, not by the multi-year lease.

14. list your running (and stopped) virtual machines cloud vm list

    A stopped instance is not free: the attached storage volume persists and keeps billing. Only a full teardown stops every charge.

15. connect to a running instance over SSH cloud vm ssh web1

    Cloud VMs ship with no password login by default — key-based SSH only. A small default with an outsized security effect: no brute-forceable password ever touches the network.

16. stop a virtual machine instance cloud vm stop web1

    Stopping releases the compute you are billed for, but the disk volume stays attached and keeps costing money until you delete it too.

17. create a load balancer in front of an instance cloud lb create web-lb --target web1

    A load balancer gives you one stable address in front of instances that come and go — the cloud equivalent of the problem a Kubernetes Service solves for pods.

18. create an IAM role — an identity a workload can assume, not a person cloud iam role create app-role

    A role has no permanent password or key to leak. A workload assumes it, gets short-lived credentials, and those credentials expire — the single biggest upgrade over hardcoding a long-lived key.

19. list the IAM roles in this account cloud iam role list

    Auditing "who can do what" starts here — a role's NAME tells you nothing; you always have to check its attached policies.

20. attach a least-privilege policy to a role cloud iam policy attach app-role storage-read-only

    Least privilege: grant only the exact permissions a workload needs. storage-read-only cannot delete a bucket even if the process running it is fully compromised — the blast radius is designed in advance.

21. inspect exactly which policies a role has attached cloud iam role show app-role

    Overly broad IAM policies are one of the most common real-world cloud misconfigurations. "show" is the command that catches a role that quietly accumulated far more access than it needs.

22. require multi-factor authentication on the account cloud iam mfa enable

    A stolen password alone should never be enough. MFA is the cheapest control against account takeover — and the one most breach post-mortems wish had been turned on.

23. deliberately make a bucket publicly readable — and understand the tradeoff cloud bucket policy demo-bucket public-read

    public-read is a real, sometimes correct choice — static sites and public downloads need it. The failure mode is never using it deliberately; it is using it on a bucket that also holds something private.

24. create a security group — a virtual firewall attached to instances cloud security-group create web-sg --allow 22,80,443

    Security groups are stateful and default-deny: nothing is reachable until explicitly allowed. Opening only 22/80/443 instead of "allow all" is the whole difference between a hardened box and an open one.

25. see the compliance frameworks a mature cloud provider is typically audited against cloud compliance list

    SOC 2, ISO/IEC 27001, PCI DSS — a provider passing these audits proves ITS controls; it says nothing about how YOU configured your own account. Compliance is inherited for the platform, never for your mistakes.

26. estimate the monthly cost of a running instance before you commit cloud billing estimate --vm small --hours 720

    720 hours is a full 30-day month. Estimating cost before launching, instead of discovering it on next month's invoice, is the habit that separates a stable cloud budget from a surprise five-figure bill.

27. view an itemized bill broken down by service cloud billing show

    Storage, compute, and data transfer are billed completely separately — and transfer OUT to the internet is usually the line item people forget to budget for.

28. tag a resource for cost allocation cloud cost tags apply demo-bucket project=academy

    Without tags, a bill is just one big number. Tag every resource by project/team/environment and the same invoice becomes an answerable question: which team actually spent this?

29. load the boss scenario — deploy a real static site, end to end scenario start

    The performance-based check: no more single commands in isolation — create the bucket, upload the content, open access correctly, point DNS at it, and prove it is actually live.

30. create the bucket that will host the static site cloud bucket create sitebucket

    Static hosting on object storage was one of the earliest "wait, we can build a whole product on this" use cases — no web server to patch, no OS to manage.

31. upload the site's index page into the bucket cloud bucket upload sitebucket index.html

    A static site is nothing more than files an object store can already serve over plain HTTP — the "server" is really just the storage layer with a policy attached.

32. open the bucket to public-read so browsers can actually load the page cloud bucket policy sitebucket public-read

    This is the ONE bucket where public-read is exactly correct — the site cannot load in a browser without it. Context, not the setting itself, is what makes a policy safe or dangerous.

33. point a DNS record at the bucket cloud dns add launchpad.servbg-academy.test sitebucket

    DNS is the last mile: without a record pointing at it, a perfectly public, perfectly hosted bucket is still unreachable by name — just an anonymous URL nobody can find.

34. Boss missionFINAL STEP — verify the whole site is actually live: bucket, content, policy, and DNS all correct together cloud site check launchpad.servbg-academy.test

    Diagnose nothing here — build it right and prove it: bucket exists, object uploaded, policy public, DNS resolved. That is the entire "ship a static site" job, the same loop whether it is a hobby blog or a landing page at scale.

Certificate

Nearby eras

All 25 eras in the Terminal Academy