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 yourworkloads. It can also help you plan how this infrastructure supports yourapplications. This planning includes identity management, organization andproject structure, and networking.

This document is part of the following multi-part series about migrating toGoogle 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-premisesenvironment, from a private hosting environment, from another cloud provider toGoogle Cloud, or if you're evaluating the opportunity to migrateand want to explore what it might look like. This document helps you understandthe available products and decisions you'll make building a foundation focusedon 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 tounderstand an array of topics and concepts related to cloud architecture. Apoorly planned foundation can cause your business to face delays, confusion,and downtime, and can put the success of your cloud migration at risk. This guideprovides an overview of Google Cloud foundation concepts anddecision points.

Each section of this document poses questions that you need to ask and answerfor your organization before building your foundation onGoogle Cloud. These questions are not exhaustive; they are meantto facilitate a conversation between your architecture teams and businessleadership about what is right for your organization. Your plans forinfrastructure, tooling, security, and account management are unique for yourbusiness and need deep consideration. When you finish this document and answerthe questions for your organization, you're ready to begin the formal planningof your cloud infrastructure and services that support your migration toGoogle Cloud.

Enterprise considerations

Consider the following questions for your organization:

  • Which IT responsibilities might change between you and yourinfrastructure 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 toGoogle Cloud?
  • How can you control where your data is stored and processed inaccordance with your data residency requirements?

Shared responsibility model

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

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

Compliance, security, and privacy

Many organizations have compliance requirements around industry and governmentstandards, regulations, and certifications. Many enterprise workloads aresubject to regulatory scrutiny, and can require attestations of compliance byyou and your cloud provider. If your business is regulated underHIPAA or HITECH,make sure you understandyour responsibilities and which Google Cloud services are regulated. For informationabout Google Cloud certifications and compliance standards, seetheCompliance resource center.For more information about region-specific or sector-specific regulations, seeGoogle Cloud and the General Data Protection Regulation (GDPR).

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

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

Data residency considerations

Geography can also be an important consideration for compliance. Make sure thatyou understand your data residency requirements and implement policies fordeploying workloads into new regions tocontrol where your data is stored and processed.Understand how to useresource location constraints to help ensure that your workloads can only be deployed in pre-approvedregions.You need to account for theregionality of different Google Cloud services when choosing the deployment target for your workloads. Make sure that youunderstand your regulatory compliance requirements and how to implement agovernance strategy that helps you ensure compliance.

Resource hierarchy

Consider the following questions for your organization:

  • How do your existing business and organizational structures map toGoogle 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 yourmigrated workloads?
  • What are best practices for managing multiple teams workingsimultaneously on multiple Google Cloud projects?

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

Understand Google Cloud resources

Resources are the fundamental components that make up all ofGoogle Cloud services. TheOrganization resource is the apex of the Google Cloud resource hierarchy. All resourcesthat belong to an organization are grouped under the organization node. Thisstructure provides central visibility and control over every resource thatbelongs to an organization.

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

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

Manage your Google Cloud projects

For more information about planning and managing your Google Cloudresource hierarchy, seeDecide a resource hierarchy for your Google Cloud landing zone.If you're already working in Google Cloud and have created independent projects as tests orproofs-of-concept, you canmigrate 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 toGoogle Cloud resources?
  • How will your existing security and access policies change when you moveto Google Cloud?
  • How will you securely enable your users and apps to interact withGoogle 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 youridentities. At a high level, understanding how you want to manage access to yourGoogle Cloud resources forms the basis for how you provision,configure, and maintain IAM.

Understand identities

Google Cloud usesidentities for authentication and access management. To access anyGoogle Cloud resources, a member of your organization must havean identity that Google Cloud can understand.Cloud Identity is an identity as a service (IDaaS) platform that letsyou centrally manage users and groups who can access Google Cloudresources. By setting up your users in Cloud Identity, you can set upsingle 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 forGoogle Cloud, seeDecide 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), aservice account (for Google Cloud products), aGoogle Group,or a Google Workspace or Cloud Identity account that canaccess a resource. Principals cannot perform any action that they aren'tpermitted to do.
  • Role:A collection of permissions.
  • Permission:Determines what operations are allowed on a resource. When you grant a roleto 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 whichprincipals have access to a resource, you create a policy and attach it tothe resource.

