Section 1 · Cloud Fundamentals
What the Cloud Is (and Isn't)
12 min3 min readChoose wisely
Lesson at a glance
Describe what a cloud provider actually sells, what moving to AWS fixes and what it leaves for you, using Lantern’s one-server setup as the case study.
No video here — just the real thing: a written lesson, runnable examples, a quiz and practice.
Lantern is a community events website. Organisers post events, people RSVP, and every event has a poster image. Today it runs on one rented server: a Node.js app, a PostgreSQL database and a folder of uploaded posters, all on the same disk. A nightly cron job copies the database dump to, yes, that same disk.
It has worked for three years. Then a street-food festival got shared widely, traffic jumped twenty-fold for an evening, the server ran out of memory, and the site went down at exactly the moment it mattered. Two weeks later the disk filled up with poster uploads and the database refused writes. Lantern’s maintainers want to move to AWS, and this course is that move, done properly.
What you are actually renting
A cloud provider sells capacity and services that you create, change and delete through an API, and pay for by usage. Behind every console button is an API call, which is why everything you click in this course you can also script.
That capacity comes at different levels of “how much do you manage”:
| You get | AWS example | You still manage |
|---|---|---|
| A virtual machine | Amazon EC2 | OS patches, runtime, app, scaling |
| A managed database | Amazon RDS | Schema, queries, who can connect |
| A function that runs on demand | AWS Lambda | Your code and its permissions |
| Object storage | Amazon S3 | What you store and who can read it |
The further down the table you go, the less undifferentiated work you do, and the more you are shaped by how that service works.
What the cloud isn’t
It isn’t automatically reliable. If you copy Lantern’s single server onto a single EC2 instance, it fails exactly as before: one machine, one disk, one place. AWS makes the better design cheap to build; it doesn’t build it for you.
It isn’t automatically cheaper. You pay for what you provision, not what you use well. A forgotten test database runs all month. Data sent out to the internet is metered. Many small teams move to AWS and get a surprise bill in month two because nobody set a budget.
It isn’t automatically secure. AWS secures the buildings, hardware and the software that runs its services. You decide who can sign in, what each piece of code may touch, and whether a bucket is private. Lesson three makes that split precise.
How this course runs
You will follow Lantern from a bare account to a production setup. Section one covers where AWS runs your things, who is responsible for what, and how to lock the account down and drive it from the terminal. Section two is identity: who and what may do which actions. Section three picks the right compute, storage, database and network pieces. Section four builds and ships the new Lantern, then measures it.
Two habits run through every lesson. Before you create anything, ask “what will this cost while it sits there?” and “who can reach it?” If you can answer both, you understand the design. Next up: where, physically, all of this runs.
Key takeaways
- The cloud is rented computing capacity and managed services that you create, change and delete through an API, and pay for by usage.
- Moving to AWS removes hardware chores but not design work; a single server in AWS fails in exactly the same ways as a single server anywhere else.
- AWS bills by the second, hour, gigabyte or request, so anything you leave running keeps costing money until you delete it.
- Security in the cloud is shared; AWS secures the data centres, and you secure what you configure and upload.