Best practices for enterprise

organizations
This guide introduces best practices to help enterprise
customers like you on your journey to Google Cloud. The
guide is not an exhaustive list of recommendations.
Instead, its goal is to help enterprise architects and
technology stakeholders understand the scope of
activities and plan accordingly. Each section provides key
actions and includes links for further reading.

Before you read this guide, we recommend reviewing the

Platform overview in order to understand the overall
Google Cloud landscape.

Try it for yourself

If you're new to Google Cloud, create an account to
evaluate how our products perform in real-world
scenarios. New customers also get $300 in free credits to
run, test, and deploy workloads.

Get started for free

Organizational setup
Best practices:

Define your resource hierarchy.

Create an Organization node.
Specify your project structure.
Automate project creation.

Define your resource hierarchy

Google Cloud resources are organized hierarchically. This

hierarchy allows you to map your enterprise's operational
structure to Google Cloud, and to manage access control
and permissions for groups of related resources. The
following diagram shows an example hierarchy.

The top-level node of the hierarchy is the Organization

resource, which represents an organization (for example,
a company). The Organization resource provides central
visibility and control over all resources further down the
hierarchy.

Next in the hierarchy are folders. You can use folders to

isolate requirements for different departments and teams
in the parent organization. You can similarly use folders to
separate production resources from development
resources.

At the bottom of the hierarchy are projects. Projects

contain the computing, storage, and networking
resources that constitute your apps. Projects are
discussed in more detail later in this document.

The structure you define is flexible and allows you to

adapt to evolving requirements. If you are just beginning
your Google Cloud journey, adopt the simplest structure
that satisfies your initial requirements. See the Resource
Manager overview for full details.

Create an Organization node

Many of the features supported by Google Cloud require

an Organization node. You can create an Organization
node that maps to your corporate internet domain, such
as example.com, through Cloud Identity. You can migrate
your existing Google Cloud projects and billing accounts
into the Organization node. For more details, see creating
and managing organizations.

If you need help setting up, see the Organization setup

wizard.

Specify your project structure

A project is required in order to use Google Cloud. All

Google Cloud resources, such as Compute Engine virtual
machines and Cloud Storage buckets, belong to a single
project. For more information about projects, see the
Platform overview.

You control the scope of your projects. A single project

might contain multiple separate apps, or conversely a
single app might include several projects. Projects can
contain resources spread across multiple regions and
geographies.
A general recommendation is to have one project per
application per environment. For example, if you have two
applications, "app1" and "app2", each with a development
and production environment, you would have four
projects: app1-dev, app1-prod, app2-dev, app2-prod. This
isolates the environments from each other, so changes to
the development project do not accidentally impact
production, and gives you better access control, since you
can (for example) grant all developers access to
development projects but restrict production access to
your CI/CD pipeline.

The ideal project structure depends on your individual

requirements, and might evolve over time. When
designing project structure, determine whether resources
need to be billed separately, what degree of isolation is
required, and how the teams that manage the resources
and apps are organized. An example structure can be
found at Policy design for enterprise customers.

Automate project creation

When you automate the creation and management of your

Google Cloud projects and resources, you get benefits
such as consistency, reproducibility, and testability.
Treating your configuration as code allows you to version
and manage the lifecycle of your configuration alongside
your software artifacts. Automation allows you to support
best practices such as consistent naming conventions
and labeling of resources. As your requirements evolve,
automation also simplifies the refactoring of your projects.

For Google Cloud projects, use Cloud Deployment

Manager, which is the Google Cloud native management
tool. With Deployment Manager, you create a
configuration file that describes a set of Google Cloud
resources that you want to deploy together. You can
define parameterized templates that act as reusable
building blocks. Deployment Manager can also set access
control permissions through IAM such that your
developers are granted appropriate access as part of the
project creation process.

If you already use tools like Terraform, Ansible, or Puppet,

you can use those instead. This lets you take advantage of
skills your team already has.

Identity and access management

Best practices:

Manage your Google identities.

Federate your identity provider with Google Cloud.
Migrate unmanaged accounts.
Control access to resources.
Use groups and service accounts.
Define an organization policy.

Manage your Google identities

Google Cloud uses Google accounts for authentication

