Domande generali
D: In che modo posso selezionare il bilanciatore del carico più adatto per un'applicazione?
R: Elastic Load Balancing (ELB) supporta quattro tipi di bilanciatori del carico. L'opzione più adatta dipende dalle esigenze specifiche dell'applicazione. Se è necessario bilanciare il carico delle richieste HTTP, consigliamo di utilizzare Application Load Balancer (ALB). Per i protocolli di rete/trasporto (livello4 - TCP, UDP) per il bilanciamento del carico e per le applicazioni con prestazioni eccezionali/a bassa latenza, consigliamo di utilizzare Network Load Balancer. Se l'applicazione è stata costruita in una rete Amazon Elastic Compute Cloud (Amazon EC2) classica, conviene utilizzare Classic Load Balancer. Se hai bisogno di implementare ed eseguire appliance virtuali di terze parti, puoi utilizzare Gateway Load Balancer.
D: È possibile accedere privatamente alle API Elastic Load Balancing da un Amazon Virtual Private Cloud (VPC) senza utilizzare un IP pubblico?
R: Sì, è possibile accedere privatamente alle API di Elastic Load Balancing da un Amazon Virtual Private Cloud (VPC) creando degli endpoint VPC. Grazie agli endpoint VPC, il routing tra il VPC e le API di Elastic Load Balancing viene gestito dalla rete AWS senza necessità di gateway Internet, gateway NAT (network address translation) o connessioni a rete privata virtuale (VPN). La generazione più recente di endpoint VPC utilizzata da Elastic Load Balancing è basata su AWS PrivateLink, una tecnologia AWS che permette connessioni private tra servizi AWS utilizzando interfacce di rete elastica (ENI, Elastic Network Interface) con IP privati nei VPC. Per ulteriori informazioni su AWS PrivateLink, consulta la relativa documentazione AWS PrivateLink.
D: Esiste un SLA per i sistemi di bilanciamento del carico?
R: Sì, Elastic Load Balancing garantisce una disponibilità mensile di almeno il 99,99% dei sistemi di bilanciamento del carico (Classic, Application or Network). Per maggiori informazioni su SLA e per sapere se hai diritto a un credito, visita questa pagina.
Application Load Balancer
D: Quali sistemi operativi supportata Application Load Balancer?
R: Application Load Balancer supporta destinazioni con qualsiasi sistema operativo attualmente supportato dal servizio Amazon EC2.
D: Quali protocolli supporta Application Load Balancer?
R: Application Load Balancer supporta il bilanciamento del carico di applicazioni che utilizzano i protocolli HTTP e HTTPS (Secure HTTP).
D: I sistemi Application Load Balancer supportano il protocollo HTTP/2?
R: 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.
D: Come posso utilizzare un IP statico o PrivateLink sul mio Application Load Balancer?
R: Puoi trasmettere il traffico dal tuo bilanciatore del carico di rete, 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.
D: Quali porte TCP è possibile utilizzare per il bilanciamento del carico?
R: Puoi effettuare il bilanciamento del carico per le seguenti porte TCP: 1-65535
D: WebSockets è supportato su Application Load Balancer?
R: Sì. Il supporto di WebSockets e Secure WebSockets è abilitato in modo nativo ed è pronto per l'uso su un sistema Application Load Balancer.
D: Application Load Balancer supporta il monitoraggio delle richieste?
R: Sì. Il monitoraggio delle richieste è attivo di default su Application Load Balancer.
D: Classic Load Balancer presenta le stesse caratteristiche e vantaggi di Application Load Balancer?
R: Anche se c'è una certa sovrapposizione, non c'è parità completa di caratteristiche tra i due tipi di sistemi di bilanciamento 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.
D: È possibile configurare le istanze Amazon EC2 in modo che accettino esclusivamente il traffico proveniente dai sistemi Application Load Balancer?
R: Sì.
D: È possibile configurare un gruppo di sicurezza per il front-end di un sistema Application Load Balancer?
R: Sì.
D: È possibile utilizzare con un sistema Application Load Balancer le API esistenti in uso in un sistema Classic Load Balancer?
R: No, per Application Load Balancer è necessario un nuovo set di interfacce del programma dell'applicazione (API).
D: In che modo è possibile gestire contemporaneamente Application Load Balancer e Classic Load Balancer?
R: La console ELB permette di gestire i sistemi Application e Classic Load Balancer 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`.
D: È possibile convertire un sistema Classic Load Balancer in un sistema Application Load Balancer (e viceversa)?
R: No, non è possibile convertire un tipo di bilanciatore del carico in un altro.
D: È possibile eseguire la migrazione ad un sistema Application Load Balancer da un sistema Classic Load Balancer?
R: Sì. È possibile eseguire la migrazione ad Application Load Balancer da Classic Load Balancer tramite una delle opzioni elencate in questo documento.
D: È possibile usare un sistema Application Load Balancer come sistema di bilanciamento a livello 4?
R: No, se devi disporre di caratteristiche di livello 4 è necessario usare un sistema Network Load Balancer.
D: È possibile usare un singolo sistema Application Load Balancer per gestire richieste HTTP e HTTPS?
R: Sì, puoi aggiungere listener per la porta HTTP 80 e la porta HTTPS 443 a un singolo sistema Application Load Balancer.
D: Posso ottenere uno storico delle chiamate API di Application Load Balancer effettuate sul mio account a scopo di analisi della sicurezza e di soluzione di problemi funzionali?
R: Sì. Per ricevere uno storico delle chiamate API Application Load Balancing effettuate sul tuo account, usa AWS CloudTrail.
D: Application Load Balancer supporta la terminazione HTTPS?
R: Sì, su Application Load Balancer puoi terminare la connessione HTTPS. Sarà tuttavia necessario installarvi un certificato SSL (Secure Sockets Layer). Il bilanciatore del carico utilizzerà il certificato per terminare la connessione e quindi decrittografare le richieste provenienti dai client prima di inoltrarle alle destinazioni.
D: In che modo è possibile ottenere un certificato SSL?
R: 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).
D: In che modo Application Load Balancer si integra con AWS Certificate Manager (ACM)?
R: 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 bilanciatore del carico.
D: L'autenticazione server back-end è supportata con un sistema Application Load Balancer?
R: No, con un sistema Application Load Balancer è supportata solo la crittografia sui back-end.
D: In che modo è possibile abilitare l'estensione SNI (Server Name Indication) per un Application Load Balancer?
R: L'estensione SNI viene abilitata automaticamente quando associ 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.
D: È possibile associare più certificati per uno stesso dominio a un listener protetto?
R: Sì, è possibile associare più certificati per lo 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
D: Il protocollo IPv6 è supportato con un sistema Application Load Balancer?
R: Sì, IPv6 è supportato con un sistema Application Load Balancer.
D: Come si impostano regole su un sistema Application Load Balancer?
R: È 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.
D: Sono previste limitazioni alle risorse per un sistema Application Load Balancer?
R: Il tuo account AWS ha questi limiti per un sistema Application Load Balancer.
D: In che modo è possibile proteggere le applicazioni Web registrate a un bilanciatore del carico dalle minacce provenienti dal Web?
R: 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 (niform resource identifier) personalizzate. Tramite queste regole, AWS WAF blocca, consente o monitora (conteggia) le richieste Web dirette all'applicazione Web. Per ulteriori informazioni, consulta la Guida per sviluppatori AWS WAF.
D: È possibile bilanciare il carico su un indirizzo IP arbitrario?
R: È 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 in locale raggiungibili tramite AWS Direct Connect o connessione VPN).
D: In che modo è possibile bilanciare il carico delle applicazioni distribuite su un VPC e in locale?
R: Esistono vari modi per ottenere un bilanciamento del 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.
D: In che modo è possibile bilanciare il carico sulle istanze EC2-Classic?
R: Non è possibile bilanciare il carico sulle istanze EC2-Classic quando si registrano gli ID istanza come destinazioni. Tuttavia, se si collegano queste istanze EC2-Classic al VPC 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.
D: In che modo è possibile attivare il bilanciamento del carico multizona in Application Load Balancer?
R: Il bilanciamento del carico tra zone è già attivo in maniera predefinita in Application Load Balancer.
D: In quali casi è più indicato autenticare gli utenti tramite l'integrazione di Application Load Balancer con Amazon Cognito oppure con il supporto nativo per i provider di identità OpenID Connect (OIDC)?
R: 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.
D: Quali tipi di reindirizzamento supporta Application Load Balancer?
R: Sono supportati i seguenti tre tipi di reindirizzamento.
Tipi di reindirizzamento | Esempi |
---|---|
Da HTTP ad HTTP | Da http://hostA ad http://hostB |
Da HTTP ad HTTPS | Da http://hostA a https://hostB |
Da HTTPS ad HTTPS | Da https://hostA ad https://hostB |
D: Quali tipi di contenuti supporta ALB per il corpo di un messaggio di un'operazione di risposta fissa?
R: Sono supportati i seguenti tipi di contenuto: testo/semplice, testo/css, testo/html, applicazione/javascript, applicazione/json.
D: Come funziona l'invocazione di AWS Lambda tramite Application Load Balancer?
R: 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.
D: L'invocazione Lambda tramite Application Load Balancer supporta richieste sia dal protocollo HTTP che HTTPS?
R: Sì. Application Load Balancer supporta l'invocazione Lambda per richieste sia dal protocollo HTTP che HTTPS.
D: In quali Regioni AWS posso utilizzare le funzioni Lambda come destinazioni con il sistema Application Load Balancer?
R: 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).
D: Application Load Balancer è disponibile nelle AWS Local Zones?
R: 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.
D: Come sono strutturati i prezzi di Application Load Balancer?
R: I costi addebitati dipendono dal numero di ore (o frazione di ora) di esecuzione di un sistema Application Load Balancer e dal numero di unità di capacità di bilanciamento del carico (Load Balancer Capacity Units, LCU) utilizzate all'ora.
D: Cos'è un'unità di capacità di bilanciamento del carico (LCU)?
R: Un'unità di capacità di bilanciamento del carico (LCU) rappresenta un nuovo parametro per determinare la modalità di 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.
D: I costi di un sistema Classic Load Balancer vengono fatturati per LCU?
R: No, i costi dei sistemi Classic Load Balancer continueranno a essere fatturati in base all'utilizzo orario e della larghezza di banda.
D: In che modo è possibile determinare il numero di unità LCU utilizzate da un sistema Application Load Balancer?
R: L'utilizzo di tutte e quattro le dimensioni che costituiscono un'unità LCU viene esposto tramite Amazon CloudWatch.
D: Mi verrà addebitato il costo di tutte le dimensioni incluse in un'unità LCU?
R: Il numero di unità LCU all'ora verrà determinato in base al volume massimo di risorse utilizzato da tutte e quattro le dimensioni che costituiscono un'unità LCU.
D: Mi verrà addebitato il costo di unità LCU parziali?
R: Sì.
D: È disponibile un piano gratuito di Application Load Balancer per nuovi account AWS?
R: 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.
D: È possibile usare una combinazione di sistemi Application Load Balancer e Classic Load Balancer nell'ambito del piano gratuito?
R: Sì. Puoi utilizzare sia Classic Load Balancer che Application Load Balancer rispettivamente per 15 GB e 15 unità LCU. Le 750 ore del bilanciatore del carico sono condivise fra i due sistemi Classic e Application Load Balancer.
D: Cosa sono le valutazioni delle regole?
R: Le valutazioni delle regole possono essere definite come il prodotto del numero di regole elaborate e la media del tasso di richieste per un'ora.
D: Come varia la fatturazione delle unità LCU in base ai tipi di certificato e alle dimensioni delle chiavi?
R: Le dimensioni della chiave del certificato influiscono solo sul 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 | <=4K | <=8K | >8K |
Nuove connessioni al secondo | 25 | 5 | 1 | 0,25 |
Certificati ECDSA | ||||
---|---|---|---|---|
Dimensioni chiave | <=256 | <=384 | <=521 | 521 o più |
Nuove connessioni al secondo | 25 | 5 | 1 | 0,25 |
D: Mi verranno addebitati dei costi per il trasferimento regionale dei dati AWS quando attivo il bilanciamento del carico multizona in Application Load Balancer?
R: No, poiché il bilanciamento del carico tra zone è sempre attivo con Application Load Balancer, non sono previsti costi aggiuntivi per questo tipo di trasferimento dati regionale.
D: L'autenticazione degli utenti in un sistema Application Load Balancer viene addebitata separatamente?
R: 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.
D: Come viene addebitato l'utilizzo di Application Load Balancer con destinazioni AWS Lambda?
R: 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.
D: Come faccio a sapere la quantità di byte elaborati da destinazioni Lambda rispetto a quelli elaborati da altre destinazioni (Amazon EC2, container e server On-Premise)?
R: 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.
Network Load Balancer
D: È possibile creare un listener TCP o UDP (livello 4) per un sistema Network Load Balancer?
R: Sì. I sistemi Network Load Balancer supportano sia listener TCP, UDP e TCP+UDP (livello 4), sia quelli del protocollo TLS.
D: Quali sono le caratteristiche chiave di Network Load Balancer?
R: 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.
D: Network Load Balancer può processare sia il traffico di protocollo TCP che UDP sulla stessa porta?
R: 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.
D: Quali sono le differenze tra un sistema Network Load Balancer e il risultato che è possibile ottenere con un listener TCP su un sistema Classic Load Balancer?
R: 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.
D: Posso eseguire la migrazione a Network Load Balancer da Classic Load Balancer?
R: Sì. È possibile eseguire la migrazione a Network Load Balancer da Classic Load Balancer tramite una delle opzioni elencate in questo documento.
D: Sono previste limitazioni alle risorse per un sistema Network Load Balancer?
R: Sì, consulta la documentazione relativa alle limitazioni per il sistema Network Load Balancer per ulteriori informazioni.
D: È possibile utilizzare la Console di gestione AWS per impostare un sistema Network Load Balancer?
R: Sì, per configurare un sistema Network Load Balancer puoi utilizzare la console di gestione AWS, l'interfaccia a riga di comando (CLI) di AWS o l'API.
D: È possibile utilizzare l'API esistente per sistemi Classic Load Balancer con un sistema Network Load Balancer?
R: 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.
D: È possibile creare un sistema Network Load Balancer in una sola zona di disponibilità?
R: 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.
D: I sistemi Network Load Balancer supportano il failover DNS di regione o di zona?
R: Sì, puoi usare le caratteristiche di controllo dello stato e di failover DNS di Amazon Route 53 per potenziare la disponibilità delle applicazioni in esecuzione dietro i sistemi Network 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.
D: È possibile ottenere un sistema Network Load Balancer con sia IP forniti da ELB sia IP elastici o IP privati assegnati?
R: No, gli indirizzi di un sistema Network Load Balancer devono essere controllati interamente dall'utente o interamente da ELB. Quando sono in uso indirizzi IP elastici in un sistema Network Load Balancer, infatti, è importante che tutti gli indirizzi noti ai client non subiscano modifiche.
D: È possibile assegnare più di un indirizzo IP elastico a un sistema Network Load Balancer in ciascuna sottorete?
R: No, per ogni sottorete associata che contiene un sistema Network Load Balancer, quest'ultimo supporterà un solo indirizzo IP pubblico o collegato a Internet.
D: Cosa accade agli indirizzi IP elastici associati a un sistema Network Load Balancer quando viene rimosso o eliminato?
R: Gli indirizzi IP elastici che erano associati al bilanciatore del carico torneranno nel pool allocato e potranno essere riutilizzati in futuro.
D: Network Load Balancer supporta bilanciatori del carico interni?
R: Un sistema 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.
D: Un sistema Network Load Balancer interno può supportare più di un IP privato per ogni sottorete?
R: No, per ogni sottorete associata che contiene un bilanciatore del carico, il sistema Network Load Balancer supporta un solo IP privato.
D: È possibile configurare WebSocket con un sistema Network Load Balancer?
R: Sì, è sufficiente configurare dei listener TCP che effettuino il routing del 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.
D: È possibile bilanciare il carico su un indirizzo IP arbitrario?
R: Sì. È possibile usare qualsiasi indirizzo IP dal CIDR dell'istanza VPC del bilanciatore 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 al VPC del bilanciatore del carico (EC2-Classic e percorsi On-Premise 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.
D: È possibile usare Network Load Balancer per configurare AWS PrivateLink?
R: 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.
D: Cos'è un flusso UDP?
R: 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.
D: Qual è il timeout di inattività supportato da Network Load Balancer?
R: 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.
D: Quali vantaggi offrono i container con bilanciatori del carico che impiegano indirizzi IP invece di istanze ID?
R: Ogni container su un'istanza ora può avere il proprio gruppo di sicurezza e non deve condividere 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.
D: In che modo è possibile bilanciare il carico delle applicazioni distribuite su un VPC e in locale?
R: Esistono vari modi per ottenere un bilanciamento del 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.
D: In che modo è possibile bilanciare il carico sulle istanze EC2-Classic?
R: Non è possibile bilanciare il carico sulle istanze EC2-Classic quando si registrano gli ID istanza come destinazioni. Tuttavia, se si collegano queste istanze EC2-Classic al VPC 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.
D: In che modo è possibile abilitare il bilanciamento del carico tra più zone in Network Load Balancer?
R: È possibile abilitare il bilanciamento del carico tra zone 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.
D: Mi verranno addebitati dei costi per il trasferimento dei dati AWS quando attivo il bilanciamento del carico tra più zone in Network Load Balancer?
R: 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 tra zone. Gli addebiti sono specificati nella sezione relativa al trasferimento dei dati alla pagina dei prezzi on demand di Amazon EC2.
D: Il bilanciamento del carico tra più zone ha conseguenze sui limiti di Network Load Balancer?
R: 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.
D: Network Load Balancer supporta la terminazione TLS?
R: 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.
D: L'IP sorgente viene preservato quando si termina TLS su Network Load Balancer?
R: L'IP sorgente continua ad essere mantenuto anche se si termina TLS su Network Load Balancer.
D: In che modo è possibile ottenere un certificato SSL?
R: 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).
D: In che modo è possibile abilitare l'estensione SNI (Server Name Indication) per un Network Load Balancer?
R: L'estensione SNI viene abilitata automaticamente quando associ più di un certificato TLS allo stesso listener protetto in un bilanciatore del carico. Analogamente, l'estensione SNI viene disabilitata automaticamente quando è presente un solo certificato associato a un listener protetto.
D: In che modo Network Load Balancer si integra ad AWS Certificate Manager (ACM) o a Identity Access Manager (IAM)?
R: 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.
D: L'autenticazione server back-end è supportata con un sistema Network Load Balancer?
R: No, con un sistema Network Load Balancer è supportata solo la crittografia sui back-end.
D: Quali sono i tipi di certificato supportati da Network Load Balancer?
R: 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.
D: In quali regioni AWS è supportata la terminazione TLS su Network Load Balancer?
R: 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).
D: Come sono strutturati i prezzi di Network Load Balancer?
R: I costi addebitati dipendono dal numero di ore (o frazione di ora) di esecuzione di un sistema Network Load Balancer e dal numero di unità di capacità di bilanciamento del carico (Load Balancer Capacity Units, LCU) utilizzate da Network Load Balancer all'ora.
D: Cos'è un'unità di capacità di bilanciamento del carico (LCU)?
R: Un'unità di capacità di bilanciamento del carico (LCU) rappresenta un nuovo parametro per determinare la modalità di 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.
D: Quali sono i parametri LCU per il traffico TCP su Network Load Balancer?
R: 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.
R: 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.
D: Quali sono i parametri LCU per il traffico TLS su Network Load Balancer?
R: 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.
D: Il parametro nuove connessioni o flussi al secondo corrisponde a richieste al secondo?
R: No, è possibile inviare diverse richieste con una singola connessione.
D: I costi di un sistema Classic Load Balancer vengono fatturati per LCU?
R: No, i costi dei sistemi Classic Load Balancer continueranno a essere addebitati in base all'utilizzo orario e della larghezza di banda.
D: In che modo è possibile determinare il numero di unità LCU utilizzate da un sistema Network Load Balancer?
R: L'utilizzo di tutte e tre le dimensioni che costituiscono un'unità LCU viene esposto tramite Amazon CloudWatch.
D: Mi verrà addebitato il costo di tutte le dimensioni incluse in un'unità LCU?
R: 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 costituiscono un'unità LCU.
D: Mi verrà addebitato il costo di unità LCU parziali?
R: Sì.
D: È disponibile un piano gratuito di Network Load Balancer per nuovi account AWS?
R: 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.
D: È possibile usare una combinazione di sistemi Network Load Balancer, Application Load Balancer e Classic Load Balancer nell'ambito del piano gratuito?
R: 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.
Gateway Load Balancer
Nozioni di base
D: In quali circostanze dovrei utilizzare Gateway Load Balancer in alternativa a Network Load Balancer o ad Application Load Balancer?
R: Dovresti utilizzare Gateway Load Balancer per distribuire appliance virtuali in linea nel caso in cui il traffico di rete non sia destinato allo stesso Gateway Load Balancer. Gateway Load Balancer inoltra con trasparenza tutto il traffico del livello 3 attraverso appliance virtuali di terze parti, ed è invisibile sia all'origine sia alla destinazione del traffico. Per maggiori informazioni sul confronto tra questi sistemi di bilanciamento del carico, consulta la pagina delle funzionalità a confronto.
D: Gateway Load Balancer è implementato per regioni o per zone di disponibilità?
Gateway Load Balancer è eseguito all'interno di una zona di disponibilità.
D: Quali sono le caratteristiche chiave di Gateway Load Balancer?
R: 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 caratteristiche di Gateway Load Balancer in questa tabella.
D: Gateway Load Balancer esegue la terminazione TLS?
Gateway Load Balancer non esegue la terminazione TLS né conserva lo stato dell'applicazione. Queste funzioni sono eseguite dalle appliance virtuali di terze parti verso cui indirizza il traffico e da cui lo riceve.
D: Gateway Load Balancer conserva lo stato dell'applicazione?
R: Il 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).
D: In che modo Gateway Load Balancer definisce un flusso?
R: 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.
D: Quando devo utilizzare la viscosità a cinque tuple, tre tuple e due tuple su Gateway Load Balancer?
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.
D: Qual è il timeout di inattività supportato da Gateway Load Balancer?
R: 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.
D: GWLB supporta la frammentazione dei pacchetti?
R: 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'è.
D: In quale modo il Gateway Load Balancer gestisce il fallimento di un'istanza di appliance virtuale in una singola zona di disponibilità?
R: In caso di fallimento 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 integra.
D: In che modo Gateway Load Balancer gestisce il fallimento di tutte le appliance virtuali in una singola zona di disponibilità?
R: 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à.
D: Posso configurare un'appliance come target per più di un Gateway Load Balancer?
R: Sì, è possibile indirizzare diversi Gateway Load Balancer allo stesso set di appliance virtuali.
Q: Che tipo di listener posso creare dal mio Gateway Load Balancer?
R: 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.
D: Sono previste limitazioni alle risorse per il Gateway Load Balancer?
R: Sì, consulta la documentazione relativa alle limitazioniper il sistema Gateway Network Load Balancer per ulteriori informazioni.
D: È possibile utilizzare la Console di gestione AWS per configurare un Gateway Load Balancer?
R: Sì, per configurare un Gateway Load Balancer puoi utilizzare la Console di gestione AWS, AWS CLI o l'API.
D: È possibile creare un Gateway Load Balancer in una sola zona di disponibilità?
R: 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.
Q: In che modo è possibile attivare il bilanciamento del carico multizona in Gateway Load Balancer?
R: Da impostazione predefinita, il bilanciamento del carico multizona è disattivato in Gateway Load Balancer. È 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.
D: Mi verranno addebitati dei costi per il trasferimento dei dati AWS quando attivo il bilanciamento del carico multizona in Gateway Load Balancer?
R: 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.
D: Il bilanciamento del carico multizona ha delle conseguenze sui limiti di Gateway Load Balancer?
R: 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.
Domande frequenti sui prezzi di Gateway Load Balancer
D: Come funzionano i prezzi di Gateway Load Balancer?
R: 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.
D: Cos'è un'unità di capacità del bilanciatore del carico (LCU)?
R: 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.
D: Quali sono i parametri LCU per il traffico TLS per Gateway Load Balancer?
R: 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.
R: No, il costo viene calcolato su una sola dimensione, ossia quella con il maggior utilizzo orario.
Endpoint Gateway Load Balancer
D: Perché è utile un endpoint Gateway Load Balancer?
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.
D: In che modo gli endpoint Gateway Load Balancer contribuiscono alla centralizzazione?
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.
D: Come funzionano gli endpoint Gateway Load Balancer?
Gli endpoint Gateway Load Balancer sono una nuova tipologia di endpoint VPC che utilizza 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.
D: Qual è la differenza tra gli endpoint PrivateLink Interface e gli endpoint Gateway Load Balancer?
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.
D: Quanti endpoint Gateway Load Balancer posso connettere a un Gateway Load Balancer?
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
D: Quali sistemi operativi supporta Classic Load Balancer?
R: Classic Load Balancer supporta istanze Amazon EC2 con qualsiasi sistema operativo attualmente supportato dal servizio Amazon EC2.
D: Quali protocolli supporta Classic Load Balancer?
R: Classic Load Balancer supporta il bilanciamento del carico di applicazioni che impiegano i protocolli HTTP, HTTPS (Secure HTTP), SSL (Secure TCP) e TCP.
D: Quali sono le porte TCP di cui posso bilanciare il carico?
R: Puoi effettuare il bilanciamento del carico per le seguenti porte TCP:
- [EC2-VPC] 1-65535
- [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535
D: Classic Load Balancer supporta il traffico IPv6?
R: 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.
D: Posso configurare le mie istanze Amazon EC2 in modo che accettino solo il traffico proveniente da sistemi Classic Load Balancer?
R: Sì.
D: Posso configurare un gruppo di sicurezza per il front-end di sistemi Classic Load Balancer?
R: Se stai usando Amazon Virtual Private Cloud, puoi configurare gruppi di sicurezza per il front-end dei tuoi sistemi Classic Load Balancer.
D: Posso usare un singolo Classic Load Balancer per gestire richieste HTTP e HTTPS?
R: Sì, puoi mappare la porta HTTP 80 e la porta HTTPS 443 a un singolo Classic Load Balancer.
D: Quante connessioni deve accettare le istanze Amazon EC2 con bilanciamento del carico da ciascun sistema Classic Load Balancer?
R: I sistemi Classic Load Balancer non limitano il numero di connessioni che possono tentare di stabilire con le istanze 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.
D: Posso bilanciare il carico delle istanze Amazon EC2 lanciate tramite un'AMI a pagamento?
R: 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.
D: Posso usare Classic Load Balancer in Amazon Virtual Private Cloud?
R: Sì. Consulta la pagina Web di Elastic Load Balancing.
D: Posso ottenere uno storico delle chiamate API di Classic Load Balancer effettuate sul mio account a scopo di analisi della sicurezza e di soluzione di problemi funzionali?
R: 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.
D: Classic Load Balancer supporta la terminazione SSL?
R: Sì, è possibile terminare 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.
D: In che modo è possibile ottenere un certificato SSL?
R: 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 il servizio AWS Identity and Access Management (IAM).
D: In che modo i sistemi Classic Load Balancer si integrano con AWS Certificate Manager (ACM)?
R: 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.
Q: Come posso attivare il bilanciamento del carico tra zone in Classic Load Balancer?
R: Puoi attivare il bilanciamento del carico tra zone tramite la console, l'interfaccia a riga di comando (CLI) di AWS o un SDK AWS. Per ulteriori dettagli, consulta la documentazione relativa al bilanciamento del carico tra zone.
D: Mi verranno addebitati dei costi per il trasferimento regionale dei dati AWS quando attivo il bilanciamento del carico multizona in Classic Load Balancer?
R: 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.
Visita la pagina dei prezzi
Ottieni l'accesso immediato al piano gratuito di AWS.