Using a single AWS account is a serious risk

For my own AWS accounts, I use a read-only account in the profile and, on the very rare occasion I want to get clicky rather than use awscli to frob something, I'll log out and log back in as my writable-to-IAM user. I have a third user that only has IAM read/write privileges if I have to deal with that service. (I haven't sold my clients on this approach, though.)

The main takeaway here is to always use IAM accounts when doing stuff with AWS, and make sure each IAM account is only permitted to do the things you want it to do. It might be a pain in the ass to learn how the IAM policy syntax works, but believe me it works out for you in the long run!

(And, of course, use multi-factor auth. But you should be doing that anyway...)

What kills me is there is no easy way to stop all the instances for an account, in a region. It took me hours to kill all the instances. They had maxed out the number of instances in every single region. Very, very annoying.

And that's why you should use Bibucket first and foremost. And then when you vet your stuff and you know it's clean, you can publish it on publicly Github.

If you rush pushing code on github public repos that's exactly what will happen. If you start with a private one then move to a public one you have more time to think things through.

Now one could imagine a third party service warning users of potential issues with files pushed,based on their name/extension/folder name. But privacy first , then open the code to the public.

https://api.github.com/events

For what it's worth, the word is "waived". :-)

I'm glad Amazon dealt with you well!

This paradigm is very puzzling to me. Why do people feel the need to publish every small project to the public? Is it because github is so easy to create a new repo? Why don't more people use private repos like self hosted or bitbucket?

The whole reason why I spawned my own source code hosting service is so that I can work on projects in private without worrying about random people looking at what I'm working on (some of my C++ projects would give even Stroustrup a heart attack...). Note - this isn't saying bitbucket or gitlab or any of the others aren't good (oh I have my own opinions and comments about them...) - I've become rather bitter/paranoid/resentment of offers of free hosting.

[1] - https://github.com/jfalken/github_commit_crawler [2] - http://blogs.aws.amazon.com/security/blog/tag/key+rotation

Always use least privileged IAM keys in code if you must, preferably use EC2 roles instead of access keys, and never give your IAM users permission to run instances ... That way if the key is leaked then evil hacker can't do much with it.

We're humans. We're imperfect. Sometimes a safety net isn't a bad thing.

Agreed. We use Google App Engine for our recommendation engine (https://recent.io/) and daily budgets are a core feature -- just tap on the "Application settings" tab.

We use AWS for some additional components of our service that aren't part of the core recommendation engine, and I've been surprised by the lack of a maximum-dollars-per-day setting. Or if there is one, I'm not aware of it.

The only way would be to completely reset the entire account, otherwise you'd still be accruing charges just for data at rest or incoming requests or anything else passive.

A complete account reset doesn't seem like a feature that's very useful or something they'd want to implement because it would likely cause more trouble then help fix.

I really like that layer of protection, but I'm under no illusion as to what a disaster it would still be if the main pass was compromised.

IAM is just a PITA is what this boils down to. Create an IAM policy that allows users to push updates to elastic beanstalk but not touch any other resources in the account.. It's a major, major hassle. AWS has no concept of resource groups and each service has different ways of restricting access(ec2 can do it on tags, other services you kinda have to use naming schemas and wild cards in your policies). So you are often left needing to have users with a little too much access, and/or spending a LOT of time testing and crafting IAM policies..

IAM is a really good idea and powerful in many ways but unfortunately AWS's lack of consistency and UX across individual services really shows through sometimes, and with IAM in particular.

And then after hours of that I can determine that IAM policies fall way short off what I needed (isolation between different product groups in the org) and that we need to use separate root accounts.