and access management. Your developers and other
technical staff must have Google accounts to access
Google Cloud. We recommend using fully managed
Google accounts tied to your corporate domain name
through Cloud Identity. This way, your developers can
access Google Cloud using their corporate email IDs, and
your admins can see and control the accounts through the
Admin Console. Subsequent sections of this doc describe
how to integrate your existing identity platform with Cloud
Identity.

Cloud Identity is a stand-alone Identity-as-a-Service

(IDaaS) solution. It gives Cloud Platform customers
access to many of the identity management capabilities
provided by Google Workspace, Google Cloud's set of
workplace productivity apps. Cloud Identity does not
require a Google Workspace license. Signing up for Cloud
Identity provides a management layer over Google
accounts that are associated with your corporate domain
name. Through this management layer, you can enable or
disable access to Google services, including Google
Cloud, for your employees. Signing up for Cloud Identity
also creates an Organization node for your domain, which
helps map corporate structure and controls to your
Google Cloud resources through the Resource Hierarchy.

For more information see Cloud Identity Solutions.

Federate your identity provider with Google

Cloud
If your organization uses an on-premises or third-party
identity provider, synchronize your user directory with
Cloud Identity to let users access Google Cloud with their
corporate credentials. This way, your identity platform
remains the source of truth while Cloud Identity controls
how your employees access Google services.

Migrate unmanaged accounts

If members of your domain have used their corporate

email addresses to create a personal Google Account—for
example, to sign up for a Google service such as YouTube
or Blogger, then consider migrating these accounts so
that they can also be managed using Cloud Identity.
Alternatively, you can force these accounts to be changed
to use a different email address.

You can find additional guidance on how to migrate

accounts or force accounts to be renamed in Assessing
existing user accounts.

Control access to resources

You must authorize your developers and IT staff to

consume Google Cloud resources. You can use Identity
and Access Management (IAM) to grant granular access
to specific Google Cloud resources and prevent unwanted
access to other resources. Specifically, IAM enables you
to control access by defining who (identity) has what
access (role) for which resource.
Rather than directly assigning permissions, you assign
roles. IAM roles are collections of permissions. For
example, the BigQuery Data Viewer role contains the
permissions to list, read, and query BigQuery tables, but
does not include permissions to create new tables or
modify existing data. IAM provides many predefined roles
to handle a wide range of common use cases. It also
enables you to create custom roles.

Use IAM to apply the security principle of least privilege,

so you grant only the necessary access to your resources.
IAM is a fundamental topic for enterprise organizations.
For more information about identity and access
management, see the following resources:

Getting to know IAM

Using IAM securely

Delegate responsibility with groups and

service accounts

We recommend collecting users with the same

responsibilities into groups and assigning IAM roles to the
groups rather than to individual users. For example, you
can create a "data scientist" group and assign appropriate
roles to enable interaction with BigQuery and Cloud
Storage. When a new data scientist joins your team, you
can simply add them to the group and they will inherit the
defined permissions. You can create and manage groups
through the Admin Console.
We recommend that enterprise customers create the
following 6 groups:

Group Function
gcp- Organization admins are responsible for
organization- organizing the structure of the resources
admins used by the organization.
Network admins are responsible for creating
gcp-network- networks, subnets, firewall rules, and
admins network devices such as Cloud Router,
Cloud VPN, and cloud load balancers.
Security admins are responsible for
establishing and managing security policies
gcp-security-
admins for the entire organization, including access
management and organization constraint
policies.
gcp-billing- Billing admins are responsible for setting up
admins billing accounts and monitoring their usage.
DevOps practitioners create or manage end-
gcp-devops
to-end pipelines that support continuous
integration and delivery, monitoring, and
system provisioning.
gcp- Developers are responsible for designing,
developers coding, and testing applications.

A service account is a special type of Google Account that

represents a Google Cloud service identity or app rather
than an individual user. Like users and groups, service
accounts can be assigned IAM roles to grant access to
specific resources. Service accounts authenticate with a
key rather than a password. Google manages and rotates
the service account keys for code running on Google
Cloud. We recommend that you use service accounts for
server-to-server interactions.

Define an organization policy

Use the Organization Policy Service to get centralized and

