Lots of AWS accounts doesn't scale. Accounts are heavy items in terms of governance, manageability and cost. On your way to 100 accounts you'll be rearchitecting security and networking and will find yourself in a strange limbo of architecture models. Once over 100 you'll be drowning in the tech debt of a complex environment with increasing friction.
Accounts can be made lightweight by using shared VPC/subnets but then you'll be in the realm of niche user, hampered by AWS's poor support for RAM service support with poor documentation if you plan on using anything off the highway of bread and butter services.
IMO a balance needs to be struck with sensible boundaries built on business units or ownership. Shared VPC's are inherently unstable and should be avoided where possible. Build a good delegated IAM model and hammer people to use it properly.
I feel this article is missing a lot of the drivers.
When automation was kicking off Ops just sucked. Infrastructure teams were slow to respond and automate, were underfunded, whatever. They sucked when Dev's were being driven to deploy faster.
Dev's started do it themselves. They sucked at it too. They got some "ops" guys in the team to help them do it better. This was then called "DevOps" and the consultants built an industry around the cultural change of collaboration between Devs and Ops.
DevOps smushed together so much that it became just "Devs" doing ops work. They realised that Ops is hard and 70% of their work was Ops, with 30% providing business value. Dev's don't want to Ops, they just want to Dev.
Scaling dev's meant building shared deployment platforms. So ops was centralised into a "Devops" team. Usually this is jammed between Dev teams and traditional Infratructure (VMWare) teams. Kubernetes lives here.
Having a devops/platform team also means you have less fingers in your cloudspace breaking things and deploying bad patterns. Good for scale. Dev's just want to write code, throw it at git, tests run, they repeat. No ops for them.
The problem for us is the mystery of everything that underpins the service. For managers, auditors, regulators, the tickbox allows us to get on with our jobs.
Thank you. I’m amazed so many here don’t get it. How are you guys building robust things? Maybe I’m too far along to see from the eyes of a novice, but why would anyone poo-poo default encryption at rest?! And as-a-service to boot!
Accounts can be made lightweight by using shared VPC/subnets but then you'll be in the realm of niche user, hampered by AWS's poor support for RAM service support with poor documentation if you plan on using anything off the highway of bread and butter services.
IMO a balance needs to be struck with sensible boundaries built on business units or ownership. Shared VPC's are inherently unstable and should be avoided where possible. Build a good delegated IAM model and hammer people to use it properly.