Choosing the Right Azure VM Sizes for RHEL 8 Workloads

Introduction

Running enterprise Linux workloads in the cloud is no longer just about “lifting and shifting” virtual machines. Performance predictability, cost efficiency, scalability, and operational resilience all depend on choosing the right virtual machine size for the workload at hand. In Microsoft Azure, this choice can feel overwhelming: dozens of VM families, hundreds of SKUs, multiple processor generations, and different storage and networking capabilities—all before you even install your operating system.

For organizations running Red Hat Enterprise Linux (RHEL) 8, VM size selection is especially important. RHEL 8 is designed for modern, hybrid, and cloud-native workloads. It introduces a modular application stream model, enhanced security defaults, improved performance tooling, and deep integration with container platforms like Podman and Kubernetes. These capabilities shine only when the underlying compute, memory, storage, and network resources are aligned with workload requirements.

This article is a deep technical guide to help you choose the right Azure VM sizes for RHEL 8 workloads. We will look at how Azure VM families are structured, how RHEL 8 behaves on Azure, and how to map real-world workloads—databases, application servers, containers, CI/CD, analytics, and HPC—to the most suitable VM types.

Somewhere during your architecture planning, you will encounter the concept of a Red Hat Enterprise Linux RHEL 8 image on Microsoft Azure. Understanding how that image interacts with Azure VM capabilities is a critical step toward building a stable and cost-efficient platform.

By the end of this guide, you will have a practical framework for selecting Azure VM sizes that balance performance, reliability, and cost for RHEL 8 in production environments.

Understanding Azure VM Size Fundamentals

Before diving into workload-specific recommendations, it is essential to understand how Azure defines and differentiates VM sizes.

Azure VM Families vs. VM Sizes

In Azure terminology:

• VM family defines the general purpose of the VM (general-purpose, compute-optimized, memory-optimized, etc.).
  
• VM size (SKU) defines the exact configuration: number of vCPUs, memory, temporary storage, network bandwidth, and disk throughput limits.
  

For example, the Dsv5 family is a general-purpose family, while Standard_D8s_v5 is a specific size within that family.

Key Dimensions That Matter for RHEL 8

When running RHEL 8 on Azure, the following dimensions are critical:

1. vCPU count and CPU architecture
   
2. Memory size and NUMA layout
   
3. Disk IOPS and throughput limits
   
4. Network bandwidth and accelerated networking
   
5. Processor generation (Intel vs AMD)
   
6. Cost model and scaling flexibility
   

Each of these dimensions influences how RHEL 8 behaves under load.

RHEL 8 Characteristics That Influence VM Selection

RHEL 8 is not a lightweight operating system. It is built for enterprise workloads and assumes access to modern hardware features.

Kernel and CPU Awareness

RHEL 8 ships with a modern Linux kernel that is NUMA-aware, scheduler-optimized, and capable of taking advantage of large core counts. This means:

• Larger VM sizes scale efficiently for multi-threaded workloads.
  
• Poor CPU-to-memory balance can cause performance degradation.
  
• CPU pinning and isolation (via tuned profiles) are effective on larger instances.
  

Memory Management

RHEL 8 uses advanced memory management features such as:

• Transparent Huge Pages (THP)
  
• Improved page reclaim algorithms
  
• cgroups v2 (in newer minor versions)
  

These features benefit memory-intensive workloads but also make memory pressure more visible when VM sizing is inadequate.

Storage and I/O Behavior

RHEL 8 performs well with high-throughput block devices and benefits from predictable latency. Azure-managed disks expose different performance tiers depending on disk type and VM size, making VM selection inseparable from storage design.

Overview of Azure VM Families Relevant to RHEL 8

Let’s explore the Azure VM families most commonly used with RHEL 8 workloads.

General Purpose: D-Series and B-Series

D-Series (Dv5, Dsv5)

The D-series is the default choice for many RHEL 8 deployments.

Characteristics:

• Balanced CPU-to-memory ratio
  
• Good network performance
  
• Support for Premium SSD and Ultra Disk
  
• Ideal for most enterprise workloads
  

Best for:

• Web servers (Apache, NGINX)
  
