Domande frequenti su Elastic Load Balancing

Application Load Balancer supporta destinazioni con qualsiasi sistema operativo supportato da Amazon EC2.

Application Load Balancer supporta il bilanciamento del carico di applicazioni che utilizzano i protocolli HTTP e HTTPS (Secure HTTP).

Sì. Il supporto di HTTP/2 è abilitato in modo nativo su un sistema Application Load Balancer. I client che supportano HTTP/2 possono collegarsi ad Application Load Balancer tramite TLS.

Puoi trasmettere il traffico dal tuo Network Load Balancer, che fornisce supporto per PrivateLink e un indirizzo IP statico per zona di disponibilità, al tuo Application Load Balancer. Crea un gruppo target di tipo Application Load Balancer, registraci il tuo Application Load Balancer e configura il tuo bilanciatore del carico di rete per trasmettere il traffico al gruppo target di Application Load Balancer.

Puoi effettuare il bilanciamento del carico per le seguenti porte TCP: 1-65535

Sì. Il supporto di WebSockets e Secure WebSockets è abilitato in modo nativo ed è pronto per l'uso su un sistema Application Load Balancer.

Sì. Il monitoraggio delle richieste è attivo di default su Application Load Balancer.

Anche se c'è una certa sovrapposizione, non c'è parità completa di funzionalità tra i due tipi di bilanciatori del carico. I sistemi Application Load Balancer costituiscono la base portante della nostra piattaforma di bilanciamento del carico a livello di applicazione per il futuro.

Sì.

Sì.

No, per Application Load Balancer è necessario un nuovo set di interfacce di programmazione dell'applicazione (API).

La Console ELB permette di gestire sistemi di bilanciamento del carico Application e Standard dalla stessa interfaccia. Se utilizzi un'interfaccia a riga di comando (CLI) o un Software Development Kit (SDK), userai un 'servizio' diverso per i sistemi Application Load Balancer. Per esempio, nella CLI descriverai i tuoi sistemi Classic Load Balancer con `aws elb describe-load-balancers` e quelli Application Load Balancer con `aws elbv2 describe-load-balancers`.

No, non è possibile convertire un tipo di sistema di bilanciamento del carico in un tipo diverso.

Sì. È possibile eseguire la migrazione ad Application Load Balancer da Classic Load Balancer tramite una delle opzioni elencate in questo documento.

No. Se è necessario poter disporre di caratteristiche di livello 4, occorre impiegare un sistema Network Load Balancer.

Sì, puoi aggiungere listener per la porta HTTP 80 e la porta HTTP 443 a un singolo sistema Application Load Balancer.

Sì. Per ricevere uno storico delle chiamate API Application Load Balancing effettuate sul tuo account, usa AWS CloudTrail.

Sì, su Application Load Balancer puoi terminare la connessione HTTPS. Sarà tuttavia necessario installarvi un certificato SSL (Secure Sockets Layer). Il sistema di bilanciamento del carico utilizzerà il certificato per terminare la connessione e quindi decrittografare le richieste provenienti dai client prima di inoltrarle agli obiettivi.

Puoi utilizzare AWS Certificate Manager per effettuare il provisioning di un certificato SSL/TLS oppure ottenerlo da altre fonti creando una richiesta di certificato, facendola firmare da un'autorità di certificazione (CA) e quindi caricando il certificato utilizzando AWS Certification Manager o il servizio AWS Identity and Access Management (IAM).

Application Load Balancer è integrato con AWS Certificate Management (ACM). L'integrazione con ACM aiuta ad associare i certificati con il bilanciatore del carico, rendendo ancora più semplice la ripartizione del carico SSL. L'acquisto, il caricamento e il rinnovo dei certificati SSL/TLS è un processo manuale lungo e complicato. Grazie all'integrazione tra ACM e Application Load Balancer, l'intero processo è stato abbreviato, perciò ora è sufficiente richiedere un certificato SSL/TLS sicuro e selezionare il certificato ACM per effettuarne il provisioning con il sistema di bilanciamento del carico.

No, con un sistema Application Load Balancer solo la crittografia è supportata sui server back-end.

L'estensione SNI viene abilitata automaticamente quando viene associato più di un certificato TLS allo stesso listener protetto in un sistema di bilanciamento del carico. Analogamente, l'estensione SNI viene disabilitata automaticamente quando è presente un solo certificato associato a un listener protetto.

Sì, è possibile associare più certificati per uno stesso dominio a un listener protetto. Ad esempio puoi associare:

• Certificati ECDSA e RSA
• Certificati con chiavi di dimensioni differenti (ad esempio 2K e 4K) per certificati SSL/TLS
• Certificati a dominio singolo, multidominio (SAN) e jolly

Sì, il protocollo IPv6 è supportato con un sistema Application Load Balancer.

È possibile configurare regole per ogni listener creato per il bilanciatore del carico. Le regole includono condizioni e operazioni corrispondenti se le condizioni vengono soddisfatte. Le condizioni supportate sono intestazione Host, percorso, intestazioni HTTP, metodi, parametri query e IP di origine CIDR (classless inter-domain routing). Le operazioni supportate sono reindirizzare, risposta fissa, autenticare e inoltrare. Una volta impostato, il bilanciatore del carico utilizzerà le regole per determinare a quale servizio deve essere instradata una specifica richiesta HTTP. Puoi utilizzare più condizioni e operazioni in un'unica regola e in ognuna di queste puoi determinare una corrispondenza in relazione a diversi valori.

Il tuo account AWS ha questi limiti per un sistema Application Load Balancer.

