Statische websites van AWS CloudFront met S3, WAF en Lambda@Edge verhuizen naar Scaleway

forums · 17 maart 2025 om 17:22

Scaleway CDN

Als onderdeel van Invantive versterkt continuïteit: Overstap naar Europese leveranciers voor betere zekerheid en onafhankelijkheid heeft Invantive een groter aantal statische websites verplaatst vanaf Amazon Web Services met CloudFront als CDN met Lambda@Edge, AWS S3 als object storage en AWS WAF naar Scaleway. Al deze websites bevatten uitsluitend publiek toegankelijke data.

Op Scaleway wordt als alternatief voor AWS S3 de zogenaamde “Object Storage” gebruikt. Scaleway biedt sinds korte tijd een productieversie van “Edge Services” als alternatief voor AWS CloudFront. Deze kan per object storage bucket geconfigureerd worden om als CDN op te treden.

Echter, de functionaliteit van Edge Services is relatief beperkt en de meerkosten zijn relatief hoog als het bucketaantal tussen de 10 en 35 buckets ligt (circa EUR 4 per bucket per maand, ook als de bucket maar 1 HTML-bestand bevat).

Beperkingen Edge Services op Scaleway

Komende vanaf AWS CloudFront distributions met Lambda@Edge en AWS WAF vielen de volgende beperkingen op:

Geen ondersteuning ALIAS-record en meerdere namen per Scaleway bucket / CloudFront distribution: een alias zoals acme.com kan wel gemaakt worden in DNS maar wordt niet herkend door Edge Services momenteel. Dit betekent dat maar 1 naam zoals www.acme.com geconfigureerd kan worden per bucket.
Geen opties om verzoeken om te leiden zoals van / naar /index.html of andere redirects.
Geen instelbare foutafhandeling voor bijvoorbeeld 404.
Geen herschrijven van vraag of antwoord zoals cache headers of cookie filtering.
Geen afwijkende gedrag afhankelijk van het soort document of achterliggend systeem, zoals bijvoorbeeld integratie tussen webapplicaties en statische inhoud.
Geen samenstelmogelijkheden om data uit meerdere bronnen te combineren.
Beperkte mogelijkheden voor certificaatbeheer.
Geen alternatief voor AWS WAF (Web Application Firewall) voor bijvoorbeeld het blokkeren van DDoS, verzoeken van ongewenste herkomst, verzoeken van ongewenste bezoekers en web scrapers.

Dit laat niet onverlet dat Edge Services een goede verbetering was van de Scaleway S3-compatible buckets. Edge Services zal ongetwijfeld als het volwassener een beter alternatief voor CloudFront en Lambda@Edge worden.

Voor relatief eenvoudige statistische websites die weinig of geen last hebben van de bovenstaande beperkingen blijft Invantive gebruik maken van Edge Services op Scaleway. Ook dedicated websites met grote downloadvolumes zoals voor binaries blijven op Edge Services; de beperkingen worden geaccepteerd.

Caddy als Alternatief voor Scaleway Edge Services

Gezien de beperkingen is gekeken naar een alternatief voor relatief eenvoudige statische websites. Uiteindelijk is gekozen voor Caddy. Caddy is een relatief eenvoudige en moderne webserver, die op veel platformen werkt en naar verluidt ook gRPC zou ondersteunen.

Er is ook gekeken naar Nginx, Apache en Traefik, maar de moderne mogelijkheden en het configuratiegemak voor het relatief eenvoudige doel gaven de doorslag.

Een bijkomend voordeel van Caddy is dat het voor statische publieke websites zelf zorgt voor de verwerving en vernieuwing van TLS-certificaten.

Meerkosten van egress traffic door beperktere cachewerking zijn niet te verwachten: zowel Scaleway als Stackit brengen momenteel geen ingress of egress transportkosten in rekening. Dit is een aanmerkelijk prijsvoordeel ten opzichte van AWS.

De totale hostingkosten bedrag circa EUR 30 per maand en naar verwachting zal de systeembelasting enkele procenten zijn.

Caddy biedt voor alle bovengenoemde punten een eenvoudige oplossing en draait op Linux met hardware en processoren van Europese herkomst indien nodig.

Caddy Server is geen volledige vervanging voor de mogelijkheden die AWS Lambda met CloudFront biedt, maar als domeinspecifieke oplossing voor websites voldoet het. Bijkomend voordeel van een domeinspecifieke oplossing is ook dat het relatief eenvoudig te configureren en testen is vergeleken met AWS Lambda@Edge.

Beschikbaarheid en Prestaties

De performance zal mogelijk wat minder zijn dan een volwaardige CDN, maar voor de meeste Invantive-websites is sinds de herorientatie op Europa het niet zo relevant meer wat de prestaties in bijvoorbeeld Brazilie zijn.

Ook de uptime zal mogelijk minder zijn omdat load balancing en fail over zelf geregeld moeten worden. Voor websites met relatief lage eisen is dat overkomelijk. Er is gekozen voor een eenvoudige server met 2 ARM64-processoren en 8 GB geheugen, die vanuit software uit een versiebeheeromgeving snel opgetuigd kan worden.

