[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"next-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-compute-services-en":4,"lesson-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-compute-services-en":302,"prev-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-compute-services-en":596},null,{"locked":5,"reason":3,"meta":6,"item":16},false,{"title":7,"description":8,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":11},"Storage Services","Object, block, and file storage: how each one organizes data differently, which workloads each one actually fits, and the exam-favorite mistake of treating them as interchangeable.",17,"beginner",[12,13,14,15],"Distinguish object, block, and file storage by how each one organizes and grants access to data","Match a storage type to a workload based on its access pattern","Explain why durability and availability are 2 separate guarantees, not one","Identify the object, block, and file storage products offered by AWS, Azure, and Google Cloud",{"id":17,"title":7,"body":18,"description":8,"difficulty":10,"estimatedMinutes":9,"extension":227,"infographics":228,"isFree":5,"learningObjectives":238,"meta":239,"navigation":240,"path":241,"quiz":242,"seo":299,"stem":300,"__hash__":301},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/03-storage-services.md",{"type":19,"value":20,"toc":214},"minimark",[21,26,30,34,37,40,44,47,50,54,57,61,185,190,194,197,200,204,207,211],[22,23,25],"h2",{"id":24},"the-same-word-3-very-different-jobs","The same word, 3 very different jobs",[27,28,29],"p",{},"\"Storage\" sounds like one thing until you actually need it. A photo-sharing app storing 50 million user photos, a database writing thousands of small updates a second, and 5 web servers that all need to read the same shared configuration folder are 3 completely different problems, and no single storage design solves all 3 well. Cloud providers ship 3 distinct storage types for exactly this reason: object, block, and file. Telling them apart by what they are built to do, not just by their names, is the actual skill this lesson teaches.",[22,31,33],{"id":32},"object-storage-buckets-full-of-tagged-files","Object storage: buckets full of tagged files",[27,35,36],{},"Start with the photo-sharing app. Every image is uploaded once, read many times, and never edited in place, you replace a photo, you do not modify 4KB of it. Amazon S3, the model for object storage, organizes data around exactly that pattern: a bucket is a container, and each file inside it is an object, addressed by a unique key rather than a folder path. There is no real folder hierarchy underneath, just a flat namespace where the key \"photos/vacation/beach.jpg\" looks like a path but is really just a string.",[27,38,39],{},"Object storage trades away in-place editing for massive scale, low cost, and strong durability, S3 is designed for 99.999999999% (11 nines) durability, achieved by storing data redundantly across multiple Availability Zones. That combination is why object storage is the default choice for data lakes, backups, static website assets, and media files: workloads defined by write-once, read-often access, not by constant small edits.",[22,41,43],{"id":42},"block-storage-numbered-chunks-for-one-machine","Block storage: numbered chunks for one machine",[27,45,46],{},"Now consider a relational database writing and rewriting rows constantly. That workload needs low latency and the ability to change small pieces of data in place, exactly what object storage does not offer. Block storage, modeled on Amazon EBS, divides a volume into fixed-size chunks, addressed by number, and attaches that volume to a single instance, the same way a hard drive attaches to one computer. The operating system running on that instance can format the volume, mount it, and treat it like local disk, because functionally, that is what it is.",[27,48,49],{},"Block storage is zonal: an EBS volume lives in 1 specific Availability Zone and can only attach to instances in that same AZ, which is exactly why a database sitting on a single EBS volume still needs its own replication or backup strategy to survive an AZ failure. In exchange for that constraint, block storage delivers the low-latency, high-IOPS performance a running database, or a virtual machine's own boot disk, actually needs.",[22,51,53],{"id":52},"file-storage-one-folder-tree-many-machines-at-once","File storage: one folder tree, many machines at once",[27,55,56],{},"The third scenario, 5 web servers sharing the same configuration directory, needs something neither of the other 2 provides directly: simultaneous access from multiple machines to the same hierarchical folder structure. File storage, modeled on Amazon EFS, solves this using a network file system protocol (NFS), so every server mounts the same file system and sees the same folders and files, with changes from one visible to the others immediately. Unlike a single-attach EBS volume, a file system like EFS scales automatically as data is added and can be mounted by many EC2 instances, containers, and even on-premises servers at once.",[22,58,60],{"id":59},"the-boundary-side-by-side","The boundary, side by side",[62,63,64,83],"table",{},[65,66,67],"thead",{},[68,69,70,74,77,80],"tr",{},[71,72,73],"th",{},"Property",[71,75,76],{},"Object",[71,78,79],{},"Block",[71,81,82],{},"File",[84,85,86,101,115,129,143,157,171],"tbody",{},[68,87,88,92,95,98],{},[89,90,91],"td",{},"Data organized as",[89,93,94],{},"Flat namespace of key-addressed objects",[89,96,97],{},"Fixed-size numbered blocks",[89,99,100],{},"Hierarchical folders and files",[68,102,103,106,109,112],{},[89,104,105],{},"Attaches to",[89,107,108],{},"Accessed over the network by any authorized client",[89,110,111],{},"One instance at a time (typically)",[89,113,114],{},"Many instances at once",[68,116,117,120,123,126],{},[89,118,119],{},"Best access pattern",[89,121,122],{},"Write once, read often, no in-place edits",[89,124,125],{},"Frequent small reads and writes, low latency",[89,127,128],{},"Shared reads and writes across machines",[68,130,131,134,137,140],{},[89,132,133],{},"Typical use case",[89,135,136],{},"Backups, media, data lakes, static assets",[89,138,139],{},"Databases, boot volumes, transactional workloads",[89,141,142],{},"Shared content, home directories, config shared across a fleet",[68,144,145,148,151,154],{},[89,146,147],{},"AWS product",[89,149,150],{},"S3",[89,152,153],{},"EBS",[89,155,156],{},"EFS",[68,158,159,162,165,168],{},[89,160,161],{},"Azure product",[89,163,164],{},"Blob Storage",[89,166,167],{},"Managed Disks",[89,169,170],{},"Azure Files",[68,172,173,176,179,182],{},[89,174,175],{},"Google Cloud product",[89,177,178],{},"Cloud Storage",[89,180,181],{},"Persistent Disk",[89,183,184],{},"Filestore",[186,187],"infographic",{"alt":188,"slug":189},"Three side-by-side diagrams showing the actual shape of object, block, and file storage: a flat bucket of tagged objects, a volume sliced into numbered blocks attached to one server, and a shared folder tree mounted by multiple servers at once.","storage-services-shapes",[22,191,193],{"id":192},"worked-example-1-e-commerce-site-3-storage-decisions","Worked example: 1 e-commerce site, 3 storage decisions",[27,195,196],{},"An e-commerce platform needs to store 3 different kinds of data, and the right answer is different every time. Product photos, millions of them, uploaded once and served to shoppers constantly: object storage, because nothing about a product photo needs in-place editing, and the volume favors object storage's scale and cost. The transactional database tracking orders and inventory: block storage, because every checkout writes and rewrites rows and needs the low latency only a directly attached volume delivers. A shared directory of session cache files that 6 identical web servers behind a load balancer all need to read and write together: file storage, because it is the only one of the 3 built for simultaneous multi-instance access to the same folder tree.",[27,198,199],{},"Swap any 2 of those choices and the system either breaks outright, a database will not run acceptably on object storage, or works but wastes money and performance on a mismatch it did not need to make.",[22,201,203],{"id":202},"the-misconception-cheaper-does-not-mean-interchangeable","The misconception: cheaper does not mean interchangeable",[27,205,206],{},"It is tempting to look at object storage's low per-gigabyte price and assume it is simply the \"budget option\" you can swap in anywhere. It is not. Object storage is cheap precisely because it gives up the in-place, low-latency random access a running database or a boot volume depends on. Moving a database's data files onto object storage does not save money on a working system, it produces a system that does not work, because the storage type and the access pattern have to match. Price is a consequence of the tradeoff, not a substitute for understanding it.",[22,208,210],{"id":209},"where-this-leaves-you","Where this leaves you",[27,212,213],{},"3 questions sort almost any storage decision: does the data get edited in place or just written once and read, does it need to be shared by multiple machines at once, and does it need to boot or run an operating system directly. Object storage answers \"written once, read often, no sharing requirement.\" Block storage answers \"attached to one machine, edited constantly, needs speed.\" File storage answers \"shared folder, multiple machines.\" The next lesson moves from raw storage to the layer most applications actually talk to directly: databases.",{"title":215,"searchDepth":216,"depth":216,"links":217},"",3,[218,220,221,222,223,224,225,226],{"id":24,"depth":219,"text":25},2,{"id":32,"depth":219,"text":33},{"id":42,"depth":219,"text":43},{"id":52,"depth":219,"text":53},{"id":59,"depth":219,"text":60},{"id":192,"depth":219,"text":193},{"id":202,"depth":219,"text":203},{"id":209,"depth":219,"text":210},"md",[229],{"slug":189,"concept":230,"style":231,"aspectRatio":232,"labels":233},"A 3-panel comparison diagram, one panel per storage type, each showing the actual shape its data takes rather than a text description. Panel 1, Object: a flat, borderless bucket icon filled with irregularly shaped blobs, each blob tagged with a short key string, no folders. Panel 2, Block: a single rectangular volume sliced into a neat grid of equal-sized numbered blocks stacked like a ledger, attached by a line to one server icon. Panel 3, File: a rooted tree of nested folder icons branching into files, with 3 small server icons all touching the same tree to show shared access. A footer strip states the one-line access-pattern takeaway for each.","diagram","16:9",[234,235,236,237],"Object: a flat bucket of tagged, unstructured blobs. No folders.","Block: fixed-size chunks addressed by number, attached to one server.","File: a shared folder tree that multiple servers can read and write at once.","Pick by access pattern, not by which one sounds simplest.",[12,13,14,15],{},true,"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/03-storage-services",{"passingScore":243,"questions":244},70,[245,254,260,265,275,283,291],{"question":246,"type":247,"options":248,"correctAnswer":251,"explanation":253},"A photo-sharing app needs to store tens of millions of user-uploaded images, each one written once and read many times afterward, with no need to edit the file in place. Which storage type fits best?","single",[249,250,251,252],"File storage","Block storage","Object storage","None of these, images require a database","Object storage is built for exactly this pattern: huge volumes of unstructured files stored in a flat namespace, written once, read often, and never edited in place. Block storage is built for low-latency, in-place random writes, and file storage's advantage is simultaneous shared access, neither of which this workload needs.",{"question":255,"type":247,"options":256,"correctAnswer":257,"explanation":259},"Amazon EBS volumes are zonal resources, meaning a volume can only attach to instances within the same Availability Zone where it was created.",[257,258],"True","False","An EBS volume lives in one specific Availability Zone and can only attach to EC2 instances in that same AZ. This is exactly why a database on EBS still needs its own replication or backup strategy across AZs. Object storage like S3, by contrast, is accessed as a Regional service, not tied to a single AZ.",{"question":261,"type":247,"options":262,"correctAnswer":249,"explanation":264},"5 web servers need to read and write the same shared directory of uploaded configuration files at the same time. Which storage type is purpose-built for this?",[251,249,250,263],"Any of the 3 works equally well","File storage, using a protocol like NFS, is designed for exactly this case: multiple servers mounting and using the same hierarchical folder structure at once. Block storage attaches to a single instance at a time in most configurations, and object storage has no concept of a mountable shared folder tree the way file storage does.",{"question":266,"type":267,"options":268,"correctAnswers":273,"explanation":274},"Which of the following statements correctly distinguish block storage from object storage? (Select all that apply.)","multiple",[269,270,271,272],"Block storage divides data into fixed-size chunks, while object storage stores whole files as unstructured objects","Object storage is generally better suited to low-latency, high-IOPS database workloads than block storage","Block storage typically attaches to a single instance, while object storage is accessed over the network by any authorized client","Object storage uses a flat namespace, while file and block systems are typically organized hierarchically or by fixed address",[269,271,272],"Block storage's fixed-size chunks and direct instance attachment give it the low latency that transactional databases need, which makes it the better fit for that workload, not object storage. Object storage trades that low-latency, in-place editing capability for massive scale and a flat, key-based namespace instead of folders or fixed block addresses.",{"question":276,"type":247,"options":277,"correctAnswer":279,"explanation":282},"Amazon S3 advertises 99.999999999% (11 nines) durability. What does 'durability' actually promise, as distinct from 'availability'?",[278,279,280,281],"That the service will never be slow to respond","That stored data will not be lost or corrupted over time, independent of whether the service is reachable at any given moment","That the storage service will always be reachable and responsive","That data will always be encrypted in transit","Durability is about data surviving intact over time, achieved by redundantly storing copies across multiple Availability Zones. Availability is a separate promise, about whether the service can be reached and responds successfully right now. A service can be briefly unavailable during a network issue without losing a single byte of durably stored data.",{"question":284,"type":247,"options":285,"correctAnswer":288,"explanation":290},"A team decides to save money by moving their relational database's data files from a block storage volume onto object storage, since object storage is cheaper per gigabyte. What is the most likely result?",[286,287,288,289],"The database runs exactly the same, just cheaper","The database performs better, since object storage scales further","The database will not work as expected, because object storage does not support the low-latency, in-place random reads and writes a running database engine needs","Nothing changes, because all storage types are interchangeable under the hood","A running database constantly reads and overwrites small pieces of its data files, the exact access pattern block storage is built for and object storage is not. Object storage's price advantage exists precisely because it gives up that in-place, low-latency access, so it is cheaper for the workloads it fits and unusable for the ones it does not.",{"question":292,"type":247,"options":293,"correctAnswer":295,"explanation":298},"Which pairing correctly matches an AWS storage product to its category?",[294,295,296,297],"Amazon EFS: block storage","Amazon S3: object storage","Amazon EBS: object storage","Amazon S3: file storage","Amazon S3 is AWS's object storage service, built around buckets and objects in a flat namespace. Amazon EBS is block storage, and Amazon EFS is file storage, the reverse of the other 2 pairings offered as distractors.",{"title":7,"description":8},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/03-storage-services","Ck8geL1GVUilT-0CUhAy6rB3r3hg_LBd2TLvnC4dOlg",{"locked":5,"reason":3,"meta":303,"item":311},{"title":304,"description":305,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":306},"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.",[307,308,309,310],"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":312,"title":304,"body":313,"description":305,"difficulty":10,"estimatedMinutes":9,"extension":227,"infographics":531,"isFree":5,"learningObjectives":541,"meta":542,"navigation":240,"path":543,"quiz":544,"seo":593,"stem":594,"__hash__":595},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/02-compute-services.md",{"type":19,"value":314,"toc":522},[315,319,322,326,329,400,403,406,410,413,420,426,429,433,436,440,443,447,507,510,514,517,519],[22,316,318],{"id":317},"what-you-are-actually-renting","What you are actually renting",[27,320,321],{},"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,323,325],{"id":324},"virtual-machines-the-baseline-unit","Virtual machines: the baseline unit",[27,327,328],{},"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.",[62,330,331,343],{},[65,332,333],{},[68,334,335,338,341],{},[71,336,337],{},"Family",[71,339,340],{},"Optimized for",[71,342,133],{},[84,344,345,356,367,378,389],{},[68,346,347,350,353],{},[89,348,349],{},"General purpose",[89,351,352],{},"A balance of compute, memory, and networking",[89,354,355],{},"Web servers, small-to-medium databases, dev environments",[68,357,358,361,364],{},[89,359,360],{},"Compute optimized",[89,362,363],{},"High-performance processors, more vCPU per GB of memory",[89,365,366],{},"Batch processing, media transcoding, game servers",[68,368,369,372,375],{},[89,370,371],{},"Memory optimized",[89,373,374],{},"Large amounts of RAM relative to vCPU",[89,376,377],{},"In-memory databases, real-time analytics",[68,379,380,383,386],{},[89,381,382],{},"Storage optimized",[89,384,385],{},"High, low-latency local disk throughput",[89,387,388],{},"High-throughput databases, streaming data processing",[68,390,391,394,397],{},[89,392,393],{},"Accelerated computing",[89,395,396],{},"GPUs or other hardware accelerators",[89,398,399],{},"Machine learning training, graphics rendering",[27,401,402],{},"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,404,405],{},"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,407,409],{"id":408},"vertical-scaling-versus-horizontal-scaling","Vertical scaling versus horizontal scaling",[27,411,412],{},"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,414,415,419],{},[416,417,418],"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,421,422,425],{},[416,423,424],{},"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,427,428],{},"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,430,432],{"id":431},"managed-compute-someone-else-runs-the-fleet","Managed compute: someone else runs the fleet",[27,434,435],{},"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,437,439],{"id":438},"the-full-compute-spectrum","The full compute spectrum",[27,441,442],{},"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.",[186,444],{"alt":445,"slug":446},"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",[62,448,449,462],{},[65,450,451],{},[68,452,453,456,459],{},[71,454,455],{},"Option",[71,457,458],{},"What you manage",[71,460,461],{},"Typical startup",[84,463,464,475,485,496],{},[68,465,466,469,472],{},[89,467,468],{},"Virtual machine",[89,470,471],{},"OS, runtime, scaling",[89,473,474],{},"Minutes",[68,476,477,480,483],{},[89,478,479],{},"Managed compute",[89,481,482],{},"Application code and configuration",[89,484,474],{},[68,486,487,490,493],{},[89,488,489],{},"Container",[89,491,492],{},"Application, its runtime dependencies, packaged together",[89,494,495],{},"Seconds",[68,497,498,501,504],{},[89,499,500],{},"Serverless function",[89,502,503],{},"Only the function code",[89,505,506],{},"Milliseconds",[27,508,509],{},"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,511,513],{"id":512},"the-misconception-serverless-is-always-cheaper","The misconception: \"serverless is always cheaper\"",[27,515,516],{},"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,518,210],{"id":209},[27,520,521],{},"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":215,"searchDepth":216,"depth":216,"links":523},[524,525,526,527,528,529,530],{"id":317,"depth":219,"text":318},{"id":324,"depth":219,"text":325},{"id":408,"depth":219,"text":409},{"id":431,"depth":219,"text":432},{"id":438,"depth":219,"text":439},{"id":512,"depth":219,"text":513},{"id":209,"depth":219,"text":210},[532],{"slug":446,"concept":533,"style":534,"aspectRatio":232,"labels":535},"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",[536,537,538,539,540],"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.",[307,308,309,310],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/02-compute-services",{"passingScore":243,"questions":545},[546,550,556,560,568,577,585],{"question":547,"type":247,"options":548,"correctAnswer":360,"explanation":549},"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?",[371,382,360,349],"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":551,"type":247,"options":552,"correctAnswer":424,"explanation":555},"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?",[424,418,553,554],"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":557,"type":247,"options":558,"correctAnswer":258,"explanation":559},"Vertical scaling and horizontal scaling solve the same problem in the same way, so it never matters which one a team picks.",[257,258],"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":561,"type":247,"options":562,"correctAnswer":566,"explanation":567},"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?",[563,564,565,566],"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":569,"type":267,"options":570,"correctAnswers":575,"explanation":576},"Which of the following statements accurately place items on the control-versus-convenience compute spectrum? (Select all that apply.)",[571,572,573,574],"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",[571,572,574],"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":578,"type":247,"options":579,"correctAnswer":581,"explanation":584},"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?",[580,581,582,583],"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":586,"type":247,"options":587,"correctAnswer":589,"explanation":592},"According to this lesson, where do containers and serverless functions get covered in full?",[588,589,590,591],"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":304,"description":305},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/02-compute-services","5paMPWdXDfm7PpzvTUl3vO7C3EfwjrxJNYgmXEBKrEw",{"locked":5,"reason":3,"meta":597,"item":606},{"title":598,"description":599,"isFree":240,"estimatedMinutes":600,"difficulty":10,"learningObjectives":601},"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,[602,603,604,605],"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":607,"title":598,"body":608,"description":599,"difficulty":10,"estimatedMinutes":600,"extension":227,"infographics":740,"isFree":240,"learningObjectives":748,"meta":749,"navigation":240,"path":750,"quiz":751,"seo":806,"stem":807,"__hash__":808},"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":609,"toc":731},[610,614,617,621,624,627,631,634,637,641,644,647,651,654,658,662,665,723,726,728],[22,611,613],{"id":612},"the-data-center-that-never-fails-does-not-exist","The data center that never fails does not exist",[27,615,616],{},"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,618,620],{"id":619},"regions-where-in-the-world-your-resources-live","Regions: where in the world your resources live",[27,622,623],{},"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,625,626],{},"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,628,630],{"id":629},"availability-zones-isolation-inside-the-region","Availability Zones: isolation inside the Region",[27,632,633],{},"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,635,636],{},"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,638,640],{"id":639},"worked-example-1-az-versus-3","Worked example: 1 AZ versus 3",[27,642,643],{},"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,645,646],{},"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,648,650],{"id":649},"the-misconception-multi-az-is-not-multi-region","The misconception: multi-AZ is not multi-region",[27,652,653],{},"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.",[186,655],{"alt":656,"slug":657},"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,659,661],{"id":660},"how-the-3-major-providers-compare","How the 3 major providers compare",[27,663,664],{},"The concept is universal, even though the vocabulary shifts slightly between providers.",[62,666,667,683],{},[65,668,669],{},[68,670,671,674,677,680],{},[71,672,673],{},"Provider",[71,675,676],{},"Top-level location",[71,678,679],{},"Isolated unit inside it",[71,681,682],{},"Typical minimum per location",[84,684,685,699,711],{},[68,686,687,690,693,696],{},[89,688,689],{},"AWS",[89,691,692],{},"Region",[89,694,695],{},"Availability Zone",[89,697,698],{},"3",[68,700,701,704,706,708],{},[89,702,703],{},"Azure",[89,705,692],{},[89,707,695],{},[89,709,710],{},"3 (in AZ-enabled regions)",[68,712,713,716,718,721],{},[89,714,715],{},"Google Cloud",[89,717,692],{},[89,719,720],{},"Zone",[89,722,698],{},[27,724,725],{},"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,727,210],{"id":209},[27,729,730],{},"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":215,"searchDepth":216,"depth":216,"links":732},[733,734,735,736,737,738,739],{"id":612,"depth":219,"text":613},{"id":619,"depth":219,"text":620},{"id":629,"depth":219,"text":630},{"id":639,"depth":219,"text":640},{"id":649,"depth":219,"text":650},{"id":660,"depth":219,"text":661},{"id":209,"depth":219,"text":210},[741],{"slug":657,"concept":742,"style":231,"aspectRatio":232,"labels":743},"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.",[744,745,746,747],"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.",[602,603,604,605],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/01-regions-and-availability-zones",{"passingScore":243,"questions":752},[753,761,770,774,782,790,798],{"question":754,"type":247,"options":755,"correctAnswer":758,"explanation":760},"A team runs its entire application on EC2 instances in a single Availability Zone. What is the main risk of this setup?",[756,757,758,759],"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":762,"type":267,"options":763,"correctAnswers":768,"explanation":769},"Which of the following are true about how AWS structures Availability Zones within a Region? (Select all that apply.)",[764,765,766,767],"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",[764,765,766],"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":771,"type":247,"options":772,"correctAnswer":258,"explanation":773},"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.",[257,258],"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":775,"type":247,"options":776,"correctAnswer":778,"explanation":781},"In AWS naming, an Availability Zone code looks like us-east-2a. What does the trailing letter identify?",[777,778,779,780],"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":783,"type":247,"options":784,"correctAnswer":786,"explanation":789},"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?",[785,786,787,788],"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":791,"type":247,"options":792,"correctAnswer":793,"explanation":797},"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?",[793,794,795,796],"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":799,"type":247,"options":800,"correctAnswer":803,"explanation":805},"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?",[801,802,803,804],"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":598,"description":599},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/01-regions-and-availability-zones","RCsBDdNOxQh4cQt1FCGGi44NuThUKLNiq2mMDIuHrwg"]