Cloud economics: licensing models, rightsizing and what automation saves

Why this matters

Lesson 4 showed that the cloud turns fixed costs into variable ones. This lesson is about the three levers that decide how large those variable costs turn out to be. The first is software licensing. Many companies have already paid for licences for Windows Server, databases or business software, and a migration plan that ignores them can mean paying for the same licence twice, or breaking the terms of an agreement nobody on the project has read.

The second lever is rightsizing. Servers bought for an on-premises data centre were sized generously, because adding capacity later meant another purchase. When those servers move to AWS at the same size, the company pays every hour for headroom it does not use. Choosing the right size is often the quickest saving in a cloud bill, and it is a conversation a manager or a finance lead can start with a single question: how busy are these machines?

The third lever is automation. People building environments by hand make mistakes, forget to turn things off and patch inconsistently. Automation fixes all three, and it is a large part of why the cloud is cheaper to operate as well as to buy. Knowing what automation does and does not change is exactly the sort of distinction a scenario question tests.

The lesson

Licensing strategies: Bring Your Own License (BYOL) and licence-included pricing

A software licence is the legal right to run a piece of software, on terms the vendor sets. Commercial operating systems and databases are licensed in many ways: per server, per user, per virtual machine, or per physical processor socket or core. On AWS there are two broad ways to cover a licence.

License-included (AWS's term) means the licence cost is built into the price of the AWS resource. The clearest example is a Windows Server instance on Amazon EC2: AWS supplies the Windows Server licence, and its cost is part of the instance price. The company buys nothing in advance and has no licences to track. When the instance stops, the licence cost stops with it. Amazon RDS also offers license-included pricing for some commercial database engines. This option suits a company that has no existing licences, wants flexibility, or does not want the administrative work of licence tracking.

Bring Your Own License (BYOL) means the company uses licences it already owns on AWS, so it pays AWS only for the infrastructure. This avoids paying for the same licence twice, which is the main reason to choose it. Two conditions come with it.

• The vendor's terms decide. Whether a licence can move to the cloud, and on what kind of hardware, is set by the software vendor's agreement, not by AWS.
• The company stays responsible for compliance. AWS does not become responsible for whether the company uses its licences within their terms. That duty stays with the licence holder.

Some licences are priced by the number of physical sockets or cores in a server. On-Demand and Spot Instances run on shared hardware by default and hide those physical details, so they do not give such a licence the information it depends on. Amazon EC2 Dedicated Hosts are physical servers dedicated to one customer, with visibility of the sockets and cores, which is what makes per-socket and per-core BYOL possible. Dedicated Hosts and the other purchasing options are covered in lesson 23.

AWS License Manager helps a company that uses BYOL. It tracks licence use across many AWS accounts and on-premises servers, and its licence rules can warn about, or prevent, use beyond the agreed terms. Do not confuse it with AWS Service Catalog, which controls which approved products teams may launch, or with AWS Artifact, which provides compliance reports and agreements, not licence files.

The comparison in one sentence: license-included puts the licence in the price and needs no licences of your own; BYOL reuses licences you own and keeps the compliance work with you.

Understanding the concept of rightsizing

Rightsizing is matching each resource's type and size to what its workload actually needs, at the lowest cost that still meets the performance requirement. For EC2, that means choosing the instance type (the family, such as general purpose, compute optimised or memory optimised) and the size within that family (how much CPU and memory it has).

Most rightsizing moves an over-provisioned instance to a smaller size. If Amazon CloudWatch shows an instance's CPU and memory use have stayed very low for months, moving it to a smaller instance type keeps the workload running at a lower cost. Sometimes the right move is to a different family, for example a memory-heavy workload on a general purpose instance. Occasionally it is a larger size, where a struggling instance is hurting performance. Rightsizing aims for the right fit, not the smallest fit.

Several services help:

• Amazon CloudWatch collects the utilisation metrics. It shows the evidence, but it does not itself recommend an instance type.
• AWS Compute Optimizer applies machine learning to historical utilisation metrics and recommends instance types and sizes that cut cost or improve performance.
• AWS Cost Explorer offers rightsizing recommendations alongside its view of spending, and AWS Trusted Advisor flags instances with low utilisation as part of its cost optimisation checks.

Three points about rightsizing are worth fixing in memory.

• Rightsizing is not scaling. Adding instances as demand grows changes how many instances run. Rightsizing changes whether each one is the right size. A question that describes adding or removing instances with demand is about scaling.
• Rightsize before you commit. A company planning to buy Savings Plans or Reserved Instances should rightsize first, so the commitment is based on what the workloads really use. Buying a commitment at the current oversized level locks in spending on capacity nobody needs.
• Rightsizing is ongoing. Demand, features and usage patterns change, so an instance that fitted last quarter can become oversized or undersized. AWS also releases new instance types. Rightsizing works best as a regular review, not a single exercise at migration time.

Identifying benefits of automation

Automation means letting software carry out tasks that people would otherwise do by hand: building environments, adjusting capacity, starting and stopping resources, and applying patches. Its benefits fall into three groups.

Consistency and fewer errors. When a company builds each environment by hand, no two come out exactly the same, and small differences cause failures that are hard to trace. Infrastructure as code (IaC) describes resources in template files instead. AWS CloudFormation is AWS's IaC service: it provisions resources from a template, so every environment is built the same way each time, faster and with fewer manual mistakes. Because the templates are text files, they can be stored in version control, reviewed before a change and rolled back. An environment that is lost or needed in a second place can be rebuilt quickly. Lesson 12 returns to IaC as a way of provisioning AWS.

Lower cost. Automation cuts waste that people leave behind.

• AWS Auto Scaling adjusts capacity to track demand, adding resources as load rises and removing them as it falls, so the company runs what the current load needs instead of paying for peak capacity all the time. Lesson 14 covers it with EC2.
• Scheduled stopping. Development instances that run around the clock, while developers work only office hours, can be stopped automatically outside working hours. The company stops paying for compute time nobody uses, without relying on anyone to remember. Reserved Instances would be the wrong answer here, because they suit steady workloads that run all the time and would commit the company to paying for the idle hours.

Speed and scale for operations. AWS Systems Manager can automate operating system patching across a fleet of EC2 instances on a schedule. Patching becomes consistent at scale, with far less manual work and fewer missed servers.

Now the limits, because distractors are built from them.

• Automation changes how a task is done, not who is responsible for it. If a company uses Systems Manager to patch its EC2 instances, guest operating system patching remains the company's responsibility under the shared responsibility model (lesson 6). The tool helps; the duty stays.
• Automation does not change prices. CloudFormation does not make the resources it creates cheaper, and Auto Scaling does not turn On-Demand Instances into Reserved Instances. They save money by changing what runs and for how long, not what each hour costs.
• Automation does not remove the need for security or testing. Resources built from a template still need security controls, and automated patches still need a sensible testing process.

What the exam is really asking

Scenario questions on these topics usually rest on one detail. "Already owns licences" points to BYOL; "without buying or tracking licences" points to license-included. "Licensed per socket or core" points to Dedicated Hosts, and "track licence use across accounts" to AWS License Manager. "Low utilisation for months" means rightsize down, and "machine learning recommendations" means AWS Compute Optimizer. "No two environments are the same" points to CloudFormation and infrastructure as code. And whenever an option claims that automation moves responsibility to AWS or lowers the price of a resource, it is the distractor.