COST 2: How do you govern usage?
Establish policies and mechanisms to ensure that appropriate costs are incurred while objectives are achieved. By employing a checks-and-balances approach,
you can innovate without overspending.
Resources
Control access to AWS Regions using IAM policies
AWS multiple account billing strategy
AWS managed policies for job functions
-
Develop policies based on your organization requirements: Develop policies that define how resources are managed by your organization.
Policies should cover cost aspects of resources and workloads, including creation, modification and decommission over the resource
lifetime.
-
Implement goals and targets: Implement both cost and usage goals for your workload. Goals provide direction to your organization on cost and usage, and targets provide measurable outcomes for your workloads.
-
Implement an account structure: Implement a structure of accounts that maps to your organization. This assists in
allocating and managing costs throughout your organization.
-
Implement groups and roles: Implement groups and roles that align to your policies and control who
can create, modify, or decommission instances and resources in each group. For example,
implement development, test, and production groups. This applies to
AWS services and third-party solutions.
-
Implement cost controls: Implement controls based on organization policies and defined groups and
roles. These ensure that costs are only incurred as defined by organization requirements: for example,
control access to regions or resource types with IAM policies.
-
Track project lifecycle: Track, measure, and audit the lifecycle of projects, teams, and environments to
avoid using and paying for unnecessary resources.
Improvement Plan
Develop policies based on your organization requirements
Meet with team members : To develop policies, get all team members from your organization to specify their
requirements and document them accordingly. Take an iterative
approach by starting broadly and continually refine down to the smallest
units at each step. Team members include those with direct interest in the workload, such as organization units or application owners, as well as
supporting groups, such as security and finance teams.
Define locations for your workload : Define where your workload operates, including the country and the area within the country. This information
is used for mapping to AWS Regions and Availability Zones.
Global Infrastructures Regions and AZs
Define and group services and resources : Define the services that the workloads require. For each service, specify the types, the size, and the number of resources
required. Define groups for the resources by function, such as
application servers or database storage. Resources can belong to multiple groups.
Cloud Products
Define and group the users by function : Define the users that interact with the workload, focusing on what they do and how they use the workload, not on who they are or their position in the organization.
Group similar users or functions together. You can use the AWS managed policies as
a guide.
AWS Managed Policies for Job Functions
Define the actions : Using the locations, resources, and users identified previously, define the actions
that are required by each to achieve the workload outcomes over its life time (development, operation, and decommission).
Identify the actions based on the groups, not the individual elements in the groups,
in each location. Start broadly with read or write, then refine
down to specific actions to each service.
Actions, Resources, and Condition Keys for AWS Services
Define the review period : Workloads and organizational requirements can change over time. Define the workload review schedule to ensure it remains aligned with organizational
priorities. High frequency review cycles are typically identified by security requirements, cost or usage is a significant, importance to the organization is
high, and the amount of change of the workload.
Document the policies : Ensure the policies that have been defined are accessible as required by your organization.
These policies are used to implement, maintain, and audit access
of your environments.
Implement goals and targets
Define expected usage levels : Focus on usage levels to begin with. Engage with the application owners, marketing
and greater business teams to understand what the expected usage
levels will be for the workload. How will customer demand change over time, and will there be
any changes due to seasonal increases or marketing campaigns.
Define workload resourcing and costs : With the usage levels defined, quantify the changes in workload resources required to meet these usage levels. You may need
to increase the size or number of resources for a workload component, increase data transfer, or change workload components to a different service at a specific level. Specify what the
costs will be at each of these major points, and what the changes in
cost will be when there are changes in usage.
Define business goals : Taking the output from the expected changes in usage and cost, combine this with expected changes in technology, or any programs
that you are running, and develop goals for the workload. Goals must address usage, cost and the relation between the two. Ensure that there are organizational
programs, for example capability building like training and education, if there are
expected changes in cost without changes in usage.
Define targets : For each of the defined goals specify a measurable target. If a goal is to increase
efficiency in the workload, the target will quantify the amount of improvement, typical
in business outputs per dollar spent, and when it will be delivered.
Implement an account structure
Define separation requirements : Requirements for separation are a combination of multiple factors, including security, reliability, and financial constructs. Work through each factor in order
and specify whether the workload or workload environment should be separate from other workloads. Security ensures that access and data requirements are adhered to. Reliability ensures that limits are managed so that environments and workloads do not impact others. Financial constructs ensure that there
is strict financial separation and accountability. Common examples
of separation are production and test workloads being run in separate accounts, or using a separate account so that the invoice and
billing data can be provided to a third-party organization.
Define grouping requirements : Requirements for grouping do not override the separation requirements, but are used
to assist management. Group together similar environments or
workloads that do not require separation. An example of this is grouping multiple test or development
environments from one or more workloads together.
Define account structure : Using these separations and groupings, specify an account for each group and ensure
that separation requirements are maintained. These accounts are
your member or linked accounts. By grouping these member accounts
under a single master/payer account, you combine usage, which allows for greater volume
discounts across all accounts, and provides a single bill for
all accounts. It's possible to separate billing data and provide each member account
with an individual view of their billing data. If a member account
must not have its usage or billing data visible to any other
account, or if a separate bill from AWS is required, define multiple master/payer
accounts. In this case, each member account has its own master/payer
account. Resources should always be placed in member/linked
accounts. The master/payer accounts should only be used for management.
AWS multiple account billing strategy
Splitting
the CUR and Sharing Access
Implement groups and roles
Implement groups : Using the groups of users defined in your organizational policies, implement the
corresponding groups, if necessary. Refer to the security pillar for best practices on users, groups, and authentication.
Well-Architected Security Pillar
Well-Architected Lab Basic Identity and Access
Implement roles and policies : Using the actions defined in your organizational policies, create the required roles
and access policies. Refer to the security pillar for best practices on roles and policies.
Well-Architected Security Pillar
Well-Architected Lab Basic Identity and Access
Implement cost controls
Implement notifications on spend : Using your defined organization policies, create AWS budgets to provide notifications
when spending is outside of your policies. Configure multiple
cost budgets, one for each account, which notifies you about overall account spending.
Then configure additional cost budgets within each account for smaller units within the account.
These units vary depending on your account structure. Some common examples are AWS Regions, workloads (using tags), or AWS services. Ensure that you configure an email distribution list as the recipient
for notifications, and not an individual's email account. You
can configure an actual budget for when an amount is exceeded, or use a forecasted
budget for notifying on forecasted usage.
Well-Architected Labs: Cost and Usage Governance
Implement controls on usage : Using your defined organization policies, implement IAM policies and roles to specify which actions users can perform and which actions they
cannot perform. Multiple organizational policies may be included in an AWS policy.
In the same way that you defined policies, start broadly and then
apply more granular controls at each step. Service limits are also an effective control on usage. Implement the correct service limits on all your accounts.
Well-Architected Labs: Cost and Usage Governance
Control access to AWS Regions using IAM
policies
AWS managed policies for job functions
Track project lifecycle
Perform workload reviews : As defined by your organizational policies, audit your existing projects. The amount
of effort spent in the audit should be proportional to the approximate
risk, value, or cost to the organization. Key areas to include in the audit would
be risk to the organization of an incident or outage, value, or contribution to the organization (measured
in revenue or brand reputation), cost of the workload (measured as total cost of resources and operational costs), and usage of the workload (measured in number of organization outcomes per unit of time). If these areas change
over the lifecycle, adjustments to the workload are required, such as full or partial decommissioning.
