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à.
# Pubblicazione di API WebSocket che i clienti possono invocare
La semplice creazione e sviluppo di un'API di API Gateway non la rende automaticamente richiamabile dagli utenti. Per renderla richiamabile, è necessario distribuire l'API in una fase. Inoltre, potrebbe essere necessario personalizzare l'URL che verrà utilizzato dagli utenti per accedere all'API. Puoi assegnarli un dominio che sia coerente con il tuo marchio o che sia più facile da ricordare dell'URL predefinito dell'API.
In questa sezione viene descritto come distribuire l'API e personalizzare l'URL fornito agli utenti per accedervi.
**Nota**
Per aumentare la sicurezza delle API API Gateway, il dominio `execute-api.{region}.amazonaws.com`è registrato nella [Public Suffix List (PSL)](https://publicsuffix.org/). Per una maggiore sicurezza, consigliamo di utilizzare i cookie con un prefisso `__Host-` se hai bisogno di impostare cookie sensibili nel nome di dominio predefinito per le API API Gateway. Questa pratica ti aiuterà a difendere il tuo dominio dai tentativi CSRF (cross-site request forgery). Per ulteriori informazioni, consulta la pagina [Impostazione cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes) nella pagina Mozilla Developer Network.
**Topics**
+ [Crea fasi per WebSocket APIs API Gateway](websocket-api-stages.md)
+ [Implementazione WebSocket APIs in API Gateway](apigateway-set-up-websocket-deployment.md)
+ [Politica di sicurezza per WebSocket APIs API Gateway](websocket-api-ciphers.md)
+ [Nomi di dominio personalizzati per API WebSocket in Gateway API](websocket-api-custom-domain-names.md)
# Crea fasi per WebSocket APIs API Gateway
Una fase API è un riferimento logico a uno stato del ciclo di vita dell'API (ad esempio, `dev`, `prod`, `beta` o `v2`). Le fasi API sono identificate dal rispettivo ID API e dal nome della fase e sono incluse nell'URL utilizzato per richiamare l'API. Ogni fase è un riferimento con nome a una distribuzione dell'API e viene resa disponibile per le applicazioni client da chiamare.
Una distribuzione è uno snapshot della configurazione dell'API. Dopo essere stata distribuita a una fase, l'API è disponibile per i client da richiamare. È necessario distribuire un'API per attivare le modifiche apportate.
## Variabili di fase
Le variabili di fase sono coppie chiave-valore che puoi definire per una fase di un' WebSocket API. Fungono da variabili di ambiente e possono essere utilizzate nella configurazione dell'API.
Ad esempio, puoi definire una variabile di fase e quindi impostare il suo valore come un endpoint HTTP per un'integrazione proxy HTTP. Successivamente, puoi fare riferimento all'endpoint utilizzando il nome della variabile di fase associata. In questo modo, puoi utilizzare la stessa configurazione API con un endpoint diverso in ogni fase. Allo stesso modo, puoi utilizzare le variabili di fase per specificare un'integrazione di AWS Lambda funzioni diversa per ogni fase dell'API.
**Nota**
Le variabili di fase non sono destinate ad essere utilizzate per i dati sensibili, come le credenziali. Per trasferire dati sensibili alle integrazioni, usa un AWS Lambda autorizzatore. È possibile passare dati sensibili alle integrazioni nell'output del provider di autorizzazioni Lambda. Per ulteriori informazioni, consulta [Formato della risposta dell'autorizzazione](http-api-lambda-authorizer.md#http-api-lambda-authorizer.payload-format-response).
### Esempi
Per utilizzare una variabile di fase per personalizzare l'endpoint di integrazione HTTP, è necessario innanzitutto impostare il nome e il valore della variabile di fase (ad esempio `url`) con un valore pari a `example.com`. Quindi, impostare un'integrazione proxy HTTP. Anziché inserire l'URL dell'endpoint, è possibile comunicare ad API Gateway di usare il valore della variabile di fase, ossi, **http://\$1\$1stageVariables.url\$1**. Questo valore indica ad API Gateway di sostituire la variabile di fase `${}` al runtime, a seconda della fase dell'API.
È possibile fare riferimento alle variabili di fase in modo simile per specificare il nome di una funzione Lambda o un ruolo AWS ARN.
Quando si specifica un nome di funzione Lambda come valore della variabile di fase, è necessario configurare manualmente le autorizzazioni per la funzione Lambda. Il comando [add-permission](https://docs.aws.amazon.com/cli/latest/reference/lambda/add-permission.html) seguente aggiunge le autorizzazioni richieste:
```
aws lambda add-permission --function-name arn:aws:lambda:XXXXXX:your-lambda-function-name --source-arn arn:aws:execute-api:us-east-1:YOUR_ACCOUNT_ID:api_id/*/HTTP_METHOD/resource --principal apigateway.amazonaws.com --statement-id apigateway-access --action lambda:InvokeFunction
```
## Riferimento alle variabili di fase di API Gateway
### Integrazione HTTP URIs
Puoi utilizzare una variabile di fase come parte di un URI di integrazione HTTP, come mostrato negli esempi seguenti.
+ Un URI completo senza protocoll – `http://${stageVariables.}`
+ Un dominio completo – `http://${stageVariables.}/resource/operation`
+ Un sottodominio – `http://${stageVariables.}.example.com/resource/operation`
+ Un percorso – `http://example.com/${stageVariables.}/bar`
+ Una stringa di query – `http://example.com/foo?q=${stageVariables.}`
### Funzioni Lambda
Puoi utilizzare una variabile di fase al posto di un nome di funzione o alias Lambda, come illustrato negli esempi seguenti.
+ `arn:aws:apigateway::lambda:path/2015-03-31/functions/arn:aws:lambda:::function:${stageVariables.}/invocations`
+ `arn:aws:apigateway::lambda:path/2015-03-31/functions/arn:aws:lambda:::function::${stageVariables.}/invocations`
**Nota**
Per utilizzare una variabile di fase per una funzione Lambda, la funzione deve essere nello stesso account dell'API. Le variabili di fase non supportano le funzioni Lambda tra più account.
### AWS credenziali di integrazione
È possibile utilizzare una variabile stage come parte di un ARN di credenziali AWS utente o di ruolo, come illustrato nell'esempio seguente.
+ `arn:aws:iam:::${stageVariables.}`
# Implementazione WebSocket APIs in API Gateway
Dopo aver creato l' WebSocket API, devi distribuirla per renderla disponibile per essere richiamata dagli utenti.
Per distribuire un'API, crea una [distribuzione API](api-gateway-basic-concept.md#apigateway-definition-api-deployment) e associala a una [fase](api-gateway-basic-concept.md#apigateway-definition-api-stage). Ogni fase è una snapshot dell'API ed è resa disponibile per essere chiamata dalle app client.
**Importante**
Ogni volta che aggiorni un'API, devi ripeterne l'implementazione. Le modifiche a qualcosa di diverso dalle impostazioni di fase richiedono una nuova implementazione, incluse le modifiche alle seguenti risorse:
Percorsi
Integrazioni
Autorizzatori
C'è un limite predefinito di 10 fasi per API. Si consiglia di riutilizzare le fasi per le implementazioni.
Per chiamare un' WebSocket API distribuita, il client invia un messaggio all'URL dell'API. L'URL viene determinato dal nome host e dal nome fase dell'API.
**Nota**
API Gateway supporta payload fino a 128 KB con dimensione del frame massima di 32 KB. Se un messaggio supera i 32 KB, deve essere suddiviso in più frame, ciascuno di 32 KB o più piccolo.
Utilizzando il nome di dominio predefinito dell'API, l'URL di (ad esempio) un' WebSocket API in una determinata fase (`{stageName}`) ha il seguente formato:
```
wss://{api-id}.execute-api.{region}.amazonaws.com/{stageName}
```
Per rendere l'URL dell' WebSocket API più intuitivo, puoi creare un nome di dominio personalizzato (ad esempio,`api.example.com`) per sostituire il nome host predefinito dell'API. Il processo di configurazione è lo stesso di REST APIs. Per ulteriori informazioni, consulta [Nome di dominio personalizzato per REST pubblico APIs in API Gateway](how-to-custom-domains.md).
Le fasi permettono un efficace controllo delle versioni dell'API. Ad esempio, puoi distribuire un'API in una fase `test` e una fase `prod` e utilizzare la fase `test` come build di test e la fase `prod` come build stabile. Dopo che gli aggiornamenti hanno superato il test, puoi promuovere la fase `test` alla fase `prod`. La promozione può essere eseguita ridistribuendo l'API nella fase `prod`. Per ulteriori dettagli sulle fasi, consulta [Configurazione di una fase per una REST API in Gateway API](set-up-stages.md).
**Topics**
+ [Crea una distribuzione WebSocket API utilizzando il AWS CLI](#apigateway-create-websocket-deployment-using-awscli)
+ [Creare una distribuzione WebSocket API utilizzando la console API Gateway](#apigateway-create-websocket-deployment-using-console)
## Crea una distribuzione WebSocket API utilizzando il AWS CLI
Il seguente comando [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-deployment.html) crea l'implementazione:
```
aws apigatewayv2 --region us-east-1 create-deployment --api-id aabbccddee
```
L'output sarà simile al seguente:
```
{
"DeploymentId": "fedcba",
"DeploymentStatus": "DEPLOYED",
"CreatedDate": "2018-11-15T06:49:09Z"
}
```
L'API distribuita non può essere chiamata fino a quando non si associa la distribuzione a una fase. Puoi creare una nuova fase o riutilizzare una fase creata in precedenza.
Il comando [create-stage](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-stage.html) seguente crea una nuova fase e la associa all’implementazione:
```
aws apigatewayv2 --region us-east-1 create-stage --api-id aabbccddee --deployment-id fedcba --stage-name test
```
L'output sarà simile al seguente:
```
{
"StageName": "test",
"CreatedDate": "2018-11-15T06:50:28Z",
"DeploymentId": "fedcba",
"DefaultRouteSettings": {
"MetricsEnabled": false,
"ThrottlingBurstLimit": 5000,
"DataTraceEnabled": false,
"ThrottlingRateLimit": 10000.0
},
"LastUpdatedDate": "2018-11-15T06:50:28Z",
"StageVariables": {},
"RouteSettings": {}
}
```
Puoi anche riutilizzare una fase esistente aggiornando la `deploymentId` proprietà della fase con l'ID di distribuzione appena creato (*deployment-id*). Il comando [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-stage.html) seguente aggiorna l’ID di implementazione della fase:
```
aws apigatewayv2 update-stage --region region \
--api-id api-id \
--stage-name stage-name \
--deployment-id deployment-id
```
## Creare una distribuzione WebSocket API utilizzando la console API Gateway
Per utilizzare la console API Gateway per creare una distribuzione per un' WebSocket API:
1. Accedere alla console API Gateway e scegliere l'API.
1. Seleziona **Deploy API (Distribuisci API)**.
1. Scegliere la fase desiderata dall'elenco a discesa oppure immettere il nome di una nuova fase.
# Politica di sicurezza per WebSocket APIs API Gateway
API Gateway applica una politica di sicurezza `TLS_1_2` per tutti gli endpoint WebSocket API.
Una *policy di sicurezza* è una combinazione predefinita di una versione TLS minima e un pacchetto di crittografia offerta da Gateway Amazon API. Il protocollo TLS affronta i problemi di sicurezza della rete, ad esempio manomissioni e intercettazioni tra un client e un server. Quando i client stabiliscono un handshake TLS sull'API tramite il dominio personalizzato, la policy di sicurezza applica la versione di TLS e le opzioni del pacchetto di crittografia che i client possono scegliere di utilizzare. Questa policy di sicurezza accetta il traffico TLS 1.2 e TLS 1.3 e rifiuta il traffico TLS 1.0.
## Protocolli e cifrari TLS supportati per WebSocket APIs
La tabella seguente descrive i protocolli TLS supportati per. WebSocket APIs
| **Protocolli TLS** | **Policy di sicurezza TLS\$11\$12** |
| --- | --- |
| TLSv13. | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| TLSv12. | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
La tabella seguente descrive i codici TLS disponibili per la politica di sicurezza TLS 1\$12 per. WebSocket APIs
| **Crittografie TLS** | **Policy di sicurezza TLS\$11\$12** |
| --- | --- |
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| TLS\$1 \$1 CHACHA20 POLY1305 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-ECDSA- -GCM- AES128 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDH-RSA- AES128 -GCM- SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-ECSA AES128 - - SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-RSA- - AES128 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-ECDSA- -GCM AES256 - SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDH-RSA- AES256 -GCM- SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-ECSA AES256 - - SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| ECDHE-RSA- - AES256 SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| AES128-GCM- SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| AES128-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| AES256-GCM- SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
| AES256-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/apigateway/latest/developerguide/images/success_icon.svg) Sì |
## OpenSSL e nomi crittografia RFC
OpenSSL e IETF RFC 5246 utilizzano nomi diversi per le stesse crittografie. Per l'elenco dei nomi delle crittografie, consulta [OpenSSL e nomi crittografia RFC](apigateway-security-policies-list.md#apigateway-secure-connections-openssl-rfc-cipher-names).
## Informazioni su REST APIs e HTTP APIs
Per ulteriori informazioni su REST APIs e HTTP APIs, vedere [Scegli una politica di sicurezza per il tuo dominio personalizzato in API Gateway](apigateway-custom-domain-tls-version.md) e[Politica di sicurezza per HTTP APIs in API Gateway](http-api-ciphers.md).
# Nomi di dominio personalizzati per API WebSocket in Gateway API
I *nomi di dominio personalizzati* sono URL più semplici e più intuitivi che è possibile fornire agli utenti delle API.
Dopo aver distribuito un'API, tu e i tuoi clienti potete richiamarla usando l'URL di base predefinito nel formato seguente:
```
https://api-id.execute-api.region.amazonaws.com/stage
```
dove *api-id* è generato da Gateway API, *region* è la Regione AWS e *stage* è il valore che è stato specificato al momento dell'implementazione dell'API.
La parte del nome host dell'URL, `api-id.execute-api.region.amazonaws.com`, fa riferimento a un endpoint API. Il nome dell'endpoint API predefinito viene generato casualmente, è complesso da richiamare e non è intuitivo.
Con i nomi di dominio personalizzati, è possibile impostare il nome host dell'API e scegliere un percorso base (ad esempio `myservice`) per mappare l'URL alternativo all'API. Ad esempio, un URL di base dell'API più intuitivo può diventare:
```
https://api.example.com/myservice
```
## Considerazioni
Le seguenti considerazioni potrebbero influire sull'utilizzo di un nome di dominio personalizzato.
+ Se un nome di dominio personalizzato viene mappato a un'API WebSocket, non può essere mappato a una REST API o a un'API HTTP.
+ Sono supportati solo i nomi di dominio personalizzati regionali.
+ L'unica versione minima di TLS supportata è TLS 1.2.
+ È necessario creare o aggiornare il record di risorse del provider DNS per eseguire la mappatura all'endpoint API. In assenza di questa mappatura, le richieste API destinate al nome di dominio personalizzato non possono raggiungere API Gateway.
+ È possibile supportare un numero pressoché infinito di nomi di dominio senza superare la quota predefinita con un certificato jolly. Per ulteriori informazioni, consulta [Nomi di dominio personalizzati con caratteri jolly](http-api-custom-domain-names.md#http-wildcard-custom-domain-names).
## Prerequisiti
Di seguito sono riportati i prerequisiti per un nome di dominio personalizzato.
### Registrare un nome di dominio
Per configurare nomi di dominio personalizzati per le API, devi avere un nome di dominio Internet registrato. Puoi registrare un nome di dominio Internet utilizzando [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) oppure un registrar di dominio di terze parti a tua scelta. Il nome di dominio personalizzato può essere il nome di un sottodominio o del dominio root (detto anche "apex di zona") di un dominio Internet registrato.
Il nome di dominio deve seguire la specifica [RFC 1035](https://tools.ietf.org/html/rfc1035#section-2.3.4) e può avere un massimo di 63 ottetti per etichetta e 255 ottetti in totale.
### Certificati per nomi di dominio personalizzati
Prima di configurare un nome di dominio personalizzato per un'API, è necessario che sia già presente un certificato SSL/TLS in ACM. Se ACM non è disponibile nella Regione AWS in cui si sta creando il nome di dominio personalizzato, è necessario importare nella Regione un certificato in Gateway API.
Per importare un certificato SSL/TLS, devi fornire il corpo del certificato SSL/TLS in formato PEM, la sua chiave privata e la catena di certificati per il nome di dominio personalizzato.
Ogni certificato archiviato in ACM è identificato dal relativo ARN. Con i certificati emessi da ACM, non devi preoccuparti di esporre dettagli sensibili del certificato, come la chiave privata. Per usare un certificato gestito da AWS per un nome di dominio, devi semplicemente fare riferimento al relativo ARN.
Se l’applicazione utilizza il blocco dei certificati, talvolta denominato associazione SSL, per associare un certificato ACM, è possibile che l'applicazione non riesca a connettersi al tuo dominio dopo che AWS ha rinnovato il certificato. Per ulteriori informazioni, consulta [Probemi nel blocco dei certificati](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-pinning.html) nella *Guida per l'utente di AWS Certificate Manager*.
## Nomi di dominio personalizzati con caratteri jolly
Con i nomi di dominio personalizzati con caratteri jolly, è possibile supportare un numero quasi infinito di nomi di dominio senza superare la [quota predefinita](limits.md). Ad esempio, è possibile dare a ciascuno dei clienti il proprio nome di dominio, `customername.api.example.com`.
Per creare un nome di dominio personalizzato con caratteri jolly, specificare un carattere jolly (`*`) come primo sottodominio di un dominio personalizzato che rappresenta tutti i possibili sottodomini di un dominio radice.
Ad esempio, il nome di dominio personalizzato con caratteri jolly `*.example.com` genera sottodomini quali `a.example.com`, `b.example.com` e `c.example.com`, indirizzati tutti allo stesso dominio.
I nomi di dominio personalizzati con caratteri jolly supportano configurazioni distinte dai nomi di dominio personalizzati standard di API Gateway. Ad esempio, in un singolo account AWS, è possibile configurare `*.example.com` e `a.example.com` affinché si comportino in modo diverso.
È possibile utilizzare le variabili di contesto `$context.domainName` e `$context.domainPrefix` per determinare il nome di dominio utilizzato da un client per chiamare l'API. Per ulteriori informazioni sulle variabili di contesto, consulta [Variabili per le trasformazioni dei dati per Gateway API](api-gateway-mapping-template-reference.md).
Per creare un nome di dominio personalizzato con caratteri jolly, è necessario fornire un certificato emesso da ACM che sia stato convalidato utilizzando il DNS o il metodo di convalida della posta elettronica.
**Nota**
Non è possibile creare un nome di dominio personalizzato con caratteri jolly se un account AWS diverso ha creato un nome di dominio personalizzato in conflitto con il nome di dominio personalizzato con caratteri jolly. Ad esempio, se l'account A ha creato `a.example.com`, l'account B non può creare il nome di dominio personalizzato con caratteri jolly `*.example.com`.
Se l'account A e l'account B condividono un proprietario, è possibile contattare il [Centro assistenza AWS](https://console.aws.amazon.com/support/home#/) per richiedere un'eccezione.
## Passaggi successivi per nomi di dominio personalizzati
Per configurare un nome di dominio personalizzato per un'API HTTP, consulta la documentazione disponibile nella sezione REST API della Guida per gli sviluppatori di Gateway API.
Per prima cosa, si specifica un certificato per il nome di dominio personalizzato. Per ulteriori informazioni, consulta [Prepara i certificati in AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md). Successivamente, si crea un nome di dominio personalizzato regionale. Per ulteriori informazioni, consulta [Configurazione di un nome di dominio personalizzato regionale in Gateway API](apigateway-regional-api-custom-domain-create.md).
# Mappatura delle fasi API a un nome di dominio personalizzato per le API WebSocket
È possibile utilizzare le mappature API per connettere le fasi API a un nome di dominio personalizzato. Dopo aver creato un nome di dominio e aver configurato i record DNS, è possibile utilizzare le mappature API per inviare il traffico alle API tramite il nome di dominio personalizzato.
Una mappatura API specifica un'API, una fase e, facoltativamente, un percorso da utilizzare per la mappatura. Ad esempio, è possibile mappare la fase `production` di un'API su `wss://api.example.com/orders`.
Prima di creare una mappatura API, è necessario disporre di un'API, di una fase e di un nome di dominio personalizzato. Per ulteriori informazioni sulla creazione di un nome di dominio personalizzato, consulta [Configurazione di un nome di dominio personalizzato regionale in Gateway API](apigateway-regional-api-custom-domain-create.md).
## Restrizioni
+ In una mappatura API, il nome di dominio personalizzato e le API mappate devono trovarsi nello stesso account AWS.
+ Le mappature API devono contenere solo lettere, numeri e i seguenti caratteri: `$-_.+!*'()`.
+ La lunghezza massima per il percorso in una mappatura API è di 300 caratteri.
+ Non è possibile mappare le API WebSocket allo stesso nome di dominio personalizzato di un'API HTTP o un'API REST.
+ Se si crea una mappatura API con più livelli, Gateway API converte tutti i nomi di intestazione in lettere minuscole.
## Creare una mappatura API
Per creare una mappatura API, innanzitutto è necessario creare un nome di dominio personalizzato, un'API e una fase. Per informazioni sulla creazione di un nome di dominio personalizzato, consulta [Configurazione di un nome di dominio personalizzato regionale in Gateway API](apigateway-regional-api-custom-domain-create.md).
------
#### [ Console di gestione AWS ]
**Per creare una mappatura API**
1. Accedere alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Scegliere **Nomi di dominio personalizzati**.
1. Selezionare un nome di dominio personalizzato già creato.
1. Scegliere **API mappings (mappature API)**.
1. Scegliere **Configure API mappings (Configura mappature API)**.
1. Scegliere **Add new mapping (Aggiungi nuova mappatura)**.
1. Immettere un'**API**, uno **Stage (Fase)**e, facoltativamente, un **Path (Percorso)**.
1. Selezionare **Salva**.
------
#### [ AWS CLI ]
Il comando [create-api-mapping](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api-mapping.html) seguente crea una mappatura API. In questo esempio, API Gateway invia le richieste `api.example.com/v1` all'API e alla fase specificate.
```
aws apigatewayv2 create-api-mapping \
--domain-name api.example.com \
--api-mapping-key v1 \
--api-id a1b2c3d4 \
--stage test
```
------
#### [ CloudFormation ]
Il seguente esempio di CloudFormation consente di creare una mappatura API.
```
MyApiMapping:
Type: 'AWS::ApiGatewayV2::ApiMapping'
Properties:
DomainName: api.example.com
ApiMappingKey: 'v1'
ApiId: !Ref MyApi
Stage: !Ref MyStage
```
------
# Tipi di indirizzo IP per nomi di dominio personalizzati per API WebSocket
Quando si crea un nome di dominio personalizzato, è possibile specificare il tipo di indirizzo IP che può invocare il dominio. È possibile scegliere IPv4 per risolvere gli indirizzi IPv4 per invocare il dominio oppure dualstack per consentire a entrambi gli indirizzi IPv4 e IPv6 di invocare il dominio. È consigliabile impostare il tipo di indirizzo IP su dualstack per ridurre l’esaurimento dello spazio IP o per il livello di sicurezza. Per ulteriori informazioni sui vantaggi del tipo di indirizzo IP dualstack, consultare [IPv6 on AWS](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/internet-protocol-version-6.html).
## Considerazioni sui tipi di indirizzo IP
Le seguenti considerazioni potrebbero influire sull’utilizzo dei tipi di indirizzo IP.
+ Il tipo di indirizzo IP predefinito per i nomi di dominio personalizzati di Gateway API è IPv4.
+ Per il nome di dominio personalizzato, non è necessario che tutte le API mappate ad esso abbiano lo stesso tipo di indirizzo IP. Se si disabilita l’endpoint API predefinito, si potrebbe influire sul modo in cui i chiamanti possono invocare l’API.
## Modifica del tipo di indirizzo IP del nome di dominio personalizzato
È possibile modificare il tipo di indirizzo IP aggiornando la configurazione dell’endpoint del nome di dominio. È possibile aggiornare la configurazione dell’endpoint utilizzando la Console di gestione AWS, AWS CLI, CloudFormation o un AWS SDK.
------
#### [ Console di gestione AWS ]
**Per modificare il tipo di indirizzo IP di un nome di dominio personalizzato**
1. Accedere alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Scegliere un nome di dominio personalizzato pubblico.
1. Scegliere **Configurazione endpoint**.
1. Per Tipo di indirizzo IP, selezionare **IPv4** o **Dualstack**.
1. Selezionare **Salva**.
------
#### [ AWS CLI ]
Il comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html) seguente aggiorna un’API in modo che abbia un tipo di indirizzo IP dualstack:
```
aws apigatewayv2 update-domain-name \
--domain-name dualstack.example.com \
--domain-name-configurations CertificateArn=arn:aws:acm:us-east-1:111122223333:certificate/abcd1234-5678-abc,IpAddressType=dualstack
```
L'output sarà simile al seguente:
```
{
"ApiMappingSelectionExpression": "$request.basepath",
"DomainName": "dualstack.example.com",
"DomainNameConfigurations": [
{
"ApiGatewayDomainName": "d-abcd1234.execute-api.us-east-1.amazonaws.com",
"CertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/abcd1234-5678-abc",
"DomainNameStatus": "AVAILABLE",
"EndpointType": "REGIONAL",
"HostedZoneId": "Z3LQWSYCGH4ADY",
"SecurityPolicy": "TLS_1_2",
"IpAddressType": "dualstack"
}
],
"Tags": {}
}
```
------
# Disabilita l'endpoint predefinito per WebSocket APIs
Per impostazione predefinita, i client possono richiamare l'API utilizzando l'endpoint `execute-api` generato da API Gateway per l'API. Per garantire che i client possano accedere all'API solo utilizzando un nome di dominio personalizzato con l'autenticazione TLS reciproca, disattivare l'endpoint `execute-api` predefinito. Quando si disattiva l'endpoint predefinito, questa operazione influisce su tutte le fasi di un'API.
La procedura seguente mostra come disabilitare l'endpoint predefinito per un' WebSocket API.
------
#### [ Console di gestione AWS ]
1. Accedi alla console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Scegli un'API. WebSocket
1. Scegli **Impostazioni API**.
1. In **Dettagli API** seleziona **Modifica**.
1. Per **Endpoint predefinito** seleziona **Inattivo**.
1. Scegli **Save changes** (Salva modifiche).
1. Nel pannello di navigazione principale scegli **Instradamenti**.
1. Scegli **Distribuzione**, quindi implementa nuovamente l'API o crea una nuova fase per rendere effettiva la modifica.
------
#### [ AWS CLI ]
Il seguente comando [update-api](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-api.html) disabilita l'endpoint predefinito per un'API: WebSocket
```
aws apigatewayv2 update-api \
--api-id abcdef123 \
--disable-execute-api-endpoint
```
Dopo aver disabilitato l'endpoint predefinito, è necessario distribuire l'API per rendere effettiva la modifica.
Il AWS CLI comando seguente crea una distribuzione.
```
aws apigatewayv2 create-deployment \
--api-id abcdef123 \
--stage-name dev
```
------