Cloud

Organizations migrating web applications and their APIs to the cloud need solutions to protect them from exploits and distributed denial of service (DDoS) attacks. Google Cloud Armor is a network security service that provides defenses against DDoS and OWASP Top 10 risks.  

We are excited to introduce several new features in Cloud Armor: granular rate limiting with the ability to combine multiple keys; and more flexibility in creating IP-based custom rules based on the origins of requests to further enhance DDoS and web application protection. 

Enforcing rate limiting with one or a combination of unique key identifiers 

We announced Cloud Armor’s rate-limiting capability in June 2022, a feature which can help customers curtail Layer 7 web requests or TCP/SSL connections based on request volume to ensure service availability. Since then, we further enhanced Cloud Armor’s per-client rate limiting capability by introducing additional rate limit keys and the ability to combine multiple keys that help throttle traffic. 

To configure a Cloud Armor rate limiting rule, users can enforce maximum requests or connection limits per client based on a key using the Google Cloud Console or API. We’re announcing several new key types including:

HTTP-PATH: for each HTTP URL path of requests

REGION-CODE: for each country/region code from which the request originate

SNI: for each server name indication value used in the TLS session for HTTPS requests

Cloud Armor users can now select up to three types from the list above where the combination of values across the selected types will form the actual key on which rate limit action is taken. 

Previously a rate limiting rule based on source IP could potentially trigger false positives when a single client is visiting a web application page designed with numerous url paths. To avoid legitimate traffic accidentally being throttled in such design, a multi-key Cloud Armor rate limiting rule based on ‘IP” and “HTTP-PATH” can be a good solution. 

A sample gcloud command for this example would be:

Providing flexible WAF rule configurations with new attributes: True-Client-IP and other custom IP

Cloud Armor IP filtering rules typically use the caller’s Client-IP in their evaluation. A common concern we heard from Cloud Armor customers is potential false positive DDoS alerts when Google Cloud-hosted services are run behind other infrastructure providers, such as an upstream CDN proxy or their own ingress proxy, since Cloud Armor will observe larger than usual traffic from a single source. In this example scenario, Cloud Armor’s security policy by default evaluates upstream proxy (23.220.162.152) instead of the actual IPs from upstream distributed clients, leaving users unaware of the true source of the traffic.

To address this, we recently introduced in public preview a user configurable field called “user_ip” to support True-Client-IP and other IP sources in the request header. Users can now tell Cloud Armor which IP address to use for their L7 filtering rules, Adaptive Protection, and Threat Intelligence by using the following instructions:

Take the same example with a single incoming request to Cloud Armor with layered header information on IP. Cloud Armor will still default to interrogating the Client-IP, in this case 23.220.162.152, which belongs to the upstream proxy. Additional configurations, however, allow customers to choose what Cloud Armor inspects. 

Example 1: You can set “True-Client-IP” (142.251.163.99) to be used by Cloud Armor for policy wide inspection by using “–user-ip-request-headers=True-Client-IP”

Example 2: You can set the left most value of the XFF header (142.251.163.102) to be used by Cloud Armor by using “–user-ip-request-headers=X-Forwarded-For”

Example 3: You can set a sequence of IP header information to be used by Cloud Armor by configuring “–user-ip-request-headers=True-Client-IP, X-Forwarded-For” which allows Cloud Armor to 

use True-Client-IP (142.251.163.99) as first choice

use XFF header (left most value 142.251.163.102) when True-Client-IP is not present

default back to Client-IP (142.251.163.99) when either True-Client-IP nor XFF is present

See more details on which IP you should choose for Cloud Armor evaluation here. After choosing an IP resolution strategy, you can now apply user_ip to Cloud Armor custom rules, Adaptive Protection, and Threat Intelligence. Setting up the appropriate user_ip will reduce  false positives when Adaptive Protection is enabled. 

Note that use of the user_ip field is  an indicator of trust and care must be taken to ensure that the user_ip based features are only used when the upstream is considered trusted. For example, in a case where Adaptive Protection Auto Deploy is configured to use True-Client-IP to establish DDoS model baseline, untrusted sources such as a non-CDN upstream providing an unsanitized True-Client-IP header would allow a potential header-injection attack vector to compromise AutoDeploy rules.

Protecting API workloads with GraphQL content parsing

We understand web applications are evolving with the extensive usage of APIs and new web standards. Cloud Armor is positioned to leverage its WAF capabilities to take on a bigger role in protecting API workloads. The first step is to support parsing of GraphQL content in the incoming request. As an extension to our JSON content parsing capability, we are adding an additional flag for users to apply preconfigured WAF interrogation of incoming POST body requests in GraphQL format.

This can reduce false positives from preconfigured WAF rules for our customers who natively use GraphQL-formatted requests and expand Cloud Armor’s inspection of OWASP attack vectors in fields with JSON and GraphQL payload. 

Do more with Cloud Armor

The first half of 2023 has been a busy and exciting few months for Cloud Armor. We introduced general availability of advanced rule tuning for preconfigured WAF rules early this year to help improve WAF tuning flexibility, reduce false positives, and automatically deploy Adaptive Protection. We also announced Cloud Armor for regional HTTP(S) load balancers in Preview, which allows users to create regionally scoped security policies where Cloud Armor rules are stored, evaluated, and enforced in a designated Cloud region, which can increase reliability needs. 

To get the latest Cloud Armor feature release updates delivered to you, add this page to your feed reader.

We’re continually working to improve Google Cloud’s Identity and Access Management (IAM) capabilities to help secure and govern your cloud environment. When organizations need to grant external applications permission to access Google Cloud APIs and resources there are several options. While many customers have embraced our updated guidance for authentication that includes using Workload identity federation where possible, service account keys are still widely used for authenticating external apps.  

