A managed service that gives you a complete VMware environment, running on dedicated servers in Azure, operated jointly by Microsoft and you.

Starting with the word “virtualization”

A physical server is a real machine in a rack. Virtualization is a technique that lets one physical machine behave like many separate computers at once. Each of these pretend computers is a virtual machine, or VM. It has its own operating system, its own programs, and its own settings, yet it shares the real hardware with its neighbors. The software that makes this possible is called a hypervisor.

Who is VMware?

VMware is a company whose software became the standard way to run virtual machines in company datacenters. Its main hypervisor is called ESXi. Its management console is vCenter, which lets administrators create, move, and monitor thousands of VMs. Its network virtualization software is NSX, and its storage virtualization software is vSAN. Together with other pieces, these form what is often called the VMware software-defined datacenter. Millions of VMs around the world run on this stack.

What AVS adds

Azure VMware Solution deploys that same VMware stack on bare-metal servers, which are physical machines with no other software layer underneath, inside Azure datacenters. Microsoft builds and operates the physical hosts, networking, and the lifecycle of the VMware software. You get a VMware environment called a private cloud with its own vCenter, NSX, and vSAN. You then run your existing VMs, using the same tools and skills as before.

Understanding the situation of the customer makes the product make sense.

Problem one: the datacenter lease or hardware is ending

Companies often face a hard deadline: a datacenter contract ends, servers reach end of life, or a building must be vacated. Rebuilding hundreds of applications for the cloud in a few months is rarely possible. Moving the VMs as they are can be done much faster.

Problem two: rewriting everything is expensive and risky

There are many ways to move to the cloud. At one end, you can rehost, moving the system as it is. At the other, you can rebuild, redesigning the application to use cloud-native services. Rebuilding gives the biggest long-term benefits but takes time, money, and skill. Many applications are old, poorly documented, or supplied by vendors who will not change them. AVS supports a “move first, modernize later” approach.

Problem three: retraining and process change

Operations teams have spent years learning VMware. Their monitoring, backup, security, and change processes are built around it. Moving to a very different platform means new skills and new processes on top of the migration itself. AVS keeps the operational model familiar.

Problem four: capacity on demand

A company may need extra capacity for a few months for a project, a disaster recovery site, or a seasonal peak. Buying hardware for that is wasteful. In AVS, hosts can be added or removed from a cluster, within limits and commitment terms.

Problem five: disaster recovery

Building a second datacenter just for emergencies is costly. A cloud-based VMware environment can serve as the recovery site, with replication from the primary location.

Four VMware building blocks appear throughout AVS. Learn them as a team.

ESXi: the hypervisor

ESXi is installed directly on each physical host. It divides the host’s processors, memory, and devices among the VMs. Think of it as the building’s floor plan manager who decides how much of the floor each tenant receives.

vCenter: the control tower

vCenter Server is the central management system. From one console, an administrator can see all hosts and VMs, create new VMs, move VMs between hosts, set resource rules, schedule tasks, and watch performance. It is the main place you work in AVS.

vSAN: shared storage from local disks

vSAN pools the disks inside all hosts of a cluster into one shared storage system. VM data is copied across different hosts according to policies, so if a host or disk fails, the data survives. This removes the need for an external storage array.

NSX: virtual networking and security

NSX creates networks in software. It provides virtual switches called segments, virtual routers called gateways, firewalls, load balancing, and connections to the outside. Networks can be created in seconds without touching physical cables.

Clusters and vSphere features

A cluster is a group of hosts managed as one pool of resources. Features such as vMotion (moving a running VM from one host to another without stopping it), HA (restarting VMs automatically on other hosts after a host failure), and DRS (balancing load across hosts) operate at the cluster level.

flowchart TD
    VC["vCenter: management and control"] --> CL["Cluster: group of hosts"]
    CL --> H1["ESXi host 1"]
    CL --> H2["ESXi host 2"]
    CL --> H3["ESXi host 3"]
    H1 --> VSAN["vSAN: shared storage from local disks"]
    H2 --> VSAN
    H3 --> VSAN
    NSX["NSX: virtual networks and firewalls"] --> VM["Virtual machines"]
    VSAN --> VM
    H1 --> VM
    H2 --> VM
    H3 --> VM
    