Puoi integrare il sistema Application Load Balancer con AWS Web Application Firewall (WAF), un firewall che protegge le applicazioni Web dagli attacchi permettendoti di configurare regole basate su indirizzi IP, intestazioni HTTP e stringhe URI (uniform resource identifier) personalizzate. Tramite queste regole, AWS WAF blocca, consente o monitora (conteggio) le richieste Web dirette all'applicazione Web. Per ulteriori informazioni, consulta la Guida per sviluppatori AWS WAF.

È possibile usare qualsiasi indirizzo IP dal CIDR VPC del bilanciatore del carico per destinazioni all'interno del VPC del bilanciatore del carico e qualsiasi indirizzo IP dagli intervalli RFC 1918 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16) o dall'intervallo RFC 6598 (100.64.0.0/10) per destinazioni esterne (ad esempio, destinazioni in VPC in peering, Amazon EC2 Classic e percorsi on-premises raggiungibili tramite AWS Direct Connect o connessione VPN).

Esistono vari modi per ottenere un bilanciamento di carico ibrido. Se un'applicazione viene eseguita su destinazioni distribuite tra un VPC e una posizione locale, le si può aggiungere allo stesso gruppo di destinazione utilizzando i loro indirizzi IP. Per migrare ad AWS senza influenzare la propria applicazione aggiungere gradualmente destinazioni VPC al gruppo di destinazione e rimuovere le destinazioni locali dal gruppo di destinazione. 

Se si hanno due applicazioni diverse per cui le destinazioni per un'applicazione si trovano in un VPC e le destinazioni per le altre applicazioni sono in locale, si possono mettere le destinazioni VPC in un gruppo di destinazione e le destinazioni locali in un altro gruppo di destinazione e usare l'instradamento basato sul contenuto per instradare il traffico a ogni gruppo di destinazione. È anche possibile separare i sistemi di bilanciamento del carico per destinazioni VPC e locali e usare la ponderazione DNS per ottenere un bilanciamento del carico ponderato tra le destinazioni VPC e quelle locali.

Non è possibile bilanciare il carico sulle istanze EC2-Classic quando si registrano i loro ID istanza come destinazioni. Tuttavia, se si collegano queste istanze EC2-Classic al cloud privato virtuale del sistema di bilanciamento del carico utilizzando ClassicLink e si usano gli IP privati di queste istanze EC2-Classic come destinazioni, si può bilanciare il carico sulle istanze EC2-Classic. Se si stanno utilizzando istanze EC2 Classic con un Classic Load Balancer, è possibile migrare facilmente a un Application Load Balancer.

Il bilanciamento del carico multizona è già attivo di default in Application Load Balancer.

Si consiglia di utilizzare l'autenticazione tramite Amazon Cognito se:

• Si desidera offrire agli utenti la flessibilità di eseguire l'autenticazione tramite identità social (Google, Facebook e Amazon) oppure aziendali (SAML) oppure tramite directory utente aziendali fornite dalla funzione pool di utenti di Amazon Cognito.
• Si gestiscono diversi provider di identità incluso OpenID Connect e si desidera creare una singola regola di autenticazione in Application Load Balancer (ALB) che possa utilizzare Amazon Cognito per creare una federazione con diversi provider di identità.
• È necessario gestire attivamente i profili utente con uno o più provider di identità social o OpenID Connect in modo centralizzato. Ad esempio, è possibile inserire gli utenti in gruppi e aggiungere attributi personalizzati che rappresentino il loro stato, controllando gli accessi per gli utenti paganti.

In alternativa, se sono già presenti investimenti nello sviluppo di soluzioni di provider di identità personalizzati e si desidera semplicemente eseguire l'autenticazione con un solo provider compatibile con OpenID Connect, è possibile utilizzare la soluzione OIDC nativa di Application Load Balancer.

Questo servizio supporta i tre seguenti tipi di reindirizzamento.

Da HTTP ad HTTP
Da http://hostA ad http://hostB

Da HTTP ad HTTPS
Da http://hostA a https://hostB
Da https://hostA:portA/pathA ad https://hostB:portB/pathB

Da HTTPS ad HTTPS
Da https://hostA ad https://hostB

Questo servizio supporta i seguenti tipi di contenuto: text/plain, text/css, text/html, application/javascript, application/json.

Le richieste HTTP(S) ricevute da un bilanciatore del carico vengono elaborate secondo le regole di routing basate sul contenuto. Se il contenuto della richiesta corrisponde alla regola con un'operazione di inoltro a un gruppo di destinazione con una funzione Lambda come destinazione, allora viene invocata la funzione Lambda corrispondente. Il contenuto della richiesta (inclusi le intestazioni e il corpo) è passato alla funzione Lambda in formato JSON. La risposta della funzione Lambda dovrebbe essere in formato JSON. La risposta della funzione Lambda viene trasformata in una risposta HTTP e inviata al client. Il bilanciatore del carico invoca la funzione Lambda utilizzando l'API Invoke di AWS Lambda e richiede che siano state fornite alla funzione Lambda le autorizzazioni di invocazione al servizio Elastic Load Balancing.

Sì. Application Load Balancer supporta l'invocazione Lambda per richieste sia dal protocollo HTTP che HTTPS.

Puoi utilizzare Lambda come destinazione con il sistema Application Load Balancer nelle regioni AWS Stati Uniti orientali (Virginia settentrionale), Stati Uniti orientali (Ohio), Stati Uniti occidentali (California settentrionale), Stati Uniti occidentali (Oregon), Asia Pacifico (Mumbai), Asia Pacifico (Seoul), Asia Pacifico (Singapore), Asia Pacifico (Sydney), Asia Pacifico (Tokyo), Canada (Centrale), UE (Francoforte), UE (Irlanda), UE (Londra), UE (Parigi), Sud America (San Paolo) e GovCloud (Stati Uniti occidentali).

