Google Cloud, Azure and Alternatives to Kubernetes

An Autopilot cluster removes node management, enables Workload Identity Federation for GKE and the Filestore CSI driver by default, and charges per pod request; a Standard cluster keeps node pools under your control. Autopilot is the closest equivalent of EKS Auto Mode. The cluster commands are on GKE Clusters; the only WordPress-specific decision is that PHP-FPM pods need CPU and memory requests equal to what the HPA measures against, which Autopilot also requires.

Source: Google Cloud Docs: Create an Autopilot cluster

The image is pushed to europe-west1-docker.pkg.dev/<project-id>/lumenpress/wordpress:<git-sha>. The GitHub Actions workflow of the release page changes in two lines: the OIDC step uses google-github-actions/auth with Workload Identity Federation for the pool and provider (see Identity and Access) instead of aws-actions/configure-aws-credentials, and the cluster login is gcloud container clusters get-credentials. The helm upgrade --rollback-on-failure step is identical.

Cloud SQL runs MySQL 8.4 (the default version at the check date; 9.7 is available but WordPress and its plugins are tested against 8.x) with a primary and a standby in two zones when --availability-type=REGIONAL, a private address through private services access, point-in-time recovery from the binary log, and automatic storage growth.

Source: Google Cloud Docs: gcloud sql instances create

The users are created as plain MySQL users; give wp_app only the privileges WordPress needs with SQL GRANT (the list is on Managed Database: RDS and Aurora) and revoke wp_migrate after the import. Two ways to connect:

Source: Google Cloud Docs: Connect to Cloud SQL from Google Kubernetes Engine

The Kubernetes ServiceAccount is bound to the role roles/cloudsql.client with a principal identifier that names the namespace and the ServiceAccount; the exact binding is on Cloud SQL. The same fragment in the web Deployment is a sidecar of PHP-FPM; in the Helm chart it is another conditional block next to extraContainers. Check the proxy’s memory in staging: one proxy per pod multiplies the connections Cloud SQL sees, so pm.max_children times replicas must stay below the instance’s max_connections. Without an HPA-aware ceiling, a scale-up can exhaust it (see the connection arithmetic on the database page).

Memorystore for Valkey is reached through a Private Service Connect endpoint that a service connection policy creates once per network and region (the commands are on Memorystore and Partner Databases). Two points are specific to WordPress. The Redis Object Cache plugin authenticates with a static password, while Memorystore’s IAM authentication uses short-lived access tokens; with IAM the plugin would need a token refresher, so for WordPress the instance runs inside the private network with transit encryption (server-authentication) and either authentication disabled or a sidecar that rotates the token; check the authorization modes your gcloud memorystore instances create --help offers. The plugin’s TLS settings (WP_REDIS_SSL_CONTEXT) take the instance’s CA from gcloud memorystore instances get-certificate-authority. Because the object cache is disposable (Object Cache, Sessions and Cron in a Cluster), losing it only costs a slow first minutes.

