Cost management and the shared responsibility model

Two questions decide whether a move to the cloud is a success: who is responsible for what, and what does it really cost? Both are easy to get wrong. Organizations that assume the provider handles everything leave data exposed; organizations that treat the cloud like a fixed-price utility get a shock when the bill arrives. Anita, Ridgeline's bookkeeper, will see the cloud bill every month, and Rosa has made it clear that the wholesale site must not cost more than the old phone and email ordering system wastes in Theo's time. This lesson covers the shared responsibility model and the practice of managing cloud costs, which the industry calls FinOps.

The shared responsibility model

Every major provider publishes a shared responsibility model that divides security and operational duties between the provider and the customer. AWS summarizes it neatly: the provider is responsible for security of the cloud, and the customer is responsible for security in the cloud. Microsoft and Google publish the same idea with their own diagrams.

Security of the cloud means the physical data centres, the hardware, the network that connects them, the hypervisors and the software that runs the managed services. Customers cannot inspect or change these, so they must trust the provider and check its independent audit reports. Security in the cloud means everything the customer controls: its data, its identities and permissions, the configuration of its services, the operating systems and applications it runs on IaaS, the network rules it writes, and its encryption and backup choices.

As lesson 2 showed, where the line falls depends on the service model. With IaaS, the customer is responsible for patching the guest operating system and everything above it. With PaaS, the provider patches the operating system and runtime, and the customer secures its code, data and access. With SaaS, the customer mostly manages users, settings and data. Some duties are always the customer's: data classification and protection, identities and access, and the configuration of whatever services it uses. Some are always the provider's: the physical facilities and hardware.

Because customers cannot audit the provider's data centres themselves, providers hire independent auditors and publish the results. Common reports and certifications include SOC 1 and SOC 2 reports, ISO/IEC 27001 for information security management, PCI DSS for card payment data, and government programs such as FedRAMP in the United States and the Government of Canada's assessments for Protected B workloads. The reports are available to customers through portals such as AWS Artifact, the Microsoft Service Trust Portal and Google's compliance reports manager. A provider's certification covers its share of the model only: a PCI DSS-compliant provider does not make a customer's payment application compliant.

The practical lesson is that most cloud security failures happen on the customer's side of the line. Industry research consistently finds that misconfiguration and stolen credentials, not provider failures, cause the large majority of cloud breaches. Turning on MFA, keeping buckets private, writing narrow firewall rules and patching what you own are therefore the highest-value security work a small cloud customer can do.

RESP = {
    "physical security": ("provider", "provider", "provider"),
    "hypervisor": ("provider", "provider", "provider"),
    "os patching": ("customer", "provider", "provider"),
    "application code": ("customer", "customer", "provider"),
    "network rules": ("customer", "shared", "provider"),
    "identities": ("customer", "customer", "customer"),
    "data": ("customer", "customer", "customer"),
}
MODELS = ["IaaS", "PaaS", "SaaS"]

def responsible(duty, model):
    return "provider"

def customer_duties(model):
    return []

print(responsible("os patching", "PaaS"), customer_duties("SaaS"))

What drives a cloud bill

Cloud bills are long and detailed, often with hundreds of line items, but most of the money usually goes on a few things. Compute is billed per second or hour for virtual machines and containers, per request and gigabyte-second for functions. Storage is billed per gigabyte per month, by tier, plus charges for operations such as reads and writes. Databases combine compute and storage charges, with extra for standby copies and backups beyond the free amount. Networking has the charges that surprise people most.

Data transfer pricing is asymmetric. Data coming into the cloud from the internet, called ingress, is usually free. Data going out to the internet, called egress, is charged per gigabyte. Data moving between availability zones and between regions is often charged too, and NAT gateways charge per gigabyte processed. A site that serves large files to many users, or a design that copies data back and forth between zones, can rack up network charges that dwarf its compute bill. Serving files through a CDN usually reduces egress cost as well as speeding up delivery.

Finally, there is waste: resources that are running but not needed. The classic examples are test servers left running over weekends and holidays, disks left behind after their virtual machines were deleted, snapshots kept forever, oversized instances that never use more than a fraction of their processor, and idle load balancers and NAT gateways. Industry surveys regularly estimate that a quarter or more of cloud spending is wasted in these ways.

