4 ms·
> My favorite way to create a network between all my services hosted in different AWS accounts is to share a VPC from a network account into all my service acco
by pid-1 4y ago
> My favorite way to create a network between all my services hosted in different AWS accounts is to share a VPC from a network account into all my service accounts and use security groups to authorize service-to-service communication. There’s no per-byte tax, zonal architectures are easy to reason about, and security groups work just like you expect.
That's gold advice. I wish AWS RAM supported more services (like AWS EKS).
A small complain: working with AWS SSO is a bit tedious. My current solution is to share my ~/aws/config with everyone so we all have the same profile names and scripts can work for everyone.
- rcrowley 4y agoI have thought a great deal about whether I also want EKS clusters to officially support nodes in multiple AWS accounts. On the one hand, having the option to create that additional low-level isolation would be lovely, even and maybe even especially if I didn't always take it. On the other hand, isolating two things from each other but then tying them to the same Kubernetes cluster upgrade schedule feels wrong. In the end, I decided that if I care about isolating two things enough to put them in separate AWS accounts, I'm willing to spend the $75 per month that it takes to have separate EKS clusters, too. (This opinion perhaps obviously doesn't fit will with hobby/side project budgets.)
- rcrowley 4y agoSynchronizing ~/aws/config gets harder and harder as your team grows because there are both more people who need to receive changes and more people making changes. I think the human-readable names for AWS accounts need to be part of the account, not part of the laptop. Substrate [1] does this so that you can type commands like `substrate assume-role -domain example -environment production -quality beta` [2] to get where you're going. [1] <https://src-bin.com/substrate/ https://src-bin.com/substrate/> [2] <https://src-bin.com/substrate/manual/moving-between-aws-accounts/ https://src-bin.com/substrate/manual/moving-between-aws-acco...>
- nijave 4y agoOne place I worked just committed it to the git repo (obviously just SSO and account numbers, no passwords or tokens)
- thedougd 4y agoWhy can't the CLI generate the config if I can see all the accounts and roles in the SSO start page? That's a desperately needed feature. I would love to see a browser extension for SSO account tabs if AWS can't solve it natively.
- pid-1 4y ago`aws configure sso` does that, but: 1 - You need to do that with each account / role pair 2 - It gives profiles very long names by default (<role>-<account_number>) 3 - It does not set $AWS_PROFILE, so you need to pass `<...> --profile <...>` manually So the code is actually there already, they just need to make the experience better.
- thedougd 4y agoI imagine most are like me and after doing this once or twice falls back to a text editor.
- lapser 4y agoDepending on your SSO provider, you can list all the roles using saml2aws[0] and then parse the output so you can generate the relavant config. It is a bit tedious, but it works. [0] https://github.com/Versent/saml2aws/ https://github.com/Versent/saml2aws/
- thayne 4y agoAnother complaint I have is that afaik none of the SDKs have any kind of API for SSO login.
- noahmasur 4y ago> My current solution is to share my ~/aws/config with everyone so we all have the same profile names and scripts can work for everyone. If you're on Mac/Linux you could have everyone use direnv. Add a .envrc file in each git repo (or your script's subdirectory) with `export AWS_PROFILE=profilename`. Now everyone is working with the same profile names without having to pass around config files.
- CoolCold 4y agoJust in case, can be used in WSL too, if one is on Windows
- coredog64 4y agoOne hidden gotcha about RAM-shared VPCs is that some services (cough RabbitMQ cough) don’t work in them.