

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Cluster Amazon ECS
<a name="clusters"></a>

Un cluster Amazon ECS è un raggruppamento logico di attività o servizi che fornisce la capacità dell'infrastruttura per le applicazioni containerizzate. Quando crei un cluster, puoi scegliere tra i tre tipi di infrastruttura principali, ciascuno ottimizzato per differenti casi d'uso e requisiti operativi.

## Scegliere il tipo di cluster giusto
<a name="cluster-types-overview"></a>

Amazon ECS fornisce tre tipi di infrastruttura per i tuoi cluster. Scegli il tipo più adatto alle tue esigenze in termini di carico di lavoro, alle tue preferenze operative e ai tuoi obiettivi di ottimizzazione dei costi:

Istanze gestite da Amazon ECS (consigliate)  
**Ideale per la maggior parte dei carichi di lavoro**: gestisce AWS completamente le istanze Amazon EC2 sottostanti, inclusi il provisioning, l'applicazione di patch e il ridimensionamento. Questa opzione offre un equilibrio ottimale tra prestazioni, convenienza economica e semplicità operativa.  
**Da usare quando:**  
+ Vuoi gestire la gestione dell'infrastruttura AWS 
+ Servono risorse di calcolo convenienti con ottimizzazione automatica
+ Ci si vuole concentrare sulle proprie applicazioni invece che sull’infrastruttura
+ Servono prestazioni prevedibili con dimensionamento flessibile

Fargate  
**Elaborazione serverless:** paghi solo per le risorse usate dalle tue attività senza dover gestire alcuna infrastruttura. Ideale per carichi di lavoro variabili e per iniziare rapidamente.  
**Da usare quando:**  
+ Si vogliono operazioni completamente serverless
+ Si hanno carichi di lavoro imprevedibili o variabili
+ Si vuole ridurre al minimo il sovraccarico operativo
+ Servono dimensionamento e implementazioni rapide

Istanze Amazon EC2  
**Controllo completo**: gestisci direttamente le istanze Amazon EC2 sottostanti, incluse la selezione, la configurazione e la manutenzione delle istanze.  
**Da usare quando:**  
+ Servono configurazioni o tipi di istanze specifici
+ Si ha un’infrastruttura Amazon EC2 esistente da sfruttare
+ È necessario un software personalizzato AMIs o specializzato
+ Serve il massimo controllo sull’infrastruttura sottostante

**Nota**  
Amazon ECS Managed Instances è la scelta consigliata per la maggior parte dei nuovi carichi di lavoro in quanto offre la migliore combinazione di prestazioni, ottimizzazione dei costi e semplicità operativa, consentendo AWS al contempo di gestire le attività di gestione dell'infrastruttura.

## Componenti del cluster
<a name="cluster-components"></a>

Oltre alla capacità dell'infrastruttura, un cluster è costituito dalle seguenti risorse:
+ La rete (VPC e sottorete) su cui vengono eseguite le attività e i servizi

  Quando utilizzi Istanze gestite da Amazon ECS o Istanze Amazon EC2 per la capacità, la sottorete può trovarsi in zone di disponibilità, locali, di lunghezza d'onda o AWS Outposts.
+ Un namespace facoltativo

  Un namespace viene utilizzato per la service-to-service comunicazione con Service Connect.
+ Un'opzione di monitoraggio

  CloudWatch Container Insights ha un costo aggiuntivo ed è un servizio completamente gestito. Raccoglie, aggrega e riepiloga automaticamente parametri e log di Amazon ECS. 

## Concetti relativi ai cluster
<a name="cluster-concepts"></a>

Di seguito sono elencati i concetti generali sui cluster Amazon ECS.
+ I cluster vengono creati per separare le risorse.
+ I cluster sono Regione AWS specifici.
+ I cluster possono trovarsi in uno dei seguenti stati.  
ACTIVE  
Il cluster è pronto per accettare i processi e, se applicabile, puoi registrare le istanze del container con il cluster.  
PROVISIONING  
Al cluster sono associati provider di capacità e vengono create le risorse necessarie per il provider di capacità.  
DEPROVISIONING  
Al cluster sono associati provider di capacità e le risorse necessarie per il provider di capacità vengono eliminate.  
NON RIUSCITO  
Al cluster sono associati provider di capacità e le risorse necessarie per il provider di capacità non sono state create.  
INACTIVE  
Il cluster è stato eliminato. I cluster con stato `INACTIVE` potrebbero rimanere individuabili nel tuo account per un periodo di tempo. Questo comportamento è soggetto a modifiche in futuro, quindi non dovresti fare affidamento sulla persistenza dei cluster `INACTIVE`.
+ Un cluster può contenere una combinazione di attività ospitate su Istanze gestite da Amazon ECS, AWS Fargate, istanze Amazon EC2 o istanze esterne. Le attività possono essere eseguite su Istanze gestite da Amazon ECS, Fargate o infrastruttura EC2 come tipo di avvio o strategia del provider di capacità. Se usi EC2 come provider di capacità, Amazon ECS non traccia e non scala la capacità dei gruppi Amazon EC2 Auto Scaling.
+ Un cluster può contenere una combinazione di provider di capacità di Istanze gestite da Amazon ECS, provider di capacità del gruppo Auto Scaling e provider di capacità Fargate. Una strategia di fornitura di capacità può contenere solo provider di capacità di Istanze gestite da Amazon ECS, provider di capacità di gruppo Auto Scaling o provider di capacità Fargate.
+ È possibile usare differenti tipi di istanze per Istanze gestite da Amazon ECS ed EC2 o per i provider di capacità del gruppo Auto Scaling. Un'istanza può essere registrata in un solo cluster alla volta.
+ È possibile limitare l'accesso ai cluster creando policy IAM personalizzate. Per informazioni, consulta la sezione [Esempi di cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies) in [Esempi di policy basate su identità per Amazon Elastic Container Service](security_iam_id-based-policy-examples.md).
+ È possibile usare il dimensionamento automatico del servizio per scalare le attività di Fargate. Per ulteriori informazioni, consulta [Scalabilità automatica del servizio Amazon ECS](service-auto-scaling.md).
+ È possibile configurare un namespace Service Connect predefinito per un cluster. Dopo aver impostato un namespace predefinito di Service Connect, tutti i nuovi servizi con Service Connect attivato creati nel cluster saranno aggiunti come servizi client nel namespace. e non sono necessarie ulteriori configurazioni. Per ulteriori informazioni, consulta [Usa Service Connect per connettere i servizi Amazon ECS con nomi brevi](service-connect.md).

## fornitori di capacità
<a name="capacity-providers"></a>

I provider di capacità Amazon ECS gestiscono il dimensionamento dell'infrastruttura per le attività nei cluster. Ogni cluster ha uno o più fornitori di capacità e una strategia di fornitori di capacità facoltativa. È possibile assegnare una strategia predefinita per il fornitore di capacità al cluster. La strategia del fornitore di capacità determina il modo in cui le attività vengono distribuite tra i fornitori di capacità del cluster. Quando esegui un’attività autonoma o crei un servizio, puoi utilizzare la strategia del fornitore di capacità predefinita del cluster o specificare una strategia che sostituisce quella del cluster. La strategia predefinita del provider di capacità del cluster si applica solo quando non viene specificato un tipo di avvio o una strategia del provider di capacità per l'attività o il servizio. Se viene fornito uno di questi parametri, la strategia predefinita non viene usata. 

Amazon ECS offre tre tipi di provider di capacità per i cluster:

Provider di capacità di Istanze gestite da Amazon ECS  
AWS gestisce completamente le istanze Amazon EC2 sottostanti, inclusi il provisioning, l'applicazione di patch, la scalabilità e la gestione del ciclo di vita. Questo offre un equilibrio ottimale tra prestazioni, convenienza economica e semplicità operativa. I provider di capacità di Amazon ECS Managed Instances ottimizzano automaticamente la selezione e il dimensionamento delle istanze in base ai requisiti del carico di lavoro.  
Con Istanze gestite da Amazon ECS, puoi ottenere i seguenti vantaggi:  
+ Provisioning e dimensionamento automatici delle istanze
+ Gestione dell'applicazione di patch e Aggiornamenti di sicurezza
+ Ottimizzazione dei costi con la selezione intelligente delle istanze
+ Riduzione del sovraccarico operativo

Provider di capacità di Fargate  
Elaborazione serverless con cui paghi solo per le risorse usate dalle tue attività senza dover gestire alcuna infrastruttura. Basta associare i provider di capacità predefiniti (Fargate e Fargate Spot) al cluster.

Provider di capacità dei gruppi Auto Scaling  
Quando si utilizzano le istanze Amazon EC2 per la propria capacità, si utilizza il gruppo Auto Scaling per gestire le istanze Amazon EC2. Auto Scaling si assicura che tu disponga del numero corretto di istanze Amazon EC2 disponibili per gestire il carico dell'applicazione. Hai il pieno controllo dell'infrastruttura sottostante.

Un cluster può contenere una combinazione di attività ospitate su Istanze gestite da Amazon ECS, AWS Fargate, istanze Amazon EC2 o istanze esterne. Le attività possono essere eseguite su Istanze gestite da Amazon ECS, Fargate o infrastruttura EC2 come tipo di avvio o strategia del provider di capacità. Se utilizzi EC2 come tipo di avvio, Amazon ECS non traccia e non scala la capacità dei gruppi Amazon EC2 Auto Scaling. 

Un cluster può contenere una combinazione di provider di capacità di Istanze gestite da Amazon ECS, provider di capacità del gruppo Auto Scaling e provider di capacità Fargate. Una strategia di fornitura di capacità può contenere solo provider di capacità di Istanze gestite da Amazon ECS, provider di capacità di gruppo Auto Scaling o provider di capacità Fargate.

# Cluster per Istanze gestite da Amazon ECS
<a name="managed-instance-clusters"></a>

I provider di capacità Amazon ECS gestiscono il dimensionamento dell'infrastruttura per le attività nei cluster. Una volta creato il cluster, vengono creati uno o più provider di capacità e una strategia dei provider di capacità opzionale per il cluster. La strategia del fornitore di capacità determina il modo in cui le attività vengono distribuite tra i fornitori di capacità del cluster. Quando esegui un’attività autonoma o crei un servizio, puoi utilizzare la strategia del fornitore di capacità predefinita del cluster o specificare una strategia che sostituisce quella del cluster.

Istanze gestite da Amazon ECS dispone dei seguenti provider di capacità.


| Tipo | Criteri usati per scegliere le istanze | 
| --- | --- | 
| Predefinita | Le istanze più convenienti che soddisfano i seguenti requisiti relativi alla definizione delle attività e ai parametri di servizio: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/managed-instance-clusters.html) | 
| Personalizzato | Le istanze che soddisfano i requisiti di attributo e tipo specificati durante la creazione del cluster. Per ulteriori informazioni relative agli attributi, consulta [Attributi delle istanze di container di Amazon ECS](task-placement-constraints.md#attributes). Per informazioni sui tipi di istanza, consulta le [Amazon EC2 instance type specifications](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html) in Amazon EC2 Instance Types. | 

Amazon ECS avvia le istanze e le associa al provider di capacità di Istanze gestite da Amazon ECS. Per il provider di capacità personalizzato, Amazon ECS crea anche il provider di capacità.

# Creazione di un cluster per Istanze gestite da Amazon ECS
<a name="create-cluster-managed-instances"></a>

Creazione di un cluster per definire l'infrastruttura in cui eseguire le attività e i servizi. 

Quando crei un cluster per Amazon ECS Managed Instances, Amazon ECS crea automaticamente un provider di capacità per istanze gestite con configurazioni predefinite. Questo provider di capacità seleziona i tipi di istanze più convenienti per i tuoi carichi di lavoro. Se hai bisogno di attributi o tipi di istanze specifici, puoi anche creare provider di capacità personalizzati.

Per semplificare il più possibile il processo di creazione del cluster, la console dispone di selezioni predefinite per molte scelte.
+ Crea uno spazio dei nomi predefinito con AWS Cloud Map lo stesso nome del cluster. Un namespace consente ai servizi creati nel cluster di connettersi agli altri servizi nel namespace senza configurazioni aggiuntive. 

  Per ulteriori informazioni, consulta [Interconnessione dei servizi Amazon ECS](interconnecting-services.md).

È possibile modificare le seguenti opzioni:
+ Modifica il namespace predefinito associato al cluster. 

  Un namespace consente ai servizi creati nel cluster di connettersi agli altri servizi nel namespace senza configurazioni aggiuntive. Il namespace predefinito ha lo stesso nome del cluster. Per ulteriori informazioni, consulta [Interconnessione dei servizi Amazon ECS](interconnecting-services.md).
+ Assegna una AWS KMS chiave per lo storage gestito. Per informazioni su come creare una chiave, consulta [Create a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *Guida per l'utente di AWS Key Management Service *.
+ Aggiungi tag per facilitare l'identificazione del cluster.

## Prerequisiti
<a name="create-cluster-managed-instances-prerequisites"></a>

Prima di iniziare, accertati di aver completato le fasi in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md) e assegna l'autorizzazione IAM corretta. Per ulteriori informazioni, consulta [Esempi di cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies).

L'utente che crea il cluster deve possedere un'autorizzazione aggiuntiva:`iam:CreateServiceLinkedRole`.

Se non lo specifichi`instanceRequirements`, Amazon ECS seleziona automaticamente i tipi di istanza più ottimizzati in termini di costi in base ai requisiti di definizione delle attività. Per utilizzare attributi o tipi di istanza specifici, crea un provider di capacità con. `instanceRequirements`

Capisci come scegliere le tue istanze. Per ulteriori informazioni, consulta [Best practice per la selezione delle istanze per le Istanze gestite da Amazon ECS](managed-instances-instance-selection-best-practices.md).

Disponi dei ruoli IAM richiesti per Istanze gestite da Amazon ECS. Questo include:
+ **Ruolo dell'infrastruttura**: consente ad Amazon ECS di effettuare chiamate ai AWS servizi per tuo conto per gestire l'infrastruttura Amazon ECS Managed Instances.

  Per ulteriori informazioni, consulta [Ruolo IAM dell’infrastruttura Amazon ECS](infrastructure_IAM_role.md).
+ **Profilo dell'istanza**: fornisce le autorizzazioni per l'agente del container di Amazon ECS e il daemon Docker in esecuzione su istanze gestite.

  Per ulteriori informazioni, consulta [Profilo delle istanze gestite da Amazon ECS](managed-instances-instance-profile.md).

## Procedura della console
<a name="create-cluster-managed-instances-console"></a>

**Creazione di un nuovo cluster (console Amazon ECS)**

1. [Apri la console alla v2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Seleziona la Regione da utilizzare nella barra di navigazione.

1. Nel pannello di navigazione scegli **Cluster**.

1. Nella pagina **Clusters** (Cluster), scegli **Create cluster** (Crea cluster).

1. In **Configurazione del cluster**, configura gli elementi seguenti:
   + In **Nome cluster**, inserisci un nome univoco.

     Il nome può contenere fino a 255 lettere (maiuscole e minuscole), numeri e trattini.
   + (Facoltativo) Per fare in modo che il namespace utilizzato per Service Connect sia diverso dal nome del cluster, in **Namespace**, inserisci un nome univoco.

1. Per **Provider di capacità personalizzato**, procedi come segue:
   + Per **Seleziona un metodo per ottenere la capacità EC2**, scegli **Istanze gestite da Amazon ECS**.
   + Per il profilo dell'istanza, seleziona il ruolo del profilo dell'istanza.
   + Per il ruolo dell'infrastruttura, seleziona il ruolo dell'infrastruttura.
   + Per usare un provider di capacità personalizzato, per **Selezione delle istanze**, scegli **Usa personalizzato**. Quindi inserisci il **valore dell'attributo** per ogni attributo.

1. (Facoltativo) Usa Container Insights, espandi **Monitoraggio**, quindi seleziona una delle seguenti opzioni:
   + Per usare la soluzione consigliata di Container Insights con osservabilità migliorata, seleziona **Container Insights con osservabilità migliorata**.
   + Per utilizzare Container Insights scegli **Container Insights**.

1. (Facoltativo) Crittografa i dati sullo storage gestito. In **Crittografia**, per **Storage gestito**, inserisci l'ARN della AWS KMS chiave che desideri utilizzare per crittografare i dati di storage gestito.

1. (Facoltativo) Per identificare il tuo cluster, espandi la sezione **Tags** (Tag), quindi configura i tag.

   [Aggiungere un tag] Scegliere **Add tag (Aggiungi tag)** e procedere come segue:
   + In **Chiave**, immetti il nome della chiave.
   + In **Valore**, immetti il valore della chiave.

1. Scegli **Create** (Crea).

## AWS CLI procedura
<a name="create-cluster-managed-instances-cli"></a>

Puoi creare un cluster per Istanze gestite da Amazon ECS utilizzando la AWS CLI. Usa la versione più recente dell' AWS CLI. Per ulteriori informazioni su come eseguire l'aggiornamento alla versione più recente, consulta [Installing or updating to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**Nota**  
Puoi utilizzare gli endpoint del servizio dual-stack per interagire con Amazon ECS da AWS AWS CLI, SDKs e l'API Amazon ECS su entrambi e. IPv4 IPv6 Per ulteriori informazioni, consulta [Utilizzo degli endpoint dual-stack Amazon ECS](dual-stack-endpoint.md).

**Come creare un nuovo cluster (AWS CLI)**

1. Crea il tuo cluster con un nome univoco usando il comando seguente:

   ```
   aws ecs create-cluster --cluster-name managed-instances-cluster
   ```

   Output:

   ```
   {
       "cluster": {
           "status": "ACTIVE", 
           "defaultCapacityProviderStrategy": [], 
           "statistics": [], 
           "capacityProviders": [], 
           "tags": [], 
           "clusterName": "managed-instances-cluster", 
           "settings": [
               {
                   "name": "containerInsights", 
                   "value": "disabled"
               }
           ], 
           "registeredContainerInstancesCount": 0, 
           "pendingTasksCount": 0, 
           "runningTasksCount": 0, 
           "activeServicesCount": 0, 
           "clusterArn": "arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster"
       }
   }
   ```

1. (Facoltativo) Per abilitare Container Insights con una osservabilità migliorata per il tuo cluster, usa il seguente comando:

   ```
   aws ecs put-account-setting --name containerInsights --value enhanced
   ```

1. (Facoltativo) Per aggiungere tag al cluster, usa il seguente comando:

   ```
   aws ecs tag-resource --resource-arn arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster --tags key=Environment,value=Production
   ```

## Fasi successive
<a name="cluster-next-steps-managed-instances"></a>

Crea una definizione dell'attività per Istanze gestite da Amazon ECS. Per ulteriori informazioni, consulta [Creazione di una definizione di attività di Amazon ECS attraverso la nuova console](create-task-definition.md).

Esegui le applicazioni come attività autonome o come parte di un servizio. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Esecuzione di un'applicazione come attività Amazon ECS](standalone-task-create.md)
+ [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md)

# Aggiornare un cluster per usare Istanze gestite da Amazon ECS
<a name="update-cluster-managed-instances"></a>

Puoi aggiornare un cluster esistente per usare Istanze gestite da Amazon ECS.

Quando aggiungi Amazon ECS Managed Instances al tuo cluster, Amazon ECS crea automaticamente un provider di capacità per istanze gestite con configurazioni predefinite. Questo fornitore di capacità seleziona i tipi di istanze generiche più ottimizzati in termini di costi per i tuoi carichi di lavoro. Se hai bisogno di attributi o tipi di istanze specifici, puoi anche creare provider di capacità personalizzati.

## Prerequisiti
<a name="update-cluster-managed-instances-prerequisites"></a>

Se non lo specifichi`instanceRequirements`, Amazon ECS seleziona automaticamente i tipi di istanza più ottimizzati in termini di costi in base ai requisiti di definizione delle attività. Per utilizzare attributi o tipi di istanza specifici, crea un provider di capacità con. `instanceRequirements`

Disponi dei ruoli IAM richiesti per Istanze gestite da Amazon ECS. Questo include:
+ **Ruolo dell'infrastruttura**: consente ad Amazon ECS di effettuare chiamate ai AWS servizi per tuo conto per gestire l'infrastruttura Amazon ECS Managed Instances.

  Per ulteriori informazioni, consulta [Ruolo IAM dell’infrastruttura Amazon ECS](infrastructure_IAM_role.md).
+ **Profilo dell'istanza**: fornisce le autorizzazioni per l'agente del container di Amazon ECS e il daemon Docker in esecuzione su istanze gestite.

  Per ulteriori informazioni, consulta [Profilo delle istanze gestite da Amazon ECS](managed-instances-instance-profile.md).

## Considerazioni sugli aggiornamenti
<a name="cluster-update-considerations-managed-instances"></a>

Durante l'aggiornamento di un cluster per Istanze gestite da Amazon ECS, tieni presente quanto segue:
+ Attività in esecuzione: l'aggiornamento delle impostazioni del cluster non influisce sulle attività attualmente in esecuzione. Le modifiche saranno applicate alle nuove attività avviate dopo l'aggiornamento.
+ Modifiche al provider di capacità: se modifichi le impostazioni del provider di capacità, le istanze gestite esistenti continueranno a funzionare, ma le nuove istanze useranno la configurazione aggiornata.
+ Monitoraggio delle modifiche: l'attivazione o la disattivazione di Container Insights influirà sulla raccolta delle metriche per l'intero cluster.

## Procedura della console
<a name="update-cluster-managed-instances-console"></a>

**Per aggiornare un cluster (console Amazon ECS)**

1. [Apri la console alla v2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Seleziona la Regione da utilizzare nella barra di navigazione.

1. Nel pannello di navigazione scegli **Cluster**.

1. Nella pagina **Cluster**, seleziona il cluster che desideri aggiornare.

1. Seleziona **Aggiorna cluster**.

1. (Facoltativo) Per modificare le impostazioni del provider di capacità, in **Provider di capacità personalizzato**, aggiorna quanto segue in base alle esigenze:
   + Per **Profilo dell'istanza**, scegli un ruolo diverso nel profilo dell'istanza, se necessario.
   + Per **ruolo dell'infrastruttura**, scegli un ruolo dell'infrastruttura diverso, se necessario.
   + Per usare un provider di capacità personalizzato, per **Selezione delle istanze**, aggiorna le impostazioni del **Valore dell'attributo**.

1. Scegliere **Aggiorna**.

## AWS CLI procedura
<a name="update-cluster-managed-instances-cli"></a>

Puoi aggiornare un cluster per Istanze gestite da Amazon ECS utilizzando la AWS CLI. Usa la versione più recente dell' AWS CLI. Per ulteriori informazioni su come eseguire l'aggiornamento alla versione più recente, consulta [Installing or updating to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**Nota**  
Puoi utilizzare gli endpoint del servizio dual-stack per interagire con Amazon ECS da AWS AWS CLI, SDKs e l'API Amazon ECS su entrambi e. IPv4 IPv6 Per ulteriori informazioni, consulta [Utilizzo degli endpoint dual-stack Amazon ECS](dual-stack-endpoint.md).

**Come aggiornare un cluster (AWS CLI)**

1. Creazione di un provider di capacità per . Esegui il comando seguente:

   Sostituiscili con i tuoi valori. *user-input*

   ```
   aws ecs create-capacity-provider \
       --name my-managed-instances-provider \
       --managed-instances-provider \
       --instance-profile arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile \
       --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRole \
       --instance-requirements '{
           "vCpuCount": {"min": 2, "max": 8},
           "memoryMiB": {"min": 4096, "max": 16384}
       }
   ```

1. Aggiungi il provider di capacità al cluster. Usa il seguente comando:

   *user-input*Sostituiscili con i tuoi valori.

   ```
   aws ecs put-cluster-capacity-providers --cluster managed-instances-cluster --capacity-providers my-managed-instances-provider --default-capacity-provider-strategy capacityProvider=my-managed-instances-provider,weight=1
   ```

# Provider di capacità di Istanze gestite da Amazon ECS
<a name="managed-instances-capacity-providers-concept"></a>

I provider di capacità di Amazon ECS Managed Instances forniscono un modello di calcolo containerizzato che consente di accedere all'intera gamma di AWS funzionalità e alle offerte di Amazon EC2, gestendo al contempo AWS le responsabilità operative e di sicurezza. AWS gestisce le patch del software e del sistema operativo, il ridimensionamento delle istanze e la manutenzione, offrendoti i vantaggi operativi di Fargate pur mantenendo l'accesso a tutte le AWS funzionalità e le integrazioni.

Amazon ECS crea modelli di avvio per le Istanze gestite da Amazon ECS. Questo definisce il modo in cui Amazon ECS avvia le istanze gestite da Amazon ECS, compreso il profilo dell'istanza per le attività, la configurazione di rete e storage, le opzioni di capacità e i requisiti dell'istanza per una selezione flessibile del tipo di istanza.

## Quando usare provider di capacità personalizzati
<a name="when-to-use-managed-instances"></a>

Prendi in considerazione i provider di capacità personalizzati quando i carichi di lavoro richiedono:
+ Requisiti di elaborazione specifici: applicazioni che richiedono elaborazione accelerata, set di istruzioni CPU specifici, prestazioni di rete elevate o configurazioni di memoria di grandi dimensioni che non sono disponibili con le opzioni Fargate standard.
+ Carichi di lavoro GPU: inferenza di machine learning, rendering di immagini in tempo reale, codifica video o altre applicazioni accelerate da GPU che richiedono l'accesso a NVIDIA o AMD. GPUs
+ Prenotazioni di capacità: carichi di lavoro mission critical che richiedono una disponibilità prevedibile della capacità.
+ Osservabilità avanzata: strumenti di sicurezza e monitoraggio che richiedono un accesso privilegiato al sistema operativo sottostante, come soluzioni di monitoraggio basate su EBPF o strumenti di analisi della rete.
+ Ottimizzazione dei costi: carichi di lavoro che possono trarre vantaggio dal posizionamento in più attività, dai componenti dell'infrastruttura condivisi o che devono massimizzare l'utilizzo di tipi di istanze più grandi.

## Opzioni di monitoraggio
<a name="monitoring-options-managed-instances"></a>

Le istanze gestite da Amazon ECS offrono funzionalità di monitoraggio complete che consentono di tenere traccia delle prestazioni, dello stato di integrità e dell'utilizzo delle risorse dei carichi di lavoro containerizzati. Puoi scegliere tra diversi livelli di monitoraggio in base alle tue esigenze operative.
+ **Monitoraggio di base**: fornisce metriche essenziali a intervalli di 5 minuti per la maggior parte delle metriche e a intervalli di 1 minuto per i controlli dello stato. Questa funzionalità è abilitata per impostazione predefinita e non comporta costi aggiuntivi.
+ **Monitoraggio dettagliato**: offre una maggiore visibilità con tutte le metriche disponibili a intervalli di 1 minuto, permettendo un rilevamento e una risposta più rapidi ai problemi operativi. Per ulteriori informazioni, consulta [Monitoraggio dettagliato delle istanze gestite da Amazon ECS](monitoring-managed-instances.md#detailed-monitoring-managed-instances).

Entrambe le opzioni di monitoraggio si integrano perfettamente CloudWatch per fornire dashboard, allarmi e risposte automatiche per aiutare a mantenere prestazioni e disponibilità ottimali delle applicazioni.

## Considerazioni sul provider di capacità
<a name="capacity-provider-considerations-managed-instances"></a>

Un cluster può contenere una combinazione di provider di capacità di Istanze gestite da Amazon ECS, provider di capacità del gruppo Auto Scaling e provider di capacità Fargate. Una strategia di fornitura di capacità può contenere solo provider di capacità di Istanze gestite da Amazon ECS, provider di capacità di gruppo Auto Scaling o provider di capacità Fargate.

## Propagazione di tag
<a name="tag-propagation-managed-instances"></a>

I provider di capacità per le istanze gestite da Amazon ECS supportano la propagazione dei tag. Con la propagazione dei tag, tutte le risorse gestite dal provider di capacità (istanza gestita, istanza di container Amazon ECS, modello di avvio, volumi, interfacce di rete elastiche) sono contrassegnate con gli stessi tag specificati a livello del provider di capacità. Puoi specificare i tag durante la creazione del provider di capacità e abilitare la propagazione dei tag specificando il parametro `propagateTags` come `CAPACITY_PROVIDER`.

Per ulteriori informazioni sull'aggiunta di tag nelle Istanze gestite da Amazon ECS, consulta [Tag per le istanze gestite da Amazon ECS](instance-details-tags-managed-instances.md).

# Best practice per l'aggiornamento dei provider di capacità per le istanze gestite da Amazon ECS
<a name="capacity-provider-managed-instances-best-practices"></a>

Per garantire il massimo livello di sicurezza e supporto al rollback, consigliamo di trattare i provider di capacità come risorse non modificabili. Per aggiornare la configurazione di un provider di capacità, segui il seguente flusso di lavoro consigliato:

1. **Crea un nuovo provider di capacità** con la configurazione aggiornata invece di modificare quello esistente.

1. **Aggiorna ogni servizio** per usare il nuovo provider di capacità e consenti il completamento delle implementazioni.

1. **Elimina il precedente provider di capacità** dopo aver verificato che la nuova configurazione funzioni come previsto.

Questo approccio offre diversi vantaggi:
+ **Rollout controllato**: puoi aggiornare i servizi uno alla volta e monitorarne l'impatto.
+ **Rollback semplificato**: in caso di problemi, è possibile ripristinare rapidamente i servizi in modo che usino il provider di capacità precedente.
+ **Raggio d'azione ridotto**: i problemi con la nuova configurazione non influiscono immediatamente su tutti i carichi di lavoro.

**Nota**  
Se lo utilizzi CloudFormation, valuta la possibilità di mantenere il vecchio provider di capacità fino a una distribuzione successiva per preservare la possibilità di ripristinare le modifiche apportate allo stack.

Sebbene sia possibile aggiornare i provider di capacità in locale, questo approccio crea un raggio d'azione incontrollato più ampio. Gli aggiornamenti in locale applicano le nuove impostazioni a tutta la nuova capacità fornita in futuro, ma non attivano l'implementazione dei servizi. Questo significa che potresti scoprire i problemi di configurazione solo molto più tardi, quando i tuoi servizi dovranno essere scalati.

# Creazione di un provider di capacità per le istanze gestite da Amazon ECS
<a name="create-capacity-provider-managed-instances"></a>

Istanze gestite da Amazon ECS usa provider di capacità per gestire la capacità di calcolo dei carichi di lavoro. Quando crei un provider di capacità senza specificare`instanceRequirements`, Amazon ECS seleziona automaticamente i tipi di istanze generiche più ottimizzati in termini di costi. Puoi creare fornitori di capacità con `instanceRequirements` cui specificare gli attributi delle istanze, come i tipi di istanza, i produttori di CPU, i tipi di acceleratori e altri requisiti.

I provider di capacità personalizzati usano la selezione del tipo di istanza basata sugli attributi, che consente di esprimere i requisiti dell'istanza come un set di attributi. Questi requisiti vengono automaticamente tradotti in tutti i tipi di istanza Amazon EC2 corrispondenti, semplificando la creazione e la manutenzione delle configurazioni dei tipi di istanza. Per ulteriori informazioni sui requisiti delle istanze e sulla selezione basata sugli attributi, consulta la documentazione relativa alla [selezione del tipo di istanza basata sugli attributi di Amazon EC2 Fleet](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) nella *Guida per l'utente di Amazon EC2*.

## Prerequisiti
<a name="create-capacity-provider-managed-instances-prerequisites"></a>

Prima di iniziare, assicurati di aver completato quanto segue:
+ Determina il tipo di monitoraggio da usare. Per ulteriori informazioni, consulta [Monitoraggio dettagliato delle istanze gestite da Amazon ECS](monitoring-managed-instances.md#detailed-monitoring-managed-instances).
+ Disponi di un cluster esistente o pianifica di crearne uno. Per ulteriori informazioni, consulta [Creazione di un cluster per Istanze gestite da Amazon ECS](create-cluster-managed-instances.md).
+ Disponi dei ruoli IAM richiesti per Istanze gestite da Amazon ECS. Questo include:
  + **Ruolo dell'infrastruttura**: consente ad Amazon ECS di effettuare chiamate ai AWS servizi per tuo conto per gestire l'infrastruttura Amazon ECS Managed Instances.

    Per ulteriori informazioni, consulta [Ruolo IAM dell’infrastruttura Amazon ECS](infrastructure_IAM_role.md).
  + **Profilo dell'istanza**: fornisce le autorizzazioni per l'agente del container di Amazon ECS e il daemon Docker in esecuzione su istanze gestite.

    Per ulteriori informazioni, consulta [Profilo delle istanze gestite da Amazon ECS](managed-instances-instance-profile.md).

Capisci come scegliere le tue istanze. Per ulteriori informazioni, consulta [Best practice per la selezione delle istanze per le Istanze gestite da Amazon ECS](managed-instances-instance-selection-best-practices.md).

## Procedura della console
<a name="create-capacity-provider-managed-instances-console"></a>

**Per creare un provider di capacità per le istanze gestite da Amazon ECS (console Amazon ECS)**

1. [Apri la console alla v2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Seleziona la Regione da utilizzare nella barra di navigazione.

1. Nel pannello di navigazione scegli **Cluster**.

1. Nella pagina **Cluster**, seleziona il nome del tuo cluster.

1. Nella pagina Cluster, scegli la scheda **Infrastruttura**.

1. Nella sezione **Provider di capacità**, seleziona **Crea provider di capacità**.

1. In **Configurazione del provider di capacità**, configura i seguenti elementi:
   + In **Nome del provider di capacità**, inserisci un nome univoco per il tuo provider di capacità.
   + Per il **Tipo di provider di capacità**, seleziona **Istanze gestite da Amazon ECS**.

1. In **Configurazione istanze**, configura gli elementi seguenti:
   + Per **Profilo dell'istanza**, seleziona il ruolo del profilo dell'istanza creato per le istanze gestite da Amazon ECS.
   + In **Ruolo dell'infrastruttura**, scegli il ruolo dell'infrastruttura creato per le istanze gestite da Amazon ECS.

1. In **Requisiti dell'istanza**, specifica gli attributi per le istanze. Puoi configurare qualsiasi combinazione dei seguenti elementi:
   + **Numero vCPU**: specifica il numero di v CPUs (ad esempio, `4` o `8-16` per un intervallo).
   + **Memoria (MiB)**: specifica la quantità di memoria in MiB (ad esempio, `8192` o `16384-32768` per un intervallo).
   + **Tipi di istanza**: specifica tipi di istanza specifici (ad esempio, `m5.large,m5.xlarge,c5.large`).
   + **Produttori di CPU**: scegli tra `intel`, `amd` o `amazon-web-services`.
   + **Tipi di acceleratori**: specifica i tipi di acceleratori come `gpu`, `fpga` o `inference`.
   + **Numero di acceleratori**: specifica il numero di acceleratori (ad esempio, `1` o `2-4` per un intervallo).

1. In **Configurazione avanzata**, scegli una delle seguenti opzioni di monitoraggio:
   + **Per impostare le metriche di controllo dello stato dell' CloudWatch invio, scegli Basic.**
   + **Per CloudWatch inviare tutte le metriche delle metriche, scegli Dettagliato.**

1. (Facoltativo) Per identificare il tuo provider di capacità, espandi la sezione **Tag**, quindi configura i tag.

   Per abilitare la propagazione dei tag dal provider di capacità alle risorse gestite, come le istanze avviate dal provider di capacità, seleziona **Provider di capacità** in **Propaga tag da**.

   [Aggiungere un tag] Scegliere **Add tag (Aggiungi tag)** e procedere come segue:
   + In **Chiave**, immetti il nome della chiave.
   + In **Valore**, immetti il valore della chiave.

1. Scegli **Create** (Crea).

## AWS CLI procedura
<a name="create-capacity-provider-managed-instances-cli"></a>

È possibile creare un provider di capacità per le istanze gestite da Amazon ECS usando AWS CLI. Usa la versione più recente dell' AWS CLI. Per ulteriori informazioni su come eseguire l'aggiornamento alla versione più recente, consulta [Installing or updating to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**Per creare un provider di capacità per le istanze gestite da Amazon ECS (AWS CLI)**

1. Esegui il comando seguente:

   ```
   aws ecs create-capacity-provider --cli-input-json file://capacity-provider-definition.json
   ```

   Il seguente file `capacity-provider-definition.json` può essere utilizzato per specificare i requisiti di base dell'istanza, la dimensione di archiviazione dell'istanza e abilitare la propagazione dei tag:

   ```
   {
       "name": "my-managed-instances-provider",
       "cluster": "my-cluster",
       "tags": [ 
           { 
               "key": "version",
               "value": "test"
           }
       ],    
       "managedInstancesProvider": {
           "infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole",
           "instanceLaunchTemplate": {
               "ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
               "instanceRequirements": {
                   "vCpuCount": {
                       "min": 4,
                       "max": 8
                   },
                   "memoryMiB": {
                       "min": 8192,
                       "max": 16384
                   }
               },
               "networkConfiguration": {
                   "subnets": [
                       "subnet-abcdef01234567",
                       "subnet-bcdefa98765432"
                   ],
                   "securityGroups": [
                       "sg-0123456789abcdef"
                   ]
               },
               "storageConfiguration": {
                   "storageSizeGiB": 100
               },
               "monitoring": "basic"
           },
           "propagateTags": "CAPACITY_PROVIDER"
       }
   }
   ```

1. Verifica che il tuo provider di capacità sia stato creato in modo corretto:

   ```
   aws ecs describe-capacity-providers \
       --capacity-providers my-managed-instances-provider
   ```

## Fasi successive
<a name="capacity-provider-managed-instances-next-steps"></a>

Dopo aver creato il tuo provider di capacità, puoi usarlo durante la creazione di servizi o l'esecuzione di attività:
+ Per usare il provider di capacità con un servizio, consulta [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md).
+ Per usare il provider di capacità con attività autonome, consulta [Esecuzione di un'applicazione come attività Amazon ECS](standalone-task-create.md).

# Aggiornamento del monitoraggio delle istanze gestite da Amazon ECS
<a name="update-capacity-provider-managed-instances"></a>

Puoi modificare l'opzione di monitoraggio per il provider di capacità delle istanze gestite da Amazon ECS per passare dal monitoraggio di base a quello dettagliato. Ciò permette di regolare il livello dei dati di monitoraggio raccolti senza ricreare il provider di capacità.

Per ulteriori informazioni sulle opzioni di monitoraggio, consulta [Monitoraggio delle istanze gestite di Amazon ECS.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-managed-instances.html)

## Procedura della console
<a name="update-capacity-provider-managed-instances-console"></a>

**Per aggiornare il monitoraggio per Istanze gestite da Amazon ECS (console Amazon ECS)**

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Seleziona la Regione da utilizzare nella barra di navigazione.

1. Nel pannello di navigazione scegli **Cluster**.

1. Nella pagina **Cluster**, seleziona il nome del tuo cluster.

1. Nella pagina Cluster, scegli la scheda **Infrastruttura**.

1. In **Configurazione avanzata**, scegli una delle seguenti opzioni di monitoraggio:
   + **Per impostare le metriche di controllo dello stato dell' CloudWatch invio, scegli Basic.**
   + **Per CloudWatch inviare tutte le metriche delle metriche, scegli Dettagliato.**

1. Scegliere **Aggiorna**.

Per aggiornare i tag associati a un provider di capacità Istanze gestite da Amazon ECS esistente, procedi come segue:

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina Cluster, seleziona **Infrastruttura**.

1. Nella pagina Infrastruttura, seleziona il provider di capacità che hai creato.

1. Nella pagina del provider di capacità, seleziona **Tag**.

1. In **Tag**, scegli **Gestisci tag**.

1. Per aggiungere un tag, specifica la chiave e il valore del tag da aggiungere e scegli **Salva**. Per aggiungere più tag contemporaneamente, scegli **Aggiungi nuovo tag** per ogni tag da aggiungere. È possibile aggiungere un massimo di 50 tag.

   Per rimuovere un tag, scegli **Remove** (Rimuovi).
**Nota**  
Se la propagazione dei tag è abilitata, i tag aggiunti o rimossi dopo la creazione del provider di capacità non si applicano alle risorse create in precedenza dal provider di capacità.

## AWS CLI procedura
<a name="update-capacity-provider-managed-instances-cli"></a>

È possibile aggiornare un provider di capacità per le istanze gestite da Amazon ECS usando AWS CLI. Usa la versione più recente dell' AWS CLI. Per ulteriori informazioni su come eseguire l'aggiornamento alla versione più recente, consulta [Installing or updating to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**Per aggiornare il monitoraggio per Istanze gestite da Amazon ECS (AWS CLI)**

1. Per abilitare il monitoraggio dettagliato, usa il seguente comando:

   ```
   aws ecs update-capacity-provider \
       --name my-managed-instances-provider \
       --managed-instances-provider '{
           "instanceLaunchTemplateUpdate": {
               "monitoring": "DETAILED"
           }
       }'
   ```

1. Per abilitare il monitoraggio di base, usa il seguente comando:

   ```
   aws ecs update-capacity-provider \
       --name my-managed-instances-provider \
       --managed-instances-provider '{
           "instanceLaunchTemplateUpdate": {
               "monitoring": "BASIC"
           }
       }'
   ```

# Eliminazione di un provider di capacità di Istanze gestite da Amazon ECS
<a name="delete-capacity-provider-managed-instances-console-v2"></a>

Se hai finito di utilizzare un provider di capacità Amazon ECS Istanze gestite da Amazon ECS, puoi eliminarlo. Dopo l'eliminazione del gruppo, il provider di capacità di Istanze gestite da Amazon ECS passa allo stato `INACTIVE`. I provider di capacità con stato `INACTIVE` potrebbero rimanere rilevabili nell'account per un periodo di tempo. Tuttavia, questo comportamento è soggetto a modifiche in futuro, quindi non dovresti fare affidamento sulla persistenza dei provider di capacità `INACTIVE`. Prima di eliminare il provider di capacità Amazon ECS Istanze gestite da Amazon ECS, è necessario rimuoverlo dalla strategia del provider di capacità per tutti i servizi. L'API `UpdateService` o il flusso di lavoro del servizio di aggiornamento nella console Amazon ECS possono essere utilizzati per rimuovere un provider di capacità dalla strategia del provider di capacità di un servizio. L'opzione **Forza nuova implementazione** può essere utilizzata per garantire che tutte le attività che utilizzano la capacità delle istanze gestite da Amazon ECS fornita dal provider di capacità vengano autorizzate a utilizzare la capacità dei provider di capacità rimanenti.

**Per eliminare un provider di capacità per il cluster (console Amazon ECS)**

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster.

1. **Nella *name* pagina **Cluster:**, scegli **Infrastruttura**, il provider di capacità Amazon ECS Managed Instances, quindi scegli Elimina.**

1. **Nella casella di conferma, inserisci delete *Amazon ECS Managed Instances capacity provider name***

1. Scegli **Elimina**.

# Interrompi in modo sicuro i carichi di lavoro Amazon ECS in esecuzione su Istanze gestite da Amazon ECS
<a name="managed-instance-task-scale-in-protect"></a>

La protezione scalabile di Amazon ECS consente di proteggere le attività dall'interruzione da parte di eventi di riduzione orizzontale derivanti da dimensionamento del servizio o implementazioni varie.

Alcune applicazioni richiedono un meccanismo per salvaguardare le attività strategiche dall'interruzione dovuta a eventi scalabili nei periodi di scarso utilizzo o durante le implementazioni dei servizi. Esempio:
+ Si tratta di un'applicazione asincrona di elaborazione delle code, ad esempio un processo di transcodifica video in cui alcune attività devono essere eseguite per ore anche quando l'utilizzo cumulativo del servizio è basso.
+ Hai un'applicazione di gioco che esegue i server di gioco come attività che devono continuare a funzionare anche se tutti gli utenti si sono disconnessi per ridurre la latenza di avvio di un riavvio del server.
+ Quando si implementa una nuova versione del codice, è necessario che le attività continuino a essere eseguite perché sarebbe costoso rielaborarle.

Per evitare che le attività appartenenti al servizio vengano terminate in caso di un evento di dimensionamento, imposta l'attributo `ProtectionEnabled` su `true`. Quando si imposta `ProtectionEnabled` su true, le attività vengono protette per 2 ore per impostazione predefinita. Poi è possibile personalizzare il periodo di protezione utilizzando l'attributo `ExpiresInMinutes`. Puoi proteggere le tue attività per un minimo di 1 minuto e fino a un massimo di 2.880 minuti (48 ore). Se utilizzi il AWS CLI, puoi specificare l'`--protection-enabled`opzione.

Dopo che un'attività ha terminato il lavoro richiesto, sarà possibile impostare l'attributo `ProtectionEnabled` su `false`, in modo che l'attività venga terminata da successivi eventi di scalabilità. Se si utilizza il AWS CLI, è possibile specificare l'`--no-protection-enabled`opzione.

## Meccanismi di protezione scalabile delle attività
<a name="managed-instance-task-scale-in-protection-mechanisms"></a>

Puoi impostare e ottenere una protezione scalabile delle attività utilizzando l'endpoint dell'agente container Amazon ECS o l'API Amazon ECS.
+ **Endpoint dell'agente del container Amazon ECS**

  Consigliamo di utilizzare l'endpoint dell'agente container Amazon ECS per attività che possono determinare autonomamente la necessità di essere protette. Utilizza questo approccio per carichi di lavoro basati su code o di elaborazione dei processi

  Quando un container inizia il lavoro di elaborazione, ad esempio consumando un messaggio SQS, è possibile impostare l'attributo `ProtectionEnabled` tramite il percorso dell'endpoint di protezione scalabile dell'attività `$ECS_AGENT_URI/task-protection/v1/state` dall'interno del container. Amazon ECS non terminerà questa attività durante gli eventi di scalabilità. Al termine dell'attività, è possibile annullare l'attributo `ProtectionEnabled` utilizzando lo stesso endpoint, rendendo l'attività idonea all'interruzione durante i successivi eventi di scalabilità.

  Per ulteriori informazioni sull'endpoint dell'agente del container Amazon ECS, consultare [Endpoint di protezione scalabile di Amazon ECS](managed-instance-task-scale-in-protection-endpoint.md).
+ **API Amazon ECS**

  È possibile utilizzare l'API Amazon ECS per impostare e recuperare la protezione scalabile delle attività se l'applicazione dispone di un componente che tiene traccia dello stato delle attività attive. Utilizzare `UpdateTaskProtection` per contrassegnare una o più attività come protette. Utilizzare `GetTaskProtection` per recuperare lo stato di protezione.

  Un esempio di questo approccio potrebbe essere se l'applicazione ospita sessioni del server di gioco come attività Amazon ECS. Quando un utente accede a una sessione sul server (attività), è possibile contrassegnare l'attività come protetta. Dopo la disconnessione dell'utente, puoi annullare la protezione specifica per l'attività o annullare periodicamente la protezione per attività simili che non hanno più sessioni attive, a seconda se è necessario mantenere i server inattivi.

  Per ulteriori informazioni, consulta [UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html)e consulta il *riferimento [GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html)all'API di Amazon Elastic Container Service*.

È possibile combinare entrambi gli approcci. Ad esempio, utilizza l'endpoint dell'agente Amazon ECS per impostare la protezione delle attività dall'interno di un container e utilizza l'API Amazon ECS per rimuovere la protezione delle attività dal servizio di controller esterno.

## Considerazioni
<a name="managed-instance-task-scale-in-protection-considerations"></a>

Considera i seguenti punti prima di utilizzare la protezione scalabile delle attività:
+ La protezione scalabile è supportata solo con le attività implementate da un servizio.
+ La protezione scalabile è supportata con attività implementate da un servizio in esecuzione su istanze gestite da Amazon ECS.
+ Ti consigliamo di utilizzare l'endpoint dell'agente del container Amazon ECS, in quanto l'agente Amazon ECS dispone di meccanismi di ripetizione integrati e di un'interfaccia più semplice.
+ Puoi reimpostare il periodo di scadenza della protezione per il dimensionamento delle attività richiamando `UpdateTaskProtection` su un'attività che ha già la protezione attivata.
+ Determina il tempo necessario a un'attività per completare il lavoro richiesto e imposta la proprietà `expiresInMinutes` di conseguenza. Se imposti la scadenza della protezione più a lungo del necessario, dovrai sostenere costi e ritardi nell'implementazione di nuove attività.
+ Considerazioni sull'implementazione:
  + Se il servizio utilizza un aggiornamento in sequenza, verranno create nuove attività ma le attività che eseguono una versione precedente non verranno interrotte fino a quando `protectionEnabled` non viene annullato o scade. È possibile regolare il parametro `maximumPercentage` nella configurazione di implementazione su un valore che consenta di creare nuove attività quando le vecchie attività sono protette.
  + Se lo utilizzi CloudFormation, lo update-stack ha un timeout di 3 ore. Pertanto, se imposti la protezione delle attività per più di 3 ore, la CloudFormation distribuzione potrebbe causare errori e ripristini.

    Durante il periodo in cui le vecchie attività sono protette, lo CloudFormation stack viene visualizzato. `UPDATE_IN_PROGRESS` Se la protezione per il dimensionamento delle attività viene rimossa o scade entro la finestra di 3 ore, l'implementazione avrà esito positivo e passerà allo stato `UPDATE_COMPLETE`. Se l'implementazione rimane bloccata in `UPDATE_IN_PROGRESS` per più di 3 ore, non riuscirà e mostrerà lo stato `UPDATE_FAILED`, quindi verrà ripristinato il vecchio set di attività.
  + Amazon ECS invia gli eventi di servizio se le attività protette impediscono a un'implementazione (in sequenza o blu/verde) di raggiungere lo stato stazionario, in modo che sia possibile intraprendere azioni correttive. Durante il tentativo di aggiornare lo stato di protezione di un'attività, se viene ricevuto un messaggio di errore `DEPLOYMENT_BLOCKED`, allora significa che il servizio ha più attività protette rispetto al numero di attività desiderato per il servizio. Per risolvere questo errore, effettuare una delle seguenti operazioni:
    + Attendi la scadenza della protezione dell'attività corrente. Quindi imposta la protezione delle attività.
    + Determina quali attività possono essere arrestate. Quindi, usa `UpdateTaskProtection` con l'opzione `protectionEnabled` impostata su `false` per queste attività.
    + Aumenta il numero di attività desiderate del servizio portandolo a un numero maggiore del numero di attività protette.

## Autorizzazioni IAM richieste per la protezione scalabile delle attività
<a name="managed-instance-task-scale-in-protection-iam"></a>

L'attività deve avere il ruolo di attività Amazon ECS con le seguenti autorizzazioni:
+ `ecs:GetTaskProtection`: consente all'agente del container Amazon ECS di effettuare chiamate `GetTaskProtection`.
+ `ecs:UpdateTaskProtection`: consente all'agente del container Amazon ECS di effettuare chiamate `UpdateTaskProtection`.

# Endpoint di protezione scalabile di Amazon ECS
<a name="managed-instance-task-scale-in-protection-endpoint"></a>

L'agente del container Amazon ECS inserisce automaticamente la variabile di ambiente `ECS_AGENT_URI` nei container delle attività di Amazon ECS per fornire un metodo per interagire con l'endpoint API dell'agente del container.

Consigliamo di utilizzare l'endpoint dell'agente container Amazon ECS per attività che possono determinare autonomamente la necessità di essere protette. 

Quando un container inizia il lavoro di elaborazione, è possibile impostare l'attributo `protectionEnabled` tramite il percorso dell'endpoint di protezione scalabile dell'attività `$ECS_AGENT_URI/task-protection/v1/state` dall'interno del container. 

Usare una richiesta PUT in questo URI dall'interno di un container per impostare la protezione scalabile. Una richiesta GET a questo URI restituisce lo stato di protezione attuale di un'attività.

## Parametri di richiesta di protezione scalabile
<a name="managed-instance-task-scale-in-protection-request"></a>

È possibile impostare la protezione scalabile delle attività utilizzando l'endpoint `${ECS_AGENT_URI}/task-protection/v1/state` con i seguenti parametri di richiesta.

`ProtectionEnabled`  
Specificare `true` per contrassegnare un'attività per la protezione. Specificare `false` per rimuovere la protezione e rendere l'attività idonea per l'interruzione.  
Tipo: Booleano  
Obbligatorio: sì

`ExpiresInMinutes`  
Il numero di minuti in cui l'attività è protetta. È possibile specificare da un minimo di 1 minuto a un massimo di 2.880 minuti (48 ore). Durante questo periodo di tempo, l'attività non verrà terminata da eventi di dimensionamento derivanti dal servizio Dimensionamento automatico o dalle implementazioni. Trascorso questo periodo di tempo, il parametro `protectionEnabled` viene impostato su `false`.  
Se non si specifica l'ora, l'attività viene protetta automaticamente per 120 minuti (2 ore).  
Tipo: Integer  
Obbligatorio: no

Gli esempi seguenti mostrano come impostare la protezione delle attività con durate diverse.

**Esempio di come proteggere un'attività con il periodo di tempo predefinito**

Questo esempio mostra come proteggere un'attività con il periodo di tempo predefinito di 2 ore.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}'
```

**Esempio di protezione di un'attività per 60 minuti**

Questo esempio mostra come proteggere un'attività per 60 minuti utilizzando il parametro `expiresInMinutes`.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}'      
```

**Esempio di protezione di un'attività per 24 ore**

Questo esempio mostra come proteggere un'attività per 24 ore utilizzando il parametro `expiresInMinutes`.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}'      
```

La richiesta PUT restituisce la risposta seguente:

```
{
  "protection": {
    "ExpirationDate": "2023-12-20T21:57:44.837Z",
    "ProtectionEnabled": true,
    "TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
  }
}
```

## Parametri di risposta della protezione scalabile
<a name="managed-instance-task-scale-in-protection-response"></a>

La risposta in formato JSON dell'endpoint di protezione per il dimensionamento delle attività `${ECS_AGENT_URI}/task-protection/v1/state` restituisce le seguenti informazioni.

`ExpirationDate`  
L'ora in cui scadrà la protezione per l'attività. Se l'attività non è protetta, questo valore è nullo.

`ProtectionEnabled`  
Lo stato di protezione dell'attività. Se la protezione scalabile è abilitata per un'attività, il valore è `true`. In caso contrario è `false`.

`TaskArn`  
L'Amazon Resource Name (ARN) completo dell'attività a cui appartiene il container.

L'esempio che segue mostra i dettagli restituiti per un'attività protetta.

```
curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
```

```
{
    "protection":{
        "ExpirationDate":"2023-12-20T21:57:44Z",
        "ProtectionEnabled":true,
        "TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
    }
}
```

Le seguenti informazioni vengono restituite quando si verifica un errore.

`Arn`  
Il nome della risorsa Amazon (ARN) completo dell'attività.

`Detail`  
I dettagli relativi all'errore.

`Reason`  
Il motivo dell’errore.

L'esempio che segue mostra i dettagli restituiti per un'attività che non è protetta.

```
{
    "failure":{
        "Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0",
        "Detail":null,
        "Reason":"TASK_NOT_VALID"
    }
}
```

Le seguenti informazioni vengono restituite quando si verifica un'eccezione.

`requestID`  
L'ID della AWS richiesta per la chiamata API Amazon ECS che genera un'eccezione.

`Arn`  
Il nome della risorsa Amazon (ARN) completo dell'attività o del servizio.

`Code`  
Il codice di errore.

`Message`  
Messaggio di errore.  
Se viene visualizzato un errore `RequestError` o `RequestTimeout`, è probabile che si tratti di un problema di rete. Prova a utilizzare gli endpoint VPC per Amazon ECS.

L'esempio che segue mostra i dettagli restituiti quando si verifica un errore.

```
{
    "requestID":"12345-abc-6789-0123-abc",
    "error":{
        "Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
        "Code":"AccessDeniedException",
        "Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action"
    }    
}
```

L'errore seguente viene visualizzato se l'agente Amazon ECS non è in grado di ottenere una risposta dall'endpoint Amazon ECS per motivi quali problemi di rete o il piano di controllo Amazon ECS inattivo.

```
{
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "RequestCanceled",
    "Message": "Timed out calling Amazon ECS Task Protection API"
  }
}
```

Il seguente errore si verifica quando l'agente Amazon ECS riceve un'eccezione di limitazione da Amazon ECS.

```
{
  "requestID": "12345-abc-6789-0123-abc",
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "ThrottlingException",
    "Message": "Rate exceeded"
  }
}
```

# Cluster Amazon ECS per Fargate
<a name="fargate-capacity-providers"></a>

Con Amazon ECS on AWS Fargate capacity provider, puoi utilizzare sia la capacità di Fargate che quella di Fargate Spot per le tue attività Amazon ECS. 

Con Fargate Spot è possibile eseguire le attività di Amazon ECS con tolleranza alle interruzioni a una tariffa scontata rispetto al prezzo di Fargate. Fargate Spot esegue le attività nella capacità di elaborazione di riserva. Quando è AWS necessario ripristinare la capacità, le attività vengono interrotte con un avviso di due minuti.

Quando le attività che utilizzano i provider di capacità Fargate e Fargate Spot vengono interrotte, l'evento di modifica dello stato dell'attività viene inviato ad Amazon. EventBridge Il motivo dell'interruzione descrive la causa. Per ulteriori informazioni, consulta [Eventi di modifica dello stato dei processi di Amazon ECS](ecs_task_events.md).

Un cluster può contenere una combinazione di provider di capacità del gruppo con scalabilità automatica e di Fargate. Tuttavia, una strategia di provider di capacità può contenere solo i provider di capacità del gruppo con scalabilità automatica o Fargate, ma non entrambi. Per ulteriori informazioni, consulta [Provider di capacità dei gruppi Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html#asg-capacity-providers).

Quando si utilizzano provider di capacità:
+ È necessario associare un provider di capacità a un cluster prima di associarlo alla strategia del provider di capacità.
+ È possibile specificare un massimo di 20 provider di capacità per una strategia del provider di capacità.
+ Non è possibile aggiornare un servizio che utilizza un provider di capacità di un gruppo con scalabilità automatica per utilizzare un provider di capacità Fargate. È vero anche il contrario.
+ In una strategia del provider di capacità, se non viene specificato alcun valore di `weight` per un provider di capacità nella console, allora viene utilizzato il valore predefinito `1`. Se si utilizza l'API o AWS CLI, `0` viene utilizzato il valore predefinito di.
+ Quando più provider di capacità sono specificati nell'ambito di una strategia di provider di capacità, almeno uno dei provider deve avere un valore di peso maggiore di zero. Tutti i provider di capacità con un peso pari a zero non vengono utilizzati per inserire attività. Se specifichi più provider di capacità in una strategia tutti con un peso pari a zero, allora qualsiasi operazione `RunTask` o `CreateService` che utilizza la strategia del provider di capacità avrà esito negativo.
+ In una strategia di provider di capacità, solo un provider di capacità può avere un valore di *base* definito. Se non viene specificato alcun valore, viene utilizzato il valore predefinito zero.
+ Un cluster può contenere una combinazione di provider di capacità del gruppo con scalabilità automatica e provider di capacità Fargate. Tuttavia, una strategia di provider di capacità può includere solo i provider di capacità del gruppo Auto Scaling o Fargate, ma non entrambi.
+ Un cluster può contenere una combinazione di servizi e attività autonome che utilizzano i provider di capacità. Un servizio può essere aggiornato per utilizzare una strategia del provider di capacità anziché un tipo di avvio. Tuttavia, quando si esegue questa operazione è necessario forzare una nuova implementazione.

## Avvisi di terminazione di Fargate Spot
<a name="fargate-capacity-providers-termination"></a>

Nei periodi con domanda estremamente elevata, la capacità Fargate spot potrebbe non essere disponibile. Ciò può causare ritardi nelle attività di Fargate Spot. Quando accade ciò, i servizi Amazon ECS riprovano ad avviare le attività finché non diventa disponibile la capacità richiesta. Fargate non sostituisce la capacità spot con quella on demand. 

Quando le attività che utilizzano la capacità Fargate Spot vengono interrotte a causa di un'interruzione Spot, viene inviato un avviso due minuti prima dell'arresto del processo. L'avviso viene inviato come evento di modifica dello stato dell'attività ad Amazon EventBridge e come segnale SIGTERM all'attività in esecuzione. Quando si utilizza Fargate Spot come parte di un servizio, lo scheduler del servizio riceve il segnale di interruzione e prova ad avviare altre attività su Fargate Spot se c'è capacità disponibile. Un servizio con una sola attività verrà interrotto fino a quando la capacità non sarà disponibile. Per ulteriori informazioni su un arresto corretto, consulta [Arresto regolare con ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/).

Per assicurarti che i container si chiudano correttamente prima che l'attività si interrompa, puoi configurare le seguenti impostazioni:
+ È possibile specificare un valore `stopTimeout` di `120` secondi al massimo nella definizione del container utilizzata dall'attività. Il valore di `stopTimeout` predefinito è 30 secondi. È possibile specificare un valore `stopTimeout` più lungo per avere più tempo tra il momento in cui viene ricevuto l'evento di modifica dello stato delle attività e il momento in cui viene forzato l'arresto del container. Per ulteriori informazioni, consulta [Timeout del container](task_definition_parameters.md#container_definition_timeout).
+ Il segnale SIGTERM deve essere ricevuto dall'interno del container per eseguire qualsiasi operazione di pulizia. La mancata elaborazione di questo segnale comporterà la ricezione di un segnale SIGKILL dopo la configurazione di `stopTimeout` e può comportare la perdita o il danneggiamento dei dati.

Di seguito è riportato un frammento di un evento di modifica dello stato dell'attività. Questo frammento visualizza il motivo dell'arresto e il codice di arresto per un'interruzione di Fargate Spot.

```
{
  "version": "0",
  "id": "9bcdac79-b31f-4d3d-9410-fbd727c29fab",
  "detail-type": "ECS Task State Change",
  "source": "aws.ecs",
  "account": "111122223333",
  "resources": [
    "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6f1cebef"
  ],
  "detail": {
    "clusterArn": "arn:aws:ecs:us-east-1:111122223333:cluster/default",
    "createdAt": "2016-12-06T16:41:05.702Z",
    "desiredStatus": "STOPPED",
    "lastStatus": "RUNNING",
    "stoppedReason": "Your Spot Task was interrupted.",
    "stopCode": "SpotInterruption",
    "taskArn": "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6fEXAMPLE",
    ...
  }
}
```

Di seguito è riportato uno schema di eventi utilizzato per creare una EventBridge regola per gli eventi di modifica dello stato delle attività di Amazon ECS. Facoltativamente, puoi specificare un cluster nel campo `detail`. Ciò significa che per quel cluster riceverai eventi di modifica dello stato delle attività. Per ulteriori informazioni sulla creazione di una EventBridge regola, consulta la sezione Guida [introduttiva ad Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) nella *Amazon EventBridge User Guide*.

```
{
    "source": [
        "aws.ecs"
    ],
    "detail-type": [
        "ECS Task State Change"
    ],
    "detail": {
        "clusterArn": [
            "arn:aws:ecs:us-west-2:111122223333:cluster/default"
        ]
    }
}
```

# Creazione di un cluster Amazon ECS per i carichi di lavoro Fargate
<a name="create-cluster-console-v2"></a>

Creazione di un cluster per definire l'infrastruttura in cui eseguire le attività e i servizi.

Prima di iniziare, accertati di aver completato le fasi in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md) e assegna l'autorizzazione IAM corretta. Per ulteriori informazioni, consulta [Esempi di cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). La console Amazon ECS crea le risorse necessarie a un cluster Amazon ECS creando uno CloudFormation stack. 

La console associa in modo automatico i provider di capacità Fargate e Fargate Spot al cluster.

È possibile modificare le seguenti opzioni:
+ Aggiungi un namespace al cluster.

  Un namespace consente ai servizi creati nel cluster di connettersi agli altri servizi nel namespace senza configurazioni aggiuntive. Per ulteriori informazioni, consulta [Interconnessione dei servizi Amazon ECS](interconnecting-services.md).
+ Abilita gli eventi delle attività per ricevere EventBridge notifiche relative alle modifiche dello stato delle attività.
+ Aggiungi tag per facilitare l'identificazione del cluster.
+ Assegna una AWS KMS chiave per lo storage gestito. Per informazioni su come creare una chiave, consulta [Create a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *Guida per l'utente di AWS Key Management Service *.
+ Assegna una AWS KMS chiave per la tua memoria effimera Fargate. Per informazioni su come creare una chiave, consulta [Create a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *Guida per l'utente di AWS Key Management Service *.
+ Configura la AWS KMS chiave e la registrazione per ECS Exec.

## Procedura
<a name="create-cluster-console-v2-procedure"></a>

**Creazione di un nuovo cluster (console Amazon ECS)**

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Seleziona la Regione da utilizzare nella barra di navigazione.

1. Nel pannello di navigazione scegli **Cluster**.

1. Nella pagina **Clusters** (Cluster), scegli **Create cluster** (Crea cluster).

1. In **Configurazione del cluster**, configura gli elementi seguenti:
   + In **Nome cluster**, inserisci un nome univoco.

     Il nome può contenere fino a 255 lettere (maiuscole e minuscole), numeri e trattini.
   + (Facoltativo) Per impostare un namespace diverso dal nome del cluster per Service Connect, in **Impostazioni predefinite di Service Connect**, per **Namespace predefinito**, seleziona o immetti il nome di un namespace. Per utilizzare un namespace condiviso, seleziona o inserisci un ARN del namespace. Per ulteriori informazioni sull'uso dei namespace condivisi, consulta [Amazon ECS Service Connect con namespace condivisi AWS Cloud Map](service-connect-shared-namespaces.md).

1. (Facoltativo) Usa Container Insights, espandi **Monitoraggio**, quindi seleziona una delle seguenti opzioni:
   + Per usare la soluzione consigliata di Container Insights con osservabilità migliorata, seleziona **Container Insights con osservabilità migliorata**.
   + Per utilizzare Container Insights scegli **Container Insights**.

1. (Facoltativo) Per abilitare gli eventi delle **attività, espandi Eventi** delle attività, quindi attiva **Abilita gli eventi delle attività**.

   Quando abiliti gli eventi delle attività, Amazon ECS invia gli eventi di modifica dello stato delle attività a EventBridge. Ciò consente di monitorare e rispondere automaticamente alle modifiche del ciclo di vita delle attività.

1. (Facoltativo) Per usare ECS Exec per eseguire il debug delle attività nel cluster, espandi **Configurazione della risoluzione dei problemi**. Quindi configura quanto segue:
   + (Facoltativo) Per **AWS KMS key for ECS Exec**, inserisci l'ARN della AWS KMS chiave che desideri utilizzare per crittografare i dati della sessione ECS Exec.
   + (Facoltativo) Per la **registrazione di ECS Exec**, scegli la destinazione del log:
     + **Per inviare i log a CloudWatch Logs, scegli Amazon. CloudWatch**
     + Per inviare i log ad Amazon S3, seleziona **Amazon S3**.
     + Per disabilitare la registrazione, seleziona **Nessuno**.

1. (Facoltativo) In **Crittografia**, puoi configurare quanto segue:
   + Crittografa i tuoi dati sull'archiviazione temporanea di Fargate. In **Crittografia**, per l'archiviazione **effimera Fargate,** inserisci l'ARN della AWS KMS chiave che desideri utilizzare per crittografare i dati di archiviazione effimera Fargate.
   + Crittografa i dati sullo storage gestito. In **Crittografia**, per **Storage gestito**, inserisci l'ARN della AWS KMS chiave che desideri utilizzare per crittografare i dati di storage gestito.

1. (Facoltativo) Per identificare il tuo cluster, espandi la sezione **Tags** (Tag), quindi configura i tag.

   [Aggiungere un tag] Scegliere **Add tag (Aggiungi tag)** e procedere come segue:
   + In **Chiave**, immetti il nome della chiave.
   + In **Valore**, immetti il valore della chiave.

   [Rimuovi un tag] Scegli **Rimuovi** a destra della Chiave e del Valore del tag.

1. Scegli **Create** (Crea).

## Fasi successive
<a name="fargate-cluster-next-steps"></a>

Dopo aver creato il cluster, è possibile creare le definizioni delle attività per le applicazioni e quindi eseguirle come attività autonome o come parte di un servizio. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Definizioni dei processi di Amazon ECS](task_definitions.md)
+ [Esecuzione di un'applicazione come attività Amazon ECS](standalone-task-create.md)
+ [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md)

# Provider di capacità Amazon ECS per carichi di lavoro di Amazon EC2
<a name="asg-capacity-providers"></a>

Quando utilizzi le istanze Amazon EC2 per la capacità, puoi sfruttare i gruppi con dimensionamento automatico per gestire le istanze Amazon EC2 registrate nei cluster. Auto Scaling si assicura che tu disponga del numero corretto di istanze Amazon EC2 disponibili per gestire il carico dell'applicazione. 

Puoi usare la funzionalità di dimensionamento gestito per permettere ad Amazon ECS di gestire le operazioni di riduzione e aumento orizzontale del gruppo Auto Scaling oppure puoi gestire le operazioni di dimensionamento autonomamente. Per ulteriori informazioni, consulta [Gestisci automaticamente la capacità di Amazon ECS con il dimensionamento automatico dei cluster](cluster-auto-scaling.md).

Ti consigliamo di creare un nuovo gruppo Auto Scaling. Se utilizzi un gruppo con scalabilità automatica esistente, qualsiasi istanza Amazon EC2 associata al gruppo che era già in esecuzione e registrata con un cluster Amazon ECS prima dell'uso del gruppo con scalabilità automatica per creare un provider di capacità potrebbe non essere registrata correttamente con il provider di capacità. Ciò può causare problemi quando si utilizza il provider di capacità in una strategia di provider di capacità. Utilizza `DescribeContainerInstances` per verificare se un'istanza di container è associata o meno a un provider di capacità.

**Nota**  
Per creare un gruppo Auto Scaling vuoto, imposta il conteggio desiderato su zero. Dopo aver creato il provider di capacità e averlo associato a un cluster, potrai aumentarlo.  
Quando usi la console Amazon ECS, Amazon ECS crea un modello di lancio Amazon EC2 e un gruppo Auto Scaling per tuo conto come parte dello stack. CloudFormation Sono preceduti da `EC2ContainerService-<ClusterName>`. Puoi utilizzare il gruppo Auto Scaling come provider di capacità per tale cluster.

Consigliamo di usare il drenaggio delle istanze gestite per consentire la terminazione graduale delle istanze Amazon EC2 senza interrompere i carichi di lavoro. Questa funzionalità è attiva per impostazione predefinita. Per ulteriori informazioni, consulta [Interrompi in modo sicuro i carichi di lavoro Amazon ECS in esecuzione sulle istanze EC2](managed-instance-draining.md)

Quando utilizzi i provider di capacità del gruppo Auto Scaling nella console, è opportuno considerare quanto segue:
+ Un gruppo Auto Scaling deve avere un valore `MaxSize` maggiore di zero per l'aumento orizzontale.
+ Il gruppo Auto Scaling non può avere impostazioni di ponderazione delle istanze.
+ Se il gruppo Auto Scaling non è in grado di impiegare la scalabilità orizzontale per adattarsi al numero di esecuzioni di attività, le attività non riusciranno ad andare oltre lo stato `PROVISIONING`.
+ Non modificare la risorsa della policy di scalabilità associata ai gruppi con scalabilità automatica gestiti dai provider di capacità. 
+ Se il dimensionamento gestito è attivato quando crei un provider di capacità, puoi impostare il conteggio per il gruppo con scalabilità automatica desiderato su `0`. Quando il dimensionamento gestito è attivato, Amazon ECS gestisce le operazioni di riduzione e aumento del gruppo con scalabilità automatica.
+ È necessario associare un provider di capacità a un cluster prima di associarlo alla strategia del provider di capacità.
+ È possibile specificare un massimo di 20 provider di capacità per una strategia del provider di capacità.
+ Non è possibile aggiornare un servizio che utilizza un provider di capacità di un gruppo con scalabilità automatica per utilizzare un provider di capacità Fargate. È vero anche il contrario.
+ In una strategia del provider di capacità, se non viene specificato alcun valore di `weight` per un provider di capacità nella console, allora viene utilizzato il valore predefinito `1`. Se si utilizza l'API o AWS CLI, viene utilizzato il valore predefinito di. `0`
+ Quando più provider di capacità sono specificati nell'ambito di una strategia di provider di capacità, almeno uno dei provider deve avere un valore di peso maggiore di zero. Tutti i provider di capacità con un peso pari a zero non vengono utilizzati per inserire attività. Se specifichi più provider di capacità in una strategia tutti con un peso pari a zero, allora qualsiasi operazione `RunTask` o `CreateService` che utilizza la strategia del provider di capacità avrà esito negativo.
+ In una strategia di provider di capacità, solo un provider di capacità può avere un valore di *base* definito. Se non viene specificato alcun valore, viene utilizzato il valore predefinito zero.
+ Un cluster può contenere una combinazione di provider di capacità del gruppo con scalabilità automatica e provider di capacità Fargate. Tuttavia, una strategia di provider di capacità può includere solo i provider di capacità del gruppo con scalabilità automatica o Fargate, ma non entrambi.
+ Un cluster può contenere una combinazione di servizi e attività autonome che utilizzano sia i provider di capacità che i tipi di avvio. Un servizio può essere aggiornato per utilizzare una strategia del provider di capacità anziché un tipo di avvio. Tuttavia, quando si esegue questa operazione è necessario forzare una nuova implementazione.
+ Amazon ECS supporta i warm pool Amazon EC2 Auto Scaling. Un warm pool è un gruppo di istanze Amazon EC2 pre-inizializzate pronte per essere messe in servizio. Ogni volta che l'applicazione ha bisogno di aumentare orizzontalmente, Amazon EC2 Auto Scaling utilizza le istanze pre-inizializzate dal warm pool anziché avviare istanze cold. Questo consente l'esecuzione di qualsiasi processo di inizializzazione finale prima della messa in servizio dell'istanza. Per ulteriori informazioni, consulta [Configurazione delle istanze preinizializzate per il tuo gruppo Auto Scaling Amazon ECS](using-warm-pool.md).

Per ulteriori informazioni su come creare un modello di avvio per Amazon EC2 Auto Scaling, consulta [Auto Scaling launch templates](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*. Per ulteriori informazioni su come creare un gruppo di Amazon EC2 Auto Scaling, consulta [Gruppi con scalabilità automatica](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.

# Considerazioni relative alla sicurezza delle istanze di container di Amazon EC2 per Amazon ECS
<a name="ec2-security-considerations"></a>

È consigliabile prendere in considerazione una singola istanza di container e il relativo accesso all'interno del modello di minaccia. Ad esempio, una singola attività interessata potrebbe essere in grado di sfruttare le autorizzazioni IAM di un'attività non infetta sulla stessa istanza.

Per impedirlo, consigliamo di utilizzare la procedura seguente:
+ Non utilizzare i privilegi di amministratore quando esegui le attività. 
+ Assegna un ruolo di attività con accesso meno privilegiato alle attività. 

  L'agente di container crea in automatico un token con un ID di credenziali univoco che viene utilizzato per accedere alle risorse Amazon ECS.
+ Per impedire ai container eseguiti da attività che utilizzano la modalità di rete `awsvpc` di accedere alle informazioni sulle credenziali fornite al profilo dell'istanza Amazon EC2, continuando allo stesso tempo a concedere le autorizzazioni fornite dal ruolo dell'attività, imposta la variabile di configurazione dell'agente `ECS_AWSVPC_BLOCK_IMDS` su true nel file di configurazione dell'agente e riavvia l'agente.
+ Usa Amazon GuardDuty Runtime Monitoring per rilevare le minacce per cluster e contenitori all'interno del tuo AWS ambiente. Runtime Monitoring utilizza un agente di GuardDuty sicurezza che aggiunge visibilità di runtime ai singoli carichi di lavoro Amazon ECS, ad esempio accesso ai file, esecuzione dei processi e connessioni di rete. Per ulteriori informazioni, consulta [GuardDutyRuntime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) nella Guida per l'*GuardDuty utente*.

# Creazione di un cluster Amazon ECS per i carichi di lavoro di Amazon EC2
<a name="create-ec2-cluster-console-v2"></a>

Creazione di un cluster per definire l'infrastruttura in cui eseguire le attività e i servizi.

Prima di iniziare, accertati di aver completato le fasi in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md) e assegna l'autorizzazione IAM corretta. Per ulteriori informazioni, consulta [Esempi di cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). La console Amazon ECS offre un modo semplice per creare le risorse necessarie a un cluster Amazon ECS creando uno CloudFormation stack. 

Per rendere il processo di creazione del cluster il più semplice possibile, la console dispone di selezioni predefinite per molte scelte che descriviamo di seguito. Ci sono anche pannelli di aiuto disponibili per la maggior parte delle sezioni della console che forniscono ulteriore contesto. 

Puoi registrare le istanze Amazon EC2 quando crei il cluster o registrare ulteriori istanze con il cluster dopo averlo creato.

È possibile modificare le seguenti opzioni di default:
+ Modifica le sottoreti in cui vengono avviate le istanze.
+ Modifica i gruppi di sicurezza utilizzati per controllare il traffico verso le istanze di container.
+ Aggiungi un namespace al cluster.

  Un namespace consente ai servizi creati nel cluster di connettersi agli altri servizi nel namespace senza configurazioni aggiuntive. Per ulteriori informazioni, consulta [Interconnessione dei servizi Amazon ECS](interconnecting-services.md).
+ Abilita gli eventi delle attività per ricevere EventBridge notifiche relative alle modifiche dello stato delle attività.
+ Assegna una AWS KMS chiave per lo storage gestito. Per informazioni su come creare una chiave, consulta [Create a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *Guida per l'utente di AWS Key Management Service *.
+ Assegna una AWS KMS chiave per la tua memoria effimera Fargate. Per informazioni su come creare una chiave, consulta [Create a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *Guida per l'utente di AWS Key Management Service *.
+ Configura la AWS KMS chiave e la registrazione per ECS Exec.
+ Aggiungi tag per facilitare l'identificazione del cluster.

## Opzioni del gruppo Auto Scaling
<a name="capacity-providers"></a>

Quando utilizzi istanze Amazon EC2, devi specificare un gruppo Auto Scaling per gestire l'infrastruttura su cui vengono eseguiti i processi e i servizi. 

Quando scegli di creare un nuovo gruppo Auto Scaling, questo viene configurato automaticamente per il seguente comportamento:
+ Amazon ECS gestisce le operazioni di riduzione e incremento orizzontale del gruppo Auto Scaling.
+ Amazon ECS non impedirà che le istanze di Amazon EC2 che contengono processi e si trovano in un gruppo Auto Scaling vengano terminate durante un'azione di riduzione orizzontale. Per ulteriori informazioni, consulta [Protezione delle istanze](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection) nella *Guida per l'utente di AWS Auto Scaling *.

Puoi configurare le seguenti proprietà del gruppo Auto Scaling che determinano il tipo e il numero di istanze da avviare per il gruppo:
+ Le AMI ottimizzate per Amazon ECS. 
+ Il tipo di istanza.
+ La coppia di chiavi SSH che dimostra la tua identità quando ti connetti all'istanza. Per ulteriori informazioni sulla creazione di chiavi SSH, consulta [Coppie di chiavi Amazon EC2 e istanza Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella *Guida per l'utente di Amazon EC2*.
+ Il numero minimo di istanze da avviare per il gruppo Auto Scaling. 
+ Il numero massimo di istanze avviate per il gruppo Auto Scaling. 

  Affinché il gruppo venga aumentato orizzontalmente, il massimo deve essere superiore a 0.

Amazon ECS crea un modello di avvio di Amazon EC2 Auto Scaling e un gruppo Auto Scaling per tuo conto come parte dello stack CloudFormation . I valori specificati per l'AMI, i tipi di istanza e la coppia di chiavi SSH fanno parte del modello di avvio. Viene utilizzato il prefisso `EC2ContainerService-<ClusterName>` per identificare i modelli con facilità. I gruppi Auto Scaling hanno il prefisso `<ClusterName>-ECS-Infra-ECSAutoScalingGroup`.

Le istanze avviate per il gruppo Auto Scaling utilizzano il modello di avvio.

## Opzioni di rete
<a name="networking-options"></a>

Per impostazione predefinita, le istanze vengono avviate nelle sottoreti predefinite per la regione. Vengono utilizzati i gruppi di sicurezza, che controllano il traffico verso le istanze di container, attualmente associati alle sottoreti. Puoi modificare le sottoreti e i gruppi di sicurezza per le istanze.

Puoi scegliere una sottorete esistente. È possibile usare un gruppo di sicurezza esistente o crearne uno nuovo. Per creare attività in una configurazione IPv6 solo, utilizza sottoreti che includono solo un blocco CIDR. IPv6 

Quando crei un nuovo gruppo di sicurezza, devi specificare almeno una regola in entrata. 

Le regole in entrata determinano il traffico che può raggiungere le istanze di container e includono le seguenti proprietà: 
+ Il protocollo da consentire
+ L’intervallo di porte da autorizzare
+ Il traffico in entrata (origine)

Per consentire il traffico in entrata da un indirizzo o da un intervallo CIDR specifico, usa **Personalizzato** per **Origine** con il CIDR consentito. 

Per consentire il traffico in entrata da tutte le destinazioni, specifica **Ovunque** per **Origine**. Questo aggiunge automaticamente il blocco CIDR 0.0.0.0/0 e il blocco CIDR: :/0 IPv4 . IPv6 

Per consentire il traffico in entrata dal computer locale, usa **Gruppo di origine** per **Origine**. Questa operazione aggiunge automaticamente l'indirizzo IP attuale del computer locale come origine consentita.

**Creazione di un nuovo cluster (console Amazon ECS)**

Prima di iniziare, assegna l'autorizzazione IAM appropriata. Per ulteriori informazioni, consulta [Esempi di cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies).

1. Apri [https://console.aws.amazon.com/ecs/la console](https://console.aws.amazon.com/ecs/v2) alla v2.

1. Seleziona la Regione da utilizzare nella barra di navigazione.

1. Nel pannello di navigazione scegli **Cluster**.

1. Nella pagina **Clusters** (Cluster), scegli **Create cluster** (Crea cluster).

1. In **Configurazione del cluster**, configura gli elementi seguenti:
   + In **Nome cluster**, inserisci un nome univoco.

     Il nome può contenere fino a 255 lettere (maiuscole e minuscole), numeri e trattini.
   + (Facoltativo) Per impostare un namespace diverso dal nome del cluster per Service Connect, in **Impostazioni predefinite di Service Connect**, per **Namespace predefinito**, seleziona o immetti il nome di un namespace. Per utilizzare un namespace condiviso, seleziona o inserisci un ARN del namespace. Per ulteriori informazioni sull'uso dei namespace condivisi, consulta [Amazon ECS Service Connect con namespace condivisi AWS Cloud Map](service-connect-shared-namespaces.md).

1. Se desideri aggiungere istanze Amazon EC2 al cluster, espandi **Infrastruttura** e poi seleziona **Istanze autogestite e Fargate**. 

   Successivamente, configura il gruppo Auto Scaling che funge da provider di capacità:

   1. Per utilizzare un gruppo Auto Scaling esistente, da **Auto Scaling group (ASG)** (Gruppo di Auto Scaling (ASG)), seleziona il gruppo.

   1. Per creare un gruppo Auto Scaling, da **Auto Scaling group (ASG)** (Gruppo di Auto Scaling (ASG)), seleziona **Create new group** (Crea nuovo gruppo) e quindi fornisci i seguenti dettagli sul gruppo:
      + Per il **Modello di provisioning**, scegli se utilizzare istanze **on demand** o istanze **spot**.
      + Se decidi di usare le istanze spot, per la **strategia di allocazione**, scegli quali pool di capacità spot (tipi di istanza e zone di disponibilità) usare per le istanze.

        Per la maggior parte dei carichi di lavoro, puoi scegliere l'opzione **Capacità di prezzo ottimizzata**.

        Per ulteriori informazioni, consulta [Strategie di allocazione per Istanze spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html) nella *Guida per l'utente di Amazon EC2*.
      + Per l'**istanza di container Amazon Machine Image (AMI)**, scegli l'AMI ottimizzata per Amazon ECS per le istanze di gruppo Auto Scaling.
      + In **EC2 instance type** (Tipo di istanza EC2), scegli il tipo di istanza per i tuoi carichi di lavoro.

         La scalabilità gestita funziona meglio se il gruppo Auto Scaling utilizza tipi di istanza uguali o simili. 
      + Per il **ruolo dell'istanza EC2**, scegli un ruolo dell'istanza di container esistente oppure puoi crearne uno nuovo.

        Per ulteriori informazioni, consulta [Ruolo IAM delle istanze di container Amazon ECS](instance_IAM_role.md).
      + In **Capacity** (Capacità), inserisci il numero minimo e massimo di istanze da avviare nel gruppo Auto Scaling. 
      + In **SSH key pair** (Coppia di chiavi SSH), scegli la coppia che dimostra la tua identità quando ti connetti all'istanza.
      + Per consentire immagini e spazio di archiviazione più grandi, per la **dimensione del volume EBS root**, immetti il valore in GiB. 

1. (Facoltativo) Per modificare il VPC e le sottoreti, in **Reti per le istanze Amazon EC2**, esegui una qualunque di queste operazioni:
   + Per rimuovere una sottorete, in **Subnets** (Sottoreti), scegli **X** per ogni sottorete da rimuovere.
   + Per passare a un VPC diverso da quello **di default**, in **VPC**, scegli un **VPC** esistente, poi in **Sottoreti**, seleziona le sottoreti. Per una configurazione IPv6 solo, scegli un VPC con un blocco CIDR e sottoreti che hanno solo IPv6 un blocco CIDR. IPv6 
   + Scegli i gruppi di sicurezza. In **Gruppo di sicurezza**, scegli una delle seguenti opzioni:
     + Per utilizzare un gruppo di sicurezza esistente, scegli **Usa un gruppo di sicurezza esistente**, quindi selezionalo.
     + Per creare un nuovo gruppo di sicurezza, scegli **Crea un nuovo gruppo di sicurezza**. Scegli quindi **Aggiungi regola** per ogni regola in entrata.

       Per informazioni sulle regole in entrata, consulta [Opzioni di rete](#networking-options). 
   + Per assegnare automaticamente gli indirizzi IP pubblici alle istanze di container Amazon EC2, in **Assegna automaticamente IP pubblico**, scegli una delle seguenti opzioni:
     + **Usa impostazione della sottorete**: assegna un indirizzo IP pubblico alle istanze quando la sottorete in cui le istanze vengono avviate è una sottorete pubblica.
     + **Attiva**: assegna un indirizzo IP pubblico alle istanze.

1. (Facoltativo) Usa Container Insights, espandi **Monitoraggio**, quindi seleziona una delle seguenti opzioni:
   + Per usare la soluzione consigliata di Container Insights con osservabilità migliorata, seleziona **Container Insights con osservabilità migliorata**.
   + Per utilizzare Container Insights scegli **Container Insights**.

1. **(Facoltativo) Per abilitare gli eventi delle attività, espandi Eventi delle **attività, quindi attiva Abilita gli eventi** delle attività.**

   Quando abiliti gli eventi delle attività, Amazon ECS invia gli eventi di modifica dello stato delle attività a EventBridge. Ciò consente di monitorare e rispondere automaticamente alle modifiche del ciclo di vita delle attività.

1. (Facoltativo) Per usare ECS Exec per eseguire il debug delle attività nel cluster, espandi **Configurazione della risoluzione dei problemi**. Quindi configura quanto segue:
   + (Facoltativo) Per **AWS KMS key for ECS Exec**, inserisci l'ARN della AWS KMS chiave che desideri utilizzare per crittografare i dati della sessione ECS Exec.
   + (Facoltativo) Per la **registrazione di ECS Exec**, scegli la destinazione del log:
     + **Per inviare i log a CloudWatch Logs, scegli Amazon. CloudWatch**
     + Per inviare i log ad Amazon S3, seleziona **Amazon S3**.
     + Per disabilitare la registrazione, seleziona **Nessuno**.

1. (Facoltativo)

   Se utilizzi Runtime Monitoring con l'opzione manuale e desideri che questo cluster venga monitorato da GuardDuty, scegli **Aggiungi tag e procedi** come segue:
   + In **Chiave**, inserisci **guardDutyRuntimeMonitoringManaged**
   + In **Valore**, specifica **true**.

1. (Facoltativo) Crittografa i dati sullo storage gestito. In **Crittografia**, per **Storage gestito**, inserisci l'ARN della AWS KMS chiave che desideri utilizzare per crittografare i dati di storage gestito.

1. (Facoltativo) Per gestire i tag cluster, espandi **Tags** (Tag), quindi esegui una delle seguenti operazioni:

   [Aggiungere un tag] Scegliere **Add tag (Aggiungi tag)** e procedere come segue:
   + In **Chiave**, immetti il nome della chiave.
   + In **Valore**, immetti il valore della chiave.

   [Rimuovi un tag] Scegli **Rimuovi** a destra della Chiave e del Valore del tag.

1. Scegli **Create** (Crea).

## Fasi successive
<a name="ec2-cluster-next-steps"></a>

Dopo aver creato il cluster, è possibile creare le definizioni delle attività per le applicazioni e quindi eseguirle come attività autonome o come parte di un servizio. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Definizioni dei processi di Amazon ECS](task_definitions.md)
+ [Esecuzione di un'applicazione come attività Amazon ECS](standalone-task-create.md)
+ [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md)

# Gestisci automaticamente la capacità di Amazon ECS con il dimensionamento automatico dei cluster
<a name="cluster-auto-scaling"></a>

Amazon ECS è in grado di gestire la scalabilità delle istanze Amazon EC2 registrate nel cluster. Questa operazione viene definita *dimensionamento automatico del cluster* Amazon ECS. Quando crei il provider di capacità del gruppo Auto Scaling Amazon ECS, attivi il dimensionamento gestito. Quindi, imposti una percentuale di destinazione (`targetCapacity`) per l'utilizzo dell'istanza in questo gruppo Auto Scaling. Amazon ECS crea due CloudWatch metriche personalizzate e una politica di scalabilità di tracciamento mirata per il tuo gruppo Auto Scaling. Amazon ECS gestisce quindi le operazioni di dimensionamento e scalabilità orizzontale in base all'utilizzo delle risorse utilizzate dalle attività.

Per ogni provider di capacità del gruppo con scalabilità automatica associato a un cluster, Amazon ECS crea e gestisce le seguenti risorse.
+ Un allarme con un valore metrico basso CloudWatch 
+ Un allarme con valore metrico elevato CloudWatch 
+ Una policy di scalabilità di monitoraggio dei target
**Nota**  
Amazon ECS crea la policy di scalabilità di monitoraggio dei target e la collega al gruppo con scalabilità automatica. Per aggiornare la policy di scalabilità di monitoraggio delle destinazioni, aggiornare le impostazioni di scalabilità gestita della policy e non aggiornare direttamente la policy di scalabilità.

Quando disattivi la scalabilità gestita o dissocii il fornitore di capacità da un cluster, Amazon ECS rimuove sia i CloudWatch parametri che le risorse della policy di scalabilità di tracciamento di destinazione.

Amazon ECS usa i seguenti parametri per determinare quali operazioni intraprendere:

`CapacityProviderReservation`  
La percentuale di istanze di container in uso per un provider di capacità specifico. Questo parametro è generato da Amazon ECS.  
Amazon ECS imposta il valore `CapacityProviderReservation` su un numero compreso tra 0 e 100. Amazon ECS utilizza la seguente formula per rappresentare il rapporto della capacità rimanente nel gruppo Auto Scaling. Quindi, Amazon ECS pubblica la metrica su. CloudWatch Per maggiori informazioni su come viene calcolato il parametro, consulta [Approfondimento sul dimensionamento automatico del cluster Amazon ECS](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).  

```
CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
```

`DesiredCapacity`  
La quantità di capacità del gruppo Auto Scaling. Questa metrica non è pubblicata su. CloudWatch

Amazon ECS pubblica la `CapacityProviderReservation` metrica CloudWatch nel namespace. `AWS/ECS/ManagedScaling` Il parametro `CapacityProviderReservation` provoca una delle seguenti operazioni:

**Il valore `CapacityProviderReservation` è uguale a `targetCapacity`**  
Il gruppo Auto Scaling non ha bisogno di essere ridimensionato o di impiegare la scalabilità orizzontale. La percentuale di utilizzo prevista è stata raggiunta.

**Il valore `CapacityProviderReservation` è maggiore di `targetCapacity`**  
Ci sono più attività che utilizzano una percentuale di capacità più elevata rispetto alla percentuale `targetCapacity`. L'aumento del valore della `CapacityProviderReservation` metrica provoca l'attivazione dell'allarme associato. CloudWatch Questo allarme aggiorna il valore di `DesiredCapacity` per il gruppo Auto Scaling. Il gruppo Auto Scaling utilizza questo valore per avviare le istanze EC2 e quindi registrarle con il cluster.  
Se `targetCapacity` è il valore predefinito del 100%, le nuove attività rimangono nello stato `PENDING` durante l'impiego della scalabilità orizzontale poiché non c'è capacità disponibile sulle istanze per eseguire le attività. Dopo la registrazione delle nuove istanze con ECS, queste attività verranno avviate sulle nuove istanze.

**Il valore `CapacityProviderReservation` è inferiore a `targetCapacity`**  
Ci sono meno attività che utilizzano una percentuale di capacità inferiore rispetto alla percentuale `targetCapacity` ed è presente almeno un'istanza che può essere terminata. La diminuzione del valore della `CapacityProviderReservation` metrica provoca l'attivazione dell' CloudWatch allarme associato. Questo allarme aggiorna il valore di `DesiredCapacity` per il gruppo Auto Scaling. Il gruppo Auto Scaling utilizza questo valore per terminare le istanze di container EC2 e quindi annullarne la registrazione con il cluster.  
Il gruppo Auto Scaling utilizza le policy di terminazione, per determinare quali istanze terminare per prime durante gli eventi di ridimensionamento. Inoltre, evita le istanze con l'impostazione di protezione da ridimensionamento delle istanze attivata. Il dimensionamento automatico del cluster può gestire le istanze con l'impostazione di protezione per il ridimensionamento se la protezione da terminazione gestita è attivata. Per ulteriori informazioni sulla protezione da terminazione gestita, consulta [Controlla le istanze terminate da Amazon ECS](managed-termination-protection.md). Per ulteriori informazioni sul modo in cui i gruppi con dimensionamento automatico terminano le istanze, consulta [Controllo delle istanze con dimensionamento automatico che vengono terminate durante il ridimensionamento](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.

Quando utilizzi il dimensionamento automatico del cluster, tieni in considerazione i seguenti aspetti:
+ Non modificare o gestire la capacità desiderata per il gruppo con scalabilità automatica associato a un provider di capacità con policy di dimensionamento diverse da quelle gestite da Amazon ECS.
+ Quando Amazon ECS aumenta orizzontalmente da 0 istanze, ne avvia automaticamente 2.
+ Amazon ECS utilizza il ruolo IAM `AWSServiceRoleForECS` collegato al servizio per le autorizzazioni necessarie per richiamare AWS Auto Scaling per tuo conto. Per ulteriori informazioni, consulta [Uso di ruoli collegati ai servizi per Amazon ECS](using-service-linked-roles.md).
+ Quando utilizzi provider di capacità con gruppi con scalabilità automatica, l'utente, il gruppo e il ruolo che crea i provider di capacità richiedono l'autorizzazione `autoscaling:CreateOrUpdateTags`. Questo perché Amazon ECS aggiunge un tag al gruppo Auto Scaling quando lo associ al provider di capacità.
**Importante**  
Assicurati che qualsiasi strumento utilizzato non rimuova il tag `AmazonECSManaged` dal gruppo con scalabilità automatica. Se questo tag viene rimosso, Amazon ECS non sarà in grado di gestire il dimensionamento.
+ La scalabilità automatica del cluster non modifica l'**MinimumCapacity**or **MaximumCapacity**per il gruppo. Affinché il gruppo venga scalato orizzontalmente, il valore di **MaximumCapacity**deve essere maggiore di zero.
+ Quando è attivata la scalabilità automatica (dimensionamento gestito), un provider di capacità può essere connesso solo a un cluster contemporaneamente. Se per il provider di capacità la scalabilità gestita è disattivata, è possibile associarlo a più cluster.
+ Quando il dimensionamento gestito è disattivato, il provider di capacità non esegue operazioni di dimensionamento con riduzione o aumento orizzontale. In questo caso, è possibile utilizzare una strategia del provider di capacità per bilanciare le attività tra i provider di capacità.
+ La strategia `binpack` è la più efficiente in termini di capacità.
+ Quando la capacità di destinazione è inferiore al 100%, nell'ambito della strategia di collocamento, la strategia `binpack` deve avere un ordine superiore rispetto alla strategia `spread`. Ciò impedisce al provider di capacità di aumentare orizzontalmente fino a quando ogni attività non dispone di un'istanza dedicata o non viene raggiunto il limite.

## Attivazione del dimensionamento automatico del cluster
<a name="cluster-auto-scale-use"></a>

Puoi attivare il dimensionamento automatico del cluster usando la console o la AWS CLI.

Quando crei un cluster che usa i provider di capacità EC2 tramite la console, Amazon ECS crea un gruppo Auto Scaling per tuo conto e imposta la capacità di destinazione. Per ulteriori informazioni, consulta [Creazione di un cluster Amazon ECS per i carichi di lavoro di Amazon EC2](create-ec2-cluster-console-v2.md).

Puoi anche creare un gruppo Auto Scaling e poi assegnarlo a un cluster. Per ulteriori informazioni, consulta [Aggiornare un provider di capacità Amazon ECS](update-capacity-provider-console-v2.md).

Quando si utilizza il AWS CLI, dopo aver creato il cluster

1. Prima di creare il provider di capacità, è necessario creare un gruppo con scalabilità automatica. Per ulteriori informazioni, consulta [Gruppi con scalabilità automatica](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.

1. Usa `put-cluster-capacity-providers` per modificare il provider di capacità del cluster. Per ulteriori informazioni, consulta [Attivazione del Dimensionamento automatico del cluster Amazon ECS](turn-on-cluster-auto-scaling.md).

# Ottimizzazione del dimensionamento automatico del cluster Amazon ECS
<a name="capacity-cluster-speed-up-ec2"></a>

I clienti che eseguono Amazon ECS su Amazon EC2 possono sfruttare il dimensionamento automatico dei cluster per gestire il dimensionamento dei gruppi Amazon EC2 Auto Scaling. Con il dimensionamento automatico dei cluster, puoi configurare Amazon ECS per scalare automaticamente il tuo gruppo Auto Scaling e concentrarti esclusivamente sull'esecuzione delle tue attività. Amazon ECS garantisce che il gruppo Auto Scaling aumenti e si riduca orizzontalmente in base alle necessità senza ulteriori interventi. I provider di capacità Amazon ECS vengono utilizzati per gestire l'infrastruttura nel cluster, garantendo che vi siano istanze di container sufficienti a soddisfare le esigenze dell'applicazione. Per scoprire come funziona il dimensionamento automatico dei cluster, consulta [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).

La scalabilità automatica del cluster si basa su un'integrazione CloudWatch basata con il gruppo Auto Scaling per la regolazione della capacità del cluster. Pertanto ha una latenza intrinseca associata a 
+ Pubblicazione delle metriche, CloudWatch 
+ Il tempo impiegato dalla metrica per `CapacityProviderReservation` violare gli CloudWatch allarmi (sia alti che bassi)
+ Il tempo necessario per la preparazione di un'istanza Amazon EC2 appena avviata. È possibile eseguire le seguenti azioni per rendere il dimensionamento automatico dei cluster più reattivo e velocizzare le implementazioni:

## Scalabilità graduale delle dimensioni del provider di capacità
<a name="cas-step-size"></a>

I fornitori di capacità di Amazon ECS sceglieranno grow/shrink le istanze di container per soddisfare le esigenze della tua applicazione. Il numero minimo di istanze che Amazon ECS avvierà è impostato su 1 per impostazione predefinita. Ciò potrebbe comportare un aumento dei tempi di implementazione, qualora fossero necessarie diverse istanze per l'esecuzione delle attività in sospeso. Puoi aumentare il valore [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) tramite l'API Amazon ECS per aumentare il numero minimo di istanze che Amazon ECS scala in entrata o in uscita alla volta. Un valore [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) troppo basso può limitare il numero di istanze di container scalate in entrata o in uscita alla volta, rallentando le implementazioni.

**Nota**  
Questa configurazione è attualmente disponibile solo tramite o. [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) APIs

## Periodo di preparazione dell'istanza
<a name="instance-warmup-period"></a>

Il periodo di riscaldamento dell'istanza è il periodo di tempo dopo il quale un'istanza Amazon EC2 appena lanciata può contribuire CloudWatch ai parametri per il gruppo Auto Scaling. Allo scadere del periodo di preparazione specificato, l'istanza viene conteggiata nelle metriche aggregate del gruppo Auto Scaling e il cluster di dimensionamento automatico procede con la successiva iterazione dei calcoli per stimare il numero di istanze richieste.

Il valore predefinito per [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod)è 300 secondi, che puoi configurare su un valore inferiore tramite [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)o [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs per un ridimensionamento più reattivo. Consigliamo di impostare un valore superiore a 60 secondi in modo da evitare un eccessivo provisioning.

## Capacità di riserva
<a name="spare-capacity"></a>

Se il tuo provider di capacità non dispone di istanze di container per l'inserimento delle attività, deve aumentare orizzontalmente la capacità del cluster avviando immediatamente le istanze Amazon EC2 e attendere che si avviino prima di poter avviare container su di esse. Questo può ridurre significativamente la velocità di avvio delle attività. Sono quindi disponibili due opzioni.

 In questo caso, disporre di capacità Amazon EC2 di riserva già avviata e pronta per l'esecuzione delle attività aumenterà la velocità effettiva di avvio delle attività. Puoi usare la configurazione `Target Capacity` per indicare che vuoi mantenere una capacità di riserva nei cluster. Ad esempio, impostando `Target Capacity` all'80%, indichi che il cluster necessita di una capacità di riserva del 20% in ogni momento. Questa capacità di riserva consente di avviare immediatamente qualsiasi attività autonoma, garantendo che l'avvio delle attività non sia limitato. Il compromesso, nel caso di questo approccio, è il potenziale aumento dei costi legati al mantenimento della capacità di riserva del cluster. 

Un approccio alternativo che si può prendere in considerazione è quello di aggiungere margine di manovra al tuo servizio, e non al provider di capacità. Ciò significa che invece di ridurre la configurazione della `Target Capacity` per avviare la capacità di riserva, puoi aumentare il numero di repliche nel servizio modificando la metrica di dimensionamento di monitoraggio delle destinazioni o le soglie di dimensionamento graduale del dimensionamento automatico. Tieni presente che questo approccio sarà utile solo per i carichi di lavoro soggetti a picchi, ma non avrà alcun effetto quando si implementano nuovi servizi e si passa da 0 a N attività per la prima volta. Per ulteriori informazioni sui criteri di dimensionamento correlati, consulta le [Target Tracking Scaling Policies](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) o [Step Scaling Policies](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html) nella *Guida per gli sviluppatori di Amazon Elastic Container Service*.

# Comportamento del dimensionamento gestito da Amazon ECS
<a name="managed-scaling-behavior"></a>

Quando utilizzi provider di capacità del gruppo Auto Scaling che utilizzano il dimensionamento gestito, Amazon ECS stima il numero ottimale di istanze da aggiungere al cluster e utilizza questo valore per determinare il numero di istanze da richiedere o rilasciare.

## Comportamento dell'aumento orizzontale gestito
<a name="managed-scaling-scaleout"></a>

Amazon ECS seleziona un provider di capacità per ogni attività seguendo la strategia del provider di capacità dal servizio, dall'attività autonoma o dall'impostazione predefinita del cluster. Amazon ECS segue il resto di questi passaggi per un singolo provider di capacità.

Le attività senza una strategia per i provider di capacità vengono ignorate dai provider di capacità. Un'attività in sospeso che non prevede una strategia del provider di capacità non comporterà l'impiego della scalabilità orizzontale di alcun provider di capacità. Le attività o i servizi non possono configurare una strategia del provider di capacità se tale attività o servizio imposta un tipo di avvio.

Di seguito viene descritto il comportamento dell'aumento orizzontale in modo più dettagliato.
+ Raggruppa tutti i processi di provisioning per questo provider di capacità in modo che ogni gruppo abbia gli stessi requisiti di risorse esatti.
+ Quando utilizzi più istanze in un gruppo Auto Scaling, le istanze all'interno di tale gruppo vengono ordinate in base ai relativi parametri. Questi parametri includono vCPU, memoria, interfacce di rete elastiche (ENIs), porte e. GPUs Vengono selezionati i tipi di istanza più piccoli e più grandi per ciascun parametro. Per ulteriori informazioni su come scegliere il tipo di istanza, consulta [Istanze di container Amazon EC2 per Amazon ECS](create-capacity.md).
**Importante**  
Se un gruppo di attività ha requisiti di risorse superiori al tipo di istanza più piccolo del gruppo Auto Scaling, quel gruppo di attività non può essere eseguito con questo provider di capacità. Il provider di capacità non dimensiona il gruppo Auto Scaling. Le attività rimangono nello stato `PROVISIONING`.  
Per evitare che le attività rimangano nello stato `PROVISIONING`, consigliamo di creare gruppi con dimensionamento automatico e provider di capacità separati per diversi requisiti minimi di risorse. Quando esegui attività o crei servizi, aggiungi solo provider di capacità alla strategia del provider di capacità in grado di eseguire l'attività sul tipo di istanza più piccolo del gruppo Auto Scaling. Per altri parametri, puoi utilizzare i vincoli di posizionamento
+ Per ogni gruppo di attività, Amazon ECS calcola il numero di istanze necessarie per eseguire le attività non posizionate. Questo calcolo utilizza una strategia `binpack`. Questa strategia tiene conto dei requisiti di vCPU, memoria, interfacce di rete elastiche (ENI), porte e GPU delle attività. Tiene conto anche della disponibilità di risorse delle istanze Amazon EC2. I valori per i tipi di istanza più grandi sono considerati quale numero massimo di istanze calcolato. I valori per il tipo di istanza più piccolo vengono utilizzati come protezione. Se il tipo di istanza più piccolo non può eseguire almeno un'istanza dell'attività, il calcolo considera l'attività come non compatibile. Di conseguenza, l'attività viene esclusa dal calcolo dell'aumento orizzontale. Quando tutte le attività non sono compatibili con il tipo di istanza più piccolo, il dimensionamento automatico del cluster si interrompe e il valore `CapacityProviderReservation` rimane `targetCapacity`.
+ Amazon ECS pubblica la `CapacityProviderReservation` metrica in CloudWatch relazione al `minimumScalingStepSize` caso in cui si verifichi una delle seguenti condizioni. 
  + Il numero massimo di istanze calcolato è inferiore all'incremento minimo del dimensionamento.
  + Il valore inferiore di `maximumScalingStepSize` o il numero massimo di istanze calcolato.
+ CloudWatch gli allarmi utilizzano la `CapacityProviderReservation` metrica per i fornitori di capacità. Quando il parametro `CapacityProviderReservation` è maggiore del valore di `targetCapacity`, gli allarmi aumentano anche la `DesiredCapacity` del gruppo con scalabilità automatica. Il `targetCapacity` valore è un'impostazione del provider di capacità che viene inviata all' CloudWatch allarme durante la fase di attivazione dell'auto scaling del cluster. 

  Il valore `targetCapacity` di default è 100%.
+ Il gruppo Auto Scaling avvia istanze EC2 aggiuntive. Per evitare un provisioning eccessivo, il dimensionamento automatico assicura che la capacità dell'istanza EC2 avviata di recente sia stabilizzata prima di avviare nuove istanze. La scalabilità automatica verifica se tutte le istanze esistenti hanno superato il `instanceWarmupPeriod` (ora meno il tempo di avvio dell'istanza). L'aumento orizzontale è bloccato per le istanze che si trovano all'interno del `instanceWarmupPeriod`.

  Il tempo di default per il riscaldamento di un'istanza appena avviata è di 300 secondi.

Per maggiori informazioni, consulta [Approfondimento sulla scalabilità automatica del cluster Amazon ECS](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).

### Considerazioni sull'aumento orizzontale
<a name="scale-out-considerations"></a>

 Considera quanto segue per il processo di aumento orizzontale:
+ Sebbene esistano più vincoli di collocamento, è consigliabile utilizzare solo il vincolo `distinctInstance` per la collocazione delle attività. Ciò impedisce l'arresto del processo di aumento orizzontale in seguito all'utilizzo di un vincolo di posizionamento non compatibile con le istanze campionate.
+ La scalabilità gestita funziona meglio se il gruppo Auto Scaling utilizza tipi di istanza uguali o simili. 
+ Quando è necessario un processo di scalabilità orizzontale e non sono presenti istanze di container attualmente in esecuzione, inizialmente Amazon ECS impiega sempre la scalabilità orizzontale fino a due istanze, quindi esegue processi di scalabilità orizzontale o ridimensionamento aggiuntivi. Qualsiasi ulteriore impiego della scalabilità orizzontale attende il periodo di preparazione dell'istanza. Per i processi di ridimensionamento, Amazon ECS attende 15 minuti dopo un processo di scalabilità orizzontale prima di avviare in qualsiasi momento i processi di ridimensionamento.
+ La seconda fase di aumento orizzontale deve attendere fino allo scadere del `instanceWarmupPeriod`, che potrebbe influire sul limite di scalabilità complessivo. Se devi ridurre questo tempo, assicurati che il `instanceWarmupPeriod` sia sufficientemente grande da consentire all'istanza EC2 di avviare e inizializzare l'agente Amazon ECS (che impedisce il provisioning eccessivo).
+ Il dimensionamento automatico del cluster supporta la configurazione di avvio, i modelli di avvio e più tipi di istanze nel gruppo Auto Scaling del provider di capacità. Puoi inoltre utilizzare la selezione del tipo di istanza basata su attributi senza molteplici tipi di istanze.
+ Quando utilizzi un gruppo Auto Scaling con istanze on demando e più tipi di istanza o istanze Spot, posiziona i tipi di istanza più grandi più in alto nell'elenco di priorità e non specificare un peso. Al momento la specifica di un peso non è supportata. Per ulteriori informazioni, consulta [Gruppi Auto Scaling con più tipi di istanze](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) nella *Guida per l'utente di AWS Auto Scaling *.
+ Amazon ECS avvierà quindi `minimumScalingStepSize`, se il conteggio massimo delle istanze calcolate è inferiore alla dimensione minima del passo di dimensionamento o il valore inferiore di `maximumScalingStepSize` o del valore massimo del conteggio delle istanze calcolato.
+ Se un servizio Amazon ECS o `run-task` avvia un'attività e le istanze di container del provider di capacità non dispongono di risorse sufficienti per avviare l'attività, Amazon ECS limita il numero di attività con questo stato per ciascun cluster e impedisce l'esecuzione di qualsiasi attività al di sopra di tale limite. Per ulteriori informazioni, consulta [Service Quotas di Amazon ECS](service-quotas.md).

## Comportamento di riduzione orizzontale gestita
<a name="managed-scaling-scalein"></a>

Amazon ECS monitora le istanze di container per ciascun provider di capacità all'interno di un cluster. Quando un'istanza di container non esegue alcuna attività, viene considerata vuota e Amazon ECS avvia il processo di ridimensionamento. 

CloudWatch gli allarmi scale-in richiedono 15 punti dati (15 minuti) prima dell'avvio del processo di scalabilità per il gruppo Auto Scaling. Dopo l'avvio del processo di riduzione orizzontale, fino a quando Amazon ECS non ha bisogno di ridurre il numero di istanze di container registrate, il gruppo con scalabilità automatica imposta il valore `DesireCapacity` di modo che sia superiore a un'istanza e inferiore al 50% ogni minuto.

Quando Amazon ECS richiede un aumento orizzontale (quando `CapacityProviderReservation` è maggiore di 100) mentre è in corso un processo di riduzione orizzontale, il processo di riduzione orizzontale viene interrotto e ricomincerà daccapo, se necessario.

Di seguito viene descritto il comportamento del ridimensionamento in modo più dettagliato:

1. Amazon ECS calcola il numero di istanze di container vuote. Un'istanza di container è considerata vuota quando non sono in esecuzione attività daemon.

1. Amazon ECS imposta il valore `CapacityProviderReservation` su un numero compreso tra 0 e 100 che utilizza la seguente formula per rappresentare il rapporto tra la dimensione prevista del gruppo Auto Scaling e la sua dimensione effettiva, espresso in percentuale. Quindi, Amazon ECS pubblica la metrica su. CloudWatch Per maggiori informazioni su come viene calcolato il parametro, consulta [Approfondimento sul dimensionamento automatico del cluster Amazon ECS](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/) 

   ```
   CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
   ```

1. La `CapacityProviderReservation` metrica genera un allarme. CloudWatch Questo allarme aggiorna il valore di `DesiredCapacity` per il gruppo Auto Scaling. Quindi, si verifica una delle seguenti operazioni:
   + Se non utilizzi la cessazione gestita dal provider di capacità, il gruppo con scalabilità automatica seleziona le istanze EC2 utilizzando la policy di cessazione del gruppo con scalabilità automatica e termina le istanze fino a che il numero di istanze EC2 raggiunge la `DesiredCapacity` Viene quindi annullata la registrazione delle istanze di container dal cluster.
   + Se tutte le istanze di container utilizzano la protezione da terminazione gestita, Amazon ECS rimuove la protezione da ridimensionamento sulle istanze di container vuote. Il gruppo Auto Scaling sarà quindi in grado di terminare le istanze EC2. Viene quindi annullata la registrazione delle istanze di container dal cluster.

# Controlla le istanze terminate da Amazon ECS
<a name="managed-termination-protection"></a>

**Importante**  
Devi attivare la *protezione da ridimensionamento dell'istanza* del dimensionamento automatico nel gruppo Auto Scaling per utilizzare la funzionalità di protezione da terminazione gestita del dimensionamento automatico del cluster.

La protezione dalla terminazione gestita consente al dimensionamento automatico del cluster di controllare quali istanze vengono terminate. Quando usi la protezione da terminazione gestita, Amazon ECS termina solo le istanze EC2 che non dispongono di attività Amazon ECS in esecuzione. Le attività eseguite da un servizio che utilizza la strategia di pianificazione `DAEMON` vengono ignorate e un'istanza può essere terminata mediante il dimensionamento automatico del cluster anche quando l'istanza esegue queste attività. Ciò avviene perché tutte le istanze del cluster eseguono queste attività.

Amazon ECS attiva innanzitutto l'opzione di *protezione da dimensionamento dell'istanza* per le istanze EC2 nel gruppo Auto Scaling. Quindi, Amazon ECS inserisce le attività sulle istanze. Quando tutte le attività non daemon vengono interrotte su un'istanza, Amazon ECS avvia il processo di riduzione orizzontale e disattiva la protezione da riduzione orizzontale per l'istanza EC2. Il gruppo Auto Scaling può quindi terminare l'istanza.

La *protezione da ridimensionamento dell'istanza* con dimensionamento automatico controlla quali istanze EC2 possono essere terminate tramite il dimensionamento automatico. Le istanze con la funzione di riduzione orizzontale attivata non possono essere terminate durante il processo di riduzione orizzontale. Per maggiori informazioni sulla protezione da ridimensionamento dell'istanza con dimensionamento automatico, consulta [Utilizzo della protezione da ridimensionamento dell'istanza](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.

Puoi impostare la percentuale `targetCapacity` in modo da avere capacità di riserva. Ciò consente di avviare più rapidamente le attività future, poiché il gruppo Auto Scaling non deve avviare ulteriori istanze. Amazon ECS utilizza il valore della capacità target per gestire la CloudWatch metrica creata dal servizio. Amazon ECS gestisce la CloudWatch metrica. Il gruppo Auto Scaling viene trattato come uno stato stazionario affinché non sia richiesta alcuna operazione di dimensionamento. I valori possono essere compresi tra 0 e 100%. Ad esempio, per configurare Amazon ECS per mantenere una capacità libera del 10% oltre a quella utilizzata dalle attività Amazon ECS, imposta il valore della capacità target al 90%. Quando imposti il valore di `targetCapacity` su un provider di capacità, tieni presenti le considerazioni seguenti.
+ Un valore di `targetCapacity` inferiore al 100% rappresenta la quantità di capacità libera (istanze Amazon EC2) che deve essere presente nel cluster. Capacità libera significa che non ci sono attività in esecuzione.
+ I vincoli di posizionamento come le zone di disponibilità, senza ulteriori `binpack`, costringono Amazon ECS a eseguire infine un'attività per ogni istanza, comportamento che potrebbe non essere quello desiderato.

Devi attivare la protezione da ridimensionamento dell'istanza del dimensionamento automatico nel gruppo Auto Scaling per utilizzare la protezione da terminazione gestita. Se non attivi la protezione da ridimensionamento, l'attivazione della protezione da terminazione gestita può portare a comportamenti indesiderati. Ad esempio, è possibile che le istanze siano bloccate in uno stato di svuotamento. Per ulteriori informazioni, consulta [Utilizzo della protezione con riduzione orizzontale delle istanze](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.

Quando utilizzi la protezione da terminazione con un provider di capacità, non eseguire operazioni manuali, come lo scollegamento dell'istanza, sul gruppo Auto Scaling associato al provider di capacità. Le azioni manuali possono interrompere il processo di ridimensionamento del provider di capacità. Se scolleghi un'istanza dal gruppo Auto Scaling, devi anche [annullare la registrazione dell'istanza scollegata](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deregister_container_instance.html) dal cluster Amazon ECS.

# Aggiornamento della protezione dalla terminazione gestita per i provider di capacità Amazon ECS
<a name="update-managed-termination-protection"></a>

Quando si utilizza la protezione dalla cessazione gestita, è necessario aggiornare l'impostazione per i provider di capacità esistenti.

## Console
<a name="update-managed-termination-protection-console"></a>

1. [Apri la console alla v2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina Cluster, scegli la scheda **Infrastruttura**.

1. Seleziona il provider di capacità.

1. Seleziona **Aggiorna** per modificare le impostazioni del provider di capacità.

1. Nelle **impostazioni del gruppo Auto Scaling**, attiva la **protezione dalla terminazione gestita** per abilitare o disabilitare la funzionalità.

1. Scegliere **Aggiorna**.

## AWS CLI
<a name="update-managed-termination-protection-cli"></a>

Puoi aggiornare l'impostazione di protezione dalla terminazione gestita di un provider di capacità con il comando: `update-capacity-provider`

Per abilitare la protezione dalla terminazione gestita:

```
aws ecs update-capacity-provider \
  --name CapacityProviderName \
  --auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=ENABLED"
```

Per disabilitare la protezione dalla terminazione gestita:

```
aws ecs update-capacity-provider \
  --name CapacityProviderName \
  --auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=DISABLED"
```

**Nota**  
Affinché le modifiche abbiano effetto su tutto il cluster potrebbero essere necessari alcuni minuti. Quando viene abilitata la protezione gestita dalla terminazione, le istanze che stanno già eseguendo attività saranno protette dagli eventi di riduzione orizzontale. Quando viene disabilitata la protezione dalla terminazione gestita, il flag di protezione verrà rimosso dalle istanze durante il ciclo di gestione del provider di capacità ECS successivo.

## Console per l'esecuzione delle attività
<a name="update-managed-termination-protection-console"></a>

1. Apri la console nella [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina del cluster, seleziona la scheda **Attività**.

1. Seleziona l'attività.

1. Nelle **Configurazione**, attiva la **protezione dalla terminazione gestita** per abilitare o disabilitare la funzionalità.

1. Seleziona **Configura la protezione scalabile**.

   Viene visualizzata la finestra di dialogo **Configura protezione scalabile**

   1. In **Protezione scalabile**, seleziona **Attiva**.

   1. Per **Scadenza in minuti**, inserisci il numero di minuti della fine della protezione scalabile.

   1. Scegli **Update (Aggiorna)**.

# Attivazione del Dimensionamento automatico del cluster Amazon ECS
<a name="turn-on-cluster-auto-scaling"></a>

Attiva il dimensionamento automatico dei cluster in modo che Amazon ECS gestisca il dimensionamento delle istanze Amazon EC2 registrate nel tuo cluster.

Se vuoi usare la console per attivare il dimensionamento automatico del cluster, consulta [Creazione di un provider di capacità per Amazon ECS](create-capacity-provider-console-v2.md).

Prima di iniziare, crea un gruppo con scalabilità automatica e un provider di capacità. Per ulteriori informazioni, consulta [Provider di capacità Amazon ECS per carichi di lavoro di Amazon EC2](asg-capacity-providers.md).

Per attivare il dimensionamento automatico del cluster, associa il provider di capacità al cluster, quindi attiva il dimensionamento automatico del cluster.

1. Esegui il comando `put-cluster-capacity-providers` per associare uno o più provider di capacità al cluster. 

   Per aggiungere i fornitori di AWS Fargate capacità, includi `FARGATE` i fornitori di `FARGATE_SPOT` capacità nella richiesta. Per ulteriori informazioni, consulta `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` nella *documentazione di riferimento dei comandi della AWS CLI *.

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers CapacityProviderName FARGATE FARGATE_SPOT \
     --default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
   ```

   Per aggiungere un gruppo Auto Scaling per EC2, includi il nome del gruppo Auto Scaling nella richiesta. Per ulteriori informazioni, consulta `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` nella *documentazione di riferimento dei comandi della AWS CLI *.

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers CapacityProviderName \
     --default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
   ```

1. Utilizza il comando `describe-clusters` per verificare che l'associazione abbia avuto successo. Per ulteriori informazioni, consulta `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` nella *documentazione di riferimento dei comandi della AWS CLI *.

   ```
   aws ecs describe-clusters \
     --cluster ClusterName \
     --include ATTACHMENTS
   ```

1. Esegui il comando `update-capacity-provider` per attivare la scalabilità automatica gestita per il provider di capacità. Per ulteriori informazioni, consulta `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` nella *documentazione di riferimento dei comandi della AWS CLI *.

   ```
   aws ecs update-capacity-provider \
     --name CapacityProviderName \
     --auto-scaling-group-provider "managedScaling={status=ENABLED}"
   ```

# Disattivazione del Dimensionamento automatico del cluster Amazon ECS
<a name="turn-off-cluster-auto-scaling"></a>

Il dimensionamento automatico del cluster viene disattivato quando è necessario un controllo più dettagliato delle istanze EC2 registrate nel cluster,

Per disattivare il dimensionamento automatico del cluster per un cluster, puoi annullare l'associazione del provider di capacità con il dimensionamento gestito attivato dal cluster o aggiornare il provider di capacità per disattivare il dimensionamento gestito.

## Annullare l'associazione del provider di capacità
<a name="disassociate-capacity-provider"></a>

Utilizza la procedura seguente per annullare l'associazione di un provider di capacità con un cluster.

1. Utilizza il comando `put-cluster-capacity-providers` per annullare l'associazione del provider di capacità del gruppo con scalabilità automatica con il cluster. Il cluster può mantenere l'associazione con i fornitori AWS Fargate di capacità. Per ulteriori informazioni, consulta `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` nella *documentazione di riferimento dei comandi della AWS CLI *.

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers FARGATE FARGATE_SPOT \
     --default-capacity-provider-strategy '[]'
   ```

   Utilizza il comando `put-cluster-capacity-providers` per annullare l'associazione del provider di capacità del gruppo con scalabilità automatica con il cluster. Per ulteriori informazioni, consulta `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` nella *documentazione di riferimento dei comandi della AWS CLI *.

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers [] \
     --default-capacity-provider-strategy '[]'
   ```

1. Utilizza il comando `describe-clusters` per verificare che l'annullamento dell'associazione abbia avuto successo. Per ulteriori informazioni, consulta la sezione `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` nella *Documentazione di riferimento della AWS CLI *.

   ```
   aws ecs describe-clusters \
     --cluster ClusterName \
     --include ATTACHMENTS
   ```

## Disattivare la scalabilità gestita per il provider di capacità
<a name="turn-off-managed-scaling"></a>

Utilizza la procedura seguente per disattivare la scalabilità gestita per il provider di capacità.
+ Utilizza il comando `update-capacity-provider` per attivare la scalabilità automatica gestita per il provider di capacità. Per ulteriori informazioni, consulta `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` nella *documentazione di riferimento dei comandi della AWS CLI *.

  ```
  aws ecs update-capacity-provider \
    --name CapacityProviderName \
    --auto-scaling-group-provider "managedScaling={status=DISABLED}"
  ```

# Creazione di un provider di capacità per Amazon ECS
<a name="create-capacity-provider-console-v2"></a>

Al termine della creazione del cluster, sarà possibile creare un nuovo provider di capacità (gruppo Auto Scaling) per EC2. I provider di capacità ti aiutano a gestire e scalare l'infrastruttura per le tue applicazioni.

Prima di creare il provider di capacità, è necessario creare un gruppo con scalabilità automatica. Per ulteriori informazioni, consulta [Gruppi con scalabilità automatica](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.

**Creazione di un provider di capacità per il cluster (console Amazon ECS)**

1. Apri la console nella [https://console.aws.amazon.com/ecs/versione 2](https://console.aws.amazon.com/ecs/v2).

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella *name* pagina **Cluster:**, scegli **Infrastruttura**, quindi scegli **Crea**.

1. Nella pagina **Create capacity providers** (Crea provider di capacità), configura le seguenti opzioni.

   1. In **Basic details** (Dettagli di base), per **Capacity provider name** (Nome provider di capacità), immetti un nome univoco per il provider di capacità.

   1. In **Auto Scaling group** (Gruppo con scalabilità automatica), per **Use an existing Auto Scaling group** (Utilizza un gruppo con scalabilità automatica esistente), scegli il gruppo con scalabilità automatica.

   1. (Facoltativo) Per configurare una policy di scalabilità, in **Scaling policies** (Policy di scalabilità), configura le seguenti opzioni.
      + Per consentire ad Amazon ECS di gestire le operazioni di riduzione e aumento orizzontale, seleziona **Turn on managed scaling** (Attiva scalabilità gestita).
      + Per evitare che l'istanza EC2 con attività Amazon ECS in esecuzione venga terminata, seleziona **Turn on scaling protection** (Attiva la protezione della scalabilità).
      + Per **Set target capacity**, inserisci il valore target per la CloudWatch metrica utilizzata nella policy di scalabilità di tracciamento degli obiettivi gestita da Amazon ECS.

1. Scegli **Create** (Crea).

# Aggiornare un provider di capacità Amazon ECS
<a name="update-capacity-provider-console-v2"></a>

Quando si utilizza un gruppo con scalabilità automatica come provider di capacità, è possibile modificare la policy di scalabilità del gruppo.

**Aggiornamento di un provider di capacità per il cluster (console Amazon ECS)**

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella *name* pagina **Cluster:**, scegli **Infrastruttura**, quindi scegli **Aggiorna**.

1. Nella pagina **Create capacity providers** (Crea provider di capacità), configura le seguenti opzioni.

   1. Nella sezione **Gruppo con scalabilità automatica**, in **Policy di dimensionamento**, configura le seguenti opzioni.
     + Per consentire ad Amazon ECS di gestire le operazioni di riduzione e aumento orizzontale, seleziona **Turn on managed scaling** (Attiva scalabilità gestita).
     + Per evitare che le istanze EC2 con attività Amazon ECS in esecuzione vengano terminate, seleziona **Attiva protezione di dimensionamento**.
     + Per **Set target capacity**, inserisci il valore target per la CloudWatch metrica utilizzata nella policy di scalabilità di tracciamento degli obiettivi gestita da Amazon ECS.

1. Scegliere **Aggiorna**.

# Eliminazione di un provider di capacità Amazon ECS
<a name="delete-capacity-provider-console-v2"></a>

Al termine dell'utilizzo di un provider di capacità del gruppo Auto Scaling, puoi eliminarlo. Una volta eliminato il gruppo, il provider di capacità del gruppo Auto Scaling passa allo stato `INACTIVE`. I provider di capacità con stato `INACTIVE` potrebbero rimanere rilevabili nell'account per un periodo di tempo. Tuttavia, questo comportamento è soggetto a modifiche in futuro, quindi non dovresti fare affidamento sulla persistenza dei provider di capacità `INACTIVE`. Prima di eliminare un provider di capacità del gruppo con scalabilità automatica, il provider di capacità deve essere rimosso dalla strategia del provider di capacità per tutti i servizi. L'API `UpdateService` o il flusso di lavoro del servizio di aggiornamento nella console Amazon ECS possono essere utilizzati per rimuovere un provider di capacità dalla strategia del provider di capacità di un servizio. L'opzione **Forza nuova implementazione** può essere usata per garantire che tutte le attività che utilizzano la capacità dell'istanza Amazon EC2 fornita dal provider di capacità vengano autorizzate a usare la capacità dei provider di capacità rimanenti.

**Per eliminare un provider di capacità per il cluster (console Amazon ECS)**

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster.

1. **Nella *name* pagina **Cluster:**, scegli **Infrastruttura**, il gruppo Auto Scaling, quindi scegli Elimina.**

1. **Nella casella di conferma, inserisci delete *Auto Scaling group name***

1. Scegli **Elimina**.

# Interrompi in modo sicuro i carichi di lavoro Amazon ECS in esecuzione sulle istanze EC2
<a name="managed-instance-draining"></a>

Il drenaggio delle istanze gestite facilita la terminazione graduale delle istanze Amazon EC2. Ciò consente ai carichi di lavoro di interrompersi in sicurezza e di essere riprogrammati su istanze di non terminazione. La manutenzione e gli aggiornamenti dell'infrastruttura vengono eseguiti senza preoccuparsi di interrompere i carichi di lavoro. Usando il drenaggio delle istanze gestite, semplifichi i flussi di lavoro di gestione dell'infrastruttura che richiedono la sostituzione delle istanze Amazon EC2, garantendo al contempo la resilienza e la disponibilità delle tue applicazioni.

Il drenaggio delle istanze gestite da Amazon ECS funziona con le istanze di gruppo Auto Scaling sostitutive. In base all'aggiornamento delle istanze e alla durata massima delle stesse, i clienti possono garantire la conformità con i più recenti requisiti di sistema operativo e sicurezza per la loro capacità.

Il drenaggio delle istanze gestite da Amazon ECS può essere usato solo con i provider di capacità Amazon ECS. Puoi attivare il drenaggio gestito delle istanze quando crei o aggiorni i fornitori di capacità del gruppo Auto Scaling utilizzando la console AWS CLI Amazon ECS o l'SDK.

Gli eventi riportati di seguito sono coperti dal drenaggio delle istanze gestite da Amazon ECS.
+ [Aggiornamento delle istanze di gruppo Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html): usa l'aggiornamento dell'istanza per eseguire la sostituzione graduale delle istanze Amazon EC2 nel gruppo Auto Scaling invece di eseguirla manualmente in batch. Ciò è utile quando è necessario sostituire un numero elevato di istanze, L'aggiornamento dell'istanza viene avviato tramite la console Amazon EC2 o l'API `StartInstanceRefresh`. Assicurati di selezionare `Replace` per ottenere la protezione scalabile quando chiami `StartInstanceRefresh` se usi la protezione dalla terminazione gestita.
+ [Durata massima dell'istanza](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-max-instance-lifetime.html): puoi definire una durata massima quando devi sostituire le istanze del gruppo Auto Scaling. Ciò è utile per pianificare le istanze sostitutive in base a policy di sicurezza interne o alla conformità.
+ Riduzione orizzontale automatica del gruppo Auto Scaling: basato su policy di dimensionamento e azioni di dimensionamento pianificate, il gruppo Auto Scaling supporta il dimensionamento automatico delle istanze. Usando un gruppo Auto Scaling come provider di capacità Amazon ECS, puoi ridurre orizzontalmente le istanze di gruppo Auto Scaling quando non è in esecuzione alcuna attività.
+ [Controlli dell'integrità del gruppo Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html): il gruppo Auto Scaling supporta molti controlli di integrità per gestire la terminazione delle istanze non integre.
+ [CloudFormation aggiornamenti dello stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-direct.html) ‐ Puoi aggiungere un `UpdatePolicy` attributo allo CloudFormation stack per eseguire aggiornamenti continui quando il gruppo cambia.
+ [Ribilanciamento della capacità spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) ‐ Il gruppo Auto Scaling cerca di sostituire in modo proattivo le istanze spot con un rischio di interruzione più elevato sulla base dell'avviso di ribilanciamento della capacità di Amazon EC2. Il gruppo Auto Scaling termina l'istanza precedente quando quella sostitutiva viene avviata e risulta funzionante. Il drenaggio delle istanze gestite da Amazon ECS drena le istanze spot allo stesso modo in cui drena le istanze non spot.
+ [Interruzione spot](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html): le istanze Spot vengono terminate con un preavviso di due minuti. Il drenaggio delle istanze gestite da Amazon ECS mette l'istanza in stato di drenaggio in risposta.

**Hook del ciclo di vita di Amazon EC2 Auto Scaling con drenaggio delle istanze gestite**  
Gli hook del ciclo di vita del gruppo Auto Scaling consentono ai clienti di creare soluzioni che vengono attivate da determinati eventi nel ciclo di vita dell'istanza ed eseguono un'azione personalizzata quando si verifica quel determinato evento. Un gruppo Auto Scaling consente fino a 50 hook. Possono esistere più hook di terminazione che vengono eseguiti in parallelo. Il gruppo Auto Scaling attende il completamento di tutti gli hook prima di terminare un'istanza.

Oltre alla terminazione degli hook gestita da Amazon ECS, è anche possibile configurare hook di terminazione del ciclo di vita personalizzati. Gli hook del ciclo di vita hanno `default action` e suggeriamo di impostare `continue` come impostazione predefinita per garantire che altri hook, come l'hook gestito da Amazon ECS, non siano influenzati da eventuali errori degli hook personalizzati.

Se hai già configurato un hook del ciclo di vita di terminazione del gruppo Auto Scaling e hai anche abilitato il drenaggio delle istanze gestite da Amazon ECS, vengono eseguiti entrambi gli hook del ciclo di vita. Tuttavia, le tempistiche relative non sono garantite. Gli hook del ciclo di vita hanno un'impostazione `default action` per specificare l'azione da intraprendere allo scadere del timeout. In caso di errori, consigliamo di usare `continue` come risultato predefinito nel tuo hook personalizzato. Ciò garantisce che altri hook, in particolare quelli gestiti da Amazon ECS, non siano influenzati da eventuali errori nel tuo hook del ciclo di vita personalizzato. Il risultato alternativo di `abandon` comporta che tutti gli altri hook vengano ignorati, e questo dovrebbe essere evitato. Per ulteriori informazioni sugli hook del ciclo di vita del gruppo Auto Scaling, consulta [Hook del ciclo di vita di Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.

**Drenaggio delle istanze gestite e delle attività**  
Il drenaggio delle istanze gestite da Amazon ECS usa la funzionalità di drenaggio esistente presente nelle istanze di container. La funzionalità di [drenaggio delle istanze di container](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-draining.html) esegue la sostituzione e l'interruzione delle attività di replica che appartengono a un servizio Amazon ECS. Un'attività autonoma, come quella invocata da `RunTask`, che si trova nello stato `PENDING` o `RUNNING`, rimane inalterata. È necessario attendere che queste attività vengano completate o interromperle manualmente. L'istanza di container rimane nello stato `DRAINING` fino a quando tutte le attività non vengono interrotte o non sono trascorse 48 ore. Le attività daemon sono le ultime a essere interrotte dopo che tutte le attività di replica sono state interrotte.

**Drenaggio delle istanze gestite e protezione dalla terminazione gestita**  
Il drenaggio delle istanze gestite funziona anche se la terminazione gestita è disabilitata. Per informazioni sulla protezione da terminazione gestita, consulta [Controlla le istanze terminate da Amazon ECS](managed-termination-protection.md). 

La seguente tabella riassume il comportamento per diverse combinazioni di terminazione gestita e drenaggio gestito.


|  Terminazione gestita  |  Drenaggio gestito  |  Outcome  | 
| --- | --- | --- | 
|  Abilitato  | Abilitato | Amazon ECS protegge le istanze Amazon EC2 che eseguono attività dalla terminazione causata da eventi di riduzione orizzontale. Tutte le istanze in fase di terminazione, ad esempio quelle per cui non è impostata la protezione dalla terminazione, che hanno subito una terminazione spot o sono state forzate dall'aggiornamento dell'istanza, vengono drenate correttamente. | 
|  Disabilitato  | Abilitato | Amazon ECS non protegge le istanze Amazon EC2 che eseguono attività dal dimensionamento. Tuttavia, tutte le istanze che vengono terminate vengono svuotate in modo corretto. | 
|  Abilitato  | Disabilitato | Amazon ECS protegge le istanze Amazon EC2 che eseguono attività dalla terminazione causata da eventi di riduzione orizzontale. Tuttavia, le istanze possono comunque essere terminate da un'interruzione spot o da un aggiornamento forzato dell'istanza, oppure se non stanno eseguendo alcuna attività. Amazon ECS non esegue il drenaggio graduale per queste istanze e avvia attività di servizio sostitutive dopo il loro arresto. | 
|  Disabilitato  | Disabilitato | Le istanze Amazon EC2 possono essere ridotte orizzontalmente o terminate in qualsiasi momento, anche se eseguono attività Amazon ECS. Amazon ECS avvierà attività di servizio sostitutive dopo la loro interruzione. | 

**Drenaggio delle istanze gestite e drenaggio delle istanze spot**  
Con il drenaggio delle istanze spot, è possibile impostare una variabile di ambiente `ECS_ENABLE_SPOT_INSTANCE_DRAINING` sull'agente Amazon ECS che consente ad Amazon ECS di mettere un'istanza in stato di drenaggio in risposta all'interruzione spot di due minuti. Il drenaggio delle istanze gestite da Amazon ECS facilita lo spegnimento graduale delle istanze Amazon EC2 in fase di terminazione per diverse ragioni, non solo per una terminazione spot. Ad esempio, è possibile utilizzare il ribilanciamento della capacità di Amazon EC2 Auto Scaling per sostituire in modo proattivo le istanze spot a elevato rischio di interruzione, mentre il drenaggio delle istanze gestite esegue lo spegnimento graduale delle istanze spot sostituite. Quando si utilizza il drenaggio gestito delle istanze, non è necessario abilitare separatamente il drenaggio delle istanze spot, quindi `ECS_ENABLE_SPOT_INSTANCE_DRAINING` nei dati utente del gruppo Auto Scaling è ridondante. Per ulteriori informazioni sulle istanze spot, consulta [Spot Instances](create-capacity.md#container-instance-spot).

## Come funziona il drenaggio gestito delle istanze con EventBridge
<a name="managed-instance-draining-eventbridge"></a>

Gli eventi di drenaggio delle istanze gestite di Amazon ECS vengono pubblicati su Amazon EventBridge e Amazon ECS crea una regola EventBridge gestita nel bus predefinito del tuo account per supportare il drenaggio gestito delle istanze. Puoi filtrare questi eventi su altri AWS servizi come Lambda, Amazon SNS e Amazon SQS per monitorare e risolvere i problemi.
+ Amazon EC2 Auto Scaling invia un EventBridge evento quando viene richiamato un hook del ciclo di vita.
+ Gli avvisi di interruzione Spot vengono pubblicati su. EventBridge
+ Amazon ECS genera messaggi di errore che puoi recuperare tramite la console Amazon ECS e. APIs
+ EventBridge dispone di meccanismi di riprova integrati per mitigare i guasti temporanei.

# Configurazione dei provider di capacità Amazon ECS per chiudere le istanze in modo sicuro
<a name="enable-managed-instance-draining"></a>

Puoi attivare il drenaggio delle istanze gestite quando crei o aggiorni i provider di capacità del gruppo Auto Scaling usando la console e la AWS CLI Amazon ECS.

**Nota**  
Il drenaggio delle istanze gestite è attivo per impostazione predefinita quando si crea un provider di capacità.

Di seguito sono riportati alcuni esempi di utilizzo di AWS CLI per creare un provider di capacità con il drenaggio gestito delle istanze abilitate e di abilitazione del drenaggio gestito delle istanze per il provider di capacità esistente di un cluster.

**Creare un provider di capacità con il drenaggio delle istanze gestite abilitato**  
Per creare un provider di capacità con lo svuotamento delle istanze gestito abilitato, usa il comando `create-capacity-provider`. Imposta il parametro `managedDraining` su `ENABLED`.

```
aws ecs create-capacity-provider \
--name capacity-provider \
--auto-scaling-group-provider '{
  "autoScalingGroupArn": "asg-arn",
  "managedScaling": {
    "status": "ENABLED",
    "targetCapacity": 100,
    "minimumScalingStepSize": 1,
    "maximumScalingStepSize": 1
  },
  "managedDraining": "ENABLED",
  "managedTerminationProtection": "ENABLED",
}'
```

Risposta:

```
{
    "capacityProvider": {
        "capacityProviderArn": "capacity-provider-arn",
        "name": "capacity-provider",
        "status": "ACTIVE",
        "autoScalingGroupProvider": {
            "autoScalingGroupArn": "asg-arn",
            "managedScaling": {
                "status": "ENABLED",
                "targetCapacity": 100,
                "minimumScalingStepSize": 1,
                "maximumScalingStepSize": 1
            },
            "managedTerminationProtection": "ENABLED"
            "managedDraining": "ENABLED"
        }
    }
}
```

**Abilita il drenaggio delle istanze gestite per il provider di capacità esistente di un cluster**  
Per abilitare il drenaggio delle istanze gestite per il provider di capacità esistente di un cluster, usa il comando `update-capacity-provider`. Come puoi vedere, `managedDraining` indica `DISABLED` e `updateStatus` indica `UPDATE_IN_PROGRESS`.

```
aws ecs update-capacity-provider \
--name cp-draining \
--auto-scaling-group-provider '{
  "managedDraining": "ENABLED"
}
```

Risposta:

```
{
    "capacityProvider": {
        "capacityProviderArn": "cp-draining-arn",
        "name": "cp-draining",
        "status": "ACTIVE",
        "autoScalingGroupProvider": {
            "autoScalingGroupArn": "asg-draining-arn",
            "managedScaling": {
                "status": "ENABLED",
                "targetCapacity": 100,
                "minimumScalingStepSize": 1,
                "maximumScalingStepSize": 1,
                "instanceWarmupPeriod": 300
            },
            "managedTerminationProtection": "DISABLED",
            "managedDraining": "DISABLED" // before update
        },
        "updateStatus": "UPDATE_IN_PROGRESS", // in progress and need describe again to find out the result
        "tags": [
        ]
    }
}
```



Usa il comando `describe-clusters` e includi `ATTACHMENTS`. Lo `status` dell'allegato di drenaggio dell'istanza gestita è `PRECREATED` e lo `attachmentsStatus` generale è `UPDATING`.

```
aws ecs describe-clusters --clusters cluster-name --include ATTACHMENTS
```

Risposta:

```
{
    "clusters": [
        {
            ...

            "capacityProviders": [
                "cp-draining"
            ],
            "defaultCapacityProviderStrategy": [],
            "attachments": [
                # new precreated managed draining attachment
                {
                    "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
                    "type": "managed_draining",
                    "status": "PRECREATED",
                    "details": [
                        {
                            "name": "capacityProviderName",
                            "value": "cp-draining"
                        },
                        {
                            "name": "autoScalingLifecycleHookName",
                            "value": "ecs-managed-draining-termination-hook"
                        }
                    ]
                },

                ...

            ],
            "attachmentsStatus": "UPDATING"
        }
    ],
    "failures": []
}
```

Al termine dell'aggiornamento, utilizza `describe-capacity-providers` e vedrai che `managedDraining` è ora `ENABLED`.

```
aws ecs describe-capacity-providers --capacity-providers cp-draining
```

Risposta:

```
{
    "capacityProviders": [
        {
            "capacityProviderArn": "cp-draining-arn",
            "name": "cp-draining",
            "status": "ACTIVE",
            "autoScalingGroupProvider": {
                "autoScalingGroupArn": "asg-draning-arn",
                "managedScaling": {
                    "status": "ENABLED",
                    "targetCapacity": 100,
                    "minimumScalingStepSize": 1,
                    "maximumScalingStepSize": 1,
                    "instanceWarmupPeriod": 300
                },
                "managedTerminationProtection": "DISABLED",
                "managedDraining": "ENABLED" // successfully update
            },
            "updateStatus": "UPDATE_COMPLETE",
            "tags": []
        }
    ]
}
```

## Risoluzione dei problemi relativi al drenaggio delle istanze gestite da Amazon ECS
<a name="managed-instance-troubleshooting"></a>

Potrebbe capitarti di dover risolvere i problemi relativi al drenaggio delle istanze gestite. Di seguito è riportato un esempio di un problema che potresti incontrare durante l'utilizzo e della relativa risoluzione.

**Le istanze non terminano dopo aver superato la durata massima dell'istanza quando si utilizza il dimensionamento automatico.**  
Se le istanze non vengono terminate neppure dopo aver raggiunto e superato la durata massima prevista durante l'utilizzo di un gruppo Auto Scaling, è possibile che siano protette dalla riduzione orizzontale. È possibile disattivare la terminazione gestita e consentire il drenaggio gestito per gestire il riciclo delle istanze. 

## Comportamento di drenaggio per le istanze gestite da Amazon ECS
<a name="managed-instances-draining-behavior"></a>

La terminazione di Amazon ECS Managed Instances garantisce transizioni agevoli dei carichi di lavoro, ottimizzando al contempo i costi e mantenendo lo stato del sistema. Il sistema di terminazione offre tre percorsi decisionali distinti per la terminazione delle istanze, ciascuno con caratteristiche temporali e profili di impatto sul cliente diversi.

### Percorsi decisionali per la terminazione
<a name="managed-instances-termination-paths"></a>

Terminazione avviata dal cliente  
Consente il controllo diretto sulla rimozione delle istanze quando bisogna rimuovere immediatamente le istanze di container dal servizio. Si richiama l' DeregisterContainerInstance API con il flag force impostato su true, a indicare che è necessaria la terminazione immediata nonostante i carichi di lavoro in esecuzione.

Terminazione dello stato di inattività avviata dal sistema  
Amazon ECS Managed Instances monitora continuamente e ottimizza in modo proattivo i costi chiudendo le istanze di container Amazon ECS inattive che non eseguono alcuna attività. ECS utilizza un ritardo euristico per dare alle istanze di container la possibilità di acquisire attività appena avviate prima di essere terminate. Questo può essere personalizzato con il parametro di configurazione del provider di capacità di `scaleInAfter` Amazon ECS Managed Instances.

Terminazione dell'aggiornamento dell'infrastruttura  
Amazon ECS Managed Instances gestisce e aggiorna automaticamente il software sulle istanze di container gestite per garantire sicurezza e conformità mantenendo al contempo la disponibilità del carico di lavoro. Per ulteriori informazioni, consulta la sezione Applicazione di [patch in Amazon ECS Managed Instances.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html)

### Drenaggio regolare e migrazione del carico di lavoro
<a name="managed-instances-draining-coordination"></a>

Il sistema di drenaggio regolare implementa un sofisticato coordinamento con la gestione dei servizi Amazon ECS per garantire che le attività gestite dal servizio vengano correttamente migrate dalle istanze pianificate per la terminazione.

**Coordinamento del drenaggio delle attività di servizio**  
Quando un'istanza passa allo stato DRAINING, il pianificatore di Amazon ECS interrompe automaticamente l'assegnazione di nuove attività all'istanza, implementando al contempo procedure di spegnimento graduale per le attività di servizio esistenti. Il drenaggio delle attività di servizio include il coordinamento con le strategie di implementazione dei servizi, i requisiti di controllo dell'integrità e le preferenze di drenaggio dell'utente, al fine di garantire tempi di migrazione ottimali e tassi di successo elevati.

**Gestione delle attività autonome**  
Per le attività autonome è necessaria una gestione diversa perché non beneficiano della gestione automatica dei servizi. Il sistema valuta le caratteristiche delle attività autonome, tra cui le stime della durata delle attività, l'analisi della probabilità di completamento e la valutazione dell'impatto sui clienti. La strategia di completamento graduale consente alle attività autonome di completarsi naturalmente durante un periodo di tolleranza prolungato, mentre la terminazione forzata garantisce che l'aggiornamento dell'infrastruttura avvenga entro tempi accettabili quando le attività non sono state completate naturalmente.

### Strategia di completamento in due fasi
<a name="managed-instances-two-phase-completion"></a>

Il sistema di terminazione implementa un approccio in due fasi che bilancia la continuità del carico di lavoro e i requisiti di gestione dell'infrastruttura.

**Fase 1: periodo di completamento graduale**  
Durante questa fase, il sistema implementa strategie di drenaggio graduale che danno priorità alla continuità del carico di lavoro. Le attività di servizio subiscono un drenaggio graduale attraverso le normali attività di pianificazione di Amazon ECS, le attività autonome continuano ad essere eseguite e possono essere completate naturalmente, mentre il sistema monitora tutte le attività affinché raggiungano lo stato di arresto attraverso attività di completamento naturali.

**Fase 2: applicazione di scadenze rigide**  
Quando il completamento graduale non consente di raggiungere gli obiettivi di terminazione entro tempi accettabili, il sistema applica una scadenza rigida. Solitamente, la scadenza rigida è fissata al momento dell'avvio del drenaggio più sette giorni, in modo da garantire un tempo sufficiente per il completamento dell'operazione nel rispetto dei requisiti operativi. L'applicazione prevede l'invocazione automatica delle procedure di annullamento forzato della registrazione e l'immediata terminazione di tutte le attività rimanenti, indipendentemente dal loro stato di completamento.

# Creazione di risorse per la scalabilità automatica del cluster Amazon ECS utilizzando Console di gestione AWS
<a name="tutorial-cluster-auto-scaling-console"></a>

Scopri come creare le risorse per il dimensionamento automatico dei cluster usando la Console di gestione AWS. Se le risorse richiedono un nome, viene utilizzato il prefisso `ConsoleTutorial` per assicurare che tutti i nomi siano univoci e facili da individuare.

**Topics**
+ [

## Prerequisiti
](#console-tutorial-prereqs)
+ [

## Fase 1: Creazione di un cluster Amazon ECS
](#console-tutorial-cluster)
+ [

## Fase 2: Registrazione di una definizione di attività
](#console-tutorial-register-task-definition)
+ [

## Fase 3: esecuzione di un'attività
](#console-tutorial-run-task)
+ [

## Fase 4: verifica
](#console-tutorial-verify)
+ [

## Fase 5: rimozione
](#console-tutorial-cleanup)

## Prerequisiti
<a name="console-tutorial-prereqs"></a>

Questo tutorial presuppone che siano stati soddisfatti i prerequisiti seguenti:
+ Hai completato le fasi descritte in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md).
+ L'utente IAM ha le autorizzazioni necessarie specificate nell'esempio di policy IAM [AmazonECS\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess).
+ Viene creato il ruolo IAM dell'istanza di container Amazon ECS. Per ulteriori informazioni, consulta [Ruolo IAM delle istanze di container Amazon ECS](instance_IAM_role.md).
+ Viene creato il ruolo IAM collegato ai servizi Amazon ECS. Per ulteriori informazioni, consulta [Uso di ruoli collegati ai servizi per Amazon ECS](using-service-linked-roles.md).
+ Viene creato il ruolo IAM collegato al servizio Auto Scaling. Per ulteriori informazioni, consulta [Ruoli collegati ai servizi per Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.
+ Sono disponibili un VPC e un gruppo di sicurezza creati per l'uso. Per ulteriori informazioni, consulta [Crea un cloud privato virtuale](get-set-up-for-amazon-ecs.md#create-a-vpc).

## Fase 1: Creazione di un cluster Amazon ECS
<a name="console-tutorial-cluster"></a>

Utilizza la procedura seguente per creare un cluster Amazon ECS. 

Amazon ECS crea un modello di lancio di Amazon EC2 Auto Scaling e un gruppo Auto Scaling per tuo conto come parte dello stack. CloudFormation 

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nel riquadro di navigazione scegli **Cluster**, quindi **Crea cluster**.

1. In **Configurazione del cluster**, per **Nome cluster**, inserisci `ConsoleTutorial-cluster`.

1. **In **Infrastruttura**, AWS deseleziona Fargate (serverless), quindi seleziona Istanze Amazon EC2.** Successivamente, configura il gruppo con scalabilità automatica che funge da provider di capacità.

   1. In **Gruppo Auto Scaling (ASG)**. Seleziona **Crea nuovo ASG**, quindi fornisci i seguenti dettagli relativi al gruppo:
     + Per **Sistema operativo/architettura**, seleziona **Amazon Linux 2**.
     + Per **Tipo di istanza EC2**, seleziona **t3.nano**.
     + In **Capacity** (Capacità), inserisci il numero minimo e massimo di istanze da avviare nel gruppo Auto Scaling. 

1. (Facoltativo) Per gestire i tag cluster, espandi **Tags** (Tag), quindi esegui una delle seguenti operazioni:

   [Aggiungere un tag] Scegliere **Add tag (Aggiungi tag)** e procedere come segue:
   + In **Chiave**, immetti il nome della chiave.
   + In **Valore**, immetti il valore della chiave.

   [Rimuovi un tag] Scegli **Rimuovi** a destra della Chiave e del Valore del tag.

1. Scegli **Create** (Crea).

## Fase 2: Registrazione di una definizione di attività
<a name="console-tutorial-register-task-definition"></a>

Prima di eseguire un'attività nel cluster, devi registrare una definizione di attività. Le definizioni di attività sono elenchi di container raggruppati. L'esempio seguente illustra una semplice definizione di attività che utilizza un'immagine `amazonlinux` da Docker Hub ed è in sospensione. Per ulteriori informazioni sui parametri disponibili per la definizione di attività, consulta [Definizioni dei processi di Amazon ECS](task_definitions.md).

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nel pannello di navigazione, scegli **Task Definitions** (Definizioni di processo).

1. Scegli **Create new task definition** (Crea nuova definizione di attività), **Create new task definition with JSON** (Crea nuova definizione di attività con JSON).

1. Nella casella **Editor JSON**, incolla i seguenti contenuti.

   ```
   {
       "family": "ConsoleTutorial-taskdef",
       "containerDefinitions": [
           {
               "name": "sleep",
               "image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
               "memory": 20,
               "essential": true,
               "command": [
                   "sh",
                   "-c",
                   "sleep infinity"
               ]
           }
       ],
       "requiresCompatibilities": [
           "EC2"
       ]
   }
   ```

1. Scegli **Create** (Crea).

## Fase 3: esecuzione di un'attività
<a name="console-tutorial-run-task"></a>

Dopo aver registrato una definizione di attività per l'account, puoi eseguire un'attività nel cluster. Per questo tutorial, esegui cinque istanze della definizione di attività `ConsoleTutorial-taskdef` nel cluster `ConsoleTutorial-cluster`.

1. Apri la console nella [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. **Nella pagina **Clusters**, scegli ConsoleTutorial -cluster.**

1. In **Attività**, scegli **Esegui nuova attività**.

1. Nella sezione **Ambiente**, in **Opzioni di calcolo**, scegli **Strategia del provider di capacità**.

1. In **Configurazione dell'implementazione**, per **Tipo di applicazione**, scegli **Attività**.

1.  **Scegli **ConsoleTutorial-taskdef** dall'elenco a discesa Family.**

1. In **Attività desiderate**, digita 5.

1. Scegli **Create** (Crea).

## Fase 4: verifica
<a name="console-tutorial-verify"></a>

A questo punto del tutorial dovresti disporre di un cluster con cinque attività in esecuzione e un gruppo Auto Scaling con un provider di capacità. Il provider di capacità ha il dimensionamento gestito di Amazon ECS abilitato.

Possiamo verificare che tutto funzioni correttamente visualizzando le CloudWatch metriche, le impostazioni del gruppo Auto Scaling e infine il conteggio delle attività del cluster Amazon ECS.

**Per visualizzare le CloudWatch metriche per il tuo cluster**

1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. Nella barra di navigazione nella parte superiore della schermata selezionare la regione .

1. Nel pannello di navigazione, in **Parametri**, scegli **Tutti i parametri**.

1. Nella pagina **Tutti i parametri**, all'interno della scheda **Sfoglia**, scegli `AWS/ECS/ManagedScaling`.

1. Scegli **CapacityProviderName, ClusterName**.

1. Seleziona la casella di controllo corrispondente a `ConsoleTutorial-cluster` ** ClusterName**.

1. Nella scheda **Parametri definiti**, modifica **Periodo** in **30 secondi** e **Statistica** in **Massimo**.

   Il valore visualizzato nel grafico mostra il valore di capacità target per il provider di capacità. Inizia da `100`, la percentuale di capacità target impostata. Osservare l'incremento fino a `200`, che attiva un allarme per la policy di dimensionamento del monitoraggio dei target. L'allarme attiverà il dimensionamento orizzontale del gruppo Auto Scaling.

Utilizza la procedura seguente per visualizzare i dettagli del gruppo Auto Scaling per verificare che l'operazione di dimensionamento orizzontale sia stata eseguita.

**Come verificare il gruppo Auto Scaling dimensionato orizzontalmente**

1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Nella barra di navigazione nella parte superiore della schermata selezionare la regione .

1. Nel pannello di navigazione, nella sezione **Dimensionamento automatico**, seleziona **Gruppi con dimensionamento automatico**.

1. Scegli il gruppo Auto Scaling `ConsoleTutorial-cluster` creato in questo tutorial. Visualizza il valore in **Capacità desiderata** e visualizza le istanze nella scheda **Gestione delle istanze** per confermare che il gruppo è stato dimensionato a due istanze.

Utilizza la procedura seguente per visualizzare il cluster Amazon ECS per verificare che le istanze Amazon EC2 siano state registrate con il cluster e che i processi siano passati allo stato `RUNNING`.

**Per verificare le istanze nel gruppo Auto Scaling**

1. Apri la console nella [https://console.aws.amazon.com/ecs/versione 2](https://console.aws.amazon.com/ecs/v2).

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina **Clusters** (Cluster), scegli il cluster `ConsoleTutorial-cluster`.

1. Nella scheda **Attività** verifica che siano visualizzate cinque attività nello stato `RUNNING`.

## Fase 5: rimozione
<a name="console-tutorial-cleanup"></a>

Una volta terminato questo tutorial, rimuovi le risorse associate per evitare costi aggiuntivi per risorse che non utilizzi. L'eliminazione dei provider di capacità e delle definizioni di attività non è supportata, ma non sono associati costi a queste risorse.

**Per eliminare le risorse del tutorial**

1. Apri la console nella [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nel pannello di navigazione scegliere **Cluster**.

1. **Nella pagina **Clusters**, scegli ConsoleTutorial -cluster.**

1. **Nella pagina **ConsoleTutorial-cluster**, scegli la scheda **Attività**, quindi scegli **Stop, Arresta tutto**.**

1. Nel pannello di navigazione scegliere **Cluster**.

1. **Nella pagina **Clusters**, scegli ConsoleTutorial -cluster.**

1. In alto a destra della pagina, scegli **Elimina cluster**. 

1. **Nella casella di conferma, inserisci **delete **ConsoleTutorial-cluster**** e scegli Elimina.**

1. Elimina i gruppi Auto Scaling completando la seguente procedura.

   1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Nella barra di navigazione nella parte superiore della schermata selezionare la regione .

   1. Nel pannello di navigazione, nella sezione **Dimensionamento automatico**, seleziona **Gruppi con dimensionamento automatico**.

   1. Seleziona il gruppo Auto Scaling `ConsoleTutorial-cluster`, quindi scegli **Operazioni**.

   1.  Nel menu **Actions (Operazioni)** selezionare **Delete (Elimina)**. Nella casella di conferma, immetti **elimina** e scegli **Elimina**.

# Istanze di container Amazon EC2 per Amazon ECS
<a name="create-capacity"></a>

Un'istanza di container di Amazon ECS è un'istanza Amazon EC2 che esegue l'agente del container di Amazon ECS ed è registrata in un cluster. Quando esegui attività con Amazon ECS utilizzando il provider di capacità, un provider di capacità esterno o un provider di capacità del gruppo Auto Scaling, le attività vengono posizionate sulle istanze di container attive. Sei responsabile della gestione e della manutenzione delle istanze di container.

Sebbene tu possa creare la tua AMI di istanza Amazon EC2 che soddisfi le specifiche di base necessarie per eseguire i carichi di lavoro containerizzati su Amazon ECS, le AMI ottimizzate per Amazon ECS AMIs sono preconfigurate e testate su Amazon ECS dai tecnici. AWS È il modo più semplice per iniziare ed eseguire i container su AWS rapidamente.

Quando crei un cluster usando la console, Amazon ECS crea un modello di avvio per le tue istanze con l'ultima AMI associata al sistema operativo selezionato. 

Quando si utilizza CloudFormation per creare un cluster, il parametro SSM fa parte del modello di avvio di Amazon EC2 per le istanze del gruppo Auto Scaling. Puoi configurare il modello in modo da usare un parametro dinamico di Systems Manager per determinare quale AMI Amazon ECS Optimized implementare. Questo parametro garantisce che, ogni volta che implementi lo stack, venga verificata la disponibilità di aggiornamenti da applicare alle istanze EC2. Per un esempio di come usare il parametro Systems Manager, consulta [Creare un cluster Amazon ECS con l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) nella *Guida per l'utente AWS CloudFormation *.
+ [Recupero dei metadati dell'AMI Linux ottimizzata per Amazon ECS](retrieve-ecs-optimized_AMI.md)
+ [Recupero dei metadati dell'AMI Bottlerocket ottimizzata per Amazon ECS](ecs-bottlerocket-retrieve-ami.md)
+ [Recupero dei metadati dell'AMI Windows ottimizzata per Amazon ECS](retrieve-ecs-optimized_windows_AMI.md)

Puoi scegliere tra i tipi di istanza compatibili con la tua applicazione. Con istanze più grandi, puoi avviare più attività contemporaneamente. Le istanze più piccole ti consentono di impiegare l'aumento orizzontale in modo più dettagliato per ridurre i costi. Non è necessario scegliere un unico tipo di istanza Amazon EC2 che si adatti a tutte le applicazioni del cluster. Puoi creare più gruppi Auto Scaling in cui ogni gruppo ha un tipo di istanza diverso. Quindi, puoi creare un provider di capacità Amazon EC2 per ognuno di questi gruppi.

Usa le seguenti linee guida per determinare i tipi di famiglia di istanza e il tipo di istanza da utilizzare:
+ Elimina i tipi di istanza o le famiglie di istanze che non soddisfano i requisiti specifici della tua applicazione. Ad esempio, se l'applicazione richiede una GPU, puoi escludere tutti i tipi di istanza che non dispongono di una GPU.
+ Considera i requisiti, tra cui lo storage e il throughput di rete
+ Prendi in considerazione la CPU e la memoria. Come regola generale, la CPU e la memoria devono essere sufficientemente grandi da contenere almeno una replica dell'attività che si desidera eseguire. 

## Spot Instances
<a name="container-instance-spot"></a>

La capacità spot può offrire risparmi significativi sui costi rispetto alle istanze on demand. La capacità spot è una capacità in eccesso a un prezzo notevolmente inferiore rispetto a quella on demand o riservata. La capacità spot è adatta per carichi di lavoro di elaborazione in batch e machine learning ambienti di sviluppo e staging. Più in generale, è adatto a qualsiasi carico di lavoro che tollera tempi di inattività temporanei. 

Tieni presente le seguenti conseguenze, poiché la capacità spot potrebbe non essere sempre disponibile.
+ Nei periodi con domanda estremamente elevata, la capacità spot potrebbe non essere disponibile. Ciò può causare ritardi nell'avvio delle istanze spot di Amazon EC2. In questi eventi, i servizi Amazon ECS riprovano ad avviare le attività e anche i gruppi con Amazon EC2 Auto Scaling riprovano ad avviare le istanze, finché la capacità richiesta non diventa disponibile. Amazon EC2 non sostituisce la capacità spot con quella on demand. 
+ Quando la domanda complessiva di capacità aumenta, le istanze e le attività spot potrebbero essere terminate con un preavviso di soli due minuti. Dopo l'invio dell'avviso, le attività dovrebbero iniziare a chiudersi regolarmente, se necessario, prima che l'istanza venga terminata completamente. Questo aiuta a ridurre al minimo la possibilità di errori. Per ulteriori informazioni su un arresto corretto, consulta [Arresto regolare con ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/).

Per ridurre al minimo le carenze di capacità spot, considera i seguenti consigli: 
+ Utilizza più regioni e zone di disponibilità: la capacità spot varia in base alla regione e alla zona di disponibilità. Puoi migliorare la disponibilità spot eseguendo i carichi di lavoro in più regioni e zone di disponibilità. Se possibile, specifica le sottoreti in tutte le zone di disponibilità nelle regioni in cui esegui le attività e le istanze. 
+ Utilizza più tipi di istanze Amazon EC2: quando utilizzi policy a istanze miste con Amazon EC2 Auto Scaling, nel tuo gruppo Auto Scaling vengono avviati più tipi di istanze. Ciò garantisce che una richiesta di capacità spot possa essere soddisfatta quando necessario. Per massimizzare l'affidabilità e ridurre al minimo la complessità, nella tua policy sulle istanze miste utilizza tipi di istanze con all'incirca la stessa quantità di CPU e memoria. Queste istanze possono appartenere a una generazione diversa o varianti dello stesso tipo di istanza di base. Tieni presente che potrebbero essere dotate di funzionalità aggiuntive di cui non hai bisogno. Un esempio di tale elenco potrebbe includere m4.large, m5.large, m5a.large, m5d.large, m5n.large, m5dn.large e m5ad.large. Per ulteriori informazioni, consulta [Gruppi Auto Scaling con più tipi di istanze e opzioni di acquisto](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) nella *Guida per l’utente di Amazon EC2 Auto Scaling.*
+ Utilizza la strategia di allocazione spot ottimizzata per la capacità: con Amazon EC2 Spot, puoi scegliere tra strategie di allocazione ottimizzate in termini di capacità e costi. Se scegli la strategia ottimizzata per la capacità al momento dell'avvio di una nuova istanza, Amazon EC2 Spot seleziona il tipo di istanza con la massima disponibilità nella zona di disponibilità selezionata. Ciò aiuta a ridurre la possibilità che l'istanza venga terminata subito dopo l'avvio. 

Per informazioni su come configurare gli avvisi di terminazione spot sulle tue istanze di container, consulta:
+ [Configurazione delle istanze di container Amazon ECS Linux per ricevere avvisi sulle istanze spot](spot-instance-draining-linux-container.md)
+ [Configurazione delle istanze di container Amazon ECS Windows per ricevere avvisi sulle istanze spot](windows-spot-instance-draining-container.md)

# Linux ottimizzato per Amazon ECS AMIs
<a name="ecs-optimized_AMI"></a>

**Importante**  
[L'AMI Amazon Linux 2 ottimizzata per Amazon ECS arriva il 30 end-of-life giugno 2026, rispecchiando la stessa data EOL del sistema operativo Amazon Linux 2 upstream (per ulteriori informazioni, consulta Amazon Linux 2). FAQs](https://aws.amazon.com/amazon-linux-2/faqs/) Invitiamo i clienti ad aggiornare le loro applicazioni per usare Amazon Linux 2023, con supporto a lungo termine incluso fino al 2028. Per informazioni sulla migrazione da Amazon Linux 2 ad Amazon Linux 2023, consulta [Migrazione dall'AMI ottimizzata per Amazon ECS di Amazon Linux 2 all'AMI ottimizzata per Amazon ECS di Amazon Linux 2023](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html).

Per impostazione predefinita, la data di obsolescenza di tutte le AMI ottimizzate per Amazon ECS è impostata su due anni dopo la data di creazione dell'AMI. Puoi utilizzare l'`DescribeImages`API Amazon EC2 per verificare lo stato di obsolescenza e la data di un AMI. Per ulteriori informazioni, consulta [DescribeImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html)*Amazon Elastic Compute Cloud API Reference.*

Amazon ECS offre le AMI ottimizzate per Amazon ECS che sono preconfigurate con requisiti e suggerimenti per l'esecuzione dei tuoi container di carichi di lavoro. Consigliamo di usare l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS per le istanze Amazon EC2. L'avvio delle istanze di container dall'AMI ottimizzata per Amazon ECS più recente ti assicura di ricevere gli aggiornamenti di sicurezza e la versione dell'agente del container corrente. Per ulteriori informazioni sull'avvio di un'istanza, consulta [Avvio di un'istanza di container Linux di Amazon ECS](launch_container_instance.md).

Quando crei un cluster usando la console, Amazon ECS crea un modello di avvio per le tue istanze con l'ultima AMI associata al sistema operativo selezionato. 

Quando si utilizza CloudFormation per creare un cluster, il parametro SSM fa parte del modello di avvio di Amazon EC2 per le istanze del gruppo Auto Scaling. Puoi configurare il modello in modo da usare un parametro dinamico di Systems Manager per determinare quale AMI Amazon ECS Optimized implementare. Questo parametro garantisce che, ogni volta che implementi lo stack, venga verificata la disponibilità di aggiornamenti da applicare alle istanze EC2. Per un esempio di come usare il parametro Systems Manager, consulta [Creare un cluster Amazon ECS con l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) nella *Guida per l'utente AWS CloudFormation *.

Se devi personalizzare l'AMI ottimizzata per Amazon ECS, consulta [Amazon ECS Optimized AMI Build Recipes](https://github.com/aws/amazon-ecs-ami) su. GitHub

Le seguenti varianti dell'AMI ottimizzata per Amazon ECS sono disponibili per le istanze Amazon EC2 con il sistema operativo Amazon Linux 2023.


| Sistema operativo | AMI | Description | Configurazione di archiviazione | 
| --- | --- | --- | --- | 
| Amazon Linux 2023 |  AMI Amazon Linux 2023 ottimizzata per Amazon ECS |  Amazon Linux 2023 è la nuova generazione di Amazon Linux di AWS. Nella maggior parte dei casi, è consigliata per l'avvio delle istanze Amazon EC2 per i carichi di lavoro Amazon ECS. Per ulteriori informazioni, consulta la sezione [Che cos'è Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html) nella *Guida per l'utente di Amazon Linux 2023*.  | Di default, l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS è fornita con un singolo volume root di 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 
| Amazon Linux 2023 (arm64) |  AMI Amazon Linux 2023 (arm64) ottimizzata per Amazon ECS |  Basata su Amazon Linux 2023, questa AMI è consigliata per l'avvio di istanze Amazon EC2, alimentate da processori 2/Graviton 3/Graviton 4 AWS Graviton/Graviton basati su ARM, per i carichi di lavoro Amazon ECS. Per ulteriori informazioni, consulta [Specifications for the Amazon EC2 general purpose instances](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html) nella guida *Tipi di istanze Amazon EC2*.  | Di default, l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS è fornita con un singolo volume root di 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 
| Amazon Linux 2023 (Neuron) |  AMI Amazon Linux 2023 ottimizzata per Amazon ECS  |  Quest'AMI basata su Amazon Linux 2023 deve essere utilizzata per le istanze Amazon EC2 Inf1, Trn1 o Inf2. Viene preconfigurato con i driver AWS Inferentia e AWS Trainium e il runtime AWS Neuron per Docker, che semplifica l'esecuzione di carichi di lavoro di inferenza di machine learning su Amazon ECS. Per ulteriori informazioni, consulta [Definizioni delle attività di Amazon ECS per i carichi di lavoro di machine learning di AWS Neuron](ecs-inference.md).  L'AMI Amazon Linux 2023 (Neuron) ottimizzata per Amazon ECS non viene fornita con la AWS CLI preinstallata.  | Di default, l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS è fornita con un singolo volume root di 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 
| GPU Amazon Linux 2023 | AMI GPU Amazon Linux 2023 ottimizzata per Amazon ECS |  Basata su Amazon Linux 2023, questa AMI è consigliata per l'avvio di istanze basate su GPU Amazon EC2 per i carichi di lavoro Amazon ECS. È preconfigurato con i driver del kernel NVIDIA e un runtime GPU Docker che consente l'esecuzione di carichi di lavoro che sfruttano su Amazon ECS. GPUs Per ulteriori informazioni, consulta [Definizioni di attività Amazon ECS per carichi di lavoro GPU](ecs-gpu.md).  | Di default, l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS è fornita con un singolo volume root di 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 

Le seguenti varianti dell'AMI ottimizzata per Amazon ECS sono disponibili per le istanze Amazon EC2 con il sistema operativo Amazon Linux 2.


| Sistema operativo | AMI | Description | Configurazione di archiviazione | 
| --- | --- | --- | --- | 
|  **Amazon Linux 2**   |  AMI Amazon Linux 2 kernel 5.10 ottimizzata per Amazon ECS | Quest'AMI basata su Amazon Linux 2 deve essere utilizzata quando si avviano istanze Amazon EC2 e si desidera utilizzare Linux kernel 5.10 anziché kernel 4.14 per i carichi di lavoro Amazon ECS. L'AMI Amazon Linux 2 kernel 5.10 ottimizzata per Amazon ECS non viene fornita con la AWS CLI preinstallata. | Per impostazione predefinita, l'AMI Amazon ECS ottimizzata per Amazon Linux 2 (AMI AMIs Amazon Linux 2 ottimizzata per Amazon ECS, AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS e AMI ottimizzata per GPU Amazon ECS) viene fornita con un singolo volume root da 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 
|  **Amazon Linux 2**  |  AMI Amazon Linux 2 ottimizzata per Amazon ECS | Questo è per i tuoi carichi di lavoro Amazon ECS. L'AMI Amazon Linux 2 ottimizzata per Amazon ECS non viene fornita con AWS CLI preinstallato. | Per impostazione predefinita, l'AMI Amazon ECS ottimizzata per Amazon Linux 2 (AMI AMIs Amazon Linux 2 ottimizzata per Amazon ECS, AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS e AMI ottimizzata per GPU Amazon ECS) viene fornita con un singolo volume root da 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 
|  **Amazon Linux 2 (arm64)**  |  AMI Amazon Linux 2 (arm64) kernel 5.10 ottimizzata per Amazon ECS |  Basata su Amazon Linux 2, questa AMI è per le tue istanze Amazon EC2, che sono alimentate da AWS Graviton/Graviton 2/Graviton 3/Graviton 4 processori basati su ARM, e desideri utilizzare il kernel Linux 5.10 anziché il kernel Linux 4.14 per i tuoi carichi di lavoro Amazon ECS. Per ulteriori informazioni, consulta [Specifications for the Amazon EC2 general purpose instances](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html) nella guida *Tipi di istanze Amazon EC2*. L'AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS non viene fornita con quella preinstallata. AWS CLI   | Per impostazione predefinita, l'AMI Amazon ECS ottimizzata per Amazon Linux 2 (AMI AMIs Amazon Linux 2 ottimizzata per Amazon ECS, AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS e AMI ottimizzata per GPU Amazon ECS) viene fornita con un singolo volume root da 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 
| Amazon Linux 2 (arm64) | AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS |  Basata su Amazon Linux 2, questa AMI è destinata all'avvio di istanze Amazon EC2, alimentate da 4 processori AWS Graviton/Graviton 2/Graviton 3/Graviton basati su ARM, per i carichi di lavoro Amazon ECS. L'AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS non viene fornita con quella preinstallata. AWS CLI   | Per impostazione predefinita, l'AMI Amazon ECS ottimizzata per Amazon Linux 2 (AMI AMIs Amazon Linux 2 ottimizzata per Amazon ECS, AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS e AMI ottimizzata per GPU Amazon ECS) viene fornita con un singolo volume root da 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 
|  **Amazon Linux 2 (GPU)**  | AMI Amazon ECS con kernel 5.10 ottimizzato per GPU | L'uso di questa AMI basata su Amazon Linux 2 è consigliato quando si avviano istanze Amazon EC2 basate su GPU con kernel Linux 5.10 per i carichi di lavoro Amazon ECS. È preconfigurato con i driver del kernel NVIDIA e un runtime GPU Docker che consente l'esecuzione di carichi di lavoro che sfruttano su Amazon ECS. GPUs Per ulteriori informazioni, consulta [Definizioni di attività Amazon ECS per carichi di lavoro GPU](ecs-gpu.md). | Per impostazione predefinita, l'AMI Amazon ECS ottimizzata per Amazon Linux 2 (AMI AMIs Amazon Linux 2 ottimizzata per Amazon ECS, AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS e AMI ottimizzata per GPU Amazon ECS) viene fornita con un singolo volume root da 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 
| Amazon Linux 2 (GPU) | AMI Amazon ECS ottimizzata per GPU | L'uso di questa AMI basata su Amazon Linux 2 è consigliato quando si avviano istanze Amazon EC2 basate su GPU con kernel Linux 4.14 per i carichi di lavoro Amazon ECS. È preconfigurato con i driver del kernel NVIDIA e un runtime GPU Docker che consente l'esecuzione di carichi di lavoro che sfruttano su Amazon ECS. GPUs Per ulteriori informazioni, consulta [Definizioni di attività Amazon ECS per carichi di lavoro GPU](ecs-gpu.md). | Per impostazione predefinita, l'AMI Amazon ECS ottimizzata per Amazon Linux 2 (AMI AMIs Amazon Linux 2 ottimizzata per Amazon ECS, AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS e AMI ottimizzata per GPU Amazon ECS) viene fornita con un singolo volume root da 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 
| Amazon Linux 2 (Neuron)  | AMI Amazon Linux 2 (Neuron) kernel 5.10 ottimizzata per Amazon ECS  | Quest'AMI basata su Amazon Linux 2 deve essere utilizzata per le istanze Amazon EC2 Inf1, Trn1 o Inf2. Viene preconfigurato con AWS Inferentia con kernel Linux 5.10 e driver AWS Trainium e il runtime AWS Neuron per Docker, che semplifica l'esecuzione di carichi di lavoro di inferenza di machine learning su Amazon ECS. Per ulteriori informazioni, consulta [Definizioni delle attività di Amazon ECS per i carichi di lavoro di machine learning di AWS Neuron](ecs-inference.md). L'AMI Amazon Linux 2 (Neuron) ottimizzata per Amazon ECS non viene fornita con quella preinstallata. AWS CLI  | Per impostazione predefinita, l'AMI Amazon ECS ottimizzata per Amazon Linux 2 (AMI AMIs Amazon Linux 2 ottimizzata per Amazon ECS, AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS e AMI ottimizzata per GPU Amazon ECS) viene fornita con un singolo volume root da 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 
| Amazon Linux 2 (Neuron)  | AMI Amazon Linux 2 (Neuron) ottimizzata per Amazon ECS | Quest'AMI basata su Amazon Linux 2 deve essere utilizzata per le istanze Amazon EC2 Inf1, Trn1 o Inf2. Viene preconfigurato con i driver AWS Inferentia e AWS Trainium e il runtime AWS Neuron per Docker, che semplifica l'esecuzione di carichi di lavoro di inferenza di machine learning su Amazon ECS. Per ulteriori informazioni, consulta [Definizioni delle attività di Amazon ECS per i carichi di lavoro di machine learning di AWS Neuron](ecs-inference.md). L'AMI Amazon Linux 2 (Neuron) ottimizzata per Amazon ECS non viene fornita con quella preinstallata. AWS CLI  | Per impostazione predefinita, l'AMI Amazon ECS ottimizzata per Amazon Linux 2 (AMI AMIs Amazon Linux 2 ottimizzata per Amazon ECS, AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS e AMI ottimizzata per GPU Amazon ECS) viene fornita con un singolo volume root da 30 GiB. Puoi modificare le dimensioni del volume root di 30 GiB al momento dell'avvio per aumentare lo storage disponibile nell'istanza di container. Questo storage è utilizzato per il sistema operativo e per le immagini Docker e i metadati. Il file system di default per l'AMI Amazon Linux 2 ottimizzata per Amazon ECS è `xfs` e Docker utilizza il driver di archiviazione `overlay2`. Per ulteriori informazioni, consulta [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) nella documentazione Docker. | 

Amazon ECS fornisce un changelog per la variante Linux dell'AMI ottimizzata per Amazon ECS su. GitHub Per ulteriori informazioni, consulta [Changelog](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md).

Le varianti Linux dell'AMI ottimizzata per Amazon ECS utilizzano l'AMI Amazon Linux 2 o Amazon Linux 2023 come base. È possibile recuperare il nome AMI per ciascuna variante interrogando l'API Archivio dei parametri Systems Manager. Per ulteriori informazioni, consulta [Recupero dei metadati dell'AMI Linux ottimizzata per Amazon ECS](retrieve-ecs-optimized_AMI.md). Sono disponibili anche le note di rilascio di AMI di Amazon Linux 2. Per ulteriori informazioni, consulta [Note di rilascio di Amazon Linux 2](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html). Sono disponibili anche le note di rilascio di Amazon Linux 2023. Per ulteriori informazioni, consulta [Note di rilascio di Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes.html).

Nelle pagine seguenti vengono fornite ulteriori informazioni sulle modifiche:
+ Note di [rilascio di Source AMI](https://github.com/aws/amazon-ecs-ami/releases) su GitHub
+ [Note di rilascio di Docker Engine](https://docs.docker.com/engine/release-notes/) nella documentazione Docker
+ [Documentazione dei driver NVIDIA](https://docs.nvidia.com/datacenter/tesla/index.html) nella documentazione NVIDIA
+ Registro delle [modifiche dell'agente Amazon ECS attivo](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md) GitHub

  Il codice sorgente dell'applicazione `ecs-init`, gli script e la configurazione per il pacchetto dell'agente fanno ora parte del repository dell'agente. Per le versioni `ecs-init` e i pacchetti precedenti di Amazon ecs-init, consulta il changelog di [Amazon ecs-init](https://github.com/aws/amazon-ecs-init/blob/master/CHANGELOG.md) su GitHub

## Applicazione degli aggiornamenti di sicurezza all'AMI ottimizzata per Amazon ECS
<a name="ecs-optimized-AMI-security-changes"></a>

I pacchetti ottimizzati per Amazon ECS AMIs basati su Amazon Linux contengono una versione personalizzata di. cloud-init Cloud-initè un pacchetto utilizzato per avviare le immagini Linux in un ambiente di cloud computing ed eseguire le azioni desiderate all'avvio di un'istanza. Per impostazione predefinita, tutti gli aggiornamenti di sicurezza «critici» e «importanti» applicati all'avvio dell'istanza sono applicati per impostazione predefinita su tutti gli aggiornamenti di sicurezza ottimizzati per Amazon ECS AMIs basati su Amazon Linux e rilasciati prima del 12 giugno 2024.

A partire dalle versioni del 12 giugno 2024 di Amazon ECS ottimizzato AMIs sulla base di Amazon Linux 2, il comportamento predefinito non includerà più l'aggiornamento dei pacchetti al momento del lancio. Invece, ti consigliamo di eseguire l'aggiornamento a una nuova AMI ottimizzata per Amazon ECS non appena saranno disponibili le nuove versioni. Le versioni ottimizzate per Amazon ECS AMIs vengono rilasciate quando sono disponibili aggiornamenti di sicurezza o modifiche alle AMI di base. In questo modo avrai la certezza di ricevere le versioni dei pacchetti e gli aggiornamenti di sicurezza più recenti, e che le versioni dei pacchetti rimangano invariate durante l'avvio delle istanze. Per ulteriori informazioni sul recupero delle AMI ottimizzate per Amazon ECS più recenti, consulta [Recupero dei metadati dell'AMI Linux ottimizzata per Amazon ECS](retrieve-ecs-optimized_AMI.md).

Ti consigliamo di automatizzare l'ambiente per eseguire l'aggiornamento a una nuova AMI non appena viene resa disponibile. Per informazioni sulle opzioni disponibili, consulta [Amazon ECS semplifica la gestione della capacità EC2 grazie al drenaggio gestito delle istanze](https://aws.amazon.com/blogs/containers/amazon-ecs-enables-easier-ec2-capacity-management-with-managed-instance-draining/).

Per continuare ad applicare manualmente gli aggiornamenti di sicurezza “Critici” e “Importanti” su una versione AMI, puoi eseguire il seguente comando sull'istanza Amazon EC2.

```
yum update --security
```

**avvertimento**  
 L'aggiornamento dei pacchetti docker o containerd interromperà tutti i container in esecuzione sull'host, il che significa che tutte le attività in esecuzione di Amazon ECS verranno interrotte. Pianifica di conseguenza per ridurre al minimo le interruzioni del servizio. 

Se vuoi riattivare gli aggiornamenti di sicurezza all'avvio, puoi aggiungere la seguente riga alla sezione `#cloud-config` dei dati utente cloud-init quando avvii la tua istanza Amazon EC2. Per ulteriori informazioni, consulta la sezione [Uso di cloud-init su Amazon Linux 2](https://docs.aws.amazon.com/linux/al2/ug/amazon-linux-cloud-init.html) nella *Guida per l'utente di Amazon Linux*.

```
#cloud-config
repo_upgrade: security
```

## Pacchetti con versione bloccata in GPU ottimizzate per Amazon ECS AL2023 AMIs
<a name="ecs-optimized-ami-version-locked-packages"></a>

Alcuni pacchetti sono fondamentali per il comportamento corretto e performante delle funzionalità della GPU nelle GPU ottimizzate per Amazon ECS AL2023 . AMIs Ciò include:
+ `nvidia*`Driver NVIDIA ()
+ Moduli del kernel () `kmod*`
+ Librerie NVIDIA () `libnvidia*`
+ Pacchetti kernel () `kernel*`

**Nota**  
Questo elenco non è esaustivo. L'elenco completo dei pacchetti bloccati è disponibile con `dnf versionlock list`

Questi pacchetti sono vincolati alla versione per garantire la stabilità e prevenire modifiche involontarie che potrebbero interrompere i carichi di lavoro della GPU. Di conseguenza, questi pacchetti devono generalmente essere modificati entro i limiti di un processo gestito che gestisca correttamente i potenziali problemi e mantenga la funzionalità della GPU.

Per evitare modifiche involontarie, il `dnf versionlock` plugin viene utilizzato su questi pacchetti.

Se desideri modificare un pacchetto bloccato, puoi:

```
# unlock a single package
sudo dnf versionlock delete $PACKAGE_NAME

# unlock all packages
sudo dnf versionlock clear
```

**Importante**  
Quando sono necessari aggiornamenti a questi pacchetti, i clienti devono prendere in considerazione l'utilizzo della versione AMI più recente che include gli aggiornamenti richiesti. Se è necessario aggiornare le istanze esistenti, è necessario adottare un approccio attento che preveda lo sblocco, l'aggiornamento e il riblocco dei pacchetti, assicurando sempre che la funzionalità della GPU sia mantenuta durante tutto il processo.

# Recupero dei metadati dell'AMI Linux ottimizzata per Amazon ECS
<a name="retrieve-ecs-optimized_AMI"></a>

È possibile recuperare i metadati dell'AMI ottimizzata per Amazon ECS a livello di programmazione. I metadati includono il nome AMI, la versione dell'agente container Amazon ECS e la versione runtime Amazon ECS che include la versione Docker. 

Quando crei un cluster usando la console, Amazon ECS crea un modello di avvio per le tue istanze con l'ultima AMI associata al sistema operativo selezionato. 

Quando si utilizza CloudFormation per creare un cluster, il parametro SSM fa parte del modello di avvio di Amazon EC2 per le istanze del gruppo Auto Scaling. Puoi configurare il modello in modo da usare un parametro dinamico di Systems Manager per determinare quale AMI Amazon ECS Optimized implementare. Questo parametro garantisce che, ogni volta che implementi lo stack, venga verificata la disponibilità di aggiornamenti da applicare alle istanze EC2. Per un esempio di come usare il parametro Systems Manager, consulta [Creare un cluster Amazon ECS con l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) nella *Guida per l'utente AWS CloudFormation *.

L'ID AMI, il nome dell'immagine, il sistema operativo, la versione dell'agente contenitore, il nome dell'immagine di origine e la versione di runtime per ogni variante di Amazon ECS Optimized AMIs possono essere recuperati a livello di codice interrogando l'API Systems Manager Parameter Store. Per ulteriori informazioni sull'API Systems Manager Parameter Store, vedere [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html)e [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html).

**Nota**  
Per recuperare i metadati dell'AMI ottimizzata per Amazon ECS, l'utente di amministrazione deve disporre delle seguenti autorizzazioni IAM. Queste autorizzazioni sono state aggiunte alla policy IAM `AmazonECS_FullAccess`.  
ssm: GetParameters
ssm: GetParameter
ssm: GetParametersByPath

## Formato del parametro dell'archivio parametri di Systems Manager
<a name="ecs-optimized-ami-parameter-format"></a>

Di seguito è riportato il formato del nome del parametro per ogni variante AMI ottimizzata per Amazon ECS.

**Ottimizzato per Linux Amazon ECS AMIs**
+ Metadati dell'AMI Amazon Linux 2023:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/<version>
  ```
+ Metadati dell'AMI Amazon Linux 2023 (arm64):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/<version>
  ```
+ Metadati dell'AMI Amazon Linux 2023 (Neuron):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/<version>
  ```
+ Metadati AMI Amazon Linux 2023 (GPU):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/<version>
  ```

  Metadati AMI Amazon Linux 2:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/<version>
  ```
+ Metadati AMI Amazon Linux 2 kernel 5.10:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/<version>
  ```
+ Metadati AMI Amazon Linux 2 (arm64):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/<version>
  ```
+ Metadati AMI Amazon Linux 2 (arm64) kernel 5.10:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/<version>
  ```
+ Metadati AMI Amazon ECS con kernel 5.10 ottimizzato per GPU:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/<version>
  ```
+ Metadati AMI Amazon Linux 2 (GPU):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/<version>
  ```
+ Metadati AMI Amazon Linux 2 (Neuron) kernel 5.10 ottimizzata per Amazon ECS:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/<version>
  ```
+ Metadati dell'AMI Amazon Linux 2 (Neuron):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/inf/<version>
  ```

Il seguente formato del nome del parametro recupera l'ID immagine dell'ultima AMI Amazon Linux 2 ottimizzata per Amazon ECS consigliata utilizzando il parametro secondario `image_id`.

```
/aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id
```

Il formato dei nomi di parametro seguente recupera i metadati di una versione di AMI ottimizzata per Amazon ECS specifica indicando il nome dell'AMI.
+ Metadati dell'AMI Amazon Linux 2 ottimizzata per Amazon ECS:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20181112-x86_64-ebs
  ```

**Nota**  
Tutte le versioni dell'AMI Amazon Linux 2 ottimizzata per Amazon ECS sono disponibili per il recupero. Possono essere recuperate solo le versioni `amzn-ami-2017.09.l-amazon-ecs-optimized` (Linux) dell'AMI ottimizzata per Amazon ECS e successive. 

## Esempi
<a name="ecs-optimized-ami-parameter-examples"></a>

Negli esempi seguenti vengono illustrati i modi in cui è possibile recuperare i metadati per ogni variante dell'AMI ottimizzata per Amazon ECS.

### Recupero dei metadati dell'ultima AMI ottimizzata per Amazon ECS consigliata
<a name="ecs-optimized-ami-parameter-examples-1"></a>

Puoi recuperare l'ultima AMI ottimizzata per Amazon ECS consigliata utilizzando AWS CLI i AWS CLI seguenti comandi.

**Ottimizzato per Linux Amazon ECS AMIs**
+ **Per Amazon Linux 2023 ottimizzato per Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended --region us-east-1
  ```
+ **Per Amazon Linux 2023 (arm64) ottimizzato per Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/recommended --region us-east-1
  ```
+ **Per Amazon Linux 2023 (Neuron) ottimizzato per Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended --region us-east-1
  ```
+ **Per la GPU Amazon Linux 2023 ottimizzata per Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/recommended --region us-east-1
  ```
+ **Per il kernel Amazon Linux 2 5.10 ottimizzato per Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended --region us-east-1
  ```
+ **Per Amazon Linux 2 ottimizzato per Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended --region us-east-1
  ```
+ **Per il kernel Amazon Linux 2 5.10 (arm64) ottimizzato per Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/recommended --region us-east-1
  ```
+ **Per Amazon Linux 2 (arm64) ottimizzato per Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/recommended --region us-east-1
  ```
+ **Per il kernel 5.10 ottimizzato per GPU Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/recommended --region us-east-1
  ```
+ **Per Amazon ECS ottimizzato per AMIs GPU:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
  ```
+ **Per il kernel Amazon Linux 2 (Neuron) 5.10 ottimizzato per Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/recommended --region us-east-1
  ```
+ **Per Amazon Linux 2 (Neuron) ottimizzato per Amazon ECS: AMIs**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/inf/recommended --region us-east-1
  ```

### Recupero dell'ID immagine dell'AMI Amazon Linux 2023 ottimizzata per Amazon ECS consigliata più recente
<a name="ecs-optimized-ami-parameter-examples-6"></a>

Puoi recuperare l'ID immagine dell'ID dell'AMI Amazon Linux 2023 ottimizzata per Amazon ECS consigliata più recente utilizzando il parametro secondario `image_id`.

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1
```

Per recuperare solo il valore `image_id`, è possibile eseguire query sul valore di parametro specifico, ad esempio:

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```

### Recupero dei metadati di una versione specifica dell'AMI Amazon Linux 2 ottimizzata per Amazon ECS
<a name="ecs-optimized-ami-parameter-examples-2"></a>

Recupera i metadati di una versione specifica dell'AMI Amazon Linux ottimizzata per Amazon ECS utilizzando AWS CLI il comando seguente. AWS CLI Sostituisci il nome dell'AMI con il nome dell'AMI ottimizzata per Amazon ECS da recuperare. 

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20200928-x86_64-ebs --region us-east-1
```

### Recupero dei metadati AMI Amazon Linux 2 kernel 5.10 ottimizzati per Amazon ECS utilizzando l'API Systems Manager GetParametersByPath
<a name="ecs-optimized-ami-parameter-examples-3"></a>

Recupera i metadati AMI Amazon Linux 2 ottimizzati per Amazon ECS con l'API Systems GetParametersByPath Manager utilizzando AWS CLI il comando seguente.

```
aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/ --region us-east-1
```

### Recupero dell'ID immagine dell'AMI kernel 5.10 Amazon Linux 2 ottimizzata per Amazon ECS consigliata più recente
<a name="ecs-optimized-ami-parameter-examples-4"></a>

Puoi recuperare l'ID immagine dell'ID dell'AMI kernel 5.10 Amazon Linux 2 ottimizzata per Amazon ECS consigliata più recente utilizzando il parametro secondario `image_id`.

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id --region us-east-1
```

Per recuperare solo il valore `image_id`, è possibile eseguire query sul valore di parametro specifico, ad esempio:

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```

### Utilizzo dell'ultima AMI ottimizzata per Amazon ECS consigliata in un modello CloudFormation
<a name="ecs-optimized-ami-parameter-examples-5"></a>

Puoi consultare l'AMI ottimizzata per Amazon ECS più recente in un modello CloudFormation facendo riferimento al nome dell'archivio parametri di Systems Manager.

**Esempio per Linux**

```
Parameters:kernel-5.10
  LatestECSOptimizedAMI:
    Description: AMI ID
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id
```

# Migrazione da Amazon Linux 2 a un'AMI Amazon Linux 2023 ottimizzata per Amazon ECS
<a name="al2-to-al2023-ami-transition"></a>

Dopo [Amazon Linux](https://aws.amazon.com/amazon-linux-2/faqs), Amazon ECS termina il supporto standard per Amazon Linux 2 ottimizzato per Amazon ECS a AMIs partire dal 30 giugno 2026. Dopo questa data, la versione dell'agente Amazon ECS viene bloccata e le nuove AMI Amazon Linux 2 ottimizzate per Amazon ECS AMIs vengono pubblicate solo quando viene aggiornata l'AMI Amazon Linux 2 di origine. La fine del ciclo di vita (EOL) completa avverrà il 30 giugno 2026, dopodiché non verrà più pubblicato Amazon Linux AMIs 2 ottimizzato per Amazon ECS, anche se l'AMI di origine viene aggiornata.

Amazon Linux 2023 offre un secure-by-default approccio con policy di sicurezza preconfigurate, SELinux in modalità permissiva, modalità IMDSv2 solo abilitata per impostazione predefinita, tempi di avvio ottimizzati e una migliore gestione dei pacchetti per una maggiore sicurezza e prestazioni.

Esiste un elevato grado di compatibilità tra Amazon Linux 2 e Amazon Linux 2023 ottimizzato per Amazon ECS AMIs e la maggior parte dei clienti riscontrerà minimal-to-zero cambiamenti nei carichi di lavoro tra i due sistemi operativi.

Per ulteriori informazioni, consulta la sezione [Confronto tra Amazon Linux 2 e *Amazon Linux 2023*](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) nella *Guida per l'utente di Amazon Linux 2023* e la [AL2023 FAQs](https://aws.amazon.com/linux/amazon-linux-2023/faqs).

## Considerazioni sulla compatibilità
<a name="al2-to-al2023-ami-transition-compatibility"></a>

### Gestione dei pacchetti e aggiornamenti del sistema operativo
<a name="al2-to-al2023-ami-transition-compatibility-package-management"></a>

A differenza delle versioni precedenti di Amazon Linux, Amazon Linux 2023 AMIs ottimizzato per Amazon ECS è bloccato su una versione specifica del repository Amazon Linux. Ciò impedisce agli utenti di aggiornare inavvertitamente pacchetti che potrebbero apportare modifiche indesiderate o sostanziali. Per ulteriori informazioni, consulta la sezione [Gestione dei repository e degli aggiornamenti del sistema operativo in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) nella *Guida per l'utente di Amazon Linux 2023*.

### Versioni kernel Linux
<a name="al2-to-al2023-ami-transition-compatibility-kernel"></a>

Amazon Linux 2 AMIs si basa sui kernel Linux 4.14 e 5.10, mentre Amazon Linux 2023 utilizza i kernel Linux 6.1 e 6.12. Per ulteriori informazioni, consulta [Confronto tra Amazon Linux 2 e kernel Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2-kernel.html) nella *Guida per l'utente di Amazon Linux 2023*.

### Modifiche alla disponibilità dei pacchetti
<a name="al2-to-al2023-ami-transition-compatibility-packages"></a>

Di seguito sono riportate le modifiche più significative apportate ai pacchetti in Amazon Linux 2023:
+ Alcuni pacchetti binari di origine in Amazon Linux 2 non sono più disponibili in Amazon Linux 2023. Per ulteriori informazioni, consulta [Pacchetti rimossi da Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/removed.html) nelle *Note di rilascio di Amazon Linux 2023*.
+ Modifiche nel modo in cui Amazon Linux supporta diverse versioni dei pacchetti. Il sistema `amazon-linux-extras` utilizzato in Amazon Linux 2 non esiste in Amazon Linux 2023. Tutti i pacchetti sono direttamente disponibili nel repository “core”.
+ I pacchetti aggiuntivi per Enterprise Linux (EPEL) non sono supportati in Amazon Linux 2023. Per ulteriori informazioni, consulta la sezione [Compatibilità EPEL in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/epel.html) nella *Guida per l'utente di Amazon Linux 2023*.
+ Le applicazioni a 32 bit non sono supportate in Amazon Linux 2023. Per ulteriori informazioni, consulta [Funzionalità obsolete di Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2.html#deprecated-32bit-rpms) nella *Guida per l'utente di Amazon Linux 2023*.

### Modifiche ai gruppi di controllo (cgroup)
<a name="al2-to-al2023-ami-transition-compatibility-cgroups"></a>

Un gruppo di controllo (cgroup) è una funzionalità del kernel Linux per organizzare gerarchicamente i processi e distribuire le risorse di sistema tra di essi. I gruppi di controllo vengono usati estensivamente per implementare un runtime di container e da `systemd`.

L'agente Amazon ECS, Docker e containerd supportano sia cgroupv1 che cgroupv2. L'agente Amazon ECS e il runtime del container gestiscono i cgroup per te, quindi i clienti Amazon ECS non devono apportare modifiche per questo aggiornamento del cgroup sottostante.

Per ulteriori dettagli su cgroupv2, consulta [Gruppi di controllo v2 in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/cgroupv2.html) nella *Guida per l'utente di Amazon Linux 2023*.

### Modifiche al servizio di metadati di istanza (IMDS)
<a name="al2-to-al2023-ami-transition-compatibility-imds"></a>

Amazon Linux 2023 richiede Instance Metadata Service versione 2 (IMDSv2) per impostazione predefinita. IMDSv2 offre diversi vantaggi che aiutano a migliorare il livello di sicurezza. Usa un metodo di autenticazione orientato alla sessione che prevede la creazione di un token segreto in una semplice richiesta HTTP PUT per avviare la sessione. Il token di una sessione può avere una validità compresa tra 1 secondo e 6 ore.

Per ulteriori informazioni su come passare da IMDSv1 a IMDSv2, consulta [Transition to using Instance Metadata Service Version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) nella *Amazon EC2* User Guide.

Se desideri utilizzarlo IMDSv1, puoi comunque farlo sovrascrivendo manualmente le impostazioni utilizzando le proprietà di avvio dell'opzione dei metadati dell'istanza.

### Modifiche della swappiness di memoria
<a name="al2-to-al2023-ami-transition-compatibility-memory-swappiness"></a>

La swappiness di memoria per container non è supportata su Amazon Linux 2023 e cgroups v2. Per ulteriori informazioni, consulta [Gestione dello spazio di memoria di swap dei container su Amazon ECS](container-swap.md).

### Modifiche alla convalida FIPS
<a name="al2-to-al2023-ami-transition-compatibility-fips"></a>

Amazon Linux 2 è certificato secondo lo standard FIPS 140-2 e Amazon Linux 2023 è certificato secondo lo standard FIPS 140-3.

Per abilitare la modalità FIPS su Amazon Linux 2023, installa i pacchetti necessari sulla tua istanza Amazon EC2 e segui i passaggi di configurazione usando le istruzioni in [Abilita modalità FIPS su Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html) nella *Guida per l'utente di Amazon Linux 2023*.

### Supporto delle istanze accelerato
<a name="al2-to-al2023-ami-transition-compatibility-accelerated"></a>

Amazon Linux 2023 ottimizzato per Amazon ECS AMIs supporta sia i tipi di istanza accelerata Neuron che quelli con GPU. Per ulteriori informazioni, consulta [Linux ottimizzato per Amazon ECS AMIs](ecs-optimized_AMI.md).

## Edificio personalizzato AMIs
<a name="al2-to-al2023-ami-transition-custom-ami"></a>

Sebbene ti consigliamo di passare a Amazon ECS ottimizzato per AMIs Amazon Linux 2023, supportato e pubblicato ufficialmente, puoi continuare a creare versioni personalizzate di Amazon Linux 2 ottimizzate per Amazon ECS AMIs utilizzando gli script di build open source utilizzati per creare le varianti Linux dell'AMI ottimizzata per Amazon ECS. Per ulteriori informazioni, consulta [Script di build per AMI Linux ottimizzata per Amazon ECS](ecs-ami-build-scripts.md).

## Strategie di migrazione
<a name="al2-to-al2023-ami-transition-migration"></a>

Consigliamo di creare e implementare un piano di migrazione che includa test approfonditi delle applicazioni. Le sezioni seguenti descrivono diverse strategie di migrazione in base alle modalità di gestione dell'infrastruttura Amazon ECS.

### Migrazione con i provider di capacità Amazon ECS
<a name="al2-to-al2023-ami-transition-migration-capacity-providers"></a>

1. Crea un nuovo provider di capacità con un nuovo modello di avvio. Questo dovrebbe fare riferimento a un gruppo Auto Scaling con un modello di avvio simile a quello esistente, ma invece dell'AMI Amazon Linux 2 ottimizzata per Amazon ECS, dovrebbe specificare una delle varianti Amazon Linux 2023. Aggiungi questo nuovo provider di capacità al tuo cluster Amazon ECS esistente.

1. Aggiorna la strategia del provider di capacità predefinito del tuo cluster in modo da includere sia il provider di capacità Amazon Linux 2 esistente che il nuovo provider di capacità Amazon Linux 2023. Inizia con un peso maggiore sul provider Amazon Linux 2 e uno inferiore sul provider Amazon Linux 2023 (ad esempio, Amazon Linux 2: peso 80, Amazon Linux 2023: peso 20). Questo fa sì che Amazon ECS inizi a fornire istanze Amazon Linux 2023 man mano che vengono pianificate le nuove attività. Verifica che le istanze vengano registrate correttamente e che le attività possano essere eseguite correttamente sulle nuove istanze.

1. Regola gradualmente i pesi dei provider di capacità nella strategia predefinita del tuo cluster, aumentando il peso del provider Amazon Linux 2023 e diminuendo quello del provider Amazon Linux 2 nel tempo (ad esempio: 60/40, poi 40/60, poi 20/80). È inoltre possibile aggiornare le strategie dei singoli provider di capacità di servizio per dare priorità alle istanze Amazon Linux 2023. Monitora il posizionamento delle attività per accertarti che vengano eseguite correttamente sulle istanze di Amazon Linux 2023.

1. Facoltativamente, puoi svuotare le istanze di container Amazon Linux 2 per accelerare la migrazione delle attività. Se disponi di una capacità sostitutiva sufficiente di Amazon Linux 2023, puoi drenare manualmente le istanze di container Amazon Linux 2 tramite la console Amazon ECS o AWS CLI accelerare la transizione delle tue attività da Amazon Linux 2 ad Amazon Linux 2023. Quando la migrazione è completata, rimuovi il provider di capacità Amazon Linux 2 dal tuo cluster ed elimina il gruppo Auto Scaling associato.

### Migrazione con un gruppo Amazon EC2 Auto Scaling
<a name="al2-to-al2023-ami-transition-migration-asg"></a>

1. Crea un nuovo gruppo Amazon EC2 Auto Scaling con un nuovo modello di avvio. Questo dovrebbe essere simile a un modello di avvio esistente, ma invece dell'AMI Amazon Linux 2 ottimizzata per Amazon ECS, dovrebbe specificare una delle varianti Amazon Linux 2023. Questo nuovo gruppo Auto Scaling può avviare istanze sul tuo cluster esistente.

1. Aumenta verticalmente il gruppo Auto Scaling in modo da iniziare a registrare le istanze di Amazon Linux 2023 nel tuo cluster. Verifica che le istanze vengano registrate correttamente e che le attività possano essere eseguite correttamente sulle nuove istanze.

1. Dopo aver verificato che le attività funzionano su Amazon Linux 2023, aumenta verticalmente il gruppo Auto Scaling Amazon Linux 2023 riducendo verticalmente il gruppo Auto Scaling Amazon Linux 2 in modo graduale, fino a sostituire completamente tutte le istanze Amazon Linux 2.

1. Se disponi di una capacità di sostituzione di Amazon Linux 2023 sufficiente, potresti voler drenare esplicitamente le istanze di container per accelerare la transizione delle tue attività da Amazon Linux 2 ad Amazon Linux 2023. Per ulteriori informazioni, consulta [Drenare le istanze di container di Amazon ECS](container-instance-draining.md).

### Migrazione con istanze gestite manualmente
<a name="al2-to-al2023-ami-transition-migration-manual"></a>

1. Avvia manualmente (o modifica gli script di avvio) nuove istanze Amazon EC2 usando l'AMI Amazon Linux 2023 ottimizzata per Amazon ECS invece di Amazon Linux 2. Verifica che queste istanze usino gli stessi gruppi di sicurezza, sottoreti, ruoli IAM e configurazione del cluster delle istanze Amazon Linux 2 esistenti. Le istanze dovrebbero registrarsi nel cluster Amazon ECS esistente automaticamente al momento dell'avvio.

1. Verifica che le nuove istanze Amazon Linux 2023 siano state registrate correttamente nel tuo cluster Amazon ECS e che siano nello stato `ACTIVE`. Verifica che le attività possano essere pianificate ed eseguite correttamente su queste nuove istanze attendendo il posizionamento naturale delle attività o attivando manualmente la riprogrammazione di stopping/starting alcune attività.

1. Sostituisci gradualmente le istanze di Amazon Linux 2 avviando istanze Amazon Linux 2023 aggiuntive in base alle necessità, quindi svuotando e terminando manualmente le istanze di Amazon Linux 2 una ad una. È possibile drenare le istanze tramite la console Amazon ECS impostando l'istanza sullo stato `DRAINING`, che interromperà l'assegnazione di nuove attività e consentirà alle attività esistenti di essere completate o ripianificate altrove.

# Script di build per AMI Linux ottimizzata per Amazon ECS
<a name="ecs-ami-build-scripts"></a>

Amazon ECS ha reso open-source gli script della build che vengono utilizzati per creare le varianti Linux dell'AMI ottimizzata per Amazon ECS. Questi script di build sono ora disponibili su. GitHub Per ulteriori informazioni, vedere [amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami)su. GitHub

Se devi personalizzare l'AMI ottimizzata per Amazon ECS, consulta Amazon [ECS Optimized AMI Build Recipies](https://github.com/aws/amazon-ecs-ami) on. GitHub

L'archivio degli script di compilazione include un modello di [HashiCorppacker](https://developer.hashicorp.com/packer/docs) e script di compilazione per generare ciascuna delle varianti Linux dell'AMI ottimizzata per Amazon ECS. Questi script sono la fonte di verità per le build AMI ottimizzate per Amazon ECS, quindi puoi seguire GitHub il repository per monitorare le modifiche al nostro. AMIs Ad esempio, magari vuoi che l'AMI utilizzi la stessa versione di Docker utilizzata dal team Amazon ECS per l'AMI ufficiale.

Per ulteriori informazioni, consulta il repository AMI Amazon ECS all'indirizzo [amazon-ecs-amiaws/](https://github.com/aws/amazon-ecs-ami) on. GitHub

**Come creare un'AMI Linux ottimizzata per Amazon ECS**

1. Clona il repository. `aws/amazon-ecs-ami` GitHub 

   ```
   git clone https://github.com/aws/amazon-ecs-ami.git
   ```

1. Aggiungi una variabile di ambiente per la AWS regione da utilizzare durante la creazione dell'AMI. Sostituisci il valore `us-west-2` con la regione da utilizzare.

   ```
   export REGION=us-west-2
   ```

1. Viene fornito un Makefile per creare l'AMI. Dalla directory principale del repository clonato, utilizza uno dei seguenti comandi, corrispondente alla variante Linux dell'AMI ottimizzata per Amazon ECS che desideri creare.
   + AMI Amazon Linux 2 ottimizzata per Amazon ECS

     ```
     make al2
     ```
   + AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS

     ```
     make al2arm
     ```
   + AMI Amazon ECS ottimizzata per GPU

     ```
     make al2gpu
     ```
   + AMI Amazon Linux 2 (Neuron) ottimizzata per Amazon ECS

     ```
     make al2inf
     ```
   + AMI Amazon Linux 2023 ottimizzata per Amazon ECS

     ```
     make al2023
     ```
   + AMI Amazon Linux 2023 (arm64) ottimizzata per Amazon ECS

     ```
     make al2023arm
     ```
   + AMI GPU Amazon Linux 2023 ottimizzata per Amazon ECS

     ```
     make al2023gpu
     ```
   + AMI Amazon Linux 2023 (Neuron) ottimizzata per Amazon ECS

     ```
     make al2023neu
     ```

# Ottimizzato per Amazon ECS Bottlerocket AMIs
<a name="ecs-bottlerocket"></a>

Bottlerocketè un sistema operativo open source Linux basato sullo scopo di AWS eseguire container su macchine virtuali o host bare metal. L'AMI Bottlerocket ottimizzata per Amazon ECS è sicura e include solo il numero minimo di pacchetti necessari per l'esecuzione dei container. Ciò migliora l'utilizzo delle risorse, riduce la superficie di attacco della sicurezza e aiuta a ridurre il sovraccarico di gestione. L'AMI Bottlerocket è inoltre integrato con Amazon ECS per contribuire a ridurre il sovraccarico operativo legato all'aggiornamento delle istanze di container in un cluster. 

Bottlerocket differisce da Amazon Linux nei seguenti modi:
+ Bottlerocket non include un gestore di pacchetti e il suo software può essere eseguito solo come container. Gli aggiornamenti a Bottlerocket vengono entrambi applicati e possono essere ripristinati in un unico passaggio, ciò riduce la probabilità di errori di aggiornamento.
+ Il meccanismo principale per gestire gli host Bottlerocket è l'utilizzo di uno strumento di pianificazione di container. A differenza di Amazon Linux, l'accesso a singole istanze Bottlerocket è destinato a essere un'operazione poco frequente solo per scopi avanzati di debug e risoluzione dei problemi.

Per ulteriori informazioni su Bottlerocket, consulta la [documentazione](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) e le [versioni](https://github.com/bottlerocket-os/bottlerocket/releases) su GitHub.

Esistono delle varianti dell'AMI Bottlerocket ottimizzata per Amazon ECS per kernel 6.1 e kernel 5.10.

Le seguenti varianti usano il kernel 6.1:
+ `aws-ecs-2`
+ `aws-ecs-2-nvidia`

Le seguenti varianti usano il kernel 5.10:
+ `aws-ecs-1`
+ `aws-ecs-1-nvidia`

  Per ulteriori informazioni sulla variante `aws-ecs-1-nvidia`, consulta [Annuncio del supporto GPU NVIDIA per Bottlerocket su Amazon ECS](https://aws.amazon.com/blogs/containers/announcing-nvidia-gpu-support-for-bottlerocket-on-amazon-ecs/).

## Considerazioni
<a name="ecs-bottlerocket-considerations"></a>

Quando utilizzi un'AMI Bottlerocket con Amazon ECS, considera gli aspetti seguenti.
+ Bottlerocket supporta le istanze Amazon EC2 con processori `x86_64` e `arm64`. L'AMI Bottlerocket non è consigliata per l'uso con istanze Amazon EC2 dotate di chip Inferentia.
+ Le immagini Bottlerocket non includono un server SSH o uno shell (interprete di comandi). Tuttavia, è possibile utilizzare gli strumenti di out-of-band gestione per ottenere l'accesso come amministratore SSH ed eseguire il bootstrap. 

   Per ulteriori informazioni, consulta le seguenti sezioni nel [README.md di Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) su GitHub:
  + [Esplorazione](https://github.com/bottlerocket-os/bottlerocket#exploration)
  + [Container amministratore](https://github.com/bottlerocket-os/bottlerocket#admin-container)
+ Per impostazione predefinita, Bottlerocket ha un [container di controllo](https://github.com/bottlerocket-os/bottlerocket-control-container) abilitato. Questo container gestisce [l'agente AWS Systems Manager](https://github.com/aws/amazon-ssm-agent) che è possibile utilizzare per eseguire comandi o avviare sessioni di shell sulle istanze Bottlerocket di Amazon EC2. Per ulteriori informazioni, consulta [Configurazione di Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) nella *Guida per l'utente di AWS Systems Manager *.
+ Bottlerocket è ottimizzato per i carichi di lavoro dei container e si concentra sulla sicurezza. Bottlerocket non include un gestore di pacchetti ed è immutabile. 

  Per informazioni sulle caratteristiche di sicurezza e sulle linee guida, consulta [Funzionalità di sicurezza](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_FEATURES.md) e [linee guida sulla sicurezza su](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_GUIDANCE.md). GitHub
+ La modalità di rete `awsvpc` è supportata qper l'AMI Bottlerocket versione `1.1.0` o successiva.
+ L'App Mesh in una definizione di attività è supportata per la versione `1.15.0` dell'AMI Bottlerocket o versioni successive.
+ Il parametro di definizione dell'attività `initProcessEnabled` è supportato per l'AMI Bottlerocket versione `1.19.0` o successive.
+ Bottlerocket AMIs Inoltre, non supportano i seguenti servizi e funzionalità:
  + ECS Anywhere
  + Service Connect
  + Amazon EFS in modalità crittografata
  + Amazon EFS in modalità di rete `awsvpc`
  + I volumi Amazon EBS non possono essere montati
  + Acceleratore di inferenze elastiche

# Recupero dei metadati dell'AMI Bottlerocket ottimizzata per Amazon ECS
<a name="ecs-bottlerocket-retrieve-ami"></a>

Puoi recuperare l'ID Amazon Machine Image (AMI) per Amazon ECS ottimizzato per Amazon ECS AMIs interrogando l' AWS Systems Manager API Parameter Store. Utilizzando questo parametro, non è necessario cercare manualmente le AMI ottimizzate per Amazon ECS. IDs Per ulteriori informazioni sull'API Systems Manager Parameter Store, vedere [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). Il principale IAM che utilizzi deve disporre dell'autorizzazione IAM `ssm:GetParameter` per recuperare i metadati dell'AMI ottimizzata per Amazon ECS.

## Variante AMI Bottlerocket `aws-ecs-2`
<a name="ecs-bottlerocket-aws-ecs-2-variant"></a>

Puoi recuperare l'ultima variante stabile dell'AMI `aws-ecs-2` Bottlerocket Regione AWS tramite un'architettura con o AWS CLI il. Console di gestione AWS
+ **AWS CLI**— Puoi recuperare l'ID immagine dell'ultima Bottlerocket AMI ottimizzata per Amazon ECS consigliata con il AWS CLI seguente comando utilizzando il sottoparametro. `image_id` Sostituisci la `region` con il codice della regione per la quale desideri ottenere l'ID AMI. 

  Per informazioni sulle funzionalità supportate Regioni AWS, consulta [Ricerca di un'AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) attiva GitHub. Per recuperare una versione diversa da quella più recente, sostituisci `latest` con il numero della versione desiderata.
  + Per un'architettura a 64 bit (`x86_64`):

    ```
    aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + Per l'architettura a 64 bit Arm (`arm64`):

    ```
    aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **Console di gestione AWS**: puoi eseguire una query per l'ID dell'AMI ottimizzata consigliata per Amazon ECS utilizzando un URL nella Console di gestione AWS. L'URL apre la console Amazon EC2 Systems Manager con il valore dell'ID per il parametro indicato. Nel seguente URL, sostituisci `region` con il codice della regione per cui desideri ottenere l'ID AMI. 

   Per informazioni sulle funzionalità supportate Regioni AWS, consulta [Ricerca di un'AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) attiva GitHub.
  + Per un'architettura a 64 bit (`x86_64`):

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id/description?region=region#
    ```
  + Per l'architettura a 64 bit Arm (`arm64`):

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id/description?region=region#
    ```

## Variante AMI Bottlerocket `aws-ecs-2-nvidia`
<a name="ecs-bottlerocket-aws-ecs-1-nvidia-variants"></a>

Puoi recuperare l'ultima variante stabile dell'AMI `aws-ecs-2-nvdia` Bottlerocket per regione e architettura con AWS CLI o. Console di gestione AWS
+ **AWS CLI**— Puoi recuperare l'ID immagine dell'ultima Bottlerocket AMI ottimizzata per Amazon ECS consigliata con il AWS CLI seguente comando utilizzando il sottoparametro. `image_id` Sostituisci la `region` con il codice della regione per la quale desideri ottenere l'ID AMI. 

   Per informazioni sulle funzionalità supportate Regioni AWS, consulta [Ricerca di un'AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) attiva GitHub. Per recuperare una versione diversa da quella più recente, sostituisci `latest` con il numero della versione desiderata.
  + Per un'architettura a 64 bit (`x86_64`):

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + Per l'architettura a 64 bit Arm (`arm64`):

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **Console di gestione AWS**: puoi eseguire una query per l'ID dell'AMI ottimizzata consigliata per Amazon ECS utilizzando un URL nella Console di gestione AWS. L'URL apre la console Amazon EC2 Systems Manager con il valore dell'ID per il parametro indicato. Nel seguente URL, sostituisci `region` con il codice della regione per cui desideri ottenere l'ID AMI. 

  Per informazioni sulle funzionalità supportate Regioni AWS, consulta [Ricerca di un'AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) attiva GitHub.
  + Per l'architettura a 64 bit (`x86_64`):

    ```
    https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id/description?region=region#
    ```
  + Per l'architettura a 64 bit Arm (`arm64`):

    ```
    https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id/description?region=region#
    ```

## Variante AMI Bottlerocket `aws-ecs-1`
<a name="ecs-bottlerocket-aws-ecs-1-variant"></a>

Puoi recuperare l'ultima variante stabile dell'AMI `aws-ecs-1` Bottlerocket Regione AWS tramite un'architettura con o AWS CLI il. Console di gestione AWS
+ **AWS CLI**— Puoi recuperare l'ID immagine dell'ultima Bottlerocket AMI ottimizzata per Amazon ECS consigliata con il AWS CLI seguente comando utilizzando il sottoparametro. `image_id` Sostituisci la `region` con il codice della regione per la quale desideri ottenere l'ID AMI. 

  Per informazioni sulle funzionalità supportate Regioni AWS, consulta [Ricerca di un'AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) attiva GitHub. Per recuperare una versione diversa da quella più recente, sostituisci `latest` con il numero della versione desiderata.
  + Per un'architettura a 64 bit (`x86_64`):

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + Per l'architettura a 64 bit Arm (`arm64`):

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **Console di gestione AWS**: puoi eseguire una query per l'ID dell'AMI ottimizzata consigliata per Amazon ECS utilizzando un URL nella Console di gestione AWS. L'URL apre la console Amazon EC2 Systems Manager con il valore dell'ID per il parametro indicato. Nel seguente URL, sostituisci `region` con il codice della regione per cui desideri ottenere l'ID AMI.

  Per informazioni sulle funzionalità supportate Regioni AWS, consulta [Ricerca di un'AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) attiva GitHub.
  + Per un'architettura a 64 bit (`x86_64`):

    ```
    https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id/description
    ```
  + Per l'architettura a 64 bit Arm (`arm64`):

    ```
    https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id/description
    ```

## Variante AMI Bottlerocket `aws-ecs-1-nvidia`
<a name="ecs-bottlerocket-aws-ecs-1-nvidia-variants"></a>

Puoi recuperare l'ultima variante stabile dell'AMI `aws-ecs-1-nvdia` Bottlerocket per regione e architettura con AWS CLI o. Console di gestione AWS
+ **AWS CLI**— Puoi recuperare l'ID immagine dell'ultima Bottlerocket AMI ottimizzata per Amazon ECS consigliata con il AWS CLI seguente comando utilizzando il sottoparametro. `image_id` Sostituisci la `region` con il codice della regione per la quale desideri ottenere l'ID AMI. 

  Per informazioni sulle funzionalità supportate Regioni AWS, consulta [Ricerca di un'AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) attiva GitHub.
  + Per un'architettura a 64 bit (`x86_64`):

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + Per l'architettura a 64 bit Arm (`arm64`):

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **Console di gestione AWS**: puoi eseguire una query per l'ID dell'AMI ottimizzata consigliata per Amazon ECS utilizzando un URL nella Console di gestione AWS. L'URL apre la console Amazon EC2 Systems Manager con il valore dell'ID per il parametro indicato. Nel seguente URL, sostituisci `region` con il codice della regione per cui desideri ottenere l'ID AMI. 

  Per informazioni sulle funzionalità supportate Regioni AWS, consulta [Ricerca di un'AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) attiva GitHub.
  + Per l'architettura a 64 bit (`x86_64`):

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id/description?region=region#
    ```
  + Per l'architettura a 64 bit Arm (`arm64`):

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id/description?region=region#
    ```

## Fasi successive
<a name="bottlerocket-next-steps"></a>

Per un tutorial dettagliato su come iniziare a [usare il sistema Bottlerocket operativo su Amazon ECS, consulta Using a Bottlerocket AMI with Amazon](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) ECS GitHub on [e Getting started with Bottlerocket e Amazon](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/) ECS sul sito del blog. AWS 

Per ulteriori informazioni sull'avvio di un'istanza Bottlerocket, consulta [Avvio di un'istanza Bottlerocket per Amazon ECS](bottlerocket-launch.md)

# Avvio di un'istanza Bottlerocket per Amazon ECS
<a name="bottlerocket-launch"></a>

Puoi avviare un'istanza Bottlerocket in modo da poter eseguire i carichi di lavoro dei container.

Puoi usare il AWS CLI per avviare l'Bottlerocketistanza.

1. Crea un file denominato `userdata.toml`. Questo file viene utilizzato per i dati utente dell'istanza. Sostituisci *cluster-name* con il nome del cluster.

   ```
   [settings.ecs]
   cluster = "cluster-name"
   ```

1. Usa uno dei comandi inclusi in [Recupero dei metadati dell'AMI Bottlerocket ottimizzata per Amazon ECS](ecs-bottlerocket-retrieve-ami.md) per ottenere l'ID dell'AMI Bottlerocket. Ti servirà per la fase successiva.

1. Esegui il comando seguente per avviare l'istanza Bottlerocket. Ricordati di sostituire i seguenti parametri:
   + Sostituiscilo *subnet* con l'ID della sottorete privata o pubblica in cui verrà avviata l'istanza.
   + Sostituisci *bottlerocket\$1ami* con l'ID AMI del passaggio precedente.
   + Sostituisci *t3.large* con il tipo di istanza che desideri utilizzare.
   + Sostituisci *region* con il codice regionale.

   ```
   aws ec2 run-instances --key-name ecs-bottlerocket-example \
      --subnet-id subnet \
      --image-id bottlerocket_ami \
      --instance-type t3.large \
      --region region \
      --tag-specifications 'ResourceType=instance,Tags=[{Key=bottlerocket,Value=example}]' \
      --user-data file://userdata.toml \
      --iam-instance-profile Name=ecsInstanceRole
   ```

1. Esegui il comando seguente per verificare che l'istanza di container sia registrata nel cluster. Quando esegui questo comando, ricordati di sostituire i parametri seguenti:
   + Sostituisci *cluster* con il nome del cluster.
   + Sostituisci *region* con il tuo codice regionale.

   ```
   aws ecs list-container-instances --cluster cluster-name --region region
   ```

Per una guida dettagliata su come iniziare a [usare il sistema Bottlerocket operativo su Amazon ECS, consulta Using a Bottlerocket AMI with Amazon ECS on e GitHub Getting started with e [BottlerocketAmazon](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/) ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) sul sito del blog. AWS 

# Gestione delle istanze di container Amazon ECS Linux
<a name="manage-linux"></a>

Quando usi le istanze EC2 per i carichi di lavoro Amazon ECS, sei responsabile della manutenzione delle istanze

**Topics**
+ [Avvio di un'istanza di container](launch_container_instance.md)
+ [Bootstrap delle istanze di container Linux](bootstrap_container_instance.md)
+ [Configurazione delle istanze di container per ricevere avvisi sulle istanze spot](spot-instance-draining-linux-container.md)
+ [Esecuzione di uno script quando si avvia un'istanza di container](start_task_at_launch.md)
+ [

# Aumento delle interfacce di rete delle istanze di container Linux di Amazon ECS
](container-instance-eni.md)
+ [Allocazione della memoria di un'istanza di container](memory-management.md)
+ [Gestione remota delle istanze di container](ec2-run-command.md)
+ [Uso di un proxy HTTP per istanze di container Linux](http_proxy_config.md)
+ [Configurazione delle istanze preinizializzate per il tuo gruppo Auto Scaling](using-warm-pool.md)
+ [

# Aggiornamento dell'agente del container Amazon ECS
](ecs-agent-update.md)

Ogni versione dell'agente del container di Amazon ECS supporta una serie di funzioni differenti e assicura le correzioni dei bug delle versioni precedenti. Quando possibile, consigliamo sempre di utilizzare la versione più recente dell'agente del container di Amazon ECS. Per passare all'ultima versione dell'agente del container, consulta [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).

[Per scoprire quali funzionalità e miglioramenti sono inclusi in ogni versione dell'agente, consulta /releases. https://github.com/aws/ amazon-ecs-agent](https://github.com/aws/amazon-ecs-agent/releases)

**Importante**  
La versione Docker minima per parametri affidabili è `v20.10.13` e successive, inclusa nell'AMI `20220607` ottimizzata per Amazon ECS e versioni successive.  
Le versioni dell'agente Amazon ECS `1.20.0` e successive non supportano più le versioni di Docker precedenti alla `18.01.0`.

# Avvio di un'istanza di container Linux di Amazon ECS
<a name="launch_container_instance"></a>

Puoi creare istanze di container di Amazon ECS utilizzando la console Amazon EC2. 

Puoi avviare un'istanza con vari metodi, tra cui la console Amazon EC2 e l' AWS CLI SDK. Per informazioni sugli altri metodi per avviare un'istanza, consulta [Avvio dell'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html) nella *Guida per l'utente di Amazon EC2*.

Per ulteriori informazioni sulla procedura guidata di avvio, consulta[Avvio di un'istanza tramite la nuova procedura guidata di avvio istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) nella *Guida per l'utente di Amazon EC2*. 

Prima di iniziare, completa i passaggi descritti in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md).

È possibile utilizzare la nuova procedura guidata Amazon EC2 per avviare un'istanza. La procedura guidata di avvio specifica tutti i parametri di avvio necessari per l'avvio di un'istanza. 

**Topics**
+ [

## Procedura
](#linux-liw-initiate-instance-launch)
+ [

## Nome e tag
](#linux-liw-name-and-tags)
+ [

## Immagini di applicazioni e sistema operativo (Amazon Machine Image)
](#linux-liw-ami)
+ [

## Tipo di istanza
](#linux-liw-instance-type)
+ [

## Coppia di chiavi (login)
](#linux-liw-key-pair)
+ [

## Impostazioni di rete
](#linux-liw-network-settings)
+ [

## Per configurare l'archiviazione
](#linux-liw-storage)
+ [

## Dettagli avanzati
](#linux-liw-advanced-details)

## Procedura
<a name="linux-liw-initiate-instance-launch"></a>

Prima di iniziare, completa i passaggi descritti in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md).

1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Nella barra di navigazione nella parte superiore dello schermo, viene visualizzata la AWS regione corrente (ad esempio, Stati Uniti orientali (Ohio)). Selezionare una regione in cui avviare l'istanza. 

1. Dal pannello di controllo della console Amazon EC2, scegli **Launch Instance (Avvia istanza)**.

## Nome e tag
<a name="linux-liw-name-and-tags"></a>

Il nome dell'istanza è un tag, dove la chiave è **Name (Nome)** e il valore è il nome specificato. È possibile aggiungere tag all'istanza, ai volumi e alla grafica elastica. Per le istanze spot, è possibile aggiungere un tag solo alla richiesta di istanza spot. 

La specifica di un nome di istanza e dei tag aggiuntivi è facoltativa.
+ Per **Name (Nome)**, inserire un nome descrittivo per l'istanza. Se non si specifica un nome, l'istanza può essere identificata dal relativo ID, che viene generato automaticamente all'avvio dell'istanza.
+ Per aggiungere altri tag, scegliere **Add additional tags (Aggiungi altri tag)**. Scegliere **Add tag (Aggiungi tag)**, quindi immettere una chiave e un valore e selezionare il tipo di risorsa da taggare. Scegliere **Add tag (Aggiungi tag)** per ogni tag aggiuntivo.

## Immagini di applicazioni e sistema operativo (Amazon Machine Image)
<a name="linux-liw-ami"></a>

Un'Amazon Machine Image (AMI) contiene tutte le informazioni necessarie per creare un'istanza. Ad esempio, un'AMI può contenere il software necessario per fungere da server Web, ad esempio Apache e il sito Web.

Utilizza la barra **di ricerca** per trovare un'AMI ottimizzata per Amazon ECS adatta pubblicata da. AWS

1. Inserisci uno dei seguenti termini nella barra **Search** (cerca).
   + **ami-ecs**
   + Il **Valore** di un'AMI ottimizzata per Amazon ECS.

     Per le ultime versioni ottimizzate per Amazon ECS AMIs e i relativi valori, consulta Linux AMI ottimizzata per [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux).

1. Premere **Invio**.

1. Nella pagina **Choose an Amazon Machine Image (AMI)**, seleziona la AMIs scheda **AWS Marketplace**.

1. Dal riquadro **Refine results** (perfeziona i risultati), seleziona **Amazon Web Services** come **Publisher**.

1. Scegli **Select** (seleziona) nella riga dell'AMI da utilizzare.

   In alternativa, scegli **Cancel** (Annulla) (in alto a destra) per tornare alla procedura guidata di avvio istanza senza scegliere un'AMI. Verrà selezionata un'AMI predefinita. Assicurati che l'AMI soddisfi i requisiti delineati in Linux ottimizzato per [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html). AMIs

## Tipo di istanza
<a name="linux-liw-instance-type"></a>

Il tipo di istanza definisce la configurazione hardware e le dimensioni dell'istanza. I tipi di istanza più grandi dispongono di una maggiore quantità di CPU e memoria. Per maggiori informazioni, consulta [ Tipi di istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) nella *Guida per l'utente di Amazon EC2*. Se desideri eseguire IPv6 solo un carico di lavoro, alcuni tipi di istanze non supportano gli indirizzi. IPv6 Per ulteriori informazioni, [IPv6consulta gli indirizzi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing) nella Guida per l'*utente di Amazon EC2*.
+ Per **Tipo di istanza**, selezionare il tipo di istanza per l'istanza. 

   Il tipo di istanza che selezioni determina le risorse disponibili per l'esecuzione delle attività.

## Coppia di chiavi (login)
<a name="linux-liw-key-pair"></a>

In **Key pair name (Nome della coppia di chiavi)**, scegliere una coppia di chiavi esistente oppure scegliere **Create new key pair (Crea nuova coppia di chiavi)** per creane una nuova. 

**Importante**  
Se si sceglie l'opzione **Proceed without key pair (Not recommended)** (Procedi senza una coppia di chiavi [non consigliato]), non sarà possibile connetterti all'istanza a meno che non si scelga un'AMI configurata per offrire agli utenti un metodo di accesso alternativo.

## Impostazioni di rete
<a name="linux-liw-network-settings"></a>

Configura le impostazioni di rete in base alle necessità dopo aver selezionato il pulsante **Modifica** nella sezione **Impostazioni di rete** del modulo.
+ Per **VPC**, seleziona il VPC nel quale desideri avviare l'istanza. Per eseguire IPv6 solo un carico di lavoro, scegli un VPC dual stack che includa sia IPv4 un blocco CIDR che uno. IPv6 
+ Per **Sottorete**, seleziona la sottorete in cui avviare l'istanza. Puoi avviare un'istanza in una sottorete associata a una zona di disponibilità, una Local Zone, una zona Wavelength o un Outpost.

  Per avviare l'istanza in una zona di disponibilità, selezionare la sottorete in cui avviare l'istanza. Per creare una nuova sottorete, scegliere **Create new subnet (Crea nuova sottorete)** per passare alla console Amazon VPC. Al termine, tornare alla procedura guidata di avvio istanza e scegliere Refresh (Aggiorna) per caricare la sottorete nell'elenco.

  Per avviare l'istanza in una Local Zone, selezionare una sottorete creata nella Local Zone. 

  Per avviare un'istanza in un Outpost, selezionare una sottorete in un VPC associato a un Outpost.

  Per eseguire un carico di lavoro IPv6 solo, scegli una sottorete che includa solo un blocco CIDR. IPv6 
+ **Auto-assign Public IP** (IP pubblico di assegnazione automatica): se l'istanza deve essere accessibile da Internet, verifica che il campo **Auto-assign Public IP** (Assegna automaticamente IP pubblico) sia impostato su **Enable** (Abilita). In caso contrario, imposta il campo su **Disable** (Disabilita).
**Nota**  
Le istanze di container richiedono un accesso per comunicare con l'endpoint del servizio Amazon ECS. Ciò può avvenire attraverso un endpoint VPC di interfaccia o tramite istanze di container con indirizzi IP pubblici.  
Per ulteriori informazioni sugli endpoint VPC di interfaccia, vedi [Endpoint VPC dell'interfaccia di Amazon ECS (AWS PrivateLink)](vpc-endpoints.md)  
Se non disponi di un endpoint VPC di interfaccia configurato e le istanze di container non dispongono di indirizzi IP pubblici, per fornire questo accesso devono utilizzare il processo Network Address Translation (NAT). Per ulteriori informazioni, consulta [NAT gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) (Gateway NAT) nella *Guida per l'utente di Amazon VPC* e [Uso di un proxy HTTP per istanze di container Linux Amazon ECS](http_proxy_config.md) in questa guida. 
+ **Se scegli un VPC dual stack e IPv6 una sottorete solo, **per IPv6 Assegnazione automatica** dell'IP, scegli Abilita.**
+ **Firewall (security groups)** (Firewall [gruppi di sicurezza]): utilizza un gruppo di sicurezza per definire le regole del firewall per l'istanza di container. Tali regole specificano quale traffico di rete in entrata viene distribuito sull'istanza di container. Tutto il traffico rimanente verrà ignorato. 
  + Per selezionare un gruppo di sicurezza esistente, scegli **Select an existing security group** (Seleziona un gruppo di sicurezza esistente), quindi seleziona il gruppo di sicurezza creato in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md).
+ ****Se avvii l'istanza per un IPv6 solo carico di lavoro, scegli **Configurazione di rete avanzata**, quindi per Assegna IP primario, scegli Sì. IPv6 ****
**Nota**  
Senza un IPv6 indirizzo primario, le attività in esecuzione sull'istanza del contenitore nelle modalità di rete host o bridge non verranno registrate con i sistemi di bilanciamento del carico o con. AWS Cloud Map

## Per configurare l'archiviazione
<a name="linux-liw-storage"></a>

L'AMI selezionata include uno o più volumi di archiviazione, compreso il volume dispositivo root. È possibile specificare altri volumi da collegare all'istanza.

Puoi utilizzare la vista **Semplice**.
+ **Storage Type** (Tipo di storage): configura lo storage per l'istanza di container.

  Se stai utilizzando l'AMI Amazon Linux 2 ottimizzata per Amazon ECS, l'istanza dispone di un singolo volume di 30 GiB configurato che è condiviso tra il sistema operativo e Docker.

  Se stai utilizzando l'AMI ottimizzata per Amazon ECS, l'istanza dispone di due volumi configurati. Il volume **Root** è per il sistema operativo, mentre il secondo volume di Amazon EBS (collegato a `/dev/xvdcz`) è per l'utilizzo di Docker.

  Puoi aumentare o diminuire le dimensioni del volume per l'istanza in modo che soddisfi le esigenze applicative.

## Dettagli avanzati
<a name="linux-liw-advanced-details"></a>

Per **Advanced Details (Dettagli avanzati)**, espandi la sezione per visualizzare i campi e specifica eventuali parametri aggiuntivi per l'istanza.
+ **Purchasing option** (Opzioni di acquisto): seleziona **Request Spot Instances** (Richiedi istanze Spot) per avviare un'istanza Spot. Dovrai anche impostare altri campi correlati alle istanze Spot. Per ulteriori informazioni, consulta [Richiesta Istanza Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html).
**Nota**  
Se utilizzi istanze Spot e visualizzi un messaggio `Not available`, potresti dover scegliere un altro tipo di istanza.
+ **Profilo istanza IAM**: seleziona il ruolo IAM dell'istanza di container. Questo di solito è chiamato `ecsInstanceRole`.
**Importante**  
Se non avvii l'istanza di container con le autorizzazioni IAM corrette, l'agente Amazon ECS non potrà connettersi al cluster. Per ulteriori informazioni, consulta [Ruolo IAM delle istanze di container Amazon ECS](instance_IAM_role.md).
+ **Dati utente**: configura l'istanza di container di Amazon ECS con i dati utente, ad esempio le variabili di ambiente dell'agente da [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md). Gli script di dati utente di Amazon EC2 vengono eseguiti solo una volta, al primo avvio dell'istanza. Di seguito sono elencati esempi comuni dei dati utente utilizzati per:
  + Di default, l'istanza di container si avvia nel cluster predefinito. Per avviarla in un cluster non predefinito, scegli l'elenco **Advanced Details** (Dettagli avanzati). Quindi, incolla lo script seguente nel campo **Dati utente**, sostituendolo *your\$1cluster\$1name* con il nome del cluster.

    ```
    #!/bin/bash
    echo ECS_CLUSTER=your_cluster_name >> /etc/ecs/ecs.config
    ```
  + Se disponi di un file `ecs.config` in Amazon S3 e hai abilitato l'accesso in sola lettura di Amazon S3 al ruolo dell'istanza di container, scegli l'elenco **Dettagli avanzati**. Quindi, incolla lo script seguente nel campo **Dati utente**, sostituendolo *your\$1bucket\$1name* con il nome del bucket per installarlo AWS CLI e scrivi il file di configurazione al momento del lancio. 
**Nota**  
Per ulteriori informazioni su questa configurazione, consulta [Archiviazione della configurazione di un'istanza di container Amazon ECS in Amazon S3](ecs-config-s3.md).

    ```
    #!/bin/bash
    yum install -y aws-cli
    aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
    ```
  + Specificare i tag per l'istanza di container utilizzando il parametro di configurazione `ECS_CONTAINER_INSTANCE_TAGS`. Ciò crea i tag associati solo a Amazon ECS, non possono essere elencati utilizzando l'API Amazon EC2.
**Importante**  
Se avvii le istanze del container utilizzando un gruppo Auto Scaling di Amazon EC2, devi utilizzare il parametro di configurazione dell'agente ECS\$1CONTAINER\$1INSTANCE\$1TAGS per aggiungere tag. Ciò è dovuto al modo in cui i tag vengono aggiunti alle istanze Amazon EC2 avviate utilizzando i gruppi Auto Scaling.

    ```
    #!/bin/bash
    cat <<'EOF' >> /etc/ecs/ecs.config
    ECS_CLUSTER=your_cluster_name
    ECS_CONTAINER_INSTANCE_TAGS={"tag_key": "tag_value"}
    EOF
    ```
  + Specifica i tag per l'istanza di container e quindi utilizza il parametro di configurazione `ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM` per propagarli da Amazon EC2 ad Amazon ECS.

    Di seguito è riportato un esempio di script di dati utente che propaga i tag associati a un'istanza di container, nonché registra l'istanza di container con un cluster denominato `your_cluster_name`:

    ```
    #!/bin/bash
    cat <<'EOF' >> /etc/ecs/ecs.config
    ECS_CLUSTER=your_cluster_name
    ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM=ec2_instance
    EOF
    ```
  + Per impostazione predefinita, l'agente container Amazon ECS cercherà di rilevare la compatibilità dell'istanza del contenitore per una configurazione IPv6 solo esaminando i valori predefiniti IPv4 e IPv6 i percorsi dell'istanza. Per ignorare questo comportamento, puoi impostare il parametro ` ECS_INSTANCE_IP_COMPATIBILITY` su `ipv4` o `ipv6` nel file dell'istanza `/etc/ecs/ecs.config`.

    ```
    #!/bin/bash
    cat <<'EOF' >> /etc/ecs/ecs.config
    ECS_CLUSTER=your_cluster_name
    ECS_INSTANCE_IP_COMPATIBILITY=ipv6
    EOF
    ```

  Per ulteriori informazioni, consulta [Bootstrap di istanze di container Linux Amazon ECS per il trasferimento dei dati](bootstrap_container_instance.md).

# Bootstrap di istanze di container Linux Amazon ECS per il trasferimento dei dati
<a name="bootstrap_container_instance"></a>

Quando avvii un'istanza Amazon EC2, puoi trasferire i dati utente all'istanza EC2. I dati possono essere utilizzati per eseguire attività di configurazione automatizzate di routine e anche per l'esecuzione di script all'avvio dell'istanza. Per Amazon ECS, i casi di utilizzo più comuni per i dati utente riguardano la trasmissione di informazioni sulla configurazione al daemon Docker e all'agente del container Amazon ECS.

Puoi trasferire diversi tipi di dati utente ad Amazon EC2, ad esempio hook di avvio del cloud, script di shell e direttive `cloud-init`. Per ulteriori informazioni su questi e altri tipi di formato, consulta la [documentazione su cloud-init](https://cloudinit.readthedocs.io/en/latest/explanation/format.html). 

Per passare i dati utente quando usi la procedura guidata di avvio di Amazon EC2, consulta [Avvio di un'istanza di container Linux di Amazon ECS](launch_container_instance.md).

È possibile configurare l'istanza di container per trasmettere i dati nella configurazione dell'agente del container o nella configurazione del daemon Docker.

## Agente del container Amazon ECS
<a name="bootstrap_container_agent"></a>

Le varianti Linux dell'AMI ottimizzata per Amazon ECS cercano i dati di configurazione dell'agente nel file `/etc/ecs/ecs.config` all'avvio dell'agente del container. Puoi specificare questi dati di configurazione al momento dell'avvio con i dati utente di Amazon EC2. Per ulteriori informazioni sulle variabili di configurazione per l'agente del container di Amazon ECS disponibili, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md).

Per impostare una sola variabile di configurazione dell'agente, ad esempio il nome del cluster, utilizza **echo** per copiare la variabile nel file di configurazione:

```
#!/bin/bash
echo "ECS_CLUSTER=MyCluster" >> /etc/ecs/ecs.config
```

Per scrivere più variabili nel file `/etc/ecs/ecs.config`, utilizza il formato `heredoc` illustrato di seguito. Questo formato scrive tutti gli elementi nel file di configurazione, inserendoli tra le righe **cat** ed `EOF`.

```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
ECS_LOGLEVEL=debug
ECS_WARM_POOLS_CHECK=true
EOF
```

Per impostare gli attributi di istanza personalizzati, imposta la variabile di ambiente `ECS_INSTANCE_ATTRIBUTES`.

```
#!/bin/bash
cat <<'EOF' >> ecs.config
ECS_INSTANCE_ATTRIBUTES={"envtype":"prod"}
EOF
```

## Daemon Docker
<a name="bootstrap_docker_daemon"></a>

È possibile specificare le informazioni di configurazione del daemon Docker con i dati utente Amazon EC2. Per ulteriori informazioni sulle opzioni di configurazione, consulta la [documentazione del daemon Docker](https://docs.docker.com/reference/cli/dockerd/).

**Nota**  
AWS non supporta configurazioni Docker personalizzate, perché a volte possono entrare in conflitto con le future modifiche o funzionalità di Amazon ECS senza preavviso.

Nell'esempio riportato di seguito, le opzioni personalizzate vengono aggiunte al file di configurazione del daemon Docker, `/etc/docker/daemon.json`, che viene quindi specificato nei dati utente all'avvio dell'istanza.

```
#!/bin/bash
cat <<EOF >/etc/docker/daemon.json
{"debug": true}
EOF
systemctl restart docker --no-block
```

Nell'esempio riportato di seguito, le opzioni personalizzate vengono aggiunte al file di configurazione del daemon Docker, `/etc/docker/daemon.json`, che viene quindi specificato nei dati utente all'avvio dell'istanza. Questo esempio mostra come disattivare il docker-proxy nel file di configurazione del daemon Docker.

```
#!/bin/bash
cat <<EOF >/etc/docker/daemon.json
{"userland-proxy": false}
EOF
systemctl restart docker --no-block
```

# Configurazione delle istanze di container Amazon ECS Linux per ricevere avvisi sulle istanze spot
<a name="spot-instance-draining-linux-container"></a>

Amazon EC2 termina, arresta o iberna l'istanza Spot quando il prezzo Spot supera il prezzo massimo per la richiesta o la capacità non è più disponibile. Amazon EC2 fornisce un preavviso di due minuti di interruzione dell'istanza Spot per le operazioni di terminazione e interruzione. Non fornisce l'avviso di due minuti per l'operazione di ibernazione. Se la funzione di drenaggio dell'istanza Spot di Amazon ECS è abilitata sull'istanza, Amazon ECS riceve l'avviso di interruzione dell'istanza spot e posiziona l'istanza nello stato `DRAINING`. 

**Importante**  
Amazon ECS non riceve alcun avviso da Amazon EC2 quando le istanze vengono rimosse da Ribilanciamento della capacità di Auto Scaling. Per ulteriori informazioni, consulta [Ribilanciamento della capacità di Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html).

Quando un'istanza di container è impostata su `DRAINING`, Amazon ECS impedisce che venga pianificato il posizionamento di nuovi processi nell'istanza di container. Le attività di servizio nell'istanza di container di esaurimento che sono in stato `PENDING` vengono interrotte immediatamente. Se nel cluster sono disponibili istanze di container, le attività del servizio di sostituzione vengono avviate su di esse.

La funzione di esaurimento dell'istanza spot è disattivata per impostazione predefinita. 

Puoi attivare lo svuotamento dell'istanza spot all'avvio di un'istanza. Aggiungi il seguente script nel campo **Dati utente**. *MyCluster*Sostituiscilo con il nome del cluster in cui registrare l'istanza del contenitore.

```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
EOF
```

Per ulteriori informazioni, consulta [Avvio di un'istanza di container Linux di Amazon ECS](launch_container_instance.md).

**Per attivare lo svuotamento dell'istanza Spot per un'istanza di container esistente**

1. Connettiti all'istanza Spot su SSH.

1. Modifica il file `/etc/ecs/ecs.config` e aggiungi quanto segue:

   ```
   ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
   ```

1. Riavvia il servizio `ecs`.
   + Per l'AMI Amazon Linux 2 ottimizzata per Amazon ECS:

     ```
     sudo systemctl restart ecs
     ```

1. (Facoltativo) Puoi verificare se l'agente è in esecuzione e visualizzare alcune informazioni sulla nuova istanza di container interrogando l'operazione API di introspezione dell'agente. Per ulteriori informazioni, consulta [Introspezione del container di Amazon ECS](ecs-agent-introspection.md).

   ```
   curl http://localhost:51678/v1/metadata
   ```

# Esecuzione di uno script quando si avvia un'istanza di container Linux di Amazon ECS
<a name="start_task_at_launch"></a>

Potresti dover eseguire un container specifico per ogni istanza di container per gestire operazioni o problemi di sicurezza, ad esempio il monitoraggio, la sicurezza, i parametri, il rilevamento servizi o la creazione di log.

Per eseguire questa operazione, puoi configurare le istanze di container per chiamare il comando **docker run** con lo script di dati utente all'avvio o in un sistema di inizializzazione come Upstart o **systemd**. Anche se questo metodo funziona, presenta di alcuni svantaggi perché Amazon ECS non conosce i container e non può monitorare CPU, memoria, porte o le altre risorse utilizzate. Per garantire che Amazon ECS tenga correttamente conto di tutte le risorse delle attività, crea una definizione di attività per il container per l'esecuzione nelle istanze di container. Quindi, utilizza Amazon ECS per posizionare il processo al momento dell'avvio con i dati utente di Amazon EC2.

Lo script di dati utente di Amazon EC2 nella procedura seguente utilizza l'API di introspezione di Amazon ECS per identificare l'istanza di container. Quindi, utilizza il AWS CLI **start-task** comando and per eseguire un'attività specificata su se stessa durante l'avvio. 

**Per avviare un'attività al momento dell'avvio di un'istanza di container**

1. Modifica il ruolo IAM `ecsInstanceRole` per aggiungere le autorizzazioni per l'operazione API `StartTask`. Per ulteriori informazioni, consulta [Aggiornare autorizzazioni per un ruolo](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_update-role-permissions.html) nella *AWS Identity and Access Management Guida per l'utente *.

1. Avvia una o più istanze di container usando l'AMI Amazon Linux 2 ottimizzata per Amazon ECS. Avvia nuove istanze di container e utilizza il seguente script di esempio nei dati utente EC2. Sostituisci *your\$1cluster\$1name* con il cluster l'istanza del contenitore in cui registrarsi e *my\$1task\$1def* con la definizione dell'attività da eseguire sull'istanza all'avvio. 

   Per ulteriori informazioni, consulta [Avvio di un'istanza di container Linux di Amazon ECS](launch_container_instance.md).
**Nota**  
Il contenuto MIME in più parti mostrato di seguito usa uno script di shell per impostare i valori di configurazione e installare pacchetti. Utilizza anche un processo systemd per avviare l'attività una volta che il servizio **ecs** è in esecuzione e l'API di introspezione è disponibile.

   ```
   Content-Type: multipart/mixed; boundary="==BOUNDARY=="
   MIME-Version: 1.0
   
   --==BOUNDARY==
   Content-Type: text/x-shellscript; charset="us-ascii"
   
   #!/bin/bash
   # Specify the cluster that the container instance should register into
   cluster=your_cluster_name
   
   # Write the cluster configuration variable to the ecs.config file
   # (add any other configuration variables here also)
   echo ECS_CLUSTER=$cluster >> /etc/ecs/ecs.config
   
   START_TASK_SCRIPT_FILE="/etc/ecs/ecs-start-task.sh"
   cat <<- 'EOF' > ${START_TASK_SCRIPT_FILE}
   	exec 2>>/var/log/ecs/ecs-start-task.log
   	set -x
   	
   	# Install prerequisite tools
   	yum install -y jq aws-cli
   	
   	# Wait for the ECS service to be responsive
   	until curl -s http://localhost:51678/v1/metadata
   	do
   		sleep 1
   	done
   
   	# Grab the container instance ARN and AWS Region from instance metadata
   	instance_arn=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F/ '{print $NF}' )
   	cluster=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .Cluster' | awk -F/ '{print $NF}' )
   	region=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F: '{print $4}')
   
   	# Specify the task definition to run at launch
   	task_definition=my_task_def
   
   	# Run the AWS CLI start-task command to start your task on this container instance
   	aws ecs start-task --cluster $cluster --task-definition $task_definition --container-instances $instance_arn --started-by $instance_arn --region $region
   EOF
   
   # Write systemd unit file
   UNIT="ecs-start-task.service"
   cat <<- EOF > /etc/systemd/system/${UNIT}
         [Unit]
         Description=ECS Start Task
         Requires=ecs.service
         After=ecs.service
    
         [Service]
         Restart=on-failure
         RestartSec=30
         ExecStart=/usr/bin/bash ${START_TASK_SCRIPT_FILE}
   
         [Install]
         WantedBy=default.target
   EOF
   
   # Enable our ecs.service dependent service with `--no-block` to prevent systemd deadlock
   # See https://github.com/aws/amazon-ecs-agent/issues/1707
   systemctl enable --now --no-block "${UNIT}"
   --==BOUNDARY==--
   ```

1. Verifica che le istanze di container vengano avviate nel cluster corretto e che le attività siano state avviate.

   1. Apri la console nella [https://console.aws.amazon.com/ecs/versione 2](https://console.aws.amazon.com/ecs/v2).

   1. Dalla barra di navigazione, scegli la regione in cui si trova il cluster.

   1. Nel pannello di navigazione, scegli **Clusters** (Cluster) e seleziona il cluster che ospita le istanze di container.

   1. Nella pagina **Cluster**, seleziona **Attività** e quindi le tue attività.

      Su ogni istanza di container che hai avviato dovrebbe essere in esecuzione la tua attività.

      Se non visualizzi le attività, puoi accedere alle istanze di container con SSH e controllare le informazioni di debug nel file `/var/log/ecs/ecs-start-task.log`.

# Aumento delle interfacce di rete delle istanze di container Linux di Amazon ECS
<a name="container-instance-eni"></a>

**Nota**  
Questa funzione non è disponibile su Fargate.

Ogni attività che utilizza la modalità di rete `awsvpc` riceve una propria interfaccia (ENI) di rete elastica, che è collegata all'istanza di container che la ospita. Esiste un limite di default al numero di interfacce di rete che possono essere collegate a un'istanza di Amazon EC2 e l'interfaccia di rete primaria viene conteggiata come una di queste. Ad esempio, per impostazione predefinita, a un'`c5.large`istanza possono essere ENIs collegate fino a tre istanze. L'interfaccia di rete principale per l'istanza conta come una sola, quindi è possibile collegarne altre due ENIs all'istanza. Poiché ogni attività che utilizza la modalità di rete `awsvpc` richiede un'ENI, in genere puoi eseguire solo due attività su questo tipo di istanza.

Amazon ECS supporta l'avvio di istanze di container con densità ENI aumentata mediante i tipi di istanze Amazon EC2 supportati. Quando si utilizzano questi tipi di istanze e si attiva l'impostazione dell'`awsvpcTrunking`account, ENIs ne sono disponibili altri nelle istanze di container appena avviate. Questa configurazione consente di posizionare più attività su ciascuna istanza di container. Per usare la console per attivare la funzionalità, consulta [Modifica delle impostazioni dell'account Amazon ECS](ecs-modifying-longer-id-settings.md). Per utilizzare l'opzione AWS CLI per attivare la funzionalità, consulta[Gestione delle impostazioni dell'account Amazon ECS utilizzando AWS CLI](account-setting-management-cli.md). 

Ad esempio, un'istanza `c5.large` con `awsvpcTrunking` ha un limite ENI aumentato di dodici. L'istanza di container avrà un'interfaccia di rete primaria e Amazon ECS crea e collega un'interfaccia di rete "trunk" all'istanza di container. Pertanto, questa configurazione consente di avviare dieci attività sull'istanza di container anziché le due attività correnti.

L'interfaccia di rete trunk è completamente gestita da Amazon ECS e viene eliminata quando termini o annulli la registrazione dell'istanza di container dal cluster. Per ulteriori informazioni, consulta [Opzioni di rete di attività di Amazon ECS per EC2](task-networking.md).

## Considerazioni
<a name="eni-trunking-considerations"></a>

Tieni in considerazione le seguenti informazioni quando usi la funzionalità di trunking ENI.
+ Solo le varianti Linux dell'AMI ottimizzata per Amazon ECS o altre varianti Amazon Linux con versione `1.28.1` o successiva dell'agente del container e versione `1.28.1-2` o successiva del pacchetto ecs-init, supportano i limiti ENI aumentati. Se utilizzi la variante Linux più recente dell'AMI ottimizzata per Amazon ECS, questi requisiti saranno soddisfatti. I container Windows non sono al momento supportati.
+ Solo nuove istanze Amazon EC2 avviate dopo l'attivazione a `awsvpcTrunking` ricevono i limiti ENI aumentati e l'interfaccia di rete trunk. In precedenza, le istanze avviate non ricevevano queste caratteristiche, a prescindere dalle operazioni eseguite.
+ Le istanze Amazon EC2 devono avere le richieste DNS basate sulle risorse IPv4 disattivate. Per disabilitare questa opzione, deseleziona l'opzione **Abilita richieste DNS basate su risorse IPV4 (A record)** quando crei una nuova istanza nella console Amazon EC2. Per disabilitare questa opzione utilizzando AWS CLI, usa il seguente comando.

  ```
  aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
  ```
+ Le istanze Amazon EC2 nelle sottoreti condivise non sono supportate. Se vengono utilizzate, non riescono a eseguire la registrazione a un cluster.
+ Le attività devono utilizzare la modalità di rete `awsvpc` e l'EC2. Le attività che usano Fargate hanno sempre ricevuto un'ENI dedicata a prescindere da quante vengono avviate, pertanto questa funzionalità non è necessaria.
+ Le attività devono essere avviate nello stesso Amazon VPC dell'istanza di container. Le tue attività non verranno avviate con un errore di attributo se non sono all'interno dello stesso VPC.
+ Quando si avvia una nuova istanza di container, l'istanza effettua la transizione a uno stato `REGISTERING` mentre viene eseguito il provisioning dell'interfaccia di rete elastica trunk per l'istanza. Se la registrazione ha esito negativo, l'istanza esegue la transizione a uno stato `REGISTRATION_FAILED`. È possibile risolvere i problemi relativi a una registrazione non riuscita descrivendo l'istanza di container per visualizzare il campo `statusReason` che descrive il motivo dell'errore. L'istanza di container può quindi essere annullata manualmente o terminata. Una volta annullata la registrazione o terminata l'istanza di container, Amazon ECS eliminerà l'ENI trunk.
**Nota**  
Amazon ECS emette eventi di modifica dello stato dell'istanza di container che è possibile monitorare per le istanze che passano a uno stato `REGISTRATION_FAILED`. Per ulteriori informazioni, consulta [Eventi di modifica dello stato delle istanze di container di Amazon ECS](ecs_container_instance_events.md).
+ Al termine dell'istanza di container, l'istanza esegue la transizione a uno stato `DEREGISTERING` mentre viene annullato il provisioning dell'interfaccia di rete elastica trunk. L'istanza quindi esegue la transizione a uno stato `INACTIVE`.
+ Se un'istanza di container in una sottorete pubblica con limiti ENI aumentati viene interrotta e quindi riavviata, l'istanza perde il suo indirizzo IP pubblico e l'agente del container perde la sua connessione.
+ Quando abiliti `awsvpcTrunking`, le istanze di container ricevono un'ENI aggiuntiva che utilizza il gruppo di sicurezza predefinito del VPC ed è gestita da Amazon ECS.

  Un VPC di default include una sottorete pubblica in ogni zona di disponibilità, un gateway Internet e impostazioni per abilitare la risoluzione DNS. La sottorete è pubblica perché la tabella di routing principale invia il traffico della sottorete destinato a Internet al gateway Internet. Puoi rendere una sottorete predefinita privata rimuovendo la route dalla destinazione 0.0.0.0/0 all'Internet Gateway. Tuttavia, in questo caso, nessuna istanza di container in esecuzione in tale sottorete può accedere a Internet. Puoi aggiungere o eliminare le regole dei gruppi di sicurezza per controllare il traffico in entrata e in uscita dalle sottoreti. Per ulteriori informazioni, consulta [Regole del gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) nella *Guida per l'utente del Amazon Virtual Private Cloud*.

## Prerequisiti
<a name="eni-trunking-launching"></a>

Prima di avviare un'istanza di container con limiti ENI aumentati, è necessario completare i seguenti requisiti preliminari.
+ Il ruolo collegato ai servizi per Amazon ECS deve essere creato. Il ruolo collegato al servizio Amazon ECS fornisce ad Amazon ECS le autorizzazioni per effettuare chiamate ad altri AWS servizi per tuo conto. Questo ruolo viene creato automaticamente quando crei un cluster oppure quando crei o aggiorni un servizio nella Console di gestione AWS. Per ulteriori informazioni, consulta [Uso di ruoli collegati ai servizi per Amazon ECS](using-service-linked-roles.md). Puoi anche creare il ruolo collegato al servizio con il seguente comando. AWS CLI 

  ```
  aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com
  ```
+ Il ruolo IAM dell'account o dell'istanza di container deve abilitare le impostazioni dell'account `awsvpcTrunking`. Consigliamo di creare 2 ruoli dell'istanza di container (`ecsInstanceRole`). È quindi possibile abilitare l'impostazione dell'account `awsvpcTrunking` per un ruolo e usare quel ruolo per attività che richiedono il trunking ENI. Per ulteriori informazioni sulle istanze di container, consulta [Ruolo IAM delle istanze di container Amazon ECS](instance_IAM_role.md).

Dopo che i requisiti preliminari sono soddisfatti, puoi avviare una nuova istanza di container utilizzando uno dei tipi di istanze Amazon EC2 supportati; l'istanza avrà i limiti ENI aumentati. Per una lista di tipi di istanze supportate, consulta [Istanze supportate per un potenziamento delle interfacce di rete dei container Amazon ECS](eni-trunking-supported-instance-types.md). La versione dell'istanza di container per l'agente del container deve essere `1.28.1` o successiva e la versione del pacchetto ecs-init deve essere `1.28.1-2` o successiva. Se utilizzi la variante Linux più recente dell'AMI ottimizzata per Amazon ECS, questi requisiti saranno soddisfatti. Per ulteriori informazioni, consulta [Avvio di un'istanza di container Linux di Amazon ECS](launch_container_instance.md).

**Importante**  
Le istanze Amazon EC2 devono avere le richieste DNS basate sulle risorse IPv4 disattivate. Per disabilitare questa opzione, assicurati che l'opzione **Abilita richieste DNS basate su risorse IPV4 (A record)** sia deselezionata quando crei una nuova istanza utilizzando la console Amazon EC2. Per disabilitare questa opzione utilizzando, usa il AWS CLI seguente comando.  

```
aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
```

**Per visualizzare le istanze del contenitore con ENI limiti maggiori con il AWS CLI**

Ogni istanza di container dispone di un'interfaccia di rete predefinita, nota anche come interfaccia di rete trunk. Utilizza il comando seguente per visualizzare un elenco di istanze di container con limiti ENI aumentati eseguendo una query dell'attributo `ecs.awsvpc-trunk-id`, che indica che dispone di un'interfaccia di rete trunk.
+ [list-attributes](https://docs.aws.amazon.com/cli/latest/reference/ecs/list-attributes.html) (AWS CLI)

  ```
  aws ecs list-attributes \
        --target-type container-instance \
        --attribute-name ecs.awsvpc-trunk-id \
        --cluster cluster_name \
        --region us-east-1
  ```
+ [Get- ECSAttribute List](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ECSAttributeList.html) ()AWS Tools for Windows PowerShell

  ```
  Get-ECSAttributeList -TargetType container-instance -AttributeName ecs.awsvpc-trunk-id -Region us-east-1
  ```

# Istanze supportate per un potenziamento delle interfacce di rete dei container Amazon ECS
<a name="eni-trunking-supported-instance-types"></a>

Di seguito vengono visualizzati i tipi di istanze Amazon EC2 supportati e il numero di attività che usano la modalità di rete `awsvpc` che è possibile avviare su ogni tipo di istanza prima e dopo aver abilitato l'impostazione dell'account `awsvpcTrunking`. 

**Importante**  
Sebbene altri tipi di istanza siano supportati nella stessa famiglia di istanze, i tipi di istanza `a1.metal`, `c5.metal`, `c5a.8xlarge`, `c5ad.8xlarge`, `c5d.metal`, `m5.metal`, `p3dn.24xlarge`, `r5.metal`, `r5.8xlarge` e `r5d.metal` non sono supportati.  
Le famiglie di istanze `c5n`, `d3`, `d3en`, `g3`, `g3s`, `g4dn`, `i3`, `i3en`, `inf1`, `m5dn`, `m5n`, `m5zn`, `mac1`, `r5b`, `r5n`, `r5dn`, `u-12tb1`, `u-6tb1`, `u-9tb1` e `z1d` non sono supportate.

**Topics**
+ [

## Uso generale
](#eni-branch-gp)
+ [

## Calcolo ottimizzato
](#eni-branch-co)
+ [

## Memoria ottimizzata
](#eni-branch-mo)
+ [

## Archiviazione ottimizzata
](#eni-branch-so)
+ [

## Elaborazione accelerata
](#eni-branch-ac)
+ [

## High Performance Computing
](#eni-branch-hpc)

## Uso generale
<a name="eni-branch-gp"></a>


| Tipo di istanza | Limite di attività senza trunking ENI | Limite di attività con trunking ENI | 
| --- | --- | --- | 
| a1.medium | 1 | 10 | 
| a1.large | 2 | 10 | 
| a1.xlarge | 3 | 20 | 
| a1.2xlarge | 3 | 40 | 
| a1.4xlarge | 7 | 60 | 
| m5.large | 2 | 10 | 
| m5.xlarge | 3 | 20 | 
| m5.2xlarge | 3 | 40 | 
| m5.4xlarge | 7 | 60 | 
| m5.8xlarge | 7 | 60 | 
| m5.12xlarge | 7 | 60 | 
| m5.16xlarge | 14 | 120 | 
| m5.24xlarge | 14 | 120 | 
| m5a.large | 2 | 10 | 
| m5a.xlarge | 3 | 20 | 
| m5a.2xlarge | 3 | 40 | 
| m5a.4xlarge | 7 | 60 | 
| m5a.8xlarge | 7 | 60 | 
| m5a.12xlarge | 7 | 60 | 
| m5a.16xlarge | 14 | 120 | 
| m5a.24xlarge | 14 | 120 | 
| m5ad.large | 2 | 10 | 
| m5ad.xlarge | 3 | 20 | 
| m5ad.2xlarge | 3 | 40 | 
| m5ad.4xlarge | 7 | 60 | 
| m5ad.8xlarge | 7 | 60 | 
| m5ad.12xlarge | 7 | 60 | 
| m5ad.16xlarge | 14 | 120 | 
| m5ad.24xlarge | 14 | 120 | 
| m5d.large | 2 | 10 | 
| m5d.xlarge | 3 | 20 | 
| m5d.2xlarge | 3 | 40 | 
| m5d.4xlarge | 7 | 60 | 
| m5d.8xlarge | 7 | 60 | 
| m5d.12xlarge | 7 | 60 | 
| m5d.16xlarge | 14 | 120 | 
| m5d.24xlarge | 14 | 120 | 
| m5d.metal | 14 | 120 | 
| m6a.large | 2 | 10 | 
| m6a.xlarge | 3 | 20 | 
| m6a.2xlarge | 3 | 40 | 
| m6a.4xlarge | 7 | 60 | 
| m6a.8xlarge | 7 | 90 | 
| m6a.12xlarge | 7 | 120 | 
| m6a.16xlarge | 14 | 120 | 
| m6a.24xlarge | 14 | 120 | 
| m6a.32xlarge | 14 | 120 | 
| m6a.48xlarge | 14 | 120 | 
| m6a.metal | 14 | 120 | 
| m6g.medium | 1 | 4 | 
| m6g.large | 2 | 10 | 
| m6g.xlarge | 3 | 20 | 
| m6g.2xlarge | 3 | 40 | 
| m6g.4xlarge | 7 | 60 | 
| m6g.8xlarge | 7 | 60 | 
| m6g.12xlarge | 7 | 60 | 
| m6g.16xlarge | 14 | 120 | 
| m6g.metal | 14 | 120 | 
| m6gd.medium | 1 | 4 | 
| m6gd.large | 2 | 10 | 
| m6gd.xlarge | 3 | 20 | 
| m6gd.2xlarge | 3 | 40 | 
| m6gd.4xlarge | 7 | 60 | 
| m6gd.8xlarge | 7 | 60 | 
| m6gd.12xlarge | 7 | 60 | 
| m6gd.16xlarge | 14 | 120 | 
| m6gd.metal | 14 | 120 | 
| m6i.large | 2 | 10 | 
| m6i.xlarge | 3 | 20 | 
| m6i.2xlarge | 3 | 40 | 
| m6i.4xlarge | 7 | 60 | 
| m6i.8xlarge | 7 | 90 | 
| m6i.12xlarge | 7 | 120 | 
| m6i.16xlarge | 14 | 120 | 
| m6i.24xlarge | 14 | 120 | 
| m6i.32xlarge | 14 | 120 | 
| m6i.metal | 14 | 120 | 
| m6id.large | 2 | 10 | 
| m6id.xlarge | 3 | 20 | 
| m6id.2xlarge | 3 | 40 | 
| m6id.4xlarge | 7 | 60 | 
| m6id.8xlarge | 7 | 90 | 
| m6id.12xlarge | 7 | 120 | 
| m6id.16xlarge | 14 | 120 | 
| m6id.24xlarge | 14 | 120 | 
| m6id.32xlarge | 14 | 120 | 
| m6id.metal | 14 | 120 | 
| m6idn.large | 2 | 10 | 
| m6idn.xlarge | 3 | 20 | 
| m6idn.2xlarge | 3 | 40 | 
| m6idn.4xlarge | 7 | 60 | 
| m6idn.8xlarge | 7 | 90 | 
| m6idn.12xlarge | 7 | 120 | 
| m6idn.16xlarge | 14 | 120 | 
| m6idn.24xlarge | 14 | 120 | 
| m6idn.32xlarge | 15 | 120 | 
| m6idn.metal | 15 | 120 | 
| m6in.large | 2 | 10 | 
| m6in.xlarge | 3 | 20 | 
| m6in.2xlarge | 3 | 40 | 
| m6in.4xlarge | 7 | 60 | 
| m6in.8xlarge | 7 | 90 | 
| m6in.12xlarge | 7 | 120 | 
| m6in.16xlarge | 14 | 120 | 
| m6in.24xlarge | 14 | 120 | 
| m6in.32xlarge | 15 | 120 | 
| m6in.metal | 15 | 120 | 
| m7a.medium | 1 | 4 | 
| m7a.large | 2 | 10 | 
| m7a.xlarge | 3 | 20 | 
| m7a.2xlarge | 3 | 40 | 
| m7a.4xlarge | 7 | 60 | 
| m7a.8xlarge | 7 | 90 | 
| m7a.12xlarge | 7 | 120 | 
| m7a.16xlarge | 14 | 120 | 
| m7a.24xlarge | 14 | 120 | 
| m7a.32xlarge | 14 | 120 | 
| m7a.48xlarge | 14 | 120 | 
| m7a.metal-48xl | 14 | 120 | 
| m7g.medium | 1 | 4 | 
| m7g.large | 2 | 10 | 
| m7g.xlarge | 3 | 20 | 
| m7g.2xlarge | 3 | 40 | 
| m7g.4xlarge | 7 | 60 | 
| m7g.8xlarge | 7 | 60 | 
| m7g.12xlarge | 7 | 60 | 
| m7g.16xlarge | 14 | 120 | 
| m7g.metal | 14 | 120 | 
| m7gd.medium | 1 | 4 | 
| m7gd.large | 2 | 10 | 
| m7gd.xlarge | 3 | 20 | 
| m7gd.2xlarge | 3 | 40 | 
| m7gd.4xlarge | 7 | 60 | 
| m7gd.8xlarge | 7 | 60 | 
| m7gd.12xlarge | 7 | 60 | 
| m7gd.16xlarge | 14 | 120 | 
| m7gd.metal | 14 | 120 | 
| m7i.large | 2 | 10 | 
| m7i.xlarge | 3 | 20 | 
| m7i.2xlarge | 3 | 40 | 
| m7i.4xlarge | 7 | 60 | 
| m7i.8xlarge | 7 | 90 | 
| m7i.12xlarge | 7 | 120 | 
| m7i.16xlarge | 14 | 120 | 
| m7i.24xlarge | 14 | 120 | 
| m7a.48xlarge | 14 | 120 | 
| m7i.metal-24xl | 14 | 120 | 
| m7i.metal-48xl | 14 | 120 | 
| m7i-flex.large | 2 | 4 | 
| m7i-flex.xlarge | 3 | 10 | 
| m7i-flex.2xlarge | 3 | 20 | 
| m7i-flex.4xlarge | 7 | 40 | 
| m7i-flex.8xlarge | 7 | 60 | 
| m7i-flex.12xlarge | 7 | 120 | 
| m7i-flex.16xlarge | 14 | 120 | 
| m8a.medium | 1 | 4 | 
| m8a.large | 2 | 10 | 
| m8a.xlarge | 3 | 20 | 
| m8a.2x grande | 3 | 40 | 
| m8a. 4x grande | 7 | 60 | 
| m8a.8x grande | 9 | 90 | 
| m8a.12 x grande | 11 | 120 | 
| m8a. 16 x grande | 15 | 120 | 
| m8a. 24x grande | 15 | 120 | 
| m8a. 48 x grande | 23 | 120 | 
| m8a.metal-24xl | 15 | 120 | 
| m8a.metal-48xl | 23 | 120 | 
| m8azn. medio | 2 | 4 | 
| m8azn.grande | 3 | 10 | 
| m8azn.xlarge | 3 | 20 | 
| m8azn. 3x grande | 7 | 40 | 
| m8azn. 6 x grande | 7 | 60 | 
| m8azn. 12 x grande | 15 | 120 | 
| m8azn. 24 x grande | 15 | 120 | 
| m8azn.in metallo - 12xl | 15 | 120 | 
| m8azn.metallo-24xl | 15 | 120 | 
| m8g.medium | 1 | 4 | 
| m8g.large | 2 | 10 | 
| m8g.xlarge | 3 | 20 | 
| m8g.2xlarge | 3 | 40 | 
| m8g.4xlarge | 7 | 60 | 
| m8g.8xlarge | 7 | 60 | 
| m8g.12xlarge | 7 | 60 | 
| m8g.16xlarge | 14 | 120 | 
| m8g.24xlarge | 14 | 120 | 
| m8g.48xlarge | 14 | 120 | 
| m8g.metal-24xl | 14 | 120 | 
| m8g.metal-48xl | 14 | 120 | 
| 8 mgb. medio | 1 | 4 | 
| m8 gb. grande | 2 | 10 | 
| m8gb.xlarge | 3 | 20 | 
| m8 gb.2xlarge | 3 | 40 | 
| m8 gb.4xlarge | 7 | 60 | 
| m8 gb.8xlarge | 9 | 60 | 
| m8 gb.12xlarge | 11 | 60 | 
| m8 gb. 16 x grande | 15 | 120 | 
| m8 gb.24xlarge | 23 | 120 | 
| m8gb.48xlarge | 23 | 120 | 
| m8 gb. metal-24xl | 23 | 120 | 
| m8gb.metallo-48xl | 23 | 120 | 
| m8gd.medium | 1 | 4 | 
| m8gd.large | 2 | 10 | 
| m8gd.xlarge | 3 | 20 | 
| m8gd.2xlarge | 3 | 40 | 
| m8gd.4xlarge | 7 | 60 | 
| m8gd.8xlarge | 7 | 60 | 
| m8gd.12xlarge | 7 | 60 | 
| m8gd.16xlarge | 14 | 120 | 
| m8gd.24xlarge | 14 | 120 | 
| m8gd.48xlarge | 14 | 120 | 
| m8gd.metal-24xl | 14 | 120 | 
| m8gd.metal-48xl | 14 | 120 | 
| m8gn. medio | 1 | 4 | 
| m8gn.grande | 2 | 10 | 
| m8gn.xlarge | 3 | 20 | 
| m8gn.2x grande | 3 | 40 | 
| m8gn. 4x grande | 7 | 60 | 
| m8gn. 8x grande | 9 | 60 | 
| m8 gn. 12 x grande | 11 | 60 | 
| m8 gn. 16 x grande | 15 | 120 | 
| m8 gn. 24 x grande | 23 | 120 | 
| m8 gn. 48 x grande | 23 | 120 | 
| m8gn.metal-24xl | 23 | 120 | 
| m8gn.metallo-48xl | 23 | 120 | 
| m8i.large | 2 | 10 | 
| m8i.xlarge | 3 | 20 | 
| m8i.2xlarge | 3 | 40 | 
| m8i.4xlarge | 7 | 60 | 
| m8i.8xlarge | 9 | 90 | 
| m8i.12xlarge | 11 | 120 | 
| m8i.16xlarge | 15 | 120 | 
| m8i.24xlarge | 15 | 120 | 
| m8i.32xlarge | 23 | 120 | 
| m8i.48xlarge | 23 | 120 | 
| m8i.96xlarge | 23 | 120 | 
| m8i.metal-48xl | 23 | 120 | 
| m8i.metal-96xl | 23 | 120 | 
| m8id.large | 2 | 10 | 
| m8id.xlarge | 3 | 20 | 
| m8id.2xlarge | 3 | 40 | 
| m8id.4xgrande | 7 | 60 | 
| m8id.8xgrande | 9 | 90 | 
| m8id.12 x grande | 11 | 120 | 
| m8id.16 x grande | 15 | 120 | 
| m8id.24xlarge | 15 | 120 | 
| m8id.32xlarge | 23 | 120 | 
| m8id.48 x grande | 23 | 120 | 
| m8id.96xlarge | 23 | 120 | 
| m8id.metal-48xl | 23 | 120 | 
| m8id.metal-96xl | 23 | 120 | 
| m8i-flex.large | 2 | 4 | 
| m8i-flex.xlarge | 3 | 10 | 
| m8i-flex.2xlarge | 3 | 20 | 
| m8i-flex.4xlarge | 7 | 40 | 
| m8i-flex.8xlarge | 9 | 60 | 
| m8i-flex.12xlarge | 11 | 120 | 
| m8i-flex.16xlarge | 15 | 120 | 
| mac2.metal | 7 | 12 | 
| mac2-m1ultra.metal | 7 | 12 | 
| mac2-m2.metal | 7 | 12 | 
| mac2-m2pro.metal | 7 | 12 | 
| mac-m4.metal | 7 | 12 | 
| mac-m4pro.metal | 7 | 12 | 
| mac-m4max.metal | 7 | 12 | 

## Calcolo ottimizzato
<a name="eni-branch-co"></a>


| Tipo di istanza | Limite di attività senza trunking ENI | Limite di attività con trunking ENI | 
| --- | --- | --- | 
| c5.large | 2 | 10 | 
| c5.xlarge | 3 | 20 | 
| c5.2xlarge | 3 | 40 | 
| c5.4xlarge | 7 | 60 | 
| c5.9xlarge | 7 | 60 | 
| c5.12xlarge | 7 | 60 | 
| c5.18xlarge | 14 | 120 | 
| c5.24xlarge | 14 | 120 | 
| c5a.large | 2 | 10 | 
| c5a.xlarge | 3 | 20 | 
| c5a.2xlarge | 3 | 40 | 
| c5a.4xlarge | 7 | 60 | 
| c5a.12xlarge | 7 | 60 | 
| c5a.16xlarge | 14 | 120 | 
| c5a.24xlarge | 14 | 120 | 
| c5ad.large | 2 | 10 | 
| c5ad.xlarge | 3 | 20 | 
| c5ad.2xlarge | 3 | 40 | 
| c5ad.4xlarge | 7 | 60 | 
| c5ad.12xlarge | 7 | 60 | 
| c5ad.16xlarge | 14 | 120 | 
| c5ad.24xlarge | 14 | 120 | 
| c5d.large | 2 | 10 | 
| c5d.xlarge | 3 | 20 | 
| c5d.2xlarge | 3 | 40 | 
| c5d.4xlarge | 7 | 60 | 
| c5d.9xlarge | 7 | 60 | 
| c5d.12xlarge | 7 | 60 | 
| c5d.18xlarge | 14 | 120 | 
| c5d.24xlarge | 14 | 120 | 
| c6a.large | 2 | 10 | 
| c6a.xlarge | 3 | 20 | 
| c6a.2xlarge | 3 | 40 | 
| c6a.4xlarge | 7 | 60 | 
| c6a.8xlarge | 7 | 90 | 
| c6a.12xlarge | 7 | 120 | 
| c6a.16xlarge | 14 | 120 | 
| c6a.24xlarge | 14 | 120 | 
| c6a.32xlarge | 14 | 120 | 
| c6a.48xlarge | 14 | 120 | 
| c6a.metal | 14 | 120 | 
| c6g.medium | 1 | 4 | 
| c6g.large | 2 | 10 | 
| c6g.xlarge | 3 | 20 | 
| c6g.2xlarge | 3 | 40 | 
| c6g.4xlarge | 7 | 60 | 
| c6g.8xlarge | 7 | 60 | 
| c6g.12xlarge | 7 | 60 | 
| c6g.16xlarge | 14 | 120 | 
| c6g.metal | 14 | 120 | 
| c6gd.medium | 1 | 4 | 
| c6gd.large | 2 | 10 | 
| c6gd.xlarge | 3 | 20 | 
| c6gd.2xlarge | 3 | 40 | 
| c6gd.4xlarge | 7 | 60 | 
| c6gd.8xlarge | 7 | 60 | 
| c6gd.12xlarge | 7 | 60 | 
| c6gd.16xlarge | 14 | 120 | 
| c6gd.metal | 14 | 120 | 
| c6gn.medium | 1 | 4 | 
| c6gn.large | 2 | 10 | 
| c6gn.xlarge | 3 | 20 | 
| c6gn.2xlarge | 3 | 40 | 
| c6gn.4xlarge | 7 | 60 | 
| c6gn.8xlarge | 7 | 60 | 
| c6gn.12xlarge | 7 | 60 | 
| c6gn.16xlarge | 14 | 120 | 
| c6i.large | 2 | 10 | 
| c6i.xlarge | 3 | 20 | 
| c6i.2xlarge | 3 | 40 | 
| c6i.4xlarge | 7 | 60 | 
| c6i.8xlarge | 7 | 90 | 
| c6i.12xlarge | 7 | 120 | 
| c6i.16xlarge | 14 | 120 | 
| c6i.24xlarge | 14 | 120 | 
| c6i.32xlarge | 14 | 120 | 
| c6i.metal | 14 | 120 | 
| c6id.large | 2 | 10 | 
| c6id.xlarge | 3 | 20 | 
| c6id.2xlarge | 3 | 40 | 
| c6id.4xlarge | 7 | 60 | 
| c6id.8xlarge | 7 | 90 | 
| c6id.12xlarge | 7 | 120 | 
| c6id.16xlarge | 14 | 120 | 
| c6id.24xlarge | 14 | 120 | 
| c6id.32xlarge | 14 | 120 | 
| c6id.metal | 14 | 120 | 
| c6in.large | 2 | 10 | 
| c6in.xlarge | 3 | 20 | 
| c6in.2xlarge | 3 | 40 | 
| c6in.4xlarge | 7 | 60 | 
| c6in.8xlarge | 7 | 90 | 
| c6in.12xlarge | 7 | 120 | 
| c6in.16xlarge | 14 | 120 | 
| c6in.24xlarge | 14 | 120 | 
| c6in.32xlarge | 15 | 120 | 
| c6in.metal | 15 | 120 | 
| c7a.medium | 1 | 4 | 
| c7a.large | 2 | 10 | 
| c7a.xlarge | 3 | 20 | 
| c7a.2xlarge | 3 | 40 | 
| c7a.4xlarge | 7 | 60 | 
| c7a.8xlarge | 7 | 90 | 
| c7a.12xlarge | 7 | 120 | 
| c7a.16xlarge | 14 | 120 | 
| c7a.24xlarge | 14 | 120 | 
| c7a.32xlarge | 14 | 120 | 
| c7a.48xlarge | 14 | 120 | 
| m7a.metal-48xl | 14 | 120 | 
| c7g.medium | 1 | 4 | 
| c7g.large | 2 | 10 | 
| c7g.xlarge | 3 | 20 | 
| c7g.2xlarge | 3 | 40 | 
| c7g.4xlarge | 7 | 60 | 
| c7g.8xlarge | 7 | 60 | 
| c7g.12xlarge | 7 | 60 | 
| c7g.16xlarge | 14 | 120 | 
| c7g.metal | 14 | 120 | 
| c7gd.medium | 1 | 4 | 
| c7gd.large | 2 | 10 | 
| c7gd.xlarge | 3 | 20 | 
| c7gd.2xlarge | 3 | 40 | 
| c7gd.4xlarge | 7 | 60 | 
| c7gd.8xlarge | 7 | 60 | 
| c7gd.12xlarge | 7 | 60 | 
| c7gd.16xlarge | 14 | 120 | 
| c7gd.metal | 14 | 120 | 
| c7gn.medium | 1 | 4 | 
| c7gn.large | 2 | 10 | 
| c7gn.xlarge | 3 | 20 | 
| c7gn.2xlarge | 3 | 40 | 
| c7gn.4xlarge | 7 | 60 | 
| c7gn.8xlarge | 7 | 60 | 
| c7gn.12xlarge | 7 | 60 | 
| c7gn.16xlarge | 14 | 120 | 
| c7gn.metal | 14 | 120 | 
| c7i.large | 2 | 10 | 
| c7i.xlarge | 3 | 20 | 
| c7i.2xlarge | 3 | 40 | 
| c7i.4xlarge | 7 | 60 | 
| c7i.8xlarge | 7 | 90 | 
| c7i.12xlarge | 7 | 120 | 
| c7i.16xlarge | 14 | 120 | 
| c7i.24xlarge | 14 | 120 | 
| c7i.48xlarge | 14 | 120 | 
| c7i.metal-24xl | 14 | 120 | 
| c7i.metal-48xl | 14 | 120 | 
| c7i-flex.large | 2 | 4 | 
| c7i-flex.xlarge | 3 | 10 | 
| c7i-flex.2xlarge | 3 | 20 | 
| c7i-flex.4xlarge | 7 | 40 | 
| c7i-flex.8xlarge | 7 | 60 | 
| c7i-flex.12xlarge | 7 | 120 | 
| c7i-flex.16xlarge | 14 | 120 | 
| c8a. medio | 1 | 4 | 
| c8a. grande | 2 | 10 | 
| c8a.xlarge | 3 | 20 | 
| c8a.2x grande | 3 | 40 | 
| c8a.4x grande | 7 | 60 | 
| c8a.8x grande | 9 | 90 | 
| c8a.12 x grande | 11 | 120 | 
| c8a.16 x grande | 15 | 120 | 
| c8a. 24 x grande | 15 | 120 | 
| c8a.48 x grande | 23 | 120 | 
| c8a.metal-24xl | 15 | 120 | 
| c8a.metal-48xl | 23 | 120 | 
| c8g.medium | 1 | 4 | 
| c8g.large | 2 | 10 | 
| c8g.xlarge | 3 | 20 | 
| c8g.2xlarge | 3 | 40 | 
| c8g.4xlarge | 7 | 60 | 
| c8g.8xlarge | 7 | 60 | 
| c8g.12xlarge | 7 | 60 | 
| c8g.16xlarge | 14 | 120 | 
| c8g.24xlarge | 14 | 120 | 
| c8g.48xlarge | 14 | 120 | 
| c8g.metal-24xl | 14 | 120 | 
| c8g.metal-48xl | 14 | 120 | 
| c8 gb. medio | 1 | 4 | 
| c8 gb. grande | 2 | 10 | 
| c8gb.xlarge | 3 | 20 | 
| c8 gb.2x grande | 3 | 40 | 
| c8 gb.4xlarge | 7 | 60 | 
| c8 gb.8xlarge | 9 | 60 | 
| c8gb.12xlarge | 11 | 60 | 
| c8 gb.16 x grande | 15 | 120 | 
| c8 gb.24xlarge | 23 | 120 | 
| c8 gb.48 x grande | 23 | 120 | 
| c8gb.metal-24xl | 23 | 120 | 
| c8gb.metallo-48xl | 23 | 120 | 
| c8gd.medium | 1 | 4 | 
| c8gd.large | 2 | 10 | 
| c8gd.xlarge | 3 | 20 | 
| c8gd.2xlarge | 3 | 40 | 
| c8gd.4xlarge | 7 | 60 | 
| c8gd.8xlarge | 7 | 60 | 
| c8gd.12xlarge | 7 | 60 | 
| c8gd.16xlarge | 14 | 120 | 
| c8gd.24xlarge | 14 | 120 | 
| c8gd.48xlarge | 14 | 120 | 
| c8gd.metal-24xl | 14 | 120 | 
| c8gd.metal-48xl | 14 | 120 | 
| c8gn.medium | 1 | 4 | 
| c8gn.large | 2 | 10 | 
| c8gn.xlarge | 3 | 20 | 
| c8gn.2xlarge | 3 | 40 | 
| c8gn.4xlarge | 7 | 60 | 
| c8gn.8xlarge | 9 | 60 | 
| c8gn.12xlarge | 11 | 60 | 
| c8gn.16xlarge | 15 | 120 | 
| c8gn.24xlarge | 23 | 120 | 
| c8gn.48xlarge | 23 | 120 | 
| c8gn.metal-24xl | 23 | 120 | 
| c8gn.metal-48xl | 23 | 120 | 
| c8i.large | 2 | 10 | 
| c8i.xlarge | 3 | 20 | 
| c8 i.2x grande | 3 | 40 | 
| c8i.4xgrande | 7 | 60 | 
| c8i.8xgrande | 9 | 90 | 
| c8i.12 x grande | 11 | 120 | 
| c8i.16 x grande | 15 | 120 | 
| c8i.24 x grande | 15 | 120 | 
| c8i.32xlarge | 23 | 120 | 
| c8i.48 x grande | 23 | 120 | 
| c8i.96xlarge | 23 | 120 | 
| c8i.metal-48xl | 23 | 120 | 
| c8i.metal-96xl | 23 | 120 | 
| c8 id. Grande | 2 | 10 | 
| c8id.xlarge | 3 | 20 | 
| c8id.2xlarge | 3 | 40 | 
| c8id.4xgrande | 7 | 60 | 
| c8id.8xgrande | 9 | 90 | 
| c8id.12xgrande | 11 | 120 | 
| c8id.16 x grande | 15 | 120 | 
| c8id.24xgrande | 15 | 120 | 
| c8id.32xgrande | 23 | 120 | 
| c8id.48 x grande | 23 | 120 | 
| c8id.96xlarge | 23 | 120 | 
| c8id.metal-48xl | 23 | 120 | 
| c8id.metal-96xl | 23 | 120 | 
| c8i-flex.large | 2 | 4 | 
| c8i-flex.xlarge | 3 | 10 | 
| c8i-flex.2xgrande | 3 | 20 | 
| c8i-flex.4xgrande | 7 | 40 | 
| c8i-flex.8x grande | 9 | 60 | 
| c8i-flex.12xgrande | 11 | 120 | 
| c8i-flex.16 x grande | 15 | 120 | 

## Memoria ottimizzata
<a name="eni-branch-mo"></a>


| Tipo di istanza | Limite di attività senza trunking ENI | Limite di attività con trunking ENI | 
| --- | --- | --- | 
| r5.large | 2 | 10 | 
| r5.xlarge | 3 | 20 | 
| r5.2xlarge | 3 | 40 | 
| r5.4xlarge | 7 | 60 | 
| r5.12xlarge | 7 | 60 | 
| r5.16xlarge | 14 | 120 | 
| r5.24xlarge | 14 | 120 | 
| r5a.large | 2 | 10 | 
| r5a.xlarge | 3 | 20 | 
| r5a.2xlarge | 3 | 40 | 
| r5a.4xlarge | 7 | 60 | 
| r5a.8xlarge | 7 | 60 | 
| r5a.12xlarge | 7 | 60 | 
| r5a.16xlarge | 14 | 120 | 
| r5a.24xlarge | 14 | 120 | 
| r5ad.large | 2 | 10 | 
| r5ad.xlarge | 3 | 20 | 
| r5ad.2xlarge | 3 | 40 | 
| r5ad.4xlarge | 7 | 60 | 
| r5ad.8xlarge | 7 | 60 | 
| r5ad.12xlarge | 7 | 60 | 
| r5ad.16xlarge | 14 | 120 | 
| r5ad.24xlarge | 14 | 120 | 
| r5b.16xlarge | 14 | 120 | 
| r5d.large | 2 | 10 | 
| r5d.xlarge | 3 | 20 | 
| r5d.2xlarge | 3 | 40 | 
| r5d.4xlarge | 7 | 60 | 
| r5d.8xlarge | 7 | 60 | 
| r5d.12xlarge | 7 | 60 | 
| r5d.16xlarge | 14 | 120 | 
| r5d.24xlarge | 14 | 120 | 
| r5dn.16xlarge | 14 | 120 | 
| r 6a. Grande | 2 | 10 | 
| r6a.xlarge | 3 | 20 | 
| r6a.2xlarge | 3 | 40 | 
| r6a.4xlarge | 7 | 60 | 
| r6a.8xlarge | 7 | 90 | 
| r6a.12xlarge | 7 | 120 | 
| r6a.16xlarge | 14 | 120 | 
| r6a.24xlarge | 14 | 120 | 
| r6a.32xlarge | 14 | 120 | 
| r6a.48xlarge | 14 | 120 | 
| r6a.metal | 14 | 120 | 
| r6g.medium | 1 | 4 | 
| r6g.large | 2 | 10 | 
| r6g.xlarge | 3 | 20 | 
| r6g.2xlarge | 3 | 40 | 
| r6g.4xlarge | 7 | 60 | 
| r6g.8xlarge | 7 | 60 | 
| r6g.12xlarge | 7 | 60 | 
| r6g.16xlarge | 14 | 120 | 
| r6g.metal | 14 | 120 | 
| r6gd.medium | 1 | 4 | 
| r6gd.large | 2 | 10 | 
| r6gd.xlarge | 3 | 20 | 
| r6gd.2xlarge | 3 | 40 | 
| r6gd.4xlarge | 7 | 60 | 
| r6gd.8xlarge | 7 | 60 | 
| r6gd.12xlarge | 7 | 60 | 
| r6gd.16xlarge | 14 | 120 | 
| r6gd.metal | 14 | 120 | 
| r6i.large | 2 | 10 | 
| r6i.xlarge | 3 | 20 | 
| r6i.2xlarge | 3 | 40 | 
| r6i.4xlarge | 7 | 60 | 
| r6i.8xlarge | 7 | 90 | 
| r6i.12xlarge | 7 | 120 | 
| r6i.16xlarge | 14 | 120 | 
| r6i.24xlarge | 14 | 120 | 
| r6i.32xlarge | 14 | 120 | 
| r6i.metal | 14 | 120 | 
| r6id.large | 2 | 10 | 
| r6id.xlarge | 3 | 20 | 
| r6id.2xlarge | 3 | 40 | 
| r6id.4xlarge | 7 | 60 | 
| r6id.8xlarge | 7 | 90 | 
| r6id.12xlarge | 7 | 120 | 
| r6id.16xlarge | 14 | 120 | 
| r6id.24xlarge | 14 | 120 | 
| r6id.32xlarge | 14 | 120 | 
| r6id. Metallo | 14 | 120 | 
| r6idn.large | 2 | 10 | 
| r6idn.xlarge | 3 | 20 | 
| r6idn.2xlarge | 3 | 40 | 
| r6idn.4xlarge | 7 | 60 | 
| r6idn.8xlarge | 7 | 90 | 
| r6idn.12xlarge | 7 | 120 | 
| r6idn.16xlarge | 14 | 120 | 
| r6idn.24xlarge | 14 | 120 | 
| r6idn.32xlarge | 15 | 120 | 
| r6idn.metal | 15 | 120 | 
| r6in.large | 2 | 10 | 
| r6in.xlarge | 3 | 20 | 
| r6in.2xlarge | 3 | 40 | 
| r6in.4xlarge | 7 | 60 | 
| r6in.8xlarge | 7 | 90 | 
| r6in.12xlarge | 7 | 120 | 
| r6in.16xlarge | 14 | 120 | 
| r6in.24xlarge | 14 | 120 | 
| r6in.32xlarge | 15 | 120 | 
| r6in.metal | 15 | 120 | 
| r7a. medio | 1 | 4 | 
| r7a.large | 2 | 10 | 
| r7a.xlarge | 3 | 20 | 
| r7a.2xlarge | 3 | 40 | 
| r7a.4xlarge | 7 | 60 | 
| r7a.8xlarge | 7 | 90 | 
| r7a.12xlarge | 7 | 120 | 
| r7a.16xlarge | 14 | 120 | 
| r7a.24xlarge | 14 | 120 | 
| r7a.32xlarge | 14 | 120 | 
| r7a.48xlarge | 14 | 120 | 
| m7a.metal-48xl | 14 | 120 | 
| r7g.medium | 1 | 4 | 
| r7g.large | 2 | 10 | 
| r7g.xlarge | 3 | 20 | 
| r7g.2xlarge | 3 | 40 | 
| r7g.4xlarge | 7 | 60 | 
| r7g.8xlarge | 7 | 60 | 
| r7g.12xlarge | 7 | 60 | 
| r7g.16xlarge | 14 | 120 | 
| r7g.metal | 14 | 120 | 
| r7gd.medium | 1 | 4 | 
| r7gd.large | 2 | 10 | 
| r7gd.xlarge | 3 | 20 | 
| r7gd.2xlarge | 3 | 40 | 
| r7gd.4xlarge | 7 | 60 | 
| r7gd.8xlarge | 7 | 60 | 
| r7gd.12xlarge | 7 | 60 | 
| r7gd.16xlarge | 14 | 120 | 
| r7gd.metal | 14 | 120 | 
| r7i.large | 2 | 10 | 
| r7i.xlarge | 3 | 20 | 
| r7i.2xlarge | 3 | 40 | 
| r7i.4xlarge | 7 | 60 | 
| r7i.8xlarge | 7 | 90 | 
| r7i.12xlarge | 7 | 120 | 
| r7i.16xlarge | 14 | 120 | 
| r7i.24xlarge | 14 | 120 | 
| r7i.48xlarge | 14 | 120 | 
| r7i.metal-24xl | 14 | 120 | 
| r7i.metal-48xl | 14 | 120 | 
| r7iz.large | 2 | 10 | 
| r7iz.xlarge | 3 | 20 | 
| r7iz.2xlarge | 3 | 40 | 
| r7iz.4xlarge | 7 | 60 | 
| r7iz.8xlarge | 7 | 90 | 
| r7iz.12xlarge | 7 | 120 | 
| r7iz.16xlarge | 14 | 120 | 
| r7iz.32xlarge | 14 | 120 | 
| r7iz.metal-16xl | 14 | 120 | 
| r7iz.metal-32xl | 14 | 120 | 
| r8a.medium | 1 | 4 | 
| r8a.large | 2 | 10 | 
| r8a.xlarge | 3 | 20 | 
| r8a.2x grande | 3 | 40 | 
| r8a.4xgrande | 7 | 60 | 
| r8a.8xgrande | 9 | 90 | 
| r8a.12 x grande | 11 | 120 | 
| r8a.16 x grande | 15 | 120 | 
| r8a.24xlarge | 15 | 120 | 
| r8a.48 x grande | 23 | 120 | 
| r8a.metal-24xl | 15 | 120 | 
| r8a.metal-48xl | 23 | 120 | 
| r8g.medium | 1 | 4 | 
| r8g.large | 2 | 10 | 
| r8g.xlarge | 3 | 20 | 
| r8g.2xlarge | 3 | 40 | 
| r8g.4xlarge | 7 | 60 | 
| r8g.8xlarge | 7 | 60 | 
| r8g.12xlarge | 7 | 60 | 
| r8g.16xlarge | 14 | 120 | 
| r8g.24xlarge | 14 | 120 | 
| r8g.48xlarge | 14 | 120 | 
| r8g.metal-24xl | 14 | 120 | 
| r8g.metal-48xl | 14 | 120 | 
| r8gb.medium | 1 | 4 | 
| r8gb.large | 2 | 10 | 
| r8gb.xlarge | 3 | 20 | 
| r8gb.2xlarge | 3 | 40 | 
| r8gb.4xlarge | 7 | 60 | 
| r8gb.8xlarge | 9 | 60 | 
| r8gb.12xlarge | 11 | 60 | 
| r8gb.16xlarge | 15 | 120 | 
| r8gb.24xlarge | 23 | 120 | 
| r8gb. 48 x grande | 23 | 120 | 
| r8gb.metal-24xl | 23 | 120 | 
| r8gb.metal-48xl | 23 | 120 | 
| r8gd.medium | 1 | 4 | 
| r8gd.large | 2 | 10 | 
| r8gd.xlarge | 3 | 20 | 
| r8gd.2xlarge | 3 | 40 | 
| r8gd.4xlarge | 7 | 60 | 
| r8gd.8xlarge | 7 | 60 | 
| r8gd.12xlarge | 7 | 60 | 
| r8gd.16xlarge | 14 | 120 | 
| r8gd.24xlarge | 14 | 120 | 
| r8gd.48xlarge | 14 | 120 | 
| r8gd.metal-24xl | 14 | 120 | 
| r8gd.metal-48xl | 14 | 120 | 
| r8gn.medium | 1 | 4 | 
| r8gn.large | 2 | 10 | 
| r8gn.xlarge | 3 | 20 | 
| r8gn.2xlarge | 3 | 40 | 
| r8gn.4xlarge | 7 | 60 | 
| r8gn.8xlarge | 9 | 60 | 
| r8gn.12xlarge | 11 | 60 | 
| r8gn.16xlarge | 15 | 120 | 
| r8gn.24xlarge | 23 | 120 | 
| r8gn.48xlarge | 23 | 120 | 
| r8gn.metal-24xl | 23 | 120 | 
| r8gn.metal-48xl | 23 | 120 | 
| r8i.large | 2 | 10 | 
| r8i.xlarge | 3 | 20 | 
| r8i.2xlarge | 3 | 40 | 
| r8i.4xlarge | 7 | 60 | 
| r8i.8xlarge | 9 | 90 | 
| r8i.12xlarge | 11 | 120 | 
| r8i.16xlarge | 15 | 120 | 
| r8i.24xlarge | 15 | 120 | 
| r8i.32xlarge | 23 | 120 | 
| r8i.48xlarge | 23 | 120 | 
| r8i.96xlarge | 23 | 120 | 
| r8i.metal-48xl | 23 | 120 | 
| r8i.metal-96xl | 23 | 120 | 
| r8id.large | 2 | 10 | 
| r8id.xlarge | 3 | 20 | 
| r8id.2xlarge | 3 | 40 | 
| r8id.4xgrande | 7 | 60 | 
| r8id.8xlarge | 9 | 90 | 
| r8id.12xgrande | 11 | 120 | 
| r8id.16 x grande | 15 | 120 | 
| r8id.24xlarge | 15 | 120 | 
| r8id.32xlarge | 23 | 120 | 
| r8id. 48 x grande | 23 | 120 | 
| r8id.96xlarge | 23 | 120 | 
| r8id.metal-48xl | 23 | 120 | 
| r8id.metal-96xl | 23 | 120 | 
| r8i-flex.large | 2 | 4 | 
| r8i-flex.xlarge | 3 | 10 | 
| r8i-flex.2xlarge | 3 | 20 | 
| r8i-flex.4xlarge | 7 | 40 | 
| r8i-flex.8xlarge | 9 | 60 | 
| r8i-flex.12xlarge | 11 | 120 | 
| r8i-flex.16xlarge | 15 | 120 | 
| u-3tb1.56xlarge | 7 | 12 | 
| u-6tb1.56xlarge | 14 | 12 | 
| u-18tb1.112xlarge | 14 | 12 | 
| u-18tb1.metal | 14 | 12 | 
| u-24tb1.112xlarge | 14 | 12 | 
| u-24tb1.metal | 14 | 12 | 
| u7i-6tb.112xlarge | 14 | 120 | 
| u7i-8tb.112xlarge | 14 | 120 | 
| u7i-12tb.224xlarge | 14 | 120 | 
| u7in-16tb.224xlarge | 15 | 120 | 
| u7in-24tb.224xlarge | 15 | 120 | 
| u7in-32tb.224xlarge | 15 | 120 | 
| u7inh-32tb.480xlarge | 15 | 120 | 
| x2gd.medium | 1 | 10 | 
| x2gd.large | 2 | 10 | 
| x2gd.xlarge | 3 | 20 | 
| x2gd.2xlarge | 3 | 40 | 
| x2gd.4xlarge | 7 | 60 | 
| x2gd.8xlarge | 7 | 60 | 
| x2gd.12xlarge | 7 | 60 | 
| x2gd.16xlarge | 14 | 120 | 
| x2gd.metal | 14 | 120 | 
| x2idn.16xlarge | 14 | 120 | 
| x2idn.24xlarge | 14 | 120 | 
| x2idn.32xlarge | 14 | 120 | 
| x2idn.metal | 14 | 120 | 
| x2iedn.xlarge | 3 | 13 | 
| x2iedn.2xlarge | 3 | 29 | 
| x2iedn.4xlarge | 7 | 60 | 
| x2iedn.8xlarge | 7 | 120 | 
| x2iedn.16xlarge | 14 | 120 | 
| x2iedn.24xlarge | 14 | 120 | 
| x2iedn.32xlarge | 14 | 120 | 
| x2iedn.metal | 14 | 120 | 
| x2iezn.2xlarge | 3 | 64 | 
| x2iezn.4xlarge | 7 | 120 | 
| x2iezn.6xlarge | 7 | 120 | 
| x2iezn.8xlarge | 7 | 120 | 
| x2iezn.12xlarge | 14 | 120 | 
| x2iezn.metal | 14 | 120 | 
| x8g.medium | 1 | 4 | 
| x8g.large | 2 | 10 | 
| x8g.xlarge | 3 | 20 | 
| x8g.2xlarge | 3 | 40 | 
| x8g.4xlarge | 7 | 60 | 
| x8g.8xlarge | 7 | 60 | 
| x8g.12xlarge | 7 | 60 | 
| x8g.16xlarge | 14 | 120 | 
| x8g.24xlarge | 14 | 120 | 
| x8g.48xlarge | 14 | 120 | 
| x8g.metal-24xl | 14 | 120 | 
| x8g.metal-48xl | 14 | 120 | 
| x8 aedz.large | 3 | 10 | 
| x8aedz.xlarge | 3 | 20 | 
| x8aedz.3x grande | 7 | 40 | 
| x8aedz.6x grande | 7 | 60 | 
| x8aedz.12x grande | 15 | 120 | 
| x8aedz.24x grande | 15 | 120 | 
| x8aedz.metallo-12xl | 15 | 120 | 
| x8aedz.metallo-24xl | 15 | 120 | 
| x8i.large | 2 | 10 | 
| x8i.xlarge | 3 | 20 | 
| x8i.2xlarge | 3 | 40 | 
| x8i.4xlarge | 7 | 60 | 
| x8i.8xlarge | 9 | 90 | 
| x8i.12xlarge | 11 | 120 | 
| x8i.16 x grande | 15 | 120 | 
| x8i.24xlarge | 15 | 120 | 
| x8i.32xlarge | 23 | 120 | 
| x8i.48 x grande | 23 | 120 | 
| x8i.64xlarge | 23 | 120 | 
| x8i.96xlarge | 23 | 120 | 
| x8i.metal-48xl | 23 | 120 | 
| x8i.metallo-96xl | 23 | 120 | 

## Archiviazione ottimizzata
<a name="eni-branch-so"></a>


| Tipo di istanza | Limite di attività senza trunking ENI | Limite di attività con trunking ENI | 
| --- | --- | --- | 
| i4g.large | 2 | 10 | 
| i4g.xlarge | 3 | 20 | 
| i4g.2xlarge | 3 | 40 | 
| i4g.4xlarge | 7 | 60 | 
| i4i.8xlarge | 7 | 60 | 
| i4i.16xlarge | 14 | 120 | 
| i4i.xlarge | 3 | 8 | 
| i4i.2xlarge | 3 | 28 | 
| i4i.4xlarge | 7 | 58 | 
| i4i.8xlarge | 7 | 118 | 
| i4i.12xlarge | 7 | 118 | 
| i4i.16xlarge | 14 | 248 | 
| i4i.24xlarge | 14 | 118 | 
| i4i.32xlarge | 14 | 498 | 
| i4i.metal | 14 | 498 | 
| i7i.large | 2 | 10 | 
| i7i.xlarge | 3 | 20 | 
| i7i.2xlarge | 3 | 40 | 
| i7i.4xlarge | 7 | 60 | 
| i7i.8xlarge | 7 | 90 | 
| i7i.12xlarge | 7 | 90 | 
| i7i.16xlarge | 14 | 120 | 
| i7i.24xlarge | 14 | 120 | 
| i7i.48xlarge | 14 | 120 | 
| i7i.metal-24xl | 14 | 120 | 
| i7i.metal-48xl | 14 | 120 | 
| i7ie.large | 2 | 20 | 
| i7ie.xlarge | 3 | 29 | 
| i7ie.2xlarge | 3 | 29 | 
| i7ie.3xlarge | 3 | 29 | 
| i7ie.6xlarge | 7 | 60 | 
| i7ie.12xlarge | 7 | 60 | 
| i7ie.18xlarge | 14 | 120 | 
| i7ie.24xlarge | 14 | 120 | 
| i7ie.48xlarge | 14 | 120 | 
| i7ie.metal-24xl | 14 | 120 | 
| i7ie.metal-48xl | 14 | 120 | 
| i8g.large | 2 | 10 | 
| i8g.xlarge | 3 | 20 | 
| i8g.2xlarge | 3 | 40 | 
| i8g.4xlarge | 7 | 60 | 
| i8g.8xlarge | 7 | 60 | 
| i8g.12xlarge | 7 | 60 | 
| i8g.16xlarge | 14 | 120 | 
| i8g.24xlarge | 14 | 120 | 
| i8g.48xlarge | 14 | 120 | 
| i8g.metal-24xl | 14 | 120 | 
| I8 g. Metallo - 48 XL | 14 | 120 | 
| i8ge.large | 2 | 20 | 
| i8ge.xlarge | 3 | 29 | 
| i8ge.2xlarge | 3 | 29 | 
| i8ge.3xlarge | 5 | 29 | 
| i8ge.6xlarge | 9 | 60 | 
| i8ge.12xlarge | 11 | 60 | 
| i8ge.18xlarge | 15 | 120 | 
| i8ge.24xlarge | 15 | 120 | 
| i8ge.48xlarge | 23 | 120 | 
| i8ge.metal-24xl | 15 | 120 | 
| i8ge.metal-48xl | 23 | 120 | 
| im4gn.large | 2 | 10 | 
| im4gn.xlarge | 3 | 20 | 
| im4gn.2xlarge | 3 | 40 | 
| im4gn.4xlarge | 7 | 60 | 
| im4gn.8xlarge | 7 | 60 | 
| im4gn.16xlarge | 14 | 120 | 
| is4gen.medium | 1 | 4 | 
| is4gen.large | 2 | 10 | 
| is4gen.xlarge | 3 | 20 | 
| is4gen.2xlarge | 3 | 40 | 
| is4gen.4xlarge | 7 | 60 | 
| is4gen.8xlarge | 7 | 60 | 

## Elaborazione accelerata
<a name="eni-branch-ac"></a>


| Tipo di istanza | Limite di attività senza trunking ENI | Limite di attività con trunking ENI | 
| --- | --- | --- | 
| dl1.24xlarge | 59 | 120 | 
| dl2q.24xlarge | 14 | 120 | 
| f2.6xlarge | 7 | 90 | 
| f2.12xlarge | 7 | 120 | 
| f2.48xlarge | 14 | 120 | 
| g4ad.xlarge | 1 | 12 | 
| g4ad.2xlarge | 1 | 12 | 
| g4ad.4xlarge | 2 | 12 | 
| g4ad.8xlarge | 3 | 12 | 
| g4ad.16xlarge | 7 | 12 | 
| g5.xlarge | 3 | 6 | 
| g5.2xlarge | 3 | 19 | 
| g5.4xlarge | 7 | 40 | 
| g5.8xlarge | 7 | 90 | 
| g5.12xlarge | 14 | 120 | 
| g5.16xlarge | 7 | 120 | 
| g5.24xlarge | 14 | 120 | 
| g5.48xlarge | 6 | 120 | 
| g5g.xlarge | 3 | 20 | 
| g5g.2xlarge | 3 | 40 | 
| g5g.4xlarge | 7 | 60 | 
| g5g.8xlarge | 7 | 60 | 
| g5g.16xlarge | 14 | 120 | 
| g5g.metal | 14 | 120 | 
| g6.xlarge | 3 | 20 | 
| g6.2xlarge | 3 | 40 | 
| g6.4xlarge | 7 | 60 | 
| g6.8xlarge | 7 | 90 | 
| g6.12xlarge | 7 | 120 | 
| g6.16xlarge | 14 | 120 | 
| g6.24xlarge | 14 | 120 | 
| g6.48xlarge | 14 | 120 | 
| g6e.xlarge | 3 | 20 | 
| g6e.2xlarge | 3 | 40 | 
| g6e.4xlarge | 7 | 60 | 
| g6e.8xlarge | 7 | 90 | 
| g6e.12xlarge | 9 | 120 | 
| g6e.16xlarge | 14 | 120 | 
| g6e.24xlarge | 19 | 120 | 
| g6e.48xlarge | 39 | 120 | 
| g6f.large | 1 | 10 | 
| g6f.xlarge | 3 | 20 | 
| g6f.2xlarge | 3 | 40 | 
| g6f.4xlarge | 7 | 60 | 
| gr6.4xlarge | 7 | 60 | 
| gr6.8xlarge | 7 | 90 | 
| gr6f.4xlarge | 7 | 60 | 
| g 7. 2x grande | 3 | 242 | 
| G 7. 4x grande | 7 | 242 | 
| G 7. 8x grande | 7 | 242 | 
| G7 e.12 x grande | 9 | 242 | 
| G7 e.24 x grande | 19 | 242 | 
| G7 e.48 x grande | 39 | 242 | 
| inf2.xlarge | 3 | 20 | 
| inf2.8xlarge | 7 | 90 | 
| inf2.24xlarge | 14 | 120 | 
| inf2.48xlarge | 14 | 120 | 
| p4d.24xlarge | 59 | 120 | 
| p4de.24xlarge | 59 | 120 | 
| p5.4xlarge | 3 | 60 | 
| p5.48xlarge | 63 | 242 | 
| p5e.48xlarge | 63 | 242 | 
| p5en.48xlarge | 63 | 242 | 
| p6-b200.48xlarge | 31 | 242 | 
| p6-b 300,48 x grande | 67 | 242 | 
| p6e-gb200.36xlarge | 38 | 120 | 
| trn1.2xlarge | 3 | 19 | 
| trn1.32xlarge | 39 | 120 | 
| trn1n.32xlarge | 79 | 242 | 
| TRN 2,3 x grande | 1 | 14 | 
| trn2.48xlarge | 31 | 242 | 
| trn2u.48xlarge | 31 | 242 | 
| vt1.3xlarge | 3 | 40 | 
| vt1.6xlarge | 7 | 60 | 
| vt1.24xlarge | 14 | 120 | 

## High Performance Computing
<a name="eni-branch-hpc"></a>


| Tipo di istanza | Limite di attività senza trunking ENI | Limite di attività con trunking ENI | 
| --- | --- | --- | 
| hpc6a.48xlarge | 1 | 120 | 
| hpc6id.32xlarge | 1 | 120 | 
| hpc7g.4xlarge | 3 | 120 | 
| hpc7g.8xlarge | 3 | 120 | 
| hpc7g.16xlarge | 3 | 120 | 
| hp 8 a.96 x grande | 3 | -2 | 

# Allocazione della memoria di un'istanza di container Amazon ECS Linux
<a name="memory-management"></a>

Quando l'agente container Amazon ECS registra un'istanza di container in un cluster, l'agente deve determinare quanta memoria è disponibile nell'istanza di container per essere allocata alle tue attività. A causa dei costi del sovraccarico di memoria della piattaforma e della memoria occupata dal kernel del sistema, questo numero è diverso rispetto alla quantità di memoria installata pubblicizzata per le istanze Amazon EC2. Ad esempio, un'istanza `m4.large` dispone di 8 GiB di memoria installata. Tuttavia, ciò non si traduce sempre in esattamente 8192 MiB di memoria disponibile per le attività quando l'istanza di container viene registrata.

## Determinazione delle risorse di memoria di ECS Managed Instances
<a name="ecs-mi-memory-calculation"></a>

Amazon ECS Managed Instances utilizza un approccio gerarchico per determinare i requisiti di risorse di memoria per le attività. A differenza di ECS su EC2, che si basa sull'introspezione della memoria di Docker, ECS Managed Instances calcola i requisiti di memoria direttamente dal payload dell'attività durante le decisioni di pianificazione.

Quando l'agente ECS Managed Instances riceve un'attività, calcola il fabbisogno di memoria utilizzando il seguente ordine di priorità:

1. **Memoria a livello di attività (priorità massima)**: se la memoria a livello di attività è specificata nella definizione dell'attività, l'agente utilizza direttamente questo valore. Ciò ha la precedenza su tutte le impostazioni di memoria a livello di contenitore.

1. **Somma di memoria a livello di contenitore (fallback)**: se la memoria a livello di attività non è specificata (o è 0), l'agente somma i requisiti di memoria di tutti i contenitori dell'operazione. Per ogni contenitore, utilizza:

   1. *Prenotazione di memoria (soft limit)*: se un contenitore lo specifica `memoryReservation` nella sua configurazione, l'agente utilizza questo valore.

   1. *Memoria del contenitore (limite rigido)*: se non `memoryReservation` è specificato, l'agente utilizza il `memory` campo del contenitore.

**Example Memoria a livello di attività specificata**  
Quando viene specificata la memoria a livello di attività, ha la precedenza sulle impostazioni a livello di contenitore:  

```
{
  "family": "my-task",
  "memory": "2048",
  "containerDefinitions": [
    {
      "name": "container1",
      "memory": 1024,
      "memoryReservation": 512
    }
  ]
}
```
L'agente riserva 2048 MiB (la memoria a livello di attività ha la precedenza).

**Example Memoria a livello di contenitore con prenotazioni**  
Quando non viene specificata la memoria a livello di attività, l'agente somma i requisiti di memoria del contenitore:  

```
{
  "family": "my-task",
  "containerDefinitions": [
    {
      "name": "container1",
      "memory": 1024,
      "memoryReservation": 512
    },
    {
      "name": "container2",
      "memory": 512
    }
  ]
}
```
L'agente riserva 512 MiB (prenotazione container1) \$1 512 MiB (memoria container2) = 1024 MiB totali.

L'agente ECS Managed Instances esegue il calcolo della memoria in tre fasi:

1. **Ricezione delle attività**: quando il payload di un'operazione arriva dal piano di controllo ECS, l'agente calcola immediatamente la memoria richiesta.

1. **Archiviazione delle risorse**: il fabbisogno di memoria calcolato viene memorizzato nel modello di attività per un uso successivo nelle operazioni di contabilità delle risorse.

1. **Decisione sulla pianificazione**: prima di accettare un'attività, l'agente verifica se è disponibile memoria sufficiente. Se la memoria disponibile è insufficiente, l'attività viene rifiutata e rimane nella coda dei servizi ECS fino a quando le risorse non diventano disponibili.

**Nota**  
A differenza di ECS su EC2, ECS Managed Instances non utilizza la variabile di configurazione. `ECS_RESERVED_MEMORY` La prenotazione della memoria per i processi di sistema viene gestita tramite la gestione delle risorse della piattaforma sottostante e l'agente esegue una contabilità accurata delle risorse in base alle definizioni delle attività.

 Per ECS su EC2, l'agente container Amazon ECS fornisce una variabile di configurazione chiamata`ECS_RESERVED_MEMORY`, che puoi usare per rimuovere un numero specifico di MiB di memoria dal pool assegnato alle tue attività. In questo modo si riserva la memoria per i processi di sistema critici.

Se occupi tutta la memoria di un'istanza di container con le tue attività, è possibile che queste ultime entrino in conflitto con le attività di sistema critiche per la memoria e causino un errore di sistema.

Ad esempio, se si specifica `ECS_RESERVED_MEMORY=256` nel file di configurazione dell'agente del container, l'agente registra la memoria totale -256 MiB per quell'istanza e 256 MiB di memoria non possono essere allocati da task ECS. Per ulteriori informazioni sulle variabili dell'agente e su come impostarle, vedere [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md) e [Bootstrap di istanze di container Linux Amazon ECS per il trasferimento dei dati](bootstrap_container_instance.md).

Se specifichi 8192 MiB per l'attività e nessuna delle istanze di container dispone di 8192 MiB o più di memoria disponibile per soddisfare questo requisito, l'attività non può essere inserita nel cluster. Se utilizzi un ambiente di elaborazione gestito, AWS Batch devi avviare un tipo di istanza più grande per soddisfare la richiesta.

L'agente del container di Amazon ECS utilizza la funzione Docker `ReadMemInfo()` per eseguire una query sulla memoria totale disponibile per il sistema operativo. Sia Linux che Windows forniscono utilità a riga di comando per determinare la memoria totale.

**Example - Determinare la memoria totale in Linux**  
Il comando **free** restituisce la memoria totale riconosciuta dal sistema operativo.  

```
$ free -b
```
Esempio di output per un'istanza `m4.large` che esegue l'AMI Amazon Linux ottimizzata per Amazon ECS.  

```
             total       used       free     shared    buffers     cached
Mem:    8373026816  348180480 8024846336      90112   25534464  205418496
-/+ buffers/cache:  117227520 8255799296
```
Questa istanza ha 8373026816 byte di memoria totale, che si traducono in 7985 MiB disponibili per le attività.

**Example - Determinare la memoria totale in Windows**  
Il comando **wmic** restituisce la memoria totale riconosciuta dal sistema operativo.  

```
C:\> wmic ComputerSystem get TotalPhysicalMemory
```
Esempio di output per un'istanza `m4.large` che esegue il server AMI Amazon Windows ottimizzato per Amazon ECS.  

```
TotalPhysicalMemory
8589524992
```
Questa istanza ha 8589524992 byte di memoria totale, che si traducono in 8191 MiB disponibili per le attività.

## Visualizzare la memoria di un'istanza di container
<a name="viewing-memory"></a>

Puoi visualizzare la quantità di memoria con cui registra un'istanza del contenitore nella console Amazon ECS (o con l'operazione [DescribeContainerInstances](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeContainerInstances.html)API). Se stai cercando di massimizzare l'utilizzo delle risorse fornendo alle tue attività la maggior quantità possibile di memoria per un particolare tipo di istanza, puoi osservare la memoria disponibile per quell'istanza di container e quindi assegnare alle tue attività tale quantità di memoria.

**Per visualizzare la memoria dell'istanza di container**

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nel riquadro di navigazione, scegli **Cluster** e seleziona il cluster che ospita l'istanza di container.

1. Scegli **Infrastruttura**, quindi in Istanze di container scegli un'istanza di container.

1. La sezione **Risorse** mostra la memoria registrata e disponibile per l'istanza di container.

   Il valore di memoria **Registrato** corrisponde a quello che l'istanza di container ha registrato in Amazon ECS la prima volta che è stata avviata e il valore di memoria **Disponibile** è quello che non è ancora stato allocato alle attività.

# Gestione remota delle istanze di container Amazon ECS tramite AWS Systems Manager
<a name="ec2-run-command"></a>

Puoi utilizzare la funzionalità Run Command in AWS Systems Manager (Systems Manager) per gestire in modo sicuro e remoto la configurazione delle tue istanze di container Amazon ECS. Run Command fornisce un modo semplice per eseguire le attività di amministrazione comuni senza accedere localmente all'istanza. Puoi gestire le modifiche della configurazione dei tuoi cluster tramite l'esecuzione simultanea di comandi su più istanze di container. Run Command tiene traccia dello stato e dei risultati di ciascun comando.

Di seguito sono elencati alcuni esempi dei tipi di attività che puoi eseguire mediante Run Command:
+ Installare o disinstallare pacchetti.
+ Eseguire aggiornamenti di sicurezza.
+ Eliminare immagini Docker.
+ Interrompere o avviare i servizi.
+ Visualizzare le risorse di sistema.
+ Visualizzare file di log.
+ Eseguire operazioni sui file.

Per ulteriori informazioni su Run Command, consulta [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) nella *Guida per l'utente di AWS Systems Manager *.

Di seguito sono riportati i prerequisiti per l'uso di Systems Manager con Amazon ECS.

1. È necessario concedere all'istanza del contenitore le autorizzazioni role (**ecsInstanceRole**) per accedere a Systems Manager APIs. Puoi farlo assegnando **Amazon SSMManaged InstanceCore** al `ecsInstanceRole` ruolo. Per informazioni su come associare una policy a un ruolo, consulta [Aggiornare le autorizzazioni per un ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) nella *Guida per l'utente di AWS Identity and Access Management *

1. Verifica che SSM Agent sia installato nelle istanze di container. Per ulteriori informazioni, consulta [Installare e disinstallare manualmente SSM Agent su istanze EC2 per Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html).

Dopo aver collegato le policy gestite di Systems Manager alle istanze del contenitore `ecsInstanceRole` e aver verificato che AWS Systems Manager l'agente (agente SSM) sia installato sulle istanze del contenitore, è possibile iniziare a utilizzare Run Command per inviare comandi alle istanze del contenitore. Per ulteriori informazioni sull'esecuzione di comandi e script di shell sulle istanze e sulla visualizzazione dell'output risultante, consulta [Esecuzione di comandi mediante Run Command di Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) e [Spiegazione passo per passo di Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command-walkthroughs.html) nella *Guida per l'utente di AWS Systems Manager *. 

Un caso d'uso comune consiste nell'aggiornare il software dell'istanza di container con Run Command. È possibile seguire le procedure riportate nella Guida per l' AWS Systems Manager utente con i seguenti parametri.


| Parametro | Valore | 
| --- | --- | 
|  **Documento di comando**  | AWS-RunShellScript | 
| Comando |  <pre>$ yum update -y</pre> | 
| Istanze di destinazione | Le tue istanze di container | 

# Uso di un proxy HTTP per istanze di container Linux Amazon ECS
<a name="http_proxy_config"></a>

Puoi configurare le tue istanze di container Amazon ECS per l'utilizzo di un proxy HTTP sia per l'agente del container Amazon ECS che per il daemon Docker. Ciò è utile se le tue istanze di container non hanno accesso alla rete esterna tramite un gateway Internet Amazon VPC, un gateway NAT o un'istanza. 

Per configurare l'istanza di container Linux di Amazon ECS per l'utilizzo di un proxy HTTP, imposta le seguenti variabili nei file pertinenti al momento dell'avvio (con dati utente di Amazon EC2). È anche possibile modificare manualmente il file di configurazione e poi riavviare l'agente.

`/etc/ecs/ecs.config`(Amazon Linux 2e AmazonLinux AMI)    
`HTTP_PROXY=10.0.0.131:3128`  
Imposta questo valore sul nome host (o indirizzo IP) e sul numero di porta di un proxy HTTP da utilizzare per l'agente Amazon ECS per la connessione a Internet. Ad esempio, le tue istanze di container potrebbero non avere accesso alla rete esterna tramite un gateway Internet Amazon VPC, un gateway NAT o un'istanza.  
`NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`  
Imposta questo valore su `169.254.169.254,169.254.170.2,/var/run/docker.sock` per filtrare i metadati dell'istanza EC2, i ruoli IAM per i processi e il traffico del daemon Docker dal proxy. 

`/etc/systemd/system/ecs.service.d/http-proxy.conf` (solo Amazon Linux 2)    
`Environment="HTTP_PROXY=10.0.0.131:3128/"`  
Imposta questo valore sul nome host (o indirizzo IP) e sul numero di porta di un proxy HTTP da utilizzare per connettere `ecs-init` a Internet. Ad esempio, le tue istanze di container potrebbero non avere accesso alla rete esterna tramite un gateway Internet Amazon VPC, un gateway NAT o un'istanza.  
`Environment="NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock"`  
Imposta questo valore su `169.254.169.254,169.254.170.2,/var/run/docker.sock` per filtrare i metadati dell'istanza EC2, i ruoli IAM per i processi e il traffico del daemon Docker dal proxy. 

`/etc/init/ecs.override` (solo AMI Amazon Linux)    
`env HTTP_PROXY=10.0.0.131:3128`  
Imposta questo valore sul nome host (o indirizzo IP) e sul numero di porta di un proxy HTTP da utilizzare per connettere `ecs-init` a Internet. Ad esempio, le tue istanze di container potrebbero non avere accesso alla rete esterna tramite un gateway Internet Amazon VPC, un gateway NAT o un'istanza.  
`env NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`  
Imposta questo valore su `169.254.169.254,169.254.170.2,/var/run/docker.sock` per filtrare i metadati dell'istanza EC2, i ruoli IAM per i processi e il traffico del daemon Docker dal proxy. 

`/etc/systemd/system/docker.service.d/http-proxy.conf` (solo Amazon Linux 2)    
`Environment="HTTP_PROXY=http://10.0.0.131:3128"`  
Imposta questo valore sul nome host (o indirizzo IP) e sul numero di porta di un proxy HTTP da utilizzare per connettere il daemon Docker a Internet. Ad esempio, le tue istanze di container potrebbero non avere accesso alla rete esterna tramite un gateway Internet Amazon VPC, un gateway NAT o un'istanza.  
`Environment="NO_PROXY=169.254.169.254,169.254.170.2"`  
Imposta questo valore su `169.254.169.254,169.254.170.2` per filtrare i metadati dell'istanza EC2 dal proxy. 

`/etc/sysconfig/docker` (solo AMI Amazon Linux e Amazon Linux 2)    
`export HTTP_PROXY=http://10.0.0.131:3128`  
Imposta questo valore sul nome host (o indirizzo IP) e sul numero di porta di un proxy HTTP da utilizzare per connettere il daemon Docker a Internet. Ad esempio, le tue istanze di container potrebbero non avere accesso alla rete esterna tramite un gateway Internet Amazon VPC, un gateway NAT o un'istanza.  
`export NO_PROXY=169.254.169.254,169.254.170.2`  
Imposta questo valore su `169.254.169.254,169.254.170.2` per filtrare i metadati dell'istanza EC2 dal proxy. 

L'impostazione di queste variabili di ambiente nei suddetti file influisce solo sull'agente del container di Amazon ECS, su `ecs-init` e sul daemon Docker. Non configurano altri servizi (ad esempio il comando **yum**) per l'utilizzo del proxy.

Per informazioni su come configurare il proxy, consulta [Come configurare un proxy HTTP per Docker e l'agente contenitore Amazon ECS in Amazon](https://repost.aws/knowledge-center/ecs-http-proxy-docker-linux2) Linux 2 o. AL2023

# Configurazione delle istanze preinizializzate per il tuo gruppo Auto Scaling Amazon ECS
<a name="using-warm-pool"></a>

Amazon ECS supporta i warm pool Amazon EC2 Auto Scaling. Un warm pool è un gruppo di istanze Amazon EC2 pre-inizializzate pronte per essere messe in servizio. Ogni volta che l'applicazione ha bisogno di aumentare orizzontalmente, Amazon EC2 Auto Scaling utilizza le istanze pre-inizializzate dal warm pool anziché avviare istanze cold, consente l'esecuzione di qualsiasi processo di inizializzazione finale e quindi mette in servizio l'istanza.

Per ulteriori informazioni sui warm pool e su come aggiungere un warm pool al gruppo con scalabilità automatica, consulta [Warm pool per Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.

Quando crei o aggiorni un warm pool per un gruppo con scalabilità automatica per Amazon ECS, non puoi impostare l'opzione che restituisce le istanze al warm pool alla riduzione orizzontale (`ReuseOnScaleIn`). Per ulteriori informazioni, consulta [put-warm-pool](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-warm-pool.html) nella *documentazione di riferimento AWS Command Line Interface *.

Per utilizzare i warm pool con il cluster Amazon ECS, imposta la variabile di configurazione dell'agente `ECS_WARM_POOLS_CHECK` su `true` nel campo **User data** (Dati utente) del modello di avvio del gruppo Amazon EC2 Auto Scaling. 

Di seguito è illustrato un esempio di come la variabile di configurazione dell'agente può essere specificata nel campo **User data** (Dati utente) di un modello di avvio Amazon EC2. Sostituisci *MyCluster* con il nome del tuo cluster.

```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_WARM_POOLS_CHECK=true
EOF
```

La variabile `ECS_WARM_POOLS_CHECK` è supportata sull'agente solo a partire dalla versione `1.59.0`. Per ulteriori informazioni sulle variabili, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md).

# Aggiornamento dell'agente del container Amazon ECS
<a name="ecs-agent-update"></a>

In alcuni casi, potrebbe essere necessario aggiornare l'agente del container di Amazon ECS per ottenere correzioni dei bug e nuove funzionalità. L'aggiornamento dell'agente del container di Amazon ECS non interrompe i processi o i servizi in esecuzione nell'istanza di container. Il processo per l'aggiornamento dell'agente differisce a seconda se la tua istanza di container è stata avviata con l'AMI ottimizzata per Amazon ECS o con un altro sistema operativo.

**Nota**  
Gli aggiornamenti dell'agente non si applicano alle istanze di container di Windows. Consigliamo di avviare nuove istanze di container per aggiornare la versione dell'agente nei cluster Windows.

## Verifica della versione dell'agente del container Amazon ECS
<a name="checking_agent_version"></a>

Puoi verificare la versione dell'agente del container che è in esecuzione nelle tue istanze di container per vedere se è necessario aggiornarla. La vista dell'istanza di container nella console di Amazon ECS fornisce la versione dell'agente. Utilizza la procedura seguente per verificare la versione del tuo agente.

------
#### [ Amazon ECS console ]

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Dalla barra di navigazione, scegli la Regione in cui l'istanza esterna è registrata.

1. Nel riquadro di navigazione, scegli **Cluster** e seleziona il cluster che ospita l'istanza esterna.

1. Nella *name* pagina **Cluster:**, scegli la scheda **Infrastruttura**.

1. In **Container instances** (Istanze di container), osserva la colonna **Agent version** (Versione agente) per le tue istanze di container. Se l'istanza di container non contiene la versione più recente dell'agente del container, la console invia un avviso con un messaggio e contrassegna la versione dell'agente obsoleta.

   Se la versione del tuo agente del container è obsoleta, puoi aggiornare l'agente con le seguenti procedure:
   + Se la tua istanza di container sta eseguendo un'AMI ottimizzata per Amazon ECS, consulta [Come aggiornare l'agente del container Amazon ECS su un'AMI ottimizzata per Amazon ECS](agent-update-ecs-ami.md).
   + Se la tua istanza di container non sta eseguendo un'AMI ottimizzata per Amazon ECS, consulta [Aggiornamento manuale dell'agente container Amazon ECS (per prodotti non ottimizzati per Amazon ECS) AMIs](manually_update_agent.md).
**Importante**  
Per aggiornare la versione dell'agente di Amazon ECS da versioni precedenti alla v1.0.0 sull'AMI ottimizzata per Amazon ECS, ti consigliamo di terminare la tua attuale istanza di container e avviare una nuova istanza con la versione dell'AMI più recente. Qualsiasi istanza di container che utilizza una versione di anteprima deve essere ritirata e sostituita con l'AMI più recente. Per ulteriori informazioni, consulta [Avvio di un'istanza di container Linux di Amazon ECS](launch_container_instance.md).

------
#### [ Amazon ECS container agent introspection API  ]

Puoi inoltre utilizzare l'API di introspezione dell'agente del container di Amazon ECS per verificare la versione dell'agente dall'istanza di container stessa. Per ulteriori informazioni, consulta [Introspezione del container di Amazon ECS](ecs-agent-introspection.md).

**Come verificare se il tuo agente del container di Amazon ECS sta eseguendo l'ultima versione con l'API di introspezione**

1. Accedi alla tua istanza di container con SSH.

1. Interroga l'API di introspezione.

   ```
   [ec2-user ~]$ curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
   ```
**Nota**  
L'API di introspezione ha aggiunto delle informazioni di `Version` nella versione v1.0.0 dell'agente del container di Amazon ECS. Se `Version` non è presente quando si interroga l'API di introspezione oppure se quest'ultima è completamente assente nel tuo agente, la versione in esecuzione è v0.0.3 o precedente. È necessario aggiornare la versione.

------

# Come aggiornare l'agente del container Amazon ECS su un'AMI ottimizzata per Amazon ECS
<a name="agent-update-ecs-ami"></a>

Se utilizzi l'AMI ottimizzata per Amazon ECS, hai diverse opzioni per ottenere la versione più recente dell'agente del container di Amazon ECS (mostrato in ordine di raccomandazione):
+ Termina l'istanza di container e avvia la versione più recente dell'AMI Amazon Linux 2 ottimizzata per Amazon ECS (manualmente o tramite l'aggiornamento della configurazione di avvio di Auto Scaling con l'AMI più recente). Questo fornisce una nuova istanza di container con le versioni testate e convalidate più aggiornate di Amazon Linux, Docker, `ecs-init` e l'agente del container di Amazon ECS. Per ulteriori informazioni, consulta [Linux ottimizzato per Amazon ECS AMIs](ecs-optimized_AMI.md).
+ Connettiti all'istanza con SSH e aggiorna il pacchetto `ecs-init` (e le relative dipendenze) alla versione più recente. Questa operazione fornisce le versioni testate e convalidate più aggiornate di Docker e `ecs-init` che sono disponibili nei repository di Amazon Linux e la versione più recente dell'agente del container di Amazon ECS. Per ulteriori informazioni, consulta [Come aggiornare il pacchetto `ecs-init` su un'AMI ottimizzata per Amazon ECS](#procedure_update_ecs-init).
+ Aggiorna l'agente del contenitore con l'operazione `UpdateContainerAgent` API, tramite la console o con l'opzione AWS CLI o AWS SDKs. Per ulteriori informazioni, consulta [Aggiornamento dell'agente del container di Amazon ECS con l'operazione API `UpdateContainerAgent`](#agent-update-api).

**Nota**  
Gli aggiornamenti dell'agente non si applicano alle istanze di container di Windows. Consigliamo di avviare nuove istanze di container per aggiornare la versione dell'agente nei cluster Windows.<a name="procedure_update_ecs-init"></a>

**Come aggiornare il pacchetto `ecs-init` su un'AMI ottimizzata per Amazon ECS**

1. Accedi alla tua istanza di container con SSH.

1. Aggiorna il pacchetto `ecs-init` con il comando seguente.

   ```
   sudo yum update -y ecs-init
   ```
**Nota**  
Il pacchetto `ecs-init` e l'agente del container di Amazon ECS vengono aggiornati immediatamente. Tuttavia, le versioni più recenti di Docker non vengono caricate finché il daemon Docker non viene riavviato. Utilizza il riavvio dell'istanza oppure esegui i comandi seguenti sull'istanza:  
AMI Amazon Linux 2 ottimizzata per Amazon ECS:  

     ```
     sudo systemctl restart docker
     ```
AMI Amazon Linux ottimizzata per Amazon ECS:  

     ```
     sudo service docker restart && sudo start ecs
     ```

## Aggiornamento dell'agente del container di Amazon ECS con l'operazione API `UpdateContainerAgent`
<a name="agent-update-api"></a>

**Importante**  
L'API `UpdateContainerAgent` è supportata solo sulle varianti Linux dell'AMI ottimizzata per Amazon ECS, ad eccezione dell'AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS. Per le istanze di container che utilizzano l'AMI Amazon Linux 2 (arm64) ottimizzata per Amazon ECS, aggiorna il pacchetto `ecs-init` per aggiornare l'agente. Per le istanze di container che eseguono altri sistemi operativi, consulta [Aggiornamento manuale dell'agente container Amazon ECS (per prodotti non ottimizzati per Amazon ECS) AMIs](manually_update_agent.md). Se utilizzi istanze di container Windows, ti consigliamo di avviare nuove istanze di container per aggiornare la versione dell'agente nei tuoi cluster Windows.

Il processo `UpdateContainerAgent` API inizia quando richiedi l'aggiornamento di un agente, tramite la console o con AWS CLI o AWS SDKs. Amazon ECS controlla la versione corrente dell'agente rispetto all'ultima versione disponibile e, se è possibile un aggiornamento. Se non è disponibile alcun aggiornamento, ad esempio se l'agente sta già eseguendo la versione più recente, allora viene restituito `NoUpdateAvailableException`.

Le fasi del processo di aggiornamento riportate in precedenza sono le seguenti:

`PENDING`  
È disponibile un aggiornamento dell'agente e il processo di aggiornamento è stato avviato.

`STAGING`  
L'agente ha iniziato a scaricare il relativo aggiornamento. Se l'agente non è in grado di scaricare l'aggiornamento, oppure se i contenuti dell'aggiornamento non sono corretti o sono danneggiati, l'agente invia una notifica dell'errore e l'aggiornamento passa allo stato `FAILED`.

`STAGED`  
Il download dell'agente è stato completato e i contenuti dell'agente sono stati verificati.

`UPDATING`  
Il servizio `ecs-init` è stato riavviato e ottiene la nuova versione dell'agente. Se l'agente non è in grado di riavviarsi per qualsiasi motivo, l'aggiornamento passa allo stato `FAILED`. In caso contrario, l'agente segnala ad Amazon ECS che l'aggiornamento è completo.

**Nota**  
Gli aggiornamenti dell'agente non si applicano alle istanze di container di Windows. Consigliamo di avviare nuove istanze di container per aggiornare la versione dell'agente nei cluster Windows.

**Come aggiornare l'agente del container Amazon ECS su un'AMI ottimizzata per Amazon ECS nella console**

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Dalla barra di navigazione, scegli la Regione in cui l'istanza esterna è registrata.

1. Nel pannello di navigazione, seleziona **Clusters** (Cluster), quindi seleziona il cluster.

1. Nella *name* pagina **Cluster:**, scegli la scheda **Infrastruttura**.

1. In **Istanze di container**, seleziona le istanze da aggiornare, quindi scegli **Operazioni**, **Aggiorna agente**.

# Aggiornamento manuale dell'agente container Amazon ECS (per prodotti non ottimizzati per Amazon ECS) AMIs
<a name="manually_update_agent"></a>

In alcuni casi, potrebbe essere necessario aggiornare l'agente del container di Amazon ECS per ottenere correzioni dei bug e nuove funzionalità. L'aggiornamento dell'agente del container di Amazon ECS non interrompe i processi o i servizi in esecuzione nell'istanza di container.
**Nota**  
Gli aggiornamenti dell'agente non si applicano alle istanze di container di Windows. Consigliamo di avviare nuove istanze di container per aggiornare la versione dell'agente nei cluster Windows.

1. Accedi alla tua istanza di container con SSH.

1. Controlla se il tuo agente utilizza la variabile di ambiente `ECS_DATADIR` per salvare il suo stato.

   ```
   ubuntu:~$ docker inspect ecs-agent | grep ECS_DATADIR
   ```

   Output:

   ```
   "ECS_DATADIR=/data",
   ```
**Importante**  
Se il comando precedente non restituisce la variabile di ambiente `ECS_DATADIR`, è necessario arrestare qualsiasi attività in esecuzione in questa istanza di container prima di aggiornare l'agente. Gli agenti più recenti con la variabile di ambiente `ECS_DATADIR` salvano il proprio stato e puoi aggiornarli mentre le attività vengono eseguite senza problemi.

1. Arresta l'agente del container di Amazon ECS.

   ```
   ubuntu:~$ docker stop ecs-agent
   ```

1. Elimina l'agente del container.

   ```
   ubuntu:~$ docker rm ecs-agent
   ```

1. Assicurati che la directory `/etc/ecs` e il file di configurazione dell'agente del container di Amazon ECS esistano in `/etc/ecs/ecs.config`.

   ```
   ubuntu:~$ sudo mkdir -p /etc/ecs && sudo touch /etc/ecs/ecs.config
   ```

1. Modifica il file `/etc/ecs/ecs.config` e assicurati che contenga almeno le seguenti dichiarazioni di variabili. Se non vuoi che la tua istanza di container sia registrata con il cluster predefinito, specifica il nome del tuo cluster come il valore per `ECS_CLUSTER`.

   ```
   ECS_DATADIR=/data
   ECS_ENABLE_TASK_IAM_ROLE=true
   ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true
   ECS_LOGFILE=/log/ecs-agent.log
   ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
   ECS_LOGLEVEL=info
   ECS_CLUSTER=default
   ```

   Per ulteriori informazioni su queste e altre opzioni di runtime dell'agente, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md).
**Nota**  
Puoi facoltativamente archiviare le variabili di ambiente dell'agente in Amazon S3 (che possono essere scaricate nelle tue istanze di container all'avvio utilizzando i dati utente di Amazon EC2). Ciò è consigliato per le informazioni sensibili, come le credenziali di autenticazione per i repository privati. Per ulteriori informazioni, consultare [Archiviazione della configurazione di un'istanza di container Amazon ECS in Amazon S3](ecs-config-s3.md) e [Utilizzo di immagini non AWS containerizzate in Amazon ECS](private-auth.md).

1. Estrai l'ultima immagine dell'agente del container di Amazon ECS da Amazon Elastic Container Registry Public.

   ```
   ubuntu:~$ docker pull public.ecr.aws/ecs/amazon-ecs-agent:latest
   ```

   Output:

   ```
   Pulling repository amazon/amazon-ecs-agent
   a5a56a5e13dc: Download complete
   511136ea3c5a: Download complete
   9950b5d678a1: Download complete
   c48ddcf21b63: Download complete
   Status: Image is up to date for amazon/amazon-ecs-agent:latest
   ```

1. Esegui l'agente del container di Amazon ECS più recente sulla tua istanza di container.
**Nota**  
Utilizza le policy di riavvio di Docker o un gestore di processo (come **upstart** o **systemd**) per trattare l'agente del container come un servizio o un daemon e assicurarne il riavvio dopo l'uscita. L'AMI ottimizzata per Amazon ECS utilizza l'`ecs-init`RPM per questo scopo e puoi visualizzare il [codice sorgente di questo](https://github.com/aws/amazon-ecs-init) RPM su. GitHub 

   Nell'esempio seguente, il comando di esecuzione dell'agente è suddiviso in righe separate per mostrare ciascuna opzione. Per ulteriori informazioni su queste e altre opzioni di runtime dell'agente, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md).
**Importante**  
I sistemi operativi con SELinux abilitato richiedono l'`--privileged`opzione nel comando. **docker run** Inoltre, per le istanze SELinux di container abilitate, si consiglia di aggiungere l'`:Z`opzione ai montaggi `/log` e `/data` volume. Tuttavia, i montaggi degli host per questi volumi devono esistere prima che tu esegua il comando o che riceva un errore `no such file or directory`. Se riscontri difficoltà nell'esecuzione dell'agente Amazon ECS su un'istanza di container SELinux abilitata, intraprendi la seguente azione:  
Crea i punti di montaggio dei volumi degli host sulla tua istanza di container.  

     ```
     ubuntu:~$ sudo mkdir -p /var/log/ecs /var/lib/ecs/data
     ```
Aggiungi l'opzione `--privileged` al comando **docker run** seguente.
Aggiungi l'opzione `:Z` ai montaggi dei volumi dei container `/log` e `/data` (ad esempio `--volume=/var/log/ecs/:/log:Z`) al comando **docker run** seguente.

   ```
   ubuntu:~$ sudo docker run --name ecs-agent \
   --detach=true \
   --restart=on-failure:10 \
   --volume=/var/run:/var/run \
   --volume=/var/log/ecs/:/log \
   --volume=/var/lib/ecs/data:/data \
   --volume=/etc/ecs:/etc/ecs \
   --volume=/etc/ecs:/etc/ecs/pki \
   --net=host \
   --env-file=/etc/ecs/ecs.config \
   amazon/amazon-ecs-agent:latest
   ```
**Nota**  
Se ricevi un messaggio `Error response from daemon: Cannot start container`, puoi eliminare il container che presenta l'errore con il comando **sudo docker rm ecs-agent** e tentare di eseguire nuovamente l'agente. 

# Windows ottimizzato per Amazon ECS AMIs
<a name="ecs-optimized_windows_AMI"></a>

I modelli ottimizzati per Amazon ECS AMIs sono preconfigurati con i componenti necessari per eseguire i carichi di lavoro Amazon ECS. Sebbene tu possa creare la tua AMI di istanza di container che soddisfi le specifiche di base necessarie per eseguire i tuoi carichi di lavoro containerizzati su Amazon ECS, gli AMI ottimizzati per Amazon ECS sono AMIs preconfigurati e testati su Amazon ECS da ingegneri. AWS È il modo più semplice per iniziare ed eseguire i container su AWS rapidamente.

I metadati dell'AMI ottimizzata per Amazon ECS, incluso il nome dell'AMI, la versione dell'agente del container di Amazon ECS e la versione runtime di Amazon ECS, che include la versione Docker, possono essere recuperati a livello di codice per ciascuna variante. Per ulteriori informazioni, consulta [Recupero dei metadati dell'AMI Windows ottimizzata per Amazon ECS](retrieve-ecs-optimized_windows_AMI.md).

**Importante**  
 Tutte le varianti AMI ottimizzate per ECS prodotte dopo agosto 2022 migreranno da Docker EE (Mirantis) a Docker CE (progetto Moby).  
Per garantire che i clienti dispongano degli ultimi aggiornamenti di sicurezza per impostazione predefinita, Amazon ECS mantiene almeno gli ultimi tre aggiornamenti di sicurezza ottimizzati per Windows Amazon AMIs ECS. Dopo aver rilasciato il nuovo Windows ottimizzato per Amazon ECS, AMIs Amazon ECS rende private le versioni precedenti ottimizzate per Amazon ECS AMIs . Se devi accedere a un'AMI privata, comunicacelo compilando un ticket con Cloud Support.

## Varianti AMI ottimizzate per Amazon ECS
<a name="ecs-optimized-ami-variants"></a>

Le seguenti varianti Windows Server dell'AMI ottimizzata per Amazon ECS sono disponibili per le istanze Amazon EC2.

**Importante**  
Tutte le varianti AMI ottimizzate per ECS prodotte dopo agosto migreranno da Docker EE (Mirantis) a Docker CE (progetto Moby).
+ **AMI completa per Windows Server 2025 ottimizzata per Amazon ECS** 
+ **AMI Core per Windows Server 2025 ottimizzata per Amazon ECS** 
+ **AMI Windows Server 2022 Full ottimizzata per Amazon ECS** 
+ **AMI Windows Server 2022 Core ottimizzata per Amazon ECS** 
+ **AMI Windows Server 2019 Full ottimizzata per Amazon ECS** 
+ **AMI Windows Server 2019 Core ottimizzata per Amazon ECS** 
+ **AMI Windows Server 2016 Full ottimizzata per Amazon ECS**

**Importante**  
Windows Server 2016 non supporta l'ultima versione di Docker, ad esempio la 25.x.x. Pertanto, Windows Server 2016 Full non AMIs riceverà patch di sicurezza o di bug nel runtime Docker. Ti suggeriamo di passare a una delle seguenti piattaforme Windows:  
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core

Il 9 agosto 2022, l'AMI Windows Server 20H2 Core ottimizzata per Amazon ECS ha raggiunto la data di fine del supporto. Non verranno rilasciate nuove versioni di questa AMI. Per ulteriori informazioni, consulta [Informazioni sulle versioni di Windows Server](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info).

Windows Server 2025, Windows Server 2022, Windows Server 2019 e Windows Server 2016 sono versioni LTSC (Long-Term Servicing Channel). Windows Server 20H2 è una versione SAC (Semi-Annual Channel). Per ulteriori informazioni, consulta [Informazioni sulle versioni di Windows Server](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info).

### Considerazioni
<a name="windows_caveats"></a>

Di seguito sono riportate alcune informazioni utili sui container Windows di Amazon EC2 e Amazon ECS.
+ I container Windows non possono essere eseguiti su istanze di container Linux e viceversa. Per assicurare il corretto posizionamento dei processi Windows e Linux, devi mantenere le relative istanze di container in cluster separati e posizionare solo i processi Windows nei cluster Windows. Puoi assicurare che le definizioni di processo di Windows vengano posizionate solo nelle istanze Windows impostando il seguente vincolo di posizionamento: `memberOf(ecs.os-type=='windows')`.
+ I container Windows sono supportati per le attività che utilizzano EC2 e Fargate.
+ I container Windows e le istanze di container non supportano tutti i parametri di definizione di attività disponibili per le istanze di container e i container Linux. Alcuni parametri non sono supportati, mentre altri si comportano in modo diverso su Windows e su Linux. Per ulteriori informazioni, consulta [Differenze nella definizione dell'attività di Amazon ECS per istanze EC2 eseguite su Windows](windows_task_definitions.md).
+ Per la funzionalità dei ruoli IAM per i processi, è necessario configurare le istanze di container Windows per consentire la funzionalità all'avvio. I contenitori devono eseguire il PowerShell codice fornito quando utilizzano la funzionalità. Per ulteriori informazioni, consulta [Configurazione aggiuntiva delle istanze Windows di Amazon EC2](task-iam-roles.md#windows_task_IAM_roles).
+ La funzionalità dei ruoli IAM per i processi utilizza un proxy di credenziali per fornire le credenziali ai container. Questo proxy di credenziali occupa la porta 80 nell'istanza di container, perciò se utilizzi i ruoli IAM per i processi, la porta 80 non è disponibile per i processi. Per i container di servizi Web, puoi utilizzare un Application Load Balancer e la mappatura di porte dinamiche per fornire connessioni di porta 80 HTTP standard ai container. Per ulteriori informazioni, consulta [Usa il bilanciamento del carico per distribuire il traffico del servizio Amazon ECS](service-load-balancing.md).
+ Le immagini Docker del server Windows sono di grandi dimensioni (9 GiB). Pertanto, le istanze di container di Windows richiedono più spazio di archiviazione rispetto alle istanze di container Linux.
+ Per eseguire un container Windows su Windows Server, la versione del sistema operativo dell'immagine di base del container deve corrispondere a quella dell'host. Per ulteriori informazioni, consultare [Compatibilità delle versioni dei container Windows](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11) sul sito Web della documentazione Microsoft. Se il cluster esegue più versioni di Windows, puoi assicurarti che un'attività venga posizionata su un'istanza EC2 in esecuzione sulla stessa versione utilizzando il vincolo di posizionamento: `memberOf(attribute:ecs.os-family == WINDOWS_SERVER_<OS_Release>_<FULL or CORE>)`. Per ulteriori informazioni, consulta [Recupero dei metadati dell'AMI Windows ottimizzata per Amazon ECS](retrieve-ecs-optimized_windows_AMI.md).

# Recupero dei metadati dell'AMI Windows ottimizzata per Amazon ECS
<a name="retrieve-ecs-optimized_windows_AMI"></a>

L'ID AMI, il nome dell'immagine, il sistema operativo, la versione dell'agente contenitore e la versione di runtime per ogni variante di Amazon ECS Optimized AMIs possono essere recuperati a livello di codice interrogando l'API Systems Manager Parameter Store. Per ulteriori informazioni sull'API Systems Manager Parameter Store, vedere [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html)e [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html).

**Nota**  
Per recuperare i metadati dell'AMI ottimizzata per Amazon ECS, l'utente di amministrazione deve disporre delle seguenti autorizzazioni IAM. Queste autorizzazioni sono state aggiunte alla policy IAM `AmazonECS_FullAccess`.  
ssm: GetParameters
ssm: GetParameter
ssm: GetParametersByPath

## Formato del parametro dell'archivio parametri di Systems Manager
<a name="ecs-optimized-ami-parameter-format"></a>

**Nota**  
I seguenti parametri dell'API Systems Manager Parameter Store sono obsoleti e non devono essere utilizzati per recuperare le versioni più recenti di Windows: AMIs  
`/aws/service/ecs/optimized-ami/windows_server/2016/english/full/recommended/image_id `
`/aws/service/ecs/optimized-ami/windows_server/2019/english/full/recommended/image_id`

Di seguito è riportato il formato del nome del parametro per ogni variante AMI ottimizzata per Amazon ECS.
+ Metadati AMI completi di Windows Server 2025:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
  ```
+ Metadati AMI Core di Windows Server 2025:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
  ```
+ Metadati dell'AMI di Windows Server 2022 Full:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
  ```
+ Metadati dell'AMI di Windows Server 2022 Core:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
  ```
+ Metadati dell'AMI di Windows Server 2019 Full:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
  ```
+ Metadati dell'AMI di Windows Server 2019 Core:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
  ```
+ Metadati dell'AMI di Windows Server 2016 Full:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
  ```

Il formato dei nomi di parametro seguente recupera i metadati dell'AMI stabile Windows Server 2019 completa più recente.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```

Di seguito viene mostrato un esempio dell'oggetto JSON restituito per il valore del parametro.

```
{
    "Parameters": [
        {
            "Name": "/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
            "Type": "String",
            "Value": "{\"image_name\":\"Windows_Server-2019-English-Full-ECS_Optimized-2023.06.13\",\"image_id\":\"ami-0debc1fb48e4aee16\",\"ecs_runtime_version\":\"Docker (CE) version 20.10.21\",\"ecs_agent_version\":\"1.72.0\"}",
            "Version": 58,
            "LastModifiedDate": "2023-06-22T19:37:37.841000-04:00",
            "ARN": "arn:aws:ssm:us-east-1::parameter/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
            "DataType": "text"
        }
    ],
    "InvalidParameters": []
}
```

Ognuno dei campi nell'output riportato sopra sono disponibili per essere interrogati come parametri secondari. Costruisci il percorso di parametro per un parametro secondario aggiungendo il nome del parametro secondario al percorso per l'AMI selezionata. Sono disponibili i seguenti parametri secondari:
+ `schema_version`
+ `image_id`
+ `image_name`
+ `os`
+ `ecs_agent_version`
+ `ecs_runtime_version`

## Esempi
<a name="ecs-optimized-ami-windows-parameter-examples"></a>

Negli esempi seguenti vengono illustrati i modi in cui è possibile recuperare i metadati per ogni variante dell'AMI ottimizzata per Amazon ECS.

### Recupero dei metadati dell'AMI ottimizzata per Amazon ECS stabile più recente
<a name="ecs-optimized-ami-windows-parameter-examples-1"></a>

Puoi recuperare l'ultima AMI stabile ottimizzata per Amazon ECS utilizzando AWS CLI i AWS CLI seguenti comandi.
+ **Per l'AMI completa di Windows Server 2025 ottimizzata per Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized --region us-east-1
  ```
+ **Per l'AMI Windows Server 2025 Core ottimizzata per Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized --region us-east-1
  ```
+ **Per l'AMI Windows Server 2022 Full ottimizzata per Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized --region us-east-1
  ```
+ **Per l'AMI Windows Server 2022 Core ottimizzata per Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized --region us-east-1
  ```
+ **Per l'AMI Windows Server 2019 Full ottimizzata per Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized --region us-east-1
  ```
+ **Per l'AMI Windows Server 2019 Core ottimizzata per Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized --region us-east-1
  ```
+ **Per l'AMI Windows Server 2016 Full ottimizzata per Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized --region us-east-1
  ```

### Utilizzo dell'ultima AMI ottimizzata per Amazon ECS consigliata in un modello CloudFormation
<a name="ecs-optimized-ami-windows-parameter-examples-5"></a>

Puoi consultare l'AMI ottimizzata per Amazon ECS più recente in un modello CloudFormation facendo riferimento al nome dell'archivio parametri di Systems Manager.

```
Parameters:
  LatestECSOptimizedAMI:
    Description: AMI ID
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized/image_id
```

# Versioni delle AMI Windows ottimizzate per Amazon ECS
<a name="ecs-windows-ami-versions"></a>

Visualizza le versioni attuali e precedenti di Amazon ECS Optimized AMIs e le versioni corrispondenti dell'agente container Amazon ECS, Docker e del pacchetto. `ecs-init`

I metadati dell'AMI ottimizzata per Amazon ECS, incluso l'ID AMI per ogni variante, possono essere recuperati a livello di programmazione. Per ulteriori informazioni, consulta [Recupero dei metadati dell'AMI Windows ottimizzata per Amazon ECS](retrieve-ecs-optimized_windows_AMI.md). 

Le seguenti schede mostrano un elenco di versioni ottimizzate per Windows Amazon ECS AMIs . Per informazioni dettagliate su come fare riferimento al parametro Systems Manager Parameter Store in un CloudFormation modello, vedere[Utilizzo dell'ultima AMI ottimizzata per Amazon ECS consigliata in un modello CloudFormation](retrieve-ecs-optimized_AMI.md#ecs-optimized-ami-parameter-examples-5).

**Importante**  
Per garantire che i clienti dispongano degli ultimi aggiornamenti di sicurezza per impostazione predefinita, Amazon ECS mantiene almeno gli ultimi tre aggiornamenti di sicurezza ottimizzati per Windows Amazon AMIs ECS. Dopo aver rilasciato il nuovo Windows ottimizzato per Amazon ECS, AMIs Amazon ECS rende private le versioni precedenti ottimizzate per Amazon ECS AMIs . Se devi accedere a un'AMI privata, comunicacelo compilando un ticket con Cloud Support.  
Windows Server 2016 non supporta l'ultima versione di Docker, ad esempio la 25.x.x. Pertanto, Windows Server 2016 Full non AMIs riceverà patch di sicurezza o di bug nel runtime Docker. Ti suggeriamo di passare a una delle seguenti piattaforme Windows:  
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core

**Nota**  
La registrazione del plug-in gMSA è stata migrata dalla registrazione basata su file `(C:\ProgramData\Amazon\gmsa)` a Windows Event logging  con la versione AMI di agosto 2025. Lo script di raccolta dei log pubblici raccoglierà tutti i log gMSA. Per ulteriori informazioni, consulta [Raccolta log dei container con il raccoglitore di log di Amazon ECS](ecs-logs-collector.md).

------
#### [ Windows Server 2025 Full AMI versions ]

La tabella seguente elenca le versioni attuali e precedenti dell'AMI Windows Server 2025 Full ottimizzata per Amazon ECS e le versioni corrispondenti dell'agente contenitore Amazon ECS e Docker.


|  AMI completa per Windows Server 2025 ottimizzata per Amazon ECS  |  Versione dell'agente del container Amazon ECS  |  Versione Docker  |  Visibilità  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2025-inglese-Full-ECS\$1Optimized-2026.03.13**  |  `1.102.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2025-Inglese-Full-ECS\$1Optimized-2026.02.13**  |  `1.101.3`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2025-inglese-Full-ECS\$1Optimized-2026.01.16**  |  `1.101.2`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2025-inglese-Full-ECS\$1Optimized-2025.12.13**  |  `1.101.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 

Usa il seguente AWS CLI comando per recuperare l'attuale AMI completa di Windows Server 2025 ottimizzata per Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
```

------
#### [ Windows Server 2025 Core AMI versions ]

La tabella seguente elenca le versioni attuali e precedenti dell'AMI Windows Server 2025 Core ottimizzata per Amazon ECS e le versioni corrispondenti dell'agente contenitore Amazon ECS e Docker.


|  AMI Core per Windows Server 2025 ottimizzata per Amazon ECS  |  Versione dell'agente del container Amazon ECS  |  Versione Docker  |  Visibilità  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2025-inglese-core-ECS\$1Optimized-2026.03.13**  |  `1.102.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2025-inglese-core-ecs\$1optimized-2026.02.13**  |  `1.101.3`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2025-inglese-core-ecs\$1optimized-2026.01.16**  |  `1.101.2`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2025-inglese-core-ecs\$1optimized-2025.12.13**  |  `1.101.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 

Usa il seguente AWS CLI comando per recuperare l'attuale AMI Windows Server 2025 Core ottimizzata per Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
```

------
#### [ Windows Server 2022 Full AMI versions ]

La tabella seguente riporta le versioni correnti e precedenti dell'AMI Windows Server 2022 Full ottimizzata per Amazon ECS e le corrispondenti versioni di Docker e dell'agente del container di Amazon ECS.


|  AMI Windows Server 2022 Full ottimizzata per Amazon ECS  |  Versione dell'agente del container Amazon ECS  |  Versione Docker  |  Visibilità  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2022-Inglese-Full-ECS\$1Optimized-2026.03.13**  |  `1.102.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2022-inglese-Full-ECS\$1Optimized-2026.02.13**  |  `1.101.3`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2022-inglese-Full-ECS\$1Optimized-2026.01.16**  |  `1.101.2`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2022-inglese-Full-ECS\$1Optimized-2025.12.13**  |  `1.101.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 

Usa il seguente AWS CLI comando per recuperare l'attuale AMI completa di Windows Server 2022 ottimizzata per Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
```

------
#### [ Windows Server 2022 Core AMI versions ]

La tabella seguente riporta le versioni correnti e precedenti dell'AMI Windows Server 2022 Core ottimizzata per Amazon ECS e le corrispondenti versioni di Docker e dell'agente del container di Amazon ECS.


|  AMI Windows Server 2022 Core ottimizzata per Amazon ECS  |  Versione dell'agente del container Amazon ECS  |  Versione Docker  |  Visibilità  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2026.03.13**  |  `1.102.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2022-inglese-core-ecs\$1optimized-2026.02.13**  |  `1.101.3`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2022-inglese-core-ecs\$1optimized-2026.01.16**  |  `1.101.2`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2022-inglese-core-ecs\$1optimized-2025.12.13**  |  `1.101.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 

Usa il seguente AWS CLI comando per recuperare l'attuale AMI completa di Windows Server 2022 ottimizzata per Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
```

------
#### [ Windows Server 2019 Full AMI versions ]

La tabella seguente riporta le versioni correnti e precedenti dell'AMI Windows Server 2019 Full ottimizzata per Amazon ECS e le corrispondenti versioni di Docker e dell'agente del container di Amazon ECS.


|  AMI Windows Server 2019 Full ottimizzata per Amazon ECS  |  Versione dell'agente del container Amazon ECS  |  Versione Docker  |  Visibilità  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2019-Inglese-Full-ECS\$1Optimized-2026.03.13**  |  `1.102.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2019-Inglese-Full-ECS\$1Optimized-2026.02.13**  |  `1.101.3`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2019-Inglese-Full-ECS\$1Optimized-2026.01.16**  |  `1.101.2`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2019-inglese-Full-ECS\$1Optimized-2025.12.13**  |  `1.101.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 

Usa il seguente AWS CLI comando per recuperare l'attuale AMI completa di Windows Server 2019 ottimizzata per Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```

------
#### [ Windows Server 2019 Core AMI versions ]

La tabella seguente riporta le versioni correnti e precedenti dell'AMI Windows Server 2019 Core ottimizzata per Amazon ECS e le corrispondenti versioni di Docker e dell'agente del container di Amazon ECS.


|  AMI Windows Server 2019 Core ottimizzata per Amazon ECS  |  Versione dell'agente del container Amazon ECS  |  Versione Docker  |  Visibilità  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2026.03.13**  |  `1.102.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2019-inglese-core-ecs\$1optimized-2026.02.13**  |  `1.101.3`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2019-inglese-core-ecs\$1optimized-2026.01.16**  |  `1.101.2`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2019-inglese-core-ecs\$1optimized-2025.12.13**  |  `1.101.0`  |  `25.0.6 (Docker CE)`  |  Pubblica  | 

Usa il seguente AWS CLI comando per recuperare l'attuale AMI completa di Windows Server 2019 ottimizzata per Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
```

------
#### [ Windows Server 2016 Full AMI versions ]

**Importante**  
Windows Server 2016 non supporta l'ultima versione di Docker, ad esempio la 25.x.x. Pertanto, Windows Server 2016 Full non AMIs riceverà patch di sicurezza o di bug nel runtime Docker. Ti suggeriamo di passare a una delle seguenti piattaforme Windows:  
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core

La tabella seguente riporta le versioni correnti e precedenti dell'AMI Windows Server 2016 Full ottimizzata per Amazon ECS e le corrispondenti versioni di Docker e dell'agente del container di Amazon ECS.


|  AMI Windows Server 2016 Full ottimizzata per Amazon ECS  |  Versione dell'agente del container Amazon ECS  |  Versione Docker  |  Visibilità  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2016-Inglese-Full-ECS\$1Optimized-2026.03.13**  |  `1.102.0`  |  `20.10.23 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2016-Inglese-Full-ECS\$1Optimized-2026.02.13**  |  `1.101.3`  |  `20.10.23 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2016-Inglese-Full-ECS\$1Optimized-2026.01.16**  |  `1.101.2`  |  `20.10.23 (Docker CE)`  |  Pubblica  | 
|  **Windows\$1Server-2016-inglese-Full-ECS\$1Optimized-2025.12.13**  |  `1.101.0`  |  `20.10.23 (Docker CE)`  |  Pubblica  | 

Utilizza la seguente AMI completa per Windows Server 2016 ottimizzata per AWS CLI Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
```

------

# Creazione dell'AMI Windows ottimizzata per Amazon ECS
<a name="windows-custom-ami"></a>

Usa EC2 Image Builder per creare la tua AMI Windows ottimizzata per Amazon ECS. In questo modo è facile utilizzare un'AMI di Windows con la propria licenza su Amazon ECS. Amazon ECS fornisce un componente di Image Builder gestito che fornisce la configurazione del sistema necessaria per eseguire istanze di Windows per ospitare i container. Ogni componente gestito da Amazon ECS include un agente del container specifico e una versione Docker. Puoi personalizzare l'immagine in modo da utilizzare l'ultimo componente gestito da Amazon ECS oppure, se è necessario un agente del container o una versione Docker precedente, puoi specificare un componente diverso.

Per una spiegazione passo per passo dell'utilizzo di EC2 Image Builder, consulta [Nozioni di base su EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/set-up-ib-env.html#image-builder-accessing-prereq) nella *Guida per l'utente di EC2 Image Builder*.

Quando crei la tua AMI Windows ottimizzata per Amazon ECS tramtie EC2 Image Builder, crei una ricetta per le immagini. La tua ricetta per le immagini deve soddisfare i seguenti requisiti:
+ L'**immagine di origine** deve essere basata su Windows Server 2019 Core, Windows Server 2019 Full, Windows Server 2022 Core o Windows Server 2022 Full. Altre eventuali versioni di Windows non sono supportate e potrebbero non essere compatibili con il componente.
+ Quando si specifica l'opzione **Crea componenti**, il componente `ecs-optimized-ami-windows` è obbligatorio. Il componente `update-windows`, che garantisce che l'immagine contenga gli aggiornamenti della sicurezza più recenti, è consigliato.

  Per specificare una versione diversa del componente, espandi il menu **Opzioni di controllo delle versioni** e specifica la versione del componente da utilizzare. Per ulteriori informazioni, consulta [Elenco delle versioni del componente `ecs-optimized-ami-windows`](#windows-component-list).

## Elenco delle versioni del componente `ecs-optimized-ami-windows`
<a name="windows-component-list"></a>

Quando crei una ricetta di EC2 Image Builder e specifichi il componente `ecs-optimized-ami-windows`, puoi utilizzare l'opzione di default oppure specificare una versione specifica del componente. Per determinare le versioni dei componenti che sono disponibili, insieme alle versioni dell'agente del container di Amazon ECS e del Docker contenute nel componente, puoi utilizzare la Console di gestione AWS.

**Come elencare le versioni del componente `ecs-optimized-ami-windows` disponibili**

1. Apri la console EC2 Image Builder [https://console.aws.amazon.com/imagebuilder/](https://console.aws.amazon.com/imagebuilder/)all'indirizzo.

1. Nella barra di navigazione seleziona la regione in cui viene creata l'immagine.

1. Nel pannello di navigazione, sotto il menu **Configurazioni salvate**, scegli **Componenti**.

1. Sulla pagina **Componenti**, nella barra di ricerca digita `ecs-optimized-ami-windows` ed espandi verso il basso il menu di qualificazione, quindi seleziona **Avvio rapido (gestito da Amazon)**.

1. Utilizza la colonna **Descrizione** per determinare la versione del componente con l'agente del container Amazon ECS e la versione Docker richiesta dall'immagine.

# Gestione delle istanze di container Windows Amazon ECS
<a name="manage-windows"></a>

Quando usi le istanze EC2 per i carichi di lavoro Amazon ECS, sei responsabile della manutenzione delle istanze.

Gli aggiornamenti dell'agente non si applicano alle istanze di container di Windows. Consigliamo di avviare nuove istanze di container per aggiornare la versione dell'agente nei cluster Windows.

**Topics**
+ [Avvio di un'istanza di container](launch_window-container_instance.md)
+ [Bootstrap delle istanze di container](bootstrap_windows_container_instance.md)
+ [Uso di un proxy HTTP per istanze di container Windows](http_proxy_config-windows.md)
+ [Configurazione delle istanze di container per ricevere avvisi sulle istanze spot](windows-spot-instance-draining-container.md)

# Avvio di un'istanza di container Windows di Amazon ECS
<a name="launch_window-container_instance"></a>

Le tue istanze di container di Amazon ECS sono create utilizzando la console Amazon EC2. Prima di iniziare, devi accertarti di aver completato le fasi in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md).

Per ulteriori informazioni sulla procedura guidata di avvio, consulta[Avvio di un'istanza tramite la nuova procedura guidata di avvio istanza](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-launch-instance-wizard.html) nella *Guida per l'utente di Amazon EC2*. 

È possibile utilizzare la nuova procedura guidata Amazon EC2 per avviare un'istanza. È possibile utilizzare il seguente elenco per i parametri e lasciare i parametri non elencati come predefiniti. Le seguenti istruzioni sono relative a ogni gruppo di parametri.

## Procedura
<a name="liw-initiate-instance-launch"></a>

Prima di iniziare, completa i passaggi descritti in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md).

1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Nella barra di navigazione nella parte superiore dello schermo, viene visualizzata la AWS regione corrente (ad esempio, Stati Uniti orientali (Ohio)). Selezionare una regione in cui avviare l'istanza. Questa scelta è importante perché, a differenza di altre, alcune risorse Amazon EC2 possono essere condivise tra più regioni. 

1. Dal pannello di controllo della console Amazon EC2, scegli **Launch Instance (Avvia istanza)**.

## Nome e tag
<a name="liw-name-and-tags"></a>

Il nome dell'istanza è un tag, dove la chiave è **Name (Nome)** e il valore è il nome specificato. È possibile aggiungere tag all'istanza, ai volumi e alla grafica elastica. Per le istanze spot, è possibile aggiungere un tag solo alla richiesta di istanza spot. 

La specifica di un nome di istanza e dei tag aggiuntivi è facoltativa.
+ Per **Name (Nome)**, inserire un nome descrittivo per l'istanza. Se non si specifica un nome, l'istanza può essere identificata dal relativo ID, che viene generato automaticamente all'avvio dell'istanza.
+ Per aggiungere altri tag, scegliere **Add additional tags (Aggiungi altri tag)**. Scegliere **Add tag (Aggiungi tag)**, quindi immettere una chiave e un valore e selezionare il tipo di risorsa da taggare. Scegliere **Add tag (Aggiungi tag)** per ogni tag aggiuntivo.

## Immagini di applicazioni e sistema operativo (Amazon Machine Image)
<a name="liw-ami"></a>

Un'Amazon Machine Image (AMI) contiene tutte le informazioni necessarie per creare un'istanza. Ad esempio, un'AMI può contenere il software necessario per fungere da server Web, ad esempio Apache e il sito Web.

Per le ultime versioni ottimizzate per Amazon ECS AMIs e i relativi valori, consulta Windows AMI ottimizzata per [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_windows_AMI.html).

Utilizza la barra **di ricerca** per trovare un'AMI ottimizzata per Amazon ECS adatta pubblicata da. AWS

1. **In base alle tue esigenze, inserisci una delle seguenti opzioni AMIs nella barra di **ricerca** e premi Invio.**
   + Windows\$1Server-2022-English-Full-ECS\$1Optimized
   + Windows\$1Server-2022-English-Core-ECS\$1Optimized
   + Windows\$1Server-2019-English-Full-ECS\$1Optimized
   + Windows\$1Server-2019-English-Core-ECS\$1Optimized
   + Windows\$1Server-2016-English-Full-ECS\$1Optimized

1. Nella pagina **Choose an Amazon Machine Image (AMI)**, seleziona la AMIs scheda **Community**.

1. Dall'elenco visualizzato, scegli un'AMI verificata da Microsoft con la data di pubblicazione più recente e fai clic su **Select** (seleziona).

## Tipo di istanza
<a name="liw-instance-type"></a>

Il tipo di istanza definisce la configurazione hardware e le dimensioni dell'istanza. I tipi di istanza più grandi dispongono di una maggiore quantità di CPU e memoria. Per ulteriori informazioni consulta la sezione relativa ai [tipi di istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
+ Per **Tipo di istanza**, selezionare il tipo di istanza per l'istanza. 

   Il tipo di istanza che selezioni determina le risorse disponibili per l'esecuzione delle attività.

## Coppia di chiavi (login)
<a name="liw-key-pair"></a>

In **Key pair name (Nome della coppia di chiavi)**, scegliere una coppia di chiavi esistente oppure scegliere **Create new key pair (Crea nuova coppia di chiavi)** per creane una nuova. 

**Importante**  
Se si sceglie l'opzione **Proceed without key pair (Not recommended)** (Procedi senza una coppia di chiavi [non consigliato]), non sarà possibile connetterti all'istanza a meno che non si scelga un'AMI configurata per offrire agli utenti un metodo di accesso alternativo.

## Impostazioni di rete
<a name="liw-network-settings"></a>

Configurare le impostazioni di rete, se necessario.
+ **Networking platform** Piattaforma di rete): scegli **Virtual Private Cloud (VPC)**, quindi specifica la sottorete nella sezione **Network interfaces** (Interfacce di rete). 
+ **VPC**: selezionare un VPC esistente in cui creare il gruppo di sicurezza.
+ **Sottorete**: è possibile avviare un'istanza in una sottorete associata a una zona di disponibilità, una Local Zone, una zona Wavelength o un Outpost.

  Per avviare l'istanza in una zona di disponibilità, selezionare la sottorete in cui avviare l'istanza. Per creare una nuova sottorete, scegliere **Create new subnet (Crea nuova sottorete)** per passare alla console Amazon VPC. Al termine, tornare alla procedura guidata di avvio istanza e scegliere Refresh (Aggiorna) per caricare la sottorete nell'elenco.

  Per avviare l'istanza in una Local Zone, selezionare una sottorete creata nella Local Zone. 

  Per avviare un'istanza in un Outpost, selezionare una sottorete in un VPC associato a un Outpost.
+ **Auto-assign Public IP** (IP pubblico di assegnazione automatica): se l'istanza deve essere accessibile da Internet, verifica che il campo **Auto-assign Public IP** (Assegna automaticamente IP pubblico) sia impostato su **Enable** (Abilita). In caso contrario, imposta il campo su **Disable** (Disabilita).
**Nota**  
Le istanze di container richiedono un accesso per comunicare con l'endpoint del servizio Amazon ECS. Ciò può avvenire attraverso un endpoint VPC di interfaccia o tramite istanze di container con indirizzi IP pubblici.  
Per ulteriori informazioni sugli endpoint VPC di interfaccia, vedi [Endpoint VPC dell'interfaccia di Amazon ECS (AWS PrivateLink)](vpc-endpoints.md)  
Se non disponi di un endpoint VPC di interfaccia configurato e le istanze di container non dispongono di indirizzi IP pubblici, per fornire questo accesso devono utilizzare il processo Network Address Translation (NAT). Per ulteriori informazioni, consulta [NAT gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) (Gateway NAT) nella *Guida per l'utente di Amazon VPC* e [Uso di un proxy HTTP per istanze di container Linux Amazon ECS](http_proxy_config.md) in questa guida.
+ **Firewall (security groups)** (Firewall [gruppi di sicurezza]): utilizza un gruppo di sicurezza per definire le regole del firewall per l'istanza di container. Tali regole specificano quale traffico di rete in entrata viene distribuito sull'istanza di container. Tutto il traffico rimanente verrà ignorato. 
  + Per selezionare un gruppo di sicurezza esistente, scegli **Select an existing security group** (Seleziona un gruppo di sicurezza esistente), quindi seleziona il gruppo di sicurezza creato in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md)

## Per configurare l'archiviazione
<a name="liw-storage"></a>

L'AMI selezionata include uno o più volumi di archiviazione, compreso il volume dispositivo root. È possibile specificare altri volumi da collegare all'istanza.

Puoi utilizzare la vista **Semplice**.
+ **Storage Type** (Tipo di storage): configura lo storage per l'istanza di container.

  Se stai utilizzando l'AMI Amazon Linux ottimizzata per Amazon ECS, l'istanza dispone di due volumi configurati. Il volume **Root** è per il sistema operativo, mentre il secondo volume di Amazon EBS (collegato a `/dev/xvdcz`) è per l'utilizzo di Docker.

  Puoi aumentare o diminuire le dimensioni del volume per l'istanza in modo che soddisfi le esigenze applicative.

## Dettagli avanzati
<a name="liw-advanced-details"></a>

Per **Advanced Details (Dettagli avanzati)**, espandi la sezione per visualizzare i campi e specifica eventuali parametri aggiuntivi per l'istanza.
+ **Purchasing option** (Opzioni di acquisto): seleziona **Request Spot Instances** (Richiedi istanze Spot) per avviare un'istanza Spot. Dovrai anche impostare altri campi correlati alle istanze Spot. Per ulteriori informazioni, consulta [Richiesta Istanza Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html).
**Nota**  
Se utilizzi istanze Spot e visualizzi un messaggio `Not available`, potresti dover scegliere un altro tipo di istanza.

  .
+ **Profilo istanza IAM**: seleziona il ruolo IAM dell'istanza di container. Questo di solito è chiamato `ecsInstanceRole`.
**Importante**  
Se non avvii l'istanza di container con le autorizzazioni IAM corrette, l'agente Amazon ECS non potrà connettersi al cluster. Per ulteriori informazioni, consulta [Ruolo IAM delle istanze di container Amazon ECS](instance_IAM_role.md).
+ (Facoltativo) **Dati utente**: configura l'istanza di container di Amazon ECS con i dati utente, ad esempio le variabili di ambiente dell'agente da [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md). Gli script di dati utente di Amazon EC2 vengono eseguiti solo una volta, al primo avvio dell'istanza. Di seguito sono elencati esempi comuni dei dati utente utilizzati per:
  + Di default, l'istanza di container si avvia nel cluster predefinito. Per avviarla in un cluster non predefinito, scegli l'elenco **Advanced Details** (Dettagli avanzati). Quindi, incolla lo script seguente nel campo **Dati utente**, sostituendolo *your\$1cluster\$1name* con il nome del cluster.

    La `EnableTaskIAMRole` attiva la funzionalità ruoli IAM dei processi per i processi.

    Inoltre, le seguenti opzioni sono disponibili quando si utilizza la modalità di rete `awsvpc`.
    + `EnableTaskENI`: questo flag attiva la rete di processi ed è necessario quando si utilizza la modalità di rete `awsvpc`.
    + `AwsvpcBlockIMDS`: questo flag facoltativo blocca l'accesso IMDS per i contenitori di processi in esecuzione con la modalità di rete `awsvpc`.
    + `AwsvpcAdditionalLocalRoutes`: questo flag facoltativo consente di avere percorsi aggiuntivi nel namespace dei processi.

      Sostituisci `ip-address` con l'indirizzo IP per le route aggiuntive, ad esempio 172.31.42.23/32.

    ```
    <powershell>
    Import-Module ECSTools
    Initialize-ECSAgent -Cluster your_cluster_name -EnableTaskIAMRole -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
    '["ip-address"]'
    </powershell>
    ```

# Bootstrap di istanze di container Windows Amazon ECS per il trasferimento dei dati
<a name="bootstrap_windows_container_instance"></a>

Quando avvii un'istanza Amazon EC2, puoi trasferire i dati utente all'istanza EC2. I dati possono essere utilizzati per eseguire attività di configurazione automatizzate di routine e anche per l'esecuzione di script all'avvio dell'istanza. Per Amazon ECS, i casi di utilizzo più comuni per i dati utente riguardano la trasmissione di informazioni sulla configurazione al daemon Docker e all'agente del container Amazon ECS.

Puoi trasferire diversi tipi di dati utente ad Amazon EC2, ad esempio hook di avvio del cloud, script di shell e direttive `cloud-init`. Per ulteriori informazioni su questi e altri tipi di formato, consulta la [documentazione su cloud-init](https://cloudinit.readthedocs.io/en/latest/explanation/format.html). 

È possibile passare questi dati utente quando si utilizza la procedura guidata di avvio di Amazon EC2. Per ulteriori informazioni, consulta [Avvio di un'istanza di container Linux di Amazon ECS](launch_container_instance.md).

## Data utente di Windows di default
<a name="windows-default-userdata"></a>

Questo script di dati utente di esempio mostra i dati utente predefiniti che le istanze di container Windows ricevono se si utilizza la console. Lo script sottostante esegue le seguenti operazioni:
+ Imposta il nome del cluster in base al nome inserito.
+ Imposta i ruoli IAM per i processi.
+ Imposta `json-file` e `awslogs` come i driver di log disponibili.

Inoltre, le seguenti opzioni sono disponibili quando si utilizza la modalità di rete `awsvpc`.
+ `EnableTaskENI`: questo flag attiva la rete di processi ed è necessario quando si utilizza la modalità di rete `awsvpc`.
+ `AwsvpcBlockIMDS`: questo flag facoltativo blocca l'accesso IMDS per i contenitori di processi in esecuzione con la modalità di rete `awsvpc`.
+ `AwsvpcAdditionalLocalRoutes`: questo flag facoltativo consente di avere route aggiuntive.

  Sostituisci `ip-address` con l'indirizzo IP per le route aggiuntive, ad esempio 172.31.42.23/32.

Puoi usare questo script per le istanze di container, purché siano avviate da un'AMI Windows Server ottimizzata per Amazon ECS. 

Sostituisci la riga `-Cluster cluster-name` per specificare il nome del cluster.

```
<powershell>
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
'["ip-address"]'
</powershell>
```

 Per le attività di Windows configurate per utilizzare il driver di registrazione `awslogs`, è necessario impostare anche la variabile di ambiente `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` nell'istanza di container. Utilizzare la seguente sintassi. 

Sostituisci la riga `-Cluster cluster-name` per specificare il nome del cluster.

```
<powershell>
[Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
</powershell>
```

## Dati utente dell'installazione dell'agente Windows
<a name="agent-service-userdata"></a>

In questo esempio lo script dei dati utente installa l'agente del container di Amazon ECS su un'istanza avviata con un'AMI **Windows\$1Server-2016-English-Full-Containers**. È stato adattato dalle istruzioni di installazione dell'agente nella pagina README del [ GitHubrepository Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent).

**Nota**  
Questo script è condiviso a scopo esemplificativo. È molto più facile iniziare a utilizzare i container di Windows con l'AMI Windows Server ottimizzata per Amazon ECS. Per ulteriori informazioni, consulta [Creazione di un cluster Amazon ECS per i carichi di lavoro Fargate](create-cluster-console-v2.md).

Per informazioni su come installare l'agente Amazon ECS su Windows Server 2022 Full, consulta il [numero 3753](https://github.com/aws/amazon-ecs-agent/issues/3753) su. GitHub

Puoi usare questo script per le tue istanze di container (purché siano avviate con una versione dell'AMI **Windows\$1Server-2016-English-Full-Containers**). Assicurati di sostituire la riga `windows` per specificare il nome del tuo cluster (se non utilizzi un cluster denominato `windows`).

```
<powershell>
# Set up directories the agent uses
New-Item -Type directory -Path ${env:ProgramFiles}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS\data -Force
# Set up configuration
$ecsExeDir = "${env:ProgramFiles}\Amazon\ECS"
[Environment]::SetEnvironmentVariable("ECS_CLUSTER", "windows", "Machine")
[Environment]::SetEnvironmentVariable("ECS_LOGFILE", "${env:ProgramData}\Amazon\ECS\log\ecs-agent.log", "Machine")
[Environment]::SetEnvironmentVariable("ECS_DATADIR", "${env:ProgramData}\Amazon\ECS\data", "Machine")
# Download the agent
$agentVersion = "latest"
$agentZipUri = "https://s3.amazonaws.com/amazon-ecs-agent/ecs-agent-windows-$agentVersion.zip"
$zipFile = "${env:TEMP}\ecs-agent.zip"
Invoke-RestMethod -OutFile $zipFile -Uri $agentZipUri
# Put the executables in the executable directory.
Expand-Archive -Path $zipFile -DestinationPath $ecsExeDir -Force
Set-Location ${ecsExeDir}
# Set $EnableTaskIAMRoles to $true to enable task IAM roles
# Note that enabling IAM roles will make port 80 unavailable for tasks.
[bool]$EnableTaskIAMRoles = $false
if (${EnableTaskIAMRoles}) {
  $HostSetupScript = Invoke-WebRequest https://raw.githubusercontent.com/aws/amazon-ecs-agent/master/misc/windows-deploy/hostsetup.ps1
  Invoke-Expression $($HostSetupScript.Content)
}
# Install the agent service
New-Service -Name "AmazonECS" `
        -BinaryPathName "$ecsExeDir\amazon-ecs-agent.exe -windows-service" `
        -DisplayName "Amazon ECS" `
        -Description "Amazon ECS service runs the Amazon ECS agent" `
        -DependsOn Docker `
        -StartupType Manual
sc.exe failure AmazonECS reset=300 actions=restart/5000/restart/30000/restart/60000
sc.exe failureflag AmazonECS 1
Start-Service AmazonECS
</powershell>
```

# Uso di un proxy HTTP per istanze di container Windows Amazon ECS
<a name="http_proxy_config-windows"></a>

Puoi configurare le tue istanze di container Amazon ECS per l'utilizzo di un proxy HTTP sia per l'agente del container Amazon ECS che per il daemon Docker. Ciò è utile se le tue istanze di container non hanno accesso alla rete esterna tramite un gateway Internet Amazon VPC, un gateway NAT o un'istanza.

Per configurare la tua istanza di container Windows di Amazon ECS per l'utilizzo di un proxy HTTP, imposta le seguenti variabili al momento dell'avvio (con i dati utente di Amazon EC2).

`[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.mydomain:port", "Machine")`  
Imposta `HTTP_PROXY` sul nome host (o indirizzo IP) e sul numero di porta di un proxy HTTP da utilizzare per l'agente Amazon ECS per connettersi a Internet. Ad esempio, le tue istanze di container potrebbero non avere accesso alla rete esterna tramite un gateway Internet Amazon VPC, un gateway NAT o un'istanza.

`[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")`  
Imposta `NO_PROXY` su `169.254.169.254,169.254.170.2,\\.\pipe\docker_engine` per filtrare i metadati dell'istanza EC2, i ruoli IAM per i processi e il traffico del daemon Docker dal proxy. 

**Example Script di dati utente per il proxy HTTP Windows**  
 PowerShell Lo script di dati utente di esempio riportato di seguito configura l'agente contenitore Amazon ECS e il daemon Docker per utilizzare un proxy HTTP specificato dall'utente. Puoi anche specificare un cluster in cui l'istanza di container si registra automaticamente.  
Per utilizzare questo script all'avvio di un'istanza di container, segui la procedura descritta in [Avvio di un'istanza di container Windows di Amazon ECS](launch_window-container_instance.md). Basta copiare e incollare lo PowerShell script seguente nel campo **Dati utente** (assicurati di sostituire i valori di esempio rossi con le informazioni sul tuo proxy e cluster).  
L'opzione `-EnableTaskIAMRole` è obbligatoria per l'abilitazione dei ruoli IAM per i processi. Per ulteriori informazioni, consulta [Configurazione aggiuntiva delle istanze Windows di Amazon EC2](task-iam-roles.md#windows_task_IAM_roles).

```
<powershell>
Import-Module ECSTools

$proxy = "http://proxy.mydomain:port"
[Environment]::SetEnvironmentVariable("HTTP_PROXY", $proxy, "Machine")
[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")

Restart-Service Docker
Initialize-ECSAgent -Cluster MyCluster -EnableTaskIAMRole
</powershell>
```

# Configurazione delle istanze di container Amazon ECS Windows per ricevere avvisi sulle istanze spot
<a name="windows-spot-instance-draining-container"></a>

Amazon EC2 termina, arresta o iberna l'istanza Spot quando il prezzo Spot supera il prezzo massimo per la richiesta o la capacità non è più disponibile. Amazon EC2 fornisce una notifica di interruzione dell'istanza spot, che dà all'istanza un preavviso di due minuti prima che venga interrotta. Se la funzione di svuotamento dell'istanza Spot di Amazon ECS è abilitata sull'istanza, ECS riceve l'avviso di interruzione dell'istanza Spot e posiziona l'istanza nello stato `DRAINING`.

**Importante**  
Amazon ECS monitora gli avvisi di interruzione dell'istanza Spot con le operazioni di istanza `terminate` e `stop`. Se hai specificato il comportamento di interruzione dell'istanza `hibernate` durante la richiesta di istanze Spot o del parco istanze Spot, la funzione di svuotamento delle istanze Spot di Amazon ECS non è supportata per tali istanze.

Quando un'istanza di container è impostata su `DRAINING`, Amazon ECS impedisce che venga pianificato il posizionamento di nuovi processi nell'istanza di container. Le attività di servizio nell'istanza di container di esaurimento che sono in stato `PENDING` vengono interrotte immediatamente. Se nel cluster sono disponibili istanze di container, le attività del servizio di sostituzione vengono avviate su di esse.

Puoi attivare lo svuotamento dell'istanza spot all'avvio di un'istanza. È necessario impostare il parametro `ECS_ENABLE_SPOT_INSTANCE_DRAINING` prima di avviare l'agente container. Sostituisci *my-cluster* con il nome del cluster.

```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_SPOT_INSTANCE_DRAINING", "true", "Machine")

# Initialize the agent
Initialize-ECSAgent -Cluster my-cluster
```

Per ulteriori informazioni, consulta [Avvio di un'istanza di container Windows di Amazon ECS](launch_window-container_instance.md).

# Cluster Amazon ECS per istanze esterne
<a name="ecs-anywhere"></a>

Amazon ECS Anywhere fornisce supporto per la registrazione di una *istanza esterna*, ad esempio un server on-premises o una macchina virtuale (VM) nel cluster Amazon ECS. Le istanze esterne sono ottimizzate per l'esecuzione di applicazioni che generano traffico in uscita o dati di processo. Se l'applicazione richiede traffico in entrata, la mancanza di supporto Elastic Load Balancing rende l'esecuzione di questi carichi di lavoro meno efficiente. Amazon ECS ha aggiunto un nuovo tipo di avvio `EXTERNAL` che è possibile utilizzare per creare servizi o eseguire processi sulle istanze esterne.

## Sistemi operativi e architetture di sistema supportati
<a name="ecs-anywhere-supported-os"></a>

Di seguito è riportato l'elenco dei sistemi operativi supportati. Le architetture CPU `x86_64` e `ARM64` sono supportate.
+ Amazon Linux 2023
+ Ubuntu 20, Ubuntu 22, Ubuntu 24
+ RHEL 9 — È necessario assicurarsi che Docker sia installato prima di eseguire lo script di installazione di [ECS Anywhere.](https://github.com/aws/amazon-ecs-agent/blob/master/scripts/ecs-anywhere-install.sh) Per ulteriori informazioni, consulta [Installare Docker Engine su RHEL](https://docs.docker.com/engine/install/rhel/) nella documentazione Docker.

A partire dal 7 agosto 2026, i seguenti sistemi operativi non sono più supportati da Amazon ECS Anywhere:
+ Amazon Linux 2
+ CentOS Stream 9
+ RIGA 7, RIGA 8
+ Fedora 32, Fedora 33, Fedora 40
+ openSUSE Tumbleweed
+ Ubuntu 18
+ Debian 9, Debian 10, Debian 11, Debian 12
+ SUSE Enterprise Server 15
+ Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 20H2

## Considerazioni
<a name="ecs-anywhere-considerations"></a>

Prima di iniziare a utilizzare le istanze esterne, tieni presente le considerazioni riportate di seguito.
+ Puoi registrare un'istanza esterna in un cluster alla volta. Per le istruzioni su come registrare un'istanza esterna con un cluster diverso, consulta [Annullamento della registrazione di un'istanza esterna Amazon ECS](ecs-anywhere-deregistration.md).
+ Le tue istanze esterne richiedono un ruolo IAM che consenta loro di comunicare con. AWS APIs Per ulteriori informazioni, consulta [Ruolo IAM di Amazon ECS Anywhere](iam-role-ecsanywhere.md).
+ Le istanze esterne non devono avere una catena di credenziali di istanze preconfigurata definita in locale in quanto ciò interferirà con lo script di registrazione.
+ Per inviare i log dei container a CloudWatch Logs, assicurati di creare e specificare un ruolo IAM per l'esecuzione delle attività nella definizione dell'attività. 
+ Quando un'istanza esterna viene registrata in un cluster, l'attributo `ecs.capability.external` è associato all'istanza. Questo attributo identificherà l'istanza come istanza esterna. Puoi aggiungere attributi personalizzati alle istanze esterne da utilizzare come vincolo di posizionamento dei processi. Per ulteriori informazioni, consulta [Attributi personalizzati](task-placement-constraints.md#ecs-custom-attributes).
+ È possibile aggiungere tag di risorsa all'istanza esterna. Per ulteriori informazioni, consulta [Aggiunta di tag alle istanze di container esterne per Amazon ECS](instance-details-tags-external.md).
+ ECS Exec è supportato sulle istanze esterne. Per ulteriori informazioni, consulta [Monitora i container Amazon ECS con ECS Exec](ecs-exec.md).
+ Di seguito sono riportate considerazioni aggiuntive specifiche per la rete con le istanze esterne. Per ulteriori informazioni, consulta [Rete](#ecs-anywhere-networking).
  + Il bilanciamento del carico dei servizi non è supportato.
  + Il rilevamento servizi non è supportato.
  + I processi eseguiti su istanze esterne devono utilizzare le modalità di rete `bridge`, `host` oppure `none`. La modalità di rete `awsvpc` non è supportata.
  + Esistono domini di servizio Amazon ECS in ogni AWS regione. Questi domini di servizio devono essere autorizzati a inviare traffico alle istanze esterne.
  + SSM Agent installato nell'istanza esterna mantiene le credenziali IAM che vengono ruotate ogni 30 minuti utilizzando un'impronta digitale hardware. Se l'istanza esterna perde la connessione a AWS, l'agente SSM aggiorna automaticamente le credenziali dopo che la connessione è stata ristabilita. Per ulteriori informazioni, consulta [Convalida di server on-premises e macchine virtuali con un'impronta digitale hardware](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation) nella *Guida per l'utente di AWS Systems Manager *.
  + È possibile eseguire attività Linux su istanze esterne in una configurazione IPv6 -only purché le istanze si trovino in sottoreti -only. IPv6 Per ulteriori informazioni, consulta [Utilizzo di un VPC in IPv6 modalità -only](task-networking.md#networking-ipv6-only).
+ L'API `UpdateContainerAgent` non è supportata. Per istruzioni su come aggiornare SSM Agent o l'agente Amazon ECS nelle istanze esterne, consulta [Aggiornamento dell' AWS Systems Manager agente e dell'agente container Amazon ECS su un'istanza esterna](ecs-anywhere-updates.md).
+ I provider di capacità Amazon ECS non sono supportati. Per creare un servizio o eseguire un processo autonomo nelle istanze esterne, utilizza il tipo di avvio `EXTERNAL`.
+ SELinux non è supportato.
+ L'uso di volumi Amazon EFS o la specifica di un `EFSVolumeConfiguration`non sono supportati.
+ L'integrazione con App Mesh non è supportata.
+ Se utilizzi la console per creare una definizione delle attività di istanza esterna, devi creare la definizione delle attività con l'editor JSON della console.
+ Quando utilizzi un'AMI non ottimizzata per Amazon ECS, esegui i seguenti comandi sull'istanza di container esterna per configurare le regole per utilizzare i ruoli IAM per le attività. Per ulteriori informazioni, consulta [Configurazione dell'istanza esterna aggiuntiva](task-iam-roles.md#enable_task_iam_roles).

  ```
  $ sysctl -w net.ipv4.conf.all.route_localnet=1
  $ iptables -t nat -A PREROUTING -p tcp -d 169.254.170.2 --dport 80 -j DNAT --to-destination 127.0.0.1:51679
  $ iptables -t nat -A OUTPUT -d 169.254.170.2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679
  ```

### Rete
<a name="ecs-anywhere-networking"></a>

Le istanze esterne di Amazon ECS sono ottimizzate per l'esecuzione di applicazioni che generano traffico in uscita o dati di processo. Se l'applicazione richiede traffico in entrata, ad esempio un servizio Web, la mancanza di supporto per Elastic Load Balancing rende l'esecuzione di questi carichi di lavoro meno efficiente perché non è disponibile il supporto per il posizionamento di questi carichi di lavoro dietro un bilanciatore del carico.

Di seguito sono riportate considerazioni aggiuntive specifiche per la rete con le istanze esterne. 
+ Il bilanciamento del carico dei servizi non è supportato.
+ Il rilevamento servizi non è supportato.
+ I processi Linux eseguiti su istanze esterne devono utilizzare le modalità di rete `bridge`, `host` oppure `none`. La modalità di rete `awsvpc` non è supportata. 

  Per ulteriori informazioni su ciascuna modalità di rete, consulta [Opzioni di rete delle attività Amazon ECS per le istanze EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html).
+ È possibile eseguire attività Linux su istanze esterne in una configurazione IPv6 -only purché le istanze si trovino in IPv6 sottoreti -only. Per ulteriori informazioni, consulta [Utilizzo di un VPC in IPv6 modalità -only](task-networking.md#networking-ipv6-only).
+ Esistono domini del servizio Amazon ECS in ogni regione e devi disporre dell'autorizzazione per inviare traffico alle istanze esterne.
+ SSM Agent installato nell'istanza esterna mantiene le credenziali IAM che vengono ruotate ogni 30 minuti utilizzando un'impronta digitale hardware. Se l'istanza esterna perde la connessione a AWS, l'agente SSM aggiorna automaticamente le credenziali dopo che la connessione è stata ristabilita. Per ulteriori informazioni, consulta [Convalida di server on-premises e macchine virtuali con un'impronta digitale hardware](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation) nella *Guida per l'utente di AWS Systems Manager *.

I seguenti domini vengono utilizzati per la comunicazione tra il servizio Amazon ECS e l'agente Amazon ECS installato nell'istanza esterna. Assicurati che il traffico sia consentito e che la risoluzione DNS funzioni. Per ogni endpoint, *region* rappresenta l'identificatore della regione per una AWS regione supportata da Amazon ECS, ad esempio `us-east-2` per la regione Stati Uniti orientali (Ohio). Gli endpoint per tutte le regioni utilizzate devono essere consentiti. Per gli endpoint `ecs-a` e `ecs-t`, è necessario includere un asterisco (ad esempio, `ecs-a-*`).
+ `ecs-a-*.region.amazonaws.com`: questo endpoint viene utilizzato per la gestione dei processi.
+ `ecs-t-*.region.amazonaws.com`: questo endpoint viene utilizzato per gestire i parametri di processi e container.
+ `ecs.region.amazonaws.com`: questo è l'endpoint del servizio per Amazon ECS.
+ `ssm.region.amazonaws.com `— Questo è l'endpoint del servizio per. AWS Systems Manager
+ `ec2messages.region.amazonaws.com`— Questo è l'endpoint di servizio AWS Systems Manager utilizzato per comunicare tra l'agente Systems Manager e il servizio Systems Manager nel cloud.
+ `ssmmessages.region.amazonaws.com`: questo endpoint del servizio necessario per creare ed eliminare canali di sessione con il servizio Session Manager nel cloud.
+ Se le tue attività richiedono la comunicazione con altri AWS servizi, assicurati che tali endpoint di servizio siano consentiti. Le applicazioni di esempio includono l'uso di Amazon ECR per estrarre le immagini dei contenitori o l'utilizzo CloudWatch per i CloudWatch log. Per ulteriori informazioni, consulta [Endpoint e quote](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) in *Riferimenti generali di AWS *.

### Amazon FSx for Windows File Server con ECS Anywhere
<a name="ecs-anywhere-fsx"></a>

**Importante**  
Il supporto Windows per Amazon ECS Anywhere è obsoleto. Questa sezione non è più applicabile.

Per utilizzarlo Amazon FSx for Windows File Server con le istanze esterne di Amazon ECS, devi stabilire una connessione tra il tuo data center locale e il. Cloud AWS Per maggiori informazioni sulle opzioni per connettere la rete al VPC, consulta [Opzioni di connettività di Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html).

### gMSA con ECS Anywhere
<a name="ecs-anywhere-gmsa"></a>

**Importante**  
Il supporto Windows per Amazon ECS Anywhere è obsoleto. Questa sezione non è più applicabile.

I seguenti casi d'uso erano supportati per ECS Anywhere quando Windows era un sistema operativo supportato.
+ Active Directory è in Cloud AWS : Per questa configurazione, si crea una connessione tra la rete locale e l' Cloud AWS utilizzo di una AWS Direct Connect connessione. Per informazioni su come creare la connessione, consulta [Opzioni di connettività di Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html). Crei un Active Directory nel Cloud AWS. Per informazioni su come iniziare AWS Directory Service, consulta [Configurazione AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/setting_up.html) nella *Guida all'AWS Directory Service amministrazione*. È quindi possibile aggiungere le istanze esterne al dominio utilizzando la AWS Direct Connect connessione. Per informazioni sull'utilizzo di GMSA con Amazon ECS, consulta [Informazioni su come utilizzare i gMSA per i container Windows EC2 per Amazon ECS](windows-gmsa.md).
+ Active Directory si trova nel data center on-premises. - Per questa configurazione, unisci le istanze esterne all'Active Directory on-premises. Quindi utilizzi le credenziali disponibili localmente quando esegui i processi di Amazon ECS.

# Creazione di un cluster Amazon ECS per i carichi di lavoro delle istanze esterne
<a name="create-cluster-console-v2-ecs-anywhere"></a>

Creazione di un cluster per definire l'infrastruttura in cui eseguire le attività e i servizi.

Prima di iniziare, accertati di aver completato le fasi in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md) e assegna l'autorizzazione IAM corretta. Per ulteriori informazioni, consulta [Esempi di cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). La console Amazon ECS offre un modo semplice per creare le risorse necessarie a un cluster Amazon ECS creando uno CloudFormation stack. 

Per rendere il processo di creazione del cluster il più semplice possibile, la console dispone di selezioni predefinite per molte scelte che descriviamo di seguito. Ci sono anche pannelli di aiuto disponibili per la maggior parte delle sezioni della console che forniscono ulteriore contesto. 

È possibile modificare le seguenti opzioni:
+ Aggiungi un namespace al cluster.

  Un namespace consente ai servizi creati nel cluster di connettersi agli altri servizi nel namespace senza configurazioni aggiuntive. Per ulteriori informazioni, consulta [Interconnessione dei servizi Amazon ECS](interconnecting-services.md).
+ Configurazione del cluster per le istanze esterne
+ Assegna una AWS KMS chiave per lo storage gestito. Per informazioni su come creare una chiave, consulta [Create a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *Guida per l'utente di AWS Key Management Service *.
+ Aggiungi tag per facilitare l'identificazione del cluster.

**Creazione di un nuovo cluster (console Amazon ECS)**

1. [Apri la console nella versione 2https://console.aws.amazon.com/ecs/.](https://console.aws.amazon.com/ecs/v2)

1. Seleziona la Regione da utilizzare nella barra di navigazione.

1. Nel pannello di navigazione scegli **Cluster**.

1. Nella pagina **Clusters** (Cluster), scegli **Create cluster** (Crea cluster).

1. In **Configurazione del cluster**, configura gli elementi seguenti:
   + In **Nome cluster**, inserisci un nome univoco.

     Il nome può contenere fino a 255 lettere (maiuscole e minuscole), numeri e trattini.
   + (Facoltativo) Per fare in modo che il namespace utilizzato per Service Connect sia diverso dal nome del cluster, in **Namespace**, inserisci un nome univoco.

1. (Facoltativo) Usa Container Insights, espandi **Monitoraggio**, quindi seleziona una delle seguenti opzioni:
   + Per usare la soluzione consigliata di Container Insights con osservabilità migliorata, seleziona **Container Insights con osservabilità migliorata**.
   + Per utilizzare Container Insights scegli **Container Insights**.

1. (Facoltativo) Per usare ECS Exec per eseguire il debug delle attività nel cluster, espandi **Configurazione della risoluzione dei problemi**. Quindi configura quanto segue:
   + Seleziona **Attiva ECS Exec**.
   + (Facoltativo) Per **AWS KMS key for ECS Exec**, inserisci l'ARN della AWS KMS chiave che desideri utilizzare per crittografare i dati della sessione ECS Exec.
   + (Facoltativo) Per la **registrazione di ECS Exec**, scegli la destinazione del log:
     + **Per inviare i log a CloudWatch Logs, scegli Amazon. CloudWatch**
     + Per inviare i log ad Amazon S3, seleziona **Amazon S3**.
     + Per disabilitare la registrazione, seleziona **Nessuno**.

1. (Facoltativo) Crittografa i dati sullo storage gestito. In **Crittografia**, per **Storage gestito**, inserisci l'ARN della AWS KMS chiave che desideri utilizzare per crittografare i dati di storage gestito.

1. (Facoltativo) Per identificare il tuo cluster, espandi la sezione **Tags** (Tag), quindi configura i tag.

   [Aggiungere un tag] Scegliere **Add tag (Aggiungi tag)** e procedere come segue:
   + In **Chiave**, immetti il nome della chiave.
   + In **Valore**, immetti il valore della chiave.

1. Scegli **Create** (Crea).

## Fasi successive
<a name="cluster-next-steps-ecs-anywhere"></a>

Devi registrare le istanze nel cluster. Per ulteriori informazioni, consulta [Registrazione di un'istanza esterna in un cluster Amazon ECS](ecs-anywhere-registration.md).

Crea una definizione dell'attività per il tipo di avvio esterno. Per ulteriori informazioni, consulta [Creazione di una definizione di attività di Amazon ECS attraverso la nuova console](create-task-definition.md)

Esegui le applicazioni come attività autonome o come parte di un servizio. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Esecuzione di un'applicazione come attività Amazon ECS](standalone-task-create.md)
+ [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md)

# Registrazione di un'istanza esterna in un cluster Amazon ECS
<a name="ecs-anywhere-registration"></a>

Per ogni istanza esterna che si registra con un cluster Amazon ECS, è necessario che sia installato SSM Agent, l'agente del container di Amazon ECS e Docker. Per registrare l'istanza esterna in un cluster Amazon ECS, deve prima essere registrata come istanza AWS Systems Manager gestita. Puoi creare lo script di installazione in pochi clic dalla console Amazon ECS. Lo script di installazione include una chiave di attivazione di Systems Manager e i comandi per installare ciascuno degli agenti richiesti e Docker. Per completare le fasi di installazione e registrazione, è necessario eseguire lo script di installazione sul server on-premises o sulla macchina virtuale.

**Nota**  
Prima di registrare l'istanza esterna Linux con il cluster, crea il file `/etc/ecs/ecs.config` sull'istanza esterna e aggiungi i parametri di configurazione dell'agente del container desiderati. Non è possibile eseguire questa operazione dopo aver registrato l'istanza esterna in un cluster. Per ulteriori informazioni, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md).

------
#### [ Console di gestione AWS ]

1. [Apri la console nella versione 2https://console.aws.amazon.com/ecs/.](https://console.aws.amazon.com/ecs/v2)

1. Seleziona la Regione da utilizzare nella barra di navigazione.

1. Nel pannello di navigazione scegli **Cluster**.

1. Sulla pagina **Cluster** scegli un cluster in cui registrare l'istanza esterna.

1. Nella *name* pagina **Cluster:**, scegli la scheda **Infrastruttura**.

1. Alla pagina **Register external instances** (Registra istanze esterne), completa la procedura seguente.

   1. Per **Durata della chiave di attivazione (in giorni)**specifica il numero di giorni per cui la chiave di attivazione rimane attiva. Una volta passati i giorni specificati, la chiave non funzionerà più quando si registra un'istanza esterna.

   1. Per **Numero di istanze** specifica il numero di istanze esterne che si desidera registrare nel cluster con la chiave di attivazione.

   1. Per **Ruolo dell'istanza**, scegli il ruolo IAM da associare alle istanze esterne. Se un ruolo non è già stato creato, scegli **Crea nuovo ruolo** perché Amazon ECS crei un ruolo per tuo conto. Per ulteriori informazioni sulle autorizzazioni IAM necessarie per le istanze esterne, consulta [Ruolo IAM di Amazon ECS Anywhere](iam-role-ecsanywhere.md).

   1.  Copia il comando di registrazione. Questo comando deve essere eseguito su ogni istanza esterna che si desidera registrare nel cluster.
**Importante**  
La parte bash dello script deve essere eseguita come root. Se il comando non viene eseguito come root, viene restituito un errore.

   1. Scegli **Chiudi**.

------
#### [ AWS CLI for Linux operating systems ]

1. Crea una coppia di attivazione di Systems Manager. Viene utilizzato per l'attivazione dell'istanza gestita di Systems Manager. L'output include un `ActivationId` e un `ActivationCode`. Utilizzerai questa funzione in una fase successiva. Assicurati di specificare il ruolo IAM ECS Anywhere creato. Per ulteriori informazioni, consulta [Ruolo IAM di Amazon ECS Anywhere](iam-role-ecsanywhere.md).

   ```
   aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
   ```

1. Scarica lo script di installazione sul server on-premises o nella macchina virtuale (VM).

   ```
   curl --proto "https" -o "/tmp/ecs-anywhere-install.sh" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
   ```

1. (Facoltativo) Sul server on-premises o nella macchina virtuale (VM), completa la procedura seguente per verificare lo script di installazione utilizzando il file di firma dello script.

   1. Scarica e installa GnuPG. Per maggiori informazioni GNUpg, consulta il sito web di [GnuPG](https://www.gnupg.org). Per i sistemi Linux, installa `gpg` usando il programma di gestione dei pacchetti che preferisci per Linux.

   1. Recupera la chiave pubblica PGP di Amazon ECS.

      ```
      gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
      ```

   1. Scarica la firma dello script di installazione. La firma è una firma PGP scollegata da ASCII archiviata in file con estensione `.asc`.

      ```
      curl --proto "https" -o "/tmp/ecs-anywhere-install.sh.asc" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh.asc"
      ```

   1. Verifica il file dello script di installazione utilizzando la chiave.

      ```
      gpg --verify /tmp/ecs-anywhere-install.sh.asc /tmp/ecs-anywhere-install.sh
      ```

      L'output previsto è il seguente:

      ```
      gpg: Signature made Tue 25 May 2021 07:16:29 PM UTC
      gpg:                using RSA key 50DECCC4710E61AF
      gpg: Good signature from "Amazon ECS <ecs-security@amazon.com>" [unknown]
      gpg: WARNING: This key is not certified with a trusted signature!
      gpg:          There is no indication that the signature belongs to the owner.
      Primary key fingerprint: F34C 3DDA E729 26B0 79BE  AEC6 BCE9 D9A4 2D51 784F
           Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB  346F 50DE CCC4 710E 61AF
      ```

1. Esegui lo script di installazione sul server on-premises o nella macchina virtuale (VM). Specifica il nome del cluster, la regione, l'ID di attivazione e il codice di attivazione di Systems Manager dalla prima fase.

   ```
   sudo bash /tmp/ecs-anywhere-install.sh \
       --region $REGION \
       --cluster $CLUSTER_NAME \
       --activation-id $ACTIVATION_ID \
       --activation-code $ACTIVATION_CODE
   ```

   Per un server on-premises o una macchina virtuale (VM) con il driver NVIDIA installato per i carichi di lavoro della GPU, è necessario aggiungere il flag `--enable-gpu` allo script di installazione. Quando viene specificato questo flag, lo script di installazione verifica che il driver NVIDIA sia in esecuzione e quindi aggiunge le variabili di configurazione necessarie per eseguire i processi Amazon ECS. Per ulteriori informazioni sull'esecuzione dei carichi di lavoro della GPU e sulla definizione dei requisiti della GPU in una definizione di attività, consulta [Specificazione GPUs in una definizione di attività Amazon ECS](ecs-gpu-specifying.md).

   ```
   sudo bash /tmp/ecs-anywhere-install.sh \
       --region $REGION \
       --cluster $CLUSTER_NAME \
       --activation-id $ACTIVATION_ID \
       --activation-code $ACTIVATION_CODE \
       --enable-gpu
   ```

Utilizza la seguente procedura per registrare un'istanza esterna esistente con un cluster diverso.

**Come registrare un'istanza esterna esistente con un cluster diverso**

1. Arresta l'agente del container di Amazon ECS.

   ```
   sudo systemctl stop ecs.service
   ```

1. Modifica il file `/etc/ecs/ecs.config` e alla riga `ECS_CLUSTER`, assicurati che il nome del cluster corrisponda al nome del cluster con cui registrare l'istanza esterna.

1. Rimuovi i dati esistenti dell'agente Amazon ECS.

   ```
   sudo rm /var/lib/ecs/data/agent.db
   ```

1. Avvia l'agente del container di Amazon ECS.

   ```
   sudo systemctl start ecs.service
   ```

------
#### [ AWS CLI for Windows operating systems ]

1. Crea una coppia di attivazione di Systems Manager. Viene utilizzato per l'attivazione dell'istanza gestita di Systems Manager. L'output include un `ActivationId` e un `ActivationCode`. Utilizzerai questa funzione in una fase successiva. Assicurati di specificare il ruolo IAM ECS Anywhere creato. Per ulteriori informazioni, consulta [Ruolo IAM di Amazon ECS Anywhere](iam-role-ecsanywhere.md).

   ```
   aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
   ```

1. Scarica lo script di installazione sul server on-premises o nella macchina virtuale (VM).

   ```
   Invoke-RestMethod -URI "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install.ps1" -OutFile “ecs-anywhere-install.ps1”
   ```

1. (Facoltativo) Lo script Powershell è firmato da Amazon e pertanto Windows esegue automaticamente la convalida del certificato sullo stesso. Non è necessario eseguire alcuna convalida manuale.

   Per verificare manualmente il certificato, fai clic con il pulsante destro del mouse sul file, accedi alle proprietà e utilizza la scheda Digital Signatures (Firme digitali) per ottenere ulteriori dettagli.

   Questa opzione è disponibile solo quando l'host ha il certificato nell'archivio dei certificati.

   La verifica dovrebbe restituire informazioni simili alle seguenti:

   ```
   # Verification (PowerShell)
   Get-AuthenticodeSignature -FilePath .\ecs-anywhere-install.ps1
   
   SignerCertificate                         Status      Path
   -----------------                         ------      ----
   EXAMPLECERTIFICATE                        Valid       ecs-anywhere-install.ps1
   
   ...
   
   Subject              : CN="Amazon Web Services, Inc.",...
   
   ----
   ```

1. Esegui lo script di installazione sul server on-premises o nella macchina virtuale (VM). Specifica il nome del cluster, la regione, l'ID di attivazione e il codice di attivazione di Systems Manager dalla prima fase.

   ```
   .\ecs-anywhere-install.ps1 -Region $Region -Cluster $Cluster -ActivationID $ActivationID -ActivationCode $ActivationCode
   ```

1. Verifica che l'agente del container Amazon ECS sia in esecuzione.

   ```
   Get-Service AmazonECS
   
   Status   Name               DisplayName
   ------   ----               -----------
   Running  AmazonECS          Amazon ECS
   ```

Utilizza la seguente procedura per registrare un'istanza esterna esistente con un cluster diverso.

**Come registrare un'istanza esterna esistente con un cluster diverso**

1. Arresta l'agente del container di Amazon ECS.

   ```
   Stop-Service AmazonECS
   ```

1. Modifica il parametro `ECS_CLUSTER` in modo che il nome del cluster corrisponda al nome del cluster con cui registrare l'istanza esterna.

   ```
   [Environment]::SetEnvironmentVariable("ECS_CLUSTER", $ECSCluster, [System.EnvironmentVariableTarget]::Machine)
   ```

1. Rimuovi i dati esistenti dell'agente Amazon ECS.

   ```
   Remove-Item -Recurse -Force $env:ProgramData\Amazon\ECS\data\*
   ```

1. Avvia l'agente del container di Amazon ECS.

   ```
   Start-Service AmazonECS
   ```

------

 AWS CLI Può essere utilizzato per creare un'attivazione di Systems Manager prima di eseguire lo script di installazione per completare il processo di registrazione dell'istanza esterna.

# Annullamento della registrazione di un'istanza esterna Amazon ECS
<a name="ecs-anywhere-deregistration"></a>

Ti consigliamo di annullare la registrazione dell'istanza sia da Amazon ECS che AWS Systems Manager dopo aver terminato con l'istanza. In seguito all'annullamento della registrazione, l'istanza esterna non è più in grado di accettare nuovi processi.

Se hai processi in esecuzione nell'istanza di container al momento dell'annullamento della registrazione, questi processi continueranno a essere in esecuzione fino all'arresto in altri modi. Tuttavia, questi processi sono orfani (non più monitorati o tenuti in conto da Amazon ECS). Se questi processi sull'istanza esterna fanno parte di un servizio Amazon ECS, allora se possibile il pianificatore di servizi avvia un'altra copia del processo su un'istanza differente.

Dopo aver annullato la registrazione dell'istanza, pulisci le risorse rimanenti AWS sull'istanza. Potrai quindi registrarla in un nuovo cluster.

## Procedura
<a name="ecs-anywhere-deregistration-procedure"></a>

------
#### [ Console di gestione AWS ]

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Dalla barra di navigazione, scegli la Regione in cui l'istanza esterna è registrata.

1. Nel riquadro di navigazione, scegli **Cluster** e seleziona il cluster che ospita l'istanza esterna.

1. Nella *name* pagina **Cluster:**, scegli la scheda **Infrastruttura**.

1. In **Container instances** (Istanze di container), seleziona l'ID dell'istanza esterna per la quale annullare la registrazione. Si sarà reindirizzati alla pagina dei dettagli dell'istanza di container.

1. Nella *id* pagina **Container Instance:**, scegli **Annulla registrazione**.

1. Esamina il messaggio di annullamento della registrazione. Seleziona **Annulla registrazione da AWS Systems Manager** per annullare la registrazione dell'istanza esterna come istanza gestita da Systems Manager. Scegli **Annulla registrazione**.
**Nota**  
È possibile annullare la registrazione dell'istanza esterna come istanza gestita da Systems Manager nella console di Systems Manager. Per istruzioni, consulta [Annullare la registrazione di nodi gestiti in ambienti ibridi e multicloud](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-deregister-hybrid-nodes.html) nella *Guida per l'utente di AWS Systems Manager *.

1. Dopo aver annullato la registrazione dell'istanza, pulisci AWS le risorse sul server o sulla macchina virtuale locale.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)

------
#### [ AWS CLI ]

1. Per annullare la registrazione dell'istanza di container, sono necessari l'ID istanza e l'ARN dell'istanza di container. Se non disponi di questi valori, esegui i comandi seguenti

   Esegui il comando seguente per ottenere l'ID istanza.

   Utilizza l'ID dell'istanza (`instanceID`) per ottenere l'ARN dell'istanza di container (`containerInstanceARN`).

   ```
   instanceId=$(aws ssm describe-instance-information --region "{{ region }}" | jq ".InstanceInformationList[] |select(.IPAddress==\"{{ IPv4 Address }}\") | .InstanceId" | tr -d'"'
   ```

   Esegui i comandi seguenti.

   Utilizza `containerInstanceArn`come parametro nel comando per annullare la registrazione dell'istanza (`deregister-container-instance`).

   ```
   instances=$(aws ecs list-container-instances --cluster "{{ cluster }}" --region "{{ region }}" | jq -c '.containerInstanceArns')
   containerInstanceArn=$(aws ecs describe-container-instances --cluster "{{ cluster }}" --region "{{ region }}" --container-instances $instances | jq ".containerInstances[] | select(.ec2InstanceId==\"{{ instanceId }}\") | .containerInstanceArn" | tr -d '"')
   ```

1.  Esegui il seguente comando per svuotare l'istanza.

   ```
   aws ecs update-container-instances-state --cluster "{{ cluster }}" --region "{{ region }}" --container-instances "{{ containerInstanceArn }}" --status DRAINING
   ```

1. Al termine dell'operazione, esegui il comando seguente per annullare la registrazione dell'istanza.

   ```
   aws ecs deregister-container-instance --cluster "{{ cluster }}" --region "{{ region }}" --container-instance "{{ containerInstanceArn }}"
   ```

1. Esegui il comando seguente per rimuovere l'istanza di container da SSM.

   ```
   aws ssm deregister-managed-instance --region "{{ region }}" --instance-id "{{ instanceId }}"
   ```

1. Dopo aver annullato la registrazione dell'istanza, pulisci le AWS risorse sul server o sulla macchina virtuale locale.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)

------

# Aggiornamento dell' AWS Systems Manager agente e dell'agente container Amazon ECS su un'istanza esterna
<a name="ecs-anywhere-updates"></a>

Il server o la macchina virtuale locale deve eseguire sia l' AWS Systems Manager agente (agente SSM) che l'agente contenitore Amazon ECS durante l'esecuzione di carichi di lavoro Amazon ECS. AWS rilascia nuove versioni di questi agenti ogni volta che vengono aggiunte o aggiornate funzionalità. Se le istanze esterne utilizzano una versione precedente di entrambi gli agenti, è possibile aggiornarle utilizzando le procedure riportate di seguito.

## Aggiornamento di SSM Agent su un'istanza esterna
<a name="ecs-anywhere-updates-ssmagent"></a>

AWS Systems Manager consiglia di automatizzare il processo di aggiornamento dell'agente SSM sulle istanze. Forniscono diversi metodi per automatizzare gli aggiornamenti. Per ulteriori informazioni, consulta [Automazione degli aggiornamenti a SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-automatic-updates.html) nella *Guida per l'utente di AWS Systems Manager *.

## Aggiornamento dell'agente di Amazon ECS su un'istanza esterna
<a name="ecs-anywhere-updates-ecsagent"></a>

Nelle istanze esterne, l'agente del container Amazon ECS viene aggiornato aggiornando il pacchetto `ecs-init`. L'aggiornamento dell'agente di Amazon ECS non interrompe i processi o i servizi in esecuzione. Amazon ECS fornisce il pacchetto `ecs-init` e il file di firma in un bucket Amazon S3 in ciascuna regione. A cominciare da `ecs-init` versione `1.52.1-1`, Amazon ECS fornisce pacchetti `ecs-init` da utilizzare in base al sistema operativo e all'architettura di sistema utilizzata dall'istanza esterna. 

Utilizza la seguente tabella per determinare il pacchetto `ecs-init` da scaricare in base al sistema operativo e all'architettura di sistema utilizzata dall'istanza esterna.

**Nota**  
È possibile determinare il sistema operativo e l'architettura di sistema utilizzati dall'istanza esterna utilizzando i comandi riportati di seguito.  

```
cat /etc/os-release
uname -m
```


| Sistemi operativi (architettura) | Pacchetto ecs-init | 
| --- | --- | 
|  CentOS 7 (x86\$164) CentOS 8 (x86\$164) CentOS Stream 9 (x86\$164) SUSE Enterprise Server 15 (x86\$164) RHEL 7 (x86\$164) RHEL 8 (x86\$164)  |  `amazon-ecs-init-latest.x86_64.rpm`  | 
|  CentOS 7 (aarch64) CentOS 8 (aarch64) CentOS Stream 9 (aarch64) RHEL 7 (aarch64)  |  `amazon-ecs-init-latest.aarch64.rpm`  | 
|  Debian 9 (x86\$164) Debian 10 (x86\$164) Debian 11 (x86\$164) Debian 12 (x86\$164) Ubuntu 18 (x86\$164) Ubuntu 20 (x86\$164) Ubuntu 22 (x86\$164) Ubuntu 24 (x86\$164)  |  `amazon-ecs-init-latest.amd64.deb`  | 
|  Debian 9 (aarch64) Debian 10 (aarch64) Debian 11 (aarch64) Debian 12 (aarch64) Ubuntu 18 (aarch64) Ubuntu 20 (aarch64) Ubuntu 22 (aarch64) Ubuntu 24 (aarch64)  |  `amazon-ecs-init-latest.arm64.deb`  | 

Completa questa procedura per aggiornare l'agente Amazon ECS. 

**Come aggiornare l'agente Amazon ECS**

1. Conferma la versione dell'agente Amazon ECS in esecuzione.

   ```
   curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
   ```

1. Scarica il pacchetto `ecs-init` per il sistema operativo e l'architettura di sistema in uso. Amazon ECS fornisce il file del pacchetto `ecs-init` in un bucket Amazon S3 in ciascuna regione. Assicurati di sostituire l'*<region>*identificatore nel comando con il nome della regione (ad esempio,`us-west-2`) a cui sei geograficamente più vicino.

   **amazon-ecs-init-latest.x86\$164.rpm**

   ```
   curl -o amazon-ecs-init.rpm https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.x86_64.rpm
   ```

   **amazon-ecs-init-latest.aarch64 rpm**

   ```
   curl -o amazon-ecs-init.rpm https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.aarch64.rpm
   ```

   **amazon-ecs-init-latest.amd64.deb**

   ```
   curl -o amazon-ecs-init.deb https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.amd64.deb
   ```

   **amazon-ecs-init-latest.arm64.deb**

   ```
   curl -o amazon-ecs-init.deb https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.arm64.deb
   ```

1. (Facoltativo) Verifica la validità del file del pacchetto `ecs-init` utilizzando la firma PGP.

   1. Scarica e installa GnuPG. Per maggiori informazioni GNUpg, consulta il sito web di [GnuPG](https://www.gnupg.org). Per i sistemi Linux, installa `gpg` usando il programma di gestione dei pacchetti che preferisci per Linux.

   1. Recupera la chiave pubblica PGP di Amazon ECS.

      ```
      gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
      ```

   1. Scarica la firma del pacchetto `ecs-init`. La firma è una firma PGP scollegata da ASCII archiviata in file con estensione `.asc`. Amazon ECS fornisce il file di firma in un bucket Amazon S3 in ciascuna regione. Assicurati di sostituire l'*<region>*identificatore nel comando con il nome della regione (ad esempio,`us-west-2`) a cui sei geograficamente più vicino.

      **amazon-ecs-init-latest.x86\$164.rpm**

      ```
      curl -o amazon-ecs-init.rpm.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.x86_64.rpm.asc
      ```

      **amazon-ecs-init-latest.aarch64 rpm**

      ```
      curl -o amazon-ecs-init.rpm.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.aarch64.rpm.asc
      ```

      **amazon-ecs-init-latest.amd64.deb**

      ```
      curl -o amazon-ecs-init.deb.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.amd64.deb.asc
      ```

      **amazon-ecs-init-latest.arm64.deb**

      ```
      curl -o amazon-ecs-init.deb.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.arm64.deb.asc
      ```

   1. Verificare il file del pacchetto `ecs-init` usando la chiave.

      **Per i pacchetti `rpm`**

      ```
      gpg --verify amazon-ecs-init.rpm.asc ./amazon-ecs-init.rpm
      ```

      **Per i pacchetti `deb`**

      ```
      gpg --verify amazon-ecs-init.deb.asc ./amazon-ecs-init.deb
      ```

      L'output previsto è il seguente:

      ```
      gpg: Signature made Fri 14 May 2021 09:31:36 PM UTC
      gpg:                using RSA key 50DECCC4710E61AF
      gpg: Good signature from "Amazon ECS <ecs-security@amazon.com>" [unknown]
      gpg: WARNING: This key is not certified with a trusted signature!
      gpg:          There is no indication that the signature belongs to the owner.
      Primary key fingerprint: F34C 3DDA E729 26B0 79BE  AEC6 BCE9 D9A4 2D51 784F
           Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB  346F 50DE CCC4 710E 61AF
      ```

1. Installare il pacchetto `ecs-init`.

   **Per il pacchetto `rpm` su CentOS 7, CentOS 8 e RHEL 7**

   ```
   sudo yum install -y ./amazon-ecs-init.rpm
   ```

   **Per il pacchetto `rpm` su SUSE Enterprise Server 15**

   ```
   sudo zypper install -y --allow-unsigned-rpm ./amazon-ecs-init.rpm
   ```

   **Per il pacchetto `deb`**

   ```
   sudo dpkg -i ./amazon-ecs-init.deb
   ```

1. Riavvia il servizio `ecs`.

   ```
   sudo systemctl restart ecs
   ```

1. Verifica che la versione dell'agente Amazon ECS sia stata aggiornata.

   ```
   curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
   ```

# Aggiornamento di un cluster Amazon ECS
<a name="update-cluster-v2"></a>

Puoi modificare le seguenti proprietà del cluster:
+ Imposta un fornitore di capacità di default

  Ogni cluster ha uno o più fornitori di capacità e una strategia di fornitori di capacità facoltativa. La strategia del fornitore di capacità determina il modo in cui le attività vengono distribuite tra i fornitori di capacità del cluster. Quando esegui un’attività autonoma o crei un servizio, puoi utilizzare la strategia del fornitore di capacità predefinita del cluster o specificare una strategia che sostituisce quella del cluster.
+ Attiva Container Insights.

  CloudWatch Container Insights raccoglie, aggrega e riepiloga metriche e log delle applicazioni e dei microservizi containerizzati. Container Insights fornisce inoltre informazioni diagnostiche, ad esempio errori di riavvio del container, che puoi usare per isolare i problemi e risolverli in modo rapido. Per ulteriori informazioni, consulta [Monitora i container di Amazon ECS utilizzando Container Insights con osservabilità migliorata.](cloudwatch-container-insights.md).
+ Aggiungi tag per facilitare l'identificazione dei cluster.

**Procedura**

1. Apri [https://console.aws.amazon.com/ecs/la](https://console.aws.amazon.com/ecs/v2) console nella versione 2.

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella *name* pagina **Cluster:**, scegli **Aggiorna cluster**.

1. Per impostare il provider di capacità predefinito, in **Strategia predefinita del provider di capacità**, scegli **Aggiungi altro**.

   1. Scegli il provider in **Provider di capacità**.

   1. (Facoltativo) Per **Base**, inserisci il numero minimo di attività eseguite sul provider di capacità. 

      Puoi impostare solo un valore **Base** per ogni provider di capacità.

   1. (Facoltativo) Per **Peso**, inserisci la percentuale relativa al numero totale di attività avviate che utilizzano il provider di capacità specificato.

   1. (Facoltativo) Ripeti i passaggi per eventuali provider di capacità aggiuntivi.

1. Per attivare o disattivare Container Insights, espandi **Monitoraggio** e poi attiva **Utilizza Container Insights**.

1. Per identificare il tuo cluster, espandi la sezione **Tag**, quindi configura i tag.

   [Aggiungere un tag] Scegliere **Add tag (Aggiungi tag)** e procedere come segue:
   + In **Chiave**, immetti il nome della chiave.
   + In **Valore**, immetti il valore della chiave.

   [Rimuovi un tag] Scegli **Rimuovi** a destra della Chiave e del Valore del tag.

1. Scegliere **Aggiorna**.

# Eliminare un cluster Amazon ECS
<a name="delete_cluster-new-console"></a>

Al termine dell'utilizzo di un cluster, puoi eliminarlo. Dopo aver eliminato il cluster, lo stato di quest'ultimo diventa `INACTIVE`. I cluster con stato `INACTIVE` potrebbero rimanere individuabili nel tuo account per un periodo di tempo. Tuttavia, questo comportamento è soggetto a modifiche in futuro, quindi non dovresti fare affidamento sulla persistenza dei cluster `INACTIVE`.

Prima di eliminare un cluster, esegui le operazioni seguenti:
+ Elimina tutti i servizi del cluster. Per ulteriori informazioni, consulta [Eliminazione di un servizio Amazon ECS utilizzando la console](delete-service-v2.md).
+ Interrompi tutti i processi attualmente in esecuzione. Per ulteriori informazioni, consulta [Interruzione di un'attività di Amazon ECS](standalone-task-stop.md).
+ Annulla la registrazione di tutte le istanze del container registrate nel cluster. Per ulteriori informazioni, consulta [Annullamento della registrazione di un'istanza di container Amazon ECS](deregister_container_instance.md).
+ Elimina il namespace . Per ulteriori informazioni, consulta [Eliminazione degli spazi dei nomi](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) nella *Guida per gli sviluppatori di AWS Cloud Map *.

**Procedura**

1. Apri la console nella [https://console.aws.amazon.com/ecs/versione 2](https://console.aws.amazon.com/ecs/v2).

1. Seleziona la Regione da utilizzare nella barra di navigazione.

1. Nel pannello di navigazione scegli **Cluster**.

1. Nella pagina **Cluster**, seleziona il cluster da eliminare.

1. In alto a destra della pagina, scegli **Elimina Cluster**. 

   Se non sono state eliminate tutte le risorse associata al cluster, viene visualizzato un messaggio.

1. Nella casella di conferma, inserisci **delete *cluster name***.

# Annullamento della registrazione di un'istanza di container Amazon ECS
<a name="deregister_container_instance"></a>

**Importante**  
Questo argomento riguarda solo le istanze del container create in Amazon EC2. Per ulteriori informazioni sull'annullamento delle registrazioni delle istanze gestite, consulta [Annullamento della registrazione di un'istanza esterna Amazon ECS](ecs-anywhere-deregistration.md).

Una volta terminato di utilizzare un'istanza di container supportata da Amazon EC2, puoi annullarne la registrazione dal cluster. In seguito all'annullamento della registrazione, l'istanza di container non è più in grado di accettare nuove attività.

Se hai attività in esecuzione nell'istanza di container al momento dell'annullamento della registrazione, queste attività continueranno a essere in esecuzione fino al termine dell'istanza o fino a quando le attività non verranno interrotte in altri modi. Tuttavia, questi processi sono orfani (non più monitorati o tenuti in considerazione da Amazon ECS). Se un processo orfano nell'istanza di container è parte di un servizio Amazon ECS, il pianificatore di servizi avvia un'altra copia di tale attività in un'altra istanza di container, se possibile. La registrazione di eventuali container in attività di servizio orfana registrati con un gruppo di destinazione di Application Load Balancer viene annullata. Ha inizio lo svuotamento della connessione in base alle impostazioni nel bilanciatore del carico o nel gruppo di destinazione. Se un processo orfano utilizza la modalità di rete `awsvpc`, le sue interfacce di rete elastiche vengono eliminate.

Se hai intenzione di utilizzare l'istanza di container per altri motivi in seguito all'annullamento della registrazione, devi interrompere tutte le attività in esecuzione nell'istanza di container prima dell'annullamento. Questa operazione interrompe il consumo di risorse da parte delle attività orfane.

Quando annulli la registrazione di un'istanza di container, tieni presente le considerazioni riportate di seguito.
+ Dato che ogni istanza di container presenta informazioni sullo stato univoche, non deve essere annullata da un cluster e registrata nuovamente in un altro. Per riposizionare le risorse dell'istanza di container, ti consigliamo di terminare le istanze di container da un cluster e avviare nuove istanze di container nel nuovo cluster. Per ulteriori informazioni, consulta [Interruzione di un'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) nella *Guida utente di Amazon EC2* e [Avvio di un'istanza di container Linux di Amazon ECS](launch_container_instance.md).
+ Se l'istanza del contenitore è gestita da un gruppo o da uno CloudFormation stack di Auto Scaling, interrompi l'istanza aggiornando il gruppo o lo stack Auto Scaling. CloudFormation In caso contrario, il gruppo Auto Scaling o CloudFormation creerà una nuova istanza dopo averla terminata.
+ Se termini un'istanza di container in esecuzione con un agente del container Amazon ECS connesso, l'agente annulla automaticamente la registrazione dell'istanza dal cluster. Non viene automaticamente annullata la registrazione delle istanze di container interrotte o delle istanze con agenti disconnessi al loro termine.
+ L'annullamento della registrazione di un'istanza di container rimuove l'istanza da un cluster, ma non termina l'istanza Amazon EC2. Al termine dell'utilizzo dell'istanza, assicurati di terminarla in modo da interrompere la fatturazione. Per ulteriori informazioni, consulta la sezione relativa alla [terminazione dell’istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) nella *Guida per l’utente di Amazon EC2*.

## Procedura
<a name="deregister_container_instance_procedure"></a>

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Dalla barra di navigazione, scegli la Regione in cui l'istanza esterna è registrata.

1. Nel pannello di navigazione, scegli **Clusters** (Cluster) e seleziona il cluster che ospita l'istanza.

1. Nella *name* pagina **Cluster:**, scegli la scheda **Infrastruttura**.

1. In **Container instances** (Istanze di container), seleziona l'ID dell'istanza per la quale annullare la registrazione. Si sarà reindirizzati alla pagina dei dettagli dell'istanza di container.

1. Nella *id* pagina **Container Instance:**, scegli **Annulla registrazione**.

1. Nella schermata di conferma, seleziona **Annulla registrazione**.

1. Se un'istanza di container non è più necessaria, termina l'istanza Amazon EC2 sottostante. Per ulteriori informazioni, consulta [Terminazione dell'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) nella *Guida per l'utente di Amazon EC2*.

# Drenare le istanze di container di Amazon ECS
<a name="container-instance-draining"></a>

In alcuni casi, potresti dover rimuovere un'istanza di container da un cluster; ad esempio, per eseguire aggiornamenti di sistema o ridurre verticalmente la capacità del cluster. Amazon ECS offre la possibilità di passare un'istanza di container a uno stato `DRAINING`. Questa operazione è nota come *svuotamento dell'istanza di container*. Quando un'istanza di container è impostata su `DRAINING`, Amazon ECS impedisce che venga pianificato il posizionamento di nuovi processi nell'istanza di container. 

## Comportamento di svuotamento per i servizi
<a name="draining-service-behavior"></a>

Qualsiasi processo che fa parte di un servizio che si trova in uno stato `PENDING` viene arrestato immediatamente. Se nel cluster è disponibile la capacità dell'istanza di container, il pianificatore di servizi avvierà i processi di sostituzione. Se la capacità dell'istanza di container non è sufficiente, verrà inviato un messaggio di evento del servizio che indica il problema.

I processi che fanno parte di un servizio nell'istanza di container che si trovano in uno stato `RUNNING` passano a uno stato `STOPPED`. Lo scheduler di servizi prova a sostituire le attività in base al tipo di implementazione e ai parametri di configurazione dell'implementazione del servizio, `minimumHealthyPercent` e `maximumPercent`. Per ulteriori informazioni, consultare [Servizi Amazon ECS](ecs_services.md) e [Parametri di definizione del servizio di Amazon ECS](service_definition_parameters.md).
+ Se `minimumHealthyPercent` è inferiore al 100%, il pianificatore può ignorare `desiredCount` temporaneamente durante la sostituzione delle attività. Ad esempio, `desiredCount` sono quattro attività, un minimo del 50% permette al pianificatore di interrompere due attività esistenti prima di avviare due nuove attività. Se il minimo è del 100%, il pianificatore del servizio non può rimuovere le attività esistenti fino a quando le attività di sostituzione non vengono considerate integre. Se le attività per i servizi che non utilizzano un bilanciatore del carico sono in stato `RUNNING`, vengono considerate integre. Le attività per i servizi che utilizzano un bilanciatore del carico vengono considerate integre se sono in stato `RUNNING` e se il bilanciatore del carico considera integra l'istanza di container su cui sono ospitate.
**Importante**  
Se utilizzi le istanze Spot e `minimumHealthyPercent` è maggiore o uguale al 100%, il servizio non avrà abbastanza tempo per sostituire l'attività prima della cessazione dell'istanza Spot.
+ Il parametro `maximumPercent` rappresenta un limite superiore al numero di attività in esecuzione durante la sostituzione delle attività. Ciò permette di definire le dimensioni del batch di sostituzione. Ad esempio, se `desiredCount` di quattro attività, un massimo di 200% avvia quattro nuove attività prima di interrompere le quattro attività affinché vengano esaurite (a condizione che le risorse del cluster necessarie per questa operazione siano disponibili). Se il massimo è 100%, le attività di sostituzione non possono avviarsi fino all'interruzione delle attività di esaurimento.
**Importante**  
Se `minimumHealthyPercent` e `maximumPercent` sono entrambi al 100%, il servizio non può rimuovere i processi esistenti e non può inoltre avviare processi di sostituzione. Ciò impedisce il corretto svuotamento delle istanze del container e impedisce la creazione di nuove implementazioni.

## Comportamento di svuotamento per processi autonomi
<a name="draining-standalone-behavior"></a>

Qualsiasi processo autonomo nello stato `PENDING` o `RUNNING` non ne è influenzato; devi attenderne l'interruzione o interromperlo manualmente. L'istanza di container rimarrà nello `DRAINING` stato.

## Comportamento di drenaggio per le istanze gestite da Amazon ECS
<a name="managed-instances-draining-behavior"></a>

La terminazione di Amazon ECS Managed Instances garantisce transizioni agevoli dei carichi di lavoro, ottimizzando al contempo i costi e mantenendo lo stato del sistema. Il sistema di terminazione offre tre percorsi decisionali distinti per la terminazione delle istanze, ciascuno con caratteristiche temporali e profili di impatto sul cliente diversi.

Terminazione avviata dal cliente  
Consente il controllo diretto sulla rimozione delle istanze quando bisogna rimuovere immediatamente le istanze di container dal servizio. Si esegue con il parametro di richiesta impostato su true`deregister-container-instance`. `force` Ciò significa che è necessaria la cessazione immediata nonostante i carichi di lavoro in esecuzione.

Terminazione dello stato di inattività avviata dal sistema  
Amazon ECS Managed Instances monitora continuamente e ottimizza in modo proattivo i costi chiudendo le istanze di container Amazon ECS inattive che non eseguono alcuna attività. ECS utilizza un ritardo euristico per dare alle istanze di container la possibilità di acquisire attività appena avviate prima di essere terminate. Questo può essere personalizzato con il parametro di configurazione del provider di capacità di `scaleInAfter` Amazon ECS Managed Instances.

Terminazione dell'aggiornamento dell'infrastruttura  
Amazon ECS Managed Instances gestisce e aggiorna automaticamente il software sulle istanze di container gestite per garantire sicurezza e conformità mantenendo al contempo la disponibilità del carico di lavoro. Per ulteriori informazioni, consulta la sezione Applicazione di [patch in Amazon ECS Managed Instances.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html)

Il sistema di terminazione implementa un approccio in due fasi che bilancia la continuità del carico di lavoro e i requisiti di gestione dell'infrastruttura.

**Fase 1: periodo di completamento graduale**  
Durante questa fase, il sistema implementa strategie di drenaggio graduale che danno priorità alla continuità del carico di lavoro. Le attività di assistenza vengono eseguite regolarmente tramite le normali attività di pianificazione di Amazon ECS. Le attività autonome continuano a funzionare perché potrebbero completarsi naturalmente. Il sistema controlla che tutte le attività raggiungano lo stato di arresto tramite attività di completamento naturali.

**Fase 2: applicazione di scadenze rigide**  
Quando il completamento graduale non consente di raggiungere gli obiettivi di terminazione entro tempi accettabili, il sistema applica una scadenza rigida. Solitamente, la scadenza rigida è fissata al momento dell'avvio del drenaggio più sette giorni, in modo da garantire un tempo sufficiente per il completamento dell'operazione nel rispetto dei requisiti operativi. L'applicazione prevede delle procedure automatiche di annullamento forzato della registrazione e l'immediata terminazione di tutte le attività rimanenti, indipendentemente dal loro stato di completamento.

Un'istanza di container ha completato lo svuotamento quando tutti i processi in esecuzione sull'istanza passano a uno stato `STOPPED`. L'istanza di container rimane nello stato `DRAINING` finché non viene nuovamente attivata o eliminata. Puoi verificare lo stato delle attività sull'istanza del contenitore utilizzando l'[ListTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ListTasks.html)operazione con il `containerInstance` parametro per ottenere un elenco di attività sull'istanza seguita da un'[DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html)operazione con l'Amazon Resource Name (ARN) o l'ID di ciascuna attività per verificare lo stato dell'attività.

Quando desideri che l'istanza di container avvi nuovamente i processi di hosting, puoi modificare lo stato dell'istanza di container da `DRAINING` a `ACTIVE`. Lo scheduler del servizio Amazon ECS considera nuovamente l'istanza di container per il posizionamento dell'attività.

## Procedura
<a name="drain-instances"></a>

Le seguenti fasi possono essere utilizzate per impostare lo svuotamento di un'istanza di container utilizzando la nuova Console di gestione AWS.

Puoi anche utilizzare l'azione [UpdateContainerInstancesState](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateContainerInstancesState.html)API o il [update-container-instances-state](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-container-instances-state.html)comando per modificare lo stato di un'istanza del contenitore in`DRAINING`.

**Console di gestione AWS**

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nel pannello di navigazione scegliere **Cluster**.

1. Alla pagina **Clusters** (Cluster), scegli un cluster che ospita le istanze.

1. Nella *name* pagina **Cluster:**, scegli la scheda **Infrastruttura**. Quindi, in **Container instances** (Istanze di container) e seleziona la casella di controllo per ciascuna istanza di container che desideri svuotare.

1. Scegli **Operazioni**, **Drain**.

# Modifica del tipo o della dimensione dell'istanza all'esterno del gruppo Auto Scaling
<a name="container-instance-change-type"></a>

AWS consiglia di mantenere l'infrastruttura immutabile. Se devi modificare le dimensioni delle istanze, puoi: 
+ Scalate orizzontalmente e aggiungete altre istanze. Quindi, posiziona attività aggiuntive su quelle istanze o su 
+ Scalate verticalmente lanciando una nuova larger/smaller istanza, quindi svuotate quella precedente. 

Entrambi questi approcci contribuiranno a ridurre al minimo l'impatto sulla disponibilità delle applicazioni.

Se hai utilizzato un altro metodo per modificare l'istanza, potresti ricevere il seguente errore: 

```
Container instance type changes are not supported.
```

Quando ricevi questo errore, esegui le seguenti operazioni:

1. Avvia nuove istanze con il tipo di istanza desiderato.

1. Svuota i tuoi vecchi tipi di istanza. Per ulteriori informazioni, consulta [Drenare le istanze di container di Amazon ECS](container-instance-draining.md).

# Istanze di container di Amazon ECS EC2
<a name="ecs-agent-versions"></a>

L'agente Amazon ECS è un processo che viene eseguito su tutte le istanze di container registrate nel cluster. Facilita la comunicazione tra le istanze di container e Amazon ECS.

**Nota**  
Nelle istanze di container Linux, il container dell'agente monta directory di primo livello come `/lib`, `/lib64` e `/proc`. Questo è necessario per caratteristiche e funzionalità ECS come i volumi Amazon EBS, la modalità di rete `awsvpc`, Amazon ECS Service Connect e FireLens per Amazon ECS.

Ogni versione dell'agente del container di Amazon ECS supporta una serie di funzioni differenti e assicura le correzioni dei bug delle versioni precedenti. Quando possibile, consigliamo sempre di utilizzare la versione più recente dell'agente del container di Amazon ECS. Per passare all'ultima versione dell'agente del container, consulta [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).

L'agente container Amazon ECS contiene l'immagine `amazon-ecs-pause`. Amazon ECS usa questa immagine per attività che sfruttano la modalità di rete di `awsvpc`.

[Per vedere quali funzionalità e miglioramenti sono inclusi in ogni versione dell'agente, consulta https://github.com/aws/ amazon-ecs-agent /releases.](https://github.com/aws/amazon-ecs-agent/releases)

**Importante**  
La versione Docker minima per parametri affidabili è `v20.10.13` e successive, inclusa nell'AMI `20220607` ottimizzata per Amazon ECS e versioni successive.  
Le versioni dell'agente Amazon ECS `1.20.0` e successive non supportano più le versioni di Docker precedenti alla `18.01.0`.

## Ciclo di vita
<a name="container-lifecycle"></a>

Quando l'agente del container di Amazon ECS registra un'istanza Amazon EC2 nel cluster, l'istanza Amazon EC2 segnala il suo stato come `ACTIVE` e lo stato di connessione dell'agente come `TRUE`. Questa istanza di container può accettare richieste di esecuzione di attività.

Se interrompi un'istanza di container (senza terminarla), lo stato rimane `ACTIVE`, ma lo stato di connessione dell'agente passa a `FALSE` entro pochi minuti. Tutte le attività in esecuzione nell'istanza di container vengono interrotte. Se avvii di nuovo l'istanza di container, l'agente del container si riconnetterà al servizio Amazon ECS e potrai nuovamente eseguire attività nell'istanza.

Se modifichi lo stato di un'istanza di container in `DRAINING`, le nuove attività non vengono posizionate nell'istanza di container. Qualsiasi attività di servizio in esecuzione nell'istanza di container viene rimossa, se possibile, in modo che possano essere eseguiti gli aggiornamenti di sistema. Per ulteriori informazioni, consulta [Drenare le istanze di container di Amazon ECS](container-instance-draining.md).

Se annulli la registrazione di un'istanza di container o la termini, lo stato dell'istanza di container passa immediatamente a `INACTIVE` e l'istanza di container non viene più segnalata quando elenchi le istanze di container. Tuttavia, puoi ancora descrivere l'istanza di container per un'ora in seguito alla terminazione. Dopo un'ora, la descrizione dell'istanza non è più disponibile.

Puoi svuotare manualmente le istanze o creare un hook del ciclo di vita del gruppo Auto Scaling per impostare lo stato dell'istanza su `DRAINING`. Per ulteriori informazioni, consulta [Hook del ciclo di vita di Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html).

## Supporto Docker
<a name="docker-support"></a>

Amazon ECS supporta le ultime due principali versioni di Docker pubblicate su Amazon Linux. Attualmente, sono Docker 20.10.x e Docker 25.x.

La versione Docker minima richiesta per Amazon ECS è disponibile nel file delle [specifiche di Amazon ECS Agent](https://github.com/aws/amazon-ecs-agent/blob/dev/packaging/amazon-linux-ami-integrated/ecs-agent.spec#L53) su. GitHub

Quando si usa l'AMI ottimizzata per Amazon ECS, Docker è preinstallato e configurato per funzionare con l'agente container Amazon ECS. L'AMI comprende una versione Docker che è stata testata ed è supportata da Amazon ECS.

**Nota**  
Sebbene Amazon ECS supporti più versioni di Docker, suggeriamo di usare la versione di Docker fornita con l'AMI ottimizzata per Amazon ECS per ottenere la massima compatibilità e il miglior supporto.

## AMI ottimizzate per Amazon ECS
<a name="ecs-optimized-ami"></a>

Per ulteriori informazioni sull'AMI ottimizzata per Amazon ECS, consulta Linux ottimizzato per [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html). AMIs

## Informazioni aggiuntive
<a name="additional-information"></a>

Nelle pagine seguenti vengono fornite ulteriori informazioni sulle modifiche:
+ Registro delle [modifiche di Amazon ECS Agent attivo](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md) GitHub
+ [Note di rilascio di Amazon Linux 2](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html).
+ [Note di rilascio di Docker Engine](https://docs.docker.com/engine/release-notes/27/) nella documentazione Docker
+ [Documentazione dei driver NVIDIA](https://docs.nvidia.com/datacenter/tesla/index.html) nella documentazione NVIDIA

# Configurazione dell'agente del container Amazon ECS
<a name="ecs-agent-config"></a>

**Si applica a**: istanze EC2

L'agente del container di Amazon ECS supporta una serie di opzioni di configurazione, la maggior parte delle quali viene impostata tramite variabili di ambiente. 

Se l'istanza di container è stata avviata con una variante Linux dell'AMI ottimizzata per Amazon ECS, puoi impostare queste variabili di ambiente nel file `/etc/ecs/ecs.config` e quindi riavviare l'agente. Puoi scrivere queste variabili di configurazione anche nelle istanze di container con i dati utente di Amazon EC2 al momento dell'avvio. Per ulteriori informazioni, consulta [Bootstrap di istanze di container Linux Amazon ECS per il trasferimento dei dati](bootstrap_container_instance.md).

Se l'istanza del contenitore è stata avviata con una variante Windows dell'AMI ottimizzata per Amazon ECS, puoi impostare queste variabili di ambiente con il PowerShell SetEnvironmentVariable comando e quindi riavviare l'agente. Per ulteriori informazioni, consulta [Esecuzione di comandi durante l'avvio di un'istanza EC2 con l'input di dati dell'utente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) nella *Guida per l'utente di Amazon EC2* e [Bootstrap di istanze di container Windows Amazon ECS per il trasferimento dei dati](bootstrap_windows_container_instance.md).

Se avvii manualmente l'agente container Amazon ECS (per dispositivi non ottimizzati per Amazon ECS AMIs), puoi utilizzare queste variabili di ambiente nel **docker run** comando che usi per avviare l'agente. Utilizza queste variabili con la sintassi `--env=VARIABLE_NAME=VARIABLE_VALUE`. Nel caso di informazioni sensibili, come ad esempio le credenziali di autenticazione a repository privati, le variabili di ambiente dell'agente vanno archiviate in un file e trasmesse tutte in una volta con l'opzione `--env-file path_to_env_file`. Per aggiungere le variabili, puoi utilizzare i seguenti comandi.

```
sudo systemctl stop ecs
sudo vi /etc/ecs/ecs.config 
# And add the environment variables with VARIABLE_NAME=VARIABLE_VALUE format.
sudo systemctl start ecs
```

## Esegui l'agente Amazon ECS con il namespace PID host
<a name="ecs-agent-pid-namespace"></a>

Per impostazione predefinita, l'agente Amazon ECS viene eseguito con il proprio namespace PID. Nelle seguenti configurazioni, puoi configurare l'agente Amazon ECS per l'esecuzione con il namespace PID host:
+ SELinux la modalità di applicazione è abilitata.
+ La politica di SELinux sicurezza di Docker è impostata su true.

Puoi configurare questo comportamento impostando la variabile di ambiente `ECS_AGENT_PID_NAMESPACE_HOST` su `true` nel tuo file `/etc/ecs/ecs.config`. Quando questa variabile è abilitata, `ecs-init` avvia il contenitore dell'agente Amazon ECS con lo spazio dei nomi PID dell'host (`--pid=host`), permettendo all'agente di avviarsi correttamente negli ambienti -enforcing. SELinux Questa caratteristica è disponibile nelle versioni `1.94.0` e successive dell'agente Amazon ECS.

Per abilitare questa funzionalità, aggiungi la seguente riga al file `/etc/ecs/ecs.config`:

```
ECS_AGENT_PID_NAMESPACE_HOST=true
```

Dopo aver apportato la modifica, riavvia l'agente Amazon ECS per renderla effettiva:

```
sudo systemctl restart ecs
```

Le seguenti funzionalità non funzioneranno: la modalità di SELinux imposizione è abilitata e la policy di sicurezza Docker è impostata su true, anche quando è impostata. `ECS_AGENT_PID_NAMESPACE_HOST=true`
+ Amazon ECS Exec
+ allega attività Amazon EBS
+ Service Connect
+ FireLens per Amazon ECS

## Parametri disponibili
<a name="ecs-agent-availparam"></a>

Per informazioni sui parametri di configurazione dell'agente container Amazon ECS disponibili, consulta [Amazon ECS Container Agent on.](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) GitHub

# Archiviazione della configurazione di un'istanza di container Amazon ECS in Amazon S3
<a name="ecs-config-s3"></a>

La configurazione dell'agente del container Amazon ECS viene controllata con la variabile di ambiente. Le varianti Linux dell'AMI ottimizzata per Amazon ECS cercano queste variabili in `/etc/ecs/ecs.config` all'avvio dell'agente del container e lo configurano di conseguenza. Le variabili di ambiente non sensibili, come ad esempio `ECS_CLUSTER`, possono essere trasmesse all'istanza di container all'avvio tramite i dati utente di Amazon EC2 ed essere scritte su questo file senza conseguenze. Tuttavia, altre informazioni sensibili, come le AWS credenziali o la `ECS_ENGINE_AUTH_DATA` variabile, non devono mai essere passate a un'istanza nei dati utente o scritte `/etc/ecs/ecs.config` in un modo che consenta loro di essere visualizzate in un file. `.bash_history`

Archiviare le informazioni di configurazione in un bucket privato in Amazon S3 e concedere l'accesso in sola lettura al ruolo IAM dell'istanza di container è un modo sicuro e conveniente per permettere la configurazione delle istanze di container all'avvio. È possibile memorizzare una copia del file `ecs.config` in un bucket privato. Puoi quindi utilizzare i dati utente di Amazon EC2 per installare AWS CLI e copiare le informazioni di configurazione all'`/etc/ecs/ecs.config`avvio dell'istanza.

**Come memorizzare un file `ecs.config` in Amazon S3**

1. È necessario concedere all'istanza del contenitore le autorizzazioni role (**ecsInstanceRole**) per avere accesso in sola lettura ad Amazon S3. Puoi farlo assegnando **AmazonS3 al ruolo ReadOnlyAccess**. `ecsInstanceRole` Per informazioni su come associare una policy a un ruolo, consulta [Aggiornare le autorizzazioni per un ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) nella *Guida per l'utente di AWS Identity and Access Management *

1. Crea un file `ecs.config` con variabili di configurazione dell'agente Amazon ECS valide utilizzando il seguente formato. In questo esempio viene configurata l'autenticazione di un registro privato. Per ulteriori informazioni, consulta [Utilizzo di immagini non AWS containerizzate in Amazon ECS](private-auth.md).

   ```
   ECS_ENGINE_AUTH_TYPE=dockercfg
   ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
   ```
**Nota**  
Per un elenco completo delle variabili di configurazione dell'agente Amazon ECS disponibili, consulta [Amazon ECS Container Agent on.](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) GitHub

1. Per archiviare il file di configurazione, crea un bucket privato in Amazon S3. Per ulteriori informazioni, consulta [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) nella *Guida per l'utente di Amazon Simple Storage Service*. 

1. Carica il file `ecs.config` nel bucket S3. Per ulteriori informazioni, consulta [Caricamento degli oggetti](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) nella *Guida per l'utente di Amazon Simple Storage Service*.

**Come caricare un file `ecs.config` da Amazon S3 all'avvio**

1. Procedi come indicato in questa sezione per consentire l'accesso Amazon S3 in sola lettura alle istanze di container e archiviare un file `ecs.config` in un bucket privato S3.

1. Avvia nuove istanze di container e utilizza il seguente script di esempio nei dati utente EC2. Lo script installa AWS CLI e copia il file di configurazione in. `/etc/ecs/ecs.config` Per ulteriori informazioni, consulta [Avvio di un'istanza di container Linux di Amazon ECS](launch_container_instance.md).

   ```
   #!/bin/bash
   yum install -y aws-cli
   aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
   ```

# Installazione dell'agente del container Amazon ECS
<a name="ecs-agent-install"></a>

Se vuoi registrare un'istanza Amazon EC2 con il tuo cluster Amazon ECS e tale istanza non usa un'AMI basata sull'AMI ottimizzata per Amazon ECS, puoi installare manualmente l'agente container Amazon ECS seguendo la seguente procedura. Per farlo, puoi scaricare l'agente da uno dei bucket Amazon S3 regionali o da Amazon Elastic Container Registry Public. Se esegui il download da uno dei bucket Amazon S3 regionali, puoi eventualmente verificare la validità del file dell'agente del container utilizzando la firma PGP.

**Nota**  
Le unità `systemd` per i servizi Amazon ECS e Docker hanno l'istruzione di attendere il completamento di `cloud-init` prima di avviare entrambi i servizi. Il processo `cloud-init` non viene considerato terminato fino a quando i dati utente di Amazon EC2 non hanno terminato l'esecuzione. Pertanto, l'avvio di Amazon ECS o Docker tramite i dati utente di Amazon EC2 può causare un deadlock. Per avviare l'agente del container utilizzando i dati utente di Amazon EC2 puoi utilizzare `systemctl enable --now --no-block ecs.service`.

## Installazione dell'agente del container Amazon ECS in un'istanza EC2 non Amazon Linux
<a name="ecs-agent-install-nonamazonlinux"></a>

Per installare l'agente del container Amazon ECS su un'istanza Amazon EC2 non , puoi scaricare l'agente da uno dei bucket Amazon S3 regionali e installarlo.

**Nota**  
Quando utilizzi un'AMI non Amazon Linux, l'istanza Amazon EC2 richiede il supporto `cgroupfs` per il driver `cgroup` in modo che l'agente Amazon ECS supporti i limiti delle risorse a livello di attività. Per ulteriori informazioni, consulta [Amazon ECS agent on GitHub](https://github.com/aws/amazon-ecs-agent).

A titolo di riferimento, di seguito sono elencati i file più recenti dell'agente del container Amazon ECS, per regione e per ciascun tipo di architettura di sistema.


| Region | Nome della Regione | File di init deb di Amazon ECS | File di init rbm di Amazon ECS | 
| --- | --- | --- | --- | 
| us-east-2 | Stati Uniti orientali (Ohio) |  [Amazon ECS init amd64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-east-1 | Stati Uniti orientali (Virginia settentrionale) |  [Amazon ECS init amd64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-west-1 | Stati Uniti occidentali (California settentrionale) |  [Amazon ECS init amd64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-west-2 | Stati Uniti occidentali (Oregon) |  [Amazon ECS init amd64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-east-1 | Asia Pacifico (Hong Kong) |  [Amazon ECS init amd64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-northeast-1 | Asia Pacifico (Tokyo) |  [Amazon ECS init amd64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-northeast-2 | Asia Pacifico (Seul) |  [Amazon ECS init amd64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-south-1 | Asia Pacifico (Mumbai) |  [Amazon ECS init amd64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-southeast-1 | Asia Pacifico (Singapore) |  [Amazon ECS init amd64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-southeast-2 | Asia Pacifico (Sydney) |  [Amazon ECS init amd64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ca-central-1 | Canada (Centrale) |  [Amazon ECS init amd64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-central-1 | Europa (Francoforte) |  [Amazon ECS init amd64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-west-1 | Europa (Irlanda) |  [Amazon ECS init amd64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-west-2 | Europa (Londra) |  [Amazon ECS init amd64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-west-3 | Europa (Parigi) |  [Amazon ECS init amd64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| sa-east-1 | Sud America (San Paolo) |  [Amazon ECS init amd64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.x86_64.rpm) [Amazon ECS init aarch64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-gov-east-1 | AWS GovCloud (Stati Uniti orientali) |  [Amazon ECS init amd64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-gov-west-1 | AWS GovCloud (Stati Uniti occidentali) |  [Amazon ECS init amd64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 

**Per installare l'agente del container Amazon ECS su un'istanza Amazon EC2 utilizzando un'AMI non Amazon Linux**

1. Avvia un'istanza Amazon EC2 con un ruolo IAM che consenta l'accesso ad Amazon ECS. Per ulteriori informazioni, consulta [Ruolo IAM delle istanze di container Amazon ECS](instance_IAM_role.md).

1. Connettiti alla tua istanza.

1. Installare la versione più recente di Docker nell'istanza.

1. Controlla la versione Docker per verificare che il tuo sistema soddisfi il requisito di versione minima. Per ulteriori informazioni sul supporto di Docker, consulta [Istanze di container di Amazon ECS EC2](ecs-agent-versions.md).

   ```
   docker --version
   ```

1. Scarica il file di agente Amazon ECS appropriato per il sistema operativo e per l'architettura di sistema in uso e installalo.

   Per le architetture `deb`:

   ```
   ubuntu:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb
   ubuntu:~$ sudo dpkg -i amazon-ecs-init-latest.amd64.deb
   ```

   Per le architetture `rpm`:

   ```
   fedora:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm
   fedora:~$ sudo yum localinstall -y amazon-ecs-init-latest.x86_64.rpm
   ```

1. Modifica il file `/lib/systemd/system/ecs.service` e aggiungi la seguente riga alla fine della sezione `[Unit]`.

   ```
   After=cloud-final.service
   ```

1. (Facoltativo) Per registrare l'istanza con un cluster diverso dal cluster `default`, modifica il file `/etc/ecs/ecs.config` e aggiungi i contenuti seguenti. L'esempio seguente specifica il cluster `MyCluster`.

   ```
   ECS_CLUSTER=MyCluster
   ```

   Per ulteriori informazioni su queste e altre opzioni di runtime dell'agente, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md). 
**Nota**  
Puoi facoltativamente archiviare le variabili di ambiente dell'agente in Amazon S3 (che possono essere scaricate nelle tue istanze di container all'avvio utilizzando i dati utente di Amazon EC2). Ciò è consigliato per le informazioni sensibili, come le credenziali di autenticazione per i repository privati. Per ulteriori informazioni, consultare [Archiviazione della configurazione di un'istanza di container Amazon ECS in Amazon S3](ecs-config-s3.md) e [Utilizzo di immagini non AWS containerizzate in Amazon ECS](private-auth.md).

1. Avviare il servizio `ecs`.

   ```
   ubuntu:~$ sudo systemctl start ecs
   ```

## Esecuzione dell'agente Amazon ECS con modalità di rete host
<a name="container_agent_host"></a>

Quando si esegue l'agente del container di Amazon ECS, `ecs-init` crea il relativo container dell'agente del container con la modalità di rete `host`. Questa è l'unica modalità di rete supportata per il container dell'agente del container. 

Ciò permette di bloccare l'accesso all'[endpoint del servizio per i metadati dell'istanza Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) (`http://169.254.169.254`) per i container avviati dall'agente di container. Questo garantisce che i container non possano accedere alle credenziali del ruolo IAM dal profilo dell'istanza di container e che le attività utilizzino solo le credenziali per il ruolo del processo IAM. Per ulteriori informazioni, consulta [Ruolo IAM dell'attività Amazon ECS](task-iam-roles.md).

Assicura inoltre che l'agente del container non debba contendersi le connessioni e il traffico di rete sul bridge `docker0`.

## Parametri di configurazione del log dell'agente container Amazon ECS
<a name="agent-logs"></a>

L'agente del container di Amazon ECS archivia i log nelle istanze del container.

Per l'agente del container versione 1.36.0 e successive, di default i log si trovano in `/var/log/ecs/ecs-agent.log` sulle istanze Linux e in `C:\ProgramData\Amazon\ECS\log\ecs-agent.log` sulle istanze Windows.

Per l'agente del container versione 1.35.0 e precedenti, di default i log si trovano in `/var/log/ecs/ecs-agent.log.timestamp` sulle istanze Linux e `C:\ProgramData\Amazon\ECS\log\ecs-agent.log.timestamp` sulle istanze Windows.

Di default, i log dell'agente vengono ruotati ogni ora per un massimo di 24 log archiviati.

Di seguito sono riportate le variabili di configurazione dell'agente del container che possono essere utilizzate per modificare il comportamento di registrazione dell'agente predefinito. Per informazioni dettagliate su tutti i parametri di configurazione disponibili, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md) o il file [README di Amazon ECS Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) su. GitHub

Per l'agente del container versione 1.36.0 e successive, il seguente è un file di log di esempio quando viene utilizzato il formato `logfmt`.

```
level=info time=2019-12-12T23:43:29Z msg="Loading configuration" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-agent:latest" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-pause:0.1.0" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Amazon ECS agent Version: 1.36.0, Commit: ca640387" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Creating root ecs cgroup: /ecs" module=init_linux.go
level=info time=2019-12-12T23:43:29Z msg="Creating cgroup /ecs" module=cgroup_controller_linux.go
level=info time=2019-12-12T23:43:29Z msg="Loading state!" module=statemanager.go
level=info time=2019-12-12T23:43:29Z msg="Event stream ContainerChange start listening..." module=eventstream.go
level=info time=2019-12-12T23:43:29Z msg="Restored cluster 'auto-robc'" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Restored from checkpoint file. I am running as 'arn:aws:ecs:us-west-2:0123456789:container-instance/auto-robc/3330a8a91d15464ea30662d5840164cd' in cluster 'auto-robc'" module=agent.go
```

Di seguito è riportato un file di log di esempio quando viene utilizzato il formato JSON.

```
{"time": "2019-11-07T22:52:02Z", "level": "info", "msg": "Starting Amazon Elastic Container Service Agent", "module": "engine.go"}
```

# Configurare istanze di container Amazon ECS per immagini Docker private
<a name="private-auth-container-instances"></a>

L'agente di container di Amazon ECS è in grado di eseguire l'autenticazione con registri privati utilizzando l'autenticazione di base. Quando si abilita l'autenticazione dei registri privati, puoi utilizzare le immagini Docker private nelle tue definizioni di attività. Questa funzionalità è supportata solo dalle attività che utilizzano EC2.

Un altro metodo per abilitare l'autenticazione del registro privato consiste nell' Gestione dei segreti AWS archiviare le credenziali del registro privato in modo sicuro e quindi farvi riferimento nella definizione del contenitore. In questo modo le attività possono utilizzare immagini da repository privati. Questo metodo supporta le attività utilizzando EC2 o Fargate. Per ulteriori informazioni, consulta [Utilizzo di immagini non AWS containerizzate in Amazon ECS](private-auth.md).

L'agente del container di Amazon ECS all'avvio ricerca due variabili di ambiente:
+ `ECS_ENGINE_AUTH_TYPE`, che specifica il tipo di dati di autenticazione inviati.
+ `ECS_ENGINE_AUTH_DATA`, che contiene le credenziali di autenticazione effettive.

Le varianti Linux dell'AMI ottimizzata per Amazon ECS analizzano il `/etc/ecs/ecs.config` file alla ricerca di queste variabili all'avvio dell'istanza del contenitore e ogni volta che il servizio viene avviato (con il **sudo start ecs** comando). AMIs che non sono ottimizzate per Amazon ECS devono archiviare queste variabili di ambiente in un file e passarle con l'`--env-file path_to_env_file`opzione al **docker run** comando che avvia l'agente contenitore.

**Importante**  
Consigliamo di non inserire queste variabili di ambiente di autenticazione al momento dell'avvio dell'istanza con i dati utente di Amazon EC2 o di trasferirle con l'opzione `--env` al comando **docker run**. Questi metodi non sono ideali per i dati sensibili, come le credenziali di autenticazione. Per informazioni sull'aggiunta sicura delle credenziali di autenticazione alle istanze di container, consulta [Archiviazione della configurazione di un'istanza di container Amazon ECS in Amazon S3](ecs-config-s3.md).

## Formati di autenticazione
<a name="docker-auth-formats"></a>

Sono disponibili due formati per l'autenticazione di registri privati, `dockercfg` e `docker`.

**Formato di autenticazione dockercfg**  
Il formato `dockercfg` utilizza le informazioni di autenticazione archiviate nel file di configurazione che viene creato quando esegui il comando **docker login**. Puoi creare questo file eseguendo il comando **docker login** sul sistema locale e inserendo il nome utente, la password e l'indirizzo e-mail del registro. Puoi inoltre effettuare l'accesso a un'istanza di container ed eseguire il comando qui. A seconda della tua versione Docker, questo file viene salvato come `~/.dockercfg` o `~/.docker/config.json`.

```
cat ~/.docker/config.json
```

Output:

```
{
  "auths": {
    "https://index.docker.io/v1/": {
      "auth": "zq212MzEXAMPLE7o6T25Dk0i"
    }
  }
}
```

**Importante**  
Le nuove versioni di Docker creano un file di configurazione come mostrato in precedenza con un oggetto `auths` esterno. L'agente Amazon ECS supporta solo i dati di autenticazione `dockercfg` nel formato seguente senza l'oggetto `auths`. Se è installata l'utility **jq**, puoi estrarre questi dati con il seguente comando: **cat \$1/.docker/config.json \$1 jq .auths**

```
cat ~/.docker/config.json | jq .auths
```

Output:

```
{
  "https://index.docker.io/v1/": {
    "auth": "zq212MzEXAMPLE7o6T25Dk0i",
    "email": "email@example.com"
  }
}
```

Nell'esempio precedente, è necessario aggiungere le seguenti variabili di ambiente al file delle variabili di ambiente (`/etc/ecs/ecs.config` per l'AMI ottimizzata per Amazon ECS) che l'agente del container di Amazon ECS carica in fase di runtime. Se non stai utilizzando l'AMI ottimizzata per Amazon ECS e stai avviando l'agente manualmente con **docker run**, specifica il file delle variabili d'ambiente con l'opzione `--env-file path_to_env_file` all'avvio dell'agente.

```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
```

Puoi configurare più registri privati con la seguente sintassi:

```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example-01.com"},"repo.example-02.com":{"auth":"fQ172MzEXAMPLEoF7225DU0j","email":"email@example-02.com"}}
```

**Formato di autenticazione docker**  
Il formato `docker` utilizza una rappresentazione JSON del server di registro con il quale l'agente deve eseguire l'autenticazione. Include anche i parametri di autenticazione richiesti da tale registro (ad esempio il nome utente, la password e l'indirizzo e-mail per l'account). Per un account Docker Hub, la rappresentazione JSON sarà simile a quanto segue:

```
{
  "https://index.docker.io/v1/": {
    "username": "my_name",
    "password": "my_password",
    "email": "email@example.com"
  }
}
```

In questo esempio, è necessario aggiungere le seguenti variabili di ambiente al file delle variabili di ambiente (`/etc/ecs/ecs.config` per l'AMI ottimizzata per Amazon ECS) che l'agente del container di Amazon ECS carica in fase di runtime. Se non stai utilizzando l'AMI ottimizzata per Amazon ECS e stai avviando l'agente manualmente con il comando **docker run**, quando avvii l'agente specifica il file delle variabili d'ambiente con l'opzione `--env-file path_to_env_file`.

```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
```

Puoi configurare più registri privati con la seguente sintassi:

```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"username":"my_name","password":"my_password","email":"email@example-01.com"},"repo.example-02.com":{"username":"another_name","password":"another_password","email":"email@example-02.com"}}
```

## Procedura
<a name="enabling-private-registry"></a>

Utilizza la procedura seguente per attivare i registri privati per le istanze di container.

**Come abilitare i registri privati nell'AMI ottimizzata per Amazon ECS**

1. Accedi alla tua istanza di container con SSH.

1. Apri il file `/etc/ecs/ecs.config` e aggiungi i valori `ECS_ENGINE_AUTH_TYPE` ed `ECS_ENGINE_AUTH_DATA` per il registro e l'account:

   ```
   sudo vi /etc/ecs/ecs.config
   ```

   In questo esempio si esegue l'autenticazione di un account utente Docker Hub:

   ```
   ECS_ENGINE_AUTH_TYPE=docker
   ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
   ```

1. Controlla se il tuo agente utilizza la variabile di ambiente `ECS_DATADIR` per salvarne lo stato:

   ```
   docker inspect ecs-agent | grep ECS_DATADIR
   ```

   Output:

   ```
   "ECS_DATADIR=/data",
   ```
**Importante**  
Se il comando precedente non restituisce la variabile di ambiente `ECS_DATADIR`, è necessario arrestare qualsiasi attività in esecuzione in questa istanza di container prima di arrestare l'agente. Gli agenti più nuovi con la variabile di ambiente `ECS_DATADIR` salvano il proprio stato e puoi arrestarli e avviarli mentre le attività vengono eseguite senza problemi. Per ulteriori informazioni, consulta [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).

1. Arresta il servizio `ecs`:

   ```
   sudo stop ecs
   ```

   Output:

   ```
   ecs stop/waiting
   ```

1. Riavvia il servizio `ecs`.
   + Per l'AMI Amazon Linux 2 ottimizzata per Amazon ECS:

     ```
     sudo systemctl restart ecs
     ```
   + Per l'AMI Amazon Linux ottimizzata per Amazon ECS:

     ```
     sudo stop ecs && sudo start ecs
     ```

1. (Facoltativo) Puoi verificare se l'agente è in esecuzione e visualizzare alcune informazioni sulla nuova istanza di container interrogando l'operazione API di introspezione dell'agente. Per ulteriori informazioni, consulta [Introspezione del container di Amazon ECS](ecs-agent-introspection.md).

   ```
   curl http://localhost:51678/v1/metadata
   ```

# Pulizia automatica dell'immagine e dell'attività Amazon ECS
<a name="automated_image_cleanup"></a>

Ogni volta che si colloca un processo in un'istanza di container, l'agente del container di Amazon ECS verifica se le immagini a cui si fa riferimento nell'attività sono le più recenti del tag specificato nel repository. In caso contrario, il comportamento di default consente all'agente di estrarre le immagini dai rispettivi repository. Se aggiorni di frequente le immagini nelle tue attività e nei servizi, il tuo storage dell'istanza di container si può riempire rapidamente con le immagini Docker che non stai più utilizzando e probabilmente non riutilizzerai mai più. Ad esempio, puoi usare una pipeline per l'integrazione e l'implementazione continue (CI/CD).

**Nota**  
Il comportamento pull dell'immagine dell'agente Amazon ECS può essere personalizzato utilizzando il parametro `ECS_IMAGE_PULL_BEHAVIOR`. Per ulteriori informazioni, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md).

Analogamente, i container che appartengono ad attività arrestate possono anche consumare lo storage dell'istanza di container con informazioni di log, volumi di dati e altri elementi. Questi elementi sono utili per il debug dei container che si sono arrestati inaspettatamente, ma la maggior parte di questo storage può essere liberata in sicurezza dopo un periodo di tempo. 

Di default, l'agente del container di Amazon ECS elimina automaticamente le attività interrotte e le immagini Docker che non vengono utilizzate da nessun processo nelle tue istanze di container.

**Nota**  
La funzione di pulizia automatizzata delle immagini richiede almeno la versione 1.13.0 dell'agente del container di Amazon ECS. Per aggiornare il tuo agente all'ultima versione, consulta [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).

Le seguenti variabili di configurazione dell'agente sono disponibili per regolare la tua esperienza di attività automatica e pulizia delle immagini. Per ulteriori informazioni su come impostare queste variabili sulle tue istanze di container, consulta [Configurazione dell'agente del container Amazon ECS](ecs-agent-config.md).

`ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`  
Il tempo di attesa predefinito per eliminare i container per un'attività interrotta. Se il valore è inferiore a 1 secondo, il valore impostato verrà ignorato. Per impostazione predefinita, questo parametro è impostato su 3 ore, ma puoi ridurre questo periodo fino a 1 secondo, se necessario per la tua applicazione.  
Il processo di pulizia delle immagini non può eliminare un'immagine finché c'è un container che fa riferimento alla stessa. Dopo la rimozione dei container, tutte le immagini senza riferimenti diventano candidate alla pulizia in base ai parametri di configurazione della pulizia delle immagini.

`ECS_DISABLE_IMAGE_CLEANUP`  
Se imposti questa variabile su `true`, la pulizia automatizzata delle immagini viene disattivata sull'istanza di container e nessuna immagine viene rimossa automaticamente.

`ECS_IMAGE_CLEANUP_INTERVAL`  
Questa variabile specifica la frequenza con cui il processo di pulizia automatizzata delle immagini deve verificare la presenza di immagini da eliminare. L'impostazione predefinita è ogni 30 minuti, ma puoi ridurre questo periodo a solo 10 minuti per rimuovere le immagini con maggiore frequenza.

`ECS_IMAGE_MINIMUM_CLEANUP_AGE`  
Questa variabile specifica la quantità di tempo minima tra l'estrazione di un'immagine e il momento in cui diventa una candidata per la rimozione. Viene utilizzata per evitare la pulizia di immagini appena estratte. Il valore predefinito è 1 ora.

`ECS_NUM_IMAGES_DELETE_PER_CYCLE`  
Questa variabile specifica il numero di immagini rimovibili durante un singolo ciclo di pulizia. Il valore predefinito è 5 e il valore minimo è 1.

Quando l'agente del container di Amazon ECS è in esecuzione e la pulizia automatizzata delle immagini non è disattivata, l'agente verifica le immagini Docker alle quali nessun container in esecuzione o arrestato fa riferimento a una frequenza determinata dalla variabile `ECS_IMAGE_CLEANUP_INTERVAL`. Se vengono rilevate immagini inutilizzate meno recenti del tempo di pulizia minimo specificato dalla variabile `ECS_IMAGE_MINIMUM_CLEANUP_AGE`, l'agente rimuove fino al numero massimo di immagini specificato con la variabile `ECS_NUM_IMAGES_DELETE_PER_CYCLE`. Le immagini a cui si fa riferimento meno di recente vengono eliminate per prime. Dopo aver rimosso le immagini, l'agente attende fino all'intervallo successivo e ripete il processo.