Cloud Questions to Ask
For anyone comparing cloud providers, sitting through a vendor pitch, or trying to work out what their organization already pays for. Twenty questions on pricing units and the lines on the bill, uptime commitments and remedies, certifications and the shared responsibility line, where data physically sits, what support looks like at 2am, and the cost of leaving.
The questions
Open any question for the note
Which of your services would we actually be running, and what does each line on the bill represent?
Why ask it
A cloud invoice is dozens of separate meters, not one product. Ask for the specific services a workload like yours would use. A proposal that quotes a single blended monthly figure is usually leaving out storage, data transfer and support, and those are the lines that grow.
How is this priced: per hour, per request, per gigabyte stored, or per gigabyte sent out?
Why ask it
The unit matters more than the rate. Per-request pricing punishes chatty applications, per-gigabyte-out punishes anything serving media or feeding an external analytics tool. Work out which unit your usage is heaviest in before comparing headline numbers.
What is included in the base price, and what gets billed separately?
Why ask it
Support plans, backups, cross-zone traffic, log retention, static addresses and managed load balancing are all commonly extra. Get the list of exclusions in writing, because two quotes are not comparable until you know which one bundled them.
What would our bill look like at three times our current volume?
Why ask it
Shows whether pricing is linear and where the tier boundaries sit. A provider who happily models growth has volume discounts to offer; one who avoids the question is relying on you not doing the multiplication yourself.
What discounts are available, and what do we commit to in return?
Why ask it
Reserved capacity and committed-spend agreements can cut a bill substantially in exchange for a one to three-year term and a fixed shape of usage. The question that matters is what happens if you shrink or change architecture halfway through.
How does this compare with what we spend on our own hardware today, using our numbers rather than yours?
Why ask it
Vendor comparisons tend to assume expensive on-premises staffing and cheap cloud operations. Insist on your own invoices, your own refresh cycle and your own utilization figures. If a model only works at assumptions you cannot recognize, it is a sales tool.
What uptime do you commit to in the contract, and what do we get when you miss it?
Why ask it
Marketing availability and contractual availability are different numbers. Read how downtime is defined, what maintenance is excluded, and who has to prove an outage. Remedies are usually service credits worth a fraction of one month, never lost revenue.
Which of our data would sit in which region, and can we pin it there?
Why ask it
Ask specifically about backups, replicas, logs and support staff access, since those often live outside the region the primary service runs in. A provider that cannot name regions per service cannot help you answer a regulator's question later.
Which certifications do you hold, and can we see the current audit report?
Why ask it
A logo on a web page is not evidence. Ask for the dated report and check what was in scope: certifications frequently cover named services in named regions, not the whole platform, and the service you want may sit outside the boundary.
Where does your responsibility end and ours begin?
Why ask it
Providers secure the platform; customers configure access, encryption, patching inside instances and public exposure. Most publicized cloud breaches sit on the customer side of that line. Ask for the split in writing, service by service.
What do you back up by default, and what would we have to set up ourselves?
Why ask it
Replication is not backup: it copies deletions faithfully. Ask what is retained, for how long, whether backups sit outside the primary region, and who can delete them. A single compromised administrator account is the scenario that matters here.
If an entire region goes down, what happens to our service, and what would we have to do?
Why ask it
Most services are only resilient within a region unless you pay for more. Ask what fails over automatically, what needs a human, and how long a full regional recovery has taken in the past. The answer determines your architecture, not just your risk register.
What support is included, and what does a response actually look like at 2am on a Sunday?
Why ask it
Compare first-response targets, whether they apply to weekends, and whether the first responder can do anything beyond opening a ticket. Ask what it costs to reach an engineer who can look at your account, because that is often a separate tier.
Who would our named contact be after the contract is signed?
Why ask it
Pre-sales attention rarely survives signature. Ask who owns the relationship in month six, how escalation works when that person is on leave, and whether the technical staff in this meeting will be available afterwards or were borrowed for the pitch.
How do your monitoring and cost reporting tools work, and can we export the raw data?
Why ask it
You want usage detail at resource level, with tags, exportable somewhere you control. Dashboards that only show pretty rollups make it impossible to trace a doubled bill to the team that caused it, which is where most cost arguments start.
How would this connect to the systems we are keeping in our own building?
Why ask it
Get concrete about the link: private circuit or internet, who provides it, what it costs, what latency to expect, and what happens when it drops. Hybrid setups fail at this seam, and the cost of the circuit is often missing from the quote.
How much notice do you give before retiring a service we depend on?
Why ask it
Managed services get deprecated, and the migration work lands on you. Ask for the published policy and for examples of services retired in the last few years. Newer, more differentiated offerings carry the most risk of disappearing.
Tell me about your last significant outage or security incident, and what changed afterwards.
Why ask it
Everyone has had one, so a denial is itself informative. Useful answers include a public post-mortem, a specific fix and a changed process. Vague reassurance suggests you will get the same vagueness during your own incident.
What would it take for us to move off you, and what would extracting our data cost?
Why ask it
Ask for the egress charge on your full data volume, plus which components have no equivalent elsewhere. Managed databases, identity and event services are the sticky parts. Lock-in can be an acceptable trade, but price it before signing, not after.
What do your customers usually wish they had asked before signing?
Why ask it
An experienced account engineer will name something real, often about tagging discipline, network design or a commitment made too early. Deflection here tells you how the relationship will feel when you have a genuinely awkward question.
Comparing providers without being sold to
Practical guidance for the conversation itself
Before the meeting
- Write down one real workload with real numbers: instances, storage in terabytes, monthly data out, peak concurrent users. Every quote should be priced against that same workload.
- Pull your current spend from invoices, including licences, support contracts, network links and the hardware refresh you have been deferring.
- Decide in advance which constraints are non-negotiable, such as a region, a certification or a maximum recovery time. It is much harder to hold a line you first drew during the pitch.
- Bring someone from finance to the pricing conversation and someone who is on call to the reliability conversation. They ask different, better questions than an architect alone.
Reading the answers
Ask for the number, then ask for the unit
"It scales automatically" is not an answer to a cost question. Keep returning to what a specific month of your specific usage costs, and which meter that money passes through. Anything you cannot express as a unit price will surprise you later.
Treat the demo as marketing
Console demos are built on clean accounts with no legacy anything. The useful equivalent is a short paid trial with one of your own non-critical systems, where your own team does the work while the vendor watches rather than the reverse.
Write down what was promised verbally
Send a short summary email after each meeting listing the commitments you heard, and ask them to confirm. Anything nobody will confirm in writing was not a commitment, and this is the cheapest possible moment to find that out.
Where these evaluations go wrong
Comparing on compute price alone
Compute is the most competitive and most visible line, which is why it is the one quoted. Storage class transitions, data transfer between zones, support tiers and log retention are where quotes actually diverge.
Signing a long commitment early
Committed-spend discounts look free until your architecture changes and you are paying for capacity in the wrong shape. A shorter first term at a worse rate often costs less than a three-year deal signed before you know your usage pattern.
Accepting free migration credits as a decision
Credits cover the move, not the following years. Model year two and year three at list price, then decide, otherwise you have chosen a provider based on a discount that expires.
Letting the pilot become production
Proof-of-concept environments get built without tagging, access control or backups, then quietly take real traffic. Agree up front what happens to the pilot: rebuilt properly, or deleted.
How to run the conversation
Two rounds, same questions
- 1First round with each provider: the workload, the pricing units, what is excluded, and the constraints you will not move on. Keep it identical across vendors so the answers are comparable.
- 2Between rounds, price the same workload yourself from their public rate cards. The gaps between your figure and theirs are the questions for round two.
- 3Second round: reliability, support behaviour during incidents, the responsibility split, deprecation policy, and what leaving would cost. This is the round that separates providers, and it is the one most buyers skip.
If you are asking your own IT team instead
The same questions work, with one addition: ask what they already tried and where it hurt. Internal teams usually know exactly which meter is eating the budget and which service they regret adopting, and nobody has asked them.