Majid Al-RaimiCost case study, NIST definition and deployment models

COE 558Lecture 02Part 06

Cost case study, NIST definition and deployment models

Finishes the traditional IT versus AWS cost comparison, then introduces the NIST definition of cloud computing, its five essential characteristics and the four deployment models.

Concepts
6
Slides
35-44
Reading
36 min
Understood
0/6 concepts

Why this part matters

Part 05 priced owning the infrastructure. This part prices renting it, and then turns a cost table into a decision rule you can defend in an exam and in your research project's deployment choices.

The second half gives the vocabulary every later lecture assumes: the NIST definition of cloud computing, its five essential characteristics and its four deployment models. Exams ask for these lists word for word. More usefully, they are a test you can apply to any design, including an edge deployment, to decide whether it is really a cloud or just servers someone else racked.

By the end you can

  1. Read a cloud bill line by line, convert European number formats, and spot totals that do not match their rows.
  2. Compare on-premise and cloud TCO as cumulative curves, compute the savings percentage and the break-even year, and name the costs the slide model leaves out.
  3. Explain why the provider runs the hardware but the customer still owns availability and lock-in risk, and why on-premise IT survives.
  4. Quote the NIST SP 800-145 definition and apply its five essential characteristics as a test for “is this cloud?”.
  5. Classify a deployment as public, private, hybrid or community by who may use it, and explain why ownership and location do not decide private or community.
  6. Explain cloud bursting as the defining example of a hybrid cloud.

Pricing the same workload as a monthly cloud bill

Take one virtual machine on AWS: an EC2 m2.xlarge instance with a 1 TB SSD block volume, running 24/7. The m2.xlarge is a previous-generation instance with 2 vCPU and 17.1 GiB of memory. Its bill has five lines, and none of them is paid before day one.

Line itemPer monthOne yearThree years
EC2 m2.xlarge + 1 TB SSD EBS1451,7405,398
Data transfer759002,707
Load balancer22264780
Object storage capacity28336991
Object storage requests485761,743
Total as printed3233,87811,619
Sum of the rows3183,81611,619
Cost of one AWS VM running around the clock, in EUR, as on slide 35 with the format converted

Compare that with slide 33. There, 68,824 EUR left the company before a single request was served. Here there is no start column at all. Every euro is Operational expenditure (OpEx), and every line is a resource the provider meters. That gives the general rule for any cloud bill:

Cmonth=∑r∈resourcespr⋅qrCyear=12 Cmonth\begin{gathered} C_{\text{month}} = \sum_{r \in \text{resources}} p_r \cdot q_r \\ C_{\text{year}} = 12\, C_{\text{month}} \end{gathered}
Cloud cost: unit price times metered quantity, summed over every resource you use

This is the NIST characteristic called Measured service, seen from the side of the person paying. Because each line is metered separately, each can be scaled or switched off on its own. You can shrink the instance, move cold files to cheaper object storage, or put a cache in front of the requests, and only that line moves.

How AWS sets these prices

AWS's pricing page names three principles: pay as you go, save when you commit, and pay less by using more. The slide uses plain on-demand prices. AWS's pricing whitepaper (now marked as historical reference) says reservations save up to 75% and Spot capacity up to 90% against on-demand. So the slide's bill is the most expensive way to buy this workload, which matters when you compare it with owning servers. To price a design of your own, use the official AWS Pricing Calculator.

Worked example

Audit the bill

  1. Convert the format

    The slide uses European notation: the dot separates thousands. 5.398 € means 5,398 EUR and 11.619 € means 11,619 EUR, not eleven euros.

  2. Sum the monthly rows

    145 + 75 + 22 + 28 + 48 = 318. The printed total is 323, five euros higher.

  3. Check the yearly column

    Every yearly row is exactly 12 times its monthly row, and they add up to 3,816. The printed total is 3,878, which is close to 12 × 323 = 3,876. The total was most likely computed from the wrong monthly total.

  4. Check the three-year column

    Here the rows do add up to the printed 11,619, but they are not 36 times the monthly values: 36 × 145 = 5,220, not 5,398, and 36 × 22 = 792, not 780. The three-year figures came from a different price estimate.

  5. Result

    Use the printed totals when the lecture builds on them (slide 36 does), but do not expect to reproduce them from the rows. The honest single-VM yearly cost is somewhere between 3,816 and 3,878 EUR.

