Live data from Hacker News

Have lots of AWS accounts

src-bin.com

111–120 of 176 posts

Re: Have lots of AWS accounts

#111
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.

`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 (-)

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.

Re: Have lots of AWS accounts

#112
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…

Having things “in a VPC” doesn’t help unless you are just using AWS as a glorified Colo. Once you start using AWS native services - many of which aren’t in a VPC, VPC isolation doesn’t help.

Each AWS account also has its own service limits and quotas. One out of control Lambda in the dev “environment” can impact production.

And you don’t have to open support tickets manually. There are APIs to request service limits and you can monitor the progress programmatically.

Re: Have lots of AWS accounts

#113
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?"

I solve that by using folders. But when you have many of anything it will become hard to reason with.

It’s not worse than your filesystem, in theory, but speaking for myself: my filesystem is a mess, so…

Re: Have lots of AWS accounts

#114
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…

Having things “in a VPC” doesn’t help unless you are just using AWS as a glorified Colo. Once you start using AWS native services - many of which aren’t in a VPC, VPC isolation doesn’t help. Each AWS account also has its own service limits and quotas. One out of control Lambda in the dev “environment” can impact production. And you don’t have to open support tickets manually. There are APIs to request service limits…

I run into "IT professionals" all the time who don't even realize you can run services without a VPC.

Re: Have lots of AWS accounts

#115
post #57

Earlier quoted context omitted.

Is billing aggregation a problem and do you need to open up 10 different support tickets if all the accounts are part of an AWS Organization? As for keeping the number of accounts down, I've seen that blow up significantly if you have someone break into an account or have a disgruntled employee that can get into a single account and wreak massive damage. Or if your software runs in multiple regions and you need to me…

None of these concerns require multiple accounts. An account is a container for resources and resources do have tangible isolation between them if configured properly and properly delegated credentials should be issued to staff which are specific and limited in capability. Same with assumed roles. Same with VPC configurations. If you didn't do that, you fucked up. Adding more accounts doesn't guarantee that you didn'…

- get all of the account numbers in your org

- for each account number

   - aws service-quotas request-service-quota-increase

Re: Have lots of AWS accounts

#116

Earlier quoted context omitted.

Having things “in a VPC” doesn’t help unless you are just using AWS as a glorified Colo. Once you start using AWS native services - many of which aren’t in a VPC, VPC isolation doesn’t help. Each AWS account also has its own service limits and quotas. One out of control Lambda in the dev “environment” can impact production. And you don’t have to open support tickets manually. There are APIs to request service limits…

I run into "IT professionals" all the time who don't even realize you can run services without a VPC.

Besides, every time you try to create a “least privileged role” to run infrastructure as code, that role has so many privileges it’s easy for mistakes to cause mistakes in your production “environment” that you meant to only affect your dev “environment”.

And I know I’m probably preaching to the choir. But one of the misconceptions I have to constantly fight is “we run our Lambdas in a VPC for security reasons”. (Lambdas are never “run in” a customer VPC)

Re: Have lots of AWS accounts

#117
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…

There's definitely a place for these counterarguments, but I have had Amazon's own consultants tell me that quota issues are exactly the reason they think you should architect to span many Amazon accounts if you're big. There are some quotas they simply can't raise as high as you want them on a per-account basis.

Re: Have lots of AWS accounts

#118

Only if you're gonna use AWS Orgs/AWS Control Tower to help manage everything otherwise it gets wild. Internally, Amazonians also use AWS accounts per "app" basically.

In fact per app per region that the AWS service exists in. My AWS service exists in 24 regions so that is 24 “prod” accounts, 8 “gamma” and 6 “beta” and 1 “alpha” account. Some newer teams go even further. If the app is made out of different micro services, then each micro service gets its own account per region. Typically a medium sized AWS service will have like 30 micro services behind it (not really micro; these…

https://www.lastweekinaws.com/blog/the-aws-service-i-hate-th...

> The fact that it’s the internal service used to provision AWS accounts means that AWS engineers building AWS are insulated from the way that the rest of the world manages AWS accounts–or should I say, ways. They don’t have to deal in the same way with AWS Organizations or Landing Zones or Control Tower or AWS SSO (an absolute hidden gem of a service, by the way). And that’s the crux of my beef with the service.

Apparently, /u/quinnypig dislikes this account-manager-thing specifically because AWS has been hoarding it to themselves.

His point is valid: When is AWS going to advertise account per region per service as an official default policy and bring AWS Orgs up to par with it? They think it's the right way, why not for the customer?

Re: Have lots of AWS accounts

#119
A related problem is multi-cloud orgs trying to copy this advice into other clouds. For example, at $dayjob, the cloud guy is trying to replicate the AWS account structure into Azure, where it's largely unnecessary. In Azure the equivalent of an account is a subscription, but then there's a second hierarchy level in the form of resource groups. Combined with tagging, this makes it very easy to do internal charge-backs or RBAC.

They've even added a feature to redistribute the costs of shared resources: https://azure.microsoft.com/blog/simplify-financial-reportin...

Splitting things across accounts or subscriptions is complex and results in all sorts of strange limitations. For example, some resources can't be connected to each other across subscription boundaries, so you have to duplicate them.

Another example is Kubernetes (EKS or AKS). The typical thing to do is to create a single cluster with multiple node pools, all in the same account or subscription. Then this is split using namespaces. All of this will be in one account, and can't be "associated" with other accounts or subscriptions. The second a shared platform like this is introduced, the fine-grained account model breaks down.

Re: Have lots of AWS accounts

#120

Earlier quoted context omitted.

Having things “in a VPC” doesn’t help unless you are just using AWS as a glorified Colo. Once you start using AWS native services - many of which aren’t in a VPC, VPC isolation doesn’t help. Each AWS account also has its own service limits and quotas. One out of control Lambda in the dev “environment” can impact production. And you don’t have to open support tickets manually. There are APIs to request service limits…

I run into "IT professionals" all the time who don't even realize you can run services without a VPC.

[deleted]
Post reply on HN