• Application servers (Java, .NET Core on Linux)
  
• Small to medium databases
  
• CI/CD agents
  
• Monitoring and management services
  

For example, a Standard_D4s_v5 VM is often an excellent starting point for RHEL 8 application servers.

B-Series (Burstable)

B-series VMs are cost-efficient but come with CPU credit constraints.

Best for:

• Development and testing
  
• Low-traffic services
  
• Automation tasks
  
• Bastion hosts
  

Not recommended for:

• Production databases
  
• Sustained CPU-intensive workloads
  

RHEL 8 runs fine on B-series, but CPU throttling can negatively impact performance-sensitive applications.

Compute Optimized: F-Series

F-series VMs provide a high vCPU-to-memory ratio.

Characteristics:

• More CPU cores per GB of RAM
  
• High clock speeds
  
• Lower memory footprint
  

Best for:

• Batch processing
  
• Build servers
  
• Media encoding
  
• Scientific simulations
  
• Stateless microservices with high CPU demand
  

For RHEL 8 workloads like CI pipelines or compute-heavy microservices, Fsv2 sizes are often more cost-effective than D-series.

Memory Optimized: E-Series and M-Series

E-Series

E-series VMs are memory-heavy compared to CPU count.

Best for:

• In-memory databases (Redis, SAP HANA test systems)
  
• Large JVM-based applications
  
• Caching layers
  
• Analytics engines
  

RHEL 8 benefits significantly from larger memory pools, especially for JVM tuning and page cache utilization.

M-Series

M-series VMs are designed for massive memory workloads.

Best for:

• Large SAP deployments
  
• Enterprise-grade in-memory databases
  
• Legacy workloads requiring huge RAM footprints
  

These are specialized and expensive but sometimes unavoidable for mission-critical workloads.

Storage Optimized: L-Series

L-series VMs are designed for high disk throughput and IOPS.

Characteristics:

• Local NVMe storage
  
• High disk bandwidth
  
• Lower CPU-to-memory ratio
  

Best for:

• NoSQL databases
  
• Log ingestion platforms
  
• Data processing pipelines
  
• Search engines (Elasticsearch, OpenSearch)
  

RHEL 8 works very well on L-series when tuned correctly for I/O scheduling and filesystem options.

GPU-Enabled: N-Series

N-series VMs include NVIDIA GPUs.

Best for:

• Machine learning
  
• AI inference and training
  
• GPU-accelerated compute
  
• Visualization workloads
  

RHEL 8 is a common choice for GPU workloads due to its stability and long-term support.

Choosing VM Sizes by Workload Type

Now let’s map real-world RHEL 8 workloads to Azure VM sizes.

Web Servers and API Gateways

Typical stack:

• RHEL 8
  
• NGINX or Apache
  
• PHP, Python, or Node.js
  

Recommended VM families:

• Dsv5
  
• Fsv2 (for CPU-heavy APIs)
  

Sizing guidance:

• Start with 2–4 vCPUs
  
• 8–16 GB RAM
  
• Scale horizontally rather than vertically
  

Application Servers (Java, Middleware)

Typical stack:

• RHEL 8
  
• JBoss / WildFly
  
• Spring Boot
  
• Tomcat
  

Recommended VM families:

• Dsv5
  
• E-series (for large heaps)
  

Sizing guidance:

• JVM heap should not exceed 70% of RAM
  
• Prefer fewer, larger VMs for stateful apps
  
• Enable accelerated networking
  

Databases on RHEL 8

Relational Databases (PostgreSQL, MySQL)

Recommended VM families:

• Dsv5 (small to medium)
  
• E-series (memory-heavy workloads)
  
• L-series (I/O-intensive workloads)
  

Sizing guidance:

• Prioritize disk throughput and latency
  
• Avoid burstable VMs
  
• Use Premium SSD or Ultra Disk
  

Containers and Kubernetes Nodes

RHEL 8 is widely used as a base OS for container platforms.

Recommended VM families:

• Dsv5 for balanced clusters
  
• Fsv2 for compute-heavy pods
  
• E-series for memory-heavy workloads
  

