It is 3 PM on a Monday at a company like Swiggy. Traffic is climbing toward the evening food-order rush, and the current fleet of servers is not going to be enough. On-premises, this is a multi-week problem - raise a purchase order, wait for hardware to arrive, rack it, cable it, provision it. On AWS, an engineer changes an Auto Scaling Group's maximum capacity and new servers are handling traffic within minutes. That difference is the entire reason cloud computing exists. It is not "someone else's computer" dressed up in marketing language - it is a fundamentally different relationship between a company and its infrastructure. On-premises infrastructure is bought, depreciated over years, and sized for peak load that may only happen a few days a year. Cloud resources are generally consumed and billed according to usage, capacity, or commitment rather than requiring upfront ownership of physical hardware - AWS itself often bills EC2 by the second, but other billing models (per request, per GB, subscription, reserved) exist too. Either way, capacity is sized for right now and reshaped in minutes as demand changes. This module builds the vocabulary and mental models every later module assumes you already have - what IaaS, PaaS, and SaaS actually mean, the core engineering concepts of scalability and availability, how AWS's physical infrastructure is organized, and where AWS's responsibility for security ends and yours begins. ### The core shift this module is really about On-premises model Cloud model ------------------ ----------- Buy hardware Rent capacity Provision in weeks Provision in seconds Size for peak, most of it idle Scale to match real demand Depreciate over 3-5 years Billed by the second/hour You own every layer Provider owns some layers Every AWS service you will learn in later modules is, underneath, a way of renting one of these layers so you do not have to own it. ### What you should be able to do after this module * Explain what cloud computing changes about how infrastructure is bought, run, and scaled * Identify whether a given AWS service is closer to IaaS, PaaS, or SaaS, and explain why that boundary is a useful approximation rather than a strict rule * Explain the difference between scalability, elasticity, availability, durability, and fault tolerance * Choose an AWS region and Availability Zone strategy for a given latency, compliance, and resilience requirement * Explain the shared responsibility model and how it shifts between EC2 and a managed service like RDS * Set up and secure a new AWS account, and interact with it through the console, CLI, and SDK ### What this module does not teach This module intentionally does not teach VPC networking, IAM policy design, EC2 administration, Terraform, containers, Kubernetes, or CI/CD. Those are covered in dedicated later modules. The goal here is the mental model that makes all of them easier to learn, not the implementation detail of any one of them. -
The cloud service models describe how much of the technology stack you manage yourself versus how much the provider manages for you. Picture a full application stack - from the physical data center up through the operating system to your actual code - as a tall stack of layers. Each service model draws the line between "provider manages this" and "you manage this" at a different height. > **Note:** IaaS, PaaS, and SaaS are conceptual categories, not rigid technical boundaries. Many modern cloud services sit somewhere between them - a service like AWS Lambda, for example, does not map cleanly onto any single category. Use these models as a mental starting point, not as a strict classification you need to force every service into. ### IaaS - Infrastructure as a Service **IaaS** gives you raw computing infrastructure - virtual machines, storage, and networking - while the provider handles the physical hardware, the data center, and the hypervisor underneath. You are responsible for everything from the operating system upward: patching, runtime, application code, and data. ```text AWS example: EC2 Azure example: Azure Virtual Machines GCP example: Compute Engine ``` > **Note:** IaaS is the closest cloud gets to "just a rented server." It gives you the most control and the most responsibility at the same time - you choose the OS, you patch it, you configure it. ### PaaS - Platform as a Service **PaaS** goes a layer higher. The provider manages the OS, the runtime, and the underlying infrastructure. You manage mainly your application code and its data - you do not choose an OS patch schedule because you never touch the OS directly. ```text AWS example: Elastic Beanstalk Google example: App Engine ``` > **Note:** PaaS trades control for convenience. You deploy code and the platform figures out how to run it - faster to build with, but you give up the ability to customize the environment underneath your application. ### SaaS - Software as a Service **SaaS** is the top of the stack. The provider manages infrastructure, platform, and the application itself. You manage configuration and your own data inside it. ```text Examples: Gmail, Salesforce, Workday ``` > 💡 **Tip:** A useful way to remember the three models: IaaS rents you the building, PaaS rents you a furnished office, SaaS rents you a finished product you just use. As you move from IaaS to SaaS, you give up control in exchange for less operational burden. ### Comparing what you manage at each layer | Layer | IaaS | PaaS | SaaS | |:---|:---|:---|:---| | Application & data | You | You | Provider | | Runtime | You | Provider | Provider | | Operating system | You | Provider | Provider | | Hardware & data center | Provider | Provider | Provider | ### The managed-service tradeoff - a decision you will make constantly Beyond the IaaS/PaaS/SaaS label, the practical question a cloud engineer asks every day is simpler: should I run this myself, or use a managed AWS service for it? ```text Self-managed: EC2 + MySQL you install and patch vs RDS (managed database) Self-managed: EC2 + Redis you install yourself vs ElastiCache (managed cache) Self-managed: Kafka cluster you operate vs MSK (managed Kafka) ``` More control ^ | Self-managed infrastructure | Managed service | Serverless v Less operational burden > **Note:** You are not expected to know RDS, ElastiCache, or MSK yet - those are covered in later modules. What matters here is the tradeoff itself: self-managed gives maximum control at the cost of operational burden (patching, backups, scaling, failover), while managed and serverless options remove that burden at the cost of some control. Many AWS architecture decisions involve this same tradeoff between control and operational burden, alongside other factors like reliability, security, latency, cost, and compliance. -
Deployment models describe *where* the infrastructure physically lives and *who* it is shared with - a separate question from the service models above. A company can run IaaS, PaaS, or SaaS workloads on any of the deployment models below. ### Public cloud Infrastructure owned and operated by a cloud provider like AWS and made available to multiple customers through isolated logical environments. This is the default model most companies mean when they say "the cloud." ### Private cloud Infrastructure dedicated entirely to one organization, either hosted on-premises or in a dedicated hosted facility. It gives more control over physical isolation, usually at a much higher operational cost than public cloud. ### Hybrid cloud A mix of on-premises infrastructure and public cloud, connected by a VPN or a dedicated private connection. Common when a company has existing data-center investments or regulatory requirements that keep some data on-premises, while still using the public cloud for burst capacity or new workloads. ### Multi-cloud Using services from more than one public cloud provider at the same time - for example, running some workloads on AWS and others on Google Cloud. This is sometimes adopted for negotiating leverage or to avoid a single point of vendor failure, but just as often it is driven by regulatory requirements, company acquisitions that inherited a different provider, existing technology investments, or one provider being genuinely stronger at a specific service - not resilience alone. > 🔴 **Common Mistake:** Assuming multi-cloud is automatically safer or more resilient. In practice, most outages are caused by application-level mistakes, not by an entire cloud provider failing - and running multi-cloud multiplies the operational complexity a small team has to manage. Most companies get more value from mastering one provider deeply before considering a second. -
These five ideas are what separate "knows AWS services" from "thinks like a cloud engineer." They apply no matter which AWS service you are looking at, and later modules will assume you already have this vocabulary. ### Scalability - handling more load by adding resources **Scalability** is a system's ability to handle increasing workload by adding resources. It comes in two forms. ```text Vertical scaling (scale up) Horizontal scaling (scale out) 2 CPU -> 8 CPU 1 instance -> 3 instances -> 10 instances (bigger machine) (more machines) ``` > **Note:** Vertical scaling has a practical ceiling - eventually there is no bigger machine to move to, and resizing often involves downtime, though some AWS services support resizing with minimal disruption. Horizontal scaling is the pattern cloud architectures favor, because adding another instance behind a load balancer can be done with little to no downtime and scales much further - though it still runs into real limits from service quotas, networking, database bottlenecks, application design, and cost. ### Elasticity - scaling automatically with demand **Elasticity** is the automatic addition and removal of resources as demand changes, without a human deciding in the moment. Scalability is the *capability* to add resources; elasticity is *doing it automatically* in response to real-time demand. An Auto Scaling Group that adds instances during Swiggy's evening rush and removes them again at 2 AM is elasticity in action. ### Availability vs durability - two different promises These two terms are often confused, but they answer different questions. * **Availability** - is the service accessible and responsive right now? * **Durability** - describes the likelihood that stored data remains intact and is not lost over time. > **Note:** Amazon S3 is designed for extremely high durability - your data is very unlikely to be lost. A single EC2 instance in one AZ can still have low availability, even while the data on its attached disk stays durable, if that instance goes down and nothing else can serve requests in its place. An architecture with an Application Load Balancer spreading traffic across EC2 instances in multiple AZs is what you build for high availability specifically. ### Fault tolerance - designing for failure, not preventing it **Fault tolerance** is the ability of a system to keep operating correctly even when one of its components fails. ```text Single AZ Multi-AZ with a load balancer User User | | AZ-A Load Balancer | / \ Application AZ-A AZ-B Application Application AZ-A fails -> application down AZ-A fails -> AZ-B keeps serving ``` > 📌 **Remember:** Cloud architecture is not about preventing every possible failure - hardware fails, networks fail, entire data centers occasionally fail. It is about designing systems that keep operating when individual components fail. This single idea underlies almost every AWS pattern you will learn later, from Multi-AZ RDS to Auto Scaling health checks to multi-region disaster recovery. -
AWS's physical infrastructure is organized in a hierarchy, and understanding this hierarchy is what makes concepts like "deploy across two Availability Zones" click instead of feeling like an arbitrary rule. AWS Global Infrastructure | +-- Regions (geographic areas, e.g. ap-south-1) | | | +-- Availability Zones (physically separate data centers) | +-- Edge Locations (CloudFront caching points, not inside any AZ) | +-- Local Zones | +-- Outposts ### Regions - where your infrastructure physically lives A **Region** is a geographic area containing multiple, physically separate data centers. AWS has dozens of regions worldwide - `ap-south-1` (Mumbai) and `us-east-1` (Northern Virginia) are examples. Choosing a region depends on three things: latency to your users, data residency or compliance requirements, and which services are actually available there, since not every AWS service launches in every region simultaneously. ### Availability Zones - the unit of resilience An **Availability Zone (AZ)** is one or more physically separate data centers within a region, each with independent power, cooling, and networking, connected to other AZs in the same region by low-latency private fiber. A region typically has three or more AZs. > 📌 **Remember:** Most production workloads that require high availability should be designed across at least two Availability Zones - a single AZ can fail from a power outage, network issue, or physical incident, and anything running only there goes down with it. This is not universal, though: development environments, short-lived batch jobs, and genuinely cost-sensitive workloads with low availability requirements can be legitimate exceptions. The principle is "design for AZ failure when availability matters," not "always use two AZs no matter what." ### Edge Locations - bringing content closer to users **Edge Locations** are CloudFront's content delivery nodes, distributed far more widely than regions or AZs - often in cities that do not have a full AWS region at all. They cache content close to end users so that a request from Mumbai does not have to travel to a data center on the other side of the world for every single asset. ### Local Zones and Outposts - extending AWS closer to you **Local Zones** place a small extension of AWS infrastructure in a specific metropolitan area, for workloads that need single-digit-millisecond latency to end users in that city but do not need a full region there. **AWS Outposts** goes further - AWS ships you physical hardware that runs inside your own data center, giving you AWS-compatible infrastructure and APIs on-premises, typically for workloads with strict data-residency or ultra-low-latency requirements that even a nearby region cannot satisfy. -
This is one of the most important concepts in cloud security, and it is frequently misunderstood by teams new to AWS. **AWS is responsible for security *of* the cloud.** That means the physical data centers, the hardware, the networking infrastructure, and the virtualization layer. **You are responsible for security *in* the cloud.** That means your data, your IAM configuration, your operating system patches (on IaaS), your network configuration, and your application code. AWS's responsibility Your responsibility --------------------- -------------------- Physical data centers Data encryption & classification Hardware & networking IAM users, roles, and policies Hypervisor / virtualization OS patching (on EC2/IaaS) Global infrastructure Security group & firewall rules Application-level security > **Note:** Exactly where the line sits shifts depending on the service. On EC2 (IaaS) you patch the OS yourself. On RDS, a managed database service, AWS manages more of the underlying infrastructure and database platform - including OS and database engine patching - and your responsibility narrows to configuration, access control, and the data itself. Always check where the line falls for the specific service you are using - it is not identical across all of AWS. > 🔴 **Common Mistake:** Assuming "AWS is responsible for security" as a blanket statement and skipping IAM hardening, encryption, or security group review as a result. The overwhelming majority of real-world cloud security incidents are caused by misconfiguration on the customer's side of this line - an open S3 bucket, an overly permissive IAM policy, a security group open to the world - not by a failure in AWS's own infrastructure. ### The principle behind your half of the line: least privilege **Least privilege** means giving an identity or workload only the permissions it actually needs to do its job, and nothing more. This single principle is the foundation of almost everything you will later learn about IAM - a dedicated later module covers how to actually write IAM policies, but the underlying idea belongs here, at the very start, because it should shape how you think about every AWS resource you create from now on. -
It is 3 PM on a Monday at a company like Swiggy. Traffic is climbing toward the evening food-order rush, and the current...
The cloud service models describe how much of the technology stack you manage yourself versus how much the provider mana...
Deployment models describe where the infrastructure physically lives and who it is shared with - a separate question fro...
These five ideas are what separate "knows AWS services" from "thinks like a cloud engineer." They apply no matter which ...
AWS's physical infrastructure is organized in a hierarchy, and understanding this hierarchy is what makes concepts like ...
This is one of the most important concepts in cloud security, and it is frequently misunderstood by teams new to AWS. AW...
AWS accounts - the billing and security boundary An AWS account is the fundamental container for your resources, and als...
This module is the front door to the rest of the roadmap, not the whole house. As you continue, these ideas build direct...
Create your AWS Free Tier account and secure it. Sign up for an AWS Free Tier account, then immediately enable MFA on th...
Category Term What it means Service model IaaS Provider manages hardware, you manage OS and up Service model PaaS Provid...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.