programmatic control over your organization's cloud
resources. IAM focuses on who, providing the ability to
authorize users and groups to take action on specific
resources based on permissions. An organization policy
focuses on what, providing the ability to set restrictions on
specific resources to determine how they can be
configured and used. For example, you can define a
constraint to restrict virtual machine instances from
having an external IP address.

You set policies on resources in the resource hierarchy. All

descendants of a resource inherit its policies by default.
You can define a base set of constraints that apply to all
elements in the hierarchy by attaching a policy to the top-
level Organization node. You can then set custom
organization policies on child nodes, which overwrite or
merge with the inherited policy.

For more information about setting policies, see Policy

Design for Enterprise Customers.

Networking and security

Best practices:
Use VPC to define your network.
Manage traffic with firewall rules.
Limit external access.
Centralize network control.
Connect your enterprise network.
Secure your apps and data.

Use VPC to define your network

Use VPCs and subnets to map out your network, and to

group and isolate related resources. Virtual Private Cloud
(VPC) is a virtual version of a physical network. VPC
networks provide scalable and flexible networking for your
Compute Engine virtual machine (VM) instances, and for
the services that leverage VM instances, including Google
Kubernetes Engine (GKE), Dataproc, and Dataflow, among
others.

VPC networks are global resources; a single VPC can

span multiple regions without communicating over the
public internet. This means you can connect and manage
resources distributed across the globe from a single
Google Cloud project, and you can create multiple,
isolated VPC networks in a single project.

VPC networks themselves do not define IP address

ranges. Instead, each VPC network consists of one or
more partitions called subnetworks. Each subnet in turn
defines one or more IP address ranges. Subnets are
regional resources; each subnet is explicitly associated
with a single region.

For more details, see the VPC overview.

Manage traffic with firewall rules

Each VPC network implements a distributed virtual

firewall. Configure firewall rules that allow or deny traffic
to and from the resources attached to the VPC, including
Compute Engine VM instances and GKE clusters. Firewall
rules are applied at the virtual networking level, so they
help provide effective protection and traffic control
regardless of the operating system your instances use.
The firewall is stateful, which means that for flows that are
permitted, return traffic is automatically allowed.

Firewall rules are specific to a particular VPC network. The

rules allow you to specify the type of traffic, such as ports
and protocols, and the source or destination of the traffic,
including IP addresses, subnets, tags, and service
accounts. For example, you can create an ingress rule to
allow any VM instance associated with a particular service
account to accept TCP traffic on port 80 that originated
from a specific source subnet. Each VPC automatically
includes default and implied firewall rules.

If your app is hosted in GKE, there are different

considerations for managing network traffic and
configuring firewall rules. For example, you can create a
network policy to control internal communication within
the GKE cluster. You can also use a service mesh like Istio
to further manage and secure communication with your
cluster. For more details, see GKE networking concepts.

Limit external access

When you create a Google Cloud resource that leverages

VPC, you choose a network and subnet to place the
resource in. The resource is assigned an internal IP
address from one of the IP ranges associated with the
subnet. Resources in a VPC network can communicate
among themselves through internal IP addresses as long
as firewall rules permit.

To communicate with the internet, resources must have

an external, public IP address or must use Cloud NAT.
Similarly, resources must possess an external IP address
to connect to other resources outside of the same VPC
network, unless the networks are connected in some way
—for example, through a VPN. For more details, see the IP
addresses documentation.

Limit access to the internet to only those resources that

need it. Resources with only a private, internal IP address
can still access many Google APIs and services through
Private Google Access. This private access enables
resources to interact with key Google and Google Cloud
services while remaining isolated from the internet.

Centralize network control

Use Shared VPC to connect to a common VPC network.
Resources in those projects can communicate with each
other securely and efficiently across project boundaries
using internal IPs. You can manage shared network
resources, such as subnets, routes, and firewalls, from a
central host project, enabling you to apply and enforce
consistent network policies across the projects.

With Shared VPC and IAM controls, you can separate

network administration from project administration. This
separation helps you implement the principle of least
privilege. For example, a centralized network team can
administer the network without having any permissions
into the participating projects. Similarly, the project
admins can manage their project resources without any
permissions to manipulate the shared network.

Connect your enterprise network

Many enterprises need to connect existing on-premises

