Cloud Run Worker Pools Go GA with NVIDIA RTX PRO 6000 Blackwell GPU Support
Google Cloud announced two significant Cloud Run updates on April 14–15, 2026: Worker Pools reached General Availability, and NVIDIA RTX PRO 6000 Blackwell GPUs became available for Cloud Run services, jobs, and worker pools. Together these make Cloud Run a substantially more capable platform for running non-request-driven AI workloads at production scale.
Worker Pools are Cloud Run's model for non-HTTP workloads — rather than scaling in response to inbound requests, worker pools maintain persistent, long-lived instances that pull work from queues, run background jobs, or support streaming inference pipelines. The GA announcement means Google is committing to a stable API and SLA for this feature. Estee Lauder Companies is among the early production users, running batch AI pipelines on worker pools rather than managing their own container fleet. For teams currently using Compute Engine or Kubernetes for background processing, worker pools offer a fully managed alternative with Cloud Run's built-in autoscaling and minimal operational surface.
The NVIDIA RTX PRO 6000 Blackwell GPU availability significantly upgrades the hardware available to Cloud Run. Each instance can be configured with up to 44 vCPU and 176 GB of RAM, and must specify at least 20 CPU and 80 GiB of memory to use the GPU. Instances start in approximately 5 seconds with drivers pre-installed — comparable to the L4 GPU startup time. The RTX PRO 6000 is currently available on-demand in us-central1 and europe-west4, with limited availability in asia-south2 and asia-southeast1. For teams running GPU inference workloads — LLM serving, embedding generation, image processing — Cloud Run now provides a serverless path to Blackwell hardware without managing GKE clusters or VM fleets.
Read more — Google Cloud Blog
Google Cloud OpenAPI v3 Now Generally Available for API Gateway and Cloud Endpoints
Google Cloud announced General Availability of OpenAPI v3 (OASv3) support for both API Gateway and Cloud Endpoints, eliminating a long-standing requirement to downgrade modern API specifications to OASv2 before deploying on Google's API management platform. Teams can now define API contracts and enforce policies using native OASv3 files directly, including Google-specific extensions.
The shift matters for teams managing public or partner APIs on Google Cloud. OpenAPI v3 introduced significant improvements over v2: a cleaner schema composition model (using oneOf, anyOf, not), better support for complex request bodies with multiple content types, improved link and callback specifications, and a revised security scheme model. Requiring a v2 downgrade forced teams to work around these improvements or maintain parallel specification files — a source of drift and maintenance burden.
With OASv3 GA, Cloud Endpoints users can enforce authentication, traffic management, rate limiting, and logging policies using specifications written in modern OAS tooling without any format conversion step. API Gateway similarly now accepts OASv3 definitions directly. Teams currently running v2 specifications should evaluate migrating — the tooling ecosystem (Swagger Editor, Redoc, Stoplight, Postman) has supported v3 natively for years, and the converters are generally reliable for straightforward API shapes.
Read more — Google Cloud Blog
AWS SDK for .NET v3 Enters Maintenance Mode Ahead of June 2026 End-of-Support
AWS officially moved the AWS SDK for .NET version 3 to maintenance mode on March 1, 2026. Under AWS's SDK lifecycle policy, maintenance mode means no new features will be developed — only critical security patches will be applied. The SDK reaches full end-of-support on June 1, 2026, after which AWS will stop publishing security patches for v3.
The successor, AWS SDK for .NET v4, has been in release for several months and introduces breaking changes: it drops support for .NET Framework targets (requiring .NET 6 or later), removes legacy synchronous API wrappers in favor of async-first patterns, and streamlines the namespace structure. For most greenfield .NET projects, v4 has been the recommended choice since its release. The v3 end-of-support deadline creates urgency for teams still running .NET Framework applications on AWS services that rely on the SDK.
AWS Tools for PowerShell v4.x entered maintenance mode on the same schedule, with end-of-support also set for June 1, 2026. Teams using PowerShell scripts for AWS automation should audit their use of the v4 module and test against the v5 toolset before the support window closes. The impact varies widely by team — organizations that have already migrated to .NET 6/8/9 will find the SDK upgrade straightforward, while those with .NET Framework dependencies face a broader platform migration decision.
Read more — AWS Developer Tools Blog
Links & Sources
You May Also Enjoy
