The Shared Responsibility Model and a Safe Account

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.

Security of the cloud, security in the cloud

AWS 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.

The line is not fixed. It moves with how managed the service is.

On 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.

Lock down the account before you build

A 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.

1. Choose the right account plan

At 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.

2. Protect the root user

The 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.

3. Create an everyday admin

Daily 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.

4. Set a budget before anything else

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:

{
  "BudgetName": "lantern-monthly",
  "BudgetLimit": { "Amount": "20", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}

5. Fill in the alternate contacts

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.

The 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.