Canadian customers should also check the currency. Some providers bill Canadian accounts in US dollars by default, so exchange rate changes alter the bill even when usage does not; others let customers pay in Canadian dollars. Bills should show GST or HST, and PST where it applies, and Anita needs invoices that show the provider's Canadian tax registration so Ridgeline can claim input tax credits.

# Estimate one month of the wholesale site (illustrative prices, in dollars)
usage = {
    "containers":        {"qty": 2 * 730 * 0.5,  "unit": "vCPU-hours",   "price": 0.045},
    "database":          {"qty": 730,            "unit": "hours",        "price": 0.034},
    "database standby":  {"qty": 730,            "unit": "hours",        "price": 0.034},
    "object storage":    {"qty": 40,             "unit": "GB-months",    "price": 0.023},
    "egress to internet":{"qty": 60,             "unit": "GB",           "price": 0.09},
    "NAT gateway":       {"qty": 730,            "unit": "hours",        "price": 0.045},
}
total = 0
for item, u in usage.items():
    cost = u["qty"] * u["price"]
    total += cost
    print(f"{item:<20} {u['qty']:>8.0f} {u['unit']:<11} {cost:>7.2f}")
print(f"{'Total':<41}{total:>7.2f}")

containers                730 vCPU-hours    32.85
database                  730 hours         24.82
database standby          730 hours         24.82
object storage             40 GB-months      0.92
egress to internet         60 GB             5.40
NAT gateway               730 hours         32.85
Total                                     121.66

Look at the NAT gateway. It costs more each month than the object storage and egress together, simply by existing. When Sam saw this estimate, he moved the database and storage connections to private endpoints and removed the NAT gateway from the design, because the containers did not need general internet access. That kind of saving, found on paper before anything is built, is exactly what cost estimation is for. Every provider offers a free pricing calculator: the AWS Pricing Calculator, the Azure pricing calculator and the Google Cloud Pricing Calculator.

items = [
    {"name": "compute", "qty": 730, "price": 0.034},
    {"name": "storage", "qty": 40, "price": 0.023, "free": 5},
    {"name": "egress", "qty": 160, "price": 0.09, "free": 100},
    {"name": "nat", "qty": 730, "price": 0.045},
]

def monthly_bill(items):
    return 0.0

def biggest(items):
    return None

print(monthly_bill(items), biggest(items))

FinOps: managing cloud spending

FinOps, short for cloud financial operations, is the practice of bringing finance, technology and business people together to manage cloud spending. The FinOps Foundation, part of the Linux Foundation, describes it as three repeating phases. Inform: make costs visible, so everyone can see who is spending what and why. Optimize: find and act on savings, such as rightsizing, removing waste and buying commitments. Operate: build cost awareness into everyday decisions, with budgets, policies and regular reviews.

Visibility starts with tags, which lesson 11 returns to. A tag is a label attached to a resource, such as project equals wholesale or environment equals test. Bills and cost reports can then be broken down by tag, so Anita can see exactly what the wholesale site costs, separately from the roast logger. Untagged resources are the usual source of mystery charges, so mature organizations require tags on every resource and use automated checks to find those missing them.

Budgets and alerts are the safety net. All three providers let you set a monthly budget, AWS Budgets, Azure cost management budgets and Google Cloud budgets, and receive an email when actual or forecast spending crosses thresholds, such as half, most and all of the budget. A forecast alert is especially useful, because it warns in the middle of the month that the bill is heading over the limit, while there is still time to act. Budgets normally only alert; they do not stop spending unless you connect them to automated actions. Sam set Ridgeline's budget at 150 dollars a month with alerts to Anita and himself.

def forecast(spent, day, days_in_month):
    return spent

def alerts(spent, day, days_in_month, budget, thresholds):
    return []

print(forecast(60, 10, 30), alerts(60, 10, 30, 150, [0.5, 0.9, 1.0]))

Ways to save

The main levers for saving money are well known, and most organizations get the biggest wins from the simplest ones.

Scheduling deserves a quick calculation, because it surprises people. A test environment needed only from eight in the morning to six in the evening on weekdays runs 50 hours a week instead of 168, under a third of the time, so stopping it outside those hours removes more than two thirds of its compute cost. The providers offer scheduling tools, and a short serverless function on a timer can do the job too.