infrastructure with their Google Cloud resources. Evaluate
your bandwidth, latency, and SLA requirements to choose
the best connection option:

If you need low-latency, highly available, enterprise-

grade connections that enable you to reliably transfer
data between your on-premises and VPC networks
without traversing the internet connections to Google
Cloud, use Cloud Interconnect:
 Dedicated Interconnect provides a direct
physical connection between your on-premises
network and Google's network.
Partner Interconnect provides connectivity
between your on-premises and Google Cloud
VPC networks through a supported service
provider.

If you don't require the low latency and high

availability of Cloud Interconnect, or you are just
starting on your cloud journey, use Cloud VPN to set
up encrypted IPsec VPN tunnels between your on-
premises network and VPC. Compared to a direct,
private connection, an IPsec VPN tunnel has lower
overhead and costs.

Secure your apps and data

Google Cloud provides robust security features across its

infrastructure and services, from the physical security of
data centers and custom security hardware to dedicated
teams of researchers. However, securing your Google
Cloud resources is a shared responsibility. You must take
appropriate measures to help ensure that your apps and
data are protected.

In addition to firewall rules and VPC isolation, use these

additional tools to help secure and protect your apps:

Use VPC Service Controls to define a security

 perimeter around your Google Cloud resources to
constrain data within a VPC and help mitigate data
exfiltration risks.
Use a Google Cloud global HTTP(S) load balancer to
support high availability and scaling for your internet-
facing services.
Integrate Google Cloud Armor with the HTTP(S) load
balancer to provide DDoS protection and control
access to known trusted or untrusted IP addresses at
the network edge.
Control access to apps by using Identity-Aware Proxy
(IAP) to verify user identity and the context of the
request to determine if a user should be granted
access.

Google Cloud helps keep your data secure by applying

encryption both in transit and at rest. Data at rest is
encrypted by default using encryption keys managed by
Google. For sensitive data, you can instead manage your
keys in Google Cloud. If you need greater control, you can
supply your own encryption keys that are maintained
outside of Google Cloud. Because managing or
maintaining your own keys introduces overhead, we
recommend using that approach only for truly sensitive
data. For more details, see encryption at rest.

Logging, monitoring, and operations

Best practices:
Centralize logging and monitoring.
Set up an audit trail.
Export your logs.
Embrace DevOps and explore Site Reliability Engineering.

Centralize logging and monitoring

Enterprises typically run multiple apps, data pipelines, and

other processes, often across different platforms.
Ensuring the health of these apps and processes is a key
responsibility of developers and operations teams alike.
To help ensure health, we recommend using Cloud
Logging and Cloud Monitoring to manage logging,
monitoring, debugging, tracing, profiling, and more.

Logs are a primary source of diagnostic information about

the health of your apps and processes. Cloud Logging
allows you to store, view, search, analyze, and alert on log
data and events. Logging integrates natively with many
Google Cloud services. For applications that are hosted
on Compute Engine or Amazon Elastic Compute Cloud
(EC2) virtual machine instances, a logging agent can be
installed to automatically forward logs to Cloud Logging.
Cloud Logging also provides an API that can be used to
write logs from any source, including from applications
that run on-premises. Use Logging to centralize logs from
all your apps.

In addition to consuming logs, you typically need to

monitor other aspects of your apps and systems to ensure
reliable operation. Use Cloud Monitoring to get visibility
into the performance, uptime, and overall health of your
apps and infrastructure. Monitoring ingests events,
metrics, and metadata and generates insights through
dashboards, charts, and alerts. Monitoring supports
metrics from many Google Cloud and third-party sources
out of the box. You can also define custom metrics with
Monitoring. For example, you can use metrics to define
alerting policies such that operations teams are notified of
unusual behaviour or trends. Monitoring also provides
flexible dashboards and rich visualization tools to help
identify emergent issues.

Set up an audit trail

In addition to capturing app and process-level logs, you

might need to track and maintain details of how your
developers and IT teams are interacting with Google
Cloud resources. Use Cloud Audit Logs to help answer
questions like "who did what, where, and when" in your
Google Cloud projects. For a list of Google Cloud services
that write audit logs, see Google services with audit logs.
Use IAM controls to limit who has access to view audit
logs.

