Migrate to Google Cloud: Plan and build your foundation

Last reviewed 2024-07-31 UTC

This document helps you create the basic cloud infrastructure for your workloads. It can also help you plan how this infrastructure supports your applications. This planning includes identity management, organization and project structure, and networking.

This document is part of the following multi-part series about migrating to Google Cloud:

The following diagram illustrates the path of your migration journey.

Migration path with four phases.

This document is useful if you're planning a migration from an on-premises environment, from a private hosting environment, from another cloud provider to Google Cloud, or if you're evaluating the opportunity to migrate and want to explore what it might look like. This document helps you understand the available products and decisions you'll make building a foundation focused on a migration use case.

For premade implementable options, see:

For additional best practice guidance designing your foundation, see:

When planning your migration to Google Cloud, you need to understand an array of topics and concepts related to cloud architecture. A poorly planned foundation can cause your business to face delays, confusion, and downtime, and can put the success of your cloud migration at risk. This guide provides an overview of Google Cloud foundation concepts and decision points.

Each section of this document poses questions that you need to ask and answer for your organization before building your foundation on Google Cloud. These questions are not exhaustive; they are meant to facilitate a conversation between your architecture teams and business leadership about what is right for your organization. Your plans for infrastructure, tooling, security, and account management are unique for your business and need deep consideration. When you finish this document and answer the questions for your organization, you're ready to begin the formal planning of your cloud infrastructure and services that support your migration to Google Cloud.

Enterprise considerations

Consider the following questions for your organization:

  • Which IT responsibilities might change between you and your infrastructure provider when you move to Google Cloud?
  • How can you support or meet your regulatory compliance needs—for example, HIPAA or GDPR—during and after your migration to Google Cloud?
  • How can you control where your data is stored and processed in accordance with your data residency requirements?

Shared responsibility model

The shared responsibilities between you and Google Cloud might be different than those you are used to, and you need to understand their implications for your business. The processes you previously implemented to provision, configure, and consume resources might change.

Review the Terms of Service and the Google security model for an overview of the contractual relationship between your organization and Google, and the implications of using a public cloud provider.

Compliance, security, and privacy

Many organizations have compliance requirements around industry and government standards, regulations, and certifications. Many enterprise workloads are subject to regulatory scrutiny, and can require attestations of compliance by you and your cloud provider. If your business is regulated under HIPAA or HITECH, make sure you understand your responsibilities and which Google Cloud services are regulated. For information about Google Cloud certifications and compliance standards, see the Compliance resource center. For more information about region-specific or sector-specific regulations, see Google Cloud and the General Data Protection Regulation (GDPR).

Trust and security are important to every organization. Google Cloud implements a shared security model for many services.

The Google Cloud trust principles can help you understand our commitment to protecting the privacy of your data and your customers' data. For more information about Google's design approach for security and privacy, read the Google infrastructure security design overview.

Data residency considerations

Geography can also be an important consideration for compliance. Make sure that you understand your data residency requirements and implement policies for deploying workloads into new regions to control where your data is stored and processed. Understand how to use resource location constraints to help ensure that your workloads can only be deployed in pre-approved regions. You need to account for the regionality of different Google Cloud services when choosing the deployment target for your workloads. Make sure that you understand your regulatory compliance requirements and how to implement a governance strategy that helps you ensure compliance.

Resource hierarchy

Consider the following questions for your organization:

  • How do your existing business and organizational structures map to Google Cloud?
  • How often do you expect changes to your resource hierarchy?
  • How do project quotas impact your ability to create resources in the cloud?
  • How can you incorporate your existing cloud deployments with your migrated workloads?
  • What are best practices for managing multiple teams working simultaneously on multiple Google Cloud projects?

Your current business processes, lines of communication, and reporting structure are reflected in the design of your Google Cloud resource hierarchy. The resource hierarchy provides the necessary structure to your cloud environment, determines the way you are billed for resource consumption, and establishes a security model for granting roles and permissions. You need to understand how these facets are implemented in your business today, and plan how to migrate these processes to Google Cloud.

Understand Google Cloud resources

Resources are the fundamental components that make up all of Google Cloud services. The Organization resource is the apex of the Google Cloud resource hierarchy. All resources that belong to an organization are grouped under the organization node. This structure provides central visibility and control over every resource that belongs to an organization.

An Organization can contain one or more folders, and each folder can contain one or more projects. You can use folders to group related projects.

