Google Cloud Tips and Tricks: Understanding the Resource Hierarchy
So, you want to get started building out your infrastructure on Google Cloud. You’ve read all about how cloud is the future and you’re ready to make moves. But building out on cloud can seem overwhelming. Theoretically, you could spin up a gargantuan server that could wind up costing thousands of dollars in a few short days. Yikes.
It sounds frightening, but it doesn’t have to be. I’ll share a few important tips (small pieces of advice) and tricks (helpful hints)** for organizing your resources on Google Cloud. My hope is that what I’ll share will help you get started quicker, and with a better understanding of what you’re running in the cloud. Let’s make things a lot more simple and a lot less yikes.
Resource Hierarchy
I’ve heard that there’s more than one way to skin a cat. While I don’t know what that means, I do know that there’s more than one way to organize your Google Cloud resources. That’s the resource hierarchy.
The hierarchy can map to your organization’s structure, and allows you to manage access and permissions to all of your cloud resources. Here’s an example of a resource hierarchy, straight from Google Cloud’s official Resource Hierarchy documentation:
Your resource hierarchy could be as simple as a single project under an organization, but if you’ve got bigger plans, there are additional methods for organizing things so that you’ll get a better understanding of which teams are using which resources and are responsible for which costs.
Tip: Do some planning
Understanding the resource hierarchy will enable you to organize your resources in the way that best suits your organization. Do some diagramming similar to the one above to get an idea of what your resource hierarchy might look like. If your organization is grouped by departments, maybe it makes sense for those to map to folders. Take into account the primary attach points for access management — organization level, folder level, and project level — and remember that permissions are inherited from top to bottom.
Trick: Start Simple
The resource hierarchy is flexible. You can always move projects, folders, and change permissions after the initial setup, so don’t feel overwhelmed by your planning. Get familiar with organizing resources while diagramming so you can make smaller and quicker changes.
The Domain and Organization
Here’s the tippy-top of the resource hierarchy. When you sign up for Cloud Identity or G Suite, you’ll be asked to provide a domain. When that’s verified an organization is created. It is essentially the umbrella of all things created in Google Cloud. All projects created will belong to the organization rather than the user who created them. This is especially important in cases where a project owner leaves the organization. Permissions set at the organization level are inherited to folders and projects below.
Tip: One organization is all you need
You might have the need to manage multiple organizations. However, your G Suite or Cloud Identity account is limited to one single organization and one single domain. Consider organizing your sub-organizations as folders instead.
If that truly doesn’t work for your needs, you can manage multiple G Suite or Cloud Identity accounts and therefore multiple organizations. The downside here is that they will be isolated from each other, require separate domains, and lack centralized access and administration. There’s more information on the effects of using multiple organization nodes here.
Trick: Start with IAM
If you’re just getting started and have your organization set up, the initial account you start with will have limited permissions. In fact, you’ll only have the role Organization Admin. An organization admin will be able to access all projects that belong to the organization and assign IAM roles to other users. Before exploring folder and project creation beneath your organization, take a moment to check the Identity & Organization page. From here you’ll be able to migrate projects, create a billing account, expand permissions for yourself or other users, and even delegate the organization admin permissions to others.
Billing accounts and payments profile
A billing account is a cloud-level resource that’s used to manage billing-related functions. This is where you’ll define the payment methods you’ll use to pay for your Cloud usage, access reports and forecasts for your costs, generate a budgets to avoid surprises, and pretty much anything else having to do with bills.
While a billing account is managed in Cloud Console, the payments profile is a Google-level resource that connects to all of your Google services like Cloud, Ads or Chrome licenses. I’m mentioning it here because a billing account is required to be linked to an existing payments profile or one will be created. If you don’t already pay for other Google services you may not need to worry about connecting to an existing payments profile.
Tip: Use a single billing account
You are allowed to configure multiple billing accounts per organization, but I recommend sticking to a single billing account instead. Associating all of your organization’s projects to one billing account will give you a more complete and centralized view of your costs and will make them easier to track.
Trick: Understand billing account users, viewers, and admins
There are 3 types of billing account roles you can delegate: billing account users, billing account viewers, and billing account administrators. While admins can unlink projects, set budgets and initiate billing exports, billing account users can only associate projects and see spend. Billing account admins are also the only ones who can contact billing support. Billing account viewers have the same permissions as users, but with a bit more visibility. Pay special attention to the differences among users, viewers and admins and delegate each role to groups or people accordingly. As a reference, here are the permissions of each role side by side:
Resources
The bread and butter. The meat and potatoes. Resources are any Google Cloud service, like BigQuery, Compute Engine, Cloud Storage, etc. Resources are organized into projects.
Tip: Think about your folders
Projects can be organized into folders. Much like a basic filesystem, a project will inherit the permissions and access from the folders to which it belongs, as well as the organization above that. If you’re planning on having multiple projects on Google Cloud, or if you’ve got multiple teams that will be deploying to Google Cloud under your organization, definitely consider using folders. Like I mentioned earlier, folders are an additional attach point for access management and will make it easier to delegate roles and permissions. It’ll also give you another way to break down billing charges at the end of the month by allowing you to analyze costs by folder rather than individual projects if you export to Big Query.
Trick: Use labels for extra granularity
Labels provide a way to horizontally organize your projects’ resources and help you gain a more granular view of costs. For example, let’s say you’ve got a project with VMs and Kubernetes clusters corresponding with either a staging or production environment. By applying a label with a key ‘environment’ and a value of either ‘staging’ or ‘production’, you can see what spending is per environment instead of just resource type. The more granularity you have, the better you’ll be able to understand your costs and keep them under control. You can read more about labels here.
More Resources to Get Started
To help you get started on Cloud, Google offers a free trial with a $300 credit. Their pricing landing page is right here. To learn more about billing check out the Beyond Your Bill series on Youtube by Mark Mirchandani that goes over most of the content above and much more.
Good luck!
** No, there is no distinguishable difference between a tip and a trick.
