DEV Community: Paul SANTUS

The Flying Squirrel: when the SPIP CMS goes serverless

Paul SANTUS — Tue, 08 Sep 2026 21:51:57 +0000

In the beginning..

The French Web was formless and empty.. a handful of sites (academic ones especially), tied to one another by links and listed in directories.

1996: the first web hosting services, Mygale, then Chez.com. "There was evening, and there was morning. The first day."

1999: As a teenager, I learn PHP. "There was evening, and there was morning. The second day."

2000: The first CMS give non-developers the power to become editors. Drupal, then SPIP. And MySQL databases. Not much content to publish on my side, but I read a lot. I watch sites (many left-wing activist ones like uZine, rezo.net..) pick up the tool. "There was evening, and there was morning. The third day."

2003: WordPress and Dotclear. So easy to write without developing; I set dev aside for a while. "There was evening, and there was morning. The fourth day."

2016: thanks to a few pioneers, I discover the cloud. I am blown away by AWS's ability to summon infrastructure on demand, and by what it lets me offer: highly available, scalable applications. "There was evening, and there was morning..."

And then, all of a sudden.

May 2026, a phone call. "Paul, I want to build an app. But I have one non-negotiable requirement: the backend must run on SPIP."

As often on the projects I support: no infra skills available. And the ambition to ship a consumer-facing application (more on that soon).

With the CMS imposed, how do I:

run it without paying around the clock (including at 3am when there is not a single visitor)?
without maintaining servers?
while keeping up with the load when our app takes off?

Serverless, of course. It remained to be seen whether it would actually work.

On the sixth day, Paul created SPIP-serverless

I discover SPIP, a French free-software CMS, written in PHP and maintained by its community for 26 years. The project's architecture is not exactly modern.. and above all, it is designed to be simple to administer, for non-technical people, to be deployed on a single machine rather than in a distributed compute environment built for high availability: no session handling in a shared cache, in-place upgrades, and so on.

With its need for a persistent local disk and an always-on database, it was not the natural candidate for serverless.

And yet, I am proud to announce today spip-serverless, a port of SPIP onto a 100% serverless architecture. You can put away your shared hosting :)

The project is available on GitHub, under the MIT license. And you can see it in action on this demo site. It will likely be many months before this site costs me a single euro in hosting.

SPIP-serverless: how does it work? The main architecture choices

Here are some of the decisions behind SPIP-serverless:

Compute runs on the Function-as-a-Service AWS Lambda. Running PHP in there is possible thanks to Bref, which gives PHP a real Lambda runtime (FPM). (For the full picture of how PHP fits into AWS serverless, I wrote a series that starts here: How to run PHP on AWS serverless.)
Sessions do not live on the local disk: they go to DynamoDB (on demand).
Uploaded media does not live on the local disk: it goes to S3 (direct presigned uploads from the browser, a stream wrapper, and a small patch so SPIP reads and writes its media on S3).
A CloudFront CDN caches content so it can be served without necessarily running SPIP's code on every request.
Secret keys are generated once and stored in SSM Parameter Store, then reinjected at boot so every environment shares the same keys.

But what about the database? A relational database costs an arm and a leg!

The brick that makes pay-as-you-go real is Aurora DSQL, a serverless Postgres billed for what you use.

A SQL CMS normally forces an always-on database, hence a fixed cost floor; DSQL removes that floor, and connections use short-lived IAM tokens (no stored password).

SPIP usually relies on MySQL, though behind an abstraction layer (I would not call it an ORM ^^), so I had to tinker a bit to get Aurora DSQL working. Fortunately, the community had already done an experimental port to PostgreSQL.

With Lambda and API Gateway per request, DynamoDB on demand, S3 and CloudFront for delivery, an idle site costs almost nothing and wakes up on the first request.

The serverless tradeoffs

The essential tradeoff is in SPIP administration: serverless rests on an immutable-infrastructure paradigm (the container that runs SPIP's code cannot be modified at runtime, and even if it could, it would be destroyed and replaced by another one a few minutes later).

For the editor, nothing changes: content is edited online (database and S3).
But the administrator's tasks (editing templates, deploying plugins, version upgrades) happen through code and continuous integration.

Versioned, reviewed, reproducible: a real modern dev workflow :)

And on the seventh day, Paul @ TerraCloud rested

The code is open source (MIT) and generic: you can deploy your own SPIP the same way.

To get started, visit the github.com/psantus/spip-serverless repository
and browse my demo site

As for me, I will not rest completely:

First, I will be counting your stars on the repo.
Then, I plan to maintain and improve this project based on real needs:
- If something is missing for your use case, open an issue and let's talk.
- If you would like a hand building or deploying your own SPIP-based project, reach out on terracloud.fr or via LinkedIn!

L'écureuil volant : quand le CMS Spip devient serverless

Paul SANTUS — Tue, 08 Sep 2026 21:37:02 +0000

Au commencement..

Le Web français était informe et vide.. quelques sites (universitaires notamment), reliés aux autres par des liens et référencées par des annuaires.

1996 : les premiers services d'hébergement web, Mygale, puis Chez.com. « Il y eut un soir, il y eu un matin. Premier jour »

1999 : Adolescent, j'apprends alors PHP. « Il y eut un soir, il y eu un matin. Deuxième jour »

2000 : Les premiers CMS donnent aux non-développeurs la possibilité de devenir éditeurs. Drupal, puis Spip. Et les bases de données MySQL. Pas trop de contenu à publier de mon côté, mais je lis beaucoup. Je vois des sites (beaucoup militants de gauche comme uZine, rezo.net..) se saisir de l'outil. « Il y eut un soir, il y eu un matin. Troisième jour »

2003 : Wordpress et Dotclear. Tellement facile d'écrire sans développer ; je laisse de côté un temps le dev. « Il y eut un soir, il y eu un matin. Quatrième jour »

2016 : grâce à des précurseurs, je découvre le cloud. Je suis bluffé par la capacité d'AWS de mobiliser de l'infra à la demande, et la possibilité pour moi de proposer des applications hautement disponibles et scalables. « Il y eut un soir, il y eu un matin... »

Et soudain.

Mai 2026, un coup de fil. « Paul, je veux développer une app. Mais j'ai une exigence non-négociable : le backend doit s'appuyer sur SPIP. »