Recall

Why does slide 35's total not match its rows, and what is the right reading of 11.619 €?

The rows add up to 318 per month and 3,816 per year, but the totals say 323 and 3,878, so the printed totals contain an error. 11.619 € is European formatting for 11,619 euros.

The three-year verdict, and why nobody deletes their own IT

Put the two options side by side. On-premise is a lump of 68,824 EUR at the start, then 6,964 EUR a year. AWS is nothing at the start and 19,364 EUR a year. After three years the slide reports 89,715 EUR against 58,093 EUR.

PeriodTraditional ITAWS
Start68,8240
1st year6,96419,364
2nd year6,96419,364
3rd year6,96419,364
Total after 3 years89,71558,093
Traditional IT vs AWS for the same five-server workload, in EUR (slide 36, format converted)

Where does 19,364 come from? Slide 35 priced one VM at about 3,878 EUR a year, and slide 33 sized the on-premise setup at five servers. 19,364 / 5 ≈ 3,873, so the AWS column is five VMs, one per server. Over three years, 5 × 11,619 = 58,095, within rounding of the printed total.

savings=89715−5809389715=3162289715≈35.2%\begin{aligned} \text{savings} &= \frac{89715-58093}{89715} \\ &= \frac{31622}{89715} \approx 35.2\% \end{aligned}
Three-year saving of AWS over traditional IT. The slide's “more than 35%” is correct

A verdict is a curve, not a number

The 35% depends entirely on stopping the clock at year three. The fair comparison writes both Total cost of ownership (TCO) figures as functions of time. On-premise starts high because of Capital expenditure (CapEx) and grows slowly. The cloud starts at zero and grows fast. Two lines like that must cross.

TCOon(t)=CapEx+t OpExonTCOcloud(t)=t Ccloud\begin{gathered} \text{TCO}_{\text{on}}(t) = \text{CapEx} + t\,\text{OpEx}_{\text{on}} \\ \text{TCO}_{\text{cloud}}(t) = t\,C_{\text{cloud}} \end{gathered}
Cumulative cost after t years for each option
t∗=CapExCcloud−OpExon=6882419364−6964=6882412400≈5.55 years\begin{aligned} t^{*} &= \frac{\text{CapEx}}{C_{\text{cloud}}-\text{OpEx}_{\text{on}}} \\ &= \frac{68824}{19364-6964} \\ &= \frac{68824}{12400} \approx 5.55\ \text{years} \end{aligned}
Break-even: the year when the two cumulative costs are equal
Cumulative cost over seven years: on-premise starts with a CapEx step, AWS starts at zero but climbs faster. They cross near 5.55 years, well past the slide's three-year horizon

Worked example

Find the break-even year

  1. Write both lines

    On-premise: 68,824 + 6,964 t. AWS: 19,364 t.

  2. Set them equal

    68,824 = (19,364 - 6,964) t = 12,400 t, so t* ≈ 5.55 years.

  3. Check on whole years

    YearsOn-premiseAWSCheaper
    389,71658,092AWS
    5103,64496,820AWS
    5.55≈ 107,500≈ 107,500Tie
    6110,608116,184On-premise
    Cumulative cost in EUR at selected horizons

  4. Result

    AWS is cheaper in cumulative cost for the first five years. From year six on, on-premise wins, unless its hardware has to be replaced first. Servers are typically refreshed every three to five years, which resets the on-premise line with a new CapEx step before it ever reaches the crossing.

