Como posso usar o AWS CloudFront e o API Gateway lado a lado no mesmo domínio?

Estou colocando esses ativos estáticos do meu site no S3 e configurando o CloudFront para distribuí-los. Essencialmente, eles mantêm o conteúdo que os usuários precisariam para qualquer solicitação GET no meu site, nos caminhos existentes, ou seja, com uma lista de erros.

Também tenho algumas solicitações POST que preciso tratar. Envie formulários, enviando e-mails, notificações, interagindo com o banco de dados.

Como posso configurar o Lambda (ou API Gateway) lado a lado com o CloudFront para o mesmo domínio, para que o CloudFront lide com solicitações GET e o API Gateway lide com solicitações com um corpo ou solicitações POST. Ou posso fazê-lo por URL individual de alguma forma?

Executo vários aplicativos da web exatamente com o design proposto e extraí o gofaas , um aplicativo educacional Go e Lambda, para compartilhar as técnicas.

Você precisa de dois domínios separados, por exemplo, www.gofaas.netpara S3 + CloudFront e api.gofaas.netpara API Gateway + Lambda.

Em seguida, você pode permitir que seu site estático interaja com a API com uma configuração CORS do Gateway de API e algum 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);
    });

Aqui estão alguns guias para configurar tudo isso:

Sites estáticos com S3, CloudFront e ACM

Segurança de API com Lambda, Gateway de API, CORS e JWT

Você pode criar uma função lambda, configurar o gateway da API e, em seguida, configurar o CloudFront para encaminhar certos caminhos (por exemplo, / rest / *) para o gateway da API, além de servir todo o resto de um bucket do S3.

Aqui está uma descrição completa de como fazer isso: https://www.codeengine.com/articles/process-form-aws-api-gateway-lambda/

Do ponto de vista da conexão, "algo" precisa responder às suas solicitações (GET, POST, PUT, tudo). Primeiro de tudo, você tem uma conexão TCP e "algo" precisa ter certeza de que está entendendo a camada 7 e fazendo sentido com os bytes que o cliente está enviando. Somente neste momento é possível lidar com solicitações GET de maneira diferente das solicitações POST ou com um URL que outro URL. Portanto, no final, você precisa de um serviço capaz de entender e encaminhar o HTTP. Os seguintes serviços são capazes de fazer isso: Gateway de API CloudFront ELB / ALB (a limitação vem depois)

O API Gateway usa o CloudFront internamente (sem dar a você a chance de realmente configurar qualquer coisa no nível do CloudFront) - isso significa que não há como executar o CloudFront e o API Gateway lado a lado, pois no final isso significa que você executa o CloudFront com o CloudFront lado a lado.

O CloudFront oferece a chance de selecionar origens diferentes com base em padrões - mas você só pode selecionar S3 ou ELB / ALBs como origem - não as funções Lambda (além da funcionalidade Lambda @ Edge).

O ALB / ELB pode usar apenas instâncias do EC2 como back-end - sem Lambda ou S3 aqui.

As únicas maneiras pelas quais consigo pensar que podem fazer o que você quer fazer são:

• Você usa o API Gateway e roteia um caminho específico de "ativo" para uma função do Lambda que faz um tipo de proxy reverso para o S3 (canalizando os ativos estáticos pelo lambda) - esteja ciente dos custos do Lambda aqui!
• Você pode fazer o mesmo, mas, em vez de canalizar o recurso pelo Lambda, basta gerar um URL assinado no Lambda e redirecionar diretamente para o S3 para veiculação (pode ser mais econômico)
• Usando subdomínios diferentes para seus ativos do que o restante do aplicativo - esse é um padrão muito comum, pois você pode facilmente dividir no nível DNS e usar serviços diferentes para os diferentes casos de uso (CloudFront para ativos e API Gateway para os não estáticos) partes)

Portanto, minha ligação seria a última opção - mas isso significa que você precisa apontar os clientes / navegadores para um subdomínio separado para todos os ativos estáticos (ou para todas as solicitações POST).

Parece que você deseja dar uma olhada em tecnologias como AngularJS ou React para criar um aplicativo verdadeiramente orientado a API no navegador. Com essa abordagem, você está executando uma API real, que lida com todas as solicitações "dinâmicas" com um Gateway de API e entrega o próprio aplicativo do S3 como um ativo estático. Talvez olhar para eles possa ajudá-lo a encontrar o caminho - mesmo que você não os use, o padrão arquitetural de como construir coisas como esta é o que você está pedindo.

Eu tenho a mesma configuração. Ativos estáticos no S3, funções Lambda servidas por meio do gateway da API e compartilham o mesmo nome de domínio.

Eu uso o gateway API, que já usa o CloudFront e expõe algumas de suas funcionalidades, como cache. Depois, configuro os URIs que são mapeados para ativos estáticos. No API Gateway, um recurso pode ser uma função Lambda, uma função da AWS, uma simulação ou outro URL. Eu os apontei para meus URLs S3.

Os URIs também podem ser configurados para acumular subcaminhos, por exemplo /assets/*.