Also take a look at aws-vault [1]. This not only assumes roles but also helps you store your original credentials in an encrypted form rather than a plain text ~/.aws/credentials file. You do have to configure all assumed roles in ~/.aws/config<p>They have an exec command but you can also export your credentials to env variables with somethings like<p><pre><code> aws-vault exec "$AWS_PROFILE" -- env | egrep '^AWS' | awk '{print "export " $1}'
</code></pre>
[1] <a href="https://github.com/99designs/aws-vault" rel="nofollow">https://github.com/99designs/aws-vault</a>
I know of no service that is more complex and off putting to newbies than AWS. I mean, wait, I need multiple accounts? Getting my team access to the one account we have took me 3 hours already!<p>No wait, I need a <i>design pattern</i> for how to manage accounts of a SaaS service?<p>I'm probably not the target audience here but I strongly get the impression that these patterns would not be necessary if AWS would get their shit together in terms of AWS Console UX design.
In Google Cloud, something like this is mostly unnecessary. The project model scopes resources to a particular project within an organisation, rather than all resources being global to the account. This gives a really good first cut at isolating different environments and projects.
I like AWS multiple accounts support it helps securing specific environments, but I don't like that going this route increases the cost.<p>Here are some things I don't like:<p>1. if you want to use AWS support, you need to purchase it per account, otherwise support will refuse any help that involves anything specific to the account (they will only respond with generic documents)<p>2. with separate account you need to recreate the same components (and therefore pay more) for example if you want internet access on your VPC over IPv4, you need to set up a NAT instance per account, you can't for example use VPC peering and use NAT instance on another account<p>3. you are being charged for any data going between accounts even if same AZ is used. Yes, I understand that one can't easily tell which AZ is which across accounts since they are randomized per account but still...
Great article and nice tool. Switching role and profile with multiple organizations is indeed cumbersome with AWS.<p>We are also developing an open source CLI for AWS named awless (cf. <a href="https://github.com/wallix/awless" rel="nofollow">https://github.com/wallix/awless</a>). We currently support easy MFA, profile switch and role assuming in CLI with the '-p' flag and are working on extending these features to support multiple organizations. We had multiple issues filed on GitHub which are closely related to this.
2018 Hottest AWS Job Postings:<p><pre><code> - Identity-Access-Management Manager
- Pricing Oracle
- Sysadmin we fired when Moving To The Cloud(tm)</code></pre>
Now that I'm comfortable with the IAM side of things, I will always use multiple accounts. I'm also beginning to think it's valuable to not even limit yourself to a single account per environment. Tools like Terraform become essential, though.<p>I've written about using multiple accounts in combination with CodePipeline to manage Lambda deployments here: <a href="https://medium.com/statics-and-dynamics/automated-lambda-deployments-with-terraform-codepipeline-a4d2a2019eae" rel="nofollow">https://medium.com/statics-and-dynamics/automated-lambda-dep...</a>
Like everyone else, I also wrote a CLI login util in GoLang for multiple AWS account with this "bastion/main" account setup: <a href="https://github.com/lencap/awslogin" rel="nofollow">https://github.com/lencap/awslogin</a> . Simplicity is the main driver. I welcome constructive input.
We took this approach at 99designs with aws-vault and bastion accounts: <a href="https://99designs.com.au/tech-blog/blog/2015/10/26/aws-vault/" rel="nofollow">https://99designs.com.au/tech-blog/blog/2015/10/26/aws-vault...</a>
Very well written article with some good advice. We found very early on the need for multiple AWS accounts and managing varying levels of access to all of them has been challenging.<p>I also recommend looking into using SAML with your own login provider, if you have one, to assume individual roles in AWS accounts.
Unless I'm missing something, isn't this whole process made a lot simpler just by using STS?<p>It also works incredibly well with Vault's STS backend.
As coinbase is a Bitcoin wallet and they transact a lot of money it suprises me that they reveal details of their implementation publicly.<p>Edit - Getting downvoted a lot.<p>Seems that some people think that the expression 'You shouldn't rely on security through obscurity' means that it's OK to publish your backend infrastructure.<p>Best practice is defence in depth.<p>That means you secure everything including your implementation details.<p>If a zero day is found in any of their stack, they're a google search away from being found for that.