Our cloud account was compromised through a user's access key and secret key. The attacker used Bedrock APIs across multiple regions and generated roughly $40,000 in charges. We have removed the affected users, rotated credentials, and updated our security controls. Billing is handled through a cloud partner, which has already opened a support case, and the provider's security team alerted us to the abuse. We've been customers for about 12 years without a previous incident. Is there a realistic chance of receiving a billing adjustment or waiver, and what should we do next to improve our chances?
4 Answers
Your strongest case is the long, clean account history and the fact that the provider identified the activity as abuse. Keep escalating through your partner, but also make sure there is a formal fraud or billing-waiver case attached directly to the account. Document when the compromise started, when it was detected, what was contained, and every remediation step. A waiver is possible in some cases, but it is not guaranteed and may take time. Keep the case visible to your account representative and follow up regularly.
The provider may view this under the shared-responsibility model, so a refund is not automatic. Be prepared to explain why the key had access to multiple regions and what monitoring was in place. Add budget alerts, service quotas, anomaly detection, resource tagging, and region or service restrictions so a similar compromise is detected quickly and cannot create another uncontrolled bill.
A similar incident resulted in tens of thousands in charges for another company. They were eventually given a credit after escalating and implementing stronger safeguards. Focus on containment first, then provide evidence of the controls you added. Don’t assume the first support response is the final decision—ask for review by the billing or abuse team.
The incident also points to a permissions problem. Long-lived secret keys should generally be avoided; use roles, temporary credentials, SSO, or workload identities where possible. If a key is unavoidable, rotate it frequently, store it securely, restrict its permissions to the minimum required, and prevent it from accessing services or regions it does not need. Remove broad administrator policies and add alerts for unusual usage.

Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures