Breaking the 100-Domain Barrier: How We Scaled Multi-Domain Hosting with Kong Gateway

The Growth Problem Every SaaS Dreams Of (And Dreads)

Picture this: Your AI-powered website creation platform is absolutely crushing it. New customers are signing up daily, each bringing their own custom domains. Your infrastructure team is celebrating the growth, but there's a storm brewing on the horizon.

Then it hits you like a brick wall – AWS Application Load Balancer's 100 host-header rule limit.

Suddenly, your infrastructure that seemed so robust is now the bottleneck preventing you from onboarding new customers. Sound familiar? This is exactly what happened to one of our clients, and how we transformed their entire hosting architecture to break free from these limitations.

The Legacy Infrastructure Trap

Let's be honest – the traditional setup seemed logical at first:

Simple, straightforward, and... completely unsustainable.

The Pain Points That Kept Us Up at Night

🔒 SSL Certificate Hell Every new domain meant manually provisioning SSL certificates. Our client's ops team was spending hours each week just getting certificates set up, renewed, and managed. It was like having a full-time job just for SSL babysitting.

📊 The Dreaded 100-Rule Limit AWS ALB's hard limit of 100 host-based routing rules per listener became our arch-nemesis. It's like being told you can only have 100 customers – not exactly the scaling story you want to tell your investors.

⚙️ Manual Everything Adding a new domain required infrastructure changes, manual certificate setup, and routing configuration. What should take minutes was taking hours, and every step was a potential point of failure.

💸 Operational Overhead Through the Roof Managing EC2 instances, tracking certificate expiration dates, and manually configuring routes for hundreds of domains? Our client's team was drowning in operational tasks instead of focusing on product innovation.

The "Aha!" Moment: Rethinking Multi-Domain Architecture

After analyzing the constraints and future growth projections, we realized we needed to completely reimagine the architecture. The solution? Kong Gateway combined with modern AWS services to create a truly cloud-native, infinitely scalable hosting platform.

Our Modern Architecture: Where Magic Happens

🚀 Kong Gateway as the Traffic Orchestrator

We deployed Kong Gateway 3.9.1 on AWS ECS with awsvpc mode for maximum security and network isolation. But here's where it gets interesting – Kong doesn't have ALB's arbitrary 100-rule limitation. We can route traffic for thousands of domains through a single Kong instance.

The game-changer? Kong's ACME plugin automatically handles SSL certificate issuance and renewal through Let's Encrypt. No more 3 AM certificate expiration alerts!

🌍 Global Performance with AWS Global Accelerator

We didn't stop at just solving the scaling problem. Customer experience matters, so we implemented:

• AWS Global Accelerator for low-latency worldwide access
• Network Load Balancer in TCP mode handling both port 80 (for ACME challenges) and port 443 (for secure traffic)

This setup ensures your customers get blazing-fast performance regardless of their location.

🔍 Dynamic Service Discovery with AWS Cloud Map

Here's where the architecture gets really elegant:

• Each customer website runs in its own dedicated ECS service (perfect isolation)
• Services automatically register with AWS Cloud Map using SRV records
• Kong dynamically discovers and routes to the correct backend service

No more manual routing configurations. The system self-organizes!

🤖 Full Automation with AWS Lambda

The crown jewel of our solution is the serverless automation workflow. When a new domain needs to be provisioned, our Lambda function receives a payload like this:

{
  "ecs_service_name": "customer-website-123",
  "subdomain": "mycoolsite", 
  "container_image": "nginx:latest",
  "container_port": 80,
  "cpu": 256,
  "memory": 1024,
  "envs": [],
  "domain": "test.domain"
}

// Automated workflow steps
1. Parse payload (subdomain: "mycoolsite", domain: "virtues.agency")
2. Create ECS service with specified resources (256 CPU, 1024 MB memory)
3. Deploy container image with environment variables
4. Register service with Cloud Map for discovery
5. Create Kong service and route for "mycoolsite.virtues.agency"
6. ACME plugin automatically provisions SSL certificate
7. Customer site is live in < 5 minutes

The Architecture in Action

Expand Image

The Results: Numbers That Speak Volumes

✅ What We Achieved

Scalability Beyond ALB Limits

We eliminated the 100-domain bottleneck and can now support up to 5,000 domains per ECS cluster, with multi-cluster strategies for unlimited growth.

⚡ Lightning-Fast Provisioning

New domains go from signup to live website in under 5 minutes, completely automated. No human intervention required.

🔐 Rock-Solid Security

Every domain gets automatic SSL certificates with auto-renewal. No more certificate-related outages or security warnings.

💰 Significant Cost Savings

Automation and optimized resource utilization reduced infrastructure costs by 40% while dramatically improving performance.

🎯 Team Focus Shift

The ops team went from fighting infrastructure fires to focusing on product innovation and customer experience.

Lessons Learned and Best Practices

🎯 What Worked Brilliantly

• Kong's flexibility made it the perfect ALB replacement for multi-domain scenarios
• ECS + Cloud Map provided the perfect balance of isolation and service discovery
• Serverless automation eliminated human error and dramatically reduced provisioning time

🔧 What We'd Do Differently

• Monitoring setup should be planned from day one – multi-domain architectures generate a lot of metrics
• Health check strategies need to be robust across hundreds of services
• Cost monitoring becomes crucial when you can spin up services automatically
• Multi-cluster planning should be considered early if you expect to exceed 5,000 domains

The Reality Check: ECS Limits and Scaling Strategies

Before we get too excited about "infinite" scaling, let's address the elephant in the room – ECS has limits too.

Current ECS Service Quotas (as of 2024)

ECS supports up to 5,000 services per cluster, which is a significant improvement from the original 1,000 limit. However, there's an important caveat: services configured to use ECS service discovery have a limit of 1,000 tasks per service due to AWS Cloud Map service quota limitations.

So what does this mean for our architecture?

• Single cluster approach: Works well for up to 5,000 domains
• Multi-cluster strategy: Required beyond 5,000 domains
• Cloud Map consideration: Each service is limited to 1,000 tasks (usually not an issue for website hosting)

Ready to Break Your Own 100-Domain Barrier?

If you're hitting similar scaling walls with your multi-domain SaaS platform, you don't have to accept these limitations. Modern cloud-native architectures can solve problems that seemed impossible just a few years ago.

The key is to stop thinking about infrastructure as a collection of servers and start thinking about it as a programmable platform that adapts to your business needs.

Want to discuss how this architecture could work for your specific use case? Let's talk about transforming your infrastructure from a scaling bottleneck into a competitive advantage.