Skip to main content
IMHCloud Logo
Back to glossary

Flavors

A flavor is a predefined template that specifies the vCPUs, RAM, and disk space allocated to an instance when you launch it in a cloud environment.

What is a Flavor in cloud hosting?

A flavor is a predefined template that specifies the amount of compute resources allocated to an instance (virtual machine) when you launch it. Each flavor defines a specific combination of vCPUs, RAM, and root disk storage. When you create an instance, you select a flavor to determine how much computing power that instance will have.

Flavors exist as standardized options provided by your cloud platform. Instead of manually configuring CPU, memory, and disk for every instance, you pick from a menu of flavors that match your workload requirements. The cloud platform then provisions an instance with exactly those resources.

Why Flavors exist

Without flavors, every user would need to specify exact CPU counts, memory amounts, and disk sizes each time they create an instance. This creates several problems:

  • Users might request invalid combinations that the underlying hardware cannot support
  • Billing becomes complicated when every instance has unique specifications
  • Capacity planning becomes difficult when resources are allocated in arbitrary increments
  • New users face a steep learning curve trying to determine appropriate resource amounts

Flavors solve these problems by providing predefined resource configurations that cloud administrators create to align with available hardware, sensible billing tiers, and common workload patterns. Users then select from these options, knowing each flavor represents a working configuration.

What Do Flavors Actually Do?

  • Reserves a specific number of vCPUs for your instance, determining how many simultaneous processing threads your applications can use
  • Allocates a fixed amount of RAM, setting the maximum memory available for your operating system and applications
  • Provisions a root disk of a defined size, establishing how much local storage your instance has for the OS and installed software
  • May include ephemeral disk space that provides temporary local storage which is deleted when the instance is terminated
  • Sets resource limits that the hypervisor enforces, preventing your instance from consuming more than its allocated share
  • Determines the billing rate for the instance, since pricing is typically tied to the flavor selected

When would I use a Flavor?

Launching a new instance: Every time you create an instance in OpenStack or a similar cloud platform, you must select a flavor. There is no way to launch an instance without one.

Matching resources to workload requirements: When you know your application needs at least 8GB of RAM and 4 vCPUs to run properly, you select a flavor that meets or exceeds those requirements.

Controlling costs: If you want to run a development server that does not need production-level resources, you select a smaller flavor with fewer vCPUs and less RAM to reduce hourly costs.

Scaling your infrastructure: When deploying multiple identical instances behind a load balancer, you use the same flavor for each instance to ensure consistent performance across your pool.

Resizing an instance: When your application outgrows its current resources, you can resize the instance to a larger flavor with more vCPUs, RAM, or disk space.

When would I NOT use a Flavor?

When you need resources beyond any available flavor: If your workload requires 512GB of RAM but the largest flavor offers 256GB, you cannot use a single instance. You would need to distribute the workload across multiple instances or request custom flavors from your cloud provider.

When you need precise resource control: Flavors offer fixed combinations. If you need exactly 6 vCPUs with 12GB RAM but available flavors offer either 4 vCPUs with 8GB or 8 vCPUs with 16GB, you must choose the closest match rather than an exact specification.

When using bare-metal servers: Bare-metal servers provide dedicated physical hardware rather than virtualized resources. While some platforms use "flavors" to categorize bare-metal options, you are selecting physical server specifications rather than virtual resource allocations.

When cost optimization requires granular adjustments: If your application uses 3.5GB of RAM and paying for a 4GB flavor wastes resources, you cannot request a 3.5GB allocation. Flavors come in predefined increments.

Real-world example

Company A runs an e-commerce platform with three tiers of servers. Their web servers handle HTTP requests and need moderate CPU but minimal RAM, so they use a "general.medium" flavor with 2 vCPUs and 4GB RAM. Their application servers run business logic and need balanced resources, so they use a "general.large" flavor with 4 vCPUs and 8GB RAM. Their database server needs high memory for caching query results, so they use a "memory.xlarge" flavor with 8 vCPUs and 32GB RAM. By selecting appropriate flavors for each tier, Company A allocates resources efficiently and controls costs. When holiday traffic increases, they add more web server instances using the same "general.medium" flavor, knowing each new instance will have identical resources.

Frequently Asked Questions

Can I change the flavor of a running instance? Yes, most cloud platforms allow you to resize an instance to a different flavor. This typically requires stopping the instance, selecting the new flavor, and starting it again. The process migrates your root disk to a new virtual machine with the updated resource allocation. Some platforms support live resizing for certain flavor changes.

What happens if I select a flavor that is too small for my application? Your application will run slowly or crash. If your application needs 2GB of RAM but you select a flavor with only 1GB, the operating system may kill processes when memory runs out. If your application needs more CPU than available, requests will queue and response times will increase.

Do all cloud platforms use the term "flavor"? No. OpenStack uses "flavor," but other platforms use different terminology. AWS calls them "instance types," Google Cloud calls them "machine types," and Azure calls them "VM sizes." The concept is the same: predefined resource configurations you select when launching instances.

How do I know which flavor to choose? Start by understanding your application's minimum requirements for CPU, RAM, and disk. Check application documentation or run tests to measure actual usage. Select a flavor that meets those requirements with some headroom for traffic spikes. Monitor resource usage after deployment and resize if needed.

Can I create custom flavors? On self-managed OpenStack deployments, administrators can create custom flavors with any valid resource combination. On public cloud platforms like InMotion Cloud, you typically choose from the provider's predefined flavors. Contact your provider if you need a configuration that does not exist.

Summary

  • A flavor is a predefined template specifying vCPUs, RAM, and disk space for a cloud instance
  • You must select a flavor every time you launch an instance, as it determines the resources allocated
  • Flavors simplify instance creation by offering standardized configurations instead of requiring manual resource specification
  • Different flavors suit different workloads: smaller flavors for development and lightweight services, larger flavors for production and resource-intensive applications
  • You can resize instances to different flavors when your resource requirements change

Related terms

  • An instance is a virtual machine running in the cloud, such as a Linux server you launch to host a web application or a Windows server running a database.
  • OpenStack is an open-source cloud platform where flavors are a core concept for defining instance sizes, such as when you select "m1.medium" to launch a 2 vCPU, 4GB RAM instance.

Related Terms

Read definition

Usage-Based Billing

Usage-based billing is a pricing model where customers pay only for the cloud resources they actually consume rather than a fixed monthly fee.

Cost Management
Learn more