To help address security challenges that may arise from the use of service account keys, we are excited to introduce service account key expiry. With this capability, customers can now configure an Organization Policy at the organization, folder, and project level to limit the usable duration of new service account keys.

As companies run applications in Google Cloud, they rely on service accounts for day-to-day operations. These service accounts often have more privileged access than end-user identities, and provide access to workloads and applications in production environments. To help ensure operations are not interrupted, Google Cloud service account keys by default do not expire. 

However, not all environments or workloads require a long key lifetime, and key leakage is similar to a password leak — anyone in possession of the key has access to the services and APIs it is authorized to access. Because use of service keys is so prevalent, developers often embed security keys in source code. 

If this code is inadvertently uploaded to public repositories, anyone who comes across the key can have access to the cloud resources it’s associated with — a significant security issue. This is where service account key expiry can help, said Antoine Castex, platform architect at L’Oreal: “We are using the new service account key expiry capability in Google Cloud, and it is helping us keep our projects and resources safe. This capability allows us to easily configure an expiration time for service account keys, significantly reducing risks around leaked and compromised keys,” said Antoine Castex. 

Service account keys in production environments

Service account key expiry can significantly improve the security posture of any organization using account keys. However, because developers are so used to long-lived keys, changing the default configuration to include expiry can lead to unintended outages that can be difficult to troubleshoot. 

Because of this, we recommend using this feature in certain scenarios such as when developers are building code in a non-production environment for an application that can only authenticate with service account keys or using a 3rd party tool that can only authenticate with service account keys. For more advanced organizations that have service account keys disabled already using Organization Policy, this feature can also act as an exception process to allow usage of keys for a limited time without changing their organization’s security policy.

If you want to set up key rotation for your service account keys in your organization, we recommend you monitor keys using cloud asset inventory instead of using key expiry to avoid potential outages. This will allow you to send warning notifications to developers when a key is about to expire and it is time to rotate the key. Alternatively, you can consider embedding the key rotation process into the developer’s workflow by leveraging tools like HashiCorp Vault. 

How to setup Service Account Key Expiry

Setting up key expiry is straightforward. As an organization administrator, you can go to the organization policy page and find the constraint with the ID “constraints/iam.serviceAccountKeyExpiryHours”.

You can then click “Edit” and configure a custom allow policy for a duration of (8h, 24h, 168h, 336h, 720h, 1440h, or 2160h) with policy enforcement set to “Replace”. Once this is configured, all new service account keys under the organization/folder/project will use this expiration period.

How to get started

You can get started using the service account key documentation. To learn more about service accounts you can watch this video primer and refer to our Service Accounts overview guide.

With a year of the Google Cloud Ready – Sustainability program under our belts, it’s a perfect time to measure the impact that the program and its partners have had — after all, we’re all about measurement. 

Looking over the past year, it’s clear that the program has come at an opportune time: A recent Harris poll conducted on behalf of Google Cloud indicates that motivation for sustainability initiatives remains high, with 84% of respondents agreeing that, “In the past 12 months, I realized I care more about sustainability than before.” However, progress has stalled slightly against economic headwinds, and environmental, social, and governance (ESG) efforts have slipped from first to third place among organizational priorities since the previous year. 

Over the next four blog posts, we’ll get into the details of how the program has evolved, including new initiatives, new partnerships, and even new ways to think about sustainability in a business context — and where the program is going next. 

Taking a rigorous approach

From day one, one of the guiding principles of the Google Cloud Ready – Sustainability program has been its rigorous selection criteria for partners, and we’re pleased to report that this approach has been well received by partners and customers alike. It ensures that the solutions our partners deliver are backed by domain expertise and climate science. This has become even more important today, with 59% of executives saying that their organizations overstate their sustainability methods, which can potentially result in reputational damage from accusations of greenwashing.  

We’ve also observed that the term “sustainability” is evolving from a somewhat ambiguous notion into a clearly defined component of sustainable business transformation clearly demonstrating measurable benefits that accrue to the bottom line. For this reason, sustainability reporting is now becoming on par with financial reporting. Regulators, legislators, NGOs, and citizen groups are starting to demand clear, third-party reporting from organizations, while business leaders want to see positive financial results. Without reliable, accurate, and verified measurement, ambiguity and greenwashing risks loom. We believe that the Google Cloud Ready – Sustainability program is providing the technology, accountability, and skills that are key to accelerating progress.

Take CARTO, for example, a founding member of the Google Cloud Ready – Sustainability program. Carto enables organizations to use spatial data and analysis for more efficient delivery routes, better behavioral marketing, strategic store placements, and much more. Data scientists, developers, and analysts use CARTO to optimize sustainable business processes and predict future outcomes through the power of spatial data science. Hundreds of global organizations use CARTO to drive impactful sustainability projects to better understand and protect biodiversity, analyze climate impacts on the built environment, guide the roll-out of sustainable energy and transport infrastructures, and reduce thousands of tons of CO2 emissions annually.

Measure, optimize, and transform

The changes we’ve seen over the past year have shaped the program in ways that we anticipate will pay dividends in the future.

First, it has resulted in a partner ecosystem that embraces quality over quantity. We’ve grown  from the original 18 charter partners to 30, including partners such as Airbus Intelligence, which owns and operates nine optical and radar satellites to support customers facing sustainability challenges. Data from Airbus has helped farmers minimize excessive water and fertilizer use while maintaining or increasing crop yields; determined water, sanitation, and hygiene service needs in Kenya; and created an early warning for forest damage in Brazil. 