The shape of what you actually create in Azure.

The private cloud

The top-level object you create in the Azure portal is an AVS private cloud. It lives in an Azure subscription and region, and it contains the VMware components: vCenter, NSX, and one or more clusters of hosts. It is private in the sense that it is dedicated to you and sits on its own isolated network.

Clusters and hosts

A private cloud has at least one cluster. A cluster needs a minimum number of hosts, commonly three, so that data can be safely copied and failures tolerated, and it has a maximum number per cluster. A private cloud can also have several clusters, up to a limit. Hosts are available in different hardware types with different amounts of processor, memory, and storage. Exact host models, sizes, and limits are updated regularly, so look up the current list for your region.

The management components

When the private cloud is created, the management components are deployed automatically. They include vCenter, the NSX managers, and supporting systems such as HCX (explained later). These consume some of the capacity of the first cluster. You get access to them through a management network that Microsoft provisions for you.

flowchart TD
    SUB["Azure subscription"] --> PC["AVS private cloud in a region"]
    PC --> MGMT["Management: vCenter, NSX manager, HCX"]
    PC --> C1["Cluster 1: hosts with vSAN"]
    PC --> C2["Cluster 2: optional, more hosts"]
    PC --> NET["Isolated private network and ExpressRoute circuit"]
    NET --> VNET["Your Azure virtual network"]
    NET --> ONP["On-premises network"]
    

Scaling

You can add hosts to a cluster to increase capacity, add clusters, or remove hosts when demand falls, within the minimum cluster size and your commitment terms. Adding a host typically takes a short time compared to buying and installing a physical server. Compute and storage scale together, since the host provides both, unless you attach external storage (explained in the storage chapter).

Who operates what

Networking is the part of AVS that most projects spend the most time on. Understand the roads before you move the cargo.

The private cloud network block

When creating a private cloud, you provide a private address range, commonly a /22 block, which AVS divides into smaller ranges for its management, vMotion, storage, and uplink networks. This range must not overlap with anything else in your Azure networks or your on-premises network. Picking it carefully at the start avoids painful redesign.

ExpressRoute inside Azure

ExpressRoute is Azure’s private connection service. Each AVS private cloud comes with an internal ExpressRoute circuit that links it to an Azure virtual network, using an ExpressRoute gateway. Through this link, VMs in AVS can reach Azure VMs, databases, storage, and other services over Microsoft’s private backbone, without crossing the public internet.

Connecting to your office or datacenter

There are two main ways to link your existing environment to AVS.

• ExpressRoute Global Reach: connects your on-premises ExpressRoute circuit directly to the AVS circuit, so traffic flows between your site and AVS without passing through your Azure virtual network.
• Through a virtual network and gateway or virtual WAN: traffic travels from on-premises to a hub network in Azure and onward to AVS, which allows central firewalls and routing.

flowchart LR
    ONP["On-premises datacenter"] -->|"ExpressRoute or VPN"| HUB["Azure hub virtual network"]
    ONP -.->|"Global Reach direct path"| AVS["AVS private cloud"]
    HUB -->|"ExpressRoute gateway"| AVS
    HUB --> SPOKE["Azure workloads: databases, apps, storage"]
    AVS --> SEG["NSX segments for VMs"]
    AVS -->|"internet via NSX or Azure"| NET["Internet"]
    

NSX inside the private cloud

Within AVS, workload networks are built in NSX. The main concepts are:

• Segment: a virtual network, similar to a VLAN, where VMs attach.
• Tier-1 gateway: a virtual router for a group of segments, often one per tenant or application group.
• Tier-0 gateway: the virtual router that connects the private cloud to the outside, handled by the platform.
• Distributed firewall: rules that apply at each VM’s virtual network card, allowing micro-segmentation without hardware appliances.

Internet access

AVS offers options for outbound and inbound internet access. Options include using a managed internet service that provides outbound access and public IP addresses through NSX, or routing internet traffic through a firewall in an Azure virtual network for central inspection. Many organizations choose to send traffic through a security appliance in Azure so rules are consistent. Check the current options and their limits.

DNS and time: the quiet essentials