Sì, Application Load Balancer è disponibile nella zona locale di Los Angeles. All'interno della zona locale di Los Angeles, Application Load Balancer opererà all'interno di una singola sottorete e si ricalibrerà in funzione delle variazioni dei livelli di carico delle applicazioni in modo automatico, senza alcun intervento manuale.

I costi addebitati dipendono dal numero di ore (o frazione di ora) di esecuzione di un sistema Application Load Balancer e al numero di unità di capacità di bilanciamento del carico (Load Balancer Capacity Units, LCU) utilizzate all'ora.

Un'unità di capacità di bilanciamento del carico o LCU rappresenta un nuovo parametro per determinare come strutturare il pagamento per un sistema Application Load Balancer. Un'unità LCU definisce il volume massimo di una risorsa utilizzato in una qualsiasi delle dimensioni (nuove connessioni, connessioni attive, larghezza di banda e valutazioni delle regole) in cui Application Load Balancer elabora il traffico.

No, i costi dei sistemi Classic Load Balancer continueranno ad essere fatturati in base a larghezza di banda e utilizzo orario.

L'utilizzo di tutte e quattro le dimensioni che costituiscono un'unità LCU viene esposto tramite Amazon CloudWatch.

Il numero di unità LCU all'ora verrà determinato in base al volume massimo di risorse, consumato da tutte e quattro le dimensioni, che costituisce un'unità LCU.

Sì.

Sì. Per nuovi account AWS, è disponibile un piano gratuito per un sistema Application Load Balancer, che offre 750 ore e 15 unità LCU. Questa offerta inclusa nel piano gratuito è disponibile solo per nuovi clienti AWS e per 12 mesi dalla data di iscrizione ad AWS.

Sì. Puoi utilizzare sia Classic Load Balancer che Application Load Balancer rispettivamente per 15 GB e 15 unità LCU. Le 750 ore di bilanciamento del carico sono condivise fra i due sistemi.

Le valutazioni delle regole possono essere definite come il prodotto del numero delle regole elaborate e la media del tasso di richiesta per un'ora.

Le dimensioni della chiave del certificato modifica il numero di nuove connessioni al secondo nel calcolo delle unità LCU per la fatturazione. Nella seguente tabella sono elencati i valori di questa dimensione in base alle dimensioni della chiave per certificati RSA ed ECDSA.

Certificati RSA
Dimensioni chiave: <=2K 
Nuove connessioni al secondo: 25

Dimensioni chiave: <=4K 
Nuove connessioni al secondo: 5

Dimensioni chiave: <=8K 
Nuove connessioni al secondo: 1

Dimensioni chiave: >8K
Nuove connessioni al secondo: 0,25

Certificati ECDSA
Dimensioni chiave: <=256
Nuove connessioni al secondo: 25

Dimensioni chiave: <=384
Nuove connessioni al secondo: 5

Dimensioni chiave: <=521 
Nuove connessioni al secondo: 1

Dimensioni chiave: >521 
Nuove connessioni al secondo: 0,25

No. Poiché il bilanciamento del carico su più zone è sempre attivo con l’Application Load Balancer, non sono previsti costi aggiuntivi per questo tipo di trasferimento dati in una stessa regione.

No. Non vengono addebitati costi separati per l'attivazione della funzionalità di autenticazione in Application Load Balancer. Quando viene impiegato Amazon Cognito con Application Load Balancer, vengono applicate le tariffe standard del servizio Amazon Cognito.

I costi addebitati come al solito sono basati sul numero di ore (o frazione di ora) di esecuzione di un sistema Application Load Balancer e sul numero di unità di capacità di bilanciamento del carico (Load Balancer Capacity Units, LCU) utilizzate all'ora. Per destinazioni Lambda, ogni LCU offre 0,4 GB di byte elaborati ogni ora, 25 connessioni nuove al secondo, 3.000 connessioni attive al minuto e 1.000 valutazioni delle regole al secondo. Per le dimensioni dei byte elaborati, ogni LCU fornisce 0,4 GB per ora per destinazioni Lambda rispetto a 1 GB per ora per tutti gli altri tipi di destinazioni come istanze Amazon EC2, container e indirizzi IP. Si noti che si applicano i costi normali di AWS Lambda alle invocazioni Lambda da parte di Application Load Balancer.

I sistemi Application Load Balancer emettono due nuovi parametri CloudWatch. Il parametro LambdaTargetProcessedBytes indica i byte elaborati dalle destinazioni Lambda e il parametro StandardProcessedBytes indica i byte elaborati dagli altri tipi di destinazioni.

Sì. I sistemi Network Load Balancer supportano sia listener TCP, UDP e TCP+UDP (livello 4), sia quelli del protocollo TLS.

Il sistema Network Load Balancer offre il bilanciamento del carico di protocolli TCP e UDP (livello 4). I sistemi di questo tipo sono stati progettati per gestire milioni di richieste al secondo e pattern di traffico incostanti e con picchi improvvisi, nonché per fornire latenze estremamente basse. Inoltre, il Network Load Balancer supporta la terminazione TLS, conserva l'indirizzo IP di origine dei client e fornisce supporto IP stabile nonché isolamento di zona. Infine, supporta connessioni a lunga durata utili per applicazioni di tipo WebSocket.

