November 2026 Summaries

Google Distributed Cloud (GDC) air-gapped provides a disconnected, Google-supplied hardware and software platform that can run proprietary Gemini models alongside open models such as Gemma and Mistral, while offering compliance accreditations relevant to defense and regulated organizations. Because Google does not release Gemini weights, organizations seeking Gemini inside an air-gapped environment must use GDC, whereas teams using open-weight models can build private inference on existing Kubernetes infrastructure with NVIDIA GPUs. The proposed self-managed architecture consists of GPU enablement, an offline registry and model storage system, an inference runtime such as vLLM or NVIDIA NIM, an OpenAI-compatible access gateway, and a developer self-service platform. The main operational challenge is maintaining an offline software supply chain, including mirroring and verifying images, drivers, charts, security updates, and large model files while managing version compatibility, certificates, storage, and upgrades. The comparison concludes that GDC is better suited to organizations requiring Gemini, vendor-provided accreditation, and integrated hardware, while Kubernetes-based deployments offer greater model choice and control for teams that already have platform expertise and can accept the operational burden; GPU utilization and engineering staffing are identified as the largest cost factors.

MCP servers should be deployed as separate isolated workloads rather than combined on shared virtual machines, containers, processes, or credential files, because shared hosting expands credential blast radius, weakens auditability, and allows one workload to consume resources needed by others. Each server should have a dedicated identity with least-privilege permissions, default-deny network egress, CPU and memory limits, short-lived credentials where possible, and structured tool-call logs sent to an append-only external sink that can be correlated with cloud audit logs. Hosting should be selected according to the server’s trust level: stateless public tools may suit edge runtimes such as Cloudflare Workers, while servers accessing private data or production systems should run in an organization’s own cloud account or Kubernetes environment, with managed services such as Fargate, Cloud Run, Azure Container Apps, or Lambda fitting different operational needs. Servers with write, destructive, or model-generated-code capabilities require stronger safeguards including approval gates, sandboxing, resource quotas, and tightly scoped credentials, since prompt-based policies alone are vulnerable to prompt injection and tool poisoning. The discussion also distinguishes hosting platforms from complementary gateway, policy, and secret-management layers, and presents Qovery as an internal developer platform intended to automate isolated deployments, RBAC, previews, and operational workflows within a customer-controlled cloud environment.

AWS’s October 2026 disconnection exercise for its European Sovereign Cloud showed that AWS’s regional control plane could continue operating without its usual links to the broader AWS network, but the account argues that this does not demonstrate whether individual customer workloads can function independently. It distinguishes data, operational, and jurisdictional sovereignty, emphasizing that applications often retain dependencies on external identity providers, code hosts, package and container registries, certificate authorities, observability platforms, paging tools, and AI APIs. The proposed evidence is a customer-run severance drill in an isolated, production-like environment: inventory actual outbound traffic, block non-sovereign endpoints, and test break-glass identity access, deployment, DNS and TLS renewal, data restoration, observability and paging, support access, and rebuilding on another provider or platform. Each test should have measurable criteria, such as privileged access within 15 minutes, an alert reaching a human within five minutes, checksum-verified restoration, and a documented recovery time objective for exit. The piece links these practices to DORA and NIS2 resilience expectations, compares sovereign-cloud and self-managed Kubernetes options as trade-offs between managed services, jurisdiction, portability, and operational burden, and argues that controlling one’s own cloud account, network, keys, and infrastructure definitions makes such testing feasible.

Unified Amazon EKS and Amazon Bedrock cost visibility currently requires combining AWS CUR 2.0-based allocation reporting with a provisioning layer that enforces identical tags across Kubernetes workloads and Bedrock inference profiles, rather than relying on a single dashboard. EKS costs are difficult to assign because shared infrastructure such as EC2 nodes, storage, NAT gateways, and load balancers supports many pods, while Bedrock charges per input and output token without inherently identifying the calling team or service. AWS split cost allocation data can add pod-level EKS costs to CUR, and Bedrock application inference profiles can attach cost-allocation tags to model calls, but teams must activate tags in billing settings and apply them consistently going forward. Allocation tools including Kubecost, OpenCost, Finout, and nOps can report CUR data, whereas Terraform-oriented platforms and internal developer platforms provide policy controls, tagging enforcement, and deployment guardrails but cannot predict runtime token consumption. The recommended approach uses shared team, service, environment, and cost-center tags; CUR reporting and Cost Categories; Bedrock budgets and anomaly alerts; and operational measures such as auto-stopping nonproduction environments, right-sizing Kubernetes requests, selecting efficient models, limiting prompts, caching, and using batch inference where appropriate. Qovery is presented as a provisioning and guardrails platform that can deploy to existing EKS clusters, enforce environment consistency, and automate nonproduction shutdowns, while relying on separate FinOps tools for cost reporting.

