Why Hyperscalers Won’t Let You Build an Email Service on Their Infrastructure

If you run a legitimate Email Service Provider (ESP) or a high-volume mail-sending service, you’ve undoubtedly discovered a frustrating truth: hyperscalers are fundamentally hostile to your business. You’re not just another tenant on AWS or GCP but a high-risk, high-volume workload.

Public cloud hyperscalers are built for general-purpose, bursty applications. They rely on shared IP pools and broad, automated abuse detection to protect their platform. This model is a business-killer for a high-volume email service. You face arbitrary throttling, platform-level service bans, and the constant risk of being penalized on a shared IP block.

Not to mention, this hostility may be in no small part due a direct conflict of interest. Hyperscalers like AWS, GCP, and Azure have their own high-margin, managed email services like Amazon SES, Azure Communication Services, and Google’s email APIs/Gmail. Their platforms are designed to funnel you into these pay-per-email ecosystems. By actively blocking or throttling direct SMTP traffic from their compute instances, they eliminate competition and make it nearly impossible to build your own service on their infrastructure. They want you as a metered-service customer.

To succeed, you must stop fighting your platform. You need to build on a dedicated infrastructure that provides total control, predictable performance, and a financial model that rewards your scale.

Why Hyperscalers Fail ESPs

The core issue is control. On a hyperscaler’s platform, you have none.

• Shared IP Reputations: You are “guilty by association.” Even if you follow every best practice, a spammer on the same AWS IP range can get your block blacklisted, cratering your deliverability.
• Arbitrary Throttling and Bans: The moment your high-volume, steady-stream egress traffic triggers an algorithm, you risk having your service throttled or your account shut down with little to no recourse. This is not a stable foundation for a business.
• A Misaligned Business Model: Hyperscalers charge for data egress, treating it as a byproduct. For you, egress is the product. Their per-GB billing model punishes you for your own success, turning your best customers into your biggest cost centers.

Architecting a Resilient ESP on OpenMetal

A professional email service is a multi-tiered, resilient architecture. This is impossible to build correctly in a shared, multi-tenant environment. A dedicated platform is the only solution.

Here’s how a professional ESP is built on OpenMetal.

1. The Foundation: Dedicated Hardware and BYOIP

First, you need a platform that treats you like a professional partner. At OpenMetal, we require and support Bring Your Own IPs (BYOIP) for mass-scale email providers. We know that as a serious ESP, you already manage your own /24s or larger IP blocks. Our platform is built for this. We provide the BGP announcement from our edge.

Your entire service runs on its own dedicated VLANs, a part of our infrastructure private networking. You are completely isolated from all other customers. “Noisy neighbor” problems cease to exist.

2. The Multi-Tier Design: Security, Scale, and Speed

You can’t have your mail queues, customer databases, and public-facing relays on the same network. A dedicated platform gives you the tools to build a secure, high-performance, multi-tier system using our included 20Gbps private networking. This unmetered, high-speed network is invisible to the public internet and connects all your servers at no additional cost.

• Frontend (SMTP Relays): This is your public-facing fleet. The goal is high concurrency. A cluster of Medium V4 servers is perfect for this. With 24 cores and 256GB of DDR5 RAM, each server can handle tens of thousands of simultaneous SMTP connections. You can scale this fleet horizontally as your traffic grows.
• Backend (Application and Queues): This is your core business logic. Run your customer-facing API, databases, and high-throughput mail queues (like RabbitMQ or Kafka) on Large V4 or XL V4 servers. With 32 to 64 cores and 512GB to 1TB of DDR5 RAM, these machines can hold massive queues in-memory, process bounce-backs, and handle customer API requests without breaking a sweat.
• Analytics and Storage (The “Data Lake”): Every email you send creates a dozen data points. For logging, analytics, and compliance, you need a storage solution. This is where a Large V4 Storage Server may be helpful. With 264TB of raw HDD capacity for long-term storage and 25.6TB of blazing-fast NVMe for a “hot” analytics-ingest layer, you can build a massive data lake to analyze deliverability and customer engagement.

All three of these tiers communicate over the private 20Gbps network, so your SMTP relays can talk to your queues, and your queues can dump data to your storage cluster, all with zero public exposure and zero data transfer fees.

A Model That Supports Your Scale

This is where the model flips. Instead of being penalized for volume, you’re rewarded for it.

• No Sending Limits: It’s your dedicated hardware. We don’t impose any sending limits, throttling, or platform-level rules. You have full control, right down to the modern IPMI access.
• The Egress Advantage: An ESP’s primary product is outbound data. OpenMetal’s generous egress allotments are pooled across your cluster. A single XL V4 server includes 2Gbps of egress. A three-node cluster for your backend gives you a 6Gbps pooled allowance.
• Fair Billing: If you do exceed your massive included allotment, you’re billed on the 95th percentile. This method is built for high-volume services. It allows for huge spikes in traffic (e.g., a big customer’s campaign) without a massive, line-item overage bill. You are not punitively charged per-GB like on AWS. Your costs are predictable and aligned with your growth.

Bare Metal or Your Own Private Cloud

How you manage this hardware is up to you.

1. Bare Metal: Treat these servers as pure, dedicated hardware. Install your OS of choice and build your service from the ground up.
2. On-Demand Private Cloud: Deploy an On-Demand OpenStack Private Cloud Core on a 3-node cluster. This gives you a full cloud control plane (like a private AWS) running on your dedicated hardware. You can then use OpenStack tools to spin up your frontend SMTP relays as VMs, allowing you to scale your fleet up or down in seconds all within your own isolated, high-performance environment.

Start Building Your Large-Scale Email Service With OpenMetal

You can’t build a professional email service on a platform that’s actively working against you. Stop risking your business on the whims of hyperscaler algorithms and their misaligned business models.

Move to a dedicated platform that provides the architectural control, network isolation, and fair economic model you need to scale.

Ready to build your platform? Talk to our team about a Proof of Concept deployment today.