Second, while raw data is valuable, its value lies in proper interpretation and taking data-driven action. Consider, for example, our new partner mCloud — whose AssetCare® solutions optimize the performance, reliability, and sustainability of energy-intensive assets, powered by a host of Google Cloud technologies including BigQuery, Vertex AI, and Looker. By helping customers in energy-intensive industries continuously take action on asset data, AssetCare helps customers worldwide save over 120 million kWh of energy each year, avoiding more than 80,000 tons in CO2 emissions annually and the equivalent of 18,000 gas-powered passenger cars driven for an entire year. We want to continue providing tools that help organizations interpret data for meaningful insights to inform decisions and drive action.

Third, it’s important to recognize where and how partner organizations are aligned to supporting sustainable business transformations. We’re introducing a new system to indicate the maturity level of our sustainability partners, with clear criteria to help them augment their offerings in ways that add value for our mutual customers, including new generative AI models.   

Lastly, we want the program to meet the needs of customers along their own ESG journeys, from measuring performance to optimizing it, and finally, to transforming their organizations to become driven by environmental and economic resilience — measure, optimize, and transform. 

Measure impact and manage ESG performance

Optimize programs along the value chain, better manage transportation and logistics, and drive toward carbon-free energy

Transform into a net-zero organization 

Each of these stages is grounded in real-world activity and investment, as we’ll see in upcoming blog posts. For example, our new partner Watershed, the enterprise climate platform, powers end-to-end climate platforms for companies like Spotify, Carlyle, Block, and SKIMS. Watershed delivers granular, audit-ready emissions data; one-click disclosure and reporting; target-setting and decarbonization tools; and cutting-edge carbon removal — all in one enterprise-grade software platform. With more than 291M tCO2e under management — more than Spain’s annual emissions — Watershed has helped leading companies satisfy regulatory requirements, unlock new business opportunities, and address climate-related risks. 

Looking forward to the next year and beyond

While we’re thrilled by the successes we’ve achieved with our partners in the Google Cloud Ready – Sustainability program, this is just the beginning.

Google Cloud Ready – Sustainability is part of Google Cloud Partner Advantage, designed to maximize our partners’ success across business models, customer requirements, success metrics, and strategic priorities. Our focus moving forward is to provide the practical, real-world solutions that organizations need to achieve measurable ESG and economic results. 

Look for Google Cloud Ready – Sustainability validated solutions on the Google Cloud Partner Directory Listing, Google Cloud Ready Sustainability Partner Advantage page, and — if applicable — via the Google Cloud Marketplace. We hope to help customers better understand how these technologies can help them meet their ESG goals, find the right solutions for their particular challenges, and implement solutions faster. 

Learn more about the Google Cloud Ready – Sustainability validation initiative and explore all our partners in sustainability transformation.

Do you have a background in building and managing cloud architecture projects in AWS or Azure? Are you looking to expand those skills to Google Cloud? Google Cloud Learning has got you covered.

With the rise of multicloud architecture and agile environments, coupled with the growing cloud skills gap, translating and certifying your knowledge and skills from one cloud to another cloud provider can help boost your resume, helping you stand out in the industry.

To support you on your path to developing your multicloud skill set, we’ve illustrated a new #GCPSketchnote to provide a view of the technologies you should learn to become a multicloud architect.

What are the basic skills you need to work across all major clouds?

It’s important to have a foundational level of cloud knowledge for at least one cloud provider. On top of that, we’ve listed some of the core skills you will need to architect on 

Identity – Identity and Access Management (IAM), Role-based Access Controls (RBAC), Google Cloud Directory Sync

Security – Key management, access controls, Distributed Denial of Service (DDoS), Web Application Firewall (WAF), etc.}

Kubernetes – Control planes, scaling rules, provisioning, etc

Open source – operating systems, underlying OSS, open source frameworks

DevOps – Continuous Integration/Continuous Delivery (CI/CD), Agile, Scrum, rapid prototyping, etc.

Operations and management – Security Information and Event Management (SIEM) integration, policies, chargeback, hierarchies, and more

Network concepts and topologies – hub-n-spoke, VNET/VPCs, interconnect vs. ExpressRoute, hairpinning, High Availability (HA) and Disaster Recovery (DR), load balancers, etc.}

Data repos and movement – BigQuery vs. Synapse/Redshift, Kafka vs. DataProc

Automating deployments – JSON, Terraform, Git, Puppet, Chef, etc

APIs – lifecycle management, proxies, integration, security

AI and ML – generative AI, regular AI, tooling, ML modeling, etc

Courses to help you translate AWS and/or Azure skills to Google Cloud

Google Cloud Skills Boost offers two learning paths that are especially designed for professionals who already use and build cloud solutions on AWS and/or Azure. The courses and labs within these learning paths help learners understand the similarities and differences between the services provided by Google Cloud, Azure and AWS, helping you answer, “I do this on Azure; what is the equivalent on Google Cloud?” As a bonus, complete the learning path to earn an industry-recognized Google Cloud skill badge, which you can add to your resume. The learning path will also help prepare cloud professionals for the Google Cloud Professional Cloud Architect certification.

Follow the sketchnote:

Cloud Architect Accelerated Learning Path for AWS professionals

Cloud Architect Accelerated Learning Path for Azure professionals

Already certified in another cloud? 

A tip for those looking to earn a Google Cloud Professional Cloud Architect certification, who already have the AWS Solutions Architect Professional Certification and the Azure Architect Expert Certifications, keep in mind some of the differences between these cloud certification exams.