Cloud Audit Logs captures several types of activity. Admin

Activity logs contain log entries for API calls or other
administrative actions that modify the configuration or
metadata of resources. Admin Activity logs are always
enabled. Data Access audit logs record API calls that
create, modify, or read user-provided data. Data Access
audit logs are disabled by default because they can be
quite large. You can configure which Google Cloud
services produce data access logs.

For more in-depth information about auditing, see Cloud

Audit Logs.

Export your logs

Logging retains app and audit logs for a limited period of

time. You might need to retain logs for longer periods to
meet compliance obligations. Alternatively, you might
want to keep logs for historical analysis.

You can route logs to Cloud Storage, BigQuery, and

Pub/Sub. Using filters, you can include or exclude
resources from the export. For example, you can export all
Compute Engine logs but exclude high-volume logs from
Cloud Load Balancing.

Where you export your logs depends on your use case.

Many enterprises export to multiple destinations. Broadly
speaking, to meet compliance obligations, use Cloud
Storage for long-term storage. If you need to analyze logs,
use BigQuery, because it supports SQL querying and a
large ecosystem of third-party tools.

For more details on logging exports, see Design patterns

for exporting from Logging.
Embrace DevOps and explore Site Reliability
Engineering

To increase agility and reduce time-to-market for apps

and features, you need to break down silos between
development, operations, networking, and security teams.
Doing so requires processes, culture, and tooling that are
together referred to as DevOps.

Google Cloud provides a range of services to help you

adopt DevOps practices. Features include integrated
source code repositories, continuous-delivery tooling, rich
monitoring capabilities through Cloud Monitoring, and
strong support for open source tools. For more details,
see Google Cloud's DevOps solutions.

Site Reliability Engineering (SRE) is a set of practices

closely related to DevOps. These practices evolved from
the SRE team that manages Google's production
infrastructure. While creating a dedicated SRE function is
beyond the scope of many enterprises, we recommend
that you study the SRE books to learn practices that can
help shape your operations strategy.

Cloud architecture
Best practices:

Plan your migration.

Favor managed services.
Design for high availability.
Plan your disaster recovery strategy.

Plan your migration

Migrating on-premises apps and infrastructure to the

cloud requires careful assessment and planning. You must
evaluate the various migration strategies, from lift-and-
shift to transform-and-move, on a per-app basis. Google
Cloud provides tools to help migrate virtual machines,
transfer your data, and modernize your workloads. For
more details, see the migration center.

Because of regulatory, technical, or financial constraints, it

might not be possible or even desirable to move certain
apps to the public cloud. Consequently, you might need to
distribute and integrate workloads across your on-
premises and Google Cloud infrastructure. This setup is
referred to as hybrid cloud. For more details on hybrid
workloads, see the hybrid cloud page and the patterns
and best practices for hybrid and multi-cloud solutions.

Favor managed services

Key drivers of cloud adoption are reducing IT overhead

and increasing efficiencies, enabling you to focus on your
core business. In addition to adopting DevOps practices
and increasing automation, you should use Google Cloud
managed services to help reduce operational burden and
total cost of ownership (TCO).
Rather than independently installing, supporting, and
operating all parts of an application stack, you can use
managed services to consume parts of your application
stack as services. For example, rather than installing and
self-managing a MySQL database on a VM instance, you
can use a MySQL database provided by Cloud SQL. You
can then rely on Google Cloud to manage the underlying
infrastructure and automate backups, updates, and
replication.

We recommend that you evaluate the SLA provided by

each managed service.

Google Cloud offers managed services and serverless

options for many common app components and use
cases, from managed databases to big-data processing
tools. Many of these managed services support popular
open source frameworks and platforms, so you can realize
TCO benefits by lifting and shifting existing apps that
leverage these open source platforms into the cloud.

Design for high availability

To help maintain uptime for mission-critical apps, design

resilient apps that gracefully handle failures or
unexpected changes in load. High availability is the ability
of an app to remain responsive and continue to function
despite failures of components in the system. Highly
available architectures typically involve distribution of
compute resources, load-balancing, and replication of
data. The extent of your high availability provisions might
vary by app. For more information about availability
concepts, see the geographies and regions
documentation.