Sì. Per riuscirci, è possibile usare un listener combinato di protocolli TCP+UDP. Ad esempio, per i servizi DNS che utilizzano sia TCP che UDP è possibile creare un listener TCP+UDP sulla porta 53 e il bilanciatore del carico elabora il traffico per entrambe le richieste UDP e TCP su quella stessa porta. È necessario associare un listener TCP+UDP a un gruppo di destinazione corrispondente.

Il sistema Network Load Balancer conserva l'indirizzo IP di origine del client, caratteristica non disponibile in Classic Load Balancer. Per ottenere l'indirizzo IP di origine con i sistemi Classic Load Balancer, i clienti potranno utilizzare il protocollo proxy. I sistemi Network Load Balancer forniscono automaticamente IP statici basati su zona di disponibilità al bilanciatore del carico e consentono anche l'assegnazione di IP. Questa caratteristica non è disponibile in sistemi Classic Load Balancer.

Sì. È possibile eseguire la migrazione a Network Load Balancer da Classic Load Balancer tramite una delle opzioni elencate in questo documento.

Sì; consulta la documentazione relativa alle limitazioni per i sistemi Network Load Balancer per ulteriori informazioni.

Sì, per configurare un sistema Network Load Balancer puoi utilizzare la Console di gestione AWS, l'interfaccia a riga di comando o l'API.

No. Per creare un sistema Classic Load Balancer, è necessario utilizzare l'API 2012-06-01. Per creare un sistema Network Load Balancer o un sistema Application Load Balancer, è necessario utilizzare l'API 2015-12-01.

Sì, puoi creare un sistema Network Load Balancer in una sola zona di disponibilità fornendo una singola sottorete al momento della creazione del bilanciatore del carico.

Sì, le caratteristiche di controllo dello stato e di failover DNS incluse in Amazon Route 53 sono utili per potenziare la disponibilità delle applicazioni in esecuzione sotto un Elastic Load Balancer. Tramite la funzione di failover DNS di Route 53, è possibile eseguire le applicazioni su più zone di disponibilità di AWS e configurare dei bilanciatori del carico alternativi per il failover su più regioni. 

Nel caso in cui il sistema Network Load Balancer sia configurato per più zone di disponibilità, se non sono presenti istanze Amazon EC2 integre registrate con il bilanciatore del carico per una determinata zona di disponibilità o se i nodi di questo sistema non sono integri in una determinata zona, Route 53 eseguirà un failover in nodi alternativi in zone di disponibilità differenti.

No. Gli indirizzi dei sistemi Network Load Balancer devono essere controllati interamente dall'utente o da ELB. Quando sono in uso indirizzi elastici in un sistema Network Load Balancer, infatti, è importante che tutti gli indirizzi noti ai client non subiscano modifiche.

No, per ogni sottorete associata che contiene un sistema Network Load Balancer, quest'ultimo supporterà un solo indirizzo IP pubblico o collegato a Internet.

Gli indirizzi IP elastici che erano associati al bilanciatore del carico torneranno nel pool allocato e potranno essere riutilizzati in futuro.

Network Load Balancer può essere impostato come bilanciatore del carico collegato a Internet o interno, analogamente a quanto possibile per Application Load Balancer o Classic Load Balancer.

No. Per ogni sottorete associata che contenga un sistema di bilanciamento del carico, il sistema Network Load Balancer supporta un solo IP privato.

Sì, è sufficiente configurare dei listener TCP che instradino il traffico nelle destinazioni che implementano il protocollo WebSocket (https://tools.ietf.org/html/rfc6455). Poiché WebSocket è un protocollo di livello 7 e i sistemi Network Load Balancer operano a livello 4, non è necessario gestire in modo speciale il sistema per WebSocket, né per protocolli di livello superiore.

Sì. È possibile usare qualsiasi indirizzo IP dal CIDR dell'istanza VPC del sistema di bilanciamento del carico per destinazioni all'interno dello stesso cloud privato virtuale e qualsiasi indirizzo IP dagli intervalli RFC 1918 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16) o dall'intervallo RFC 6598 (100.64.0.0/10) per destinazioni esterne (EC2-Classic e percorsi in locale raggiungibili tramite AWS Direct Connect). Il bilanciamento del carico per indirizzo IP come tipo di destinazione è supportato al momento solo per i listener TCP e non per quelli UDP.

Sì, è possibile utilizzare Network Load Balancer con listener TCP e TLS per configurare AWS PrivateLink. Non è possibile configurare PrivateLink con listener UDP sui sistemi Network Load Balancer.

Durante il periodo di disconnessione del protocollo UDP (user datagram protocol), il bilanciatore del carico ne mantiene lo stato del flusso basato su hash a 5 tuple, assicurando, in questo modo, che i pacchetti inviati nello stesso contesto siano inoltrati coerentemente alla stessa destinazione. Il flusso è considerato attivo fintanto che il traffico scorre e fino al raggiungimento del timeout di inattività. Una volta raggiunta la soglia di timeout, il bilanciatore del carico dimentica l'affinità e il pacchetto UDP in entrata viene considerato come un nuovo flusso e bilanciato su una nuova destinazione.

Il timeout di inattività di Network Load Balancer per le connessioni TCP è di 350 secondi. Il timeout di inattività per i flussi UDP è di 120 secondi.

Ogni container in un'istanza può avere il proprio gruppo di sicurezza e non è necessario che condivida le regole di sicurezza con altri container. I gruppi di sicurezza possono essere allegati a un ENI e ogni ENI in un'istanza può avere un gruppo di sicurezza diverso. Si può mappare un container sull'indirizzo IP di un particolare ENI per associare gruppo/i di sicurezza per ogni container. Il bilanciamento del carico tramite indirizzo IP consente anche a più container in esecuzione in un'istanza di usare la stessa porta (ad esempio la porta 80). La capacità di usare la stessa porta per i contenitori permette ai container in un'istanza di comunicare tra loro attraverso porte ben note invece che attraverso porte casuali.

