Your cloud landing zone is the foundation of your cloud infrastructure. How you organize your resources and set up controls and policies will have a huge impact on whether your cloud journey is smooth sailing or rough riding.
For instance, a well-structured resource hierarchy will make your life easier when it comes to allocating cloud costs and configuring access control. A poorly set-up resource hierarchy will have you scratching your head over which team is responsible for which cost and increase the chances that someone sees data they aren’t supposed to see.
And while every cloud provider describes a set of best practices for setting up your cloud landing zone for success, we still see some common anti-patterns being performed.
Applying our experience gained through helping 3,000+ digital native companies with their cloud challenges, we’ve highlighted the top 7 landing zone anti-patterns that we observe most and what you should be doing instead.
Let’s dig in.
Anti-Pattern #1: Not utilizing Organizational Units (OUs) and/or Folders
Failing to establish proper Folder (Google Cloud) or Organizational Unit (AWS) structures can lead to resource sprawl and difficulties in managing access and permissions.
Ideally, your cloud resources should be organized in a way that matches your actual organization structure, and Folders/OUs are a great way to set that up. They’re used to separate and categorize resources for different departments/teams within your organization. Within these, you’ll have projects (Google Cloud) or accounts (AWS), with each of your workloads belonging to a single project/account (more on that in our next anti-pattern).
Folders and OUs are also great for setting guardrails via policies and permissioning. For example, you may want to block users in a specific department from accessing regions you don’t use. Or you might want to prevent development teams from using specific instances like T2Ds in Google Cloud or X1s in AWS.
But while Folders/OUs can be nested, you shouldn’t make things too complicated unless you really need to. The more levels that you add to your cloud resource hierarchy, the more hassle you’ll encounter trying to manage everything.
Anti-Pattern #2: Housing all resources within a single AWS account or Google Cloud project
When you group all your workloads together in a single account or project, you make it challenging to manage costs, track usage, and enforce security controls.
For example, imagine you have resources related to two different applications located in the same Google Cloud project. By not isolating resources into different projects/accounts, you become overly reliant on having a perfect tagging policy (more on that in the next anti-pattern). Tracking expenses and attributing costs to specific teams, applications, or environments becomes convoluted, hindering your ability to identify opportunities for cost savings and efficient resource allocation. This will only get more complicated as your organization grows.
Additionally, when all resources are concentrated within a single account or project, any security breach or misconfiguration can potentially affect all services and workloads (thinking in terms of blast-radius reduction can help mitigate the impact of negative events).
When possible, go with a single workload in a single account/project. However, sometimes when you have small workloads that are similar to each other in terms of scope, you may want to put them all in the same account (see illustration above).
Finally, while you do have less administration with fewer accounts, by separating your workloads you benefit from built-in operational security features like permission structures and rate-limiting (anyone who’s tried to put 100+ buckets into an account will be aware of those limits).
Anti-Pattern #3: Underutilizing Tags/Labels (or not using them at all)
Tags (AWS) and Labels (Google Cloud) are used to provide fine-grained information around your cloud resources.
Use cases include:
- Billing enrichment (ex. adding cost center information to a resource)
- Environment/application classification (ex. specifying data-security levels)
- Automation (ex. determining reboot schedules)
…but let’s focus specifically on the first point and why tags are so important.
Tags and labels play a crucial role in cost allocation and tracking. And good cost allocation sets you up for success when managing your cloud spend.
Without proper tagging, it becomes challenging to associate expenses with specific projects, departments, or teams. Failing to utilize tags and labels means missing out on the opportunity to generate detailed insights, track usage trends, and generate meaningful reports for informed decision-making. This lack of granularity can lead to cost inefficiencies, overspending, and difficulty in identifying areas for optimization.
With tagging, it may be tempting to define a highly-detailed structure with many different tags that should be applied to every resource. While this level of tagging is admirable, it’s unrealistic when getting started. We recommend starting small, and using 2-3 tags only, but being very strict on enforcement of these.
The three absolutely required tags (in our opinion) are:
- Application name
- Team
- Stage/Environment
Since tags are case sensitive, we recommend adopting a naming standard, such as snake case, to avoid having duplication of tags. The names can, of course, be changed to suit your company culture, but should be descriptive and clear. In this case, “app_name” refers to a microservice or workload name, and “env” is a development stage, such as “development,” “testing” or “production.”
Values for both fields should ideally come from a relatively standard list – again if you have users tagging their resources with variations of “Website – Frontend,” it could lead to problems analyzing the data.
One example where tags will help you better understand your cloud consumption could be when there’s a ‘shared resource’ account within an organization and all the database resources (which are used by multiple teams) are located there. For each database, you can assign a tag or label that determines which team should be charged for usage of that resource.
__________
For more information about cloud management strategies, visit www.doit.com.
