Search the Community

Private connectivity is critical for organizations to secure data access and meet regulatory requirements — particularly if their applications access an operational database. Traditionally, organizations have relied on VPC Network Peering leveraging private services access, but that can be cumbersome at scale. And for more demanding environments, there’s Private Service Connect, which helps customers simplify and streamline private connectivity at scale, providing enhanced security controls, better IP space management, and flexible network topologies. This week at Google Cloud Next, we announced that Private Service Connect is now fully integrated with Cloud SQL, Google Cloud’s fully managed database service for PostgreSQL, MySQL, and SQL Server. With high availability (99.99% SLA), high performance, and rich data-protection capabilities, Cloud SQL is a popular choice for customers that run their business-critical applications on Compute Engine, Google Kubernetes Engine (GKE), Cloud Run, or on-premises. Integration with Private Service Connect makes it easier for these applications to securely connect to Cloud SQL without sacrificing on flexibility, scalability or security. Private Service Connect for Cloud SQL for SQL Server is now generally available, in addition to pre-existing support for MySQL and PostgreSQL. Benefits of Private Service Connect with Cloud SQL You can expect to find the following benefits from using Private Service Connect with Cloud SQL: Private Service Connect makes it easy to connect to Cloud SQL from multiple consumer VPC networks that belong to different groups, teams, projects, or organizations. Private Service Connect makes it easier to manage the IP space since you only need one IP address to access a Cloud SQL instance from the VPC. Because you choose this IP from your VPC, it’s like you access Cloud SQL as if it were a local target. Cloud SQL on Private Service Connect allows a single instance to manifest in different VPCs with different endpoints. This makes multi-tenanted deployments (e.g., SaaS applications) easier to manage and more secure. Private Service Connect simplifies connecting to primary instances, same-region read replicas, and cross-region read replicas in Cloud SQL. Configuring Private Service Connect with Cloud SQL Now let’s look into the details of configuring Private Service Connect with Cloud SQL: 1. Create a Cloud SQL instance Create a Cloud SQL Instance with Private Service Connect enabled. 2. Create a Private Service Connect endpoint Create a Private Service Connect Endpoint within your VPC to connect to Cloud SQL instance. You can choose an IP address for the endpoint from your VPC. While creating the endpoint, use the service attachment URI from the instance created in step #1. You can also allowlist specific projects within the VPC that can connect to Cloud SQL instance via Private Service Connect. 3. Connect to a Cloud SQL instance Once the Private Service Connect endpoint is created, you are ready to connect to the Cloud SQL instance. You can connect by using an internal IP address, a DNS record, the Cloud SQL Auth Proxy, or the Cloud SQL Language Connectors. Refer to the documentation for details of all the above steps along with code samples. Deployment patterns Now let’s look at different deployment patterns that Private Service Connect enables for Cloud SQL. 1. Connecting from single VPC to Cloud SQL If you have all your applications in a single VPC, then you can connect to the Cloud SQL instance using a single Private Service Connect endpoint within that VPC. If it’s a shared VPC, then you can control the list of projects that can connect. For example, let’s say you have both the production project and test project in the same VPC and you want to restrict access to production Cloud SQL instances to only the production project. You can do so by allowlisting only the production project. 2. Connecting from multiple VPCs to Cloud SQL If you have your applications in multiple VPCs and you want those applications to connect simultaneously to Cloud SQL, it is easy to do so using Private Service Connect. You just need to create a separate Private Service Connect endpoint within each VPC. 3. Connecting to Cloud SQL read replica instances In Cloud SQL you can create same-region read replicas to scale the read throughput and you can create cross-region read replicas for either disaster recovery or to reduce the read-latency for applications in different regions. It’s easier to connect privately to those read replicas using Private Service Connect. Since each read replica is considered a separate Cloud SQL instance, you need to create a new Private Service Connect endpoint for each read replica and connect to it from your applications. 4. Connecting from on-premises to Cloud SQL and connecting from a different region to Cloud SQL If an application hosted on-premises wants to connect to a Cloud SQL instance, then you can use Cloud Interconnect or VPN to reach the VPC that has the Private Service Connect endpoint for the Cloud SQL instance. You can also connect from an application in one region to the Private Service Connect endpoint in a different region within the same VPC using Private Service Connect global access. Benefits of Private Service Connect over Private Service Access Cloud SQL on Private Service Connect provides better security controls and ease of operations compared to traditional VPC network peering-based connectivity options such as Private Service Access. In Private Service Access, it’s cumbersome to have multiple VPCs simultaneously access a single Cloud SQL instance since you need to use VPN, Cloud Interconnect, or intermediate proxy (SOCKS5). Private Service Connect makes it easier since you can create separate Private Service Connect endpoints within each VPC. Private IP address space is limited and address space management is complex when using Private Service Access since you need to reserve an entire subnet range for Cloud SQL instances in each region. Private Service Connect brings a massive reduction in IP space usage, as you need to reserve only one IP address for each Private Service Connect endpoint that is mapped to the Cloud SQL instance. When using Private Service Access, you need to allowlist an entire subnet range beforehand when setting egress firewall rules, which can be overly permissive and an operational burden. With Private Service Connect, you can set granular firewall rules, which is better from a security perspective. When using Private Service Access, VPC Peering quotas can create challenges for deployment at scale. This is not an issue with Private Service Connect, as peering quotas don’t apply. Conclusion In conclusion, Private Service Connect with Cloud SQL offers strong security, ease of use, simplicity of operations, and seamless scalability. Click here for documentation on step-by-step instructions of using Private Service Connect with Cloud SQL. Click here to learn more about Cloud SQL. View the full article