Esistono vari modi per ottenere un bilanciamento di carico ibrido. Se un'applicazione viene eseguita su destinazioni distribuite tra un VPC e una posizione locale, le si può aggiungere allo stesso gruppo di destinazione utilizzando i loro indirizzi IP. Per migrare ad AWS senza influenzare la propria applicazione aggiungere gradualmente destinazioni VPC al gruppo di destinazione e rimuovere le destinazioni locali dal gruppo di destinazione. È anche possibile separare i sistemi di bilanciamento del carico per destinazioni VPC e locali e usare la ponderazione DNS per ottenere un bilanciamento del carico ponderato tra le destinazioni VPC e quelle locali.

Non è possibile bilanciare il carico sulle istanze EC2-Classic quando si registrano i loro ID istanza come destinazioni. Tuttavia, se si collegano queste istanze EC2-Classic al cloud privato virtuale del sistema di bilanciamento del carico utilizzando ClassicLink e si usano gli IP privati di queste istanze EC2-Classic come destinazioni, si può bilanciare il carico sulle istanze EC2-Classic. Se si stanno utilizzando istanze EC2 Classic con un Classic Load Balancer, è possibile eseguire con la massima semplicità una migrazione in un Network Load Balancer.

È possibile attivare il bilanciamento del carico multizona solo dopo la creazione di un sistema Network Load Balancer. Per l'attivazione, è necessario modificare la sezione degli attributi del bilanciamento del carico e quindi selezionare la casella relativa al supporto del bilanciamento del carico tra più zone.

Sì, verrà addebitato il costo per il trasferimento regionale dei dati tra zone di disponibilità con Network Load Balancer quando è attivato il bilanciamento del carico multizona. Gli addebiti sono specificati nella sezione relativa al trasferimento dei dati alla pagina dei prezzi on demand di Amazon EC2.

Sì. Network Load Balancer al momento supporta 200 destinazioni per zona di disponibilità. Ad esempio, se ti trovi in due zone di disponibilità, potrai contare su un massimo di 400 destinazioni registrate con Network Load Balancer. Se è attivo il bilanciamento del carico tra più zone, il numero massimo di destinazioni si riduce da 200 per zona di disponibilità a 200 per bilanciatore del carico. Quindi, nell'esempio precedente, con il bilanciamento del carico attivato, anche se il bilanciatore del carico si trova in due zone di disponibilità, la registrazione con il bilanciatore del carico è limitata a 200 destinazioni.

Sì, è possibile interrompere le connessioni TLS su Network Load Balancer. Sarà tuttavia necessario installarvi un certificato SSL. Il sistema di bilanciamento del carico utilizzerà il certificato per terminare la connessione e quindi decrittografare le richieste provenienti dai client prima di inoltrarle agli obiettivi.

L'IP di origine continua ad essere mantenuto anche se si termina TLS su Network Load Balancer.

Puoi utilizzare AWS Certificate Manager per effettuare il provisioning di un certificato SSL/TLS oppure ottenerlo da altre fonti creando una richiesta di certificato, facendola firmare da un'autorità di certificazione (CA) e quindi caricando il certificato utilizzando AWS Certification Manager (ACM) o il servizio AWS Identity and Access Management (IAM).

L'estensione SNI viene abilitata automaticamente quando viene associato più di un certificato TLS allo stesso listener protetto in un sistema di bilanciamento del carico. Analogamente, l'estensione SNI viene disabilitata automaticamente quando è presente un solo certificato associato a un listener protetto.

Network Load Balancer è integrato con AWS Certificate Management (ACM). L'integrazione con questo servizio aiuta ad associare i certificati con il bilanciatore del carico, rendendo ancora più semplice la ripartizione del carico SSL. L'acquisto, il caricamento e il rinnovo dei certificati SSL/TLS è un processo manuale lungo e complicato. Grazie all'integrazione tra ACM e Network Load Balancer, l'intero processo è stato abbreviato, perciò ora è sufficiente richiedere un certificato SSL/TLS sicuro e selezionare il certificato ACM per effettuarne il provisioning con il bilanciatore del carico. Una volta creato un Network Load Balancer, è possibile configurare un listener TLS e, in seguito, selezionare un certificato sia da ACM o da Identity Access Manager (IAM). Questa esperienza è simile a quello che si può trovare in Application Load Balancer o Classic Load Balancer.

No, con un sistema Network Load Balancer è supportata solo la crittografia sui back-end.

Network Load Balancer supporta solo certificati RSA con chiavi dimensioni di 2K. Al momento non supportiamo certificati RSA con chiavi di dimensioni superiori a 2K o certificati ECDSA su Network Load Balancer.

Puoi utilizzare la terminazione TLS su Network Load Balancer nelle regioni AWS Stati Uniti orientali (Virginia settentrionale), Stati Uniti orientali (Ohio), Stati Uniti occidentali (California settentrionale), Stati Uniti occidentali (Oregon), Asia Pacifico (Mumbai), Asia Pacifico (Seoul), Asia Pacifico (Singapore), Asia Pacifico (Sydney), Asia Pacifico (Tokyo), Canada (Centrale), UE (Francoforte), UE (Irlanda), UE (Londra), UE (Parigi), Sud America (San Paolo) e GovCloud (Stati Uniti occidentali).

I costi addebitati dipendono dal numero di ore (o frazione di ora) di esecuzione di un sistema Network Load Balancer e al numero di unità di capacità di bilanciamento del carico (Load Balancer Capacity Units, LCU) utilizzate all'ora.

