AWS Cloud Governance — Part I

AWS GOVERNANCE

In the past few years AWS has added a plethora of managed services to its rich portfolio. The list encompasses almost any existing IT service, from networking, to security, databases, analytics, A.I. etc. Today, architects can compose cloud services to build complex systems, or integrate them with on-premises resources for diverse use cases. Possibilities are endless.

The “Cloud Era” has indeed allowed business of any size, from startups to very large enterprises, to benefit from services that, when well architected, provide IT costs reduction, a reduced time to market for software products or new business capabilities, IT operations streamlining, to mention just a few. On the other side, cloud adoption has posed brand new challenges to the organizations that have embraced it, regardless their level of maturity. The main challenges can be identified in the below categories:

· Governance · Security · Data Management (Protection, Confidentiality, Sovereignty)

In this article we will examine the specific topic of *AWS Cloud Governance. AWS Cloud Governance can have different meanings to organizations, and by its nature has interplays with the other two categories, but in general it can be defined as the “Set of architectural principles and procedures that must be in place to avoid that the cloud environments become unmanageable”. A poorly defined or absent AWS Governance has direct impact on security, compliance, systems availability, operations and costs. Adopting the Cloud without a Governance framework might prove disastrous for an enterprise that would not be able to exploit the benefits, (easy provisioning, elasticity, etc.), of the Cloud, remaining stuck in an effective “operational and finance nightmare” that may even lead the business to roll back to the on-premise. The tenet of AWS Governance is the “Multi-Account*” architecture. The main benefits of the design are listed below:

· Reduced Blast-Radius · Separation of Concerns · Cost Visibility & Control

In Part I we will examine “Blast-Radius”, “Separation of Concerns” and “Cost Visibility & Control”. In Part II we will explore the core features of Control Tower, the service to build an automated and solid AWS Governance.

Blast-Radius — Today enterprises utilize for their SaaS products or internal applications, a lifecycle that involves in general multiple phases like R&D, Development, Staging, UAT and finally Production. Multi-Account strategy dictates that each SaaS/application an its related environment should have a separated AWS account. The rationale behind this approach is multiple. Introducing such a design will reduce the so called “Blast-Radius”, defined as the “ Scope of applications or resources that may be impacted by issues in the account”. Common events are human or automation tools operation errors, security breaches due to compromised IAM credential, unintended access to Production resources by users not allowed to etc. Let’s examine now the following scenario: Imagine that the fictious Acme.com has deployed UAT and Production environments in the same account and that an automated process, with access to UAT resources, consumes, for testing purposes, the account quotas of the concurrent invocations of the lambda functions part of a SaaS sold by the enterprise. The impact on Production would be huge, with the SaaS product suffering degradations or maybe even experiencing a complete fault. Hitting accounts quota, limits sometimes hardcoded, due to resources contention is not so uncommon. The above example is just one of the many that may lead to quite disruptive events due to a bad practice: “collapsing applications environments under the same AWS account, with the result of an increased Blast-Radius”. Not adopting any Multi-Account strategy would also make the business less trusted by customers, who discover that UAT or Staging environments have been deployed in the same account along with Production.

Separation of Concerns — Adopting a Multi-Account design would also help with the “Separation of Concerns”, the general practice of separating IT roles like engineering, operations, finance etc. In the specific of AWS this means allowing users or automated provisioning processes, (Terraform is a classic example), with specific IT roles to access only the accounts related to their functions. Depending on the different needs of the business the setup may include a variable number of accounts with different purposes, anyway the “operational accounts” that should always be part of the architecture are: “Networking”, “Security”, “DevOps, “Logs Archive”, “Audit”. Separation of Concerns is implemented operationally allowing those actors to login into their specific accounts, and from there: configure resources to be shared via RAM service to the other accounts, or assume specific “cross-accounts” IAM roles, with well defined privileges, to access the destination accounts where they need to perform their provisioning or other activities. A summary of the tasks related to the mentioned IT roles is listed here:

· Networking: VPCs, VPC Peering, Transit Gateways, Direct Connect, Private Links, etc. · Security: Security Groups, Network Firewalls, KMS keys, IAM users & roles, IAM policies, AWS services like Inspector, Security Hub, etc. · DevOps: CI/CD Pipelines for the full life-cycle of applications and various automated cloud provisioning and operational processes etc.

