In the previous lesson we met MercadoFresco and decided that its future is in AWS. Today Marta takes the first real step: creating the account. It looks like an administrative formality, but it is not. The decisions taken in the first twenty minutes of an account's life —which email address is used, how the root user is protected, which identity you work with day to day, which spending alarms are set— determine whether in a year's time the account is a solid platform or a problem.

This lesson is deliberately meticulous. A badly configured account is the number one cause of the two most frequent disasters in AWS: the surprise bill and the compromised account. By the end you will have an account created, protected, with billing under watch and a checklist you can reuse every time you open a new account in your professional life.

1. Before you start: what you need to hand
2. The sign-up process step by step
3. The root user: what it is and why you do not use it
4. How to lock down the root user
5. The day-to-day working identity: IAM Identity Center and the administrator user
6. Enabling billing access for IAM users
7. The Free Tier in detail
8. A first financial safety net: alarm and budget
9. Default region and the initial choice
10. Checklist for a brand-new account

Marta gathers four things before opening the browser. Bear in mind that sign-up cannot be completed halfway: if you are missing the card, you will have to start all over again.

Marta is tempted to use marta@mercadofresco.example. That is a mistake. The root user's email address is the master key to the account: whoever controls that mailbox can recover the password and take full control. If Marta leaves the company or loses access to her mailbox, MercadoFresco loses its AWS account.

The correct practice is to use a company distribution list received by several people and not dependent on any particular employee:

And apply the same logic to the phone: better a corporate number than someone's personal mobile.

Sign-up happens at https://portal.aws.amazon.com/billing/signup and has five steps.

You enter the root email address and an account name (for example, MercadoFresco Produccion). AWS sends a verification code to that address. The account name is descriptive and you can change it later; the email address is far more awkward to change.

Generate a long, random password with a password manager and store it there. You are hardly ever going to type it, so it does not matter that it is impossible to remember: quite the opposite.

You choose between Business and Personal. MercadoFresco ticks Business and enters its legal name, address and tax ID. This affects how the invoice is issued and how VAT is treated, so it is worth getting right from the very beginning.

You enter the card. AWS makes a temporary verification charge (around one dollar) that is then refunded. Next comes phone verification: you receive an SMS or an automated call with a four-digit code.

It is the last step and it usually raises questions. These are the plans:

Marta chooses Basic. It is free and can be upgraded to Business the day the shop depends on AWS to take orders; on that day, besides, 10 % of spend will be a reasonable, proportionate figure.

Once confirmed, the account takes anywhere from a few minutes to a few hours to activate. You will receive a welcome email.

When you create an AWS account you get a special identity: the root user, which is literally "the person who signed up with that email address". It is not an IAM user, permission policies cannot be applied to it and it cannot be restricted: it can do absolutely everything, including closing the account.

The professional rule is unambiguous: root is used to create the first administrator and is then locked away. Only a handful of tasks require it:

• Changing the email address, name or password of the root account itself.
• Changing the support plan or the payment method.
• Closing the AWS account.
• Restoring IAM permissions if someone has locked themselves out.
• Registering as a seller on the Marketplace and some tax formalities.
• Changing the policy of an S3 bucket that has been left inaccessible to everyone.

If you catch yourself using root to launch an instance, to run a deployment or to look at metrics, something is wrong with your setup.

With root compromised, an attacker can launch hundreds of cryptocurrency mining instances, delete all your backups and lock you out of your own account. There is no "safe mode" to protect you: root sits above every control.

Marta does these four things on the same day she creates the account, before anything else.

This is the single most important measure in the whole lesson. With MFA, knowing the password is not enough: you also need a temporary code generated by a physical device or an app.

Path: sign in as root → account menu (top right) → Security credentials → the Multi-factor authentication (MFA) section → Assign MFA device.

MercadoFresco uses a TOTP app inside the company password manager, so that the code can be recovered by more than one person. AWS lets you register up to 8 MFA devices on root: register at least two (for example, the company manager and a physical key kept in the office safe). That way losing one device does not mean losing the account.

When you save the recovery codes for the TOTP app, print them and keep them physically. Do not leave them in the same email account that is used to recover access.

On that same Security credentials screen you will see the Access keys section. Leave that section empty. A root access key is a permanent credential with total power: if it ends up in a Git repository, in a configuration file or on someone's laptop, the account is lost. If a key already exists, inherited from another era, delete it.

We already did this when signing up. Check that the root email address is the distribution list and not one person's mailbox.

In Account settings you can define alternate contacts for Billing, Operations and Security. Fill them in with company addresses: AWS uses them for abuse notices, breaches or payment problems. Without them, a critical notice can sit in a mailbox nobody ever looks at.

With root safe, we need an identity to work with day to day. There are two routes, and it is worth knowing both even though in this course we will use the second one for simplicity.

Professional recommendation: use IAM Identity Center from day one if you are going to have several people or several accounts. It is free, and it removes the permanent-key problem for good. At MercadoFresco Marta will enable it later on, when Luis and Sara join and the development and production accounts appear (multi-account governance is covered in lesson 09-04).