Ook zullen de websites op Caddy eerder gevoelig zijn voor een Distributed Denial of Service-aanval ten opzichte van een CDN beveiligd met AWS WAF. Gezien de beperkte invloed van de statistische websites op de continuiteit van de bedrijfsvoering wordt dit acceptabel geacht.

AWS WAF

Via AWS WAF werden alle AWS CloudFront-distributies ondersteund met onder andere:

Blokkade van bekende ongewenste IP-adressen en bekende kwaadwillende bezoekers.
Blokkade van aantal web crawlers zoals * python, Barkrowler, BLEXBot, ltx71, MegaIndex, MauiBot, MJ12bot, SemrushBot, 360Spider, YandexBot, Cloudfind, dotbot, mailru, hubspot, petalbot, coccoc, DataForSeoBot, YandexBot en Daum.
Blokkade van verkeer van buiten het servicegebied.
Blokkade van bezoekers die veel verzoeken deden in een kort tijdsinterval.
Automatische blokkade van bezoekers die kwaadwillend gedrag en/of intenties laten zien.

In de praktijk werden circa 20% van alle HTTP-verzoeken door AWS WAF geblokkeerd. In de nieuwe situatie voor de statische websites zal dit een lichte verhoging van de load veroorzaken.

Om de beveiligingsrisico’s ook voor statische websites te verlagen draait Caddy in een volledig geisoleerde omgeving. Een kwaadwillende zou bij het verkrijgen van toegang in staat zijn om de geserveerde webinhoud aan te passen. Hiervoor zijn een aantal controlemaatregelen aangebracht die hier verder niet beschreven zullen worden. Ook andere beveiligingsmaatregelen worden hier verder niet beschreven.

Voorbeeldconfiguratie Caddy

Caddy wordt geconfigureerd via een JSON-configuratiebestand. Een pre-processor kan ook een ietwat eenvoudiger tekstformaat hanteren (de zogenaamde Caddyfile). Dit voorbeeld zal zich baseren op dit eenvoudiger tekstformaat.

De Caddyfile begint met een aantal generieke configuratie elementen die in elke site gebruikt (kunnen) worden:

###########################################################################
#
# 1. Global configuration
#
###########################################################################
{
  email info@invantive.eu
  admin off
  grace_period 10s

  servers :443 {
    name theservername
  }
}

#
# 2. Snippet.
# Redirect root to index.html page when imported.
#
(redirectroot) {
  redir / /index.html 301
}

#
# 3. Snippet.
# Rewrite acme.com/something to www.acme.com/something
# when imported.
#
(redirectwww) {
  redir https://www.{host}{uri} permanent
}

Elke website gebruikt de globale configuratie, en kan de snippets zoals (2) en (3) importeren. Bijvoorbeeld de definitie van de website invantive.nl ziet er zo uit:

###########################################################################
#
# 4. invantive.nl
#
###########################################################################

www.invantive.nl
{
  import redirectroot

  reverse_proxy http://invantive.nl.s3.fr-par.scw.cloud {
    header_up Host invantive.nl.s3.fr-par.scw.cloud
    header_down Cache-Control "public,max-age=86400,stale-while-revalidate=172800"
  }
}

invantive.nl
{
  import redirectwww
}

Indien Caddy een verzoek voor https://invantive.nl/onderwerp ontvangt, zal deze als eerste passen bij invantive.nl. Hierin wordt via de definitie van het snippet redirectwww de URL via een permanent redirect (301) omgeschreven naar https://www.invantive.nl/onderwerp.

Het verzoek voor https://www.invantive.nl/onderwerp wordt allereerst indien nodig herschreven naar index.html indien geen onderwerp is opgegeven dankzij het snipper redirectroot.

Vervolgens wordt de URL - na aanpassing van de Host HTTP-header - doorgestuurd naar het Scaleway bucket uit de object storage. Deze is AWS S3-compatible op grote stukken.

Caddy ontvangt van de bucket de data met headers. Voor deze statische website wordt altijd een Cache-Control HTTP-header ingesteld om caching in een eventueel tussenliggend CDN en op het apparatuur van de eindgebruiker mogelijk te maken. Dit vervangt functionaliteit voorheen actief op Lambda@Edge.

Invantive liet in principe de S3-buckets altijd world-readable op AWS en deze aanpak wordt op Scaleway gehandhaafd. Op deze wijze komen informatielekken het snelst naar boven en wordt gebruik vermeden voor objecten met niet-publieke data.

DNS-configuratie

Het is voor zover bekend niet mogelijk om binnen AWS Route 53 een ALIAS DNS-record te gebruiken dat naar buiten AWS wijst. Daarom zal de DNS eerst op een ander platform moeten staan zoals Scaleway DNS.

Binnen Scaleway DNS zijn (naast algemene zaken zoals CAA-records) twee records vereist in DNS om bovenstaande voorbeeldconfiguratie te laten werken:

een ALIAS-record voor invantive.nl dat wijst naar de server waar Caddy op draait, en
een CNAME-record voor www.invantive.nl dat wijst naar de server waar Caddy op draait.