Google Cloud projects contain service resources such as Compute Engine virtual machines (VMs), Pub/Sub topics, Cloud Storage buckets, Cloud VPN endpoints, and other Google Cloud services. You can create resources by using the Google Cloud console, Cloud Shell, or the Cloud APIs. If you expect frequent changes to your environment, consider adopting an infrastructure as a code (IaC) approach to streamline resource management.

Manage your Google Cloud projects

For more information about planning and managing your Google Cloud resource hierarchy, see Decide a resource hierarchy for your Google Cloud landing zone. If you're already working in Google Cloud and have created independent projects as tests or proofs-of-concept, you can migrate existing Google Cloud projects into your organization.

Identity and Access Management

Consider the following questions for your organization:

  • Who will control, administer, and audit access to Google Cloud resources?
  • How will your existing security and access policies change when you move to Google Cloud?
  • How will you securely enable your users and apps to interact with Google Cloud services?

Identity and Access Management (IAM) lets you grant granular access to Google Cloud resources. Cloud Identity is a separate but related service that can help you migrate and manage your identities. At a high level, understanding how you want to manage access to your Google Cloud resources forms the basis for how you provision, configure, and maintain IAM.

Understand identities

Google Cloud uses identities for authentication and access management. To access any Google Cloud resources, a member of your organization must have an identity that Google Cloud can understand. Cloud Identity is an identity as a service (IDaaS) platform that lets you centrally manage users and groups who can access Google Cloud resources. By setting up your users in Cloud Identity, you can set up single sign-on (SSO) with thousands of third-party software as a service (SaaS) applications. The way you set up Cloud Identity depends on how you manage identities.

For more information about identity provisioning options for Google Cloud, see Decide how to onboard identities to Google Cloud.

Understand access management

The model for managing access consists of four core concepts:

  • Principal: Can be a Google Account (for end users), a service account (for Google Cloud products), a Google Group, or a Google Workspace or Cloud Identity account that can access a resource. Principals cannot perform any action that they aren't permitted to do.
  • Role: A collection of permissions.
  • Permission: Determines what operations are allowed on a resource. When you grant a role to a principal, you grant all the permissions that the role contains.
  • IAM allow policy: Binds a set of principals to a role. When you want to define which principals have access to a resource, you create a policy and attach it to the resource.

Proper setup and effective management of principals, roles, and permissions forms the backbone of your security posture in Google Cloud. Access management helps protect you from internal misuse, and helps protect you from external attempts at unauthorized access to your resources.

Understand application access

In addition to users and groups, there is another kind of identity known as a service account. A service account is an identity that your programs and services can use to authenticate and gain access to Google Cloud resources.

User-managed service accounts include service accounts that you explicitly create and manage using IAM, and the Compute Engine default service account that comes built into all Google Cloud projects. Service agents are automatically created, and run internal Google processes on your behalf.

When using service accounts, it's important to understand application default credentials, and follow our recommended best practices for service accounts to avoid exposing your resources to undue risk. The most common risks involve privilege escalation or accidental deletion of a service account that a critical application relies on.

Follow best practices

For more information about best practices to manage identity and access effectively, see Manage identity and access.

Billing

How you pay for Google Cloud resources that you consume is an important consideration for your business, and an important part of your relationship with Google Cloud. You can manage billing in the Google Cloud console with Cloud Billing alongside the rest of your cloud environment.

The concepts of resource hierarchy and billing are closely related, so it's critical that you and your business stakeholders understand these concepts.

For more information about best practices, tools and techniques to help you track and control costs, see Cost optimization.

Connectivity and networking

For more information about designing your network on Google Cloud, see:

If your source environment is in another cloud service provider, you might need to connect it with your Google Cloud environment. For more information, see Patterns for connecting other cloud service providers with Google Cloud.

When migrating production data and workloads to Google Cloud, we recommend that you consider how the availability of the connectivity solution can affect the success of your migration. For example, Cloud Interconnect provides supports production-level SLA if you provision it according to specific topologies.

When migrating data from your source environment to your Google Cloud environment, you should adjust the maximum transmission unit (MTU) to take protocol overhead into account. Doing so helps ensure that the data is transferred efficiently and accurately. This adjustment can also help prevent delays caused by data fragmentation and network performance issues. For example, if you're using Cloud VPN to connect your source environment to your Google Cloud environment, you might need to configure the MTU to a lower value to accommodate the VPN protocol overhead in each transmission unit.

To help you avoid connectivity issues during your migration to Google Cloud, we recommend that you:

  • Ensure that DNS records resolve across the source environment and your Google Cloud environment.
  • Ensure that network routes between the source environment and your Google Cloud environment correctly propagate across environments.

