DEV Community: Paul SANTUS

Spawn a cheap, SSO-Secured, ephemeral AWS Client VPN

Paul SANTUS — Thu, 01 Oct 2026 10:28:12 +0000

Releasing a Terraform module for an ephemeral, SSO-secured AWS Client VPN

Today I'm releasing a Terraform module that spins up an ephemeral, SSO-secured AWS Client VPN endpoint. It costs nothing when nobody's using it, your team logs in with the same corporate identity they already have, and you flip it on from a little web page when you need it.

I built it because I kept running into the same handful of networking problems and I was tired of solving them with always-on boxes and shared secrets (or private PKIs).

The problems it solves

1. Goodbye bastion host

The classic way to reach a private RDS instance, an ElastiCache cluster, or an internal load balancer is to keep a bastion around and SSH through it. That means a box to patch, keys to rotate, and a standing attack surface that sits there whether anyone uses it or not.

Once you're on this VPN you're inside the VPC. You talk to private resources directly, no jump host in the middle, no public database endpoint. When you disconnect, there's nothing left running for someone to poke at.

2. A fixed egress IP out of your VPC

Plenty of third-party APIs still gate access with an IP allow-list. If your traffic leaves AWS from whatever ephemeral address a Lambda or a container happened to get, you can't satisfy that.

With a full tunnel, everything you send exits through your VPC's NAT gateway, so it all appears to come from that one Elastic IP. You give the vendor a single address to allow-list and you're done.

3. Egress from any AWS region

Because you choose which region the VPC lives in, you choose where your traffic appears to come from. That's genuinely useful when you're testing how a service behaves for users in another part of the world, or when you need to reach something that geofilters by country. Stand the module up in eu-west-3 and you look French; stand it up in us-east-1 and you look American. Same setup, different exit door.

How to use it

How it works

The moving parts fit together like this. You open a small single-page app served from CloudFront and S3. You sign in through the Cognito hosted UI, which federates via SAML to IAM Identity Center, so it's your real company login, not a password someone shared in Slack two years ago. Cognito hands back a JWT.

That token lets you call an API Gateway endpoint, which is guarded by a Cognito authorizer. Behind it sits a small Lambda that does one job: when you ask it to turn the VPN on, it associates a subnet with the Client VPN endpoint and adds the default route so your traffic can get out. When you turn it off, it tears the association back down.

The reason this is cheap is the billing model. AWS charges you for the Client VPN endpoint per associated subnet per hour, not for the endpoint merely existing. So the endpoint stays up permanently at no cost, and the one thing that actually bills, the subnet association, only exists while you're using it. An EventBridge rule runs every 15 minutes and checks whether anyone is still connected. If the last reading shows nobody home, it disassociates automatically. Forget to switch it off and it switches itself off for you.

Here's the portal you actually interact with:

You sign in, hit start, wait for the status to go green, then connect your client. When you're done you hit stop, or you just walk away and let the idle check handle it.

Example module configuration

The module is on the Terraform Registry. A minimal call looks like this:

module "vpn" {
  source  = "psantus/ephemeral-vpn/aws"
  version = "~> 1.0"

  region       = "eu-west-3"
  project_name = "acme-vpn"
  app_title    = "ACME VPN"

  # Bring your own VPC with a NAT gateway and a private subnet
  # that routes 0.0.0.0/0 through it.
  vpc_id           = "vpc-0123456789abcdef0"
  target_subnet_id = "subnet-0123456789abcdef0"

  # SSO via IAM Identity Center, federated through Cognito.
  auth_mode = "federated"

  # Metadata XML from your three IDC custom SAML apps
  # (VPN client, self-service portal, Cognito).
  client_saml_metadata_file  = "${path.module}/idc/client.xml"
  portal_saml_metadata_file  = "${path.module}/idc/portal.xml"
  cognito_saml_metadata_file = "${path.module}/idc/cognito.xml"

  cognito_domain_prefix = "acme-vpn"

  # Optional: a pretty URL for the web app.
  dns_hosted_zone_name = "example.com"
  dns_name             = "vpn"
}

You bring a VPC that already has a NAT gateway and a private subnet, plus three IAM Identity Center SAML apps (one for the VPN client, one for the self-service portal, one for Cognito). Drop in their metadata files and apply. The server certificate is generated for you by Terraform, so there's no openssl dance and no private key sitting on your laptop.

Try it

The module is public and ready to use:

Terraform Registry: psantus/ephemeral-vpn/aws
Source: https://github.com/psantus/terraform-aws-ephemeral-vpn

If it saves you from standing up yet another bastion, or from explaining to a vendor why your source IP keeps changing, don't hesitate buy me a coffee ;).

Give it a spin!

aws console : ouvrir la Console AWS depuis le terminal, en une commande

Paul SANTUS — Tue, 22 Sep 2026 08:36:50 +0000

Quand on gère des dizaines de comptes et de rôles AWS, ouvrir la Console est un rituel pénible : retrouver le bon profil, cliquer pour se connecter, recommencer pour changer de compte. J'ai fini par packager le raccourci que j'utilise au quotidien en une commande toute simple :

aws console mon-profil

