Hacker News new | ask | show | jobs
by csakon 1871 days ago
I don't think i'm leaving anything out. It was my account (which now has had password changes and MFA set up), but I don't understand how there weren't red flags on the Austrian IP address login and the sudden spike in usage. I realize (now) that CloudWatch exists, but not sure why this isn't standard.

I was at fault for the double post of the support case, but that was a simple error on my part due to not thinking the first went through.

Once access was made, we were completely unaware of their existence until I saw the charges and asked our devs about it. They said they didn't have any knowledge or access to these new instances.

I appreciate the advice, will upgrade the support and try again.

4 comments

AWS gives you access to a lot of footguns, and they expect you to implement proper security practices, access controls, monitoring, billing alerts, etc.

Why? Because they serve just about every use case and scenario. I've myself spun up $5k/day resources on accounts that did four magnitudes less / day before that. There are some limits by default which you can get raised, but they're not going to prevent a $50k bill - at best, they're here to prevent a $500k one.

Anyway I agree they could make it clearer that you have to do all this crap yourself but it makes for a poor sales pitch.

Footguns...lol. New term for me. I see your point and it makes sense from that perspective. For me as a small business owner, it's very painful considering I tried to go the normal route of opening a case for help and simply cannot get anyone to escalate this or talk to me on the phone.
I understand. It's a tough situation. Breathe, AWS is one of the better services to end up in such a situation with. This will get resolved.

Be a little patient, but don't try to superescalate by going through emails and what not. Just file a business ticket. If this needs escalation, they will do so.

AWS is like a weapons cache you've stumbled upon in the middle of the desert, lots of fun, useful and interesting stuff in it but you're going to get yourself hurt if you don't take proper precautions.

This sounds like a cautionary tale. I have spending alarms on my personal account for this very reason, I'll know within 5-10 minutes if my monthly spend is going to break $50 because I've set up my alarms.

Your other option is to start a Cloudtrail and alarm on foreign IPs that are logging in, new IAM users and keys being created and changes to any alarms you have in place to check for this stuff. It won't necessarily stop it, but you'll be able to react a lot faster.

You'll have a notice within 5-10 minutes if you continually carry your phone and are "supporting" your application 24/7. What if you want to go camping or turn your phone off when you go to bed or do a long drive or something?
I don't want 5-10 minutes necessarily.

But what would be best practices for billing alarms? I have used them in the past when I used a bit more of AWS, but I don't think I ever got one (which is good).

But it happens to me that I miss emails that I would have liked to read in time for weeks. That could happen with a billing alarm, too.

Maybe you could forward it to SNS with SMS delivery. But as a matter of fact SMS is one of the few services (if not the only one) with a spending limit. If that is reached you silently won't get SMSes anymore, I have experienced that.

No need to be facetious, friend. Were I a more paranoid man I'd hook a lambda into the SNS topic and terminate all ec2 instances, delete all S3 buckets, delete all IAM keys and regenerate and send me the root password.

I'm not that worried though.

There's nothing facetious about his post, you've over-reacted to it.
Are you going to know it within 5-10m? Billing updates can take hours to appear on my account (I noticed that with some new services I was using). Even CloudTrail can take longer than 5-10m.
I mean, it’s hard to have sympathy. Your setup sounds like a complete mess especially if you didn’t notice it. You didn’t even have MFA and you’re using the console to create resources?

It’s not on AWS to flag anything. They give you the tools to comprehensively monitor your account, but you choose not to use them. Cloudwatch is also “standard”. Datadog has a free tier, I’d suggest checking that out because you don’t seem to have any infrastructure monitoring?

I’d honestly hire some people that have experience in this area, because your “dev team” sounds clueless.

Nonsense, AWS is an industry leader in use of the asterisk. With exception to perhaps S3 and AWS Lambda, the predominant majority of AWS services are cloaked with accounting legalese and hidden billing gotchas that can easily result in a several thousand dollar bill within days if you don't analyze every aspect of AWS service offerings including their EULAs and acceptable use policies.

So yes, it was bad form for OP to not establish billing alerts, but you can't in any way say that AWS is transparent about most aspects of their service tiers.

It is not in AWS interest to give too many options to their users to restrict the usage and expenditure.

AWS can certainly do a better job in telling me how to optimise my AWS hardware and expenses

In OPs case, if you search in Google, you will find this AWS hacking happen a lot with many users including me and AWS support was extremely kind to me to give additional credits to offset that expense.

If AWS hacking happens a lot it sounds like a problem for AWS to deal with by default, doesn't it? Perhaps even be forced to by law?

It would be trivial for AWS to force you to setup spending limits when setting up an account, one for an alert, one for a hard lock.

AWS billing is terrible too, even now I'm getting charged a few dollars on my personal account for who knows what, I've cancelled everything I can find. It's like whack-a-mole everytime you spin something up.

In the end that's basically theft by AWS but you can't make too much noise or your account gets cancelled.

I mean, yes, AWS isn’t going to not take your money if you’re using their service. And no, it’s not some murky snake pit. There are some nuances but on the whole it’s pretty clear.

Anyway I was talking more about cloudwatch monitoring, including tracing all API calls. The billing is secondary: someone has been in his account and might have exfiltrated everything.

I agree that it should have been noticed earlier from a few vantage points. I'm managing over a dozen contractors which varies from dev to marketing to customer support, operations, sales, financials, investor relations, etc. Everything could be better, but it's a business and the squeaky wheel gets the oil. I never fathomed the squeaky wheel was going to be AWS usage charges.

I myself have never created an instance, I set up the account then gave access to the devs. I only log into the account to provide new access to devs that need it and none of them are full time.

Ultimately the responsibility lies with me, but I would disagree that my dev team is clueless. Rather they're working on development, not watching what the servers are doing on a daily basis so I think that's a bit unfair.

Let me get this right: you give a parade of short-term contractors access to your production AWS account, presumably without proper permission segmentation, and neglect to do anything _other_ than that?

I assume you revoke access later, but I doubt you audit anything that they may have done (like create keys that outlive their access) in the account or that any of it is version controlled or traceable.

And you’re surprised you’re in this situation?

And fair enough, you pay your contractors to do a specific job. None of them are going to point out that the way you’re managing your infrastructure is pretty slow and inefficient, or that perhaps there’s a better way to do any of what you’re doing on AWS that is cheaper, faster, more secure and that might give you a far quicker iteration time with the added advantage that you won’t fall apart with a surprise bill like this. They, after all, are working on “development”.

Economy of scale is an indispensable aspect of any competent engineering effort. Any reasonably adept AWS engineer would always include cost considerations for any change to AWS backend architecture, including helping the client decide which service tier makes the most sense for a particular application's use case...
> I realize (now) that CloudWatch exists, but not sure why this isn't standard.

CloudWatch is standard AWS, or what do you mean?

Amazon gives you all the tools to monitor your usage and management of the cloud. You did not use those tools, had sloppy security and now it is Amazon's fault?

Take it as an expensive lesson learned. And get someone who knows what they are doing in AWS to administer it. Maybe your company was pennywise pound foolish by not having someone who knew AWS?