¿Cómo puedo usar AWS CloudFront y API Gateway lado a lado para el mismo dominio?

Estoy poniendo esos activos estáticos de mi sitio web en S3 y configurando CloudFront para distribuirlos. Esencialmente contiene el contenido que los usuarios necesitarían para cualquier solicitud GET en mi sitio, a las rutas existentes, es decir, con una gran cantidad de errores.

También tengo algunas solicitudes POST que necesito manejar. Envíos de formularios, envío de correos electrónicos, notificaciones, interacción con la base de datos.

¿Cómo puedo configurar Lambda (o API Gateway) junto con CloudFront para el mismo dominio para que CloudFront maneje las solicitudes GET, y API Gateway maneja las solicitudes con un cuerpo o solicitudes POST? ¿O puedo hacerlo por URL individual de alguna manera?

Ejecuté varias aplicaciones web exactamente con su diseño propuesto, y extraje gofaas , una aplicación educativa Go and Lambda, para compartir las técnicas.

Necesita dos dominios separados, por ejemplo, www.gofaas.netpara S3 + CloudFront y api.gofaas.netpara API Gateway + Lambda.

Luego puede dejar que su sitio estático interactúe con la API con una configuración CORS de API Gateway y algo de JavaScript:

fetch(`https://api.gofaas.net/work`, {
    method: "POST",
    mode: "cors",
    headers: {
        "Accept": "application/json",
        ...
    },
    body: JSON.stringify(...)
})
    .then(function(response) {
        return response.json();
    })
    .then(function (json) {
        // use response
    })
    .catch(function (err) {
        console.log("fetch error", err);
    });

Aquí hay algunas guías para configurar todo esto:

Sitios web estáticos con S3, CloudFront y ACM

Seguridad API con Lambda, API Gateway, CORS y JWT

Puede crear una función lambda, configurar la puerta de enlace API y luego configurar CloudFront para reenviar ciertas rutas (por ejemplo, / rest / *) a la puerta de enlace API, y servir todo lo demás desde un bucket S3.

Aquí hay un recorrido completo que muestra cómo hacer esto: https://www.codeengine.com/articles/process-form-aws-api-gateway-lambda/

Desde el punto de vista de la conexión, "algo" debe responder a sus solicitudes (GET, POST, PUT, todo). En primer lugar, tiene una conexión TCP y "algo" debe asegurarse de que comprende la capa 7 y que tiene sentido los bytes que envía el cliente. Solo en este punto es posible manejar las solicitudes GET de manera diferente a las solicitudes POST o una URL que otra URL. Entonces, al final, necesita un servicio que sea capaz de comprender y enrutar HTTP. Los siguientes servicios son capaces de hacer esto: CloudFront ELB / ALB API Gateway (la limitación viene más adelante)

API Gateway usa CloudFront internamente (sin darle la oportunidad de configurar realmente nada en el nivel de CloudFront), eso significa que no hay forma de ejecutar CloudFront y API Gateway lado a lado, ya que al final esto significaría que ejecuta CloudFront con CloudFront lado a lado.

CloudFront le brinda la oportunidad de seleccionar diferentes orígenes basados ​​en patrones, pero solo puede seleccionar S3 o ELB / ALB como origen, no las funciones de Lambda (además de la funcionalidad Lambda @ Edge).

ALB / ELB solo puede usar instancias EC2 como backend; aquí no hay Lambda o S3.

Las únicas formas en que puedo pensar que podrían hacer lo que quieres hacer son estas:

• Utiliza API Gateway y enruta una ruta de "activo" específica a una función Lambda que hace una especie de proxy inverso para S3 (por lo que canaliza los activos estáticos a través de lambda). ¡Tenga en cuenta los costos para Lambda aquí!
• Puede hacer lo mismo, pero en lugar de canalizar el activo a través de Lambda, simplemente genere una URL firmada dentro de Lambda y redirija directamente a S3 para servir (podría ser más rentable)
• Usar diferentes subdominios para sus activos que el resto de su aplicación: este es un patrón muy común, ya que puede dividirse fácilmente en el nivel DNS y usar diferentes servicios para los diferentes casos de uso (CloudFront para activos y API Gateway para los no estáticos partes)

Por lo tanto, mi llamada sería la última opción, pero eso significa que debe apuntar a los clientes / navegadores a un subdominio separado para todos los activos estáticos (o para todas las solicitudes POST).

Parece que quiere echar un vistazo a tecnologías como AngularJS o React para crear una aplicación verdaderamente basada en API en el navegador. Con este enfoque, está ejecutando una API real que maneja todas las solicitudes "dinámicas" con una API Gateway y entrega la aplicación en sí desde S3 como un activo estático. Tal vez mirarlos podría ayudarlo a encontrar su camino; incluso si no los usa, el patrón arquitectónico sobre cómo construir cosas como esta es lo que está pidiendo en mi humilde opinión.

Tengo la misma configuración. Activos estáticos en S3, las funciones de Lambda se sirven a través de la puerta de enlace API y comparten el mismo nombre de dominio.

Voy con la puerta de enlace API que ya usa CloudFront y expone algunas de sus funcionalidades, como el almacenamiento en caché. Luego configuro URI que se asignan a activos estáticos. En API Gateway, un recurso puede ser una función Lambda, una función de AWS, un simulacro u otra URL. Les hago apuntar a mis URL S3.

Los URI se pueden configurar para englobar subrutas también, por ejemplo /assets/*.