Un'unità di capacità di bilanciamento del carico o LCU rappresenta un nuovo parametro per determinare come strutturare il pagamento per un sistema Network Load Balancer. Un'unità LCU definisce il volume massimo di una risorsa utilizzato in una qualsiasi delle dimensioni (nuove connessioni o flussi, connessioni o flussi attivi e larghezza di banda) in cui Network Load Balancer elabora il traffico.

I parametri LCU per il traffico TCP sono i seguenti:

• 800 nuove connessioni TCP al secondo.
• 100.000 connessioni TCP attive (calcolate al minuto).
• 1 GB all'ora per le istanze Amazon EC2, i container e gli indirizzi IP come destinazioni.

I parametri LCU per il traffico UDP sono i seguenti:

• 400 nuovi flussi al secondo.
• 50.000 flussi UDP attivi (calcolati al minuto).
• 1 GB all'ora per le istanze Amazon EC2, i container e gli indirizzi IP come destinazioni.

I parametri LCU per il traffico TLS sono i seguenti:

• 50 nuove connessioni TLS al secondo.
• 3.000 connessioni TLS attive (calcolate al minuto).
• 1 GB all'ora per le istanze Amazon EC2, i container e gli indirizzi IP come destinazioni.

No, la fatturazione viene calcolata su una sola dimensione, ovvero quella con il maggior utilizzo orario.

No. È possibile inviare diverse richieste con una singola connessione.

No. I costi dei sistemi Classic Load Balancer continueranno ad essere addebitati in base a larghezza di banda e utilizzo orario.

Sarà possibile consultare in Amazon CloudWatch l'utilizzo di tutte e tre le dimensioni che costituiscono un'unità LCU.

No. Il numero di unità LCU all'ora verrà determinato in base al volume massimo di risorse, consumato da tutte e tre le dimensioni, che costituisce un'unità LCU.

Sì.

Sì. Per nuovi account AWS, è disponibile un piano gratuito per un sistema Network Load Balancer, che offre 750 ore e 15 unità LCU. Questa offerta inclusa nel piano gratuito è disponibile solo per nuovi clienti AWS e per 12 mesi dalla data di iscrizione ad AWS.

Sì. Puoi utilizzare sistemi sia Network o Application sia Classic, rispettivamente per 15 unità LCU e 15 GB. Le 750 ore del bilanciatore del carico sono condivise fra Application, Network e Classic Load Balancers.

Utilizza Gateway Load Balancer per distribuire appliance virtuali in linea se il traffico di rete non è destinato allo stesso Gateway Load Balancer. Gateway Load Balancer inoltra con trasparenza tutto il traffico del livello 3 attraverso appliance virtuali di terza parte ed è invisibile all'origine e alla destinazione del traffico. Per maggiori informazioni sul confronto tra questi bilanciatori del carico, consulta la pagina delle funzionalità a confronto.

Gateway Load Balancer è eseguito all'interno di una zona di disponibilità.

Gateway Load Balancer fornisce sia il gateway di livello 3 che le capacità di bilanciamento del carico di livello 4. È un dispositivo bump-in-the-wire trasparente che non modifica nessuna parte del pacchetto. I sistemi di questo tipo sono progettati per gestire milioni di richieste al secondo e modelli di traffico incostanti e, in aggiunta, forniscono latenze estremamente basse. Consulta le funzionalità di Gateway Load Balancer in questa tabella. 

Gateway Load Balancer non esegue la terminazione TLS né conserva lo stato dell'applicazione. Queste funzioni sono eseguite dalle appliance virtuali di terza parte verso cui indirizza il traffico e da cui lo riceve.

Gateway Load Balancer non conserva lo stato dell'applicazione, ma preserva la persistenza dei flussi verso una appliance specifica utilizzando 3 tuple (per i flussi non-TCP/UDP) o 5 tuple (per i flussi TCP/UDP).

Per impostazione predefinita, Gateway Load Balancer definisce un flusso come una combinazione di cinque tuple che comprendono IP di origine, IP di destinazione, protocollo, porta di origine e porta di destinazione. Utilizzando l'hash a cinque tuple predefinito, Gateway Load Balancer assicura che entrambe le direzioni di un flusso (ovvero, da origine a destinazione e da destinazione a origine) vengano inoltrate in modo coerente alla stessa destinazione. Il flusso è considerato attivo fintanto che il traffico scorre e fino al raggiungimento del timeout di inattività. Una volta raggiunta la soglia di timeout, il sistema di bilanciamento del carico dimentica l'affinità e il pacchetto di traffico in entrata viene considerato come un nuovo flusso e il suo carico viene bilanciato su una nuova destinazione.

La persistenza predefinita a cinque tuple (IP di origine, IP di destinazione, protocollo IP, porta di origine e porta di destinazione) fornisce la distribuzione ottimale del traffico verso le destinazioni ed è adatta per la maggior parte delle applicazioni basate su TCP e UDP, con alcune eccezioni. L'hash a cinque tuple predefinito non è adatto per applicazioni basate su TCP o UDP che utilizzano flussi o numeri di porta separati per il controllo e i dati, come FTP, Microsoft RDP, Windows RPC e VPN SSL. Il controllo e i flussi di dati di tali applicazioni possono atterrare su diversi dispositivi di destinazione e possono causare interruzioni del traffico. Se desideri supportare tali protocolli, puoi abilitare la persistenza del flusso GWLB utilizzando l'hash a tre tuple (IP di origine, IP di destinazione, protocollo di trasporto) o a due tuple (IP di origine, IP di destinazione).

