Les Function URLs Lambda pour les endpoints mono-fonction comme les webhooks et les outils internes, les API HTTP d'API Gateway pour la plupart des API serverless publiques, les API REST quand l'accès est contractuel (plans d'utilisation, clés d'API, WAF), et un ALB dès que le trafic est assez soutenu pour que la facturation à la requête perde face à un coût horaire. La capacité brute départage rarement : les quatre savent exposer du Lambda en HTTPS. Les vraies différences sont les options d'authentification, le throttling, le support WAF et la structure de coût.
Quand une Function URL Lambda suffit-elle ?
Une Function URL suffit quand une seule fonction Lambda porte tout l'endpoint et que ses appelants peuvent s'authentifier via AWS IAM, ou s'en passer complètement. L'URL elle-même ne coûte rien : vous ne payez que l'invocation Lambda. En contrepartie, vous renoncez au throttling, aux quotas, au WAF et aux domaines personnalisés.
Une Function URL est un endpoint HTTPS accroché directement à une fonction, avec support du streaming de réponse et sans la couche de routage d'API Gateway (voir la documentation Lambda). Cette absence coupe dans les deux sens : rien à configurer, mais rien non plus entre Internet et votre fonction. Une URL publique en mode NONE laisse n'importe qui consommer vos invocations et votre concurrence, et la concurrence réservée est le seul frein. Réservez les URL non authentifiées aux webhooks qui vérifient une signature dans le code, et préférez AWS_IAM pour les appels de service à service.
Qu'apporte une API HTTP d'API Gateway en plus ?
Une API HTTP ajoute une vraie porte d'entrée : des routes vers plusieurs fonctions, des authorizers JWT pour Cognito ou tout fournisseur OIDC, du throttling par route, des domaines personnalisés et des stages. Sa structure de coût est purement à la requête : une API à trafic faible ou irrégulier ne coûte presque rien au repos.
Cette forme à la requête est tout l'intérêt (les paliers sont détaillés sur la page de tarification officielle). Pas de plancher horaire, pas de planification de capacité, et l'authorizer JWT rejette les jetons invalides avant l'exécution de votre code : vous ne payez pas Lambda pour du bruit non authentifié. Le throttling s'applique par stage ou par route, de quoi protéger un backend, mais il n'y a ni clés d'API, ni plans d'utilisation, ni attachement WAF direct. Pour la plupart des API serverless publiques en 2026, c'est notre choix par défaut.
Quand faut-il encore une API REST ?
Choisissez une API REST quand l'accès est contractuel : les plans d'utilisation mesurent et limitent chaque clé d'API, la validation des requêtes rejette les payloads malformés avant l'invocation, AWS WAF s'attache directement à un stage, et les endpoints privés gardent l'API dans un VPC. Vous acceptez un tarif à la requête plus élevé pour cette couche de gestion.
Commercialement, les plans d'utilisation sont la fonctionnalité qui compte : quotas et limites par client forment la base mécanique des offres partenaires, et nous avons détaillé comment les transformer en engagements contractuels dans notre guide sur la conception de SLA pour API partenaires. Validation des requêtes et WAF déplacent les rejets peu coûteux hors de votre code. AWS maintient une comparaison fonctionnalité par fonctionnalité des deux variantes : lisez-la avant de conclure qu'il vous faut REST, car beaucoup d'équipes n'ont besoin que du JWT et du throttling.
Vous hésitez entre facturation à la requête et coût horaire pour votre API ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Quand un ALB bat-il API Gateway ?
Un ALB gagne quand le trafic est soutenu et élevé, ou quand Lambda côtoie des conteneurs et des instances dans un même VPC. Sa structure de coût combine un tarif horaire et des unités de capacité (LCU) : le volume de requêtes ne multiplie pas la facture comme le fait la tarification à la requête.
Le compromis est symétrique. À faible volume, l'ALB tourne à vide à son plancher horaire pendant qu'une API HTTP coûte quelques centimes ; passé un débit soutenu, les courbes se croisent et l'ALB devient moins cher. Modélisez les deux formes sur votre trafic réel (voir la page de tarification ELB). Un ALB route un même nom d'hôte vers des cibles Lambda et des cibles VPC, accepte WAF directement et authentifie les utilisateurs via OIDC ou Cognito au niveau du répartiteur. Il n'offre ni throttling, ni quotas, ni clés d'API, et les réponses des cibles Lambda sont plafonnées à 1 Mo à l'heure où nous écrivons.
Comment les quatre options se comparent-elles ?
Le tableau ci-dessous compare authentification, throttling, support WAF et structure de coût. Lisez d'abord la dernière colonne : chaque option a un profil de trafic et de sécurité où elle gagne nettement, et le mauvais choix se paie soit en facture surdimensionnée, soit en protection manquante reconstruite à la main.
| Option | Authentification | Throttling et quotas | WAF | Structure de coût | Quand elle gagne |
|---|---|---|---|---|---|
| Function URL | AWS_IAM ou aucune | Aucun (concurrence réservée seulement) | Non (via CloudFront uniquement) | Gratuite, seul Lambda est facturé | Webhooks mono-fonction, endpoints internes |
| API HTTP | JWT, IAM, authorizer Lambda | Throttling par stage et par route, ni clés ni quotas | Pas d'attachement direct | Faible coût à la requête | API serverless publiques, trafic irrégulier ou modeste |
| API REST | IAM, Cognito, authorizer Lambda, clés d'API | Throttling plus plans d'utilisation et quotas | Oui, direct | Coût à la requête plus élevé | API partenaires et monétisées, endpoints privés |
| ALB | OIDC ou Cognito au niveau du répartiteur | Aucun | Oui, direct | Horaire plus unités de capacité | Volume soutenu, cibles Lambda et VPC mélangées |
Faut-il placer CloudFront devant une Function URL ?
Oui, quand la Function URL gratuite vous convient mais qu'il vous manque un domaine personnalisé, du cache ou un WAF. CloudFront apporte les trois : attachez WAF à la distribution, pointez-la vers l'URL, puis verrouillez l'origine avec l'origin access control (OAC) pour empêcher tout contournement.
Avec OAC, CloudFront signe les requêtes vers l'origine en IAM et la Function URL reste en AWS_IAM : le seul chemin d'entrée passe par la distribution. Ce montage couvre une part surprenante des cas d'usage d'une API HTTP, avec une autre structure de coût. Sachez toutefois vous arrêter : dès qu'il vous faut des quotas par client, des clés d'API ou de la validation de requêtes, vous êtes en train de reconstruire API Gateway à la main. Le choix et le câblage de cette couche edge font partie de notre travail de développement d'API.
Check-list de décision
Parcourez ces critères dans l'ordre et arrêtez-vous à la première correspondance :
- Une seule fonction, appelants IAM ou signature vérifiée : Function URL.
- API publique, trafic irrégulier ou modeste, jetons OIDC : API HTTP.
- Consommateurs contractuels ou payants, clés, quotas, WAF, endpoints privés : API REST.
- Volume soutenu et élevé, ou Lambda mélangé à des cibles VPC : ALB.
- Origine gratuite mais besoin de domaine personnalisé, de cache ou de WAF : CloudFront devant une Function URL avec OAC.
- Point de bascule incertain : modélisez un mois de trafic réel sur les deux structures de coût avant de trancher.