The advancement of the public cloud has accelerated the innovation and implementation of applications and services significantly. On-demand providers such as Amazon Web Services returns the agility and velocity controls back to the user. You no longer need to wait for your service provider to deploy your servers, grant network and user access or even procure additional resources. With a few clicks or API calls, you have virtually unlimited computing and storage resources at your disposal. Conversely, the freedom to deploy resources at any time has introduced a new dilemma - organizing and controlling spending.
However, with AWS Organizations, you now have the resources to organize, monitor and implement guard rails to ensure usage and spend are under control.
AWS best practices recommend implementing a multiple AWS account structure for each workload or environment. For example, you should have individual accounts for your production, staging and development environments, log aggregation and security event monitoring. There are many benefits of adopting this type of account structure such as added security and aggregated billing and payment methods.
AWS Organizations allows you to bring all of your AWS accounts under one consolidated payer account. This means your billing details, payment method and invoices are defined and located in your payer account. Any new accounts you create in the future will automatically roll up to your payer account without any additional configuration. With AWS Cost Explorer or Cloud Management Platform tools such as CloudHealth, you have a single pane of glass to view your cost and usage metrics.
Resource tagging is a great way to categorize your resources which help you define details not innately obvious on your invoice — for example, applying tags to define the cost center or the engineering team responsible for maintaining the resources. While great in theory, consistent resource tagging can be a challenge. Case sensitivity, spaces, misspellings and similar but different values (ex: yes vs true, disabled vs off) in your tags can create more of a mess than they were intended to prevent.
Tag Policies in AWS Organizations allow you to define a consistent tagging strategy across your resources and member accounts. You can define tag keys, including how they should be capitalized or their allowed values. In addition, you can optionally enforce a Tag Policy which will prevent any non-compliant tags from being implemented.
Service Control Policies
Service control policies (SCPs) are guard rails that can be implemented in AWS Organizations that have precedence over all access levels in member accounts, even the root login. SCPs provide additional governance facilities that can enhance security, such as disallowing users from disabling auditing trails such as CloudTrail or AWS Config. SCPs also allow you to manage usage and spend in member accounts.
For example, over-provisioning EC2 instance sizes is a common problem affecting development sandbox accounts. You can ensure spending within these accounts does not quickly balloon out of control by implementing an SCP which only allows the creation of t2.micro EC2 instance types.
A major attraction to AWS is the pay-for-what-you-use nature of its services. That said, some services can quickly add to your monthly bill. The region in which you run your resources also affects your spend as pricing can vary between regions.
Services in us-west-1 (N. Cal) are slightly more expensive than us-west-2 (Oregon) - unless you have a requirement to run your workload in California, us-west-2 makes the most sense from a cost perspective. With an SCP, you can deny the use of any AWS services in us-west-1 and limit the use of unnecessary services in us-west-2.
To learn more about how leveraging AWS Organizations can be an important component in optimizing your cloud environment, reach out to Mission, an AWS Premier Consulting Partner.
Lower Your AWS Bill Today
Take immediate action to lower AWS cost today with the Mission Instant Discount Program (IDP).