Most AWS operations conversations start with a tool list and end with a monthly fee. The more useful conversation starts somewhere else: with the documents nobody asks to see during the sales cycle. An SLA defines what the provider promises. A runbook defines how the promise is kept at three in the morning. Ownership defines who is accountable when neither of the first two holds up. If you are an IT or engineering leader evaluating AWS operations support, these are the questions worth asking before you hand over production.
Questions to Ask About SLAs Before You Trust a 24/7 Promise
An availability percentage on a slide is not an SLA. It is a marketing number until you know how it is measured, what falls outside the measurement, and what happens when the target is missed. Start by asking what the target actually is for your workload class. A credible commitment states specifics: for critical workloads, a stated availability target of 99.9% or better, and for response, a premium plan that lists a Sev-1 acknowledgment time of 15 minutes or less. If those numbers are absent or described only as “best effort,” you have learned something useful already.
Next, separate response from resolution. Acknowledgment time is the clock starting; resolution is the clock finishing, and the second one is rarely guaranteed in the way the first is. Ask how severity levels are defined, who assigns them, and whether you can escalate an incident into a higher severity when the business impact is worse than the ticket suggests. Then ask about escalation itself: is there a named escalation path with phone numbers, or only a shared inbox? The difference shows up on the worst day, not the best one.
Scope is the third area where SLAs quietly fail. Ask, in writing, whether the SLA covers database administration for RDS and Aurora, security patching across EC2 fleets, IAM governance and access reviews, WAF and Shield management, backup verification, and cost optimization reviews. Many agreements promise availability while excluding the very tasks that produce it. Look just as closely at the exclusions: maintenance windows, customer-caused outages, third-party provider incidents, and unsupported architecture choices are common carve-outs, and each one narrows the promise.
Finally, ask how the SLA is evidenced. Availability SLAs are only meaningful when someone publishes the score. Request sample dashboards, ticket reports, and monthly review decks. Ask whether regular Executive Service Reviews happen on a fixed cadence and who attends from the provider’s side. A provider that reports openly on misses is safer than one that reports only on wins, because the first has built a system for being wrong in public. Every question above has the same underlying purpose: converting a feature list into something you can check after the fact.
Runbooks: The Difference Between Documented and Practiced
Ask to see the runbook index before you see the price sheet. A runbook is not a wiki page someone wrote during onboarding and never opened again. It is the operational script that tells an engineer which alert means what, which system to check first, what a known-good state looks like, when to escalate, and how to roll back. If the provider cannot produce an index mapping runbooks to your critical services, the rest of the SLA is theoretical.
Then dig into the questions that reveal whether the documents are alive. Who owns each runbook? Ownership should sit with a person or role, not with “the team.” Where is it stored and versioned? Runbooks kept outside version control drift silently. When was it last tested? A runbook that has never been exercised against a real failure is a hypothesis. What triggers an update? The right answer is that every Sev-1 and Sev-2 incident produces a review and, where needed, a revision — not that updates happen quarterly if someone remembers.
Ask how runbooks connect to monitoring. Alerts without a matching runbook generate noise and panic; runbooks without alert thresholds never get used. A disciplined setup maps CloudWatch and Grafana alerts to documented response steps, so a first responder knows within seconds whether they are looking at a capacity issue, a dependency failure, or a bad deployment. Ask about the on-call rotation and the communication cadence during a major incident: who tells your stakeholders, how often, and through which channel. Support delivered through tickets, email, and phone is a baseline; premium arrangements often add Slack or Microsoft Teams, and that detail matters when minutes count.
Backup and disaster recovery deserve their own runbook questions, because this is where written plans most often diverge from reality. Ask whether restore procedures are documented, whether recovery drills are scheduled, and whether you will receive the results. A recovery plan that has never been tested is not a plan; it is a hope. And since a managed aws managed services provider is taking on the daily work of monitoring, patching, and incident response, its runbooks are effectively your operations manual. Review them the way you would review code, and insist on getting them transferred if the relationship ever ends.
Questions to Ask About AWS Ownership, Handover and Exit
Ownership is the question nobody raises until a bill spikes or an audit lands. Begin with the account structure. In a multi-account AWS estate, who governs organizational units, service control policies, and cross-account access? Ask how IAM governance works in practice — role design, least-privilege reviews, break-glass access, and the audit trail for privileged actions. If the answer is vague, the provider is administering your environment rather than owning its governance.
Then ask who owns the operational artifacts. Infrastructure as code written in Terraform or CloudFormation belongs to you, in your repositories, under your review process, even when someone else authors it. Tagging standards, snapshot retention policies, and lifecycle rules should also be documented and auditable; hand-managed snapshots are one of the most common sources of inconsistent retention and quietly rising storage costs. On cost specifically, ask who decides on rightsizing recommendations, Reserved Instance and Savings Plan purchases, and idle resource cleanup — and how those decisions get reported back to you. Optimization framed as a one-time audit tends to decay; ask whether it is an ongoing commitment with a review cadence attached.
Scope boundaries matter as much as scope inclusions. Ask directly what is out of scope: application code, feature development, third-party vendor management, end-user support. A provider that describes its limits clearly is easier to work with than one that says yes to everything. Also ask how the engagement tier is matched to your environment — a shared support pod for a small team, a semi-dedicated pod for mid-size enterprises with production workloads, a premium pod for business-critical systems, or a dedicated team for enterprise estates. Getting this wrong in either direction produces either a thin response or a bill you cannot justify.
The final set of questions concerns exit, and they are the ones most often skipped. Ask what happens if you leave. A professional handover includes documentation, AWS configuration exports, access cleanup, runbook transfer, and structured knowledge transition — all specified in the contract rather than promised verbally. Ask about onboarding timelines as well, so you can plan the transition: an AWS health check typically takes three to five business days, standard managed onboarding one to two weeks, and complex environments two to six weeks. Anyone comparing providers on ownership should ask for the exit terms in writing on day one, because the quality of the exit tells you how seriously the provider takes your independence.
Born in Sapporo and now based in Seattle, Naoko is a former aerospace software tester who pivoted to full-time writing after hiking all 100 famous Japanese mountains. She dissects everything from Kubernetes best practices to minimalist bento design, always sprinkling in a dash of haiku-level clarity. When offline, you’ll find her perfecting latte art or training for her next ultramarathon.