CloudFront rend ses forfaits à tarif fixe pilotables par l’API et l’IaC
Le 3 septembre 2026, AWS ouvre la gestion programmatique des forfaits à tarif fixe de CloudFront via l’API PricingPlanManager, la CLI, CloudFormation et le CDK. Les équipes peuvent désormais codifier l’abonnement, le changement de palier et la résiliation d’un prix mensuel sans dépassement, avec une approbation à deux phases pour éviter toute facturation non voulue.
Novembre 2025. AWS lance les forfaits à tarif fixe de CloudFront, promettant un prix mensuel unique sans frais de dépassement. 3 septembre 2026. La gestion de ces forfaits sort de la console et devient pilotable par l’API, la CLI, CloudFormation et le CDK. Plusieurs centaines de milliers de clients. C’est l’ordre de grandeur revendiqué par AWS pour l’adoption de la grille en quatre mois. Pourquoi c’est important : pour la première fois, un coût de CDN — historiquement le plus imprévisible en cas de pic — peut être figé en une valeur mensuelle écrite dans un dépôt, revue en pull request et déployée comme n’importe quelle ressource d’infrastructure.
Un prix fixe qui échappait encore au code
Le paradoxe des forfaits à tarif fixe tenait en une phrase : AWS vendait la prévisibilité, mais uniquement au clic. Depuis novembre 2025, souscrire un forfait, en changer de palier ou le résilier imposait de passer par la console CloudFront, une action manuelle, impossible à reproduire entre les environnements, à auditer dans un dépôt ou à faire valider par une revue de code. Une équipe qui provisionne son CDN en IaC se retrouvait avec un angle mort : tout le périmètre était déclaratif, sauf la facturation.
L’annonce du 3 septembre 2026 comble exactement ce trou. CloudFront expose désormais ses forfaits à travers le service PricingPlanManager, accessible via la CLI, les SDK, CloudFormation et le CDK. Concrètement, on peut souscrire, changer de palier et résilier un forfait de façon programmatique, avec le même cycle de vie que le reste de l’infrastructure. La grille tarifaire devient un objet de configuration comme un autre.
Ce que couvre un forfait
Un forfait à tarif fixe agrège une liste de services qu’un site ou une application consomme presque toujours ensemble. Pour un prix mensuel unique, il couvre le CDN CloudFront, AWS WAF, la protection DDoS, la gestion de bots, le DNS Route 53, l’ingestion de logs CloudWatch, le calcul edge serverless et un crédit de stockage S3. Quatre paliers structurent l’offre :
| Palier | Prix mensuel | Positionnement |
|---|---|---|
| Free | 0 $ | Découverte, petits sites |
| Pro | 15 $ | Sites de production légers |
| Business | 200 $ | Trafic soutenu, Bot Control |
| Premium | 1 000 $ | Fort trafic, mTLS viewer |
Chaque palier fixe une allocation d’usage pensée pour un niveau de trafic, mais l’allocation n’est pas une limite dure : AWS notifie à 50 %, 80 % et 100 %, et absorbe les dépassements sans surfacturer. On peut aussi mélanger forfaits et pay-as-you-go sur des distributions différentes d’un même compte, ce qui évite de tout basculer d’un coup.
PricingPlanManager, la nouvelle brique
Le service PricingPlanManager est la pièce technique de l’annonce. Son endpoint est disponible dans la région us-east-1, et CloudFront est aujourd’hui la seule plan family supportée. Deux choix de conception méritent l’attention d’un SRE : la concurrence optimiste et l’approbation à deux phases.
Toute opération de modification s’appuie sur un ETag. On lit l’abonnement, on récupère son eTag, puis on repasse cette valeur dans le paramètre --if-match de l’écriture. Si l’abonnement a changé entre-temps, l’appel échoue avec une ConflictException plutôt que d’écraser un changement concurrent :
# Lister les abonnements du compte
aws pricing-plan-manager list-subscriptions --region us-east-1
# Lire l'ETag d'un abonnement avant toute modification
SUBSCRIPTION_ARN="arn:aws:pricingplanmanager:us-east-1:111122223333:subscription/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
ETAG=$(aws pricing-plan-manager get-subscription \
--arn "$SUBSCRIPTION_ARN" \
--query 'eTag' \
--output text)
# Passer un abonnement au palier Premium en repassant l'ETag
aws pricing-plan-manager update-subscription \
--arn "$SUBSCRIPTION_ARN" \
--if-match "$ETAG" \
--plan-tier PREMIUMLe cycle de vie d’un abonnement passe par des statuts explicites — ACTIVE, PENDING_APPROVAL, SYNC_IN_PROGRESS et FAILED — et l’application d’un changement prend de 2 à 5 minutes. Un échec laisse un statusReason lisible pour comprendre la cause, au lieu d’un silence de facturation.
L’approbation à deux phases, la sécurité financière
La décision la plus utile de PricingPlanManager est le choix du mode d’approbation à la création d’un forfait payant. Le mode IMMEDIATE active la facturation en une seule étape. Le mode MANUAL crée l’abonnement en PENDING_APPROVAL et exige un second appel, ApprovePaidSubscription, pour démarrer la facturation. Un forfait payant activé ne peut pas être annulé pendant le mois en cours, et le palier Premium atteint 1 000 $ par mois : activer une facturation par erreur dans un pipeline n’est pas anodin.
AWS recommande donc le mode MANUAL pour tout workflow programmatique, et propose une séparation des permissions IAM pour l’imposer techniquement : le rôle d’automatisation reçoit pricingplanmanager:CreateSubscription, tandis que pricingplanmanager:ApprovePaidSubscription reste réservé à un rôle à approbation humaine.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "pricingplanmanager:CreateSubscription",
"Resource": "*"
}
]
}Avec ce découpage, un agent ou un pipeline peut préparer un changement de palier sans jamais déclencher la facturation : c’est exactement le garde-fou qui manquait pour intégrer le coût du CDN au GitOps.
Les ajouts de la grille depuis novembre
La maturité de l’offre s’est aussi jouée sur le périmètre fonctionnel. Au lancement, certaines distributions ne pouvaient pas basculer sur un forfait parce qu’elles utilisaient des fonctions non encore supportées. AWS a comblé ces trous en quatre mois. Lambda@Edge et la CAPTCHA des règles WAF sont désormais incluses — les invocations Lambda@Edge restent facturées en pay-as-you-go par-dessus le forfait. Le mTLS est arrivé en deux déclinaisons : origin mTLS à partir du palier Business, viewer mTLS en Premium.
Le tableau de bord AI activity, inclus dès le palier Pro, ajoute la visibilité sur le trafic des bots et agents IA qui frappent l’application — tendances, bots les plus actifs, chemins les plus sollicités. Les contrôles de blocage, via WAF Bot Control, restent réservés au Business et au-dessus. L’intention est claire : un forfait ne doit plus jamais être un compromis qui dégrade la sécurité d’une distribution existante.
Comment un forfait absorbe un pic
La promesse « pas de dépassement » mérite une lecture précise. L’allocation mensuelle n’est pas un plafond : le premier pic, jusqu’à trois fois l’allocation, est intégralement absorbé dans le mois. Au-delà, l’excédent est évalué sur plusieurs mois, et seuls des dépassements significatifs et prolongés conduiraient AWS à ajuster la livraison du trafic — sans jamais facturer de surcoût. La sortie est toujours la même : monter de palier.
Cette mécanique change l’équation pour une équipe qui redoute le viral moment. Le pire scénario n’est plus une facture surprise mais une invitation à revoir le palier. Pour la prévisibilité budgétaire, c’est un progrès ; pour le finops, c’est un déplacement de la vigilance — du « combien ça va coûter » vers le « dans quel palier je vis réellement ».
Ce que ça change pour le FinOps
La bascule d’un coût variable à un coût fixe déplace la nature de la vigilance financière. En pay-as-you-go, la question est « combien ce pic m’a coûté » — une réponse qui arrive après coup, sur la facture. Avec un forfait, la question devient « dans quel palier je vis réellement », et la réponse se lit en temps réel : la console affiche l’usage historique face à l’allocation de chaque palier lors d’une conversion ou d’un changement.
Pour une équipe FinOps, le forfait n’est pas une économie automatique : c’est un transfert de risque. On échange la volatilité d’une facture contre le coût d’un palier potentiellement surdimensionné en période creuse. Le bon réflexe est de choisir le palier sur la médiane de trafic, pas sur le pic, et de réévaluer la distribution chaque trimestre — désormais possible par le code, donc automatisable.
Verdict
Si vous provisionnez déjà CloudFront en IaC et que votre trafic est stable ou prévisible, basculez vos distributions sur un forfait à tarif fixe et gérez-le via PricingPlanManager en mode MANUAL : vous figez le coût mensuel, vous gardez l’audit en dépôt, et vous évitez la facturation accidentelle grâce à la séparation des permissions IAM.
Si votre trafic est fortement variable mais sujet à des pics de viralité, le forfait reste pertinent précisément parce qu’il absorbe les pointes sans surcoût : calculez le palier sur votre médiane, pas sur votre pic.
Dans tous les cas, commencez par la console pour lire votre usage historique face à chaque allocation, puis migrez la décision vers le code. Un coût de CDN écrit dans un dépôt est un coût que l’on peut discuter, auditer et optimiser — ce qu’aucun clic de console ne permettra jamais.