AWS Cloud Foundation Series, part 2: Governance
Taking control of your cloud foundation
In the previous blog post of this series on the AWS Cloud Foundation, we looked at the capability-based approach defined by AWS to set up an AWS Cloud Foundation. The first capability, based on that approach, is Governance.
In general, “Governance” refers to structures, policies, and practices that determine how decisions are made, how power and authority are distributed, and how accountability is maintained. This definition also holds in the context of setting up a Cloud Foundation for your business.
In this blog post, we look at the decisions that need to be made at the start of your cloud journey to provide the Governance capability for your organization. The benefits of having this capability in your organization include:
- Ownership of cloud foundation: It becomes clear who is responsible and thus accountable for which part of the cloud foundation of your organization. This increases the chances that the other capabilities are developed and maintained properly, allowing you to run your AWS workloads in an efficient, secure, reliable, and cost-effective way.
- Avoid unnecessary mistakes: By spending some time upfront on decisions that guide the rest of your cloud journey, you can avoid unnecessary mistakes and the cost that comes with remediating those mistakes later on.
Governance is a capability that guides all other capabilities that we discuss in this series. We define a structure of ownership for these capabilities and define policies that need to be adhered to while building them.
The Structures
The first thing we want to define is the governance structure. AWS has presented a set of seven functional areas, each having one owner who is responsible for that functional area:
Please read the first blog of this series on the AWS Cloud Foundation for more info on this if you have not yet done so. In the illustration above we can see the seven functional areas.
The first order of business when starting with the Governance capability is to designate someone to be the owner of the Governance functional area. That person is responsible for everything else that is mentioned in the rest of this blog.
Once you have done so, this owner should designate the other members of your organization to be owners of the other functional areas. However, remember that for each of these functional areas, the owner can create a team for support. Once this is done, your organization has a governance structure to achieve a solid Cloud Foundation.
Based on your organization and the workloads you are going to build for your business, you are free to create any kind of structure on top of or next to this Cloud Foundation structure. For example, a common approach is to assign an owner per workload.
One common anti-pattern is to not assign functional area owners, thus leading to the workload owners becoming “shared owners” of the foundation capabilities, which effectively means that no one is responsible for them. This leads to a foundation that is created based on just-in-time needs of the functionality to be built instead of a well thought out foundation based on best practices.
The following is an example overview of owners in a Cloud organization with 3 workloads on AWS:
Each of the functional area owners only work on developing foundational capabilities for the organization and not with any functionality that needs to be built for the workloads.
However, the workloads are upon the foundation and use of the foundational capabilities.
For example, in the next blog in this series, we cover the capability of “Identity Management and Access Control”. The owner of the Security Functional Area is responsible for developing this capability. Once that capability is available for the organization, all workloads can make use of it.
This increases the speed of development and introduces consistency since the workload owners do not have to think about this (too much) and make use of the same Identity Management and Access Control capabilities as the other workloads in the organization. However, the functional area owners can always take input from the workload owners when specific demands arise and expand the capability in this case.
As said in the first blog, depending on the size of your organization certain people might need to take on multiple owner roles. You should assess your organization and decide how to assign these roles in the best way.
It is up to you to decide how to map these owners to your organization. For example, the owner of the Finance functional area could be the CFO or someone who reports directly to the CFO. The same with Security and the CSO and so on.
With this structure in place, it is now clear who is responsible for what part of the cloud journey, who has authority, and who is accountable.
AWS Cloud Foundation: the Policies
With the governing structures in place, the next step is to decide on the governing policies. These policies guide decision-making for your Cloud Foundation and everything built on top of it.
We start by defining some starting policies that have to do with the entire organization and that apply to all foundational capabilities, however, throughout this blog series, we introduce more policies as we go through the capabilities. As your organization grows, so will the Governance capability of your organization.
Policy: Security and Compliance
Depending on the type of business, geographical location, and other factors, you need to adhere to certain regulations when it comes to security and compliance. This is always the case for any business and also holds for when you run your business on AWS.
Since AWS is now responsible for part of the stack of your workloads, it now falls on AWS to provide proof of compliance to different types of regulation. However, AWS is not completely responsible for your entire workload. This is what AWS refers to as the “shared responsibility model”:
AWS shared responsibility model.
As we can see in the image above, you as a customer are still responsible for certain parts of your workload. However, this image is not completely accurate for all scenarios. You can shift even more responsibility to AWS depending on which services you use:
Responsibility based on level of service usage.
For example, there is a difference in responsibility if you choose to use AWS EC2 (IaaS) for your computing needs instead of AWS Lambda (PaaS), since with Lambda you are no longer responsible for the OS and patching security vulnerabilities. However, if you can find a SaaS for the functionality you need, you will shift even more to the right and have fewer responsibilities.
How does this information help guide you in building your workloads? First of all, understanding the shared responsibility model is important so that you are aware that just because your workloads run in AWS does not mean that they are automatically secure. This means that all security regulations that would hold for your organization when running your workload outside of the Cloud still holds now.
For example, when looking at the General Data Protection Regulation (GDPR), AWS provides many tools to help you manage certain aspects. However, it is still your responsibility to use these tools accordingly. If we take the “right to be forgotten” principle in GDRP, AWS provides all the mechanisms to be able to delete a user’s data, however, you are responsible for making use of this in the correct way.
Knowing this upfront can help you design your workloads in a way that adheres to the regulations that are relevant to your organization while making use of AWS to lessen the burden.
Proof of compliance
When you need to provide proof of compliance to external auditors, you must combine the proof of compliance of your organization and that of the AWS services you use in your workload.
For the AWS proof of compliance, AWS has created a service called AWS Artifact. It can be accessed through the AWS console and contains reports and agreements.
Reports are a set of documents that prove that AWS adheres to certain regulatory programs. These are performed by external auditors. You can search through all of the reports and download the ones that you might need to give to external auditors.
To download a report, you first must download a pdf that includes the terms & conditions as well as instructions on how to actually download the report itself.
Agreements are legal agreements that you can make with AWS when this is necessary. One situation is when your business deals with personal health information (HIPAA). In this case, you can also download the agreement and follow the instructions to accept this agreement. You can always see in this overview which agreements are active:
There are only 5 agreements, if these do not apply to your organization then you can skip this.
Policy: Regions
AWS runs all over the world at this point. They operate in different “Regions” across the world. When setting up your Cloud Foundation on AWS, it is important to decide which Regions your organization will operate in. This policy creates the boundaries that other foundational capabilities need and ensures that no resources are being used in unwanted Regions.
These Regions are geographical locations around the world where AWS has multiple physical data centers. Within each Region there are multiple Availability Zones. An Availability Zone is a data center or a cluster of data centers within a Region. Availability Zones are isolated from each other, meaning that they do not impact or depend on each other when it comes to power, networking and connectivity. AWS provides an overview of all Regions and Availability Zones.
How do you decide as an organization which AWS Regions to deploy your workloads in? Here are the most important (general) factors:
Compliance and Legal Requirements
If you don’t adhere to the Compliance and Legal Requirements, then none of the other points in this list matter. Laws in certain countries or regions may dictate its mandatory to store and process data in a specific geographic location. This is particularly relevant in industries like finance, healthcare, and public sector. Specific compliance requirements (e.g., GDPR in Europe) might also influence the choice of Region to ensure adherence to legal and regulatory standards.
Latency
Where will the end-users be geographically when using your workload? Deploying applications closer to the end-users can significantly reduce latency, improving user experience. If your users are in multiple regions, then it is possible to deploy to multiple Regions. More on that later.
Cost
The cost of AWS services can vary between Regions. Depending on the service mix, choosing a Region with lower costs can lead to significant savings. Also consider the cost of data transfer both into and out of AWS Regions, especially if your architecture involves significant data movement. Keeping data transfer inside one Region is more cost-effective than moving data between Regions.
Most AWS services have a page related to the pricing of that service and they allow you to select different Regions to be able to see the difference in pricing.
Service Availability
Not all AWS services are available in every Region. If your application depends on certain AWS services, you’ll need to choose a Region where these services are available. Also, AWS often launches new services and features in certain Regions before rolling them out globally. If access to the latest AWS innovations is critical, this may influence your Region choice.
For the United States, the US-East(N. Virginia) region tends to get the newest functionality first. In Europe, this has been the EU-West (Ireland) region.
Disaster Recovery and High Availability
To design a robust disaster recovery plan, it’s essential to deploy applications across multiple Regions or Availability Zones to ensure that an outage in one Region doesn’t impact your entire operation. The number of Availability Zones in a Region can affect your ability to design highly available architectures.
The newer regions tend to have less availability zones, so if your High Availability plan requires more than 3 Availability Zones in a Region, you might be better off not using the newest regions.
Multiple Regions
If based on the information above it turns out that you need to use multiple regions, then it is still recommended to choose one AWS Region as your main region. Typically this would be the AWS Region closest to your organization’s headquarters. Later in this blog series we cover the capability “Workload Isolation”, where we look at how to structure your AWS account structure. The decisions made here in the Governance capability are there to determine the best structure.
Policy: Procurement Agreements
Depending on the size of the workload you want to run on AWS, a procurement agreement with AWS might be beneficial for your organization. Such an agreement outlines the terms and conditions under which you purchase AWS resources.
The agreement can contain a description of services to be used, potential pricing and payment terms that can be beneficial to you based on the volume of usage, SLA’s that AWS must adhere to, the duration of the agreement, details about the support from AWS and many legal terms and conditions.
Want to know if a procurement agreement is a good fit for your organization? Contact AWS Sales or a Partner in the AWS Partner Network (like Luminis).
Before you do this, however, it is useful to first identify your needs. If you are migrating from on-premise to the Cloud for example, then it is useful to know what the current production load is and what kind of functionality you need. If it is a new project/product, then it can be useful to at least have some estimates for the future production load and needs. In your discussion with the AWS Sales representative or partner this information is necessary.
The process
Once you have made contact with them, they guide you in the process. The procurement agreement looks different for each company. The best thing to do is indentifying your needs and make contact.
Once such a procurement agreement is made (or not), this information guides you to develop your foundational capabilities or workloads.
Suppose your procurement agreement provides significant discounts on Amazon EC2 and Amazon RDS when you commit to a certain level of usage over a three-year period. As a result, when developing a new web application, you decide to architect it using EC2 instances for the web servers and RDS for the relational database backend to take advantage of these discounts. Furthermore, knowing that you’re committed to these services helps justify investing in automation and optimization specific to EC2 and RDS, such as automated scaling and backup solutions, to maximize their value over the agreement period.
The AWS Cloud Foundation Culture
With the structure and initial policies in place, you can start to develop the other Cloud Foundation capabilities. You need to hold regular meetings with the functional area owners to follow the progress, learn from each other and make sure that all areas are respecting the Governance policies that are defined for the organization.
At some point, you need to start working on the actual functionality that needs to be built. It becomes a balancing act to decide what work to prioritize, be it to continue working on your Cloud foundation or start to work on functionality.
In an ideal world, you would have all the time and budget to develop all of the foundational capabilities. However, in the real world this is not possible. My advice would be to at least develop the “Governance” and “Identity Management and Access Controls” before starting with workload functionality. After that, hold regular meetings and decide how to move forward, developing foundational capabilities while building workload functionality.
Another suggested action is to motivate your colleagues to get certification and training in AWS. There are many ways to learn more about AWS. I used CloudAcademy and Udemy in the past to learn about AWS, however, there is also a lot of content to be found on Youtube.
As for certifications, it would be beneficial if all colleagues could get the AWS Cloud Practitioner, which covers foundational level knowledge of AWS. From a governance point of view, making budget available, learning about AWS and getting certifications is strongly encouraged.
The benefits of having knowledgeable people are not only beneficial for your workloads, but also for your Cloud Foundation, as many of the topics discussed in this blog series are also present in these certifications.
Up next in AWS Cloud Foundation Series: The Identity Management & Access Control
This blog covered the Governance capability for an AWS Cloud foundation. We covered the structures that need to be in place to move forward and which policies you need to define at the start of your cloud journey. This helps create ownership for the cloud foundation and prevents us from making unnecessary mistakes later on.
These policies are only some initial policies for your organization. This blog series also covers items such as “Workload Isolation” and “Cloud Financial Management.” However, this framework sees these capabilities as separate from Governance.
The next blog post in this series covers the Identity Management & Access Control capability.
