Lesson 1-2 established what happens when you deploy a server in eu-central-1.
It exists only in eu-central-1, the Frankfurt region, unless you deploy it elsewhere yourself. Regions are independent, and nothing moves between them unless you move it. Your Frankfurt server lives in Frankfurt, full stop.
Keep that model in place as this unit adds identity on top of it. Permissions are checked per request no matter where the resource sits, but the resource itself never wanders.
Security before servers
We cover identity before any real service on purpose. Almost every serious cloud breach starts with a stolen or over-powered credential, not a hacked server.
An AWS account is the container for everything: your servers, your data, and your bill. When you create one you get the root user, an identity with unlimited power that cannot be restricted. Root can delete every server, empty every storage bucket (a bucket is S3's named container of stored files, and unit 4 covers S3 properly), and close the account.
The first rule of AWS: lock root away. Turn on MFA (multi-factor authentication), a second login step from your phone, then stop using root for daily work. Instead you create IAM users.
IAM (Identity and Access Management) is the free service that answers one question on every single API call: is this identity allowed to do this action on this resource?
Users, and how they log in
An IAM user is a named identity inside your account, like ben or ci-deployer. Each one gets its own credentials:
- a password for the web console (the point-and-click website), and
- access keys for the command line and code: an ID plus a secret, like a username and password for programs. The
awsCLI you will see in this course signs every request with them.
One more term you will meet constantly: least privilege. Give every identity the smallest set of permissions that lets it do its job, nothing more. The deploy robot that uploads files to one bucket should be able to do exactly that, not delete databases.
Fixing a shared root password
A team of three sharing the root password in a group chat needs three changes: create an IAM user per person with only the permissions each needs, add MFA to root, and stop using root.
Root cannot be restricted, which is the heart of the problem. Sharing it gives all three people unlimited power over every resource and the billing settings, and there is no way to narrow that down.
It also destroys the audit trail. Every action in the account logs as "root", so when a bucket is emptied there is no record of who did it, and no way to tell a mistake from a compromised laptop.
One IAM user per person fixes both at once. Each identity gets scoped permissions and its own history. Shared identities of any kind, not just root, defeat both properties, so "one shared IAM user" is not an improvement.