Regardez-le en action :

Et voilà, la Console s'ouvre dans le navigateur, connectée au bon compte. Ça s'installe en une commande et ça s'utilise comme une sous-commande native de l'AWS CLI.

Installation

Pré-requis : AWS CLI v2, curl, python3, et des profils SSO / assume-role.

curl -fsSL -o aws-console-url.tar.gz \
  https://github.com/psantus/aws-console-url/archive/refs/tags/v1.1.0.tar.gz
tar xzf aws-console-url.tar.gz
cd aws-console-url-1.0.0
./install.sh

L'installeur enregistre deux alias équivalents dans ~/.aws/cli/alias : aws console (court) et aws console-url (explicite).

aws console mon-profil --print   # affiche l'URL au lieu d'ouvrir le navigateur

À l'usage

aws console mon-profil                    # ouvre la console, loué avec le profil correspondant
aws console mon-profil --print            # affiche juste l'URL de connexion
aws console mon-profil --region us-east-1 # force la région d'atterrissage
aws console mon-profil --browser "Safari" # choisir le navigateur

Par défaut, l'URL s'ouvre dans votre navigateur système (macOS, Linux et WSL/Git Bash sous Windows sont gérés). Pour en fixer un :

export AWS_CONSOLE_BROWSER="Google Chrome"

Atterrir directement sur un service

Un deuxième argument (ou --service) vous emmène droit sur la console d'un service, pas seulement la page d'accueil :

aws console mon-profil ec2        # ouvre directement la console EC2
aws console mon-profil s3         # S3 (console globale)
aws console mon-profil lambda     # Lambda dans la bonne région
aws console mon-profil --service rds

La plupart des services suivent /<service>/home ; quelques cas particuliers (s3, iam, route53, billing globaux ; stepfunctions → states) sont gérés automatiquement. Pour tout deep-link exotique, --destination <url> reste disponible.

Le multi-session, gratuitement

La Console AWS permet d'être connecté à jusqu'à 5 comptes simultanément dans le même navigateur. L'outil l'active automatiquement : chaque profil s'ouvre dans sa propre session au lieu d'écraser la précédente.

aws console compte-a    # session A
aws console compte-b    # session B, en parallèle : les deux restent connectées

La première fois, la Console affiche une invite « Enable multi-session » : un clic, une fois par navigateur, et c'est réglé. (--no-multi pour revenir au comportement classique mono-session.)

Le trio d'alias shell : `al` / `ap` / `ac`

Pour aller encore plus vite au quotidien, dans le fichier shell/aws-helpers.sh je fournis trois fonctions à sourcer dans votre ~/.zshrc (ou ~/.bashrc) :

alias	fonction
`al`	login : s'assure qu'une session SSO valide existe (idempotent)
`ap`	profile : positionne le `AWS_PROFILE` ambiant
`ac`	console : ouvre la console (`ac <profile>`, ou juste `ac` après `ap`)

source /chemin/vers/aws-console-url/shell/aws-helpers.sh
export AWS_DEFAULT_SSO_PROFILE="mon-profil-sso"   # optionnel, utilisé par al

Le workflow type devient :

al                 # on s'assure d'être connecté
ap mon-profil      # on choisit un profil
ac                 # on ouvre sa console (utilise $AWS_PROFILE)
ac autre-compte    # ...ou un autre explicitement (multi-session)

ac accepte aussi bien un profil explicite que le $AWS_PROFILE posé par ap, et transmet toutes les options à aws console.

Et pour aller au bout du confort, une complétion zsh (shell/completion.zsh) complète au TAB les noms de profils (lus en direct depuis votre config AWS), les services et les options :

ac de<TAB>            # → dev-readonly  dev-admin  …
ac mon-profil e<TAB>  # → ec2  ecs  ecr  efs  events  …

Comment ça marche ; petit point sécu

Sous le capot, l'outil s'appuie entièrement sur l'AWS CLI et sur le
flow de fédération documenté par AWS :

aws console <profil>
        │
        ├─ aws configure export-credentials  → credentials temporaires (la CLI gère SSO/STS)
        ├─ aws sts get-caller-identity        → ID de compte
        │
        ├─ GET signin.aws.amazon.com/federation?Action=getSigninToken
        └─ open  signin.aws.amazon.com/federation?Action=login&...   (navigateur)

Il ne réinvente rien : c'est l'AWS CLI qui résout les credentials, et l'outil se contente de construire l'URL de connexion à la Console.

Accessoirement, ça en fait un outil 100 % auditable (~150 lignes de bash) qui ne lit jamais votre cache de tokens SSO, ne stocke aucun credential et ne contacte que signin.aws.amazon.com : aucune exfiltration de vos identifiants n'est possible.

C'est open source

Le code est sous licence MIT, sur GitHub. Si l'outil vous fait gagner du
temps, vous pouvez me sponsoriser ☕.

aws console: open the AWS Console from your terminal, in one command

Paul SANTUS — Tue, 22 Sep 2026 08:36:47 +0000

When you manage dozens of AWS accounts and roles, opening the Console is a tedious ritual: find the right profile, click to sign in, start over to switch accounts.

