Cloud computing is a business model that offers on-demand computing resources that users access over a network. For example, cloud storage is a service run by a cloud provider in their data centers, which users can access remotely to store files. Another example is cloud compute resources, which are virtual machines operated and owned by a cloud provider and made available to users over a network.
Most cloud providers use a pay-as-you-go pricing model by default. Unless special conditions apply, users are only charged for the resources they use. Charges may be based on time, or on time plus other factors such as network bandwidth and storage consumed. This makes the public cloud an affordable and flexible option with minimal upfront investment, but costs can increase dramatically if unused resources are left running and forgotten (we will cover that part later in the “Tagging and Cost” section).
Cloud services are often grouped into three models based on how much the cloud provider manages for you and how much you manage yourself.
| Model | What you manage | What the provider manages | Examples |
|---|---|---|---|
| IaaS (Infrastructure as a Service) | Operating system, applications, data, and configuration | Physical servers, storage, networking, and virtualization | Amazon EC2, Azure Virtual Machines, Google Compute Engine |
| PaaS (Platform as a Service) | Your application code and your data | Infrastructure plus runtime, scaling, and much of the operating system layer | AWS Elastic Beanstalk, Heroku, Google App Engine |
| SaaS (Software as a Service) | How you use the software, your content, and access control | The application and everything underneath it | Gmail, Slack, Notion, Google Drive |
A helpful way to think about it is: IaaS gives you building blocks, PaaS gives you a managed environment to run your app, and SaaS gives you a finished product.
In this course, we will focus on Amazon Web Services: AWS. Other popular public cloud providers include Microsoft’s Azure and Google Cloud Platform (GCP), as well as regional offerings like Tencent Cloud in China or services focused on developers like Digital Ocean. We picked AWS for this course due to its ubiquity and dominant market share. While public cloud services aren’t identical, they share concepts and have mostly equivalent services. We believe that learning AWS will give you a solid basis to work with any public cloud in the future.
AWS compute products are offered in regions, which are further segmented into availability zones (AZs). At the time of writing these course materials, AWS offers 39 regions and 123 AZs, and these numbers continue to grow. Regions are geographically separated. For example, creating resources in eu-central-1 means they are deployed in data centers near Frankfurt, Germany, while af-south-1 means they are deployed in data centers near Cape Town, South Africa.
Geographic separation of compute resources allows users to choose locations that are closer to their users for better network latency, but also to choose locations according to laws that govern how the data is stored (important for EU users, for example). Regions differ in cost and availability of services, the rule of thumb being that the earlier the region was introduced, the more likely it has more services available.
Every region has at least 3 availability zones, and some regions have more. Availability zones are separate data centers within the same region. They have independent power, cooling, and security, and they provide redundancy and fault tolerance. Availability zones in the same region are connected with high-bandwidth, low-latency networking, which makes it practical to spread workloads across them while keeping performance high. An application can (and indeed should) be deployed across more than one AZ. If one data center fails, another takes over, and with the right setup (for example, load balancing plus data replication) the outage may be seamless for end users.
You can find a full list of regions and AZs along with their codes in AWS documentation.
<aside> ⚠️
There are a few caveats with respect to regions and AZs.
eu-west-1a but not in eu-west-1b. Always be careful when deploying resources to different regions and AZs, and make sure they are available.The AWS shared responsibility model explains that securing workloads in the cloud is a joint effort: AWS is responsible for the security of the cloud (the physical data centers, hardware, networking, and the managed service infrastructure), while customers are responsible for security in the cloud (configuring identities and permissions, choosing secure network settings, patching and hardening guest operating systems when using IaaS like EC2, encrypting data, and protecting applications and content). Exactly where the line is drawn depends on the service, with more AWS responsibility in managed services like S3 or RDS, but customers always own their data, access controls, and configuration.
While most of the time users interact with AWS programmatically (via API calls), the easiest way to discover how AWS works is via its UI, known as the Management Console.
https://www.youtube.com/watch?v=i331jNgsL_4
Most compute resources and services offered by AWS operate in a Virtual Private Cloud (VPC). A VPC provides network isolation for your resources. Any resources put in a particular VPC will be only available to other resources from the same VPC. We will cover VPC management in future modules, but it’s worth noting that AWS always provides you with a default VPC. This means that if you start creating EC2 instances and subnets, they will belong to the default VPC unless you create a different one and explicitly specify that they should belong to it.
The default VPC is a ready-to-use network that AWS creates for you in each region. Out of the box, it a default route table, network ACL, and security group, plus a subnet in each availability zone in that region, all wired up to an Internet Gateway so resources can get public internet access when you assign a public IPv4 address. This makes it great for quick experiments and learning, but users often create custom VPCs in order to provide fine-grained security settings, partition their networks and tweak private/public networking settings and network routing tables. We will cover this in Week 4.
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.