How AWS Control Tower customisation can assist in automating cloud infrastructure governance?
Technology is the bedrock for almost every single industry out there. With that in mind, technology (specifically cloud based platforms) goes through a high rate of innovation and fast-paced evolution. The challenge these days is to deliver constant improvements while providing bedrock-like stability. We have seen this trend in the recent decades by the emergence of Agile, DevOps and similar techniques.
When Infrastructure as Code (IaC) was introduced, it meant we could have all of our infrastructure executed via self documenting code. IaC allowed companies to produce complex cloud infrastructures consistently and fast. IaC also allowed companies to apply coding best practices to the infrastructure, practices like Peer Code Review, Coding Standards, Automated Security check and so forth. At a glance it seems as we may have reached an optimal place on keeping pace with the rate of change in the cloud, but as they say: ‘The buck doesn’t stop here’.
Businesses often need to manage several cloud accounts with many of their employees requiring some level of access to different accounts or cloud solutions. Each business unit has different level of cloud maturity and different go to market requirements. This is where the current techniques and practices falls short as organisations resort to traditional methods to govern their ‘Cloud’.
Governance strategy is often written down as procedures and offloaded to CCoEs (Cloud Centre of Excellence) or similar teams to ‘manage’ and ‘enforce’ the strategy. This means that we have now two issues:
- Your CCoE has to grow to accommodate the company’s growth and;
- Humans are still in charge of applying the governance strategy
In this model your CCoE has to be up to date with the latest changes and trends in the cloud and have enough time to review and manage the governance of how ever many cloud accounts there are. We need a fundamentally new approach to managing the cloud that allows decentralized teams to adopt the cloud and run at cloud-speed, while still maintaining the best practices and optimum security/efficiency required by the enterprise.
Governance on AWS
To be clear, when we talk about governance, we are also including Compliance, Security Requirements and Overall Best Practices. The ‘Governance Strategy’ document should outline the organisation specific and industry specific governance requirements as well as defining key organisational metrics on how the mechanism of the governance is performing. This is a topic for another day, but for now, let us briefly touch of specific AWS Service which are used as part of governance on AWS.
At its core AWS Organisations provides the highest level of governance across your enterprise, whether you are managing 10 accounts or 1000 accounts. You are able to structure your accounts using logical containers called Organisation Units (OUs). Structured OUs allow for granular or broad application of Service Control Policies (SCPs). Remember AWS Organisation is a service enabled on the ‘Management Account’, an account purely used for managing all other accounts which is often performed by AWS Control Tower.
AWS Control Tower provides the platform for managing the ‘governance’ of your organisation. Being established in a Home Region, AWS Control Tower uses Guardrails to Prevent or Detect governance drifts. Preventative Guardrails (powered by Service Control Policies) DENY specific actions on specific resources and can be applied on OUs at any levels. Detective Guardrails (powered by AWS Config) monitors activities within the accounts and mark resources or accounts as non-compliant if the activities is performed is outside of the governance boundaries.
The number of guardrails that can be created are virtually endless, below are a few example controls you can achieve by using guardrails:
- Restrict use of certain AWS Regions (Preventative)
- Prevent use of certain EC2 Instances (Preventative)
- Identify un-encrypted data At Rest (Detective)
- Detect Whether Versioning for Amazon S3 Buckets is Enabled (Detective)
- Disallow Delete Actions on Amazon S3 Buckets Without MFA (Preventative)
As part of best practices, when initialising the AWS Control Tower, it creates few extra accounts like Audit Account for amalgamating all security and auditable events; And the Log Archive Account, a highly restricted account to hold all things log related.
There are few more AWS services which assist in applying and maintaining the governance function like, AWS Account Factory, AWS Service Catalogue.
Establishing AWS Organisation and AWS Control Tower is a giant step ahead of managing multiple of individual accounts separately and ensuring every single one of them is in line with your organisational requirements. However, if we look at this setup from a far enough distance, we can see the same pattern and issues as when we had to manage the infrastructure without code. What we see is a collection of AWS Config Rules, SCPs, Baselining Templates, Custom setups like Transit/Network Account, Shared Services Account which are tightly coupled with the rest of the accounts.
At its core AWS Organisations provides the highest level of governance across your enterprise, whether you are managing 10 accounts or 1000 accounts. You are able to structure your accounts using logical containers called Organisation Units (OUs). Structured OUs allow for granular or broad application of Service Control Policies (SCPs). Remember AWS Organisation is a service enabled on the ‘Management Account’, an account purely used for managing all other accounts which is often performed by AWS Control Tower.
AWS Control Tower provides the platform for managing the ‘governance’ of your organisation. Being established in a Home Region, AWS Control Tower uses Guardrails to Prevent or Detect governance drifts. Preventative Guardrails (powered by Service Control Policies) DENY specific actions on specific resources and can be applied on OUs at any levels. Detective Guardrails (powered by AWS Config) monitors activities within the accounts and mark resources or accounts as non-compliant if the activities is performed is outside of the governance boundaries.
The number of guardrails that can be created are virtually endless, below are a few example controls you can achieve by using guardrails:
- Restrict use of certain AWS Regions (Preventative)
- Prevent use of certain EC2 Instances (Preventative)
- Identify un-encrypted data At Rest (Detective)
- Detect Whether Versioning for Amazon S3 Buckets is Enabled (Detective)
- Disallow Delete Actions on Amazon S3 Buckets Without MFA (Preventative)
As part of best practices, when initialising the AWS Control Tower, it creates few extra accounts like Audit Account for amalgamating all security and auditable events; And the Log Archive Account, a highly restricted account to hold all things log related.
There are few more AWS services which assist in applying and maintaining the governance function like, AWS Account Factory, AWS Service Catalogue.
Establishing AWS Organisation and AWS Control Tower is a giant step ahead of managing multiple of individual accounts separately and ensuring every single one of them is in line with your organisational requirements. However, if we look at this setup from a far enough distance, we can see the same pattern and issues as when we had to manage the infrastructure without code. What we see is a collection of AWS Config Rules, SCPs, Baselining Templates, Custom setups like Transit/Network Account, Shared Services Account which are tightly coupled with the rest of the accounts.
Customer Success Story
One of the TechConnect larger enterprise clients are in transition of moving into the cloud as part of their modernisation program. The transition means that traditional governance measures are not going to be applicable. For example, the function of Cloud Viability Assessment would almost need to be reversed.
To better grasp the size of the operation, they comprise of 2000+ employees with 20+ internal departments and 55+ external departments scattered across the world. It is also worth mentioning that the client is highly technical in their field (but just not in cloud technologies as of yet).
Given the scale and timeline of the migration, at TechConnect we became the temporary custodian of the governance function for our client. This challenge meant that the governance function has to be Transferable, Repeatable, Efficient and Easy to modify.
Based on the ‘Customization for AWS Control Tower’ implementation, at TechConnect we have added few extra functionalities to allow complete Governance as Code (GaC) for our client. This means that based on the Governance Strategy document, we are able to convert that function into code and subject that change to the usual Coding best practices. Governance changes are written in code (as Policies, CloudFormation or Scripts) and are peer reviewed and are tested in a ‘Test Organisation’. Not only this approach is transferable to our client after the migration, it allows for a much smaller team to manage and enforce governance, no matter the size of the enterprise.
For our client, implementing the GaC provided faster go to market for each team with confidence that their solution is meeting the organisation’s governance requirements. The speed is achieved by:
- Providing each team the independence to build knowing they will not cross the organisation governance boundaries and;
- Reducing the number of gates (Security, Compliance and etc.) by automating the process.
Where to start?
We have gone this far without mentioning AWS Well-Architected Framework. AWS WAF and WAR (Well-Architected Review) are the glue which brings all the pieces together. As an AWS Well-Architected Partner, here at TechConnect, we offer WARs alongside our other services.
“With Governance as Code, central IT is moving from gatekeepers to enable rapid innovation by giving developers easy access to the underlying infrastructure while, also, programmatically keeping track of all the guardrails put in place to ensure governance.” – Mazzi Nabavi | Solutions Architect
If your organisation can benefit from GaC then we would recommend to run a Well-Architected Review using the Management and Governance Lens (M&G Lens) on one of your main AWS accounts. As an outcome, we can provide a roadmap (transition path) to automate your organisation could governance.