[{"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-storage-services-en":4,"lesson-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-storage-services-en":387,"prev-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-storage-services-en":653},null,{"locked":5,"reason":3,"meta":6,"item":16},false,{"title":7,"description":8,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":11},"Databases in the Cloud","What a managed database service actually takes off your plate, how relational and NoSQL databases model data differently, and which one fits which part of a real application.",18,"beginner",[12,13,14,15],"Explain what a managed database service takes over compared to running a database yourself","Distinguish relational databases from NoSQL databases by data model and query pattern","Choose a relational or NoSQL database for a given workload based on its access pattern","Identify the major managed relational and NoSQL products offered by AWS, Azure, and Google Cloud",{"id":17,"title":7,"body":18,"description":8,"difficulty":10,"estimatedMinutes":9,"extension":310,"infographics":311,"isFree":5,"learningObjectives":320,"meta":321,"navigation":322,"path":323,"quiz":324,"seo":384,"stem":385,"__hash__":386},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/04-databases-in-the-cloud.md",{"type":19,"value":20,"toc":297},"minimark",[21,26,30,34,37,142,145,149,152,155,159,162,166,171,276,280,283,287,290,294],[22,23,25],"h2",{"id":24},"the-2-am-problem-a-managed-database-solves","The 2 a.m. problem a managed database solves",[27,28,29],"p",{},"A database crashes at 2 a.m. Someone has to notice, diagnose whether it was a bad patch, a disk failure, or a runaway query, and bring it back without losing data. Running a database yourself, even on a cloud virtual machine, means that someone is you. A managed database service exists to make that someone the provider instead, for everything except the parts only you can answer, like which queries your application actually runs.",[22,31,33],{"id":32},"what-managed-actually-takes-over","What \"managed\" actually takes over",[27,35,36],{},"Amazon RDS is the model for a managed relational database, and its own documentation is specific about the split. Compare running a database on-premises, on a plain EC2 virtual machine, and on RDS:",[38,39,40,59],"table",{},[41,42,43],"thead",{},[44,45,46,50,53,56],"tr",{},[47,48,49],"th",{},"Task",[47,51,52],{},"On-premises",[47,54,55],{},"On EC2",[47,57,58],{},"On RDS",[60,61,62,75,87,98,109,120,131],"tbody",{},[44,63,64,68,71,73],{},[65,66,67],"td",{},"Application optimization",[65,69,70],{},"You",[65,72,70],{},[65,74,70],{},[44,76,77,80,82,84],{},[65,78,79],{},"Scaling",[65,81,70],{},[65,83,70],{},[65,85,86],{},"AWS",[44,88,89,92,94,96],{},[65,90,91],{},"High availability",[65,93,70],{},[65,95,70],{},[65,97,86],{},[44,99,100,103,105,107],{},[65,101,102],{},"Database backups",[65,104,70],{},[65,106,70],{},[65,108,86],{},[44,110,111,114,116,118],{},[65,112,113],{},"Database software patching",[65,115,70],{},[65,117,70],{},[65,119,86],{},[44,121,122,125,127,129],{},[65,123,124],{},"Operating system patching",[65,126,70],{},[65,128,70],{},[65,130,86],{},[44,132,133,136,138,140],{},[65,134,135],{},"Server maintenance",[65,137,70],{},[65,139,86],{},[65,141,86],{},[27,143,144],{},"Moving from on-premises to EC2 hands over the physical hardware. Moving from EC2 to RDS hands over almost everything about running the database engine itself, patching, backups, scaling, failure detection and recovery. What stays with you in every column is query tuning, because that depends entirely on your specific application, your specific queries, and your specific data, work no managed service can do on your behalf.",[22,146,148],{"id":147},"relational-databases-rows-that-relate-to-other-rows","Relational databases: rows that relate to other rows",[27,150,151],{},"Picture an online store's Orders table. Every row needs a customer_id that points to a real row in a separate Customers table, and a product_id that points to a real row in Inventory. That enforced relationship, an order that cannot exist without a matching customer and product, is the defining feature of a relational database: data organized into tables with rows and columns, queried with SQL, and connected across tables through keys. Amazon RDS supports 6 engines this way: MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, Oracle Database, and IBM Db2, all queryable with the same relational model even though the underlying engines differ.",[27,153,154],{},"That structure is exactly what an order needs. If a payment fails partway through checkout, the database must not leave an order pointing at a customer or inventory row that no longer makes sense, and relational databases are built to enforce that kind of consistency.",[22,156,158],{"id":157},"nosql-databases-fast-lookups-without-the-relationships","NoSQL databases: fast lookups without the relationships",[27,160,161],{},"Now picture a leaderboard for a game with 10 million concurrent players, or a shopping cart that gets read and rewritten on every click. Neither one needs to be joined against another table, and neither one benefits from the overhead of enforcing table relationships. NoSQL databases, modeled on Amazon DynamoDB, drop the table-and-join model in favor of items retrieved directly by a key, with a flexible structure that can differ from one item to the next. DynamoDB advertises single-digit millisecond performance whether an application serves tens of thousands or hundreds of millions of concurrent users, because the entire design trades away cross-item relationships for that kind of scale.",[22,163,165],{"id":164},"the-boundary-match-the-model-to-the-access-pattern","The boundary: match the model to the access pattern",[167,168],"infographic",{"alt":169,"slug":170},"A comparison diagram contrasting relational database tables connected by join lines with independent NoSQL items of varying shape, each addressed by a partition key.","databases-relational-vs-nosql-shape",[38,172,173,186],{},[41,174,175],{},[44,176,177,180,183],{},[47,178,179],{},"Property",[47,181,182],{},"Relational",[47,184,185],{},"NoSQL",[60,187,188,199,210,221,232,243,254,265],{},[44,189,190,193,196],{},[65,191,192],{},"Data organized as",[65,194,195],{},"Tables with fixed rows and columns",[65,197,198],{},"Independent items, flexible shape",[44,200,201,204,207],{},[65,202,203],{},"Relationships across records",[65,205,206],{},"Enforced through keys and joins",[65,208,209],{},"Not built in, usually avoided by design",[44,211,212,215,218],{},[65,213,214],{},"Query language",[65,216,217],{},"SQL",[65,219,220],{},"Product-specific APIs, key-based lookups",[44,222,223,226,229],{},[65,224,225],{},"Scaling model",[65,227,228],{},"Primarily vertical, with read replicas for reads",[65,230,231],{},"Horizontal by design, built for massive concurrent access",[44,233,234,237,240],{},[65,235,236],{},"Strong fit for",[65,238,239],{},"Transactions that must stay consistent across related records",[65,241,242],{},"High-scale, simple-lookup workloads like sessions, carts, leaderboards",[44,244,245,248,251],{},[65,246,247],{},"AWS product",[65,249,250],{},"RDS",[65,252,253],{},"DynamoDB",[44,255,256,259,262],{},[65,257,258],{},"Azure product",[65,260,261],{},"Azure SQL Database",[65,263,264],{},"Azure Cosmos DB",[44,266,267,270,273],{},[65,268,269],{},"Google Cloud product",[65,271,272],{},"Cloud SQL",[65,274,275],{},"Firestore",[22,277,279],{"id":278},"worked-example-1-platform-2-databases","Worked example: 1 platform, 2 databases",[27,281,282],{},"The same e-commerce platform from the previous lesson needs both models at once, not a single choice between them. Orders, customers, and inventory go in a relational database, because an order that references a nonexistent customer or an inventory row is a bug, and the relational model is what prevents it. Shopping cart contents and session data go in a NoSQL database, because that data changes constantly, gets read on nearly every page load, and never needs to be joined against the Orders table to do its job. Running both side by side, rather than forcing every kind of data through one model, is normal architecture, not a compromise.",[22,284,286],{"id":285},"the-misconception-newer-does-not-mean-universally-better","The misconception: newer does not mean universally better",[27,288,289],{},"It is tempting to treat NoSQL as the modern upgrade and relational as the legacy option. That framing misses what each one actually gives up. NoSQL scales to enormous concurrent load precisely because it does not enforce relationships between items, the exact guarantee an order-and-inventory system depends on. A well-run application does not pick a side once, it puts each kind of data in the model built for its access pattern, which is why real systems commonly run relational and NoSQL databases side by side rather than choosing one for everything.",[22,291,293],{"id":292},"where-this-leaves-you","Where this leaves you",[27,295,296],{},"A managed database service takes over patching, backups, and failure recovery so you can focus on the queries and the schema only you understand. Reach for a relational database when records must stay consistent with each other across tables, and reach for NoSQL when the workload is a high-volume, simple lookup that does not need those relationships. The next lesson covers how traffic actually reaches these databases and the compute in front of them: cloud networking.",{"title":298,"searchDepth":299,"depth":299,"links":300},"",3,[301,303,304,305,306,307,308,309],{"id":24,"depth":302,"text":25},2,{"id":32,"depth":302,"text":33},{"id":147,"depth":302,"text":148},{"id":157,"depth":302,"text":158},{"id":164,"depth":302,"text":165},{"id":278,"depth":302,"text":279},{"id":285,"depth":302,"text":286},{"id":292,"depth":302,"text":293},"md",[312],{"slug":170,"concept":313,"style":314,"aspectRatio":315,"labels":316},"A 2-panel comparison. Left panel, Relational: 2 small grid tables, Orders and Customers, each with clearly ruled rows and columns, connected by a visible join line from an Orders row's customer_id column to a matching Customers row, showing structured cross-table relationships. Right panel, NoSQL: a set of independent item cards, each a self-contained document with its own set of fields (one card has 3 fields, another has 5, a third has a nested list), with no join lines between them, addressed instead by a highlighted partition key on each card. A footer strip states the one-line access-pattern takeaway for each.","comparison","16:9",[317,318,319],"Relational: fixed rows and columns, related across tables by keys.","NoSQL: independent items, each with its own shape, addressed by key.","Relational asks 'how do these tables relate.' NoSQL asks 'how do I look this up fast.'",[12,13,14,15],{},true,"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/04-databases-in-the-cloud",{"passingScore":325,"questions":326},70,[327,336,344,352,358,368,376],{"question":328,"type":329,"options":330,"correctAnswer":333,"explanation":335},"According to Amazon RDS's own management comparison, which of these tasks does RDS take over that running a database on a plain EC2 instance does not?","single",[331,332,333,334],"Query tuning for a specific application's SQL statements","Choosing the database schema","Database software patching, backups, and automatic failure detection and recovery","Writing the application code that connects to the database","RDS's own comparison shows patching, backups, and failure detection and recovery moving to AWS's side under RDS, while they stay with the customer on plain EC2. Query tuning stays the customer's job in both cases, since it depends entirely on the specific application and its queries, something no managed service can do for you.",{"question":337,"type":329,"options":338,"correctAnswer":341,"explanation":343},"An online store's Orders table stores a customer_id column that must always match a real row in the Customers table. This kind of structured, enforced relationship between tables is a defining feature of which data model?",[339,340,341,342],"NoSQL databases","Object storage","Relational databases","Block storage","Relational databases are built around exactly this: rows in tables, related to other tables through keys, queried with SQL. NoSQL databases are designed to avoid this kind of cross-table relationship in favor of independent, quickly retrievable items, which is precisely the difference that makes each one fit different workloads.",{"question":345,"type":329,"options":346,"correctAnswer":347,"explanation":351},"A gaming company needs to store leaderboard data for tens of millions of concurrent players, with single-digit millisecond reads at any scale, and does not need to join leaderboard entries against other tables. Which type of database fits this requirement best?",[347,348,349,350],"A NoSQL database like DynamoDB","A relational database like PostgreSQL","Neither, this data should not be stored in a database at all","A relational database, because leaderboards are inherently tabular","This is exactly the pattern NoSQL databases like DynamoDB are built for: massive concurrent scale, fast key-based lookups, and no need for cross-table joins. A relational database could technically store this data too, but scaling it to tens of millions of concurrent reads with single-digit millisecond latency is a far harder operational problem than DynamoDB is purpose-built to solve.",{"question":353,"type":329,"options":354,"correctAnswer":356,"explanation":357},"NoSQL databases are always faster than relational databases, which is why a well-run application should use NoSQL for every part of its data.",[355,356],"True","False","NoSQL scales more easily to very high, simple-lookup workloads, but it does that by giving up the enforced relationships and flexible ad hoc querying a relational database provides. An e-commerce order that must stay consistent with its linked customer and inventory rows is exactly the kind of data relational databases are built to protect, and NoSQL is not simply 'faster' for that job, it is a worse fit.",{"question":359,"type":360,"options":361,"correctAnswers":366,"explanation":367},"Which of the following are true about an Amazon RDS Multi-AZ deployment? (Select all that apply.)","multiple",[362,363,364,365],"AWS automatically provisions and maintains a standby DB instance in a different Availability Zone","It applies the same Availability Zone redundancy concept from earlier in this topic, specifically to a database","It guarantees the database will survive the loss of an entire AWS Region","It helps provide failover support if the primary DB instance's Availability Zone has a problem",[362,363,365],"Multi-AZ is the same AZ-level redundancy from the Regions and Availability Zones lesson, applied specifically to a database: a synchronous standby in a different AZ that AWS can fail over to. Like any multi-AZ setup, it protects against a single AZ's failure, not a failure of the entire Region, which would require a separate cross-Region strategy.",{"question":369,"type":329,"options":370,"correctAnswer":373,"explanation":375},"Which pairing correctly matches a managed database product to its data model?",[371,372,373,374],"Amazon RDS: NoSQL","Amazon DynamoDB: relational","Amazon DynamoDB: NoSQL","Amazon RDS: object storage","DynamoDB is AWS's managed NoSQL database, built around key-based access instead of tables and joins. Amazon RDS is the relational counterpart, running engines like MySQL, PostgreSQL, and SQL Server, not NoSQL and not a storage service at all.",{"question":377,"type":329,"options":378,"correctAnswer":381,"explanation":383},"An e-commerce platform needs to record orders that must always stay consistent with a specific customer and specific inventory rows, and separately needs to store session data that changes constantly and does not need to be joined against anything. What is the most defensible database strategy?",[379,380,381,382],"Use NoSQL for both, since it is newer technology","Use relational for both, since consistency always matters","Use a relational database for orders, where relationships must be enforced, and a NoSQL database for session data, where fast key-based access matters more than relationships","Store everything in object storage instead of a database","This is exactly the kind of decision covered in this lesson: match the data model to the access pattern, not to a single default choice. Orders need enforced relationships and consistency, the relational strength; session data needs fast, simple lookups at scale, the NoSQL strength. Real applications commonly run both side by side rather than forcing one model to do both jobs.",{"title":7,"description":8},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/04-databases-in-the-cloud","zYo6IvtYLYz1E_4TTIPM0I9KD-ku7mZYq1Ly8xKqTuE",{"locked":5,"reason":3,"meta":388,"item":397},{"title":389,"description":390,"isFree":5,"estimatedMinutes":391,"difficulty":10,"learningObjectives":392},"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,[393,394,395,396],"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":398,"title":389,"body":399,"description":390,"difficulty":10,"estimatedMinutes":391,"extension":310,"infographics":588,"isFree":5,"learningObjectives":597,"meta":598,"navigation":322,"path":599,"quiz":600,"seo":650,"stem":651,"__hash__":652},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/03-storage-services.md",{"type":19,"value":400,"toc":578},[401,405,408,412,415,418,422,425,428,432,435,439,552,556,560,563,566,570,573,575],[22,402,404],{"id":403},"the-same-word-3-very-different-jobs","The same word, 3 very different jobs",[27,406,407],{},"\"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,409,411],{"id":410},"object-storage-buckets-full-of-tagged-files","Object storage: buckets full of tagged files",[27,413,414],{},"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,416,417],{},"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,419,421],{"id":420},"block-storage-numbered-chunks-for-one-machine","Block storage: numbered chunks for one machine",[27,423,424],{},"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,426,427],{},"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,429,431],{"id":430},"file-storage-one-folder-tree-many-machines-at-once","File storage: one folder tree, many machines at once",[27,433,434],{},"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,436,438],{"id":437},"the-boundary-side-by-side","The boundary, side by side",[38,440,441,456],{},[41,442,443],{},[44,444,445,447,450,453],{},[47,446,179],{},[47,448,449],{},"Object",[47,451,452],{},"Block",[47,454,455],{},"File",[60,457,458,471,485,499,513,526,539],{},[44,459,460,462,465,468],{},[65,461,192],{},[65,463,464],{},"Flat namespace of key-addressed objects",[65,466,467],{},"Fixed-size numbered blocks",[65,469,470],{},"Hierarchical folders and files",[44,472,473,476,479,482],{},[65,474,475],{},"Attaches to",[65,477,478],{},"Accessed over the network by any authorized client",[65,480,481],{},"One instance at a time (typically)",[65,483,484],{},"Many instances at once",[44,486,487,490,493,496],{},[65,488,489],{},"Best access pattern",[65,491,492],{},"Write once, read often, no in-place edits",[65,494,495],{},"Frequent small reads and writes, low latency",[65,497,498],{},"Shared reads and writes across machines",[44,500,501,504,507,510],{},[65,502,503],{},"Typical use case",[65,505,506],{},"Backups, media, data lakes, static assets",[65,508,509],{},"Databases, boot volumes, transactional workloads",[65,511,512],{},"Shared content, home directories, config shared across a fleet",[44,514,515,517,520,523],{},[65,516,247],{},[65,518,519],{},"S3",[65,521,522],{},"EBS",[65,524,525],{},"EFS",[44,527,528,530,533,536],{},[65,529,258],{},[65,531,532],{},"Blob Storage",[65,534,535],{},"Managed Disks",[65,537,538],{},"Azure Files",[44,540,541,543,546,549],{},[65,542,269],{},[65,544,545],{},"Cloud Storage",[65,547,548],{},"Persistent Disk",[65,550,551],{},"Filestore",[167,553],{"alt":554,"slug":555},"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,557,559],{"id":558},"worked-example-1-e-commerce-site-3-storage-decisions","Worked example: 1 e-commerce site, 3 storage decisions",[27,561,562],{},"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,564,565],{},"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,567,569],{"id":568},"the-misconception-cheaper-does-not-mean-interchangeable","The misconception: cheaper does not mean interchangeable",[27,571,572],{},"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,574,293],{"id":292},[27,576,577],{},"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":298,"searchDepth":299,"depth":299,"links":579},[580,581,582,583,584,585,586,587],{"id":403,"depth":302,"text":404},{"id":410,"depth":302,"text":411},{"id":420,"depth":302,"text":421},{"id":430,"depth":302,"text":431},{"id":437,"depth":302,"text":438},{"id":558,"depth":302,"text":559},{"id":568,"depth":302,"text":569},{"id":292,"depth":302,"text":293},[589],{"slug":555,"concept":590,"style":591,"aspectRatio":315,"labels":592},"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",[593,594,595,596],"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.",[393,394,395,396],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/03-storage-services",{"passingScore":325,"questions":601},[602,608,612,617,626,634,642],{"question":603,"type":329,"options":604,"correctAnswer":340,"explanation":607},"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?",[605,342,340,606],"File 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":609,"type":329,"options":610,"correctAnswer":355,"explanation":611},"Amazon EBS volumes are zonal resources, meaning a volume can only attach to instances within the same Availability Zone where it was created.",[355,356],"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":613,"type":329,"options":614,"correctAnswer":605,"explanation":616},"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?",[340,605,342,615],"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":618,"type":360,"options":619,"correctAnswers":624,"explanation":625},"Which of the following statements correctly distinguish block storage from object storage? (Select all that apply.)",[620,621,622,623],"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",[620,622,623],"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":627,"type":329,"options":628,"correctAnswer":630,"explanation":633},"Amazon S3 advertises 99.999999999% (11 nines) durability. What does 'durability' actually promise, as distinct from 'availability'?",[629,630,631,632],"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":635,"type":329,"options":636,"correctAnswer":639,"explanation":641},"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?",[637,638,639,640],"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":643,"type":329,"options":644,"correctAnswer":646,"explanation":649},"Which pairing correctly matches an AWS storage product to its category?",[645,646,647,648],"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":389,"description":390},"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":654,"item":662},{"title":655,"description":656,"isFree":5,"estimatedMinutes":391,"difficulty":10,"learningObjectives":657},"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.",[658,659,660,661],"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":663,"title":655,"body":664,"description":656,"difficulty":10,"estimatedMinutes":391,"extension":310,"infographics":882,"isFree":5,"learningObjectives":891,"meta":892,"navigation":322,"path":893,"quiz":894,"seo":943,"stem":944,"__hash__":945},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/02-compute-services.md",{"type":19,"value":665,"toc":873},[666,670,673,677,680,751,754,757,761,764,771,777,780,784,787,791,794,798,858,861,865,868,870],[22,667,669],{"id":668},"what-you-are-actually-renting","What you are actually renting",[27,671,672],{},"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,674,676],{"id":675},"virtual-machines-the-baseline-unit","Virtual machines: the baseline unit",[27,678,679],{},"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.",[38,681,682,694],{},[41,683,684],{},[44,685,686,689,692],{},[47,687,688],{},"Family",[47,690,691],{},"Optimized for",[47,693,503],{},[60,695,696,707,718,729,740],{},[44,697,698,701,704],{},[65,699,700],{},"General purpose",[65,702,703],{},"A balance of compute, memory, and networking",[65,705,706],{},"Web servers, small-to-medium databases, dev environments",[44,708,709,712,715],{},[65,710,711],{},"Compute optimized",[65,713,714],{},"High-performance processors, more vCPU per GB of memory",[65,716,717],{},"Batch processing, media transcoding, game servers",[44,719,720,723,726],{},[65,721,722],{},"Memory optimized",[65,724,725],{},"Large amounts of RAM relative to vCPU",[65,727,728],{},"In-memory databases, real-time analytics",[44,730,731,734,737],{},[65,732,733],{},"Storage optimized",[65,735,736],{},"High, low-latency local disk throughput",[65,738,739],{},"High-throughput databases, streaming data processing",[44,741,742,745,748],{},[65,743,744],{},"Accelerated computing",[65,746,747],{},"GPUs or other hardware accelerators",[65,749,750],{},"Machine learning training, graphics rendering",[27,752,753],{},"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,755,756],{},"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,758,760],{"id":759},"vertical-scaling-versus-horizontal-scaling","Vertical scaling versus horizontal scaling",[27,762,763],{},"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,765,766,770],{},[767,768,769],"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,772,773,776],{},[767,774,775],{},"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,778,779],{},"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,781,783],{"id":782},"managed-compute-someone-else-runs-the-fleet","Managed compute: someone else runs the fleet",[27,785,786],{},"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,788,790],{"id":789},"the-full-compute-spectrum","The full compute spectrum",[27,792,793],{},"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.",[167,795],{"alt":796,"slug":797},"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",[38,799,800,813],{},[41,801,802],{},[44,803,804,807,810],{},[47,805,806],{},"Option",[47,808,809],{},"What you manage",[47,811,812],{},"Typical startup",[60,814,815,826,836,847],{},[44,816,817,820,823],{},[65,818,819],{},"Virtual machine",[65,821,822],{},"OS, runtime, scaling",[65,824,825],{},"Minutes",[44,827,828,831,834],{},[65,829,830],{},"Managed compute",[65,832,833],{},"Application code and configuration",[65,835,825],{},[44,837,838,841,844],{},[65,839,840],{},"Container",[65,842,843],{},"Application, its runtime dependencies, packaged together",[65,845,846],{},"Seconds",[44,848,849,852,855],{},[65,850,851],{},"Serverless function",[65,853,854],{},"Only the function code",[65,856,857],{},"Milliseconds",[27,859,860],{},"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,862,864],{"id":863},"the-misconception-serverless-is-always-cheaper","The misconception: \"serverless is always cheaper\"",[27,866,867],{},"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,869,293],{"id":292},[27,871,872],{},"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":298,"searchDepth":299,"depth":299,"links":874},[875,876,877,878,879,880,881],{"id":668,"depth":302,"text":669},{"id":675,"depth":302,"text":676},{"id":759,"depth":302,"text":760},{"id":782,"depth":302,"text":783},{"id":789,"depth":302,"text":790},{"id":863,"depth":302,"text":864},{"id":292,"depth":302,"text":293},[883],{"slug":797,"concept":884,"style":314,"aspectRatio":315,"labels":885},"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.",[886,887,888,889,890],"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.",[658,659,660,661],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/02-compute-services",{"passingScore":325,"questions":895},[896,900,906,910,918,927,935],{"question":897,"type":329,"options":898,"correctAnswer":711,"explanation":899},"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?",[722,733,711,700],"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":901,"type":329,"options":902,"correctAnswer":775,"explanation":905},"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?",[775,769,903,904],"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":907,"type":329,"options":908,"correctAnswer":356,"explanation":909},"Vertical scaling and horizontal scaling solve the same problem in the same way, so it never matters which one a team picks.",[355,356],"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":911,"type":329,"options":912,"correctAnswer":916,"explanation":917},"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?",[913,914,915,916],"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":919,"type":360,"options":920,"correctAnswers":925,"explanation":926},"Which of the following statements accurately place items on the control-versus-convenience compute spectrum? (Select all that apply.)",[921,922,923,924],"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",[921,922,924],"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":928,"type":329,"options":929,"correctAnswer":931,"explanation":934},"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?",[930,931,932,933],"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":936,"type":329,"options":937,"correctAnswer":939,"explanation":942},"According to this lesson, where do containers and serverless functions get covered in full?",[938,939,940,941],"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":655,"description":656},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/02-compute-services","5paMPWdXDfm7PpzvTUl3vO7C3EfwjrxJNYgmXEBKrEw"]