Proper setup and effective management of principals, roles, and permissionsforms the backbone of your security posture in Google Cloud.Access management helps protect you from internal misuse, and helps protect youfrom 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 aservice account.A service account is an identity that your programs and services can use toauthenticate and gain access to Google Cloud resources.

User-managed service accounts include service accounts that you explicitly create and manage usingIAM, and the Compute Engine default service account thatcomes 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 understandapplication default credentials,and follow our recommendedbest practices for service accounts to avoid exposing your resources to undue risk. The most common risks involveprivilege escalation or accidental deletion of a service account that a criticalapplication relies on.

Follow best practices

For more information about best practices to manage identity andaccess effectively, seeVerify every access attempt explicitly.

Billing

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

The concepts ofresource hierarchy andbilling are closely related, so it's critical that you and your business stakeholdersunderstand these concepts.

For more information about best practices, tools and techniques to help youtrack and control costs, seeCost 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 mightneed to connect it with your Google Cloud environment. For moreinformation, seePatterns for connecting other cloud service providers with Google Cloud.

When migrating production data and workloads to Google Cloud, we recommendthat you consider how the availability of the connectivity solution can affectthe 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 yourGoogle Cloud environment, you should adjust the maximumtransmission unit (MTU) to take protocol overhead into account. Doing so helpsensure that the data is transferred efficiently and accurately. This adjustmentcan also help prevent delays caused by data fragmentation and networkperformance issues. For example, if you're using Cloud VPN toconnect your source environment to your Google Cloud environment,you might need to configure the MTU to a lower value to accommodate the VPNprotocol overhead in each transmission unit.

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

  • Ensure that DNS records resolve across the source environment and yourGoogle Cloud environment.
  • Ensure that network routes between the source environment and yourGoogle Cloud environment correctly propagate acrossenvironments.

If you need to provision and use your own public IPv4 addresses in yourVPCs, seeBring your own IP address.

Understand DNS options

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

If you need to customize how Cloud DNS responds to queries according to theirsource or destination, seeDNS policies overview.For example, you can configure Cloud DNS to forward queries to your existingDNS 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 andconfiguring your own DNS servers, you can use the internal DNS service for yourprivate network. For more information, seeOverview of internal DNS.

Understand data transfer

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

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

  • Ingress traffic: Network traffic that enters yourGoogle Cloud environment from outside locations. Theselocations can be from the public internet, on-premises locations, or othercloud environments. Ingress is free for most services onGoogle Cloud. Some services that deal with internet-facingtraffic management, such asCloud Load Balancing,Cloud CDN,andGoogle Cloud Armor charge based on how much ingress traffic they handle.
  • Egress traffic: Network traffic that leaves yourGoogle Cloud environment in any way. Egress charges apply tomany Google Cloud services, including Compute Engine,Cloud Storage,Cloud SQL,andCloud Interconnect.
  • Regional and zonal traffic: Network traffic that crosses regional orzonal boundaries in Google Cloud can also be subject tobandwidth charges. These charges can impact how you choose to design yourapps for disaster recovery and high availability. Similar to egresscharges, cross-regional and cross-zonal traffic charges apply to manyGoogle Cloud services and are important to consider when planning forhigh availability and disaster recovery. For example, sending traffic to adatabase 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, andyou deploy and configure your network usingsoftware-defined networking (SDN). To ensure that yournetwork is configured in a consistent and repeatable way, you need to understandhow to automatically deploy and tear down your environments. You can use IaCtools, such asTerraform.

Security

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

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

For more information about designing a secure environment on Google Cloud, seeDecide 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 andalign them with your business policies?
  • What strategies are available to maintain and organize yourGoogle Cloud users and resources?

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

Support continuous compliance

To help support organization-wide compliance of yourGoogle Cloud resources, consider establishing a consistentresourcenaming and grouping strategy.Google Cloud provides several methods for annotating andenforcing policies on resources:

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

For more information, seeRisk and compliance as code.

What's next

Contributors

Authors:

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2024-07-31 UTC.