// Linux, servers and cloud
What is AWS, explained for parents
Amazon Web Services in plain language: what the cloud is, who uses it, and what a 14 year old can safely build in a sandbox we pay for, with a spending limit.
Amazon Web Services, usually shortened to AWS, is the world's largest cloud computing platform. The idea is simple: instead of buying a server and running it yourself, you rent computing from Amazon by the second. You use what you need, pay only for that, and hand it back when you're done. Amazon launched the service in 2006, opening up the internal infrastructure it had built for amazon.com to outside customers.
Today a large share of the internet runs on AWS. When you stream a film, check your bank balance, or book a flight, there is a reasonable chance that request passed through one of Amazon's data centres. The platform covers storage, databases, computing power, and hundreds of specialised services, but the underlying logic has not changed since 2006: rent what you need, stop when you don't.
This guide explains what that means in plain terms, who uses it, and what your child actually does when they work with AWS at 14, inside a sandbox the club owns and pays for.
What 'the cloud' actually means
The cloud is not a mystical place where data floats. It is a network of very large data centres, mostly owned by Amazon, Microsoft, and Google, which rent out computing resources over the internet. You pay a fraction of a penny per second for a piece of that capacity, use it, and release it. No hardware to buy, no server to maintain.
The word 'cloud' became common because diagrams of the internet used to draw the network as a cloud shape, representing everything in between you and the other end that you don't need to think about. It stuck.
What this changes for software developers is significant. Before the cloud, putting a website on the internet meant buying a server, renting a full machine for a fixed monthly fee, or using a shared hosting service with strict limits. The cloud let developers spin up as little or as much computing power as they needed, for as long as they needed it. A small personal project and a large commercial service now run on the same infrastructure; they just use different amounts of it.
Why AWS, and who uses it
Amazon launched AWS in 2006, starting with a storage service and a computing service sold separately. The idea came from Amazon's own engineering teams, who had spent years building internal tools to manage the computing infrastructure behind amazon.com. They realised those tools had value beyond Amazon and opened them to outside customers.
AWS now operates data centres across dozens of locations worldwide, with a regional cluster in London (eu-west-2). The customer list covers startups, large companies, and public-sector organisations. The UK government uses AWS for several national services. Companies you use daily run significant parts of their infrastructure there.
The reason it became the default starting point for developers is partly timing and partly breadth. By the time competitors launched comparable services, AWS had years of documentation, tooling, and customer experience behind it. For a teenager learning cloud computing today, AWS is the natural place to begin: the concepts transfer to other platforms, but the largest volume of documentation, employer experience, and job advertisements points here.
What a 14 year old does inside a sandbox
At 14, your child joins the Advanced level of the programme. The second module is Cloud on AWS, running over six weeks (or twelve weeks on the once-weekly plan). During it, your child works inside a sandbox account the club owns and funds.
The setup is specific. One AWS account covers the whole group, not one account per child. Every student gets their own login inside that account, with a permission set restricted to the services the module uses. They cannot create accounts, cannot access other AWS regions, and cannot touch anything outside the module's scope. A policy pins every action to the London region (eu-west-2), so nothing can accidentally run anywhere else in the world.
A £10 budget alert sits on the group account with a hard stop: when the group reaches £10, the account stops accepting new resource creation. In practice the module stays well within the always-free usage allowances for the services used, so the £10 limit is a safety net rather than a ceiling you'd expect to hit. The club budgets under £2 per child for the full module.
At the end of every session, a nightly cleanup removes all resources the students created. Nothing persists after the session ends. No configuration drifts, no forgotten running services, no unexpected costs the following morning.
What they build
The module's final deliverable is a small working application that runs in the cloud. Your child builds it piece by piece across twelve sessions.
They start with storage: a place to put files that the internet can read. Then they add a small function that answers requests. This piece of code runs only when someone calls it, then stops. It doesn't sit idle all day waiting; it starts, does its job in milliseconds, and finishes. This is how a large part of modern web software is built.
They connect a front door to that function, a URL the public internet can reach, which routes requests to the function automatically. They add a database to store information between requests, so the app remembers things from one visit to the next. By the end of the module they have a complete, running app: put a URL in a browser, it returns something, and the data behind it persists.
They also do a cost review with the group, reading through what the module actually spent and working out where every penny went. This is deliberate: understanding what cloud services cost is part of how engineers make decisions, and your child leaves the module having read a real bill rather than just having been told the number.
Your child's name is on none of it
Your child never holds an AWS account themselves. They never see a credit card number, a root password, or a billing email. The club owns the AWS organisation, owns the accounts, and receives the bills. This is not a workaround; it is the intentional design. The account model is described in the curriculum: no per-child AWS accounts, no credit cards, no access outside the module's scope.
The two people who run Builders Club, Ismail and Sami, both work as engineers at AWS. Ismail works in applied AI and machine learning; Sami works in platform engineering. They wrote the curriculum and teach every session. The club's AWS setup is entirely separate from their employer accounts: the club holds its own organisation on a club email address, and Amazon does not endorse or sponsor the programme.
AWS pricing can feel opaque if you have never used it. The short version: most services charge per request, per unit of data stored, or per unit of computing time consumed. At the scale of a small student group, several services fall within AWS's always-free tier, meaning the cost is genuinely zero. The club budgets under £2 per child for the full module and the £10 group budget alert is the hard ceiling, enforced automatically.
What Builders Club does with AWS
From 14, your child deploys to Amazon Web Services in a sandbox we own and pay for, ships code the way engineering teams do, and builds an AI tool that answers questions from their own notes.
Cloud on AWS is the second of six modules at Advanced level. The fourth and fifth modules apply the same infrastructure to building an AI product end to end: a chatbot that answers questions from your child's own notes, tested against a set of questions scored by an AI judge, then published at a club address with rate limits and a spending cap.
Sessions are 90 minutes, live, in a group of 6 to 8. The first session is free. Advanced costs £55 a session, billed monthly. Two engineers who work at AWS write the curriculum and teach every session. The club's AWS accounts are separate from their employer accounts, and Amazon has no involvement in or endorsement of the programme.