Google Cloud Expands Official Rust SDK Support Across 150-Plus Services

When AWS launched general availability of its Rust SDK in November 2023, it shipped first-party coverage for more than 300 AWS services in a single announcement and set a benchmark the Google Cloud Rust community had been watching closely. Last week, Google moved to close that distance: its official "Rust for Cloud SDK overview," refreshed on April 2, covered more than 150 services with first-party client libraries living under the googleapis GitHub organization, installable from crates.io, and pinned to a minimum supported Rust version of 1.86.

The breadth of the Google Cloud SDK spans services that matter most to production workloads. Cloud Storage, Vertex AI, Secret Manager, Cloud Key Management Service, and Identity and Access Management all have dedicated crates. Every crate follows the same authentication pattern: Application Default Credentials, OAuth2, API keys, and service accounts are all supported out of the box, with Workload Identity Federation noted as forthcoming.

The AWS comparison is instructive for teams evaluating both clouds. The aws-sdk-rust repository, maintained by AWS Labs, offers one crate per service and ships with aws-config for credential resolution. It reached GA in November 2023 and has since become the canonical first-party library for S3, DynamoDB, and the broader AWS catalog. The Lambda runtime, aws-lambda-rust-runtime, sits in a separate AWS Labs repository, a detail worth knowing when assembling a serverless Rust stack on AWS. Google Cloud's structure is parallel: a central repository under googleapis, per-service crates on crates.io, and an async model built around Tokio.

That async runtime choice matters in practice. Both clouds' Rust SDKs assume Tokio as the executor, which means Cargo.toml for any Google Cloud Rust project will look familiar to anyone who has built on AWS: tokio with the "full" feature flag, the relevant service crate, and a #[tokio::main] entry point.

Getting a Rust service running on Cloud Run is where the official documentation earns its keep. The minimum viable path runs through four steps. Add the relevant crate to Cargo.toml: the Secret Manager quickstart uses google-cloud-secretmanager-v1 and calls client.list_secrets().set_parent(...).by_item() with a standard Tokio async main. Authenticate locally with Application Default Credentials by running gcloud auth application-default login, which the SDK picks up automatically with no additional configuration code. Containerize with Docker using a multi-stage build, a practice the documentation explicitly recommends and which keeps final image sizes competitive with Go equivalents. Deploy with gcloud run deploy, which handles scaling to zero automatically, meaning serverless Rust workloads incur no idle cost.

The cold-start question is the one Google Cloud is implicitly answering by pointing teams toward Cloud Run. Rust binaries are small, startup is fast, and the Tokio runtime adds minimal overhead compared to a JVM or Node.js cold start. Google's documentation frames zero-cost abstractions and fine-grained memory management as direct contributors to lower cloud bills, not just language-design niceties, which gives platform teams a cost argument alongside the correctness argument.

GKE and Compute Engine are the other two deployment targets the documentation emphasizes. For teams running persistent workloads, long-running model inference against Vertex AI, or high-throughput data pipelines into Cloud Storage, those paths make more sense than Cloud Run's serverless model. A containerized Rust service fronting a Vertex AI endpoint gets low-latency request handling with predictable memory bounds, something harder to achieve in Python.

The significance of April 2 is partly about trajectory. Google Cloud's documentation previously acknowledged Rust but treated it as one of many supported languages. The "Rust for Cloud SDK overview" page that exists now is vendor-owned, version-tracked, linked to canonical GitHub repositories, and structured around idiomatic Rust patterns rather than REST wrapper examples. The googleapis/google-cloud-rust repository states a Rust 1.86 MSRV requirement and commits to bumping the major version on breaking changes. That is the shape of a production-readiness commitment, and it mirrors the progression AWS made between its initial Rust preview and the November 2023 GA announcement.

For platform teams evaluating whether to standardize on Rust for internal SDKs, vendor documentation is itself a risk argument. A library maintained by Google with a published MSRV policy and a documented breaking-change strategy is a different compliance conversation than a community crate with an informal maintainer, however active. The 150-service count trails AWS's 300, and AWS's longer runway at GA gives it more battle-tested production history. But the services Google Cloud prioritized first, Vertex AI, Cloud Storage, Secret Manager, KMS, and IAM, are precisely the ones a new cloud-native Rust project will reach for first. The table stakes are covered.