Provisioning compute and storage

Why this matters

Provisioning is the everyday work of the job, and CompTIA's bullet asks for it to be done effectively — which means repeatably, correctly sized, and configured at creation rather than patched up afterwards.

The recurring theme of this lesson is that several important properties are fixed at creation. Storage type, encryption on some platforms, placement, and the image a machine was built from are all much harder to change later than to get right now. Knowing which decisions are one-way doors is most of doing this well.

The lesson

Instance provisioning: image, size, placement, and the metadata that configures it on boot

Creating an instance is four decisions and one mechanism.

Image. The starting filesystem: a provider-supplied base, a marketplace image, or your own. Custom images are the usual answer for anything deployed repeatedly, because baking the agents, hardening and dependencies in produces a faster, more consistent launch than configuring each machine afterwards. The maintenance cost is that images go stale and need rebuilding on a schedule — an image pipeline, which is where objective 5.3 meets this one.

Size. The family and size from objective 1.2, chosen on the measurements from objective 2.1. Remember that size also caps network and storage throughput.

Placement. Region and availability zone. Region is chosen on latency to users, data residency, service availability and price — they differ. Zone matters because a subnet belongs to one, and anything resilient needs to be spread across several. Placement groups can additionally request that instances be packed close together for low latency, or spread apart so a single hardware failure cannot take them all.

Metadata / user data. A script or configuration document passed at launch and executed by the instance on first boot. This is how an instance configures itself — joins a cluster, installs an agent, pulls its configuration, registers with the load balancer.

Two rules about user data that are both examinable and practical:

• It is readable from inside the instance, through the metadata service, by any process running there. Never put secrets in it. Fetch secrets at boot from a secret store, using the instance's own identity (next lesson).
• Keep it short. A long bootstrap script is a fragile, untested deployment system. Use it to pull a proper configuration mechanism, not to be one.

Block, file and object storage, and the workload each one is shaped for

Three storage types, and picking the wrong one is a design error that is expensive to reverse.

Block. A raw volume attached to one instance, formatted with a filesystem. Lowest latency, and the only sensible choice for boot disks and databases. Normally attached to a single instance at a time — multi-attach exists and requires a cluster-aware filesystem, which is a specialist answer rather than a convenience.

File. A shared filesystem accessed over a network protocol (NFS, SMB), mountable by many instances simultaneously. The answer when several machines need the same files with filesystem semantics — shared application content, home directories, a lift-and-shifted application expecting a file share. More expensive per gigabyte than object storage, and slower than block.

Object. Data stored as objects with metadata in a flat namespace, accessed over HTTP. Effectively unlimited, cheapest, highly durable, and accessible from anywhere with credentials. It is not a filesystem: objects are replaced rather than edited in place, there are no real directories, and listing is a different operation from reading. Right for backups, media, logs, data lakes, static content and archives. Wrong for a database's data files or anything needing partial updates or low-latency random access.

The decision test: one instance, low latency → block. Many instances, filesystem semantics → file. Anything large, immutable or internet-reachable → object. A scenario describing "several web servers must serve the same uploaded files" is describing file storage or object storage, and almost never block.

Storage classes and performance tiers chosen at creation, not discovered later

Within each type, providers offer tiers.

Block volume types differ on the performance model:

• General-purpose SSD — baseline performance often scaling with size, often with burst credits. The default, and the source of the "fast then slow" behaviour from objective 1.2.
• Provisioned IOPS SSD — performance you specify and pay for, independent of size and without bursting. The correct answer for production databases and anything with a sustained requirement.
• Throughput-optimised HDD — cheap, sequential throughput, poor at random access. Big sequential workloads and logs.
• Cold HDD — cheapest, infrequent access.

Object storage classes trade storage price against retrieval cost and retrieval time, as covered in objective 1.7. The lifecycle rules there are the right mechanism; choosing the class thoughtfully at upload is the other half.

What makes this a provisioning lesson rather than an optimisation one is that some of these are awkward or impossible to change in place. Changing a volume type may be online on one platform and require a snapshot-and-restore on another. Encryption is frequently settable only at creation — turning it on later means creating a new encrypted volume and copying, with downtime. Similarly, a bucket's region and often its name are fixed forever.

So the rule is: decide encryption, type and placement at creation. The platform defaults are chosen for convenience and low cost, not for your requirements.

Auto-scaling groups and launch templates as the provisioned unit, rather than a server

The modern unit of provisioning is not a machine, and this shift is worth stating plainly because it changes several answers.

A launch template captures everything about how to create an instance: image, size, network configuration, storage, identity, user data, tags. An auto-scaling group uses that template to maintain a number of instances across zones, replacing any that fail health checks.

What this gives you, beyond scaling:

• Self-healing. An instance that fails a health check is terminated and replaced, without a human.
• Zone resilience, by spreading instances across zones automatically.
• Consistency. Every instance comes from the same template, so they do not drift apart the way hand-built machines do.
• Rolling replacement as the update mechanism — change the template, replace instances gradually (objective 3.1).

The mental shift is to stop treating an instance as a thing with an identity and start treating it as a replaceable member of a group. The practical consequences:

• Do not configure an instance by hand. It will be replaced and the change will vanish — the same lesson as drift, one layer down.
• Do not store state on it.
• Version the template. A group should reference a specific version so a change is deliberate rather than picked up at the next scaling event.
• Health checks must reflect the application, not just whether the machine is powered on. An instance whose application has crashed but whose operating system is fine will pass an infrastructure health check forever.

Quotas and service limits, and the deployment that fails at scale because of one

Every provider limits how much of each resource an account may create — a number of instances of a type, addresses, volumes, requests per second against an API.

Quotas exist for the provider's capacity management and for your protection, and they are the only real defence against a runaway spend (objective 1.8). They are also a recurring cause of deployments that fail in a confusing way.

What makes them hard to diagnose:

• They are per-region and often per-instance-type. A deployment that works in one region fails in another with the same code.
• They fail at the worst moment. A scaling event during a traffic peak hits the instance limit, and the group simply cannot add capacity. The application degrades and nothing is technically broken.
• The error message is often indirect — a generic capacity or authorisation failure rather than a clear statement that a quota was reached.
• Some are soft (raisable by request, taking hours or days) and some are hard. Knowing which is which is part of planning.
• Deleted resources sometimes count until they are fully released.

The discipline is to check the relevant quotas against the intended scale during planning, request increases in advance with lead time, and monitor usage against limits as a routine metric rather than discovering the ceiling by hitting it. A scenario in which an autoscaling group refuses to grow during a peak, with no error in the application, is describing this.

What to take into the exam

• User data is readable from inside the instance. Never put secrets in it; fetch them at boot using the instance's identity.
• Block = one instance, low latency. File = many instances, filesystem semantics. Object = large, immutable, HTTP-accessible — and it is not a filesystem.
• Encryption, volume type, region and placement are creation-time decisions and are painful to change afterwards.
• Provisioned IOPS for sustained database performance; general-purpose volumes burst and then fall to baseline.
• The provisioned unit is the launch template plus scaling group, not a server. Never hand-configure a group member; health checks must test the application.
• Quotas are per-region and per-type, fail at peak, and report indirectly. Check and raise them during planning.