Buying cloud services: ask what you can change without a support ticket

Before buying a service labelled cloud, ask what your team can change without opening a support ticket. A useful starting point remains NIST's 2011 definition, by Peter Mell and Timothy Grance: examine the service's behaviour, not simply where equipment sits. This is a guide to checking a service, not a new cloud standard or product launch.

Three things to know

• NIST identifies five cloud characteristics, including self-service, elasticity and metering; a facility address does not describe them.
• Usage measurement does not guarantee a particular tariff or savings.
• The service model changes what your team controls, so name that boundary before comparing offers.

Start with who can make a change

In SP800-145, on-demand self-service means a consumer can provision capabilities automatically without a fresh human interaction with each provider. Broad network access means standard access mechanisms serving different client platforms. Neither phrase answers every practical question about permissions. Ask which authorised person can create a resource, from which equipment, and what still needs a manual request.

Imagine a Lagos design studio preparing a temporary project workspace with a London collaborator. This is a hypothetical example, not a customer story. In a proposed walkthrough, one person requests an agreed non-confidential sample resource while another follows the documented access route. Record who can perform each step. A sales demonstration using an administrator's privileges may leave the ordinary team's workflow unanswered.

A shared pool is not a promise of endless capacity

Resource pooling describes the provider assigning and reassigning resources across consumers. Rapid elasticity concerns expanding and releasing capacity with demand, automatically in some cases. Translate those ideas into a specific question: what can this account increase, and how does it reduce that allocation afterwards? Request the applicable limits and approval steps. Do not turn capacity that appears abundant into a promise that any quantity is always available.

NIST also distinguishes deployment arrangements. A private cloud can be on or off premises; the word private alone does not identify a country or building. For the hypothetical studio, name the proposed location separately from who operates the service. That is a scope question, not a legal conclusion about where its files must be kept.

Separate the usage report from the price

Measured service concerns metering and reporting resource use. NIST's footnote describes pay-per-use charging as typical, not an unconditional rule. Ask for a sample usage report and the quotation that prices it. Which unit is counted, who can see the report and what happens after the temporary workspace is removed? A report can clarify consumption without establishing that the entire arrangement is cheaper.

Name what you will operate

The same document separates using a provider's application, deploying an application on its platform and provisioning infrastructure. Its IaaS model gives the consumer control over operating systems and applications, not the underlying cloud infrastructure. That distinction changes the conversation from an attractive feature list to an ownership question: which configuration and maintenance tasks will this team actually perform? Obtain a written division of responsibilities rather than infer one from the word managed.

Keep the walkthrough small and authorised, using non-confidential material and no unapproved paid resources. Write down the requested action, observed response and remaining question. PING has not performed it. For readers in Nigeria or the UK, NIST supplies comparison language, not a provider audit or service-availability guarantee. Find more documented explainers on PING's Networks desk.