The AWS Solutions Architect Professional Certification generally requires more practical experience with AWS services, architectures, and deployments. Exam takers are expected to have hands-on experience designing and implementing enterprise-scale solutions specifically using AWS, and the exam delves into advanced architectural concepts, high availability, fault tolerance, cost optimization, and complex multi-tier application design on AWS.

The Azure Solutions Architect Expert Certification requires significant experience with Azure administration, architectures, and deployments. Exam takers are expected to have hands-on experience designing and implementing enterprise-scale solutions specifically using Azure, and need to be familiar with DevOps, code debugging (ex: JSON), networking security, and data. 

The Google Cloud Professional Cloud Architect Certification validates general architecture and industry experience, as well as specific hands-on experience with Google Cloud. Exam takers should be experienced in software development methodologies and approaches including multi-tiered distributed applications which span multi-cloud or hybrid environments.

 And, don’t miss the no-cost resource that helps you prepare for your Google Cloud certification: Preparing for the Google Cloud Professional Cloud Architect journey

Learn more about and register for the Google Cloud Professional Cloud Architect certification here, and get started building your multicloud skills today. New users are eligible for a 30-day no-cost trial on Google Cloud Skills Boost.

As the default and recommended mode of cluster operation in Google Kubernetes Engine (GKE), we’ve told you about how GKE Autopilot can save you up to 85% on your Kubernetes total cost of ownership (TCO)1 compared with traditional managed Kubernetes. That’s a lot of potential savings — to say nothing of the operational savings that GKE Autopilot users enjoy. 

But how? Where do these cost efficiencies come from? More to the point, how can you use Autopilot mode to save yourself the most money? In this blog post, we dig into how GKE Autopilot pricing works, and explore the types of considerations you should be factoring into your Kubernetes cost-efficiency analysis.

Traditional managed Kubernetes pricing model

But first, let’s review how pricing works in a traditional managed Kubernetes environment. Kubernetes clusters run their workloads on nodes — underlying compute and infrastructure resources (usually virtual machines, or VMs). With traditional managed Kubernetes, you are indirectly paying for those provisioned nodes including their CPU/Memory ratios and other attributes, e.g., which Compute Engine machine family they are running on.

GKE Autopilot pricing model 

So, having established that you’re likely not bin packing your Kubernetes clusters anywhere near 100% efficiency, what’s the alternative? GKE Autopilot mode provides a novel approach: pay only for the resources your workload requests, and leave the bin-packing to GKE. In this model, each workload specifies the resources it needs — the machine family type, CPU, GPU, memory, storage, spot, etc. — and you only pay for those requested resources while the workload is running.

With Autopilot, you don’t pay for the OS, system workloads, or any unused capacity on the node. In fact, node efficiency is left entirely for GKE to manage. This has the added benefit of letting each workload define what it needs with regards to machine families and node characteristics, without needing to provision finite node pools. 

So what’s the catch? Compared to node/VM pricing, Autopilot resource unit pricing is more expensive. But that does not mean GKE Autopilot is pricier than traditional managed Kubernetes overall. In fact, there’s a break-even point in terms of utilization under which Autopilot is actually cheaper than managed Kubernetes. 

A sample cost comparison

To illustrate how to do a cost analysis for your own workloads, let’s look at running the same workloads in a high-availability configuration on both traditional managed Kubernetes and GKE Autopilot mode, and compare the costs. To keep it simple, we’ll stick with vCPU and memory, although you could easily add storage to this framework.

On traditional managed Kubernetes, we provision a cluster with 12 e2-standard-8 type nodes, spread across three zones for HA. This adds up to 96 vCPU / 384 GB memory, for a total list-price cost of about $2,545 per month.

For Autopilot, we just specify the workloads’ required resources in the pod spec, without having to set up node pools. After deploying, we use GKE’s built-in cost optimization tool to analyze our actual usage, and find that our workloads have a mostly static usage pattern, with periodic spikes. We therefore set our request requests to about 15% above that static baseline and configure Horizontal Pod autoscaling (HPA) to deal with the spikes. 

We know that our target environment requires a certain number of replicas, each of which requests CPU and RAM via the resources.requests Pod specification, totaling 48 vCPU and 192 GB of RAM for about 96% of the time. HPA increases the replica count threefold during scale events for the remaining 4% of the time (about an hour per day). With this setup, the total list-price cost on Autopilot is approximately $2,250 per month — about 12% less than the equivalent setup on managed Kubernetes.

You may have some questions about this example. For one, why didn’t we just provision fewer nodes on GKE Standard to begin with? For two reasons:

Because bin packing is difficult in practice. We will not be able to achieve the same level of bin packing on GKE Standard that we get on Autopilot, so we provision extra capacity to ensure we don’t hit any unintended limits.

There are some spikes in our usage and we need spare capability available to handle it.

All told, GKE Autopilot makes more efficient use of resources, so there is less guesswork and fewer chances of creating an inefficient setup.

GCP Partner EPAM Helps Customers Save with Autopilot

by Stan Drapkin – North American Google Cloud Chief Technologist, EPAM Systems, Inc.

We recommend Autopilot for cost-conscious customers

There are several reasons why GKE Autopilot is widely adopted by our customers. First, it simplifies the management of Kubernetes clusters by automating many tasks, such as node provisioning, scaling and upgrades, which can be time-consuming and error-prone. This frees up developers and operators to focus on building and deploying applications rather than managing infrastructure. 

Second, GKE Autopilot provides a highly secure and reliable Kubernetes environment by default. It implements industry best practices for security and includes features like node auto-repair, which automatically replaces unhealthy nodes, and horizontal pod autoscaling, which automatically adjusts resources based on application demand.  

Comparing costs on Autopilot

