Du point de vue de la connexion, "quelque chose" doit répondre à vos demandes (GET, POST, PUT, tout). Tout d'abord, vous avez une connexion TCP et "quelque chose" doit s'assurer qu'il comprend la couche 7 et donne un sens aux octets que le client envoie. Ce n'est qu'à ce stade qu'il est possible de traiter les demandes GET différemment des demandes POST ou d'une URL à une autre URL. Donc, à la fin, vous avez besoin d'un service capable de comprendre et d'acheminer HTTP. Les services suivants sont capables de le faire: CloudFront ELB / ALB API Gateway (la limitation vient plus tard)
API Gateway utilise CloudFront en interne (sans vous donner la possibilité de configurer quoi que ce soit au niveau de CloudFront) - cela signifie qu'il n'y a aucun moyen d'exécuter CloudFront et API Gateway côte à côte, car à la fin cela signifierait que vous exécutez CloudFront avec CloudFront cote à cote.
CloudFront vous donne la possibilité de sélectionner différentes origines en fonction de modèles - mais vous ne pouvez sélectionner que S3 ou ELB / ALB comme origine - pas les fonctions Lambda (en plus de la fonctionnalité Lambda @ Edge).
ALB / ELB ne peut utiliser que des instances EC2 comme backend - pas de Lambda ou S3 ici.
Les seules façons dont je peux penser qui pourraient faire ce que vous voulez faire sont les suivantes:
- Vous utilisez la passerelle API et acheminez un chemin d'accès "actif" spécifique vers une fonction Lambda qui fait une sorte de proxy inverse pour S3 (afin de canaliser les actifs statiques via lambda) - soyez conscient des coûts pour Lambda ici!
- Vous pouvez faire de même, mais au lieu de canaliser l'actif via Lambda, générez simplement une URL signée dans Lambda et redirigez directement vers S3 pour la servir (cela pourrait être plus rentable)
- Utiliser des sous-domaines différents pour vos actifs que le reste de votre application - c'est un modèle très courant car vous pouvez facilement vous répartir au niveau DNS et utiliser différents services pour les différents cas d'utilisation (CloudFront pour les actifs et API Gateway pour les non statiques) les pièces)
Mon appel serait donc la dernière option - mais cela signifie que vous devez pointer les clients / navigateurs vers un sous-domaine distinct pour tous les actifs statiques (ou pour toutes les demandes POST).
Il semble que vous souhaitiez jeter un œil à des technologies comme AngularJS ou React pour créer une application véritablement pilotée par API dans le navigateur. Avec cette approche, vous exécutez une véritable API qui gère toutes les demandes "dynamiques" avec une passerelle API et fournit l'application elle-même à partir de S3 en tant qu'actif statique. Peut-être que les regarder pourrait vous aider à trouver votre chemin - même si vous ne les utilisez pas, le modèle architectural sur la façon de construire des choses comme celle-ci est ce que vous demandez à mon humble avis.