Comme souvent sur les projets que j'accompagne : pas de compétence infra disponible. Et l'ambition de proposer une application grand public (bientôt plus d'info là-dessus).

Le CMS étant imposé, comment

le faire tourner sans payer 24h/24 (y compris à 3h du matin quand il n'y a pas un seul visiteur ?)
sans maintenir de serveurs
en suivant la charge quand notre appli va cartonner ?

Le serverless, bien sûr. Reste à savoir si ça allait marcher.

Le 6e jour, Paul créa SPIP-serverless

Je découvre SPIP, CMS libre français, écrit en PHP et maintenu par sa communauté depuis 26 ans. L'architecture du projet n'est pas moderne, moderne.. et surtout, il est conçu pour être simple d'administration, pour des non-tech, pour être déployé en mode mono-machine et non dans un environnement de calculé distribué pour de la haute dispo : pas de gestion de session dans un cache partagé, upgrade "in-place", etc.

Avec son besoin d'un disque local persistant et d'une base de données toujours allumée, ça n'en faisait pas le candidat naturel pour le serverless.

Et pourtant, je suis fier de vous annoncer aujourd'hui spip-serverless, un port de Spip sur une architecture 100% serverless. Vous pouvez ranger votre hébergement mutu :)

Le projet est disponible sur Github, en licence MIT. Et vous pouvez le voir en action sur ce site de démo. Il se passera sans doute de longs mois avant que ce site me coûte un seul euro en hébergement.

Spip-serverless, comment ça fonctionne ? Les principaux choix d'architecture

Voici quelques-uns des partis pris pour faire Spip-serverless :

Le calcul est hébergé sur le service de Function-as-a-Service AWS Lambda. Faire tourner PHP là-dedans est possible grâce à Bref, qui donne à PHP un vrai runtime Lambda (FPM). (Pour comprendre en détail comment PHP s'intègre au serverless AWS, j'ai écrit une série qui commence ici : How to run PHP on AWS serverless).
Les sessions ne vivent pas sur le disque local : elles vont dans DynamoDB (à la demande).
Les médias uploadés ne vivent pas sur le disque local : ils vont sur S3 (upload présigné direct depuis le navigateur, stream wrapper, et un petit patch pour que SPIP lise et écrive ses médias sur S3).
Un CDN CloudFront permet de mettre en cache les contenus pour les servir sans nécessairement que le code de Spip tourne pour chaque requête.
Les clés secrètes sont générées une fois et rangées dans SSM Parameter Store, puis réinjectées au démarrage pour que chaque environnement partage les mêmes clés.

Mais la base de données ? Une base relationnelle, ça coûte un bras !

La brique qui rend le pay-as-you-go réel, c'est Aurora DSQL, un Postgres serverless facturé à l'usage.

Un CMS SQL impose normalement une base toujours allumée, donc un plancher de coût fixe ; DSQL fait disparaître ce plancher, et les connexions utilisent des jetons IAM éphémères (aucun mot de passe stocké).

Spip s'appuyant habituellement sur MySQL, mais avec une couche d'abstraction (j'appelle pas ça un ORM ^^), j'ai dû un peu bricoler pour qu'Aurora DSQL fonctionne. Heureusement, la communauté avait déjà fait un portage expérimental vers Postgresql.

Avec Lambda et API Gateway à la requête, DynamoDB à la demande, S3 et CloudFront pour la diffusion, un site au repos ne coûte quasiment rien et se réveille à la première requête.

Les compromis du serverless

Le compromis essentiel est dans l'administration de spip : en effet, le serverless repose sur un paradigme d'infra immuable (le conteneur qui exécute le code spip ne peut être modifié au runtime, et, quand bien même, sera détruit et remplacé par un autre quelques minutes après).

Pour l'éditeur, rien ne change : le contenu s'édite en ligne (base et S3)
mais les tâches de l'administrateur (édition de squelettes, déploiement de plugins, montées de version) se fait par le code et l'intégration continue.

Versionné, relu, reproductible : un vrai workflow de dev moderne :)

Et le 7e jour, Paul @ TerraCloud se reposa

Le code est open source (MIT) et générique : tu peux déployer ton propre SPIP de la même façon.

Pour commencer, visitez le dépôt github.com/psantus/spip-serverless
et parcourez mon site de démo

Quant à moi, je ne vais pas complètement me reposer :

Déjà je vais compter vos étoiles sur le repo
Ensuite, je compte maintenir et améliorer ce projet en fonction des besoins réels :
- S'il manque quelque chose pour votre cas d'usage, ouvrez une issue et discutons-en.
- Si vous souhaitez un coup de main pour développer, déployer votre propre projet à base de spip, contactez moi sur terracloud.fr ou via LinkedIn!

Fed up with repeated `aws sso login`? Fix your config!

Paul SANTUS — Tue, 08 Sep 2026 08:09:38 +0000

If you juggle a lot of AWS accounts through IAM Identity Center, you know the ritual. You sit down, run a command, and get slapped with this:

aws: [ERROR]: Error when retrieving token from sso: Token has expired and refresh failed

So you type aws sso login again. And again tomorrow. And again after lunch.

Here's the thing I figured out the hard way: if, just like me, your config file was initiated years ago, then maybe your config is still using the old format. Back then the AWS CLI wrote SSO settings inline into every single profile, and that style never really opted into refresh tokens the way the modern one does. The file kept working, so I never touched it, and I paid for that with a login prompt several times a day.

If you get hit by frequent login requests, most of the time this isn't AWS being annoying. It's either a config that never asks for refresh tokens, or your org making it painful for you. Let's fix both.

The two tokens you need to understand

There isn't a single "session" behind aws sso. There are two tokens, they have very different lifetimes, and almost every "why did I get logged out?" question comes from mixing them up.

Token	Typical validity	Configurable?	What it does
Access token	~8 hours	No (fixed by AWS OIDC)	The short-lived token the CLI presents to get role credentials
Refresh token	Up to your sign-in session duration (max 90 days)	Yes, in Identity Center settings	Silently mints a new access token when the old one expires

The access token expiring is completely normal. It happens roughly every 8 hours and you're not supposed to notice, because the CLI is meant to take the refresh token and quietly exchange it for a new access token behind your back.

If you keep having to log in by hand, it usually comes down to one of three things.

Either your cached session has no refresh token at all, which is a config and scope problem you can fix.
Or your sign-in session duration is short, so the refresh token itself dies overnight.
Or a single refresh just failed for a transient reason, like being offline, behind a VPN, or with the laptop asleep at the wrong moment.

Fix number one: use a shared `sso-session` block

This is the change that matters most. Adopt the modern [sso-session] construct in ~/.aws/config. It's what makes your logins refresh-token capable, and as a bonus it lets one aws sso login cover every profile at once.

Here is the old, painful style, with the SSO settings copied into each profile:

[profile my-account]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start/
sso_region = eu-west-1
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = eu-west-1

Repeating sso_start_url and sso_region in every profile is the legacy token-provider style. It's verbose, it drifts over time, and it doesn't share a refreshable session across profiles.

Here is the modern style, where you declare the session once and point profiles at it:

# Declare the SSO session ONCE. This is the refresh-capable part.
[sso-session sso]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start/
sso_region = eu-west-1
sso_registration_scopes = sso:account:access

[default]
region = us-east-1

[profile account-one]
sso_session = sso
sso_account_id = 111111111111
sso_role_name = AdministratorAccess
region = eu-west-1

[profile account-two]
sso_session = sso
sso_account_id = 222222222222
sso_role_name = AdministratorAccess
region = eu-west-1

A few reasons this is simply better.

One login now covers all your profiles, because aws sso login --profile account-one refreshes the token for everything that references sso_session = sso. The sso_registration_scopes = sso:account:access line is the piece that makes the client registration ask for a refresh grant in the first place; without it you can end up holding only an 8-hour access token with nothing to refresh from, which is exactly the "refresh failed" trap.
You also get a single source of truth, so changing the start URL or region is a one-line edit instead of a find-and-replace across dozens of profiles. The only requirement is AWS CLI v2, which you almost certainly already run.

Assume-role and chained profiles sit happily on top of this. Just point their source_profile at an SSO profile that uses the shared session:

[profile prod-admin]
role_arn = arn:aws:iam::111122223333:role/MyAdminRole
role_session_name = me
source_profile = account-one

Fix number two: raise the sign-in session duration

Even with a perfect config, if your sign-in session duration is stuck at the 8-hour default, the refresh token can't survive the night. That setting is the real ceiling on how long a refresh token stays valid.

It's a console-only, org-wide parameter. There is no public API, CLI, CloudFormation, or Terraform surface for it, so this is one you have to click through yourself. Open the console, go to IAM Identity Center in your instance's home account and region, then Settings, then the Authentication tab, then Session settings, and edit the maximum session duration. You'll see separate values for user interactive sessions, user background sessions, and CLI or tool sessions. The maximum is 90 days.

One warning worth taking seriously: this is an org-wide policy. It affects every user in the Identity Center instance, not just you. Raising it trades a little security posture for a lot fewer logins, so pick a number your security team is comfortable with. Seven days is a common sweet spot, and 90 days is the ceiling. If you want your organisation to raise its duration, be prepared to make a strong case for Security people (mentioning that IDC tokens can be revoked is a good start for a security conversation).

There's a second, different duration that people confuse with this one: the permission set session, which controls how long the assumed-role credentials last (often 12 hours). That one you can read from the CLI:

INSTANCE_ARN=$(aws sso-admin list-instances \
  --query 'Instances[0].InstanceArn' --output text --region eu-west-1)

aws sso-admin describe-permission-set \
  --instance-arn "$INSTANCE_ARN" \
  --permission-set-arn <ps-arn> \
  --query 'PermissionSet.{Name:Name,SessionDuration:SessionDuration}' \
  --region eu-west-1

Just remember it's a different clock. It governs role-credential lifetime, not SSO refresh.

How refresh timing actually works

A common assumption is that you have to refresh "every 8 hours." You don't, and there's no background daemon doing it for you either. Refresh is lazy and on demand. The CLI only refreshes when you run a command that needs credentials. If the access token is still valid it just uses it. If it's expired, it silently swaps the refresh token for a new access token and carries on. And each successful refresh usually rotates the refresh token, sliding the window forward.

In practice that means you should use any profile well within your session ceiling, and daily use is more than enough. During a normal working week you'll basically never type aws sso login. The first command each morning triggers a silent refresh, and everything after it rides the fresh 8-hour access token.

Keeping the token cache tidy

The CLI caches tokens under ~/.aws/sso/cache/. Over the months this fills up with stale files from old client registrations. They rarely cause trouble, but a cluttered cache can occasionally make the CLI match an older registration than you expect. It's safe to remove the expired token files as long as you leave the active one for your current session in place. This snippet shows what's there and when each entry expires, without printing any secrets:

for f in ~/.aws/sso/cache/*.json; do
  python3 -c "import json,sys;
try: d=json.load(open('$f'))
except: sys.exit()
print('$f', '->', d.get('expiresAt'), '| refresh:', 'refreshToken' in d)"
done

To sum up

The access token lasts about 8 hours and you can't change that. The refresh token lasts up to 90 days depending on your Identity Center setting, and that's the one that actually keeps you logged in. Move to a shared [sso-session] block with sso_registration_scopes = sso:account:access so refresh tokens get issued and one login covers everything.

Raise the maximum session duration in IAM Identity Center under Settings and Authentication, remembering it's console-only and org-wide. Don't bother scheduling refreshes, because the CLI renews lazily on your next command and daily use is plenty.

Fix the config once, set a sane session duration, and aws sso login turns into something you type a handful of times a year instead of a handful of times a day.

AWS WAF Challenge: Blocking Bots Before They Reach the Application

Paul SANTUS — Fri, 14 Aug 2026 09:17:29 +0000

When I was called in, the attack had been going on for about a week.

It was targeting the login page of a legacy application that generated its HTML server-side.

Requests numbered in the millions and came from a very large number of IP addresses, which made IP-based blocking largely ineffective. Unlike other campaigns I had encountered, the attacker was also rotating JA3 and JA4 fingerprints. Even rate limiting aggregated on those signals could therefore provide only a partial response.

A few days later, a similar attack targeted a second application belonging to my client. This time, it was no longer the legacy server-side application, but a SPA (single-page application) calling a JSON API to create accounts.

These two incidents gave me the opportunity to use both integration modes offered by AWS WAF Challenge:

the challenge returned directly by WAF for an HTML page;
the challenge solved beforehand by challenge.js, then passed to an API called with fetch.

Why Put the Challenge at the Infrastructure Layer?

If my client called me after seven days, it was because the team had first tried to deal with the attack at the application layer by integrating Cloudflare Turnstile.

The integration was solid. A PrestaShop module managed the keys, global activation, and separate configurations for each tenant. On submission, the application retrieved the token from the form and validated it directly with Cloudflare:

$turnstileToken = Tools::getValue('cf-turnstile-response');

if (empty($turnstileToken)) {
    $turnstileValid = false;
} elseif (!$this->verifyTurnstileToken($turnstileToken)) {
    $turnstileValid = false;
}

Validation then required a server-side call to siteverify:

$response = Tools::file_get_contents(
    'https://challenges.cloudflare.com/turnstile/v0/siteverify',
    false,
    stream_context_create([
        'http' => [
            'method' => 'POST',
            'header' => 'Content-Type: application/x-www-form-urlencoded',
            'content' => http_build_query([
                'secret' => $secretKey,
                'response' => $token,
                'remoteip' => Tools::getRemoteAddr(),
            ]),
            'timeout' => 5,
        ],
    ])
);

This approach worked, but only partially: a significant proportion of the traffic still managed to obtain valid tokens. In particular, we observed tokens generated from a group of Dutch IP addresses and then presented to our infrastructure from Spain. The attacker had therefore industrialized token acquisition and circulation. A token proved that a challenge had been solved, but it was neither a persistent identity nor, in this flow, strictly bound to the IP address that obtained it.

More importantly, this protection had a major drawback: before rejecting a request, the entire chain had to be engaged: the CDN, load balancer, web server, PHP, framework, and our validation code. Even when authentication failed, a significant part of the technical cost had already been incurred. With millions of calls, this affected application performance, although autoscaling limited the impact, as well as the bill.

With a Challenge rule placed in AWS WAF, which the application was already using elsewhere, a request without a valid token is stopped at the edge. It consumes no PHP worker, no database connection, and no application compute capacity. That was exactly what we needed when facing several million requests.

Moving the control also brings a maintenance benefit. Any validation managed by the application necessarily involves code in the form, the controller, secret management, the remote call, and error messages. With a challenge managed by WAF, the backend is not even aware of its existence. It receives only requests that have already passed the check.

The provider of the application-level challenge, Cloudflare versus AWS, is not the point of this comparison. The same distinction would exist with any mechanism validated in the backend. What I want to highlight here, even though I admit I was tired of seeing the developer give in to the “obvious Cloudflare choice” because of its dominant position instead of calling me on the first day of the attack ^^, is the architectural difference between a control managed by the application and one placed at the edge, upstream from the origin.

First Implementation: An Application That Generates Its HTML Server-Side

On the legacy application, authentication uses a native HTML form submitted with POST.

This detail matters. When a user opens an HTML page, the HTTP response becomes a document that the browser must display. AWS WAF can therefore intercept this navigation and respond with its Challenge request. The browser executes the JavaScript provided by AWS WAF, performs the silent proof of work, obtains a token, and the interstitial script then transparently retries the backend request, which WAF now allows through.

In this case, implementing the challenge with AWS WAF is extremely simple.

I started by assigning a label to requests matching the login flow. The challenge rule takes just 15 lines of declarative code, including observability!

rule {
  name     = "ChallengeLoginNoToken"
  priority = 13

  action {
    challenge {}
  }

  statement {
    label_match_statement {
      key   = "login"
      scope = "LABEL"
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "ChallengeLoginNoToken"
    sampled_requests_enabled   = true
  }
}

The login label was assigned by an earlier rule to POST requests targeting /login. This separation between detection and action makes it possible to reuse the same scope for other protections, such as rate limiting by IP address or JA4 fingerprint.

For a server-side site, there is nothing to add to the PHP code. There is no SDK to integrate and no token to validate in the application controller.

This is the simplest configuration: the browser requests a document, WAF can respond with an executable document, and the application is called only after the challenge has been solved.

Implementation 2: AWS WAF Challenge on a SPA

The second application used a SPA, built with React, for its interface and an API hosted on another subdomain.

Account creation conceptually looked like this:

await fetch("https://api.example.com/account-registration", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify(payload),
});

If AWS WAF returns its challenge directly to this request, the response arrives inside fetch. The browser does not interpret it as a new document and does not automatically execute the JavaScript contained in the response. The SPA therefore receives a 202 status, potentially with a body it does not know how to process, and the registration flow fails.

This is a property of the browser execution model, not a limitation specific to AWS. JavaScript returned as data by an XHR or fetch request is not executed spontaneously.

The solution is to reverse the order of operations:

the SPA loads the AWS WAF challenge.js SDK;
the SDK silently solves the challenge within the page;
the SPA retrieves a token;
it attaches that token to the API request;
WAF verifies the token before allowing the request through.

Configuring WAF for a SPA

The Web ACL must first know the domains on which its tokens are valid. In my case, the frontend and API used two subdomains of the same root domain:

resource "aws_wafv2_web_acl" "acl_cloudfront" {
  provider = aws.us-east-1

  name  = "cloudfront-api-acl"
  scope = "CLOUDFRONT"

  token_domains = ["example.com"]

  default_action {
    allow {}
  }

  # ...
}

I then assign a label to POST requests targeting the sensitive endpoint and verify the token with a Challenge action:

rule {
  name     = "ChallengeRegister"
  priority = 15

  action {
    challenge {}
  }

  statement {
    label_match_statement {
      key   = "register"
      scope = "LABEL"
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "ChallengeRegister"
    sampled_requests_enabled   = true
  }
}

Up to this point, the implementation is therefore the same as in V1. However, we need to send a valid token “on the first try,” since we cannot process the challenge synchronously.

The JavaScript SDK URL and secret key to inject into the SPA are provided in the integration section of the AWS WAF console. I inject them into the SPA using an environment variable.

A Small Implementation Detail That Can Become a Blocker

The first version of my loader simply waited for the script's load event. That was not enough. The initial jsapi.js script loads challenge.js in turn, then initializes window.AwsWafIntegration asynchronously.

The first script may therefore have finished loading while getToken() is not yet available. The symptom was particularly misleading: the first submission was sent without a token, which was obtained just a few milliseconds later.

I solved this problem with a bounded wait:

function waitForIntegration(timeoutMs = 3000): Promise<boolean> {
  return new Promise((resolve) => {
    const start = Date.now();

    const tick = () => {
      if (typeof window.AwsWafIntegration?.getToken === "function") {
        resolve(true);
        return;
      }

      if (Date.now() - start >= timeoutMs) {
        resolve(false);
        return;
      }

      window.setTimeout(tick, 50);
    };

    tick();
  });
}

export async function getWafToken(): Promise<string | undefined> {
  await injectWafScript();

  if (!(await waitForIntegration())) {
    return undefined;
  }

  return window.AwsWafIntegration!.getToken();
}

The token is then placed in the header specified by AWS:

export async function register(payload: RegisterPayload) {
  const wafToken = await getWafToken();

  return publicClient.post("/account-registration", payload, {
    headers: {
      "x-aws-waf-token": wafToken,
    },
  });
}

A Second Detail That Can Become a Blocker

In an architecture involving multiple subdomains, CORS must be taken into account, particularly the OPTIONS preflight request, since adding the token makes the request “complex.”

The header must be permitted by the response to the OPTIONS request:

Access-Control-Allow-Headers:
  Authorization,
  Content-Type,
  x-aws-waf-token

This therefore requires a small addition to the CloudFront configuration.

How Much Does This Protection Cost?

Based on the public AWS pricing available in August 2026, the AWS WAF base service is billed at:

$5 per Web ACL per month;
$1 per rule per month;
$0.60 per million requests processed, within the standard WCU allocation.

The Allow, Block, and Count actions do not add a per-action charge. Challenge responses are billed separately at $0.40 per million Challenge responses.

This additional cost remains low, especially if the rule is limited to a few high-value entry points: login, registration, password recovery, order validation, or a sensitive business operation.

The difference compared with the specialized Fraud Control rules is considerable. AWS WAF Account Takeover Prevention and Account Creation Fraud Prevention add a monthly subscription, followed by per-request charges with declining but still high rates. In AWS's public example, 15 million requests analyzed by ATP generate more than $8,000 in Fraud Control charges.

ATP provides much more advanced capabilities. It simply does not address the same economic need. When a targeted Challenge action, rate limiting, and a few network signals are enough, the cost-effectiveness is hard to beat.

In Summary: One Solution, Two Implementations

The first implementation takes 15 lines of Terraform because the browser navigates to an HTML document. AWS WAF can respond directly with the challenge JavaScript.

The second requires a small frontend service because the protected call is made with fetch. The challenge must be executed before the request, and its token must then be passed in a header or cookie.

In both cases, the backend implements no challenge validation. It stores no additional secret key, calls no external service, and consumes no resources for rejected requests.

AWS WAF Challenge is not a replacement for a complete anti-abuse strategy. It does, however, make it possible to move an expensive operation to the right place: before the application.

AWS WAF Challenge : bloquer les bots avant qu’ils n’atteignent l’application

Paul SANTUS — Fri, 14 Aug 2026 09:10:35 +0000

Quand on m’a appelé, l’attaque durait depuis environ une semaine.

Elle visait la page de connexion d’une application historique qui générait son HTML côté serveur.

Les requêtes se comptaient en millions et provenaient d’un très grand nombre d’adresses IP, ce qui rendait un blocage par IP peu efficace. Contrairement à d’autres campagnes que j’avais rencontrées, l’assaillant faisait également tourner ses empreintes JA3 et JA4. Même un rate limiting agrégé sur ces signaux ne pouvait donc apporter qu’une réponse partielle.

Quelques jours plus tard, une attaque similaire a visé une deuxième application chez mon client. Cette fois, il ne s’agissait plus de l’ancienne application server-side, mais d’une SPA (single page app) qui appelait une API JSON pour créer les comptes.

Ces deux incidents m’ont permis d’utiliser les deux modes d’intégration de la fonctionnalité Challenge d’AWS WAF :

le challenge directement renvoyé par le WAF pour une page HTML ;
le challenge résolu en amont par challenge.js, puis transmis à une API appelée avec fetch.

Pourquoi placer le challenge côté infrastructure ?

Si mon client m'a appelé au bout de 7 jours, c'est que l'équipe a d'abord essayé de traiter l'attaque au niveau applicatif, via l'intégration de Cloudflare Turnstile.

L’intégration était sérieuse. Un module PrestaShop gérait les clés, l’activation globale et des configurations distinctes selon le tenant. Lors de la soumission, l’application récupérait le jeton du formulaire et le validait elle-même auprès de Cloudflare :

$turnstileToken = Tools::getValue('cf-turnstile-response');

if (empty($turnstileToken)) {
    $turnstileValid = false;
} elseif (!$this->verifyTurnstileToken($turnstileToken)) {
    $turnstileValid = false;
}

La validation nécessitait ensuite un appel serveur vers siteverify :

$response = Tools::file_get_contents(
    'https://challenges.cloudflare.com/turnstile/v0/siteverify',
    false,
    stream_context_create([
        'http' => [
            'method' => 'POST',
            'header' => 'Content-Type: application/x-www-form-urlencoded',
            'content' => http_build_query([
                'secret' => $secretKey,
                'response' => $token,
                'remoteip' => Tools::getRemoteAddr(),
            ]),
            'timeout' => 5,
        ],
    ])
);

Cette approche fonctionnait, mais seulement partiellement : une proportion significative du trafic obtenait malgré tout des jetons valides. Nous avons notamment observé des jetons générés depuis un groupe d’adresses IP néerlandaises, puis présentés à notre infrastructure depuis l'Espagne : l’attaquant avait donc industrialisé l’acquisition et la circulation des jetons. Le jeton prouvait qu’un challenge avait été résolu, mais il ne constituait ni une identité durable ni, dans ce flux, une liaison stricte avec l’adresse IP qui l’avait obtenu.

Mais surtout, cette protection avait un défaut important : avant de rejeter une requête, il fallait mobiliser tout la chaine : le CDN, le load balancer, le serveur web, PHP, le framework, et notre code de validation : même quand l’authentification échouait, une partie significative du coût technique avait déjà été payée. Et avec des millions d'appels, ça avait un impact sur les performances de l'application (impact limité par l'autoscaling) et sur la facture.

Avec une règle Challenge placée dans AWS WAF (qui était déjà utilisé par ailleurs par l'application), la requête sans jeton valide est arrêtée à la périphérie. Elle ne consomme ni worker PHP, ni connexion à la base de données, ni capacité de calcul applicative. C’était exactement ce dont nous avions besoin face à plusieurs millions de requêtes.

Il y a aussi un bénéfice de maintenance propre au déplacement du contrôle. Toute validation gérée par l’application implique nécessairement du code dans le formulaire, le contrôleur, la gestion des secrets, l’appel distant et les messages d’erreur. Avec un challenge géré par le WAF, le backend ne connaît même pas son existence. Il ne reçoit que les requêtes qui ont déjà passé le contrôle.

Le fournisseur du challenge applicatif (Cloudflare vs AWS) n’est pas le sujet de cette comparaison. La même distinction existerait avec n’importe quel mécanisme validé dans le backend. Ce que je veux relever ici (même si j'avoue avoir été lassé que le dev succombe à l'« évidence Cloudflare » liée à sa position dominante, plutôt que de m'appeler au premier de l'attaque ^^), c'est la différence architecturale entre un contrôle géré par l’application et un contrôle placé à la périphérie, en amont de l’origine.

Première implémentation : une application qui génère son HTML côté serveur

Sur l’application historique, l'authentification se fait par un formulaire HTML natif en POST.

Ce détail est important. Lorsqu’un utilisateur ouvre une page HTML, la réponse HTTP devient un document que le navigateur doit afficher. AWS WAF peut donc intercepter cette navigation et envoyer en réponse sa demande de Challenge. Le navigateur exécute le JavaScript fourni par AWS WAF, réalise le proof of work silencieux, obtient un jeton, puis reprend le script interstitiel relance de façon transparente l'appel au backend, appel que WAF laisse donc passer.

Dans ce cas-là, l'implémentation du challenge par AWS WAF est ultra simple.

J’ai commencé par poser un label sur les requêtes qui correspondaient au parcours de connexion. La règle de challenge tient en 15 lignes de code déclaratif, observabilité comprise !

rule {
  name     = "ChallengeLoginNoToken"
  priority = 13

  action {
    challenge {}
  }

  statement {
    label_match_statement {
      key   = "login"
      scope = "LABEL"
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "ChallengeLoginNoToken"
    sampled_requests_enabled   = true
  }
}

Le label login était attribué par une règle précédente aux requêtes POST portant sur /login (cette séparation entre détection et action permet de réutiliser le même périmètre pour d’autres protections, par exemple une rate limit par IP ou par empreinte JA4).

Dans le cas d’un site server-side, il n’y a rien à ajouter dans le code PHP. Il n’y a pas de SDK à intégrer, pas de jeton à valider dans le contrôleur applicatif.

C’est la configuration la plus simple : le navigateur demande un document, le WAF peut répondre par un document exécutable, et l’application n’est appelée qu’après résolution du challenge.

Implémentation 2 : Challenge AWS WAF sur une SPA

La deuxième application utilisait une SPA (appli React) pour son interface et une API sur un autre sous-domaine.

La création de compte ressemble conceptuellement à ceci :

await fetch("https://api.example.com/account-registration", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify(payload),
});

Si AWS WAF renvoie directement son challenge à cette requête, la réponse arrive dans fetch. Le navigateur ne l’interprète pas comme un nouveau document et n’exécute pas automatiquement le JavaScript contenu dans la réponse. La SPA reçoit donc un statut 202, éventuellement avec un corps qu’elle ne sait pas traiter, et le parcours d’inscription échoue.

C’est une propriété du modèle d’exécution du navigateur, pas une limitation spécifique à AWS. Du JavaScript renvoyé comme donnée par une requête XHR ou fetch n’est pas exécuté spontanément.

La solution consiste à inverser l’ordre des opérations :

la SPA charge le SDK challenge.js d’AWS WAF ;
le SDK résout silencieusement le challenge dans la page ;
la SPA récupère un jeton ;
elle joint ce jeton à la requête API ;
le WAF vérifie le jeton avant de laisser passer la requête.

Configurer le WAF pour une SPA

La Web ACL doit d’abord connaître les domaines sur lesquels ses jetons sont valables. Dans mon cas, le frontend et l’API utilisaient deux sous-domaines du même domaine racine :

resource "aws_wafv2_web_acl" "acl_cloudfront" {
  provider = aws.us-east-1

  name  = "cloudfront-api-acl"
  scope = "CLOUDFRONT"

  token_domains = ["example.com"]

  default_action {
    allow {}
  }

  # ...
}

Je pose ensuite un label sur les requêtes POST vers l’endpoint sensible, puis je vérifie le jeton avec une action Challenge :

rule {
  name     = "ChallengeRegister"
  priority = 15

  action {
    challenge {}
  }

  statement {
    label_match_statement {
      key   = "register"
      scope = "LABEL"
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "ChallengeRegister"
    sampled_requests_enabled   = true
  }
}

On retrouve donc jusqu'ici la même implémentation qu'en v1.. par contre, il nous faut envoyer un token valide "du premier coup" vu qu'on ne saurait pas traiter le challenge de façon synchrone.

L’URL du SDK js et la secret key à injecter dans notre SPA sont fournies dans la section d’intégration de la console AWS WAF. Je l’injecte dans la SPA à partir d’une variable d’environnement.

Un petit détail d'implémentation qui peut être bloquant

La première version de mon chargeur attendait simplement l’événement load du script. Ce n’était pas suffisant. Le script initial jsapi.js charge à son tour challenge.js, puis initialise window.AwsWafIntegration de manière asynchrone.

Le chargement du premier script peut donc être terminé alors que getToken() n’est pas encore disponible. Le symptôme était particulièrement trompeur : le premier submit partait sans jeton, celui-ci étant obtenu quelques milli-secondes plus tard.

J’ai résolu ce problème avec une attente bornée :

function waitForIntegration(timeoutMs = 3000): Promise<boolean> {
  return new Promise((resolve) => {
    const start = Date.now();

    const tick = () => {
      if (typeof window.AwsWafIntegration?.getToken === "function") {
        resolve(true);
        return;
      }

      if (Date.now() - start >= timeoutMs) {
        resolve(false);
        return;
      }

      window.setTimeout(tick, 50);
    };

    tick();
  });
}

export async function getWafToken(): Promise<string | undefined> {
  await injectWafScript();

  if (!(await waitForIntegration())) {
    return undefined;
  }

  return window.AwsWafIntegration!.getToken();
}

Le jeton est ensuite placé dans le header prévu par AWS :

export async function register(payload: RegisterPayload) {
  const wafToken = await getWafToken();

  return publicClient.post("/account-registration", payload, {
    headers: {
      "x-aws-waf-token": wafToken,
    },
  });
}

Deuxième détail qui peut bloquer

Dans une architecture avec plusieurs sous-domaines, il faut penser au CORS (et notamment au preflight OPTIONS puisque l'ajout du token rend la requête 'complexe').

Le header doit être autorisé par la réponse à la requête OPTIONS :

Access-Control-Allow-Headers:
  Authorization,
  Content-Type,
  x-aws-waf-token

Un petit ajout à faire au niveau de la configuration Cloudfront, donc.

Combien coûte cette protection ?

Aux tarifs publics AWS consultés en août 2026, le socle AWS WAF est facturé :

5 dollars par Web ACL et par mois ;
1 dollar par règle et par mois ;
0,60 dollar par million de requêtes traitées, dans l’allocation WCU standard.

Les actions Allow, Block et Count n’ajoutent pas de coût par action. Les réponses Challenge sont facturées séparément, à hauteur de 0,40 dollar par million de réponses Challenge.

Ce coût additionnel reste faible, surtout si la règle est limitée à quelques points d’entrée à forte valeur : connexion, inscription, récupération de mot de passe, validation d’une commande ou opération métier sensible.

La différence avec les règles spécialisées Fraud Control est considérable. AWS WAF Account Takeover Prevention et Account Creation Fraud Prevention ajoutent un abonnement mensuel, puis une facturation par requête analysée avec des tarifs dégressifs mais élevés. Dans l’exemple public d’AWS, 15 millions de requêtes analysées par ATP produisent plus de 8 000 dollars de frais Fraud Control.

ATP apporte des capacités beaucoup plus avancées. Il ne répond simplement pas au même besoin économique. Quand une action Challenge ciblée, un rate limiting et quelques signaux réseau suffisent, le rapport efficacité-prix est difficile à battre.

En résumé : une même solution avec deux implémentations

La première implémentation tient dans 15 liines Terraform parce que le navigateur navigue vers un document HTML. AWS WAF peut lui répondre directement avec le JavaScript du challenge.

La seconde demande un petit service frontend parce que l’appel protégé est réalisé avec fetch. Le challenge doit être exécuté avant la requête, puis son jeton doit être transmis dans un header ou un cookie.

Dans les deux cas, le backend n’implémente aucune validation de challenge. Il ne stocke pas de clé secrète supplémentaire, n’appelle pas un service externe et ne consomme pas de ressources pour les requêtes rejetées.

La fonctionnalité AWS WAF Challenge ne remplace pas une stratégie anti-abus complète. Elle permet en revanche de déplacer une opération coûteuse au bon endroit : avant l’application.

Cloud Native Buildpack for AWS Lambda PHP (Bref) - technical detail

Paul SANTUS — Wed, 29 Jul 2026 22:00:00 +0000

In first post of this series, I introduced my Cloud Native Buildpack for AWS Lambda PHP (Bref).

Here I want to provide some technical details on how it works so far.

Lambda's /var/task problem

CNB places the application at /workspace. Lambda requires it at /var/task. And you can't override LAMBDA_TASK_ROOT, as it's a reserved environment variable.

The buildpack runs as a non-root user during certain CNB phases, so it can't write to /var/task either. The solution is a thin flatten step after the CNB build that copies /workspace to /var/task and restores the Bref entrypoint. This is handled automatically by make lambda.

Is it elegant? Not perfectly. But it works, and the developer never sees it.

Extension installation: three fallback strategies

Bref's extra PHP extensions are published as Docker images (e.g., bref/extra-gd-php-84:3). Each image is a FROM scratch layer containing just the .so file and its dependencies under /opt.

The buildpack uses a three-tier strategy to install extensions:

Method 1: crane. It uses go-containerregistry to pull and extract the extension image directly from Docker Hub, no Docker daemon needed. Works great in CI. However, bref-extra only publishes x86_64 images (ARM64 is not supported by the bref-extra project).

Method 2: docker create + cp. It falls back to the Docker daemon if crane fails. Same limitation: x86 only.

Method 3: Compile from source. When neither method works (ARM deployments), the buildpack compiles extensions from source using the Bref build image's toolchain. This is the same approach used in multi-stage Dockerfiles but automated via build recipes.

The recipes file (lib/extension-recipes.sh) defines how to build each extension: what system packages to install, what configure flags to pass, where to download external source. Currently supports gd, redis, imagick, amqp, soap, ftp, gmp, pgsql, uuid, yaml, mongodb, calendar, and exif.

How bref-extra extensions are built

Looking at the bref-extra repo, each extension uses a two-stage Dockerfile:

FROM bref/build-php-$PHP_VERSION:$BREF_VERSION AS ext
# compile the extension...
RUN cp "$(php-config --extension-dir)/redis.so" /tmp/redis.so
RUN php /bref/lib-copy/copy-dependencies.php /tmp/redis.so /tmp/extension-libs

FROM scratch
COPY --from=ext /tmp/redis.so /opt/bref/extensions/redis.so
COPY --from=ext /tmp/ext.ini /opt/bref/etc/php/conf.d/ext-redis.ini
COPY --from=ext /tmp/extension-libs /opt/lib

The final published image is literally just /opt with the compiled artifacts. That's what crane extracts during our build. And for ARM, our recipes replicate that first stage at build time.

Cloud Native Buildpack for Bref: build your app for Lambda in one command

Paul SANTUS — Tue, 28 Jul 2026 13:29:23 +0000

I've been deploying PHP applications to AWS Lambda with Bref for a while now. Since I'm a Terraform fan, I very quickly parted with @mnapoli's serverless.yml approach, in favour a Terraform + container-based Lambdas.

Here, the Dockerfile approach works, but it's verbose: a typical multi-stage Dockerfile for a Symfony app on Lambda is 100+ lines of repetitive infrastructure code.

Recently, Cloud Native Buildpacks (CNB) caught my attention. Their promise is to turn source code into container images without a Dockerfile, with built-in layer caching and a standardized build/run separation. The question was: could this work for Lambda?

The challenge

Lambda container images have specific requirements that don't align perfectly with the CNB model:

Lambda expects the app at /var/task (a reserved, non-overridable path)
Lambda needs a specific entrypoint (/lambda-entrypoint.sh for Bref)
The CNB lifecycle adds its own launcher binary that Lambda doesn't understand
Bref base images use Amazon Linux with stripped-down package managers

None of these are showstoppers, but they required creative solutions.

What my buildpack does

Given a PHP project with bref/bref in its composer.json, the buildpack handles everything:

Detects the app (composer.json + bref dependency)
Installs PHP extensions (via crane download or from-source compilation)
Runs composer install with production optimizations
Configures OPcache for Lambda cold starts
Detects Symfony and warms the cache
Produces a Lambda-ready container image

The entire configuration is driven by environment variables:

make lambda \
  TEST_APP_PATH=./my-symfony-app \
  LAMBDA_IMAGE=my-app \
  BP_BREF_RUNTIME=fpm \
  BP_BREF_EXTENSIONS=redis,gd,soap \
  BP_OPCACHE_JIT=true

Compare that to 120 lines of multi-stage Dockerfile with extension compilation, vendor optimization, cache warmup, and OPcache tuning.

Testing it for real

I deployed the Symfony Demo application to Lambda using the buildpack. Same app, same database, same environment variables as the existing layer-based deployment. Only change: it's just built with pack build instead of docker build and a long multi-stage Docker file.

It works. The function URL serves the app correctly, Symfony cache is pre-warmed, and the second build reuses all cached layers (vendor, opcache config) making rebuilds near-instant when only application code changes.

I also tested extension compilation: ftp and soap compile successfully from PHP source on ARM64 during the build step, with proper shared library dependency resolution via Bref's copy-dependencies.php.

What's not handled by the buildpack

The buildpack builds your app into a Lambda container image. It does not:

Set up your Symfony app for Bref (you still need BrefKernel, trusted_proxies, etc.)
Serve static assets (CSS/JS need CloudFront + S3, same as any Bref deployment)
Replace your IaC (you still need Terraform/CDK/Serverless to create the Lambda function)

It replaces the Dockerfile and the build process, not the infrastructure or app configuration.

Current state

The buildpack is published and usable today:

GitHub: https://github.com/psantus/bref-buildpack
Docker Hub: psantus/bref-buildpack:0.2.0
CNB Registry: bref/php-lambda (registered at registry.buildpacks.io)
CI: passing on GitHub Actions
Tested: Symfony Demo running on Lambda ARM64 (Graviton) via function URL

It supports PHP 8.2/8.3/8.4, ARM and x86 architectures, extension compilation from source, all 40+ bref-extra extensions (x86) or compile-from-source (ARM), Symfony auto-detection, composer caching, OPcache/JIT configuration, and vendor shrinking.

Try it

brew install buildpacks/tap/pack
git clone https://github.com/psantus/bref-buildpack
cd bref-buildpack
make lambda TEST_APP_PATH=/path/to/your/php/app LAMBDA_IMAGE=my-lambda BP_BREF_EXTENSIONS=gd,redis

The resulting image is ready to push to ECR and deploy to Lambda.

Serverless Lazy Generation: generate once, cache forever with CloudFront origin groups (+ S3 and Lambda)

Paul SANTUS — Sat, 25 Jul 2026 14:14:08 +0000

Sometimes, your business app may have to be ready to serve millions of assets generated from your data (invoice PDFs, text-to-speech audio files, etc.), only a small fraction of which will actually be requested by users.

When such assets generation is expensive, the naive approach - pre-generate every asset - leads to a lot of wasted compute: you generate assets that may never be requested.

Pre-generation may also cause bottlenecks (adding 1,000 new articles means synthesizing 1,000 audio files before they're available), storage bloat (you're paying to store assets that may never see a single request), and staleness (when content changes, you need a pipeline to detect and regenerate affected assets).

What if you could flip this model? Generate assets only when requested, cache them permanently, and never generate the same asset twice.

In this post, I'll walk through a complete serverless architecture that uses CloudFront's native failover mechanism to implement lazy audio generation with Amazon Polly. The same pattern applies to image thumbnails, PDF rendering, video transcoding, or any expensive asset generation.

Architecture Overview: The CloudFront Origin Group Pattern

The key insight is that CloudFront Origin Groups support automatic failover. You configure a primary origin (S3) and a failover origin (API Gateway + Lambda). When the primary returns a 403 or 404, CloudFront transparently routes the request to the failover origin: no client-side retry, no custom logic.

This gives us a clean separation:

Component	Role
S3 (primary origin)	Serves cached audio files. Acts as a permanent cache.
API Gateway + Lambda (failover origin)	Generates audio on-demand when S3 returns 404.
Amazon Polly	Converts text to speech (the expensive operation).
CloudFront	Edge caching + origin failover orchestration.

The beauty is that once Lambda generates an audio file and stores it in S3, all subsequent requests are served directly from S3 (or CloudFront's edge cache). Lambda never executes again for that asset.

How It Works

(full-disclosure: from this point onwards, the post is AI-generated)

First Request (Cache Miss)

Client requests https://d1234.cloudfront.net/audio/welcome.mp3
CloudFront checks its edge cache — miss. Routes to the Origin Group.
S3 (primary origin) returns 404 — the file doesn't exist yet.
CloudFront detects the 404 and fails over to the secondary origin.
API Gateway receives the request and invokes Lambda.
Lambda reads the source text from s3://bucket/texts/welcome.txt.
Lambda calls Amazon Polly to synthesize speech from the text.
Lambda stores the generated MP3 at s3://bucket/audio/welcome.mp3.
Lambda returns the MP3 binary (base64-encoded) with Cache-Control: public, max-age=31536000.
CloudFront caches the response at the edge and returns it to the client.

Second Request (Cache Hit)

Client requests https://d1234.cloudfront.net/audio/welcome.mp3
CloudFront checks its edge cache — hit. Returns immediately.

If the edge cache has expired:

CloudFront routes to the Origin Group.
S3 (primary origin) returns 200 — the file exists.
CloudFront caches and returns the response. Lambda is never invoked.

Key Components

Below I detail the components of the solution I share in my sample GitHub repo. My use case is for Text-to-Speech generation with Polly, but you can adapt it to your own.

CloudFront Origin Group

The Origin Group is the orchestration layer. It defines:

A primary origin (S3 with OAC) for serving cached content
A failover origin (API Gateway) for on-demand generation
Failover criteria: HTTP 403 and 404 status codes

This is infrastructure-level routing — no application code needed to handle caching logic.

S3 as a Permanent Cache

S3 serves dual purpose:

Source storage: Text files live at texts/{filename}.txt
Cache storage: Generated audio lives at audio/{filename}.mp3

The S3 bucket is not publicly accessible. CloudFront accesses it via Origin Access Control (OAC), and Lambda accesses it via IAM role permissions.

Lambda as the Generator

The Lambda function is lean — its only job is:

Read the source text from S3
Call Polly to synthesize audio
Store the result back in S3
Return the audio to the caller

It includes a belt-and-suspenders check: before calling Polly, it verifies the audio doesn't already exist in S3 (handling race conditions where multiple simultaneous first-requests hit Lambda).

Amazon Polly for TTS

Polly provides neural and standard voices for text-to-speech synthesis. In this architecture, we use the standard engine with the Joanna voice and MP3 output format. Polly charges per character synthesized — another reason lazy generation saves money.

Benefits

Zero cold starts for cached content. Once generated, audio is served from S3 or CloudFront's edge — sub-10ms latency worldwide. Lambda cold starts only affect the very first request for each asset.

Infinite scalability. S3 and CloudFront scale to any traffic level without configuration. The generation layer (Lambda) only handles the small fraction of requests that are cache misses.

Pay only for generation once. Each audio file is synthesized exactly once. After that, you're paying only S3 storage ($0.023/GB/month) and CloudFront data transfer.

CloudFront edge caching. Popular content is served from 400+ edge locations worldwide. Your users get sub-50ms response times regardless of where the origin bucket lives.

Zero maintenance. No cron jobs, no batch pipelines, no cache invalidation logic. The system is self-healing — if you delete a cached file, it regenerates on next request.

Cost Analysis

Let's compare pre-generation vs. lazy generation for a platform with 10,000 text articles:

Pre-Generation Approach

Item	Cost
Polly: 10,000 articles × 2,000 chars avg	$16.00 (standard voice)
S3 storage: 10,000 × 500KB avg	$0.12/month
Lambda compute: 10,000 invocations × 5s avg	$0.83
Total upfront	$16.95

You pay this every time content changes and you re-run the batch.

Lazy Generation Approach (assuming 20% of content is ever requested)

Item	Cost
Polly: 2,000 articles × 2,000 chars avg	$3.20
S3 storage: 2,000 × 500KB avg	$0.02/month
Lambda compute: 2,000 invocations × 5s avg	$0.17
CloudFront requests (all 10K articles, cached)	$0.01
Total	$3.40

80% cost reduction — and you never pay for content nobody reads.

Code Walkthrough

Lambda Handler Highlights

import json
import re
import os
import base64
import boto3

s3 = boto3.client("s3")
polly = boto3.client("polly")
BUCKET = os.environ["BUCKET_NAME"]

def handler(event, context):
    path = event.get("path", "")
    match = re.search(r"/audio/(.+)\.mp3$", path)
    if not match:
        return {"statusCode": 400, "body": "Invalid path"}

    filename = match.group(1)

    # Belt-and-suspenders: check if already generated (race condition guard)
    try:
        existing = s3.get_object(Bucket=BUCKET, Key=f"audio/{filename}.mp3")
        audio_bytes = existing["Body"].read()
    except s3.exceptions.NoSuchKey:
        # Read source text
        text_obj = s3.get_object(Bucket=BUCKET, Key=f"texts/{filename}.txt")
        text = text_obj["Body"].read().decode("utf-8")

        # Synthesize with Polly
        response = polly.synthesize_speech(
            Text=text, OutputFormat="mp3",
            VoiceId="Joanna", Engine="standard"
        )
        audio_bytes = response["AudioStream"].read()

        # Cache to S3 (non-fatal if this fails)
        try:
            s3.put_object(
                Bucket=BUCKET, Key=f"audio/{filename}.mp3",
                Body=audio_bytes, ContentType="audio/mpeg"
            )
        except Exception:
            pass  # Audio still returned even if caching fails

    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "audio/mpeg",
            "Cache-Control": "public, max-age=31536000"
        },
        "body": base64.b64encode(audio_bytes).decode("utf-8"),
        "isBase64Encoded": True
    }

Terraform Highlights: Origin Group Configuration

resource "aws_cloudfront_distribution" "cdn" {
  # Primary origin: S3 with OAC
  origin {
    domain_name              = aws_s3_bucket.assets.bucket_regional_domain_name
    origin_id                = "s3-assets"
    origin_access_control_id = aws_cloudfront_origin_access_control.oac.id
  }

  # Failover origin: API Gateway
  origin {
    domain_name = "${aws_api_gateway_rest_api.api.id}.execute-api.us-east-1.amazonaws.com"
    origin_id   = "api-fallback"
    origin_path = "/live"
    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "https-only"
      origin_ssl_protocols   = ["TLSv1.2"]
    }
  }

  # Origin Group: failover on 403/404
  origin_group {
    origin_id = "s3-with-fallback"
    failover_criteria {
      status_codes = [403, 404]
    }
    member { origin_id = "s3-assets" }
    member { origin_id = "api-fallback" }
  }

  # Route /audio/* through the origin group
  ordered_cache_behavior {
    path_pattern     = "/audio/*"
    target_origin_id = "s3-with-fallback"
    # Uses CachingOptimized managed policy
    cache_policy_id  = "658327ea-f89d-4fab-a63d-7e88639e58f6"
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods  = ["GET", "HEAD"]
    cached_methods   = ["GET", "HEAD"]
  }
}

The key is the origin_group block — CloudFront handles all failover logic natively.

Deployment

# Clone the repository
cd serverless-lazy-generation

# Add your text files
echo "Welcome to our platform." > sample-texts/welcome.txt
echo "This is a demo of lazy generation." > sample-texts/demo.txt

# Deploy with Terraform
cd terraform
terraform init
terraform plan
terraform apply

# Note the outputs
# cloudfront_url = "https://d1234abcdef.cloudfront.net"
# sample_audio_url = "https://d1234abcdef.cloudfront.net/audio/welcome.mp3"

Testing

# Get the CloudFront URL from Terraform output
CF_URL=$(terraform -chdir=terraform output -raw cloudfront_url)

# First request — triggers generation (slower, ~2-5 seconds)
time curl -o welcome.mp3 "${CF_URL}/audio/welcome.mp3"

# Second request — served from cache (fast, <100ms)
time curl -o welcome2.mp3 "${CF_URL}/audio/welcome.mp3"

# Verify the files are identical
md5 welcome.mp3 welcome2.mp3

# Check response headers for cache status
curl -I "${CF_URL}/audio/welcome.mp3"
# Look for: X-Cache: Hit from cloudfront

# Request a non-existent text (should return 404)
curl -v "${CF_URL}/audio/nonexistent.mp3"

Extensions: Other Use Cases

The lazy generation pattern isn't limited to audio. Any expensive, deterministic transformation works:

Use Case	Source	Generator	Output
Image thumbnails	Original images in S3	Lambda + Sharp	Resized images
PDF generation	HTML templates + data	Lambda + Puppeteer	PDF documents
Video transcoding	Source video in S3	Lambda + FFmpeg	Transcoded video
Open Graph images	Article metadata	Lambda + Canvas	Social preview images
Map tiles	Vector data	Lambda + Mapbox GL	Raster tiles

For each case, the pattern is identical:

S3 stores the output (acts as cache)
CloudFront Origin Group fails over to Lambda on 404
Lambda generates, caches to S3, and returns
All subsequent requests bypass Lambda entirely

Conclusion

The serverless lazy generation pattern gives you the best of both worlds: the simplicity of static file serving with the flexibility of on-demand generation. CloudFront Origin Groups handle all the routing logic at the infrastructure level — no caching libraries, no invalidation jobs, no state management.

The architecture is:

Self-healing: Delete a cached file, and it regenerates on next request
Cost-efficient: You only pay to generate content that's actually consumed
Globally fast: CloudFront edge caching provides sub-50ms responses worldwide
Zero-ops: No servers to manage, no batch jobs to monitor, no cache to warm

Whether you're building a content platform, an accessibility layer, or a media processing pipeline, this pattern scales from zero to millions of assets with no code changes.

The complete source code — Lambda function, Terraform infrastructure, and sample texts — is available in the repository. Deploy it in under 5 minutes and start generating audio on demand.

Zipping 15Gb of S3 files in 6s. How the power of community made it possible.

Paul SANTUS — Thu, 25 Jun 2026 18:23:01 +0000

In my first article, I showed how parallelizing zip assembly across multiple Lambdas can beat the single-Lambda bandwidth ceiling. I zipped 6.9GB in 35 seconds with just 5 workers.

Since then, Jérémie published a follow-up article where a contributor (Fitz) introduced a brilliant optimization: UploadPartCopy. Instead of downloading (or even streaming) big files through Lambda just to upload them back into the zip, you can tell S3 to copy them server-side. This halves the bandwidth requirement and brought his single-Lambda solution down to 106 seconds.

I took Fitz's UploadPartCopy idea and combined it with my parallel approach. Here's what happened.

What I took from Jérémie and Fitz

The UploadPartCopy insight is elegant: since ZIP STORE mode has deterministic offsets, we know exactly where each file's data lands in the final archive. For big files (≥5MB), we can:

Write just the local file header (50 bytes) in an UploadPart
Have S3 copy the file data directly via UploadPartCopy — no download, no upload, instant

This means workers barely use any memory or bandwidth for big files.

Only issue is that S3 multipart upload API requires all segments (except the last one) to be bigger than 5MB. So the local file header needs to be appended to an another file (or group of files).

My planner Lambda groups small files together until they reach 5MB, appends the LOC header of the next big file, then the worker fires an UploadPartCopy for that big file's data.

When we run out of small files, we stream the smallest remaining big file and pair it with (the LOC header then) a copy of the largest remaining one.

For CRC32 (required in zip headers): files uploaded with modern AWS SDKs already have CRC32 stored as object metadata. A simple HeadObject call retrieves it — no need to read the file.

Step Functions: three limitations

My original architecture used Step Functions to orchestrate workers. Here's what I hit.

1. Inline Map caps at ~40 concurrent iterations

The AWS documentation says the Inline Map state supports "up to 40 concurrent iterations." In practice I saw up to 55, but never more. With 1500 duos to process, Step Functions queued them in batches of 55.

I switched to Distributed Map which launches Express child workflow executions. All 1120 iterations started within 2 seconds. Problem solved? Not quite.

2. Distributed Map: fast to dispatch, slow to collect

With Distributed Map, all workers started within 2 seconds. Every single one finished in under 1 second (mostly UploadPartCopy calls). Total Lambda compute: ~500ms average.

Yet the Map state took 38 seconds to complete.

The bottleneck? Step Functions' internal machinery for collecting and aggregating results from 1120 Express child executions. I confirmed: all workers started at 10:06:52-53, all finished by 10:06:54, but the Map state didn't report success until 10:07:28. 35 seconds of pure orchestration overhead.

3. The 256KB payload limit

Step Functions states can pass at most 256KB between them. With 3000 files:

The planner's assignment list exceeds 256KB → had to write to S3
The aggregated worker results exceed 256KB → had to write CRC32s to S3, read them back in the finalizer

This added complexity and latency (the finalizer reading 1500 small S3 files — 29 seconds sequentially, until I parallelized it down to 1.5s).

After all these fixes, the Step Functions version ran in 41 seconds for 3000 × 5MB files. Respectable — 2.5× faster than Jérémie's 106s — but I knew most of that time was Step Functions overhead, not actual work.

The final version: direct Lambda invocation

I stripped out Step Functions entirely and wrote a single orchestrator Lambda that:

Lists files, computes zip layout (the job of the "planner" Lambda in my StepFunction architecture), and initiates multipart upload (~0.5s)
Invokes all worker Lambdas synchronously in parallel using goroutines + the Lambda SDK (~0.5s to dispatch)
Collects results (workers return inline, no S3 round-trip for parts)
Reads CRC32 files from S3 in parallel, builds central directory, completes multipart upload (~1s)

Orchestrator Lambda (15min timeout, 1024MB)
    │
    ├─── goroutine → Invoke Worker 1 (sync) → return {parts}
    ├─── goroutine → Invoke Worker 2 (sync) → return {parts}
    ├─── ...
    └─── goroutine → Invoke Worker N (sync) → return {parts}
    │
    └─── All done → Build CD → CompleteMultipartUpload

The Lambda SDK's synchronous Invoke blocks until the worker returns. With 200 concurrent goroutines, all workers are dispatched instantly. No orchestration overhead, no state size limits for the parts (only CRC32s go to S3), no 35-second result aggregation.

Now the theoretical time is: orchestration time + time to upload the smallest large file that stays orphan after we pair all large files with groups of small files or single large files

Results: 3000 × 5MB benchmark

Approach	Time	Notes
Jérémie Gen1 (Rust, streaming)	212s	Single Lambda, 512MB
Jérémie Gen2 (Rust, UploadPartCopy)	106s	Single Lambda, 640MB
My Step Functions version	41s	Distributed Map, 1120 workers
My orchestrator Lambda	6s	Direct invoke, ~1500 workers

6 seconds to zip 15GB into a single valid ZIP64 archive. That's a 18× improvement over the optimized single-Lambda approach, and 35× over the original.

Worker stats:

Max memory: 85 MB (I initially allocated 3008MB — massively over-provisioned thanks to UploadPartCopy)
Average duration: 516ms per worker
Max duration: 1035ms

What I learned (round 2)

Step Functions Parallel Map adds seconds, not milliseconds. For latency-sensitive fan-out/fan-in, direct Lambda invocation is faster. Step Functions shines when you need retries, visual debugging, long-running workflows, or error handling, or lightning fast step transition speed. This outstanding performance lasts only until you need more than 40 parallel processes.
UploadPartCopy is the killer optimization. When most files are ≥5MB, workers barely do any work — they just tell S3 to copy data server-side. Memory stays under 100MB regardless of file sizes.
The orchestrator pattern is underrated. A single Lambda with goroutines can invoke hundreds of child Lambdas synchronously, collect results, and finalize — all within one execution context. No state machine, no payload limits between states, no aggregation overhead.
Over-parallelization can hurt. 1500 separate assignments created more Step Functions overhead than the actual compute. Grouping into fewer, larger batches would have been better for the SFN approach.

Try it

Code: github.com/psantus/on-demand-archive-on-s3

The repo has both approaches: Step Functions (cmd/planner + cmd/worker + cmd/finalizer) and the orchestrator Lambda (cmd/orchestrator).

Jérémie's challenge repo: github.com/RustyServerless/demo-s3-archiving

What's next?

The theoretical minimum is bounded by Lambda cold start time (~200ms) plus the slowest UploadPart call (if we lack small files, we may need to upload a large file manually to append another file's LOC to it) plus orchestrator overhead (~500ms).

Your move, Jérémie 😏

Edit: with 73.2Gb (15,000 files), my solutions gives quite acceptable performance. Just 20s (probably due to my 1000 account default concurrency, would likely be faster on an unbounded account :D)

Paul out.

AWS Security Agent: 34 Findings in Under 10 Hours. A Real-World Test

Paul SANTUS — Mon, 08 Jun 2026 12:00:34 +0000

Last week, I ran AWS Security Agent against an app I'm building for a client. The app is quite usual: a React front-end, and the backend is powered by a CMS (that's part of my customer's requirements) on top of which I built a custom API. Both run on Lambda, with DSQL as the database layer and quite a lot of AI inside (more on that below). The results were impressive.

Two scans, overnight

I kicked off both scans in the evening:

Code Review completed in 1h26m:

For this, I had to grant read access to my application Github repository (you can provide write access to get fixes, but that was a step I wasn't ready to take just yet.)
18 findings (9 High, 8 Medium, 1 Low) which covered SQL injection, SSRF, XSS, privilege escalation, secret exposure, IAM misconfigurations
2h42m of agent task time

Penetration Test completed in 7h56m:

The pentest was not a full blackbox test. It started with 3 URLs I provided (the app's front-end, the API and the admin app) but I also submitted the repository.
16 findings (2 Critical, 2 High, 12 Medium)
29.16 hours of agent task time

By the time I woke up, I had a downloadable 60+ page report with reproduction steps, CVSS scores, and suggested fixes. And a pleasant UI to see results summary, but also findings details, test logs, etc.

What impressed me

It thinks like a real Pentester

The agent didn't just scan for known CVEs. It understood my application's architecture and chained vulnerabilities together:

It discovered that some API method had no authentication
It found that the some Lambda code called by a Step Function this method was triggering constructed a URL with user-supplied (non-protected) lang parameter
It crafted a payload using # fragment to redirect requests to an attacker-controlled domain it owned
It verified the SSRF by actually receiving DNS callbacks!!

That's a multi-step attack requiring deep understanding of Python's URL parsing, AWS Step Functions workflow, and the application's data flow from API to Lambda to Wikipedia API.
(I provided the repo )

SQL injection: genuinely clever

The code review found a SQL injection vector I would never have caught manually. Our DSQL driver had a shortcut: if a value starts with CAST(, it's passed through unescaped (intended for internal type conversions). The agent traced the full path from user input (POST /api/my-route body) through the CMS' abstraction layer down to the raw pg_query() call, proving the injection was reachable.

A unexpected category.

I was expecting the Agent to report SSRF, path traversal, etc. One category I didn't expect was "Cost Abuse". Since my app runs on serverless, the Agent also provided valuable insights on path were attackers could make my AWS bill fat, especially via the use of Bedrock, Polly and other AI services.

Findings were validated through exploitation

The penetration test didn't just flag theoretical issues. A bug let the CMS "Installation Wizard" accessible even once install once done. AWS Security Agent

Accessed the install page without auth
Successfully connected to the production database (DSQL with IAM auth meant empty credentials worked)
Enumerated installed plugins with exact version numbers
Documented each step with HTTP requests and responses

Both approaches brought original content

Despite the white box approach, only half of findings were redundant. The code review caught architectural issues (IAM over-privilege due to several Lambdas sharing the same IAM role, hardcoded secrets, missing log retention) while the pentest found runtime exploitables (auth bypass, path traversal, IDOR). Together they covered more ground than either alone.

A word on cost

Warning: AWS Security Agent CAN be expensive (yet cost-effective): at standard pricing of $50/agent-hour, the total would have been:

Code review: 2.7h × $50 = $135
Pentest: 29.2h × $50 = $1,460
Total: ~$1,595

For context, a human pentest engagement of equivalent scope (3 URLs, mixed tech stack, 8 hours of active testing) would probably run $8,000–$20,000 and take 1-2 weeks to deliver results.

But here's the kicker: AWS Security Agent includes a generous free tier. New customers get a 2-month trial with up to 400 pentesting task-hours per month. Both my scans (31.8 task-hours total) fit comfortably within that allowance. So the first real-world security audit of my production application cost me exactly $0.

From Findings to Fixes

The actionable output let me fix all findings within a single day:

SQL injection → removed CAST bypass, added intval() on inputs
SSRF → URL scheme allowlist + private IP blocking
Auth bypass on install page → overlay file blocking access
Path traversal → regex validation on URL path parameters
Task token exposure → stripped from API response
Info disclosure → CloudFront response headers policy removes version headers
Missing logging → API Gateway access logs + 30-day retention

The suggested fixes in the report were specific enough to implement directly, not generic "validate your inputs" advice, but exact code locations and replacement patterns.

A few more things

To be exhaustive, I must share that

it didn't find existing application logic bugs (due to the model being instructed to focus solely on security. Attention is all we need, right?)
due to our white box nature of our pentest, a couple findings, while technically correct, required knowledge of our deployment model to be exploited. If you need to know the value of a secret "consider-i-m-an-admin" header, then maybe the risk is not high.. but again the agent thinks like security folks, and probably considered lateral movement after log access like a possible path.
Some findings are CMS upstream issues that I can't fix without modifying vendor code. I submitted findings to their security team.

Verdict

AWS Security Agent is not a full replacement for security expertise: you still need to understand your architecture to prioritize and fix findings. But as a first pass that runs overnight and produces a professional-grade report? It's remarkably good; literally 0 findings were non-relevant. The multi-step attack chains, the code-level precision, and the actual exploitation validation put it well above traditional SAST/DAST tools.

For a solo developer or small team shipping on AWS, this is a no-brainer at the free tier. Run it before every major release, fix what it finds, and sleep better.

S3 zipper challenge: a parallel zip assembly that beats the single Lambda approach

Paul SANTUS — Mon, 01 Jun 2026 21:27:25 +0000

I recently read Jérémie Rodon's excellent article On-Demand Archives on S3, where he describes an elegant Rust solution for zipping 3,000 × 5MB files from S3 within a single Lambda function.

His approach is impressive: streaming a ZIP archive through a custom Rotating Slab Buffer, saturating bandwidth with concurrent downloads, all within 512MB of RAM. The result: 3 minutes 35 seconds.

I thought it was a good challenge to reach better performance. His article ends with an open invitation: "do you think you can do better with your favorite language?" Well, my favorite language is not Rust nor Go nor.. however, I'm fluent in serverless ;) so I took a different angle entirely.

A Different Approach: Why Not Parallelize the Problem?

Jérémie's constraint was a single Lambda. That's elegant, but it means you're bound by one machine's network bandwidth (~600 Mbps). No matter how perfect your streaming is, physics wins: 15GB at 600 Mbps ≈ 200 seconds minimum.

My question was: what if we break that single-machine bottleneck?

The key insight is that ZIP files in STORE mode (no compression) have deterministic byte offsets. Each entry is exactly 50 + len(filename) + filesize bytes (local header + ZIP64 extra field + data). If you know all filenames and sizes upfront, you can pre-calculate exactly where every file will land in the final archive, before downloading a single byte.

This means independent workers can each build their portion of the zip in parallel, and S3's multipart upload lets them write their chunks independently (parts can be uploaded in any order by different processes sharing the same upload ID).

Architecture

Planner Lambda → Step Functions Distributed Map → N Worker Lambdas → Finalizer Lambda
     │                        │ │ │                        │
     │ CreateMultipartUpload  │ │ │ UploadPart (parallel)  │ CompleteMultipartUpload
     ▼                        ▼ ▼ ▼                        ▼
                         S3 Output Bucket

Planner: Lists all source files, computes zip byte offsets, initiates multipart upload, divides work into balanced batches (equal data volume per worker).
Workers (N concurrent): Each downloads its assigned files, constructs zip local file headers + raw data, computes CRC32 on the fly, streams to S3 as multipart parts.
Finalizer: Builds the central directory with real CRC32 values, uploads it as the final part, calls CompleteMultipartUpload.

Results

With a quota-constrained training account (I had 10 concurrency limit so used only 5 concurrent Lambdas, 3008MB each), zipping 6.9GB across 160 files:

Metric	Single Lambda (Jérémie's Rust)	Parallel (this project)
Approach	Stream within 1 Lambda	Fan-out N workers
Time (15GB, 3000 files)	~215s	Estimated ~10-15s with 100+ workers
Time (6.9GB, 160 files, 5 workers)	-	35s
Memory per worker	512MB	3008MB (could be lower)
Language	Rust 🦀	Go

With a production account (1000 concurrent Lambdas), the 3000 × 5MB scenario would complete in under 15 seconds (each worker handles ~150MB, downloads take ~2s at 600Mbps, upload ~2s). The bottleneck shifts from bandwidth to Lambda cold start (~200ms for Go on ARM64).

Tradeoffs

Jérémie's approach is simpler to deploy (one Lambda, no orchestration) and cheaper per invocation (512MB × 215s vs N × 3008MB × few seconds). It's the right choice when you want minimal infrastructure.

The parallel approach wins on wall-clock time, and dramatically so. It's the right choice when the user is waiting and you want the archive ready in seconds, not minutes.

	Single Lambda	Parallel Fan-Out
Wall-clock time	Bounded by bandwidth	Bounded by slowest worker
Complexity	Low	Medium (Step Functions + 3 Lambdas)
Cost per archive	Lower	Higher (more Lambda-seconds total)
Scalability	Fixed ceiling (~600Mbps)	Linear with concurrency
Memory efficiency	Excellent (512MB)	Good (3GB, could optimize)

If I were to use it in prod, there are plenty of room for optimization (our current Lambda used at most 1875mb, well below our allocated 3Gb, we could use Jérémie's streaming optimizations to cut that to by 10). Yet, we'd probably still have some overhead compared to Jeremie's solutions (cold starts, TLS negociations...) and so far it's just a vanity project :)

What I Learned

ZIP STORE mode is embarrassingly parallel: deterministic offsets mean zero coordination between workers during the data phase.
S3 multipart upload is the perfect primitive: parts uploaded out of order, by different processes, assembled by S3 at the end.
Step Functions Distributed Map is ideal for this pattern: it handles fan-out, concurrency limits, retries, and result collection.
The real bottleneck at scale is Lambda concurrency limits, not bandwidth or compute. With sufficient concurrency, you can zip 15GB in the time it takes to download one 5MB file.

Try It

The code is at github.com/psantus/on-demand-archive-on-s3.

And if you want to try Jérémie's challenge with the single-Lambda constraint, his demo project is at github.com/RustyServerless/demo-s3-archiving.

Both approaches are valid, it just depends on whether you're optimizing for simplicity or speed.

Keep the challenge going?

So, « do you think you can do better with your favorite ~~language~~ architecture?»

And what does "better" even mean for you? :)

Hackez votre AWS CLI pour ajouter le support CloudShell et transformer votre terminal en bastion

Paul SANTUS — Fri, 29 May 2026 12:43:23 +0000

J'utilise AWS CloudShell depuis la Console depuis un moment. C'est pratique : un shell pré-authentifié dans votre navigateur, directement dans la Console AWS. Mais je me suis toujours demandé : pourquoi je ne peux pas l'utiliser depuis mon terminal ? Pourquoi n'y a-t-il pas de commande aws cloudshell ?

Il s'avère que c'est possible. L'API existe, elle n'est simplement pas publique. Et une fois que vous avez accès à CloudShell en CLI, vous pouvez faire des choses intéressantes avec, comme utiliser un CloudShell attaché à un VPC comme bastion pour atteindre vos instances RDS privées.

Consultez le dépôt compagnon en lisant cet article.

CloudShell : une API non documentée

AWS CloudShell n'a pas de support officiel SDK ou CLI. Mais la Console doit bien communiquer avec quelque chose, non ? En regardant ce que fait le navigateur quand vous ouvrez CloudShell, vous pouvez rétro-ingénierer l'API.

Heureusement, Jérôme Guyon a déjà fait ce travail et publié un modèle de service compatible boto3. Son travail a rendu tout cela possible.

L'API est simple : créer des environnements, les démarrer/arrêter, créer des sessions, uploader/télécharger des fichiers. Le mécanisme de session utilise le protocole WebSocket de SSM sous le capot, ce qui signifie que session-manager-plugin (le même binaire qui fait tourner aws ssm start-session) peut se connecter aux sessions CloudShell.

Apprendre un nouveau tour à l'AWS CLI

L'AWS CLI a une fonctionnalité peu connue : aws configure add-model. Donnez-lui un modèle de service JSON, et soudain la CLI connaît un nouveau service. AWS utilise ça en interne pour les previews privées.

(Le modèle boto3 du dépôt de Jérôme a juste besoin d'un champ "version": "2.0" ajouté au niveau racine pour devenir compatible CLI.)

Exécutez :

aws configure add-model \
  --service-model file://cloudshell-cli-model.json \
  --service-name cloudshell

C'est tout. Maintenant j'ai aws cloudshell avec l'auto-complétion et tout :

$ aws cloudshell help

AVAILABLE COMMANDS
       create-environment
       create-session
       delete-environment
       describe-environments
       get-environment-status
       start-environment
       stop-environment
       ...

Se connecter à CloudShell depuis le terminal

Le workflow est simple :

# Créer ou trouver un environnement
aws cloudshell create-environment --region eu-west-1

# Attendre qu'il soit RUNNING
aws cloudshell get-environment-status --environment-id <ID> --region eu-west-1

# Créer une session et se connecter
session-manager-plugin "$(aws cloudshell create-session \
  --environment-id <ID> \
  --session-type TMUX \
  --tab-id "$(uuidgen | tr '[:upper:]' '[:lower:]')" \
  --q-cli-disabled \
  --region eu-west-1 \
  --query '{SessionId:SessionId,TokenValue:TokenValue,StreamUrl:StreamUrl}' \
  --output json)" eu-west-1 StartSession

Et vous y êtes. Un shell complet sur une instance CloudShell, depuis votre terminal. Pas besoin de navigateur.

Le problème des credentials

Il y a un hic. Quand vous utilisez CloudShell depuis la Console, AWS injecte vos credentials automatiquement via un appel API PutCredentials. Celui-ci utilise votre token de session console (l'auth par cookie de votre connexion navigateur) pour alimenter le endpoint de métadonnées du conteneur en credentials temporaires.

Quand vous vous connectez par programme, ça ne se fait pas. Le endpoint de credentials du conteneur renvoie une erreur 500. Vous devez injecter les credentials vous-même :

# Exécutez localement, puis collez la sortie dans votre session CloudShell
aws configure export-credentials --profile my-profile --format env

Pas idéal, mais ça fonctionne.

Le cas d'usage bastion

C'est là que ça devient intéressant. Vous pouvez créer un environnement CloudShell attaché à un VPC :

aws cloudshell create-environment \
  --environment-name db-access \
  --vpc-config '{
    "VpcId": "vpc-abc123",
    "SubnetIds": ["subnet-private-1"],
    "SecurityGroupIds": ["sg-allowed-by-rds"]
  }' \
  --region eu-west-1

Mettez-le dans le même security group que celui autorisé par votre RDS, et soudain vous pouvez vous connecter à votre base de données directement depuis le shell :

mysql -h my-instance.xxx.eu-west-1.rds.amazonaws.com -u admin -p

Pas d'instance EC2 bastion à maintenir. Pas de clés SSH à gérer. Pas de coût horaire quand vous ne l'utilisez pas (CloudShell est gratuit). L'environnement se suspend après 20 minutes d'inactivité et vous pouvez le maintenir en vie avec aws cloudshell send-heart-beat.

Ce qui ne marche pas (et j'ai essayé..)

J'ai passé pas mal de temps à essayer de faire fonctionner CloudShell comme un vrai bastion de port-forwarding, pour pouvoir utiliser des outils locaux comme DBeaver contre un RDS distant à travers lui. Voici ce que j'ai trouvé :

Le port forwarding basé sur SSM ne fonctionne pas.

ECS, par exemple, enregistre les conteneurs comme cibles SSM. Son identifiant SSM n'est pas documenté mais une fois qu'on le connaît, ça marche bien, comme je l'ai décrit dans un précédent article. De cette façon vous pouvez lancer aws ssm start-session --document-name AWS-StartPortForwardingSessionToRemoteHost.
Les notebooks SageMaker ont un comportement similaire.

Les instances/conteneurs CloudShell ne semblent pas être enregistrés comme instances managées SSM. Ou s'ils le sont, c'est caché et à ce jour, personne chez AWS n'a divulgué le format de leur ID :) J'ai essayé toutes les combinaisons d'ID d'environnement, d'ID de session et de format de préfixe auxquelles j'ai pu penser. Aucune ne fonctionne.

Le port forwarding local à travers le PTY ne fonctionne pas non plus. La session est un terminal, pas un flux TCP brut. Vous ne pouvez pas faire passer des données binaires du protocole MySQL à travers. J'ai même essayé de mettre en place un relais ncat à l'intérieur de CloudShell et de tunneler à travers la session. Le relais fonctionne bien en interne, mais il n'y a aucun moyen de l'exposer comme un port TCP local sur votre machine.

Le hole punching UDP est théoriquement possible mais nécessite que le CloudShell ait accès à internet (NAT Gateway sur son subnet), et même là vous vous battez contre des problèmes de symétrie NAT des deux côtés. J'ai réussi à faire fonctionner STUN depuis CloudShell, mais le hole punch complet est fragile et impraticable pour un usage en production.

Alors à quoi ça sert ?

Honnêtement, à pas mal de choses :

Accès rapide à la base de données sans maintenir une instance EC2 bastion. Connectez-vous, exécutez vos requêtes, déconnectez-vous. Gratuit.
Automatisation. Vous pouvez scripter l'exécution de commandes sur CloudShell via Python + session-manager-plugin. Utile pour exécuter des choses à l'intérieur d'un VPC sans déployer une Lambda ou une tâche Fargate.
Débogage de connectivité réseau. Lancez un CloudShell dans une combinaison subnet/SG spécifique et testez ce qui peut atteindre quoi.
Transfert de fichiers (depuis les environnements publics). Les APIs get-file-upload-urls et get-file-download-urls vous donnent des URLs S3 présignées.

La limitation principale est que vous êtes limité à exécuter des commandes à l'intérieur du shell. Vous ne pouvez pas l'utiliser comme un tunnel transparent pour vos outils locaux. Pour ça, vous avez toujours besoin d'une instance EC2 avec l'agent SSM, ou d'une tâche ECS avec execute-command activé.

Essayez vous-même

J'ai publié le modèle et un script d'exemple ici : github.com/psantus/cloudshell-cli

L'installation se fait en une commande. Le tout est un seul fichier JSON qui apprend un nouveau service à votre AWS CLI. Rappelez-vous juste : c'est une API non documentée. AWS peut la modifier ou la casser à tout moment. Ne construisez rien de critique dessus.

Mais pour un accès VPC rapide depuis votre terminal ? C'est plutôt génial.

DEV Community: Paul SANTUS

The Flying Squirrel: when the SPIP CMS goes serverless

In the beginning..

And then, all of a sudden.

On the sixth day, Paul created SPIP-serverless

SPIP-serverless: how does it work? The main architecture choices

But what about the database? A relational database costs an arm and a leg!

The serverless tradeoffs

And on the seventh day, Paul @ TerraCloud rested

L'écureuil volant : quand le CMS Spip devient serverless

Au commencement..

Et soudain.

Le 6e jour, Paul créa SPIP-serverless

Spip-serverless, comment ça fonctionne ? Les principaux choix d'architecture

Mais la base de données ? Une base relationnelle, ça coûte un bras !

Les compromis du serverless

Et le 7e jour, Paul @ TerraCloud se reposa

Fed up with repeated `aws sso login`? Fix your config!

The two tokens you need to understand

Fix number one: use a shared sso-session block

Fix number two: raise the sign-in session duration

How refresh timing actually works

Keeping the token cache tidy

To sum up

AWS WAF Challenge: Blocking Bots Before They Reach the Application

Why Put the Challenge at the Infrastructure Layer?

First Implementation: An Application That Generates Its HTML Server-Side

Implementation 2: AWS WAF Challenge on a SPA

Configuring WAF for a SPA

A Small Implementation Detail That Can Become a Blocker

A Second Detail That Can Become a Blocker

How Much Does This Protection Cost?

In Summary: One Solution, Two Implementations

AWS WAF Challenge : bloquer les bots avant qu’ils n’atteignent l’application

Pourquoi placer le challenge côté infrastructure ?

Première implémentation : une application qui génère son HTML côté serveur

Implémentation 2 : Challenge AWS WAF sur une SPA

Configurer le WAF pour une SPA

Un petit détail d'implémentation qui peut être bloquant

Deuxième détail qui peut bloquer

Combien coûte cette protection ?

En résumé : une même solution avec deux implémentations

Cloud Native Buildpack for AWS Lambda PHP (Bref) - technical detail

Lambda's /var/task problem

Extension installation: three fallback strategies

How bref-extra extensions are built

Cloud Native Buildpack for Bref: build your app for Lambda in one command

The challenge

What my buildpack does

Testing it for real

What's not handled by the buildpack

Current state

Try it

Serverless Lazy Generation: generate once, cache forever with CloudFront origin groups (+ S3 and Lambda)

Architecture Overview: The CloudFront Origin Group Pattern

How It Works

First Request (Cache Miss)

Second Request (Cache Hit)

Key Components

CloudFront Origin Group

S3 as a Permanent Cache

Lambda as the Generator

Amazon Polly for TTS

Benefits

Cost Analysis

Pre-Generation Approach

Lazy Generation Approach (assuming 20% of content is ever requested)

Code Walkthrough

Lambda Handler Highlights

Terraform Highlights: Origin Group Configuration

Deployment

Testing

Extensions: Other Use Cases

Conclusion

Zipping 15Gb of S3 files in 6s. How the power of community made it possible.

What I took from Jérémie and Fitz

Step Functions: three limitations

1. Inline Map caps at ~40 concurrent iterations

2. Distributed Map: fast to dispatch, slow to collect

3. The 256KB payload limit

Fix number one: use a shared `sso-session` block