Two small services cause a surprising number of migration problems. The first is DNS, the system that turns names into addresses. Moved VMs must be able to find domain controllers, databases, and each other by name, from AVS as well as from on-premises and Azure. Decide where the authoritative DNS servers live, set forwarders so that AVS can resolve names in other networks, and make sure the other networks can resolve names for AVS. The second is time synchronization. Many security and clustering features break when clocks drift apart, so all VMs and hosts should follow a trusted time source. Test both with a pilot VM long before any production move.

Also think about the path that administrators use to reach management consoles. A common design is a small jump host inside the Azure hub network, reachable only through secure remote access, from which administrators open vCenter and NSX. This avoids exposing management interfaces to wide networks and gives a single place to record who connected and when.

Where the data of your virtual machines lives, and how to add capacity without adding hosts.

vSAN: the default storage

Each host contains fast local disks, which vSAN combines into one pool for the cluster. VM disks are stored as objects, and storage policies decide how they are protected. A policy can request, for example, that every piece of data be stored in two or three copies on different hosts, or encoded with parity to save space. The policy you choose trades protection, performance, and usable capacity. Heavier protection uses more raw space.

Capacity and the slack space rule

vSAN needs free space to heal after failures and to move data around. A common practice is to keep a good margin of free capacity, rather than filling the datastore to the brim. Watch utilization closely and plan to add hosts or external storage before the pool becomes very full.

The “storage-heavy” problem and external storage

Some workloads need a lot of storage but only moderate compute, such as file servers or archives. Adding hosts just for disk space is expensive. AVS therefore supports attaching external storage from Azure services to the hosts as additional datastores, such as Azure NetApp Files or Azure Elastic SAN, depending on current support. This lets storage grow independently of compute. Check which options are supported in your region and which performance tiers are available.

flowchart TD
    VM["Virtual machine disks"] --> DS1["vSAN datastore: fast local pool"]
    VM --> DS2["External datastore from Azure storage service"]
    DS1 --> POL["Storage policy: copies or parity"]
    DS2 --> NETP["Private network path to storage"]
    HOSTS["Cluster hosts"] --> DS1
    HOSTS --> DS2
    

What you decide and do before the first VM moves.

Before you deploy

• Quota and availability: host capacity in AVS is requested from Microsoft, and availability varies by region and host type. Request it early.
• Subscription and permissions: choose the subscription, resource group, and the people who can create and manage the private cloud.
• Address plan: reserve the private cloud block and check for overlap.
• Hub network: prepare an Azure virtual network with an ExpressRoute gateway.
• Sizing: estimate hosts from inventory and utilization data of your current VMs.

Identity and access

After deployment you receive credentials for a built-in administrator role, often called CloudAdmin, in vCenter and NSX. Rather than sharing this account, connect vCenter to your directory service so that individuals sign in with their own identities and groups are mapped to roles. This supports auditing and least privilege.

HCX is the moving crew that carries virtual machines from your old VMware environment into AVS.

What is HCX?

VMware HCX is a mobility tool that connects two VMware environments and moves workloads between them. In AVS, HCX is available as an add-on that you enable in the portal. You install a matching component at your source site, pair the two, and build a secure link between them. HCX can also extend networks across the two sites, so that a VM can move without changing its IP address.

Migration methods

Network extension

With Layer 2 extension, a network segment in your old site is stretched to AVS, so that a moved VM keeps its address and still sees its neighbors. This makes it possible to move applications piece by piece instead of all at once. The stretch is temporary: after the last VM of a network has moved, you cut over the network itself and remove the extension. During the extension, traffic between the sites passes through the link, so latency and bandwidth matter.

sequenceDiagram
    participant S as Source VMware site
    participant H as HCX link
    participant A as AVS private cloud
    participant T as Migration team
    T->>H: Pair source and AVS and create service mesh
    T->>S: Select group of VMs to migrate
    S->>A: Replicate disks in the background
    S->>A: Keep sending changes
    T->>A: Schedule switchover window
    S->>A: Final sync and stop source VM
    A->>A: Start VM at the new site
    T->>A: Test application
    T->>S: Keep source VM for rollback period
    

Planning migration waves

1. Group VMs by application, because an application’s parts should move together or be arranged so cross-site latency does not hurt.
2. Start with low-risk systems to practice and build confidence.
3. Move the most interdependent or critical systems last, with the best rehearsed plan.
4. Define success checks and a rollback plan for each wave.

Cutover day, in detail

A well-run switchover is boring because everything was rehearsed. A few days before, the team confirms that replication is healthy and the target networks and firewall rules exist. On the day, the team follows a runbook: announce the window, stop the application at the source in the agreed order, let the final replication finish, start the VMs at the new site in dependency order (databases before application servers, application servers before web servers), update DNS or load balancer entries if addresses change, and run a prepared set of tests. Business testers then confirm key transactions. A named person has the authority to call a rollback if success criteria are not met by a fixed time. After success, the old VMs are powered off but kept for a hold period, and are only deleted after sign-off.

After each wave, hold a short review. What took longer than expected? Which firewall rule was forgotten? Which application needed a special start order? Feeding those lessons into the next wave is how the migration gets faster and safer as it proceeds.

How traffic travels once your workloads live in AVS.

flowchart LR
    U["Users"] --> FW["Central firewall or security appliance"]
    FW --> VM["VM in AVS segment"]
    VM -->|"through NSX gateway"| ER["ExpressRoute circuit"]
    ER --> HUB["Azure hub network"]
    HUB --> DB["Azure database service"]
    HUB --> ST["Azure storage"]
    HUB --> ONP["On-premises systems"]
    VM --> MON["Monitoring and backup services"]
    

Traffic categories

• East-west traffic moves between VMs inside AVS. It stays within NSX and is controlled by the distributed firewall.
• North-south traffic enters or leaves the private cloud, toward users, the internet, Azure, or on-premises.
• Management traffic reaches vCenter, NSX, HCX, and the platform, and should be restricted to administrators.
• Migration traffic flows between the old site and AVS during moves.

A request, step by step

Why latency still matters

Traffic between AVS and Azure services is fast, because they sit in the same cloud. Traffic between AVS and your old datacenter, however, has real distance. If an application tier is moved to AVS but its database stays on-premises, every query crosses that distance. This split-brain arrangement can make a system painfully slow. Plan so that tightly coupled components move together.

A big advantage of AVS is that moved VMs gain Azure neighbors that can be adopted step by step.

The modernization ladder

AVS is often the first rung of a ladder, not the final destination. Teams typically move VMs first, and then replace pieces step by step.

Security in AVS is shared: Microsoft protects the platform, and you protect what runs on it.

flowchart TD
    A["Physical: Microsoft datacenter and hosts"] --> B["Platform: lifecycle and isolation by Microsoft"]
    B --> C["Network: NSX segments, gateway firewall, distributed firewall"]
    C --> D["Access: identity, roles, privileged access"]
    D --> E["Workloads: guest operating systems and applications"]
    E --> F["Data: encryption and backups"]
    F --> G["Monitoring: logs, alerts, threat detection"]
    

Network security

• Micro-segmentation: use the NSX distributed firewall to allow only the traffic each VM needs, even between VMs in the same segment.
• Gateway firewalls: control traffic leaving or entering the private cloud.
• Central inspection: route internet and cross-site traffic through a firewall in an Azure hub network for consistent policy and logging.
• Protect management interfaces: allow vCenter, NSX, and HCX only from administrator networks.

Identity and privileged access

Connect vCenter and NSX to your directory. Grant roles to groups according to job duties. Protect the built-in administrator credentials in a vault, restrict their use to emergencies, and rotate them. Require multi-factor sign-in for the portal and for jump hosts used to reach management consoles.

Data protection

vSAN data at rest is encrypted by default using platform-managed keys, with options for customer-managed keys in supported setups. Traffic between sites should use encrypted links. Remember that encryption does not replace backup: a deleted or corrupted VM must be restored from a backup copy.

Compliance

AVS is built on Azure infrastructure that has been assessed against many industry and regional standards, but the compliance of your workloads depends on your configuration and processes. Review Microsoft’s current compliance documentation for the specific standards you must meet, and keep evidence such as access reviews, patch records, and firewall rule justifications.

Workload security basics

• Keep guest operating systems patched; the platform does not patch your VMs.
• Run endpoint protection and monitoring inside the VMs.
• Scan for vulnerabilities and unusual behavior using cloud security tools that support AVS workloads.
• Isolate sensitive systems in their own segments with strict rules.

Three different questions: what if a host fails, what if I delete something by mistake, and what if a whole site is lost?

High availability within the cluster

vSphere HA restarts VMs automatically on other hosts if a host fails. vSAN keeps data copies on different hosts. The platform also replaces failed hosts according to service terms. For this to work, keep enough spare capacity in the cluster so that the remaining hosts can carry the load when one is lost.

Backup

Backup answers the question “what if data is deleted or corrupted?” Because VM snapshots on the same storage are not backups, use a real backup product that stores copies outside the cluster. Options include Azure-based backup services that support AVS, and third-party backup tools that integrate with VMware. Define how often to back up, how long to keep copies, and how quickly each system must be restored. Test restores regularly.

Disaster recovery

Disaster recovery answers “what if the entire site or region fails?” Typical designs include replication to another AVS private cloud in a different region, replication to an on-premises site, or replication to native Azure services. The right design depends on the recovery objectives of each application.

flowchart LR
    PRIM["AVS in primary region"] -->|"replicate"| SEC["Recovery site: AVS in second region or on-premises"]
    PRIM -->|"scheduled backups"| BK["Backup storage outside the cluster"]
    PRIM --> HA["Cluster HA: restart on other hosts"]
    SEC --> RUN["Recovery plan: order, networks, tests"]
    

Setting recovery targets that people understand

Two simple numbers guide every protection design. The recovery time objective is how long an application may be unavailable after a failure. The recovery point objective is how much recent data may be lost. A payroll report that can wait a day and lose a day of changes needs far simpler protection than an order system that must be back within minutes with almost no lost orders. Agree these numbers with the business owners for each application, group applications into a few tiers, and design one protection pattern per tier. This keeps the design understandable and the bill fair, because only the applications that truly need expensive protection receive it.

Finally, write down the order of recovery. Directory services and DNS must come back first, then databases, then application servers, then web tiers. A recovery plan that lists steps, owners, and expected times is worth far more than a diagram on its own, and it must be tested at least once or twice a year because systems change and plans decay.

Running AVS day after day, and understanding what Microsoft does behind the scenes.

What to monitor

Where monitoring data goes

Metrics and logs can be sent to Azure Monitor and Log Analytics, and syslog from NSX and vCenter can be forwarded to a central logging system. Many organizations also keep their existing VMware monitoring tools, which continue to work against vCenter.

Platform maintenance

Microsoft keeps the VMware software and host firmware up to date within supported versions. Upgrades are rolled out in stages and are designed to be non-disruptive through vMotion and cluster capacity. You receive advance notices through Azure service health. To keep upgrades smooth, leave spare capacity in the cluster and avoid configurations that block host evacuation, such as VMs pinned to a specific host.

Operations you still own

• Patching and managing guest operating systems and applications.
• Managing VM lifecycle: creation, sizing, decommissioning.
• Right-sizing VMs to avoid wasting host capacity.
• Managing templates, firewall rules, DNS, and time settings.
• Reviewing alerts and handling incidents.

Troubleshooting basics

AVS is billed by the host, so sizing decides the bill.

How sizing works

Start with data from your current environment: CPU use, memory use, storage consumed, and storage input and output rates for each VM. Tools such as Azure Migrate can analyze and suggest a number of hosts. Then adjust for storage protection policy, spare capacity for failures and maintenance, and growth. Hosts that are limited by storage but not by compute are a sign that external storage may save money.

Cost drivers

Performance considerations

• Over-commitment: VMs often share CPU cores, but too much sharing causes waiting. Watch CPU ready time.
• Memory: avoid memory shortages that cause the hypervisor to compress or swap.
• Storage: match policies to workload needs. Heavy random writes with erasure coding can be slower than mirroring.
• Network paths: keep chatty components close together, and check bandwidth of the ExpressRoute circuit.

A worked sizing story in words

Suppose a company has four hundred VMs. Measurements show that, at their busiest, they use about the equivalent of three hundred virtual processors’ worth of real work, a bit over four terabytes of memory in active use, and around ninety terabytes of stored data. A first estimate based on compute alone suggests a modest number of hosts. But storing ninety terabytes with a protection policy that makes extra copies needs far more raw disk than the data itself, and that storage need pushes the host count up sharply. The team notices that sixty terabytes of the data are file shares and old archives that are rarely read. By placing that data on an external datastore from an Azure storage service, the number of hosts needed drops significantly. The lesson is that the limiting resource is not always the one you expect, and that looking at compute, memory, and storage separately reveals savings.

Add the safety margins last: capacity to survive a host failure and to allow rolling maintenance, and a growth allowance for the first year. Then compare the final plan with the cost of other options, such as converting suitable VMs to native Azure virtual machines, so that the decision rests on numbers rather than habit.

Technology works better when people know who decides what.

Governance basics

• Ownership: name who owns the private cloud, the network, the security rules, and each application.
• Change control: record changes to firewall rules, networks, and cluster sizes, with review for risky ones.
• Tagging and naming: label resources with owner, environment, and cost center so bills and responsibility are clear.
• Policy: use Azure Policy and role-based access for the Azure side, and consistent rules for the VMware side.
• Lifecycle: rules for how long test VMs live and when unused VMs are removed.

Automation

Anything done more than a couple of times should be automated. The Azure side can be created from templates and automation tools. On the VMware side, existing scripts, orchestration tools, and APIs continue to work within the permissions you hold. AVS also provides a way to run approved administrative commands as part of the managed experience, since you do not have full root control. Store automation definitions in version control, review changes, and test them in a small environment first.

A sensible operating model

flowchart TD
    OWN["Service owner: roadmap and budget"] --> PLAT["Platform team: private cloud and capacity"]
    OWN --> SEC["Security team: rules and monitoring"]
    PLAT --> APPT["Application teams: VMs and migration"]
    SEC --> APPT
    PLAT --> FIN["Cloud finance: cost and commitments"]
    APPT --> FIN
    

Approaches that successful teams repeat, and traps they learned to avoid.

Pattern: hub and spoke with AVS as a spoke

Place shared services, firewalls, and gateways in an Azure hub network. Connect AVS, native Azure workloads, and on-premises as spokes. Traffic is inspected centrally and rules are consistent.

Pattern: land, then optimize

Move quickly to meet the deadline, then spend the following months reducing cost and risk: right-size VMs, use external storage, replace components with Azure services.

Pattern: landing zone first

Prepare identity, networking, monitoring, policy, and security before migrating. A well-prepared landing zone makes every wave faster and safer.

Pattern: AVS as disaster recovery site

Use a private cloud with a small baseline of hosts as the recovery location for an on-premises VMware environment, scaling up the cluster during a real failover or a rehearsal where terms allow.

flowchart TD
    HUB["Azure hub: firewall, DNS, gateways, monitoring"] --> AVSS["Spoke: AVS private cloud"]
    HUB --> AZS["Spoke: native Azure workloads"]
    HUB --> ONPS["Connection to on-premises"]
    AVSS --> AZS
    

Anti-patterns

A practical checklist and a list of avoidable errors.

Best practices

Common mistakes

These are composite examples that show typical situations. They are illustrations, not reports about specific companies.

AVS is one choice among several ways of moving workloads.

flowchart TD
    Q["Start: workloads on VMware"] --> A{"Hard deadline and little time to change apps"}
    A -->|"yes"| AVSX["Azure VMware Solution first, then modernize"]
    A -->|"no"| B{"Applications can run on native Azure VMs"}
    B -->|"yes"| NAT["Move to native Azure VMs or managed services"]
    B -->|"no"| C{"Strong need to keep VMware tooling"}
    C -->|"yes"| AVSX
    C -->|"no"| REB["Rebuild or retire"]
    

AVS lets you move the warehouse without rearranging the shelves.

We began with a company that had to leave its old warehouse and had to choose between rebuilding everything and moving into a building arranged in exactly the same way. Azure VMware Solution is the second choice. It gives you a VMware private cloud on dedicated Azure hosts, with vCenter, vSAN, and NSX that your team already knows, while Microsoft runs the physical platform and its lifecycle. HCX carries workloads across, ExpressRoute connects the networks, and native Azure services sit next door, ready to be used when you are.

The deeper lesson is that AVS is a bridge, and bridges work best when you know where you are going. Good projects plan addresses and networks first, move related systems together, protect data with real backups and tested recovery, watch capacity and cost closely, and keep a roadmap for modernizing after the move.