Lantern’s old host had a short answer to “who keeps this secure?”: the maintainers did everything above the power socket. AWS splits the job. Knowing exactly where the split falls tells you what you can stop worrying about, and what you can never hand off.
\nAWS calls this the shared responsibility model. AWS is responsible for security of the cloud: data centres, guards, hardware, the global network, the virtualisation layer, and the software that runs each managed service. You are responsible for security in the cloud: your data, who can access it, how you configure each service, and the code you deploy.
\nThe line is not fixed. It moves with how managed the service is.
\nOn EC2 you patch the operating system, exactly as on Lantern’s old server. On RDS, AWS patches the database engine and OS during a maintenance window you choose, but your schema, users and network access are yours. On Lambda, AWS keeps the runtime and OS patched, and you own the code and every package you bundle with it. The top row never moves: your data and who can reach it are always your job.
\nA new account is the most dangerous moment, because the only identity is the all-powerful root user. Here is the setup Lantern uses, in order.
\nAt sign-up, AWS (as of 2026) offers a Free plan and a Paid plan. Both start with promotional credits, and both include monthly free usage for over thirty services. The Free plan guarantees no charges, but limits you to selected services and closes the account after six months or when the credits run out, unless you upgrade. The Paid plan unlocks everything and bills you for usage beyond the credits. Use the Free plan to learn; Lantern’s production account is on the Paid plan, which is exactly why the budget in step 4 matters.
\nThe root user is the email address you signed up with. It can change billing details and close the account, and IAM policies cannot restrict it. AWS requires MFA on root users; register a passkey or security key if you can, because they resist phishing in a way that six-digit codes do not. Never create access keys for root. After setup, you sign in as root only for the handful of root-only tasks, such as turning on IAM user and role access to billing information in the account settings, so that your admin identity can see costs.
\nDaily work happens as a separate identity. For a single standalone account like Lantern’s first one, that is an IAM user with console access, a strong password, its own MFA, and membership of an Admins group that has the AdministratorAccess managed policy. Section two explains every one of those words, and how teams with several accounts use IAM Identity Center instead.
In AWS Budgets, create a monthly cost budget at an amount that would worry you, say 20 USD, with email alerts at 80% of actual spend and at 100% of forecasted spend. The forecast alert matters: it fires early in the month when the trend says you will overshoot. Under the hood a budget is a small JSON document:
\n{\n \"BudgetName\": \"lantern-monthly\",\n \"BudgetLimit\": { \"Amount\": \"20\", \"Unit\": \"USD\" },\n \"TimeUnit\": \"MONTHLY\",\n \"BudgetType\": \"COST\"\n}Under account settings, add a security contact and a billing contact. When AWS detects something suspicious, such as leaked credentials, it emails them. On a one-person project those emails easily land in a forgotten inbox.
\n\nThe account is safe to use. Next you will drive it from the terminal with the AWS CLI v2 and prove which identity you are using.
\n","toc":[{"id":"sec-1","text":"Security of the cloud, security in the cloud","level":2},{"id":"sec-2","text":"Lock down the account before you build","level":2},{"id":"sec-3","text":"1. Choose the right account plan","level":3},{"id":"sec-4","text":"2. Protect the root user","level":3},{"id":"sec-5","text":"3. Create an everyday admin","level":3},{"id":"sec-6","text":"4. Set a budget before anything else","level":3},{"id":"sec-7","text":"5. Fill in the alternate contacts","level":3}],"takeaways":["AWS is responsible for security of the cloud (buildings, hardware, network, service software); you are responsible for security in the cloud (data, access, configuration, code).","The more managed the service, the more of the stack AWS patches, but your data, permissions and code are always yours.","The root user can do anything, including closing the account, so give it a passkey or security key, never create access keys for it, and use it only for root-only tasks.","Do daily work as a separate admin identity with its own MFA, not as root.","An AWS Budgets alert warns you before a bill surprises you, but it does not stop spending on its own."],"further":[{"title":"Shared Responsibility Model","url":"https://aws.amazon.com/compliance/shared-responsibility-model/"},{"title":"Root user best practices for your AWS account","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html"},{"title":"Choosing a Free Tier account plan","url":"https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-tier-plans.html"},{"title":"Managing your costs with AWS Budgets","url":"https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html"}],"quiz":[{"q":"Lantern’s API runs on AWS Lambda. A security advisory lands for an npm package bundled in the function. Who patches it?
","options":[{"text":"AWS, because Lambda is a managed service and applies runtime updates.","why":"AWS patches the managed runtime (Node.js itself and the OS underneath). Dependencies you bundle are part of your code."},{"text":"Lantern, because packages bundled with the function code are part of the customer’s code.","why":"Correct. Under the shared responsibility model your code and its dependencies are always yours, on every service."},{"text":"Nobody needs to, because Lambda functions run in isolated environments.","why":"Isolation limits the blast radius between customers. It does not stop a vulnerable library from being exploited through your own API."}],"answer":1},{"q":"Which task should you do while signed in as the root user?
","options":[{"text":"Creating the Lantern S3 bucket, since the root user owns the account.","why":"Any admin identity can create buckets. Using root for daily work exposes the most powerful credential for no gain."},{"text":"Creating root access keys so scripts can manage the account.","why":"Root access keys are the worst credential to leak because nothing can restrict them. AWS recommends never creating them."},{"text":"Turning on IAM user and role access to billing information so your admin user can see costs.","why":"Correct. That account setting is one of the few tasks only the root user can perform."},{"text":"Deploying Lambda functions, because root avoids permission errors.","why":"Avoiding permission errors by using unlimited access hides design problems and makes every mistake bigger."}],"answer":2},{"q":"Lantern has a monthly AWS Budgets cost budget of 20 USD with an email alert at 100%. A forgotten instance pushes spend to 35 USD. What happens?
","options":[{"text":"AWS stops the instance when spend reaches 20 USD.","why":"A plain budget only notifies. Stopping resources needs a budget action or automation that you configure separately."},{"text":"The account is suspended until you raise the budget.","why":"Budgets never suspend an account. They are a monitoring tool, not a spending cap."},{"text":"You get an email when spend crosses 20 USD, and the instance keeps running and costing money until someone acts.","why":"Correct. The alert buys you reaction time. Someone still has to read it and delete the resource."}],"answer":2}],"exercise":{"kind":"choice","multiple":true,"options":["ec2-os","disk-swap","sg-port","lambda-runtime","bucket-policy","rds-engine-hw"],"correct":["ec2-os","sg-port","bucket-policy"],"title":"Whose job is it?","prompt":"During the migration Lantern runs a worker on Amazon EC2, the events database on Amazon RDS, the RSVP API on AWS Lambda, and posters in Amazon S3. Select every task that is Lantern’s responsibility under the shared responsibility model.
\n","hints":["Picture the stacks from the lesson’s figure. Which layers are purple (yours) for each service?","Physical hardware is never yours. Who can reach your data always is.","Three tasks belong to Lantern: one is an operating system, two are about access."],"explanation":"On EC2 you own the guest operating system, so applying security updates to it is Lantern’s job. Network access rules, such as which addresses can reach the database port, are configuration and therefore yours on every service. Who may read the posters bucket is also configuration, so the bucket policy is yours. AWS replaces failed physical disks, keeps Lambda’s managed runtime patched, and runs the hardware under RDS.
\n","checkLabels":{},"optionText":{"ec2-os":{"text":"Installing security updates on the EC2 instance’s Linux operating system.","why":"Yours. On EC2 the guest OS sits above the line; AWS only runs the hardware and the hypervisor underneath it."},"disk-swap":{"text":"Replacing a failed physical drive in the data centre that hosts the RDS database.","why":"AWS’s. Physical hardware and facilities are always security of the cloud. You will never touch a data-centre drive."},"sg-port":{"text":"Making sure the database port only accepts connections from Lantern’s app, not the whole internet.","why":"Yours. Network access is configuration you control through security groups, covered in section three."},"lambda-runtime":{"text":"Patching the Node.js runtime that the Lambda function runs on.","why":"AWS’s, for managed runtimes with the default automatic updates. Your bundled npm packages, however, stay yours."},"bucket-policy":{"text":"Deciding who is allowed to read objects in the posters bucket.","why":"Yours. AWS gives safe defaults such as Block Public Access, but every access decision on your data is your responsibility."},"rds-engine-hw":{"text":"Keeping the servers under the RDS database powered and cooled.","why":"AWS’s. Power, cooling and physical security are the clearest example of security of the cloud."}}},"words":729,"readMinutes":3}