Gateways cloud-native 1 day

AWS API Gateway en production : clinique des pannes (Course #aws-apigw-clinic)

For ingénieurs plateforme, SRE, développeurs d'API, architectes cloud.

S'inscrire à ce cours Toutes les formations
Réf#aws-apigw-clinic
Durée1 jour
Formats4 modalités
Certif—
PrérequisAucun

À la fin, vous saurez

À l'issue de cette formation, vous saurez exploiter un parc Amazon API Gateway face à ses limites publiées — registre des plafonds, budget de throttle au niveau du compte et suite de tests des transformations de requête — afin que le trafic d'une équipe voisine comme un en-tête supprimé cessent d'être découverts en production.

Cas fil rouge

Pellingham Grocers exploite ses API de vitrine, de préparation de commande et fournisseurs en mélangeant REST et HTTP APIs dans un seul compte et une seule Région AWS, avec un pic à 4 100 req/s pendant les promotions du jeudi. Un endpoint de lot fournisseur a été throttlé en pleine promotion par le trafic d'une équipe sans rapport, et un autre incident a demandé 3 jours de diagnostic faute des corps de requête nécessaires, absents des logs. L'ingénierie veut chaque plafond plateforme recensé et chaque transformation imposée par la gateway couverte par un test avant la prochaine saison de pic.

Programme chaque ligne est quelque chose que vous faites

4 modules · 12 sujets · dans l'ordre du cours

  1. Module 1

    Un compte, un budget de throttle

    Objectif. Modéliser le quota de throttle du compte comme une ressource partagée et le répartir délibérément entre les équipes.

    • Établir le plafond partagé : le quota de throttle vaut par compte et par Région, tous types confondus — HTTP, REST, WebSocket et rappel WebSocket
    • Vérifier la Région avant de supposer de la marge — 13 Régions nommées démarrent à 2 500 RPS et 1 250 en burst, et non 10 000
    • Répartir les throttles par stage et par méthode pour qu'aucune API ne consomme le budget partagé, en notant que le seau de burst n'est pas paramétrable par le client
  2. Module 2

    Les plafonds rencontrés par accident

    Objectif. Recenser les plafonds de configuration franchis par une conception et chiffrer la contrepartie de chaque relèvement.

    • Arbitrer timeout contre débit : porter le timeout d'intégration de 29 s vers 300 s peut exiger de réduire le quota de throttle du compte
    • Vérifier l'éligibilité avant de bâtir dessus, les REST APIs edge-optimized et les HTTP APIs ne pouvant pas bénéficier du relèvement
    • Recenser les plafonds silencieux — templates de mapping à 300 Ko, charges WebSocket de 128 Ko avec trames de 32 Ko fermant sur le code 1009, et réponse 413 non personnalisable
  3. Module 3

    La requête que reçoit le backend

    Objectif. Comparer requête client et requête backend, et couvrir par un test chaque transformation imposée par la gateway.

    • Localiser la rupture d'identité : l'en-tête Authorization est supprimé s'il porte une signature SigV4 ou si l'autorisation AWS_IAM est utilisée, les autres étant remappés en X-Amzn-Remapped-*
    • Tester la négociation de contenu, seul le premier type de média Accept étant honoré et le traitement binaire dépendant de la liste binaryMediaTypes
    • Couvrir les 3 pièges de query string — un point-virgule scinde la donnée, barres verticales et accolades doivent être encodées, et les paramètres sont sensibles à la casse
  4. Module 4

    Preuves et fidélité du contrat

    Objectif. Combler les deux trous qui rendent les incidents irreproductibles : preuves de charge utile manquantes et perte silencieuse de contrat à l'import.

    • Contourner la troncature à 1024 octets par événement de log, qui retire les corps de requête et de réponse de la piste d'audit de la gateway
    • Placer ailleurs les preuves de charge utile nécessaires, avec taux d'échantillonnage et rétention cible arrêtés avant la prochaine saison de pic
    • Comparer l'API importée à la spécification source, default, nullable, example, discriminator et readOnly n'étant pas supportés et la sécurité de niveau racine étant ignorée

Références & documentation officielle chaque affirmation ci-dessus a une source

Module 1

Module 2

Module 4

Dans la filière Gateways cloud-native

#gateway-ops-clinic · Diagnostiquer les pannes de gateway API en production#azure-apim-clinic · Azure API Management en production : clinique des pannes#cloud-native-gateway · Praticien des gateways API cloud-native#gateway-api-migration · Lab de migration Ingress-NGINX vers Kubernetes Gateway API#kong-clinic · Kong Gateway en production : clinique des pannes

Une formation pour votre équipe ?

Chaque session est adaptée à vos cas d'usage, vos données et votre planning.

Demander un devis