So the cloud wins when the horizon is short, when demand is uncertain or bursty, and when hardware would be refreshed before t*. Owning wins for steady load run for many years on hardware you keep.

Benefits the table does not price

Slide 37 lists what the money buys beyond the line items. The provider operates the hardware, keeps the infrastructure's Availability and upgrades it. Extra demand is met through Rapid elasticity. Armbrust and colleagues at Berkeley explain why that last point is worth so much. They call it cost associativity: “using 1000 EC2 machines for 1 hour costs the same as using 1 machine for 1000 hours”. They also note that “real world estimates of server utilization in datacenters range from 5% to 20%”, so owned capacity sits mostly idle. Most of all, the cloud removes the up-front commitment: you do not have to guess your peak before you know your users.

Why nobody deletes their own IT

  • Some IT is always local. Laptops, office networks, printers and identity still need someone in the building.
  • Some workloads must stay on premises. Tight latency, data residency rules or regulation can forbid sending data to a remote data center. This is the edge side of the E2C continuum from parts 01 and 02: edge resources sit close to the data source, often on the user's own premises.
  • Lock-in is a real cost. Vendor lock-in grows with every proprietary service you adopt, and leaving later means paying outbound transfer and rewriting code.

Quick check

Using the slide 36 figures and ignoring hardware refresh, after roughly how long does on-premise become cheaper than AWS?

Recall

What is the three-year saving of AWS on slide 36, and why must you always quote it with its horizon?

(89,715 - 58,093) / 89,715 ≈ 35.2%. The two cumulative curves cross at t* ≈ 5.55 years, so the same comparison stopped at year six favours on-premise. The saving is a property of the horizon, not of the cloud.

Recall

What does “the provider is responsible for availability” leave to the customer?

Architecting for availability in the cloud, for example spreading across multiple availability zones. A single EC2 instance has only a 99.5% SLA, while the region-level SLA is 99.99%.

The NIST definition: one sentence, three layers

At 2 a.m. you open the AWS console on your phone, launch a VM, and it is running a minute later. An hour later you delete it and stop paying. Nobody at Amazon was woken up. Every part of that experience appears in one sentence that the whole field uses as its reference.

The NIST cloud definition, published by Mell and Grance as SP 800-145 in September 2011, reads:

Map the 2 a.m. VM onto it. A phone on any network is ubiquitous access. Launching without asking is on-demand. The VM came from a shared pool of hardware. It appeared in a minute and disappeared an hour later: rapidly provisioned and released. No one at the provider was involved: minimal interaction.

The 5-3-4 frame

The definition continues: the cloud model “is composed of five essential characteristics, three service models, and four deployment models”. Slide 38 draws them as three layers.

Deployment models
4

Public, private, hybrid, community

offer
Service models
3

IaaS, PaaS, SaaS

built on
Essential characteristics
5

Resource pooling spanning self-service, network access, elasticity and metering

The NIST frame as three layers: how it is deployed, what is offered, and the properties every cloud must have

Service models are part 07. This part covers the five characteristics and the four deployment models. NIST later built its cloud reference architecture (SP 500-292) on the same definition, so the vocabulary carries through standards, procurement documents and papers.

Recall

Write the NIST definition of cloud computing from memory, then give the 5-3-4 frame.

“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” Then 5 essential characteristics, 3 service models (IaaS, PaaS, SaaS), 4 deployment models (public, private, community, hybrid).

Five essential characteristics: the test for whether something is cloud

Your department has a file server. To get space on it you email IT, wait two days, and receive a fixed quota that never shrinks. It runs on a VM, so it is “virtualized”. Is it a cloud? Test it against the five characteristics and it fails two at once: there is no self-service, and capacity does not grow or shrink with demand. It is virtualized hosting. Now test Google Drive or EC2. They pass all five.

