This first lesson has two goals. The first is to introduce you to MercadoFresco, the fictional company that will accompany us throughout the course: you will see its real starting situation, its concrete problems and why it needs the cloud. The second is to understand what cloud computing is and what AWS is, not as a list of service names, but as a different model for buying, operating and growing the infrastructure of an application.

It is important to start here because almost all of the technical decisions you will make in AWS (which service to use, in which region, at what size, how much it is going to cost) only make sense if you understand the economic and responsibility model that sits underneath. Many teams migrate to the cloud and end up with an enormous bill and a fragile architecture precisely because they skipped this part.

1. MercadoFresco: the company and its single server
2. MercadoFresco's four concrete problems
3. What cloud computing is
4. Your own server versus the cloud: CapEx, OpEx, elasticity and provisioning
5. Service models: IaaS, PaaS and SaaS
6. Deployment models: public, private and hybrid
7. What AWS is: history, scale and service families
8. The shared responsibility model
9. Pay-as-you-go pricing and the Free Tier
10. MercadoFresco's target architecture

MercadoFresco is a Spanish online fresh-produce shop: fruit, vegetables, fish and meat bought from local suppliers, with home delivery within 24 hours. It started as a small project in a single city and today serves several thousand orders a month. Its domain is mercadofresco.example.

The technical team is tiny:

The whole platform lives today on a single physical server in a cupboard at the office:

That single server hosts:

• The monolith: a PHP application that serves the shop and the admin panel, plus several Python scripts that generate the delivery routes and Sara's reports.
• The relational database with customers, products, stock and orders.
• The product photos stored directly on the local disk, in /var/www/fotos.

There is no test environment: Luis tests on his laptop and deploys by FTP to the very same server that customers use.

We are not going to migrate to the cloud "because it is modern". We are going to migrate because there are four measurable problems that the single server cannot solve.

The order peak is concentrated between 17:00 and 21:00 on Friday, when people organise the weekend shop. In that window the traffic is between 8 and 10 times that of a Tuesday morning. The server runs out of memory, the database starts refusing connections and the site returns errors for 20 or 30 minutes. Marta fixes it by restarting services by hand.

The underlying problem: capacity is fixed and sized for the peak. Either you buy an expensive server that runs at 8 % utilisation 90 % of the time, or you buy a cheap one that goes down at the very moment when most of the money comes in.

There is a USB disk plugged into the server and a cron script that takes a dump of the database overnight. Nobody has ever tried to restore that dump. The product photos are not copied anywhere at all. A fire, a burglary or a disk failure at the office would wipe out the entire catalogue.

Opening in a second and a third city means a bigger catalogue, more simultaneous orders and more delivery routes to calculate. With the current architecture, growing means buying hardware, waiting weeks for it to arrive, racking it and migrating over an entire night. And all of that would fall on Marta, who is one single person.

With no test environment and no way to roll back, every change Luis makes can take the shop down. The team deploys on Tuesday mornings "just in case" and avoids touching anything all week.

Keep these four problems in mind: every module of the course solves one or more of them, and by the end we will have built a platform where none of the four exists.

Cloud computing is the delivery of information technology resources —servers, storage, databases, networking, software— on demand, over the internet and paid for according to what you actually use.

The key idea is not "the servers are somewhere else". That already existed with traditional hosting. The key idea is three properties combined:

1. On-demand self-service: you ask for a server with an API call and you have it in seconds, without talking to a salesperson or signing anything.
2. Elasticity: you can have 2 servers on Tuesday and 20 on Friday at 18:00, and be back to 2 at 22:00, paying only for the hours you had them.
3. Pay per consumption: you do not buy the asset, you rent its metered use (CPU hours, gigabytes stored, requests served).

A useful analogy: it is the difference between buying an electricity generator and plugging into the grid. The generator is yours, you maintain it, you size it for your peak and it ends up either too small or too big. The grid is always there, you flip the switch, and you pay the kilowatts you use.

Two financial concepts worth having clear, because they change how decisions get made:

• CapEx (Capital Expenditure): you buy an asset up front. MercadoFresco's server cost €6,000 in one go and is depreciated over 4 or 5 years. It is a hard decision to reverse: if you get the size wrong, you have already paid for it.
• OpEx (Operational Expenditure): you pay for use, month by month, like electricity or the phone bill. If you stop using it, you stop paying for it. It is a reversible decision.