Alcune applicazioni non utilizzano affatto il trasporto TCP o UDP ma utilizzano invece protocolli IP come SCTP e GRE. Con la persistenza predefinita a cinque tuple di GWLB, i flussi di traffico provenienti da questi protocolli possono atterrare su diversi dispositivi di destinazione e causare interruzioni. Se desideri supportare tali protocolli, puoi abilitare la persistenza del flusso GWLB utilizzando l'hash a tre tuple (IP di origine, IP di destinazione, protocollo di trasporto) o a due tuple (IP di origine, IP di destinazione).

Per informazioni su come modificare il tipo di persistenza del flusso, vedi la documentazione sulla persistenza del flusso.

Il timeout di inattività di Gateway Load Balancer per le connessioni TCP è di 350 secondi. Il timeout di inattività per i flussi non TCP è di 120 secondi. Questi timeout sono prestabiliti e non possono essere modificati.

Trattandosi di un bump-in-the-wire trasparente, GWLB non frammenta né riassembla i pacchetti.

GWLB inoltra i frammenti UDP da/verso le appliance di destinazione. Tuttavia, GWLB rifiuta i frammenti TCP e ICMP poiché in questi frammenti non è presente l'intestazione di livello 4.

Inoltre, se l'appliance di destinazione converte il contenuto originale del pacchetto in arrivo in frammenti e invia tali frammenti a GWLB, quest'ultimo li elimina in quanto non contengono l'intestazione di livello 4. Per evitare che si verifichi la frammentazione sull'appliance di destinazione, si consiglia di abilitare il frame jumbo sull'appliance di destinazione o di impostare l'interfaccia di rete dell'appliance di destinazione per utilizzare l'MTU massimo desiderato, ottenendo così un comportamento di inoltro trasparente mantenendo il contenuto del pacchetto originale così com'è. 

In caso di errore di una singola istanza di appliance virtuale, Gateway Load Balancer rimuove l'istanza dall'elenco di routing e reindirizza il traffico verso un'istanza di appliance funzionante.

In caso di fallimento di tutte le appliance virtuali all'interno di una zona di disponibilità, Gateway Load Balancer abbandona il traffico di rete. Per una maggiore disponibilità, consigliamo di implementare i Gateway Load Balancer in più zone di disponibilità. In caso di fallimento di tutte le appliance all'interno di una zona di disponibilità, è possibile utilizzare degli script per aggiungere nuove appliance oppure indirizzare il traffico verso un Gateway Load Balancer in un'altra zona di disponibilità.

Sì, è possibile indirizzare diversi Gateway Load Balancer allo stesso set di appliance virtuali.

Gateway Load Balancer è un dispositivo bump-in-the-wire trasparente adatto a tutti i tipi di traffico IP (compresi TCP, UDP, ICMP, GRE, ESP e altri). Per questo motivo, solo il listener IP può essere creato su un Gateway Load Balancer.

Sì, consulta la documentazione relativa alle limitazioniper il sistema Gateway Load Balancer per ulteriori informazioni.

Sì, per configurare un Gateway Load Balancer puoi utilizzare la Console di gestione AWS, AWS CLI o l'API.

Sì, puoi creare un Gateway Load Balancer in una sola zona di disponibilità fornendo una singola sottorete al momento della creazione del bilanciatore del carico. In ogni caso, consigliamo di utilizzare più zone per una migliore disponibilità. Non è possibile aggiungere o rimuovere zone di disponibilità per un Gateway Load Balancer dopo averlo creato.

Da impostazione predefinita, il bilanciamento del carico multizona è disattivato. È possibile attivare il bilanciamento del carico multizona solo dopo la creazione di un Gateway Load Balancer. Per l'attivazione, è necessario modificare la sezione degli attributi del bilanciamento del carico e quindi selezionare la casella relativa al supporto del bilanciamento del carico multizona.

Sì, quando attivi il bilanciamento del carico multizona ti verrà addebitato il costo per il trasferimento dei dati tra le zone di disponibilità con Gateway Load Balancer. Gli addebiti sono specificati nella sezione relativa al trasferimento dei dati alla pagina dei prezzi on demand di Amazon EC2.

Sì. Gateway Load Balancer al momento supporta 300 target per zona di disponibilità. Ad esempio, se hai creato un Gateway Load Balancer in tre zone di disponibilità, potrai contare su un massimo di 900 target registrati. Se è attivo il bilanciamento del carico multizona, il numero massimo di target si riduce da 300 per zona di disponibilità a 300 per Gateway Load Balancer.

Ti verranno addebitati dei costi per ogni ora o frazione di ora in cui un Gateway Load Balancer è in funzione e per il numero di unità di capacità del bilanciatore del carico (LCU) utilizzate da Gateway Load Balancer per ora.

Una LCU è un parametro di Elastic Load Balancing che serve a determinare il pagamento per Gateway Load Balancer. Un'unità LCU definisce il volume massimo di una risorsa utilizzato in una qualsiasi dimensione (nuove connessioni o flussi, connessioni o flussi attivi e larghezza di banda) in cui Gateway Load Balancer elabora il traffico.

I parametri LCU per il traffico TCP sono i seguenti:

• 600 nuovi flussi (o connessioni) al secondo.
• 60.000 flussi attivi (o connessioni) (rilevati al minuto).
• 1 GB all'ora per le istanze EC2, i container e gli indirizzi IP come target.

No, il costo viene calcolato su una sola dimensione, ossia quella con il maggior utilizzo orario.

No. È possibile inviare diverse richieste con una singola connessione.

È possibile monitorare l'utilizzo di tutte e tre le dimensioni di una LCU tramite Amazon CloudWatch.