There’s no one generic benchmark that adequately quantifies GKE Autopilot vs. GKE Standard, because every application is different. The best way to compare is to deploy an application on both GKE Standard and GKE Autopilot and compare the costs incurred.

One sample GKE Autopilot deployment scenario we’ve comparison-tested with synthetic data is the Open-Source Bank of Anthos (BoA), which simulates a payment processing network. You too can deploy this sample app by following this tutorial.

A BoA deployment consists of two data-stores and seven services (four Python and three Java) and is a reasonable “real-world” test, as far as sample apps go:

In our tests, we saw up to 40% cost reduction on GKE Autopilot as compared to Standard. 

We also extrapolated the costs for both workloads on an annual basis. For the GKE Standard workload, we would incur $3,317 USD in cloud costs for the year. However, for the GKE Autopilot workload it would only be $1,906 USD — a difference of $1,411, or 42.5%. This was a simple workload, so you can’t make any generalizations (especially not for already optimized workloads), but it does show Autopilot’s potential for specific cases. 

Customers have discovered that GKE Autopilot offers a hassle-free, secure and economical solution for running their Kubernetes workloads. This is why we recommend our customers to consider adopting it as their primary choice for running containerized applications on Google Cloud.

Soft savings with GKE Autopilot

There are other benefits to GKE Autopilot than just raw dollar savings. Again and again, GKE Autopilot customers tell us they don’t need to provision as much headroom for their applications, and they have to perform much less day-to-day management. Let’s take a deeper look.  

Autopilot minimizes headroom requirements

Autopilot can help you cut down on how much spare headroom you need to provision, including in high availability (HA) setups. If you anticipate an increase in load, provisioning extra headroom provides for options like HPA to scale to meet increased demand. Similarly, for redundancy in a HA setup, you may need to have multiple nodes in several geographically separated zones.

Autopilot spins up new hardware on demand in response to scaling, so you don’t need to pre-allocate infrastructure headroom that sits idle. And in an Autopilot HA setup, you only need to deploy pods per zone rather than duplicates of the entire node, which again, is likely much less expensive. Autopilot also makes it easy to duplicate only specific workloads with higher availability requirements, and you can rely on Autopilot to shift less critical workloads to a new healthy zone on-demand.

Day 2 operations 

With traditional managed Kubernetes, you manage the Kubernetes nodes including provisioning/shaping, upgrading, patching, and dealing with security incidents.

With Autopilot, Google SRE does all this, while providing a Pod SLA that’s additive to the GKE Standard SLA. At the same time, you still retain control and flexibility via maintenance policies.

The bottom line

If your team is amazing at bin packing and you need the level of control offered by directly managing nodes, a traditional managed Kubernetes platform like GKE Standard is likely your best bet. However, even if you’re doing a phenomenal job of bin packing, chances are you spend a lot of time and energy on it. In most cases, this effort rises linearly with the scale of the Kubernetes fleet, and smaller clusters wind up paying less attention to running efficiently. If your platform team needs to reclaim the effort they spend on bin packing, Autopilot can help reduce Day 2 operations and the financial risks of inefficient bin packing, while freeing you to build more powerful developer experiences.

To learn how to get up and running with Autopilot quickly, check out the following resources:

Overview of Autopilot

Autopilot pricing details

Using Compute Classes to specify machine types

Migrating workloads to GKE Autopilot

Deploy a full stack workload on Autopilot

Deploying workloads like Redis, high-availability PostgreSQL, and high-availability Kafka on Autopilot

1. Forrester TEI report: GKE Autopilot – January 2023 – https://services.google.com/fh/files/misc/forrester_tei_of_gke_autopilot.pdf

Ford Motor Company is an American multinational automobile manufacturer headquartered in Dearborn, Michigan, United States. In this blog post, we’re highlighting Ford for the DevOps achievements that earned them the ‘Growing DevOps throughout your organization’ award in the2022 DevOps Awards. To learn more about the winners and how they used DORA metrics and practices to grow their businesses, start here.

Ford recognized the potential of cloud computing early on and had approximately 50% of our computing landscape, including CaaS, PaaS, and SaaS, on the cloud. While leveraging the cloud and hybrid environments improved our business operations, none of the platforms we used enforced DevOps practices. Consequently, some teams had console access in production environments and did not consistently adopt basic DevOps and GitOps practices — if they used them at all.

Without proper DevOps practices, our company was exposed to increased risks, such as service issues and the associated costs, delays, and negative customer experiences. As our cloud adoption continued to grow, it became evident that any large-scale migration would introduce even more risks if not effectively managed.

Cloud-first mindset

To maximize the benefits of the cloud, the company realized the importance of adopting a “cloud-first” mindset, where new applications or updated technologies would be developed or migrated to the cloud as the primary option whenever feasible. To achieve this, we recognized the need for a platform that would drive mature DevOps practices.

We set out to:

Enhance customer experience and gain better cost control

Securely deliver power and scalability to teams without resource wastage

Provide business-led app teams with as much direct control as possible

Google Cloud and Terraform at Ford

To solve the above problems, the Ford teams developed a scalable approach to managing project environments through pipelines. These pipelines not only organized the platform but also built and maintained thousands of Google Cloud projects. Together, we and our partners developed a unique solution that restricted console access to sandbox environments only, with system account restrictions that enforced CI/CD pipelines within their extensive community of app team developers.

The pipelines were divided into two components:

The first controlled Google Cloud projects, ensuring that Ford implemented Google-recommended security practices and enterprise technology attestations and policies.

The second pipeline granted business teams sufficient control over their infrastructure, enabling them to dynamically provision and manage infrastructure according to their requirements.

