> 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…
Have lots of AWS accounts
171–176 of 176 posts
Re: Have lots of AWS accounts
#172I 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.
> If you want to build a _reliable_ infrastructure, the only rule is to avoid singe point of failure. Account is one of those.
I'm not sure which sense of the word "reliable" you're using here. Usually durability / continuity of business conversations focus on having backups in other accounts (on same or different IaaS providers).
Availability conversations are usually centered around multi-region within a single IaaS provider, and that can be in a single account. Sure, you could build it to use multiple accounts, and you might pat yourself on the back if it ever actually saves you, but how long would it take to build that and what else could you have done with that time?
Re: Have lots of AWS accounts
#173I 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…
Ok...
> My favourite thing doing is spending 2 days opening support tickets in 10 different accounts to get a limit raised and then tracking the state of all the tickets and limit changes...
Oh. So, you fucked up too? Because all that should be automated.
Re: Have lots of AWS accounts
#174Could someone come with some analogy please?
Re: Have lots of AWS accounts
#175Earlier quoted context omitted.
Each account within the organization gets the limits of the free tier, just as a single account would. I think the reasoning is that if you're going to go through the hassle of setting up orgs then you're probably an enterprise user slated to take the long haul anyway.
Not true, the free tier is applied at the Organization level (i.e. the billing account), not to each individual account.
Re: Have lots of AWS accounts
#176Earlier quoted context omitted.
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.
Are you suggesting having 2+ copies of your infra so that you can withstand losing one of them? I've never heard anybody propose this approach before. > If you want to build a _reliable_ infrastructure, the only rule is to avoid singe point of failure. Account is one of those. I'm not sure which sense of the word "reliable" you're using here. Usually durability / continuity of business conversations focus on having b…
Some people do, some people just talk. Noone proposed don't mean noone did.
> Usually durability / continuity of business conversations focus on having backups in other accounts
That's quite poor quality of conversations then. Continuity of business is much wider than having backups.
> how long would it take to build that and what else could you have done with that time?
Lesser than you may have expect. What could you have done with your time is certainly a good question, the best asked when your infra is down because cloud provider blocked your account. As I mentioned in original comment, if you ignore probability of that, then you are just not experienced enough.