Sizing guidance:

• Avoid overcommitting memory
  
• Leave headroom for kubelet and OS
  
• Prefer uniform node sizes for scheduling efficiency
  

CI/CD and Build Systems

Typical tools:

• Jenkins
  
• GitLab Runner
  
• Azure DevOps agents
  

Recommended VM families:

• Fsv2
  
• Dsv5
  

Sizing guidance:

• High CPU count
  
• Fast temporary storage
  
• Ephemeral OS disks where possible
  

Analytics and Batch Processing

Typical workloads:

• ETL pipelines
  
• Spark jobs
  
• Data transformation
  

Recommended VM families:

• F-series
  
• L-series
  
• E-series (depending on memory needs)
  

Sizing guidance:

• Match memory to dataset size
  
• Scale out aggressively
  
• Use spot instances where appropriate
  

Networking Considerations for RHEL 8 on Azure

VM size directly affects network performance.

• Larger VM sizes offer higher bandwidth
  
• Accelerated Networking is critical for low latency
  
• Small VMs may bottleneck under high traffic
  

For production RHEL 8 systems, always choose VM sizes that support Accelerated Networking.

Disk and Storage Implications of VM Size

Azure limits disk throughput and IOPS at the VM level.

Even if you attach high-performance disks:

• A small VM will throttle disk performance
  
• Larger VMs unlock higher aggregate throughput
  

For database-heavy RHEL 8 workloads, VM size selection is often more important than disk type alone.

Cost Optimization Strategies

Choosing the “right” VM size is not about picking the biggest instance.

Practical strategies:

• Start small and scale based on metrics
  
• Use Azure Monitor and tuned profiles
  
• Combine Reserved Instances with autoscaling
  
• Right-size regularly
  

RHEL 8 provides excellent observability tools (perf, tuned, cockpit) to guide optimization.

High Availability and Scaling Considerations

Instead of a single large VM:

• Use multiple smaller VMs
  
• Place them in Availability Zones
  
• Use Azure Load Balancer or Application Gateway
  

RHEL 8 works best in architectures that assume failure and scale horizontally.

Security and Compliance Impact of VM Choice

Larger VM sizes:

• Support stronger encryption workloads
  
• Handle security scanning better
  
• Reduce performance impact of security agents
  

RHEL 8 security features (SELinux, FIPS, auditd) benefit from sufficient CPU and memory headroom.

Common Mistakes When Choosing Azure VM Sizes

1. Using B-series in production
   
2. Ignoring disk throughput limits
   
3. Overcommitting memory
   
4. Scaling vertically instead of horizontally
   
5. Choosing VM sizes without Accelerated Networking
   

Avoiding these mistakes leads to more predictable RHEL 8 performance.

Decision Framework Summary

When choosing Azure VM sizes for RHEL 8, ask:

1. Is my workload CPU, memory, or I/O bound?
   
2. Does it scale vertically or horizontally?
   
3. How sensitive is it to latency?
   
4. What are the steady-state vs peak requirements?
   
5. Can I optimize cost with autoscaling or reservations?
   

Answering these questions narrows the choice quickly.

Conclusion

Selecting the right Azure VM sizes for RHEL 8 workloads is a foundational architectural decision. It affects performance, stability, security, and cost across the entire lifecycle of your application. Azure’s wide range of VM families makes it possible to tailor infrastructure precisely—but only if you understand how RHEL 8 interacts with compute, memory, storage, and networking resources.

By aligning workload characteristics with the appropriate Azure VM families and sizes, you can fully leverage RHEL 8’s enterprise-grade capabilities while maintaining control over performance and spending. Whether you are running web services, databases, containers, or analytics pipelines, thoughtful VM sizing turns the cloud from a cost center into a strategic advantage.

When done right, RHEL 8 on Azure becomes not just a supported platform, but a highly optimized one—ready for modern, scalable, and secure enterprise workloads powered by Microsoft Azure and supported by the long-term stability of Red Hat.

Red Hat, Red Hat Enterprise Linux, and RHEL are trademarks or registered trademarks of Red Hat, Inc. We are not affiliated with or endorsed by Red Hat.