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à.
# Utilizzo della piattaforma Windows Elastic Beanstalk .NET
Questo argomento descrive come configurare, creare ed eseguire le applicazioni Web ASP.NET e.NET Core Windows su Elastic Beanstalk.
AWS Elastic Beanstalk supporta diverse piattaforme per diverse versioni del framework di programmazione .NET e di Windows Server. Consulta la sezione relativa a [.NET su Windows Server con IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) nel documento sulle *piattaforme AWS Elastic Beanstalk * per un elenco completo.
Elastic [Beanstalk offre](command-options.md) opzioni di configurazione che puoi utilizzare per personalizzare il software che viene eseguito EC2 sulle istanze nell'ambiente Elastic Beanstalk. Puoi configurare le variabili di ambiente necessarie all'applicazione, attivare la rotazione dei log in Amazon S3 e configurare le impostazioni del framework .NET.
Sono disponibili opzioni di configurazione specifiche della piattaforma nella console Elastic Beanstalk per la [modifica della configurazione di un ambiente in esecuzione](environment-configuration-methods-after.md). Per conservare la configurazione dell'ambiente una volta terminata, puoi utilizzare [configurazioni salvate](environment-configuration-savedconfig.md) per salvare le impostazioni e applicarle successivamente a un altro ambiente.
Per salvare le impostazioni nel codice sorgente, puoi includere i [file di configurazione](ebextensions.md). Le impostazioni nei file di configurazione vengono applicate ogni volta che crei un ambiente o distribuisci l'applicazione. Puoi inoltre utilizzare i file di configurazione per installare pacchetti, eseguire script o altre operazioni di personalizzazione delle istanze durante le distribuzioni.
Le impostazioni applicate nella console Elastic Beanstalk sostituiscono le stesse impostazioni nei file di configurazione, se esistenti. Ciò ti consente di disporre di impostazioni predefinite nei file di configurazione, sostituibili con impostazioni specifiche per l'ambiente nella console. Per ulteriori informazioni sulla precedenza e altri metodi di modifica delle impostazioni, consulta [Opzioni di configurazione](command-options.md).
## Configurazione dell'ambiente.NET nella console Elastic Beanstalk
Puoi utilizzare la console Elastic Beanstalk per attivare la rotazione dei log in Amazon S3, configurare variabili che l'applicazione è in grado di leggere dall'ambiente e modificare le impostazioni del framework .NET.
**Per configurare l'ambiente.NET nella console Elastic Beanstalk**
1. Apri la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk) e, **nell'elenco Regioni, seleziona la tua**. Regione AWS
1. Nel pannello di navigazione selezionare **Environments** (Ambienti), quindi selezionare il nome dell'ambiente dall'elenco.
1. Nel riquadro di navigazione, seleziona **Configuration** (Configurazione).
1. Nella categoria di configurazione **Updates, monitoring, and logging** (Aggiornamenti, monitoraggio e registrazione), scegli **Edit** (Modifica).
### Opzioni del contenitore
+ **Target .NET runtime (Runtime target .NET)**: impostare questa opzione su `2.0` per eseguire CLR v2.
+ **Enable 32-bit applications (Abilita le applicazioni a 32 bit)**: impostare questa opzione su `True` per eseguire applicazioni a 32 bit.
### Opzioni di log
La sezione Log Options (Opzioni di log) ha due impostazioni:
+ **Instance profile** (Profilo dell'istanza): specifica il profilo dell'istanza che dispone dell'autorizzazione ad accedere al bucket Amazon S3 associato all'applicazione.
+ **Abilita la rotazione dei file di registro su Amazon S3**: specifica se i file di log per le EC2 istanze Amazon dell'applicazione vengono copiati nel bucket Amazon S3 associato all'applicazione.
### Proprietà dell'ambiente
La sezione **Environment Properties** consente di specificare le impostazioni di configurazione dell'ambiente sulle EC2 istanze Amazon su cui è in esecuzione l'applicazione. Queste impostazioni sono passate come coppie chiave-valore all'applicazione. Utilizza `System.GetEnvironmentVariable` per leggerle. In `web.config` e nelle proprietà dell'ambiente possono esservi chiavi identiche. Utilizza lo spazio dei nomi `System.Configuration` per leggere i valori da `web.config`.
```
NameValueCollection appConfig = ConfigurationManager.AppSettings;
string endpoint = appConfig["API_ENDPOINT"];
```
Per ulteriori informazioni, consulta [Variabili di ambiente e altre impostazioni software](environments-cfg-softwaresettings.md).
## Spazio dei nomi aws:elasticbeanstalk:container:dotnet:apppool
Puoi utilizzare un [file di configurazione](ebextensions.md) per impostare le opzioni di configurazione ed eseguire alte attività di configurazione delle istanze durante le distribuzioni. Le opzioni di configurazione possono essere [specifiche della piattaforma](command-options-specific.md) o essere applicate a [tutte le piattaforme](command-options-general.md) del servizio Elastic Beanstalk nel suo complesso. *Le opzioni di configurazione sono organizzate in namespace.*
La piattaforma .NET definisce le opzioni nel namespace `aws:elasticbeanstalk:container:dotnet:apppool` che puoi utilizzare per configurare il runtime .NET.
Il seguente file di configurazione di esempio mostra le impostazioni per ognuna delle opzioni disponibili in questo namespace:
**Example .ebextensions/dotnet-settings.config**
```
option_settings:
aws:elasticbeanstalk:container:dotnet:apppool:
Target Runtime: 2.0
Enable 32-bit Applications: True
```
In Elastic Beanstalk sono disponibili varie opzioni di configurazione per la personalizzazione dell'ambiente. Oltre ai file di configurazione, puoi impostare le opzioni di configurazione tramite la console, le configurazioni salvate, la CLI EB o AWS CLI. Per ulteriori informazioni, consulta [Opzioni di configurazione](command-options.md).
# Migrazione tra le versioni principali della piattaforma server Windows di Elastic Beanstalk
AWS Elastic Beanstalk ha avuto diverse versioni principali della sua piattaforma Windows Server. Questa pagina descrive i miglioramenti più significativi per ogni versione principale e cosa occorre considerare prima di eseguire la migrazione a una versione più recente.
La versione corrente della piattaforma Windows Server è la versione 2 (v2). Se l'applicazione usa qualsiasi versione della piattaforma Windows Server precedente a v2, ti consigliamo di eseguire la migrazione a v2.
## Novità delle versioni principali della piattaforma Windows Server
### Piattaforma Windows Server V2
La versione 2 (v2) della piattaforma Windows Server di Elastic Beanstalk è stata resa [disponibile a febbraio 2019](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2019-02-21-windows-v2.html). La versione V2 avvicina il funzionamento della piattaforma Windows Server a quello delle piattaforme basate su Linux di Elastic Beanstalk in molti modi importanti. La versione V2 è completamente compatibile con la versione v1 e questo semplifica la migrazione dalla versione v1.
La piattaforma Windows Server ora supporta quanto segue:
+ *Funzione Versioni multiple*: ogni versione ottiene un nuovo numero di versione e puoi fare riferimento alle versioni precedenti, ancora disponibili, quando crei e gestisci gli ambienti.
+ *Integrità migliorata*: per informazioni dettagliate, consulta [Reportistica e monitoraggio dello stato di salute migliorati in Elastic Beanstalk](health-enhanced.md).
+ Distribuzioni *Non modificabile* e *In sequenza con un batch aggiuntivo* – Per informazioni dettagliate sulle policy di distribuzione, consulta [Distribuzione di applicazioni in ambienti Elastic Beanstalk](using-features.deploy-existing-version.md).
+ *Aggiornamenti non modificabili*: per informazioni dettagliate sui tipi di aggiornamento, consulta [Modifiche di configurazione](environments-updating.md).
+ *Aggiornamenti gestiti della piattaforma*: per informazioni dettagliate, consulta [Aggiornamenti gestiti della piattaforma](environment-platform-update-managed.md).
**Nota**
Le nuove caratteristiche di distribuzione e aggiornamento dipendono dallo stato avanzato. Abilita stato avanzato per utilizzarle. Per informazioni dettagliate, consulta [Abilitazione del reporting dello stato avanzato Elastic Beanstalk](health-enhanced-enable.md).
### Piattaforma Windows Server V1
La versione 1.0.0 (v1) della piattaforma Windows Server di Elastic Beanstalk è stata resa disponibile a ottobre 2015. Questa versione cambia l'ordine in cui Elastic Beanstalk elabora i comandi nei [file di configurazione](ebextensions.md) durante la creazione dell'ambiente e gli aggiornamenti.
Le versioni precedenti della piattaforma non dispongono di un numero di versione nel nome dello stack della soluzione:
+ Windows Server 2012 R2 (64 bit) con IIS 8.5 in esecuzione
+ Windows Server Core 2012 R2 (64 bit) con IIS 8.5 in esecuzione
+ Windows Server 2012 (64 bit) con IIS 8 in esecuzione
+ Windows Server 2008 R2 (64 bit) con IIS 7.5 in esecuzione
Nelle versioni precedenti l'ordine di elaborazione per i file di configurazione è incoerente. Durante la creazione dell'ambiente, `Container Commands` viene eseguito dopo che il codice sorgente dell'applicazione viene distribuito su IIS. Durante una distribuzione in un ambiente di esecuzione, i comandi del container vengono eseguiti prima della distribuzione della nuova versione. Durante un aumento del dimensionamento, i file di configurazione non vengono elaborati.
Oltre a questo, IIS viene avviato prima dell'esecuzione dei comandi del container. Questo comportamento ha portato alcuni clienti a implementare soluzioni alternative nei comandi dei container, con una pausa del server IIS prima dell'esecuzione dei comandi e con un avvio successivo al completamento.
La versione 1 corregge l'incoerenza e avvicina il comportamento della piattaforma Windows Server a quello delle piattaforme basate su Linux di Elastic Beanstalk. Nella piattaforma v1, Elastic Beanstalk esegue sempre i comandi dei container prima di avviare il server IIS.
La soluzione della piattaforma v1 specifica `v1` dopo la versione di Windows Server:
+ Windows Server 2012 R2 (64 bit) v1.1.0 con IIS 8.5 in esecuzione
+ Windows Server Core 2012 R2 (64 bit) v1.1.0 con IIS 8.5 in esecuzione
+ Windows Server 2012 (64 bit) v1.1.0 con IIS 8 in esecuzione
+ Windows Server 2008 R2 (64 bit) v1.1.0 con IIS 7.5 in esecuzione
Inoltre, la piattaforma v1 estrae il contenuto del bundle di origine dell'applicazione in `C:\staging\` prima dell'esecuzione dei comandi dei container. Quando i comandi container hanno completato l'operazione, i contenuti di questa cartella vengono compressi in un file .zip e distribuiti in IIS. Questo flusso di lavoro consente di modificare i contenuti del tuo bundle di origine dell'applicazione con comandi o con uno script prima della distribuzione.
## Migrazione da versioni principali della piattaforma Windows Server
Questa sezione contiene alcune considerazioni sulla migrazione di cui tenere conto prima di aggiornare l'ambiente. Per aggiornare la piattaforma dell'ambiente a una versione più recente, consulta [Aggiornamento della versione della piattaforma dell'ambiente Elastic Beanstalk](using-features.platform.upgrade.md).
### Da V1 verso V2
La piattaforma Windows Server v2 non supporta .NET Core 1.x e 2.0. Se esegui la migrazione dell'applicazione da Windows Server v1 a v2 e l'applicazione utilizza una di queste versioni .NET Core, aggiorna l'applicazione a una versione .NET Core supportata da v2. Per un elenco delle versioni supportate, consulta [.NET su Windows Server con IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) in *Piattaforme AWS Elastic Beanstalk *.
Se l'applicazione utilizza una Amazon Machine Image (AMI) personalizzata, crea una nuova AMI personalizzata in base all’AMI della piattaforma di Windows Server v2. Per ulteriori informazioni, vedi [Utilizzo di un'immagine Amazon Machine Image (AMI) personalizzata nell'ambiente Elastic Beanstalk](using-features.customenv.md).
**Nota**
Le caratteristiche di distribuzione e aggiornamento che sono nuove per Windows Server v2 dipendono dallo stato avanzato. Quando si esegue la migrazione di un ambiente a v2, lo stato avanzato è disabilitato. Abilitarlo per utilizzare queste caratteristiche. Per informazioni dettagliate, consulta [Abilitazione del reporting dello stato avanzato Elastic Beanstalk](health-enhanced-enable.md).
### Da versioni precedenti alla versione V1
Oltre alle considerazioni sulla migrazione da v1, se esegui la migrazione dell'applicazione da uno stack di soluzioni Windows Server che è precedente alla versione v1 e usi attualmente comandi dei container, rimuovi tutti i comandi aggiunti per risolvere le incoerenze di elaborazione quando esegui la migrazione a una versione più recente. A partire da v1, i comandi del container vengono sicuramente eseguiti completamente prima dell'origine dell'applicazione che viene distribuita e prima dell'avvio di IIS. Questo consente di apportare eventuali modifiche all'origine in `C:\staging` e modificare i file di configurazione IIS durante questa fase senza problemi.
Ad esempio, puoi utilizzare per AWS CLI scaricare un file DLL nella sorgente dell'applicazione da Amazon S3:
`.ebextensions\copy-dll.config`
```
container_commands:
copy-dll:
command: aws s3 cp s3://amzn-s3-demo-bucket/dlls/large-dll.dll .\lib\
```
Per ulteriori informazioni sull'utilizzo dei file di configurazione, consulta [Personalizzazione avanzata dell'ambiente con i file di configurazione (`.ebextensions`)](ebextensions.md).
# Esecuzione di più applicazioni e delle applicazioni ASP.NET Core con un manifest di distribuzione
È possibile utilizzare un manifest di distribuzione per indicare a Elastic Beanstalk come distribuire l'applicazione. Utilizzando questo metodo, non è necessario utilizzare `MSDeploy` per generare un bundle di origine per una singola applicazione ASP.NET che viene eseguita nel percorso root del sito Web. Piuttosto, è possibile utilizzare un file manifest per eseguire più applicazioni in percorsi diversi. In alternativa, puoi chiedere a Elastic Beanstalk di distribuire ed eseguire l'app con ASP.NET Core. È inoltre possibile utilizzare un manifest di distribuzione per configurare un pool di applicazioni in cui eseguire le applicazioni.
I manifest di distribuzione aggiungono il supporto per [Applicazioni .NET Core](#dotnet-manifest-dotnetcore) su Elastic Beanstalk. È possibile distribuire un'applicazione .NET Framework senza un manifest di distribuzione. Tuttavia, le applicazioni .NET Core richiedono un manifest di distribuzione per essere eseguite su Elastic Beanstalk. Quando utilizzi un manifest di distribuzione, è necessario creare un archivio del sito per ogni applicazione e quindi raggruppare gli archivi del sito in un secondo archivio ZIP che contiene il manifest di distribuzione.
I manifest di distribuzione aggiungono anche la possibilità di [eseguire più applicazioni in diversi percorsi](#dotnet-manifest-multiapp). Un manifest di distribuzione definisce una gamma di obiettivi di distribuzione, ognuno con un archivio del sito e un percorso su cui IIS dovrebbe eseguirlo. Ad esempio, è possibile eseguire un'API Web nel percorso `/api` per servire richieste asincrone e un'app Web nel percorso root che utilizza l'API.
È possibile utilizzare un manifesto di distribuzione per [configurare i siti Web IIS con collegamenti e percorsi fisici personalizzati](#dotnet-manifest-websites). Ciò consente di configurare siti Web che ascoltano su porte o nomi host specifici prima di distribuire le applicazioni.
È inoltre possibile utilizzare un manifest di distribuzione per [eseguire più applicazioni utilizzando pool di applicazioni in IIS o Kestrel](#dotnet-manifest-apppool). È possibile configurare un pool di applicazioni per riavviare le proprie applicazioni periodicamente, eseguire applicazioni a 32 bit o utilizzare una versione specifica del runtime di .NET Framework.
Per una personalizzazione completa, puoi [scrivere i tuoi script di distribuzione](#dotnet-manifest-custom) in Windows PowerShell e indicare a Elastic Beanstalk quali script eseguire per installare, disinstallare e riavviare l'applicazione.
I manifest di distribuzione e le relative caratteristiche richiedono una piattaforma Windows Server [versione 1.2.0 o più recente](dotnet-v2migration.md).
[Per informazioni dettagliate su tutte le opzioni di configurazione, le proprietà e le funzionalità avanzate disponibili, come ignorare le reimpostazioni di IIS, consulta il riferimento allo schema del manifesto di distribuzione.](dotnet-manifest-schema.md)
**Topics**
+ [App .NET Core](#dotnet-manifest-dotnetcore)
+ [Esecuzione di più applicazioni](#dotnet-manifest-multiapp)
+ [Configurazione dei siti Web IIS](#dotnet-manifest-websites)
+ [Utilizzo dell'Application Request Routing (ARR)](#dotnet-manifest-arr)
+ [Configurazione dei pool delle applicazioni](#dotnet-manifest-apppool)
+ [Definizione delle distribuzioni personalizzate](#dotnet-manifest-custom)
+ [Riferimento allo schema del manifesto di distribuzione](dotnet-manifest-schema.md)
## App .NET Core
È possibile utilizzare un manifest di implementazione per eseguire applicazioni .NET Core su Elastic Beanstalk. .NET Core è una versione multipiattaforma di .NET fornita con uno strumento a riga di comando (`dotnet`). È possibile utilizzarlo per generare un'applicazione, eseguirla in locale e prepararla per la pubblicazione.
Per eseguire un'applicazione .NET Core su Elastic Beanstalk, esegui `dotnet publish` e raggruppa l'output in un archivio ZIP senza includere le directory. Posiziona l'archivio del sito in un bundle di origine con un manifest di distribuzione con una destinazione di distribuzione di tipo `aspNetCoreWeb`.
Il seguente manifest di distribuzione esegue un'applicazione .NET Core da un archivio del sito denominato `dotnet-core-app.zip` al percorso root.
**Example aws-windows-deployment-manifest.json - .NET core**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
Raggruppa il manifest e l'archivio del sito in un archivio ZIP per creare un bundle di origine.
**Example dotnet-core-bundle.zip**
```
.
|-- aws-windows-deployment-manifest.json
`-- dotnet-core-app.zip
```
L'archivio del sito contiene il codice compilato dell'applicazione, le dipendenze e il file `web.config`.
**Example dotnet-core-app.zip**
```
.
|-- Microsoft.AspNetCore.Hosting.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.dll
|-- Microsoft.AspNetCore.Http.Abstractions.dll
|-- Microsoft.AspNetCore.Http.Extensions.dll
|-- Microsoft.AspNetCore.Http.Features.dll
|-- Microsoft.AspNetCore.Http.dll
|-- Microsoft.AspNetCore.HttpOverrides.dll
|-- Microsoft.AspNetCore.Server.IISIntegration.dll
|-- Microsoft.AspNetCore.Server.Kestrel.dll
|-- Microsoft.AspNetCore.WebUtilities.dll
|-- Microsoft.Extensions.Configuration.Abstractions.dll
|-- Microsoft.Extensions.Configuration.EnvironmentVariables.dll
|-- Microsoft.Extensions.Configuration.dll
|-- Microsoft.Extensions.DependencyInjection.Abstractions.dll
|-- Microsoft.Extensions.DependencyInjection.dll
|-- Microsoft.Extensions.FileProviders.Abstractions.dll
|-- Microsoft.Extensions.FileProviders.Physical.dll
|-- Microsoft.Extensions.FileSystemGlobbing.dll
|-- Microsoft.Extensions.Logging.Abstractions.dll
|-- Microsoft.Extensions.Logging.dll
|-- Microsoft.Extensions.ObjectPool.dll
|-- Microsoft.Extensions.Options.dll
|-- Microsoft.Extensions.PlatformAbstractions.dll
|-- Microsoft.Extensions.Primitives.dll
|-- Microsoft.Net.Http.Headers.dll
|-- System.Diagnostics.Contracts.dll
|-- System.Net.WebSockets.dll
|-- System.Text.Encodings.Web.dll
|-- dotnet-core-app.deps.json
|-- dotnet-core-app.dll
|-- dotnet-core-app.pdb
|-- dotnet-core-app.runtimeconfig.json
`-- web.config
```
## Esecuzione di più applicazioni
È possibile eseguire più applicazioni con un manifest di distribuzione definendo più target di distribuzione.
Il seguente manifesto di distribuzione configura due applicazioni .NET Core. L'`WebApiSampleApp`applicazione implementa una semplice API web e serve richieste asincrone sul percorso. `/api` `DotNetSampleApp` è un'applicazione Web che fornisce richieste al percorso root.
**Example aws-windows-deployment-manifest.json: più app**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "WebAPISample",
"parameters": {
"appBundle": "WebApiSampleApp.zip",
"iisPath": "/api"
}
},
{
"name": "DotNetSample",
"parameters": {
"appBundle": "DotNetSampleApp.zip",
"iisPath": "/"
}
}
]
}
}
```
Un'applicazione di esempio con più applicazioni è disponibile qui:
+ **[Pacchetto sorgente distribuibile - -v2.zip dotnet-multiapp-sample-bundle](samples/dotnet-multiapp-sample-bundle-v2.zip)**
+ **[Codice sorgente: -v2.zip dotnet-multiapp-sample-source](samples/dotnet-multiapp-sample-source-v2.zip)**
## Configurazione dei siti Web IIS
È possibile configurare i siti Web IIS con collegamenti e percorsi fisici personalizzati utilizzando il manifesto di distribuzione. Ciò è utile quando è necessario configurare siti Web che ascoltano su porte specifiche, utilizzano nomi host personalizzati o forniscono contenuti da directory specifiche.
Il seguente manifesto di distribuzione configura un sito Web IIS personalizzato che ascolta su HTTP con un numero di porta specifico e un percorso fisico personalizzato:
**Example aws-windows-deployment-manifest.json - configurazione del sito Web IIS**
```
{
"manifestVersion": 1,
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
}
]
}
]
},
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"appBundle": "dotnet-core-app.zip",
"iisWebSite": "MyCustomSite",
"iisPath": "/"
}
}
]
}
}
```
In questo esempio:
+ Un sito Web denominato "MyCustomSite" viene creato con un percorso fisico personalizzato
+ Il sito Web ha un'associazione HTTP sulla porta 8080 con un nome host specifico
+ L'applicazione ASP.NET Core viene distribuita su questo sito Web personalizzato utilizzando il parametro `iisWebSite`
## Utilizzo dell'Application Request Routing (ARR)
I moduli Application Request Routing (ARR) e URL Rewrite sono preinstallati e disponibili in Elastic Beanstalk Windows. AMIs Questi moduli consentono scenari di routing avanzati e la manipolazione degli URL tramite la configurazione IIS utilizzando ebextensions o la configurazione dell'applicazione.
L'esempio seguente mostra un semplice manifesto di distribuzione che configura un sito Web con una porta personalizzata, combinato con una configurazione ebextensions che imposta il routing ARR di base:
**Example aws-windows-deployment-manifest.json: configurazione ARR semplice**
```
{
"manifestVersion": 1,
"iisConfig": {
"websites": [
{
"name": "ARRSite",
"physicalPath": "C:\\inetpub\\wwwroot\\arrsite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "localhost"
}
]
}
]
},
"deployments": {
"aspNetCoreWeb": [
{
"name": "BackendApp",
"parameters": {
"appBundle": "backend-app.zip",
"iisWebSite": "ARRSite",
"iisPath": "/backend"
}
}
]
}
}
```
La configurazione ARR viene eseguita tramite ebextensions. La seguente configurazione imposta le regole di routing ARR di base:
**Example .ebextensions/arr-config.config - Configurazione ARR di base**
```
files:
"C:\\temp\\configure-arr.ps1":
content: |
# Enable ARR proxy at server level
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/proxy' -Name 'enabled' -Value 'True'
# Clear any existing global rules to avoid conflicts
Clear-WebConfiguration -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/rewrite/globalRules'
# Add global rule to route all requests to backend
Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
-Filter 'system.webServer/rewrite/globalRules' `
-Name '.' `
-Value @{
name = 'Route_to_Backend'
stopProcessing = 'True'
match = @{ url = '^(?!backend/)(.*)' }
action = @{
type = 'Rewrite'
url = 'http://localhost:8080/backend/{R:1}'
}
}
container_commands:
01_configure_arr:
command: powershell -ExecutionPolicy Bypass -File "C:\\temp\\configure-arr.ps1"
waitAfterCompletion: 0
```
Questa configurazione crea un sito Web sulla porta 8080 e configura ARR per indirizzare tutte le richieste in arrivo all'applicazione di backend in esecuzione su quel sito.
## Configurazione dei pool delle applicazioni
È possibile supportare più applicazioni nell'ambiente Windows. Sono disponibili due approcci:
+ È possibile utilizzare il modello di out-of-process hosting con il server web Kestrel. Con questo modello, è possibile configurare più applicazioni per l'esecuzione in un unico pool di applicazioni.
+ È possibile utilizzare il modello di hosting in-process. Con questo modello, è possibile utilizzare più pool di applicazioni per eseguire più applicazioni con una sola applicazione in ogni pool. Se utilizzi il server IIS e desideri eseguire più applicazioni, devi utilizzare questo approccio.
Per configurare Kestrel ed eseguire più applicazioni in un pool di applicazioni, aggiungi `hostingModel="OutofProcess"` nel file `web.config`. Considera i seguenti esempi:
**Example web.config - per il modello di hosting Kestrel out-of-process**
```
```
**Example aws-windows-deployment-manifest.json: più applicazioni**
```
{
"manifestVersion": 1,
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {"archive": "site1.zip",
"iisPath": "/"
}
},
{"name": "Web-app2",
"parameters": {"archive": "site2.zip",
"iisPath": "/app2"
}
}
]
}
}
```
IIS non supporta più applicazioni in un pool di applicazioni perché utilizza il modello di hosting in-process. Pertanto, è necessario configurare più applicazioni assegnando ciascuna applicazione a un pool di applicazioni. In altre parole, assegnare una sola applicazione a un pool di applicazioni.
È possibile configurare IIS per utilizzare diversi pool di applicazioni nel file `aws-windows-deployment-manifest.json`. Apporta i seguenti aggiornamenti consultando il file di esempio successivo:
+ Aggiungi una sezione `iisConfig` che includa una sottosezione denominata `appPools`.
+ Nel blocco `appPools`, elenca i pool di applicazioni.
+ Nella sezione `deployments`, definisci una sezione `parameters` per ogni applicazione.
+ Per ogni applicazione, la sezione `parameters` specifica un archivio, un percorso per eseguirla e un `appPool` in cui eseguirla.
Il seguente manifest di distribuzione consente di configurare due pool di applicazioni che riavviano l'applicazione ogni 10 minuti. Essi inoltre allegano le loro applicazioni a un'applicazione Web .NET Framework che viene eseguita nel percorso specificato.
**Example aws-windows-deployment-manifest.json: un'applicazione per pool di applicazioni**
```
{
"manifestVersion": 1,
"iisConfig": {"appPools": [
{"name": "MyFirstPool",
"recycling": {"regularTimeInterval": 10}
},
{"name": "MySecondPool",
"recycling": {"regularTimeInterval": 10}
}
]
},
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {
"archive": "site1.zip",
"iisPath": "/",
"appPool": "MyFirstPool"
}
},
{"name": "Web-app2",
"parameters": {
"archive": "site2.zip",
"iisPath": "/app2",
"appPool": "MySecondPool"
}
}
]
}
}
```
## Definizione delle distribuzioni personalizzate
Per un maggiore controllo, è possibile personalizzare completamente la distribuzione di un'applicazione definendo una *distribuzione personalizzata*.
Questo manifesto di distribuzione indica a Elastic Beanstalk PowerShell di eseguire gli script in modalità a 32 bit. [Specifica tre script: `install` uno script (`siteInstall.ps1`) che viene eseguito durante l'avvio e la distribuzione dell'istanza, uno `uninstall` script (`siteUninstall.ps1`) che viene eseguito prima di installare nuove versioni durante le distribuzioni e uno `restart` script (`siteRestart.ps1`) che viene eseguito quando si seleziona Riavvia App Server nella console di gestione.](environments-dashboard-actions.md) AWS
**Example aws-windows-deployment-manifest.json: distribuzione personalizzata**
```
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "Custom site",
"architecture" : 32,
"scripts": {
"install": {
"file": "siteInstall.ps1"
},
"restart": {
"file": "siteRestart.ps1"
},
"uninstall": {
"file": "siteUninstall.ps1"
}
}
}
]
}
}
```
Include eventuali artefatti necessari per eseguire l'applicazione nel bundle di origine con il manifest e gli script.
**Example C - .zip ustom-site-bundle**
```
.
|-- aws-windows-deployment-manifest.json
|-- siteInstall.ps1
|-- siteRestart.ps1
|-- siteUninstall.ps1
`-- site-contents.zip
```
# Riferimento allo schema del manifesto di distribuzione
Il manifesto di distribuzione è un file JSON che definisce in che modo Elastic Beanstalk deve distribuire e configurare le applicazioni Windows. Questa sezione fornisce un riferimento completo per tutte le proprietà e le opzioni di configurazione supportate nello schema del manifesto.
## Struttura del manifesto
Il manifesto di distribuzione segue uno schema JSON specifico con la seguente struttura di primo livello:
**Example Struttura del manifesto di base**
```
{
"manifestVersion": 1,
"skipIISReset": false,
"iisConfig": {
"websites": [...],
"appPools": [...]
},
"deployments": {
"msDeploy": [...],
"aspNetCoreWeb": [...],
"custom": [...]
}
}
```
### Proprietà di primo livello
`manifestVersion`(richiesto)
*Tipo*: numero
*Impostazione predefinita*: 1
*Valori validi:* 1
Speciifica la versione dello schema del manifesto. Attualmente è supportata solo la versione 1.
`skipIISReset` (facoltativo)
*Tipo*: Booleano
*Di default:* false
Controlla se IIS viene ripristinato durante le distribuzioni delle applicazioni. Questo flag influisce su entrambi i tipi `msDeploy` di `aspNetCoreWeb` distribuzione.
*Comportamento:*
+ *Non specificato o `false` (impostazione predefinita):* le reimpostazioni di IIS vengono eseguite durante le operazioni di installazione, disinstallazione e aggiornamento. Questo è il comportamento tradizionale.
+ *`true`:* le reimpostazioni IIS vengono ignorate durante le operazioni di distribuzione.
*Vantaggi:*
+ Tempi di *inattività ridotti*: le applicazioni subiscono interruzioni del servizio più brevi durante le implementazioni.
+ *Implementazioni più rapide*: elimina il tempo necessario a IIS per riavviare e reinizializzare completamente IIS.
Durante l'utilizzo`skipIISReset`, l'[RestartAppServer](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RestartAppServer.html)operazione esegue un ripristino di IIS indipendentemente dall'impostazione di questa bandiera.
*Esempio*:
```
{
"manifestVersion": 1,
"skipIISReset": true,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
`deployments`(obbligatorio)
*Tipo:* oggetto
Contiene le configurazioni di distribuzione per le tue applicazioni. Questo oggetto può includere `msDeploy` e `aspNetCoreWeb` tipi di `custom` distribuzione.
`iisConfig` (facoltativo)
*Tipo:* oggetto
Definisce le impostazioni di configurazione IIS da applicare prima di distribuire le applicazioni. Supporta la configurazione del sito Web e del pool di applicazioni.
## Configurazione IIS
La `iisConfig` sezione consente di configurare le impostazioni IIS prima di distribuire le applicazioni. Ciò include la configurazione di pool di applicazioni con configurazioni specifiche e la configurazione di siti Web IIS con associazioni personalizzate.
### Siti Web IIS
I siti Web IIS consentono di configurare impostazioni personalizzate dei siti Web, inclusi percorsi fisici e collegamenti di rete, prima di distribuire le applicazioni.
**Considerazioni importanti per la creazione di diversi siti Web IIS**
*Ordine di configurazione dei siti Web:* i siti Web vengono configurati in sequenza nell'ordine in cui appaiono nell'`websites`array. La piattaforma elabora ogni configurazione del sito Web in sequenza, quindi assicurati un ordine corretto in caso di dipendenze tra i siti Web.
*Firewall e accesso alle porte:* solo la porta 80 viene esposta automaticamente tramite la configurazione firewall Windows Elastic Beanstalk predefinita. Se si configurano siti Web per utilizzare porte non standard, è necessario definire regole firewall personalizzate tramite ebextensions o script di distribuzione personalizzati per consentire l'accesso esterno a queste porte.
**Example Configurazione del sito Web**
```
{
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
},
{
"protocol": "https",
"port": 8443
}
]
}
]
}
}
```Proprietà del sito Web
`name`(richiesto)
▬*Tipo:* stringa
Il nome del sito Web IIS. Questo nome viene utilizzato per identificare il sito Web in IIS Manager e deve essere univoco all'interno della configurazione IIS.
`physicalPath`(richiesto)
▬*Tipo:* stringa
Il percorso fisico sul server in cui sono archiviati i file del sito Web. Questo percorso deve essere accessibile al processo di lavoro IIS.
`bindings`(obbligatorio)
*Tipo*: matrice
*Numero minimo di articoli:* 1
Una serie di configurazioni vincolanti che definiscono il modo in cui il sito Web risponde alle richieste di rete. Ogni associazione specifica un protocollo, una porta e un nome host opzionale.
#### Associazioni a siti Web
Le associazioni ai siti Web definiscono gli endpoint di rete in cui il sito Web IIS ascolterà le richieste in arrivo.
`protocol`(richiesto)
▬*Tipo:* stringa
*Valori validi:* «http», «https»
Il protocollo utilizzato per l'associazione.
`port`(richiesto)
*Tipo*: integer
*Intervallo valido: 1-65535*
Il numero di porta su cui il sito Web ascolterà le richieste.
`hostName` (facoltativo)
▬*Tipo:* stringa
Il nome host (nome di dominio) per l'associazione.
### Pool di applicazioni
I pool di applicazioni forniscono l'isolamento tra le applicazioni e consentono di configurare le impostazioni di runtime per gruppi di applicazioni.
**Example Configurazione del pool di applicazioni**
```
{
"iisConfig": {
"appPools": [
{
"name": "MyAppPool",
"enable32Bit": false,
"managedPipelineMode": "Integrated",
"managedRuntimeVersion": "v4.0",
"queueLength": 1000,
"cpu": {
"limitPercentage": 80,
"limitAction": "Throttle",
"limitMonitoringInterval": 5
},
"recycling": {
"regularTimeInterval": 1440,
"requestLimit": 10000,
"memory": 1048576,
"privateMemory": 524288
}
}
]
}
}
```Proprietà del pool di applicazioni
`name`(richiesto)
▬*Tipo:* stringa
Il nome del pool di applicazioni. Questo nome viene utilizzato per fare riferimento al pool nelle configurazioni di distribuzione.
`enable32Bit` (facoltativo)
*Tipo*: Booleano
Consente l'esecuzione di un'applicazione a 32 bit su una versione a 64 bit di Windows. Impostato su `true` per le applicazioni legacy che richiedono la compatibilità a 32 bit.
`managedPipelineMode` (facoltativo)
▬*Tipo:* stringa
*Valori validi:* «Integrato», «Classico»
Speciifica la modalità di elaborazione delle richieste per il pool di applicazioni.
`managedRuntimeVersion` (facoltativo)
▬*Tipo:* stringa
*Valori validi:* «No Managed Code», «v2.0", «v4.0"
Speciifica la versione.NET Framework per il pool di applicazioni.
`queueLength` (facoltativo)
*Tipo*: integer
Numero massimo di richieste che HTTP.sys mette in coda per il pool di applicazioni prima di rifiutare richieste aggiuntive.
#### Configurazione della CPU
L'`cpu`oggetto configura i limiti di utilizzo della CPU e il monitoraggio per il pool di applicazioni.
`limitPercentage` (facoltativo)
*Tipo*: numero
Percentuale massima di tempo di CPU che i processi di lavoro nel pool di applicazioni possono consumare.
`limitAction` (facoltativo)
▬*Tipo:* stringa
*Valori validi:* "NoAction«, «killW3WP», «Throttle», "» ThrottleUnderLoad
Azione da intraprendere quando viene raggiunto il limite della CPU.
`limitMonitoringInterval` (facoltativo)
*Tipo*: numero
Periodo di ripristino (in minuti) per il monitoraggio della CPU e i limiti di limitazione.
#### Configurazione del riciclaggio
L'`recycling`oggetto configura quando e come i processi di lavoro del pool di applicazioni vengono riciclati.
`regularTimeInterval` (facoltativo)
*Tipo*: integer
Intervallo di tempo (in minuti) dopo il quale il pool di applicazioni viene riciclato. Impostare su 0 per disabilitare il riciclo basato sul tempo.
`requestLimit` (facoltativo)
*Tipo*: integer
Numero massimo di richieste elaborate dal pool di applicazioni prima del riciclaggio.
`memory` (facoltativo)
*Tipo*: integer
Quantità di memoria virtuale (in kilobyte) che attiva il riciclaggio dei processi di lavoro.
`privateMemory` (facoltativo)
*Tipo*: integer
Quantità di memoria privata (in kilobyte) che attiva il riciclaggio dei processi di lavoro.
## Tipi di implementazione
L'`deployments`oggetto contiene matrici di configurazioni di distribuzione per diversi tipi di applicazioni. Ogni tipo di distribuzione ha proprietà e casi d'uso specifici.
### MSDeploy distribuzioni
MSDeploy le distribuzioni vengono utilizzate per le tradizionali applicazioni.NET Framework che possono essere distribuite utilizzando Web Deploy (). MSDeploy
**Example MSDeploy configurazione di distribuzione**
```
{
"deployments": {
"msDeploy": [
{
"name": "WebApp",
"description": "Main web application",
"parameters": {
"appBundle": "webapp.zip",
"iisPath": "/",
"appPool": "DefaultAppPool"
}
}
]
}
}
```MSDeploy proprietà di distribuzione
`name`(richiesto)
▬*Tipo:* stringa
Nome univoco per la distribuzione. Questo nome deve essere univoco in tutte le distribuzioni del manifesto.
`description` (facoltativo)
▬*Tipo:* stringa
Descrizione della distribuzione in formato leggibile dall'uomo.
`parameters`(richiesto)
*Tipo:* oggetto
Parametri di configurazione per l' MSDeploy operazione.
`scripts` (facoltativo)
*Tipo:* oggetto
PowerShell script da eseguire in varie fasi del ciclo di vita dell'implementazione.
#### MSDeploy parametri
`appBundle`(richiesto)
▬*Tipo:* stringa
Percorso del pacchetto dell'applicazione (file ZIP) relativo al file manifest. Questo pacchetto contiene i file dell'applicazione da distribuire.
`iisWebSite` (facoltativo)
▬*Tipo:* stringa
*Predefinito:* «Sito Web predefinito»
Il sito Web IIS su cui distribuire l'applicazione. Per impostazione predefinita, le applicazioni vengono distribuite nel «Sito Web predefinito». Facoltativamente, è possibile specificare un nome di sito Web diverso, ad esempio quello configurato nella `iisConfig.websites` sezione.
`iisPath` (facoltativo)
▬*Tipo:* stringa
*Predefinito:* «/»
Percorso della directory virtuale in IIS in cui verrà distribuita l'applicazione. Usa «/» per il percorso principale o «/api» per una sottodirectory.
`appPool` (facoltativo)
▬*Tipo:* stringa
Nome del pool di applicazioni per eseguire questa applicazione.
### Distribuzioni ASP.NET Core
Le distribuzioni ASP.NET Core sono progettate specificamente per le applicazioni.NET Core e.NET 5\$1.
**Example Configurazione della distribuzione di ASP.NET Core**
```
{
"deployments": {
"aspNetCoreWeb": [
{
"name": "CoreAPI",
"description": "ASP.NET Core Web API",
"parameters": {
"appBundle": "coreapi.zip",
"iisPath": "/api",
"appPool": "CoreAppPool"
}
}
]
}
}
```
Le distribuzioni ASP.NET Core utilizzano la stessa struttura di proprietà delle MSDeploy distribuzioni, con la differenza fondamentale nell'ambiente di runtime e nel modello di hosting utilizzati per l'applicazione.Parametri di distribuzione di ASP.NET Core
`appBundle`(richiesto)
▬*Tipo:* stringa
Percorso del bundle dell'applicazione relativo al file manifest. Può trattarsi di un archivio ZIP o di un percorso di directory contenente l'applicazione ASP.NET Core pubblicata.
`iisWebSite` (facoltativo)
▬*Tipo:* stringa
*Predefinito:* «Sito Web predefinito»
Il sito Web IIS su cui distribuire l'applicazione ASP.NET Core. Per impostazione predefinita, le applicazioni vengono distribuite nel «Sito Web predefinito». Facoltativamente, è possibile specificare un nome di sito Web diverso, ad esempio quello configurato nella `iisConfig.websites` sezione.
`iisPath` (facoltativo)
▬*Tipo:* stringa
*Predefinito:* «/»
Percorso della directory virtuale in IIS per l'applicazione ASP.NET Core.
`appPool` (facoltativo)
▬*Tipo:* stringa
Pool di applicazioni per l'applicazione ASP.NET Core. Il pool verrà configurato in modo appropriato per l'hosting ASP.NET Core.
### Distribuzioni personalizzate
Le distribuzioni personalizzate forniscono il controllo completo sul processo di distribuzione tramite script. PowerShell Questo tipo di distribuzione è utile per scenari complessi che richiedono installazione, configurazione o logica di distribuzione personalizzate.
**Example Configurazione di distribuzione personalizzata**
```
{
"deployments": {
"custom": [
{
"name": "CustomService",
"description": "Custom Windows service deployment",
"architecture": 32,
"scripts": {
"install": {
"file": "install-service.ps1"
},
"restart": {
"file": "restart-service.ps1"
},
"uninstall": {
"file": "uninstall-service.ps1",
"ignoreErrors": true
}
}
}
]
}
}
```Proprietà di distribuzione personalizzate
`name`(obbligatorio)
▬*Tipo:* stringa
Nome univoco per la distribuzione personalizzata.
`description` (facoltativo)
▬*Tipo:* stringa
Descrizione della distribuzione personalizzata.
`architecture` (facoltativo)
*Tipo*: integer
Valore *predefinito:* 32
*Valori validi:* 32, 64
Le specifiche di architettura per la modalità di esecuzione degli script PowerShell
`scripts`(richiesto)
*Tipo:* oggetto
PowerShell script che definiscono il comportamento di distribuzione. Le distribuzioni personalizzate supportano tipi di script aggiuntivi rispetto ad altri tipi di distribuzione.
## Script di distribuzione
Gli script di distribuzione sono PowerShell script che vengono eseguiti in momenti specifici durante il ciclo di vita della distribuzione. Diversi tipi di distribuzione supportano diversi set di eventi di script.
### Eventi di script
I seguenti eventi di script sono disponibili a seconda del tipo di distribuzione:Script di distribuzione standard (MSDeploy e Web) aspNetCore
`preInstall`
Viene eseguito prima dell'installazione o dell'aggiornamento dell'applicazione.
`postInstall`
Viene eseguito dopo l'installazione o l'aggiornamento dell'applicazione.
`preRestart`
Viene eseguito prima del riavvio dell'applicazione.
`postRestart`
Viene eseguito dopo il riavvio dell'applicazione.
`preUninstall`
Viene eseguito prima della disinstallazione dell'applicazione.
`postUninstall`
Viene eseguito dopo la disinstallazione dell'applicazione.Script di distribuzione personalizzati (solo distribuzioni personalizzate)
`install`
Script di installazione principale per distribuzioni personalizzate. Questo script è responsabile dell'installazione dell'applicazione o del servizio.
`restart`
Script per riavviare l'applicazione o il servizio. Chiamato al riavvio dell'ambiente.
`uninstall`
Script per disinstallare l'applicazione o il servizio. Chiamato durante la chiusura dell'ambiente o la rimozione dell'applicazione.
### Proprietà dello script
Ogni script è definito come un oggetto con le seguenti proprietà:
`file`(obbligatorio)
▬*Tipo:* stringa
Percorso del file di PowerShell script relativo al file manifest. Lo script deve avere un'`.ps1`estensione.
`ignoreErrors` (facoltativo)
*Tipo*: Booleano
*Di default:* false
Se impostato su`true`, la distribuzione continua anche se lo script fallisce. Utilizzalo per script o operazioni di pulizia non critici.
**Example Esempio di configurazione dello script**
```
{
"scripts": {
"preInstall": {
"file": "backup-config.ps1",
"ignoreErrors": true
},
"postInstall": {
"file": "configure-app.ps1"
}
}
}
```
# Utilizzo di EC2 Fast Launch con i rami della piattaforma Windows
La funzionalità EC2 Fast Launch riduce i tempi di avvio delle istanze Windows negli ambienti Elastic Beanstalk. Lo scopo di questo argomento è di guidarti nell'utilizzo di questa funzionalità con i tuoi ambienti Elastic Beanstalk. A partire dalla versione 2.16.2 della piattaforma Windows, rilasciata il [22 gennaio 2025](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-01-22-windows.html), le versioni della piattaforma Elastic Beanstalk includono la versione base con Fast Launch abilitato. AMIs EC2
## Disponibilità predefinita di Fast Launch EC2
Le ultime versioni della piattaforma Elastic Beanstalk Windows AMIs includono una EC2 base con Fast Launch abilitato automaticamente, senza costi aggiuntivi. Tuttavia, quando vengono rilasciate versioni più recenti della piattaforma, EC2 Fast Launch potrebbe non rimanere abilitato automaticamente sulla base delle versioni precedenti AMIs della piattaforma.
Si consiglia di eseguire l'aggiornamento alla versione più recente della piattaforma Windows per utilizzare la versione base AMIs con EC2 Fast Launch abilitato automaticamente. Tuttavia, se è necessario continuare a utilizzare la versione della piattaforma esistente, è possibile abilitare manualmente EC2 Fast Launch sull'AMI di base del proprio ambiente. Per istruzioni, consulta [Configurazione manuale di EC2 Fast Launch](#dotnet-ec2fastlaunch-manual).
## Configurazione manuale di EC2 Fast Launch
**Nota**
L'attivazione manuale di EC2 Fast Launch può comportare costi aggiuntivi rispetto all'utilizzo di versioni della piattaforma con EC2 Fast Launch abilitato automaticamente. Per ulteriori informazioni sui costi di EC2 Fast Launch, consulta la pagina [delle risorse sottostanti per Manage costs for EC2 Fast Launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-manage-costs.html) nella *Amazon EC2 User Guide*.
Segui questi passaggi per abilitare EC2 Fast Launch su un'AMI di base Windows utilizzata dall'ambiente Elastic Beanstalk:
**Per abilitare manualmente EC2 Fast Launch per il tuo ambiente Elastic Beanstalk**
1. Identifica l'AMI di base del tuo ambiente:
Segui i passaggi descritti in [Creazione di un'AMI personalizzata](using-features.customenv.md) per identificare l'ID AMI di base del tuo ambiente. Tieni presente che non è necessario creare un AMI personalizzato: devi solo seguire i passaggi per individuare l'ID AMI di base corrente.
1. Abilita l'avvio EC2 rapido sull'AMI:
Utilizza le istruzioni in [Enable EC2 Fast Launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-configure.html) nella *Amazon EC2 User Guide* per configurare EC2 Fast Launch per la tua AMI.