The cloud turns CapEx into OpEx. This has an enormous practical consequence: the cost of being wrong drops dramatically, and therefore you can experiment. Trying a different database no longer means buying a machine; it means starting it up, measuring it for three days and switching it off.

An honest caveat, because this course is not a sales brochure: the cloud is not always cheaper. A constant, predictable, well-sized workload running for five years can work out more economical on your own hardware. The cloud wins when there is variability, when you need speed of change, or when the team is small and cannot spend its time maintaining metal, which is exactly the case of MercadoFresco.

Cloud services are classified by how much you manage and how much the provider manages.

For MercadoFresco this classification is a constant decision guide. A real example we will see: the database.

• If they install it themselves on an EC2 machine (IaaS), Marta is still responsible for patching MySQL, configuring replication and scheduling the backups.
• If they use Amazon RDS (PaaS), AWS takes care of patches, automatic backups and failover, and the team only designs the schema and writes queries.

The practical rule we will use throughout the course: the more managed, the better, unless you have a concrete reason for the opposite. Every piece you manage yourself is time that Marta and Luis are not spending selling fruit.

There is also the term multicloud (using AWS and another provider at the same time), common in large companies for commercial leverage or for resilience. For a team of three people it is almost always a bad idea: it multiplies complexity and the knowledge required without adding value.

MercadoFresco is going to public cloud on AWS, with a short hybrid coexistence phase during the migration (the office server will stay switched on for a few weeks until everything is confirmed to be working).

Amazon Web Services (AWS) is Amazon's cloud computing platform. It was born out of an internal problem: in the early 2000s, Amazon.com took months to provision infrastructure for each new project, so they built a layer of common services with APIs. In 2006 they decided to sell it to the public.

Milestones worth knowing, because they explain why the catalogue has the shape it has:

Notice the order: first raw storage and raw compute (IaaS), then managed services (PaaS), then abstractions with no servers at all. That same order is, more or less, the one this course follows.

Scale: AWS operates dozens of geographic regions, each one with several independent data centres, and a private fibre network of its own that connects them. It is the cloud provider with the largest market share and its catalogue exceeds 200 services. You do not need to know them all: with about 25 well understood you can build practically any application.

This is probably the most important concept in the lesson, and the one that causes the most misunderstandings. AWS is not responsible for the whole of your security. It is split in two:

• AWS is responsible for the security of the cloud: the data centres, the hardware, the physical network, the hypervisor and the software of the managed services.
• You are responsible for the security in the cloud: your data, who accesses it, the encryption you enable, the configuration of your networks, the patches on your operating systems and your application code.

The boundary moves depending on the service you use, and this is key:

Almost every security incident that reaches the press as an "AWS leak" is in fact a customer mistake: an S3 bucket left open to the public by configuration, an access key pushed to GitHub, a security group with the database port exposed to the internet. None of those three is AWS's responsibility. We will explicitly avoid all three in this course.

The general principle is simple: you pay for what you consume, with no minimum commitment. The three dimensions that are almost always billed are:

1. Compute: per second or hour that a machine is switched on.
2. Storage: per gigabyte and month that you keep data.
3. Data transfer: per gigabyte that leaves AWS towards the internet. Inbound traffic (ingress) is normally free; outbound (egress) is not.

On top of that base there are commitment discounts (Savings Plans, reserved instances, module 11) and cheaper options in exchange for fewer guarantees (spot instances).

A realistic sense of orders of magnitude, so that you stop seeing prices as a mystery. These are approximate figures for the Ireland region, useful for reasoning, not for budgeting:

Two warnings that will save you money starting today:

• Some resources charge even when you do not use them: a detached EBS disk, an unassociated Elastic IP, a load balancer with no traffic, an old snapshot. They are billed for existing.
• Switching off is not always the same as stopping paying: a stopped EC2 instance is not charged for compute, but its EBS disk keeps billing.

AWS offers a Free Tier with three modalities that we will look at in detail in lesson 01-02, when we create the account:

• 12 months free from sign-up (for example, 750 hours a month of t2.micro/t3.micro).
• Always free, with no expiry (for example, the first million Lambda requests per month).
• Trials of short duration for specific services.