Cloud SQL for SQL Server is a fully managed relational database that offers native SQL Server features along with several Google Cloud innovations, and allows migrating databases while retaining their existing versions or upgrading to newer ones. But migrating SQL Server databases to the cloud can be daunting. Concerns about downtime, complexity, and security risks can hinder your move to managed cloud databases. This week at Google Cloud Next, we announced the preview of support for SQL Server migrations to Cloud SQL for SQL Server in Database Migration Service , a fully managed serverless cloud service that performs database migrations with minimal downtime. Database Migration Service reduces migration complexity by loading an initial snapshot of the database followed by non-intrusive incremental load, reducing operational downtime. Let’s take a look at how it works and how to get started. Introducing SQL Server migration support Database Migration Service leverages built-in backup and restore to facilitate high-fidelity, low-downtime SQL Server migrations. Similar to other Database Migration Service homogeneous migration paths, SQL Server to Cloud SQL for SQL Server migrations are secure and reliable, and available at no additional charge. Database Migration Service offers: Minimal downtime and system overhead : Database Migration Service’s continuous native backup and restore technology helps ensure that your SQL Server source databases remain operational while the migration progresses, for reduced downtime. Because Database Migration Service leverages SQL Server backups to perform the migration, no additional overhead is introduced to your production operational systems. Serverless simplicity: As a managed service, you don’t need to manage any infrastructure for Database Migration Service, allowing your IT teams to focus on strategic initiatives rather than on managing complex migration setups. Security at the forefront: Database Migration Service supports encrypted SQL Server backups for robust protection throughout the migration. At Google Cloud, we’ve been working closely with customers who are looking to migrate SQL Server workloads. One of them is GoodRx Holdings, Inc., an American healthcare company that operates a telemedicine platform. "GoodRx is excited that Database Migration Service is now available to migrate SQL Server to Cloud SQL for SQL Server. Google Cloud's solutions help our business improve operational efficiencies in an intelligent, innovative, and cost-effective way." - Nitin Shingate, CTO GoodRx Migrating your SQL Server Databases with Database Migration Service Here’s how to start migrating your SQL Server workloads today using Database Migration Service: Navigate to the Database Migration area of the Google Cloud console, under Databases, and create a Connection Profile pointing to a Cloud Storage bucket to which your SQL Server backup files will be uploaded. Similarly, create another Connection Profile pointing to your chosen Cloud SQL for SQL Server instance. Create a migration job to connect both connection profiles and choose which databases you’d like to migrate. Test your migration job and make sure the test was successful as displayed below.,Then start it whenever you're ready. 5. Upload a full backup and continuously upload transaction log backups for each database to the Cloud Storage bucket at your desired frequency. 6. Once the full backups have been restored, the migration phase will change from “Initial Load” to “Incremental Load”. Database Migration Service keeps looking for new transaction log backup files and continuously restore them. 7. Monitor the progress of your migration jobs using the built-in metrics and logs to assess the right moment to complete the migration. 8. When ready to complete the migration, click “Promote” for Database Migration Service to recover the databases, making them available and completing the migration. Congratulations! You’ve completed your migration to Cloud SQL for SQL Server. Get started today Ready to migrate? Start your SQL Server migration to Google Cloud with the Database Migration Service. View the full article