One account per service per region per deployment stage (e.g. dev, test, production) is the best practice. How you define "service" is up to you, but I usually divide them by trust/dependency footprints.
This significantly reduces the risk that an account-level problem or throttle will disrupt your entire business.
Fortunately, AWS finally seems to be getting serious about building management tools for multiple accounts. AWS Organizations is way better than the old consolidated billing stuff.
Who calls that a best practice? If you're a very small company, that might be fine. With thousands of employees and tens or hundreds of applications, you'll run into serious problems if you want to use e.g. VPC peering for shared services. You'll also run into major cost issues if for example you have per-VPC or per-account commercial appliances.
That's interesting, because their consultants discourage it for their customers. For companies that want to keep most of their traffic internal, I don't think it's a working model. I suppose Amazon's internally used services are the same ones they expose to customers, so it probably works fine.
This significantly reduces the risk that an account-level problem or throttle will disrupt your entire business.
Fortunately, AWS finally seems to be getting serious about building management tools for multiple accounts. AWS Organizations is way better than the old consolidated billing stuff.