Scaleway CDN
As part of Invantive strengthens continuity: Move to European suppliers for better security and independence, Invantive moved a larger number of static websites from Amazon Web Services using CloudFront as CDN with Lambda@Edge, AWS S3 as object storage and AWS WAF to Scaleway. All these websites contain only publicly accessible data.
At Scaleway, the so-called “Object Storage” is used as an alternative to AWS S3. Scaleway has recently offered a production version of “Edge Services” as an alternative to AWS CloudFront. It can be configured per object storage bucket to act as a CDN.
However, the functionality of Edge Services is relatively limited and the additional cost is relatively high if the bucket number is between 10 and 35 buckets (about EUR 4 per bucket per month, even if the bucket contains only 1 HTML file).
Limitations Edge Services on Scaleway.
Coming from AWS CloudFront distributions with Lambda@Edge and AWS WAF, the following limitations stood out:
- No support ALIAS record and multiple names per Scaleway bucket / CloudFront distribution: an alias such as
acme.comcan be created in DNS but is not recognized by Edge Services currently. This means that only 1 name such aswww.acme.comcan be configured per bucket. - No options to redirect requests such as from
/to/index.htmlor other redirects. - No configurable error handling for example 404.
- No rewriting of request or response like cache headers or cookie filtering.
- No different behavior depending on document type or underlying system, such as integration between web applications and static content.
- No composability to combine data from multiple sources.
- Limited certificate management capabilities.
- No alternative to AWS WAF (Web Application Firewall) for e.g. blocking DDoS, requests from unwanted origin, requests from unwanted visitors and web scrapers.
That said, Edge Services was a good improvement on the Scaleway S3-compatible buckets. Edge Services will undoubtedly become a better alternative to CloudFront and Lambda@Edge as it matures.
For relatively simple statistical Web sites that suffer little or no from the above limitations, Invantive will continue to use Edge Services on Scaleway. Dedicated Web sites with large download volumes such as for binaries will also remain on Edge Services; the limitations are accepted.
Caddy as an Alternative to Scaleway Edge Services
Given the limitations, an alternative for relatively simple static Web sites was considered. Ultimately, Caddy was chosen. Caddy is a relatively simple and modern Web server that works on many platforms and is said to also support gRPC.
Nginx, Apache and Traefik were also considered, but its modern capabilities and ease of configuration for its relatively simple purpose were the deciding factors.
An additional advantage of Caddy is that for static public Web sites, it takes care of TLS certificate acquisition and renewal itself.
Additional costs of egress traffic due to more limited caching are not to be expected: both Scaleway and Stackit do not currently charge ingress or egress transport fees. This is a significant price advantage over AWS.
Total hosting costs amount to about EUR 30 per month and system load is expected to be a few percent.
Caddy provides a simple solution for all the above points and runs on Linux with hardware and processors of European origin if needed.
Caddy Server is not a complete replacement for the capabilities offered by AWS Lambda with CloudFront, but as a domain-specific solution for websites it suffices. An additional advantage of a domain-specific solution is also that it is relatively easy to configure and test compared to AWS Lambda@Edge.
Availability and Performance.
The performance will possibly be a bit less than a full-fledged CDN, but for most Invantive websites, since the refocus on Europe, it is not so relevant anymore what the performance is in, say, Brazil.
The uptime may also be less because load balancing and fail over have to be taken care of themselves. For websites with relatively low requirements, this is acceptable. A simple server was chosen with 2 ARM64 processors and 8 GB of memory, which can be quickly set up from software from a version control environment.
Also, the websites on Caddy are more likely to be susceptible to a Distributed Denial of Service attack compared to a CDN secured with AWS WAF. Given the limited impact of statistical websites on business continuity, this is considered acceptable.
AWS WAF
Through AWS WAF, all AWS CloudFront distributions were supported with features including:
- Blocking of known unwanted IP addresses and known malicious visitors.
- Blocking of number of web crawlers such as * python, Barkrowler, BLEXBot, ltx71, MegaIndex, MauiBot, MJ12bot, SemrushBot, 360Spider, YandexBot, Cloudfind, dotbot, mailru, hubspot, petalbot, coccoc, DataForSeoBot, YandexBot and Daum.
- Blocking traffic from outside the service area.
- Blocking of visitors who made many requests in a short time interval.
- Automatic blocking of visitors showing malicious behavior and/or intentions.
In practice, about 20% of all HTTP requests were blocked by AWS WAF. In the new situation for static websites, this will cause a slight increase in load.
To lower security risks also for static websites, Caddy runs in a fully isolated environment. A malicious person, upon gaining access, would be able to modify the web content served. A number of control measures are in place for this, which will not be described further here. Other security measures will also not be described further here.
Sample configuration Caddy
Caddy is configured via a JSON configuration file. A pre-processor can also use a somewhat simpler text format (called Caddyfile). This example will rely on this simpler text format.
The Caddyfile starts with some generic configuration elements that (can) be used in any site:
###########################################################################
#
# 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
}
If Caddy receives a request for https://invantive.nl/onderwerp, it will first fit to invantive.nl. Herein, via the definition of the snippet redirectwww, the URL is rewritten to https://www.invantive.nl/onderwerp via a permanent redirect (301).
The request for https://www.invantive.nl/onderwerp is first rewritten if necessary to index.html if no subject is specified thanks to the snippet redirectroot.
Then the URL - after modifying the Host HTTP header - is forwarded to the Scaleway bucket from the object storage. This is AWS S3-compatible on large chunks.
Caddy receives from the bucket the data with headers. For this static website, a Cache-Control HTTP header is always set to enable caching in any intermediate CDN and on the end user’s equipment. This replaces functionality previously active on Lambda@Edge.
Invantive basically always left S3 buckets world-readable on AWS and this approach is maintained on Scaleway. In this way, information leaks surface fastest and use is avoided for objects with non-public data.
DNS Configuration.
As far as we know, it is not possible to use an ALIAS DNS record within AWS Route 53 that points outside AWS. Therefore, the DNS will first have to be on another platform such as Scaleway DNS.
Within Scaleway DNS (in addition to general things like CAA records), two records are required in DNS for the above example configuration to work:
- an ALIAS record for
invantive.nlthat points to the server that Caddy is running on, and - a CNAME record for
www.invantive.nlthat points to the server that Caddy is running on.