Media has the same two options as on AWS. An offload plugin writes to a Cloud Storage bucket (gcloud storage buckets create gs://lumenpress-prod-media --location=europe-west1 --uniform-bucket-level-access --public-access-prevention), with Cloud CDN on a backend bucket in front of it (Cloud CDN and Media CDN); the plugins for Cloud Storage and their maintenance state differ from those for S3, so verify the plugin’s compatibility with WordPress 7.1 before choosing. Or the uploads directory is a shared ReadWriteMany volume from Filestore through the CSI driver:

Source: Google Cloud Docs: Access Filestore instances with the Filestore CSI driver

The Filestore minimum for a zonal volume is large (1 TiB at the check date, see Block and File Storage on Google Cloud), which makes the bucket the better default for a small site. The rule of the EFS case applies unchanged: uploads on the shared volume, never PHP code.

Secrets come from Secret Manager. The External Secrets Operator reads them with a store that authenticates through Workload Identity; the chart’s ExternalSecret is unchanged except for the store name and the remote keys. The GKE Secret Manager add-on (see Secret Manager and Cloud KMS) mounts secrets as files instead, which suits _FILE variables of the official image.

Source: External Secrets Operator: Google Cloud Secret Manager

The HTTP entry is a Gateway of class gke-l7-global-external-managed, which provisions a global external Application Load Balancer; a certificate map in Certificate Manager carries the TLS certificate for www.lumenpress.example, and Cloud Armor policies attach to the backend (Load Balancing and Cloud Armor, GKE Microservices). The load balancer probes the backend Service at / by default; WordPress answers / with a redirect when the site address differs from the host, so set a health check policy that uses the /healthz location of the Nginx container.

Source: Google Cloud Docs: Deploy Gateways

Gateway API resources replace Ingress for new work on both clouds, and ingress-nginx was retired by Kubernetes SIG Network (best-effort maintenance ended in March 2026), so none of the manifests here use it. Pod disruption budgets and topology spread are in the chart and the same as on EKS; on Autopilot, spread over zones is the default placement for replicas of one Deployment but still declare it.

Azure Managed Redis is the current first-party service (Azure Cache for Redis is retiring in two waves, the first on 2027-03-31 for the Enterprise tiers and the second on 2028-09-30 for Basic, Standard and Premium), it speaks the Redis protocol and works with the Redis Object Cache plugin, and it is not Valkey. Its endpoint listens on port 10000, so WP_REDIS_PORT is not 6379, the clustering policy is fixed at creation (OSSCluster needs a cluster-aware client; the plugin’s PhpRedis client supports it, but for a small cache EnterpriseCluster lets a client that does not follow cluster redirects connect to a single endpoint), and a new cache defaults to Microsoft Entra authentication with access keys off. The tokens expire, so as with Memorystore either enable access-key authentication on a cache that is reachable only from the cluster’s private network, or run a token refresher; the commands and the choices are on Redis and Partner Databases on Azure.

Uploads go to Blob Storage through an offload plugin with Front Door in front (Blob Storage, Front Door and CDN; plugin support for Azure differs from S3, so verify maintenance and WordPress 7.1 compatibility), or on a shared volume. Azure Files over NFS needs a premium file storage account and a StorageClass for the Azure Files CSI driver:

Source: Microsoft Learn: Use Azure Files CSI driver in AKS

NFS shares are reachable from the virtual network only, enforce the file system’s POSIX permissions instead of SMB authentication, and need the fsGroup or an init step that sets ownership to UID 33; the same rules as for EFS apply to PHP code and to cache directories of plugins.

On AKS the ServiceAccount and the pods carry the identity of a user-assigned managed identity through a federated credential: the ServiceAccount has the annotation azure.workload.identity/client-id, and the pod template the label azure.workload.identity/use: "true". The identity needs the role Key Vault Secrets User on the vault (Key Vault and Secrets, Identity and Access).

Source: External Secrets Operator: Azure Key Vault

For the HTTP entry, the application routing add-on’s Gateway API implementation (gatewayClassName: approuting-istio) is the recommended path on current AKS and replaces the older managed NGINX mode whose upstream is retired; Application Gateway for Containers is the heavier alternative with Web Application Firewall integration, and Azure Front Door is the global edge for media and for TLS offload (AKS Microservices, Gateways and Load Balancing). The Gateway and HTTPRoute of the GKE section are the same objects, with gatewayClassName: approuting-istio and an HTTPS listener whose certificate comes from a Key Vault secret synchronised by the add-on.

A task definition replaces the Deployment: two containers (Nginx and PHP-FPM) in one task share localhost, an ALB target group replaces the Service, and an ECS service with target-tracking scaling replaces the HPA (ECS and Fargate, ECS Deployments, Scaling and Networking). Secrets are injected by ECS from Secrets Manager, uploads live in S3 or on EFS, and there is no Helm: the release is a new task definition revision and a service update, with the migration as a one-off run-task before it and cron as an EventBridge Scheduler rule that runs wp cron event run --due-now.

Source: Amazon ECS Developer Guide: Task definition parameters

The excerpt shows two of the eight keys and salts; the others follow the same pattern. The Nginx container needs the static files of WordPress (wp-includes, the theme assets) at the paths it serves: build its image from the same Dockerfile stage that holds the code (the tag with the -nginx suffix above is an illustration; use the layout of the production image of the Helm page). Fargate gives each task 20 GiB of ephemeral storage and no persistent disk, which is the right default for stateless pods; mount EFS through the task definition’s volumes only for uploads.

The oldest pattern: an image (an AMI baked with Packer, or a launch template with user data that pulls the container image), an Auto Scaling group across three zones behind an ALB, RDS, S3 or EFS, and a rolling instance refresh as the release (EC2 and Auto Scaling). It has the fewest moving parts and the highest operational burden: operating system patching, one more image to build, and cron on exactly one instance (a systemd timer guarded by a lock in the database, or an EventBridge rule that calls SSM Run Command on one instance).

Source: Terraform Registry: aws_autoscaling_group (AWS provider)

Cloud Run runs a container without a cluster: requests are routed to instances that scale from a configured minimum to a maximum, an instance serves a configurable number of concurrent requests, and billing follows the chosen mode. WordPress fits if its state is external: Cloud SQL through the built-in connection (a Unix socket under /cloudsql/), media in Cloud Storage (a mounted bucket volume exists, but object-store semantics make an offload plugin the better path), secrets from Secret Manager as environment variables, and Memorystore through Direct VPC egress. The official apache variant is the simplest image, because one container serves HTTP; with Nginx and PHP-FPM use a multi-container service (Cloud Run).

Source: Google Cloud Docs: gcloud run deploy

A Cloud Run Job and a Cloud Scheduler trigger replace the CronJob; the migration is another job executed before the deployment. The limits to weigh are a request timeout (not a problem for page views, a problem for long admin imports, which run as Jobs), cold starts of a PHP application (minimum instances address them), no local persistent disk, and WP_HOME/WP_SITEURL handling when the service sits behind a load balancer with a custom domain.

Container Apps is the Azure analogue: an environment with a virtual network, revisions per deployment, HTTP scaling rules, Key Vault references for secrets, and jobs for scheduled and manual work (Container Apps, Container Apps: Scaling, Jobs and Dapr).

Source: Microsoft Learn: az containerapp

Uploads need an offload plugin or an Azure Files volume mounted into the app (SMB or, in a workload-profile environment, NFS; check the current restrictions in the service documentation). The scheduled job runs one execution at a time by default with a retry limit; set the replica timeout so a hung run does not overlap the next.

A managed host removes the whole infrastructure and sells WordPress as a service: WordPress.com (Automattic’s platform, with plugin installation only on its higher plans), WP Engine, Kinsta, Pantheon, Pressable and Cloudways (on top of cloud providers) are the commonly compared names, and the list changes; check each product’s current documentation. Questions that decide the choice:

When the answers are acceptable and nothing needs custom infrastructure (private networking to internal systems, custom Nginx rules, compliance regimes), a managed host is the cheapest operation. The WordPress project’s own requirements and hosting guidance is on Requirements and Hosting.