Most VI admins hear “VCF Automation” and quietly file it under “Aria Automation with a new logo.” That assumption will cost you a design decision or two. VCF Automation in VCF 9 keeps the Assembler, Service Broker and Orchestrator engines you know, but it rebuilds the consumption layer on top of vSphere Supervisor and ships a multi-tenant provider model that did not exist in the old vRA world. If you treat it like a rename, you will configure the wrong organization type and discover the problem after the tenant is live.
This part of the series explains what VCF Automation actually is in VCF 9, how the provider and organization model fits together, what you get out of the box, and the one decision (All Apps versus VM Apps) that an architect should settle before any tenant onboarding starts.
What VCF Automation is, and what changed from Aria Automation
VCF Automation is the self-service consumption layer of VCF 9. It is the product formerly sold as VMware Aria Automation (and vRealize Automation before that), now folded into the VCF platform and licensed with it rather than as a standalone SKU. You license it by assigning the VCF license to a vCenter instance from VCF Operations: when VCF Automation connects to that vCenter, it becomes licensed automatically. There is no separate Aria entitlement to track anymore.
The engines underneath are familiar. Assembler and Service Broker still exist on the backend, so your role-based access control and existing blueprint logic carry over. The big surface change is that the separate Assembler, Service Broker and Orchestrator tiles are gone. They are merged into one interface organized by intent: a Consume menu for Catalog and Deployments, a Design menu for Blueprints, Property Groups, Custom Resources and Resource Actions, and a Content & Policies menu for content sources and governance. Orchestrator is now embedded as VCF Operations orchestrator (the artist formerly known as vRealize Orchestrator) on its own tab, with nested workflow runs finally shown in a tree view for sane troubleshooting.
The deeper change is architectural. The old vRA consumed vCenter through cloud accounts and endpoints. VCF Automation 9 consumes vSphere Supervisor directly through the Kubernetes IaaS API. That is why a VM and a Kubernetes cluster are both just declarative objects you can define in YAML and apply with a kubectl-compatible CLI. The Supervisor is the engine; VCF Automation is the storefront and the governance layer on top of it.
The consumption model: provider, organizations, projects, namespaces
The mental model that trips people up is the multi-tenant hierarchy, because it borrows heavily from vCloud Director rather than from classic vRA. Four layers matter.
The provider is run by the Enterprise IT Admin through the Provider portal. This is where you carve up shared infrastructure: data center resources and quotas, NSX edge clusters, IP spaces, provider gateways (which sit on Tier-0 VRFs), and content libraries. A Quick Setup wizard stands up the first organization and assigns its infrastructure quota, which is a reasonable way to learn the model without hand-wiring everything.
An organization is the tenant boundary: a Line of Business, a business unit, or an external customer if you are a service provider. Each org has its own identity provider integration, roles, quotas and policies. One detail worth burning into memory: a VCF Automation organization maps to one NSX Project per NSX Manager. Completing org networking creates an NSX Project, a Transit Gateway, a default VPC and an outbound SNAT rule. If you do not understand how VPCs and Transit Gateways work in VCF 9 NSX, you do not yet understand org networking.
Inside an org, the Org Admin creates Projects (logical groupings for app teams) and assigns each one resource envelopes in the form of vSphere Namespaces. The namespace is where reservations and limits live: CPU, memory, storage classes, and the VPCs that give the workloads network isolation. This is the layer your developers actually touch.
What you get out of the box
The reason VCF Automation is more than a rename is the catalog of cloud services that ship with it, served directly from the Supervisor rather than bolted on through integrations:
- VM Service for declarative VM provisioning with cloud-init or sysprep customization, now including SRM and VADP backup support and deploy-from-ISO.
- vSphere Kubernetes Service (VKS), the product formerly called TKG Service, for full Kubernetes cluster lifecycle, bundled at VKS 3.3.1 in VCF 9.0.
- Network Service for self-service subnets, static routes and load balancers.
- Volume Service for block and file storage through PVCs and snapshots, with RWX support on vSAN storage clusters.
- Data Services for self-service PostgreSQL and MySQL with Day 0, 1 and 2 operations.
- Secret Store and External DNS for credential injection and DNS record lifecycle without external tooling.
All of this is consumable three ways: the web UI, a declarative Kubernetes-style API, or a CLI that integrates with kubectl. On top sits the blueprinting layer, where platform engineers define VMs, networks, storage and applications as code, version them in GitHub or GitLab, and publish them to a self-service catalog. The pattern is familiar to anyone who built vRA blueprints, except the provisioning target is now the Supervisor.
The decision that matters: All Apps versus VM Apps organizations
Here is the part the marketing material soft-pedals. When you create an organization, you pick one of two types, and the choice is not cosmetic.
An All Apps organization is the modern, cloud-native model. It requires vSphere Supervisor services and, critically, NSX VPC networking. The official guidance is explicit: the combination of a vSphere Namespace and a VPC is a prerequisite for All Apps organizations. In return you get the full menu: VMs, VKS, data services, Secret Store, policy as code, the lot.
A VM Apps organization is, in practice, the traditional vRA experience. It does not require Supervisor services or NSX. You provision VMs against classic vSphere constructs, much as you did in vRA 8. It is the on-ramp for shops that are not ready to stand up Supervisor and NSX VPCs on day one.
My take
. Default to All Apps if, and only if, you already run NSX and have committed to VPC-based workload networking. That is where VCF 9 is going, and the Kubernetes, data services and policy-as-code capabilities only exist there. Choose VM Apps when you are migrating an existing vRA estate, you do not yet have NSX deployed, or the tenant genuinely only needs VMs and you do not want to make NSX VPCs a hard dependency for a VM-only workload. What you should not do is pick All Apps because it sounds more future-proof and then discover your NSX edge and VPC design is not ready, because there is no clean in-place flip from one org type to the other. Validate three things before you commit: that NSX is deployed and VPC networking is designed, that the Supervisor deployment model (single-zone versus multi-zone) is decided, and that your identity provider integration is sorted per organization. Get those wrong and onboarding stalls at the first tenant.
Governance: policy as code, content hub, chargeback
Governance is where VCF Automation 9 earns its place over a pile of scripts. Org Admins write IaaS resource policies in YAML, built on native Kubernetes Validating Admission Policy, so guardrails on VM and VKS provisioning are enforced at the infrastructure level rather than hoped for. Pre-defined policy templates ship out of the box if you are new to policy as code. Classic governance constructs (approval, lease, Day-2 action policies) carry over and can be scoped per project.
Content is centralized through the Content Hub, which discovers content libraries across every vCenter and synchronizes them in the background. No more pub/sub library sprawl per vCenter. Cost visibility comes from VCF Operations: chargeback and showback roll up per organization, so the Enterprise IT Admin sees total estate cost while each Org Admin sees only their own. This ties the consumption model back to the fleet, instance and domain architecture that underpins VCF 9.
What I’d Do
Treat VCF Automation as a new consumption platform that happens to reuse vRA’s engines, not as vRA 9. Stand up the provider layer first, model one organization end to end with the Quick Setup wizard before you onboard anyone real, and decide All Apps versus VM Apps on the basis of your NSX and Supervisor readiness rather than the brochure. If you came from vCloud Director, the organization and tenant concepts will feel natural; if you came from vRA, the multi-tenancy and the Supervisor dependency are the parts to study hardest.
Which org type are you defaulting to for your first tenant, and is your NSX VPC design actually ready for it? Next in the series we move into Part 26: VMware Private AI Foundation with NVIDIA on VCF, where these same namespaces and blueprints start provisioning GPU-backed AI workloads.
References
- Broadcom TechDocs: What’s New in VCF Automation 9.0
- VMware Cloud Foundation Blog: Unified Cloud Consumption Experience with VCF 9.0
- Brock Peterson: VCF Automation 9 VM Apps Organization
About The Author