At a minimum, you should distribute compute resources,

such as Compute Engine VM instances and GKE clusters,
across the available zones in a region to protect against
failure of a particular zone. To further improve the
availability of your compute resources, you can similarly
distribute them across multiple geographically dispersed
regions to mitigate against loss of an entire region. For
guidance on where to create your compute resources, see
best practices for Compute Engine region selection.

Google Cloud offers several variations of load balancing.

The HTTP(S) load balancer is often used to expose
internet-facing apps. This load balancer provides global
balancing, allowing distribution of load across regions in
different geographies. If a zone or region becomes
unavailable, the load balancer directs traffic to a zone with
available capacity. For more details, see application
capacity optimizations with global load balancing.

Also consider availability when choosing your data

storage. Some Google Cloud data storage services offer
the ability to replicate data across zones in a single region.
Other services automatically replicate data across
multiple regions in a geographical area, but might require
a trade-off on either latency or the consistency model.
Which data storage service is most appropriate varies by
app and availability requirements.

Plan your disaster recovery strategy

In addition to designing for high availability, you should

create a plan for maintaining business continuity in the
event of a wide-scale outage or natural disaster. Disaster
recovery (DR) is the ability to recover from rare but major
incidents. When high availability provisions are ineffective
or unavailable, you might need to initiate disaster
recovery.

Creating an effective DR plan requires planning and

testing. We recommend that you address DR plans early.
For more details, see the disaster recovery planning guide
and related articles.

Resources

Building scalable and resilient web applications on

Google Cloud
Designing and implementing your disaster recovery
plan using Google Cloud
Geography and regions

Billing and management

Best practices:

Know how resources are charged.

Set up billing and permissions.
Analyze and export your bill.
Plan for your capacity requirements.
Implement cost controls.
Purchase a support package.
Get help from the experts.
Build centers of excellence.

Know how resources are charged

Google Cloud operates on a consumption model. You are

charged based on how much of a particular resource or
product you use over a given payment period. You must
enable a Cloud Billing account to use Google Cloud
products. Products measure consumption in different
ways, for example:

As an amount of time (how many seconds a machine

was running)
As a volume (how much data is stored)
As the number of operations executed
As variations of those concepts

Make sure you understand how the billing works for the
components in your system so that you can accurately
gauge your costs. Each product provides detailed pricing
information in its documentation. Many products provide a
Free Tier where the cost of any consumption below a
certain threshold is credited to your billing account so you
do not incur charges. Resources consumed beyond what
is offered by the Free Tier are charged to your billing
account.

For more details about Google Cloud pricing philosophies,

innovations, and discounts, see the Pricing page.

Set up billing controls

All Google Cloud resources, including Compute Engine

VMs, Cloud Storage buckets, and BigQuery datasets,
must be associated with a Google Cloud project. To
consume resources, including resources included in the
Free Tier, a project must be associated with a billing
account. There is a one-to-many relationship between a
billing account and projects; a project can be associated
with only one billing account, but a billing account can be
associated with many projects.

A billing account defines who pays for the resources in a

set of projects. A billing account can be one of two types:
a self-serve (online) auto-paid account, or an invoiced
account. Self-serve (online) accounts include a payment
instrument, such as a credit card, to which costs are
automatically charged. Invoiced accounts are paid with a
check or bank wire transfer. If you want to determine
which type of billing account you are using, see Find out
your Cloud Billing account type and charging cycle.

You can define billing accounts at the organization level,

where you link projects under the Organization node to
the billing accounts. You can have multiple billing
accounts in your organization, though we recommend
creating only one central billing account.

IAM provides a robust set of controls to limit how different

users can administer and interact with billing. These
controls help you apply the principle of least privilege and
provide a clear separation of roles. For example, you can
separate permission to create billing accounts from
permission to link projects to a particular billing account.

For a detailed discussion of billing concepts and setup,

see the Billing onboarding checklist.

Analyze and export your bill

Users with appropriate permissions can view a detailed

breakdown of costs, transaction history, and more in the
Cloud Console. Information is presented per billing
account. The console also contains interactive billing
reports that allow you to filter and break down costs by
project, product, and time range. The Cloud Console
functionality is often sufficient for customers with less
complicated Google Cloud setups.