Multi-cloud resilience and compliance efforts often fail when teams maintain separate, manually synchronized copies of environments across providers and regions, creating configuration drift, inconsistent security controls, and difficult failover testing. The article argues that effective automation requires a shared declarative source of truth, policy enforcement before changes are applied, and ongoing drift detection or reconciliation. It distinguishes infrastructure-as-code tools such as OpenTofu, Terraform, and Pulumi, which define resources but require external orchestration; Kubernetes-native Crossplane, which continuously reconciles declared cloud resources; platforms including Spacelift, env0, and HCP Terraform, which add policy gates, approvals, audit trails, and scheduled drift checks; and internal developer platforms such as Qovery, which manage Kubernetes clusters and application environments in customer-owned cloud accounts. It recommends combining layers rather than expecting one tool to cover all needs, commonly using IaC for foundational accounts and networking, a governance platform for policy and drift management, and an application platform for clusters and deployments. Governance depends on enforceable policy-as-code, scoped access controls, immutable audit evidence, and tested recovery processes, while realistic multi-cloud designs often rely on a primary environment and a validated secondary rather than costly active-active deployments across several providers.

Migrating a Supabase application to Kubernetes is presented as a phased process involving separate cutovers for PostgreSQL data, authentication, and Edge Functions, with independent rollback plans rather than a single migration event. PostgreSQL can be moved through dump-and-restore with a planned write freeze or logical replication for near-zero downtime, while managed database services are recommended over running PostgreSQL in Kubernetes; teams must also account for unsupported extensions, storage files, schema customizations, sequences, and replication limitations. Existing Supabase Auth users can generally retain their passwords because bcrypt hashes from the auth schema can be moved to self-hosted GoTrue or imported into several identity providers, although JWT signing keys, RLS claims, OAuth redirects, email configuration, and refresh tokens require careful handling. Edge Functions must be adapted into API routes, Deno containers, or serverless functions, and frontend calls using Supabase functions must change to standard HTTP requests. Keeping PostgREST preserves existing supabase-js database calls, whereas removing it requires an API rewrite. The source contrasts full self-hosting, a managed-services rebuild, and a gradual hybrid approach, noting that self-hosting adds operational responsibility and is usually less economical for small projects but may suit organizations needing cloud-account ownership, private networking, compliance control, or cloud-discount benefits; it also describes Qovery as a platform for deploying and managing the migrated Kubernetes components in a customer-owned cloud account.

For small Kubernetes platform teams in 2026, the choice between Cilium and Calico should center on operational responsibility, debugging expertise, policy portability, and managed-service support rather than performance benchmarks. Cilium is positioned as the preferred option for multi-cloud environments because its eBPF-based dataplane underpins or is available through managed offerings such as GKE Dataplane V2, Azure CNI powered by Cilium, and Scaleway Kapsule, while providing integrated observability through Hubble and advanced L7, FQDN, and identity-based policies. Calico is presented as better suited to on-premises environments, older kernels, unusual distributions, Windows needs, and teams whose on-call staff are more comfortable with standard Linux tools such as tcpdump and iptables-save; its commercial tiers also offer compliance reporting and enhanced flow visualization. For very small teams operating in only one cloud, the recommended approach is generally to use the provider-managed CNI, such as Amazon VPC CNI, Azure CNI, or GKE Dataplane V2, and retain portability through standard Kubernetes NetworkPolicy rather than CNI-specific policy CRDs. Flannel is considered unsuitable for production environments requiring policy enforcement because it does not natively enforce NetworkPolicy, while Antrea remains a specialized option for Windows and VMware-oriented estates. The discussion also argues that teams without Kubernetes operations expertise may benefit more from an internal developer platform such as Qovery, Northflank BYOC, or Porter, which manages cluster lifecycle and networking decisions while allowing developers to focus on deployments.

BSI’s C5:2026 Cloud Computing Compliance Criteria Catalogue expands Germany’s cloud-assurance framework to 168 criteria across 17 domains, adding focus on post-quantum cryptography, confidential computing, container management, supply-chain security, and digital sovereignty. It applies to Type 2 audit periods beginning on or after 1 June 2027, meaning providers seeking a 2027 attestation need controls operating and generating evidence from the start of their observation period, rather than merely implementing them before an audit. Core cryptography requirements mandate crypto-agility and alignment with BSI or NIST guidance, while optional additional requirements call for a documented PQC strategy including a cryptographic inventory, hybrid encryption, transition triggers, and annual reviews. The article recommends prioritizing hybrid X25519MLKEM768 TLS key exchange, key-management inventories, rotation records, configuration-as-code, and a phased plan for post-quantum signatures and PKI. Confidential-computing criteria address protection of data in use through trusted execution environments and customer-verifiable remote attestation, with available options including Google Confidential GKE Nodes, Azure confidential AKS node pools, and AWS SEV-SNP instances or Nitro Enclaves. It emphasizes that auditors will examine operational evidence such as policies, inventories, attestation reports, access logs, change records, and configuration histories, while noting that cloud-account ownership and platform architecture can affect third-party dependencies, key custody, regional control, and the overall C5 audit scope.