One of our AWS Managed Services customers has a multi-AWS Organization account structure - three Organizations in total.
While not a common deployment strategy, in this particular case it satisfied the client’s specific charge-backup requirements for the various geographical regions where the client operates.
Since resources exist in several AWS Organizations and multiple AWS accounts, we needed a simple way to provide a ‘compliance’ dashboard.
We satisfied this requirement by deploying AWS Config across all AWS accounts in a set of ‘approved’ AWS Regions. We then centralized all reporting and configuration history into a single AWS account - which we refer to as the ‘security account.’
Within the security account, several AWS Managed Config Rules monitor for compliance across all AWS resources.
We needed to deploy AWS Config across three distinct AWS Organizations, eight AWS accounts, and in a minimum of three AWS Regions in each account.
Without some form of automation, this task would have been time-consuming as well as error-prone. To meet the customer’s timelines, we created several CloudFormation templates - one for AWS Config, one for AWS Config Rules and another for the central S3 bucket. We simplified deployment across all AWS environments with the use of GitLab CI scripts.
By using CloudFormation, we were able to streamline the deployment and maintenance process and ensure a consistent configuration across each AWS Organization and AWS account. For example, we record changes to all supported AWS resources and collect information about global resources in a single AWS Region for each AWS account.
For this deployment, we created a single S3 bucket located in the security account. The bucket is used by AWS Config in each Account to store configuration snapshot information. Snapshots are stored for each AWS account every six hours.
To ensure the confidentiality and integrity of the data AWS Config collects, we protected the centralized S3 bucket with both an S3 Bucket Policy and Access Control Lists (ACLs) during the deployment.
In some situations, business units within the organization create large development environments for new projects or updates to existing infrastructure. Although these environments are automatically turned off at night, the customer wanted to help control costs by using only Burstable instance types (T2 or T3).
To help them achieve this requirement, we created a Custom AWS Config rule which was invoked by configuration changes on EC2 instances in the account. The rule evaluated each EC2 instance tagged as development and set a compliance status based on the instance family.
The administrators were able to use this rule to educate their internal user base or make changes to the deployed resources to help manage costs.
Finally, we deployed several AWS Managed Config Rules in the AWS Config deployment in the security account. For this particular deployment, we used a combination of triggered and periodic Config Rules.
By triggering rules on configuration changes, we’re able to evaluate compliance immediately as configuration items are modified. As an example, we deployed the ‘required-tags’ rule to evaluate tags associated with resources during deployment.
Periodic Config Rules allow us to evaluate compliance on a schedule. In this particular deployment, we validate the Account password policy every twenty-four hours to ensure it meets the documented corporate standard.
Like what you read? Why not subscribe to the weekly Orbit newsletter and get content before everyone else?