However, if you typically require custom analyses and

reporting on your cloud expenditure, we recommend
enabling daily exports of Cloud Billing data to a BigQuery
dataset. Exported data includes any labels that have been
applied to resources.
Timing is important. We recommend that you enable
exports to BigQuery at the same time you create your
Cloud Billing account. Your BigQuery dataset only reflects
Google Cloud billing data incurred from the date you set
up Cloud Billing export, and after. That is, Google Cloud
billing data is not added retroactively, so you won't see
Cloud Billing data from before you enable export. After the
billing data is in BigQuery, finance teams can analyze the
data using standard SQL and use tools that integrate with
BigQuery, such as Data Studio.

Plan for your capacity requirements

Google Cloud projects have quotas that limit the

consumption of a particular resource or API. Quotas are in
place to protect the wider Google Cloud community by
preventing unforeseen spikes in usage. For example,
quotas ensure that a small number of customers or
projects cannot monopolize usage of CPU cores in a
particular region or zone.

Plan the capacity requirements of your projects in

advance to prevent unexpected limiting of your resource
consumption. If the quotas are not sufficient, you can
request changes in the Quotas section of the Cloud
Console. If you require a large capacity, contact your
Google Cloud sales team.

Implement cost controls

As cloud services scale up, their costs also go up. Google
Cloud provides several methods to limit resource
consumption, and to notify interested parties of relevant
billing events.

You can define budgets that generate alerts when

spending reaches certain thresholds. Alerts take the form
of emails and can optionally generate Pub/Sub messages
for programmatic notification. You can apply the budget
to the entire billing account or to an individual project that
is linked to the billing account. For example, you could
create a budget to generate alerts when total monthly
spending for a billing account reaches 50, 80, and 100
percent of the specified budget amount. Note that
budgets do not themselves limit spending; rather, they are
a function to generate alerts. For more details, see the
budget alerts documentation. For more best practices,
design decisions, and configuration options that help
simplify cost management, see Cloud Billing onboarding
checklist

You can also use quotas to cap the consumption of a

particular resource. For example, you can set a maximum
"query usage per day" quota over the BigQuery API to
ensure that a project does not overspend on BigQuery.

Purchase a support package

Google Cloud provides various ways to get support when

you experience problems, from community forums to paid
support packages. To protect your business-critical
workloads, we recommend purchasing an Enterprise
support package. For details, see the Google Cloud
support portal.

Depending on the level of support you purchase, your

ability to raise support tickets could be limited to certain
individuals. So it's a good practice to establish a support
clearinghouse or triage desk. This approach helps you
avoid ticket duplication and miscommunication, and keeps
your communication with Google Cloud Support as clear
as possible.

Get help from the experts

The Google Cloud Professional Services organization

(PSO) offers consulting services to help you on your
Google Cloud journey. Contact PSO consultants, who can
provide deep expertise to educate your team on best
practices and guiding principles for a successful
implementation. Services are delivered in the form of
packages to help you plan, deploy, execute, and optimize
workloads.

Google Cloud also has a strong ecosystem of Google

Cloud partners, from large global systems integrators to
partners with a deep specialization in a particular area like
machine learning. Partners have demonstrated customer
success using Google Cloud and can accelerate your
projects and improve business outcomes. We recommend
that enterprise customers engage partners to help plan
and execute their Google Cloud implementation.

Build centers of excellence

Google continues to invest in these products, and new

features are continually being rolled out. It can be valuable
to capture your organization's information, experience,
and patterns in an internal knowledge base, such as a
wiki, Google site, or intranet site.

Similarly, it's a good practice to nominate Google Cloud

experts and champions in your organization. A range of
training and certification options are available to help
nominated champions grow in their area of expertise.
Teams can stay up to date on the latest news,
announcements, and customer stories by subscribing to
the Google Cloud blog.

What's next
Review the Launch checklist.
Explore Google Cloud Solutions to optimize your
business.

Compare with other platforms:

Google Cloud for data center professionals

Google Cloud for AWS professionals
Google Cloud for Azure professionals
Visit the blog.

Explore reference architectures, diagrams, tutorials,

and best practices about Google Cloud. Take a look
at our Cloud Architecture Center.