Universities, colleges, vocational schools, and other institutions of higher education often have unique IT needs compared to other types of enterprises. This guide presents best practices and outlines a number of critical issues to resolve when setting up your institution's Google Cloud environment.
Here are some definitions of basic terms to make the guide more understandable.
- Org node
- The Organization node (Org node) represents an organization such as your school. It's the root node in the hierarchy of Google Cloud resources.
- Folders organize resources under your organization. When you configure Identity and Access Management (IAM) policies at the folder level, policies apply transitively to resources that are contained in the folder.
- The project level is where you enable and use all Google Cloud services, manage APIs and billing, add and remove collaborators, and manage permissions.
- IAM controls policies for your organization and projects. It governs what level of access project members have to manage virtual machines (VMs), logs, and other resources.
- A role is a collection of permissions. You cannot assign permissions directly to users; instead you grant the user a role. When you grant a role, you grant all the permissions that the role includes.
- A physical asset, such as a computer or hard disk drive, or a virtual asset, such as a virtual machine (VM). Some examples of resources include projects, Compute Engine instances, and Cloud Storage buckets.
Setting up G Suite for Education
If your school is investigating the capabilities of Google Cloud, setting up G Suite for Education is often the starting point. Even if you don't intend to use Gmail, setting up G Suite for Education and disabling unused services like Gmail allows you to take advantage of user accounts and groups for Google Cloud identity and authentication. For commercial entities that don't qualify for free G Suite for Education accounts, Cloud Identity is an option.
Google Cloud provides a hierarchical container system that consists of organizations, folders, and projects. Within those structures, you can organize other resources such as Compute Engine virtual machines (VMs) and Pub/Sub topics. This hierarchy helps you manage aspects such as access control and configuration settings that are common to multiple resources. You can programmatically manage these resources by using Resource Manager.
Large institutions, including many universities, often have numerous projects and users that interact directly with Google Cloud resources. To best support existing IT governance and access control strategies, we recommend that you implement a centralized approach to Google Cloud resource organization.
Organizations and folders
Resources are organized with the Org node at the root. Folders can be nested up to four levels beneath the Org node. These folders can contain projects, which in turn contain other resources as child nodes under the projects. Each resource has exactly one parent. When you set access control policies and configuration settings for a parent resource, its child resources inherit those policies and settings.
An Org node ensures that all projects that users create in your G Suite for Education domain are visible to the super admins. Each primary domain in G Suite for Education has one Org node; secondary G Suite domains do not get their own Org node. By default, the G Suite super admin has irrevocable access to set policy for the organization. For organizations that have separate IT and cloud administration, the G Suite super admin must assign an organization admin to administer the organization.
The structure of a typical Google Cloud organization might look like this:
If projects were created prior to establishment of the Org node, you can migrate these orphaned projects into the Org node.
To list all projects in your Org node, run the following command:
gcloud projects list --filter "parent.type=organization parent.id=$ORG_ID"
When a school with a G Suite for Education domain is adopting Google Cloud, the default configuration is to have a single Org node. The following section discusses single versus multiple Org node approaches.
When to use a centralized Org node
The centralized Org node is mapped to the G Suite domain, which is the source of truth for IAM. You can set up each folder with its own central admins along with separate IAM and other policies.
For more information, see these resources:
You can host global resources such as cross-project networks and shared images in a folder with permissions that allow access to all users in the organization.
When to use separate Org nodes
If you want to treat departments within the school as isolated entities with no central administration, consider creating separate organizations as shown in the following diagram.
To implement this configuration, you set up
as separate primary G Suite domains, resulting in discrete Org nodes. Use this
option only if you have decided to:
- Maintain separate identity domains.
- Keep IAM, custom roles, billing, quota, and configuration
settings distinct from the central
For many schools with centralized IT governance, managing two separate Google Cloud environments creates additional overhead. Also, policies among multiple Org nodes can diverge over time.
How to use folders
Folders enable you to organize your Google Cloud resources, apply policies, delegate administrative privileges, and give departments and teams more autonomy. Folders also help you administer policies and control access above the project level. Folders, projects, and resources that are nested within a folder inherit the policies of the parent folder.
Here are a few scenarios where using folders might be appropriate:
- Your institution has distinct schools, such as for engineering, business, and liberal arts, each with its own IT group.
- You are mapping to an established structure that is based on an LDAP directory, such as Microsoft Active Directory.
- You want to segregate projects by use case, such as IT infrastructure, research computing, or teaching and learning.
Projects and resources
Any Google Cloud resources that you allocate and use must belong to a project. Think of a project as the organizing entity for what you're building. A project consists of the settings, permissions, and other metadata that describe your applications. Resources within a single project work together smoothly by communicating through an internal network, subject to rules that vary by region or zone. The resources that each project uses remain separate across project boundaries; you can link them only through an external network connection or a shared Virtual Private Cloud (VPC) network.
Each Google Cloud project has the following:
- A project name, which you provide.
- A project ID, which you can provide or Google Cloud can provide for you.
- A project number, which Google Cloud provides.
When you set up a new project, you might base it on one of these scenarios:
- Ownership of applications or projects, such as setting up a project around a workload or small team.
- Dividing an application into production and non-production projects. This way, changes made in the non-production test environment will not affect the production environment, and changes can be promoted or propagated by using deployment scripts.
- Segregation of computing and data resources between labs or even projects within a lab. This segregation allows full autonomy and data separation between projects, which is useful if a lab is working on multiple projects with competing stakeholders.
Projects must be associated with billing accounts, which are covered later in this document. Note that only a user with the Billing Account Administrator or Billing Account User role can associate a new project with an existing billing account.
Many resources within Google Cloud are limited by quotas. For example, a new project that is linked to a newly associated billing account has a quota of eight virtual CPUs on Compute Engine. You can request an increase in your quota to add more resources or new resources, such as GPUs, that are not issued by default.
Along with resource quotas, organizations are subject to quotas on the number of projects they create. Even if you delete a project, it remains part of the project quota for a few days until the project is completely purged.
When deciding upon a project structure, consider IT trust boundaries, which likely follow an existing IT governance or security model. For example, do separate schools, such as engineering, business, and law, maintain trust boundaries between each other? Do separate departments within schools trust one another?
By applying the IT security best practice of least-privileged access, you can grant different roles to user accounts and service accounts within a single project and across multiple projects. If a user has administrator-level access to one project but should have only viewer or read-only access to another project, you can define those roles explicitly by using the IAM policy in Google Cloud. For more information, see the IAM guidance on least privilege.
Large organizations often separate operations teams, such as security and network administration, from product teams. This separation requires using resources that are managed by other teams and following the principle of least privilege. You can configure the settings for this separation by using IAM and service accounts.
With IAM, you manage access control by defining who has what level of access to which resources. You grant roles to users by creating an IAM policy, which is a collection of statements attached to a resource that define and control who has what type of access to that resource. To give granular access to specific Google Cloud resources, use predefined roles or define customized IAM roles.
How to use privileged accounts
Following the principle of least privilege, assign Super Admin roles to
infrequently used accounts. For example, you might use
for day-to-day activities but use
firstname.lastname@example.org when making
changes to the G Suite Admin Console or Cloud Console.
How to use service accounts
Google Cloud uses IAM service accounts to invoke Google API calls so that individual user credentials aren't directly involved. One feature of these accounts is that they are treated as both an identity and a resource.
When a service account acts as an identity, you grant it roles so that it can access a resource, such as a Cloud Storage bucket.
When a service account acts as a resource, you must grant users permission to access that account in the same way you grant permission to access a BigQuery dataset. You can grant a user the role of owner, editor, viewer, or Service Account User. Users who are Service Account Users can access all the resources to which the service account has access.
When to use groups
When you use groups instead of individuals in policies, as team members join and leave, your admins can adjust group membership. As a result, the correct policy changes happen automatically. To implement this practice, you create groups that are based on job function for each project or folder. You then assign multiple roles to each group as required for the job function.
Group management is handled by Google Groups for Business, which is part of G Suite. A G Suite admin user or delegated admin can use the Admin Console to access this tool.
With Virtual Private Cloud (VPC), you can isolate your private cloud services. For example, you might use VPC to set up a network, a common private RFC 1918 IP space, that spans all your projects. You then add instances from any project to this network or its subnetworks.
You can also attach a virtual private network (VPN) to a single network, which all or a subset of the projects can use. The VPN connection can be used to connect to a Google Cloud-specific RFC 1918 IP space or extend your on-premises network's RFC 1918 IP space.
Google offers the following options for connecting to your VPC instances.
|Dedicated Interconnect||IPsec VPN||Direct Peering||Carrier Peering|
|Useful for extending corporate networks and RFC 1918 IP space into the
No VPN is required for access to Google Cloud resources in your VPC.
|Useful for tunneling through the public internet to connect to Google, and for low-volume data connections.||Useful for connecting directly to Google, and for saving 50% on egress fees compared to VPN or public access over the internet.||Useful if you like the benefits of direct peering but are unable to meet the peering requirements without a partner.|
|10 Gbps for each link||1.5–3 Gbps for each tunnel||10 Gbps for each link||Varies based on partner offering|
For more details about these options, see the Cloud Interconnect page.
When to use direct peering
Any Google Cloud customer who has a registered Autonomous System Number (ASN) and publicly routable IP prefixes is welcome to establish direct peering with Google. This option uses the same interconnection model as the public internet, except there is no service provider in the middle. Learn more about peering with Google.
When to use carrier peering
For customers who do not have public ASNs, or who want to connect to Google by using a service provider, Google offers the Carrier Peering service. Carrier Peering is designed for customers who want enterprise-grade connectivity to the Google edge network.
You can use the Cloud Console to manage your Cloud Billing account. From the Cloud Console, you can update account settings such as payment methods and administrative contacts. You can also configure the Cloud Console to set budgets, trigger alerts, view your payment history, and export billing data.
For most users, a single Cloud Billing account is sufficient. Institution-wide discounts apply to all projects that are associated with the account. Users make a single payment to Google to settle the monthly invoice, and department-specific or lab-specific projects can be charged by using an internal IT chargeback process.
The single billing account looks like this:
Billing considerations can also drive how you organize projects and folders in Google Cloud. Depending on your internal cost centers, you might decide to organize as in the following diagram.
- In this diagram, folders identify all the projects and assets that are associated with a cost center, department, or IT project.
- Projects organize resources. Cost is shown per project, and project IDs are included in the billing export.
- You annotate projects with labels that represent additional grouping
information, such as
environment=test. Labels are included in the billing export.
- The cost center is encoded into the project name or ID.
This model works well if you align each folder with a separate internal cost center. However, internal chargebacks are still necessary because Google sends a single invoice for a given billing account.
Multiple billing accounts are an option if cost centers must pay a separate invoice or, for some workloads, pay with a separate currency. This approach might require a signed agreement for each billing account.
Administering Cloud Billing accounts
Cloud Billing account roles help you administer billing accounts. You can assign the following billing roles at the organization level.
|Billing Account Administrator||Manages all billing accounts in the organization.|
|Billing Account Creator||Creates billing accounts in the organization.|
|Billing Account User||Links projects with billing accounts.|
|Project Billing Manager||Provides access to assign a project's billing account or disable project billing.|
Grant the Billing Account Administrator role at the Org node level to allow viewing of all the billing accounts in your organization. To limit who can create billing accounts, and how, use the Billing Account Creator role and restrict which users have this permission. These Google Help Center articles provide more information:
Changing billing accounts
If you want to change Cloud Billing accounts for a project, or disable billing altogether, follow these steps.
- In the Cloud Console, in the left navigation menu, click Billing.
To the right of the project name, click the three-dot icon, and then click Change billing account. You can also use this icon to disable billing, which disables the project.
Creating a budget
Budgets generate alerts but don't turn off billing for projects, which means that a project continues to run even if it exceeds the budget. If a project is running over budget, you must disable billing manually. Or you can stop the resources that are incurring billable charges in order to prevent further exceeding the budget. Because the budget doesn't update in real time, you might not discover it for a day or two from the time a project begins to overspend.
Follow these steps to create a budget.
In the Cloud Console, go to the Billing menu, click Budgets & alerts, and click Create Budget.
In this example, the account is already over budget for the month. Remember that a budget does not turn off any services but rather notifies the billing administrator when the budget is exceeded.
Enter the budget details and at what levels of budget usage you want to receive alerts.
Under Project or billing account, choose whether you want to monitor your overall budget or individual projects. The budgets feature works on a calendar month period. You can determine how much you want the budget to be for a given month.
Setting up billing export
If you want a detailed report of all the services used by your Cloud Billing account, set up Billing export from the Billing menu in the Cloud Console. Store the details in either Cloud Storage or BigQuery. If you opt to use Cloud Storage, you can store the data in either JSON or CSV format.
Exporting billing data to BigQuery means you can quickly find projects
that are spending over a limit that you set. You can also see which services you
are being charged for. For example, the following query lists all projects that
have spent over $0.10 in the current month. Replace
your table name.
SELECT project.name, cost FROM [YOUR_BIGQUERY_TABLE] WHERE cost > 0.1 ORDER BY cost DESC
- Learn more about each of the Google Cloud services.
- Learn how Google Cloud services map to Amazon Web Services (AWS) or Microsoft Azure services.
- Learn how to create your first VM, deploy a container image, or train a TensorFlow model.
- Take a class or get certified on Google Cloud training fundamentals.
- Explore the catalog of Qwiklabs Google Cloud training labs.
- Take a self-paced Google Cloud training course from Coursera.
- Try out other Google Cloud features for yourself. Have a look at our tutorials.