- [Alana] Imagine you were part of an organization that has to separate their infrastructure to meet some financial, security, or legal purpose. Your team decides that the best way to do this is to have many AWS accounts, and separate your resources by account. This is a great idea because it will allow your organization to define boundaries between departments or resources, and it also enables your organization to easily scale out by simply adding more AWS accounts. So you start thinking, well, if we have hundreds of accounts, how are we going to have oversight over all of those resources in all of those accounts? It's easy with one account because I only have to look in one place, but with hundreds, does that mean I have to look in a hundred places? More than that, what about managing cost or usage? Am I going to have to put together a hundred different bills to see the full cost of my AWS environments? These are common questions that customers from the traditional, on-premises world are asking. In fact, we want you to ask your CSP these questions so that you understand what governance tools and support a CSP has to offer. With the cloud, things like oversight, security, and cost controls are designed to be easier for you. Take oversight, for example. In traditional data centers, it's possible through human error to miss key upgrades or maintenance cycles for hardware, such as servers, but with the cloud, you're given the ability to automate these upgrades, which removes the risk of human error. One of the tools that AWS created to make oversight, security, and cost controls easier is called AWS Organizations. This service enables you to have centralized management of all of your AWS accounts. With AWS Organizations, you can group accounts together to better manage account permissions and resource needs. The idea of this service is to make questions-- like how do I manage hundreds of accounts? -- no longer a concern. Here's an example of a starter AWS multi-account framework that we often recommend for new customers. In this diagram, you have four main groups of accounts. The first group is all of your security accounts, accounts for archiving logs, accounts for security tooling, and more. The second group is your infrastructure accounts, for all the accounts that run your backend business, maybe internal build tools, shared services, an account for your network. The third group is for your sandbox accounts, full of accounts that are owned and accessed by employees, maybe for sharing business data or trying out new AWS services. And then, the last group, which is your workloads, full of the applications that your end users access. The great thing about categorizing your accounts is that you can audit and maintain security at the group level and treat each group differently. For example, you may want to be more lenient with security standards for your sandbox accounts, so that your developers can actually access the new services that they want to play around with. But the accounts dedicated to security tooling...hmm, probably needs to be a lot stricter with those. This makes a difference even from the auditing perspective. If I have a PCI auditor that comes in to audit my systems, it's a lot easier to say to your auditor, these are all the PCI resources that are in this one AWS account under this group, rather than trying to explain that there are resources across multiple accounts and groups, and this is how we've secured access to them, and why they're compliant. And from the billing perspective, all of your cost is rolled up to one central location in your organization. So, you can keep tabs on how much you're spending on your whole environment, how that's changing over time, and even break that out to see spends for individual accounts. This becomes important if you create accounts for each application you run. That way, you can see resource cost and spend for each application, and know which part of the business owns that, instead of sorting through every account, trying to figure out who is paying for what. AWS Organizations also integrates seamlessly with AWS Budgets, which is a way to monitor and track your AWS spend and usage. With AWS Budgets, you can create cost budgets and usage budgets to ensure your teams are staying under their allotted spend. Also, remember in an earlier section, where I mentioned that you have to monitor your Reserved Instances to make sure those discounts are being applied? Well, with AWS Budgets, you can create controls to track your Reserved Instances and be notified if you fall below a certain amount of usage. Now, this idea of governance is not one size fits all. Not every organization is going to want to start with this example account structure. And that's because it's very unique to the business that you work in. It's like houses. There are many different types of house, and they all serve very different purposes designed to fit different use cases. For example, I might be vying to live in an apartment, and you might want to live in a mansion. The idea here is to get you thinking about what you need from a cloud service provider, far before you do any buying at all. Understanding how you'll manage your accounts will help you understand what capabilities to ask a CSP for when buying cloud. This is vital to cloud procurement, and the more you feel comfortable with the CSPs tools, the better off your stakeholders will feel when setting and monitoring controls within your cloud environments. I know that we've covered a lot of information here, but keep in mind that we have AWS Partners to help support you. They can help you create the right account structure for your organization, implement it, and manage it.
