Hacker News new | comments | show | ask | jobs | submit login

My huge recommendation is to put production instances in a completely seperate region than development and staging instances. I actually just discovered that you can limit IAM API keys to a specific region, you just need to create a custom policy. The following policy is an example:

    "Version": "2012-10-17",
    "Statement": [
            "Sid": "SOME-ID-HERE",
            "Effect": "Allow",
            "Action": [
            "Condition": {
                "StringEquals": {
                    "ec2:Region": "us-west-2"
            "Resource": [

Why would you do this instead of using multiple AWS accounts? Different regions have different feature sets (available instance types, beta eligibility, etc.). I strongly recommend instead using multiple AWS accounts instead and keeping them in the same region.

That said, since you should be using an infrastructure provisioning tool like CloudFormation, the tagging solution should not be a particularly big obstacle.

yes, use multiple accounts. you can use STS to grant permissions between the accounts if needed.

STS works, but I feel like multiple accounts linked is more of a hack than using a single AWS account. Of course, if you use a service that is not available in both regions, use STS.

How is multiple accounts a hack? It's the correct solution to isolation. Using regions is just stupid because now you've attached extra meaning to regions and can't bring up production stuff in other regions for better latency.

Alternatively, you can run two AWS accounts and get a single bill with 'combined billing'. One account being prod and one is test.


If you segment production instances from develop/staging you can use IAM rules to grant specific privileges based on the entire region, instead of by tag (which is fragile). Additionally, it is less error prone when you are making manual changes in the console as it requires switching regions between production and develop/staging.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact