The public cloud offers scalability, flexibility, and speed. Anyone, anywhere, can spin up a new cloud instance and start taking advantage of powerful remote computing resources, lowering the barrier for innovation and allowing businesses to build and grow quickly. However, rogue and abandoned cloud accounts introduce a variety of risks—as well as potential costs. Unfortunately, organizations often have no visibility of cloud assets outside of central governance, particularly accounts created in Amazon AWS.
‍
Let’s talk about what unmonitored cloud and AWS accounts can cost your business, along with what you can do to address them.Â
‍
Missed discounts and credits
AWS typically charges organizations in one of two ways. For large organizations, AWS provides discounts based on usage volume. The organization may even prepay for a certain amount of usage for the year, potentially committing to millions of dollars of usage. A smaller startup might receive a certain number of AWS credits over a certain period of time. In either case, creating a new account outside of the organization means those corporate discounts and credits don’t apply, and your organization misses out on savings.Â
‍
Wasted investments
If you don’t know about a cloud account, you can’t apply any of the security tools or policies your organization has invested in. In other words, not only is the account unmonitored and unprotected, but the security investments you’ve made are going to waste. You have no way of detecting if an unmonitored S3 bucket containing customer data has been exposed to the public, for example, even if you pay for a solution that should theoretically catch that type of misconfiguration.Â
‍
Duplication & inefficiencies
In the aftermath of an acquisition, or even multiple acquisitions, acquired companies often continue to maintain their own AWS infrastructure. These accounts may not be entirely unmonitored, but given that they fall outside of the organization’s centralized AWS infrastructure, they create inefficiencies that can add up to substantial costs. Companies may miss out on higher potential corporate discounts, pay duplicate costs for security tools and services, and waste time that all of the teams involved could have allocated to other projects if these accounts were enrolled in centralized governance.Â
‍
Exceeding free tier usage
We’ve all heard the horror stories about surprise AWS bills. On one hand, there’s a lot you can do for free with AWS pay-as-you-go pricing, which makes it enticing for employees to spin up new accounts to take advantage of a free tier. However, once the account’s activity exceeds that tier’s limit, your organization is on the hook for the additional usage. (This structure is the target of substantial critique.) Whether the account’s usage spikes because of normal activity, a misconfiguration, or something else, an unexpected AWS bill can put a dent in a department’s budget.Â
‍
AbuseÂ
It’s one thing when an AWS bill results from legitimate activity, and quite another when the source of that bill comes from an intrusion. An attacker who gains access to an unmonitored AWS account and uses it for their own purposes, such as cryptomining, can rack up substantial usage fees. According to the Sysdig 2022 Threat Report, for an attacker to mine just one Monero coin using a hijacked AWS EC2 instance results in a staggering $11k bill for victims; in other words, mining a single dollar’s worth of cryptocurrency costs $53 in losses for victims. When security teams can’t actively monitor an account, there may be no sign of the illegitimate activity until the bill arrives.Â
‍
Regulatory fines & legal fees
A security incident involving an unmonitored AWS account can have significant legal and regulatory implications, not to mention potential civil liability. Capital One, a high-profile victim of an attacker who targeted misconfigured S3 buckets, was forced to pay $80M in regulatory fines for the incident, plus an additional $190M to affected customers who filed a class action suit. As you evaluate your own potential liability in case of rogue accounts, make sure to consider data locality issues that an employee might inadvertently cause by storing data somewhere it shouldn’t be.Â
‍
Extra audit fees & security investments
Once an incident occurs, some laws and regulations may require additional audit activity or security investments. For example, the Federal Trade Committee targeted Chegg Software in 2022 with a series of requirements after they experienced a series of security incidents over a few years, including a major breach involving illegitimate access to an AWS S3 bucket containing customer data. If Chegg fails to meet these additional security requirements, which will require them to make investments in security, the organization will be forced to pay a civil penalty of up to $46,517 per violation.Â
‍
It goes without saying that the cost of a data breach can be astronomical, from investigating a potential incident to managing brand damage in the aftermath. According to IBM, breaches affecting the public cloud cost an average of $5.02M. Of the breaches analyzed in the report, 45% happened in the cloud. Unmanaged AWS accounts can provide attackers with an especially easy entry point. If an employee makes a mistake like using weak credentials or misconfiguring an S3 bucket when they create an AWS account outside of central governance, your organization has no way of catching the error or detecting an intrusion, leaving any sensitive information stored within the account vulnerable.Â
‍
While most organizations have policies in place to minimize the creation of cloud accounts outside of their centralized governance process, there are common reasons policy can’t effectively eliminate this problem.Â
‍
Often, AWS accounts go unmonitored because of simple human error (or good intentions gone wrong). For employees to follow your corporate policy, they have to both know about it and remember it every time they create a new account. Well-intentioned engineers may even think they’re doing the right thing by sidestepping the rules in the interest of speed or taking advantage of a free offer. Staking your cloud security posture on the assumption that engineers will always follow a policy is a risky proposition: These are the same people who are told to “move fast and break things,” people who pride themselves on being the right kind of lazy, who tinker and spin up skunkworks projects on the side that then find their way into business-critical environments.
‍
While it’s tempting to put the blame entirely on individual users, AWS accounts can also slip through the cracks because of organizational complexity. When an organization acquires another company—or multiple companies—it can take time to identify and consolidate AWS resources under centralized governance and iron out expensive inefficiencies. Even without an acquisition, responsibilities involving cloud resources can span multiple departments or business units, making it difficult to get complete visibility of what’s going on across an organization.Â
‍
Policy alone can’t solve the problem of unmonitored cloud accounts—businesses need a reliable technical backstop. Unfortunately, there is no technical mechanism within Amazon AWS to prevent employees from signing up for AWS services outside of your organization altogether. Ultimately, you need to know when your employees create new unmanaged accounts, so you can catch them before they incur costs or present security concerns.
‍
Imagine this: The minute one of your engineers signs up for a new AWS account without following your centralized governance process, you automatically receive a notification within Slack alerting you to the new account, so that you can add it to your organization’s infrastructure as code (IaC) service or AWS Organization.Â
‍
Nudge Security continuously discovers your organization’s AWS accounts and identifies which ones have bypassed your centralized governance process, helping you avoid the risks and costs associated with rogue accounts. As your employees create accounts, Nudge Security can notify you of the new additions while automatically nudging your employees to follow corporate policies. You can even see how much you’re spending on AWS services, and how much of it comes from managed v. unmanaged accounts.Â
‍
You can also use Nudge Security to remind users to stick with your organization’s preferred cloud service provider. For example, if an employee signs up for a Microsoft Azure account when your organization has paid for AWS credits, or vice versa, you can automatically nudge them via Slack or email to either make the switch or explain why they need to use the unapproved vendor.Â
‍
Do you know how many AWS accounts your organization has? Take your best guess—and then let Nudge Security show you the answer. Try it free for 14 days to find out.