|8 min read

Akamai-Fronted Web Applications on AWS

Designing enterprise web tier architecture with Akamai CDN in front of AWS origins, including WAF, origin shield, and caching strategies

cloud

At enterprise scale, you do not serve web traffic directly from your origin servers. You put a CDN in front of them. For a major entertainment company serving content to hundreds of millions of users globally, that CDN is Akamai, and the origin infrastructure runs on AWS. The interplay between these two layers is more nuanced than it appears, and getting it right has a material impact on performance, security, and cost.

Why Akamai in Front of AWS

AWS has CloudFront, its own CDN. It is a good service. But enterprises with existing Akamai contracts, deep Akamai expertise, and applications already configured for Akamai delivery do not rip that out just because the origin moved to AWS. The CDN layer and the origin layer are separate concerns, and changing both simultaneously is unnecessary risk.

Akamai also brings capabilities that matter at our scale: a larger edge network, advanced traffic management, bot detection, and a mature WAF with rules tuned for high-profile targets. When your web properties are globally recognized brands, the attack surface is significant, and the CDN is your first line of defense.

The Architecture

The high-level architecture is straightforward:

Users
  |
Akamai Edge (Global)
  |
Origin Shield (Regional)
  |
AWS ALB (us-east-1 / us-west-2)
  |
ECS / EC2 Origin Servers

Every user request hits an Akamai edge server first. If the content is cached, Akamai serves it directly. If not, the request goes to the origin. But it does not go directly to our ALB. It goes through Origin Shield.

Origin Shield: Why It Matters

Without Origin Shield, every Akamai edge server that experiences a cache miss sends a request to your origin. With a global edge network, that means cache misses from Tokyo, London, Sydney, and Sao Paulo all hit your origin servers independently. For a cache miss on popular content, you can see hundreds of near-simultaneous requests for the same object.

Origin Shield collapses these requests. It acts as a regional caching layer between the edge and the origin. All edge servers in a region funnel cache misses through the shield, which handles deduplication. If ten edge servers request the same uncached object simultaneously, Origin Shield sends one request to the origin and distributes the response to all ten.

The impact on origin load is dramatic. Without Origin Shield, a cache expiration event on popular content could spike origin requests by 10 to 50 times normal traffic. With Origin Shield, origin traffic stays flat regardless of how many edge servers are requesting the content.

Caching Strategy

Effective caching requires precision. Not all content is equal, and caching the wrong content (or not caching the right content) creates either stale data problems or unnecessary origin load.

We categorize content into tiers:

Static assets (images, CSS, JavaScript, fonts): Cached aggressively with long TTLs, typically 30 days. Content-hashed filenames ensure that deployments serve fresh assets without waiting for cache expiration. A new deployment changes the filename, which is a cache miss, and Akamai fetches the new version.

API responses: Caching varies by endpoint. Public catalog data is cacheable for minutes to hours. Personalized responses (user profiles, recommendations) are not cached at the CDN layer. We use Cache-Control headers from the origin to communicate caching intent:

Cache-Control: public, max-age=300, s-maxage=600

The s-maxage directive tells Akamai (as a shared cache) to cache for 600 seconds, while browsers cache for 300 seconds. This gives us the ability to serve slightly staler content from the CDN while keeping browser caches fresher.

Dynamic HTML pages: Short TTLs (30 to 60 seconds) or no caching, depending on personalization requirements. Even a 30-second TTL dramatically reduces origin load during traffic spikes, because the majority of requests during that window are served from cache.

Cache Key Design

Akamai's cache key determines which requests are treated as identical for caching purposes. By default, the cache key includes the full URL with query parameters. This means page?sort=date and page?sort=name are cached separately, which is correct. But page?utm_source=twitter and page?utm_source=email are also cached separately, which is wasteful since the response is identical.

We configure Akamai to strip marketing parameters (utm_source, utm_medium, utm_campaign, etc.) from the cache key while preserving them in the origin request. This improves cache hit rates significantly for marketing-heavy pages.

WAF Configuration

The Web Application Firewall runs at the Akamai edge, inspecting requests before they reach our infrastructure. This is important for two reasons: it stops attacks at the edge, closer to the attacker, and it prevents malicious traffic from consuming origin resources.

