Host aggregates (or simply aggregates), are commonly confused with the more-familiar term availability zones—however the two are not identical. Customers using OpenStack as a service never see host aggregates; administrators use them to group hardware according to various properties. Most commonly, host aggregates are used to differentiate between physical host configurations. For example, you can have an aggregate composed of machines with 2GB of RAM and another aggregate composed of machines with 64GB of RAM. This highlights the typical use case of aggregates: defining static hardware profiles.
Once an aggregate is created, administrators can then define specific public flavors from which clients can choose to run their virtual machines (the same concept as EC2 instance types on AWS). Flavors are used by customers and clients to choose the type of hardware that will host their instance.
Contrast aggregates with availability zones (AZ) in OpenStack, which are customer-facing and usually partitioned geographically. To cement the concept, think of availability zones and flavors as customer-accessible subsets of host aggregates.
As an OpenStack end user, you don’t really have a choice. Only administrators can create host aggregates, so you will be using availability zones and flavors defined by your cloud administrator.
OpenStack admins, on the other hand, should carefully consider the subtle distinction between the two when planning their deployments. Hosts separated geographically should be segregated with availability zones, while hosts sharing the same specs should be grouped with host aggregates.
You should now have a better sense of the differences between host aggregates, flavors, and availability zones. More information on host aggregates and availability zones is available in the OpenStack documentation. Additional terms and definitions can be found in the OpenStack glossary.