[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"prev-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-regions-and-availability-zones-en":4,"next-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-regions-and-availability-zones-en":291,"lesson-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-regions-and-availability-zones-en":588},null,{"locked":5,"reason":3,"meta":6,"item":16},false,{"title":7,"description":8,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":11},"IaaS vs. PaaS vs. SaaS","The full responsibility split across all 3 service models side by side, the keyword cues that identify each one in a scenario, and the classic trap that catches learners who assume moving up the stack always means an upgrade.",19,"intermediate",[12,13,14,15],"Compare the full responsibility split across IaaS, PaaS, and SaaS, layer by layer","Apply keyword cues to identify the correct service model in a scenario","Explain why moving up the stack trades control for convenience rather than simply improving","Evaluate a scenario against its constraints to select the service model that fits",{"id":17,"title":7,"body":18,"description":8,"difficulty":10,"estimatedMinutes":9,"extension":213,"infographics":214,"isFree":5,"learningObjectives":225,"meta":226,"navigation":227,"path":228,"quiz":229,"seo":288,"stem":289,"__hash__":290},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/01-cloud-service-models/04-iaas-vs-paas-vs-saas.md",{"type":19,"value":20,"toc":201},"minimark",[21,26,30,34,117,122,125,129,132,136,139,174,178,181,184,187,191,194,198],[22,23,25],"h2",{"id":24},"naming-them-is-easy-telling-them-apart-is-the-actual-skill","Naming them is easy. Telling them apart is the actual skill",[27,28,29],"p",{},"You can now define IaaS, PaaS, and SaaS individually. That is not, on its own, a useful skill: almost nobody hands you a service and asks \"what is this?\" in isolation. What actually gets tested, on an exam and on the job, is a scenario with constraints, a team, a deadline, a compliance requirement, and the question of which of the 3 models fits it. That is where this lesson spends its effort.",[22,31,33],{"id":32},"the-full-stack-side-by-side","The full stack, side by side",[35,36,37,56],"table",{},[38,39,40],"thead",{},[41,42,43,47,50,53],"tr",{},[44,45,46],"th",{},"Layer",[44,48,49],{},"IaaS",[44,51,52],{},"PaaS",[44,54,55],{},"SaaS",[57,58,59,72,84,95,106],"tbody",{},[41,60,61,65,68,70],{},[62,63,64],"td",{},"Networking, servers, virtualization",[62,66,67],{},"Provider",[62,69,67],{},[62,71,67],{},[41,73,74,77,80,82],{},[62,75,76],{},"Operating system",[62,78,79],{},"You",[62,81,67],{},[62,83,67],{},[41,85,86,89,91,93],{},[62,87,88],{},"Runtime and middleware",[62,90,79],{},[62,92,67],{},[62,94,67],{},[41,96,97,100,102,104],{},[62,98,99],{},"Application code",[62,101,79],{},[62,103,79],{},[62,105,67],{},[41,107,108,111,113,115],{},[62,109,110],{},"Data and your own configuration",[62,112,79],{},[62,114,79],{},[62,116,79],{},[118,119],"infographic",{"alt":120,"slug":121},"A 3-column stack diagram comparing IaaS, PaaS, and SaaS, showing which layers the provider manages and which stay with the customer, with data and configuration always remaining the customer's responsibility.","iaas-vs-paas-vs-saas-responsibility-stack",[27,123,124],{},"Read the table by column instead of by row and the pattern is obvious: each step from IaaS to SaaS moves exactly one more layer from \"you\" to \"provider.\" Data and your own configuration are the only row that never moves, no matter which model you pick.",[22,126,128],{"id":127},"the-trap-this-is-a-tradeoff-not-a-ranking","The trap: this is a tradeoff, not a ranking",[27,130,131],{},"It is tempting to read that table left to right and conclude SaaS is simply the best model, since the provider does the most work. That conclusion is wrong, and it is exactly the trap an exam question sets. What SaaS gains in convenience, it spends in control. You cannot install a custom library on Gmail's servers, run your own code on Salesforce's infrastructure, or choose a different kernel version for Microsoft 365. IaaS gives you all of that control back, at the cost of doing the OS, runtime, and application management yourself. Neither end of the table is \"better.\" Each one fits a different set of constraints.",[22,133,135],{"id":134},"keyword-cues-for-scenarios","Keyword cues for scenarios",[27,137,138],{},"Exam scenarios rarely say \"IaaS\" or \"PaaS\" directly. They describe a constraint, and the constraint points at the model.",[35,140,141,151],{},[38,142,143],{},[41,144,145,148],{},[44,146,147],{},"The scenario says...",[44,149,150],{},"Points to",[57,152,153,160,167],{},[41,154,155,158],{},[62,156,157],{},"\"Full control of the operating system,\" \"specific kernel version,\" \"root access\"",[62,159,49],{},[41,161,162,165],{},[62,163,164],{},"\"Just deploy the code,\" \"no server management,\" \"focus on the application\"",[62,166,52],{},[41,168,169,172],{},[62,170,171],{},"\"No installation,\" \"use it out of the box,\" \"no developers on staff\"",[62,173,55],{},[22,175,177],{"id":176},"worked-example-2-scenarios-2-answers","Worked example: 2 scenarios, 2 answers",[27,179,180],{},"A 12-person sales team needs a working CRM by next week and has no developers on staff to build one. Nothing about this scenario mentions code, infrastructure, or customization beyond configuration. That absence is the cue: this is a SaaS scenario, and a tool like Salesforce is the fit, not something a team builds from scratch.",[27,182,183],{},"Now change the constraint. A fintech company operates under a regulation that requires it to control the exact OS patch level running on every server, down to the kernel version, and to apply security patches on its own schedule rather than a vendor's. PaaS and SaaS both take the operating system out of the customer's hands, which is precisely the control this regulation demands. That single requirement rules out both, and leaves IaaS as the only model that fits.",[27,185,186],{},"Same underlying question in both cases: how far up the stack does this scenario require you to reach. The sales team's answer is \"not at all.\" The fintech company's answer is \"all the way down to the kernel.\"",[22,188,190],{"id":189},"the-connection-to-shared-responsibility","The connection to shared responsibility",[27,192,193],{},"This same layer-by-layer split is the foundation of the shared responsibility model, covered in full in this course's Security and Reliability domain. What you are learning here, which layer belongs to you and which belongs to the provider, is the exact question that model answers for security specifically. You are not learning a new idea there. You are applying this one to a new question.",[22,195,197],{"id":196},"where-this-leaves-you","Where this leaves you",[27,199,200],{},"One question separates these 3 models in any scenario: how far up the stack does the situation require the provider to go. Root access and kernel control pull you toward IaaS. A focus on shipping code with no server management pulls you toward PaaS. No installation and no in-house developers pulls you toward SaaS. The next topic in this domain leaves the service models behind and moves to the building blocks every one of them runs on: regions, compute, storage, databases, and networking.",{"title":202,"searchDepth":203,"depth":203,"links":204},"",3,[205,207,208,209,210,211,212],{"id":24,"depth":206,"text":25},2,{"id":32,"depth":206,"text":33},{"id":127,"depth":206,"text":128},{"id":134,"depth":206,"text":135},{"id":176,"depth":206,"text":177},{"id":189,"depth":206,"text":190},{"id":196,"depth":206,"text":197},"md",[215],{"slug":121,"concept":216,"style":217,"aspectRatio":218,"labels":219},"A 3-column stack diagram, one column per service model (IaaS, PaaS, SaaS), each built from the same layers stacked bottom to top: networking and servers, virtualization, operating system, runtime and middleware, application code, and data. In each column, the layers the provider manages are shaded one color and the layers the customer manages are shaded a contrasting second color. Moving left to right from IaaS to SaaS, the provider-shaded portion grows taller and the customer-shaded portion shrinks, visually showing the responsibility handoff. A footer strip carries the tradeoff takeaway.","diagram","16:9",[220,221,222,223,224],"IaaS: Provider manages networking, servers, and virtualization. You manage the OS, runtime, and app.","PaaS: Provider also takes over the OS and runtime. You manage the app code and data.","SaaS: Provider manages the entire application. You manage only your data and settings.","Data and access are always yours, in every model.","Moving right trades control for convenience. It is not an upgrade, it is a tradeoff.",[12,13,14,15],{},true,"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/01-cloud-service-models/04-iaas-vs-paas-vs-saas",{"passingScore":230,"questions":231},70,[232,238,243,249,255,265,273,281],{"question":233,"type":234,"options":235,"correctAnswer":55,"explanation":237},"A 12-person sales team needs a working CRM next week and has no developers on staff. Which service model fits best?","single",[52,55,49,236],"None, they must hire developers first","With no developers on staff and a working tool needed fast, SaaS fits: a complete application like Salesforce is ready to configure and use immediately. IaaS and PaaS both assume someone on the team is writing or deploying code, which this scenario rules out.",{"question":239,"type":234,"options":240,"correctAnswer":49,"explanation":242},"A fintech company is legally required to control the exact OS kernel version on every server it runs. Which service model is the only one that satisfies this requirement?",[55,52,241,49],"Either PaaS or SaaS, since both are managed by the provider","Only IaaS leaves the operating system, including the kernel version, in the customer's hands. PaaS and SaaS both move the OS to the provider, which is exactly the control this regulation requires the company to keep for itself.",{"question":244,"type":234,"options":245,"correctAnswer":247,"explanation":248},"Moving from IaaS toward SaaS is always an improvement, since the provider takes on more of the work.",[246,247],"True","False","What SaaS gains in convenience, it spends in control: you cannot install custom code on Gmail's servers or choose Salesforce's kernel version. Each model fits different constraints, so moving up the stack is a tradeoff, not a straightforward upgrade.",{"question":250,"type":234,"options":251,"correctAnswer":110,"explanation":254},"According to the responsibility split, which layer is the customer responsible for in every one of the 3 service models, without exception?",[110,252,99,253],"The operating system","Virtualization","Data and your own configuration are the one row that never moves across IaaS, PaaS, or SaaS. The operating system and application code shift to the provider at different points in the stack, and virtualization belongs to the provider in all 3 models.",{"question":256,"type":257,"options":258,"correctAnswers":263,"explanation":264},"Which of the following phrases in a scenario would point toward PaaS rather than IaaS or SaaS? (Select all that apply.)","multiple",[259,260,261,262],"Full control of the operating system","Focus on deploying application code, no server management","No installation required, just log in and use it","The team wants to write and ship code without managing infrastructure",[260,262],"PaaS scenarios describe a team writing and shipping their own code while the platform handles servers and the OS. \"Full control of the operating system\" points to IaaS, and \"no installation required\" points to SaaS, since neither involves the customer deploying their own application code.",{"question":266,"type":234,"options":267,"correctAnswer":270,"explanation":272},"Why can a company not simply say SaaS is the best service model for every situation?",[268,269,270,271],"SaaS is always more expensive than IaaS","SaaS is technically inferior to IaaS and PaaS","SaaS trades away control that some scenarios genuinely require, such as running custom code or controlling the OS","SaaS does not actually exist as a real deployment option","SaaS is not inferior or superior to the other models, it is a different point on the same control-versus-convenience tradeoff. A scenario that needs custom code or OS-level control rules SaaS out regardless of how convenient it otherwise is.",{"question":274,"type":234,"options":275,"correctAnswer":277,"explanation":280},"Which service model does the shared responsibility model, covered later in this course, build directly on?",[276,277,278,279],"A completely separate framework unrelated to service models","The same layer-by-layer split between customer and provider covered in this topic","Only the SaaS model","Only the IaaS model","The shared responsibility model applies the same customer-versus-provider split you just learned specifically to security. It is not a new framework, it is this one, pointed at a specific question.",{"question":282,"type":234,"options":283,"correctAnswer":286,"explanation":287},"A team deploys an application through a PaaS product. Compared to IaaS, which additional layer does the provider now manage?",[99,284,285,286],"Data","Networking","The operating system and runtime","The operating system and runtime are the layers that move from customer to provider between IaaS and PaaS. Application code and data stay with the customer in both models, and networking is already the provider's job under IaaS.",{"title":7,"description":8},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/01-cloud-service-models/04-iaas-vs-paas-vs-saas","aqcJIr7pB2vb9kCvpVwqkButhpb5OOlPapjCzJzT8Z0",{"locked":5,"reason":3,"meta":292,"item":302},{"title":293,"description":294,"isFree":5,"estimatedMinutes":295,"difficulty":296,"learningObjectives":297},"Compute Services","The actual compute options behind IaaS and PaaS: how virtual machines are sized and priced, what managed compute platforms take off your plate, and where containers and serverless functions sit on the same spectrum.",17,"beginner",[298,299,300,301],"Explain what compute means as a billed cloud resource","Choose an appropriate virtual machine family for a given workload profile","Distinguish vertical scaling from horizontal scaling as 2 different responses to running out of capacity","Place virtual machines, managed compute, containers, and serverless functions on a single control-versus-convenience spectrum",{"id":303,"title":293,"body":304,"description":294,"difficulty":296,"estimatedMinutes":295,"extension":213,"infographics":523,"isFree":5,"learningObjectives":533,"meta":534,"navigation":227,"path":535,"quiz":536,"seo":585,"stem":586,"__hash__":587},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/02-compute-services.md",{"type":19,"value":305,"toc":514},[306,310,313,317,320,392,395,398,402,405,412,418,421,425,428,432,435,439,499,502,506,509,511],[22,307,309],{"id":308},"what-you-are-actually-renting","What you are actually renting",[27,311,312],{},"The last topic told you that IaaS hands you a virtual machine and PaaS hands you a platform that runs your code. Neither one told you what is actually happening inside that box: some amount of CPU and memory, sitting in a data center, that you rent by the hour, the second, or the request. That resource is compute, and how much of it you get, how it is packaged, and how you pay for it are decisions that shape almost every other choice you make on a cloud platform.",[22,314,316],{"id":315},"virtual-machines-the-baseline-unit","Virtual machines: the baseline unit",[27,318,319],{},"A virtual machine is still the most common way compute gets sold, and providers group their VM offerings into families built around different resource ratios.",[35,321,322,335],{},[38,323,324],{},[41,325,326,329,332],{},[44,327,328],{},"Family",[44,330,331],{},"Optimized for",[44,333,334],{},"Typical use case",[57,336,337,348,359,370,381],{},[41,338,339,342,345],{},[62,340,341],{},"General purpose",[62,343,344],{},"A balance of compute, memory, and networking",[62,346,347],{},"Web servers, small-to-medium databases, dev environments",[41,349,350,353,356],{},[62,351,352],{},"Compute optimized",[62,354,355],{},"High-performance processors, more vCPU per GB of memory",[62,357,358],{},"Batch processing, media transcoding, game servers",[41,360,361,364,367],{},[62,362,363],{},"Memory optimized",[62,365,366],{},"Large amounts of RAM relative to vCPU",[62,368,369],{},"In-memory databases, real-time analytics",[41,371,372,375,378],{},[62,373,374],{},"Storage optimized",[62,376,377],{},"High, low-latency local disk throughput",[62,379,380],{},"High-throughput databases, streaming data processing",[41,382,383,386,389],{},[62,384,385],{},"Accelerated computing",[62,387,388],{},"GPUs or other hardware accelerators",[62,390,391],{},"Machine learning training, graphics rendering",[27,393,394],{},"A batch job that spends its time doing floating-point math and barely touches memory belongs on compute optimized, not general purpose. A database holding a large working set in memory belongs on memory optimized. Picking the wrong family does not just waste money, it can leave a workload starved of the one resource it actually needed.",[27,396,397],{},"Instance sizes inside a family follow a doubling pattern: a large steps up to an xlarge, which steps up to a 2xlarge, roughly doubling vCPUs and memory at each step. You saw in the IaaS lesson that a t3.micro, 2 vCPUs and 1 GiB of memory, runs about $7.59 a month before storage. Moving up a size roughly doubles both the resources and the bill; moving to a different family at a similar size changes the resource ratio instead.",[22,399,401],{"id":400},"vertical-scaling-versus-horizontal-scaling","Vertical scaling versus horizontal scaling",[27,403,404],{},"Say that same application starts timing out under load. A quick look at its metrics shows CPU pegged at 100% while memory usage stays low. There are 2 different ways to respond, and they are not interchangeable.",[27,406,407,411],{},[408,409,410],"strong",{},"Vertical scaling"," resizes the existing instance to a bigger one, more vCPUs, more memory, same single machine. It is simple, but it has a ceiling (the largest instance type in the family) and it briefly interrupts the instance during the resize.",[27,413,414,417],{},[408,415,416],{},"Horizontal scaling"," adds more instances of the same size and spreads the load across all of them, typically behind a load balancer. It avoids the ceiling and does not require downtime on the existing instances, but it only works if the application can actually split its work across multiple machines instead of depending on one.",[27,419,420],{},"For the CPU-pegged, memory-fine application above, either move fixes the symptom. Which one a real team picks depends on whether the application was built to run on more than one instance at once, which is a design question, not a compute question, but one that compute options force you to confront.",[22,422,424],{"id":423},"managed-compute-someone-else-runs-the-fleet","Managed compute: someone else runs the fleet",[27,426,427],{},"You already met AWS Elastic Beanstalk, Google App Engine, and similar products as PaaS examples. Underneath, they are still running your code on virtual machines, the difference is who provisions and operates those machines. A managed compute platform takes over launching instances, deploying new versions of your code, and, in most cases, scaling the fleet up and down as traffic changes. You still choose your runtime and supply your application; you stop writing the scripts that would otherwise provision and babysit the instances by hand.",[22,429,431],{"id":430},"the-full-compute-spectrum","The full compute spectrum",[27,433,434],{},"Virtual machines and managed compute are 2 points on a longer line. Containers and serverless functions sit further along it, and this domain gives each one a full lesson later. For now, the shape of the whole spectrum matters more than the mechanics of any single stop on it.",[118,436],{"alt":437,"slug":438},"A spectrum diagram placing virtual machines, managed compute, containers, and serverless functions along a single axis from more control to more convenience, with a caption under each showing what you manage and typical startup time.","compute-services-spectrum",[35,440,441,454],{},[38,442,443],{},[41,444,445,448,451],{},[44,446,447],{},"Option",[44,449,450],{},"What you manage",[44,452,453],{},"Typical startup",[57,455,456,467,477,488],{},[41,457,458,461,464],{},[62,459,460],{},"Virtual machine",[62,462,463],{},"OS, runtime, scaling",[62,465,466],{},"Minutes",[41,468,469,472,475],{},[62,470,471],{},"Managed compute",[62,473,474],{},"Application code and configuration",[62,476,466],{},[41,478,479,482,485],{},[62,480,481],{},"Container",[62,483,484],{},"Application, its runtime dependencies, packaged together",[62,486,487],{},"Seconds",[41,489,490,493,496],{},[62,491,492],{},"Serverless function",[62,494,495],{},"Only the function code",[62,497,498],{},"Milliseconds",[27,500,501],{},"A container shares its host's operating system kernel instead of running a full guest OS the way a virtual machine does, which is exactly why it starts in seconds instead of minutes. A serverless function, such as an AWS Lambda function, goes further still: the provider manages the entire execution environment, and you are billed per request and per fraction of a second the function actually runs, not for idle time between invocations.",[22,503,505],{"id":504},"the-misconception-serverless-is-always-cheaper","The misconception: \"serverless is always cheaper\"",[27,507,508],{},"It is tempting to assume that paying only for what you use always beats paying for a machine that sits there. That is true for spiky or low-volume traffic, where a small always-on virtual machine spends most of its time idle and billed anyway. Run a workload at high, steady volume instead, and the math flips: per-invocation charges on a serverless function can add up past what a modest always-on instance would have cost for the same total work. Neither end of the spectrum is cheaper in every case. The traffic pattern decides, which is exactly why the full comparison waits for its own lesson later in this domain.",[22,510,197],{"id":196},[27,512,513],{},"Every compute option on this spectrum answers the same underlying question, how much of the operating and scaling work do you want to keep versus hand to the provider, at the cost of how much control. Virtual machines keep the most in your hands; serverless functions keep the least. The next lesson leaves compute behind and covers what happens to the data those compute resources read and write: storage.",{"title":202,"searchDepth":203,"depth":203,"links":515},[516,517,518,519,520,521,522],{"id":308,"depth":206,"text":309},{"id":315,"depth":206,"text":316},{"id":400,"depth":206,"text":401},{"id":423,"depth":206,"text":424},{"id":430,"depth":206,"text":431},{"id":504,"depth":206,"text":505},{"id":196,"depth":206,"text":197},[524],{"slug":438,"concept":525,"style":526,"aspectRatio":218,"labels":527},"A horizontal spectrum diagram with 4 stops left to right: Virtual Machines, Managed Compute, Containers, Serverless Functions. A single axis arrow runs beneath all 4 labeled 'More control' on the left end and 'More convenience' on the right end. Each stop has a short 2-line caption below it: what you manage and typical startup time. A footer strip carries the takeaway that this is a spectrum, not a ranking.","comparison",[528,529,530,531,532],"Virtual Machines: you manage the OS and scaling. Starts in minutes.","Managed Compute: platform manages the OS and deploys your code. Starts in minutes.","Containers: platform manages the OS, you package the runtime. Starts in seconds.","Serverless Functions: platform manages everything except your code. Starts in milliseconds.","More control on the left, more convenience on the right. Neither end is universally better.",[298,299,300,301],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/02-compute-services",{"passingScore":230,"questions":537},[538,542,548,552,560,569,577],{"question":539,"type":234,"options":540,"correctAnswer":352,"explanation":541},"A video-transcoding batch job spends almost all its time doing floating-point math and barely touches memory. Which EC2 instance family fits this workload best?",[363,374,352,341],"Compute optimized instances are built around high-performance processors for exactly this kind of processing-bound workload, batch processing, media transcoding, and similar CPU-heavy tasks. Memory optimized instances would be wasted here, since the job barely uses memory, and general purpose trades away the raw processing headroom this job actually needs.",{"question":543,"type":234,"options":544,"correctAnswer":416,"explanation":547},"An application currently runs on 1 virtual machine. Under heavy traffic, its CPU stays pegged at 100% while memory usage stays low. The team adds a second, identical virtual machine behind a load balancer instead of resizing the existing one. What is this response called?",[416,410,545,546],"Service migration","Instance right-sizing","Horizontal scaling adds more instances of the same size to share the load, which is what happened here. Vertical scaling would instead mean resizing the original instance to a larger type with more vCPUs and memory. Both are valid responses to running out of capacity, but they are not the same move.",{"question":549,"type":234,"options":550,"correctAnswer":247,"explanation":551},"Vertical scaling and horizontal scaling solve the same problem in the same way, so it never matters which one a team picks.",[246,247],"Vertical scaling, moving to a bigger instance, has a hard ceiling at the largest instance size and briefly interrupts the instance during the resize. Horizontal scaling, adding more instances, avoids that ceiling and that interruption, but only works if the application can actually spread work across multiple instances. The right choice depends on the application, not personal preference.",{"question":553,"type":234,"options":554,"correctAnswer":558,"explanation":559},"The lesson describes AWS Elastic Beanstalk, Google App Engine, and similar products as managed compute platforms. What do they take off a team's plate that plain virtual machines do not?",[555,556,557,558],"Writing the application code","Nothing, they work identically to raw virtual machines","Choosing which programming language to use","Provisioning the underlying instances, deploying updates, and often scaling them automatically","A managed compute platform still runs your application on virtual machines underneath, but it handles provisioning, deployment, and often scaling for you, the same operational work a team would otherwise script by hand. It does not write your code or choose your language; you still supply the application.",{"question":561,"type":257,"options":562,"correctAnswers":567,"explanation":568},"Which of the following statements accurately place items on the control-versus-convenience compute spectrum? (Select all that apply.)",[563,564,565,566],"A raw virtual machine sits further toward the control end than a serverless function","A serverless function typically starts running faster than a virtual machine boots","Containers require the provider to manage your application's guest operating system the same way a virtual machine does","Managed compute platforms still run on virtual machines underneath, even though you do not manage them directly",[563,564,566],"Virtual machines sit at the control end and serverless functions at the convenience end, with serverless functions starting in milliseconds against a VM's minutes-long boot. Managed compute is still built on virtual machines, just ones you no longer provision by hand. Containers do not hand the guest OS to the provider the way a VM does; a container shares the host operating system's kernel instead of running its own full OS, which is exactly why it starts faster than a VM.",{"question":570,"type":234,"options":571,"correctAnswer":573,"explanation":576},"A team's monthly bill on serverless functions turned out higher than an equivalent workload would cost on a small always-on virtual machine. What does this most likely indicate about the workload?",[572,573,574,575],"Serverless pricing is a marketing myth and never actually saves money","The workload runs at high, steady volume, the kind of pattern where paying for a machine you already own beats paying per invocation","The team configured the virtual machine incorrectly","AWS made a billing error, since serverless is always cheaper","Serverless billing charges per request and execution duration, which is a bargain for spiky or low-volume workloads that would otherwise leave a VM idle most of the time. Run that same math at high, constant volume, and the per-invocation charges add up past what a small always-on VM would have cost for the same total work. Neither model is cheaper in every case; the traffic pattern decides.",{"question":578,"type":234,"options":579,"correctAnswer":581,"explanation":584},"According to this lesson, where do containers and serverless functions get covered in full?",[580,581,582,583],"They are not covered anywhere else in this course","In the Modern Cloud Architectures topic later in this domain","In the Cloud Economics topic from the previous domain","In the Security and Reliability domain","This lesson places containers and serverless functions on the compute spectrum so you have the vocabulary and the orientation, but the Modern Cloud Architectures topic gives each one a full lesson of its own. That is deliberate: knowing where something sits on the spectrum is a different skill from knowing how to operate it.",{"title":293,"description":294},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/02-compute-services","5paMPWdXDfm7PpzvTUl3vO7C3EfwjrxJNYgmXEBKrEw",{"locked":5,"reason":3,"meta":589,"item":598},{"title":590,"description":591,"isFree":227,"estimatedMinutes":592,"difficulty":296,"learningObjectives":593},"Regions and Availability Zones","How cloud providers organize their global infrastructure into regions and availability zones, and why that structure is the reason a well-built cloud application can survive a data center fire.",16,[594,595,596,597],"Define what a region and an availability zone are and how they relate to each other","Explain why providers physically isolate availability zones from each other","Apply availability zone redundancy to explain why spreading an application across zones improves uptime","Compare how AWS, Azure, and Google Cloud name and structure their regions and zones",{"id":599,"title":590,"body":600,"description":591,"difficulty":296,"estimatedMinutes":592,"extension":213,"infographics":731,"isFree":227,"learningObjectives":739,"meta":740,"navigation":227,"path":741,"quiz":742,"seo":797,"stem":798,"__hash__":799},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/01-regions-and-availability-zones.md",{"type":19,"value":601,"toc":722},[602,606,609,613,616,619,623,626,629,633,636,639,643,646,650,654,657,714,717,719],[22,603,605],{"id":604},"the-data-center-that-never-fails-does-not-exist","The data center that never fails does not exist",[27,607,608],{},"Picture an online store's servers running out of one building. That building loses power during the year's biggest sales event, and every server in it goes dark at the same moment. It does not matter how good the code is or how much traffic the servers could otherwise handle: the store is offline until someone restores power in that one place. Cloud providers face the exact same physics as that building. A single data center can still catch fire, flood, or lose power, no matter whose logo is on the door. What providers built instead is a structure that keeps one location's bad day from becoming everyone's bad day: regions and Availability Zones.",[22,610,612],{"id":611},"regions-where-in-the-world-your-resources-live","Regions: where in the world your resources live",[27,614,615],{},"A Region is a separate geographic area, for example US East (N. Virginia) or Europe (Ireland). When you launch a virtual machine or create a storage bucket, you choose a Region, and that choice decides which country or continent physically holds your data and how far network traffic has to travel to reach your users. AWS alone operates around 39 Regions worldwide, each one designed to be fully isolated from every other Region so that a failure in one has no way to reach the others.",[27,617,618],{},"Regions exist for 2 practical reasons: latency and law. A user in Singapore gets faster responses from a Singapore Region than from one in Virginia, and some industries and governments require that certain data never leave a specific country's borders. Picking a Region is your first infrastructure decision on any cloud platform, and it is usually driven by exactly those 2 constraints.",[22,620,622],{"id":621},"availability-zones-isolation-inside-the-region","Availability Zones: isolation inside the Region",[27,624,625],{},"A Region on its own does not protect you from anything, it is just a location. The protection comes one level down, inside the Region, where providers carve out multiple Availability Zones (AZs). Each AZ is 1 or more discrete data centers, each with its own redundant power, cooling, and physical security, housed in a physically separate facility from the other AZs in the same Region. AWS guarantees a minimum of 3 AZs per Region. The AZs are still close enough to each other, generally within 100 km, that a dedicated low-latency, high-bandwidth fiber connection keeps traffic between them fast.",[27,627,628],{},"AWS names AZs after their Region: us-east-2a, us-east-2b, and us-east-2c are the 3 AZs in the us-east-2 Region. That trailing letter is the only thing that changes: everything before it identifies the Region, and the letter picks the specific zone.",[22,630,632],{"id":631},"worked-example-1-az-versus-3","Worked example: 1 AZ versus 3",[27,634,635],{},"Say a retailer runs its checkout service on 6 virtual machines. Put all 6 in a single AZ, and a power failure in that one data center takes every one of them offline at the same instant, exactly like the single building from the opening scenario. Split those same 6 machines across 3 AZs, 2 per AZ, and the picture changes completely: if 1 AZ loses power, the other 4 machines in the remaining 2 AZs keep serving checkout requests. The AZ that failed is offline, but the checkout service, as a whole, is not.",[27,637,638],{},"Nothing about the code changed between those 2 scenarios. The only difference is where the 6 machines physically sit, which is the entire reason Availability Zones exist as a concept, not as a feature you write, but as a decision you make when you deploy.",[22,640,642],{"id":641},"the-misconception-multi-az-is-not-multi-region","The misconception: multi-AZ is not multi-region",[27,644,645],{},"It is tempting to treat \"spread across Availability Zones\" and \"protected against any outage\" as the same thing. They are not. Multi-AZ protects you from a failure that is local to 1 data center location, power, cooling, fire, flood. It does nothing for an event that affects an entire geographic area at once, a major natural disaster or a region-wide network failure. Surviving that requires running in more than 1 Region, replicating data and traffic across a much larger distance, which is a bigger commitment in cost and complexity than multi-AZ. Most applications only need multi-AZ. Multi-Region is for workloads where losing an entire geographic area for any length of time is not acceptable.",[118,647],{"alt":648,"slug":649},"A hierarchy diagram showing a Region containing multiple Availability Zones, and each Availability Zone containing multiple independent data centers, illustrating how cloud providers isolate failures.","regions-and-availability-zones-hierarchy",[22,651,653],{"id":652},"how-the-3-major-providers-compare","How the 3 major providers compare",[27,655,656],{},"The concept is universal, even though the vocabulary shifts slightly between providers.",[35,658,659,674],{},[38,660,661],{},[41,662,663,665,668,671],{},[44,664,67],{},[44,666,667],{},"Top-level location",[44,669,670],{},"Isolated unit inside it",[44,672,673],{},"Typical minimum per location",[57,675,676,690,702],{},[41,677,678,681,684,687],{},[62,679,680],{},"AWS",[62,682,683],{},"Region",[62,685,686],{},"Availability Zone",[62,688,689],{},"3",[41,691,692,695,697,699],{},[62,693,694],{},"Azure",[62,696,683],{},[62,698,686],{},[62,700,701],{},"3 (in AZ-enabled regions)",[41,703,704,707,709,712],{},[62,705,706],{},"Google Cloud",[62,708,683],{},[62,710,711],{},"Zone",[62,713,689],{},[27,715,716],{},"One structural difference is worth knowing: if an entire Azure Region experiences a failure, every Availability Zone inside it can be affected, because Azure builds a Region out of its Zones. AWS and Google Cloud design Regions to be isolated from each other, so a failure specific to 1 Region should not spread to a different Region. This is a design detail, not something that changes how you use multi-AZ day to day, but it explains why \"which Regions to use\" is itself sometimes an availability decision, not just a latency one.",[22,718,197],{"id":196},[27,720,721],{},"A Region picks where your resources live; the Availability Zones inside it are what actually protect you from a single data center's bad day. Deploy across at least 2, ideally 3, AZs whenever an application needs to stay up, and reach for multiple Regions only when an entire geographic area going dark is a risk you cannot accept. Now that you know how providers organize the physical map beneath the cloud, the next lesson covers what you actually rent inside that map: compute.",{"title":202,"searchDepth":203,"depth":203,"links":723},[724,725,726,727,728,729,730],{"id":604,"depth":206,"text":605},{"id":611,"depth":206,"text":612},{"id":621,"depth":206,"text":622},{"id":631,"depth":206,"text":632},{"id":641,"depth":206,"text":642},{"id":652,"depth":206,"text":653},{"id":196,"depth":206,"text":197},[732],{"slug":649,"concept":733,"style":217,"aspectRatio":218,"labels":734},"A hierarchy diagram with 3 nested levels, read top to bottom. Level 1: a world map with a handful of pins, each pin labeled as one Region. Level 2: one Region pin expands into 3 Availability Zone boxes side by side, each drawn as a distinct physical location. Level 3: each Availability Zone box expands into 2 small data center icons inside it, each with its own power and network lines, to show that a single AZ is itself more than one building. A footer strip carries the resilience takeaway.",[735,736,737,738],"Region: a geographic area, such as US East (N. Virginia)","Availability Zone: one or more isolated data centers inside a Region","Data center: independent power, cooling, and networking","A failure in one Availability Zone should never reach another.",[594,595,596,597],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/01-regions-and-availability-zones",{"passingScore":230,"questions":743},[744,752,761,765,773,781,789],{"question":745,"type":234,"options":746,"correctAnswer":749,"explanation":751},"A team runs its entire application on EC2 instances in a single Availability Zone. What is the main risk of this setup?",[747,748,749,750],"The application will run slower than if it used multiple AZs","AWS will not allow single-AZ deployments for production workloads","A single-AZ failure, such as a data center power or cooling outage, takes the entire application down","There is no risk, since Availability Zones never fail","A single Availability Zone is one or more discrete data centers, and a failure there, power, cooling, flooding, fire, is isolated to that AZ. If every instance sits in that one AZ, the whole application goes down with it. Spreading the same instances across 2 or 3 AZs means one AZ's failure only removes part of the capacity.",{"question":753,"type":257,"options":754,"correctAnswers":759,"explanation":760},"Which of the following are true about how AWS structures Availability Zones within a Region? (Select all that apply.)",[755,756,757,758],"Each Region has at least 3 Availability Zones","Availability Zones are connected by low-latency, high-bandwidth dedicated networking","An Availability Zone can span more than one discrete data center","Availability Zones in the same Region share a single power grid to reduce cost",[755,756,757],"AWS Regions ship with a minimum of 3 AZs, linked by dedicated low-latency metro fiber so cross-AZ traffic stays fast, and each AZ itself can be one or more discrete data centers. Shared power would defeat the entire point of an AZ: each one has its own independent power, cooling, and physical security, precisely so a power failure in one AZ cannot reach another.",{"question":762,"type":234,"options":763,"correctAnswer":247,"explanation":764},"A company needs to protect its application from an outage that takes down an entire geographic region, not just one data center. Deploying across multiple Availability Zones in the same Region is sufficient to guarantee this.",[246,247],"Multi-AZ protects against a failure inside one data center or AZ, not against an event that affects an entire geographic area, a widespread natural disaster or a regional network failure. Surviving a whole-region event requires deploying across multiple Regions, a different and larger commitment than multi-AZ.",{"question":766,"type":234,"options":767,"correctAnswer":769,"explanation":772},"In AWS naming, an Availability Zone code looks like us-east-2a. What does the trailing letter identify?",[768,769,770,771],"The specific data center building number","The Availability Zone within the named Region","The customer's AWS account partition","The generation of hardware running in that zone","The code before the letter, us-east-2, names the Region, and the trailing letter, a, b, c, and so on, identifies one specific Availability Zone inside that Region. AWS also maps each AZ to an AZ ID behind the scenes, so the same physical location is consistent across different AWS accounts even though the a/b/c letters are assigned per account.",{"question":774,"type":234,"options":775,"correctAnswer":777,"explanation":780},"Why do cloud providers place the data centers inside one Availability Zone many kilometers apart from the data centers in a neighboring Availability Zone, rather than right next door?",[776,777,778,779],"To reduce the provider's real estate costs","So that a single localized disaster, a fire, a flood, a tornado, cannot plausibly damage 2 Availability Zones at once","Distance is required by international data-transfer law","It has no real purpose beyond marketing","The physical separation is the entire point of an Availability Zone: keeping AZs a meaningful distance apart, while still close enough for low-latency links between them, means a fire or flood at one AZ has no physical path to reach another. Distance without redundant power and networking would not achieve this on its own, which is why both matter together.",{"question":782,"type":234,"options":783,"correctAnswer":784,"explanation":788},"A learner assumes that since Google Cloud subnets are regional resources instead of zonal, Google Cloud regions must not use Availability Zones at all. Why is that assumption wrong?",[784,785,786,787],"Google Cloud does use isolated zones inside each region, generally at least 3; only its subnet resource happens to span the whole region instead of a single zone","The assumption is correct, Google Cloud has no concept of zones","Google Cloud only isolates by continent, not by data center","Subnets and zones are the same concept in Google Cloud, so this question does not apply","Google Cloud regions are still built from multiple isolated zones, the direct equivalent of an AWS Availability Zone. What differs is scope for a specific resource: a Google Cloud subnet is defined once per region and reaches every zone in it, while an AWS subnet is pinned to a single AZ. That is a networking design choice, not a sign that zone-level isolation is missing.",{"question":790,"type":234,"options":791,"correctAnswer":794,"explanation":796},"A retailer's checkout service must never go fully offline, even if one data center loses power during a flash sale. What is the most direct fix based on what this lesson covers?",[792,793,794,795],"Switch to a faster instance type","Move the entire workload to a single, larger data center","Deploy the service across multiple Availability Zones in the Region instead of one","Wait for the provider to fix the outage, since nothing can be done in advance","Spreading the same service across multiple AZs means the loss of any single AZ, including a power failure during peak traffic, leaves the other AZs still serving checkout requests. A single, larger data center recreates the exact single point of failure this lesson opened with; it just makes the failure bigger.",{"title":590,"description":591},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/01-regions-and-availability-zones","RCsBDdNOxQh4cQt1FCGGi44NuThUKLNiq2mMDIuHrwg"]