Our WAF rules cover:

  • SQL injection and XSS: Standard rule sets that inspect query parameters, headers, and request bodies.
  • Rate limiting: Per-IP request rate limits that trigger progressive responses, from CAPTCHA challenges to temporary blocks.
  • Bot management: Distinguishing legitimate bots (search engine crawlers) from malicious bots (scrapers, credential stuffers). Akamai's bot detection uses behavioral analysis, device fingerprinting, and reputation scoring.
  • Geographic restrictions: Blocking or challenging requests from regions where we do not operate, reducing the attack surface.
  • Custom rules: Application-specific rules that protect known-sensitive endpoints, login pages, API keys, administrative interfaces.

WAF tuning is an ongoing process. Rules that are too aggressive block legitimate traffic. Rules that are too permissive let attacks through. We review WAF logs weekly and adjust rules based on observed traffic patterns.

SSL/TLS Architecture

TLS termination happens at the Akamai edge. Users connect to Akamai over TLS, and Akamai connects to our origin over a separate TLS connection. This means we manage two sets of certificates:

  • Edge certificate: The customer-facing certificate for our domain names, managed through Akamai's certificate provisioning system.
  • Origin certificate: The certificate on our ALB, which Akamai validates when connecting to the origin.

We enforce TLS 1.2 as the minimum version at the edge and use strong cipher suites. The origin connection also uses TLS, ensuring encryption in transit for the full request path.

Origin Health and Failover

Akamai monitors origin health and can failover between origin endpoints. We configure multiple origin servers (our ALBs in us-east-1 and us-west-2) with health checks, and Akamai routes to healthy origins automatically.

This provides an additional layer of multi-region failover beyond Route 53. If the us-east-1 ALB becomes unhealthy, Akamai shifts origin requests to us-west-2 without waiting for DNS propagation. The failover is faster because it happens at the CDN layer, where decisions are made per-request rather than per-DNS-TTL.

Performance Optimization

Beyond caching, Akamai provides several performance optimizations:

Connection optimization: Akamai maintains persistent connections to the origin, eliminating the TCP handshake and TLS negotiation overhead for each request. The edge-to-origin path uses optimized routing through Akamai's backbone network, which often provides lower latency than the public internet.

Compression: Akamai compresses responses at the edge, reducing bandwidth and improving load times for users on slower connections.

HTTP/2: Akamai serves content over HTTP/2 to supported browsers, providing multiplexing and header compression. Our origin servers still speak HTTP/1.1, but users get HTTP/2 benefits without infrastructure changes.

Monitoring and Observability

Visibility into CDN behavior is essential. We monitor:

  • Cache hit rates: Target is above 90% for static content, above 60% for cacheable API responses. Drops indicate configuration issues or content changes that affect cacheability.
  • Origin offload: The percentage of requests served from cache versus forwarded to the origin. Higher offload means lower origin cost and better user experience.
  • Error rates by edge region: Identifies geographic performance issues or regional CDN problems.
  • Time to first byte: Measured at the edge and at the origin, showing both CDN performance and origin performance independently.

Akamai's real-time logging streams data to our Splunk instance, giving us unified visibility across the CDN and origin layers.

Lessons Learned

CDN configuration is infrastructure. Treat Akamai property configurations like code. Version them, review them, test them in staging before deploying to production. A bad CDN configuration change can take down your entire web tier.

Cache invalidation is still hard. Purging content from a global CDN takes time, typically 5 to 10 seconds across the entire network. Design your cache strategy so that you rarely need to purge. Content-hashed filenames and short TTLs for volatile content are better than relying on purges.

The CDN is a security boundary. It is the first thing an attacker sees. Invest in WAF rules, bot management, and rate limiting at the edge. Every attack stopped at the CDN is an attack that never reaches your infrastructure.

The CDN layer is often treated as a "set it and forget it" component, but at enterprise scale, it requires the same engineering rigor as any other tier. Get it right, and your users get fast, reliable experiences. Get it wrong, and no amount of origin optimization will save you.

Share: