If you are designing a fairly large platform to support upwa

Question

If you are designing a fairly large platform to support upwards of 100 dev teams what is the best approach to think about cloud accounts would you have one platform account for everything or would you have an account per dev team or product Any learning from those who have walked this path

Johannes Würbach · Answer

This depends a bit on what you are building the cloud provider and if teams should be able to interact with the cloud provider directly I ve struggle in the past to cleanly separate permissions inside a single AWS account as not all services support tag based permissions etc Multiple accounts make this way easier because the boundary is the account but make other things more challenging E g SSO to 50+ accounts keeping security requirements inline etc

Florian Lipp · Answer

Maybe good question also for < Maryann Bell> < Bryan Finster> < Galo Navarro> < Brian Leathem>

Joern Barthel · Answer

on aws multiaccount is the only way otherwise you drown in policy complexity if you want to have any change of least privilege also at scale API limits become an issue <https docs aws amazon com whitepapers latest organizing your aws environment organizing your aws environment html> gives a good overview about sensible options

Joern Barthel · Answer

tl dr organize accounts by workload add sandboxes for individuals if you want everything else shared infra ci cd environment considerations special accounts can be added later

Wellington Majora · Answer

Thank you < Joern Barthel> for this really helpful much appreciated slightly smiling face

Bryan Finster · Answer

Morning

Bryan Finster · Answer

You need a way to track team utilization One of the mistakes that s frequently made is to think of the cloud as an infinite server Those workloads cost money You need to be able to track it when a team doesn t design something correctly and your cloud bill goes through the roof You need a way to track the total cost of ownership of each team s product and that includes daily operation You of course also need to make sure that one team does not impact another team in production

Paul Seddon · Answer

Out of interest what do people here use for cost tracking Tagging is often a losing battle ownership changes etc so a way of dynamically creating cost groups outside of AWS feels like the way to go Yet to find the right tool to do that along with monitoring reporting anomaly detection recommendations all in a single pane of glass We have fine grained accounts which helps a lot but within that or even across accounts cost management is tricky

Joern Barthel · Answer

depends if you want can afford highly dependent on your profile amp how you negotiate an external cost management tool typically requires substantial investment into understanding how to use it can help here the standard 1 account per environment and workload service structure + individuals sandboxes style i described above also tends to simplify this aspect a lot for what kind of shared costs do you need insights in your fine grained accounts or are they cut by sth other than workload types

Paul Seddon · Answer

Cut by business groups and environments but within each account there is still some splitting of costs required

Joern Barthel · Answer

for resources provisioned by the users of that account or centrally stacksets lz adf ctc whatever provisioned

Joern Barthel · Answer

ah wait you wrote business groups would the same need to redistribute costs still apply if it would be workloads

Joern Barthel · Answer

with business groups becoming OUs