I ended up packaging the shortcut I use every day into a dead-simple command:

aws console my-profile

And that's it: the AWS Console opens in your browser, signed in to the right account.

The tools installs in one command and behaves like a native AWS CLI subcommand. Look at it in action:

Installation

Requirements: AWS CLI v2, curl, python3, and SSO / assume-role profiles.

curl -fsSL -o aws-console-url.tar.gz \
  https://github.com/psantus/aws-console-url/archive/refs/tags/v1.1.0.tar.gz
tar xzf aws-console-url.tar.gz
cd aws-console-url-1.0.0
./install.sh

The installer registers two equivalent aliases in ~/.aws/cli/alias:
aws console (short) and aws console-url (explicit). Verify:

aws console my-profile --print   # print the URL instead of opening the browser

Basic use

aws console my-profile                    # open the account's console
aws console my-profile --print            # just print the sign-in URL
aws console my-profile --region us-east-1 # force the landing region
aws console my-profile --browser "Safari" # pick the browser

By default the URL opens in your system browser (macOS, Linux, and WSL/Git Bash on Windows are supported). To pin one, on macOS:

export AWS_CONSOLE_BROWSER="Google Chrome"

Jump straight to a service

A second argument (or --service) takes you directly to a service's console, not just the home page:

aws console my-profile ec2        # open the EC2 console directly
aws console my-profile s3         # S3 (global console)
aws console my-profile lambda     # Lambda in the right region
aws console my-profile --service rds

Most services resolve to /<service>/home; a few special cases (s3, iam, route53, billing are global; stepfunctions → states) are handled automatically. For any exotic deep-link, --destination <url> is still available.

Multi-session, for free

The AWS Console lets you be signed in to up to 5 accounts simultaneously in the same browser.

The tool enables this automatically: each profile opens in its own session instead of overwriting the previous one.

aws console account-a    # session A
aws console account-b    # session B, in parallel — both stay signed in

The first time, the Console shows an "Enable multi-session" prompt: one click, once per browser, and you're set. (--no-multi to go back to classic single-session behavior.)

BONUS : my personal shell alias trio: `al` / `ap` / `ac`

To move even faster day to day, a shell/aws-helpers.sh file provides three functions to source from your ~/.zshrc (or ~/.bashrc):

alias	shortcut to
`al`	perform aws sso login: ensure a valid SSO session exists idempotent)
`ap`	set profile: set the ambient `AWS_PROFILE`
`ac`	console: open the console (`ac <profile>`, or just `ac` after `ap`)

source /path/to/aws-console-url/shell/aws-helpers.sh
export AWS_DEFAULT_SSO_PROFILE="my-sso-profile"   # optional, used by al

The typical workflow becomes:

al                 # make sure you're logged in
ap my-profile      # pick a profile
ac                 # open its console (uses $AWS_PROFILE)
ac other-account   # ...or a different one explicitly (multi-session)

ac accepts either an explicit profile or the $AWS_PROFILE set by ap, and passes all options through to aws console.

And for maximum comfort, a zsh completion shell/completion.zsh) tab-completes profile names (read live from your AWS config), services and options:

ac de<TAB>            # → dev-readonly  dev-admin  …
ac my-profile e<TAB>  # → ec2  ecs  ecr  efs  events  …

How it works; a note on security

Under the hood, the tool relies entirely on the AWS CLI and on the
AWS federation sign-in flow documented by AWS:

aws console <profile>
        │
        ├─ aws configure export-credentials  → temporary credentials (the CLI handles SSO/STS)
        ├─ aws sts get-caller-identity        → account id
        │
        ├─ GET signin.aws.amazon.com/federation?Action=getSigninToken
        └─ open  signin.aws.amazon.com/federation?Action=login&...   (browser)

It reinvents nothing: the AWS CLI resolves the credentials, and the tool just builds the Console sign-in URL. As a nice side effect, that makes it 100% auditable (~150 lines of bash): it never reads your SSO token cache, never stores any credential, and only ever contacts signin.aws.amazon.com, so there's no room for credentials exfiltration.

It's open source

The code is MIT-licensed, on GitHub. If the tool saves you time, you can sponsor me ☕.

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.

DEV Community: Paul SANTUS

Spawn a cheap, SSO-Secured, ephemeral AWS Client VPN

Releasing a Terraform module for an ephemeral, SSO-secured AWS Client VPN

The problems it solves

1. Goodbye bastion host

2. A fixed egress IP out of your VPC

3. Egress from any AWS region

How to use it

How it works

Example module configuration

Try it

aws console : ouvrir la Console AWS depuis le terminal, en une commande

Installation

À l'usage

Atterrir directement sur un service

Le multi-session, gratuitement

Le trio d'alias shell : al / ap / ac

Comment ça marche ; petit point sécu

C'est open source

aws console: open the AWS Console from your terminal, in one command

Installation

Basic use

Jump straight to a service

Multi-session, for free

BONUS : my personal shell alias trio: al / ap / ac

How it works; a note on security

It's open source

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)

Le trio d'alias shell : `al` / `ap` / `ac`

BONUS : my personal shell alias trio: `al` / `ap` / `ac`

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