The Separation of Concerns would clarify “Who does What”, allowing teams to collaborate with clear demarcation boundaries for accountability. That would also produce an additional benefit: clearer and more concise IAM policies, avoiding the otherwise inevitable “spaghetti” effect of lengthy and intricated policies that, trying to handle all cases and all exceptions of AWS resources access would become unmanageable. The operational burden of managing such policies would be very high and mistakes in updating those, unnecessary complex rules, would result in issues impacting negatively the environments. Classic examples can be those of IAM roles that lose access to resources or, as already mentioned, a UAT user or other actor who gains unintended reads/writes privileges to Production Databases, S3 buckets, or other restricted AWS resources, triggering a security incident. The Separation of Concerns is pivotal for any business, especially for those operating in highly regulated sectors, (i.e. Banking, Finance, Medical, etc.), to comply with the various frameworks, (SOC2, HIPAA, etc.), of the relevant Regulating Bodies. The main examples are the handling of the transactions logs generated by financial applications or the logs of various AWS services, a with particular attention to security logs, (ALBs, Firewalls, IAM access, KMS and more). To comply with regulators audits, all logs should be injected from all accounts in a separated “Logs Archive” account, accessible only by security personnel to ensure a secure data handling along with a well trusted “custody-chain”. The “Logs Archive” account would also have additional security, long-terms, storage and data immutability features, (like WORM, anti-tamper etc.), not usually needed in others. This is due to being often the logs a very sensitive type of data that could be even used in legal controversies.

We will end this section with the “Audit” account the one storing all reports related to the findings for the entire cloud environments generated by the AWS service Audit Manager. Those reports are key to prove compliance of the deployed cloud environments with the various frameworks or industry standards required by external auditors. Those will be given read access to the “Audit” account to perform their vetting activities without any need for them to access the cloud environments, simplifying and making secure at the same time the auditing process.

Cost Visibility & Control — We can not avoid mentioning another key topic strictly related to AWS cloud Governance: “Costs Visibility & Control”. With todays easy access to cloud resources it is often cumbersome, especially in presence of a not well structured resource tagging policy in place, for the enterprise to provide to the finance team a clear view of which projects or teams are the ones responsible for the various AWS cloud expenditures needed to run the business. This lack of clarity might cause CFOs or other senior stakeholders not to fully understand what is happening in the AWS cloud from a pure finance perspective. Once again, adopting a Multi-Account design would mitigate at least in part this issue. The Cost Explorer service and all others related to various billing reports are capable of filtering costs “per AWS account” so when deployed in their accounts different application environments (UAT, Staging, Prod, etc.) would be reported by Cost Explorer all with their linked expenditures. This would help understanding “who is spending on what” and finance could now allocate defined budgets for each app, team, or project, track consumption, and set alerts for breached or near to thresholds spendings that would then be sent to the relevant actors (Team Leads, Finance, etc.). Cost Control is another hot topic, achievable, (as we`ll see in section II), by the introduction of Control Tower SCPs (Service Control Policies ). SCPs can be used, (their scope for Governance go much beyond that), to control AWS costs by enforcing AWS regions allowed to deploy which AWS services and, for compute resources like EC2, RDS, etc., their hardware specifications in relation to the their environments, (UAT, Testing, etc.). SCPs alone, anyway, cannot totally govern cloud costs. Cron jobs, (Scripts, lambdas, EventBridge rules etc.), should be setup to find idle or orphaned resources, (common in Test or POC environments), and to alert IT teams for further investigations. Cost Visibility & Control are key to AWS Governance because they can avoid resources waste and spiraling costs. A mature enterprise FinOps always starts from those pillars.

Regardless the size of an enterprise, cloud architects should never neglect to plan for Governance. This is achievable by adhering to the Multi-Account tenet: “Separated AWS accounts per application and per environment”. Exceptions to this principle should be minimal, unless not operationally or technically feasible. Not planning, since the beginning, for a Multi-Account architecture would make the cloud environments both not manageable and not compliant, with the business possibly forced to a lengthy, operationally risky and costly migration to split the monolithic accounts architecture into a well architected one based on the Multi-Account principle.