Given that most Google Cloud services support Terraform providers, our Ford Services Teams were able to test and support these providers and create test scripts that all of our DevOps teams could utilize. We believe that Google Cloud’s built-in support for Terraform providers is a game-changer for our company.

To promote the adoption of DevOps best practices throughout the organization, we also relied on our automated provisioning tool: the Ford Cloud Portal (FCP). The FCP enabled teams to rapidly provision resources, facilitated the creation of app-based repositories, provided links to policy attestations and training, and even offered specialized bundles supporting specific personas, thereby accelerating deployments significantly.

The FCP established managed pipelines, where each app team had its own repository to manage infrastructure, fostering true GitOps/DevOps experiences. Through an intuitive interface, the FCP guided app teams through all the steps of the Google Cloud provisioning process, allowing even novice teams to navigate and manage both Google Cloud and infrastructure-as-code environments while reinforcing DevOps practices. Additionally, the FCP provided a list of fully vetted, contractually approved, and Ford-supported Google Cloud services on the Service Selection Screen, enabling teams to support, develop, and share best practices effectively.

The FCP also offered architecture-specific bundles that assisted teams in configuring specific elements based on their use cases. This flexibility allowed teams to choose whether to configure just the project, the project and infrastructure, or even entire development environments. Regardless of the elements configured, they would do so with value-added and validated development and data scientist tooling.

Distributing success to all teams

By mandating the use of pipelines for infrastructure provisioning and management, supported by Google Cloud Terraform services providers, Ford’s app teams embraced the DevOps culture. They no longer had to manage and configure infrastructure through error-prone tickets or interfaces. Instead, they integrated infrastructure provisioning into their pipelines, enabling continuous deployment and testing. This significantly improved our change control and security posture, facilitating faster rollout and rollback of changes. As a result, we witnessed substantial adoption of DevOps practices across our developer community, with over 12% of Ford applications now benefiting from DevOps-managed Google Cloud footprints.

The results have been evident. In 2022 alone, we achieved the following:

Exceeded our application migration targets to Google Cloud with mandated DevOps and GitOps practices

Promoted the use of FCP/Google Cloud pipelines throughout the organization, with approximately half of Ford’s software engineers utilizing pipelines for infrastructure provisioning and management

Moreover, Ford observed notable improvements in dynamic scalability and availability, including in some of DORA’s key metrics:

Deployment frequency: Changes to projects and infrastructure became over 100x times faster, taking minutes instead of weeks, thanks to the migration to Google Cloud.

Lead time for changes: Provisioning velocity in the project pipeline improved tenfold, with changes that previously took over 80 hours on a single channel now being provisioned in less than half an hour.

Change failure rate

Time to restore service: 

Project capacity: By transitioning from a single channel to parallelized sets, Ford can now handle the enterprise load of project creations or updates per month.

Productivity: Since the shift, Ford has eliminated all manual bottlenecks associated with obtaining Google Cloud projects.

Stay tuned for the rest of the series highlighting the 2022 DevOps Award Winners and read the 2022 State of DevOps report to dive deeper into the DORA research.

This spring we launched a new series of Google Cloud AI & Research Days at Google’s regional US offices. Each event is designed to help local researchers and industry experts innovate, network and learn from each other in person, with presentations from thought leaders, demonstrations of Google solutions, and open-ended time for chatting and networking. By providing an opportunity to share problems and explore solutions, Google Cloud aims to facilitate collaboration and jumpstart new breakthroughs. In March the inaugural session in San Diego focused on biomedical research; the next three in Austin in April, Atlanta in May, and New York City in June all focused on AI innovation. At each AI & Research Day, scientific researchers, IT leaders, and Google experts gathered together to advance the common goal of scientific discovery.

In San Diego, participants heard:

How ITS leaders from the University of California, Riverside (UCR) developed an innovative research funding model that helps UCR researchers cut costs and avoid the queues for time and computing capacity on supercomputers. With a flexible, fixed cost subscription model for Google Cloud access, ITS can respond quickly and at scale to enterprise and research needs.

How a pilot study of a mouse brain showed researchers at the Salk Institute that cloud computing could transform the institute’s computing infrastructureand improve workflows. As a result, Salk launched a five-year $23 million initiative to accelerate their transition to cloud infrastructure.

In Austin, participants learned about:

How Katana Graph uses Google Cloud’s Kubernetes and Vertex AI to build a scalable AI platform optimized for graphing on massive connected datasets. The platform helps their customers from precision medicine to banking deliver faster and more accurate results.

How Texans Connecting Overdose Prevention Efforts (TxCOPE) partnered with Google Cloud to develop an app that integrates data sources, visualizes community impact, and organizes interventions and supports to reduce opioid deaths. The app disseminates information and resources that can lead to treatment and save lives.

In Atlanta, participants discussed:

How to design and scope generative AI technologies responsibly with students, researchers, faculty, and staff first in mind.

How the Responsible AI organization at Google works to advance interdisciplinary research.

How Form Bio, a leading biotech firm, partnered with Google Cloud to provide scientific data management and workflow solutions in the synthetic biology and gene therapy fields.

In New York City, participants discovered:

How Google’s HPC solutions can drive impact at scale, with speed, security, and cost efficiency

How Google tools like Vertex AI can detect patterns and anomalies in massive datasets to help prevent cybercrime.

How NYU’s Research and Technology Services modernized their cyber infrastructure on Google Cloud to serve research faculty around the globe as well as drive core missions like sustainability.

To attend the next Google Cloud AI & Research Day, register here for San Francisco on August 31. More cities will be announced for fall workshops.

