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à. # Progettazione per AWS Fargate per Amazon ECS AWS Fargate è una tecnologia che puoi utilizzare con Amazon ECS per eseguire [container](https://aws.amazon.com/containers/) senza dover gestire server o cluster di istanze Amazon EC2. Con AWS Fargate, non è più necessario effettuare il provisioning, configurare o dimensionare i cluster di macchine virtuali per eseguire i container. Viene anche eliminata la necessità di scegliere i tipi di server, di decidere quando dimensionare i cluster o ottimizzarne il packing. Quando esegui le attività e i servizi con Fargate, crei un pacchetto dell'applicazione in container, specifichi i requisiti di CPU e di memoria, definisci le reti e le policy IAM e avvii l'applicazione. Ogni attività Fargate ha un proprio limite di isolamento e non condivide il kernel sottostante, le risorse CPU, le risorse di memoria o l'interfaccia di rete elastica con un'altra attività. Configura le definizioni delle attività per Fargate impostando il parametro di definizione delle attività di `requiresCompatibilities` su `FARGATE`. Per ulteriori informazioni, consulta [Capacity](task_definition_parameters.md#requires_compatibilities). Fargate offre versioni della piattaforma per Amazon Linux 2 (versione della piattaforma 1.3.0), il sistema operativo Bottlerocket (versione della piattaforma 1.4.0) e le edizioni Microsoft Windows 2019 Server Full e Core. Salvo diversa indicazione, le informazioni si applicano a tutte le piattaforme di Fargate. Per informazioni sulle regioni che supportano container Linux su Fargate, consulta [Contenitori Linux su AWS Fargate](AWS_Fargate-Regions.md#linux-regions). Per informazioni sulle regioni che supportano container Windows su Fargate, consulta [Contenitori Windows su AWS Fargate](AWS_Fargate-Regions.md#windows-regions). ## Procedure guidate Per informazioni su come iniziare a usare la console, consulta: + [Ulteriori informazioni su come creare un'attività di Amazon ECS Linux per Fargate](getting-started-fargate.md) + [Ulteriori informazioni su come creare un'attività di Amazon ECS Windows per Fargate](Windows_fargate-getting_started.md) Per informazioni su come iniziare a utilizzare AWS CLI, consulta: + [Creazione di un'attività Amazon ECS Linux per Fargate con AWS CLI](ECS_AWSCLI_Fargate.md) + [Creazione di un'attività Amazon ECS Windows per Fargate con AWS CLI](ECS_AWSCLI_Fargate_windows.md) ## fornitori di capacità Sono disponibili i seguenti provider di capacità: + Fargate + Fargate Spot: esegui le attività di Amazon ECS con tolleranza alle interruzioni a una tariffa scontata rispetto al prezzo di AWS Fargate. Fargate Spot esegue le attività nella capacità di elaborazione di riserva. Quando sarà AWS necessario ripristinare la capacità, le attività verranno interrotte con un avviso di due minuti. Per ulteriori informazioni, consulta [Cluster Amazon ECS per Fargate](fargate-capacity-providers.md). ## Definizioni di processi Le attività di Fargate non supportano tutti i parametri di definizione delle attività di Amazon ECS disponibili. Alcuni parametri non sono supportati, mentre altri si comportano diversamente con i processi Fargate. Per ulteriori informazioni, consulta [CPU e memoria del processo](fargate-tasks-services.md#fargate-tasks-size). ## Versioni della piattaforma AWS Le versioni della piattaforma Fargate vengono utilizzate per fare riferimento a un ambiente di runtime specifico per l'infrastruttura di attività Fargate. Si tratta di una combinazione delle versioni del kernel e del runtime del container. La versione della piattaforma viene selezionata quando si esegue un'attività o quando si crea un servizio per mantenere una serie di attività identiche. Nuove versioni della piattaforma vengono rilasciate con l'evolvere dell'ambiente di runtime, ad esempio se vengono introdotti aggiornamenti relativi al kernel o al sistema operativo, nuove funzionalità, correzioni di bug o aggiornamenti della sicurezza. La versione della piattaforma Fargate viene aggiornata attraverso una nuova revisione della versione della piattaforma. Ogni attività viene eseguita su una revisione della versione della piattaforma durante il suo ciclo di vita. Se desideri utilizzare l'ultima revisione della versione della piattaforma, devi avviare una nuova attività. Una nuova attività in esecuzione su Fargate viene eseguita sempre sulla versione della piattaforma più recente. Ciò garantisce che le attività vengano sempre avviate su un'infrastruttura sicura e con patch applicate. Se viene rilevato un problema di sicurezza che riguarda una versione della piattaforma esistente, AWS crea una nuova revisione con patch della versione della piattaforma e annulla le attività in esecuzione sulla revisione vulnerabile. In alcuni casi viene inviata una notifica in merito alla programmazione del ritiro delle attività su Fargate. Per ulteriori informazioni, consulta [Ritiro e manutenzione delle attività per AWS Fargate su Amazon ECS](task-maintenance.md). Per ulteriori informazioni, consulta . [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md). ## Bilanciamento del carico nel servizio Puoi scegliere di configurare il servizio Amazon ECS su AWS Fargate per l'utilizzo di Elastic Load Balancing per l'implementazione uniforme del traffico fra i processi del tuo servizio. I servizi di Amazon ECS su AWS Fargate supportano i tipi di bilanciatori del carico Application Load Balancer, Network Load Balancer e Gateway Load Balancer. Gli Application Load Balancer vengono utilizzati per instradare il traffico HTTP/HTTPS (o di livello 7). I Network Load Balancer sono utilizzati per instradare il traffico TCP o UDP (o livello 4). Per ulteriori informazioni, consulta [Usa il bilanciamento del carico per distribuire il traffico del servizio Amazon ECS](service-load-balancing.md). Inoltre, quando crei gruppi di destinazione per questi servizi, devi scegliere `ip` come tipo di destinazione e non `instance`. Il motivo è che i processi che usano la modalità di rete `awsvpc` sono associati a un'interfaccia di rete elastica e non a un'istanza Amazon EC2. Per ulteriori informazioni, consulta [Usa il bilanciamento del carico per distribuire il traffico del servizio Amazon ECS](service-load-balancing.md). L'utilizzo di un Network Load Balancer per instradare il traffico UDP alle attività Amazon ECS su AWS Fargate è supportato solo se utilizzi la piattaforma versione 1.4 o successiva. ## Parametri di utilizzo Puoi utilizzare le metriche di CloudWatch utilizzo per fornire visibilità sull'utilizzo delle risorse del tuo account. Utilizza queste metriche per visualizzare l'utilizzo corrente del servizio su CloudWatch grafici e dashboard. AWS Fargate le metriche di utilizzo corrispondono alle quote di servizio. AWS È possibile configurare gli allarmi che avvisano quando l'uso si avvicina a una quota di servizio. Per ulteriori informazioni sulle quote di servizio di AWS Fargate, consulta [Amazon ECS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html) in *Riferimenti generali di Amazon Web Services*. [Per ulteriori informazioni sulle metriche di AWS Fargate utilizzo, consulta AWS Fargate metriche di utilizzo.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-fargate-usage.html) # Considerazioni sulla sicurezza di Amazon ECS su quando utilizzare Fargate Consigliamo ai clienti che cercano un forte isolamento per le proprie attività di utilizzare Fargate. Fargate esegue ogni attività in un ambiente di virtualizzazione hardware. Ciò garantisce che tali carichi di lavoro containerizzati non condividono le interfacce di rete, lo spazio di archiviazione temporaneo, la CPU o la memoria di Fargate con altre attività. Per ulteriori informazioni, consulta [Panoramica sulla sicurezza di](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf). AWS Fargate # Best practice sulla sicurezza di Fargate in Amazon ECS Consigliamo di tenere in considerazione le best practice seguenti quando utilizzi AWS Fargate. Per ulteriori indicazioni, vedere [Panoramica sulla sicurezza di AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf). ## Utilizzato AWS KMS per crittografare lo storage temporaneo per Fargate È necessario crittografare lo storage temporaneo con una delle chiavi gestite dal cliente o con chiavi gestite dal cliente. AWS KMS Le attività ospitate su Fargate che utilizzano la versione della piattaforma `1.4.0` o successiva ricevono almeno 20 GiB di spazio di archiviazione temporaneo. Per ulteriori informazioni, consulta l'argomento relativo alla [chiave gestita dal cliente (CMK)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html). La quantità totale di spazio di archiviazione temporaneo può essere aumentata, fino ad un massimo di 200 GiB, specificando il parametro `ephemeralStorage` nella definizione di attività. Per le attività avviate a partire dal 28 maggio 2020 (compreso), lo spazio di archiviazione temporaneo viene crittografato con un algoritmo di crittografia AES-256 utilizzando una chiave di crittografia gestita da Fargate. Per ulteriori informazioni, [Storage options for Amazon ECS tasks](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html). **Esempio: avvio di un'attività sulla versione della piattaforma 1.4.0 di Fargate con crittografia dello spazio di archiviazione temporaneo** Il comando seguente avvierà un'attività sulla versione della piattaforma 1.4 di Fargate. Dal momento che viene avviata nell'ambito del cluster, l'attività utilizza 20 GiB di spazio di archiviazione temporaneo crittografato in automatico. ``` aws ecs run-task --cluster clustername \ --task-definition taskdefinition:version \ --count 1 --launch-type "FARGATE" \ --platform-version 1.4.0 \ --network-configuration "awsvpcConfiguration={subnets=[subnetid],securityGroups=[securitygroupid]}" \ --region region ``` ## Funzionalità SYS\$1PTRACE per il tracciamento di syscall del kernel con Fargate La configurazione predefinita delle funzionalità di Linux che vengono aggiunte o rimosse dal container è fornita da Docker. Le attività avviate su Fargate supportano solo l'aggiunta della funzionalità del kernel `SYS_PTRACE`. Il seguente video mostra come utilizzare questa funzionalità attraverso il progetto Sysdig [Falco](https://github.com/falcosecurity/falco). [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/OYGKjmFeLqI/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/OYGKjmFeLqI) [Il codice discusso nel video precedente può essere trovato qui. GitHub ](https://github.com/paavan98pm/ecs-fargate-pv1.4-falco) ## Usa Amazon GuardDuty con Fargate Runtime Monitoring Amazon GuardDuty è un servizio di rilevamento delle minacce che aiuta a proteggere account, contenitori, carichi di lavoro e dati all'interno del tuo AWS ambiente. Utilizzando modelli di machine learning (ML) e funzionalità di rilevamento di anomalie e minacce, monitora GuardDuty continuamente diverse fonti di log e attività di runtime per identificare e dare priorità ai potenziali rischi per la sicurezza e alle attività dannose nel tuo ambiente. Runtime Monitoring in GuardDuty protegge i carichi di lavoro in esecuzione su Fargate AWS monitorando continuamente i log e l'attività di rete per identificare comportamenti dannosi o non autorizzati. Runtime Monitoring utilizza un agente di GuardDuty sicurezza leggero e completamente gestito che analizza il comportamento sull'host, come l'accesso ai file, l'esecuzione dei processi e le connessioni di rete. Ciò copre problemi come le escalation di privilegi, l'utilizzo di credenziali esposte o la comunicazione con indirizzi IP e domini dannosi e la presenza di malware sulle istanze di Amazon EC2 e sui carichi di lavoro del container. Per ulteriori informazioni, consulta [GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) nella Guida per l'*GuardDuty utente*. # Considerazioni relative sicurezza di Fargate per Amazon ECS Ogni attività dispone di una capacità di infrastruttura dedicata, perché Fargate esegue ciascun carico di lavoro su un ambiente virtuale isolato. I carichi di lavoro eseguiti su Fargate non condividono interfacce di rete, spazio di archiviazione temporaneo, CPU o memoria con altre attività. È possibile eseguire più container all'interno di un'attività, inclusi container di applicazioni e container sidecar (o semplicemente sidecar). Un *sidecar* è un container che viene eseguito parallelamente al container di un'applicazione in un'attività Amazon ECS. Sebbene il container dell'applicazione esegua il codice applicativo di base, i processi in esecuzione nei sidecar possono potenziare l'applicazione. I sidecar consentono di separare le funzioni dell'applicazione in container dedicati e di semplificare così l'aggiornamento di parti dell'applicazione. I container che fanno parte della stessa attività condividono le risorse per il tipo di avvio Fargate, perché verranno sempre eseguiti sullo stesso host e condivideranno le risorse di elaborazione. Questi container condividono anche l'archiviazione temporanea fornita da Fargate. I container Linux in un'attività condividono gli spazi dei nomi di rete, inclusi l'indirizzo IP e le porte di rete. All'interno di un'attività, i container che appartengono a tale attività possono comunicare tra loro attraverso localhost. L'ambiente di runtime in Fargate impedisce l'uso di determinate funzionalità del controller supportate sulle istanze EC2. Quando progetti carichi di lavoro in esecuzione su Fargate, tieni presente gli aspetti seguenti: + Nessun container o accesso privilegiato: funzionalità come i container o l'accesso privilegiato non sono attualmente disponibili su Fargate. Ciò influirà su casi d'uso come l'esecuzione di Docker in Docker. + Accesso limitato alle funzionalità di Linux: l'ambiente in cui i container vengono eseguiti su Fargate è bloccato. Le funzionalità aggiuntive di Linux, come CAP\$1SYS\$1ADMIN e CAP\$1NET\$1ADMIN, sono limitate per impedire un'escalation dei privilegi. Fargate supporta l'aggiunta della funzionalità [CAP\$1SYS\$1PTRACE](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#other_task_definition_params) di Linux alle attività per consentire agli strumenti di osservabilità e sicurezza implementati all'interno dell'attività di monitorare l'applicazione containerizzata. + Nessun accesso all'host sottostante: né i clienti né AWS gli operatori possono connettersi a un host che esegue i carichi di lavoro dei clienti. Puoi utilizzare ECS exec per eseguire comandi in oppure ottenere uno shell (interprete di comandi) per un container in esecuzione su Fargate. Puoi utilizzare ECS exec per raccogliere informazioni diagnostiche per il debug. Fargate impedisce inoltre ai container di accedere alle risorse dell'host sottostante, come il file system, i dispositivi, le reti e il runtime di container. + Rete: è possibile utilizzare i gruppi di sicurezza e la rete ACLs per controllare il traffico in entrata e in uscita. Le attività Fargate ricevono un indirizzo IP dalla sottorete configurata nel VPC. # Versioni della piattaforma Fargate per Amazon ECS AWS Le versioni della piattaforma Fargate vengono utilizzate per fare riferimento a un ambiente di runtime specifico per l'infrastruttura di attività Fargate. Si tratta di una combinazione delle versioni del kernel e del runtime del container. La versione della piattaforma viene selezionata quando si esegue un'attività o quando si crea un servizio per mantenere una serie di attività identiche. Nuove versioni della piattaforma vengono rilasciate con l'evolvere dell'ambiente di runtime, ad esempio se vengono introdotti aggiornamenti relativi al kernel o al sistema operativo, nuove funzionalità, correzioni di bug o aggiornamenti della sicurezza. La versione della piattaforma Fargate viene aggiornata attraverso una nuova revisione della versione della piattaforma. Ogni attività viene eseguita su una revisione della versione della piattaforma durante il suo ciclo di vita. Se desideri utilizzare l'ultima revisione della versione della piattaforma, devi avviare una nuova attività. Una nuova attività in esecuzione su Fargate viene eseguita sempre sulla versione della piattaforma più recente. Ciò garantisce che le attività vengano sempre avviate su un'infrastruttura sicura e con patch applicate. Se viene rilevato un problema di sicurezza che riguarda una versione della piattaforma esistente, AWS crea una nuova revisione con patch della versione della piattaforma e annulla le attività in esecuzione sulla revisione vulnerabile. In alcuni casi viene inviata una notifica in merito alla programmazione del ritiro delle attività su Fargate. Per ulteriori informazioni, consulta [Ritiro e manutenzione delle attività per AWS Fargate su Amazon ECS](task-maintenance.md). Specifica la versione della piattaforma quando esegui un'attività o implementi un servizio. Tieni presente le considerazioni seguenti quando specifichi una versione della piattaforma: + Puoi specificare un numero di versione in particolare, ad esempio `1.4.0` o `LATEST`. La versione della piattaforma Linux **PIÙ RECENTE** è `1.4.0`. La versione della piattaforma Windows **PIÙ RECENTE** è `1.0.0`. + Se desideri aggiornare la versione della piattaforma per un servizio, crea un'implementazione. Ad esempio, supponiamo che tu disponga di un servizio che esegue attività nella versione della piattaforma Linux `1.3.0`. Per modificare il servizio allo scopo di eseguire attività sulla versione `1.4.0` della piattaforma Linux, aggiorna il servizio e specifica una nuova versione della piattaforma. Le attività vengono implementate nuovamente con la versione e la revisione della versione della piattaforma più recenti. Per ulteriori informazioni sulle implementazioni, consulta [Servizi Amazon ECS](ecs_services.md). + Se la capacità del servizio viene ridotta senza aggiornare la versione della piattaforma, le attività ricevono la versione della piattaforma specificata nell'implementazione corrente del servizio. Ad esempio, supponiamo che tu disponga di un servizio che esegue attività nella versione della piattaforma Linux `1.3.0`. Se aumenti il conteggio desiderato del servizio, il pianificatore del servizio avvia le nuove attività utilizzando la revisione più recente della versione della piattaforma `1.3.0`. + Le nuove attività vengono sempre eseguite sulla revisione più recente della versione della piattaforma. Ciò garantisce che le attività siano sempre eseguite su un'infrastruttura protetta e aggiornata. + I numeri di versione della piattaforma per i container Linux e Windows su Fargate sono indipendenti. Ad esempio, il comportamento, le funzionalità e il software utilizzati nella versione della piattaforma `1.0.0` per i container Windows su Fargate non sono paragonabili a quelli della versione della piattaforma `1.0.0` per i container Linux su Fargate. + Quanto segue si applica alle versioni della piattaforma Fargate Windows. Le immagini del container Microsoft Windows Server devono essere create da una versione specifica di Windows Server. Devi selezionare la stessa versione di Windows Server in `platformFamily` quando esegui un'attività o crei un servizio che corrisponde all'immagine del container di Windows Server. Inoltre, puoi fornire una `operatingSystemFamily` corrispondente nella definizione delle attività per evitare che vengano eseguite sulla versione di Windows errata. Per ulteriori informazioni, consulta [Corrispondenza della versione dell'host del container con le versioni delle immagini del container](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility#matching-container-host-version-with-container-image-versions) sul sito Web di Microsoft Learn. # Migrazione alla versione 1.4.0 della piattaforma Linux su Amazon ECS Quando si esegue la migrazione dei processi Amazon ECS su Fargate dalla versione della piattaforma `1.0.0`, `1.1.0`, `1.2.0` o `1.3.0` alla piattaforma `1.4.0` è necessario considerare quanto segue. È consigliabile verificare che il processo funzioni correttamente sulla versione `1.4.0` della piattaforma prima di eseguire la migrazione delle attività. + Il comportamento del traffico di rete da e verso le attività è stato aggiornato. A partire dalla versione 1.4.0 della piattaforma, tutte le attività di Amazon ECS su Fargate ricevono un'unica interfaccia di rete elastica (denominata interfaccia di rete elastica (ENI) dell'attività) e tutto il traffico di rete passa attraverso tale ENI all'interno del VPC. Questo traffico viene registrato nei log di flusso VPC. Per ulteriori informazioni, consulta [Opzioni di rete di attività di Amazon ECS per Fargate](fargate-task-networking.md). + Se utilizzi endpoint VPC dell'interfaccia, prendi in considerazione le seguenti informazioni. + Per le immagini dei container ospitate con Amazon ECR, sono necessari i seguenti endpoint. Per ulteriori informazioni, consulta [Endpoint VPC dell'interfaccia Amazon ECR (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) nella *Guida per l'utente di Amazon Elastic Container Registry*. + **com.amazonaws. *region*.ecr.dkr Endpoint VPC Amazon ECR** + **com.amazonaws. *region*.ecr.api Endpoint** VPC Amazon ECR + Endpoint del gateway Amazon S3 + Quando la definizione delle attività fa riferimento a segreti di Secrets Manager per recuperare dati sensibili per i container, è necessario creare gli endpoint VPC dell'interfaccia per Secrets Manager. Per ulteriori informazioni, consulta [Utilizzo di Secrets Manager con endpoint VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html) nella *Guida per l'utente di Gestione dei segreti AWS *. + Quando si utilizza una definizione di attività che fa riferimento ai parametri dell'archivio parametri di Systems Manager per recuperare dati sensibili per i container, è necessario creare gli endpoint VPC di interfaccia per Systems Manager. Per ulteriori informazioni, consulta [Improve the security of EC2 instances by using VPC endpoints for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) nella *Guida per l'utente di AWS Systems Manager *. + Il gruppo di sicurezza nell'interfaccia di rete elastica (ENI) associato all'attività richiede delle regole del gruppo di sicurezza per consentire il traffico tra l'attività e gli endpoint VPC. # Log delle modifiche della versione della piattaforma Fargate Linux Di seguito sono riportate le versioni della piattaforma Linux disponibili. Per informazioni sulla dichiarazione delle versioni della piattaforma come obsolete, consulta [AWS Deprecazione della versione della piattaforma Fargate Linux](platform-versions-retired.md). ## 1.4.0 Di seguito è riportato il changelog per la versione della piattaforma `1.4.0`. + A partire dal 5 novembre 2020, qualsiasi nuovo processo Amazon ECS avviato su Fargate tramite la versione della piattaforma `1.4.0` potrà utilizzare le seguenti funzioni: + Quando utilizzi Secrets Manager per archiviare dati sensibili, è possibile inserire una chiave JSON specifica o una versione specifica di un segreto come variabile di ambiente o in una configurazione di log. Per ulteriori informazioni, consulta [Trasferimento di dati sensibili a un container Amazon ECS](specifying-sensitive-data.md). + Specifica le variabili di ambiente in blocco utilizzando il parametro di definizione del container `environmentFiles`. Per ulteriori informazioni, consulta [Passare una singola variabile di ambiente a un container Amazon ECS](taskdef-envfiles.md). + Alle attività eseguite in un VPC e in una sottorete abilitata per IPv6 verranno assegnati sia un IPv4 indirizzo privato che un indirizzo. IPv6 Per maggiori informazioni, consulta la sezione [Opzioni di networking delle attività di Amazon ECS per Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html). + L'endpoint dei metadati dei processi versione 4 fornisce metadati aggiuntivi relativi al processo e al container, inclusi il tipo di avvio del processo, l'Amazon Resource Name (ARN) del container e il driver di log e le relative opzioni utilizzate. Quando si esegue una query sull'endpoint `/stats` si ricevono anche le statistiche sulla velocità di rete per i container. Per ulteriori informazioni, consulta [Endpoint metadati delle attività versione 4](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4-fargate.html). + A partire dal 30 luglio 2020, qualsiasi nuovo processo Amazon ECS avviato su Fargate tramite la versione della piattaforma `1.4.0` sarà in grado di instradare il traffico UDP utilizzando un Network Load Balancer ai suoi processi Amazon ECS su Fargate. Per ulteriori informazioni, consulta [Usa il bilanciamento del carico per distribuire il traffico del servizio Amazon ECS](service-load-balancing.md). + A partire dal 28 maggio 2020, qualsiasi nuova attività Amazon ECS lanciata su Fargate utilizzando la `1.4.0` versione della piattaforma avrà lo storage temporaneo crittografato con un algoritmo di crittografia AES-256 utilizzando una chiave di crittografia proprietaria. AWS Per ulteriori informazioni, consultare [Archiviazione temporanea delle attività di Fargate per Amazon ECS](fargate-task-storage.md) e [Opzioni di archiviazione per le attività di Amazon ECS](using_data_volumes.md). + Aggiunto il supporto per l'utilizzo dei volumi del file system Amazon EFS per l'archiviazione dei processi persistenti. Per ulteriori informazioni, consulta [Usare i volumi Amazon EFS con Amazon ECS](efs-volumes.md). + Lo storage temporaneo delle attività è stato aumentato fino a un minimo di 20 GB per ogni attività. Per ulteriori informazioni, consulta [Archiviazione temporanea delle attività di Fargate per Amazon ECS](fargate-task-storage.md). + Il comportamento del traffico di rete da e verso le attività è stato aggiornato. A partire dalla versione 1.4.0 della piattaforma, tutti i processi Fargate ricevono un'unica interfaccia di rete elastica (denominata ENI di processo) e tutto il traffico di rete scorre attraverso tale ENI all'interno del VPC e sarà visibile all'utente attraverso i log di flusso del VPC. Per ulteriori informazioni sul networking per il tipo di avvio Amazon EC2, consulta [Opzioni di networking delle attività di Amazon ECS per EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html). Per ulteriori informazioni sul networking per Fargate, consulta [Opzioni di rete di attività di Amazon ECS per Fargate](fargate-task-networking.md). + Task aggiunge il supporto per i jumbo frame. ENIs Le interfacce di rete sono configurate con un'unità di trasmissione massima (MTU), ovvero la dimensione del payload più grande che si adatta all'interno di un singolo frame. Più grande è l'MTU, più il payload dell'applicazione può essere adattato all'interno di un singolo fotogramma, riducendo il sovraccarico per fotogramma e aumentando l'efficienza. Il supporto dei frame jumbo riduce il sovraccarico quando il percorso di rete tra l'attività e la destinazione supporta frame jumbo, ad esempio tutto il traffico che rimane all'interno del VPC. + CloudWatch Container Insights includerà metriche delle prestazioni di rete per le attività di Fargate. Per ulteriori informazioni, consulta [Monitora i container di Amazon ECS utilizzando Container Insights con osservabilità migliorata.](cloudwatch-container-insights.md). + Aggiunto il supporto per l'endpoint dei metadati dei processi versione 4 che fornisce informazioni aggiuntive per i processi Fargate, incluse le statistiche di rete per il processo e la zona di disponibilità in cui il processo è in esecuzione. Per ulteriori informazioni, consultare [Versione 4 degli endpoint dei metadati delle attività di Amazon ECS](task-metadata-endpoint-v4.md) e [Endpoint metadati delle attività Amazon ECS versione 4 per le attività su Fargate](task-metadata-endpoint-v4-fargate.md). + Aggiunto il supporto per il parametro Linux `SYS_PTRACE` nelle definizioni dei container. Per ulteriori informazioni, consulta [Parametri Linux](task_definition_parameters.md#container_definition_linuxparameters). + L'agente del container Fargate sostituisce l'uso dell'agente del container Amazon ECS per tutti i processi di Fargate. Spesso, questa modifica non dovrebbe avere effetto sull'esecuzione delle attività. + Il runtime del container ora utilizza Containerd invece di Docker. Più frequentemente, questa modifica non dovrebbe avere effetto sull'esecuzione delle attività. Si noterà che alcuni messaggi di errore che hanno origine dal runtime del container passano dal menzionare Docker a errori più generici. Per informazioni, consulta [Messaggi di errore delle attività di Amazon ECS interrotte](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html) + Basato su Amazon Linux 2. # AWS Deprecazione della versione della piattaforma Fargate Linux **Importante** Il supporto per PV 1.3.0 a Fargate terminerà il 30 giugno 2026. A partire dal 15 giugno 2026, renderemo ritirata la versione 1.3.0 della piattaforma. Da quel momento, non sarà possibile avviare nuove attività o creare nuovi servizi configurati con la versione 1.3.0 della piattaforma, ma le attività esistenti continueranno a essere eseguite. Il 30 giugno 2026, termineremo tutte le restanti attività in esecuzione configurate con la versione 1.3.0 della piattaforma. Per informazioni su come eseguire la migrazione alla versione 1.4 della piattaforma, consulta [Migrazione alla versione 1.4.0 della piattaforma Linux su Amazon ECS](platform-version-migration.md). La tabella seguente elenca le versioni della piattaforma Linux che AWS Fargate ha dichiarato obsolete o per le quali è stata pianificata la loro obsolescenza. Queste versioni della piattaforma rimarranno disponibili fino alla data di dichiarazione come obsolete pubblicata. Una *data di aggiornamento forzato* viene fornita per ogni versione della piattaforma pianificata per l'interruzione dei processi. Alla data di aggiornamento forzato, qualsiasi servizio che utilizza la versione della piattaforma `LATEST` che punta a una versione della piattaforma che è stata dichiarata come obsoleta verrà aggiornata utilizzando l'opzione Forza nuova implementazione. Quando il servizio viene aggiornato utilizzando l'opzione Forza nuova implementazione, tutti i processi in esecuzione su una versione della piattaforma pianificata per la dichiarazione come obsoleta vengono arrestati e vengono avviati nuovi processi che utilizzano la versione della piattaforma a cui punta il tag `LATEST` in quel momento. I processi o i servizi autonomi con una versione esplicita della piattaforma impostata non sono interessati dalla data di aggiornamento forzato. Per informazioni su come eseguire la migrazione alla versione della piattaforma più recente, consulta [Migrazione alla versione 1.4.0 della piattaforma Linux su Amazon ECS](platform-version-migration.md). Una volta che la versione della piattaforma raggiunge la *data di ritiro*, la versione della piattaforma non sarà più disponibile per nuove attività o servizi. Qualsiasi processo o servizio autonomo che utilizza esplicitamente una versione della piattaforma dichiarata obsoleta continuerà a utilizzare tale versione della piattaforma fino a quando i processi non saranno arrestati. Dopo la data di ritiro, una versione della piattaforma dichiarata obsoleta non riceverà più aggiornamenti di sicurezza o correzioni di bug. | Versione della piattaforma | Data di aggiornamento forzato | Data di ritiro | | --- | --- | --- | | 1.0.0 | 26 ottobre 2020 | 14 dicembre 2020 | | 1.1.0 | 26 ottobre 2020 | 14 dicembre 2020 | | 1.2.0 | 26 ottobre 2020 | 14 dicembre 2020 | | 1.3.0 | | 15 giugno 2026 | Per informazioni sulle versioni correnti della piattaforma, consulta [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md). ## Log delle modifiche delle versioni obsolete di Fargate Linux ### 1.3.0 Di seguito è riportato il changelog per la versione della piattaforma `1.3.0`. + A partire dal 30 settembre 2019, ogni nuovo processo Fargate che viene avviato supporta i driver di log `awsfirelens`. Configura Amazon ECS FireLens per utilizzare i parametri di definizione delle attività per indirizzare i log verso un AWS servizio o una destinazione AWS Partner Network (APN) per l'archiviazione e l'analisi dei log. Per ulteriori informazioni, consulta [Inviare i log di Amazon ECS a un servizio o AWS AWS Partner](using_firelens.md). + Aggiunta la funzione di riavvio dei processi per i processi Fargate, che corrisponde al processo di aggiornamento dei processi che sono parte di un servizio Amazon ECS. Per ulteriori informazioni, consulta [Task retirement and maintenance for AWS Fargate su Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-maintenance.html). + A partire dal 27 marzo 2019, ogni nuovo processo Fargate che viene avviato può utilizzare ulteriori parametri di definizione dei processi che consentono di definire una configurazione proxy, le dipendenze per l'avvio e l'arresto di container, nonché un valore di timeout di avvio e arresto per container. Per ulteriori informazioni, consultare [Configurazione del proxy](task_definition_parameters.md#proxyConfiguration), [Dipendenze per i container](task_definition_parameters.md#container_definition_dependson) e [Timeout del container](task_definition_parameters.md#container_definition_timeout). + A partire dal 2 aprile 2019, qualsiasi nuova attività di Fargate che verrà lanciata supporta l'iniezione di dati sensibili nei contenitori archiviando i dati sensibili in Gestione dei segreti AWS segreti o AWS Systems Manager parametri Parameter Store e quindi facendo riferimento ad essi nella definizione del contenitore. Per ulteriori informazioni, consulta [Trasferimento di dati sensibili a un container Amazon ECS](specifying-sensitive-data.md). + A partire dal 1 maggio 2019, ogni nuovo processo Fargate che viene avviato supporta il riferimento ai dati sensibili nella configurazione dei log di un container utilizzando il parametro di definizione del container `secretOptions`. Per ulteriori informazioni, consulta [Trasferimento di dati sensibili a un container Amazon ECS](specifying-sensitive-data.md). + A partire dal 1 maggio 2019, ogni nuovo processo Fargate che viene avviato supporta i driver di log `splunk` in aggiunta ai driver di log `awslogs`. Per ulteriori informazioni, consulta [Archiviazione e registrazione](task_definition_parameters.md#container_definition_storage). + A partire dal 9 luglio 2019, tutte le nuove attività di Fargate lanciate supportano CloudWatch Container Insights. Per ulteriori informazioni, consulta [Monitora i container di Amazon ECS utilizzando Container Insights con osservabilità migliorata.](cloudwatch-container-insights.md). + A partire dal 3 dicembre 2019, è supportato il Capacity Provider Fargate Spot. Per ulteriori informazioni, consulta [Cluster Amazon ECS per Fargate](fargate-capacity-providers.md). + Basato su Amazon Linux 2. ### 1.2.0 Di seguito è riportato il changelog per la versione della piattaforma `1.2.0`. **Nota** La versione della piattaforma `1.2.0` non è più disponibile. Per informazioni sulla dichiarazione delle versioni della piattaforma come obsolete, consulta [AWS Deprecazione della versione della piattaforma Fargate Linux](#platform-versions-retired). + È stato aggiunto il supporto per l'autenticazione del registro privato tramite Gestione dei segreti AWS. Per ulteriori informazioni, consulta [Utilizzo di immagini non AWS containerizzate in Amazon ECS](private-auth.md). ### 1.1.0 Di seguito è riportato il changelog per la versione della piattaforma `1.1.0`. **Nota** La versione della piattaforma `1.1.0` non è più disponibile. Per informazioni sulla dichiarazione delle versioni della piattaforma come obsolete, consulta [AWS Deprecazione della versione della piattaforma Fargate Linux](#platform-versions-retired). + Aggiunto il supporto per gli endpoint dei metadati dei processi di Amazon ECS. Per ulteriori informazioni, consulta [Metadati delle attività Amazon ECS disponibili per le attività su Fargate](fargate-metadata.md). + Aggiunta del supporto per i controlli dello stato Docker nelle definizioni dei container. Per ulteriori informazioni, consulta [Controllo dell’integrità](task_definition_parameters.md#container_definition_healthcheck). + Aggiunto il supporto per il rilevamento servizi di Amazon ECS. Per ulteriori informazioni, consulta [Usare il rilevamento servizi per connettere i servizi Amazon ECS con nomi DNS](service-discovery.md). ### 1.0.0 Di seguito è riportato il changelog per la versione della piattaforma `1.0.0`. **Nota** La versione della piattaforma `1.0.0` non è più disponibile. Per informazioni sulla dichiarazione delle versioni della piattaforma come obsolete, consulta [AWS Deprecazione della versione della piattaforma Fargate Linux](#platform-versions-retired). + Basato su Amazon Linux 2017.09 + Versione iniziale. # Log delle modifiche della versione della piattaforma Fargate Windows Di seguito sono riportate le versioni della piattaforma disponibili per i container Windows. ## 1.0.0 Di seguito è riportato il changelog per la versione della piattaforma `1.0.0`. + Versione iniziale per il supporto sui seguenti sistemi operativi Microsoft Windows Server: + Windows Server 2019 Full + Windows Server 2019 Core + Windows Server 2022 Full + Windows Server 2022 Core # Considerazioni relative ai container Windows su Fargate per Amazon ECS Di seguito sono riportate le differenze e le considerazioni da tenere presente quando si eseguono contenitori Windows su AWS Fargate. Per eseguire attività su container Linux e Windows, devi creare definizioni delle attività separate per ciascun sistema operativo. AWS gestisce la gestione delle licenze del sistema operativo, quindi non sono necessarie licenze Microsoft Windows Server aggiuntive. I contenitori Windows su AWS Fargate supportano i seguenti sistemi operativi: + Windows Server 2019 Full + Windows Server 2019 Core + Windows Server 2022 Full + Windows Server 2022 Core I contenitori Windows su AWS Fargate supportano il driver awslogs. Per ulteriori informazioni, consulta [Invia i log di Amazon ECS a CloudWatch](using_awslogs.md). Le seguenti funzionalità non sono supportate nei container Windows su Fargate: + Amazon FSx + Trunking ENI + g per Windows Containers MSAs + Servizio App Mesh e integrazione proxy per i processi + Integrazione del router di log Firelens per i processi + Volumi EFS + Volumi EBS + I parametri di definizione delle attività riportati di seguito: + `maxSwap` + `swappiness` + `environmentFiles` + Il provider di capacità Fargate Spot + Volumi di immagine L'opzione Dockerfile `volume` viene ignorata. Invece, usa montaggi vincolati nella tua definizione di attività. Per ulteriori informazioni, consulta [Utilizzo di montaggio vincolato con Amazon ECS](bind-mounts.md). + I parametri della CPU e della memoria a livello di attività vengono ignorati per i container Windows. Ti consigliamo di specificare risorse a livello di container per i container Windows. + memoria per attività + mermoryReservation sui container + Riavvia le policy sui container + Impossibile aggiornare la platformFamily per un servizio. # Comportamento dell'estrazione delle immagini dei container Linux sui container Fargate per Amazon ECS Ogni attività di Fargate viene eseguita su una propria istanza monouso con tenant singolo. Quando si eseguono container Linux su Fargate, le immagini o i livelli di immagini dei container non vengono memorizzati nella cache dell'istanza. Pertanto, per ogni immagine del container definita nell'attività, l'intera immagine del container deve essere estratta dal relativo registro per ogni attività di Fargate. Il tempo necessario per estrarre le immagini è direttamente correlato al tempo impiegato per avviare un'attività di Fargate. Prendi in considerazione le seguenti informazioni per ottimizzare il tempo di estrazione dell'immagine. **Prossimità dell'immagine del container** Per ridurre il tempo necessario per scaricare le immagini dei container, posiziona i dati il più vicino possibile al calcolo. L'estrazione dell'immagine di un contenitore da Internet o dall'altra parte Regioni AWS potrebbe influire sui tempi di download. Consigliamo di archiviare l'immagine del container nella stessa Regione in cui verrà eseguita l'attività. Se memorizzi l'immagine del container in Amazon ECR, utilizza un endpoint dell'interfaccia VPC per ridurre ulteriormente il tempo di estrazione dell'immagine. Per ulteriori informazioni, consulta [Amazon ECR interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) nella *Guida per l'utente di Amazon ECR*. **Riduzione delle dimensioni dell'immagine del container** Le dimensioni di un'immagine del container influiscono direttamente sul tempo di download. La riduzione delle dimensioni o del numero di livelli dell'immagine del container può ridurre il tempo necessario per il download di un'immagine. Le immagini di base leggere (come l'immagine minima del container Amazon Linux 2023) possono essere significativamente più piccole di quelle basate sulle immagini del sistema operativo tradizionale. Per ulteriori informazioni sull'immagine minima, consulta [AL2023 Minimal container image](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html) nella *Amazon Linux 2023 User Guide*. **Algoritmi di compressione alternativi** I livelli dell'immagine del container vengono spesso compressi quando si inseriscono in un registro di immagini del container. La compressione del livello dell'immagine del container riduce la quantità di dati che devono essere trasferiti attraverso la rete e archiviati nel registro di immagini del container. Dopo che un livello dell'immagine del container è stato scaricato su un'istanza dal runtime di quest'ultimo, tale livello viene decompresso. L'algoritmo di compressione utilizzato e la quantità di v CPUs disponibile per il runtime influiscono sul tempo necessario per decomprimere l'immagine del contenitore. Su Fargate, puoi aumentare le dimensioni dell'attività o sfruttare l'algoritmo di compressione zstd più performante per ridurre il tempo impiegato per la decompressione. Per ulteriori informazioni, vedere [zstd](https://github.com/facebook/zstd) on. GitHub Per informazioni su come implementare le immagini per Fargate, vedere [Riduzione dei tempi di AWS Fargate avvio con le immagini dei container compressi zstd.](https://aws.amazon.com/blogs/containers/reducing-aws-fargate-startup-times-with-zstd-compressed-container-images/) **Caricamento lento delle immagini del container** Per immagini del container di grandi dimensioni (> 250 MB), potrebbe essere utile caricare lentamente l'immagine del container anziché scaricarla tutta. Su Fargate, puoi utilizzare Seekable OCI (SOCI) per caricare lentamente un'immagine del container da un registro di immagini del container. Per ulteriori informazioni, consulta [soci-snapshotter](https://github.com/awslabs/soci-snapshotter) on GitHub e [Lazy loading](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-soci-images) container images using Seekable OCI (SOCI). # Comportamento dell'estrazione delle immagini dei container Windows sui container Fargate per Amazon ECS Fargate Windows memorizza nella cache l'immagine di base servercore del mese più recente e quella del mese precedente fornita da Microsoft. Queste immagini corrispondono al numero di patch aggiornate ogni Patch Tuesday. KB/Build Ad esempio, il 9 aprile 2024, Microsoft ha rilasciato KB5036896 (17763.5696) per Windows Server 2019. Il mese precedente KB del 12 marzo 2024 era (17763.5576). KB5035849 Quindi, per le piattaforme `WINDOWS_SERVER_2019_CORE` e `WINDOWS_SERVER_2019_FULL` le seguenti immagini del container sono state memorizzate nella cache: + `mcr.microsoft.com/windows/servercore:ltsc2019` + ` mcr.microsoft.com/windows/servercore:10.0.17763.5696` + `mcr.microsoft.com/windows/servercore:10.0.17763.5576` Inoltre, il 9 aprile 2024, Microsoft ha rilasciato KB5036909 (20348.2402) per Windows Server 2022. Il mese precedente KB del 12 marzo 2024 era (20348.2340). KB5035857 Quindi, per le piattaforme `WINDOWS_SERVER_2022_CORE` e `WINDOWS_SERVER_2022_FULL` le seguenti immagini del container sono state memorizzate nella cache: + `mcr.microsoft.com/windows/servercore:ltsc2022` + `mcr.microsoft.com/windows/servercore:10.0.20348.2402` + `mcr.microsoft.com/windows/servercore:10.0.20348.2340` # Archiviazione temporanea delle attività di Fargate per Amazon ECS Una volta eseguito il provisioning, ogni attività Amazon ECS ospitata su container Linux AWS Fargate riceve il seguente storage temporaneo per i bind mount. Può essere montato e condiviso tra container che utilizzano i parametri `volumes`, `mountPoints` e `volumesFrom` nella definizione di attività. Questa funzionalità non è supportata per i contenitori Windows su. AWS Fargate ## Versioni della piattaforma container Linux Fargate ### Versione 1.4.0 o successiva Per impostazione predefinita, le attività Amazon ECS ospitate su Fargate che utilizzano la piattaforma versione `1.4.0` o successiva ricevono almeno 20 GiB di storage temporaneo. La quantità totale di storage temporaneo può essere aumentata, fino a un massimo di 200 GiB. Puoi eseguire questa operazione specificando il parametro `ephemeralStorage` nella definizione di attività. L’immagine del container estratta, compressa e non compressa per il processo viene memorizzata nell’archiviazione temporanea. Per determinare la quantità totale di archiviazione temporanea che il processo deve utilizzare, è necessario sottrarre la quantità di archiviazione utilizzata dall’immagine del container dall’importo totale di archiviazione temporanea in cui è allocato il processo. Per le attività che utilizzano la piattaforma versione `1.4.0` o successiva avviati il 28 maggio 2020 o successivamente, lo storage temporaneo viene crittografato con un algoritmo di crittografia AES-256. Questo algoritmo utilizza una chiave AWS di crittografia proprietaria oppure è possibile creare una chiave gestita dal cliente. Per ulteriori informazioni, consulta [Customer managed keys for AWS Fargate ephemeral](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html) storage. Per le attività che utilizzano la piattaforma versione `1.4.0` o successiva, avviate a partire dal 18 novembre 2022, l'utilizzo di archiviazione temporanea viene segnalato tramite l'endpoint dei metadati dell'attività. Le applicazioni coinvolte nelle attività possono interrogare la versione 4 dell'endpoint dei metadati delle attività per ottenere la dimensione riservata dello spazio di archiviazione temporanea e la quantità utilizzata. Inoltre, la dimensione riservata dello storage temporaneo e la quantità utilizzata vengono inviate a Amazon CloudWatch Container Insights se attivi Container Insights. **Nota** Fargate riserva spazio su disco destinato unicamente a questo motore di calcolo. Non ti viene addebitato alcun costo. Sebbene non sia mostrato in queste metriche, puoi visualizzare questo spazio di archiviazione aggiuntivo in altri strumenti, come `df`. ### Versione 1.3.0 o precedente Per le attività Amazon ECS su Fargate che utilizzano la piattaforma versione `1.3.0` o precedente, ogni attività riceve il seguente storage temporaneo. + 10 GB di storage di livello Docker **Nota** Questo importo include gli artefatti dell'immagine sia del container compresso che di quello non compresso. + 4 GB aggiuntivi per i montaggi dei volumi. Può essere montato e condiviso tra container che utilizzano i parametri `volumes`, `mountPoints` e `volumesFrom` nella definizione di attività. ## Versioni della piattaforma container Windows Fargate ### Versione 1.0.0 o successiva Per impostazione predefinita, le attività Amazon ECS ospitate su Fargate che utilizzano la piattaforma versione `1.0.0` o successiva ricevono almeno 20 GiB di storage temporaneo. La quantità totale di storage temporaneo può essere aumentata, fino a un massimo di 200 GiB. Puoi eseguire questa operazione specificando il parametro `ephemeralStorage` nella definizione di attività. L’immagine del container estratta, compressa e non compressa per il processo viene memorizzata nell’archiviazione temporanea. Per determinare la quantità totale di storage temporaneo che l'attività deve utilizzare, è necessario sottrarre la quantità di storage utilizzato dall'immagine del container dalla quantità totale di storage temporaneo in cui è allocata l'attività. Per ulteriori informazioni, consulta [Utilizzo di montaggio vincolato con Amazon ECS](bind-mounts.md). # Chiavi gestite dal cliente per lo AWS Fargate storage temporaneo per Amazon ECS AWS Fargate supporta le chiavi gestite dai clienti per crittografare i dati per le attività di Amazon ECS archiviate in uno storage temporaneo per aiutare i clienti sensibili alle normative a soddisfare le proprie politiche di sicurezza interne. I clienti ottengono comunque i vantaggi della tecnologia serverless di Fargate, offrendo al contempo una maggiore visibilità sulla crittografia dell'archiviazione autogestita ai revisori della conformità. Sebbene Fargate utilizzi la crittografia dell'archiviazione temporanea gestita da Fargate per impostazione predefinita, i clienti possono anche utilizzare le proprie chiavi autogestite per crittografare i dati sensibili, come le informazioni finanziarie o relative alla salute. Puoi importare le tue chiavi o crearle in. AWS KMS AWS KMS Queste chiavi autogestite vengono archiviate AWS KMS ed eseguono azioni standard AWS KMS del ciclo di vita come la rotazione, la disabilitazione e l'eliminazione. È possibile controllare l'accesso e l'utilizzo delle chiavi nei log. CloudTrail Per impostazione predefinita, la chiave KMS supporta 50.000 concessioni per chiave. Fargate utilizza una singola AWS KMS sovvenzione per attività chiave gestita dal cliente, quindi supporta fino a 50.000 attività simultanee per ogni chiave. Se desideri aumentare questo numero, puoi richiedere un aumento del limite, che viene approvato su base volontaria. case-by-case Fargate non addebita alcun costo aggiuntivo per l'utilizzo delle chiavi gestite dal cliente. Ti viene addebitato solo il prezzo standard per l'utilizzo AWS KMS delle chiavi per l'archiviazione e le richieste API. **Topics** + [Creazione di una chiave di crittografia per l'archiviazione temporanea di Fargate per Amazon ECS](fargate-create-storage-key.md) + [Gestione delle AWS KMS chiavi per lo storage temporaneo Fargate per Amazon ECS](fargate-managing-kms-key.md) # Creazione di una chiave di crittografia per l'archiviazione temporanea di Fargate per Amazon ECS Crea una chiave gestita dal cliente per crittografare i dati nell'archiviazione temporanea di Fargate. **Nota** La crittografia dell'archiviazione temporanea di Fargate con chiavi gestite dal cliente non è disponibile per i cluster di attività di Windows. La crittografia dell'archiviazione temporanea di Fargate con chiavi gestite dal cliente non è disponibile sulle `platformVersions` precedenti alla `1.4.0`. Fargate riserva spazio sull'archiviazione temporanea utilizzata solo da Fargate e non viene addebitato alcun costo per lo spazio. L'allocazione potrebbe differire dalle attività chiave non gestite dal cliente, ma lo spazio totale rimane invariato. Puoi visualizzare questa modifica in strumenti come `df`. Le chiavi multiregione non sono supportate per l'archiviazione temporanea di Fargate. Gli alias delle chiavi KMS non sono supportati per l'archiviazione temporanea di Fargate. Per creare una chiave gestita dal cliente (CMK) per crittografare lo storage temporaneo per AWS KMS Fargate in, procedi nel seguente modo. 1. [https://console---aws.amazon.com.rproxy.goskope.comPassa](https://console.aws.amazon.com/kms) a /kms. 1. Segui le istruzioni per la [creazione di chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella [Guida per gli sviluppatori di AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) 1. Durante la creazione della AWS KMS chiave, assicuratevi di fornire al servizio Fargate le autorizzazioni AWS KMS operative pertinenti nelle politiche chiave. Per utilizzare la chiave gestita dal cliente con le risorse del cluster di Amazon ECS, le seguenti operazioni API devono essere concesse nella policy della chiave gestita: + `kms:GenerateDataKeyWithoutPlainText`‐ Chiama `GenerateDataKeyWithoutPlainText` per generare una chiave dati crittografata dalla chiave fornita AWS KMS . + `kms:CreateGrant`: aggiunge una concessione a una chiave gestita dal cliente. Concede l'accesso di controllo a una AWS KMS chiave specificata, che consente l'accesso alle operazioni di concessione richieste da Amazon ECS Fargate. Per ulteriori informazioni sull'[utilizzo delle concessioni](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html), consulta la [Guida per gli sviluppatori di AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). Ciò consente ad Amazon ECS Fargate di effettuare le seguenti operazioni: + Chiama `Decrypt` per AWS KMS ottenere la chiave di crittografia per decrittografare i dati di archiviazione effimeri. + Configurare un principale ritirato per consentire al servizio di `RetireGrant`. + `kms:DescribeKey`: fornisce i dettagli della chiave gestita dal cliente per consentire ad Amazon ECS di convalidarla se è simmetrica e abilitata. L'esempio seguente mostra una politica AWS KMS chiave da applicare alla chiave di destinazione per la crittografia. Per usare gli esempi di dichiarazioni della policy, sostituire *user input placeholders* con le proprie informazioni. Come sempre, configura solo le autorizzazioni di cui hai bisogno, ma dovrai fornire AWS KMS le autorizzazioni ad almeno un utente per evitare errori. ``` { "Sid": "Allow generate data key access for Fargate tasks.", "Effect": "Allow", "Principal": { "Service":"fargate.amazonaws.com" }, "Action": [ "kms:GenerateDataKeyWithoutPlaintext" ], "Condition": { "StringEquals": { "kms:EncryptionContext:aws:ecs:clusterAccount": [ "customerAccountId" ], "kms:EncryptionContext:aws:ecs:clusterName": [ "clusterName" ] } }, "Resource": "*" }, { "Sid": "Allow grant creation permission for Fargate tasks.", "Effect": "Allow", "Principal": { "Service":"fargate.amazonaws.com" }, "Action": [ "kms:CreateGrant" ], "Condition": { "StringEquals": { "kms:EncryptionContext:aws:ecs:clusterAccount": [ "customerAccountId" ], "kms:EncryptionContext:aws:ecs:clusterName": [ "clusterName" ] }, "ForAllValues:StringEquals": { "kms:GrantOperations": [ "Decrypt" ] } }, "Resource": "*" }, { "Sid": "Allow describe key permission for cluster operator - CreateCluster and UpdateCluster.", "Effect": "Allow", "Principal": { "AWS":"arn:aws:iam::customerAccountId:role/customer-chosen-role" }, "Action": [ "kms:DescribeKey" ], "Resource": "*" } ``` Le attività di Fargate utilizzano le chiavi contestuali di crittografia `aws:ecs:clusterAccount` e `aws:ecs:clusterName` per le operazioni di crittografia con la chiave. I clienti devono aggiungere queste autorizzazioni per limitare l'accesso a un cluster di account specifico. and/or Utilizza il nome del cluster e non l'ARN quando specifichi il cluster. Per ulteriori informazioni, consultare [Contesto della crittografia](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) nella [Guida per gli sviluppatori di AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). Quando crei o aggiorni un cluster, puoi utilizzare una chiave di condizione `fargateEphemeralStorageKmsKeyId`. Tale chiave di condizione consente ai clienti di avere un controllo più granulare delle policy IAM. Gli aggiornamenti alla configurazione `fargateEphemeralStorageKmsKeyId` hanno effetto solo sulle nuove implementazioni di servizi. Di seguito è riportato un esempio di come consentire ai clienti di concedere le autorizzazioni solo a uno specifico set di chiavi approvate AWS KMS . ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecs:CreateCluster", "ecs:UpdateCluster" ], "Resource": "*", "Condition": { "StringEquals": { "ecs:fargate-ephemeral-storage-kms-key": "arn:aws:kms:us-west-2:111122223333:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } } } ] } ``` ------ Segue un esempio per negare i tentativi di rimuovere AWS KMS chiavi già associate a un cluster. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": [ "ecs:CreateCluster", "ecs:UpdateCluster" ], "Resource": "*", "Condition": { "Null": { "ecs:fargate-ephemeral-storage-kms-key": "true" } } } } ``` ------ I clienti possono verificare se le attività non gestite o le attività di servizio sono crittografate utilizzando la chiave utilizzando i AWS CLI `describe-tasks` comandi`describe-cluster`, o`describe-services`. Per ulteriori informazioni sulle chiavi, consulta [Condition keys for AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html) nella [Guida per gli sviluppatori di AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). ------ #### [ Console di gestione AWS ] 1. [Apri la console nella versione 2https://console.aws.amazon.com/ecs/.](https://console.aws.amazon.com/ecs/v2) 1. Scegli **Cluster** nella barra di navigazione a sinistra e **Crea cluster** in alto a destra oppure scegli un cluster esistente. Per un cluster esistente, scegli **Aggiorna cluster** in alto a destra. 1. Nella sezione **Crittografia** del flusso di lavoro, avrai la possibilità di selezionare la tua AWS KMS chiave in **Archiviazione gestita e Archiviazione** **effimera Fargate**. Puoi anche scegliere di **creare una AWS KMS chiave da qui**. 1. Scegli **Crea** una volta terminata la creazione del nuovo cluster o **Aggiorna**, se ne stavi aggiornando uno esistente. ------ #### [ AWS CLI ] Di seguito è riportato un esempio di creazione di un cluster e configurazione dello storage temporaneo Fargate utilizzando (sostituisci AWS CLI *red* i valori con i tuoi): ``` aws ecs create-cluster --cluster clusterName \ --configuration '{"managedStorageConfiguration":{"fargateEphemeralStorageKmsKeyId":"arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"}}' { "cluster": { "clusterArn": "arn:aws:ecs:us-west-2:012345678901:cluster/clusterName", "clusterName": "clusterName", "configuration": { "managedStorageConfiguration": { "fargateEphemeralStorageKmsKeyId": "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } }, "status": "ACTIVE", "registeredContainerInstancesCount": 0, "runningTasksCount": 0, "pendingTasksCount": 0, "activeServicesCount": 0, "statistics": [], "tags": [], "settings": [], "capacityProviders": [], "defaultCapacityProviderStrategy": [] }, "clusterCount": 5 } ``` ------ #### [ CloudFormation ] Di seguito è riportato un modello di esempio per la creazione di un cluster e la configurazione dello storage temporaneo Fargate utilizzando (sostituisci CloudFormation *red* i valori con i tuoi): ``` AWSTemplateFormatVersion: 2010-09-09 Resources: MyCluster: Type: AWS::ECS::Cluster Properties: ClusterName: "clusterName" Configuration: ManagedStorageConfiguration: FargateEphemeralStorageKmsKeyId: "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" ``` ------ # Gestione delle AWS KMS chiavi per lo storage temporaneo Fargate per Amazon ECS Dopo aver creato o importato la AWS KMS chiave per crittografare l'archivio temporaneo Fargate, la gestisci nello stesso modo in cui faresti con qualsiasi altra chiave. AWS KMS **AWS KMS Rotazione automatica dei tasti** Puoi abilitare la rotazione automatica delle chiavi o ruotarle manualmente. La rotazione automatica della chiave ruota la chiave ogni anno generando nuovo materiale crittografico per la chiave. AWS KMS salva anche tutte le versioni precedenti del materiale crittografico, così sarete in grado di decrittografare tutti i dati che utilizzavano le versioni precedenti della chiave. Qualsiasi materiale ruotato non verrà eliminato AWS KMS finché non elimini la chiave. La rotazione automatica della chiave è facoltativa e può essere abilitata o disabilitata in qualsiasi momento. **Disattivazione o revoca delle chiavi AWS KMS** Se disabiliti un accesso con chiave gestita dal cliente AWS KMS, ciò non ha alcun impatto sull'esecuzione delle attività, che continuano a funzionare per tutto il loro ciclo di vita. Se una nuova attività utilizza la chiave disabilitata o revocata, l'attività ha esito negativo poiché non può accedere alla chiave. Dovresti impostare un CloudWatch allarme o qualcosa di simile per assicurarti che non sia mai necessaria una chiave disabilitata per decrittografare i dati già crittografati. **Eliminazione delle chiavi AWS KMS** L'eliminazione delle chiavi dovrebbe sempre essere l'ultima risorsa e deve essere eseguita solo se hai la certezza che la chiave eliminata non sarà più necessaria. Le nuove attività che tentano di utilizzare la chiave eliminata falliranno perché non potranno accedervi. AWS KMS consiglia di disabilitare una chiave anziché eliminarla. Se ritieni necessario eliminare una chiave, ti consigliamo di disabilitarla prima e di impostare un CloudWatch allarme per assicurarti che non sia necessaria. Se elimini una chiave, hai AWS KMS a disposizione almeno sette giorni per cambiare idea. **Controllo dell'accesso alle AWS KMS chiavi** Puoi utilizzare CloudTrail i log per controllare l'accesso alla tua AWS KMS chiave. Puoi controllare le AWS KMS operazioni `CreateGrant` `GenerateDataKeyWithoutPlaintext` e`Decrypt`. Queste operazioni mostrano anche il `aws:ecs:clusterAccount` e `aws:ecs:clusterName` come parte dell'`EncryptionContext`accesso. CloudTrail Di seguito sono riportati CloudTrail gli eventi di esempio per `GenerateDataKeyWithoutPlaintext``GenerateDataKeyWithoutPlaintext (DryRun)`,`CreateGrant`,`CreateGrant (DryRun)`, e `RetireGrant` (sostituisci i *red* valori con i tuoi). ------ #### [ GenerateDataKeyWithoutPlaintext ] ``` { "eventVersion": "1.08", "userIdentity": { "type": "AWSService", "invokedBy": "ec2-frontend-api.amazonaws.com" }, "eventTime": "2024-04-23T18:08:13Z", "eventSource": "kms.amazonaws.com", "eventName": "GenerateDataKeyWithoutPlaintext", "awsRegion": "us-west-2", "sourceIPAddress": "ec2-frontend-api.amazonaws.com", "userAgent": "ec2-frontend-api.amazonaws.com", "requestParameters": { "numberOfBytes": 64, "keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "encryptionContext": { "aws:ecs:clusterAccount": "account-id", "aws:ebs:id": "vol-xxxxxxx", "aws:ecs:clusterName": "cluster-name" } }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "account-id", "sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventCategory": "Management" } ``` ------ #### [ GenerateDataKeyWithoutPlaintext (DryRun) ] ``` { "eventVersion": "1.08", "userIdentity": { "type": "AWSService", "invokedBy": "fargate.amazonaws.com" }, "eventTime": "2024-04-23T18:08:11Z", "eventSource": "kms.amazonaws.com", "eventName": "GenerateDataKeyWithoutPlaintext", "awsRegion": "us-west-2", "sourceIPAddress": "fargate.amazonaws.com", "userAgent": "fargate.amazonaws.com", "errorCode": "DryRunOperationException", "errorMessage": "The request would have succeeded, but the DryRun option is set.", "requestParameters": { "keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "dryRun": true, "numberOfBytes": 64, "encryptionContext": { "aws:ecs:clusterAccount": "account-id", "aws:ecs:clusterName": "cluster-name" } }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "account-id", "sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventCategory": "Management" } ``` ------ #### [ CreateGrant ] ``` { "eventVersion": "1.08", "userIdentity": { "type": "AWSService", "invokedBy": "ec2-frontend-api.amazonaws.com" }, "eventTime": "2024-04-23T18:08:13Z", "eventSource": "kms.amazonaws.com", "eventName": "CreateGrant", "awsRegion": "us-west-2", "sourceIPAddress": "ec2-frontend-api.amazonaws.com", "userAgent": "ec2-frontend-api.amazonaws.com", "requestParameters": { "keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "granteePrincipal": "fargate.us-west-2.amazonaws.com", "operations": [ "Decrypt" ], "constraints": { "encryptionContextSubset": { "aws:ecs:clusterAccount": "account-id", "aws:ebs:id": "vol-xxxx", "aws:ecs:clusterName": "cluster-name" } }, "retiringPrincipal": "ec2.us-west-2.amazonaws.com" }, "responseElements": { "grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333", "readOnly": false, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "account-id", "sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventCategory": "Management" } ``` ------ #### [ CreateGrant (DryRun) ] ``` { "eventVersion": "1.08", "userIdentity": { "type": "AWSService", "invokedBy": "fargate.amazonaws.com" }, "eventTime": "2024-04-23T18:08:11Z", "eventSource": "kms.amazonaws.com", "eventName": "CreateGrant", "awsRegion": "us-west-2", "sourceIPAddress": "fargate.amazonaws.com", "userAgent": "fargate.amazonaws.com", "errorCode": "DryRunOperationException", "errorMessage": "The request would have succeeded, but the DryRun option is set.", "requestParameters": { "keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "granteePrincipal": "fargate.us-west-2.amazonaws.com", "dryRun": true, "operations": [ "Decrypt" ], "constraints": { "encryptionContextSubset": { "aws:ecs:clusterAccount": "account-id", "aws:ecs:clusterName": "cluster-name" } } }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333", "readOnly": false, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "account-id", "sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventCategory": "Management" } ``` ------ #### [ RetireGrant ] ``` { "eventVersion": "1.08", "userIdentity": { "type": "AWSService", "invokedBy": "AWS Internal" }, "eventTime": "2024-04-20T18:37:38Z", "eventSource": "kms.amazonaws.com", "eventName": "RetireGrant", "awsRegion": "us-west-2", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": null, "responseElements": { "keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }, "additionalEventData": { "grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" }, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333", "readOnly": false, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "account-id", "sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventCategory": "Management" } ``` ------ # Ritiro e manutenzione delle attività per AWS Fargate su Amazon ECS AWS è responsabile della manutenzione dell'infrastruttura sottostante per AWS Fargate. AWS determina quando una revisione della versione della piattaforma deve essere sostituita con una nuova revisione dell'infrastruttura. Questa operazione è nota come ritiro delle attività. AWS invia una notifica di ritiro dell'attività quando viene ritirata una revisione della versione della piattaforma. Aggiorniamo regolarmente le versioni della piattaforma supportate per introdurre una nuova revisione contenente aggiornamenti al software runtime di Fargate e alle dipendenze sottostanti come il sistema operativo e il runtime del container. Dopo aver reso disponibile una revisione più recente, ritiriamo la versione precedente per garantire che tutti i carichi di lavoro dei clienti vengano eseguiti sulla revisione più aggiornata della versione della piattaforma di Fargate. Quando una revisione viene ritirata, tutte le attività in esecuzione su di essa vengono interrotte. Le attività di Amazon ECS possono essere classificate come attività di servizio o come attività autonome. Le attività del servizio sono implementate nell'ambito di un servizio e controllate dalla pianificazione di Amazon ECS. Per ulteriori informazioni, consulta [Servizi Amazon ECS](ecs_services.md). Le attività autonome sono attività avviate dall'`RunTask`API Amazon ECS, direttamente o da uno scheduler esterno, come le attività pianificate (che vengono avviate da Amazon EventBridge), AWS Batch oppure. AWS Step Functions Non devi effettuare alcuna operazione in risposta al ritiro delle attività di servizio poiché il pianificatore di Amazon ECS sostituisce automaticamente le attività. Per le attività autonome, potrebbe essere necessario eseguire una gestione aggiuntiva in risposta al ritiro delle attività. Per ulteriori informazioni, consulta [Amazon ECS può gestire automaticamente le attività autonome?](#task-retirement-standalone-tasks). Per le attività di servizio, non è necessario intraprendere alcuna azione per ritirarle, a meno che non si desideri sostituirle prima dell'esecuzione. AWS Quando il pianificatore di Amazon ECS arresta le attività, quest'ultimo utilizza `maximumPercent` e avvia nuove attività nel tentativo di mantenere il numero di servizi desiderato. Segui le best practice per ridurre al minimo l'impatto del ritiro delle attività. Il valore predefinito `maximumPercent` per un servizio che utilizza il pianificatore di servizi REPLICA è del 200%. Pertanto, quando AWS Fargate inizia a ritirare le attività, Amazon ECS pianifica prima una nuova attività e quindi attende che sia in esecuzione, prima di ritirare una vecchia attività. Quando imposti il valore `maximumPercent` al 100%, Amazon ECS arresta prima l'attività, quindi la sostituisce. Per il ritiro di un'attività autonoma, AWS interrompe l'attività alla o dopo la data di ritiro dell'attività. Amazon ECS non avvia un'attività sostitutiva quando un'attività viene interrotta. Se hai bisogno che queste attività continuino a essere eseguite, devi arrestare le attività in esecuzione e avviarne una sostitutiva prima del tempo indicato nella notifica. Pertanto, consigliamo ai clienti di monitorare lo stato delle attività autonome e, se necessario, di implementare una logica per sostituire quelle interrotte. Quando un'attività viene interrotta in uno degli scenari seguenti, puoi eseguire il comando `describe-tasks`. Il `stoppedReason` nella risposta è `ECS is performing maintenance on the underlying infrastructure hosting the task`. La manutenzione delle attività viene applicata quando una revisione della versione della piattaforma deve essere sostituita con una nuova. In caso di problemi con un host Fargate sottostante, Amazon ECS sostituisce l'host senza un avviso di ritiro delle attività. ## Panoramica sull'avviso di ritiro delle attività Quando AWS contrassegna una revisione della versione della piattaforma come da ritirare, identifichiamo tutte le attività in esecuzione su quella revisione della versione della piattaforma in tutte le regioni. La figura seguente mostra il ciclo di vita di una revisione della versione della piattaforma di Fargate, dall'avvio di una nuova revisione al ritiro della versione della piattaforma. ![\[Diagramma che mostra il ciclo di vita del ritiro delle attività di Fargate.\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/images/fargate-task-retirement.png) Le seguenti informazioni forniscono dettagli. + Dopo l'avvio di una nuova revisione della versione della piattaforma, tutte le nuove attività vengono pianificate in base a tale revisione. + Le attività esistenti che sono state pianificate e in esecuzione rimangono nella revisione in cui erano state originariamente inserite per tutta la durata dell'attività e non vengono migrate a quella nuova. + Le nuove attività, ad esempio come parte di un aggiornamento di un servizio o del ritiro delle attività di Fargate, vengono inserite nell'ultima versione della piattaforma disponibile al momento dell'avvio. Le notifiche di ritiro delle attività vengono inviate tramite AWS Health Dashboard e tramite e-mail all'indirizzo e-mail registrato e includono le seguenti informazioni: + Data di ritiro dell'attività: l'attività viene interrotta a partire da questa data. + Per le attività autonome, IDs le attività. + Per le attività di servizio, l'ID del cluster in cui viene eseguito il servizio e il IDs nome del servizio. + I passaggi successivi da eseguire. In genere, inviamo una notifica per ciascuna attività del servizio e attività autonome in ogni Regione AWS. Tuttavia, in alcuni casi potresti ricevere più di un evento per ogni tipo di attività, ad esempio quando ci sono troppe attività per essere ritirate e superano i limiti previsti dai nostri meccanismi di notifica. Puoi identificare le attività pianificate per il ritiro nei modi seguenti: + Il Health Dashboard AWS Health le notifiche possono essere inviate tramite Amazon EventBridge a sistemi di archiviazione come Amazon Simple Storage Service, eseguire azioni automatiche come eseguire una AWS Lambda funzione o altri sistemi di notifica come Amazon Simple Notification Service. Per ulteriori informazioni, consulta [Monitoraggio AWS Health degli eventi con Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). Per una configurazione di esempio per inviare notifiche ad Amazon Chime, Slack o Microsoft Teams, consulta l'archivio [AWS Health Aware](https://github.com/aws-samples/aws-health-aware) su. GitHub Di seguito è riportato un esempio di evento. EventBridge ``` { "version": "0", "id": "3c268027-f43c-0171-7425-1d799EXAMPLE", "detail-type": "AWS Health Event", "source": "aws.health", "account": "123456789012", "time": "2023-08-16T23:18:51Z", "region": "us-east-1", "resources": [ "cluster|service", "cluster|service" ], "detail": { "eventArn": "arn:aws:health:us-east-1::event/ECS/AWS_ECS_TASK_PATCHING_RETIREMENT/AWS_ECS_TASK_PATCHING_RETIREMENT_test1", "service": "ECS", "eventScopeCode": "ACCOUNT_SPECIFIC", "communicationId": "7988399e2e6fb0b905ddc88e0e2de1fd17e4c9fa60349577446d95a18EXAMPLE", "lastUpdatedTime": "Wed, 16 Aug 2023 23:18:52 GMT", "eventRegion": "us-east-1", "eventTypeCode": "AWS_ECS_TASK_PATCHING_RETIREMENT", "eventTypeCategory": "scheduledChange", "startTime": "Wed, 16 Aug 2023 23:18:51 GMT", "endTime": "Fri, 18 Aug 2023 23:18:51 GMT", "eventDescription": [ { "language": "en_US", "latestDescription": "\\nA software update has been deployed to Fargate which includes CVE patches or other critical patches. No action is required on your part. All new tasks launched automatically uses the latest software version. For existing tasks, your tasks need to be restarted in order for these updates to apply. Your tasks running as part of the following ECS Services will be automatically updated beginning Wed, 16 Aug 2023 23:18:51 GMT.\\n\\nAfter Wed, 16 Aug 2023 23:18:51 GMT, the ECS scheduler will gradually replace these tasks, respecting the deployment settings for your service. Typically, services should see little to no interruption during the update and no action is required. When AWS stops tasks, AWS uses the minimum healthy percent (1) and launches a new task in an attempt to maintain the desired count for the service. By default, the minimum healthy percent of a service is 100 percent, so a new task is started first before a task is stopped. Service tasks are routinely replaced in the same way when you scale the service or deploy configuration changes or deploy task definition revisions. If you would like to control the timing of this restart you can update the service before Wed, 16 Aug 2023 23:18:51 GMT, by running the update-service command from the ECS command-line interface specifying force-new-deployment for services using Rolling update deployment type. For example:\\n\\n$ aws ecs update-service -service service_name \\\n--cluster cluster_name -force-new-deployment\\n\\nFor services using Blue/Green deployment type with AWS CodeDeploy:\\nPlease refer to create-deployment document (2) and create new deployment using same task definition revision.\\n\\nFor further details on ECS deployment types, please refer to ECS Deployment Developer Guide (1).\\nFor further details on Fargate's update process, please refer to the AWS Fargate User Guide (3).\\nIf you have any questions or concerns, please contact AWS Support (4).\\n\\n(1) https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html\\n(2) https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html\\n(3) https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-maintenance.html\\n(4) https://aws.amazon.com/support\\n\\nA list of your affected resources(s) can be found in the 'Affected resources' tab in the 'Cluster/ Service' format in the AWS Health Dashboard. \\n\\n" } ], "affectedEntities": [ { "entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c23333" }, { "entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c25555" } } ] } } ``` + Email Viene inviata un'e-mail all'indirizzo di posta elettronica registrato per l' Account AWS ID. Per informazioni su come preparare il ritiro delle attività, consulta [Preparati per il ritiro delle attività di AWS Fargate su Amazon ECS](prepare-task-retirement.md). ## Posso disabilitare il ritiro delle attività? No. Come parte del modello di responsabilità AWS condivisa, AWS è responsabile della gestione e della manutenzione dell'infrastruttura sottostante per AWS Fargate. Ciò include l'esecuzione di aggiornamenti periodici della piattaforma per garantire sicurezza e stabilità. Questi aggiornamenti vengono applicati automaticamente dai clienti AWS e non possono essere disattivati. Questo è uno dei vantaggi principali dell'utilizzo di a AWS Fargate rispetto all'esecuzione dei carichi di lavoro su istanze EC2, la responsabilità della manutenzione della piattaforma sottostante è gestita da. AWS In questo modo, puoi concentrarti sulle applicazioni, piuttosto che sulla manutenzione dell'infrastruttura. Applicando automaticamente questi aggiornamenti della piattaforma, AWS è in grado di mantenere l'ambiente Fargate sicuro up-to-date e protetto, senza che sia richiesta alcuna azione da parte dell'utente in qualità di cliente. Questo aiuta a fornire un ambiente containerizzato affidabile e sicuro per l'esecuzione dei carichi di lavoro su Fargate. ## Posso ricevere notifiche di ritiro delle attività tramite altri AWS servizi? AWS invia una notifica di ritiro dell'attività al Health Dashboard e al contatto di posta elettronica principale su. Account AWS Health Dashboard Fornisce una serie di integrazioni in altri AWS servizi, tra cui. EventBridge È possibile EventBridge utilizzarlo per automatizzare la visibilità degli avvisi (ad esempio inoltrando il messaggio a uno strumento). ChatOps Per ulteriori informazioni, consulta [Solution overview: Capturing task retirement notifications](https://aws.amazon.com/blogs/containers/improving-operational-visibility-with-aws-fargate-task-retirement-notifications/). ## Posso modificare il ritiro di un'attività dopo averla pianificata? No. La pianificazione si basa sul tempo di attesa per il ritiro dell'attività, che ha un valore predefinito di 7 giorni. Se hai bisogno di più tempo, puoi estendere il periodo di attesa a 14 giorni. Per ulteriori informazioni, consulta [Fase 2: registrazione delle notifiche di ritiro delle attività per avvisare i team ed effettuare azioni](prepare-task-retirement.md#prepare-task-retirement-capture-task-events). A partire dal 18/12/2025, Amazon ECS ti consente di configurare le finestre degli [eventi di Amazon EC2 per le attività di Fargate](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html). Se hai bisogno di un controllo preciso sulla tempistica esatta del ritiro delle attività, ad esempio programmandole durante i fine settimana per evitare interruzioni durante l'orario lavorativo, puoi configurare le finestre degli eventi di Amazon EC2 per le tue attività, servizi o cluster, vedi. [Passaggio 1: imposta il tempo di attesa dell'attività o utilizza le finestre degli eventi di Amazon EC2](prepare-task-retirement.md#prepare-task-retirement-set-time) Tieni presente che la modifica di questa configurazione si applica ai pensionamenti che verranno programmati in futuro. I ritiri attualmente pianificati non sono influenzati. Inoltre, quando configuri una finestra di eventi di Amazon EC2 per le attività di Fargate, questa ha la precedenza sulla configurazione del tempo di attesa per il ritiro delle attività. Se hai ulteriori dubbi, contatta. Supporto ## In che modo Amazon ECS gestisce le attività che fanno parte di un servizio? Per le attività di servizio, non è necessario intraprendere alcuna azione in risposta al ritiro dell'attività, a meno che non si desideri sostituire tali attività prima dell' AWS esecuzione. Quando il pianificatore di Amazon ECS arresta le attività, quest'ultimo utilizza la percentuale minima di integrità e avvia nuove attività nel tentativo di mantenere il numero di servizi desiderato. Per ridurre al minimo l'impatto del ritiro delle attività di Fargate, i carichi di lavoro devono essere implementati seguendo le best practice di Amazon ECS. Ad esempio, quando distribuiscono un'applicazione stateless come servizio Amazon ECS, come un server Web o API, i clienti devono distribuire più repliche di attività e impostarle al 100%. minimumHealthyPercent Il valore predefinito per la percentuale minima di integrità di un servizio è il 100%. Pertanto, quando Fargate inizia a ritirare le attività, Amazon ECS pianifica una nuova attività e attende che sia in esecuzione, prima di ritirarne una vecchia. Le attività del servizio vengono sostituite regolarmente come parte del ritiro delle attività allo stesso modo quando dimensioni il servizio, implementi le modifiche alla configurazione o le revisioni di definizioni delle attività. Per preparare il processo di ritiro delle attività, consulta [Preparati per il ritiro delle attività di AWS Fargate su Amazon ECS](prepare-task-retirement.md). ## Amazon ECS può gestire automaticamente le attività autonome? No. AWS non può creare un'attività sostitutiva per attività autonome avviate da`RunTask`, attività pianificate (ad esempio tramite EventBridge Scheduler) o. AWS Batch AWS Step Functions Amazon ECS gestisce solo le attività che fanno parte di un servizio. ## Risoluzione dei problemi relativi alla disponibilità del servizio durante il ritiro delle attività Se Amazon ECS non è in grado di avviare un'attività sostitutiva durante il ritiro delle attività, la disponibilità del servizio potrebbe risentirne. Ciò può verificarsi a causa di una configurazione errata del cliente, ad esempio: + Ruoli IAM mancanti o configurati in modo non corretto + Capacità insufficiente nelle sottoreti di destinazione + Configurazioni errate del gruppo di sicurezza + Errori nelle definizioni delle attività Quando Amazon ECS non è in grado di avviare attività sostitutive, le attività ritirate vengono arrestate senza sostituzioni, riducendo la capacità disponibile del servizio e causando potenzialmente interruzioni del servizio. Monitora il numero di attività del tuo servizio e i CloudWatch parametri di Amazon per assicurarti che le attività sostitutive vengano lanciate con successo durante gli eventi di pensionamento. # Preparati per il ritiro delle attività di AWS Fargate su Amazon ECS Per preparare il ritiro delle attività, esegui le seguenti operazioni: 1. Imposta il periodo di attesa per il ritiro dell'attività o utilizza le finestre degli eventi di Amazon EC2. 1. Registra le notifiche di ritiro delle attività per avvisare i membri del team. 1. Puoi assicurarti che tutte le attività dei tuoi servizi vengano eseguite sulla versione più recente della piattaforma aggiornando il servizio con l'opzione di implementazione forzata. Questa fase è facoltativa. ## Passaggio 1: imposta il tempo di attesa dell'attività o utilizza le finestre degli eventi di Amazon EC2 Sono disponibili due opzioni di impostazione dell'account per configurare l'ora in cui Fargate avvia il ritiro delle attività: e. `fargateTaskRetirementWaitPeriod` `fargateEventWindows` **Utilizzo delle impostazioni dell'account fargateTaskRetirement WaitPeriod ** Puoi configurare l'ora in cui Fargate avvia il ritiro dell'attività. Il periodo di attesa predefinito è di 7 giorni. Per i carichi di lavoro che richiedono l'applicazione immediata degli aggiornamenti, scegli l'impostazione immediata (`0`). Se hai bisogno di più tempo, configura l'opzione`7`, o `14` day. Consigliamo di scegliere un periodo di attesa più breve per ricevere prima le revisioni delle versioni più recenti della piattaforma. Configura il periodo di attesa eseguendo `put-account-setting-default` o `put-account-setting` come utente root o utente amministrativo. Utilizza l'opzione `fargateTaskRetirementWaitPeriod` per il `name` e l'opzione `value` impostata su uno dei seguenti valori: + `0`- AWS invia la notifica e inizia immediatamente a ritirare le attività interessate. + `7`- AWS invia la notifica e attende 7 giorni di calendario prima di iniziare a ritirare le attività interessate. Questa è l’impostazione predefinita. + `14`: AWS invia la notifica e attende 14 giorni di calendario prima di iniziare a ritirare le attività interessate. Per ulteriori informazioni, consulta [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)e consulta il *riferimento [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)all'API di Amazon Elastic Container Service*. **Utilizzo fargateEventWindows delle impostazioni dell'account** A partire dal 18/12/2025, Amazon ECS ti consente di configurare le finestre degli [eventi di Amazon EC2 per le attività di Fargate](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html). Se hai bisogno di un controllo preciso sulla tempistica esatta del ritiro delle attività, ad esempio programmandole durante i fine settimana per evitare interruzioni durante l'orario lavorativo, puoi configurare le finestre degli eventi di Amazon EC2 per le tue attività, i tuoi servizi o i tuoi cluster. Quando si utilizzano le finestre degli eventi, Fargate assicura che le attività vengano eseguite per almeno 3 giorni prima di essere ritirate entro la finestra successiva disponibile, a meno che non vengano interrotte da azioni avviate dall'utente o da eventi critici di salute come il degrado dell'hardware sottostante. Impostare le impostazioni dell'account `fargateEventWindows` su `enabled`. È possibile utilizzare uno dei seguenti APIs: `put-account-setting-default` o `put-account-setting` come utente root o utente amministrativo. Ogni finestra di eventi di Amazon EC2 deve essere aperta per almeno 4 ore a settimana e ogni intervallo di tempo deve essere lungo almeno 2 ore. Per cluster e servizi di grandi dimensioni, consigliamo di configurare finestre di eventi con durate lunghe (8 ore o più) o intervalli di tempo più frequenti che si verificano almeno una volta ogni 3 giorni. Puoi esaminare ulteriormente le considerazioni relative alle finestre degli eventi di Amazon EC2 nella AWS Fargate guida per [l'utente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html#event-windows-considerations), per assicurarti che le attività vengano eseguite per almeno 3 giorni prima di essere ritirate, a meno che non vengano interrotte da azioni avviate dall'utente o da eventi critici di salute come il degrado dell'hardware sottostante. **Importante** La sostituzione delle attività all'interno della finestra degli eventi è la soluzione migliore. Se noti che le attività vengono ritirate al di fuori delle finestre degli eventi, valuta la possibilità di aumentare la durata (8 ore o più) o di aumentare la frequenza (almeno una volta ogni 3 giorni). Per applicare le finestre degli eventi di Amazon EC2 ai ritiri delle attività Fargate: + Impostare le impostazioni dell'account `fargateEventWindows` su `enabled`. Puoi utilizzare uno dei seguenti APIs: `put-account-setting-default` o `put-account-setting` come utente root o utente amministrativo. Tieni presente che si tratta di un'attivazione unica per l'utilizzo della funzionalità delle finestre degli eventi di Amazon EC2 per le tue attività su Fargate. + Crea una finestra di eventi Amazon EC2 tramite la console AWS o l'AWS CLI. Per creare una finestra di eventi utilizzando la CLI, usa l'`create-instance-event-window`API EC2 con intervalli di tempo o espressioni cron. Prendi nota della risposta`InstanceEventWindowId`. ``` aws ec2 create-instance-event-window \ --time-range StartWeekDay=monday,StartHour=2,EndWeekDay=wednesday,EndHour=8 \ --tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \ --name myEventWindowName ``` In alternativa, puoi usare le espressioni cron durante la creazione di finestre di eventi EC2. ``` aws ec2 create-instance-event-window \ --cron-expression "* 21-23 * * 2,3" \ --tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \ --name myEventWindowName ``` + Puoi quindi associare la finestra dell'evento a servizi specifici, cluster o a tutte le attività del tuo account utilizzando l'API EC2. `associate-instance-event-window` + Per le attività di servizio ECS ``` aws ec2 associate-instance-event-window \ --instance-event-window-id iew-0abcdef1234567890 \ --association-target "InstanceTags=[{Key=aws:ecs:serviceArn,Value=your-service-arn}]" ``` + Per i cluster ECS ``` aws ec2 associate-instance-event-window \ --instance-event-window-id iew-0abcdef1234567890 \ --association-target "InstanceTags=[{Key=aws:ecs:clusterArn,Value=your-cluster-arn}]" ``` + Per associare una finestra dell'evento a tutte le attività dell'account ``` aws ec2 associate-instance-event-window \ --instance-event-window-id iew-0abcdef1234567890 \ --association-target "InstanceTags=[{Key=aws:ecs:fargateTask,Value=true}]" ``` È possibile utilizzare più di una coppia chiave-valore per associare una finestra dell'evento a più servizi o cluster. Fargate sceglierà la finestra dell'evento per ogni attività nel seguente ordine: + Se è presente una finestra di eventi associata al servizio dell'attività, verrà utilizzata. Questo non è applicabile alle attività autonome o non gestite. + Se è presente una finestra di eventi associata al cluster dell'attività, verrà utilizzata. + Se è impostata una finestra di eventi per tutte le attività di Fargate, verrà utilizzata. + L'`fargateTaskRetirementWaitPeriod`impostazione verrà utilizzata se nessuna delle finestre degli eventi corrisponde all'attività. **Configurazione delle finestre degli eventi per la manutenzione delle attività di Fargate** Prendi in considerazione un caso in cui esegui più servizi ECS su Fargate con requisiti di disponibilità diversi. Desiderate un controllo preciso sulla cessazione delle attività. È possibile configurare più finestre di eventi come segue: + **Manutenzione predefinita per tutte le attività Fargate**: create una finestra evento per la manutenzione ordinaria durante le ore non di punta (tutti i giorni dalle 12:00 alle 4:00) e associatela a tutte le attività Fargate utilizzando il tag. ` aws:ecs:fargateTask` + **Manutenzione solo nel fine settimana per il cluster di sviluppo**: per un cluster di sviluppo con servizi in grado di tollerare interruzioni nei fine settimana, crea una finestra di 24 ore per il fine settimana (sabato e domenica, tutto il giorno) e associala al cluster utilizzando il tag con l'ARN del `aws:ecs:clusterArn` cluster. + **Intervallo limitato per il servizio mission critical: per un servizio** di elaborazione dei pagamenti di importanza critica che richiede un'elevata operatività durante i giorni feriali, limita la manutenzione alle prime ore mattutine del fine settimana (sabato e domenica, dalle 00:00 alle 04:00) e associala al servizio specifico utilizzando il tag con l'ARN del servizio. `aws:ecs:serviceArn` Con questa configurazione, il servizio di pagamento utilizza la sua finestra specifica solo per il fine settimana, i servizi e le attività del cluster di sviluppo utilizzano la finestra di 24 ore del fine settimana e tutte le altre attività di Fargate utilizzano la finestra di manutenzione giornaliera predefinita. Per ulteriori informazioni, consulta [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)e consulta il *riferimento [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)all'API di Amazon Elastic Container Service*. ## Fase 2: registrazione delle notifiche di ritiro delle attività per avvisare i team ed effettuare azioni Quando è imminente il ritiro di un'attività, AWS invia una notifica di ritiro dell'attività alla AWS Health Dashboard e al contatto e-mail principale su. Account AWS La AWS Health dashboard offre una serie di integrazioni in altri AWS servizi, tra cui Amazon EventBridge. Puoi utilizzarla EventBridge per creare automazioni a partire da una notifica di ritiro di un'attività, ad esempio per aumentare la visibilità del pensionamento imminente inoltrando il messaggio a uno strumento. ChatOps AWS Health Aware è una risorsa che mostra la potenza della AWS Health Dashboard e come le notifiche possono essere distribuite all'interno di un'organizzazione. Puoi inoltrare una notifica di ritiro delle attività a un'applicazione di chat, come Slack. La figura seguente illustra la panoramica della soluzione. ![\[Diagramma che mostra la soluzione Fargate per registrare gli avvisi di ritiro delle attività di Fargate.\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/images/fargate-task-retirement-solution.png) Le seguenti informazioni forniscono dettagli. + Fargate invia la notifica di ritiro dell'attività a Dashboard AWS Health . + La AWS Health Dashboard invia la posta elettronica al contatto di posta elettronica principale su e notifica. Account AWS EventBridge + EventBridge ha una regola che registra la notifica di pensionamento. La regola che cerca eventi con il tipo di dettagli dell'evento: `"AWS Health Event" and the Event Detail Type Code: "AWS_ECS_TASK_PATCHING_RETIREMENT"` + La regola attiva una funzione Lambda che inoltra le informazioni a Slack utilizzando un webhook in ingresso di Slack. Per ulteriori informazioni, consulta [Webhook in ingresso](https://slack.com/marketplace/A0F7XDUAZ-incoming-webhooks). Per un esempio di codice, vedi [Acquisizione delle notifiche di ritiro delle AWS Fargate attività su Github](https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications/tree/main). ## Fase 3: controllo della sostituzione delle attività Non puoi controllare l'ora esatta del ritiro di un'attività, tuttavia puoi definire un tempo di attesa. Se desideri controllare la sostituzione delle attività in base alla tua pianificazione, puoi registrare l'avviso di ritiro delle attività per comprendere innanzitutto la data di ritiro. Quindi, puoi implementare nuovamente il servizio per avviare attività sostitutive e, allo stesso modo, sostituire qualsiasi attività autonoma. Per i servizi che utilizzano l'implementazione progressiva, è possibile aggiornare il servizio utilizzando `update-service` con l'opzione `force-deployment` prima dell'inizio del ritiro. Nell'esempio `update-service` seguente viene utilizzata l'opzione `force-deployment`. ``` aws ecs update-service —-service service_name \ --cluster cluster_name \ --force-new-deployment ``` Per i servizi che utilizzano la blue/green distribuzione, è necessario creare una nuova distribuzione in. AWS CodeDeploy Per informazioni su come creare l'implementazione, consulta [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) nella *Guida di riferimento di AWS Command Line Interface *. # Regioni supportate per Amazon ECS su Fargate AWS È possibile utilizzare le seguenti tabelle per verificare il supporto regionale per i contenitori Linux su AWS Fargate e i contenitori Windows su AWS Fargate. ## Contenitori Linux su AWS Fargate I contenitori Amazon ECS Linux su AWS Fargate sono supportati nei seguenti Regioni AWS casi. Le zone di disponibilità supportate IDs vengono indicate quando applicabile. | Nome della regione | Regione | | --- | --- | | US East (Ohio) | us-east-2 | | US East (N. Virginia) | us-east-1 | | Stati Uniti occidentali (California settentrionale) | us-west-1 (solo `usw1-az1` e `usw1-az3`) | | Stati Uniti occidentali (Oregon) | us-west-2 | | Canada (Centrale) | ca-central-1 | | Canada occidentale (Calgary) | ca-west-1 | | Messico (centrale) | mx-central-1 | | Africa (Città del Capo) | af-south-1 | | Asia Pacific (Hong Kong) | ap-east-1 | | Asia Pacifico (Mumbai) | ap-south-1 | | Asia Pacifico (Tokyo) | ap-northeast-1 (solo `apne1-az1`, `apne1-az2` e `apne1-az4`) | | Asia Pacific (Seoul) | ap-northeast-2 | | Asia Pacifico (Osaka-Locale) | ap-northeast-3 | | Asia Pacifico (Hyderabad) | ap-south-2 | | Asia Pacifico (Singapore) | ap-southeast-1 | | Asia Pacific (Sydney) | ap-southeast-2 | | Asia Pacifico (Thailandia) | ap-southeast-7 | | Asia Pacifico (Giacarta) | ap-southeast-3 | | Asia Pacifico (Melbourne) | ap-southeast-4 | | Asia Pacifico (Malesia) | ap-southeast-5 | | Canada (Centrale) | ca-central-1 | | Canada occidentale (Calgary) | ca-west-1 | | Cina (Pechino) | cn-north-1 (solo `cnn1-az1` e `cnn1-az2`) | | China (Ningxia) | cn-northwest-1 | | Europe (Frankfurt) | eu-central-1 | | Europa (Zurigo) | eu-central-2 | | Europa (Irlanda) | eu-west-1 | | Europe (London) | eu-west-2 | | Europe (Paris) | eu-west-3 | | Europe (Milan) | eu-south-1 | | Europa (Spagna) | eu-south-2 | | Europa (Stoccolma) | eu-north-1 | | South America (São Paulo) | sa-east-1 | | Israele (Tel Aviv) | il-central-1 | | Medio Oriente (Bahrein) | me-south-1 | | Medio Oriente (Emirati Arabi Uniti) | me-central-1 | | AWS GovCloud (Stati Uniti orientali) | us-gov-east-1 | | AWS GovCloud (Stati Uniti occidentali) | us-gov-west-1 | ## Contenitori Windows su AWS Fargate I contenitori Amazon ECS Windows attivi AWS Fargate sono supportati nei seguenti Regioni AWS casi. Le zone di disponibilità supportate IDs vengono indicate quando applicabile. | Nome della regione | Regione | | --- | --- | | US East (Ohio) | us-east-2 | | Stati Uniti orientali (Virginia settentrionale) | us-east-1 (solo `use1-az1`, `use1-az2`, `use1-az4`, `use1-az5` e `use1-az6`) | | Stati Uniti occidentali (California settentrionale) | us-west-1 (solo `usw1-az1` e `usw1-az3`) | | Stati Uniti occidentali (Oregon) | us-west-2 | | Africa (Città del Capo) | af-south-1 | | Asia Pacific (Hong Kong) | ap-east-1 | | Asia Pacifico (Mumbai) | ap-south-1 | | Asia Pacifico (Hyderabad) | ap-south-2 | | Asia Pacifico (Osaka-Locale) | ap-northeast-3 | | Asia Pacifico (Seoul) | ap-northeast-2 | | Asia Pacific (Singapore) | ap-southeast-1 | | Asia Pacific (Sydney) | ap-southeast-2 | | Asia Pacifico (Melbourne) | ap-southeast-4 | | Asia Pacifico (Malesia) | ap-southeast-5 | | Asia Pacifico (Tokyo) | ap-northeast-1 (solo `apne1-az1`, `apne1-az2` e `apne1-az4`) | | Canada (Centrale) | ca-central-1 (solo `cac1-az1` e `cac1-az2`) | | Canada occidentale (Calgary) | ca-west-1 | | Cina (Pechino) | cn-north-1 (solo `cnn1-az1` e `cnn1-az2`) | | China (Ningxia) | cn-northwest-1 | | Europe (Frankfurt) | eu-central-1 | | Europa (Zurigo) | eu-central-2 | | Europa (Irlanda) | eu-west-1 | | Europe (London) | eu-west-2 | | Europe (Paris) | eu-west-3 | | Europe (Milan) | eu-south-1 | | Europa (Spagna) | eu-south-2 | | Europa (Stoccolma) | eu-north-1 | | South America (São Paulo) | sa-east-1 | | Israele (Tel Aviv) | il-central-1 | | Medio Oriente (Emirati Arabi Uniti) | me-central-1 | | Medio Oriente (Bahrein) | me-south-1 |