Ricezione di connessioni in entrata da Internet

Se gestisci un servizio pubblico, devi accettare il traffico in entrata da Internet. Ad esempio, il sito Web pubblico deve accettare richieste HTTP in entrata dai browser. In tal caso, anche altri host su Internet devono avviare una connessione in entrata all'host dell'applicazione.

Un approccio a questo problema consiste nell'avviare i contenitori su host che si trovano in una sottorete pubblica con un indirizzo IP pubblico. Tuttavia, non lo consigliamo per applicazioni su larga scala. Per queste, un approccio migliore consiste nell'avere un livello di input scalabile che si colloca tra Internet e l'applicazione. Per questo approccio, è possibile utilizzare uno qualsiasi dei AWS servizi elencati in questa sezione come input.

Application Load Balancer

Un Application Load Balancer funziona a livello di applicazione. È il settimo livello del modello Open Systems Interconnection (OSI). Ciò rende un Application Load Balancer adatto ai servizi HTTP pubblici. Se disponi di un sito Web o di un'API REST HTTP, un Application Load Balancer è un sistema di bilanciamento del carico adatto per questo carico di lavoro. Per ulteriori informazioni, consulta Cos'è un Application Load Balancer? nella Guida per l'utente di Application Load Balancers.

Con questa architettura, si crea un Application Load Balancer in una sottorete pubblica in modo che abbia un indirizzo IP pubblico e possa ricevere connessioni in entrata da Internet. Quando l'Application Load Balancer riceve una connessione in entrata, o più specificamente una richiesta HTTP, apre una connessione all'applicazione utilizzando il suo indirizzo IP privato. Quindi, inoltra la richiesta tramite la connessione interna.

Un Application Load Balancer presenta i seguenti vantaggi.

• Terminazione SSL/TLS: un Application Load Balancer può supportare comunicazioni e certificati HTTPS sicuri per le comunicazioni con i client. Facoltativamente, può interrompere la connessione SSL a livello di load balancer in modo da non dover gestire i certificati nella propria applicazione.

• Routing avanzato: un Application Load Balancer può avere più nomi host DNS. Dispone inoltre di funzionalità di routing avanzate per inviare richieste HTTP in entrata a diverse destinazioni in base a metriche come il nome host o il percorso della richiesta. Ciò significa che è possibile utilizzare un singolo Application Load Balancer come input per molti servizi interni diversi o anche microservizi su percorsi diversi di un'API REST.

• Supporto gRPC e websocket: un Application Load Balancer può gestire più di un semplice HTTP. Può anche bilanciare il carico di servizi basati su gRPC e websocket, con supporto HTTP/2.

• Sicurezza: un Application Load Balancer aiuta a proteggere l'applicazione dal traffico dannoso. Include funzionalità come le mitigazioni della sincronizzazione HTTP ed è integrato con AWS Web Application Firewall ()AWS WAF. AWS WAF può filtrare ulteriormente il traffico dannoso che potrebbe contenere schemi di attacco, come SQL injection o cross-site scripting.

Network Load Balancer

Un sistema Network Load Balancer funziona al quarto livello del modello Open Systems Interconnection (OSI). È adatto per protocolli o scenari non HTTP in cui è necessaria end-to-end la crittografia, ma non ha le stesse funzionalità specifiche HTTP di un Application Load Balancer. Pertanto, un Network Load Balancer è più adatto per le applicazioni che non utilizzano HTTP. Per ulteriori informazioni, consulta Cos'è un Network Load Balancer? nella Guida per l'utente di Network Load Balancers.

Quando un Network Load Balancer viene utilizzato come input, funziona in modo simile a un Application Load Balancer. Questo perché è creato in una sottorete pubblica e dispone di un indirizzo IP pubblico a cui è possibile accedere su Internet. Il Network Load Balancer apre quindi una connessione all'indirizzo IP privato dell'host che esegue il container e invia i pacchetti dal lato pubblico a quello privato.

Funzionalità di Network Load Balancer

Poiché il Network Load Balancer opera a un livello inferiore dello stack di rete, non ha lo stesso set di funzionalità di Application Load Balancer. Tuttavia, presenta le seguenti caratteristiche importanti.

• nd-to-end Crittografia E: poiché un Network Load Balancer opera al quarto livello del modello OSI, non legge il contenuto dei pacchetti. Ciò lo rende adatto per il bilanciamento del carico di comunicazioni che richiedono la crittografia. end-to-end

