[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"prev-cloud-computing-fundamentals-cloud-concepts-and-economics-cloud-economics-cloud-pricing-models-en":4,"lesson-cloud-computing-fundamentals-cloud-concepts-and-economics-cloud-economics-cloud-pricing-models-en":171,"next-cloud-computing-fundamentals-cloud-concepts-and-economics-cloud-economics-cloud-pricing-models-en":408},null,{"locked":5,"reason":3,"meta":6,"item":17},false,{"title":7,"description":8,"isFree":9,"estimatedMinutes":10,"difficulty":11,"learningObjectives":12},"CapEx vs OpEx","Why buying a server and renting one from a cloud provider hit a company's books in completely different ways, and why a monthly invoice is not automatically the same thing as OpEx.",true,15,"beginner",[13,14,15,16],"Define capital expenditure (CapEx) and operating expenditure (OpEx) by asking who owns the underlying asset","Explain why the cloud shifted IT spending from CapEx toward OpEx, and what that shift does to cash flow and risk","Identify the misconception that billing frequency, rather than asset ownership, determines whether a cost is CapEx or OpEx","Calculate the CapEx and OpEx totals for the same workload using real dollar figures",{"id":18,"title":7,"body":19,"description":8,"difficulty":11,"estimatedMinutes":10,"extension":103,"infographics":104,"isFree":9,"learningObjectives":113,"meta":114,"navigation":9,"path":115,"quiz":116,"seo":168,"stem":169,"__hash__":170},"courses/courses/cloud-computing-fundamentals/en/domains/01-cloud-concepts-and-economics/03-cloud-economics/01-capex-vs-opex.md",{"type":20,"value":21,"toc":92},"minimark",[22,27,31,35,38,41,45,48,51,55,58,61,64,69,73,76,79,82,85,89],[23,24,26],"h2",{"id":25},"from-a-locked-in-guess-to-a-monthly-choice","From a locked-in guess to a monthly choice",[28,29,30],"p",{},"The previous topic left you at the edge of a question every deployment decision eventually runs into: what does this actually cost? The first lesson of this domain already put a name on half the answer, in passing. A company that buys $40,000 of server hardware books that purchase as capital expenditure, or CapEx, months before it knows how much of that capacity it will actually use. Move the same workload to a cloud provider instead, and the same team pays for it differently enough that accounting uses an entirely different word: operating expenditure, or OpEx. The difference is not just vocabulary. It changes how much cash a company ties up, how a purchase affects its tax filings, and how much risk it carries into a decision that is hard to reverse.",[23,32,34],{"id":33},"what-capex-means-and-what-it-costs-you-upfront","What CapEx means, and what it costs you upfront",[28,36,37],{},"CapEx is money spent to acquire a long-lived asset, a building, a vehicle, server hardware, that the company then owns and uses for years. Accounting will not let you deduct the full purchase the day you pay for it. Instead, you depreciate it: spreading the expense across the asset's useful life on the income statement, even though the cash left the bank account all at once. A $40,000 server with a 5-year useful life, depreciated on a straight-line basis, shows up as an $8,000 expense every year for 5 years, but the full $40,000 was gone from the company's cash the month it was purchased.",[28,39,40],{},"That gap between \"cash spent\" and \"expense recognized\" creates 2 real consequences. First, the cash is committed immediately, before the business knows whether it will grow into that capacity or outgrow it. Second, the purchase is close to final: reversing it means selling used hardware, usually for a fraction of what it cost, not simply cancelling a subscription.",[23,42,44],{"id":43},"what-opex-means-and-why-cloud-providers-are-built-to-sell-it","What OpEx means, and why cloud providers are built to sell it",[28,46,47],{},"OpEx is the cost of running the business day to day, recognized as an expense in the same period it is incurred, with no lasting asset left on the balance sheet afterward. Renting compute from a cloud provider is exactly this: you pay for an hour of usage, and that hour's cost hits the books the month you used it, not spread across 5 future years of depreciation. Nothing about the arrangement requires you to own hardware, because you do not. The provider does.",[28,49,50],{},"This is also why AWS's own Well-Architected Framework lists \"adopt a consumption model\" as a foundational cost optimization principle: pay only for the computing resources you consume, and scale up or down as the business actually needs, rather than sizing a purchase around a guess about the future. The framework gives a concrete illustration: a development environment used only 8 hours a day on weekdays and switched off the rest of the time can cut its compute cost by as much as 75%, simply by not paying for the 128 hours a week nobody is using it. A CapEx purchase cannot do that. Once you own the server, it costs the same whether it is busy or idle.",[23,52,54],{"id":53},"the-misconception-billing-frequency-is-not-the-test","The misconception: billing frequency is not the test",[28,56,57],{},"It is tempting to assume that if a cost shows up on a bill every month, it must be OpEx, and if you pay a lump sum upfront, it must be CapEx. That rule breaks the moment you look at how cloud providers actually price commitments.",[28,59,60],{},"AWS lets you pay for a 3-year Reserved Instance or Savings Plan entirely upfront, in a single lump sum that can run into tens of thousands of dollars paid on day one. That single large payment still does not turn the bill into CapEx, because the company still does not own a server. AWS does. Accounting treats it as a prepaid operating expense, amortized across the 3 years it covers, not as a depreciating asset on the buyer's balance sheet. Run the comparison the other way, and it holds just as well: a company that finances a physical server purchase with a bank loan and repays it in 36 equal monthly installments is still paying for CapEx. Spreading the payments out does not turn a loan into rent. The company still owns, and still depreciates, the machine at the end of it.",[28,62,63],{},"The actual test is simple to state and easy to forget under pressure: do you own a depreciating asset that sits on your balance sheet, or are you paying for someone else's asset as you consume it? That question, not the invoice schedule, is what a finance team is really asking when it labels a cost CapEx or OpEx.",[65,66],"infographic",{"alt":67,"slug":68},"A side-by-side comparison showing CapEx as one large upfront payment for an owned, depreciating asset, next to OpEx as many small payments each fully expensed as incurred.","capex-vs-opex-split",[23,70,72],{"id":71},"worked-example-the-same-workload-2-different-books","Worked example: the same workload, 2 different books",[28,74,75],{},"Say a company needs a database server to handle steady, predictable traffic for the next 5 years. It can go 2 ways.",[28,77,78],{},"The CapEx path: buy a physical server for $40,000. That $40,000 leaves the bank in month one. The income statement shows $8,000 of depreciation a year for 5 years. The company also now owns the rack space and power draw that server needs, and will eventually pay to dispose of it when it retires.",[28,80,81],{},"The OpEx path: rent equivalent compute from a cloud provider for $700 a month, or $8,400 a year. Each month's bill is fully expensed the month it is incurred. No cash is committed beyond that month, and the arrangement can be resized or cancelled at any time without owning anything to sell off afterward.",[28,83,84],{},"Add up 5 years of each path, ignoring financing costs for simplicity: the CapEx path spends $40,000 in total cash. The OpEx path spends $8,400 a year for 5 years, or $42,000. The cloud path here actually costs slightly more in total dollars over the full 5 years. That is worth sitting with for a moment: OpEx is not a guarantee of a lower price tag. Its advantage is smaller, reversible commitments instead of one large, irreversible one, which matters most when you are not yet certain the capacity will get used for the full 5 years. Whether the extra flexibility is worth that gap, and how to measure the full picture properly, is exactly what the total cost of ownership lesson later in this topic works through.",[23,86,88],{"id":87},"where-this-leaves-you","Where this leaves you",[28,90,91],{},"Ask one question about any cost: do you own the asset, or are you renting the outcome? That single distinction, not how the invoice arrives, is what separates CapEx from OpEx. Knowing that cloud spending is OpEx does not yet tell you which OpEx option to pick, though. Cloud providers sell the exact same capacity several different ways, on-demand, reserved, spot, each trading a different amount of discount for a different amount of commitment. That choice is what the next lesson breaks down.",{"title":93,"searchDepth":94,"depth":94,"links":95},"",3,[96,98,99,100,101,102],{"id":25,"depth":97,"text":26},2,{"id":33,"depth":97,"text":34},{"id":43,"depth":97,"text":44},{"id":53,"depth":97,"text":54},{"id":71,"depth":97,"text":72},{"id":87,"depth":97,"text":88},"md",[105],{"slug":68,"concept":106,"style":107,"aspectRatio":108,"labels":109},"A two-panel comparison diagram, CapEx on the left and OpEx on the right. The left panel shows a single large payment arrow hitting a server icon, with a small depreciation bar chart underneath spreading that cost across 5 shrinking yearly slices, labeled as a balance-sheet asset. The right panel shows a repeating sequence of small equal payment arrows hitting a cloud icon, each one fully absorbed the month it happens, with no asset icon left behind. A footer strip carries the one-sentence takeaway about the real test: ownership, not billing frequency.","comparison","16:9",[110,111,112],"CapEx: one large payment, an owned asset that depreciates over years on the balance sheet","OpEx: many small payments, each one fully expensed the month it happens, nothing owned","The real test: do you own a depreciating asset, or are you paying for a service as you use it?",[13,14,15,16],{},"/courses/cloud-computing-fundamentals/en/domains/01-cloud-concepts-and-economics/03-cloud-economics/01-capex-vs-opex",{"passingScore":117,"questions":118},70,[119,128,134,142,152,160],{"question":120,"type":121,"options":122,"correctAnswer":125,"explanation":127},"Which question actually determines whether a cost counts as CapEx or OpEx?","single",[123,124,125,126],"How often the invoice arrives","Whether the total cost is over a fixed dollar threshold","Whether you own the underlying asset or are paying for it as a service","Whether the provider happens to be a cloud company","Accounting draws the line at ownership: CapEx buys an asset the company keeps and depreciates, while OpEx pays for something consumed and expensed in the same period. Invoice frequency and dollar amount are surface details that often correlate with this split, but neither one is the actual rule.",{"question":129,"type":121,"options":130,"correctAnswer":132,"explanation":133},"Paying for a 3-year AWS Savings Plan entirely upfront in a single lump sum converts that spending into CapEx.",[131,132],"True","False","Even a large lump-sum prepayment stays OpEx, because the company still does not own any hardware, AWS does. Accounting treats it as a prepaid operating expense amortized across the commitment term, not as a depreciating asset on the buyer's balance sheet.",{"question":135,"type":121,"options":136,"correctAnswer":137,"explanation":141},"A logistics company takes out a bank loan to buy 10 physical servers and repays the loan in 36 equal monthly installments. How does its accounting department most likely classify this spending?",[137,138,139,140],"CapEx, because the company owns a depreciating asset regardless of the payment schedule","OpEx, because it is billed monthly in equal installments","OpEx, because a loan is not considered a capital purchase","It depends only on the interest rate charged on the loan","The company owns the servers the moment it buys them, and that ownership, not the monthly loan repayment schedule, is what makes this CapEx. A monthly payment plan changes the cash flow timing, not the accounting classification of the underlying asset.",{"question":143,"type":144,"options":145,"correctAnswers":150,"explanation":151},"Which of these are genuine effects of the CapEx model, according to this lesson? (Select all that apply.)","multiple",[146,147,148,149],"Cash leaves the business in one large amount before usage is proven","The purchase is easy to reverse if the business's needs change","The expense is depreciated across the asset's useful life on the income statement","The company owns the underlying hardware",[146,148,149],"CapEx ties up cash immediately, spreads the expense across years of depreciation, and leaves the company holding an owned asset. The one false statement is reversibility: a CapEx purchase is hard to undo, since reversing it means selling used hardware for a fraction of what it cost.",{"question":153,"type":121,"options":154,"correctAnswer":158,"explanation":159},"Why did the shift from CapEx to OpEx appeal to fast-growing startups in particular?",[155,156,157,158],"OpEx is always the cheaper total price over the life of a workload","OpEx eliminates the need for any IT staff","OpEx removes the need to ever pay for compute capacity","OpEx avoids tying up cash in a large purchase before the business has proven how much capacity it actually needs","A startup's biggest constraint is usually cash, not compute. OpEx keeps that cash free for a business still figuring out its actual usage pattern; it does not automatically mean a lower total price, and it does not remove the need to pay for compute or staff altogether.",{"question":161,"type":121,"options":162,"correctAnswer":164,"explanation":167},"A company buys a $40,000 server with a 5-year useful life and depreciates it on a straight-line basis. How much does this purchase reduce the company's reported profit on the income statement in year 1?",[163,164,165,166],"$40,000","$8,000","$4,000","$0, because the cash already left the bank","Straight-line depreciation spreads the $40,000 cost across the server's 5-year life, so year 1's income statement shows an $8,000 depreciation expense, even though the full $40,000 in cash left the bank account the day the server was purchased. That gap, cash spent immediately but expense recognized gradually, is exactly what CapEx accounting produces.",{"title":7,"description":8},"courses/cloud-computing-fundamentals/en/domains/01-cloud-concepts-and-economics/03-cloud-economics/01-capex-vs-opex","YiFuBEPhlYzupFZohR7I90ZXGIzpxJXpCGNAq7BCzH4",{"locked":5,"reason":3,"meta":172,"item":181},{"title":173,"description":174,"isFree":5,"estimatedMinutes":175,"difficulty":11,"learningObjectives":176},"Cloud Pricing Models","On-demand, reserved and committed-use, and spot pricing across AWS, Azure, and Google Cloud: the discount each one trades for a commitment, and which workload actually fits each one.",18,[177,178,179,180],"Explain why cloud providers discount pricing in exchange for a usage commitment, and what a workload gives up to get that discount","Compare on-demand, reserved and committed-use, and spot pricing by discount size, commitment length, and interruption risk","Match a workload's predictability and interruption tolerance to the pricing model that fits it","Calculate the monthly savings a committed-use discount produces over on-demand pricing for a given spend",{"id":182,"title":173,"body":183,"description":174,"difficulty":11,"estimatedMinutes":175,"extension":103,"infographics":339,"isFree":5,"learningObjectives":348,"meta":349,"navigation":9,"path":350,"quiz":351,"seo":405,"stem":406,"__hash__":407},"courses/courses/cloud-computing-fundamentals/en/domains/01-cloud-concepts-and-economics/03-cloud-economics/02-cloud-pricing-models.md",{"type":20,"value":184,"toc":330},[185,189,192,196,199,203,206,209,212,215,219,222,225,228,232,311,315,319,322,325,327],[23,186,188],{"id":187},"paying-the-same-rate-whether-you-need-flexibility-or-not","Paying the same rate whether you need flexibility or not",[28,190,191],{},"Run a database server 24 hours a day, every day, for 3 years straight, and you are still charged the exact same per-hour rate as a team that might shut its server down tomorrow. On-demand pricing is built for that second team, the one that needs the freedom to walk away at any moment. If a workload never walks away, that built-in flexibility is not free. The team running it every single hour is quietly paying for an option it never uses.",[23,193,195],{"id":194},"on-demand-pay-for-exactly-what-you-use-whenever-you-use-it","On-demand: pay for exactly what you use, whenever you use it",[28,197,198],{},"On-demand pricing has no upfront payment and no long-term commitment. AWS bills EC2 On-Demand Instances by the hour or the second, with a 60-second minimum, at a rate set by the provider and unaffected by how long someone has been a customer. This is the model built for the exact problem the first lesson in this domain opened with: guessing how much capacity a brand-new or unpredictable workload will need. Guess wrong on-demand, and the fix is a few clicks, not a hardware return.",[23,200,202],{"id":201},"reserved-and-committed-use-pricing-trading-flexibility-for-a-discount","Reserved and committed-use pricing: trading flexibility for a discount",[28,204,205],{},"Commit to steady usage for 1 or 3 years, and a provider prices that certainty into a lower rate. AWS calls this Reserved Instances or Savings Plans, discounting up to 72% off On-Demand pricing, with a 3-year term always discounting more than a 1-year one because it removes more uncertainty from the provider's own planning. Payment can be split 3 ways: All Upfront, Partial Upfront, or No Upfront, and generally the more you pay upfront, the deeper the discount.",[28,207,208],{},"Reserved Instances come in 2 offering classes, and the difference between them is worth knowing precisely. Standard Reserved Instances lock in the largest discount, but the instance family and Region are fixed for the term; they can be modified within limits but never exchanged for something different. Convertible Reserved Instances trade some of that discount away in exchange for the right to exchange the reservation later for a different instance family, useful for a team that expects its needs to shift before the term ends.",[28,210,211],{},"Other providers sell the same underlying idea under different names. Azure calls its version Reserved VM Instances, also up to 72% off pay-as-you-go pricing, and adds something specific to its own business: Azure Hybrid Benefit lets a company that already owns Windows Server or SQL Server licenses apply them in the cloud, stacking with a reservation for a combined discount of up to 85%. Google Cloud calls the equivalent Committed Use Discounts, up to 55% off standard machine types and up to 70% off memory-optimized ones, in exchange for the same 1- or 3-year commitment.",[28,213,214],{},"Google Cloud adds a second discount that AWS and Azure do not offer at all: the Sustained Use Discount, applied automatically, with no commitment of any kind. Run an eligible VM for more than 25% of a billing month, and Google Cloud starts discounting it on its own, with the discount growing as the VM's runtime approaches the full month, up to about 30% off. On AWS and Azure, a discount only exists if you commit to it in advance. On Google Cloud, simply running a workload long enough earns one automatically. That is a genuine structural difference between how the 3 providers price commitment, not just 3 names for the same mechanism.",[23,216,218],{"id":217},"spot-and-preemptible-the-deepest-discount-with-a-real-catch","Spot and preemptible: the deepest discount, with a real catch",[28,220,221],{},"Spot pricing sells unused capacity that a provider would rather discount heavily than leave idle. AWS EC2 Spot Instances discount up to 90% off On-Demand pricing, but AWS can reclaim that capacity with only a 2-minute warning whenever it needs it for an on-demand or committed customer instead. Azure Spot Virtual Machines discount up to 90% off pay-as-you-go rates and offer no reservation option at all. Google Cloud Spot VMs discount up to 91%, and can be preempted at any time.",[28,223,224],{},"This model fits fault-tolerant, interruption-tolerant work: batch data processing, CI/CD pipelines, rendering jobs, anything that checkpoints its progress often enough that an interruption costs a few minutes, not a failed job.",[28,226,227],{},"It is tempting to treat spot pricing as simply a cheaper version of on-demand. It is not the same product at a lower price. It is fundamentally uncommitted capacity that the provider can take back whenever a paying on-demand or committed customer needs it instead. Putting a production database, something that cannot tolerate a sudden shutdown, on spot pricing is one of the most common cost-optimization mistakes teams make, and a frequent trap in exam-style scenarios for exactly that reason.",[23,229,231],{"id":230},"the-3-models-side-by-side","The 3 models, side by side",[233,234,235,253],"table",{},[236,237,238],"thead",{},[239,240,241,244,247,250],"tr",{},[242,243],"th",{},[242,245,246],{},"On-Demand",[242,248,249],{},"Reserved / Committed Use",[242,251,252],{},"Spot / Preemptible",[254,255,256,271,284,297],"tbody",{},[239,257,258,262,265,268],{},[259,260,261],"td",{},"Discount vs on-demand rate",[259,263,264],{},"None (this is the baseline)",[259,266,267],{},"Up to 72% (AWS, Azure), up to 70% (Google Cloud)",[259,269,270],{},"Up to 90 to 91%",[239,272,273,276,279,282],{},[259,274,275],{},"Commitment",[259,277,278],{},"None",[259,280,281],{},"1 or 3 years",[259,283,278],{},[239,285,286,289,292,294],{},[259,287,288],{},"Can be interrupted",[259,290,291],{},"No",[259,293,291],{},[259,295,296],{},"Yes, with little to no notice",[239,298,299,302,305,308],{},[259,300,301],{},"Best fit",[259,303,304],{},"Unpredictable, short-lived, or brand-new workloads",[259,306,307],{},"Steady, predictable baseline capacity",[259,309,310],{},"Fault-tolerant, interruption-tolerant batch work",[65,312],{"alt":313,"slug":314},"A spectrum showing On-Demand, Reserved or Committed Use, and Spot pricing arranged by discount size, with discount growing as commitment and flexibility trade off against each other.","cloud-pricing-models-spectrum",[23,316,318],{"id":317},"worked-example-what-a-commitment-is-actually-worth","Worked example: what a commitment is actually worth",[28,320,321],{},"Say a workload runs steadily enough that its on-demand bill is $1,000 a month. Commit that workload to a 3-year Savings Plan at the ceiling AWS advertises, up to 72% off, and the same workload costs about $280 a month instead, a savings of roughly $720 a month, or about $8,640 over a year, in exchange for giving up the ability to walk away without penalty.",[28,323,324],{},"That discount only pays off if the commitment actually gets used. A 3-year Reserved Instance sized for a project that gets cancelled 8 months in is now a fixed cost with 28 months left to run and nothing left to run it on, which is exactly why committing should follow measured, steady usage, not a guess about future growth, the same guessing problem that made traditional on-premises IT so expensive in the first place.",[23,326,88],{"id":87},[28,328,329],{},"Match the commitment to how sure you are, and to how much an interruption would actually cost. A workload running every day for the next 3 years belongs on a committed rate. A workload that can lose an hour of progress and simply restart belongs on spot. Everything in between stays on-demand until there is enough usage history to commit with confidence. None of these hourly rates is the full story, though: the price on this page is not the same thing as what a workload actually costs a company to run, once the people, the tools, and everything built around it get counted too. That gap is exactly what total cost of ownership measures, and it is where this topic goes next.",{"title":93,"searchDepth":94,"depth":94,"links":331},[332,333,334,335,336,337,338],{"id":187,"depth":97,"text":188},{"id":194,"depth":97,"text":195},{"id":201,"depth":97,"text":202},{"id":217,"depth":97,"text":218},{"id":230,"depth":97,"text":231},{"id":317,"depth":97,"text":318},{"id":87,"depth":97,"text":88},[340],{"slug":314,"concept":341,"style":342,"aspectRatio":108,"labels":343},"A horizontal spectrum diagram with 3 positions along one axis labeled discount size, increasing left to right. On-Demand sits at the left end with an icon showing full flexibility and no lock. Reserved / Committed Use sits in the middle with an icon showing a calendar spanning 1 to 3 years. Spot / Preemptible sits at the right end with an icon showing a capacity block that can be pulled away. Each position carries a short caption with its discount ceiling and its main tradeoff. A footer strip carries the takeaway that discount grows as flexibility shrinks.","diagram",[344,345,346,347],"On-Demand: no commitment, full flexibility, the baseline rate","Reserved / Committed Use: 1 to 3-year commitment, up to 72% off","Spot / Preemptible: no commitment, up to 90% off, capacity can be reclaimed anytime","Discount grows as flexibility shrinks",[177,178,179,180],{},"/courses/cloud-computing-fundamentals/en/domains/01-cloud-concepts-and-economics/03-cloud-economics/02-cloud-pricing-models",{"passingScore":117,"questions":352},[353,361,365,372,380,389,397],{"question":354,"type":121,"options":355,"correctAnswer":357,"explanation":360},"What does a cloud provider get in return for offering a steep discount on reserved or committed-use pricing?",[356,357,358,359],"A promise that the customer will only ever use spot capacity","A predictable, committed usage pattern it can plan its own capacity around","A one-time setup fee paid through a reseller","Exclusive rights to the customer's application data","Reserved and committed-use discounts exist because a provider can plan its own data center capacity more efficiently when it knows, in advance, how much a customer will use and for how long. The customer trades flexibility for that certainty, and the provider prices the discount accordingly.",{"question":362,"type":121,"options":363,"correctAnswer":132,"explanation":364},"Amazon EC2 Spot Instances let you reserve guaranteed capacity for a fixed term, the same way Reserved Instances do.",[131,132],"Spot Instances have no reservation and no guaranteed term. They use spare capacity that AWS can reclaim with as little as 2 minutes of notice when it needs that capacity for on-demand or committed customers instead, which is the opposite of a Reserved Instance's guaranteed term.",{"question":366,"type":121,"options":367,"correctAnswer":370,"explanation":371},"A team runs a nightly batch job that reprocesses log files, checkpoints its progress every few minutes, and can safely restart if interrupted. Which pricing model fits this workload best?",[246,368,369,370],"3-year Reserved Instance, paid All Upfront","Dedicated Host","Spot or preemptible capacity","A job that checkpoints frequently and tolerates restarts is exactly what spot and preemptible pricing is built for: the deepest discount, in exchange for the provider's right to reclaim the capacity at any time. Committing this workload to a 3-year reservation would lock in a fixed cost for a job that does not need the guarantee.",{"question":373,"type":121,"options":374,"correctAnswer":375,"explanation":379},"What is the key difference between a Standard and a Convertible Reserved Instance on AWS?",[375,376,377,378],"Standard offers the largest discount but cannot be exchanged for a different instance family; Convertible offers a smaller discount but can be exchanged","Standard can only be purchased with a No Upfront payment option","Convertible Reserved Instances always cost more than On-Demand pricing","Standard applies only to spot capacity, and Convertible applies only to on-demand capacity","Standard Reserved Instances lock in the largest discount but can only be modified, not exchanged for a different instance family. Convertible Reserved Instances trade some of that discount for the ability to exchange the reservation later if instance needs change, which is the boundary the exam expects you to know between the two.",{"question":381,"type":144,"options":382,"correctAnswers":387,"explanation":388},"Which of the following are true about Google Cloud's discount model, based on this lesson? (Select all that apply.)",[383,384,385,386],"Sustained Use Discounts apply automatically once a VM runs more than 25% of a billing month, with no upfront commitment","Committed Use Discounts require a 1- or 3-year commitment, similar to AWS Reserved Instances","Spot VMs on Google Cloud can never be preempted once they start running","Sustained Use and Committed Use discounts can both be stacked on top of Spot pricing for the same VM",[383,384],"Google Cloud is unusual in offering an automatic discount, the Sustained Use Discount, with no commitment at all, on top of a committed-use option similar to AWS and Azure. Spot VMs can be preempted at any time, and discount types cannot be combined: a VM running on Spot pricing does not also collect Sustained Use or Committed Use discounts.",{"question":390,"type":121,"options":391,"correctAnswer":394,"explanation":396},"A workload costs $1,000 a month at on-demand rates. The team commits to a 3-year Savings Plan advertised at up to 72% off On-Demand pricing. Roughly what will the monthly bill be after the discount?",[392,393,394,395],"$720","$500","$280","$72","A 72% discount off $1,000 leaves 28% of the original cost, or about $280 a month. That is roughly $720 a month in savings, or about $8,640 a year, in exchange for committing to that usage level for the full 3-year term.",{"question":398,"type":121,"options":399,"correctAnswer":401,"explanation":404},"A company signs a 3-year Reserved Instance commitment sized for a project that gets cancelled 8 months later. What does this scenario best illustrate?",[400,401,402,403],"Reserved pricing always costs more than On-Demand pricing in the end","A commitment only pays off if the usage it was sized for actually happens","Spot capacity should have been used instead of a Reserved Instance","The provider will automatically refund the unused months","A Reserved Instance is a bet that the usage will continue for the full term. When the project ends early, the remaining 28 months still have to be paid for, turning what looked like savings into a fixed cost with nothing left to run on it. This is exactly why committing should follow measured, steady usage rather than a guess about future growth.",{"title":173,"description":174},"courses/cloud-computing-fundamentals/en/domains/01-cloud-concepts-and-economics/03-cloud-economics/02-cloud-pricing-models","m0ezqHWY_aaTLqn2jhlWvCKkCV0ftmkZ_lsXBk53fMU",{"locked":5,"reason":3,"meta":409,"item":418},{"title":410,"description":411,"isFree":5,"estimatedMinutes":175,"difficulty":412,"learningObjectives":413},"Total Cost of Ownership","Why the number on a cloud invoice, or a hardware quote, is never the full cost of running a workload, and how to compare cloud and on-premises costs honestly over several years.","intermediate",[414,415,416,417],"Define total cost of ownership (TCO) and distinguish it from the price on a single invoice or hardware quote","Identify the direct and indirect cost categories a full TCO comparison has to include on both the cloud and on-premises sides","Explain what FinOps is and why it exists as an ongoing practice rather than a one-time calculation","Evaluate a scenario to judge whether a workload's TCO favors cloud or on-premises infrastructure",{"id":419,"title":410,"body":420,"description":411,"difficulty":412,"estimatedMinutes":175,"extension":103,"infographics":591,"isFree":5,"learningObjectives":599,"meta":600,"navigation":9,"path":601,"quiz":602,"seo":656,"stem":657,"__hash__":658},"courses/courses/cloud-computing-fundamentals/en/domains/01-cloud-concepts-and-economics/03-cloud-economics/03-total-cost-of-ownership.md",{"type":20,"value":421,"toc":582},[422,426,429,432,436,439,443,446,449,453,456,459,463,466,554,557,560,564,568,571,574,576,579],[23,423,425],{"id":424},"the-invoice-that-only-tells-you-the-price-of-the-meter","The invoice that only tells you the price of the meter",[28,427,428],{},"In 2022, 37signals, the company behind Basecamp and the email service Hey, decided its AWS and Google Cloud bills had become one of the most expensive parts of running the business, and began moving that infrastructure back into its own data centers. By 2024, its annual cloud bill had dropped from $3.2 million to $1.3 million, a reported $2 million a year in savings, after an upfront hardware purchase of around $700,000, with the company projecting more than $10 million saved over 5 years. That is a real, well-documented case of owning hardware costing less than renting the equivalent capacity, for that company's specific, steady, predictable workload.",[28,430,431],{},"It is also, on its own, an incomplete comparison, and understanding why is exactly what total cost of ownership is for.",[23,433,435],{"id":434},"what-tco-actually-means","What TCO actually means",[28,437,438],{},"Total cost of ownership is the complete cost of acquiring, running, and maintaining a system over a defined period, usually 3 to 5 years, not just the price of any single line item. A cloud invoice shows the meter: compute, storage, and data transfer, billed for the month just used. A hardware quote shows the sticker price of the box. Neither one is TCO. TCO is what you get once you add everything that surrounds that visible number on both sides of the comparison.",[23,440,442],{"id":441},"direct-costs-versus-the-costs-nobody-puts-on-the-invoice","Direct costs versus the costs nobody puts on the invoice",[28,444,445],{},"The direct, metered costs are the ones a cloud bill already shows: compute, storage, and data transfer. Data transfer deserves a specific note, because it is not symmetric. AWS, like most providers, does not charge to move data into its cloud, but does charge, on a tiered basis, to move data out, called egress. A workload that reads a small amount of data but exports large amounts of it regularly can carry a much bigger data-transfer bill than its compute costs alone would suggest.",[28,447,448],{},"Everything else is an indirect cost, and it sits on both sides of the comparison, not just one. On the cloud side: the one-time work of migrating or re-architecting a workload to run there, staff time spent configuring, monitoring, and optimizing cloud resources, the cost-management and monitoring tooling bought specifically to track that spend, and security or compliance tooling layered on top. On the on-premises side: power and cooling for the room the hardware sits in, the real estate itself, a hardware refresh every few years as equipment ages out, and staff time spent racking, patching, and eventually disposing of retired equipment, the same maintenance burden the first lesson in this domain described as one of the original reasons the cloud exists.",[23,450,452],{"id":451},"the-trap-comparing-only-whats-easy-to-compare","The trap: comparing only what's easy to compare",[28,454,455],{},"It is tempting to run this comparison by looking up 2 numbers, this quarter's cloud bill and the sticker price of equivalent server hardware, and declaring whichever one is smaller the winner. Neither number is TCO. The cloud bill leaves out the staff and tooling built up around it. The hardware sticker price leaves out power, cooling, and the refresh cycle that arrives again in 3 to 5 years.",[28,457,458],{},"The 37signals case is a useful, real example of how easy this trap is to fall into even when a company is genuinely trying to be rigorous. Independent reporting on the move specifically noted that its published savings figures did not yet account for future hardware refresh costs, the additional operations staff the move required, or the ongoing cost of running data center space, power, and cooling. That is not a criticism of 37signals's decision, which may well still hold up once those categories are counted. It is a demonstration that even a company publicly making the case for owning hardware had not, at the point those figures were reported, finished counting every category a full TCO comparison requires.",[23,460,462],{"id":461},"worked-example-a-3-year-comparison-done-honestly","Worked example: a 3-year comparison, done honestly",[28,464,465],{},"Take a workload with steady, predictable traffic and compare 3 years of on-premises ownership against 3 years in the cloud, counting the indirect costs on both sides.",[233,467,468,481],{},[236,469,470],{},[239,471,472,475,478],{},[242,473,474],{},"Cost category",[242,476,477],{},"On-premises (3 years)",[242,479,480],{},"Cloud (3 years)",[254,482,483,494,505,515,525,536],{},[239,484,485,488,491],{},[259,486,487],{},"Compute and storage / hardware",[259,489,490],{},"$120,000 (upfront purchase)",[259,492,493],{},"$270,000 ($7,500/month)",[239,495,496,499,502],{},[259,497,498],{},"Power and cooling",[259,500,501],{},"$45,000 ($15,000/year)",[259,503,504],{},"--",[239,506,507,510,512],{},[259,508,509],{},"Cost-management and monitoring tooling",[259,511,504],{},[259,513,514],{},"$6,000 ($2,000/year)",[239,516,517,520,522],{},[259,518,519],{},"One-time migration",[259,521,504],{},[259,523,524],{},"$20,000",[239,526,527,530,533],{},[259,528,529],{},"Staff time",[259,531,532],{},"$150,000 ($50,000/year)",[259,534,535],{},"$75,000 ($25,000/year)",[239,537,538,544,549],{},[259,539,540],{},[541,542,543],"strong",{},"Total",[259,545,546],{},[541,547,548],{},"$315,000",[259,550,551],{},[541,552,553],{},"$371,000",[28,555,556],{},"For this specific, steady workload, the honest 3-year comparison favors on-premises hardware, by about $56,000, and not simply because the cloud's metered bill is bigger than the hardware's sticker price. It only becomes clear once staffing and tooling are counted on both sides. This is the same shape of decision 37signals made, at a much larger scale.",[28,558,559],{},"Change one assumption and the answer can flip. Give this workload a traffic pattern that spikes to 3 times its baseline for 2 weeks a year, and the on-premises side now needs hardware sized for a peak it uses for 2 weeks and leaves idle the rest of the year, the exact overprovisioning problem the cloud was built to remove. The cloud side, by contrast, simply scales up for those 2 weeks and back down afterward, paying only for the extra capacity it actually used. That single change in workload shape is often enough to tip the comparison the other way. Neither \"the cloud is always cheaper\" nor \"the cloud is always a ripoff\" is a rule you can memorize; TCO is a calculation you run for a specific workload, not a verdict that transfers from one company's case to another's.",[65,561],{"alt":562,"slug":563},"An iceberg diagram showing the visible cloud invoice above the waterline and the larger, hidden costs of staff, tooling, migration, power, and cooling below it.","total-cost-of-ownership-iceberg",[23,565,567],{"id":566},"finops-the-discipline-that-keeps-tco-from-going-stale","FinOps: the discipline that keeps TCO from going stale",[28,569,570],{},"A TCO calculation is a snapshot, priced once for a decision made at one point in time. Cloud spending does not stay still after that decision: it changes every time an engineer spins up a new resource, which is exactly what makes it different from a fixed annual data center budget set once and left alone. FinOps is the discipline built to manage that difference. The FinOps Foundation defines it as an operational framework and cultural practice that maximizes the business value of technology, enables timely, data-driven decisions, and creates financial accountability through collaboration between engineering, finance, and business teams, rather than treating cost as something only a finance department reviews after the fact.",[28,572,573],{},"This is the same idea AWS's own Well-Architected Framework points at with its cost optimization principles: implementing cloud financial management as a real organizational capability, and continuously analyzing and attributing expenditure so a workload's owner can see, and act on, what it actually costs. FinOps is what it looks like to run that analysis continuously instead of once a year.",[23,575,88],{"id":87},[28,577,578],{},"A cloud invoice and a hardware quote are both partial answers. Before comparing 2 ways of running a workload, list every direct and indirect cost on both sides, price them over the same multi-year window, and only then compare totals. Get that habit right once, in a spreadsheet, and FinOps is simply what it looks like to keep doing it continuously instead of once.",[28,580,581],{},"That closes out the economics of the cloud: what problem it solves, how you pay for it, and what it actually costs to run. The next domain leaves cost behind and turns to the services themselves, starting with the 3 ways cloud providers package what they sell: IaaS, PaaS, and SaaS.",{"title":93,"searchDepth":94,"depth":94,"links":583},[584,585,586,587,588,589,590],{"id":424,"depth":97,"text":425},{"id":434,"depth":97,"text":435},{"id":441,"depth":97,"text":442},{"id":451,"depth":97,"text":452},{"id":461,"depth":97,"text":462},{"id":566,"depth":97,"text":567},{"id":87,"depth":97,"text":88},[592],{"slug":563,"concept":593,"style":342,"aspectRatio":594,"labels":595},"An iceberg diagram split by a waterline. Above the waterline, small and clearly visible, sits an invoice icon labeled with the direct, metered costs: compute, storage, data transfer. Below the waterline, a much larger submerged mass carries the indirect costs: staff time, monitoring and cost-management tooling, security and compliance tooling, migration effort, and, on a mirrored on-premises side, power, cooling, and hardware refresh cycles. A footer strip carries the takeaway that TCO counts everything below the waterline too.","4:3",[596,597,598],"Above the waterline: the invoice. Compute, storage, and data transfer, the price everyone sees.","Below the waterline: migration, staff time, monitoring and security tooling, power, cooling, and hardware refresh cycles.","Total cost of ownership counts everything below the waterline too.",[414,415,416,417],{},"/courses/cloud-computing-fundamentals/en/domains/01-cloud-concepts-and-economics/03-cloud-economics/03-total-cost-of-ownership",{"passingScore":117,"questions":603},[604,612,616,624,632,640,648],{"question":605,"type":121,"options":606,"correctAnswer":608,"explanation":611},"What does total cost of ownership (TCO) measure that a monthly cloud invoice does not?",[607,608,609,610],"TCO measures only the compute portion of a bill","TCO measures the complete cost of running a system, including the indirect costs an invoice or hardware quote leaves out","TCO measures only the upfront hardware price","TCO is another name for the on-demand pricing rate","A monthly invoice or a hardware quote each shows one visible price. TCO adds everything around that price, staff time, tooling, migration effort, power and cooling, over a multi-year period, so the comparison reflects the full cost rather than just the part that happens to appear on a single bill.",{"question":613,"type":121,"options":614,"correctAnswer":132,"explanation":615},"37signals' publicly reported cloud repatriation savings, according to independent reporting, fully accounted for hardware refresh costs, new operations staff, and data center power and cooling.",[131,132],"Independent coverage of 37signals' move noted that its published savings figures did not yet include future hardware refresh costs, the new operations roles the move required, or the ongoing cost of running its own data center space. That gap is exactly the kind of incomplete comparison a rigorous TCO analysis is built to catch, even when the company making the comparison is genuinely trying to be transparent.",{"question":617,"type":121,"options":618,"correctAnswer":621,"explanation":623},"A finance team compares 2 options for a workload by looking up this quarter's cloud bill and the sticker price of equivalent server hardware, then picks whichever number is lower. What is the main problem with this comparison?",[619,620,621,622],"It ignores the on-demand discount percentage","It correctly identifies the cheaper option in every case","It leaves out the indirect costs on both sides, staff time, tooling, power and cooling, and migration, that a single invoice or sticker price does not show","Cloud bills and hardware prices cannot be compared to each other at all","Both numbers in this comparison are partial. The cloud bill leaves out the staff and tooling built up around it; the hardware sticker price leaves out power, cooling, and the refresh cycle that arrives again in 3 to 5 years. A real TCO comparison prices every category on both sides over the same window before declaring a winner.",{"question":625,"type":144,"options":626,"correctAnswers":630,"explanation":631},"Which of the following are indirect costs that belong in a cloud TCO calculation, based on this lesson? (Select all that apply.)",[627,628,629,509],"Staff time spent configuring and monitoring cloud resources","The on-demand hourly compute rate itself","Migration and re-architecting work needed to move a workload to the cloud",[627,629,509],"Staff time, migration effort, and the tooling used to watch cloud spend are all indirect costs that sit around the metered bill, not on it. The on-demand hourly rate is the one direct, metered cost in this list, the part of TCO that already shows up on the invoice.",{"question":633,"type":121,"options":634,"correctAnswer":637,"explanation":639},"Using the 3-year worked example in this lesson, what is the main reason the on-premises total ends up lower than the cloud total for that specific workload?",[635,636,637,638],"The cloud path has a larger one-time migration cost than the entire on-premises hardware purchase","On-premises power and cooling costs are cheaper than any cloud data-transfer fee","The workload is steady and predictable, so it gets no benefit from the cloud's ability to scale usage up and down","Cloud providers charge more for storage than for compute in every case","The cloud's cost advantage usually comes from matching spend to a workload that varies. A workload that runs at the same steady size around the clock never uses that flexibility, so it pays the cloud's metered rate every hour without ever getting the payoff that variability would provide, which is what lets the on-premises total come out ahead here.",{"question":641,"type":121,"options":642,"correctAnswer":643,"explanation":647},"A workload that normally runs at a steady baseline spikes to 3 times its usual size for 2 weeks a year. How does this change a TCO comparison between on-premises and cloud?",[643,644,645,646],"It can favor the cloud, since on-premises would need hardware sized for the rare spike, while cloud capacity can scale up temporarily and back down","It does not change anything; TCO comparisons never depend on the shape of a workload","It favors on-premises further, since owned hardware handles spikes better than the cloud does","It eliminates the need to calculate TCO at all","On-premises hardware has to be sized for the worst 2 weeks of the year and then sits underused the rest of the time, exactly the overprovisioning problem from earlier in this domain. Cloud capacity can scale up for those 2 weeks and back down afterward, so a spiky workload often tips a TCO comparison in the cloud's favor even when a steady one does not.",{"question":649,"type":121,"options":650,"correctAnswer":652,"explanation":655},"According to the FinOps Foundation, what is FinOps primarily about?",[651,652,653,654],"Cutting cloud costs to the lowest possible number, regardless of business impact","A cultural practice and operational framework that creates financial accountability and data-driven decisions across engineering, finance, and business teams","A pricing model offered directly by AWS, Azure, and Google Cloud","A once-a-year budgeting exercise kept separate from engineering","FinOps is defined by its own foundation as a cross-team cultural practice, not simply a cost-cutting mandate or a once-a-year budget review. It exists because cloud spending changes every time an engineer provisions a resource, so managing it well requires the same continuous attention as security or reliability, with finance and engineering making decisions together.",{"title":410,"description":411},"courses/cloud-computing-fundamentals/en/domains/01-cloud-concepts-and-economics/03-cloud-economics/03-total-cost-of-ownership","wol5owsWNcpygHYTaqOtd77uM9jYLnRLVOafyyyEKPU"]