If you attend an AWS talk about security, bump into an AWS security person in a business meeting, or are in line behind an AWS employee at a Starbucks, you’ll invariably hear the phrase “Security is Job Zero.”
What does this actually mean?
Cynically, I might suggest that they came up with a list of their jobs for a conference talk, got to the end, realized “oh crap, we forgot security!,” and bolted it on at the beginning as “job zero” so they didn’t have to renumber all of their slides, but that might be uncharitable.
They clearly take security very, very seriously. They also call it “job zero,” and let’s be very clear: the defining line between “hobby” and “job” is whether or not you get paid for something. To that end, let’s talk about some of the ways you get to pay AWS more money in return for security.
Before I begin, I want to highlight that I’m not suggesting that all security services should be free in perpetuity. But I also want to be clear that there’s a line drawn internally at AWS between “okay to charge for” such as for Amazon Macie, and “not okay to charge for,” such as enabling MFA for your root, IAM, or SSO users.
Where exactly is that line drawn? Clearly in the wrong place sometimes!
I’d like to see it drawn more clearly and distinctly. I don’t think encrypting traffic or data should cost extra. I do think ML-powered services to find PII buried in your data should cost money. If you follow AWS’s best practices, it shouldn’t cost you extra security money. If you’re a bank and have a bunch of compliance checkboxes to tick, you should expect to pay more.
The line can be blurry. But it needs to be established somewhere that’s less seemingly arbitrary.
Let’s explore…
CloudFront
We’ll start with everyone’s least favorite CDN: CloudFront.
Setting aside the giant list of complaints I have about the service for a better time, let’s look at one aspect of its pricing: the per-request charge.
In North America, every 10,000 HTTP (read as: unencrypted) requests will cost you $0.0075, whereas every 10,000 HTTPS (read as: encrypted) requests will cost you $0.0100.
That’s right, you’re paying a 33% premium for HTTPS requests, in an era where Amazon’s CTO walks around in a t-shirt emblazoned with the phrase “Encrypt Everything.” That looks a lot less thought-leadery and a lot more like a cash grab when you start charging extra for that encryption layer.
What’s even more frustrating is that—with many private pricing deals for CloudFront—they don’t just reduce the cost, they also normalize the per-request charge between HTTP and HTTPS requests to be the same thing.
While fascinating in that it’s not just a discount but also a change to an actual pricing dimension, it’s nonetheless frustrating to see from a company that periodically hurts itself patting itself on the back for how awesome its security posture is.
Shield Advanced
AWS Shield is their anti-DDoS service that guards a bunch of resources. It has two tiers; the first is Standard, which applies to everyone at no additional charge. It protects services like CloudFront and Route 53, and you can basically pretend it isn’t there—because it pretty much isn’t.
It’s an intrinsic property of those AWS services, and you need not worry about it until suddenly it starts eating traffic you didn’t want it to. (Note that for all my snark, I’ve never yet seen such a thing happen in the wild; “a bunch of missing traffic” hasn’t happened due to Shield.)
The second tier is AWS Shield Advanced, which extends that detection and mitigation of DDoS attacks to EC2 instances, ELB load balancers, Global Accelerator, and a few more services. Additionally, it lets you talk to the AWS DDoS Response Team and changes the Web Application Firewall (WAF) pricing structure.
It costs $3K a month with a 1-year commitment only, so that’s a $36K checkbox.
I’m not begrudging AWS charging extra for access to its response team or mapping extra protections on to a variety of services. What I am saying somewhat tongue-in-cheek is that—given how hard it is to attribute DDoS attacks to their source, combined with how much you’re at AWS’s mercy for understanding / seeing what happens at lower levels of the network stack—I’d be hard pressed to identify a better extortion opportunity if this group wanted to juice its numbers for a quarter.
Let me be clear: I don’t suggest that this was, is, or will be happening. And, if it were, the people on that DDoS response team would insta-quit and go public because they’re principled, honest people.
All I am saying is that if it were occurring, we’d never be able to tell at a technical level.
IAM
I want to be clear here before I get letters from all of you people: IAM doesn’t cost anything directly!
Despite its frustrations, it’s incredibly well thought out and well-built. The thing that annoys me and sparked this entire blog post came out of a recent (wonderful) IAM announcement: the ability to generate least-privilege IAM policies based upon access activity.
This, of course, costs nothing directly. But here’s where it gets sticky.
It operates on the basis of analyzing CloudTrail management events, which is itself free for the first trail. Subsequent trails cost $2 per 100,000 events delivered, which can be monstrous.
The easy solution is of course to just have one trail, right? Enter Control Tower! This thing sets up a dedicated logging / auditing account pair that receives the CloudTrail management events—and the account containing the IAM policy can’t read that S3 bucket by design.
You’re required to enable a second trail for this to work properly—and in my $50 test account, this quickly became the single most expensive service therein.
This isn’t so much a deliberate “charge extra for security” play so much as it is yet another example of AWS service teams not speaking to one another clearly and concisely. Out of everything I’ve listed here, this is the one I’m most optimistic about getting fixed in the near term just because the people on the Identity team flat out Do Not Mess Around.
KMS
AWS’s Key Management Service or KMS is a great service. My problem with it comes down to how impenetrable the service’s pricing is, to the point where after a bad experience or two it starts scaring people away from using it.
It costs $1 per month per Customer Master (their term, not mine) Key, which is fine. But then it charges 3¢ per 10,000 requests. Note that this skyrockets for some request types, but we’ll ignore those for purposes of this article.
The trouble comes in when you start to realize how many things make requests to KMS.
“Wait, so you’re telling me I have to pay three cents for every 10K DynamoDB requests? I do that four times a second!” is a common misunderstanding. In practice, it caches the key for five minutes to avoid turning your bill into a monstrous joke. But that’s not at all obvious or easily discoverable unless you explicitly go looking for it.
KMS calls are logged in CloudTrail so you can identify the expensive services making calls. But that requires a lot of work on your end to glue various things together.
Unlike the others in this post, I don’t have a problem with KMS charging. My issue instead lies with the lack of transparency and predictability.
I recently had someone at AWS tell me that every Lambda invocation would make KMS calls to decrypt the environment variables on every execution. This scared the heck out of me until a quick spot check of my own bill demonstrated that there was no possible way this was true. So, KMS needs some serious pricing simplification to avoid scaring people away.
So what would I change?
I’m not suggesting that AWS is doing anything inherently wrong with any of these services. I’m saying that all of these examples trip over the seams between different service teams—divisions that are very far from clear to customers. The gaps need to be addressed, and the storytelling improved.
In an ideal world, sensible security practices won’t wind up costing customers another dime. As it stands today, there are some security configurations that are more expensive than the data breach they’re defending against.
Fortunately, for the moment, cleaning up those messes remains someone else’s job zero.
