Appendix A: Example Use Case - AWS Governance at Scale

Appendix A: Example Use Case

Example use case for implementing governance at scale to manage AWS accounts within a company:

ACME organization has outgrown their manual and spreadsheet-based governance process. The company is large and profitable (1B yearly revenue) but have diverse business units that require autonomy and flexibility. They have a small governance team, and a limited budget for a custom home-grown solution. Because of their organizational and financial constraints, they decided to purchase a solution from the AWS partner. (Partner offerings include, Turbot, and Dome9 Security.) Once the solution is deployed and configured to align with the company specific processes and requirements, the solution is available for developers and decision makers, to centrally manage their cloud resources. The workflow below describes how a new developer would access and manage their resources within a governance at scale solution.

John is a developer joining a team that designs application environments for deployment in the AWS Cloud. Therefore, he needs an AWS development environment that allows him to manipulate infrastructure components using code without affecting other developers or systems. Each developer within the team is approved for individual monthly billing budgets for the use of AWS.

A governance at scale implementation and workflow for this scenario is:

  1. John navigates to a portal to submit a request for an AWS account for developers. From the list, he chooses from a set of standard corporate AWS account types, and then specifies that he needs a monthly billing budget of $5,000.

  2. His request triggers a notification that is sent to his manager. His manager uses the portal to confirm or change the monthly billing budget that John specified, and selects any preapproved/assessed system boundary that John’s environment is allowed to operate within.

  3. An automated process creates a new AWS account for John, and uses AWS CloudFormation to build a baseline architecture, and apply predefined IAM policies and AWS service configurations within John’s new AWS account.

    • IAM policies include what services and resources that John is allowed to access, and the AWS Service API calls he is allowed to perform. See for details.

    • AWS service configurations include services such as an Amazon Virtual Private Cloud (VPC) architecture that includes predefined AWS security groups to be assigned to Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Simple Storage Service (Amazon S3) buckets provisioned with predefined access control policies, and network connectivity to access functional and security-enabling shared services. Example, code repositories, patch repositories, security scanning tools, anti-malware services, authentication services, time synchronization services, directory services, backup and recovery services, and etc.

  4. An automated process interfaces with the company’s governance, risk, and compliance (GRC) tool to link John’s AWS account with the preapproved/assessed system boundary. This allows the GRC tool to access the account for the system inventory, and monitor for compliance violations as part of automated IT auditing and continuous monitoring.

  5. An automated process begins tracking the AWS services and resources that John provisions to record the spending rate within John’s AWS account.

  6. As the monthly spend limit is approached, an automated series of notifications is sent to John so he can act to ensure he does not overspend his budget. It is escalated to his management if John fails to react appropriately. Additionally, a series of automated predefined budget enforcement actions take place, including preventing new AWS resources from being provisioned, and shutting down or de-provisioning AWS resources.