PE2-6.4 Resource Management & Cloud Security
Standard cloud computing concepts — written September 2026
What this is and why it exists
Resource management is where the provider's economics and your bill meet. Both sides are solving the same problem from opposite directions.
Over-provision and you pay for capacity that sits idle. Under-provision and you fail under load. Elasticity is the promise that you should not have to choose, and this topic is what stands behind that promise.
The vocabulary
- Provisioning — obtaining capacity before it is needed.
- Over-provisioning — holding more capacity than demand requires.
- Under-provisioning — holding less, and failing when demand exceeds it.
- Scheduling — deciding which workload runs on which machine.
- Consolidation — packing workloads onto fewer machines to raise utilisation.
- Green computing — treating energy as a design constraint.
- Denial of service — an attack that exhausts capacity so real users cannot be served.
- Encryption at rest — data stored encrypted.
- Encryption in transit — data encrypted while moving over a network.
- Key management — how encryption keys are created, stored and rotated.
- Tenant isolation — keeping one customer's workload away from another's.
The mental model
Provisioning is the whole design problem in two sentences. Capacity obtained in advance costs money whether or not it is used. Capacity not obtained means requests are lost when demand arrives. The strategies available are to provision for the peak, provision for the average and accept failures, or provision dynamically and accept that scaling takes time.
Scheduling is the allocation decision underneath. Packing workloads tightly onto fewer machines raises utilisation and saves money. It also puts more tenants on each machine, which reduces isolation and makes one noisy workload another's problem. That trade between efficiency and separation runs through the whole topic.
Green computing is not decoration in this context. Data centre electricity is a first-order cost, large enough to change design decisions on its own. Consolidating workloads, switching off idle machines, and placing data centres where cooling is cheap are all commercial arguments as well as environmental ones. When the two align, the efficiency actually happens.
The vocabulary for managing across more than one provider appears here too. The naming follows the same pattern as the service models, describing hardware, infrastructure and networking each offered as a service. Recognising those terms keeps older material readable, which is their main value.
Now security, and the useful framing is what changes here rather than what security is in general.
The firewall is the oldest control there is, and what changes is where the boundary sits. A traditional network has an inside and an outside with a wall between. Here there is no single perimeter. Machines appear and disappear, and the boundary has to be described in rules attached to workloads rather than drawn around a building.
Denial of service takes a form specific to this environment. In a traditional data centre, an attack exhausting your capacity makes the service unavailable. Here, elasticity means the service may instead scale up to meet the attack, and stay available, and bill you for all of it. Availability is preserved and the damage arrives as an invoice. That failure mode exists only where capacity is elastic and metered.
Data security has a baseline everyone states and a hard part everyone underestimates. The baseline is encryption at rest and in transit. The hard part is key management. Encrypted data with the key stored beside it is not protected. A key that cannot be rotated or revoked leaves you unable to respond to a compromise. It is almost always key management that fails, not the encryption.
Application security is largely unchanged from anywhere else, with one addition. The application's credentials for other services are now valuable in a way they were not on a private network.
Virtual machine security closes the topic on the risk unique to shared infrastructure. The entire model assumes one tenant cannot reach another. That assumption is enforced by the hypervisor, which is software, and software has bugs. An escape from one virtual machine into another, or into the host, breaks the assumption everything else stands on. It is rare, it is taken extremely seriously, and it is the reason some regulated workloads pay for dedicated hardware.
What you should now be able to explain or do
State the provisioning problem and the three strategies available. Explain the trade between packing workloads tightly and keeping tenants isolated. Give both the commercial and the environmental argument for efficiency. Explain how a denial of service attack differs when capacity is elastic and metered. Say why key management fails more often than encryption, and what a hypervisor escape would break.
Check yourself
What is the provisioning problem?
Capacity bought early costs money while idle, and capacity not bought loses requests under load. Every strategy trades one against the other.
What does packing workloads tightly cost?
Isolation. More tenants per machine means one heavy workload can affect its neighbours' performance.
How does a denial of service attack differ on elastic infrastructure?
The service may scale to meet it and stay available. The damage arrives as a bill for the capacity the attack consumed.
Why does key management fail more often than encryption?
Encryption algorithms are sound. Keys stored beside the data, or unable to be rotated, remove the protection without breaking the algorithm.
What would a hypervisor escape break?
Tenant isolation, which the entire shared model assumes. One customer could reach another's workload or the host itself.
Go deeper
We haven't checked most of these for screen reader use yet.
Back to Resource Management & Cloud Security: work through the checklist