Working With Cloud Provider Support

Chapter 6 covered internal escalation. This chapter covers the other side of it: engaging the cloud provider's own support organization directly, when an issue genuinely sits on their side of Chapter 1's shared responsibility model — "of the cloud," not "in the cloud."

When to Actually Engage Provider Support

Genuinely provider-side issues: a documented service outage, a hardware failure affecting a specific resource (cloud2-5's instance-failure material), or behavior that contradicts documented service guarantees. Not provider support's job: your own IAM misconfiguration (cloud2-3), your own application bugs, or architecture-optimization advice for your own choices (though some higher support tiers do offer this as a paid add-on — worth distinguishing from break/fix support). A practical gut check: is this something only the provider can fix, or something fixable internally with the right access or knowledge? If the latter, Chapter 6's internal escalation is the right path, not a provider case.

Support Tiers, Compared

The general pattern: higher tiers mean faster guaranteed response times, broader scope (architecture guidance, not just "is this broken"), and often a named technical account manager at the top tier. Which tier an organization has directly determines what's actually possible to get from a support case — worth knowing before setting expectations with a customer.

Severity Levels in Provider Support Cases

Revisiting Chapter 6's own internal severity triage, now applied to the provider's side: providers have their own severity definitions (e.g. "production system down" vs. "general guidance") that determine their response-time commitment, entirely separate from an organization's internal severity classification. Accurately classifying severity in the case itself genuinely matters — an inflated severity may simply get reclassified by the provider rather than fast-tracked, while an understated one produces a slower response than the actual situation needs.

What Makes a Good Support Case

• The specific resource ID/ARN, not just "my service."
• The exact error message, not a paraphrase.
• A precise timeline of when it started and what, if anything, changed around that time — Chapter 4's own documentation habit pays off directly here.
• What's already been tried or ruled out — saves the support engineer from suggesting things already tested.

Understanding SLA Credits

If a provider fails to meet its own published SLA (a documented uptime guarantee, for instance), customers are typically entitled to service credits — but this is not usually automatic. It typically requires actively filing a claim with specific supporting evidence, directly rewarding the documentation habit from Chapters 4 and 6. Assuming credits happen automatically is a genuinely common misconception worth correcting directly.

Reading Provider Status Pages & Health Dashboards

Working a Case Collaboratively

• Respond promptly to support's follow-up questions — cases can get deprioritized or closed for inactivity.
• Provide the specific additional diagnostic information requested, rather than re-explaining the original problem from scratch.
• If the case involves genuinely time-sensitive production impact, say so explicitly and make sure the case's severity actually reflects that.

Hands-On Exercises