The five characteristics are the test. Slide 39 gives one-line versions. The NIST text is more precise, and the precise words are where the exam marks are.

  1. On-demand self-service. A consumer can provision computing capabilities “unilaterally … as needed automatically without requiring human interaction with each service provider”.
  2. Broad network access. Capabilities are available over the network through “standard mechanisms” usable from “heterogeneous thin or thick client platforms”: phones, tablets, laptops, workstations.
  3. Resource pooling. The provider's resources serve many consumers in a “multi-tenant model”, “dynamically assigned and reassigned according to consumer demand”. The customer does not control the exact location but may specify it “at a higher level of abstraction (e.g., country, state, or datacenter)”. That is why you pick a region but never a rack.
  4. Rapid elasticity. Capabilities scale rapidly “outward and inward commensurate with demand”, and to the consumer they “often appear to be unlimited”.
  5. Measured service. Cloud systems “automatically control and optimize resource use by leveraging a metering capability” suited to the type of service (storage, processing, bandwidth, active user accounts). Usage “can be monitored, controlled, and reported, providing transparency for both the provider and consumer”. NIST adds in a footnote that metering is typically pay-per-use or charge-per-use. The bill in concept one is this characteristic made visible.
Slide 39 draws resource pooling as a band spanning the other four. Here it is drawn as the shared base they all rely on: self-service, network access, elasticity and metering sit on the pool, and elasticity stretches outward and inward
CharacteristicNIST wording (condensed)Everyday exampleWithout it
On-demand self-serviceProvision capability unilaterally, as needed, without human interaction with each providerLaunching a VM from the console at 2 a.m.Every request waits for a ticket and an administrator
Broad network accessAvailable over the network through standard mechanisms, from heterogeneous thin or thick clientsThe same storage from a phone, laptop or script over HTTPSAccess only from one office network or one special client
Resource poolingMulti-tenant pool, resources dynamically assigned and reassigned, location independent at a higher levelYou choose a region, never a rackDedicated boxes per customer, idle most of the time
Rapid elasticityProvisioned and released rapidly, outward and inward with demand, often appearing unlimitedAn auto scaling group adds servers at peak and removes them afterYou buy for the peak and pay for idle capacity all year
Measured serviceAutomatically controls and optimizes resource use through metering, and reports usage transparently to provider and consumerThe line items of the slide 35 billNo pay-per-use, and no data to optimize cost with
The five essential characteristics, what NIST says, and what breaks without each

Quick check

A billing dashboard shows per-hour vCPU charges and per-GB transfer charges for every resource you use. Which essential characteristic does this show most directly?

Recall

Name the five NIST essential characteristics.

On-demand self-service, broad network access, resource pooling, rapid elasticity, measured service.

Deployment models: who may use it and where it lives

Three scenarios. Anyone with a credit card rents EC2 capacity in AWS's Bahrain region. A bank runs OpenStackfor its own business units only, either in its own data hall or in a hall it rents. And a student asks: if Saudi Aramco's internal cloud sits in a colocation facility, does it stop being private?

It does not, and the reason is the whole idea of a deployment model. Slide 40 summarizes it as “where the cloud infrastructure is deployed and who is allowed to use it”. Of those two, who may use it is what decides. NIST deliberately leaves ownership and, for most models, location open.

Public cloud

A Public cloud is provisioned “for open use by the general public”. It “may be owned, managed, and operated by a business, academic, or government organization, or some combination of them”, and it “exists on the premises of the cloud provider”, which means off premises for every user. This is the Hyperscaler world of AWS, Azure and Google Cloud. Armbrust et al. describe it as a cloud “made available in a pay-as-you-go manner to the general public”, and the provider is a Cloud service provider (CSP).

Private cloud

A Private cloud is provisioned “for exclusive use by a single organization comprising multiple consumers (e.g., business units)”. It may be owned, managed and operated by the organization, a third party, or both, and it “may exist on or off premises”. The bank's OpenStack deployment is private whether it runs in the bank's basement or in a rented hall, because only the bank's units can use it. The same goes for the colocated Aramco cloud.

