Three announcements this week cover different layers of the same problem: how to run AI and analytics workloads where the data lives, with identity and governance that hold up in production. Broadcom reworked VMware into a private AI control plane, Kubernetes 1.37 shipped with meaningful identity and scheduling changes, and Amazon Redshift added IAM Identity Center support for VPC-restricted traffic.
Broadcom turns VMware into a private AI control plane
At VMware Explore 2026 in Las Vegas, Broadcom introduced VMware Private AI Cloud. The positioning is that VMware Cloud Foundation (VCF) is no longer just the successor platform for the virtualization portfolio. It is now an assembled stack for inference, agentic applications, containers, and traditional virtualized workloads.
The architecture combines VCF infrastructure automation with Tanzu, vDefend, Avi Load Balancer, and new AI governance capabilities. Broadcom says the design targets three enterprise requirements: controlling AI infrastructure and token economics, maintaining data sovereignty and security, and providing a governed environment for autonomous agents.
At the infrastructure layer, the new VMware AI Factory automates the path from bare-metal servers through VCF deployment to model inference. Broadcom claims this cuts the time between bare-metal deployment and serving the first model from weeks to hours. That is a vendor claim, and I would want to see a real customer benchmark before trusting it. But the automation direction is sound.
The platform supports heterogeneous hardware: AMD Instinct GPUs with ROCm, NVIDIA GPUs, and systems from Dell, Cisco, Lenovo, Supermicro, and others. A partnership with MetalSoft extends VCF automation into heterogeneous bare-metal provisioning. VCF can pool GPU resources across organizations, with multi-tenant model sharing, an AI Gateway, secure AI sandboxes, and observability for token throughput, latency, compute, and memory utilization. That last part matters. GPU idle time is expensive, and token-level observability is the only way to know whether the pool is earning its keep.
At the model layer, more than 150 open-source models run through VCF's vLLM-based runtime. Models from NVIDIA, Google DeepMind, NEC, Alibaba, and Z.ai are being validated for on-premises deployment. Broadcom's Private Cloud Outlook 2026 says 56% of surveyed enterprises are running or planning production AI inference in private clouds. That survey is vendor-funded, so treat the number as directional rather than gospel.
For agentic workloads, Tanzu is extended with governed data foundations, and the new AgentMinder control plane assigns agents identities, missions, authorized tools, and runtime policies. vDefend and Avi add lateral security, virtual patching, API protection, and controls intended to restrict agents from unauthorized tools and data.
The key architectural question is whether enterprises treat AI inference as another workload class inside their existing private-cloud operating environment, or build dedicated AI silos. Broadcom's answer is clearly the former. VMs, Kubernetes, GPUs, models, data pipelines, and agents share one governed infrastructure layer. I think that is the right bet for most organizations. Siloed AI infrastructure is expensive to operate and hard to secure, because security teams end up managing separate policies and monitoring stacks.
The link to Broadcom's broader AI business is worth noting. Broadcom participates in hyperscale AI infrastructure through custom accelerators, Ethernet switching, and networking silicon. VMware gives the company a software platform for enterprise consumption of heterogeneous CPUs, GPUs, storage, and networking. VMware Private AI Cloud extends Broadcom's AI exposure beyond hyperscale clusters into enterprise inference, sovereign AI, and agentic applications inside regulated environments.
Kubernetes 1.37 lands with identity and scheduling changes
Kubernetes 1.37, code-named "Garhwal," shipped on Aug. 26 with 67 enhancements: 16 features graduating to stable, 23 to beta, 27 to alpha, and one deprecation.
The most consequential changes are two security features that reached stable: Pod Certificates and Cluster Trust Bundles. Until now, the primary workload identity mechanism in Kubernetes was service account JWTs. Those are bearer credentials. A party that obtains the token can potentially use the identity it represents. Pod Certificates introduce proof-of-possession. The kubelet generates a private key for a workload and obtains an X.509 certificate from a certificate signer. The private key stays with the workload, and the certificate lets other systems verify its identity.
Cluster TrustBundles provide a mechanism for distributing X.509 trust anchors to workloads. One caveat: Kubernetes does not yet include a Pod Certificate signer in the core platform. Organizations that want to use the capability need a third-party signer or their own implementation. That is a real adoption barrier, but the foundation is there.
Gang scheduling moved to beta, built around the Workload API and PodGroup concept. It now includes workload-aware preemption and PodGroup queueing. The scheduler can consider a group of related Pods when deciding whether to displace lower-priority workloads, rather than treating each Pod independently. The release team explicitly tied this work to the increasing use of Kubernetes for AI and ML workloads at scale.
Dynamic Resource Allocation receives additions too. ResourceClaim support for workloads moved to beta, allowing groups of Pods to associate ResourceClaims and ResourceClaimTemplates with a workload. DRA is designed to provide a more flexible way for Pods to request specialized hardware.
HorizontalPodAutoscaler scale-to-zero is now beta and enabled by default. Workloads that use object or external metrics can reduce their replica count to zero when there is no work, then restore Pods when demand returns. CPU and memory metrics cannot trigger this because those measurements depend on running Pods. You need external signals like queue depth. This matters for GPU workloads, because idle Pods holding GPU resources are expensive and scale-to-zero lets the scheduler release them.
The metrics.k8s.io API finally graduated to stable after years in beta. It provides CPU and memory usage for nodes and Pods, underpinning kubectl top and resource-based autoscaling.
Control plane changes target large clusters. Resilient watch cache initialization is now fully stable, preventing API server startup or recovery from generating request spikes against etcd. The API server can bound requests and reject others with HTTP 429 responses. Controllers and operators should handle those with Retry-After headers and exponential backoff. A beta etcd RangeStream capability returns list data in chunks while maintaining a consistent snapshot, reducing the memory pressure from building entire responses in memory.
Older infrastructure continues to be retired. kube-dns is being deprecated, replaced as the default cluster DNS add-on by CoreDNS since Kubernetes 1.13. The kubelet still refuses to initialize on cgroup v1 nodes unless administrators override, but that override is temporary. Static Pods can no longer reference Secrets or ConfigMaps, closing a path that was never intended since static Pods are not created through the API server.
Kubernetes 1.37 remains in active support until August 2027, with end of life on Oct. 28, 2027.
Redshift gets IAM Identity Center with enhanced VPC routing
Amazon Redshift now supports AWS IAM Identity Center authentication for provisioned clusters and serverless workgroups configured with enhanced VPC routing (EVR). Users get single sign-on with corporate credentials, and traffic traverses the Amazon VPC and stays on the AWS network.
With EVR, all traffic between the Redshift warehouse and other AWS services goes through your VPC, governed by security groups, network ACLs, and endpoint policies, and observable in VPC Flow Logs. The new launch validates and exchanges IAM Identity Center tokens over AWS PrivateLink interface VPC endpoints from inside the VPC. Authentication follows the same governed network path as the rest of the Redshift traffic. The feature supports IAM Identity Center multi-Region replication for customers running Redshift in a different Region than their primary Identity Center instance.
This is a smaller announcement than the other two, but it solves a concrete problem for regulated environments. If you have data residency or network-isolation requirements that forbid public internet egress for analytics, you previously had to choose between single sign-on and VPC-only traffic. Now you get both.
What the three stories share
Broadcom's VMware push, Kubernetes 1.37, and Redshift's IAM support all circle the same theme: enterprises want AI and analytics near their data, with identity and governance that operators control.
The VMware announcement is the largest strategic bet. Whether VCF can genuinely absorb model serving, agent governance, and heterogeneous GPU management alongside virtualization remains to be proven. The 56% adoption figure is vendor-funded, so read it with that context.
Kubernetes 1.37 gives platform engineers concrete tools: Pod Certificates for workload identity, gang scheduling for AI batch work, scale-to-zero for GPU cost control. The missing Pod Certificate signer is the main gap.
Redshift's IAM Identity Center support is the quietest of the three, but it removes a real friction point for compliance-bound teams.
The practical takeaway across all of them: identity is becoming the common thread. Workloads, agents, and users all need credentials that can be verified without bearer-token fragility. Kubernetes addresses this with X.509 proof-of-possession. VMware addresses it with AgentMinder. AWS addresses it with PrivateLink-routed IAM tokens. If you are planning infrastructure for the next 18 months, design the identity and governance model first. The compute layers will follow.