If you need to provision and use your own public IPv4 addresses in your VPCs, see Bring your own IP address.

Understand DNS options

Cloud DNS can serve as your public domain name system (DNS) server. For more information about how you can implement Cloud DNS, see Cloud DNS best practices.

If you need to customize how Cloud DNS responds to queries according to their source or destination, see DNS policies overview. For example, you can configure Cloud DNS to forward queries to your existing DNS servers, or you can override private DNS responses based on the query name.

A separate but similar service, called internal DNS, is included with your VPC. Instead of manually migrating and configuring your own DNS servers, you can use the internal DNS service for your private network. For more information, see Overview of internal DNS.

Understand data transfer

On-premises networking is managed and priced in a fundamentally different way than cloud networking. When managing your own data center or colocation facility, installing routers, switches, and cabling requires a fixed, upfront capital expenditure. In the cloud, you are billed for data transfer rather than the fixed cost of installing hardware, plus the ongoing cost of maintenance. Plan and manage data transfer costs accurately in the cloud by understanding data transfer costs.

When planning for traffic management, there are three ways you are charged:

  • Ingress traffic: Network traffic that enters your Google Cloud environment from outside locations. These locations can be from the public internet, on-premises locations, or other cloud environments. Ingress is free for most services on Google Cloud. Some services that deal with internet-facing traffic management, such as Cloud Load Balancing, Cloud CDN, and Google Cloud Armor charge based on how much ingress traffic they handle.
  • Egress traffic: Network traffic that leaves your Google Cloud environment in any way. Egress charges apply to many Google Cloud services, including Compute Engine, Cloud Storage, Cloud SQL, and Cloud Interconnect.
  • Regional and zonal traffic: Network traffic that crosses regional or zonal boundaries in Google Cloud can also be subject to bandwidth charges. These charges can impact how you choose to design your apps for disaster recovery and high availability. Similar to egress charges, cross-regional and cross-zonal traffic charges apply to many Google Cloud services and are important to consider when planning for high availability and disaster recovery. For example, sending traffic to a database replica in another zone is subject to cross-zonal traffic charges

Automate and control your network setup

In Google Cloud, the physical network layer is virtualized, and you deploy and configure your network using software-defined networking (SDN). To ensure that your network is configured in a consistent and repeatable way, you need to understand how to automatically deploy and tear down your environments. You can use IaC tools, such as Terraform.

Security

The way you manage and maintain the security of your systems in Google Cloud, and the tools you use, are different than when managing an on-premises infrastructure. Your approach will change and evolve over time to adapt to new threats, new products, and improved security models.

The responsibilities that you share with Google might be different than the responsibilities of your current provider, and understanding these changes is critical to ensuring the continued security and compliance of your workloads. Strong, verifiable security and regulatory compliance are often intertwined, and begin with strong management and oversight practices, consistent implementation of Google Cloud best practices, and active threat detection and monitoring.

For more information about designing a secure environment on Google Cloud, see Decide the security for your Google Cloud landing zone.

Monitoring, alerting, and logging

For more information about setting up monitoring, alerting, and logging, see:

Governance

Consider the following questions for your organization:

  • How can you ensure your users support and meet their compliance needs and align them with your business policies?
  • What strategies are available to maintain and organize your Google Cloud users and resources?

Effective governance is critical for helping to ensure reliability, security, and maintainability of your assets in Google Cloud. As in any system, entropy naturally increases over time and left unchecked, it can result in cloud sprawl and other maintainability challenges. Without effective governance, the accumulation of these challenges can impact your ability to achieve your business objectives and to reduce risk. Disciplined planning and enforcement of standards around naming conventions, labeling strategies, access controls, cost controls, and service levels is an important component of your cloud migration strategy. More broadly, the exercise of developing a governance strategy creates alignment among stakeholders and business leadership.

Support continuous compliance

To help support organization-wide compliance of your Google Cloud resources, consider establishing a consistent resource naming and grouping strategy. Google Cloud provides several methods for annotating and enforcing policies on resources:

  • Security marks let you classify resources to provide security insights from Security Command Center, and to enforce policies on groups of resources.
  • Labels can track your resource spend in Cloud Billing, and provide extra insights in Cloud Logging.
  • Tags for firewalls let you define sources and targets in global network firewall policies and regional network firewall policies.

For more information, see Risk and compliance as code.

What's next

Contributors

Authors: