Come posso utilizzare AWS CloudFront e API Gateway fianco a fianco per lo stesso dominio?

Sto inserendo le risorse statiche del mio sito Web su S3 e configurando CloudFront per distribuirle. Questi essenzialmente contengono i contenuti di cui gli utenti avrebbero bisogno per qualsiasi richiesta GET sul mio sito, ai percorsi esistenti, ovvero con una catchall per errori.

Ho anche alcune richieste POST che devo gestire. Inviare moduli, inviare e-mail, notifiche, interagire con il database.

Come posso configurare Lambda (o API Gateway) fianco a fianco con CloudFront per lo stesso dominio in modo che CloudFront gestisca le richieste GET e API Gateway gestisca le richieste con un corpo o richieste POST. O posso farlo in base al singolo URL in qualche modo?

Gestisco più app web esattamente con il tuo progetto proposto e ho estratto gofaas , un'app educativa Go e Lambda, per condividere le tecniche.

Sono necessari due domini separati, ad esempio www.gofaas.netper S3 + CloudFront e api.gofaas.netper API Gateway + Lambda.

Quindi puoi consentire al tuo sito statico di interagire con l'API con una configurazione CORS del gateway API e alcuni 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);
    });

Ecco alcune guide per l'impostazione di tutto questo:

Siti Web statici con S3, CloudFront e ACM

Sicurezza API con Lambda, API Gateway, CORS e JWT

È possibile creare una funzione lambda, configurare il gateway API e quindi configurare CloudFront per inoltrare determinati percorsi (ad es. / Rest / *) al gateway API e servire tutto il resto da un bucket S3.

Ecco una passeggiata completa che mostra come farlo: https://www.codeengine.com/articles/process-form-aws-api-gateway-lambda/

Dal punto di vista della connessione "qualcosa" deve rispondere alle tue richieste (GET, POST, PUT, tutto). Prima di tutto hai una connessione TCP e "qualcosa" deve assicurarti che capisca il livello 7 e abbia senso dai byte che il client sta inviando. Solo a questo punto è possibile gestire le richieste GET in modo diverso dalle richieste POST o da un URL rispetto a un altro URL. Quindi alla fine hai bisogno di un servizio in grado di comprendere e instradare HTTP. I seguenti servizi sono in grado di fare questo: CloudFront ELB / ALB API Gateway (la limitazione arriva dopo)

API Gateway utilizza CloudFront internamente (senza darti la possibilità di configurare effettivamente nulla a livello di CloudFront) - ciò significa che non c'è modo di eseguire CloudFront e API Gateway fianco a fianco poiché alla fine ciò significherebbe che esegui CloudFront con CloudFront side-by-side.

CloudFront ti dà la possibilità di selezionare origini diverse in base ai modelli, ma puoi selezionare solo S3 o ELB / ALB come origine, non le funzioni Lambda (oltre alla funzionalità Lambda @ Edge).

ALB / ELB può usare solo istanze EC2 come backend - qui non Lambda o S3.

Gli unici modi in cui riesco a pensare a quale potrebbe fare quello che vuoi fare sono questi:

• Usi API Gateway e instrada un percorso "asset" specifico a una funzione Lambda che fa una sorta di proxy inverso per S3 (quindi instrada le risorse statiche tramite lambda) - fai attenzione ai costi per Lambda qui!
• Potresti fare lo stesso ma invece di eseguire il piping dell'asset tramite Lambda, generare semplicemente un URL firmato all'interno di Lambda e reindirizzare direttamente a S3 per la pubblicazione (potrebbe essere più conveniente)
• Utilizzo di sottodomini diversi per le risorse rispetto al resto dell'applicazione: questo è un modello molto comune in quanto è possibile suddividere facilmente a livello DNS e utilizzare servizi diversi per i diversi casi d'uso (CloudFront per risorse e Gateway API per non statici parti)

Quindi la mia chiamata sarebbe l'ultima opzione, ma ciò significa che devi indirizzare i client / i browser verso un sottodominio separato per tutte le risorse statiche (o per tutte le richieste POST).

Sembra che tu voglia dare un'occhiata a tecnologie come AngularJS o React per creare un'applicazione veramente basata su API nel browser. Con questo approccio stai eseguendo una vera API che gestisce tutte le richieste "dinamiche" con un gateway API e consegna l'applicazione stessa da S3 come risorsa statica. Forse guardarli potrebbe aiutarti a trovare la tua strada - anche se non li usi, lo schema architettonico su come costruire cose come questa è ciò che stai chiedendo imho.

Ho la stessa configurazione. Risorse statiche su S3, funzioni Lambda servite tramite gateway API e condividono lo stesso nome di dominio.

Vado con il gateway API che utilizza già CloudFront ed espone alcune delle sue funzionalità come la cache. Quindi configuro gli URI che si associano a risorse statiche. In API Gateway, una risorsa può essere una funzione Lambda, una funzione AWS, un finto o un altro URL. Li faccio puntare ai miei URL S3.

Gli URI possono essere impostati anche per il raggruppamento di sottopercorsi, ad es /assets/*.