Live data from Hacker News

Have lots of AWS accounts

src-bin.com

141–150 of 176 posts

Re: Have lots of AWS accounts

#141
post #139

I agree with a lot of this, but it's missing any discussion of downsides to having a lot of accounts. Some of these include: * Granting permissions to resources in other accounts is complicated. Even where there is first class support, such as for s3 and kms, it involves multiple steps, and familiarity with confusing terminology. * Using the web console or cli is more complicated. In the cli you'll have to manage a b…

> * Having to assume a role in another account can complicate code, especially if you may or may not have to assume a role depending on the circumstances.

One workaround I usually implement for this is to always have to assume a role. Meaning that, basically, your base permissions only allow you to assume roles. To actually do the job, you need a separate one, in whichever account.

This way, it's also easier to standardize roles across accounts. A action requires R role.

Re: Have lots of AWS accounts

#143
post #71
post #38

I disagree with this perspective. You should have multiple accounts but only if your organisation requires it for isolation or data protection reasons and only enough to perform the task. Every other reason here is because you fucked up. You have poor architecture, poor tagging, poor VPC design, poor IAM policy and role modelling or don't know what you are doing to start with. And some of the stuff doesn't even make…

> poor IAM policy and role modeling This is a bad take. Making good IAM Roles and Policies is incredibly complicated if you have a complicated account. You WILL get it wrong. This becomes much more tractable if you have reasonable account boundaries between workloads. If you insist on a single massive account you're fighting against the way that AWS designs the system, and you're gonna have a bad time.

I'm not even sure at what point account boundaries really have merit anymore past organization. Most things that are subject to account boundaries have really poorly crafted IAM roles or policies somewhere. You just have a single logical boundary in between the two talking things.

The way that GCP organizes various different projects is actually really nice. I haven't seen what this looks like at scale though.

Re: Have lots of AWS accounts

#144
post #82
post #60

Earlier quoted context omitted.

They don't really though because in the several systems I've seen configured like that, the same staff have access to all accounts. Accidental deletion and unauthorized access should not be a possibility via policy rather than isolation, because if the former isn't done then the latter will not help. If the client demands it, sure, but charge them for the inconvenience. The main risk is hitting resource limits which…

The places I've worked just control that with SSO and groups in their auth system. Much easier to make a group in your auth software than try to create multiple permission boundaries in the same AWS account. It also makes cost allocation much easier (you don't need complicated tagging policies everywhere)

Security in layers.

Infrastructure as code.

Easier for you, easier for the black hatters.

Re: Have lots of AWS accounts

#145
post #38

I disagree with this perspective. You should have multiple accounts but only if your organisation requires it for isolation or data protection reasons and only enough to perform the task. Every other reason here is because you fucked up. You have poor architecture, poor tagging, poor VPC design, poor IAM policy and role modelling or don't know what you are doing to start with. And some of the stuff doesn't even make…

lol, I can sense someone who have never got their account blocked for some arbitrary reason.

Just imagine you woke up and your AWS account is blocked and all your infra is shut off. What's your plan? Blame "poor design" or policy?

If you want to build a _reliable_ infrastructure, the only rule is to avoid singe point of failure. Account is one of those.

No worries, it will come with experience.

Re: Have lots of AWS accounts

#146
post #10

> 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 A…

Why 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.

Depending 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/

Re: Have lots of AWS accounts

#147
post #10

> 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 A…

Why 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.

Another complaint I have is that afaik none of the SDKs have any kind of API for SSO login.

Re: Have lots of AWS accounts

#148
post #3

One of the things I love most about google cloud is that "projects" are easy to create and easy to link to other projects. Roles and service accounts can even reference across projects, though I'm not sure I'd recommend doing that. No more faffing about with special accounts, passwords and difficult to configure shared VPCs, it all becomes so easy. Even managing the different accounts is difficult without browser ext…

I really dislike the Google Cloud way of doing things, for example Projects, Folders and Orgs. There's a dozen different weird paradigms that you have to consider to securely and reliably manage a large number of different projects, accounts, tenants, business units, etc in Google Cloud; if you don't do things "The Google Cloud Way" you are screwed. AWS is much simpler and more straightforward. You don't have to thin…

AWS is decidely _not_ simpler here. You've got Stockholm syndrome. What's complicated about making two projects and picking between them? What's complicated about grouping projects under a single organization? What's complicated about grouping projects under a folder? What's complicated about adding someone to a project through IAM? The only way you can fuck that last part up is by granting overly broad permissions (which they warn you when you've done right there in the console).

You can safely ignore the existence of Organizations and folders completely if you are so inclined. At least there's a sensible way to set default policies for your organization baked into the platform. Even so, literally 3 hours, tops, and you know everything about these abstractions you could ever care about. I cannot emphasize enough how much easier GCP is to learn and use than AWS.

Re: Have lots of AWS accounts

#149
post #3

One of the things I love most about google cloud is that "projects" are easy to create and easy to link to other projects. Roles and service accounts can even reference across projects, though I'm not sure I'd recommend doing that. No more faffing about with special accounts, passwords and difficult to configure shared VPCs, it all becomes so easy. Even managing the different accounts is difficult without browser ext…

I don't know. I've found it to be pretty difficult to answer the question "which of these 1000 gcp projects are running a production workload and which are random one offs created by a dev messing around or by a google sheet script?"

So the problem is the abstraction is so easy to use to get a project going that people just litter them everywhere... how is that a problem with the platform? At least they are actually in one searchable location. How do you find your production workloads if you have 1000 AWS accounts?

Re: Have lots of AWS accounts

#150
post #38

I disagree with this perspective. You should have multiple accounts but only if your organisation requires it for isolation or data protection reasons and only enough to perform the task. Every other reason here is because you fucked up. You have poor architecture, poor tagging, poor VPC design, poor IAM policy and role modelling or don't know what you are doing to start with. And some of the stuff doesn't even make…

If there's one thing that is true in this world, it's that you can't rely on people not fucking up.

All you can do is try making fuckups difficult by figuring out how to implement systems where doing the right thing is the path of least resistance. You won't stop fuckups, but a system where people will do the right thing 90% of the time instead of 50% is so much better.

Post reply on HN