Forem: Paul SANTUS

Remplacez AWS Transfer Family SFTP par S3 Files + Atmoz SFTP

Paul SANTUS — Wed, 08 Apr 2026 08:37:49 +0000

AWS vient de lancer l'une des fonctionnalités de stockage les plus attendues : S3 Files. S3 Files place une interface de système de fichiers compatible EFS directement devant vos buckets S3. Quand j'ai entendu parler de cette fonctionnalité (dans le cadre du programme Community Builders) j'ai tout de suite pensé au cas d'usage du SFTP sur AWS.

Si vous payez actuellement AWS Transfer Family pour donner à vos partenaires un accès SFTP à S3, lisez attentivement ce qui suit. Il existe désormais une alternative nettement moins chère et plus puissante.

Qu'est-ce que S3 Files ?

S3 Files crée un système de fichiers NFS haute performance adossé à un bucket S3. Voyez-le comme une couche EFS qui lit et écrit directement dans les objets S3, avec une synchronisation bidirectionnelle automatique. Tout fichier écrit via le système de fichiers apparaît comme un objet S3, et tout objet uploadé dans S3 devient visible via le système de fichiers.

Les propriétés clés :

Latence sub-milliseconde pour les opérations fichier
Synchronisation automatique entre le système de fichiers et le bucket S3 (via EventBridge sous le capot)
Montable sur ECS Fargate, ECS Managed Instances, EKS et EC2
Protocole NFS standard — pas de client spécial nécessaire côté compute (ECS/EKS le gèrent nativement)
Points d'accès avec contrôle d'identité POSIX (uid/gid)
S3 Versioning requis et exploité pour la cohérence

Le problème avec AWS Transfer Family

AWS Transfer Family est la solution "officielle" pour exposer des endpoints SFTP adossés à S3. Ça fonctionne, mais avec des inconvénients sérieux :

C'est cher

Transfer Family facture 0,30 $/heure rien que pour l'endpoint — soit ~216 $/mois avant même de transférer un seul octet. Ajoutez les coûts de transfert de données par-dessus. Pour un service que beaucoup d'équipes utilisent pour quelques dépôts de fichiers quotidiens, c'est difficile à justifier.

C'est une boîte noire

Vous obtenez un endpoint SFTP, mais vous ne contrôlez pas le serveur. L'authentification personnalisée nécessite des hooks Lambda. Le logging est limité. Vous ne pouvez pas vous connecter en SSH pour débugger. Vous ne pouvez pas personnaliser le comportement du serveur SFTP, ajouter des scripts de pré/post-traitement, ou exécuter quoi que ce soit à côté.

La nouvelle architecture : atmoz/sftp + S3 Files sur ECS Fargate

Voici ce que nous allons mettre en place :

Les composants :

Bucket S3 avec versioning activé (requis par S3 Files)
Système de fichiers S3 Files pointant vers le bucket, avec des mount targets dans votre VPC
Volume EFS pour les clés SSH persistantes (empreinte stable entre les redémarrages et le scaling)
Service ECS Fargate exécutant atmoz/sftp avec le volume S3 Files monté sur /home
Network Load Balancer exposant le port 22
Enregistrement DNS pour sftp.votredomaine.com (optionnel)

Les fichiers uploadés via SFTP atterrissent sur le montage S3 Files → apparaissent dans S3 en quelques secondes → déclenchent les notifications S3 pour le traitement en aval.

Comparaison des coûts

Composant	Transfer Family	S3 Files + Fargate
Coût de base	0,30 $/h (~216 $/mois)	NLB : ~16 $/mois
Compute	Inclus	Fargate 0.25 vCPU / 512 Mo : ~9 $/mois
Stockage	Tarification S3	Tarification S3 (identique)
Transfert de données	0,04 $/Go via SFTP	Tarification NLB standard
Minimum mensuel	~216 $	~25 $

