[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"prev-cloud-computing-fundamentals-cloud-services-and-architecture-modern-cloud-architectures-serverless-computing-en":4,"next-cloud-computing-fundamentals-cloud-services-and-architecture-modern-cloud-architectures-serverless-computing-en":247,"lesson-cloud-computing-fundamentals-cloud-services-and-architecture-modern-cloud-architectures-serverless-computing-en":743},null,{"locked":5,"reason":3,"meta":6,"item":16},false,{"title":7,"description":8,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":11},"Cloud Networking Basics","How a virtual private cloud, subnets, security groups, network ACLs, and a load balancer work together to get a user's request safely from the internet to a private database, and nowhere it should not go.",18,"intermediate",[12,13,14,15],"Explain what a virtual private cloud is and why it exists","Distinguish public and private subnets and identify which resources belong in each","Compare security groups and network ACLs by scope, statefulness, and rule type","Describe how a load balancer distributes traffic across compute targets",{"id":17,"title":7,"body":18,"description":8,"difficulty":10,"estimatedMinutes":9,"extension":168,"infographics":169,"isFree":5,"learningObjectives":180,"meta":181,"navigation":182,"path":183,"quiz":184,"seo":244,"stem":245,"__hash__":246},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/05-cloud-networking-basics.md",{"type":19,"value":20,"toc":156},"minimark",[21,26,30,34,37,41,44,47,51,54,57,60,127,130,134,137,141,146,149,153],[22,23,25],"h2",{"id":24},"getting-a-request-from-the-internet-to-a-private-database-safely","Getting a request from the internet to a private database, safely",[27,28,29],"p",{},"2 lessons ago, an e-commerce database sat safely in a relational database, storing orders that had to stay consistent with real customers and real inventory. That database is useless if a shopper's browser cannot reach it, and dangerous if anyone on the internet can reach it directly. Cloud networking is the layer that resolves that tension: it gets a request from a user's browser to the right application server and the right database, while keeping the database itself unreachable from the outside world entirely. This lesson builds that path piece by piece.",[22,31,33],{"id":32},"the-vpc-your-own-private-network-virtualized","The VPC: your own private network, virtualized",[27,35,36],{},"A virtual private cloud (VPC) is a logically isolated virtual network dedicated to your account. You choose an IP address range for it, then add subnets, gateways, and security controls, the same building blocks you would configure in a physical data center network, except there is no cabling and no hardware to rack. Every resource you launch, a virtual machine, a database instance, lives inside a VPC, which is what makes the next piece, subnets, meaningful.",[22,38,40],{"id":39},"subnets-public-versus-private","Subnets: public versus private",[27,42,43],{},"A subnet is a range of IP addresses inside a VPC, and, on AWS, a subnet lives entirely within 1 Availability Zone, the same AZ concept from earlier in this topic, now applied to networking. What makes a subnet public or private is not its name but its route table: a public subnet has a route to an internet gateway, so its resources can be reached from, and can reach, the internet; a private subnet has no such route, so nothing outside the VPC can reach it directly.",[27,45,46],{},"This is exactly the shape of the RDS reference architecture: application servers sit in public subnets across 2 Availability Zones, reachable by users, and the database instances sit in private subnets in those same 2 AZs, reachable only by the application servers inside the VPC, never directly from the internet. A resource in a private subnet is not cut off entirely; it can still reach the internet outbound, to download a software update, for instance, through a separate NAT gateway, but nothing outside can initiate a connection in.",[22,48,50],{"id":49},"security-groups-and-network-acls-2-different-locks-on-2-different-doors","Security groups and network ACLs: 2 different locks on 2 different doors",[27,52,53],{},"Getting the placement right is only half the job. The other half is deciding exactly what traffic each piece is allowed to see, and AWS gives you 2 different tools for that, at 2 different scopes.",[27,55,56],{},"A security group is a virtual firewall attached to an individual instance, like a doorman standing at one specific door who remembers everyone he has let in: once he allows a request out, he automatically lets the matching response back in without checking his list again. That memory is what \"stateful\" means. A security group only supports allow rules, and it checks every rule before deciding, since there is nothing to deny, only permission to grant or withhold.",[27,58,59],{},"A network ACL works at the subnet level instead, more like a building's front desk that checks every single person crossing the threshold, in either direction, against a written list, with no memory of who it let through 5 minutes ago. That is \"stateless\": a network ACL supports both allow and deny rules, and it stops at the first rule that matches, checked in order, rather than reviewing every rule the way a security group does.",[61,62,63,79],"table",{},[64,65,66],"thead",{},[67,68,69,73,76],"tr",{},[70,71,72],"th",{},"Property",[70,74,75],{},"Security group",[70,77,78],{},"Network ACL",[80,81,82,94,105,116],"tbody",{},[67,83,84,88,91],{},[85,86,87],"td",{},"Applies to",[85,89,90],{},"An instance",[85,92,93],{},"An entire subnet",[67,95,96,99,102],{},[85,97,98],{},"Rule types",[85,100,101],{},"Allow only",[85,103,104],{},"Allow and deny",[67,106,107,110,113],{},[85,108,109],{},"Rule evaluation",[85,111,112],{},"Checks all rules before deciding",[85,114,115],{},"Stops at the first matching rule, in order",[67,117,118,121,124],{},[85,119,120],{},"Return traffic",[85,122,123],{},"Automatically allowed (stateful)",[85,125,126],{},"Must be explicitly allowed (stateless)",[27,128,129],{},"AWS's own guidance is to use security groups as your primary access control and add network ACLs as a secondary, coarser layer on top. The reason is straightforward: a network ACL guards the whole subnet, so it keeps working as a backstop even in the rare case an instance gets launched without the right security group attached. 2 layers that can fail in different ways protect you better than 1 layer that has to be perfect every time.",[22,131,133],{"id":132},"the-load-balancer-spreading-traffic-across-healthy-targets","The load balancer: spreading traffic across healthy targets",[27,135,136],{},"Recall the compute lesson's horizontal scaling: adding more instances of the same size instead of resizing one. Splitting the load across 4 identical app servers only works if something decides which of the 4 handles each incoming request, and that something is a load balancer. A load balancer sits in front of a group of targets, health-checks each one, and routes traffic only to the targets currently passing those checks, automatically routing around an instance that has stopped responding.",[22,138,140],{"id":139},"the-full-path-assembled","The full path, assembled",[142,143],"infographic",{"alt":144,"slug":145},"A network diagram showing a user request entering a VPC through an internet gateway, reaching a load balancer and app server in a public subnet, and the app server reaching a database in a private subnet that has no direct route to the internet.","cloud-networking-request-path",[27,147,148],{},"Put every piece from this lesson together and the path a request actually takes looks like this: a user's request enters the VPC through an internet gateway, reaches a load balancer, which routes it to one of several healthy app servers sitting in a public subnet, protected by that instance's security group. The app server then reaches into a private subnet to read or write the database, a connection allowed only because both sides sit inside the same VPC, never because the database is reachable from the internet. A network ACL watches each subnet boundary the whole way through, as the coarse-grained backstop behind every security group.",[22,150,152],{"id":151},"where-this-leaves-you","Where this leaves you",[27,154,155],{},"Networking is not a single setting, it is a stack of decisions: which subnet a resource lives in decides whether the internet can reach it at all, security groups decide exactly which traffic reaches a specific instance, network ACLs back that up at the subnet level, and a load balancer decides which of several healthy instances actually answers a given request. Every service this topic covered, compute, storage, databases, sits somewhere inside this network, and none of it is reachable, or protected, without it. The next topic in this domain, Modern Cloud Architectures, builds on every one of these building blocks to cover the patterns teams actually deploy today: serverless computing, containers and microservices, and infrastructure as code.",{"title":157,"searchDepth":158,"depth":158,"links":159},"",3,[160,162,163,164,165,166,167],{"id":24,"depth":161,"text":25},2,{"id":32,"depth":161,"text":33},{"id":39,"depth":161,"text":40},{"id":49,"depth":161,"text":50},{"id":132,"depth":161,"text":133},{"id":139,"depth":161,"text":140},{"id":151,"depth":161,"text":152},"md",[170],{"slug":145,"concept":171,"style":172,"aspectRatio":173,"labels":174},"A network topology diagram of one VPC box spanning 2 Availability Zone columns. Each AZ column contains a public subnet band on top holding a load balancer icon and an app server icon, and a private subnet band below it holding a database icon. A numbered arrow path starts outside the VPC box at a user icon, enters through an internet gateway into the load balancer, branches to either app server, then continues down into the matching AZ's private-subnet database, with the second AZ's database connected by a thin replication line. A footer strip states the layered-defense takeaway.","diagram","16:9",[175,176,177,178,179],"1. User request enters through the internet gateway.","2. Load balancer routes to a healthy app server in a public subnet.","3. App server reads and writes the database in a private subnet.","4. The private subnet has no route to the internet. Only the app server can reach it.","Security groups guard each resource. Network ACLs guard each subnet.",[12,13,14,15],{},true,"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/05-cloud-networking-basics",{"passingScore":185,"questions":186},70,[187,196,204,214,220,228,236],{"question":188,"type":189,"options":190,"correctAnswer":192,"explanation":195},"What is a virtual private cloud (VPC), in the most basic terms?","single",[191,192,193,194],"A physical, dedicated data center reserved for one customer","A logically isolated virtual network within the cloud, where you choose the IP address range and add subnets, gateways, and security controls","A synonym for an Availability Zone","A managed database service","A VPC is a private, virtualized network dedicated to your account, logically isolated from other customers' networks, where you control the IP address range, subnets, and gateways much like you would in a traditional data center network, except nothing physical to rack or wire.",{"question":197,"type":189,"options":198,"correctAnswer":200,"explanation":203},"In the RDS reference architecture this lesson describes, application servers sit in public subnets and database instances sit in private subnets. Why are the database instances placed in a private subnet specifically?",[199,200,201,202],"Private subnets are cheaper to operate than public subnets","Private subnets have no route that lets internet traffic reach them directly, so the database cannot be reached from outside the VPC even if someone tries","Databases physically cannot run in a public subnet","It is only a naming convention with no functional effect","A private subnet lacks a route to an internet gateway, so nothing outside the VPC can initiate a connection to resources inside it, which is exactly the protection a database needs. The application servers still reach the database because they are inside the same VPC; only inbound traffic from the public internet is blocked.",{"question":205,"type":206,"options":207,"correctAnswers":212,"explanation":213},"Which of the following statements correctly describe the difference between security groups and network ACLs? (Select all that apply.)","multiple",[208,209,210,211],"A security group operates at the instance level, while a network ACL operates at the subnet level","A security group only supports allow rules, while a network ACL supports both allow and deny rules","A security group is stateless and a network ACL is stateful","A network ACL evaluates its rules in order until it finds a match, while a security group evaluates all its rules before deciding",[208,209,211],"Security groups attach to instances and only allow traffic, evaluating every rule before deciding, while network ACLs attach to a subnet, support both allow and deny rules, and stop at the first matching rule in order. The statefulness is reversed from the distractor: security groups are stateful, automatically allowing return traffic, while network ACLs are stateless and require explicit rules in both directions.",{"question":215,"type":189,"options":216,"correctAnswer":217,"explanation":219},"A security group is stateful, which means that if it allows an outbound request from an instance, the response to that request is automatically allowed back in, without needing a matching inbound rule.",[217,218],"True","False","This is the defining behavior of a stateful firewall: the security group tracks the connection, so response traffic to an already-allowed request is let back in automatically. A network ACL does not do this, it is stateless, so a subnet using a network ACL must explicitly allow both the outbound request and the inbound response.",{"question":221,"type":189,"options":222,"correctAnswer":224,"explanation":227},"AWS's own guidance recommends using security groups as the primary access control and adding network ACLs on top as a secondary layer. Why bother with a second layer if security groups already control access?",[223,224,225,226],"Network ACLs are required by law in every AWS Region","Network ACLs apply to an entire subnet, so they provide a backstop even if an instance is ever launched without the correct security group attached","Security groups do not actually work, so a second layer is mandatory","There is no real benefit, the guidance is only a formality","Because a network ACL guards the whole subnet rather than a single instance, it keeps working as a coarse-grained guard rail even in the case a security group is misconfigured or missing on a specific instance. That is defense-in-depth: 2 layers that fail differently, so a mistake in one does not automatically expose the resource.",{"question":229,"type":189,"options":230,"correctAnswer":234,"explanation":235},"After a team applies horizontal scaling and now runs 4 identical app server instances instead of 1, what component is responsible for spreading incoming user traffic across all 4 healthy instances?",[231,232,233,234],"A network ACL","A security group","The database","A load balancer","A load balancer distributes incoming traffic across multiple targets and routes only to the ones that pass its health checks, which is exactly what 4 identical app servers behind it need. Security groups and network ACLs control which traffic is allowed to reach a resource; neither one decides how to split traffic across several healthy instances.",{"question":237,"type":189,"options":238,"correctAnswer":240,"explanation":243},"Which pairing correctly matches a virtual networking concept to its equivalent product name?",[239,240,241,242],"Google Cloud's VPC equivalent: Azure Virtual Network","AWS's VPC equivalent: Azure Virtual Network","Azure's virtual network product: Google Cloud VPC","AWS's VPC equivalent: Google Cloud Compute Engine","Azure's virtual networking product is called Virtual Network (VNet), and it plays the same role as an AWS VPC: an isolated, customer-controlled network you subdivide into subnets. Google Cloud uses the term VPC directly, and Compute Engine is a compute product, unrelated to networking.",{"title":7,"description":8},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/05-cloud-networking-basics","0SX2qccPGNhQBbG5JDix81hbDCTg9cH8MYkBC0YuQOI",{"locked":5,"reason":3,"meta":248,"item":258},{"title":249,"description":250,"isFree":5,"estimatedMinutes":251,"difficulty":10,"learningObjectives":252},"Containers and Microservices","What a container actually packages, why splitting a monolith into microservices changes how a team ships and scales, and what an orchestrator like Kubernetes adds once you have more containers than you can manage by hand.",19,[253,254,255,256,257],"Explain what a container is and why it starts faster than a virtual machine","Describe how a container image keeps the runtime environment identical from a laptop to production","Distinguish a monolithic application from a microservices architecture by how each one is deployed and scaled","Identify what container orchestration adds on top of running individual containers by hand","Recognize the operational tradeoffs microservices introduce in exchange for independent scaling and deployment",{"id":259,"title":249,"body":260,"description":250,"difficulty":10,"estimatedMinutes":251,"extension":168,"infographics":671,"isFree":5,"learningObjectives":682,"meta":683,"navigation":182,"path":684,"quiz":685,"seo":740,"stem":741,"__hash__":742},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/02-containers-and-microservices.md",{"type":19,"value":261,"toc":662},[262,266,269,273,276,321,364,379,383,386,390,393,397,400,404,410,597,603,607,653,655,658],[22,263,265],{"id":264},"the-last-lesson-answered-who-runs-the-code-this-one-asks-how-it-is-built","The last lesson answered who runs the code. This one asks how it is built",[27,267,268],{},"The last lesson left compute answered: a serverless function, a virtual machine, or something in between runs your code, and the provider handles more or less of the surrounding work depending on which you pick. None of that says anything about how the application itself is put together. An application that started as one large codebase, one deployment, one team, runs into a specific kind of trouble as it grows: a small fix to the checkout flow means testing and redeploying the entire application, catalog, accounts, and all, and a traffic spike in one part of the app forces you to scale the whole thing. Containers and microservices are 2 separate ideas that, together, solve exactly that problem.",[22,270,272],{"id":271},"what-a-container-actually-packages","What a container actually packages",[27,274,275],{},"A container is an isolated process bundled with everything it needs to run: your code, its runtime, and its dependencies, all in one self-contained unit. Package a Node.js application into a container image and that image runs identically whether it started on a developer's laptop, a test server, or a production cluster, because the image carries its own runtime instead of depending on whatever happens to be installed on the host.",[277,278,282],"pre",{"className":279,"code":280,"language":281,"meta":157,"style":157},"language-dockerfile shiki shiki-themes material-theme-lighter github-light github-dark","FROM node:20-slim\nWORKDIR /app\nCOPY package*.json ./\nRUN npm install --production\nCOPY . .\nCMD [\"node\", \"server.js\"]\n","dockerfile",[283,284,285,293,298,303,309,315],"code",{"__ignoreMap":157},[286,287,290],"span",{"class":288,"line":289},"line",1,[286,291,292],{},"FROM node:20-slim\n",[286,294,295],{"class":288,"line":161},[286,296,297],{},"WORKDIR /app\n",[286,299,300],{"class":288,"line":158},[286,301,302],{},"COPY package*.json ./\n",[286,304,306],{"class":288,"line":305},4,[286,307,308],{},"RUN npm install --production\n",[286,310,312],{"class":288,"line":311},5,[286,313,314],{},"COPY . .\n",[286,316,318],{"class":288,"line":317},6,[286,319,320],{},"CMD [\"node\", \"server.js\"]\n",[277,322,326],{"className":323,"code":324,"language":325,"meta":157,"style":157},"language-bash shiki shiki-themes material-theme-lighter github-light github-dark","docker build -t checkout-service:1.0 .\ndocker run -p 3000:3000 checkout-service:1.0\n","bash",[283,327,328,348],{"__ignoreMap":157},[286,329,330,334,338,342,345],{"class":288,"line":289},[286,331,333],{"class":332},"sbgvK","docker",[286,335,337],{"class":336},"s_sjI"," build",[286,339,341],{"class":340},"stzsN"," -t",[286,343,344],{"class":336}," checkout-service:1.0",[286,346,347],{"class":336}," .\n",[286,349,350,352,355,358,361],{"class":288,"line":161},[286,351,333],{"class":332},[286,353,354],{"class":336}," run",[286,356,357],{"class":340}," -p",[286,359,360],{"class":336}," 3000:3000",[286,362,363],{"class":336}," checkout-service:1.0\n",[27,365,366,367,370,371,374,375,378],{},"That ",[283,368,369],{},"Dockerfile"," describes the image; ",[283,372,373],{},"docker build"," packages it; ",[283,376,377],{},"docker run"," starts a container from it. The compute lesson already placed containers on the control-versus-convenience spectrum, starting in seconds instead of a virtual machine's minutes, because a container shares the host operating system's kernel instead of booting a full guest OS of its own.",[22,380,382],{"id":381},"from-monolith-to-microservices","From monolith to microservices",[27,384,385],{},"A monolith is one codebase, one deployment, and usually one shared database, no matter how many distinct features it contains. A microservices architecture splits that same application into a suite of small, independently deployable services, each built around one business capability (catalog, cart, checkout, user accounts) and communicating over lightweight APIs rather than in-process function calls. Each service typically owns its own database instead of sharing one, which is what makes it deployable and scalable on its own.",[142,387],{"alt":388,"slug":389},"A side-by-side comparison of a monolith, one codebase and one database, against a microservices architecture split into independent services each with its own database.","containers-and-microservices-monolith-vs-microservices",[27,391,392],{},"Go back to the flash-sale scenario. In a monolith, a tripling of checkout traffic forces you to scale the entire deployment, catalog and accounts included, since there is only one deployable unit to scale. Split into microservices, the checkout service scales on its own, and catalog and accounts stay exactly as they were, because each one is now a separate, independently deployable piece.",[22,394,396],{"id":395},"the-trade-you-make-independence-for-coordination","The trade you make: independence for coordination",[27,398,399],{},"None of this is free. Splitting a monolith into microservices trades a single codebase's simplicity for a set of new problems that only show up once services are separate. A call from checkout to the user service now crosses a network instead of calling a function in the same process, which means it can time out or fail in ways an in-process call never could. Decentralized data, each service with its own database, means giving up one shared transaction across the whole request in favor of eventual consistency between services. And a single customer request that touches 5 services is harder to debug than one that touches one, since there is no longer a single stack trace to read. More services is not automatically better; it is a deliberate trade of simplicity for independence, one that only pays off once a team has the operational tooling to manage it, which is exactly what the next lesson covers.",[22,401,403],{"id":402},"orchestration-managing-more-containers-than-a-human-can-track","Orchestration: managing more containers than a human can track",[27,405,406,407,409],{},"Run one container by hand and ",[283,408,377],{}," is enough. Run 3 replicas of a checkout service for redundancy, plus a catalog service, plus a cart service, each with its own replicas, and manually watching all of them stops working quickly. A container orchestrator like Kubernetes takes a declarative description of what you want and continuously works to make reality match it.",[277,411,415],{"className":412,"code":413,"language":414,"meta":157,"style":157},"language-yaml shiki shiki-themes material-theme-lighter github-light github-dark","apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: checkout-service\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: checkout-service\n  template:\n    metadata:\n      labels:\n        app: checkout-service\n    spec:\n      containers:\n        - name: checkout\n          image: checkout-service:2.1\n          ports:\n            - containerPort: 8080\n","yaml",[283,416,417,430,440,448,458,465,476,484,492,502,510,518,526,536,544,552,566,577,584],{"__ignoreMap":157},[286,418,419,423,427],{"class":288,"line":289},[286,420,422],{"class":421},"sQzsp","apiVersion",[286,424,426],{"class":425},"sP7_E",":",[286,428,429],{"class":336}," apps/v1\n",[286,431,432,435,437],{"class":288,"line":161},[286,433,434],{"class":421},"kind",[286,436,426],{"class":425},[286,438,439],{"class":336}," Deployment\n",[286,441,442,445],{"class":288,"line":158},[286,443,444],{"class":421},"metadata",[286,446,447],{"class":425},":\n",[286,449,450,453,455],{"class":288,"line":305},[286,451,452],{"class":421},"  name",[286,454,426],{"class":425},[286,456,457],{"class":336}," checkout-service\n",[286,459,460,463],{"class":288,"line":311},[286,461,462],{"class":421},"spec",[286,464,447],{"class":425},[286,466,467,470,472],{"class":288,"line":317},[286,468,469],{"class":421},"  replicas",[286,471,426],{"class":425},[286,473,475],{"class":474},"srdBf"," 3\n",[286,477,479,482],{"class":288,"line":478},7,[286,480,481],{"class":421},"  selector",[286,483,447],{"class":425},[286,485,487,490],{"class":288,"line":486},8,[286,488,489],{"class":421},"    matchLabels",[286,491,447],{"class":425},[286,493,495,498,500],{"class":288,"line":494},9,[286,496,497],{"class":421},"      app",[286,499,426],{"class":425},[286,501,457],{"class":336},[286,503,505,508],{"class":288,"line":504},10,[286,506,507],{"class":421},"  template",[286,509,447],{"class":425},[286,511,513,516],{"class":288,"line":512},11,[286,514,515],{"class":421},"    metadata",[286,517,447],{"class":425},[286,519,521,524],{"class":288,"line":520},12,[286,522,523],{"class":421},"      labels",[286,525,447],{"class":425},[286,527,529,532,534],{"class":288,"line":528},13,[286,530,531],{"class":421},"        app",[286,533,426],{"class":425},[286,535,457],{"class":336},[286,537,539,542],{"class":288,"line":538},14,[286,540,541],{"class":421},"    spec",[286,543,447],{"class":425},[286,545,547,550],{"class":288,"line":546},15,[286,548,549],{"class":421},"      containers",[286,551,447],{"class":425},[286,553,555,558,561,563],{"class":288,"line":554},16,[286,556,557],{"class":425},"        -",[286,559,560],{"class":421}," name",[286,562,426],{"class":425},[286,564,565],{"class":336}," checkout\n",[286,567,569,572,574],{"class":288,"line":568},17,[286,570,571],{"class":421},"          image",[286,573,426],{"class":425},[286,575,576],{"class":336}," checkout-service:2.1\n",[286,578,579,582],{"class":288,"line":9},[286,580,581],{"class":421},"          ports",[286,583,447],{"class":425},[286,585,586,589,592,594],{"class":288,"line":251},[286,587,588],{"class":425},"            -",[286,590,591],{"class":421}," containerPort",[286,593,426],{"class":425},[286,595,596],{"class":474}," 8080\n",[27,598,366,599,602],{},[283,600,601],{},"replicas: 3"," line is a declaration, not a one-time command. If one of the 3 crashes, Kubernetes notices the mismatch between the declared state and reality and starts a replacement automatically, a capability called self-healing. Kubernetes also handles service discovery and load balancing across those replicas, and rolls updates out gradually instead of all at once, so a team stops babysitting containers by hand and starts describing the state they want instead.",[22,604,606],{"id":605},"exam-cues-spotting-the-fit-in-a-scenario","Exam cues: spotting the fit in a scenario",[61,608,609,619],{},[64,610,611],{},[67,612,613,616],{},[70,614,615],{},"The scenario says...",[70,617,618],{},"Points to",[80,620,621,629,637,645],{},[67,622,623,626],{},[85,624,625],{},"\"Package once, run identically everywhere\"",[85,627,628],{},"Container",[67,630,631,634],{},[85,632,633],{},"\"Independent teams ship independently, each owns its own data\"",[85,635,636],{},"Microservices",[67,638,639,642],{},[85,640,641],{},"\"Automatically restart failed instances, roll updates out gradually\"",[85,643,644],{},"Container orchestration (Kubernetes)",[67,646,647,650],{},[85,648,649],{},"\"One codebase, one deployment, one database\"",[85,651,652],{},"Monolith",[22,654,152],{"id":151},[27,656,657],{},"Splitting an application into microservices and packaging each piece as a container are 2 separate decisions that happen to reinforce each other: the independent deployability microservices promise only holds up if each piece can actually ship and scale on its own, and a container is exactly what makes that practical. None of it, the builds, the rollouts, the ever-growing number of moving pieces, stays manageable by hand for long. The next lesson covers the practices and tooling, DevOps and infrastructure as code, that keep it manageable.",[659,660,661],"style",{},"html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .sbgvK, html code.shiki .sbgvK{--shiki-light:#E2931D;--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .s_sjI, html code.shiki .s_sjI{--shiki-light:#91B859;--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .stzsN, html code.shiki .stzsN{--shiki-light:#91B859;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .sQzsp, html code.shiki .sQzsp{--shiki-light:#E53935;--shiki-default:#22863A;--shiki-dark:#85E89D}html pre.shiki code .sP7_E, html code.shiki .sP7_E{--shiki-light:#39ADB5;--shiki-default:#24292E;--shiki-dark:#E1E4E8}html pre.shiki code .srdBf, html code.shiki .srdBf{--shiki-light:#F76D47;--shiki-default:#005CC5;--shiki-dark:#79B8FF}",{"title":157,"searchDepth":158,"depth":158,"links":663},[664,665,666,667,668,669,670],{"id":264,"depth":161,"text":265},{"id":271,"depth":161,"text":272},{"id":381,"depth":161,"text":382},{"id":395,"depth":161,"text":396},{"id":402,"depth":161,"text":403},{"id":605,"depth":161,"text":606},{"id":151,"depth":161,"text":152},[672],{"slug":389,"concept":673,"style":674,"aspectRatio":173,"labels":675},"A 2-panel side-by-side comparison. The left panel, labeled Monolith, shows a single large block containing UI, business logic, and data access, connected to one shared database icon. The right panel, labeled Microservices, shows 4 small independent boxes (Catalog, Cart, Checkout, User), each connected to its own small database icon, with thin arrows between boxes showing API calls. The monolith panel emphasizes one solid mass; the microservices panel emphasizes separation and multiple small parts. A footer strip carries the takeaway that splitting the code is the point, containers just make each piece easy to ship.","comparison",[676,677,678,679,680,681],"Monolith: one codebase, one deployment, one shared database.","A fix to checkout means redeploying the entire application.","Microservices: independent services, independent deployments.","Catalog, Cart, Checkout, and User each own their own database.","A fix to checkout redeploys only the checkout service.","Splitting the code is the point. Containers just make each piece easy to ship.",[253,254,255,256,257],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/02-containers-and-microservices",{"passingScore":185,"questions":686},[687,695,703,707,715,724,732],{"question":688,"type":189,"options":689,"correctAnswer":690,"explanation":694},"According to Docker's own documentation, what is a container, most fundamentally?",[690,691,692,693],"An isolated process bundled with everything it needs to run, sharing the host's kernel","A lightweight virtual machine with its own kernel","A cloud region reserved for one customer","A serverless function with a longer timeout","A container packages an application with its code, libraries, and dependencies into one self-contained, isolated process. Unlike a virtual machine, it shares the host operating system's kernel instead of running a full guest OS of its own.",{"question":696,"type":189,"options":697,"correctAnswer":701,"explanation":702},"Why does a container typically start in seconds while a comparable virtual machine takes minutes?",[698,699,700,701],"Containers use faster physical hard drives","Containers do not run any code, only configuration","Containers are always smaller in file size than any virtual machine image","A container shares the host operating system's kernel instead of booting its own, while a virtual machine boots a complete guest OS","Booting a full guest operating system, the way a virtual machine does, takes minutes. A container skips that step entirely by reusing the host's already-running kernel, so starting one is closer to starting a regular process than booting a computer.",{"question":704,"type":189,"options":705,"correctAnswer":218,"explanation":706},"A microservices architecture is defined mainly by how many servers an application runs on, not by how its code is organized into services.",[217,218],"Microservices are defined by organization, not server count: a single application built as a suite of small, independently deployable services, each built around a business capability and communicating over lightweight APIs. The same architecture could run on many servers or, at small scale, surprisingly few.",{"question":708,"type":189,"options":709,"correctAnswer":711,"explanation":714},"An online store built as microservices sees checkout traffic triple during a flash sale, while catalog browsing and account traffic stay flat. What can the team do that a monolith could not do as cleanly?",[710,711,712,713],"Nothing, containers do not change how scaling works","Scale only the checkout service, leaving catalog and user services untouched","Switch the whole application to serverless functions automatically","Redeploy the entire application to add more capacity everywhere","Because each microservice deploys and scales independently, the team can add capacity to checkout alone. A monolith bundles catalog, cart, checkout, and accounts into one deployable unit, so scaling it means scaling all of it, whether the extra capacity is needed there or not.",{"question":716,"type":206,"options":717,"correctAnswers":722,"explanation":723},"Which of the following are real costs a team takes on when it splits a monolith into microservices? (Select all that apply.)",[718,719,720,721],"Calls between services now cross a network and can fail in ways an in-process function call cannot","Each service can choose its own database, which trades strict consistency for eventual consistency across services","The application automatically becomes cheaper to run","Debugging a request that touches 5 services requires tracing across all of them, not just reading one stack trace",[718,719,721],"Microservices trade a monolith's simplicity for independence, and that trade has real costs: network calls can fail where a function call cannot, decentralized data means accepting eventual consistency instead of one shared transaction, and a single request's path across several services is harder to trace than one stack trace. None of that makes the application automatically cheaper; it can just as easily cost more to run and operate.",{"question":725,"type":189,"options":726,"correctAnswer":729,"explanation":731},"A team runs 3 replicas of a checkout service container, and one crashes under load. Which capability of a container orchestrator like Kubernetes addresses this automatically?",[727,728,729,730],"Encryption at rest","Automatic code review","Self-healing: it detects the failed replica and starts a replacement to match the declared desired state","Currency conversion for international customers","An orchestrator like Kubernetes continuously compares the actual state of the system to the desired state you declared, 3 healthy replicas, and starts a replacement the moment one falls short. That self-healing is exactly what running containers by hand with no orchestrator would leave to a human to notice and fix.",{"question":733,"type":189,"options":734,"correctAnswer":735,"explanation":739},"A Kubernetes Deployment file declares \"replicas: 3\" and Kubernetes continuously works to keep exactly 3 healthy copies running. What broader practice, covered in the next lesson, generalizes this same idea to a team's entire infrastructure?",[735,736,737,738],"Infrastructure as code: describing the desired state of infrastructure in a file instead of configuring it by hand","Vertical scaling","The shared responsibility model","Choosing a service model","Declaring \"replicas: 3\" and letting Kubernetes reconcile reality to match is the same underlying idea infrastructure as code applies to servers, networks, and every other piece of infrastructure: describe the state you want, let a tool make it happen and keep it that way.",{"title":249,"description":250},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/02-containers-and-microservices","K33r70KDceWTgfhJn0KUHnXkUJutK27cms9eEqIJoqU",{"locked":5,"reason":3,"meta":744,"item":753},{"title":745,"description":746,"isFree":182,"estimatedMinutes":9,"difficulty":10,"learningObjectives":747},"Serverless Computing","What 'serverless' actually means, how a function scales from zero to thousands of requests and back, the real cost math behind it, and where its limits sit.",[748,749,750,751,752],"Explain what serverless computing means and correct the misconception that no servers are involved","Describe the event-driven lifecycle of a serverless function, including cold starts and warm starts","Calculate whether a workload costs less as a serverless function or as an always-on server, using its request volume and duration","Identify the execution-time and state limits that rule serverless functions out for a given workload","Compare serverless functions against containers and virtual machines on the control-versus-convenience spectrum",{"id":754,"title":745,"body":755,"description":746,"difficulty":10,"estimatedMinutes":9,"extension":168,"infographics":869,"isFree":182,"learningObjectives":881,"meta":882,"navigation":182,"path":883,"quiz":884,"seo":939,"stem":940,"__hash__":941},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/01-serverless-computing.md",{"type":19,"value":756,"toc":859},[757,761,764,768,771,775,778,782,786,789,793,796,799,802,806,809,811,854,856],[22,758,760],{"id":759},"the-spectrum-lesson-could-not-show-you-this-part","The spectrum lesson could not show you this part",[27,762,763],{},"The compute lesson placed serverless functions at the far right of the control-versus-convenience spectrum: the provider manages everything except your code, and a function starts in milliseconds. That diagram earns its place by showing where serverless sits relative to virtual machines and containers, but it cannot show what \"the provider manages everything\" actually means in practice, or where the edges of that convenience sit. Both matter once you are the one deciding whether a workload belongs on a serverless function at all.",[22,765,767],{"id":766},"no-servers-is-the-marketing-name-not-the-mechanism","No servers is the marketing name, not the mechanism",[27,769,770],{},"\"Serverless\" is the industry's name for the model, not a literal description. AWS runs your function inside an isolated micro virtual machine on its own fleet of physical servers, using a virtualization technology called Firecracker on its Nitro System; Azure and Google Cloud do the equivalent on their own hardware. What \"serverless\" removes is not the server, it is your job of choosing, sizing, patching, and scaling that server. Compare that to IaaS, where you pick the instance type yourself, or even PaaS, where you at least choose a runtime and a scaling policy. A serverless function hands you neither dial: you supply a function, attach a trigger, and the provider decides how many copies of it to run, where, and for how long each one lives.",[22,772,774],{"id":773},"the-event-driven-lifecycle-idle-invoke-execute-idle-again","The event-driven lifecycle: idle, invoke, execute, idle again",[27,776,777],{},"A serverless function does not sit running and waiting for work the way a virtual machine does. Picture a function that generates a thumbnail every time a customer uploads a photo to a storage bucket. Most of the day, zero copies of that function are running anywhere, and it costs nothing. The moment a photo lands in the bucket, the event triggers an invocation: the platform finds or creates an execution environment, runs your handler code against the event, and returns a result. Once the flow of uploads stops for a while, the platform reclaims that environment, and the function is back to zero.",[142,779],{"alt":780,"slug":781},"A timeline showing a serverless function's lifecycle from idle through a cold or warm start, execution, and back to idle, noting that billing follows only the execution segment.","serverless-computing-request-lifecycle",[22,783,785],{"id":784},"cold-starts-and-warm-starts","Cold starts and warm starts",[27,787,788],{},"That \"finds or creates\" distinction has a name. If an execution environment from a recent invocation is still around, the platform reuses it, a warm start, which runs your handler almost immediately. If not, after an idle period or a burst of new traffic, the platform first has to initialize a fresh environment, load your runtime, and import your dependencies before your handler runs at all, a cold start. That initialization work is not free in time or money: current AWS Lambda billing counts the initialization phase of a cold start as billed duration, the same as the handler itself. A function invoked constantly rarely pays the cold-start tax, since environments stay warm; a function invoked in occasional bursts pays it on the first request of every burst.",[22,790,792],{"id":791},"the-math-behind-pay-only-for-what-runs","The math behind \"pay only for what runs\"",[27,794,795],{},"AWS Lambda's on-demand pricing charges $0.20 per million requests plus $0.0000166667 per GB-second of execution time, with a free tier of 1 million requests and 400,000 GB-seconds every month, forever.",[27,797,798],{},"Take a function configured with 512 MB of memory (0.5 GB) that runs for 400 milliseconds (0.4 seconds), invoked 100,000 times a month, image thumbnailing for a small photo-sharing app, say. That workload uses 100,000 x 0.5 x 0.4 = 20,000 GB-seconds and 100,000 requests, both comfortably inside the free tier. The bill: $0.",[27,800,801],{},"Now scale the same function to 5 million invocations a month, a busier app, or the same app grown up. That is 5,000,000 x 0.5 x 0.4 = 1,000,000 GB-seconds, of which 600,000 are billable after the free tier, plus 4,000,000 billable requests. Duration costs about 600,000 x $0.0000166667, roughly $10.00, and requests add another 4 x $0.20 = $0.80, for a bill around $10.80 a month. Compare that to the t3.micro from the compute lesson, about $7.59 a month running around the clock whether it does any work or not. At low, spiky volume, serverless wins outright, it is free. At high, steady volume, an always-on instance can undercut it, and that is before asking whether one t3.micro could even keep up with 5 million requests without falling over.",[22,803,805],{"id":804},"where-a-serverless-function-stops-fitting","Where a serverless function stops fitting",[27,807,808],{},"Two boundaries matter as much as the cost math. First, execution time: AWS Lambda functions cap a single invocation at 15 minutes; a video-encoding job that runs for 2 hours simply does not fit inside a plain function, no matter how the pricing works out. Second, state: an execution environment can be reused between invocations, but nothing guarantees it, so a function cannot rely on data staying in memory or a connection staying open between one invocation and the next. A workload that needs a long-lived database connection pool, a multi-hour batch job, or guaranteed in-memory state belongs on a container or a virtual machine instead.",[22,810,606],{"id":605},[61,812,813,821],{},[64,814,815],{},[67,816,817,819],{},[70,818,615],{},[70,820,618],{},[80,822,823,831,838,846],{},[67,824,825,828],{},[85,826,827],{},"\"Runs only when triggered,\" \"event-driven,\" \"no servers to manage\"",[85,829,830],{},"Serverless function",[67,832,833,836],{},[85,834,835],{},"\"Traffic is unpredictable,\" \"idle most of the day\"",[85,837,830],{},[67,839,840,843],{},[85,841,842],{},"\"Needs a persistent connection,\" \"runs continuously for hours\"",[85,844,845],{},"Container or virtual machine",[67,847,848,851],{},[85,849,850],{},"\"High, steady volume around the clock\"",[85,852,853],{},"Container or virtual machine (cost crossover favors always-on)",[22,855,152],{"id":151},[27,857,858],{},"Serverless does not remove servers, it removes your job of managing them, and it bills you only for the milliseconds your code actually runs. That trade pays off at low or spiky volume and can lose to an always-on instance at high, steady volume, which is exactly why \"serverless is always cheaper\" is a trap, not a rule. The next lesson leaves the question of who manages the server behind and asks a different one: how should the application itself be split into pieces, and how do those pieces run the same way everywhere. That is what containers and microservices answer.",{"title":157,"searchDepth":158,"depth":158,"links":860},[861,862,863,864,865,866,867,868],{"id":759,"depth":161,"text":760},{"id":766,"depth":161,"text":767},{"id":773,"depth":161,"text":774},{"id":784,"depth":161,"text":785},{"id":791,"depth":161,"text":792},{"id":804,"depth":161,"text":805},{"id":605,"depth":161,"text":606},{"id":151,"depth":161,"text":152},[870],{"slug":781,"concept":871,"style":872,"aspectRatio":173,"labels":873},"A left-to-right timeline showing a serverless function's lifecycle across 5 stages: Idle (zero instances running), Event arrives (a trigger invokes the function), a branch into Cold start versus Warm start that reconverges, Execution (the handler runs and returns a response), and Idle again once a timeout reclaims the environment. The cold start path shows an extra 'initialize environment' step drawn visibly longer than the warm start path. A footer strip carries the takeaway that billing follows only the execution segment of this timeline.","timeline",[874,875,876,877,878,879,880],"Idle: zero instances running, zero cost.","Event arrives: a trigger invokes the function.","Cold start: a new environment initializes first. Slower.","Warm start: a cached environment is reused. Faster.","Execution: the handler runs and returns a response.","Idle again: after a timeout, the environment is reclaimed.","You pay only for the execution segment, never for idle time.",[748,749,750,751,752],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/01-serverless-computing",{"passingScore":185,"questions":885},[886,894,902,910,914,922,931],{"question":887,"type":189,"options":888,"correctAnswer":890,"explanation":893},"A colleague says AWS Lambda is called \"serverless\" because Amazon's data centers do not use physical servers for it. What is wrong with this claim?",[889,890,891,892],"Nothing, Lambda functions genuinely run without any physical servers involved","Physical servers still run the function, but the provider manages provisioning, patching, and capacity so you never touch them","Lambda functions run entirely on the requesting device instead of in a data center","Serverless only applies to storage services, not compute","\"Serverless\" describes what disappears from your job, not what disappears from the data center. AWS still runs your function on real hardware, isolated in its own micro virtual machine, but you never choose, size, patch, or scale that machine yourself.",{"question":895,"type":189,"options":896,"correctAnswer":899,"explanation":901},"A team's serverless function handles 100,000 requests a month, each running for 400 ms at 512 MB of memory. Given AWS Lambda's free tier of 1 million requests and 400,000 GB-seconds a month, what does this workload cost?",[897,898,899,900],"About $10.80, since compute charges always exceed the free tier","About $0.20, just the request charge","$0, the workload falls entirely within the free tier","It cannot be calculated without knowing the AWS region","100,000 invocations at 0.5 GB for 0.4 seconds each use 20,000 GB-seconds, well under the 400,000 GB-second free tier, and 100,000 requests is well under the 1 million free requests. Both the compute and request charges land inside the free tier, so the bill is $0.",{"question":903,"type":189,"options":904,"correctAnswer":905,"explanation":909},"The same function type instead runs 5 million times a month at the same 400 ms / 512 MB profile. Which statement about the cost compared to a $7.59-a-month t3.micro instance is accurate?",[905,906,907,908],"The serverless bill, about $10.80, is now higher than the always-on VM, even though the VM might not even handle that volume alone","Serverless remains free no matter how much the volume grows","The VM would cost more than serverless no matter the traffic pattern","AWS caps Lambda's bill so it can never exceed VM pricing","At 5 million invocations, billable usage rises to 600,000 GB-seconds (about $10.00) plus 4 million billable requests (about $0.80), roughly $10.80 total, more than the always-on t3.micro's $7.59. High, steady volume is exactly where an always-on instance can undercut serverless pricing.",{"question":911,"type":189,"options":912,"correctAnswer":218,"explanation":913},"A serverless function can run for as long as a workload needs, with no upper limit on a single invocation's duration.",[217,218],"AWS Lambda functions cap a single invocation at 15 minutes. A workload that genuinely needs hours of continuous processing, a video-encoding job, for example, does not fit inside a plain serverless function no matter how favorable the per-request math looks.",{"question":915,"type":189,"options":916,"correctAnswer":920,"explanation":921},"A serverless function that has not been invoked in over an hour receives a new request. What happens compared to a request that arrives seconds after the previous one?",[917,918,919,920],"The new request is rejected because the function scaled to zero","Nothing changes, every invocation behaves identically regardless of idle time","The new request reuses a cached warm execution environment, exactly like the recent request would","The new request triggers a cold start, since the platform must first initialize a fresh execution environment before running the handler, adding latency a warm request would not have","After an hour of no traffic, the platform has reclaimed any warm environments, so the next invocation pays the cost of initializing a new one first. A request seconds after another one almost always finds a warm environment still around and skips that initialization entirely.",{"question":923,"type":206,"options":924,"correctAnswers":929,"explanation":930},"Which of the following scenario descriptions point toward a serverless function rather than an always-on virtual machine? (Select all that apply.)",[925,926,927,928],"Code needs to run only when a file lands in a storage bucket, a few times a day","The application needs a persistent database connection held open for hours at a time","Traffic is unpredictable and spends most of the day at zero","The workload must run continuously at high, steady volume around the clock",[925,927],"Event-driven work and traffic that spends most of its time at zero are exactly what serverless functions are billed and built for: no cost while idle, automatic scaling when a burst arrives. A persistent connection held open for hours and steady round-the-clock volume both point toward a container or virtual machine instead.",{"question":932,"type":189,"options":933,"correctAnswer":934,"explanation":938},"This lesson placed serverless functions on the control-versus-convenience spectrum. What question does the next topic in this domain, containers and microservices, ask instead?",[934,935,936,937],"How should the application itself be split into pieces, and how do those pieces run consistently across environments","Who manages the underlying physical servers","How much a workload costs per month","Which programming language the team should use","Serverless functions answer who manages the server. Containers and microservices leave that question behind and ask how the application's own code should be organized and packaged so it runs the same way everywhere.",{"title":745,"description":746},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/01-serverless-computing","9_f-d1cgguk9P2Vb5FVYfvScvwpt34XfIoc6b6isRCc"]