With the Free Tier you can do practically every exercise in this course at a cost of zero or a few euros, provided you delete the resources when you finish. Whenever an exercise could generate spend, we will warn you and tell you how to remove what you created.

So that you know where we are heading, this is the approximate destination we will build over the eleven modules. You do not need to understand every box yet; come back to this diagram when you finish each module and you will see the pieces lighting up one by one.

Check how each initial problem gets solved:

• Believing that "migrating to the cloud" means copying the server as it is. Spinning up a single EC2 instance with everything inside (the famous badly done lift and shift) reproduces exactly the same problems, but paying more. The cloud adds value when you take advantage of its elasticity and its managed services.
• Ignoring shared responsibility. "It is on AWS, so it is secure" is false. A badly configured S3 bucket is public on the internet in five seconds and the responsibility is yours.
• Forgetting outbound transfer. It is the line on the bill that surprises new teams the most. Serving product photos directly from an instance can cost far more than serving them from S3 with CloudFront.
• Leaving resources on "just in case". Get into the habit today of deleting whatever you create for practice. At the end of each exercise in this course we will remind you how.
• Trying to learn all 200 services. You do not need them. Master the ~25 in the syllabus and you will know how to read the documentation for the rest when you need it.
• Tip: when you hesitate between managing it yourself and using a managed service, ask yourself how much an hour of Marta's time is worth. The managed service almost always wins.

Without using any AWS service yet, build a table with MercadoFresco's four problems. For each one state: (a) the business impact in one sentence, (b) whether a bigger server of your own would solve it, and (c) which property of the cloud (elasticity, managed services, geographic distribution or pay-as-you-go) attacks the root cause.

Classify each of these items as IaaS, PaaS or SaaS, and justify in one line who manages the operating system in each case:

1. A Linux virtual machine where you install Nginx and MySQL yourself.
2. A MySQL database managed by AWS that you only connect to through an endpoint.
3. A corporate mail system that you access through a browser.
4. A function that runs Python code when an HTTP request arrives, with no visible server involved.

Marta proposes a first minimal architecture for MercadoFresco on AWS:

• 2 t3.medium instances running 24 hours a day.
• 1 small RDS database.
• 1 load balancer.
• 200 GB of photos in S3.
• 300 GB of outbound transfer to the internet per month.

Using the order-of-magnitude table from this lesson, estimate the total monthly cost and say which two line items are the largest. Then propose a change that reduces the cost without making Friday availability worse.

Solution 1

Solution 2

1. IaaS. AWS gives you the virtual machine; the operating system, the patches, Nginx and MySQL are managed by you (Amazon EC2).
2. PaaS. AWS manages the operating system and the database engine, including backups and patches; you only manage the schema and the data (Amazon RDS).
3. SaaS. There is no operating system visible to you; you only configure users and mailboxes (for example, Amazon WorkMail).
4. PaaS (in its serverless variant, often called FaaS). There is no operating system for you to administer; you only supply the code (AWS Lambda).

Solution 3

The two largest line items are EC2 compute ($70) and outbound transfer ($27).

Two possible improvements:

• Serve the photos through CloudFront in front of S3 (module 3): outbound traffic from the cache is cheaper than from the instance and it also takes load off the servers.
• Replace the 2 fixed instances with an auto scaling group with 1 instance as a baseline that grows to 3 or 4 on Friday afternoons (modules 2 and 3): it lowers the average cost and improves availability exactly at the peak.

Note that going from 2 instances down to 1 with no scaling would be cheaper but would worsen availability, so it does not meet the requirement.

You now have the two foundations the rest of the course rests on. On one side, MercadoFresco: a fresh-produce shop trapped on a single server, with Friday outages, backups nobody has ever tested, no way to grow and deployments that are frightening. On the other, the cloud model: on-demand resources, pay-as-you-go, CapEx turned into OpEx, real elasticity and managed services that free up the team's time.

You have also seen the three mental frameworks you will use constantly: IaaS/PaaS/SaaS to decide how much you want to manage, shared responsibility to know which part of security is yours, and the pricing model so that no bill ever surprises you.

In the next lesson, 01-02 "Setting up your AWS account", Marta moves from theory to practice: she creates MercadoFresco's account, protects the root user with MFA, creates the administrator user we will work with for the whole course and sets up the first financial safety net so that the bill never gets out of control.