Security insights are essential for a secure enterprise browsing solution. By integrating your chosen security reporting solution with Chrome Enterprise, IT and security teams can gain a comprehensive view of the potential threats users face on the web and make data-driven decisions in their security journey.

The Chrome Enterprise and Palo Alto Networks Cortex XDRintegration is now available in the Google Admin console in Chrome Browser Cloud Management. This integration has been validated by Chrome Enterprise Recommended, a program created to help enterprises find technologies that make working on the web and in the cloud even better. 

With this integration, organizations can easily send browser insights from managed Chrome browsers to Palo Alto Networks Cortex XDR for further analysis. In addition, customers can use these insights to create remediation rules and actions with Cortex XSIAM for an automated, end-to-end remediation experience for their browsers.For more information, see the XSIAM content pack here. 

Available Security Events

Malware transfer

Password changed

Unapproved password reuse

Unsafe site visit

Log-in events

Password breaches 

Extension installs

Crash events 

Content transfer*

Content unscanned*

Sensitive data transfer*

Enrolling machines in Chrome Browser Cloud Management

Getting started is easy. The first step is to set up Chrome Browser Cloud Management for your organization. This tool allows organizations to manage Chrome browsers from a single cloud-based Admin console across Windows, Mac, Linux, Android, and iOS at no additional cost. It is also the same console where IT teams can manage Chrome OS.

Once Chrome Browser Cloud Management is set up, you can turn on the integration with Palo Alto Networks Cortex to send critical security events for further investigation. You do not need to be fully managing the browser to do this.

Check out this guide for steps on how to enroll your devices. Once you are done, or if you already have Chrome Browser Cloud Management in place, move to the steps below. 

Set up Chrome Enterprise connectors in Palo Alto Networks Cortex XDR

Log into Palo Alto Networks Cortex XDR at https://cortex-gateway.paloaltonetworks.com. 

Under Settings > Configurations > Custom Collectors , click the Add Instance button (or click on an instance of a HTTP log collector) to create a new repository or select an existing one that you want to send Chrome browser security events to. 

When you create a new repository, you need to give it a name, select JSON as Log Format, set the Compression as uncompressed and enter the Vendor andProduct names. (Note: If you don’t enter in a Vendor or Product, Cortex XDR will label the dataset as “unknown_unknown_raw”.)

Click Save & Generate Token and copy the token that is generated. You will need to enter this into the admin console in the next step.

Set up in Chrome Browser Cloud Management

Log in to the Google Admin console at admin.google.com and select the organizational unit that contains the enrolled Chrome browsers that you want to send security events to Palo Alto Networks Cortex XDR.

Navigate to Devices > Chrome > Users and browsers. Add a filter for“event reporting”.

Under Browser reporting > Event reporting, select Enable event reporting. Under the additional settings, you can specify which events you want to send to Palo Alto Networks Cortex XDR.

Now that the events are turned on, click on the blue hyperlink called “Reporting connector provider configurations” to take you to the connector provider configurations, or it can be found under Devices > Chrome > Connectors.

Click the New Provider Configuration button and select Palo Alto Networks as the provider.

Enter the configuration name that you want this connector to display as in the Google Admin console.

Enter the host name of your Palo Alto Networks instance and the ingest token value from step 4 of the last section

You can find your instance URL under Settings > Configurations > Data Collection > Custom Collectors and select the collector that you just created

Click the three dots and select Copy API URL

Remove the ‘https://’ and anything after the ‘.com’ to use as the hostname in the admin console. E.g. https://chrome.xdr.us.paloaltonetworks.com/logs/v1/event

Press the Add Configuration to save.

Select the Organizational Unit that has reporting events enabled and select the Chrome Palo Alto Networks connector that was created in the previous step and hit Save.

You can also download the setup guide here or watch the step-by-step setup video below: 

Chrome’s integration work with Palo Alto Networks is just one example of how Google is supporting Palo Alto Networks customers. Last year, we announced an expanded partnership that brings together BeyondCorp Enterprise from Google Cloud and Prisma® Access from Palo Alto Networks. This integration offers hybrid users a secure enterprise browsing experience and enables zero trust access to applications from unmanaged devices through Chrome.

Our commitment to help businesses work safer on the web remains constant. See why Chrome is the most trusted enterprise browser here. 

*Available throughBeyondCorp Enterprise

TL;DR — We invite startups developing AI models, infrastructure, or applications in Europe and Israel to apply for the new Google for Startups Accelerator: AI First program.

Google Cloud is committed to partnering with startups to innovate responsibly with AI and reach its full potential, especially teams leveraging tech to solve some of the world’s greatest challenges. AI helps startups unlock tech’s long-term potential, which in turn opens up new opportunities that could significantly improve billions of lives and drive economic growth. 

We’re proud to deepen our support with the launch of our new Google for Startups Accelerator: AI First program in Europe and Israel. This 10-week program is designed to help AI-first seed to Series-A startups to deliver on their vision and shorten the time-to-value by providing access to Google Cloud’s world-class AI capabilities supported by subject-matter experts.

Selected startups will work alongside experts from Google Cloud and Google Deepmind to access the best of Google insights and best practises, including mentors such as: 

James Rosenthal, Director of Startups & AI, Google Cloud

Joelle Barral, Director of AI Research, Google Deepmind 

Yariv Adan, Lead for Cloud Conversational AI 

Adrian Poole, Director of Digital Natives, Google Cloud 

Participating startups will receive:

Exposure to potential partners, venture capital firms and investors interested in AI solutions

Product credits via the Google for Startups Cloud AI Program, with the first year of Google Cloud and Firebase usage covered with credits up to $250,000 (upon eligibility) 