For the rest of the course we will work with an IAM administrator user called mercadofresco-admin, because it is the simplest way to follow the examples with a single account.

Signed in as root, go to IAM → Users → Create user:

1. User name: mercadofresco-admin.
2. Tick Provide user access to the AWS Management Console and choose a custom password; untick the option that forces a change if you are going to store it in the manager.
3. On the permissions screen, choose Attach policies directly and attach the AWS managed policy AdministratorAccess.
4. Create the user and save the sign-in link that AWS shows you. It looks like this:

That 111122223333 is the account ID (12 digits). Note it down: you will use it constantly.

5. Enable MFA on this user too. An administrator without MFA is almost as dangerous as a root without MFA.

About policies: AdministratorAccess grants permission over almost everything. It is acceptable for the single administrator of a learning account, but it is not what is done in a mature company, where each person receives the minimum privilege they need. How those policies are written precisely is the subject of lesson 04-01 (IAM); we do not go into detail here.

Remembering 111122223333 is awkward. In IAM → main dashboard → Account Alias → Create, enter mercadofresco. From then on the sign-in link is far more readable:

The alias must be unique across the whole of AWS, so you may need to add a suffix.

Finish by signing out of root and signing back in as mercadofresco-admin. From here on, the whole course is done with this user.

Here is a trap that catches almost everyone. By default, only the root user can see the billing console, even when another user has AdministratorAccess. If Marta does not change it, she will sign in as administrator, click Billing and get an access denied error.

To enable it you have to do this as root, once:

1. Sign in as root.
2. Account menu (top right) → Account.
3. Scroll down to IAM user and role access to Billing Information.
4. Click Edit, tick Activate IAM Access and Update.

This is one of the very few legitimate root tasks. Do it now and you will not have to sign in as root again for weeks.

The Free Tier has three distinct modalities, and confusing them is a common source of unexpected bills.

Four warnings that genuinely save money:

• The allowance is per account, not per resource. The 750 monthly EC2 hours are the total: two instances running all month come to ~1,460 hours, so the second one gets billed.
• The instance type matters. A t3.micro can fall within the Free Tier; a t3.small is billed in full from the very first second.
• The Free Tier does not cover everything attached to it. A load balancer, an unassociated Elastic IP or a large snapshot are billed even if your instance is free.
• Watch out for month 13. Mark the sign-up date plus one year in your calendar. On that day, everything still running "because it was free" starts costing money.

AWS provides a dashboard in Billing and Cost Management → Free tier where you can see your consumption against each allowance. Review it in the first week of every month.

You should never have an AWS account without spend monitoring. We are going to set up two minimum layers. Advanced budget management is lesson 11-04; here we put only the essentials in place.

In Billing and Cost Management → Billing preferences, enable:

• Receive AWS Free Tier alerts, with the address aws-alertas@mercadofresco.example.
• Receive PDF invoice by email, so that the invoice reaches the admin mailbox.

With this, AWS warns you when you go past 85 % of any free allowance. It is free and takes ten seconds.

Marta creates a budget of $10 a month, a deliberately low figure: any deviation will trigger early. Path: Billing and Cost Management → Budgets → Create budget → Cost budget.

The third alert is the most valuable: it warns you when AWS projects that you are going to exceed the budget by the end of the month, not once you already have. If you leave something expensive running on the 4th, that alert fires on the 5th, not on the 30th.

The first two budgets are free; from the third onwards they cost a few cents a day.

This is the classic alternative and it is still useful because it can trigger actions (a message to a chat channel, for instance). It requires two important things:

• The billing metric only exists in the us-east-1 region (North Virginia), even if your resources are in Europe. It is one of AWS's oddities.
• You must enable Receive Billing Alerts in Billing preferences before the metric appears.

Steps: switch to the US East (N. Virginia) region → CloudWatch → Alarms → Create alarm → Select metric → Billing → Total Estimated Charge → currency USD → condition Greater than 10 → create an SNS topic with your email address → confirm the subscription from the email you receive (if you do not confirm, no alerts will ever arrive).

Cost: a CloudWatch alarm is within the Free Tier (10 alarms a month). The SNS topic and a handful of emails are too. This setup should not cost you anything.

CloudWatch in depth (metrics, logs, dashboards and complex alarms) is lesson 05-01.

Every time you create a resource in AWS, you create it inside a specific region. The console has a region selector at the top right, and whatever you create lands in whichever one was selected.

MercadoFresco chooses eu-west-1 (Ireland) as its main region. The three reasons, in short:

1. Latency: it is close to its Spanish customers.
2. Catalogue and price: it is one of the most complete and economical European regions.
3. Data residency: it is in the European Union, which fits with the GDPR.

The full criteria for choosing a region, together with the alternatives eu-south-2 (Spain) and eu-west-3 (Paris), are analysed in detail in lesson 01-03. For now, take away two practical rules:

• Fix your region and always check it before creating anything. Creating resources scattered across different regions is the most common beginner mistake (we will see it in 01-04).
• Known exception: billing alarms live in us-east-1, as we have just seen.

Keep this list. It applies to any AWS account you open in your professional career.

