SLA Credits in Multi-Account Setups: Which Account Gets the Money
September 26, 2026
Your cloud bill is spread across accounts: an AWS organization with a management account and a dozen members, Azure subscriptions per team, GCP projects per product. When a provider breaches an SLA, the credit lands in exactly one place, and it is not the account that noticed the outage. It is the account that paid for the affected service. Get the filing account wrong and the claim stalls, or worse, the credit goes to a box nobody watches and quietly expires. This post maps who files and who gets paid for each of the big four.
The rule that runs through all four providers is the same: the credit is a percentage of what you actually paid for the affected service in the affected region, and it is applied to the account that paid that bill. Consolidated billing does not pool credits. It pools invoices.
AWS: the credit follows the account that paid
AWS SLAs apply separately to each account. The EC2 SLA states it plainly: the agreement "applies separately to each account using Amazon EC2," and a Service Credit "may not be transferred or applied to any other account." Consolidated billing in AWS Organizations merges your invoices and shares volume discounts, but it does not merge SLA credits.
So when EC2 in us-east-1 drops below its 99.99% commitment, the credit is a percentage of what each member account spent on EC2 in that region that month. A member account that ran $2,000 of EC2 gets a 10% credit of $200. The management account that paid the consolidated bill does not get a credit for the member's usage, because the member account is the one that incurred the charge.
| Provider | Credit lands in | Who files | Claim window |
|---|---|---|---|
| AWS | The account that paid for the affected service | That account, via Support Center case | End of second billing cycle after the incident |
| Azure | The subscription that incurred the charge | That subscription, via a Billing / Refund Request support case | 60 days from the incident |
| GCP | The project that incurred the charge | That project, via Cloud Support | 30 or 60 days, depends on the service |
| DigitalOcean | The account that owns the affected resource | That account, via support ticket | 30 days from the end of the month |
Two AWS details are worth internalizing. First, the claim must be filed from the account that owns the affected resources, because the request must include that account's ID and its request logs. A management account can open a support case, but the credit is calculated against the member account's spend and applied to that member account. Second, the $1 floor applies per account: a member account whose credit comes to less than $1 gets nothing, even if the organization as a whole spent enough to clear the threshold.
The credit follows the account that paid, not the account that noticed. Consolidated billing pools invoices, never credits. File from the account that owns the affected resources, or the claim stalls.
Azure: one claim per subscription
Azure's consolidated SLA (September 2026 edition) is explicit that claims are per subscription. The credit is a percentage of the "Applicable Service Fees," which for metered pay-as-you-go services means the fees you actually paid in the 30 days before the incident. For a subscription that ran $3,000 of Virtual Machines in the affected region, a 10% credit is $300 against that subscription's future bill.
The filing path is per subscription too. In the Azure portal you open Help + support, set the issue type to Billing and the problem type to Refund Request, and you must select the subscription where the problem occurred. The support engineer assigned to the case can only access resources in the subscription you specify. If the outage hit three subscriptions, you file three claims, one per subscription, each with its own incident ID from Service Health.
Two Azure edge cases change the math. If you bought through a Cloud Solution Provider, you do not file in the portal at all: only the direct or indirect provider can request the credit, and they need your tenant GUID, the outage ID, and an email from your tenant's domain as evidence. And if you bought through Open, Open Value, or Open Value Subscription licensing, the credit is paid as service time (days) rather than as a fee credit, because those agreements do not carry Applicable Service Fees.
| Azure purchase channel | Who files | What the credit looks like |
|---|---|---|
| Direct (pay-as-you-go) | You, per subscription, via Billing / Refund Request | Fee credit on that subscription's bill |
| Cloud Solution Provider | The direct or indirect provider, via Partner Center | Fee credit, prorated to the affected service |
| Open / Open Value licensing | You, per subscription | Service time (days), not a fee credit |
GCP: per project, and the window varies by service
GCP determines credits per project per region. The Compute Engine SLA (last modified March 2025) gives you 60 days from the moment you become eligible to notify Google technical support. The Cloud Storage SLA (last modified April 2026) gives you only 30 days. That split is easy to miss, and it is the difference between a paid claim and a forfeited one.
| GCP service | Claim window | Credit cap |
|---|---|---|
| Compute Engine | 60 days from eligibility | 100% of the month's bill for the covered service |
| Cloud Storage | 30 days from eligibility | 50% of the month's bill for the covered service |
| Cloud SQL | 30 days from eligibility | 50% (Enterprise) or 100% (Enterprise Plus) of the month's bill |
| BigQuery | 30 days from eligibility | 50% of the month's bill |
The credit is applied to the project that incurred the charge, and it is capped at the amount that project owed for the covered service that month. If you run the same service across several projects, you file per project, and each project's credit is capped on its own. Google also notes that if you buy through a reseller or partner, the credit applies only to the impacted partner order, and the partner files on your behalf.
DigitalOcean: the account that owns the resource
DigitalOcean keeps it simplest. The SLA covers the account that owns the affected Droplet, database cluster, or Spaces bucket, and the credit is a percentage of that resource's charges. You file a support ticket from that account, name the affected resource IDs and the region, and the credit lands on that account's bill. There is no consolidated-billing layer to route around, because DigitalOcean does not offer one.
The practical filing checklist
Across all four providers, the same five steps keep a multi-account claim from dying in support limbo:
- Identify the account or subscription that paid for the affected service in the affected region. That is the filing account.
- Pull that account's resource IDs, not the management account's.
- Grab the incident ID from the provider's status page or Service Health, and the exact outage window in UTC.
- Attach request logs from the affected account that show the error rate, redacting anything sensitive.
- File before the window closes, and track the deadline per account, because a 30-day GCP window and a 60-day Azure window do not line up.
The single most common reason a multi-account claim fails is not missing evidence. It is filing from the wrong account, so the credit is calculated against the wrong spend, or the support engineer cannot access the subscription that actually incurred the charge.
Here is the one action to take today: open your provider's billing console, list your accounts or subscriptions, and note which one pays for each service you run. When the next outage hits, you will already know which account files, and the credit will land where you can see it instead of expiring in a box nobody checks.