• Crittografia TLS: oltre alla end-to-end crittografia, Network Load Balancer può anche interrompere le connessioni TLS. In questo modo, le tue applicazioni di backend non devono implementare il proprio TLS.

• Supporto UDP: poiché un Network Load Balancer opera al quarto livello del modello OSI, è adatto per carichi di lavoro e protocolli non HTTP diversi dal TCP.

Chiusura delle connessioni

Poiché Network Load Balancer non rispetta il protocollo applicativo ai livelli superiori del modello OSI, non può inviare messaggi di chiusura ai client in tali protocolli. A differenza dell'Application Load Balancer, tali connessioni devono essere chiuse dall'applicazione oppure è possibile configurare Network Load Balancer per chiudere le connessioni di quarto livello quando un'attività viene interrotta o sostituita. Vedi l'impostazione di terminazione della connessione per i gruppi target di Network Load Balancer nella documentazione di Network Load Balancer.

Consentire al Network Load Balancer di chiudere le connessioni al quarto livello può far sì che i client visualizzino messaggi di errore indesiderati, se il client non li gestisce. Per ulteriori informazioni sulla configurazione del client consigliata, consulta la libreria per gli sviluppatori qui.

I metodi per chiudere le connessioni variano a seconda dell'applicazione, tuttavia un modo è garantire che il ritardo di annullamento della registrazione del target di Network Load Balancer sia più lungo del timeout della connessione client. Il client prima andava in timeout e si riconnetteva senza problemi tramite Network Load Balancer all'attività successiva, mentre la vecchia operazione esauriva lentamente tutti i client. Per ulteriori informazioni sul ritardo di annullamento della registrazione previsto per Network Load Balancer, consulta la documentazione di Network Load Balancer.

API HTTP di Amazon API Gateway

L'API HTTP di Amazon API Gateway è un ingresso serverless adatto per applicazioni HTTP con picchi improvvisi di volumi di richieste o volumi di richieste bassi. Per ulteriori informazioni, consulta Cos'è Amazon API Gateway? nella Guida per sviluppatori di API Gateway.

Il modello di prezzo per Application Load Balancer e Network Load Balancer include una tariffa oraria per mantenere i sistemi di bilanciamento del carico disponibili per accettare connessioni in entrata in ogni momento. Al contrario, API Gateway addebita separatamente ogni richiesta. Ciò ha l'effetto che, se non arriva alcuna richiesta, non ci sono costi. In caso di carichi di traffico elevati, un Application Load Balancer o un Network Load Balancer è in grado di gestire un volume maggiore di richieste a un prezzo per richiesta inferiore rispetto all'API Gateway. Tuttavia, se hai un numero complessivo di richieste limitato o hai periodi di traffico ridotto, il prezzo cumulativo per l'utilizzo dell'API Gateway dovrebbe essere più conveniente rispetto al pagamento di una tariffa oraria per mantenere un sistema di bilanciamento del carico sottoutilizzato. L'API Gateway può anche memorizzare nella cache le risposte API, il che potrebbe comportare una riduzione delle percentuali di richieste di backend.

Funzioni API Gateway che utilizzano un collegamento VPC che consente al servizio AWS gestito di connettersi agli host all'interno della sottorete privata del VPC, utilizzando il relativo indirizzo IP privato. Può rilevare questi indirizzi IP privati esaminando i record AWS Cloud Map di rilevamento dei servizi gestiti da Amazon ECS service discovery.

API Gateway supporta le seguenti funzionalità.

• Il funzionamento dell'API Gateway è simile a quello di un sistema di bilanciamento del carico, ma presenta funzionalità aggiuntive esclusive per la gestione delle API

• L'API Gateway offre funzionalità aggiuntive relative all'autorizzazione del client, ai livelli di utilizzo e alla modifica della richiesta/risposta. Per ulteriori informazioni, consulta le funzionalità di Amazon API Gateway.

• L'API Gateway può supportare endpoint gateway API edge, regionali e privati. Gli endpoint Edge sono disponibili tramite una distribuzione gestita CloudFront . Gli endpoint regionali e privati sono entrambi locali rispetto a una regione.

• Terminazione SSL/TLS

• Instradamento di diversi percorsi HTTP verso diversi microservizi di backend

Oltre alle funzionalità precedenti, API Gateway supporta anche l'utilizzo di autorizzatori Lambda personalizzati che puoi utilizzare per proteggere l'API dall'utilizzo non autorizzato. Per ulteriori informazioni, consulta Field Notes: API serverless basate su container con Amazon ECS e Amazon API Gateway.