• Registering the account with an employee's personal address. When that person leaves, recovering control can turn into a long process with AWS support. Always use a corporate alias.
• Putting off root MFA "until tomorrow". New accounts are actively scanned. Enable it in the first few minutes, not after the first deployment.
• Creating access keys for root because "it is quicker for testing the CLI". It is the most effective way there is to lose an account. In lesson 01-05 we will configure the CLI with the administrator user's credentials, never with root's.
• Working as root because "that way there are no permission problems". Besides being dangerous, it stops you learning IAM and makes CloudTrail record everything under the same identity, ruining the audit trail (CloudTrail is covered in 05-03).
• Being surprised that the administrator cannot see billing. Remember: it has to be enabled explicitly from root.
• Trusting that "the Free Tier protects me". It is not a spending limit: it is a discount. If you exceed the allowance, it is billed without blocking anything. The real protection is alerts.
• Tip: keep a record card in the company password manager with the account ID, the alias, the sign-in URL, the root email address and where the MFA devices are. The day there is an emergency, that card is worth its weight in gold.
• Tip: if you are going to do the whole course, start thinking now about the fact that a real company will have several accounts (development, production). That design is tackled in 09-04.

Create your own AWS account following the lesson and complete points 1 to 9 of the checklist. Then answer in writing:

• Which email address did you use and why?
• Which type of MFA device did you choose for root and what would you do if you lost it?
• What is your account ID and your sign-in URL as administrator?

Cost: sign-up is free. You will only see a temporary verification charge of ~$1 that AWS refunds. Do not create any resource yet.

Set up, in your account:

1. The Free Tier alerts and receiving the invoice as a PDF.
2. A monthly budget of 5 USD with three alerts: 50 % actual, 100 % actual and 100 % forecasted.
3. Explain in two sentences why the alert on the forecasted amount is more useful than the one on the actual amount for reacting in time.

MercadoFresco takes on Luis (developer) and Sara (business analyst). Marta asks you how they should be accessing AWS. Answer each question, justifying your reasoning:

1. Should Marta share the mercadofresco-admin credentials with them? Why?
2. Which identity option would you recommend (IAM users or IAM Identity Center) and on what grounds?
3. Sara only needs to see cost reports and a few metrics. Which security principle should guide her permissions and in which lesson of the course is it developed?
4. The new accountant asks for access to the invoices only. What earlier step must have been taken on the account for that to be possible at all?

Solution 1

Model answers:

• Email address: a company alias such as aws-root@mercadofresco.example that forwards to several people. Reason: the root address is the account recovery route; it must not depend on a person who might leave or lose access to it.
• MFA: a TOTP app inside the corporate password manager, plus a physical backup key registered as a second device. If one is lost, you get in with the other. If both were lost, you would have to start the recovery process with AWS support, verifying identity, email and phone, which can take days: that is exactly why two are registered.
• Account ID and URL: the 12 digits shown in the top menu and the URL https://<alias>.signin.aws.amazon.com/console.

Solution 2

1. In Billing and Cost Management → Billing preferences, tick Receive AWS Free Tier alerts and Receive PDF invoice by email, giving the alerts address.
2. In Budgets → Create budget → Cost budget: monthly recurring period, amount 5 USD, and three alerts: Actual > 50 %, Actual > 100 % and Forecasted > 100 %, all notifying by email.
3. The actual amount alert tells you about spend that has already happened and that you cannot undo. The forecasted amount alert fires when the consumption trend indicates that you will pass the limit by the end of the month, which gives you days of margin to switch off the guilty resource before the spend actually occurs.

Solution 3

1. No. Sharing credentials breaks traceability: CloudTrail would record every action under the same identity and it would be impossible to know who did what. It also forces you to rotate the password every time someone leaves the team, and it grants everybody administrator permissions they do not need.
2. IAM Identity Center, because it issues temporary credentials instead of permanent keys, centralises joiners and leavers in a single place, lets you assign different permission sets to each person and scales painlessly when the separate development and production accounts appear.
3. The principle of least privilege: each identity receives only the permissions it needs for its job, not one more. For Sara, read permissions over billing and metrics. It is developed in lesson 04-01 (IAM).
4. Having enabled IAM user and role access to billing information from the root user (Account → IAM user and role access to Billing Information). Without that step, no identity other than root can see billing, however many permissions it is granted.

MercadoFresco now has an AWS account and —more importantly— it has it set up properly. You have seen the complete sign-up process, understood why the root user is a master key that gets protected with MFA and then locked away, and created the mercadofresco-admin identity we will work with for the rest of the course. You have enabled billing access for IAM users, understood the three Free Tier modalities and put together the first financial safety net with alerts and a budget that will warn you before the bill takes off. And you have a reusable checklist for any future account.

One decision is still pending, which we flagged: the region. We chose eu-west-1 almost in passing, but it deserves to be properly understood, because it shapes your customers' latency, the price of every service, which services are available to you and where your data legally resides.

In the next lesson, 01-03 "AWS global infrastructure", we open the bonnet: what exactly a region is, what an Availability Zone really is, how you survive the failure of an entire data centre and how to reason about the choice of region for a shop whose customers are in Spain.