Sì.

Per essere utili, le appliance virtuali devono introdurre la minima latenza aggiuntiva possibile e il traffico in transito da e verso l'appliance virtuale deve utilizzare una connessione sicura. Gli endpoint Gateway Load Balancer creano le connessioni protette e a bassa latenza necessarie per soddisfare tali requisiti.

Utilizzando un endpoint Gateway Load Balancer, le appliance possono trovarsi in account AWS e VPC differenti. Questo consente di centralizzare le appliance in una sede per facilitarne la gestione e ridurre il carico operativo.

Gli endpoint Gateway Load Balancer sono una nuova tipologia di endpoint VPC che impiega la tecnologia PrivateLink. Quando il traffico di rete transita da un'origine (ad esempio un gateway Internet, un VPC, ecc.) al Gateway Load Balancer, e viceversa, l'endpoint Gateway Load Balancer garantisce la connettività privata tra i due. Tutto il traffico transita sulla rete AWS e i dati non sono mai esposti a Internet, migliorando sia la sicurezza sia le prestazioni.

Un endpoint PrivateLink Interface è abbinato a un Network Load Balancer (NLB) al fine di distribuire il traffico TCP e UDP destinato alle applicazioni Web. Invece, gli endpoint Gateway Load Balancer sono utilizzati con i Gateway Load Balancer per connettere l'origine e la destinazione del traffico. Il traffico transita dall'endpoint Gateway Load Balancer al Gateway Load Balancer, attraverso le appliance virtuali, e torna alla destinazione mediante connessioni PrivateLink protette.

Un endpoint Gateway Load Balancer è un endpoint VPC e il numero di endpoint VPC che si possono connettere a un servizio che utilizza Gateway Load Balancer è illimitato. Tuttavia, consigliamo di non connettere più di cinquanta endpoint Gateway Load Balancer per ogni Gateway Load Balancer in modo da ridurre il rischio di un impatto maggiore in caso di interruzione del servizio.

Classic Load Balancer supporta istanze Amazon EC2 con qualsiasi sistema operativo attualmente supportato dal servizio Amazon EC2.

Classic Load Balancer supporta il bilanciamento del carico di applicazioni che impiegano i protocolli HTTP, HTTPS (Secure HTTP), SSL (Secure TCP) e TCP.

Puoi effettuare il bilanciamento del carico per le seguenti porte TCP:

• [EC2-VPC] 1-65535
• [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535

Sì. A ogni Classic Load Balancer viene associato un nome DNS per IPv4, IPv6 e dualstack (sia IPv4 che IPv6). Il protocollo IPv6 non è supportato in VPC. In questo caso, si consiglia di usare Application Load Balancer con supporto nativo per IPv6.

Sì.

Se stai usando Amazon Virtual Private Cloud, puoi configurare dei gruppi di sicurezza per il front-end dei tuoi sistemi Classic Load Balancer.

Sì, puoi mappare la porta HTTP 80 e la porta HTTP 443 a un singolo Classic Load Balancer.

I Classic Load Balancer non limitano il numero di connessioni che possono tentare di stabilire con le tue istanze di Amazon EC2 con carico bilanciato. Queste connessioni possono ricalibrarsi in base al numero di richieste HTTP, HTTPS o SSL simultanee o al numero di connessioni TCP simultanee ricevute dai sistemi Classic Load Balancer.

Puoi bilanciare il carico delle istanze Amazon EC2 lanciate tramite un'AMI a pagamento da AWS Marketplace. Tuttavia, i sistemi Classic Load Balancer non supportano le istanze avviate tramite un'AMI a pagamento dal sito Amazon DevPay.

Sì. Consulta la pagina Web di Elastic Load Balancing.

Sì. Per ricevere uno storico di tutte le chiamate delle API di Classic Load Balancer effettuate sul tuo account, non devi fare altro che attivare CloudTrail nella Console di gestione AWS.

Sì, è possibile eseguire la terminazione SSL sui sistemi Classic Load Balancer. Sarà tuttavia necessario installare su ciascuno di essi un certificato SSL. I sistemi di bilanciamento del carico utilizzano questo certificato per terminare la connessione e quindi decrittografare le richieste provenienti dai client prima di inoltrarle alle istanze back-end.

Puoi utilizzare Gestione certificati AWS per effettuare il provisioning di un certificato SSL/TLS oppure ottenerlo da altre fonti creando una richiesta di certificato, facendola firmare da un'autorità di certificazione (CA) e quindi caricando il certificato utilizzando il servizio AWS Identity and Access Management (IAM).

I sistemi Classic Load Balancer sono ora integrati con AWS Certificate Management (ACM). L'integrazione con questo servizio aiuta ad associare i certificati a ciascun sistema di bilanciamento del carico, rendendo ancora più semplice la ripartizione del carico SSL. L'acquisto, il caricamento e il rinnovo dei certificati SSL/TLS è un processo manuale lungo e complicato. Grazie all'integrazione tra ACM e i sistemi Classic Load Balancer, l'intero processo è stato abbreviato, perciò ora è sufficiente richiedere un certificato SSL/TLS sicuro e selezionare il certificato ACM per effettuarne il provisioning con il sistema di bilanciamento del carico.

Puoi attivare il bilanciamento del carico tra zone tramite la console, l'interfaccia a riga di comando (CLI) AWS o un SDK AWS. Per ulteriori dettagli, consulta la documentazione relativa al bilanciamento del carico tra zone.

No, non verrà addebitato alcun costo per il trasferimento regionale dei dati tra zone di disponibilità quando attivi il bilanciamento del carico tra zone per un sistema Classic Load Balancer.