C'est environ 8 fois moins cher au niveau de base. Pour les cas d'usage SFTP à trafic faible à moyen (c'est-à-dire la majorité), les économies sont significatives.

Pourquoi c'est mieux que du SFTP sur EFS

Avant S3 Files, l'approche DIY classique consistait à monter EFS sur Fargate et faire tourner atmoz/sftp. C'est exactement ce que nous faisions. Ça marchait, mais avec une limitation fondamentale : vos fichiers vivaient dans EFS, pas dans S3.

Ça signifiait :

Pas de notifications S3 à l'arrivée des fichiers
Pas de politiques de cycle de vie S3
Pas de réplication cross-region S3
Pas d'accès direct aux fichiers via l'API S3
Tarification EFS (0,30 $/Go pour Standard) vs S3 (0,023 $/Go)
Stratégie de backup séparée nécessaire

Avec S3 Files, les données vivent dans S3. Vous bénéficiez de tout l'écosystème S3 — notifications, règles de cycle de vie, réplication, analytics, tiering Glacier — tout en ayant un système de fichiers montable pour votre serveur SFTP.

Traitement événementiel des fichiers

Transfer Family et notre approche S3 Files écrivent tous deux dans S3, donc vous obtenez les mêmes capacités événementielles dans les deux cas :

Notifications S3 → SQS/SNS/Lambda pour un traitement immédiat à l'arrivée d'un fichier
Notifications S3 → EventBridge pour des règles de routage complexes
S3 Inventory pour l'audit
S3 Object Lock pour la conformité
S3 Replication pour répliquer les fichiers uploadés vers une autre région ou un autre compte

La différence n'est pas dans les fonctionnalités — c'est dans le coût. Vous obtenez exactement le même pipeline événementiel S3 pour ~25 $/mois au lieu de ~216 $/mois.

L'implémentation Terraform

Comme aws_s3files_file_system n'est pas encore dans le provider Terraform AWS (PR #47325 ouverte et priorisée), nous gérons les ressources S3 Files via terraform_data avec des provisioners local-exec appelant l'AWS CLI.

Les ressources clés :

# Système de fichiers S3 Files — créé via AWS CLI
resource "terraform_data" "s3files_file_system" {
  provisioner "local-exec" {
    command = <<-EOT
      aws s3files create-file-system \
        --bucket "$BUCKET_ARN" \
        --role-arn "$ROLE_ARN" \
        --accept-bucket-warning \
        --region "$REGION"
    EOT
  }
}

# Mount targets dans chaque sous-réseau privé
resource "terraform_data" "s3files_mount_targets" {
  for_each = toset(var.private_subnet_ids)
  provisioner "local-exec" {
    command = <<-EOT
      aws s3files create-mount-target \
        --file-system-id "$FS_ID" \
        --subnet-id "${each.value}" \
        --security-groups "$SG_ID"
    EOT
  }
}

# La task definition ECS utilise s3filesVolumeConfiguration
volume = {
  sftp-home = {
    s3files_volume_configuration = {
      file_system_arn = local.s3files_fs_arn
      root_directory  = "/"
    }
  }
}

Le code Terraform complet est disponible en tant que module Terraform. Le provider Terraform AWS ne supporte pas encore aws_s3files_file_system (PR #47325 ouverte et priorisée), donc les ressources S3 Files sont actuellement gérées via terraform_data + AWS CLI. Je m'engage à mettre à jour ce module pour utiliser les ressources Terraform natives dès que le provider intégrera le support S3 Files.

Configuration IAM

Deux rôles IAM sont nécessaires :

Rôle de service S3 Files — assumé par elasticfilesystem.amazonaws.com pour synchroniser entre le système de fichiers et le bucket S3. Nécessite un accès S3 en lecture/écriture sur le bucket + des permissions EventBridge pour la détection des changements.
Rôle de tâche ECS — nécessite s3files:ClientMount, s3files:ClientWrite, et s3:GetObject/s3:ListBucket sur le bucket pour des lectures optimisées.

Quand Transfer Family reste pertinent

Pour être honnête, Transfer Family n'est pas mort pour tous les cas d'usage :

Gestion managée des clés SFTP et des utilisateurs — Transfer Family intègre nativement des fournisseurs d'identité (AD, authentification Lambda custom). Avec atmoz/sftp, vous gérez les utilisateurs via la configuration.
Support du protocole AS2 — si vous avez besoin d'AS2, Transfer Family reste la seule option managée.
FTPS — Transfer Family supporte FTPS nativement.
Tolérance zéro aux opérations — si vous ne pouvez vraiment pas gérer un conteneur, Transfer Family est entièrement managé.

Mais pour la grande majorité des cas d'usage SFTP — des partenaires qui déposent des fichiers à traiter — l'approche S3 Files est moins chère, plus flexible, et offre une meilleure observabilité.

Pour démarrer

Prérequis : Les commandes aws s3files nécessitent AWS CLI v2.34.26 ou ultérieur. Vous avez également besoin de jq (utilisé par les scripts des provisioners Terraform). Mettez à jour la CLI avec brew upgrade awscli ou consultez le guide d'installation AWS CLI.

Créer un bucket S3 avec le versioning activé
Créer un rôle IAM pour S3 Files avec les politiques de confiance et de permissions requises
Créer un système de fichiers S3 Files via la console ou aws s3files create-file-system
Créer des mount targets dans vos sous-réseaux VPC
Créer un EFS pour les clés SSH persistantes
Déployer un service ECS Fargate avec atmoz/sftp, en montant S3 Files sur /home et EFS sur /etc/ssh/
Placer un NLB devant, pointer votre DNS dessus
Configurer les notifications S3 sur le bucket pour le traitement en aval

Ou utilisez simplement le module Terraform — le tout se déploie en moins de 10 minutes.

Test de bout en bout

Après terraform apply, le serveur SFTP est prêt en environ 8 minutes (l'essentiel du temps est consacré à la mise à disposition des mount targets S3 Files). Voici un test rapide :

# Upload d'un fichier
echo "Hello from S3 Files SFTP!" > test.txt
sshpass -p demo sftp -o StrictHostKeyChecking=no -P 22 demo@<sftp_endpoint> <<EOF
cd upload
put test.txt
bye
EOF

# Vérifier qu'il est arrivé dans S3 (attendre ~30-60s pour la synchro)
aws s3 cp s3://<sftp_bucket_name>/demo/upload/test.txt -
# Output: Hello from S3 Files SFTP!

Nous avons également vérifié que les clés SSH persistent entre les redémarrages de tâches — l'empreinte du serveur reste identique après un redéploiement forcé, grâce au volume EFS monté sur /etc/ssh/.

Conclusion

S3 Files comble le fossé entre système de fichiers et stockage objet d'une manière qui rend beaucoup de services AWS coûteux redondants. Pour le SFTP en particulier, la combinaison atmoz/sftp + S3 Files sur Fargate vous offre :

~8x moins cher que Transfer Family
Contrôle total sur le serveur SFTP
Notifications S3 natives pour le traitement événementiel
S3 comme source de vérité — règles de cycle de vie, réplication, analytics fonctionnent
Infrastructure as Code avec Terraform (même avant le support natif du provider)

L'époque où il fallait payer 216 $/mois minimum pour un endpoint SFTP managé est révolue pour la plupart des équipes. S3 Files est la pièce manquante qui rend le SFTP DIY sur AWS non seulement viable, mais ~8x moins cher.

AWS S3 Files just made Transfer Family SFTP obsolete for most use cases

Paul SANTUS — Wed, 08 Apr 2026 08:15:29 +0000

AWS just launched one of the most impactful storage features in years: S3 Files. It puts an EFS-compatible file system interface directly in front of your S3 buckets. When I was introduced to S3 Files (as part of AWS Community Builder program), I immediately thought of SFTP as the most obvious use case for my clients.

If you're currently paying for AWS Transfer Family to give your partners SFTP access to S3, you should read this carefully. There's now a dramatically cheaper and more powerful alternative.

What is S3 Files?

S3 Files creates a high-performance NFS file system backed by an S3 bucket. Think of it as an EFS-like layer that reads and writes directly to S3 objects, with automatic bidirectional synchronization. Any file written through the file system appears as an S3 object, and any object uploaded to S3 becomes visible through the file system.

The key properties:

Sub-millisecond latency for file operations
Automatic sync between file system and S3 bucket (powered by EventBridge under the hood)
Mountable on ECS Fargate, ECS Managed Instances, EKS, and EC2
Standard NFS protocol — no special client needed on the compute side (ECS/EKS handle it natively)
Access points with POSIX user/group enforcement
S3 Versioning required and leveraged for consistency

The Problem with AWS Transfer Family

AWS Transfer Family has been the "official" way to expose SFTP endpoints backed by S3. It works, but it comes with serious pain points:

It's expensive

Transfer Family charges $0.30/hour just for the endpoint — that's ~$216/month before you transfer a single byte. Add data transfer costs on top. For a service that many teams use for a handful of daily file drops, this is hard to justify.

It's a black box

You get an SFTP endpoint, but you don't control the server. Custom authentication requires Lambda hooks. Logging is limited. You can't SSH in to debug. You can't customize the SFTP server behavior, add pre/post-processing scripts, or run anything alongside it.

The New Architecture: atmoz/sftp + S3 Files on ECS Fargate

Here's what you could run instead:

The components:

S3 bucket with versioning enabled (required by S3 Files)
S3 Files file system pointed at the bucket, with mount targets in your VPC
EFS volume for persistent SSH host keys (stable fingerprint across restarts and scaling)
ECS Fargate service running atmoz/sftp with the S3 Files volume mounted at /home
Network Load Balancer exposing port 22
DNS record for sftp.yourdomain.com (optional)

Files uploaded via SFTP land on the S3 Files mount → appear in S3 within seconds → trigger S3 event notifications for downstream processing.

Cost Comparison

Component	Transfer Family	S3 Files + Fargate
Base cost	$0.30/hr (~$216/mo)	NLB: ~$16/mo
Compute	Included	Fargate 0.25 vCPU / 512MB: ~$9/mo
Storage	S3 pricing	S3 pricing (same)
Data transfer	$0.04/GB over SFTP	Standard NLB pricing
Monthly minimum	~$216	~$25

That's roughly 8x cheaper at the base level. For low-to-medium traffic SFTP use cases (which is most of them), the savings are significant.

Why This Is Better Than EFS-Backed SFTP

Before S3 Files, the common DIY approach was to mount EFS on Fargate and run atmoz/sftp. We did exactly this. It worked, but had a fundamental limitation: your files lived in EFS, not S3.

That meant:

No S3 event notifications when files arrived
No S3 lifecycle policies
No S3 cross-region replication
No direct S3 API access to the files
EFS pricing ($0.30/GB for Standard) vs S3 ($0.023/GB)
Separate backup strategy needed

With S3 Files, the data lives in S3. You get the full S3 feature set — notifications, lifecycle rules, replication, analytics, Glacier tiering — while still having a mountable file system for your SFTP server.

Event-Driven File Processing

Both Transfer Family and our S3 Files approach write to S3, so you get the same event-driven capabilities either way:

S3 Event Notifications → SQS/SNS/Lambda for immediate processing when a file arrives
S3 Event Notifications → EventBridge for complex routing rules
S3 Inventory for auditing
S3 Object Lock for compliance
S3 Replication to replicate uploaded files to another region or account

The difference isn't in features — it's in cost. You get the exact same S3 event-driven pipeline for ~$25/mo instead of ~$216/mo.

The Terraform Implementation

Since aws_s3files_file_system isn't in the Terraform AWS provider yet (PR #47325 is open and prioritized), we manage S3 Files resources through terraform_data with local-exec provisioners calling the AWS CLI.

The key resources:

# S3 Files file system — created via AWS CLI
resource "terraform_data" "s3files_file_system" {
  provisioner "local-exec" {
    command = <<-EOT
      aws s3files create-file-system \
        --bucket "$BUCKET_ARN" \
        --role-arn "$ROLE_ARN" \
        --accept-bucket-warning \
        --region "$REGION"
    EOT
  }
}

# Mount targets in each private subnet
resource "terraform_data" "s3files_mount_targets" {
  for_each = toset(var.private_subnet_ids)
  provisioner "local-exec" {
    command = <<-EOT
      aws s3files create-mount-target \
        --file-system-id "$FS_ID" \
        --subnet-id "${each.value}" \
        --security-groups "$SG_ID"
    EOT
  }
}

# ECS task definition uses s3filesVolumeConfiguration
volume = {
  sftp-home = {
    s3files_volume_configuration = {
      file_system_arn = local.s3files_fs_arn
      root_directory  = "/"
    }
  }
}

The full working Terraform code is available as a Terraform module. The Terraform AWS provider doesn't support aws_s3files_file_system yet (PR #47325 is open and prioritized), so S3 Files resources are currently managed via terraform_data + AWS CLI. I pledge to update this module to use native Terraform resources as soon as the provider ships S3 Files support.

IAM Setup

Two IAM roles are needed:

S3 Files service role — assumed by elasticfilesystem.amazonaws.com to sync between the file system and S3 bucket. Needs S3 read/write on the bucket + EventBridge permissions for change detection.
ECS task role — needs s3files:ClientMount, s3files:ClientWrite, and s3:GetObject/s3:ListBucket on the backing bucket for optimized reads.

When Transfer Family Still Makes Sense

To be fair, Transfer Family isn't dead for every use case:

Managed SFTP keys and user management — Transfer Family has built-in identity provider integration (AD, Lambda custom auth). With atmoz/sftp, you manage users via config.
AS2 protocol support — if you need AS2, Transfer Family is still the only managed option.
FTPS — Transfer Family supports FTPS natively.
Zero ops tolerance — if you truly cannot manage a container, Transfer Family is fully managed.

But for the vast majority of SFTP use cases — partners dropping files that need processing — the S3 Files approach is cheaper, more flexible, and gives you better observability.

Getting Started

Prerequisite: The aws s3files commands require AWS CLI v2.34.26 or later. You also need jq installed (used by the Terraform provisioner scripts). Update the CLI with brew upgrade awscli or see AWS CLI install guide.

Create an S3 bucket with versioning enabled
Create an IAM role for S3 Files with the required trust and permissions policies
Create an S3 Files file system via the console or aws s3files create-file-system
Create mount targets in your VPC subnets
Create an EFS for persistent SSH host keys
Deploy an ECS Fargate service with atmoz/sftp, mounting S3 Files at /home and EFS at /etc/ssh/
Put an NLB in front, point your DNS at it
Set up S3 event notifications on the bucket for downstream processing

Or just use the Terraform module — the whole thing deploys in under 10 minutes.

Testing it end-to-end

After terraform apply, the SFTP server is ready in about 8 minutes (most of the time is S3 Files mount targets becoming available). Here's a quick test:

# Upload a file
echo "Hello from S3 Files SFTP!" > test.txt
sshpass -p demo sftp -o StrictHostKeyChecking=no -P 22 demo@<sftp_endpoint> <<EOF
cd upload
put test.txt
bye
EOF

# Verify it landed in S3 (wait ~30-60s for sync)
aws s3 cp s3://<sftp_bucket_name>/demo/upload/test.txt -
# Output: Hello from S3 Files SFTP!

We also verified that SSH host keys persist across task restarts — the server fingerprint stays the same after a forced redeployment, thanks to the EFS volume mounted at /etc/ssh/.

Conclusion

S3 Files bridges the gap between file system and object storage in a way that makes a lot of expensive AWS services feel redundant. For SFTP specifically, the combination of atmoz/sftp + S3 Files on Fargate gives you:

~8x lower cost than Transfer Family
Full control over the SFTP server
Native S3 event notifications for event-driven processing
S3 as the source of truth — lifecycle rules, replication, analytics all work
Infrastructure as Code with Terraform (even before native provider support)

The days of paying $216/month minimum for a managed SFTP endpoint are over for most teams. S3 Files is the missing piece that makes DIY SFTP on AWS not just viable, but ~8x cheaper.

Agents Bedrock AgentCore en mode VPC : attention aux coûts de NAT Gateway !

Paul SANTUS — Sat, 04 Apr 2026 08:59:14 +0000

La semaine dernière, j'ai reçu une alerte d'anomalie de coûts AWS. L'alerte pointait vers mon compte de formation (où je fais mes démos et aussi mes POCs), signalant une charge inattendue de 29 $ sous — étrangement — Amazon Elastic Block Store. Le type d'utilisation racontait cependant une tout autre histoire : NatGateway-Bytes. 659 Go de données avaient transité par ma NAT Gateway en six jours.

J'avais récemment déployé un agent vocal sur Bedrock AgentCore Runtime en mode VPC, utilisant une NAT Gateway pour l'accès internet sortant (nécessaire pour le relais TURN WebRTC) — voir mon billet de blog ici. Le VPC avait été créé spécifiquement pour cet agent, donc le suspect était évident. Mais je voulais des preuves concrètes avant de tirer des conclusions. Était-ce le trafic WebRTC ? Autre chose ?

Début de l'investigation

Mon premier réflexe a été de consulter les métriques CloudWatch de la NAT Gateway. La métrique BytesOutToDestination (trafic du conteneur vers internet) ne montrait que 2,1 Go au total sur les six jours. Négligeable. Mais BytesInFromDestination (trafic d'internet vers le conteneur à travers la NAT) racontait une tout autre histoire :

Date	Entrant via la NAT
26 mars	6,3 Go
27 mars	240,3 Go
28 mars	149,1 Go
29 mars	149,8 Go
30 mars	102,3 Go
31 mars	15,0 Go
1er avril	5,4 Go (journée partielle)

Ce déséquilibre entre les flux entrants et sortants plaidait contre WebRTC comme responsable du trafic.

De plus, la métrique ActiveConnectionCount montrait un nombre stable d'environ 90 connexions 24h/24, même quand personne n'utilisait l'agent. Le pattern horaire était remarquablement régulier — alternant entre ~850 Mo et ~430 Mo par heure, en continu.

Pour en avoir le cœur net, j'ai vérifié CloudTrail pour les événements InvokeAgentRuntime entre le 28 et le 30 mars. Zéro. Aucune activité utilisateur pendant la période avec le trafic le plus intense. L'agent était complètement inactif.

Activation des VPC Flow Logs

J'avais besoin de voir d'où venait le trafic. J'ai activé les VPC Flow Logs (j'aurais dû le faire dès le premier jour ? Bah, c'était un POC !) sur le VPC, en les envoyant vers un groupe de logs CloudWatch, et j'ai lancé une requête Logs Insights pour identifier les plus gros consommateurs :

stats sum(bytes) as totalBytes by srcAddr, dstAddr, dstPort
| sort totalBytes desc
| limit 20

Les résultats sur une fenêtre de deux heures montraient une poignée d'adresses IP responsables de tout le trafic lourd :

    52.216.58.42 ->       10.0.0.144: 31175     270.1 MB
    16.15.207.229 ->      10.0.0.144: 62935     263.7 MB
    16.15.191.63 ->       10.0.0.144: 25320     263.6 MB
    52.216.12.24 ->       10.0.0.144: 12542     115.8 MB
    3.5.16.209 ->         10.0.0.144: 30762     113.4 MB
    16.15.199.52 ->       10.0.0.144: 49632     113.3 MB
    54.231.160.154 ->     10.0.0.144: 55754      29.6 MB

L'adresse 10.0.0.144 est l'IP privée de la NAT Gateway. Tout le trafic transitait depuis des IP externes, à travers la NAT, vers les ENI du conteneur AgentCore dans les sous-réseaux privés.

Identification de la source

J'avais besoin de savoir à quel service appartenaient ces IP. J'ai utilisé mon outil does-this-ip-belong-to-aws, qui vérifie les IP par rapport aux plages IP officielles AWS publiées sur https://ip-ranges.amazonaws.com/ip-ranges.json.

Chaque IP à fort trafic correspondait à Amazon S3 en us-east-1 !

Tout le trafic — jusqu'au dernier gigaoctet — était des téléchargements S3 transitant par la NAT Gateway.

Le correctif : S3 Gateway Endpoint

Le correctif est simple et gratuit. Un S3 Gateway VPC Endpoint route le trafic S3 directement via le réseau AWS, contournant entièrement la NAT Gateway. Contrairement aux interface endpoints, les gateway endpoints n'ont ni frais horaires ni frais de traitement de données.

resource "aws_vpc_endpoint" "s3" {
  vpc_id       = aws_vpc.main.id
  service_name = "com.amazonaws.${var.aws_region}.s3"
  route_table_ids = [
    aws_route_table.private.id,
    aws_route_table.public.id,
  ]
}

Un terraform apply et les coûts de transfert de données de la NAT Gateway tombent à quasi zéro.

Ce qui soulève une question plus large : pourquoi ne pas toujours avoir un S3 Gateway Endpoint dans un VPC ? C'est gratuit, ça se crée en une seule ressource, et ça prévient exactement ce genre de surprise. Si vous créez des VPC avec des sous-réseaux privés et des NAT Gateways, ajoutez un S3 Gateway Endpoint par défaut. Il n'y a aucun inconvénient. Les S3 Gateway endpoints sont bons pour votre portefeuille, sinon pour votre âme.

La cause racine : recyclage du warm pool

Après avoir ouvert un ticket de support, l'équipe du service Bedrock AgentCore a identifié la cause racine.

AgentCore Runtime maintient un warm pool de VM pour garantir des invocations à faible latence. Chaque VM du pool télécharge l'image du conteneur depuis ECR — et ECR stocke les couches d'images dans S3. Mon image de conteneur faisait environ 435 Mo compressée.

Trois facteurs se sont combinés pour produire la facture de 659 Go :

Premièrement, les 21 appels API UpdateAgentRuntime que j'ai effectués le 27 mars (une journée de débogage et redéploiement intensifs) ont chacun déclenché un cycle asynchrone de re-provisionnement du warm pool. Plusieurs séries de provisionnement de 10 VM, chacune téléchargeant l'image de 435 Mo, ont produit le pic de ~240 Go observé ce jour-là.

Deuxièmement, le warm pool a continué à recycler les VM les jours suivants pour les garder fraîches et prêtes. Avec 10 VM téléchargeant chacune l'image périodiquement, le trafic stable de ~150 Go/jour du 28 au 30 mars est cohérent avec un recyclage régulier.

Troisièmement, après environ 72 heures sans invocations, le warm pool a automatiquement réduit sa taille de 10 VM à 1 VM. Cela explique la chute de ~150 Go/jour à ~15 Go/jour le 31 mars.

Le recyclage du warm pool est un comportement attendu de la plateforme — c'est ce qui permet à AgentCore de servir les requêtes avec une faible latence. Le problème était que tous ces téléchargements S3 passaient par ma NAT Gateway à 0,045 $/Go au lieu de rester sur le réseau interne AWS.

Lancer autant de VM pour si peu d'invocations me semble un peu comme tirer au bazooka pour tuer une mouche ; je me demande si c'est soutenable... Cela dit, AWS a un bon historique de gestion d'activités rentables à grande échelle : qui suis-je pour juger ?

Quoi qu'il en soit, l'équipe du service a promis de mettre à jour la documentation pour que pas (trop) d'utilisateurs ne se retrouvent face à ces charges (franchement) indues.

Points à retenir

Si vous utilisez Bedrock AgentCore Runtime en mode VPC, trois choses à garder en tête :

Ajoutez un S3 Gateway Endpoint à votre VPC. C'est gratuit et ça élimine ce qui s'est avéré être la source dominante de coûts de transfert de données de la NAT Gateway — les téléchargements d'images ECR par le warm pool. AWS a confirmé qu'ils mettent à jour leur documentation VPC pour recommander cela plus visiblement. Il n'y a véritablement aucune raison de ne pas en avoir un dans chaque VPC avec des sous-réseaux privés.
Soyez attentif à la taille de votre image de conteneur. Mon image de 435 Mo, téléchargée par un warm pool de 10 VM avec recyclage régulier, a généré des centaines de gigaoctets de transfert. Réduire l'image (builds multi-étapes, moins de dépendances, base Alpine) réduit directement ce coût — même avec le endpoint S3 en place, des images plus petites signifient des démarrages à froid plus rapides.
Surveillez vos métriques NAT Gateway tôt. Les métriques BytesInFromDestination et BytesOutToSource dans CloudWatch vous montreront si quelque chose d'inattendu se passe. Je ne m'en suis rendu compte que grâce à l'alerte d'anomalie de coûts — à ce moment-là, 29 $ avaient déjà été dépensés. Les VPC Flow Logs combinés avec CloudWatch Logs Insights ont rendu le diagnostic simple une fois que j'ai regardé.

Paul Santus est consultant cloud indépendant chez TerraCloud. Il accompagne les organisations dans la construction et le déploiement d'applications IA sur AWS. Retrouvez-le sur LinkedIn.

VPC-connected Bedrock AgentCore Runtime-hosted agents: beware of NAT Gateway costs!

Paul SANTUS — Fri, 03 Apr 2026 14:05:35 +0000

Last week I received a cost anomaly alert from AWS. The alert pointed at my training account, flagging an unexpected $29 charge under — oddly enough — Amazon Elastic Block Store. The usage type, however, told a different story: NatGateway-Bytes. 659 GB of data had flowed through my NAT Gateway in six days.

I had recently deployed a voice agent on Bedrock AgentCore Runtime in VPC mode, using a NAT Gateway for outbound internet access (required for WebRTC TURN relay) - see my blog post here. The VPC had been created specifically for this agent, so the suspect was obvious. But I wanted ground truth before jumping to conclusions. Was it WebRTC traffic? Something else?

Starting the investigation

My first stop was CloudWatch metrics on the NAT Gateway. The BytesOutToDestination metric (traffic from the container to the internet) showed only 2.1 GB total over the six days. Negligible. But BytesInFromDestination (traffic from the internet into the container through the NAT) told a very different story:

Date	Inbound through NAT
Mar 26	6.3 GB
Mar 27	240.3 GB
Mar 28	149.1 GB
Mar 29	149.8 GB
Mar 30	102.3 GB
Mar 31	15.0 GB
Apr 01	5.4 GB (partial)

This unbalanced metrics values between inbound and outbound flows pleaded against WebRTC as the traffic culprit.

Moreover, the ActiveConnectionCount metric showed a steady ~90 connections 24/7, even when nobody was using the agent. The hourly pattern was remarkably regular — alternating between ~850 MB and ~430 MB per hour, around the clock.

Just to be sure, I checked CloudTrail for InvokeAgentRuntime events between March 28 and March 30. Zero. No user activity at all during the period with the heaviest traffic. The agent was completely idle.

Enabling VPC Flow Logs

I needed to see where the traffic was coming from. I enabled VPC Flow Logs (shouldn't have it done on day 1? Nay, this was a POC workload!) on the VPC, sending them to a CloudWatch log group, and ran a Logs Insights query to identify the top talkers:

stats sum(bytes) as totalBytes by srcAddr, dstAddr, dstPort
| sort totalBytes desc
| limit 20

The results over a two-hour window showed a handful of IP addresses responsible for all the heavy traffic:

    52.216.58.42 ->       10.0.0.144: 31175     270.1 MB
    16.15.207.229 ->      10.0.0.144: 62935     263.7 MB
    16.15.191.63 ->       10.0.0.144: 25320     263.6 MB
    52.216.12.24 ->       10.0.0.144: 12542     115.8 MB
    3.5.16.209 ->         10.0.0.144: 30762     113.4 MB
    16.15.199.52 ->       10.0.0.144: 49632     113.3 MB
    54.231.160.154 ->     10.0.0.144: 55754      29.6 MB

The 10.0.0.144 address is the NAT Gateway's private IP. All the traffic was flowing from external IPs, through the NAT, to the AgentCore container ENIs in the private subnets.

Identifying the source

I needed to know what service these IPs belonged to. I used my does-this-ip-belong-to-aws tool, which checks IPs against the official AWS IP ranges published at https://ip-ranges.amazonaws.com/ip-ranges.json.

Every single high-traffic IP resolved to Amazon S3 in us-east-1!

All the traffic — every last gigabyte — was S3 pulls flowing through the NAT Gateway.

The fix: S3 Gateway Endpoint

The fix is straightforward and free. An S3 Gateway VPC Endpoint routes S3 traffic directly through the AWS network, bypassing the NAT Gateway entirely. Unlike interface endpoints, gateway endpoints have no hourly charge and no data processing fee.

resource "aws_vpc_endpoint" "s3" {
  vpc_id       = aws_vpc.main.id
  service_name = "com.amazonaws.${var.aws_region}.s3"
  route_table_ids = [
    aws_route_table.private.id,
    aws_route_table.public.id,
  ]
}

One terraform apply and the NAT Gateway data transfer cost drops to near zero.

This raises a broader question: why would you ever not have an S3 Gateway Endpoint in a VPC? It's free, takes one resource to create, and prevents exactly this kind of surprise. If you're creating VPCs with private subnets and NAT Gateways, add an S3 Gateway Endpoint as a default. There's no downside. S3 Gateway endpoints are good for you wallet, if not for your soul.

The root cause: warm pool recycling

After filing a support case, the Bedrock AgentCore service team identified the root cause.

AgentCore Runtime maintains a warm pool of VMs to ensure low-latency invocations. Each VM in the pool pulls the container image from ECR — and ECR stores image layers in S3. My container image was ~435 MB compressed.

Three things combined to produce the 659 GB bill:

First, the 21 UpdateAgentRuntime API calls I made on March 27 (a day of heavy debugging and redeployment) each triggered an asynchronous warm pool re-provisioning cycle. Multiple rounds of 10-VM provisioning, each pulling the 435 MB image, produced the ~240 GB spike that day.

Second, the warm pool continued recycling VMs over the following days to keep them fresh and ready. With 10 VMs each pulling the image periodically, the steady ~150 GB/day on March 28-30 is consistent with regular recycling.

Third, after approximately 72 hours with no invocations, the warm pool automatically downscaled from 10 VMs to 1 VM. This explains the drop from ~150 GB/day to ~15 GB/day on March 31.

The warm pool recycling is expected platform behavior — it's what makes AgentCore able to serve requests with low latency. The problem was that all those S3 pulls were routing through my NAT Gateway at $0.045/GB instead of staying on the AWS internal network.

Firing these many VMs for so few invocations seems to mme like shooting a bazooka to kill a fly; I wonder how sustainable that is.. yet AWS has a good track record at operating profitable business at scale: who am I to judge?

Anyway, the service team promised they'll make an update to the documentation so that not (too) many users face these (frankly) undue charges.

Takeaways

If you're running Bedrock AgentCore Runtime in VPC mode, three things to keep in mind:

add an S3 Gateway Endpoint to your VPC. It's free and eliminates what turned out to be the dominant source of NAT Gateway data transfer costs — ECR image pulls from the warm pool. AWS has confirmed they are updating their VPC documentation to more prominently recommend this. There is genuinely no reason not to have one in every VPC with private subnets.
be mindful of container image size. My 435 MB image, pulled across a 10-VM warm pool with regular recycling, generated hundreds of gigabytes of transfer. Slimming the image (multi-stage builds, fewer dependencies, Alpine base) directly reduces this cost — even with the S3 endpoint in place, smaller images mean faster cold starts.
monitor your NAT Gateway metrics early. The BytesInFromDestination and BytesOutToSource metrics in CloudWatch will show you if something unexpected is happening. I only noticed because of the cost anomaly alert — by then, $29 had already been spent. VPC Flow Logs combined with CloudWatch Logs Insights made the diagnosis straightforward once I looked.

Paul Santus is an independent cloud consultant at TerraCloud. He helps organizations build and deploy AI-powered applications on AWS. Connect with him on LinkedIn.

Héberger un agent IA vocal sur AWS Bedrock AgentCore communiquant via WebRTC

Paul SANTUS — Fri, 27 Mar 2026 16:02:24 +0000

Aujourd'hui j'ai migré agent vocal IA de WebSocket vers WebRTC — voici ce qui a cassé et ce que j'ai appris.

Il y a quelques jours, je suis tombé sur le billet de blog et le repo de Darryl Ruggles pour un agent vocal bidirectionnel construit avec Strands BidiAgent et Amazon Nova Sonic v2. Son travail est remarquablement bien ficelé — j'avais un assistant vocal fonctionnel sur mon laptop en une dizaine de minutes. L'agent écoute votre voix, cherche dans une base de recettes, programme des minuteurs de cuisson, consulte des données nutritionnelles et convertit des unités, le tout par conversation naturelle.

La version de Darryl utilise WebSocket comme transport entre le navigateur et l'agent. Ça fonctionne bien, mais je voulais aller plus loin : passer le transport en WebRTC et déployer le tout sur Bedrock AgentCore Runtime. Ce billet couvre ce parcours — ce qui a changé, ce qui a cassé, et ce que j'en ai tiré.

Vous avez rêvé de demander la recette des crêpes à un agent IA ? je l'ai fait :)

Le code source complet est disponible sur GitHub. Le repo est entièrement géré par Terraform, mais vous pouvez toujours utiliser l'approche Makefile de Darryl si vous préférez garder Terraform pour l'infrastructure et le CLI pour le déploiement de l'agent.

Pourquoi WebRTC pour un agent vocal ?

La version WebSocket de l'agent fonctionne, alors pourquoi changer ? Plusieurs raisons m'ont poussé vers WebRTC.

D'abord, la latence. WebSocket tourne sur TCP, ce qui signifie que chaque paquet est garanti d'arriver dans l'ordre. C'est parfait pour des messages de chat, mais pour de l'audio en temps réel, un seul paquet perdu bloque tout le flux pendant que TCP retransmet. WebRTC¹ utilise UDP — si un paquet est perdu, le flux continue. Pour une conversation vocale, un micro-glitch est bien préférable à une pause perceptible.

Ensuite, le navigateur fait plus de travail. Avec WebSocket, je devais capturer l'audio du micro via getUserMedia, le sous-échantillonner à 16kHz avec un ScriptProcessorNode, l'encoder en base64 PCM et l'envoyer en messages JSON. Côté lecture, il fallait un AudioWorklet avec un buffer circulaire pour gérer le flux audio entrant. Avec WebRTC, le navigateur gère nativement la capture audio, l'encodage (Opus) et la lecture via RTCPeerConnection. Le code frontend s'en trouve considérablement simplifié.

Enfin, WebRTC est prêt pour la vidéo. Les avatars IA arrivent à des latences acceptables, et WebRTC gère les pistes vidéo aussi naturellement que les pistes audio. Ajouter un flux vidéo plus tard revient simplement à ajouter une piste à la connexion existante — aucun changement d'architecture ne sera nécessaire.

Petit tour d'horizon des architectures WebRTC

Il existe deux façons fondamentalement différentes d'utiliser WebRTC, et le choix compte quand on construit un agent vocal.

Pair-à-pair (P2P)

En WebRTC P2P, deux pairs se connectent directement l'un à l'autre. Pas de serveur média au milieu — l'audio circule directement du navigateur à l'agent et retour. Un serveur relais TURN² peut être nécessaire quand l'un ou les deux pairs sont derrière un NAT³ (ce qui est quasi systématique en production : les clients sont derrière un routeur Internet et les agents doivent être dans un VPC privé pour accéder aux outils de l'entreprise), mais le serveur TURN ne fait que relayer les paquets sans les inspecter ni les traiter.

Basé sur des salles (SFU)

Dans une architecture basée sur des salles de visio, un serveur média (appelé SFU⁴ — Selective Forwarding Unit) se place au milieu. Les participants se connectent au serveur, pas entre eux. Le serveur reçoit les pistes audio/vidéo de chaque participant et les retransmet sélectivement aux autres. LiveKit, Amazon Chime SDK et Daily sont des exemples de plateformes SFU.

Pour un agent vocal en 1:1, le P2P est plus simple et évite le coût et la complexité de faire tourner (ou de payer) un serveur média. J'ai opté pour le P2P avec Amazon Kinesis Video Streams (KVS) comme relais TURN managé — c'est l'approche documentée pour WebRTC sur AgentCore.

J'ai envisagé les solutions basées sur des salles, mais chaque plateforme SFU nécessite son propre SDK — on ne peut pas simplement se connecter avec un RTCPeerConnection standard. L'offre WebRTC d'AWS, Amazon Chime SDK, est riche en fonctionnalités (transcription, enregistrement, analytics) et nettement moins chère que les alternatives comme LiveKit ou Daily, mais elle n'offre pas encore de chemin balisé pour la communication agent-vers-salle côté serveur. C'est une fonctionnalité que j'aimerais beaucoup voir arriver, vu la qualité du reste du Chime SDK. Pour l'instant, le P2P avec KVS TURN était le chemin le plus direct. Je considérerai certainement le WebRTC en salle, mais c'est une histoire pour un autre billet.

La pile WebRTC : navigateur et serveur

Côté navigateur, WebRTC est intégré nativement. L'API RTCPeerConnection est disponible dans tous les navigateurs modernes — Chrome, Safari, Firefox, Edge. On crée une connexion pair, on ajoute une piste micro via getUserMedia, et le navigateur gère l'encodage audio (Opus), la collecte des candidats ICE et le chiffrement DTLS. Aucune bibliothèque nécessaire.

Côté serveur, c'est une autre histoire. WebRTC a été conçu pour les navigateurs, pas pour des backends Python. La bibliothèque de référence pour le WebRTC côté serveur en Python est aiortc — une implémentation asyncio de WebRTC et ORTC. Elle gère les connexions pair, la négociation ICE et les pistes média, et utilise PyAV (bindings FFmpeg) pour le traitement des trames audio/vidéo. Elle n'est pas aussi éprouvée que le WebRTC des navigateurs, mais elle fonctionne bien et c'est ce qu'utilise aussi le code d'exemple AWS.

Architecture : développement local vs. déployé

Un point que je voulais préserver du design original de Darryl est la possibilité de tout faire tourner localement pour le développement, sans aucune infrastructure cloud. La migration WebRTC maintient cela.

Mode local

En mode local, l'agent tourne sur votre machine. Le navigateur et l'agent sont sur le même réseau (ou la même machine), donc WebRTC se connecte en pair-à-pair sans avoir besoin de relais TURN. La signalisation — l'échange d'offres/réponses SDP⁵ et de candidats ICE⁶ — passe par le proxy du serveur de développement Vite vers le serveur FastAPI local.

Mode hébergé sur Bedrock AgentCore

En mode hébergé, l'agent tourne dans un conteneur Docker sur Bedrock AgentCore Runtime, attaché à un VPC via une interface réseau élastique (ENI) dans un sous-réseau privé. Le navigateur ne peut pas atteindre l'agent directement — tout le trafic média passe par un relais KVS TURN. La signalisation passe par le endpoint HTTP /invocations d'AgentCore, authentifié en SigV4 via le SDK @aws-sdk/client-bedrock-agentcore.

Le diagramme suivant, tiré de la documentation AWS, montre le réseau VPC en détail — la signalisation passe par le endpoint HTTP d'AgentCore tandis que le trafic média passe par la NAT gateway du VPC vers le relais KVS TURN :

Le point important à noter est que le code de l'agent est quasi identique entre les modes local et déployé. Le BidiAgent, le BidiNovaSonicModel et les quatre outils (recherche de recettes, minuteur, recherche nutritionnelle, conversion d'unités) sont totalement inchangés. La seule différence est la couche transport : en local, aiortc se connecte en P2P ; en déployé, il se connecte via KVS TURN. L'agent détecte dans quel mode il se trouve via la variable d'environnement CONTAINER_ENV et configure les serveurs ICE en conséquence.

Cette séparation propre a été possible grâce au protocole BidiInput/BidiOutput de Strands. J'ai écrit deux petites classes adaptateurs — WebRTCBidiInput et WebRTCBidiOutput — qui font le pont entre les pistes audio aiortc et le format d'événements attendu par BidiAgent. L'agent ne sait pas et ne se soucie pas de savoir si l'audio vient d'un WebSocket ou d'une piste WebRTC.

Ce qu'apporte le support WebRTC de Bedrock AgentCore

Le 20 mars 2026, AWS a annoncé le support WebRTC pour AgentCore Runtime. Je veux être honnête sur ce que cela signifie en pratique.

Je n'en suis pas sûr à 100%, et je suis prêt à être corrigé, mais mon impression est que les briques de base — le mode réseau VPC, KVS TURN, le endpoint HTTP /invocations — existaient tous déjà avant cette annonce. Le mode réseau VPC est disponible depuis la disponibilité générale d'AgentCore en octobre 2025. KVS TURN est une fonctionnalité de longue date de Kinesis Video Streams. Et /invocations a toujours été le endpoint HTTP standard des runtimes AgentCore.

Ce que la release du 20 mars ajoute, d'après ce que je comprends, c'est de la documentation officielle, du code d'exemple fonctionnel, et la déclaration explicite que WebRTC est un protocole supporté sur AgentCore Runtime. Avant cela, on pouvait techniquement assembler les mêmes pièces soi-même, mais on était seul — pas de docs, pas d'exemples, pas de garantie que ça continuerait à fonctionner.

Ce qu'AgentCore apporte est réellement précieux : un hébergement de conteneurs managé avec auto-scaling, l'isolation des sessions entre utilisateurs concurrents, l'observabilité intégrée (logs CloudWatch, traces X-Ray), et aucune infrastructure à gérer au-delà du VPC. Je n'ai pas eu à configurer ECS, des load balancers ou de l'orchestration de conteneurs.

Cela dit, il y a une bonne quantité de code custom. La signalisation WebRTC (échange SDP, gestion des candidats ICE), le cycle de vie de la connexion pair aiortc, le pont entre les pistes audio et BidiAgent, et la gestion des identifiants KVS TURN — tout cela est du code applicatif que j'ai écrit. AgentCore l'héberge et l'exécute, mais ne l'abstrait pas.

Défis et leçons apprises

La migration de WebSocket vers WebRTC a commencé en douceur, puis ça s'est corsé. Voici ce qui m'a fait trébucher.

Compatibilité des zones de disponibilité du VPC

AgentCore Runtime ne supporte que certaines zones de disponibilité. En us-east-1, seules use1-az4 (us-east-1a), use1-az1 (us-east-1c) et use1-az2 (us-east-1d) sont supportées. J'ai initialement laissé Terraform choisir les deux premières AZ automatiquement, ce qui m'a donné us-east-1a et us-east-1b. La mise à jour du runtime a échoué avec un statut cryptique UPDATE_FAILED. Le vrai message d'erreur — mentionnant l'AZ non supportée — était enfoui dans le champ failureReason de la réponse API, pas remonté dans l'erreur Terraform. J'ai fini par coder en dur les AZ supportées dans mon module VPC.

Affinité de session

Celui-ci m'a coûté des heures. La signalisation WebRTC est une poignée de main en plusieurs étapes — le navigateur et l'agent échangent plusieurs messages pour établir une connexion. L'agent doit se souvenir de l'état de la connexion du premier message quand il traite le deuxième et le troisième. Si ces messages atterrissent sur des instances serveur différentes, l'agent n'a aucune mémoire de la poignée de main en cours et la connexion échoue.

J'ai d'abord utilisé des requêtes HTTP POST signées SigV4, en supposant qu'inclure l'identifiant de session comme paramètre de requête fournirait l'affinité de routage. Ce n'était pas le cas. Les candidats ICE atterrissaient sur une instance de conteneur différente de celle qui détenait la connexion pair.

La solution a été d'utiliser le SDK @aws-sdk/client-bedrock-agentcore avec InvokeAgentRuntimeCommand et le paramètre runtimeSessionId. C'est le seul moyen fiable de s'assurer que toutes les requêtes d'une session WebRTC atteignent la même instance de conteneur. Le code d'exemple AWS utilise ce pattern aussi — je ne l'avais simplement pas remarqué au début parce que j'étais concentré sur les parties WebRTC.

Filtrage des candidats SDP

Quand l'agent crée une connexion pair à l'intérieur du VPC, aiortc génère des candidats ICE pour toutes les interfaces réseau disponibles — y compris des IP internes au VPC comme 169.254.0.2. Ces candidats hôtes se retrouvent dans la réponse SDP envoyée au navigateur. Le navigateur essaie consciencieusement de s'y connecter, échoue (parce qu'ils sont injoignables depuis l'Internet public), et ne se rabat sur les candidats relais qu'ensuite. Cela ajoute plusieurs secondes au temps de connexion.

La solution est simple : retirer les candidats non-relais de la réponse SDP avant de la renvoyer au navigateur. En mode déployé, les seuls candidats qui peuvent fonctionner sont les candidats relais TURN, donc il n'y a aucune raison d'inclure les autres.

Mode TURN uniquement

Similaire au problème de filtrage SDP, l'instance aiortc de l'agent essaie les candidats hôtes avant les candidats relais par défaut. Comme les candidats hôtes utilisent des IP internes au VPC qui ne peuvent jamais fonctionner du point de vue du navigateur, c'est du temps perdu. Configurer aiortc pour n'utiliser que les candidats relais TURN (turn_only=True) saute directement aux candidats qui fonctionnent réellement.

Initialisation paresseuse de KVS

J'appelais initialement kvs.init() au moment de l'import du module, protégé par un if IS_CONTAINER. Ça fonctionnait bien en local mais faisait crasher le conteneur sur AgentCore. L'appel API KVS pour trouver ou créer le canal de signalisation nécessite des identifiants AWS, et au démarrage du conteneur il peut y avoir un bref délai avant que les identifiants du rôle IAM soient disponibles. Déplacer l'initialisation à la première requête réelle (init paresseuse) a résolu le crash.

Comportement au démarrage à froid

Après que le conteneur est resté inactif un moment, la première tentative de connexion WebRTC échoue parfois. Les requêtes de signalisation réussissent (AgentCore renvoie 200), mais la connexion ICE ne s'établit jamais. Je soupçonne que c'est lié au fait qu'AgentCore démarre une nouvelle instance de conteneur — les premières requêtes peuvent être traitées par une instance qui n'est pas encore complètement prête. Côté agent, j'ai explicitement mis --workers 1 dans la commande uvicorn pour m'assurer que toutes les requêtes au sein d'un conteneur touchent le même processus (et donc le même état de connexion pair en mémoire). Côté frontend, j'ai ajouté un mécanisme de retry : attendre que ICE atteigne l'état "connected", et si ce n'est pas le cas dans les 10 secondes, tout démonter et réessayer avec un nouvel identifiant de session. Ensemble, ces deux mesures ont rendu la connexion fiable.

Code clé

Je ne vais pas parcourir chaque fichier, mais voici les pièces qui font fonctionner l'intégration WebRTC.

L'adaptateur WebRTCBidiInput lit les trames audio de la piste aiortc, les rééchantillonne à 16kHz, et les renvoie comme événements bidi_audio_input que BidiAgent comprend :

class WebRTCBidiInput:
    def __init__(self, track):
        self._track = track

    async def __call__(self):
        try:
            frame = await self._track.recv()
        except MediaStreamError:
            raise StopAsyncIteration
        resampled = _resampler.resample(frame)
        pcm = b"".join(f.planes[0] for f in resampled)
        return {
            "type": "bidi_audio_input",
            "audio": base64.b64encode(pcm).decode("utf-8"),
            "sample_rate": 16000,
        }

L'adaptateur WebRTCBidiOutput fait l'inverse — il reçoit les événements de BidiAgent et pousse l'audio vers la piste de sortie aiortc :

class WebRTCBidiOutput:
    def __init__(self, output_track):
        self._output_track = output_track

    async def __call__(self, event):
        if event.get("type") == "bidi_audio_stream":
            audio_bytes = base64.b64decode(event["audio"])
            self._output_track.add_audio(audio_bytes)
        elif event.get("type") == "bidi_interruption":
            self._output_track.clear()

Côté frontend, le hook useWebRTCSession utilise le SDK AgentCore pour la signalisation :

const invoke = async (action, data = {}) => {
  const client = new BedrockAgentCoreClient({ region, credentials });
  const resp = await client.send(new InvokeAgentRuntimeCommand({
    agentRuntimeArn,
    runtimeSessionId: sessionId,  // assure l'affinité de session
    contentType: 'application/json',
    payload: new TextEncoder().encode(JSON.stringify({ action, data })),
  }));
  return JSON.parse(new TextDecoder().decode(
    await resp.response.transformToByteArray()
  ));
};

Le code source complet est dans le repo — la branche feat/webrtc contient la version locale uniquement, et feat/webrtc-agentcore la version déployée complète avec Terraform.

Outillage de développement

J'ai construit ce projet avec Kiro CLI, l'assistant de développement IA d'Amazon. Il a géré la planification, la génération de code, le débogage et le déploiement itératif — y compris les nombreux allers-retours d'essais-erreurs avec la configuration WebRTC que ce billet décrit. Le va-et-vient entre écriture de code, déploiement, vérification des logs et correction des problèmes se prêtait naturellement à un workflow de pair-programming avec une IA.

Essayez vous-même

Pour lancer en local :

git clone https://github.com/psantus/strands-bidir-nova.git
cd strands-bidir-nova
git checkout feat/webrtc
uv sync && make install-frontend
# Terminal 1 :
make serve
# Terminal 2 :
make serve-frontend

Ouvrez http://localhost:5173, cliquez sur le micro, et commencez à parler.

Pour la version déployée sur AgentCore, passez sur la branche feat/webrtc-agentcore et suivez le README. Vous aurez besoin d'une Knowledge Base Bedrock avec quelques recettes, d'un pool d'utilisateurs Cognito et de Docker pour construire l'image du conteneur. Un seul terraform apply gère le reste.

Si vous préférez commencer par la version WebSocket, le billet original de Darryl Ruggles est le bon point de départ.

Paul Santus est consultant cloud indépendant chez TerraCloud. Il accompagne les organisations dans la construction et le déploiement d'applications IA sur AWS. Retrouvez-le sur LinkedIn.

WebRTC (Web Real-Time Communication) — Standard ouvert pour la communication audio, vidéo et données en temps réel directement entre navigateurs et appareils, utilisant un transport basé sur UDP. ↩
TURN (Traversal Using Relays around NAT) — Serveur relais qui transfère le trafic média quand deux pairs ne peuvent pas se connecter directement. Les deux côtés envoient leur audio au serveur TURN, qui le relaie à l'autre côté. ↩
NAT (Network Address Translation) — Mécanisme réseau qui fait correspondre des adresses IP privées à des adresses publiques. La plupart des routeurs domestiques et des VPC cloud utilisent le NAT, ce qui empêche les connexions entrantes directes. ↩
SFU (Selective Forwarding Unit) — Serveur média qui reçoit les pistes audio/vidéo des participants et les retransmet sélectivement aux autres, sans mixage ni transcodage. Utilisé par LiveKit, Chime SDK, Daily, etc. ↩
SDP (Session Description Protocol) — Format texte décrivant une session multimédia : codecs, adresses de transport et types de média. En WebRTC, les pairs échangent des « offres » et « réponses » SDP pour négocier la connexion. ↩
ICE (Interactive Connectivity Establishment) — Protocole pour trouver le meilleur chemin réseau entre deux pairs. Il collecte des adresses candidates (locales, réflexives serveur, relais) et teste la connectivité entre elles. ↩

Switching my AI voice agent from WebSocket to WebRTC — what broke and what I learned

Paul SANTUS — Fri, 27 Mar 2026 15:29:19 +0000

Switching my AI voice agent from WebSocket to WebRTC — what broke and what I learned

A few weeks ago, I came across Darryl Ruggles' blog post and accompanying repo for a bidirectional voice agent built with Strands BidiAgent and Amazon Nova Sonic v2. His work is remarkably well put together — I had a working voice assistant running on my laptop in about 10 minutes. The agent listens to your voice, searches a recipe knowledge base, sets cooking timers, looks up nutrition data, and converts units, all through natural conversation.

Darryl's version uses WebSocket as the transport between the browser and the agent. It works well, but I wanted to push things further: switch the transport to WebRTC, and deploy the whole thing on Bedrock AgentCore Runtime. This post covers that journey — what changed, what broke, and what I learned along the way.

But first, a short demo!

The full source code is available on GitHub. The repo is Terraform-managed end-to-end, though you can still use Darryl's Makefile approach if you prefer keeping Terraform for surrounding infrastructure and CLI calls for agent deployment.

Why WebRTC for a voice agent

The WebSocket version works, so why change it? A few reasons pushed me toward WebRTC.

First, latency. WebSocket runs over TCP, which means every packet is guaranteed to arrive in order. That's great for chat messages, but for real-time audio, a single dropped packet causes the entire stream to stall while TCP retransmits. WebRTC¹ uses UDP under the hood — if a packet is lost, the stream keeps going. For a voice conversation, a tiny glitch is far better than a noticeable pause.

Second, the browser does more of the heavy lifting. With WebSocket, I had to capture microphone audio using getUserMedia, downsample it to 16kHz with a ScriptProcessorNode, encode it as base64 PCM, and send it as JSON messages. On the playback side, I needed an AudioWorklet with a ring buffer to handle the incoming audio stream. With WebRTC, the browser handles audio capture, encoding (Opus), and playback natively through RTCPeerConnection. The frontend code got significantly simpler.

Third, WebRTC is future-proof for video. AI avatar are getting there with acceptable latency, and WebRTC handles video tracks just as naturally as audio tracks. Adding a video stream later is just a matter of adding a track to the existing peer connection — no architectural change needed.

A quick primer on WebRTC architectures

There are two fundamentally different ways to use WebRTC, and the choice matters when building a voice agent.

Peer-to-peer (P2P)

In P2P WebRTC, two peers connect directly to each other. There's no media server in the middle — audio flows straight from the browser to the agent and back. A TURN² relay server may be needed when one or both peers are behind NAT³ (which is almost always the case in production: clients are behind Internet Router and Agents need to be in private VPC to access company tools), but the TURN server just forwards packets without inspecting or processing them.

Room-based (SFU)

In a room-based architecture, a media server (called an SFU⁴ — Selective Forwarding Unit) sits in the middle. Participants connect to the server, not to each other. The server receives audio/video tracks from each participant and selectively forwards them to the others. LiveKit, Amazon Chime SDK, and Daily are examples of SFU-based platforms.

For a 1:1 voice agent, P2P is simpler and avoids the cost and complexity of running (or paying for) a media server. I went with P2P using Amazon Kinesis Video Streams (KVS) as the managed TURN relay — this is the documented approach for WebRTC on AgentCore.

I did consider room-based solutions, but each SFU platform requires its own SDK — you can't just connect with a standard RTCPeerConnection. AWS's own WebRTC offering, Amazon Chime SDK, is feature-rich (transcription, recording, analytics) and significantly cheaper than alternatives like LiveKit or Daily, but it doesn't yet offer a paved path for server-side agent-to-room communication. That's a feature I'd love to see, given how compelling the rest of the Chime SDK is. For now, P2P with KVS TURN was the most straightforward path. I'll definitely consider in-room WebRTC, but that's a story for another post.

The WebRTC stack: browser and server

On the browser side, WebRTC is built in. The RTCPeerConnection API is available natively in every modern browser — Chrome, Safari, Firefox, Edge. You create a peer connection, add a microphone track via getUserMedia, and the browser handles audio encoding (Opus), ICE candidate gathering, and DTLS encryption. No libraries needed.

On the server side, it's a different story. WebRTC was designed for browsers, not for Python backends. The go-to library for server-side WebRTC in Python is aiortc — an asyncio-based implementation of WebRTC and ORTC. It handles peer connections, ICE negotiation, and media tracks, and uses PyAV (FFmpeg bindings) for audio/video frame processing. It's not as battle-tested as browser WebRTC, but it works well and is what the AWS sample code uses too.

Architecture: local development vs. deployed

One thing I wanted to preserve from Darryl's original design is the ability to run everything locally for development, without any cloud infrastructure. The WebRTC migration maintains this.

Local mode

In local mode, the agent runs on your machine. The browser and agent are on the same network (or the same machine), so WebRTC connects peer-to-peer without needing a TURN relay. Signaling — the exchange of SDP⁵ offers/answers and ICE⁶ candidates — goes through the Vite dev server proxy to the local FastAPI server.

Deployed mode

In deployed mode, the agent runs inside a Docker container on Bedrock AgentCore Runtime, attached to a VPC via an elastic network interface (ENI) in a private subnet. The browser can't reach the agent directly — all media traffic flows through a KVS TURN relay. Signaling goes through AgentCore's /invocations HTTP endpoint, authenticated with SigV4 via the @aws-sdk/client-bedrock-agentcore SDK.

The following diagram from the AWS documentation shows how it works in terms of networking: signaling flows through AgentCore's HTTP endpoint while media traffic goes through the VPC's NAT gateway to the KVS TURN relay:

The important thing to note is that the agent code is almost identical between local and deployed modes. The BidiAgent, BidiNovaSonicModel, and all four tools (recipe search, timer, nutrition lookup, unit converter) are completely unchanged. The only difference is the transport layer: in local mode, aiortc connects P2P; in deployed mode, it connects through KVS TURN. The agent detects which mode it's in via the CONTAINER_ENV environment variable and configures ICE servers accordingly.

This clean separation was possible because of Strands' BidiInput/BidiOutput protocol. I wrote two small adapter classes — WebRTCBidiInput and WebRTCBidiOutput — that bridge aiortc audio tracks to the event format BidiAgent expects. The agent doesn't know or care whether audio is coming from a WebSocket or a WebRTC track.

What Bedrock AgentCore's WebRTC support adds

On March 20th, 2026, AWS announced WebRTC support for AgentCore Runtime.

I'm not 100% sure, and am ready to stand corrected, but my impression is that the building blocks — VPC network mode, KVS TURN, the /invocations HTTP endpoint — all existed before this announcement. VPC network mode has been available since AgentCore's general availability in October 2025. KVS TURN is a long-standing Kinesis Video Streams feature. And /invocations has always been the standard HTTP endpoint for AgentCore runtimes.

What the March 20th release adds, as far as I can tell, is official documentation, working sample code, and the explicit statement that WebRTC is a supported protocol on AgentCore Runtime. Before this, you could technically have assembled the same pieces yourself, but you'd be on your own — no docs, no samples, no guarantee it would keep working.

What AgentCore does provide is genuinely valuable: managed container hosting with auto-scaling, session isolation between concurrent users, built-in observability (CloudWatch logs, X-Ray traces), and no infrastructure to manage beyond the VPC. I didn't have to set up ECS, configure load balancers, or manage container orchestration.

That said, there's a fair amount of custom code involved. The WebRTC signaling (SDP exchange, ICE candidate management), the aiortc peer connection lifecycle, the audio track bridging to BidiAgent, and the KVS TURN credential management — all of that is application code that I wrote. AgentCore hosts and runs it, but doesn't abstract it away.

Challenges and lessons learned

The migration from WebSocket to WebRTC started as a smooth ride (local mode worked on first attempt!), and was not so smooth afterwards, as I tried to get it to work on Bedrock AgentCore. Here's what tripped me up.

VPC availability zone compatibility

AgentCore Runtime only supports specific availability zones. In us-east-1, only use1-az4 (us-east-1a), use1-az1 (us-east-1c), and use1-az2 (us-east-1d) are supported. I initially let Terraform pick the first two AZs automatically, which gave me us-east-1a and us-east-1b. The runtime update failed with a cryptic UPDATE_FAILED status. The actual error message — mentioning the unsupported AZ — was buried in the failureReason field of the API response, not surfaced in the Terraform error. I ended up hardcoding the supported AZs in my VPC module.

Session affinity

This one cost me hours. WebRTC signaling is a multi-step handshake — the browser and agent exchange several messages to establish a connection. The agent needs to remember the connection state from the first message when processing the second and third. If those messages land on different server instances, the agent has no memory of the ongoing handshake and the connection fails.

I initially used raw SigV4-signed HTTP POST requests, assuming that including the session ID as a query parameter would provide routing affinity. It didn't. The ICE candidates were landing on a different container instance (?) than the one holding the peer connection.

The fix was to use the @aws-sdk/client-bedrock-agentcore SDK with InvokeAgentRuntimeCommand and the runtimeSessionId parameter. This is the only reliable way to ensure all requests for a WebRTC session reach the same container instance. The AWS sample code uses this pattern too — I just didn't notice it at first because I was focused on the WebRTC parts.

SDP candidate filtering

When the agent creates a peer connection inside the VPC, aiortc generates ICE candidates for all available network interfaces — including VPC-internal IPs like 169.254.0.2. These host candidates end up in the SDP answer sent to the browser. The browser dutifully tries to connect to them, fails (because they're unreachable from the public internet), and only then falls back to the relay candidates. This adds several seconds to the connection time.

The fix is straightforward: strip non-relay candidates from the SDP answer before returning it to the browser. In deployed mode, the only candidates that can work are TURN relay candidates, so there's no reason to include the others.

TURN-only mode

Similar to the SDP filtering issue, the agent's aiortc instance tries host candidates before relay candidates by default. Since host candidates use VPC-internal IPs that can never work from the browser's perspective, this wastes time. Configuring aiortc to only use TURN relay candidates (turn_only=True) skips straight to the candidates that actually work.

Lazy KVS initialization

I initially called kvs.init() at module import time, guarded by an if IS_CONTAINER check. This worked fine locally but caused the container to crash on AgentCore. The KVS API call to find or create the signaling channel requires AWS credentials, and during container startup there can be a brief delay before the IAM role credentials are available. Moving the initialization to the first actual request (lazy init) fixed the crash.

Cold start behavior

After the container has been idle for a while, the first WebRTC connection attempt sometimes fails. The signaling requests succeed (AgentCore returns 200), but the ICE connection never completes. I suspect this is related to AgentCore spinning up a fresh container instance — the first few requests may be handled by an instance that isn't fully warmed up. On the agent side, I explicitly set --workers 1 in the uvicorn command to ensure all requests within a container hit the same process (and therefore the same in-memory peer connection state). On the frontend, I added a retry mechanism: wait for ICE to reach "connected" state, and if it doesn't within 10 seconds, tear down and retry with a new session ID. Together, these made the connection reliable.

Key code

I won't walk through every file, but here are the pieces that make the WebRTC integration work.

The WebRTCBidiInput adapter reads audio frames from the aiortc track, resamples them to 16kHz, and returns them as bidi_audio_input events that BidiAgent understands:

class WebRTCBidiInput:
    def __init__(self, track):
        self._track = track

    async def __call__(self):
        try:
            frame = await self._track.recv()
        except MediaStreamError:
            raise StopAsyncIteration
        resampled = _resampler.resample(frame)
        pcm = b"".join(f.planes[0] for f in resampled)
        return {
            "type": "bidi_audio_input",
            "audio": base64.b64encode(pcm).decode("utf-8"),
            "sample_rate": 16000,
        }

The WebRTCBidiOutput adapter does the reverse — it receives events from BidiAgent and pushes audio to the aiortc output track:

class WebRTCBidiOutput:
    def __init__(self, output_track):
        self._output_track = output_track

    async def __call__(self, event):
        if event.get("type") == "bidi_audio_stream":
            audio_bytes = base64.b64decode(event["audio"])
            self._output_track.add_audio(audio_bytes)
        elif event.get("type") == "bidi_interruption":
            self._output_track.clear()

On the frontend, the useWebRTCSession hook uses the AgentCore SDK for signaling:

const invoke = async (action, data = {}) => {
  const client = new BedrockAgentCoreClient({ region, credentials });
  const resp = await client.send(new InvokeAgentRuntimeCommand({
    agentRuntimeArn,
    runtimeSessionId: sessionId,  // ensures session affinity
    contentType: 'application/json',
    payload: new TextEncoder().encode(JSON.stringify({ action, data })),
  }));
  return JSON.parse(new TextDecoder().decode(
    await resp.response.transformToByteArray()
  ));
};

The full source is in the repo — the feat/webrtc branch has the local-only version, and feat/webrtc-agentcore has the full deployed version with Terraform.

Development tooling

I built this project using Kiro CLI, Amazon's AI development assistant. It handled the planning, code generation, debugging, and iterative deployment — including the many rounds of trial-and-error with WebRTC configuration that this post describes. The back-and-forth between writing code, deploying, checking logs, and fixing issues was a natural fit for an AI pair-programming workflow.

Try it yourself

To run locally:

git clone https://github.com/psantus/strands-bidir-nova.git
cd strands-bidir-nova
git checkout feat/webrtc
uv sync && make install-frontend
# Terminal 1:
make serve
# Terminal 2:
make serve-frontend

Open http://localhost:5173, click the microphone, and start talking.

For the deployed version on AgentCore, check out the feat/webrtc-agentcore branch and follow the README. You'll need a Bedrock Knowledge Base with some recipes, a Cognito user pool, and Docker for building the container image. A single terraform apply handles the rest.

If you'd rather start with the WebSocket version first, Darryl Ruggles' original post is the place to go.

Paul Santus is an independent cloud consultant at TerraCloud. He helps organizations build and deploy AI-powered applications on AWS. Connect with him on LinkedIn.

WebRTC (Web Real-Time Communication) — An open standard for real-time audio, video, and data communication directly between browsers and devices, using UDP-based transport. ↩
TURN (Traversal Using Relays around NAT) — A relay server that forwards media traffic when two peers can't connect directly. Both sides send their audio to the TURN server, which relays it to the other side. ↩
NAT (Network Address Translation) — A networking mechanism that maps private IP addresses to public ones. Most home routers and cloud VPCs use NAT, which prevents direct inbound connections. ↩
SFU (Selective Forwarding Unit) — A media server that receives audio/video tracks from participants and selectively forwards them to others, without mixing or transcoding. Used by LiveKit, Chime SDK, Daily, etc. ↩
SDP (Session Description Protocol) — A text format describing a multimedia session: codecs, transport addresses, and media types. In WebRTC, peers exchange SDP "offers" and "answers" to negotiate the connection. ↩
ICE (Interactive Connectivity Establishment) — A protocol for finding the best network path between two peers. It gathers candidate addresses (local, server-reflexive, relay) and tests connectivity between them. ↩

re:Invent25, jour 2 : le chemin vers l'IA

Paul SANTUS — Thu, 04 Dec 2025 08:54:18 +0000

Matt Garman ayant défloré la quasi-totalité des annonces hier (allant jusqu'au rythme d'une annonce de fonctionnalité toutes les 24 secondes dans un sprint de 10' en fin de keynote), le what's new est un peu plus vide ce matin.

Mais c'est l'occasion de prendre un peu de recul et de jeter un oeil aux nombreuses sessions (toutes mise en vidéo sur le compte Youtube @awsevents). Et hier, le thème était clairement : comment aller vers l'IA ? En préparant vos data.

Approche sémantique : S3 Vectors et Valkey

Les données vectorielles permettent aux LLMs de faire des rapprochements sémantiques entre une question, ou une conversation, et des documents (textes, images, vidéos) de votre base documentaire.

Jusqu'ici, pour utiliser ces données, il fallait utiliser une base de données dédiées, comme OpenSearch ou PostgreSQL avec pgvectors. Toute ça coûte un peu cher..

Sorti en pré-version en cours d'année, S3 Vectors est maintenant un service AWS pleinement supporté, avec un gain de performance notable. Il est maintenant directement intégré avec Bedrock Knowledge base.

Les agents IA peuvent donc désormais rechercher facilement des documents encodés sous forme de vecteurs.

Néanmoins, les agents coûtant également cher et, dans la pratique, répondront assez souvent aux mêmes questions. De la même manière que votre appli web peut utiliser un side-cache au niveau de la BDD pour éviter de trop la solliciter, vous pouvez désormais utiliser un cache sémantique avec Valkey

Pour savoir comment ça fonctionne, je vous partage ci-dessous une conférence à ce sujet que j'ai trouvée passionnante : "Optimize gen AI apps with semantic caching in Amazon ElastiCache (DAT451)".

Approche tabulaire : S3 Tables et Apache Iceberg

Dans de nombreuses entreprises, le défi reste encore de pouvoir mobiliser toute la donnée structurée pour de la BI ou du Machine Learning.

Tous les services d'analytics AWS sont désormais alignés pour supporter les tables Apache Iceberg dans sa version v3 (Redshift, qui pouvait seulement les lire, peut maintenant les écrire).

Côté Athena : il y a de nombreuses évolutions !

certaines sont quasi-invisibles pour nous, mais permettent des gains de performance (et de coût) considérables : l'indexation des colonnes dans les fichiers Parquet, le fait de pousser de plus en plus de prédicats au niveau stockage (et donc éviter de récupérer et traiter en mémoire de la donnée inutile pour la requête en cours).
d'autres sont de petits trucs pratiques : depuis juin, il n'y a plus besoin de gérer l'emplacement S3 d'arrivée du résultat de vos requêtes Athena.

Parmi les évolutions qu'il me semble important de noter : l'arrivée des vues matérialisées dans Glue !!!

Rafraichies sur événement ou de façon planifiées, ces vues vont vous permettre de mettre en place des pipelines complexes avec des étapes intermédiaires matérialisées, tout en SQL, sans avoir à gérer la mise à jour des données.

Ce talk détaille l'ensemble des évolutions sur Redshift et Athena

Et l'infra sous-jacente ? S3 !

Une des questions que je me suis posées il y a quelques temps était : quelles sont les performances maximales que je peux tirer de S3 ? Si vous prenez une lambda en python et que vous faite un basique GetObject, vous aurez 70-100Mbps par secondes. Mais on peut aller beaucoup plus vite.

Dans ce talk Ian Mc Garry, directeur du développement logiciel sur S3, montre comment vous pouvez aller chercher une performance quasi-illimitée grâce à l'AWS Common Runtime: ça parle de "ListParts", de "Range GET" côté client, et côté back, de préfixes, de directory buckets / One-Zone et de session durable (s3:CreateSession) pour gagner du temps sur l'authentification de chaque requête.

Si vous souhaitez savoir comment fonctionne l'infra S3, je vous conseille deux conférences très riches :

Tout d'abord l'innovation talk d'Andy Warfield, VP Storage d'AWS qui donne un aperçu des évolutions de l'infra sous-jacente au service
Ensuite, celui de Carl Summers qui explique comment S3 gère ses logs

re:Invent25, jour 1 : « boom »

Paul SANTUS — Wed, 03 Dec 2025 00:51:23 +0000

Je suis le "What's new" d'AWS de façon quasi quotidienne depuis plus de 7 ans. J'ai trouvé certaines éditions de re:Invent excitantes, d'autres décevantes.. mais j'ai rarement éprouvé le sentiment de submersion face à l'explosion d'annonces du jour.

IA : des agents autonomes

L'annonce la plus importante de la Keynote de Matt Garman ↗️ est sans doute la disponibilité immédiate de 3 agents à durée de vie longue.

Jusqu'ici, l'IA agentique s'appuie sur des agents qui doivent à chaque tâche redécouvrir le contexte (comment est structuré le projet, quels profils CLI sont dispo pour qu'ils accèdent aux API, ce qu'ils ont le droit de faire ou non, les choix d'architecture) ; il y a besoin d'interactions fréquentes avec le "pilote" pour les garder "on-track". L'agent Kiro autonome↗️ se propose de résoudre cette limite avec des agents tournant en tâche de fond et capitalisant sur l'ensemble des tâches effectuées. Arrêtons de babysitter nos agents et commençons à les manager !

Deux autres agents font leur entrée :

l'agent DevOps ↗️ qui, en situation d'incident, va pouvoir proactivement analyser l'ensemble des logs, métriques, et déterminer la cause de l'incident, proposer des actions résolutives et correctives.
l'agent de Sécurité ↗️ qui va pouvoir évaluer tant le code lors de sa production (à chaque PR) que réaliser des Pentests.

Ces agents sont le déploiement, à l'échelle, des technologies que j'ai pu présenter lors du dernier AWS Poitiers User Group :

Des frameworks d'agents comme Strands permettent de donner aux LLM des "yeux" et des "mains" pour voir et agir ;
Bedrock AgentCore, service qui héberge les agents, permet maintenant ↗️ d'évaluer les agents (ont-ils résolu la tâche ? en faisant appel aux bons outils ?) et de contrôler rigoureusement leur exécution par des politiques exprimées en langage naturel ("tu ne feras pas une offre commerciale à un client en recouvrement") traduites dans un langage formel, Cedar.

IA : les modèles d'AWS, ceux des tiers.. et le vôtre?

Pour faire tourner ces agents, au début, il faut un LLM.

AWS vient d'ajouter 20 modèles "open-weight" (deepseek, GPT, ...) à Bedrock
La firme de Seattle publie également la v2 de sa suite de modèles Nova, avec de vraies innovations : Nova Omni ↗️ un modèle multimodal capable de raisonnements avancés, Nova Sonic v2 **↗️, modèle speech-to-speech à basse latence qui alimente désormais **Amazon Connect↗️, le centre de contact omni-canal d'AWS qui est maintenant présenté comme "staffé par des agents humains et IA", ainsi que Nova Lite et Pro.
Nova Forge ↗️ propose de partir de ces modèles et d'entraîner sur vos données (complétées par des données fournies par AWS pour que le modèle ne perde pas ses capacités généralistes) afin d'acquérir une vraie compréhension de votre métier, qu'un simple RAG ne permet pas d'obtenir.
Nova Act ↗️, modèle capable sans ajout d'outil tiers, de naviguer sur le web ou d'exécuter du code.

Cela sans compter AWS Transform, un service d'agents dédiés à la refonte du legacy (sortie de VM Ware, d'Oracle, de Windows... ) ou l'inclusion dans d'autres services d'agents d'upgrade (EMR permet de mettre à jour du vieux code Spark↗️ et il faut s'attendre à voir la même chose sur des Lambda dans les prochains jours)

Une infra "IA-ready"

De nombreux services annoncent des évolutions pour être adaptés à l'IA :

comme API Gateway (cf. post sur Pre:Invent), Bedrock AgentCore Runtime supporte maintenant du streaming bidirectionnel ↗️,
S3 Vector ↗️ devient généralement disponible, s'intègre avec Bedrock Knowledge bases et permet des recherches à partir de 100ms de latence (pour les recherches fréquentes) à 1s (pour les moins fréquentes) sur des milliards de vecteurs.
Le Support annonce des plans ↗️ où un premier niveau de réponse par l'IA permet, à moindre coût, d'avoir un opérateur humain en moins de 30min sur un incident de prod.

Et pour les autres services ?

Lambda connaît deux évolutions majeures :

Lambda Durable Functions↗️ permet d'interrompre en cours d'exécution, puis de reprendre des exécutions Lambda jusqu'à 1 an après (après un "sleep" ou réception d'un callback), sans payer aucun frais pendant la phase de pause.
Lambda Managed Instances↗️ permet à ceux qui ont des charges de travail relativement stables ou des besoins de hardware spécifiques (pas encore de GPU, mais on parie que ça va venir?) de bénéficier du tarif d'EC2 avec la simplicité opérationnelle de Lambda.

Et aussi

S3 Tables offre désormais une classe de stockage type "Intelligent-tiering"↗️ qui permet de réduire fortement les coûts des tables Iceberg.
Les bases de données↗️ offrent désormais des savings plans. Mieux vaut tard que jamais !! Economies massives à la clé.
S3 Storage Lens↗️ offre plus de visibilité sur l'utilisation du stockage s3 (distribution de la taille des objets, requêtes les plus coûteuses etc.)
SageMaker offre désormais MLFlow en mode serverless↗️.. gratuitement ??? (Pricing – The new serverless MLflow capability is offered at no additional cost. Note there are service limits that apply) à suivre.

Pre:Invent : Semaine 1, que retenir ?

Paul SANTUS — Mon, 24 Nov 2025 09:08:41 +0000

Les semaines qui précèdent Re:Invent sont intéressantes pour les entreprises déjà utilisatrices d'AWS, car elles regorgent d'annonces de nouvelles fonctionnalités ou d'optimisation des services existants.

Ces fonctionnalités ne sont peut-être pas suffisamment "marketing" pour paraître pendant re:Invent, mais elles peuvent parfois grandement améliorer l'expérience utilisateur.

Voici quelques fonctionnalités clés de cette première semaine de "pre:Invent" :

CloudFront offre des forfaits à prix fixe. J'en ai parlé ici assez longuement. Si votre use case tombe dans les limites prévues, vous ferez de belles économies.
Le response streaming est désormais possible sur API Gateway (pour les API Rest).
C'est bien sûr une fonctionnalité tirée par l'IA / les Chatbots, qui permet aux clients de recevoir le premier octet rapidement et de se voir transmettre la suite de la réponse dès que le LLM l'a calculée... mais ça pourrait avoir de bien plus larges applications
Utilisez vos rôles IAM sur des services tiers avec OAuth! IAM supportait déjà OAuth dans le sens entrant (ça permet notamment à GitHub Actions ou GitLab CI de venir agir sur vos comptes AWS par un AssumeRoleWithWebIdentity) ; grâce à IAM Outbound Identity Federation, appeler GetWebIdentityToken vous donnera un token JWT, il suffira de déclarer l'issuer URL fournie par IAM sur votre fournisseur de services et celui-ci acceptera les identités IAM. Plus de raison d'avoir des secrets à durée de vie longue !
Gérer ses permissions sur S3 devient plus facile avec le support de l'ABAC (Attribute-based access control), c'est-à dire la gestion des permissions par les tags/étiquettes).

Mais aussi

Grâce à l'IA, StepFunctions devient plus accessible (sans devoir apprendre le détail du domain-specific language). Du coup AWS publie de l'outillage pour tester facilement votre Step Function localement.
Redshift peut maintenant écrire dans des tables Iceberg. L'ETL full SQL a de beaux jours devant lui.
ECS lance "express mode", un wizard qui permet de créer facilement un service à partir d'une image docker. Bien pour découvrir le service, mais de toute façon, ensuite, vous créerez tout avec de l'Infra-as-Code, n'est-ce pas ?

A bientôt !

CloudFront : de nouveaux plans à prix fixes !

Paul SANTUS — Mon, 24 Nov 2025 08:33:09 +0000

« Pre:Invent » est là : le What's New d'AWS s'allonge (suivez-moi ici ou sur LinkedIn pour suivre l'actualité de re:Invent en français pendant ces quelques jours) alors que Re:Invent démarre dans 2 semaines. Parmi les annonces de ces dernières heures, l'une mérite d'être relevée : des offres CloudFront à prix fixe !

Le modèle économique principal du Cloud est le pay-as-you-go : on démarre à $0 et on les frais augmentent avec l'usage réel. Mais certains clients éprouvent des difficultés à estimer leurs frais à l'avance, ou à les corréler avec leurs revenus. C'est en particulier vrai pour les données sortantes et CloudFront représente une partie non-négligeable de ces frais.

Des forfaits "all-inclusive" pour CloudFront

CloudFront propose désormais 4 forfaits "tout-en-un" qui conviendront à la plupart des besoins, mais laisseront néanmoins de côté certains (cf. business case ci-dessous) :

Les plans permettent tous de mobiliser les services suivants :

CloudFront (CDN)
WAF (plus ou moins riche fonctionnellement selon les plans) et protection DDoS
Ingestion des CloudWatch Log correspondant aux services du plan DNS (Route 53)
Certificats TLS
Serverless Edge Compute (CloudFront Functions)
Stockage S3 (sous forme de crédits qui viendront compenser les frais S3 induits par l'activité CloudFront)

Ces plans sont au nombre de quatre :

Un plan gratuit permettra de servir 1 millions de requêtes CloudFront (100 Go de traffic sortant), et incluant 5Go de stockage S3, et des fonctionnalités WAF de base
Pro : pour $15 on a 10m de requêtes et 50To de trafic sortant, des fonctionnalités WAF plus avancées (protection des vulnérabilités PHP connues + SQL injection)
Business : pour $200, on a l'ensemble du WAF, 125m de requêtes (et toujours 50To de trafic sortant)
Premium : pour $1000 des fonctionnalités avancées qui seront inutiles pour la plupart (mTLS) mais surtout 500m de requêtes mensuelles.

Ils viennent s'ajouter aux possibilités actuelles sans les dégrader :

Il reste possible d'être en mode "pay-as -you-go".
On bénéficie toujours de 1To de données sortantes par mois "always free"
Les savings bundle et private pricing agreement restent accessibles

Une distribution qui dépassera sa limite verra ses performances dégradées (mais AWS ne dit pas de combien.. +1s à chaque appel? à voir avec l'expérience)..

Attention néanmoins :

il y a un certain nombre de fonctionnalités non-supportées par les plans CloudFront - par exemple si votre WAF utilise des règles de prévention de vol de compte (ATP), vous ne pourrez pas activer ces plans.
Comme l'indique Jason Butz ici il y a également des limites liées à chaque Plan. Parmi celles-ci, à mon sens, interdire les Custom origin request rules et Custom caching roles est rédhibitoire pour les Plans Free et Pro hormis pour des sites purement statiques.

Un business case tiré d'un de mes clients

Ces offres permettent-ils de répondre à tous les besoins : pour y répondre, regardons un de mes clients préférés (oui, vous !) , qui a 2 distributions CloudFront :

	Requêtes / mois	Débit / mois	Coût / mois	WAF / mois
Distribution 1	243m	4 To	$600	$200
Distribution 2	40m	7 To	$600	$29

Clairement,

La Distribution 2 pourra bénéficier d'un plan business, soit une économie directe de $429/mois.
Mais pour la Distribution 1, les nouveaux Plans de CloudFront ne changeront pas la donne. Le plan à $200 n'offre pas assez de requêtes... et à 243m de requêtes (en croissance), on ne va probablement pas faire d'effort pour découper la distribution en deux (au risque qu'une des sous-partie dépasse 125m de requêtes)

En conclusion les Plans à prix fixe permettront de couvrir un large éventail de clients... mais certains devront rester sur du Pay-as-you-Go. L'occasion de redécouvrir les "Savings Bundle" CloudFront (qui m'annoncent une économie de $300 mensuels sur le niveau d'usage actuel sur les distributions précitées).

Great post if you have need for custom instances (GPUs...) to host your containers

Paul SANTUS — Wed, 22 Oct 2025 20:28:21 +0000

Piotr Pabis for AWS Community Builders

Oct 22 '25

Let's try Managed ECS Instances

#aws #containers #ecs #docker

Comments

8 min read

AWS : une panne « mondiale » ?

Paul SANTUS — Tue, 21 Oct 2025 13:15:23 +0000

AirBnB, Slack, SnapChat par terre ! Les médias se sont fait l'écho (par exemple ici Le Monde avec l'AFP) d'un incident majeur touchant l'infrastructure d'AWS, parlant de « panne mondiale ». Le terme est-il approprié ?

Nb : il ne s'agit pas de "défendre" AWS, ni de nier l'ampleur de l'incident, mais de donner l'opportunité aux moins "tech" de comprendre ce qui se cache derrière.

Quelques exemples d'impacts chez mes clients

L'un de mes clients a toute son infrastructure sur les datacenters d'AWS en France (on parle de "région" de Paris, ou eu-west-3). Il n'a juste eu aucun impact de l'incident. Business as usual. Même trafic, mêmes temps de réponses, même nombre de commandes sur son site d'e-commerce.

Un autre client a une partie de son infra à Paris et l'autre aux Etats-Unis, en Virginie du Nord (us-east-1), la région en cause dans l'incident. Pendant la durée de l'incident, les envois de mails via le service SES ont échoué. Les temps de réponses ont augmenté et le nombre de messages en file d'attente traités par seconde a drastiquement baissé, le débit étant volontairement limité par AWS dans la phase de "recovery" (pour ne pas submerger des machines qui démarrent sous un flux de requêtes d'autant plus volumineux que tout le monde "retry").

Enfin, pendant tout l'incident, j'ai de mon côté été dans l'impossibilité de mettre à jour l'infrastructure de mes clients (ce que je fais habituellement en appelant les services d'AWS par un outil appelé "Terraform").

Un incident régional, des impacts mondiaux

Alors que s'est-il passé ? Sans entrer trop dans les détails techniques, AWS a eu - sur la région us-east-1 un problème d'adressage réseau (DNS) pour un de ses services, DynamoDB, une base de données ultra-performante qui est utilisée par de nombreux autres services AWS (AWS dénombrait environ 70 services impactés).

Pourquoi cet incident, semble-t-il local, a t-il eu un impact si large ? Aurait-il été identique si une autre région, par exemple Europe (Milan), avait connu le même incident ?

Pour comprendre cela, il faut comprendre deux notions clés :

Data-Plane vs Control-Plane : pour consommer un service, je mets en place du paramétrage, c'est le control plane ; ce paramétrage est ensuite utilisé par AWS pour opérer une ressource, c'est le data plane. Par exemple : je démarre un cluster de base de données MySQL (control plane), ce cluster sert du trafic SQL, enregistre des transactions sur des disques durs, écrit des logs (data plane).

L'empreinte géographique d'un service : certains services AWS sont conçus pour fonctionne à l'échelle d'un data center (pour faire simple, en réalité à l'échelle d'une zone de disponibilité). C'est le cas quand je déploie une machine Linux. D'autres fonctionnent à l'échelle d'une région (de sorte qu'ils sont capable de vivre avec la perte d'un datacenter). D'autres enfin fonctionnent à l'échelle mondiale.

Ces deux notions se conjuguent : par exemple IAM a son control plane centralisé (je définis mes politiques d'autorisation à un seul endroit) puis la configuration est distribuée sur toutes les régions, de sorte que celles-ci peuvent appliquer ces politiques eu toute autonomie (data plane régionalisé).

Le tableau ci-dessous donne quelques exemples :

Que s'est-il passé ?

Il se trouve que la région us-east-1 sert de control plane centralisé pour un certain nombre (voire un nombre certain) de services AWS. Quand un incident majeur survient sur cette région (historiquement tous les 2 à 4 ans), cela impacte donc :

le control plane de tous ces services
le data plane des services sur cette région (le data plane des services sur les autres régions est sauf, d'où le business-as-usual de mon premier client).

Quelles leçons en tirer ?

Architecturer pour la haute-disponibilité ! « Tout échoue tout le temps, tout tombera en panne un jour» dit le Dr. Werner Vogels, CTO d'Amazon. Si l'incident a eu un tel impact visible du public c'est que les opérateurs des services cités par la presse n'ont pas jugé bon (ou su) architecturer leurs services pour être résilients à la perte de la région us-east-1. Cela peut-être un choix éclairé (mon client précité a choisi d'être KO si la région de Paris tombait, confiant qu'AWS saurait remonter l'infra plus rapidement que lui ne saurait mettre en oeuvre un Plan de Reprise d'Activité, avec toutefois un backup externalisé juste au cas où...)
Persister d'abord, traiter ensuite : mon deuxième client ne pouvait pas envoyer ses mails... et les appels d'API pour les envoyer se faisaient au beau milieu du traitement d'une transaction. Retour d'expérience et évolution dans les prochains jours : il va désormais stocker ces tâches dans une file d'attente et la dépiler avec gestion du retry, une dead letter queue etc.

Voilà, vous avez maintenant quelques base sur la conception de l'infrastructure mondiale d'AWS !