qasim@wiki:~$ ▍
Wiki Home Portfolio

Architecture Overview

Current setup

User/Browser
    │
    ├── requests www.example.com ──► DNS: CNAME → ALB (us-east-1.elb.amazonaws.com)
    │                                     │
    │                                     ▼
    │                              AWS WAF → ALB (ACM SSL) → Target Group (EC2/ECS/Fargate)
    │
    └── requests example.com (apex) ──► DNS: A record → Static IP (MainDomains server)
                                              │
                                              ▼
                                    Apache 301 redirect: example.com → www.example.com
                                    (also hosts redirects for several other client domains)

Why the split exists

  • Subdomains (www.*) → CNAME straight to the ALB. Clean, no static IP needed, SSL handled by ACM on the ALB.
  • Apex domain → can't CNAME (see DNS Fundamentals), so it's pointed at a small EC2 instance ("MainDomains server") with a fixed IP, whose only job is to redirect example.com → www.example.com.
  • The MainDomains server also does the redirect at the web-server level (Apache), as a fallback in case a client's DNS provider hasn't picked up the redirect, or DNS propagation is slow.
  • SSL for the apex domain is issued via Let's Encrypt / certbot directly on that server, since ACM only covers the ALB, not this separate box.

Why this is a shared, multi-tenant server

Cost and practicality: rather than running one small EC2 instance per client just to handle an apex redirect, one server hosts the redirect vhost for every client's apex domain. This is efficient, but it means:

  • Every client's apex traffic depends on one shared server's config.
  • A misconfigured or missing vhost for one domain can allow Apache to fall through to a different, unrelated client's vhost — see the Incident Postmortem for exactly how this happened and how it's now prevented.

Related pages

← Back to the DNS series index