We recently migrated our infrastructure to AWS, and two days ago one of our important instances was taken offline after we received security notices claiming that an access key had been compromised. We investigated the activity, resources, billing, and CloudTrail history, and everything appears to be ours. The key was brand new, was not committed to a public repository, and has since been deactivated and deleted. We answered AWS's questions and were told the case had been escalated to the security team, but we have not received a meaningful update despite following up. The instance is critical to our business, so we need advice on the safest way to proceed and whether upgrading to a paid support plan is likely to speed up the review or help restore access.
3 Answers
The response time may be tied to your support tier. Basic support generally does not promise rapid handling for security or operational incidents, while a paid plan can provide a clearer escalation path and response targets. That does not guarantee the security team will immediately clear the restriction, but opening the case through the highest support level available and clearly documenting the revoked key, investigation results, CloudTrail findings, and business impact is probably the fastest legitimate route. In parallel, restore the workload from a known-good backup so the business is not dependent on the locked instance.
If this is production infrastructure, treat the event as a possible breach until you can rule that out. Preserve an image or snapshot for forensic review, avoid trusting the original instance, and redeploy the application on fresh resources. Review CloudTrail, IAM users, roles, keys, and activity in every region for unexpected persistence, new credentials, or unfamiliar instances. Also determine whether a credential was exposed or whether the server itself may have been exploited; those require different fixes. Instance roles are preferable to storing long-lived access keys on servers.
Immediately revoke the flagged key and create a replacement only after confirming the source of the alert. AWS can detect exposed credentials in public code repositories, even when they have not been used yet. Also, if you have a recent backup or image, launch the service on a clean replacement instance rather than waiting indefinitely for the original one to return.
We reviewed CloudTrail, billing, and the related activity, and everything matches our own work. The key was new and was never committed anywhere. We may still be missing something, but at this point it looks more like an automated false positive or an old account becoming active again than an obvious compromise.