Users across, premises down. Private and community fit both rows. Public appears only off premises, at the provider
ModelWho may use itWho may own and operate itWhere it is located
PublicThe general publicA business, academic or government organization, or a mixOn the provider's premises
PrivateOne organization, with many internal consumersThe organization, a third party, or bothOn or off premises
CommunityA community of organizations with shared concernsMembers, a third party, or bothOn or off premises
HybridWhoever each component cloud servesEach component keeps its own ownerSpans the locations of its components
The four NIST deployment models. Who may use it is the deciding column

Quick check

A university runs OpenStack only for its own departments, on servers housed in a rented colocation facility. Which NIST deployment model is this?

Recall

Does a private cloud have to sit on the organization's premises?

No. NIST says it may be owned or operated by a third party and may exist on or off premises. Exclusive use by one organization is what defines it.

Hybrid and community clouds: composing clouds and sharing one

During Hajj season or Black Friday, an e-commerce site's traffic multiplies for a few days. The company runs its shop on its own private cloud, sized for a normal week. When that capacity hits its peak, the overflow is sent to EC2, and when the rush ends the rented capacity is released. That move has a name: Cloud bursting, and it is the textbook example of a hybrid cloud.

Hybrid cloud

NIST defines a Hybrid cloud as “a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds)”. Two phrases carry the definition. The parts “remain unique entities”: the private cloud does not dissolve into the public one. And they are bound by technology that enables “portability”: the same application and data can run on either side.

The private cloud fills to its peak line, and the overflow bursts along the connector into public cloud capacity, which is released after the peak

AWS describes cloud bursting as “a configuration method that uses cloud computing resources whenever on-premises infrastructure reaches peak capacity”. It also sells the opposite direction: AWS Outposts brings “AWS infrastructure and services to virtually any on-premises or edge location for a truly consistent hybrid experience”, aimed at low latency, local data processing and data residency. Those are exactly the reasons the previous concept gave for keeping IT on premises, which is why hybrid designs show up all along the E2C continuum.

Community cloud

A Community cloud is provisioned “for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations)”. Like a private cloud, it may be owned and operated by community members, a third party, or both, and it may exist on or off premises.

AWS GovCloud (US) is a working example. It is offered to “verified U.S. government agencies and entities”, in “physically and logically isolated U.S. sovereign regions … operated by U.S. citizens on U.S. soil”. The agencies share it because they share the same compliance regime (FedRAMP High, ITAR), which is precisely NIST's “shared concerns”. NIST SP 800-146 discusses the trade-offs of each deployment model in more depth.

Quick check

Several hospitals jointly operate a cloud reserved for their patient-record workloads under the same health regulations. Which deployment model fits best?

Recall

What two properties make a composition of clouds “hybrid” under NIST?

The clouds remain unique entities, and they are bound by standardized or proprietary technology that enables data and application portability, for example cloud bursting.

Recap

If you remember nothing else

  • A cloud bill is pure OpEx: unit price times metered quantity, line by line. The VM line (instance plus disk) was under half of the slide 35 bill.
  • Slide 36: 89,715 EUR on-premise vs 58,093 EUR on AWS over three years, a saving of about 35.2%.
  • TCO is a curve, not a number: break-even t* = CapEx / (cloud per year - on-premise OpEx per year) ≈ 5.55 years here.
  • Unpriced cloud benefits are provider-run hardware, upgrades and elasticity. Availability above the infrastructure is still the customer's design job.
  • Keep some traditional IT: latency, residency, regulation and vendor lock-in.
  • NIST SP 800-145 has 5 essential characteristics, 3 service models and 4 deployment models.
  • The five characteristics are on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service.
  • The deployment model is about who may use the infrastructure: anyone (public), one organization (private), organizations with shared concerns (community), or a composition (hybrid).
  • Private and community clouds may sit on or off premises. A public cloud sits on the provider's premises.
  • Hybrid clouds remain distinct units bound by portability technology. Cloud bursting is the canonical example.

Sources