Tailored support from Google mentors and industry experts, including in-person and virtual activities, one-on-one mentoring, and group learning sessions

Dedicated Google Cloud technical expertise on the innovations — cloud computing, AI, machine learning and geospatial analysis — to help early stage participants accelerate their MVPs 

Applications close on July 30 and Accelerator: AI First will kick off in September 2023. We encourage interested and eligible startups in Europe and Israel to apply — and join some incredible founders from the Google for Startups network who are already innovating with AI.

Meet some of the AI startups who have participated in Google for Startups Accelerator programs

Besides the authors mentioned in the byline, the team is composed also of Diana Codreanu and Martin Filipczyk.

Founded in Germany in 1964, METRO is a B2B wholesaler with sales of €29.8 in the financial year 2021/22. METRO.digital is the tech product-led company of METRO, the leading international specialist for wholesale and food trade. With longstanding experience in global wholesale, METRO.digital develops customized IT services and products worldwide for all METRO countries. Located in Germany, Romania, and Vietnam, the METRO.digital teams are working continuously on one goal: digitalizing the wholesale industry. In this blog post, we’re highlighting METRO.digital for the DevOps achievements that earned them the ‘DevOps Dreamer’ award in the2022 DevOps Awards. If you want to learn more about the winners and how they used DORA metrics and practices to grow their businesses, start here.

With the rise of ecom merce, the future of stores in the retail and wholesale industries was unclear. For our company, having a strong presence online was a matter of survival, which is why we launched our “go digital or die campaign” in 2015. As part of this, we built the first platform products and ecommerce solution on Rackspace — an OpenStack-compatible public cloud platform — but even innovators can’t rest on their laurels. Creating ecommerce solutions was the first step, but to meet our customers’ needs, we began our digital transformation journey to expand to customer engagement, master data, and the store business.

Meanwhile, we also realized that while our choice of Rackspace helped us avoid vendor lock-in, the technology and service weren’t keeping up with our transformation. We switched to Google Cloud for more robust offerings and scalability. It was better than what we had before, but even after giving production teams direct access to Google Cloud tools, we found our process still limited our speed and innovation.

Objectives

In our planning, METRO.digital turned to DORA metrics to measure current and potential improvements to time-to-market, stability, and availability. We also treated team safety and happiness as crucial factors as crunch, burnout, and similar problems were just as damaging to productivity as to the team members themselves.

To achieve all of this, we realized that we needed to give teams the opportunity to take full ownership of their products with the autonomy to build and run products by themselves. This strategy of overall decentralization from the platform was so that they could react to market and technology changes themselves rather than waiting for the time it can take a big platform to do it. To reach our digital transformation goals, we identified these objectives:

Build a generative DevOps culture 

Use a loosely coupled architecture

Set up a data lake on Google Cloud’s BigQuery

Solution

METRO.digital pilot product teams worked directly with Google Cloud architects and Professional Services Organization (PSO), receiving help with everything from concepts to code. With this deeper level of cooperation with Google Cloud, we not only found success in our pilot programs, but we also created blueprints from which other teams should build.

In addition to infrastructure architecture, we worked with Google Cloud experts to develop our SRE knowledge and mindset, starting by giving teams more autonomy by switching to Agile and DevOps practices, which fostered an attitude of collaborating to constantly improve their offerings. Our loosely coupled architecture of microservices gave teams the ability to release changes several times a week. This improved the reliability of our products and helped promote an SRE mindset. Today, more than 90% of METRO.digital products are running in Google Cloud.

By coupling our tools that tracked SLOs and the budget for errors with automatic measurement of the DORA’s four key metrics, we worked to give teams the data to promote continuous improvement of their DevOps practices. This promoted the practice of continuous integration and continuous deployment across autonomous teams, greatly speeding up change deployments to keep offerings as up-to-date with market needs as possible.

And since all of the microservices are deployed in Kubernetes clusters with Cassandra and PostgreSQL databases, we are able to consolidate data more securely with Google’s tools. Much of our data is exported directly to BigQuery, and reports are created with Looker Studio. We also protect our data and productivity with advanced security including Cloud Load Balancing and Cloud Armor.

Results

“METRO follows a clear cloud strategy, Google is our partner of choice. We do not only benefit from the technology provided by Google, but also best practice processes used at Google like DevOps, DORA, architecture patterns down to non-tech topics like OKR or in our People & Culture department.” – Timo Salzsieder, CEO METRO.digital, CIO METRO AG

By coupling autonomous teams with loosely coupled architecture, we have seen constant improvements in our culture and offerings. One example of success is M.SHOP — METRO’s food service distribution and online product visibility platform for 50,000 B2B customers across 17 countries. With over 200 microservices written in languages like Java, Kotlin, Go, JavaScript, and ReactJS, 10 teams can work in parallel to guarantee independent deployability and scalability of their modules.

With a digital transformation built around microservices and DevOps practices, we have seen measurable success, including:

Increased the release velocity by 600%, from one release every two weeks to three deployment days/week

Over 4000 repositories in our Github organization 

A total of 153 distinct teams using Google Cloud’s native services with 1,526 registered users in 747 Google Projects

151 teams using the platform they built on top of Google Cloud

This collaboration is also setting up further transformation while improving output. At time of this blog, mean time to recovery (MTTR) improved by 80% and deployment frequency by 43%, all while continuing to migrate assets to Google Cloud. Just like the DevOps practices we run on, this continual transformation helps keep us aligned with changing customer and market demands.

Stay tuned for the rest of the series highlighting the DevOps Award Winners and read the 2022 State of DevOps report to dive deeper into the DORA research.