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à.
# Sicurezza in MemoryDB
La sicurezza del cloud AWS è la massima priorità. In qualità di AWS cliente, puoi beneficiare di un data center e di un'architettura di rete progettati per soddisfare i requisiti delle organizzazioni più sensibili alla sicurezza.
La sicurezza è una responsabilità condivisa tra AWS te e te. Il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/) descrive questo modello come sicurezza del cloud e sicurezza nel cloud:
+ **Sicurezza del cloud**: AWS è responsabile della protezione dell'infrastruttura che gestisce AWS i servizi nel AWS cloud. AWS ti fornisce anche servizi che puoi utilizzare in modo sicuro. I revisori esterni testano e verificano regolarmente l'efficacia della nostra sicurezza nell'ambito dei [AWS Programmi di AWS conformità dei Programmi di conformità](https://aws.amazon.com/compliance/programs/) dei di . Per ulteriori informazioni sui programmi di conformità che si applicano a MemoryDB, vedere [AWS Servizi nell'ambito del programma di conformitàAWS Servizi nell'ambito del programma](https://aws.amazon.com/compliance/services-in-scope/) conformità.
+ **Sicurezza nel cloud**: la tua responsabilità è determinata dal AWS servizio che utilizzi. Sei anche responsabile di altri fattori, tra cui la riservatezza dei dati, i tuoi requisiti aziendali e le leggi e le normative applicabili
Questa documentazione aiuta a capire come applicare il modello di responsabilità condivisa quando si utilizza MemoryDB. Mostra come configurare MemoryDB per soddisfare i tuoi obiettivi di sicurezza e conformità. Imparerai anche come utilizzare altri AWS servizi che ti aiutano a monitorare e proteggere le tue risorse di MemoryDB.
**Topics**
+ [Protezione dei dati](data-protection.md)
+ [Gestione dell’identità e degli accessi](iam.md)
+ [Registrazione di log e monitoraggio](monitoring-overview.md)
+ [Convalida della conformità](memorydb-compliance.md)
+ [Sicurezza dell'infrastruttura](infrastructure-security.md)
+ [Riservatezza del traffico Internet](Security.traffic.md)
+ [Aggiornamenti di servizio](service-updates.md)
# Protezione dei dati in MemoryDB
Il modello di [responsabilità AWS condivisa modello](https://aws.amazon.com/compliance/shared-responsibility-model/) di di si applica alla protezione dei dati in. Come descritto in questo modello, AWS è responsabile della protezione dell'infrastruttura globale che gestisce tutti i Cloud AWS. L’utente è responsabile del controllo dei contenuti ospitati su questa infrastruttura. L’utente è inoltre responsabile della configurazione della protezione e delle attività di gestione per i Servizi AWS utilizzati. Per maggiori informazioni sulla privacy dei dati, consulta le [Domande frequenti sulla privacy dei dati](https://aws.amazon.com/compliance/data-privacy-faq/). Per informazioni sulla protezione dei dati in Europa, consulta il post del blog relativo al [AWS Modello di responsabilità condivisa e GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) nel *AWS Blog sulla sicurezza*.
Ai fini della protezione dei dati, consigliamo di proteggere Account AWS le credenziali e configurare i singoli utenti con AWS IAM Identity Center or AWS Identity and Access Management (IAM). In tal modo, a ogni utente verranno assegnate solo le autorizzazioni necessarie per svolgere i suoi compiti. Suggeriamo, inoltre, di proteggere i dati nei seguenti modi:
+ Utilizza l’autenticazione a più fattori (MFA) con ogni account.
+ SSL/TLS Da utilizzare per comunicare con AWS le risorse. È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Configura l'API e la registrazione delle attività degli utenti con AWS CloudTrail. Per informazioni sull'utilizzo dei CloudTrail percorsi per acquisire AWS le attività, consulta [Lavorare con i CloudTrail percorsi](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) nella *Guida per l'AWS CloudTrail utente*.
+ Utilizza soluzioni di AWS crittografia, insieme a tutti i controlli di sicurezza predefiniti all'interno Servizi AWS.
+ Utilizza i servizi di sicurezza gestiti avanzati, come Amazon Macie, che aiutano a individuare e proteggere i dati sensibili archiviati in Amazon S3.
+ Se hai bisogno di moduli crittografici convalidati FIPS 140-3 per accedere AWS tramite un'interfaccia a riga di comando o un'API, usa un endpoint FIPS. Per ulteriori informazioni sugli endpoint FIPS disponibili, consulta il [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Ti consigliamo di non inserire mai informazioni riservate o sensibili, ad esempio gli indirizzi e-mail dei clienti, nei tag o nei campi di testo in formato libero, ad esempio nel campo **Nome**. Ciò include quando lavori o Servizi AWS utilizzi la console, l'API o. AWS CLI AWS SDKs I dati inseriti nei tag o nei campi di testo in formato libero utilizzati per i nomi possono essere utilizzati per i la fatturazione o i log di diagnostica. Quando si fornisce un URL a un server esterno, suggeriamo vivamente di non includere informazioni sulle credenziali nell’URL per convalidare la richiesta al server.
# Sicurezza dei dati in MemoryDB
Per proteggere i dati, MemoryDB e Amazon EC2 forniscono meccanismi di protezione contro l'accesso non autorizzato ai dati sul server.
MemoryDB fornisce anche funzionalità di crittografia per i dati sui cluster:
+ La crittografia dei dati in transito esegue la crittografia dei dati quando si spostano da una posizione a un'altra, ad esempio tra i nodi nel cluster o tra il cluster e l'applicazione.
+ La crittografia At-Rest crittografa il registro delle transazioni e i dati su disco durante le operazioni di snapshot.
Puoi anche utilizzarla [Autenticazione degli utenti con gli elenchi di controllo degli accessi () ACLs](clusters.acls.md) per controllare l'accesso degli utenti ai tuoi cluster.
**Topics**
+ [Sicurezza dei dati in MemoryDB](encryption.md)
+ [Crittografia At-Rest in MemoryDB](at-rest-encryption.md)
+ [Crittografia in transito (TLS) in MemoryDB](in-transit-encryption.md)
+ [Autenticazione degli utenti con gli elenchi di controllo degli accessi () ACLs](clusters.acls.md)
+ [Autenticazione con IAM](auth-iam.md)
# Crittografia At-Rest in MemoryDB
Per proteggere i dati, MemoryDB e Amazon S3 offrono diversi modi per limitare l'accesso ai dati nei cluster. Per ulteriori informazioni, consultare [MemoryDB e Amazon VPC](vpcs.md) e [Gestione delle identità e degli accessi in MemoryDB](iam.md).
La crittografia a riposo di MemoryDB è sempre abilitata per aumentare la sicurezza dei dati crittografando i dati persistenti. Crittografa i seguenti aspetti:
+ Dati nel registro delle transazioni
+ Disco durante le operazioni di sincronizzazione, istantanea e scambio
+ Istantanee archiviate in Amazon S3
MemoryDB offre la crittografia predefinita (gestita dal servizio) a riposo, oltre alla possibilità di utilizzare le proprie chiavi root simmetriche gestite dal cliente in [AWS Key](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) Management Service (KMS).
I dati archiviati su SSDs (unità a stato solido) in cluster abilitati alla suddivisione dei dati sono sempre crittografati per impostazione predefinita.
Per informazioni sulla crittografia dei dati in transito, consulta [Crittografia in transito (TLS) in MemoryDB](in-transit-encryption.md)
**Topics**
+ [Utilizzo delle chiavi gestite dai clienti di KMS AWS](#using-customer-managed-keys-for-memorydb-security)
+ [Vedi anche](#at-rest-encryption-see-also)
## Utilizzo delle chiavi gestite dai clienti di KMS AWS
MemoryDB supporta chiavi root simmetriche gestite dal cliente (chiave KMS) per la crittografia a riposo. Le chiavi KMS gestite dal cliente sono chiavi di crittografia che puoi creare, possedere e gestire nel tuo account. AWS Per ulteriori informazioni, consulta [Customer Root Keys nella AWS Key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys) *Management Service* Developer Guide. Le chiavi devono essere create in AWS KMS prima di poter essere utilizzate con MemoryDB.
Per informazioni su come creare le chiavi principali di AWS KMS, consulta [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *AWS Key Management* Service Developer Guide.
MemoryDB consente l'integrazione con KMS. AWS Per ulteriori informazioni, consulta [Utilizzo di concessioni](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) nella *AWS Guida per gli sviluppatori Key Management Service*. Non è necessaria alcuna azione da parte del cliente per abilitare l'integrazione di MemoryDB con KMS. AWS
La chiave `kms:ViaService` condition limita l'uso di una chiave AWS KMS alle richieste provenienti da servizi specifici. AWS Da utilizzare `kms:ViaService` con MemoryDB, includi entrambi i ViaService nomi nel valore della chiave di condizione:. `memorydb.amazon_region.amazonaws.com` Per ulteriori informazioni, vedere [kms:](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service). ViaService
Puoi usarlo [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)per tenere traccia delle richieste a cui MemoryDB invia per tuo AWS Key Management Service conto. Tutte le chiamate API AWS Key Management Service relative alle chiavi gestite dal cliente hanno i log corrispondenti CloudTrail . Puoi anche vedere le concessioni create da MemoryDB chiamando la chiamata all'[ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html)API KMS.
Una volta crittografato un cluster utilizzando una chiave gestita dal cliente, tutte le istantanee del cluster vengono crittografate come segue:
+ Le istantanee giornaliere automatiche vengono crittografate utilizzando la chiave gestita dal cliente associata al cluster.
+ L'istantanea finale creata quando il cluster viene eliminato viene inoltre crittografata utilizzando la chiave gestita dal cliente associata al cluster.
+ Le istantanee create manualmente sono crittografate per impostazione predefinita per utilizzare la chiave KMS associata al cluster. Puoi sostituirla scegliendo un'altra chiave gestita dal cliente.
+ Per impostazione predefinita, la copia di un'istantanea prevede l'utilizzo della chiave gestita dal cliente associata allo snapshot di origine. Puoi sostituirla scegliendo un'altra chiave gestita dal cliente.
**Nota**
Le chiavi gestite dal cliente non possono essere utilizzate per l'esportazione di istantanee nel bucket Amazon S3 selezionato. Tuttavia, tutte le istantanee esportate in Amazon S3 vengono crittografate [utilizzando](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html) la crittografia lato server. Puoi scegliere di copiare il file di istantanea su un nuovo oggetto S3 e cifrarlo utilizzando una chiave KMS gestita dal cliente, copiare il file in un altro bucket S3 configurato con crittografia predefinita utilizzando una chiave KMS o modificare un'opzione di crittografia nel file stesso.
Puoi anche utilizzare chiavi gestite dal cliente per crittografare istantanee create manualmente che non utilizzano chiavi gestite dal cliente per la crittografia. Con questa opzione, il file di snapshot archiviato in Amazon S3 viene crittografato utilizzando una chiave KMS, anche se i dati non sono crittografati nel cluster originale.
Il ripristino da un'istantanea consente di scegliere tra le opzioni di crittografia disponibili, simili alle scelte di crittografia disponibili durante la creazione di un nuovo cluster.
+ Se si elimina la chiave o si [disabilita](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) la chiave e si [revocano le concessioni](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) per la chiave utilizzata per crittografare un cluster, il cluster diventa irrecuperabile. In altre parole, non può essere modificato o ripristinato dopo un guasto hardware. AWS KMS elimina le chiavi principali solo dopo un periodo di attesa di almeno sette giorni. Dopo l'eliminazione della chiave, puoi utilizzare una chiave gestita dal cliente diversa per creare un'istantanea a scopo di archiviazione.
+ La rotazione automatica delle chiavi preserva le proprietà delle chiavi principali del AWS KMS, quindi la rotazione non ha alcun effetto sulla capacità di accedere ai dati di MemoryDB. I cluster MemoryDB crittografati non supportano la rotazione manuale delle chiavi, che comporta la creazione di una nuova chiave principale e l'aggiornamento di qualsiasi riferimento alla vecchia chiave. Per ulteriori informazioni, consulta [Rotating Customer Root Keys nella AWS Key](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) *Management* Service Developer Guide.
+ La crittografia di un cluster MemoryDB utilizzando la chiave KMS richiede una concessione per cluster. Questa concessione viene utilizzata per tutta la durata del cluster. Inoltre, durante la creazione di istantanee viene utilizzata una concessione per istantanea. Questa concessione viene ritirata una volta creata l'istantanea.
+ Per ulteriori informazioni su concessioni e limiti AWS KMS, consulta [Quotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) nella *AWS Key* Management Service Developer Guide.
## Vedi anche
+ [Crittografia in transito (TLS) in MemoryDB](in-transit-encryption.md)
+ [MemoryDB e Amazon VPC](vpcs.md)
+ [Gestione delle identità e degli accessi in MemoryDB](iam.md)
# Crittografia in transito (TLS) in MemoryDB
Per aiutarti a proteggere i tuoi dati, MemoryDB e Amazon EC2 forniscono meccanismi di protezione contro l'accesso non autorizzato ai tuoi dati sul server. Fornendo funzionalità di crittografia in transito, MemoryDB ti offre uno strumento che puoi usare per proteggere i tuoi dati quando vengono spostati da una posizione all'altra. Ad esempio, è possibile spostare i dati da un nodo primario a un nodo di replica di lettura all'interno di un cluster o tra il cluster e l'applicazione.
**Topics**
+ [Panoramica della crittografia dei dati in transito](#in-transit-encryption-overview)
+ [Consulta anche](#in-transit-encryption-see-also)
## Panoramica della crittografia dei dati in transito
La crittografia in transito di MemoryDB è una funzionalità che aumenta la sicurezza dei dati nei punti più vulnerabili, quando sono in transito da una posizione all'altra.
La crittografia in transito di MemoryDB implementa le seguenti funzionalità:
+ **Connessioni crittografate: sia le connessioni** server che quelle client sono crittografate con Transport Layer Security (TLS).
+ **Replica crittografata.**i dati che si spostano tra un nodo primario e nodi di replica vengono crittografati.
+ **Autenticazione del server**: i client possono autenticare che si stanno connettendo al server giusto.
A partire dal 20/07/2023, TLS 1.2 è la versione minima supportata per i cluster nuovi ed esistenti. Utilizza questo [link](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/) per ulteriori informazioni su TLS 1.2 all'indirizzo. AWS
Per ulteriori informazioni sulla connessione ai cluster MemoryDB, vedere. [Connessione ai nodi MemoryDB utilizzando redis-cli](getting-started.md#connect-tls)
## Consulta anche
+ [Crittografia At-Rest in MemoryDB](at-rest-encryption.md)
+ [Autenticazione degli utenti con elenchi di controllo degli accessi () ACLs](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html)
+ [MemoryDB e Amazon VPC](vpcs.md)
+ [Gestione delle identità e degli accessi in MemoryDB](iam.md)
# Autenticazione degli utenti con gli elenchi di controllo degli accessi () ACLs
È possibile autenticare gli utenti con gli elenchi di controllo degli accessi (). ACLs
ACLs consentono di controllare l'accesso al cluster raggruppando gli utenti. Queste liste di controllo degli accessi sono progettate per organizzare l'accesso ai cluster.
Con ACLs, si creano utenti e si assegnano loro autorizzazioni specifiche utilizzando una stringa di accesso, come descritto nella sezione successiva. Gli utenti vengono assegnati agli elenchi di controllo degli accessi allineati a un ruolo specifico (amministratori, risorse umane) che vengono quindi distribuiti in uno o più cluster di MemoryDB. In questo modo, è possibile stabilire limiti di sicurezza tra i client che utilizzano lo stesso cluster o gli stessi cluster di MemoryDB e impedire ai client di accedere ai dati degli altri.
ACLs sono progettati per supportare l'introduzione di [ACL](https://valkey.io/docs/topics/acl/) in Redis OSS 6. Quando si utilizza ACLs con il cluster MemoryDB, esistono alcune limitazioni:
+ Non è possibile specificare password in una stringa di accesso. Le password vengono impostate con [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html)o chiamate. [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html)
+ Per i diritti utente, si passa`on`e`off`come parte della stringa di accesso. Se nessuno dei due è specificato nella stringa di accesso, l'utente viene assegnato `off` e non dispone dei diritti di accesso al cluster.
+ Non è possibile utilizzare comandi proibiti. Se specifichi un comando proibito, verrà generata un'eccezione. Per un elenco di questi comandi, vedi[Comandi limitati](restrictedcommands.md).
+ Non è possibile utilizzare la`reset`come parte di una stringa di accesso. Si specificano le password con parametri API e MemoryDB gestisce le password. Pertanto, non è possibile utilizzare`reset`perché rimuoverebbe tutte le password per un utente.
+ [Redis OSS 6 introduce il comando ACL LIST.](https://valkey.io/commands/acl-list) Questo comando restituisce un elenco di utenti insieme alle regole ACL applicate a ciascun utente. MemoryDB supporta il `ACL LIST` comando, ma non include il supporto per gli hash delle password come fa Redis OSS. Con MemoryDB, è possibile utilizzare l'[DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html)operazione per ottenere informazioni simili, incluse le regole contenute nella stringa di accesso. Tuttavia, [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html)non recupera una password utente.
[https://valkey.io/commands/acl-users](https://valkey.io/commands/acl-users) MemoryDB non supporta nessun altro comando ACL basato sulla scrittura.
L'utilizzo ACLs con MemoryDB è descritto più dettagliatamente di seguito.
**Topics**
+ [Specifica delle autorizzazioni mediante una stringa di accesso](#access-string)
+ [Funzionalità di ricerca vettoriale](#access-vss)
+ [Applicazione ACLs a un cluster per MemoryDB](#rbac-using)
## Specifica delle autorizzazioni mediante una stringa di accesso
Per specificare le autorizzazioni per un cluster MemoryDB, si crea una stringa di accesso e la si assegna a un utente, utilizzando o. AWS CLI Console di gestione AWS
Le stringhe di accesso sono definite come un elenco di regole delimitate da spazi che vengono applicate all'utente. Essi definiscono quali comandi un utente può eseguire e quali chiavi un utente può operare. Per eseguire un comando, un utente deve avere accesso al comando in esecuzione e tutte le chiavi sono accessibili dal comando. Le regole vengono applicate da sinistra a destra in modo cumulativo ed è possibile utilizzare una stringa più semplice al posto di quella fornita in caso di ridondanze nella stringa fornita.
Per ulteriori informazioni sulla sintassi delle regole ACL, consulta [ACL](https://valkey.io/topics/acl).
Nell'esempio seguente, la stringa di accesso rappresenta un utente attivo con accesso a tutti i tasti e i comandi disponibili.
`on ~* &* +@all`
La sintassi della stringa di accesso è suddivisa come segue:
+ `on`— L'utente è un utente attivo.
+ `~*`— L'accesso è dato a tutte le chiavi disponibili.
+ `&*`— L'accesso è dato a tutti i canali pubsub.
+ `+@all`— Accesso a tutti i comandi disponibili.
Le impostazioni precedenti sono le meno restrittive. È possibile modificare queste impostazioni per renderle più sicure.
Nell'esempio seguente, la stringa di accesso rappresenta un utente con accesso limitato all'accesso in lettura sulle chiavi che iniziano con lo spazio delle chiavi «app::»
`on ~app::* -@all +@read`
È possibile perfezionare ulteriormente queste autorizzazioni elencando i comandi a cui l'utente ha accesso:
`+command1`— L'accesso dell'utente ai comandi è limitato a*`command1`*.
`+@category`— L'accesso dell'utente è limitato a una categoria di comandi.
Per informazioni sull'assegnazione di una stringa di accesso a un utente, vedere[Creazione di utenti ed elenchi di controllo degli accessi con la console e la CLI](#users-management).
Se stai migrando un carico di lavoro esistente su MemoryDB, puoi recuperare la stringa di accesso chiamando`ACL LIST`, escludendo l'utente e qualsiasi hash della password.
## Funzionalità di ricerca vettoriale
Infatti[Ricerca vettoriale](vector-search.md), tutti i comandi di ricerca appartengono alla `@search` categoria e alle categorie `@read` esistenti `@fast` e `@slow` vengono aggiornati per includere i comandi di ricerca. `@write` Se un utente non ha accesso a una categoria, non ha accesso a nessun comando all'interno della categoria. Ad esempio, se l'utente non ha accesso a`@search`, non può eseguire alcun comando relativo alla ricerca.
La tabella seguente indica la mappatura dei comandi di ricerca alle categorie appropriate.
| Comandi VSS | @read | @write | @fast | @slow |
| --- | --- | --- | --- | --- |
| FT.CREATE | | Y | Y | |
| FT.DROPINDEX | | Y | Y | |
| FT.LIST | Y | | | Y |
| FT.INFO | Y | | Y | |
| FT.SEARCH | Y | | | Y |
| FT.AGGREGATE | Y | | | Y |
| FT.PROFILE | Y | | | Y |
| FT.ALIASADD | | Y | Y | |
| FT.ALIASDEL | | Y | Y | |
| FT.ALIASUPDATE | | Y | Y | |
| FT.\$1ALIASLIST | Y | | | Y |
| FT.EXPLAIN | Y | | Y | |
| FT.EXPLAINCLI | Y | | Y | |
| FT.CONFIG | Y | | Y | |
## Applicazione ACLs a un cluster per MemoryDB
Per utilizzare MemoryDB ACLs, procedi nel seguente modo:
1. Crea uno o più utenti.
1. Crea un ACL e aggiungi utenti all'elenco.
1. Assegna l'ACL a un cluster.
La tabella seguente descrive i seguenti passaggi nel dettaglio.
**Topics**
+ [Creazione di utenti ed elenchi di controllo degli accessi con la console e la CLI](#users-management)
+ [Gestione degli elenchi di controllo degli accessi con la console e la CLI](#user-groups)
+ [Assegnazione delle liste di controllo degli accessi ai cluster](#users-groups-to-clusterss)
### Creazione di utenti ed elenchi di controllo degli accessi con la console e la CLI
Le informazioni utente per ACLs gli utenti sono un nome utente e, facoltativamente, una password e una stringa di accesso. La stringa di accesso fornisce il livello di autorizzazione per i tasti e i comandi. Il nome è univoco per l'utente ed è quello che viene passato al motore.
Assicurati che le autorizzazioni utente fornite corrispondano allo scopo previsto dell'ACL. Ad esempio, se crei un ACL chiamato`Administrators`, qualsiasi utente aggiunto a quel gruppo dovrebbe avere la stringa di accesso impostata per l'accesso completo a tasti e comandi. Per gli utenti di un `e-commerce` ACL, è possibile impostare le stringhe di accesso in sola lettura.
MemoryDB configura automaticamente un utente predefinito per account con un nome utente. `"default"` Non sarà associato a nessun cluster a meno che non venga aggiunto esplicitamente a un ACL. Non è possibile eliminare o modificare questo utente. Questo utente è progettato per garantire la compatibilità con il comportamento predefinito delle versioni precedenti di Redis OSS e dispone di una stringa di accesso che gli consente di chiamare tutti i comandi e accedere a tutte le chiavi.
Verrà creato un ACL immutabile «ad accesso aperto» per ogni account che contiene l'utente predefinito. Questa è l'unica ACL di cui l'utente predefinito può essere membro. Quando si crea un cluster, è necessario selezionare un ACL da associare al cluster. Sebbene sia possibile applicare l'ACL «ad accesso aperto» all'utente predefinito, consigliamo vivamente di creare un ACL con utenti con autorizzazioni limitate alle esigenze aziendali.
I cluster che non hanno TLS abilitato devono utilizzare l'ACL «ad accesso aperto» per fornire un'autenticazione aperta.
ACLs possono essere creati senza utenti. Un ACL vuoto non avrebbe accesso a un cluster e può essere associato solo a cluster abilitati per TLS.
Quando si crea un utente, è possibile impostare fino a due password. Quando si modifica una password, vengono mantenute tutte le connessioni esistenti ai cluster.
In particolare, tenete presente questi vincoli relativi alla password utente quando utilizzate ACLs for MemoryDB:
+ Le password devono essere da 16 a 128 caratteri stampabili.
+ I seguenti caratteri non alfanumerici non sono consentiti:`,` `""` `/` `@`.
#### Gestione degli utenti con la console e la CLI
##### Creazione di un utente (Console)
**Per creare utenti sulla console**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. **Nel riquadro di navigazione a sinistra, scegli Utenti.**
1. Scegli **Crea utente**.
1. Nella pagina **Crea utente**, inserisci un **nome**.
I vincoli di denominazione dei cluster sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
1. In **Password**, puoi inserire fino a due password.
1. In Stringa di **accesso, inserisci una stringa** di accesso. La stringa di accesso imposta il livello di autorizzazione per le chiavi e i comandi consentiti all'utente.
1. Per i **tag**, puoi facoltativamente applicare tag per cercare e filtrare gli utenti o tenere traccia AWS dei costi.
1. Scegli **Create** (Crea).
##### Creazione di un utente utilizzando il AWS CLI
**Per creare un utente utilizzando la CLI**
+ Utilizzate il comando [create-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-user.html) per creare un utente.
Per Linux, macOS o Unix:
```
aws memorydb create-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode \
Passwords="abc",Type=password
```
Per Windows:
```
aws memorydb create-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode \
Passwords="abc",Type=password
```
##### Modifica di un utente (Console)
**Per modificare gli utenti sulla console**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. **Nel riquadro di navigazione a sinistra, scegli Utenti.**
1. Scegli il pulsante di opzione accanto all'utente che desideri modificare, quindi scegli **Azioni** -> **Modifica**
1. Se desideri modificare una password, scegli il pulsante di opzione **Modifica password**. Nota che se hai due password, devi inserirle entrambe quando ne modifichi una.
1. Se stai aggiornando la stringa di accesso, inserisci quella nuova.
1. Scegli **Modifica**.
##### Modificare un utente utilizzando AWS CLI
**Per modificare un utente utilizzando la CLI;**
1. Usa il comando [update-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-user.html) per modificare un utente.
1. Quando un utente viene modificato, gli elenchi di controllo degli accessi associati all'utente vengono aggiornati, insieme a tutti i cluster associati all'ACL. Tutte le connessioni esistenti vengono mantenute. Di seguito vengono mostrati gli esempi.
Per Linux, macOS o Unix:
```
aws memorydb update-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*"
```
Per Windows:
```
aws memorydb update-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*"
```
##### Visualizzazione dei dettagli dell'utente (Console)
**Per visualizzare i dettagli dell'utente sulla console**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. **Nel riquadro di navigazione a sinistra, scegli Utenti.**
1. Scegli l'utente in **Nome utente** o utilizza la casella di ricerca per trovare l'utente.
1. In **Impostazioni utente** puoi controllare la stringa di accesso, il numero di password, lo stato e l'Amazon Resource Name (ARN) dell'utente.
1. In **Access control lists (ACL)** puoi controllare l'ACL a cui appartiene l'utente.
1. In **Tag** puoi rivedere tutti i tag associati all'utente.
##### Visualizzazione dei dettagli dell'utente utilizzando il AWS CLI
Utilizzare il comando [describe-users](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-users.html) per visualizzare i dettagli di un utente.
```
aws memorydb describe-users \
--user-name my-user-name
```
##### Eliminazione di un utente (Console)
**Per eliminare utenti dalla console**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. **Nel riquadro di navigazione a sinistra, scegli Utenti.**
1. Scegli il pulsante di opzione accanto all'utente che desideri modificare, quindi scegli **Azioni** -> **Elimina**
1. Per confermare, inserisci `delete` nella casella di testo di conferma, quindi scegli **Elimina**.
1. Per annullare, scegliere **Cancel (Annulla)**.
##### Eliminazione di un utente utilizzando il AWS CLI
**Per eliminare un utente utilizzando la CLI;**
+ Utilizzare il comando [delete-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-user.html) per eliminare un utente.
L'account viene eliminato e rimosso da tutti gli elenchi di controllo degli accessi a cui appartiene. Di seguito è riportato un esempio di :
Per Linux, macOS o Unix:
```
aws memorydb delete-user \
--user-name user-name-2
```
Per Windows:
```
aws memorydb delete-user ^
--user-name user-name-2
```
### Gestione degli elenchi di controllo degli accessi con la console e la CLI
È possibile creare elenchi di controllo degli accessi per organizzare e controllare l'accesso degli utenti a uno o più cluster, come illustrato di seguito.
Utilizzare la procedura seguente per gestire gli elenchi di controllo degli accessi utilizzando la console.
#### Creazione di una lista di controllo degli accessi (ACL) (console)
**Per creare un elenco di controllo degli accessi utilizzando la console**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Nel riquadro di navigazione a sinistra, scegli **Access control lists (ACL)**.
1. Scegli **Crea ACL**.
1. Nella pagina **Crea lista di controllo di accesso (ACL)**, inserisci un nome ACL.
I vincoli di denominazione dei cluster sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
1. In **Utenti selezionati**, esegui una delle seguenti operazioni:
1. Crea un nuovo utente selezionando **Crea utente**
1. Aggiungi utenti scegliendo **Gestisci**, quindi selezionando gli utenti dalla finestra di dialogo **Gestisci utenti** e quindi selezionando **Scegli**.
1. Per i **tag**, puoi opzionalmente applicare tag per cercare e filtrare ACLs o tenere traccia AWS dei costi.
1. Scegli **Create** (Crea).
#### Creazione di una lista di controllo degli accessi (ACL) utilizzando AWS CLI
Utilizzare le seguenti procedure per creare un elenco di controllo degli accessi utilizzando la CLI.
**Per creare un nuovo ACL e aggiungere un utente utilizzando la CLI**
+ Utilizzate il comando [create-acl per creare un ACL](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-acl.html).
Per Linux, macOS o Unix:
```
aws memorydb create-acl \
--acl-name "new-acl-1" \
--user-names "user-name-1" "user-name-2"
```
Per Windows:
```
aws memorydb create-acl ^
--acl-name "new-acl-1" ^
--user-names "user-name-1" "user-name-2"
```
#### Modifica di una lista di controllo degli accessi (ACL) (console)
**Per modificare un elenco di controllo degli accessi utilizzando la console**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Nel riquadro di navigazione a sinistra, scegli **Access control lists (ACL)**.
1. **Scegli l'ACL che desideri modificare, quindi scegli Modifica**
1. Nella pagina **Modifica**, in **Utenti selezionati**, esegui una delle seguenti operazioni:
1. Crea un nuovo utente scegliendo **Crea utente** da aggiungere all'ACL.
1. **Aggiungi o rimuovi utenti scegliendo **Gestisci**, quindi selezionando o deselezionando gli utenti dalla finestra di dialogo **Gestisci utenti** e quindi selezionando Scegli.**
1. Nella pagina **Crea lista di controllo degli accessi (ACL)**, inserisci un nome ACL.
I vincoli di denominazione dei cluster sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
1. In **Utenti selezionati**, esegui una delle seguenti operazioni:
1. Crea un nuovo utente selezionando **Crea utente**
1. Aggiungi utenti scegliendo **Gestisci**, quindi selezionando gli utenti dalla finestra di dialogo **Gestisci utenti** e quindi selezionando **Scegli**.
1. Scegli **Modifica** per salvare le modifiche o **Annulla** per eliminarle.
#### Modifica di una lista di controllo degli accessi (ACL) utilizzando il AWS CLI
**Per modificare un ACL aggiungendo nuovi utenti o rimuovendo i membri correnti utilizzando la CLI**
+ Utilizzate il comando [update-acl per modificare un ACL](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-acl.html).
Per Linux, macOS o Unix:
```
aws memorydb update-acl --acl-name new-acl-1 \
--user-names-to-add user-name-3 \
--user-names-to-remove user-name-2
```
Per Windows:
```
aws memorydb update-acl --acl-name new-acl-1 ^
--user-names-to-add user-name-3 ^
--user-names-to-remove user-name-2
```
**Nota**
Tutte le connessioni aperte appartenenti a un utente rimosso da un ACL vengono terminate con questo comando.
#### Visualizzazione dei dettagli dell'Access Control List (ACL) (Console)
**Per visualizzare i dettagli ACL sulla console**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Nel riquadro di navigazione a sinistra, scegli **Access control lists (ACL)**.
1. Scegli l'ACL sotto il **nome ACL** o usa la casella di ricerca per trovare l'ACL.
1. In **Utenti** puoi visualizzare l'elenco degli utenti associati all'ACL.
1. In **Cluster associati** è possibile esaminare il cluster a cui appartiene l'ACL.
1. In **Tag** è possibile esaminare tutti i tag associati all'ACL.
#### Visualizzazione degli elenchi di controllo degli accessi (ACL) utilizzando il AWS CLI
Utilizzate il comando [describe-acls](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-acls.html) per visualizzare i dettagli di un ACL.
```
aws memorydb describe-acls \
--acl-name test-group
```
#### Eliminazione di un Access Control List (ACL) (console)
**Per eliminare gli elenchi di controllo degli accessi utilizzando la console**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Nel riquadro di navigazione a sinistra, scegli **Access control lists (ACL)**.
1. **Scegli l'ACL che desideri modificare, quindi scegli Elimina**
1. Nella pagina **Elimina**, inserisci `delete` la casella di conferma e scegli **Elimina** o **Annulla** per evitare di eliminare l'ACL.
L'ACL stesso, non gli utenti appartenenti al gruppo, viene eliminato.
#### Eliminazione di una lista di controllo degli accessi (ACL) utilizzando AWS CLI
**Per eliminare un ACL utilizzando la CLI**
+ Utilizzate il comando [delete-acl per eliminare un ACL](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-acl.html).
Per Linux, macOS o Unix:
```
aws memorydb delete-acl /
--acl-name
```
Per Windows:
```
aws memorydb delete-acl ^
--acl-name
```
Gli esempi precedenti restituiscono la risposta seguente.
```
aws memorydb delete-acl --acl-name "new-acl-1"
{
"ACLName": "new-acl-1",
"Status": "deleting",
"EngineVersion": "6.2",
"UserNames": [
"user-name-1",
"user-name-3"
],
"clusters": [],
"ARN":"arn:aws:memorydb:us-east-1:493071037918:acl/new-acl-1"
}
```
### Assegnazione delle liste di controllo degli accessi ai cluster
Dopo aver creato un ACL e aggiunto gli utenti, il passaggio finale dell'implementazione ACLs consiste nell'assegnare l'ACL a un cluster.
#### Assegnazione degli elenchi di controllo degli accessi ai cluster tramite la console
Per aggiungere un ACL a un cluster utilizzando il Console di gestione AWS, vedere. [Creazione di un cluster MemoryDB](getting-started.md#clusters.create)
#### Assegnazione delle liste di controllo degli accessi ai cluster Utilizzando il AWS CLI
La seguente AWS CLI operazione crea un cluster con la crittografia in transito (TLS) abilitata e il **acl-name** parametro con il valore. `my-acl-name` Sostituisci il gruppo di sottoreti `subnet-group` con uno esistente.
**Parametri chiave**
+ **--engine-version**— Deve essere 6.2.
+ **--tls-enabled**— Utilizzato per l'autenticazione e per associare un ACL.
+ **--acl-name**— Questo valore fornisce elenchi di controllo degli accessi composti da utenti con autorizzazioni di accesso specifiche per il cluster.
Per Linux, macOS o Unix:
```
aws memorydb create-cluster \
--cluster-name "new-cluster" \
--description "new-cluster" \
--engine-version "6.2" \
--node-type db.r6g.large \
--tls-enabled \
--acl-name "new-acl-1" \
--subnet-group-name "subnet-group"
```
Per Windows:
```
aws memorydb create-cluster ^
--cluster-name "new-cluster" ^
--cluster-description "new-cluster" ^
--engine-version "6.2" ^
--node-type db.r6g.large ^
--tls-enabled ^
--acl-name "new-acl-1" ^
--subnet-group-name "subnet-group"
```
La seguente AWS CLI operazione modifica un cluster con la crittografia in transito (TLS) abilitata e il **acl-name** parametro con il valore. `new-acl-2`
Per Linux, macOS o Unix:
```
aws memorydb update-cluster \
--cluster-name cluster-1 \
--acl-name "new-acl-2"
```
Per Windows:
```
aws memorydb update-cluster ^
--cluster-name cluster-1 ^
--acl-name "new-acl-2"
```
# Autenticazione con IAM
**Topics**
+ [Panoramica di](#auth-iam-overview)
+ [Limitazioni](#auth-iam-limits)
+ [Configurazione](#auth-iam-setup)
+ [Connessione](#auth-iam-Connecting)
## Panoramica di
Con IAM Authentication puoi autenticare una connessione a MemoryDB utilizzando identità AWS IAM, quando il cluster è configurato per utilizzare Valkey o Redis OSS versione 7 o successiva. Ciò consente di consolidare il modello di sicurezza e semplificare molte attività di sicurezza amministrative. Con IAM Authentication puoi configurare un controllo granulare degli accessi per ogni singolo cluster di MemoryDB e utente di MemoryDB e seguire i principi delle autorizzazioni con privilegi minimi. L'autenticazione IAM per MemoryDB funziona fornendo un token di autenticazione IAM di breve durata anziché una password utente MemoryDB di lunga durata nel comando or. `AUTH` `HELLO` Per ulteriori informazioni sul token di autenticazione IAM, consulta il [processo di firma Signature Version 4](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html) nella AWS General Reference Guide e l'esempio di codice riportato di seguito.
Puoi utilizzare le identità IAM e le relative politiche associate per limitare ulteriormente l'accesso a Valkey o Redis OSS. Puoi anche concedere l'accesso agli utenti dei loro provider di identità federati direttamente ai cluster MemoryDB.
Per utilizzare AWS IAM con MemoryDB, devi prima creare un utente MemoryDB con la modalità di autenticazione impostata su IAM, quindi puoi creare o riutilizzare un'identità IAM. L'identità IAM necessita di una policy associata per concedere l'`memorydb:Connect`azione al cluster MemoryDB e all'utente MemoryDB. Una volta configurato, puoi creare un token di autenticazione IAM utilizzando AWS le credenziali dell'utente o del ruolo IAM. Infine, è necessario fornire il token di autenticazione IAM di breve durata come password nel client Valkey o Redis OSS quando ci si connette al nodo del cluster MemoryDB. Un client con supporto per il provider di credenziali può generare automaticamente le credenziali temporanee per ogni nuova connessione. MemoryDB eseguirà l'autenticazione IAM per le richieste di connessione degli utenti di MemoryDB abilitati a IAM e convaliderà le richieste di connessione con IAM.
## Limitazioni
Durante l'utilizzo dell'autenticazione IAM, valgono le seguenti limitazioni:
+ L'autenticazione IAM è disponibile quando si utilizza la versione 7.0 o successiva del motore Valkey o Redis OSS.
+ Il token di autenticazione IAM è valido per 15 minuti. Per connessioni di lunga durata, consigliamo di utilizzare un client Redis OSS che supporti un'interfaccia con un provider di credenziali.
+ Una connessione autenticata IAM a MemoryDB verrà automaticamente disconnessa dopo 12 ore. La connessione può essere prolungata per 12 ore inviando un comando `AUTH` o `HELLO` con un nuovo token di autenticazione IAM.
+ L'autenticazione IAM non è supportata nei comandi `MULTI EXEC`.
+ Attualmente, l'autenticazione IAM non supporta nessuna delle chiavi di contesto delle condizioni globali. Per ulteriori informazioni sulle chiavi di contesto delle condizioni globali, consultare [Chiavi di contesto delle condizioni globali AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) nella Guida per l'utente di IAM.
## Configurazione
Per impostare l'autenticazione IAM:
1. Creazione di un cluster
```
aws memorydb create-cluster \
--cluster-name cluster-01 \
--description "MemoryDB IAM auth application"
--node-type db.r6g.large \
--engine-version 7.0 \
--acl-name open-access
```
1. Crea un documento della policy di attendibilità IAM per il ruolo, come mostrato di seguito, che consenta all'account di assumere il nuovo ruolo. Salva la policy in un file denominato *trust-policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole"
}
}
```
------
1. Crea un documento della policy IAM, come mostrato di seguito. Salva la policy in un file denominato *policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect" : "Allow",
"Action" : [
"memorydb:connect"
],
"Resource" : [
"arn:aws:memorydb:us-east-1:123456789012:cluster/cluster-01",
"arn:aws:memorydb:us-east-1:123456789012:user/iam-user-01"
]
}
]
}
```
------
1. Crea un ruolo IAM.
```
aws iam create-role \
--role-name "memorydb-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. Creare la policy IAM.
```
aws iam create-policy \
--policy-name "memorydb-allow-all" \
--policy-document file://policy.json
```
1. Allega la policy IAM al ruolo.
```
aws iam attach-role-policy \
--role-name "memorydb-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/memorydb-allow-all"
```
1. Crea un nuovo utente attivato da IAM.
```
aws memorydb create-user \
--user-name iam-user-01 \
--authentication-mode Type=iam \
--access-string "on ~* +@all"
```
1. Crea un ACL e collega l'utente.
```
aws memorydb create-acl \
--acl-name iam-acl-01 \
--user-names iam-user-01
aws memorydb update-cluster \
--cluster-name cluster-01 \
--acl-name iam-acl-01
```
## Connessione
**Connetti con token come password**
È innanzitutto necessario generare il token di autenticazione IAM di breve durata utilizzando una [richiesta prefirmata AWS SigV4](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html). Dopodiché, fornisci il token di autenticazione IAM come password quando ti connetti a un cluster MemoryDB, come mostrato nell'esempio seguente.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request and signed it using the AWS credentials.
// The pre-signed request URL is used as an IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
String iamAuthToken = iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(userName, iamAuthToken)
.build();
// Create a new Lettuce client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Di seguito è riportata la definizione per `IAMAuthTokenRequest`.
```
public class IAMAuthTokenRequest {
private static final HttpMethodName REQUEST_METHOD = HttpMethodName.GET;
private static final String REQUEST_PROTOCOL = "http://";
private static final String PARAM_ACTION = "Action";
private static final String PARAM_USER = "User";
private static final String ACTION_NAME = "connect";
private static final String SERVICE_NAME = "memorydb";
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final String userName;
private final String clusterName;
private final String region;
public IAMAuthTokenRequest(String userName, String clusterName, String region) {
this.userName = userName;
this.clusterName = clusterName;
this.region = region;
}
public String toSignedRequestUri(AWSCredentials credentials) throws URISyntaxException {
Request request = getSignableRequest();
sign(request, credentials);
return new URIBuilder(request.getEndpoint())
.addParameters(toNamedValuePair(request.getParameters()))
.build()
.toString()
.replace(REQUEST_PROTOCOL, "");
}
private Request getSignableRequest() {
Request request = new DefaultRequest<>(SERVICE_NAME);
request.setHttpMethod(REQUEST_METHOD);
request.setEndpoint(getRequestUri());
request.addParameters(PARAM_ACTION, Collections.singletonList(ACTION_NAME));
request.addParameters(PARAM_USER, Collections.singletonList(userName));
return request;
}
private URI getRequestUri() {
return URI.create(String.format("%s%s/", REQUEST_PROTOCOL, clusterName));
}
private void sign(SignableRequest request, AWSCredentials credentials) {
AWS4Signer signer = new AWS4Signer();
signer.setRegionName(region);
signer.setServiceName(SERVICE_NAME);
DateTime dateTime = DateTime.now();
dateTime = dateTime.plus(Duration.standardSeconds(TOKEN_EXPIRY_SECONDS));
signer.presignRequest(request, credentials, dateTime.toDate());
}
private static List toNamedValuePair(Map> in) {
return in.entrySet().stream()
.map(e -> new BasicNameValuePair(e.getKey(), e.getValue().get(0)))
.collect(Collectors.toList());
}
}
```
**Connetti con provider di credenziali**
Il codice seguente mostra come autenticarsi con MemoryDB utilizzando il provider di credenziali di autenticazione IAM.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request. Once this request is signed it can be used as an
// IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
// Create a credentials provider using IAM credentials.
RedisCredentialsProvider redisCredentialsProvider = new RedisIAMAuthCredentialsProvider(
userName, iamAuthTokenRequest, awsCredentialsProvider);
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(redisCredentialsProvider)
.build();
// Create a new Lettuce cluster client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Di seguito è riportato un esempio di client cluster Lettuce che lo inserisce IAMAuth TokenRequest in un provider di credenziali per generare automaticamente credenziali temporanee quando necessario.
```
public class RedisIAMAuthCredentialsProvider implements RedisCredentialsProvider {
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final AWSCredentialsProvider awsCredentialsProvider;
private final String userName;
private final IAMAuthTokenRequest iamAuthTokenRequest;
private final Supplier iamAuthTokenSupplier;
public RedisIAMAuthCredentialsProvider(String userName,
IAMAuthTokenRequest iamAuthTokenRequest,
AWSCredentialsProvider awsCredentialsProvider) {
this.userName = userName;
this.awsCredentialsProvider = awsCredentialsProvider;
this.iamAuthTokenRequest = iamAuthTokenRequest;
this.iamAuthTokenSupplier = Suppliers.memoizeWithExpiration(this::getIamAuthToken, TOKEN_EXPIRY_SECONDS, TimeUnit.SECONDS);
}
@Override
public Mono resolveCredentials() {
return Mono.just(RedisCredentials.just(userName, iamAuthTokenSupplier.get()));
}
private String getIamAuthToken() {
return iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
}
```
# Gestione delle identità e degli accessi in MemoryDB
AWS Identity and Access Management (IAM) è un programma Servizio AWS che aiuta un amministratore a controllare in modo sicuro l'accesso alle risorse. AWS Gli amministratori IAM controllano chi può essere *autenticato* (effettuato l'accesso) e *autorizzato (disporre delle autorizzazioni*) a utilizzare le risorse MemoryDB. IAM è uno strumento Servizio AWS che puoi utilizzare senza costi aggiuntivi.
**Topics**
+ [Destinatari](#security_iam_audience)
+ [Autenticazione con identità](#security_iam_authentication)
+ [Gestione dell’accesso tramite policy](#security_iam_access-manage)
+ [Come funziona MemoryDB con IAM](security_iam_service-with-iam.md)
+ [Esempi di policy basate sull'identità per MemoryDB](security_iam_id-based-policy-examples.md)
+ [Risoluzione dei problemi relativi all'identità e all'accesso a MemoryDB](security_iam_troubleshoot.md)
+ [Controllo accessi](#iam.accesscontrol)
+ [Panoramica sulla gestione delle autorizzazioni di accesso alle risorse di MemoryDB](iam.overview.md)
## Destinatari
Il modo in cui utilizzi AWS Identity and Access Management (IAM) varia in base al tuo ruolo:
+ **Utente del servizio**: richiedi le autorizzazioni all’amministratore se non riesci ad accedere alle funzionalità (consulta [Risoluzione dei problemi relativi all'identità e all'accesso a MemoryDB](security_iam_troubleshoot.md))
+ **Amministratore del servizio**: determina l’accesso degli utenti e invia le richieste di autorizzazione (consulta [Come funziona MemoryDB con IAM](security_iam_service-with-iam.md))
+ **Amministratore IAM**: scrivi policy per gestire l’accesso (consulta [Esempi di policy basate sull'identità per MemoryDB](security_iam_id-based-policy-examples.md))
## Autenticazione con identità
L'autenticazione è il modo in cui accedi AWS utilizzando le tue credenziali di identità. Devi autenticarti come utente IAM o assumendo un ruolo IAM. Utente root dell'account AWS
Puoi accedere come identità federata utilizzando credenziali provenienti da una fonte di identità come AWS IAM Identity Center (IAM Identity Center), autenticazione Single Sign-On o credenziali. Google/Facebook Per ulteriori informazioni sull’accesso, consulta [Come accedere all’ Account AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) nella *Guida per l’utente di Accedi ad AWS *.
Per l'accesso programmatico, AWS fornisce un SDK e una CLI per firmare crittograficamente le richieste. Per ulteriori informazioni, consulta [AWS Signature Version 4 per le richieste API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) nella *Guida per l’utente di IAM*.
### Account AWS utente root
Quando si crea un Account AWS, si inizia con un'identità di accesso denominata *utente Account AWS root* che ha accesso completo a tutte Servizi AWS le risorse. Consigliamo vivamente di non utilizzare l’utente root per le attività quotidiane. Per le attività che richiedono le credenziali dell’utente root, consulta [Attività che richiedono le credenziali dell’utente root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) nella *Guida per l’utente IAM*.
### Identità federata
Come procedura ottimale, richiedi agli utenti umani di utilizzare la federazione con un provider di identità per accedere Servizi AWS utilizzando credenziali temporanee.
Un'*identità federata* è un utente della directory aziendale, del provider di identità Web o Directory Service che accede Servizi AWS utilizzando le credenziali di una fonte di identità. Le identità federate assumono ruoli che forniscono credenziali temporanee.
Per la gestione centralizzata degli accessi, si consiglia di utilizzare AWS IAM Identity Center. Per ulteriori informazioni, consulta [Che cos’è il Centro identità IAM?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) nella *Guida per l’utente di AWS IAM Identity Center *.
### Utenti e gruppi IAM
Un *[utente IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* è una identità che dispone di autorizzazioni specifiche per una singola persona o applicazione. Ti consigliamo di utilizzare credenziali temporanee invece di utenti IAM con credenziali a lungo termine. *Per ulteriori informazioni, consulta [Richiedere agli utenti umani di utilizzare la federazione con un provider di identità per accedere AWS utilizzando credenziali temporanee](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) nella Guida per l'utente IAM.*
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifica una raccolta di utenti IAM e semplifica la gestione delle autorizzazioni per gestire gruppi di utenti di grandi dimensioni. Per ulteriori informazioni, consulta [Casi d’uso per utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) nella *Guida per l’utente di IAM*.
### Ruoli IAM
Un *[ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* è un’identità con autorizzazioni specifiche che fornisce credenziali temporanee. Puoi assumere un ruolo [passando da un ruolo utente a un ruolo IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) o chiamando un'operazione AWS CLI o AWS API. Per ulteriori informazioni, consulta [Metodi per assumere un ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) nella *Guida per l’utente di IAM*.
I ruoli IAM sono utili per l’accesso degli utenti federati, le autorizzazioni utente IAM temporanee, l’accesso multi-account, l’accesso multi-servizio e le applicazioni in esecuzione su Amazon EC2. Per maggiori informazioni, consultare [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente IAM*.
## Gestione dell’accesso tramite policy
Puoi controllare l'accesso AWS creando policy e associandole a AWS identità o risorse. Una policy definisce le autorizzazioni quando è associata a un'identità o a una risorsa. AWS valuta queste politiche quando un preside effettua una richiesta. La maggior parte delle politiche viene archiviata AWS come documenti JSON. Per maggiori informazioni sui documenti delle policy JSON, consulta [Panoramica delle policy JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) nella *Guida per l’utente IAM*.
Utilizzando le policy, gli amministratori specificano chi ha accesso a cosa definendo quale **principale** può eseguire **azioni** su quali **risorse** e in quali **condizioni**.
Per impostazione predefinita, utenti e ruoli non dispongono di autorizzazioni. Un amministratore IAM crea le policy IAM e le aggiunge ai ruoli, che gli utenti possono quindi assumere. Le policy IAM definiscono le autorizzazioni indipendentemente dal metodo utilizzato per eseguirle.
### Policy basate sull’identità
Le policy basate su identità sono documenti di policy di autorizzazione JSON che è possibile collegare a un’identità (utente, gruppo o ruolo). Tali policy controllano le operazioni autorizzate per l’identità, nonché le risorse e le condizioni in cui possono essere eseguite. Per informazioni su come creare una policy basata su identità, consultare [Definizione di autorizzazioni personalizzate IAM con policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l’utente IAM*.
Le policy basate su identità possono essere *policy in linea* (con embedding direttamente in una singola identità) o *policy gestite* (policy autonome collegate a più identità). Per informazioni su come scegliere tra una policy gestita o una policy inline, consulta [Scegliere tra policy gestite e policy in linea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) nella *Guida per l’utente di IAM*.
### Policy basate sulle risorse
Le policy basate su risorse sono documenti di policy JSON che è possibile collegare a una risorsa. Gli esempi includono le *policy di trust dei ruoli* IAM e le *policy dei bucket* di Amazon S3. Nei servizi che supportano policy basate sulle risorse, gli amministratori dei servizi possono utilizzarli per controllare l’accesso a una risorsa specifica. In una policy basata sulle risorse è obbligatorio [specificare un’entità principale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
Le policy basate sulle risorse sono policy inline che si trovano in tale servizio. Non è possibile utilizzare le policy AWS gestite di IAM in una policy basata sulle risorse.
### Altri tipi di policy
AWS supporta tipi di policy aggiuntivi che possono impostare le autorizzazioni massime concesse dai tipi di policy più comuni:
+ **Limiti delle autorizzazioni**: imposta il numero massimo di autorizzazioni che una policy basata su identità ha la possibilità di concedere a un’entità IAM. Per ulteriori informazioni, consulta [Limiti delle autorizzazioni per le entità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) nella *Guida per l’utente di IAM*.
+ **Politiche di controllo del servizio (SCPs)**: specificano le autorizzazioni massime per un'organizzazione o un'unità organizzativa in. AWS Organizations Per ulteriori informazioni, consultare [Policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) nella *Guida per l’utente di AWS Organizations *.
+ **Politiche di controllo delle risorse (RCPs)**: imposta le autorizzazioni massime disponibili per le risorse nei tuoi account. Per ulteriori informazioni, consulta [Politiche di controllo delle risorse (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) nella *Guida per l'AWS Organizations utente*.
+ **Policy di sessione**: policy avanzate passate come parametro quando si crea una sessione temporanea per un ruolo o un utente federato. Per maggiori informazioni, consultare [Policy di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) nella *Guida per l’utente IAM*.
### Più tipi di policy
Quando a una richiesta si applicano più tipi di policy, le autorizzazioni risultanti sono più complicate da comprendere. Per scoprire come si AWS determina se consentire o meno una richiesta quando sono coinvolti più tipi di policy, consulta [Logica di valutazione delle policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) nella *IAM User Guide*.
# Come funziona MemoryDB con IAM
Prima di utilizzare IAM per gestire l'accesso a MemoryDB, scopri quali funzionalità IAM sono disponibili per l'uso con MemoryDB.
**Funzionalità IAM che puoi usare con MemoryDB**
| Funzionalità IAM | Supporto per MemoryDB |
| --- | --- |
| [Policy basate sull’identità](#security_iam_service-with-iam-id-based-policies) | Sì |
| [Policy basate su risorse](#security_iam_service-with-iam-resource-based-policies) | No |
| [Operazioni di policy](#security_iam_service-with-iam-id-based-policies-actions) | Sì |
| [Risorse relative alle policy](#security_iam_service-with-iam-id-based-policies-resources) | Sì |
| [Chiavi di condizione delle policy](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Sì |
| [ACLs](#security_iam_service-with-iam-acls) | Sì |
| [ABAC (tag nelle policy)](#security_iam_service-with-iam-tags) | Sì |
| [Credenziali temporanee](#security_iam_service-with-iam-roles-tempcreds) | Sì |
| [Autorizzazioni del principale](#security_iam_service-with-iam-principal-permissions) | Sì |
| [Ruoli di servizio](#security_iam_service-with-iam-roles-service) | Sì |
| [Ruoli collegati al servizio](#security_iam_service-with-iam-roles-service-linked) | Sì |
*Per avere una visione di alto livello di come MemoryDB e altri AWS servizi funzionano con la maggior parte delle funzionalità IAM, consulta [AWS i servizi che funzionano con IAM nella IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) User Guide.*
## Politiche basate sull'identità per MemoryDB
**Supporta le policy basate sull’identità:** sì
Le policy basate sull'identità sono documenti di policy di autorizzazione JSON che è possibile allegare a un'identità (utente, gruppo di utenti o ruolo IAM). Tali policy definiscono le operazioni che utenti e ruoli possono eseguire, su quali risorse e in quali condizioni. Per informazioni su come creare una policy basata su identità, consulta [Definizione di autorizzazioni personalizzate IAM con policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l’utente di IAM*.
Con le policy basate sull’identità di IAM, è possibile specificare quali operazioni e risorse sono consentite o respinte, nonché le condizioni in base alle quali le operazioni sono consentite o respinte. Per informazioni su tutti gli elementi utilizzabili in una policy JSON, consulta [Guida di riferimento agli elementi delle policy JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) nella *Guida per l’utente IAM*.
### Esempi di policy basate sull'identità per MemoryDB
Per visualizzare esempi di politiche basate sull'identità di MemoryDB, vedere. [Esempi di policy basate sull'identità per MemoryDB](security_iam_id-based-policy-examples.md)
## Politiche basate sulle risorse all'interno di MemoryDB
**Supporta le policy basate su risorse:** no
Le policy basate su risorse sono documenti di policy JSON che è possibile collegare a una risorsa. Esempi di policy basate sulle risorse sono le *policy di attendibilità dei ruoli* IAM e le *policy di bucket* Amazon S3. Nei servizi che supportano policy basate sulle risorse, gli amministratori dei servizi possono utilizzarli per controllare l’accesso a una risorsa specifica. Quando è collegata a una risorsa, una policy definisce le operazioni che un principale può eseguire su tale risorsa e a quali condizioni. In una policy basata sulle risorse è obbligatorio [specificare un’entità principale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). I principali possono includere account, utenti, ruoli, utenti federati o. Servizi AWS
Per consentire l’accesso multi-account, è possibile specificare un intero account o entità IAM in un altro account come entità principale in una policy basata sulle risorse. Per ulteriori informazioni, consulta [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente IAM*.
## Azioni politiche per MemoryDB
**Supporta le operazioni di policy:** si
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L'elemento `Action` di una policy JSON descrive le operazioni che è possibile utilizzare per consentire o negare l'accesso in una policy. Includere le operazioni in una policy per concedere le autorizzazioni a eseguire l’operazione associata.
*Per visualizzare un elenco delle azioni di MemoryDB, vedere [Actions Defined by MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions) nel Service Authorization Reference.*
Le azioni politiche in MemoryDB utilizzano il seguente prefisso prima dell'azione:
```
MemoryDB
```
Per specificare più operazioni in una sola istruzione, occorre separarle con la virgola.
```
"Action": [
"MemoryDB:action1",
"MemoryDB:action2"
]
```
È possibile specificare più azioni tramite caratteri jolly (\$1). Ad esempio, per specificare tutte le azioni che iniziano con la parola `Describe`, includi la seguente azione:
```
"Action": "MemoryDB:Describe*"
```
Per visualizzare esempi di politiche basate sull'identità di MemoryDB, vedere. [Esempi di policy basate sull'identità per MemoryDB](security_iam_id-based-policy-examples.md)
## Risorse politiche per MemoryDB
**Supporta le risorse relative alle policy:** sì
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento JSON `Resource` della policy specifica l’oggetto o gli oggetti ai quali si applica l’operazione. Come best practice, specifica una risorsa utilizzando il suo [nome della risorsa Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Per le azioni che non supportano le autorizzazioni a livello di risorsa, si utilizza un carattere jolly (\$1) per indicare che l’istruzione si applica a tutte le risorse.
```
"Resource": "*"
```
*Per visualizzare un elenco dei tipi di risorse di MemoryDB e relativi ARNs, vedere [Resources Defined by MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-resources-for-iam-policies) nel Service Authorization Reference.* Per sapere con quali azioni è possibile specificare l'ARN di ciascuna risorsa, vedere [Azioni definite da](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions) MemoryDB.
Per visualizzare esempi di politiche basate sull'identità di MemoryDB, vedere. [Esempi di policy basate sull'identità per MemoryDB](security_iam_id-based-policy-examples.md)
## Chiavi delle condizioni dei criteri per MemoryDB
**Supporta le chiavi di condizione delle policy specifiche del servizio:** sì
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento `Condition` specifica quando le istruzioni vengono eseguite in base a criteri definiti. È possibile compilare espressioni condizionali che utilizzano [operatori di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), ad esempio uguale a o minore di, per soddisfare la condizione nella policy con i valori nella richiesta. Per visualizzare tutte le chiavi di condizione AWS globali, consulta le chiavi di [contesto delle condizioni AWS globali nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) per l'*utente IAM*.
Per visualizzare esempi di politiche basate sull'identità di MemoryDB, consulta. [Esempi di policy basate sull'identità per MemoryDB](security_iam_id-based-policy-examples.md)
### Utilizzo delle chiavi di condizione
Puoi specificare le condizioni che determinano il modo in cui una policy IAM viene applicata. In MemoryDB, è possibile utilizzare l'`Condition`elemento di una policy JSON per confrontare le chiavi nel contesto della richiesta con i valori chiave specificati nella policy. Per ulteriori informazioni, consulta [elementi della policy IAM JSON: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html).
*Per visualizzare un elenco di chiavi di condizione di MemoryDB, vedere Condition [Keys for MemoryDB nel Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-policy-keys) Authorization Reference.*
Per un elenco delle chiavi di condizione globali, consulta [Chiavi di contesto delle condizioni globali AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).
#### Specifica delle condizioni: Uso delle chiavi di condizione
Per implementare un controllo granulare, puoi scrivere una policy di autorizzazioni IAM che specifichi le condizioni per controllare un set di singoli parametri su determinate richieste. Puoi quindi applicare la policy agli utenti, ai gruppi o ai ruoli IAM che crei utilizzando la console IAM.
Per applicare una condizione, aggiungere le informazioni sulla condizione all'istruzione della policy IAM. Ad esempio, per impedire la creazione di qualsiasi cluster MemoryDB con TLS disabilitato, puoi specificare la seguente condizione nella tua dichiarazione politica.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "false"
}
}
}
]
}
```
------
Per ulteriori informazioni sull'etichettatura, vedere. [Etichettare le risorse di MemoryDB](tagging-resources.md)
Per ulteriori informazioni sull'utilizzo degli operatori delle condizioni di policy, consulta [Autorizzazioni API MemoryDB: riferimento ad azioni, risorse e condizioni](iam.APIReference.md).
#### Policy di esempio: Utilizzo di condizioni per il controllo granulare dei parametri
Questa sezione mostra esempi di policy per l'implementazione di un controllo granulare degli accessi sui parametri MemoryDB elencati in precedenza.
1. **memorydb: TLSEnabled** — Specificate che i cluster verranno creati solo con TLS abilitato.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"arn:aws:memorydb:*:*:parametergroup/*",
"arn:aws:memorydb:*:*:subnetgroup/*",
"arn:aws:memorydb:*:*:acl/*"
]
},
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "true"
}
}
}
]
}
```
------
1. **memorydb:UserAuthenticationMode:** — Specificare che gli utenti possono essere creati con una modalità di autenticazione di tipo specifico (IAM per esempio).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:Createuser"
],
"Resource": [
"arn:aws:memorydb:*:*:user/*"
],
"Condition": {
"StringEquals": {
"memorydb:UserAuthenticationMode": "iam"
}
}
}
]
}
```
------
Nei casi in cui si impostano politiche basate su «Deny», si consiglia di utilizzare l'[StringEqualsIgnoreCase](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String)operatore per evitare tutte le chiamate con un tipo di modalità di autenticazione utente specifico, indipendentemente dal caso.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateUser"
],
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"memorydb:UserAuthenticationMode": "password"
}
}
}
]
}
```
------
## Accedi agli elenchi di controllo (ACLs) in MemoryDB
**Supporti ACLs**: Sì
Le liste di controllo degli accessi (ACLs) controllano quali principali (membri dell'account, utenti o ruoli) dispongono delle autorizzazioni per accedere a una risorsa. ACLs sono simili alle politiche basate sulle risorse, sebbene non utilizzino il formato del documento di policy JSON.
## Controllo degli accessi basato sugli attributi (ABAC) con MemoryDB
**Supporta ABAC (tag nelle policy):** sì
Il controllo degli accessi basato su attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base ad attributi chiamati tag. Puoi allegare tag a entità e AWS risorse IAM, quindi progettare politiche ABAC per consentire le operazioni quando il tag del principale corrisponde al tag sulla risorsa.
Per controllare l’accesso basato su tag, fornire informazioni sui tag nell’[elemento condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) di una policy utilizzando le chiavi di condizione `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`.
Se un servizio supporta tutte e tre le chiavi di condizione per ogni tipo di risorsa, il valore per il servizio è **Sì**. Se un servizio supporta tutte e tre le chiavi di condizione solo per alcuni tipi di risorsa, allora il valore sarà **Parziale**.
Per maggiori informazioni su ABAC, consulta [Definizione delle autorizzazioni con autorizzazione ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) nella *Guida per l’utente di IAM*. Per visualizzare un tutorial con i passaggi per l’impostazione di ABAC, consulta [Utilizzo del controllo degli accessi basato su attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) nella *Guida per l’utente di IAM*.
## Utilizzo di credenziali temporanee con MemoryDB
**Supporta le credenziali temporanee:** sì
Le credenziali temporanee forniscono l'accesso a breve termine alle AWS risorse e vengono create automaticamente quando si utilizza la federazione o si cambia ruolo. AWS consiglia di generare dinamicamente credenziali temporanee anziché utilizzare chiavi di accesso a lungo termine. Per ulteriori informazioni, consulta [Credenziali di sicurezza temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) e [Servizi AWS compatibili con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) nella *Guida per l’utente IAM*.
## Autorizzazioni principali multiservizio per MemoryDB
**Supporta l’inoltro delle sessioni di accesso (FAS):** sì
Le sessioni di accesso diretto (FAS) utilizzano le autorizzazioni del principale che chiama an Servizio AWS, combinate con la richiesta di effettuare richieste ai servizi Servizio AWS downstream. Per i dettagli delle policy relative alle richieste FAS, consulta [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Ruoli di servizio per MemoryDB
**Supporta i ruoli di servizio:** sì
Un ruolo di servizio è un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che un servizio assume per eseguire operazioni per tuo conto. Un amministratore IAM può creare, modificare ed eliminare un ruolo di servizio dall’interno di IAM. Per ulteriori informazioni, consulta [Create a role to delegate permissions to an Servizio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) nella *Guida per l’utente IAM*.
**avvertimento**
La modifica delle autorizzazioni per un ruolo di servizio potrebbe interrompere la funzionalità di MemoryDB. Modifica i ruoli di servizio solo quando MemoryDB fornisce indicazioni in tal senso.
## Ruoli collegati ai servizi per MemoryDB
**Supporta i ruoli collegati ai servizi:** sì
Un ruolo collegato al servizio è un tipo di ruolo di servizio collegato a un. Servizio AWS Il servizio può assumere il ruolo per eseguire un’operazione per tuo conto. I ruoli collegati al servizio vengono visualizzati nel tuo account Account AWS e sono di proprietà del servizio. Un amministratore IAM può visualizzare le autorizzazioni per i ruoli collegati al servizio, ma non modificarle.
Per ulteriori informazioni su come creare e gestire i ruoli collegati ai servizi, consulta [Servizi AWS supportati da IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Trova un servizio nella tabella che include un `Yes` nella colonna **Service-linked role (Ruolo collegato ai servizi)**. Scegli il collegamento **Sì** per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
# Esempi di policy basate sull'identità per MemoryDB
Per impostazione predefinita, gli utenti e i ruoli non dispongono dell'autorizzazione per creare o modificare risorse MemoryDB. Per concedere agli utenti l’autorizzazione a eseguire azioni sulle risorse di cui hanno bisogno, un amministratore IAM può creare policy IAM.
Per informazioni su come creare una policy basata su identità IAM utilizzando questi documenti di policy JSON di esempio, consulta [Creazione di policy IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) nella *Guida per l’utente di IAM*.
*Per informazioni dettagliate sulle azioni e sui tipi di risorse definiti da MemoryDB, incluso il formato di ARNs per ciascun tipo di risorsa, vedere [Actions, Resources and Condition Keys for MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html) nel Service Authorization Reference.*
**Topics**
+ [Best practice per le policy](#security_iam_service-with-iam-policy-best-practices)
+ [Utilizzo della console MemoryDB](#security_iam_id-based-policy-examples-console)
+ [Consentire agli utenti di visualizzare le loro autorizzazioni](#security_iam_id-based-policy-examples-view-own-permissions)
## Best practice per le policy
Le politiche basate sull'identità determinano se qualcuno può creare, accedere o eliminare le risorse di MemoryDB nel tuo account. Queste azioni possono comportare costi aggiuntivi per l’ Account AWS. Quando si creano o modificano policy basate sull’identità, seguire queste linee guida e raccomandazioni:
+ **Inizia con le policy AWS gestite e passa alle autorizzazioni con privilegi minimi: per iniziare a concedere autorizzazioni** *a utenti e carichi di lavoro, utilizza le politiche gestite che concedono le autorizzazioni per molti casi d'uso comuni.AWS * Sono disponibili nel tuo. Account AWS Ti consigliamo di ridurre ulteriormente le autorizzazioni definendo politiche gestite dai AWS clienti specifiche per i tuoi casi d'uso. Per maggiori informazioni, consulta [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o [Policy gestite da AWS per le funzioni dei processi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) nella *Guida per l’utente di IAM*.
+ **Applicazione delle autorizzazioni con privilegio minimo** - Quando si impostano le autorizzazioni con le policy IAM, concedere solo le autorizzazioni richieste per eseguire un’attività. È possibile farlo definendo le azioni che possono essere intraprese su risorse specifiche in condizioni specifiche, note anche come *autorizzazioni con privilegio minimo*. Per maggiori informazioni sull’utilizzo di IAM per applicare le autorizzazioni, consulta [Policy e autorizzazioni in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) nella *Guida per l’utente di IAM*.
+ **Condizioni d’uso nelle policy IAM per limitare ulteriormente l’accesso** - Per limitare l’accesso ad azioni e risorse è possibile aggiungere una condizione alle policy. Ad esempio, è possibile scrivere una condizione di policy per specificare che tutte le richieste devono essere inviate utilizzando SSL. Puoi anche utilizzare le condizioni per concedere l'accesso alle azioni del servizio se vengono utilizzate tramite uno specifico Servizio AWS, ad esempio CloudFormation. Per maggiori informazioni, consultare la sezione [Elementi delle policy JSON di IAM: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l’utente di IAM*.
+ **Utilizzo dello strumento di analisi degli accessi IAM per convalidare le policy IAM e garantire autorizzazioni sicure e funzionali** - Lo strumento di analisi degli accessi IAM convalida le policy nuove ed esistenti in modo che aderiscano al linguaggio (JSON) della policy IAM e alle best practice di IAM. Lo strumento di analisi degli accessi IAM offre oltre 100 controlli delle policy e consigli utili per creare policy sicure e funzionali. Per maggiori informazioni, consultare [Convalida delle policy per il Sistema di analisi degli accessi IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) nella *Guida per l’utente di IAM*.
+ **Richiedi l'autenticazione a più fattori (MFA**): se hai uno scenario che richiede utenti IAM o un utente root nel Account AWS tuo, attiva l'MFA per una maggiore sicurezza. Per richiedere la MFA quando vengono chiamate le operazioni API, aggiungere le condizioni MFA alle policy. Per maggiori informazioni, consultare [Protezione dell’accesso API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) nella *Guida per l’utente di IAM*.
Per maggiori informazioni sulle best practice in IAM, consulta [Best practice di sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) nella *Guida per l’utente di IAM*.
## Utilizzo della console MemoryDB
Per accedere alla console MemoryDB, è necessario disporre di un set minimo di autorizzazioni. Queste autorizzazioni devono consentirvi di elencare e visualizzare i dettagli sulle risorse MemoryDB presenti nel vostro. Account AWS Se crei una policy basata sull’identità più restrittiva rispetto alle autorizzazioni minime richieste, la console non funzionerà nel modo previsto per le entità (utenti o ruoli) associate a tale policy.
Non è necessario consentire autorizzazioni minime per la console per gli utenti che effettuano chiamate solo verso o l' AWS CLI API. AWS Al contrario, è opportuno concedere l’accesso solo alle azioni che corrispondono all’operazione API che stanno cercando di eseguire.
Per garantire che utenti e ruoli possano ancora utilizzare la console MemoryDB, collega anche MemoryDB `ConsoleAccess` o la policy `ReadOnly` AWS gestita alle entità. Per maggiori informazioni, consulta [Aggiunta di autorizzazioni a un utente](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) nella *Guida per l’utente di IAM*.
## Consentire agli utenti di visualizzare le loro autorizzazioni
Questo esempio mostra in che modo è possibile creare una policy che consente agli utenti IAM di visualizzare le policy inline e gestite che sono collegate alla relativa identità utente. Questa politica include le autorizzazioni per completare questa azione sulla console o utilizzando l'API o a livello di codice. AWS CLI AWS
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Risoluzione dei problemi relativi all'identità e all'accesso a MemoryDB
Utilizza le seguenti informazioni per aiutarti a diagnosticare e risolvere i problemi più comuni che potresti riscontrare quando lavori con MemoryDB e IAM.
**Topics**
+ [Non sono autorizzato a eseguire un'azione in MemoryDB](#security_iam_troubleshoot-no-permissions)
+ [Non sono autorizzato a eseguire iam: PassRole](#security_iam_troubleshoot-passrole)
+ [Voglio consentire a persone esterne al mio AWS account di accedere alle mie risorse MemoryDB](#security_iam_troubleshoot-cross-account-access)
## Non sono autorizzato a eseguire un'azione in MemoryDB
Se ti Console di gestione AWS dice che non sei autorizzato a eseguire un'azione, devi contattare l'amministratore per ricevere assistenza. L'amministratore è la persona da cui si sono ricevuti il nome utente e la password.
Il seguente esempio di errore si verifica quando l'utente `mateojackson` prova a utilizzare la console per visualizzare i dettagli relativi a una risorsa `my-example-widget` fittizia, ma non dispone di autorizzazioni `MemoryDB:GetWidget` fittizie.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: MemoryDB:GetWidget on resource: my-example-widget
```
In questo caso, Mateo richiede al suo amministratore di aggiornare le policy per poter accedere alla risorsa `my-example-widget` utilizzando l'operazione `MemoryDB:GetWidget`.
## Non sono autorizzato a eseguire iam: PassRole
Se ricevi un errore che indica che non sei autorizzato a eseguire l'`iam:PassRole`azione, le tue politiche devono essere aggiornate per consentirti di passare un ruolo a MemoryDB.
Alcuni Servizi AWS consentono di passare un ruolo esistente a quel servizio invece di creare un nuovo ruolo di servizio o un ruolo collegato al servizio. Per eseguire questa operazione, è necessario disporre delle autorizzazioni per trasmettere il ruolo al servizio.
Il seguente errore di esempio si verifica quando un utente IAM denominato `marymajor` tenta di utilizzare la console per eseguire un'azione in MemoryDB. Tuttavia, l’azione richiede che il servizio disponga delle autorizzazioni concesse da un ruolo di servizio. Mary non dispone delle autorizzazioni per trasmettere il ruolo al servizio.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In questo caso, le policy di Mary devono essere aggiornate per poter eseguire l’operazione `iam:PassRole`.
Se hai bisogno di aiuto, contatta il tuo AWS amministratore. L’amministratore è la persona che ti ha fornito le credenziali di accesso.
## Voglio consentire a persone esterne al mio AWS account di accedere alle mie risorse MemoryDB
È possibile creare un ruolo con il quale utenti in altri account o persone esterne all’organizzazione possono accedere alle tue risorse. È possibile specificare chi è attendibile per l’assunzione del ruolo. Per i servizi che supportano politiche basate sulle risorse o liste di controllo degli accessi (ACLs), puoi utilizzare tali politiche per concedere alle persone l'accesso alle tue risorse.
Per maggiori informazioni, consulta gli argomenti seguenti:
+ Per sapere se MemoryDB supporta queste funzionalità, consulta. [Come funziona MemoryDB con IAM](security_iam_service-with-iam.md)
+ Per scoprire come fornire l'accesso alle risorse di tua proprietà, consulta [Fornire l'accesso a un utente IAM di un altro Account AWS utente di tua proprietà nella](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) *IAM User* Guide. Account AWS
+ Per scoprire come fornire l'accesso alle tue risorse a terze parti Account AWS, consulta [Fornire l'accesso a soggetti Account AWS di proprietà di terze parti](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) nella *Guida per l'utente IAM*.
+ Per informazioni su come fornire l'accesso tramite la federazione delle identità, consulta [Fornire l'accesso a utenti autenticati esternamente (federazione delle identità)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) nella *Guida per l'utente IAM*.
+ Per informazioni sulle differenze di utilizzo tra ruoli e policy basate su risorse per l’accesso multi-account, consulta [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente di IAM*.
## Controllo accessi
Puoi avere credenziali valide per autenticare le tue richieste, ma a meno che tu non disponga delle autorizzazioni non puoi creare o accedere alle risorse di MemoryDB. Ad esempio, è necessario disporre delle autorizzazioni per creare un cluster MemoryDB.
Le sezioni seguenti descrivono come gestire le autorizzazioni per MemoryDB. Consigliamo di leggere prima la panoramica.
+ [Panoramica sulla gestione delle autorizzazioni di accesso alle risorse di MemoryDB](iam.overview.md)
+ [Utilizzo di politiche basate sull'identità (politiche IAM) per MemoryDB](iam.identitybasedpolicies.md)
# Panoramica sulla gestione delle autorizzazioni di accesso alle risorse di MemoryDB
Ogni AWS risorsa è di proprietà di un AWS account e le autorizzazioni per creare o accedere a una risorsa sono regolate dalle politiche di autorizzazione. Un amministratore dell'account è in grado di collegare le policy relative alle autorizzazioni alle identità IAM (ovvero utenti, gruppi e ruoli). Inoltre, MemoryDB supporta anche l'associazione di politiche di autorizzazione alle risorse.
**Nota**
Un *amministratore account* (o un utente amministratore) è un utente con privilegi di amministratore. Per ulteriori informazioni, consulta [Best practice IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) nella *Guida per l'utente di IAM*.
Per fornire l’accesso, aggiungi autorizzazioni agli utenti, gruppi o ruoli:
+ Utenti e gruppi in: AWS IAM Identity Center
Crea un set di autorizzazioni. Segui le istruzioni riportate nella pagina [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) (Creazione di un set di autorizzazioni) nella *Guida per l’utente di AWS IAM Identity Center *.
+ Utenti gestiti in IAM tramite un provider di identità:
Crea un ruolo per la federazione delle identità. Segui le istruzioni riportate nella pagina [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) della *Guida per l’utente IAM*.
+ Utenti IAM:
+ Crea un ruolo che l’utente possa assumere. Segui le istruzioni riportate nella pagina [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) della *Guida per l’utente IAM*.
+ (Non consigliato) Collega una policy direttamente a un utente o aggiungi un utente a un gruppo di utenti. Segui le istruzioni riportate nella pagina [Aggiunta di autorizzazioni a un utente (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) nella *Guida per l’utente IAM*.
**Topics**
+ [Risorse e operazioni di MemoryDB](#iam.overview.resourcesandoperations)
+ [Informazioni sulla proprietà delle risorse](#access-control-resource-ownership)
+ [Gestione dell'accesso alle risorse](#iam.overview.managingaccess)
+ [Utilizzo di politiche basate sull'identità (politiche IAM) per MemoryDB](iam.identitybasedpolicies.md)
+ [Autorizzazioni a livello di risorsa](iam.resourcelevelpermissions.md)
+ [Utilizzo dei ruoli collegati ai servizi per MemoryDB](using-service-linked-roles.md)
+ [AWS politiche gestite per MemoryDB](security-iam-awsmanpol.md)
+ [Autorizzazioni API MemoryDB: riferimento ad azioni, risorse e condizioni](iam.APIReference.md)
## Risorse e operazioni di MemoryDB
*In MemoryDB, la risorsa principale è un cluster.*
A queste risorse sono associati Amazon Resource Names (ARNs) univoci, come illustrato di seguito.
**Nota**
Affinché le autorizzazioni a livello di risorsa siano efficaci, il nome della risorsa nella stringa ARN deve essere minuscolo.
****
| Tipo di risorsa | Formato ARN |
| --- | --- |
| Utente | arn:aws:memorydb ::user/user1 *us-east-1:123456789012* |
| Elenco di controllo degli accessi (ACL) | arn:aws:memorydb ::acl/myacl *us-east-1:123456789012* |
| Cluster | arn:aws:memorydb ::cluster/mio-cluster *us-east-1:123456789012* |
| Istantanea | arn:aws:memorydb ::snapshot/my-snapshot *us-east-1:123456789012* |
| Gruppo di parametri | arn:aws:memorydb: :parametergroup/ *us-east-1:123456789012* my-parameter-group |
| Gruppo di sottoreti | arn:aws:memorydb ::subnetgroup/ *us-east-1:123456789012* my-subnet-group |
MemoryDB fornisce una serie di operazioni per lavorare con le risorse di MemoryDB. [Per un elenco delle operazioni disponibili, vedere MemoryDB Actions.](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html)
## Informazioni sulla proprietà delle risorse
*Il proprietario della risorsa* è l' AWS account che ha creato la risorsa. In altre parole, il proprietario della risorsa è l' AWS account dell'entità principale che autentica la richiesta che crea la risorsa. Un'*entità principale* può essere l'account root, un utente IAM o un ruolo IAM. Negli esempi seguenti viene illustrato il funzionamento:
+ Supponiamo di utilizzare le credenziali dell'account root del proprio AWS account per creare un cluster. In questo caso, il tuo AWS account è il proprietario della risorsa. In MemoryDB, la risorsa è il cluster.
+ Supponiamo di creare un utente IAM nel tuo AWS account e di concedere a quell'utente le autorizzazioni per creare un cluster. In questo caso, l'utente può creare un cluster. Tuttavia, l' AWS account a cui appartiene l'utente è proprietario della risorsa del cluster.
+ Supponiamo che tu crei un ruolo IAM nel tuo AWS account con le autorizzazioni per creare un cluster. In questo caso, chiunque possa assumere il ruolo può creare un cluster. Il tuo AWS account, a cui appartiene il ruolo, possiede la risorsa del cluster.
## Gestione dell'accesso alle risorse
La *policy delle autorizzazioni* descrive chi ha accesso a cosa. Nella sezione seguente vengono descritte le opzioni disponibili per la creazione di policy relative alle autorizzazioni.
**Nota**
Questa sezione illustra l'utilizzo di IAM nel contesto di MemoryDB. Non vengono fornite informazioni dettagliate sul servizio IAM. Per la documentazione di IAM completa, consulta [Che cos'è IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) nella *Guida per l'utente di IAM*. Per informazioni sulla sintassi delle policy IAM e le rispettive descrizioni, consulta [Riferimento alle policy IAM di AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) nella *Guida per l'utente di IAM*.
Le policy collegate a un'identità IAM vengono definite *policy basate su identità* (policy IAM). Le policy collegate a una risorsa vengono definite *policy basate sulle risorse*.
**Topics**
+ [Policy basate su identità (policy IAM)](#iam.overview.managingaccess.identitybasedpolicies)
+ [Specifica degli elementi delle policy: operazioni, effetti, risorse ed entità](#iam.overview.policyelements)
+ [Specifica delle condizioni in una policy](#iam.specifyconditions)
### Policy basate su identità (policy IAM)
Puoi collegare le policy alle identità IAM. Ad esempio, puoi eseguire le operazioni seguenti:
+ **Collegare una policy di autorizzazione a un utente o a un gruppo nell'account** – Per assegnare le autorizzazioni un amministratore di account può utilizzare una policy di autorizzazione associata a un utente specifico. In questo caso, l'utente ha il permesso di creare una risorsa MemoryDB, come un cluster, un gruppo di parametri o un gruppo di sicurezza.
+ **Collega una policy di autorizzazione a un ruolo (assegnazione di autorizzazioni tra account)**: per concedere autorizzazioni tra più account, è possibile collegare una policy di autorizzazione basata su identità a un ruolo IAM. Ad esempio, l'amministratore dell'account A può creare un ruolo per concedere autorizzazioni su più account a un altro account (ad esempio, l' AWS account B) o a un servizio nel modo seguente: AWS
1. L'amministratore dell'account A crea un ruolo IAM e attribuisce una policy di autorizzazione al ruolo che concede le autorizzazioni sulle risorse per l'account A.
1. L'amministratore dell'account A attribuisce una policy di attendibilità al ruolo, identificando l'account B come il principale per tale ruolo.
1. L'amministratore dell'Account B può quindi delegare le autorizzazioni per assumere il ruolo a qualsiasi utente dell'Account B. In questo modo gli utenti dell'Account B possono creare o accedere alle risorse dell'Account A. In alcuni casi, potresti voler concedere a un AWS servizio le autorizzazioni per assumere il ruolo. Per supportare tale approccio, l'entità principale nella policy di trust può anche essere un'entità principale di un servizio AWS .
Per ulteriori informazioni sull'uso di IAM per delegare le autorizzazioni, consulta [Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) nella *IAM User Guide* (Guida per l'utente di IAM).
Di seguito è riportato un esempio di politica che consente a un utente di eseguire l'`DescribeClusters`azione per il tuo account. AWS MemoryDB supporta anche l'identificazione di risorse specifiche utilizzando la risorsa ARNs per le azioni API. (questo approccio è anche noto come autorizzazioni a livello di risorsa).
Per ulteriori informazioni sull'utilizzo di politiche basate sull'identità con MemoryDB, vedere. [Utilizzo di politiche basate sull'identità (politiche IAM) per MemoryDB](iam.identitybasedpolicies.md) Per ulteriori informazioni su utenti, gruppi, ruoli e autorizzazioni, consulta [Identità (utenti, gruppi e ruoli)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) nella *Guida per l'utente di IAM*.
### Specifica degli elementi delle policy: operazioni, effetti, risorse ed entità
[Per ogni risorsa MemoryDB (vedi[Risorse e operazioni di MemoryDB](#iam.overview.resourcesandoperations)), il servizio definisce un insieme di operazioni API (vedi Azioni).](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html) Per concedere le autorizzazioni per queste operazioni API, MemoryDB definisce una serie di azioni che è possibile specificare in una politica. Ad esempio, per la risorsa del cluster MemoryDB, vengono definite le seguenti azioni:, e. `CreateCluster` `DeleteCluster` `DescribeClusters` L'esecuzione di un'operazione API può richiedere le autorizzazioni per più di un'operazione.
Di seguito sono elencati gli elementi di base di una policy:
+ **Risorsa**: in una policy si utilizza il nome della risorsa Amazon (ARN) per identificare la risorsa a cui si applica la policy stessa. Per ulteriori informazioni, consulta [Risorse e operazioni di MemoryDB](#iam.overview.resourcesandoperations).
+ **Operazione**: utilizzi le parole chiave per identificare le operazioni sulla risorsa da permettere o rifiutare. Ad esempio, a seconda di quanto specificato`Effect`, l'`memorydb:CreateCluster`autorizzazione consente o nega all'utente le autorizzazioni per eseguire l'operazione MemoryDB. `CreateCluster`
+ **Effetto**: l'effetto prodotto quando l'utente richiede l'operazione specifica, ovvero un'autorizzazione o un rifiuto. USe non concedi esplicitamente (consenti) l'accesso a una risorsa, l'accesso viene implicitamente rifiutato. È anche possibile negare esplicitamente l'accesso a una risorsa. Ad esempio, è possibile eseguire questa operazione per accertarsi che un utente non sia in grado di accedere a una risorsa, anche se l'accesso viene concesso da un'altra policy.
+ **Principale**: nelle policy basate su identità (policy IAM), l'utente a cui la policy è collegata è il principale implicito. Per policy basate su risorse, specifichi l'utente, l'account, il servizio o un'altra entità che desideri riceva le autorizzazioni (si applica solo alle policy basate su risorse).
Per ulteriori informazioni sulla sintassi e le descrizioni delle policy IAM, consulta [AWS Riferimento alle policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) nella *Guida per l'utente di IAM*.
Per una tabella che mostra tutte le azioni dell'API MemoryDB, vedere. [Autorizzazioni API MemoryDB: riferimento ad azioni, risorse e condizioni](iam.APIReference.md)
### Specifica delle condizioni in una policy
Quando si concedono le autorizzazioni, è possibile utilizzare il linguaggio della policy IAM per specificare le condizioni in base a cui la policy deve essere applicata. Ad esempio, potresti decidere che una policy venga applicata solo dopo una data specifica. Per ulteriori informazioni su come specificare le condizioni in un linguaggio di policy, consulta la sezione [Condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition) nella *Guida per l'utente di IAM*.
# Utilizzo di politiche basate sull'identità (politiche IAM) per MemoryDB
In questo argomento vengono forniti esempi di policy basate su identità in cui un amministratore account può collegare policy di autorizzazione a identità IAM, ovvero utenti, gruppi e ruoli.
**Importante**
Ti consigliamo di leggere prima gli argomenti che spiegano i concetti e le opzioni di base per gestire l'accesso alle risorse di MemoryDB. Per ulteriori informazioni, consulta [Panoramica sulla gestione delle autorizzazioni di accesso alle risorse di MemoryDB](iam.overview.md).
In questa sezione vengono trattati gli argomenti seguenti:
+ [Autorizzazioni necessarie per utilizzare la console MemoryDB](#iam.identitybasedpolicies.minconpolicies)
+ [AWS-politiche gestite (predefinite) per MemoryDB](security-iam-awsmanpol.md#iam.identitybasedpolicies.predefinedpolicies)
+ [Esempi di policy gestite dal cliente](#iam.identitybasedpolicies.customermanagedpolicies)
Di seguito viene illustrato un esempio di policy di autorizzazione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowClusterPermissions",
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster",
"memorydb:DescribeClusters",
"memorydb:UpdateCluster"],
"Resource": "*"
},
{
"Sid": "AllowUserToPassRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::123456789012:role/EC2-roles-for-cluster"
}
]
}
```
------
La policy include due dichiarazioni:
+ La prima istruzione concede le autorizzazioni per le azioni di MemoryDB (`memorydb:CreateCluster``memorydb:DescribeClusters`, e`memorydb:UpdateCluster`) su qualsiasi cluster di proprietà dell'account.
+ La seconda istruzione concede le autorizzazioni per l'operazione IAM (`iam:PassRole`) sul nome del ruolo IAM specificato alla fine del valore `Resource`.
La policy non specifica l'elemento `Principal` poiché in una policy basata su identità l'entità che ottiene l'autorizzazione non viene specificata. Quando si collega una policy a un utente, quest'ultimo è l'entità implicita. Quando colleghi una policy di autorizzazioni a un ruolo IAM, il principale identificato nella policy di attendibilità del ruolo ottiene le autorizzazioni.
Per una tabella che mostra tutte le azioni dell'API MemoryDB e le risorse a cui si applicano, vedere. [Autorizzazioni API MemoryDB: riferimento ad azioni, risorse e condizioni](iam.APIReference.md)
## Autorizzazioni necessarie per utilizzare la console MemoryDB
La tabella di riferimento delle autorizzazioni elenca le operazioni dell'API MemoryDB e mostra le autorizzazioni richieste per ciascuna operazione. Per ulteriori informazioni sulle operazioni dell'API MemoryDB, vedere. [Autorizzazioni API MemoryDB: riferimento ad azioni, risorse e condizioni](iam.APIReference.md)
Per utilizzare la console MemoryDB, concedi innanzitutto le autorizzazioni per azioni aggiuntive, come mostrato nella seguente politica di autorizzazione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "MinPermsForMemDBConsole",
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeVpcs",
"ec2:DescribeAccountAttributes",
"ec2:DescribeSecurityGroups",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"s3:ListAllMyBuckets",
"sns:ListTopics",
"sns:ListSubscriptions" ],
"Resource": "*"
}
]
}
```
------
La console MemoryDB necessita di queste autorizzazioni aggiuntive per i seguenti motivi:
+ Le autorizzazioni per le azioni MemoryDB consentono alla console di visualizzare le risorse MemoryDB nell'account.
+ La console necessita delle autorizzazioni per le `ec2` azioni di interrogazione di Amazon EC2 in modo da poter visualizzare zone di disponibilità VPCs, gruppi di sicurezza e attributi dell'account.
+ Le `cloudwatch` autorizzazioni per le azioni consentono alla console di recuperare CloudWatch metriche e allarmi di Amazon e di visualizzarli nella console.
+ Le autorizzazioni per le operazioni `sns` consentono alla console di recuperare argomenti e sottoscrizioni di Amazon Simple Notification Service (Amazon SNS) e mostrarli.
## Esempi di policy gestite dal cliente
Se non si utilizza una policy predefinita e si sceglie di utilizzare una policy gestita in modo personalizzato, assicurarsi di trovarsi in una delle due seguenti situazioni. O si dispone delle autorizzazioni per richiamare `iam:createServiceLinkedRole` (Per ulteriori informazioni, consulta[Esempio 4: consentire a un utente di chiamare l'API IAM CreateServiceLinkedRole](#create-service-linked-role-policy)). Oppure avresti dovuto creare un ruolo collegato al servizio MemoryDB.
Se combinate con le autorizzazioni minime necessarie per utilizzare la console MemoryDB, le politiche di esempio in questa sezione concedono autorizzazioni aggiuntive. Gli esempi sono rilevanti anche per il e il. AWS SDKs AWS CLI Per ulteriori informazioni sulle autorizzazioni necessarie per utilizzare la console MemoryDB, vedere. [Autorizzazioni necessarie per utilizzare la console MemoryDB](#iam.identitybasedpolicies.minconpolicies)
Per istruzioni su come impostare gruppi e utenti IAM, consulta [Creazione del primo utente e gruppo di amministratori IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) nella *Guida per l'utente di IAM*.
**Importante**
Testa sempre in modo approfondito le Policy IAM prima di avvalertene in fase di produzione. Alcune azioni di MemoryDB che sembrano semplici possono richiedere altre azioni per supportarle quando si utilizza la console MemoryDB. Ad esempio, `memorydb:CreateCluster` concede le autorizzazioni per creare cluster MemoryDB. Tuttavia, per eseguire questa operazione, la console MemoryDB utilizza una serie di azioni per compilare gli elenchi delle `Describe` console. `List`
**Topics**
+ [Esempio 1: consentire a un utente l'accesso in sola lettura alle risorse di MemoryDB](#example-allow-list-current-memorydb-resources)
+ [Esempio 2: consentire a un utente di eseguire attività comuni di amministratore del sistema MemoryDB](#example-allow-specific-memorydb-actions)
+ [Esempio 3: consentire a un utente di accedere a tutte le azioni dell'API MemoryDB](#allow-unrestricted-access)
+ [Esempio 4: consentire a un utente di chiamare l'API IAM CreateServiceLinkedRole](#create-service-linked-role-policy)
### Esempio 1: consentire a un utente l'accesso in sola lettura alle risorse di MemoryDB
La seguente politica concede le autorizzazioni per le azioni di MemoryDB che consentono a un utente di elencare le risorse. In genere, si collega questo tipo di policy di autorizzazione a un gruppo di gestori.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MemDBUnrestricted",
"Effect":"Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"],
"Resource":"*"
}
]
}
```
------
### Esempio 2: consentire a un utente di eseguire attività comuni di amministratore del sistema MemoryDB
Le attività comuni dell'amministratore di sistema includono la modifica di cluster, parametri e gruppi di parametri. Un amministratore di sistema può anche voler ottenere informazioni sugli eventi di MemoryDB. La seguente politica concede a un utente le autorizzazioni per eseguire azioni di MemoryDB per queste attività comuni dell'amministratore di sistema. In genere, si collega questo tipo di policy di autorizzazione al gruppo degli amministratori di sistema.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MDBAllowSpecific",
"Effect": "Allow",
"Action": [
"memorydb:UpdateCluster",
"memorydb:DescribeClusters",
"memorydb:DescribeEvents",
"memorydb:UpdateParameterGroup",
"memorydb:DescribeParameterGroups",
"memorydb:DescribeParameters",
"memorydb:ResetParameterGroup"
],
"Resource": "*"
}
]
}
```
------
### Esempio 3: consentire a un utente di accedere a tutte le azioni dell'API MemoryDB
La seguente politica consente a un utente di accedere a tutte le azioni di MemoryDB. Consigliamo di concedere questo tipo di policy di autorizzazione solo a un utente amministratore.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MDBAllowAll",
"Effect":"Allow",
"Action":[
"memorydb:*" ],
"Resource":"*"
}
]
}
```
------
### Esempio 4: consentire a un utente di chiamare l'API IAM CreateServiceLinkedRole
La policy seguente permette a un utente di chiamare l'API IAM `CreateServiceLinkedRole` . Si consiglia di concedere questo tipo di politica di autorizzazione all'utente che richiama operazioni mutative di MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"CreateSLRAllows",
"Effect":"Allow",
"Action":[
"iam:CreateServiceLinkedRole"
],
"Resource":"*",
"Condition":{
"StringLike":{
"iam:AWS ServiceName":"memorydb.amazonaws.com"
}
}
}
]
}
```
------
# Autorizzazioni a livello di risorsa
È possibile limitare la portata delle autorizzazioni specificando le risorse in una policy IAM. Molte azioni AWS CLI API supportano un tipo di risorsa che varia a seconda del comportamento dell'azione. Ogni dichiarazione di policy IAM concede l'autorizzazione a un'operazione eseguita su una risorsa. Quando l'operazione non agisce su una risorsa designata oppure quando concedi l'autorizzazione per eseguire l'operazione su tutte le risorse, il valore della risorsa nella policy è un carattere jolly (\$1). Per molte operazioni API è possibile limitare le risorse che un utente può modificare specificando l'Amazon Resource Name (ARN) di una risorsa o un modello ARN che soddisfa più risorse. Per limitare le autorizzazioni in base alla risorsa, specifica la risorsa in base all'ARN.
**Formato ARN delle risorse MemoryDB**
**Nota**
Affinché le autorizzazioni a livello di risorsa siano efficaci, il nome della risorsa nella stringa ARN deve essere minuscolo.
+ Utente — *us-east-1:123456789012* arn:aws:memorydb ::user/user1
+ ACL — arn:aws:memorydb ::acl/my-acl *us-east-1:123456789012*
+ Cluster — arn:aws:memorydb ::cluster/my-cluster *us-east-1:123456789012*
+ Istantanea — arn:aws:memorydb ::snapshot/my-snapshot *us-east-1:123456789012*
+ Gruppo di parametri — arn:aws:memorydb ::parametergroup/ *us-east-1:123456789012* my-parameter-group
+ Gruppo di sottoreti — arn:aws:memorydb ::subnetgroup/ *us-east-1:123456789012* my-subnet-group
**Topics**
+ [Esempio 1: consentire a un utente l'accesso completo a tipi di risorse MemoryDB specifici](#example-allow-list-current-memorydb-resources-resource)
+ [Esempio 2: negare a un utente l'accesso a un cluster.](#example-allow-specific-memorydb-actions-resource)
## Esempio 1: consentire a un utente l'accesso completo a tipi di risorse MemoryDB specifici
La seguente politica consente esplicitamente l'accesso `account-id` completo specificato a tutte le risorse di tipo gruppo di sottorete, gruppo di sicurezza e cluster.
```
{
"Sid": "Example1",
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:subnetgroup/*",
"arn:aws:memorydb:us-east-1:account-id:securitygroup/*",
"arn:aws:memorydb:us-east-1:account-id:cluster/*"
]
}
```
## Esempio 2: negare a un utente l'accesso a un cluster.
L'esempio seguente nega esplicitamente l'`account-id`accesso specificato a un particolare cluster.
```
{
"Sid": "Example2",
"Effect": "Deny",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:cluster/name"
]
}
```
# Utilizzo dei ruoli collegati ai servizi per MemoryDB
[MemoryDB utilizza AWS Identity and Access Management ruoli collegati ai servizi (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un ruolo collegato al servizio è un tipo unico di ruolo IAM collegato direttamente a un AWS servizio, come MemoryDB. I ruoli collegati ai servizi MemoryDB sono predefiniti da MemoryDB. Includono tutte le autorizzazioni necessarie al servizio per richiamare servizi AWS per conto dei cluster.
Un ruolo collegato al servizio semplifica la configurazione di MemoryDB perché non è necessario aggiungere manualmente le autorizzazioni necessarie. I ruoli esistono già all'interno dell' AWS account ma sono collegati ai casi d'uso di MemoryDB e dispongono di autorizzazioni predefinite. Solo MemoryDB può assumere questi ruoli e solo questi ruoli possono utilizzare la politica di autorizzazioni predefinita. È possibile eliminare i ruoli solo dopo aver eliminato le risorse correlate. Ciò protegge le risorse di MemoryDB perché non è possibile rimuovere inavvertitamente le autorizzazioni necessarie per accedere alle risorse.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consulta la sezione [Servizi AWS che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cerca i servizi che riportano **Sì** nella colonna **Ruolo associato ai servizi**. Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
**Contents**
+ [Autorizzazioni del ruolo collegato ai servizi](#service-linked-role-permissions)
+ [Creazione di un ruolo collegato ai servizi (IAM)](#create-service-linked-role-iam)
+ [Utilizzo della console di IAM](#create-service-linked-role-iam-console)
+ [Utilizzo della CLI di IAM](#create-service-linked-role-iam-cli)
+ [Utilizzo dell'API di IAM](#create-service-linked-role-iam-api)
+ [Modifica della descrizione di un ruolo collegato ai servizi](#edit-service-linked-role)
+ [Utilizzo della console di IAM](#edit-service-linked-role-iam-console)
+ [Utilizzo della CLI di IAM](#edit-service-linked-role-iam-cli)
+ [Utilizzo dell'API di IAM](#edit-service-linked-role-iam-api)
+ [Eliminazione di un ruolo collegato ai servizi per MemoryDB](#delete-service-linked-role)
+ [Pulizia di un ruolo collegato ai servizi](#service-linked-role-review-before-delete)
+ [Eliminazione di un ruolo collegato ai servizi (console di IAM)](#delete-service-linked-role-iam-console)
+ [Eliminazione di un ruolo collegato ai servizi (CLI di IAM)](#delete-service-linked-role-iam-cli)
+ [Eliminazione di un ruolo collegato ai servizi (API di IAM)](#delete-service-linked-role-iam-api)
## Autorizzazioni di ruolo collegate ai servizi per MemoryDB
MemoryDB utilizza il ruolo collegato al servizio denominato DB: questa politica consente a **AWSServiceRoleForMemoryMemoryDB** di gestire le risorse per conto dell'utente, se necessario per la gestione AWS dei cluster.
La politica di autorizzazione dei ruoli collegati al servizio AWSService RoleForMemory DB consente a MemoryDB di completare le seguenti azioni sulle risorse specificate:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
Per ulteriori informazioni, consulta [AWS politica gestita: memoria DBService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-memorydbServiceRolePolicy).
**Per consentire a un'entità IAM di creare ruoli collegati ai servizi DB AWSService RoleForMemory**
Aggiungi la seguente istruzione di policy alle autorizzazioni per l'entità IAM.
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWS ServiceName": "memorydb.amazonaws.com"}}
}
```
**Per consentire a un'entità IAM di eliminare i ruoli collegati ai servizi AWSService RoleForMemory DB**
Aggiungi la seguente istruzione di policy alle autorizzazioni per l'entità IAM.
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWS ServiceName": "memorydb.amazonaws.com"}}
}
```
In alternativa, puoi utilizzare una policy AWS gestita per fornire l'accesso completo a MemoryDB.
## Creazione di un ruolo collegato ai servizi (IAM)
È possibile creare un ruolo collegato ai servizi utilizzando la console di IAM, la CLI o l'API.
### Creazione di un ruolo collegato ai servizi (Console di IAM)
Puoi utilizzare la console IAM per creare un ruolo collegato ai servizi.
**Come creare un ruolo collegato ai servizi (console)**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Nel riquadro di navigazione a sinistra della console IAM, scegli **Ruoli**. Quindi seleziona **Create new role (Crea nuovo ruolo)**.
1. In **Select type of trusted entity (Seleziona tipo di entità attendibile)**, scegli **Service AWS **.
1. In **Oppure seleziona un servizio per visualizzarne i casi d'uso**, scegli **MemoryDB**.
1. Scegli **Successivo: autorizzazioni**.
1. In **Policy name (Nome policy)**, si noti che `MemoryDBServiceRolePolicy` è necessario per questo ruolo. Scegli **Successivo: Tag**.
1. Si noti che i tag non sono supportati per i ruoli collegati al servizio. Scegliere **Next:Review** (Successivo:Rivedi).
1. (Facoltativo) In **Role description** (Descrizione ruolo) modifica la descrizione per il nuovo ruolo collegato ai servizi.
1. Rivedere il ruolo e scegliere **Crea ruolo**.
### Creazione di un ruolo collegato ai servizi (CLI di IAM)
Puoi utilizzare le operazioni IAM di AWS Command Line Interface per creare un ruolo collegato al servizio. Questo ruolo può includere la policy di attendibilità e le policy inline che il servizio richiede per assumere il ruolo.
**Per creare un ruolo collegato ai servizi (CLI)**
Attenersi alle operazioni seguenti:
```
$ aws iam [create-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) --aws-service-name memorydb.amazonaws.com
```
### Creazione di un ruolo collegato ai servizi (API di IAM)
È possibile utilizzare l'API di IAM per creare un ruolo collegato ai servizi. Questo ruolo può contenere la policy di attendibilità e le policy inline che il servizio richiede per assumere il ruolo.
**Per creare un ruolo collegato ai servizi (API)**
Utilizzare la chiamata API [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html). Nella richiesta, specificare un nome del servizio di `memorydb.amazonaws.com`.
## Modifica della descrizione di un ruolo collegato ai servizi per MemoryDB
MemoryDB non consente di modificare il ruolo collegato al servizio DB. AWSService RoleForMemory Dopo avere creato un ruolo collegato al servizio, non sarà possibile modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM.
### Modifica della descrizione di un ruolo collegato ai servizi (console di IAM)
È possibile utilizzare la console di IAM per modificare la descrizione di un ruolo collegato ai servizi.
**Per modificare la descrizione di un ruolo collegato ai servizi (console)**
1. **Nel riquadro di navigazione a sinistra della console IAM, scegli Ruoli.**
1. Scegliere il nome del ruolo da modificare.
1. Nella parte destra di **Role description** (Descrizione ruolo), scegliere **Edit** (Modifica).
1. Digita una nuova descrizione nella casella e scegli **Save (Salva)**.
### Modifica della descrizione di un ruolo collegato ai servizi (CLI di IAM)
Puoi utilizzare le operazioni IAM da AWS Command Line Interface per modificare una descrizione del ruolo collegato al servizio.
**Per modificare la descrizione di un ruolo collegato ai servizi (CLI)**
1. (Facoltativo) Per visualizzare la descrizione corrente di un ruolo, utilizza l'operazione AWS CLI for IAM. `[get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)`
**Example**
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name AWSServiceRoleForMemoryDB
```
Utilizzare il nome del ruolo, non l'ARN, per fare riferimento ai ruoli con le operazioni CLI. Ad esempio, per fare riferimento a un ruolo il cui ARN è `arn:aws:iam::123456789012:role/myrole`, puoi usare **myrole**.
1. Per aggiornare la descrizione di un ruolo collegato al servizio, utilizza l'operazione AWS CLI for IAM. `[update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)`
Per Linux, macOS o Unix:
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) \
--role-name AWSServiceRoleForMemoryDB \
--description "new description"
```
Per Windows:
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) ^
--role-name AWSServiceRoleForMemoryDB ^
--description "new description"
```
### Modifica della descrizione di un ruolo collegato ai servizi (API di IAM)
È possibile utilizzare l'API di IAM per modificare la descrizione di un ruolo collegato ai servizi.
**Per modificare la descrizione di un ruolo collegato ai servizi (API)**
1. (Facoltativo) Per visualizzare la descrizione corrente di un ruolo, utilizzare l'operazione API di IAM [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html).
**Example**
```
https://iam.amazonaws.com/
?Action=[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&AUTHPARAMS
```
1. Per aggiornare la descrizione di un ruolo, utilizzare l'operazione API di IAM [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html).
**Example**
```
https://iam.amazonaws.com/
?Action=[UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&Description="New description"
```
## Eliminazione di un ruolo collegato ai servizi per MemoryDB
Se non è più necessario utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, ti consigliamo di eliminare il ruolo. In questo modo non sarà più presente un'entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, è necessario effettuare la pulizia delle risorse associate al ruolo collegato ai servizi prima di poterlo eliminare.
MemoryDB non elimina automaticamente il ruolo collegato al servizio.
### Pulizia di un ruolo collegato ai servizi
Prima di poter utilizzare IAM per eliminare un ruolo collegato al servizio, verifica innanzitutto che al ruolo non siano associate risorse (cluster).
**Per verificare se il ruolo collegato ai servizi dispone di una sessione attiva nella console IAM**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Nel riquadro di navigazione a sinistra della console IAM, scegli **Ruoli**. Quindi scegli il nome (non la casella di controllo) del ruolo AWSService RoleForMemory DB.
1. Nella pagina **Summary** (Riepilogo) per il ruolo selezionato, scegliere la scheda **Access Advisor (Consulente accessi)**.
1. Nella scheda **Access Advisor** (Consulente accessi), esamina l'attività recente per il ruolo collegato ai servizi.
**Per eliminare le risorse MemoryDB che richiedono AWSService RoleForMemory DB (console)**
+ Per eliminare un cluster, consultare i seguenti argomenti:
+ [Utilizzando il Console di gestione AWS](getting-started.md#clusters.deleteclusters.viewdetails)
+ [Usando il AWS CLI](getting-started.md#clusters.delete.cli)
+ [Utilizzo dell'API MemoryDB](getting-started.md#clusters.delete.api)
### Eliminazione di un ruolo collegato ai servizi (console di IAM)
È possibile utilizzare la console IAM per eliminare un ruolo collegato ai servizi.
**Per eliminare un ruolo collegato ai servizi (console)**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Nel riquadro di navigazione a sinistra della console IAM, scegli **Ruoli**. Quindi, seleziona la casella di controllo accanto al nome del ruolo che desideri eliminare, non il nome o la riga stessa.
1. In operazioni **Role (Ruolo)** nella parte superiore della pagina, seleziona **Delete (Elimina)** ruolo.
1. Nella pagina di conferma, esamina i dati dell'ultimo accesso al servizio, che mostrano l'ultima volta che ciascuno dei ruoli selezionati ha effettuato l'ultimo accesso a un AWS servizio. In questo modo potrai verificare se il ruolo è attualmente attivo. Se desideri procedere, seleziona **Yes, Delete (Sì, elimina)** per richiedere l'eliminazione del ruolo collegato ai servizi.
1. Controlla le notifiche della console IAM per monitorare lo stato dell'eliminazione del ruolo collegato ai servizi. Poiché l'eliminazione del ruolo collegato ai servizi IAM è asincrona, una volta richiesta l'eliminazione del ruolo, il task di eliminazione può essere eseguito correttamente o meno. Se il task non viene eseguito correttamente, puoi scegliere **View details (Visualizza dettagli)** o **View Resources (Visualizza risorse)** dalle notifiche per capire perché l'eliminazione non è stata effettuata.
### Eliminazione di un ruolo collegato ai servizi (CLI di IAM)
Puoi utilizzare le operazioni IAM da AWS Command Line Interface per eliminare un ruolo collegato al servizio.
**Per eliminare un ruolo collegato ai servizi (CLI)**
1. Se non conosci il nome del ruolo collegato ai servizi da eliminare, inserisci il comando seguente: Questo comando elenca i ruoli e i relativi Amazon Resource Names (ARNs) nel tuo account.
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name role-name
```
Utilizzare il nome del ruolo, non l'ARN, per fare riferimento ai ruoli con le operazioni CLI. Ad esempio, per fare riferimento a un ruolo il cui ARN è `arn:aws:iam::123456789012:role/myrole`, puoi usare **myrole**.
1. Poiché un ruolo collegato ai servizi non può essere eliminato se è in uso o se a esso sono associate delle risorse, occorre inviare una richiesta di eliminazione. Se queste condizioni non sono soddisfatte, la richiesta può essere rifiutata. Acquisisci il valore di `deletion-task-id`dalla risposta per controllare lo stato del task di eliminazione. Per inviare una richiesta di eliminazione per un ruolo collegato ai servizi, inserire quanto segue:
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) --role-name role-name
```
1. Inserire quanto segue per verificare lo stato del processo di eliminazione:
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) --deletion-task-id deletion-task-id
```
Lo stato di un task di eliminazione può essere `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`o `FAILED`. Se l'eliminazione non viene eseguita correttamente, la chiamata restituisce il motivo dell'errore per consentire all'utente di risolvere il problema.
### Eliminazione di un ruolo collegato ai servizi (API di IAM)
È possibile utilizzare l'API di IAM; per eliminare un ruolo collegato ai servizi.
**Per eliminare un ruolo collegato ai servizi (API)**
1. Per inviare una richiesta di eliminazione per un ruolo collegato ai servizi, chiamare [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html). Nella richiesta, specifica il nome del ruolo.
Poiché un ruolo collegato ai servizi non può essere eliminato se è in uso o se a esso sono associate delle risorse, occorre inviare una richiesta di eliminazione. Se queste condizioni non sono soddisfatte, la richiesta può essere rifiutata. Acquisisci il valore di `DeletionTaskId`dalla risposta per controllare lo stato del task di eliminazione.
1. Chiamare [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) per controllare lo stato dell'eliminazione. Nella richiesta, specificare il `DeletionTaskId`.
Lo stato di un task di eliminazione può essere `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`o `FAILED`. Se l'eliminazione non viene eseguita correttamente, la chiamata restituisce il motivo dell'errore per consentire all'utente di risolvere il problema.
# AWS politiche gestite per MemoryDB
Per aggiungere autorizzazioni a utenti, gruppi e ruoli, è più facile utilizzare le policy AWS gestite che scriverle da soli. La [creazione di policy gestite dai clienti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) che forniscono al team solo le autorizzazioni di cui ha bisogno richiede tempo e competenza. Per iniziare rapidamente, puoi utilizzare le nostre politiche AWS gestite. Queste politiche coprono casi d'uso comuni e sono disponibili nel tuo AWS account. Per ulteriori informazioni sulle policy AWS gestite, consulta le [policy AWS gestite](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) nella *IAM User Guide*.
AWS i servizi mantengono e aggiornano le politiche AWS gestite. Non è possibile modificare le autorizzazioni nelle politiche AWS gestite. I servizi occasionalmente aggiungono altre autorizzazioni a una policy gestita da AWS per supportare nuove funzionalità. Questo tipo di aggiornamento interessa tutte le identità (utenti, gruppi e ruoli) a cui è collegata la policy. È più probabile che i servizi aggiornino una policy gestita da AWS quando viene avviata una nuova funzionalità o quando diventano disponibili nuove operazioni. I servizi non rimuovono le autorizzazioni da una policy AWS gestita, quindi gli aggiornamenti delle policy non comprometteranno le autorizzazioni esistenti.
Inoltre, AWS supporta politiche gestite per le funzioni lavorative che si estendono su più servizi. Ad esempio, la policy **ReadOnlyAccess** AWS gestita fornisce l'accesso in sola lettura a tutti i AWS servizi e le risorse. Quando un servizio lancia una nuova funzionalità, AWS aggiunge autorizzazioni di sola lettura per nuove operazioni e risorse. Per l’elenco e la descrizione delle policy di funzione dei processi, consultare la sezione [Policy gestite da AWS per funzioni di processi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) nella *Guida per l’utente di IAM*.
## AWS politica gestita: memoria DBService RolePolicy
Non puoi allegare la politica di DBService RolePolicy AWS gestione della memoria alle identità del tuo account. Questa politica fa parte del ruolo collegato al servizio AWS MemoryDB. Questo ruolo consente al servizio di gestire le interfacce di rete e i gruppi di sicurezza nell'account.
MemoryDB utilizza le autorizzazioni contenute in questa politica per gestire i gruppi di sicurezza e le interfacce di rete EC2. Ciò è necessario per gestire i cluster MemoryDB.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
## AWS-politiche gestite (predefinite) per MemoryDB
AWS affronta molti casi d'uso comuni fornendo policy IAM autonome create e amministrate da. AWS Le policy gestite concedono le autorizzazioni necessarie per i casi di utilizzo comune in modo da non dover cercare quali sono le autorizzazioni richieste. Per ulteriori informazioni, consulta [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) nella *Guida per l'utente di IAM*.
Le seguenti politiche AWS gestite, che puoi allegare agli utenti del tuo account, sono specifiche di MemoryDB:
### AmazonMemoryDBReadOnlyAccess
È possibile allegare la policy `AmazonMemoryDBReadOnlyAccess` alle identità IAM. Questa politica concede autorizzazioni amministrative che consentono l'accesso in sola lettura a tutte le risorse MemoryDB.
**AmazonMemoryDBReadOnlyAccess**- Concede l'accesso in sola lettura alle risorse di MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"
],
"Resource": "*"
}]
}
```
------
### AmazonMemoryDBFull- Accesso
È possibile allegare la policy `AmazonMemoryDBFullAccess` alle identità IAM. Questa politica concede autorizzazioni amministrative che consentono l'accesso completo a tutte le risorse di MemoryDB.
**AmazonMemoryDBFullAccesso**: concede l'accesso completo alle risorse di MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws-cn:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
È inoltre possibile creare politiche IAM personalizzate per consentire le autorizzazioni per le azioni dell'API MemoryDB. Puoi associare queste policy personalizzate agli utenti o ai gruppi IAM che richiedono tali autorizzazioni.
## MemoryDB aggiorna le politiche gestite AWS
Visualizza i dettagli sugli aggiornamenti alle politiche AWS gestite per MemoryDB da quando questo servizio ha iniziato a tenere traccia di queste modifiche. Per ricevere avvisi automatici sulle modifiche a questa pagina, iscriviti al feed RSS nella pagina della cronologia dei documenti di MemoryDB.
| Modifica | Descrizione | Data |
| --- | --- | --- |
| [AWS politica gestita: memoria DBService RolePolicy](#security-iam-awsmanpol-memorydbServiceRolePolicy)— Aggiungere una politica | Memory DBService RolePolicy ha aggiunto l'autorizzazione per memorydb:. ReplicateMultiRegionClusterData Questa autorizzazione consentirà al ruolo collegato al servizio di replicare i dati per i cluster multiregionali di MemoryDB. | 12/01/2024 |
| [AmazonMemoryDBFull- Accesso](#iam.identitybasedpolicies.predefinedpolicies-fullaccess)— Aggiungere una politica | MemoryDB ha aggiunto nuove autorizzazioni per descrivere ed elencare le risorse supportate. Queste autorizzazioni sono necessarie per consentire a MemoryDB di interrogare tutte le risorse supportate in un account. | 10/07/2021 |
| [AmazonMemoryDBReadOnlyAccess](#iam.identitybasedpolicies.predefinedpolicies-readonly)— Aggiungere una politica | MemoryDB ha aggiunto nuove autorizzazioni per descrivere ed elencare le risorse supportate. Queste autorizzazioni sono necessarie a MemoryDB per creare applicazioni basate su account interrogando tutte le risorse supportate in un account. | 10/07/2021 |
| MemoryDB ha iniziato a tracciare le modifiche | Avvio del servizio | 19/08/2021 |
# Autorizzazioni API MemoryDB: riferimento ad azioni, risorse e condizioni
Quando configuri le policy di [controllo degli accessi](iam.md#iam.accesscontrol) e di scrittura per le autorizzazioni da allegare a una policy IAM (basata sull'identità o basata sulle risorse), utilizza la tabella seguente come riferimento. La tabella elenca ogni operazione dell'API MemoryDB e le azioni corrispondenti per le quali è possibile concedere le autorizzazioni per eseguire l'azione. Puoi specificare le operazioni nel campo `Action` della policy e il valore di una risorsa nel campo `Resource` della policy. Se non diversamente indicato, la risorsa è obbligatoria. Alcuni campi includono sia una risorsa obbligatoria che risorse facoltative. Quando non è presente alcuna risorsa ARN, la risorsa nella policy è un carattere jolly (\$1).
**Nota**
Per specificare un'operazione, utilizza il prefisso `memorydb:` seguito dal nome dell'operazione API (ad esempio, `memorydb:DescribeClusters`).
Utilizzare le barre di scorrimento per visualizzare il resto della tabella.
**API MemoryDB e autorizzazioni richieste per le azioni**
| Operazioni dell'API MemoryDB | Autorizzazioni necessarie (operazioni API) | Resources |
| --- | --- | --- |
| [BatchUpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_BatchUpdateCluster.html) | `memorydb:BatchUpdateCluster` | Cluster |
| [CopySnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CopySnapshot.html) | `memorydb:CopySnapshot` `memorydb:TagResource` `s3:GetBucketLocation` `s3:ListAllMyBuckets` | Snapshot (origine, destinazione) \$1 \$1 |
| [CreateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateCluster.html) | `memorydb:CreateCluster` `memorydb:TagResource` `s3:GetObject` Quando si utilizza il parametro `SnapshotArns`, ogni membro dell'elenco `SnapshotArns` necessita della propria autorizzazione `s3:GetObject` con l'ARN `s3` come risorsa. | Gruppo di parametri (Facoltativo) cluster, snapshot, ID del gruppo di sicurezza e gruppo di sottoreti `arn:aws:s3:::my_bucket/snapshot1.rdb` Dove*my\$1bucket*/*snapshot1*sono il bucket S3 e lo snapshot da cui si desidera creare il cluster. |
| [CreateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateParameterGroup.html) | `memorydb:CreateParameterGroup` `memorydb:TagResource` | Gruppo di parametri |
| [CreateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSubnetGroup.html) | `memorydb:CreateSubnetGroup` `memorydb:TagResource` | Gruppo di sottoreti | \$1 |
| [CreateSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSnapshot.html) | `memorydb:CreateSnapshot` `memorydb:TagResource` | Istantanea, cluster |
| [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html) | `memorydb:CreateUser` `memorydb:TagResource` | Utente |
| [Crea ACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateACL.html) | `memorydb:CreateACL` `memorydb:TagResource` | Elenco di controllo degli accessi (ACL) |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | Cluster |
| [DeleteCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteCluster.html) | `memorydb:DeleteCluster` | Cluster. (Facoltativo) Snapshot |
| [DeleteParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteParameterGroup.html) | `memorydb:DeleteParameterGroup` | Gruppo di parametri |
| [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html) | `memorydb:DeleteSubnetGroup` | Gruppo di sottoreti |
| [DeleteSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSnapshot.html) | `memorydb:DeleteSnapshot` | Istantanea |
| [DeleteUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteUser.html) | `memorydb:DeleteUser` | Utente |
| [Elimina ACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteACL.html) | `memorydb:DeleteACL` | ACL |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | Cluster |
| [DescribeEngineVersions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEngineVersions.html) | `memorydb:DescribeEngineVersions` | Nessuna risorsa ARN: \$1 |
| [DescribeParameterGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameterGroups.html) | `memorydb:DescribeParameterGroups` | Gruppo di parametri |
| [DescribeParameters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameters.html) | `memorydb:DescribeParameters` | Gruppo di parametri |
| [DescribeSubnetGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSubnetGroups.html) | `memorydb:DescribeSubnetGroups` | Gruppo di sottoreti | \$1 |
| [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html) | `memorydb:DescribeEvents` | Nessuna risorsa ARN: \$1 |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | Cluster |
| [DescribeServiceUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html) | `memorydb:DescribeServiceUpdates` | Nessuna risorsa ARN: \$1 |
| [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html) | `memorydb:DescribeSnapshots` | Istantanea |
| [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) | `memorydb:DescribeUsers` | Utente |
| [Descriva ACLs](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeACLs.html) | `memorydb:DescribeACLs` | ACLs |
| [ListAllowedNodeTypeUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListAllowedNodeTypeUpdates.html) | `memorydb:ListAllowedNodeTypeUpdates` | Cluster |
| [ListTags](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListTags.html) | `memorydb:ListTags` | (Facoltativo) cluster, istantanea |
| [UpdateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateParameterGroup.html) | `memorydb:UpdateParameterGroup` | Gruppo di parametri |
| [UpdateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateSubnetGroup.html) | `memorydb:UpdateSubnetGroup` | Gruppo di sottoreti |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | ammasso. (Facoltativo) Gruppo di parametri, Gruppo di sicurezza |
| [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html) | `memorydb:UpdateUser` | Utente |
| [Aggiorna ACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateACL.html) | `memorydb:UpdateACL` | ACL |
| [UntagResource](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UntagResource.html) | `memorydb:UntagResource` | (Facoltativo) Cluster, snapshot |
| [ResetParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ResetParameterGroup.html) | `memorydb:ResetParameterGroup` | Gruppo di parametri |
| [FailoverShard](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html) | `memorydb:FailoverShard` | cluster, frammento |
# Registrazione di log e monitoraggio
Il monitoraggio è una parte importante per mantenere l'affidabilità, la disponibilità e le prestazioni di MemoryDB e delle altre AWS soluzioni. AWS fornisce i seguenti strumenti di monitoraggio per controllare MemoryDB, segnalare quando qualcosa non va e intraprendere azioni automatiche quando appropriato:
+ *Amazon CloudWatch* monitora AWS le tue risorse e le applicazioni su cui esegui AWS in tempo reale. Puoi raccogliere i parametri e tenerne traccia, creare pannelli di controllo personalizzati e impostare allarmi per inviare una notifica o intraprendere azioni quando un parametro specificato raggiunge una determinata soglia. Ad esempio, puoi tenere CloudWatch traccia dell'utilizzo della CPU o di altri parametri delle tue EC2 istanze Amazon e avviare automaticamente nuove istanze quando necessario. Per ulteriori informazioni, consulta la [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ *Amazon CloudWatch Logs* ti consente di monitorare, archiviare e accedere ai tuoi file di registro da EC2 istanze Amazon e altre fonti. CloudTrail CloudWatch I log possono monitorare le informazioni nei file di registro e avvisarti quando vengono raggiunte determinate soglie. Puoi inoltre archiviare i dati del log in storage estremamente durevole. Per ulteriori informazioni, consulta la [Amazon CloudWatch Logs User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).
+ *AWS CloudTrail*acquisisce le chiamate API e gli eventi correlati effettuati da o per conto del tuo AWS account e invia i file di log a un bucket Amazon S3 da te specificato. Puoi identificare quali utenti e account hanno chiamato AWS, l'indirizzo IP di origine da cui sono state effettuate le chiamate e quando sono avvenute le chiamate. Per ulteriori informazioni, consulta la [AWS CloudTrail Guida per l'utente di ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
# Monitoraggio di MemoryDB con Amazon CloudWatch
È possibile monitorare MemoryDB utilizzando CloudWatch, che raccoglie dati grezzi e li elabora in metriche leggibili e quasi in tempo reale. Queste statistiche vengono conservate per un periodo di 15 mesi, per permettere l'accesso alle informazioni storiche e offrire una prospettiva migliore sulle prestazioni del servizio o dell'applicazione web. È anche possibile impostare allarmi che controllano determinate soglie e inviare notifiche o intraprendere azioni quando queste soglie vengono raggiunte. Per ulteriori informazioni, consulta la [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
Le seguenti sezioni elencano le metriche e le dimensioni per MemoryDB.
**Topics**
+ [Parametri a livello di host](metrics.HostLevel.md)
+ [Metriche per MemoryDB](metrics.memorydb.md)
+ [Quali parametri è opportuno monitorare?](metrics.whichshouldimonitor.md)
+ [Scelta delle statistiche e dei periodi di un parametro](metrics.ChoosingStatisticsAndPeriods.md)
+ [Metriche di monitoraggio CloudWatch](cloudwatchmetrics.md)
# Parametri a livello di host
Il `AWS/MemoryDB` namespace include le seguenti metriche a livello di host per i singoli nodi.
**Vedi anche**
+ [Metriche per MemoryDB](metrics.memorydb.md)
| Parametro | Descrizione | Unità |
| --- | --- | --- |
| CPUUtilization | La percentuale di utilizzo CPU per l'intero host. Poiché Valkey e Redis OSS sono a thread singolo, consigliamo di monitorare EngineCPUUtilization la metrica per i nodi con 4 o più v. CPUs | Percentuale |
| FreeableMemory | La quantità di memoria libera disponibile sull'host. Questo numero è derivato dalla memoria nella RAM e nei buffer che il sistema operativo riporta come liberabili. | Byte |
| NetworkBytesIn | Il numero di byte che l'host ha letto dalla rete. | Byte |
| NetworkBytesOut | Il numero di byte inviati dall'istanza su tutte le interfacce di rete. | Byte |
| NetworkPacketsIn | Il numero di pacchetti ricevuti dall'istanza su tutte le interfacce di rete. Questo parametro identifica il volume del traffico in entrata in termini di numero di pacchetti su una singola istanza. | Conteggio |
| NetworkPacketsOut | Il numero di pacchetti inviati dall'istanza su tutte le interfacce di rete. Questo parametro identifica il volume del traffico in uscita in termini di numero di pacchetti su una singola istanza. | Conteggio |
| NetworkBandwidthInAllowanceExceeded | Numero di pacchetti modellati perché la larghezza di banda aggregata in entrata ha superato il valore massimo per l'istanza. | Conteggio |
| NetworkConntrackAllowanceExceeded | Numero di pacchetti modellati perché il rilevamento delle connessioni ha superato il valore massimo per l'istanza e non è stato possibile stabilire nuove connessioni. Ciò può comportare la perdita di pacchetti per il traffico da o verso l'istanza. | Conteggio |
| NetworkBandwidthOutAllowanceExceeded | Numero di pacchetti modellati perché la larghezza di banda aggregata in uscita ha superato il valore massimo per l'istanza. | Conteggio |
| NetworkPacketsPerSecondAllowanceExceeded | Numero di pacchetti modellati perché i pacchetti bidirezionali al secondo hanno superato il valore massimo per l'istanza. | Conteggio |
| NetworkMaxBytesIn | Il numero massimo di byte ricevuti al secondo in ogni minuto. | Byte |
| NetworkMaxBytesOut | Burst massimo al secondo di byte trasmessi in ogni minuto. | Byte |
| NetworkMaxPacketsIn | Il numero massimo di pacchetti ricevuti al secondo in ogni minuto. | Conteggio |
| NetworkMaxPacketsOut | Il numero massimo di pacchetti trasmessi al secondo in ogni minuto. | Conteggio |
| SwapUsage | La quantità di spazio di swapping utilizzato sull'host. | Byte |
# Metriche per MemoryDB
Lo spazio dei nomi `AWS/MemoryDB` include i parametri descritti di seguito.
Ad eccezione di`ReplicationLag`,, e `EngineCPUUtilization` `SuccessfulWriteRequestLatency``SuccessfulReadRequestLatency`, queste metriche derivano dai comandi Valkey e Redis OSS. **info** Ogni metrica viene calcolata a livello di nodo.
Per la documentazione completa del **INFO** comando, vedere [INFO](http://valkey.io/commands/info).
**Consulta anche:**
+ [Parametri a livello di host](metrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/memorydb/latest/devguide/metrics.memorydb.html)
Di seguito sono riportate le aggregazioni di certi tipi di comandi, derivati da **info commandstats**: La sezione commandstats fornisce statistiche basate sul tipo di comando, incluso il numero di chiamate.
[Per un elenco completo dei comandi disponibili, vedi comandi.](https://valkey.io/commands)
| Parametro | Descrizione | Unità |
| --- | --- | --- |
| EvalBasedCmds | Numero totale di comandi per i comandi basati su valutazione. Questo è derivato dalla commandstats statistica sommando eval e. evalsha | Conteggio |
| GeoSpatialBasedCmds | Numero totale di comandi per i comandi basati su GeoSpace. Questo è derivato dalla statistica. commandstats Viene ricavato sommando tutti i tipi di comandi geo: geoadd, geodist, geohash, geopos, georadius, e georadiusbymember. | Conteggio |
| GetTypeCmds | Il numero totale di comandi di tipo read-only. Viene derivato dalla commandstats statistica sommando tutti i comandi di read-only tipo (get,, hget scardlrange, e così via). | Conteggio |
| HashBasedCmds | Il numero totale di comandi basati su hash. Viene derivato dalla commandstats statistica sommando tutti i comandi che agiscono su uno o più hash (hget,, hkeys hvalshdel, e così via). | Conteggio |
| HyperLogLogBasedCmds | Il numero totale di comandi basati su HyperLogLog. Viene ricavato dalla commandstats statistica sommando tutti i pf tipi di comandi (pfadd, pfcountpfmerge, e così via). | Conteggio |
| JsonBasedCmds | Il numero totale di comandi basati su JSON. Questo è derivato dalla commandstats statistica sommando tutti i comandi che agiscono su uno o più oggetti del documento JSON. | Conteggio |
| KeyBasedCmds | Il numero totale di comandi basati su chiavi. Questo valore è derivato dalla commandstats statistica sommando tutti i comandi che agiscono su una o più chiavi su più strutture di dati (del, expirerename, e così via). | Conteggio |
| ListBasedCmds | Il numero totale di comandi basati su elenchi. Questo valore è derivato dalla commandstats statistica sommando tutti i comandi che agiscono su uno o più elenchi (lindex,, lrange lpushltrim, e così via). | Conteggio |
| PubSubBasedCmds | Il numero totale di comandi per la pub/sub funzionalità. Viene ricavato dalle commandstats statistiche sommando tutti i comandi utilizzati per la pub/sub funzionalità:psubscribe,publish,pubsub, punsubscribesubscribe, eunsubscribe. | Conteggio |
| SearchBasedCmds | Il numero totale di comandi di indicizzazione e ricerca secondari, inclusi i comandi di lettura e scrittura. Viene ricavato dalla commandstats statistica sommando tutti i comandi di ricerca che agiscono sugli indici secondari. | Conteggio |
| SearchBasedGetCmds | Numero totale di comandi secondari di sola lettura per l'indice e la ricerca. Viene derivato dalla commandstats statistica sommando tutti i comandi secondari di index e search get. | Conteggio |
| SearchBasedSetCmds | Numero totale di comandi secondari di indicizzazione e scrittura di ricerca. Viene derivato dalla commandstats statistica sommando tutti i comandi secondari dell'indice e del set di ricerca. | Conteggio |
| SearchNumberOfIndexes | Numero totale di indici. | Conteggio |
| SearchNumberOfIndexedKeys | Numero totale di chiavi indicizzate | Conteggio |
| SearchTotalIndexSize | Memoria (byte) utilizzata da tutti gli indici. | Byte |
| SetBasedCmds | Il numero totale di comandi basati su set. Questa viene ricavata dalla commandstats statistica sommando tutti i comandi che agiscono su uno o più set (scard,, sdiff saddsunion, e così via). | Conteggio |
| SetTypeCmds | Il numero totale di comandi di tipo write. Viene derivato dalla commandstats statistica sommando tutti i mutative tipi di comandi che operano sui dati (set,, hset saddlpop, e così via). | Conteggio |
| SortedSetBasedCmds | Il numero totale di comandi basati su set ordinati. Viene derivato dalla commandstats statistica sommando tutti i comandi che agiscono su uno o più set ordinati (zcount, zrange zrankzadd, e così via). | Conteggio |
| StringBasedCmds | Il numero totale di comandi basati su stringhe. Viene derivato dalla commandstats statistica sommando tutti i comandi che agiscono su una o più stringhe (strlen,setex, setrange e così via). | Conteggio |
| StreamBasedCmds | Il numero totale di comandi basati sul flusso. Viene derivato dalla commandstats statistica sommando tutti i comandi che agiscono su uno o più tipi di dati di stream (xrange, xlenxadd, xdel e così via). | Conteggio |
# Quali parametri è opportuno monitorare?
Le seguenti CloudWatch metriche offrono informazioni approfondite sulle prestazioni di MemoryDB. Nella maggior parte dei casi, si consiglia di impostare CloudWatch allarmi per queste metriche in modo da poter intraprendere azioni correttive prima che si verifichino problemi di prestazioni.
**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [Motore CPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage](#metrics-swap-usage)
+ [Espulsioni](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [Memoria](#metrics-memory)
+ [Rete](#metrics-network)
+ [Latenza](#metrics-latency)
+ [Replica](#metrics-replication)
## CPUUtilization
Si tratta di un parametro a livello di host restituito sotto forma di percentuale. Per ulteriori informazioni, consulta [Parametri a livello di host](metrics.HostLevel.md).
Per tipi di nodi più piccoli con 2v CPUs o meno, utilizza la `CPUUtilization ` metrica per monitorare il carico di lavoro.
In linea generale, ti consigliamo di impostare la soglia al 90% della CPU disponibile. Poiché Valkey e Redis OSS sono a thread singolo, il valore di soglia effettivo deve essere calcolato come una frazione della capacità totale del nodo. Ad esempio, supponi che il tipo di nodo in uso supporti due core. In questo caso, la soglia per CPUUtilization sarebbe 90/2 o 45%. [Per trovare il numero di core (vCPUs) del tuo tipo di nodo, consulta i prezzi di MemoryDB.](https://aws.amazon.com/memorydb/pricing/?p=ps)
Dovrai determinare la tua soglia, in base al numero di core nel nodo che stai utilizzando. Se superi questa soglia e il tuo carico di lavoro principale deriva dalle richieste di lettura, ridimensiona il cluster aggiungendo repliche di lettura. Se il carico di lavoro principale proviene da richieste di scrittura, ti consigliamo di aggiungere altri shard per distribuire il carico di lavoro di scrittura su più nodi primari.
**Suggerimento**
Invece di utilizzare la metrica Host-Level`CPUUtilization`, potresti utilizzare la metrica`EngineCPUUtilization`, che riporta la percentuale di utilizzo sul core del motore Valkey o Redis OSS. [Per vedere se questa metrica è disponibile sui tuoi nodi e per ulteriori informazioni, consulta Metrics for MemoryDB.](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html)
Per tipi di nodi più grandi con 4v CPUs o più, potresti voler utilizzare la `EngineCPUUtilization` metrica, che riporta la percentuale di utilizzo sul core del motore Valkey o Redis OSS. [Per vedere se questa metrica è disponibile sui tuoi nodi e per ulteriori informazioni, consulta Metrics for MemoryDB.](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html)
## Motore CPUUtilization
Per tipi di nodi più grandi con 4v CPUs o più, potresti voler utilizzare la `EngineCPUUtilization` metrica, che riporta la percentuale di utilizzo sul core del motore Valkey o Redis OSS. [Per vedere se questa metrica è disponibile sui tuoi nodi e per ulteriori informazioni, consulta Metrics for MemoryDB.](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html)
## SwapUsage
Si tratta di un parametro a livello di host restituito in byte. Per ulteriori informazioni, consulta [Parametri a livello di host](metrics.HostLevel.md).
Se la `FreeableMemory` CloudWatch metrica è vicina a 0 (ovvero inferiore a 100 MB) o la `SwapUsage` metrica è maggiore della metrica, è possibile che un nodo sia sotto pressione `FreeableMemory` in termini di memoria.
## Espulsioni
Questa è una metrica del motore. Ti consigliamo di determinare la tua soglia di allarme per questo parametro in base alle esigenze dell'applicazione.
## CurrConnections
Questa è una metrica del motore. Ti consigliamo di determinare la tua soglia di allarme per questo parametro in base alle esigenze dell'applicazione.
Un numero crescente di *CurrConnections*dati potrebbe indicare un problema con l'applicazione; per risolvere il problema, sarà necessario esaminare il comportamento dell'applicazione.
## Memoria
La memoria è un aspetto fondamentale di Valkey e di Redis OSS. È necessario comprendere l'utilizzo della memoria del cluster per evitare la perdita di dati e consentire la crescita futura del set di dati. [Le statistiche sull'utilizzo della memoria di un nodo sono disponibili nella sezione memoria del comando INFO.](https://valkey.io/commands/info)
## Rete
Uno dei fattori determinanti per la capacità della larghezza di banda di rete del cluster è il tipo di nodo selezionato. Per ulteriori informazioni sulla capacità di rete del tuo nodo, consulta i prezzi di [Amazon MemoryDB](https://aws.amazon.com/memorydb/pricing/).
## Latenza
I parametri di latenza `SuccessfulWriteRequestLatency` e la `SuccessfulReadRequestLatency` misurazione del tempo totale impiegato da MemoryDB per il motore Valkey per rispondere a una richiesta.
**Nota**
Quando si utilizza il pipelining Valkey con CLIENT REPLY abilitato sul client Valkey, possono verificarsi valori `SuccessfulWriteRequestLatency` e `SuccessfulReadRequestLatency` metriche gonfiati. Il pipelining Valkey è una tecnica per migliorare le prestazioni emettendo più comandi contemporaneamente, senza attendere la risposta a ogni singolo comando. [Per evitare valori gonfiati, consigliamo di configurare il client Redis per eseguire la pipeline dei comandi con CLIENT REPLY OFF.](https://valkey.io/commands/client-reply/)
## Replica
Il volume dei dati da replicare è visibile tramite il parametro `ReplicationBytes`. È possibile monitorare il throughput della capacità di `MaxReplicationThroughput` replica. Si consiglia di aggiungere altri shard quando si raggiunge il throughput massimo della capacità di replica.
`ReplicationDelayedWriteCommands`può anche indicare se il carico di lavoro supera il throughput massimo della capacità di replica. [Per ulteriori informazioni sulla replica in MemoryDB, vedere Understanding MemoryDB replication](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html)
# Scelta delle statistiche e dei periodi di un parametro
Sebbene CloudWatch ti consenta di scegliere qualsiasi statistica e periodo per ogni metrica, non tutte le combinazioni saranno utili. Ad esempio, le statistiche Media, Minima e Massima per CPUUtilization sono utili, ma la statistica Sum no.
Tutti gli esempi di MemoryDB vengono pubblicati per una durata di 60 secondi per ogni singolo nodo. Per ogni periodo di 60 secondi, una metrica del nodo conterrà solo un singolo campione.
# Metriche di monitoraggio CloudWatch
MemoryDB e CloudWatch sono integrati in modo da poter raccogliere una varietà di metriche. Puoi monitorare queste metriche utilizzando. CloudWatch
**Nota**
Gli esempi seguenti richiedono gli strumenti della CloudWatch riga di comando. Per ulteriori informazioni CloudWatch e per scaricare gli strumenti per sviluppatori, consulta la [pagina CloudWatch del prodotto](https://aws.amazon.com/cloudwatch).
Le seguenti procedure mostrano come CloudWatch raccogliere le statistiche sullo spazio di archiviazione per un cluster nell'ultima ora.
**Nota**
I `EndTime` valori `StartTime` and forniti negli esempi seguenti sono a scopo illustrativo. Assicurati di sostituire i valori di ora di inizio e fine appropriati per i tuoi nodi.
Per informazioni sui limiti di MemoryDB, consulta i limiti del [AWS servizio](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_memorydb) per MemoryDB.
## Metriche di monitoraggio CloudWatch (Console)
**Per raccogliere statistiche sull'utilizzo della CPU per un cluster**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Seleziona i nodi per i quali desideri visualizzare le metriche.
**Nota**
La selezione di oltre 20 nodi disabilita la visualizzazione dei parametri sulla console.
1. Nella pagina **Cluster** della Console di AWS gestione, fai clic sul nome di uno o più cluster.
Viene visualizzata la pagina di dettaglio del cluster.
1. Fare clic sulla scheda **Nodes (Nodi)** nella parte superiore della finestra.
1. Nella scheda **Nodi** della finestra di dettaglio, seleziona i nodi per i quali desideri visualizzare le metriche.
Nella parte inferiore della finestra della console viene visualizzato un elenco di CloudWatch metriche disponibili.
1. Fare clic sul parametro **CPU Utilization (Utilizzo CPU)**.
La CloudWatch console si aprirà e mostrerà le metriche selezionate. È possibile modificare i parametri visualizzati, mediante gli elenchi a discesa di **Statistic (Statistica)** e **Period (Periodo)** e la scheda **Time Range (Intervallo di tempo)**.
## Monitoraggio delle CloudWatch metriche tramite la CLI CloudWatch
**Per raccogliere statistiche sull'utilizzo della CPU per un cluster**
+ Utilizzate il CloudWatch comando **aws cloudwatch get-metric-statistics** con i seguenti parametri (notate che gli orari di inizio e fine sono mostrati solo a titolo di esempio; sarà necessario sostituirli con gli orari di inizio e di fine appropriati):
Per Linux, macOS o Unix:
```
1. aws cloudwatch get-metric-statistics CPUUtilization \
2. --dimensions=ClusterName=mycluster,NodeId=0002" \
3. --statistics=Average \
4. --namespace="AWS/MemoryDB" \
5. --start-time 2013-07-05T00:00:00 \
6. --end-time 2013-07-06T00:00:00 \
7. --period=60
```
Per Windows:
```
1. mon-get-stats CPUUtilization ^
2. --dimensions=ClusterName=mycluster,NodeId=0002" ^
3. --statistics=Average ^
4. --namespace="AWS/MemoryDB" ^
5. --start-time 2013-07-05T00:00:00 ^
6. --end-time 2013-07-06T00:00:00 ^
7. --period=60
```
## Monitoraggio delle CloudWatch metriche tramite l'API CloudWatch
**Per raccogliere statistiche sull'utilizzo della CPU per un cluster**
+ Chiamate l' CloudWatch API `GetMetricStatistics` con i seguenti parametri (tenete presente che gli orari di inizio e fine sono mostrati solo a titolo di esempio; sarà necessario sostituire gli orari di inizio e fine appropriati):
+ `Statistics.member.1``=Average`
+ `Namespace``=AWS/MemoryDB`
+ `StartTime``=2013-07-05T00:00:00`
+ `EndTime``=2013-07-06T00:00:00`
+ `Period``=60`
+ `MeasureName``=CPUUtilization`
+ `Dimensions``=ClusterName=mycluster,NodeId=0002`
**Example**
```
1. http://monitoring.amazonaws.com/
2. ?SignatureVersion=4
3. &Action=GetMetricStatistics
4. &Version=2014-12-01
5. &StartTime=2013-07-16T00:00:00
6. &EndTime=2013-07-16T00:02:00
7. &Period=60
8. &Statistics.member.1=Average
9. &Dimensions.member.1="ClusterName=mycluster"
10. &Dimensions.member.2="NodeId=0002"
11. &Namespace=Amazon/memorydb
12. &MeasureName=CPUUtilization
13. &Timestamp=2013-07-07T17%3A48%3A21.746Z
14. &AWS;AccessKeyId=<&AWS; Access Key ID>
15. &Signature=
```
# Monitoraggio degli eventi di MemoryDB
Quando si verificano eventi significativi per un cluster, MemoryDB invia una notifica a un argomento specifico di Amazon SNS. Esempi includono l'impossibilità di aggiungere un nodo, l'aggiunta di un nodo, la modifica di un gruppo di sicurezza e altro ancora. Tramite il monitoraggio degli eventi chiave, è possibile conoscere lo stato corrente dei cluster e, in base all'evento, intraprendere eventuali operazioni correttive.
**Topics**
+ [Gestione delle notifiche Amazon SNS di MemoryDB](mdbevents.sns.md)
+ [Visualizzazione degli eventi di MemoryDB](mdbevents.viewing.md)
+ [Notifiche di eventi Amazon SNS](memorydbsns.md)
# Gestione delle notifiche Amazon SNS di MemoryDB
Puoi configurare MemoryDB per inviare notifiche per importanti eventi del cluster utilizzando Amazon Simple Notification Service (Amazon SNS). Negli esempi che seguono, verrà configurato un cluster con l'Amazon Resource Name (ARN) di un argomento Amazon SNS per la ricezione di notifiche.
**Nota**
Tale argomento presuppone l'avvenuta registrazione a Amazon SNS, nonché la configurazione e sottoscrizione di un argomento Amazon SNS. Per ulteriori informazioni su come procedere, consultare la [Guida per gli sviluppatori di Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/).
## Aggiungere un argomento Amazon SNS.
Le seguenti sezioni mostrano come aggiungere un argomento Amazon SNS utilizzando la AWS console, l'o l'API MemoryDB. AWS CLI
### Aggiunta di un argomento Amazon SNS (console)
Nella seguente procedura viene mostrato come aggiungere un argomento Amazon SNS a un cluster.
**Nota**
Attenendosi alla presente procedura, è anche possibile modificare l'argomento Amazon SNS.
**Per aggiungere o modificare l'argomento Amazon SNS per un cluster (console)**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. In **Clusters (Cluster)**, scegliere il cluster al quale aggiungere o di cui modificare un ARN d'argomento Amazon SNS.
1. Scegli **Modifica**.
1. In **Modify Cluster (Modifica cluster)** nella sezione **Topic for SNS Notification (Argomento per notifica SNS)**, scegliere l'argomento SNS da aggiungere o scegliere **Manual ARN input (Input ARN manuale)** e digitare l'ARN dell'argomento Amazon SNS.
1. Scegli **Modifica**.
### Aggiungere un argomento Amazon SNS (AWS CLI)
Per aggiungere o modificare un argomento Amazon SNS per un cluster, usa il AWS CLI comando. `update-cluster`
L'esempio di codice riportato di seguito rappresenta l'aggiunta di un ARN d'argomento Amazon SNS a *my-cluster*.
Per Linux, macOS o Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Per Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Per ulteriori informazioni, consulta [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
### Aggiungere un argomento Amazon SNS (API MemoryDB)
Per aggiungere o aggiornare un argomento Amazon SNS per un cluster, richiama l'`UpdateCluster`azione con i seguenti parametri:
+ `ClusterName``=my-cluster`
+ `SnsTopicArn``=arn%3Aaws%3Asns%3Aus-east-1%3A565419523791%3AmemorydbNotifications`
Per aggiungere o aggiornare un argomento Amazon SNS per un cluster, chiama l'azione`UpdateCluster`.
Per ulteriori informazioni, consulta [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
## Attivazione e disattivazione delle notifiche Amazon SNS
È possibile, in base alle proprie esigenze, abilitare o disabilitare le notifiche relative a un cluster. La seguente procedura mostra come disabilitare le notifiche Amazon SNS.
### Attivazione e disattivazione delle notifiche Amazon SNS (Console)
**Per disabilitare le notifiche di Amazon SNS utilizzando il Console di gestione AWS**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Scegli il pulsante di opzione a sinistra del cluster per il quale desideri modificare la notifica.
1. Scegli **Modifica**.
1. In **Modify Cluster (Modifica cluster)** nella sezione **Topic for SNS Notification (Argomento per notifica SNS)**, scegliere *Disable Notifications (Disabilita notifiche)*.
1. Scegli **Modifica**.
### Abilitazione e disabilitazione delle notifiche Amazon SNS (CLI)AWS
Per disabilitare le notifiche Amazon SNS, occorre utilizzare il comando `update-cluster` con i seguenti parametri:
Per Linux, macOS o Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-status inactive
```
Per Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-status inactive
```
### Abilitazione e disabilitazione delle notifiche Amazon SNS (API MemoryDB)
Per disabilitare le notifiche Amazon SNS, occorre chiamare l'operazione `UpdateCluster` con i seguenti parametri:
+ `ClusterName``=my-cluster`
+ `SnsTopicStatus``=inactive`
Questa chiamata restituisce un output simile al seguente:
**Example**
```
1. https://memory-db.us-east-1.amazonaws.com/
2. ?Action=UpdateCluster
3. &ClusterName=my-cluster
4. &SnsTopicStatus=inactive
5. &Version=2021-01-01
6. &SignatureVersion=4
7. &SignatureMethod=HmacSHA256
8. &Timestamp=20210801T220302Z
9. &X-Amz-Algorithm=Amazon4-HMAC-SHA256
10. &X-Amz-Date=20210801T220302Z
11. &X-Amz-SignedHeaders=Host
12. &X-Amz-Expires=20210801T220302Z
13. &X-Amz-Credential=
14. &X-Amz-Signature=
```
# Visualizzazione degli eventi di MemoryDB
MemoryDB registra gli eventi relativi ai cluster, ai gruppi di sicurezza e ai gruppi di parametri. Queste informazioni includono la data, l'ora, il nome e tipo di fonte e una descrizione dell'evento. È possibile recuperare facilmente gli eventi dal registro utilizzando la console MemoryDB, il AWS CLI `describe-events` comando o l'azione API MemoryDB. `DescribeEvents`
Le procedure seguenti mostrano come visualizzare tutti gli eventi di MemoryDB delle ultime 24 ore (1440 minuti).
## Visualizzazione degli eventi di MemoryDB (Console)
La procedura seguente visualizza gli eventi utilizzando la console MemoryDB.
**Per visualizzare gli eventi utilizzando la console MemoryDB**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. **Nel riquadro di navigazione a sinistra, scegli Eventi.**
Viene visualizzata la schermata *Eventi* che elenca tutti gli eventi disponibili. Ogni riga dell'elenco rappresenta un evento e mostra l'origine dell'evento, il tipo di evento (ad esempio cluster, parameter-group, acl, security-group o subnet group), l'ora GMT dell'evento e la descrizione dell'evento.
La voce **Filter (Filtra)** consente di specificare se si preferisce visualizzare in elenco tutti gli eventi o solo quelli di un tipo specifico.
## Visualizzazione degli eventi MemoryDB (CLI AWS )
Per generare un elenco di eventi MemoryDB utilizzando il, utilizzare il AWS CLI comando. `describe-events` Tramite parametri facoltativi è anche possibile specificare il tipo, l'intervallo di tempo, il numero massimo e altre peculiarità degli eventi da includere nell'elenco.
Il codice seguente elenca fino a 40 eventi del cluster.
```
aws memorydb describe-events --source-type cluster --max-results 40
```
Il codice seguente elenca tutti gli eventi delle ultime 24 ore (1440 minuti).
```
aws memorydb describe-events --duration 1440
```
L'output del comando `describe-events` è simile a quello riportato.
```
{
"Events": [
{
"Date": "2021-03-29T22:17:37.781Z",
"Message": "Added node 0001 in Availability Zone us-east-1a",
"SourceName": "memorydb01",
"SourceType": "cluster"
},
{
"Date": "2021-03-29T22:17:37.769Z",
"Message": "cluster created",
"SourceName": "memorydb01",
"SourceType": "cluster"
}
]
}
```
Per ulteriori informazioni, tra cui i parametri disponibili e i valori consentiti per tali parametri, consulta [https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html).
## Visualizzazione degli eventi MemoryDB (API MemoryDB)
Per generare un elenco di eventi MemoryDB utilizzando l'API MemoryDB, utilizzate l'azione. `DescribeEvents` Tramite parametri facoltativi è anche possibile specificare il tipo, l'intervallo di tempo, il numero massimo e altre peculiarità degli eventi da includere nell'elenco.
Il codice seguente elenca i 40 eventi -cluster più recenti.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&MaxResults=40
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
Il codice seguente elenca gli eventi del cluster delle ultime 24 ore (1440 minuti).
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&Duration=1440
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
Le operazioni descritte in precedenza dovrebbero generare un output simile al seguente.
```
cluster created
cluster
2021-08-02T18:22:18.202Z
my-memorydb-primary
(...output omitted...)
e21c81b4-b9cd-11e3-8a16-7978bb24ffdf
```
Per ulteriori informazioni, tra cui i parametri disponibili e i valori consentiti per tali parametri, consulta [https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html).
# Notifiche di eventi Amazon SNS
MemoryDB può pubblicare messaggi utilizzando Amazon Simple Notification Service (SNS) quando si verificano eventi significativi in un cluster. Questa funzionalità può essere utilizzata per aggiornare gli elenchi di server sulle macchine client connesse agli endpoint dei singoli nodi di un cluster.
**Nota**
Per ulteriori informazioni su Amazon Simple Notification Service (SNS) e relativi prezzi e per i link alla documentazione Amazon SNS, consulta la[Pagina del prodotto Amazon SNS](https://aws.amazon.com/sns).
Le notifiche vengono pubblicate su un Amazon SNS specificato*Argomento*. Di seguito sono riportati i requisiti delle notifiche:
+ È possibile configurare un solo argomento per le notifiche di MemoryDB.
+ L' AWS account proprietario dell'argomento Amazon SNS deve essere lo stesso account proprietario del cluster su cui sono abilitate le notifiche.
## Eventi MemoryDB
I seguenti eventi MemoryDB attivano le notifiche Amazon SNS:
| Nome evento | Messaggio | Descrizione |
| --- | --- | --- |
| MemoryDB: AddNodeComplete | "Modified number of nodes from %d to %d" | Un nodo è stato aggiunto al cluster ed è pronto per l'uso. |
| MemoryDB: AddNodeFailed a causa di indirizzi IP gratuiti insufficienti | "Failed to modify number of nodes from %d to %d due to insufficient free IP addresses" | Impossibile aggiungere un nodo perché non ci sono abbastanza indirizzi IP disponibili. |
| DB di memoria: ClusterParametersChanged | "Updated parameter group for the cluster" In caso di creazione, viene inviato anche il messaggio `"Updated to use a ParameterGroup %s"` | Uno o più parametri del cluster sono stati modificati. |
| DB di memoria: ClusterProvisioningComplete | "Cluster created." | Il provisioning di un cluster è completato e i nodi del cluster sono pronti per l'uso. |
| MemoryDB: a ClusterProvisioningFailed causa di uno stato di rete incompatibile | "Failed to create cluster due to incompatible network state. %s" | È stato effettuato un tentativo di lanciare un nuovo cluster in un cloud privato virtuale (VPC) inesistente. |
| DB di memoria: ClusterRestoreFailed | "Restore from %s failed for node %s. %s" | MemoryDB non è riuscito a popolare il cluster con i dati delle istantanee. Ciò potrebbe essere dovuto a un file di snapshot inesistente in Amazon S3 o ad autorizzazioni errate su quel file. Se descrivi il cluster, lo stato sarà. `restore-failed` Dovrai eliminare il cluster e ricominciare da capo. Per ulteriori informazioni, consulta [Seminare un nuovo cluster con un'istantanea creata esternamente](snapshots-seeding-redis.md). |
| DB di memoria: ClusterScalingComplete | `"Succeeded applying modification to node type to %s."` | Scalabilità verso il cluster completata con successo. |
| DB di memoria: ClusterScalingFailed | `"Failed applying modification to node type to %s."` | Operazione di scalabilità sul cluster non riuscita. |
| DB di memoria: NodeReplaceStarted | "Recovering node %s" | MemoryDB ha rilevato che l'host che esegue un nodo è danneggiato o irraggiungibile e ha iniziato a sostituire il nodo. La voce DNS per il nodo sostituito non viene modificata. Nella maggior parte dei casi, non è necessario aggiornare l'elenco dei server per i client, quando si verifica questo evento. Tuttavia, alcune librerie client potrebbero smettere di usare il nodo anche dopo che MemoryDB ha sostituito il nodo; in questo caso, l'applicazione dovrebbe aggiornare l'elenco dei server quando si verifica questo evento. |
| MemoryDB: NodeReplaceComplete | "Finished recovery for node %s" | MemoryDB ha rilevato che l'host che esegue un nodo è danneggiato o irraggiungibile e ha completato la sostituzione del nodo. La voce DNS per il nodo sostituito non viene modificata. Nella maggior parte dei casi, non è necessario aggiornare l'elenco dei server per i client, quando si verifica questo evento. Tuttavia, alcune librerie client potrebbero smettere di usare il nodo anche dopo che MemoryDB ha sostituito il nodo; in questo caso, l'applicazione dovrebbe aggiornare l'elenco dei server quando si verifica questo evento. |
| MemoryDB: CreateClusterComplete | "Cluster created" | Il cluster è stato creato con successo. |
| MemoryDB: CreateClusterFailed | "Failed to create cluster due to unsuccessful creation of its node(s)." e "Deleting all nodes belonging to this cluster." | Il cluster non è stato creato. |
| MemoryDB: DeleteClusterComplete | "Cluster deleted." | L'eliminazione di un cluster e di tutti i nodi associati è stata completata. |
| DB di memoria: FailoverComplete | `"Failover to replica node %s completed"` | Il failover su un nodo di replica ha avuto esito positivo. |
| DB di memoria: NodeReplacementCanceled | "The replacement of node %s which was scheduled during the maintenance window from start time: %s, end time: %s has been canceled" | È stata annullata la sostituzione programmata di un nodo nel cluster. |
| DB di memoria: NodeReplacementRescheduled | "The replacement in maintenance window for node %s has been re-scheduled from previous start time: %s, previous end time: %s to new start time: %s, new end time: %s" | È stata riprogrammata la già prevista sostituzione di un nodo del cluster in una nuova finestra riportata nella notifica. Per informazioni su cosa fare in questa situazione, consulta [Sostituzione dei nodi](nodes.nodereplacement.md). |
| DB di memoria: NodeReplacementScheduled | "The node %s is scheduled for replacement during the maintenance window from start time: %s to end time: %s" | È stata programmata la sostituzione di un nodo del cluster nella finestra riportata nella notifica. Per informazioni su cosa fare in questa situazione, consulta [Sostituzione dei nodi](nodes.nodereplacement.md). |
| DB di memoria: RemoveNodeComplete | "Removed node %s" | Un nodo è stato rimosso dal cluster. |
| MemoryDB: SnapshotComplete | "Snapshot %s succeeded for node %s" | Un'istantanea è stata completata con successo. |
| MemoryDB: SnapshotFailed | "Snapshot %s failed for node %s" | Un'istantanea non è riuscita. Vedi gli eventi del cluster per una causa più dettagliata. Lo stato della snapshot, riportato in [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html), sarà `failed`. |
# Registrazione delle chiamate API MemoryDB con AWS CloudTrail
MemoryDB è integrato con AWS CloudTrail, un servizio che fornisce un registro delle azioni intraprese da un utente, ruolo o AWS servizio in MemoryDB. CloudTrail acquisisce tutte le chiamate API per MemoryDB come eventi, incluse le chiamate dalla console di MemoryDB e dalle chiamate di codice alle operazioni dell'API MemoryDB. Se crei un trail, puoi abilitare la distribuzione continua di CloudTrail eventi a un bucket Amazon S3, inclusi gli eventi per MemoryDB. **Se non configuri un percorso, puoi comunque visualizzare gli eventi più recenti nella CloudTrail console nella cronologia degli eventi.** Utilizzando le informazioni raccolte da CloudTrail, è possibile determinare la richiesta effettuata a MemoryDB, l'indirizzo IP da cui è stata effettuata la richiesta, chi ha effettuato la richiesta, quando è stata effettuata e dettagli aggiuntivi.
Per ulteriori informazioni CloudTrail, consulta la Guida per l'[AWS CloudTrail utente](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## Informazioni su MemoryDB in CloudTrail
CloudTrail è abilitato sul tuo AWS account al momento della creazione dell'account. **Quando si verifica un'attività in MemoryDB, tale attività viene registrata in un CloudTrail evento insieme ad altri eventi di AWS servizio nella cronologia degli eventi.** Puoi visualizzare, cercare e scaricare gli eventi recenti nel tuo AWS account. Per ulteriori informazioni, consulta [Visualizzazione degli eventi con la cronologia degli CloudTrail eventi](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Per una registrazione continua degli eventi nel tuo AWS account, inclusi gli eventi per MemoryDB, crea un percorso. Un trail consente di CloudTrail inviare file di log a un bucket Amazon S3. Per impostazione predefinita, quando crei un trail nella console, il trail sarà valido in tutte le regioni. Il trail registra gli eventi da tutte le regioni della AWS partizione e consegna i file di log al bucket Amazon S3 specificato. Inoltre, puoi configurare altri AWS servizi per analizzare ulteriormente e agire in base ai dati sugli eventi raccolti nei log. CloudTrail Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Panoramica della creazione di un trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Servizi e integrazioni supportati](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configurazione delle notifiche Amazon SNS per CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Ricezione di file di CloudTrail registro da più regioni](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) e [ricezione di file di CloudTrail registro da](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html) più account
Tutte le azioni di MemoryDB vengono registrate da. CloudTrail Ad esempio, le chiamate a `DescribeClusters` e le `CreateCluster` `UpdateCluster` azioni generano voci nei file di registro. CloudTrail
Ogni evento o voce di log contiene informazioni sull'utente che ha generato la richiesta. Le informazioni di identità consentono di determinare quanto segue:
+ Se la richiesta è stata effettuata con le credenziali dell'utente IAM o root.
+ Se la richiesta è stata effettuata con le credenziali di sicurezza temporanee per un ruolo o un utente federato.
+ Se la richiesta è stata effettuata da un altro AWS servizio.
Per ulteriori informazioni, consulta [Elemento CloudTrail userIdentity](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Comprensione delle voci dei file di registro di MemoryDB
Un trail è una configurazione che consente la distribuzione di eventi come file di log in un bucket Amazon S3 specificato dall'utente. CloudTrail i file di registro contengono una o più voci di registro. Un evento rappresenta una singola richiesta proveniente da qualsiasi fonte e include informazioni sull'azione richiesta, la data e l'ora dell'azione, i parametri della richiesta e così via. CloudTrail i file di registro non sono una traccia ordinata dello stack delle chiamate API pubbliche, quindi non vengono visualizzati in un ordine specifico.
L'esempio seguente mostra una voce di CloudTrail registro che illustra l'`CreateCluster`azione.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T17:56:46Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"nodeType": "db.r6g.large",
"subnetGroupName": "memorydb-subnet-group",
"aCLName": "open-access"
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "creating",
"numberOfShards": 1,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"enginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "09:00-10:00",
"aCLName": "open-access",
"dataTiering": "false",
"autoMinorVersionUpgrade": true
}
},
"requestID": "506fc951-9ae2-42bb-872c-98028dc8ed11",
"eventID": "2ecf3dc3-c931-4df0-a2b3-be90b596697e",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
L'esempio seguente mostra una voce di CloudTrail registro che illustra l'`DescribeClusters`azione. Si noti che per tutte le chiamate MemoryDB Descrive e List (`Describe*`and`List*`), la `responseElements` sezione viene rimossa e appare come. `null`
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T18:39:51Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "DescribeClusters",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.describe-clusters",
"requestParameters": {
"maxResults": 50,
"showShardDetails": true
},
"responseElements": null,
"requestID": "5e831993-52bb-494d-9bba-338a117c2389",
"eventID": "32a3dc0a-31c8-4218-b889-1a6310b7dd50",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
L'esempio seguente mostra una voce di CloudTrail registro che registra un'`UpdateCluster`azione.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:23:20Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "UpdateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.update-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"snapshotWindow": "04:00-05:00",
"shardConfiguration": {
"shardCount": 2
}
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "updating",
"numberOfShards": 2,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"address": "clustercfg.memorydb-cluster.cde8da.memorydb.us-east-1.amazonaws.com",
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "04:00-05:00",
"autoMinorVersionUpgrade": true,
"DataTiering": "false"
}
},
"requestID": "dad021ce-d161-4365-8085-574133afab54",
"eventID": "e0120f85-ab7e-4ad4-ae78-43ba15dee3d8",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
L'esempio seguente mostra una voce di CloudTrail registro che illustra l'`CreateUser`azione. Si noti che per le chiamate MemoryDB che contengono dati sensibili, tali dati verranno oscurati nell' CloudTrail evento corrispondente, come mostrato nella sezione seguente. `requestParameters`
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:56:13Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-user",
"requestParameters": {
"userName": "memorydb-user",
"authenticationMode": {
"type": "password",
"passwords": [
"HIDDEN_DUE_TO_SECURITY_REASONS"
]
},
"accessString": "~* &* -@all +@read"
},
"responseElements": {
"user": {
"name": "memorydb-user",
"status": "active",
"accessString": "off ~* &* -@all +@read",
"aCLNames": [],
"minimumEngineVersion": "6.2",
"authentication": {
"type": "password",
"passwordCount": 1
},
"aRN": "arn:aws:memorydb:us-east-1:123456789012:user/memorydb-user"
}
},
"requestID": "ae288b5e-80ab-4ff8-989a-5ee5c67cd193",
"eventID": "ed096e3e-16f1-4a23-866c-0baa6ec769f6",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
# Convalida della conformità per MemoryDB
I revisori di terze parti valutano la sicurezza e la conformità di MemoryDB come parte di più AWS programmi di conformità. Questo include:
+ Payment Card Industry Data Security Standard (PCI DSS). Per ulteriori informazioni, consulta [PCI DSS](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/).
+ Health Insurance Portability and Accountability Act Business Associate Agreement (HIPAA BAA). Per ulteriori informazioni, consulta [Compliance HIPAA](https://aws.amazon.com/compliance/hipaa-compliance).
+ System and Organization Controls (SOC) 1, 2 e 3. Per ulteriori informazioni, consulta [SOC](https://aws.amazon.com/compliance/soc-faqs).
+ Programma federale di gestione dei rischi e delle autorizzazioni (FedRAMP) Moderato. Per ulteriori informazioni, consulta [FedRAMP](https://aws.amazon.com/compliance/services-in-scope/FedRAMP/).
+ ISO/IEC 27001:2013, 27017:2015, 27018:2019 e 9001:2015. ISO/IEC [Per ulteriori informazioni, consulta le certificazioni e i servizi ISO e CSA STAR.AWS](https://aws.amazon.com/compliance/iso-certified/)
Per un elenco dei AWS servizi che rientrano nell'ambito di specifici programmi di conformità, consulta la sezione [AWS Servizi rientranti nell'ambito del programma di conformità](https://aws.amazon.com/compliance/services-in-scope/).
È possibile scaricare report di audit di terze parti utilizzando AWS Artifact. Per ulteriori informazioni, consulta [Scaricamento dei report in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
La vostra responsabilità di conformità quando utilizzate MemoryDB è determinata dalla sensibilità dei vostri dati, dagli obiettivi di conformità della vostra azienda e dalle leggi e dai regolamenti applicabili. AWS fornisce le seguenti risorse per contribuire alla conformità:
+ [Security and Compliance Quick Start Guides (Guide Quick Start Sicurezza e compliance)](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance): queste guide alla distribuzione illustrano considerazioni relative all'architettura e forniscono procedure per la distribuzione di ambienti di base incentrati sulla sicurezza e sulla conformità su AWS.
+ [AWS Risorse per](https://aws.amazon.com/compliance/resources/) la per la conformità: questa raccolta di cartelle di lavoro e guide potrebbe riguardare il settore e la località in cui operi.
+ [Valutazione delle risorse con le regole](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) nella *Guida per gli sviluppatori di AWS Config *: AWS Config valuta il livello di conformità delle configurazioni delle risorse con pratiche interne, linee guida e regolamenti industriali.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Questo AWS servizio offre una visione completa dello stato di sicurezza dell'utente e consente di verificare la conformità agli standard e alle best practice del settore della sicurezza. AWS
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html): questo AWS servizio consente di verificare continuamente AWS l'utilizzo per semplificare la gestione del rischio e la conformità alle normative e agli standard di settore.
# Sicurezza dell'infrastruttura in MemoryDB
In quanto servizio gestito, MemoryDB è protetto dalle procedure di sicurezza di rete AWS globali descritte nel white paper [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf).
Utilizzi chiamate API AWS pubblicate per accedere a MemoryDB attraverso la rete. I client devono supportare Transport Layer Security (TLS) 1.2 o versioni successive. È consigliabile TLS 1.3 o versioni successive. I client devono, inoltre, supportare le suite di crittografia con PFS (Perfect Forward Secrecy), ad esempio Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La maggior parte dei sistemi moderni come Java 7 e versioni successive, supporta tali modalità.
Inoltre, le richieste devono essere firmate tramite un ID chiave di accesso e una chiave di accesso segreta associata a un principal IAM. In alternativa, è possibile utilizzare [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) per generare le credenziali di sicurezza temporanee per firmare le richieste.
# Riservatezza del traffico Internet
MemoryDB utilizza le seguenti tecniche per proteggere i dati e proteggerli da accessi non autorizzati:
+ **[MemoryDB e Amazon VPC](vpcs.md)** spiega il tipo di gruppo di sicurezza necessario per l'installazione.
+ **[API MemoryDB e endpoint VPC di interfaccia ()AWS PrivateLink](memorydb-privatelink.md)**ti consente di stabilire una connessione privata tra il tuo VPC e gli endpoint dell'API MemoryDB.
+ **[Gestione delle identità e degli accessi in MemoryDB](iam.md)** per concedere e limitare le operazioni di utenti, gruppi e ruoli.
# MemoryDB e Amazon VPC
Il servizio Virtual Private Cloud (Amazon VPC) di Amazon definisce una rete virtuale che ricorda molto un data center tradizionale. Quando configuri un cloud privato virtuale (VPC) con Amazon VPC, puoi selezionarne l'intervallo di indirizzi IP, creare sottoreti e configurare tabelle di routing, gateway di rete e impostazioni di sicurezza. Puoi anche aggiungere un cluster alla rete virtuale e controllare l'accesso al cluster utilizzando i gruppi di sicurezza Amazon VPC.
Questa sezione spiega come configurare manualmente un cluster MemoryDB in un VPC. Queste informazioni sono destinate agli utenti che desiderano una comprensione più approfondita del modo in cui MemoryDB e Amazon VPC interagiscono.
**Topics**
+ [Comprendere MemoryDB e VPCs](vpcs.mdb.md)
+ [Modelli di accesso per accedere a un cluster MemoryDB in un Amazon VPC](memorydb-vpc-accessing.md)
+ [Creazione di un virtual private cloud (VPC).](VPCs.creatingVPC.md)
# Comprendere MemoryDB e VPCs
MemoryDB è completamente integrato con Amazon VPC. Per gli utenti di MemoryDB, ciò significa quanto segue:
+ MemoryDB avvia sempre il cluster in un VPC.
+ Se sei nuovo AWS, verrà creato automaticamente un VPC predefinito.
+ Se disponi di un VPC predefinito e non specifichi una sottorete all'avvio di un cluster, il cluster si avvia nel Amazon VPC predefinito.
Per ulteriori informazioni, consulta la sezione relativa al [rilevamento delle piattaforme supportate e di un eventuale VPC di default](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#detecting-platform).
Con Amazon VPC, puoi creare una rete virtuale nel AWS cloud che assomiglia molto a un data center tradizionale. Puoi configurare il tuo VPC, inclusa la selezione dell'intervallo di indirizzi IP, la creazione di sottoreti e la configurazione di tabelle di routing, gateway di rete e impostazioni di sicurezza.
MemoryDB gestisce gli aggiornamenti software, l'applicazione di patch, il rilevamento degli errori e il ripristino.
## Panoramica di MemoryDB in un VPC
+ Un VPC è una porzione isolata del AWS Cloud a cui viene assegnato un proprio blocco di indirizzi IP.
+ Un gateway Internet collega il tuo VPC direttamente a Internet e fornisce l'accesso ad altre AWS risorse come Amazon Simple Storage Service (Amazon S3) che funzionano all'esterno del tuo VPC.
+ Una sottorete Amazon VPC è un segmento dell'intervallo di indirizzi IP di un VPC in cui è possibile isolare AWS le risorse in base alle proprie esigenze operative e di sicurezza.
+ Un gruppo di sicurezza Amazon VPC controlla il traffico in entrata e in uscita per i cluster MemoryDB e le istanze Amazon. EC2
+ Puoi avviare un cluster MemoryDB nella sottorete. I nodi dispongono di indirizzi IP privati compresi nell'intervallo di indirizzi della sottorete.
+ Puoi anche avviare EC2 istanze Amazon nella sottorete. Ogni EC2 istanza Amazon ha un indirizzo IP privato dall'intervallo di indirizzi della sottorete. L' EC2 istanza Amazon può connettersi a qualsiasi nodo della stessa sottorete.
+ Affinché un' EC2 istanza Amazon nel tuo VPC sia raggiungibile da Internet, devi assegnare all'istanza un indirizzo pubblico statico chiamato indirizzo IP elastico.
## Prerequisiti
Per creare un cluster MemoryDB all'interno di un VPC, il VPC deve soddisfare i seguenti requisiti:
+ Il tuo VPC deve consentire istanze Amazon EC2 non dedicate. Non è possibile utilizzare MemoryDB in un VPC configurato per la tenancy di istanze dedicate.
+ È necessario definire un gruppo di sottoreti per il VPC. MemoryDB utilizza quel gruppo di sottorete per selezionare una sottorete e gli indirizzi IP all'interno di quella sottorete da associare ai nodi.
+ È necessario definire un gruppo di sicurezza per il VPC oppure è possibile utilizzare il gruppo di sicurezza predefinito fornito.
+ I blocchi CIDR per ogni sottorete devono essere sufficientemente grandi da fornire indirizzi IP di riserva da utilizzare a MemoryDB durante le attività di manutenzione.
## Routing e sicurezza
Puoi configurare il routing nel tuo VPC per controllare dove scorre il traffico (ad esempio, verso il gateway Internet o il gateway privato virtuale). Con un gateway Internet, il tuo VPC ha accesso diretto ad altre AWS risorse che non sono in esecuzione nel tuo VPC. Se scegli di avere solo un gateway privato virtuale con una connessione alla rete locale della tua organizzazione, puoi instradare il traffico diretto a Internet tramite la VPN e utilizzare le politiche di sicurezza locali e il firewall per controllare l'uscita. In tal caso, l'accesso alle risorse tramite Internet comporta costi aggiuntivi per la larghezza di banda. AWS
Puoi utilizzare i gruppi di sicurezza Amazon VPC per proteggere i cluster MemoryDB e le istanze Amazon nel EC2 tuo Amazon VPC. I gruppi di sicurezza operano come un firewall a livello di istanza, non di sottorete.
**Nota**
Ti consigliamo vivamente di utilizzare nomi DNS per connetterti ai tuoi nodi, poiché l'indirizzo IP sottostante può cambiare nel tempo.
## Documentazione Amazon VPC
Amazon VPC dispone della propria documentazione che descrive come creare e usare l’Amazon VPC. La tabella seguente mostra dove trovare informazioni nelle guide di Amazon VPC.
| Descrizione | Documentazione |
| --- | --- |
| Come iniziare a usare Amazon VPC | [Nozioni di base su Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html) |
| Come usare Amazon VPC tramite Console di gestione AWS | [Guida per l'utente di Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/) |
| Descrizioni complete di tutti i comandi di Amazon VPC | [Amazon EC2 Command Line Reference](https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/) (i comandi Amazon VPC si trovano nel riferimento Amazon EC2 ) |
| Descrizioni complete di operazioni API, tipi di dati ed errori di Amazon VPC | [Amazon EC2 API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/) (le operazioni dell'API Amazon VPC si trovano nel riferimento Amazon EC2 ) |
| Informazioni per l'amministratore di rete che deve configurare il gateway all'estremità di una IPsec connessione VPN opzionale | [Che cos'è AWS Site-to-Site una VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) |
Per informazioni più dettagliate su Amazon Virtual Private Cloud, consulta [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/).
# Modelli di accesso per accedere a un cluster MemoryDB in un Amazon VPC
MemoryDB supporta i seguenti scenari per l'accesso a un cluster in un Amazon VPC:
**Contents**
+ [Accesso a un cluster MemoryDB quando esso e l' EC2 istanza Amazon si trovano nello stesso Amazon VPC](#memorydb-vpc-accessing-same-vpc)
+ [Accesso a un cluster MemoryDB quando esso e l' EC2 istanza Amazon si trovano in Amazon diversi VPCs](#memorydb-vpc-accessing-different-vpc)
+ [In diversi Amazon VPCs nella stessa regione](#memorydb-vpc-accessing-different-vpc-same-region)
+ [Uso del Transit Gateway](#memorydb-vpc-accessing-using-transit-gateway)
+ [In diversi Amazon VPCs in diverse regioni](#memorydb-vpc-accessing-different-vpc-different-region)
+ [Utilizzo di VPC di transito](#memorydb-vpc-accessing-different-vpc-different-region-using-transit-vpc)
+ [Accesso a un cluster MemoryDB da un'applicazione in esecuzione nel data center di un cliente](#memorydb-vpc-accessing-data-center)
+ [Utilizzo della connessione VPN](#memorydb-vpc-accessing-data-center-vpn)
+ [Uso di Direct Connect](#memorydb-vpc-accessing-data-center-direct-connect)
## Accesso a un cluster MemoryDB quando esso e l' EC2 istanza Amazon si trovano nello stesso Amazon VPC
Il caso d'uso più comune è quando un'applicazione distribuita su un' EC2 istanza deve connettersi a un cluster nello stesso VPC.
Il modo più semplice per gestire l'accesso tra EC2 istanze e cluster nello stesso VPC consiste nel fare quanto segue:
1. Creare un gruppo di sicurezza VPC per il cluster. Questo gruppo di sicurezza può essere utilizzato per limitare l'accesso ai cluster. Per questo gruppo di sicurezza è ad esempio possibile creare una regola personalizzata che consenta l'accesso TCP tramite la porta assegnata al cluster al momento della creazione e un indirizzo IP che verrà utilizzato per accedere al cluster.
La porta predefinita per i cluster MemoryDB è. `6379`
1. Crea un gruppo di sicurezza VPC per le tue EC2 istanze (server web e applicazioni). Questo gruppo di sicurezza può, se necessario, consentire l'accesso all' EC2 istanza da Internet tramite la tabella di routing del VPC. Ad esempio, è possibile impostare regole su questo gruppo di sicurezza per consentire l'accesso TCP all' EC2 istanza tramite la porta 22.
1. Crea regole personalizzate nel gruppo di sicurezza per il tuo cluster che consentano le connessioni dal gruppo di sicurezza che hai creato per le tue EC2 istanze. Ciò consente a qualsiasi membro del gruppo di sicurezza di accedere ai cluster.
**Per creare in un gruppo di sicurezza VPC una regola che consenta connessioni da un altro gruppo di sicurezza**
1. [Accedi alla console di AWS gestione e apri la console Amazon VPC su https://console.aws.amazon.com /vpc.](https://console.aws.amazon.com/vpc)
1. Nel riquadro di navigazione a sinistra, scegli **Security Groups** (Gruppi di sicurezza).
1. Seleziona o crea un gruppo di sicurezza da utilizzare per i tuoi cluster. In **Regole in entrata**, scegliere **Modifica regole in entrata** e quindi **Aggiungi regola**. Tale gruppo di sicurezza consentirà di accedere ai membri di un altro gruppo di sicurezza.
1. In **Type (Tipo)** scegliere **Custom TCP Rule (Regola TCP personalizzata)**.
1. Per **Port Range (Intervallo porte)** specificare la porta utilizzata alla creazione del cluster.
La porta predefinita per i cluster MemoryDB è. `6379`
1. Nella casella **Source (fonte)** iniziare a digitare l'ID del gruppo di sicurezza. Dall'elenco seleziona il gruppo di sicurezza che utilizzerai per le tue EC2 istanze Amazon.
1. Scegliere **Save (Salva)** al termine.
## Accesso a un cluster MemoryDB quando esso e l' EC2 istanza Amazon si trovano in Amazon diversi VPCs
Quando il cluster si trova in un VPC diverso dall' EC2 istanza utilizzata per accedervi, esistono diversi modi per accedere al cluster. Se il cluster e l' EC2 istanza si trovano in VPCs aree diverse ma nella stessa regione, puoi utilizzare il peering VPC. Se il cluster e l' EC2 istanza si trovano in regioni diverse, puoi creare connettività VPN tra le regioni.
**Topics**
+ [In diversi Amazon VPCs nella stessa regione](#memorydb-vpc-accessing-different-vpc-same-region)
+ [In diversi Amazon VPCs in diverse regioni](#memorydb-vpc-accessing-different-vpc-different-region)
### Accesso a un cluster MemoryDB quando esso e l' EC2 istanza Amazon si trovano in Amazon diverse VPCs nella stessa regione
*Cluster a cui accede un' EC2 istanza Amazon in un altro Amazon VPC all'interno della stessa regione - VPC Peering Connection*
Una connessione peering VPC è una connessione di rete tra due VPCs che consente di instradare il traffico tra di loro utilizzando indirizzi IP privati. Le istanze in uno qualsiasi dei VPC possono comunicare tra loro come se fossero nella stessa rete. Puoi creare una connessione peering VPC tra il tuo Amazon o con un Amazon VPCs VPC in un altro AWS account all'interno di una singola regione. Per ulteriori informazioni sul peering VPC di Amazon consulta la [documentazione relativa alla VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html).
**Per accedere a un cluster in una Amazon VPC differente sul peering**
1. Assicurati che i due VPCs non abbiano un intervallo IP sovrapposto o non sarai in grado di peerizzarli.
1. Guarda i due. VPCs Per ulteriori informazioni, consulta [Creare e accettare una connessione peering VPC di Amazon](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/create-vpc-peering-connection.html).
1. Aggiornare la tabella di routing. Per ulteriori informazioni, consulta [Aggiornamento delle tabelle di routing per una connessione peering VPC](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-routing.html).
1. Modifica il gruppo di sicurezza del tuo cluster MemoryDB per consentire la connessione in entrata dal gruppo di sicurezza dell'applicazione nel VPC peerizzato. Per ulteriori informazioni, vedi l'argomento relativo ai [gruppi di sicurezza nel VPC in peering](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-security-groups.html).
L'accesso a un cluster in una connessione peering implicherà ulteriori costi di trasferimento dei dati.
#### Uso del Transit Gateway
Un gateway di transito consente di collegare VPCs connessioni VPN nella stessa AWS regione e di instradare il traffico tra di esse. Un gateway di transito funziona su più AWS account ed è possibile utilizzare AWS Resource Access Manager per condividere il gateway di transito con altri account. Dopo aver condiviso un gateway di transito con un altro AWS account, il proprietario dell'account può collegarlo VPCs al gateway di transito. Un utente di uno qualsiasi degli account può eliminare il collegamento in qualsiasi momento.
È possibile abilitare il multicast in un gateway di transito, quindi creare un dominio del gateway di transito multicast che consenta l'invio del traffico multicast dall'fonte multicast ai membri del gruppo multicast tramite allegati VPC associati al dominio.
Puoi anche creare un collegamento di peering tra gateway di transito in diverse AWS regioni. In questo modo è possibile instradare il traffico tra gli allegati dei gateway di transito in diverse regioni.
Per ulteriori informazioni, consulta [Gateway di transito](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html).
### Accesso a un cluster MemoryDB quando esso e l' EC2 istanza Amazon si trovano in Amazon diverse VPCs in regioni diverse
#### Utilizzo di VPC di transito
Un'alternativa all'utilizzo del peering VPC, un'altra strategia comune per connettere più reti remote VPCs e geograficamente disperse consiste nel creare un VPC di transito che funga da centro di transito di rete globale. Un VPC di transito semplifica la gestione della rete e riduce al minimo il numero di connessioni necessarie per connettere reti multiple VPCs e remote. Questo tipo di progettazione può consentirti di risparmiare tempo, limitare il lavoro necessario e ridurre i costi, in quanto è praticamente implementato senza la spesa in genere necessaria per stabilire una presenza fisica in un hub di transito di co-location o per distribuire un'apparecchiatura di rete fisica.
*Connessione tra diverse regioni VPCs *
Una volta stabilito il VPC Amazon Transit, un'applicazione distribuita in un VPC «spoke» in una regione può connettersi a un cluster MemoryDB in un VPC «spoke» all'interno di un'altra regione.
**Per accedere a un cluster in un VPC diverso all'interno di una regione diversa AWS**
1. Distribuire una soluzione VPC di transito. Per ulteriori informazioni, consulta [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/).
1. Aggiorna le tabelle di routing VPC nell'app e VPCs instrada il traffico attraverso VGW (Virtual Private Gateway) e l'appliance VPN. Nel caso di un routing dinamico con Border Gateway Protocol (BGP) le route possono essere automaticamente propagate.
1. Modifica il gruppo di sicurezza del cluster MemoryDB per consentire la connessione in entrata dall'intervallo IP delle istanze dell'applicazione. In questo scenario, non è possibile fare riferimento al gruppo di sicurezza del server di applicazioni.
L'accesso a un cluster tra regioni introdurrà latenze di rete e ulteriori costi di trasferimento dei dati tra regioni.
## Accesso a un cluster MemoryDB da un'applicazione in esecuzione nel data center di un cliente
Un altro scenario possibile è un'architettura ibrida in cui i client o le applicazioni nel data center del cliente potrebbero dover accedere a un cluster MemoryDB nel VPC. Anche questo scenario è supportato purché sia disponibile una connessione tra VPC e data center dei clienti tramite VPN o Direct Connect.
**Topics**
+ [Utilizzo della connessione VPN](#memorydb-vpc-accessing-data-center-vpn)
+ [Uso di Direct Connect](#memorydb-vpc-accessing-data-center-direct-connect)
### Accesso a un cluster MemoryDB da un'applicazione in esecuzione nel data center di un cliente utilizzando la connettività VPN
*Connessione a MemoryDB dal data center tramite una VPN*
**Per accedere a un cluster in un VPC da un'applicazione locale su una connessione VPN**
1. Stabilire una connessione VPN aggiungendo un gateway privato virtuale hardware al proprio VPC. Per ulteriori informazioni, consulta [Aggiunta di un gateway privato virtuale hardware al proprio VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html).
1. Aggiorna la tabella di routing VPC per la sottorete in cui è distribuito il cluster MemoryDB per consentire il traffico proveniente dal server delle applicazioni locale. Nel caso di un routing dinamico con BGP le route possono essere automaticamente propagate.
1. Modifica il gruppo di sicurezza del cluster MemoryDB per consentire la connessione in entrata dai server delle applicazioni locali.
L'accesso a un cluster su una connessione VPN introdurrà latenze di rete e ulteriori costi di trasferimento dei dati.
### Accesso a un cluster MemoryDB da un'applicazione in esecuzione nel data center di un cliente tramite Direct Connect
*Connessione a MemoryDB dal data center tramite Direct Connect*
**Per accedere a un cluster MemoryDB da un'applicazione in esecuzione nella rete utilizzando Direct Connect**
1. Stabilire una connessione Direct Connect. Per ulteriori informazioni, consulta [Guida introduttiva a AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/getting_started.html).
1. Modifica il gruppo di sicurezza del cluster MemoryDB per consentire la connessione in entrata dai server delle applicazioni locali.
L'accesso a un cluster su una connessione DX può introdurre latenze di rete e ulteriori costi di trasferimento dei dati.
# Creazione di un virtual private cloud (VPC).
In questo esempio, crei un cloud privato virtuale (VPC) basato sul servizio Amazon VPC con una sottorete privata per ogni zona di disponibilità.
## Creazione di un VPC (console)
**Per creare un cluster MemoryDB all'interno di un Amazon Virtual Private Cloud**
1. Accedi alla console di AWS gestione e apri la console Amazon VPC all'indirizzo. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)
1. Nel pannello di controllo VPC, scegli **Crea VPC**.
1. Per **Resources to create** (Risorse da creare), scegli **VPC and more** (VPC e altro).
1. In **Numero di zone di disponibilità (AZs)**, scegli il numero di zone di disponibilità in cui desideri avviare le sottoreti.
1. Per **Number of public subnets** (Numero di sottoreti pubbliche), scegli il numero di sottoreti pubbliche che vuoi aggiungere al tuo VPC.
1. Per **Number of private subnets** (Numero di sottoreti private), scegli il numero di sottoreti private che vuoi aggiungere al tuo VPC.
**Suggerimento**
Prendi nota degli identificatori di sottorete, specificando quello pubblico e quello privato. Queste informazioni ti serviranno in seguito, quando lancerai i cluster e aggiungerai un' EC2 istanza Amazon al tuo Amazon VPC.
1. Creare un gruppo di sicurezza Amazon VPC Utilizzerai questo gruppo per il tuo cluster e la tua EC2 istanza Amazon.
1. Nel riquadro di navigazione a sinistra di Console di gestione AWS, scegli **Gruppi di sicurezza**.
1. Scegli **Crea gruppo di sicurezza**.
1. Inserisci un nome e una descrizione per il tuo gruppo di sicurezza nelle caselle corrispondenti. Per **VPC**, scegli l'identificatore per il tuo VPC.
1. Dopo aver selezionato tutte le impostazioni che desideri, scegliere **Yes, Create (Crea)**.
1. Definire una regola di ingresso di rete per il gruppo di sicurezza. Questa regola ti consentirà di connetterti alla tua EC2 istanza Amazon utilizzando Secure Shell (SSH).
1. Nel riquadro di navigazione a sinistra, scegli **Security Groups** (Gruppi di sicurezza).
1. Occorre trovare il gruppo di sicurezza nell'elenco, quindi selezionarlo.
1. In **Security groups (Gruppi di sicurezza)**, scegliere la scheda **Inbound (In entrata)**. Nella casella **Create a new rule (Crea una nuova regola)**, scegliere **SSH**, quindi **Add Rule (Aggiungi regola)**.
Impostare i seguenti valori per la nuova regola in entrata per consentire l'accesso HTT:.
+ Tipo: HTTP
+ Fonte: 0.0.0.0/0
1. Impostare i seguenti valori per la nuova regola in entrata per consentire l'accesso HTT:.
+ Tipo: HTTP
+ Fonte: 0.0.0.0/0
Scegliere **Apply Rule Changes (Applica modifiche della regola)**.
Ora sei pronto per creare un [gruppo di sottoreti](https://docs.aws.amazon.com/memorydb/latest/devguide/subnetgroups.html) e [creare un cluster](https://docs.aws.amazon.com/memorydb/latest/devguide/getting-started.createcluster.html) nel tuo VPC.
# Sottoreti e gruppi di sottoreti
Un *gruppo di sottoreti* è una raccolta di sottoreti (generalmente private) che è possibile designare per i cluster in esecuzione in un ambiente Amazon Virtual Private Cloud (VPC)
Quando crei un cluster in un Amazon VPC, puoi specificare un gruppo di sottoreti o utilizzare quello predefinito fornito. MemoryDB utilizza quel gruppo di sottoreti per scegliere una sottorete e gli indirizzi IP all'interno di quella sottorete da associare ai nodi.
Questa sezione spiega come creare e sfruttare sottoreti e gruppi di sottoreti per gestire l'accesso alle risorse di MemoryDB.
Per ulteriori informazioni sull'utilizzo dei gruppi di sottoreti in un ambiente Amazon VPC, consulta [Fase 3: autorizzazione dell'accesso al cluster](getting-started.md#getting-started.authorizeaccess).
**MemoryDB AZ supportato IDs**
| Nome regione/Regione | AZ supportato IDs |
| --- | --- |
| Stati Uniti orientali (Ohio) `us-east-2` | `use2-az1, use2-az2, use2-az3` |
| Stati Uniti orientali (Virginia settentrionale) `us-east-1` | `use1-az1, use1-az2, use1-az4, use1-az5, use1-az6` |
| Regione Stati Uniti occidentali (California settentrionale) `us-west-1` | `usw1-az1, usw1-az2, usw1-az3` |
| Stati Uniti occidentali (Oregon) `us-west-2` | `usw2-az1, usw2-az2, usw2-az3, usw2-az4` |
| Regione Canada (Centrale) `ca-central-1` | `cac1-az1, cac1-az2, cac1-az4` |
| Regione Asia Pacifico (Hong Kong) `ap-east-1` | `ape1-az1, ape1-az2, ape1-az3` |
| Regione Asia Pacifico (Mumbai) `ap-south-1` | `aps1-az1, aps1-az2, aps1-az3` |
| Regione Asia Pacifico (Tokyo) `ap-northeast-1` | `apne1-az1, apne1-az2, apne1-az4` |
| Asia Pacific (Seoul) Region `ap-northeast-2` | `apne2-az1, apne2-az2, apne2-az3` |
| Regione Asia Pacifico (Singapore) `ap-southeast-1` | `apse1-az1, apse1-az2, apse1-az3` |
| Regione Asia Pacifico (Sydney) `ap-southeast-2` | apse2-az1, apse2-az2, apse2-az3 |
| Regione Europa (Francoforte) `eu-central-1` | `euc1-az1, euc1-az2, euc1-az3` |
| Regione Europa (Irlanda) `eu-west-1` | `euw1-az1, euw1-az2, euw1-az3` |
| Regione Europa (Londra) `eu-west-2` | `euw2-az1, euw2-az2, euw2-az3` |
| Regione UE (Parigi) `eu-west-3` | `euw3-az1, euw3-az2, euw3-az3` |
| Regione Europa (Stoccolma) `eu-north-1` | `eun1-az1, eun1-az2, eun1-az3 ` |
| Regione Europa (Milano) `eu-south-1` | `eus1-az1, eus1-az2, eus1-az3 ` |
| Regione Sud America (San Paolo) `sa-east-1` | `sae1-az1, sae1-az2, sae1-az3` |
| Regione Cina (Pechino) `cn-north-1` | `cnn1-az1, cnn1-az2` |
| Regione Cina (Ningxia) `cn-northwest-1` | `cnw1-az1, cnw1-az2, cnw1-az3` |
| `us-gov-east-1` | `usge1-az1, usge1-az2, usge1-az3` |
| `us-gov-west-1` | `usgw1-az1, usgw1-az2, usgw1-az3` |
| Regione Europa (Spagna) `eu-south-2` | `eus2-az1, eus2-az2, eus2-az3` |
**Topics**
+ [MemoryDB e IPV6](subnetgroups.ipv6.md)
+ [Creazione di un gruppo di sottoreti](subnetgroups.creating.md)
+ [Aggiornamento di un gruppo di sottoreti](subnetgroups.modifying.md)
+ [Visualizzazione dei dettagli del gruppo di sottoreti](subnetgroups.Viewing.md)
+ [Eliminazione di un gruppo di sottoreti](subnetgroups.deleting.md)
# MemoryDB e IPV6
È possibile creare nuovi cluster dual stack e solo ipv6 con i motori Valkey e Redis OSS, fornendo ai gruppi di sottoreti con sottoreti dual stack e solo ipv6. Non è possibile modificare il tipo di rete per un cluster esistente.
Con questa funzionalità è possibile:
+ Creare cluster dual stack e solo ipv4 su sottoreti dual stack.
+ Crea cluster solo ipv6 su sottoreti solo ipv6.
+ Crea nuovi gruppi di sottoreti per supportare sottoreti solo ipv4, dual stack e solo ipv6.
+ Modifica i gruppi di sottoreti esistenti per includere sottoreti aggiuntive dal VPC sottostante.
+ Modifica le sottoreti esistenti nei gruppi di sottoreti
+ Aggiungi IPv6 solo sottoreti ai gruppi di sottoreti configurati per IPv6
+ Aggiungi IPv4 o supporta sottoreti dual stack ai gruppi di sottoreti configurati per IPv4
+ Scopri tutti i nodi del cluster con indirizzi ipv4 O ipv6, tramite i comandi di Engine Discovery per cluster dual stack e ipv6. Questi comandi di rilevamento includono e simili. `redis_info` `redis_cluster`
+ Scopri gli indirizzi ipv4 e ipv6 di tutti i nodi del cluster, tramite i comandi di rilevamento DNS per cluster dual stack e ipv6.
# Creazione di un gruppo di sottoreti
Quando si crea un nuovo gruppo di sottoreti, tieni presente il numero di indirizzi IP disponibili. Se la sottorete ha un numero molto ridotto di indirizzi IP gratuiti, potresti avere delle limitazioni sul numero di nodi aggiuntivi da aggiungere al cluster. Per risolvere questo problema, è possibile assegnare una o più sottoreti a un gruppo di sottoreti in modo da avere un numero sufficiente di indirizzi IP nella zona di disponibilità del cluster. Dopodiché, è possibile aggiungere ulteriori nodi al cluster.
Le seguenti procedure mostrano come creare un gruppo di sottoreti chiamato `mysubnetgroup` (console), e l'API MemoryDB. AWS CLI
## Creazione di un gruppo di sottoreti (Console)
La procedura seguente mostra come creare un gruppo di sottoreti (console).
**Per creare un gruppo di sottoreti (Console)**
1. Accedere alla console di AWS gestione e aprire la console di MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Nel riquadro di navigazione a sinistra, scegli **Subnet** Groups.
1. Scegliere **Create Subnet Group (Crea gruppo di sottoreti)**.
1. Nella pagina **Crea gruppo di sottoreti**, procedi come segue:
1. Nella casella **Name (Nome)**, digitare un nome per il gruppo di sottoreti.
I vincoli di denominazione dei cluster sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
1. Nella casella **Description (Descrizione)**, digitare una descrizione per il gruppo di sottoreti.
1. Nella casella **VPC ID (ID VPC)**, scegleire l’Amazon VPC creato. Se non ne hai ancora creato uno, scegli il pulsante **Crea VPC** e segui i passaggi per crearne uno.
1. **In **Sottoreti selezionate**, scegli la zona di disponibilità e l'ID della tua sottorete privata, quindi scegli.**
1. Per i **tag**, puoi facoltativamente applicare tag per cercare e filtrare le sottoreti o tenere traccia dei costi. AWS
1. Dopo aver selezionato tutte le impostazioni desiderate, scegli **Crea**.
1. Nel messaggio di conferma visualizzato, scegliere **Close (Chiudi)**.
Il nuovo gruppo di sottoreti viene visualizzato nell'elenco dei **gruppi di sottoreti della console** MemoryDB. Nella parte in basso della finestra puoi scegliere il gruppo di sottoreti per visualizzare i dettagli, ad esempio tutte le sottoreti associate a tale gruppo.
## Creazione di un gruppo di sottoreti (AWS CLI)
Al prompt dei comandi, utilizzare il comando `create-subnet-group` per creare un gruppo di sottoreti.
Per Linux, macOS o Unix:
```
aws memorydb create-subnet-group \
--subnet-group-name mysubnetgroup \
--description "Testing" \
--subnet-ids subnet-53df9c3a
```
Per Windows:
```
aws memorydb create-subnet-group ^
--subnet-group-name mysubnetgroup ^
--description "Testing" ^
--subnet-ids subnet-53df9c3a
```
Questo comando dovrebbe generare un output simile al seguente:
```
{
"SubnetGroup": {
"Subnets": [
{
"Identifier": "subnet-53df9c3a",
"AvailabilityZone": {
"Name": "us-east-1a"
}
}
],
"VpcId": "vpc-3cfaef47",
"Name": "mysubnetgroup",
"ARN": "arn:aws:memorydb:us-east-1:012345678912:subnetgroup/mysubnetgroup",
"Description": "Testing"
}
}
```
Per ulteriori informazioni, consultate l' AWS CLI argomento. [create-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-subnet-group.html)
## Creazione di un gruppo di sottoreti (API MemoryDB)
Utilizzando l'API MemoryDB, chiamate `CreateSubnetGroup` con i seguenti parametri:
+ `SubnetGroupName=``mysubnetgroup`
+ `Description=``Testing`
+ `SubnetIds.member.1=``subnet-53df9c3a`
# Aggiornamento di un gruppo di sottoreti
È possibile aggiornare la descrizione di un gruppo di sottoreti o modificare l'elenco delle sottoreti IDs associate al gruppo di sottoreti. Non è possibile eliminare un ID di sottorete da un gruppo se un cluster utilizza attualmente quella sottorete.
Le procedure seguenti mostrano come aggiornare un gruppo di sottoreti.
## Aggiornamento dei gruppi di sottoreti (Console)
**Per aggiornare un gruppo di sottoreti**
1. Accedere Console di gestione AWS e aprire la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Nel riquadro di navigazione a sinistra, scegli **Subnet** Groups.
1. Nell'elenco dei gruppi di sottoreti, scegliere quello che si desidera modificare.
1. I campi **Nome **VPCId****e **Descrizione** non sono modificabili.
1. Nella sezione **Sottoreti selezionate**, fate clic su **Gestisci per apportare le** modifiche necessarie alle zone di disponibilità per le sottoreti. Per salvare le modifiche, scegliere **Save (Salva)**.
## Aggiornamento dei gruppi di sottoreti (AWS CLI)
Al prompt dei comandi, utilizzate il comando `update-subnet-group` per aggiornare un gruppo di sottoreti.
Per Linux, macOS o Unix:
```
aws memorydb update-subnet-group \
--subnet-group-name mysubnetgroup \
--description "New description" \
--subnet-ids "subnet-42df9c3a" "subnet-48fc21a9"
```
Per Windows:
```
aws memorydb update-subnet-group ^
--subnet-group-name mysubnetgroup ^
--description "New description" ^
--subnet-ids "subnet-42df9c3a" "subnet-48fc21a9"
```
Questo comando dovrebbe generare un output simile al seguente:
```
{
"SubnetGroup": {
"VpcId": "vpc-73cd3c17",
"Description": "New description",
"Subnets": [
{
"Identifier": "subnet-42dcf93a",
"AvailabilityZone": {
"Name": "us-east-1a"
}
},
{
"Identifier": "subnet-48fc12a9",
"AvailabilityZone": {
"Name": "us-east-1a"
}
}
],
"Name": "mysubnetgroup",
"ARN": "arn:aws:memorydb:us-east-1:012345678912:subnetgroup/mysubnetgroup",
}
}
```
Per ulteriori informazioni, consultate l' AWS CLI argomento. [update-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html)
## Aggiornamento dei gruppi di sottoreti (API MemoryDB)
Utilizzando l'API MemoryDB, chiamate `UpdateSubnetGroup` con i seguenti parametri:
+ `SubnetGroupName=``mysubnetgroup`
+ Qualsiasi altro parametro di cui si desidera modificare i valori. Questo esempio utilizza `Description=``New%20description` per modificare la descrizione del gruppo di sottoreti.
**Example**
```
https://memory-db.us-east-1.amazonaws.com/
?Action=UpdateSubnetGroup
&Description=New%20description
&SubnetGroupName=mysubnetgroup
&SubnetIds.member.1=subnet-42df9c3a
&SubnetIds.member.2=subnet-48fc21a9
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=Amazon4-HMAC-SHA256
&X-Amz-Credential=
&X-Amz-Date=20141201T220302Z
&X-Amz-Expires=20141201T220302Z
&X-Amz-Signature=
&X-Amz-SignedHeaders=Host
```
**Nota**
Quando si crea un gruppo di sottoreti, prendere nota del numero di indirizzi IP disponibili. Se la sottorete ha un numero molto ridotto di indirizzi IP gratuiti, potresti avere delle limitazioni sul numero di nodi aggiuntivi da aggiungere al cluster. Per risolvere questo problema, è possibile assegnare una o più sottoreti a un gruppo di sottoreti in modo da avere un numero sufficiente di indirizzi IP nella zona di disponibilità del cluster. Dopodiché, è possibile aggiungere ulteriori nodi al cluster.
# Visualizzazione dei dettagli del gruppo di sottoreti
Le procedure seguenti mostrano come visualizzare i dettagli di un gruppo di sottoreti.
## Visualizzazione dei dettagli dei gruppi di sottoreti (console)
**Per visualizzare i dettagli di un gruppo di sottoreti (Console)**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Nel riquadro di navigazione a sinistra, scegli **Subnet** Groups.
1. Nella pagina **Gruppi di sottoreti**, scegli il gruppo di sottoreti in **Nome o inserisci il nome** del gruppo di sottoreti nella barra di ricerca.
1. Nella pagina **Gruppi di sottoreti**, scegli il gruppo di sottoreti in **Nome o inserisci il nome** del gruppo di sottoreti nella barra di ricerca.
1. **Nelle impostazioni del gruppo di sottorete** puoi visualizzare il nome, la descrizione, l'ID VPC e l'Amazon Resource Name (ARN) del gruppo di sottoreti.
1. In **Subnet puoi visualizzare le zone di disponibilità, la sottorete** e i blocchi CIDR del gruppo di IDs sottoreti
1. In **Tag** è possibile visualizzare tutti i tag associati al gruppo di sottoreti.
## Visualizzazione dei dettagli dei gruppi di sottoreti (AWS CLI)
Al prompt dei comandi, utilizzate il comando `describe-subnet-groups` per visualizzare i dettagli di un gruppo di sottoreti specificato.
Per Linux, macOS o Unix:
```
aws memorydb describe-subnet-groups \
--subnet-group-name mysubnetgroup
```
Per Windows:
```
aws memorydb describe-subnet-groups ^
--subnet-group-name mysubnetgroup
```
Questo comando dovrebbe generare un output simile al seguente:
```
{
"subnetgroups": [
{
"Subnets": [
{
"Identifier": "subnet-060cae3464095de6e",
"AvailabilityZone": {
"Name": "us-east-1a"
}
},
{
"Identifier": "subnet-049d11d4aa78700c3",
"AvailabilityZone": {
"Name": "us-east-1c"
}
},
{
"Identifier": "subnet-0389d4c4157c1edb4",
"AvailabilityZone": {
"Name": "us-east-1d"
}
}
],
"VpcId": "vpc-036a8150d4300bcf2",
"Name": "mysubnetgroup",
"ARN": "arn:aws:memorydb:us-east-1:53791xzzz7620:subnetgroup/mysubnetgroup",
"Description": "test"
}
]
}
```
Per visualizzare i dettagli su tutti i gruppi di sottoreti, utilizzate lo stesso comando ma senza specificare il nome del gruppo di sottorete.
```
aws memorydb describe-subnet-groups
```
Per ulteriori informazioni, consultate l'argomento. AWS CLI [describe-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html)
## Visualizzazione dei gruppi di sottoreti (API MemoryDB)
Utilizzando l'API MemoryDB, chiamate `DescribeSubnetGroups` con i seguenti parametri:
`SubnetGroupName=``mysubnetgroup`
**Example**
```
https://memory-db.us-east-1.amazonaws.com/
?Action=UpdateSubnetGroup
&Description=New%20description
&SubnetGroupName=mysubnetgroup
&SubnetIds.member.1=subnet-42df9c3a
&SubnetIds.member.2=subnet-48fc21a9
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Timestamp=20211801T220302Z
&Version=2021-01-01
&X-Amz-Algorithm=Amazon4-HMAC-SHA256
&X-Amz-Credential=
&X-Amz-Date=20210801T220302Z
&X-Amz-Expires=20210801T220302Z
&X-Amz-Signature=
&X-Amz-SignedHeaders=Host
```
# Eliminazione di un gruppo di sottoreti
Se ritieni che il gruppo di sottoreti non sia più necessario, puoi eliminarlo. Non è possibile eliminare un gruppo di sottoreti se è attualmente utilizzato da un cluster. Non è inoltre possibile eliminare un gruppo di sottoreti in un cluster con la funzione Multi-AZ abilitato se tale cluster non contiene più di due sottoreti. È necessario prima deselezionare **Multi-AZ** e quindi eliminare la sottorete.
Le procedure seguenti mostrano come eliminare un gruppo di sottoreti.
## Eliminazione di un gruppo di sottoreti (Console)
**Per eliminare un gruppo di sottoreti**
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Nel riquadro di navigazione a sinistra, scegli **Subnet** Groups.
1. **Nell'elenco dei gruppi di sottoreti, scegli quello che desideri eliminare, scegli **Azioni** e quindi scegli Elimina.**
**Nota**
Non è possibile eliminare un gruppo di sottoreti predefinito o associato a qualsiasi cluster.
1. Verrà visualizzata la schermata di conferma dell'**eliminazione dei gruppi di sottorete**.
1. Per eliminare il gruppo di sottoreti, inseriscilo `delete` nella casella di testo di conferma. Per mantenere il gruppo di sottoreti, scegliere **Cancel (Annulla)**.
## Eliminazione di un gruppo di sottoreti (CLI AWS )
Utilizzando AWS CLI, chiamate il comando **delete-subnet-group** con il seguente parametro:
+ `--subnet-group-name` *mysubnetgroup*
Per Linux, macOS o Unix:
```
aws memorydb delete-subnet-group \
--subnet-group-name mysubnetgroup
```
Per Windows:
```
aws memorydb delete-subnet-group ^
--subnet-group-name mysubnetgroup
```
Per ulteriori informazioni, consulta l' AWS CLI argomento [delete-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-subnet-group.html).
## Eliminazione di un gruppo di sottoreti (API MemoryDB)
Utilizzando l'API MemoryDB, chiamate con il seguente parametro: `DeleteSubnetGroup`
+ `SubnetGroupName=mysubnetgroup`
**Example**
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DeleteSubnetGroup
&SubnetGroupName=mysubnetgroup
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Timestamp=20210801T220302Z
&Version=2021-01-01
&X-Amz-Algorithm=Amazon4-HMAC-SHA256
&X-Amz-Credential=
&X-Amz-Date=20210801T220302Z
&X-Amz-Expires=20210801T220302Z
&X-Amz-Signature=
&X-Amz-SignedHeaders=Host
```
Questo comando non produce alcun output.
Per ulteriori informazioni, consultate l'argomento API MemoryDB. [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html)
# API MemoryDB e endpoint VPC di interfaccia ()AWS PrivateLink
*Puoi stabilire una connessione privata tra il tuo VPC e gli endpoint dell'API Amazon MemoryDB creando un endpoint VPC di interfaccia.* Gli endpoint dell'interfaccia sono alimentati da. [AWS PrivateLink](https://aws.amazon.com/privatelink) AWS PrivateLink consente di accedere in modo privato alle operazioni dell'API MemoryDB senza un gateway Internet, un dispositivo NAT, una connessione VPN o una connessione Direct Connect AWS .
Le istanze nel tuo VPC non necessitano di indirizzi IP pubblici per comunicare con gli endpoint dell'API MemoryDB. Le tue istanze, inoltre, non necessitano di indirizzi IP pubblici per utilizzare nessuna delle operazioni API MemoryDB disponibili. Il traffico tra il tuo VPC e MemoryDB non esce dalla rete Amazon. Ogni endpoint dell'interfaccia è rappresentato da una o più interfacce di rete elastiche nelle sottoreti. Per maggiori informazioni sulle interfacce di rete elastiche, consulta le [interfacce di rete elastiche](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) nella *Guida dell'utente di Amazon EC2.*
+ *Per ulteriori informazioni sugli endpoint VPC, consulta Interface [VPC endpoints () nella Amazon VPC User AWS PrivateLink Guide](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html).*
+ [Per ulteriori informazioni sulle operazioni dell'API MemoryDB, consulta Operazioni dell'API MemoryDB.](https://docs.aws.amazon.com/memorydb/latest/APIReference/Welcome.html)
Dopo aver creato un endpoint VPC di interfaccia, se abiliti i nomi host [DNS privati](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-private-dns) per l'endpoint, l'endpoint MemoryDB predefinito (https://memorydb. *Region*.amazonaws.com) si risolve nel tuo endpoint VPC. Se non abiliti nomi host DNS privati, Amazon VPC fornisce un nome di endpoint DNS che puoi utilizzare nel formato seguente:
```
VPC_Endpoint_ID.memorydb.Region.vpce.amazonaws.com
```
Per ulteriori informazioni, consulta [Endpoint VPC di interfaccia (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) nella *Guida per l'utente di Amazon VPC*. MemoryDB supporta l'esecuzione di chiamate a tutte le sue [azioni API](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html) all'interno del tuo VPC.
**Nota**
I nomi host DNS privati possono essere abilitati per un solo endpoint VPC nel VPC. Per creare un endpoint VPC supplementare, il nome host DNS privato deve essere disabilitato.
## Considerazioni sugli endpoint VPC dell'
*Prima di configurare un endpoint VPC di interfaccia per gli endpoint dell'API MemoryDB, assicurati di esaminare le [proprietà e le limitazioni degli endpoint dell'interfaccia nella](https://docs.aws.amazon.com/vpc/latest/privatelink/endpoint-services-overview.html) Amazon VPC User Guide.* Tutte le operazioni dell'API MemoryDB rilevanti per la gestione delle risorse di MemoryDB sono disponibili tramite il VPC utilizzando. AWS PrivateLink Le policy degli endpoint VPC sono supportate per gli endpoint dell'API MemoryDB. Per impostazione predefinita, l'accesso completo alle operazioni dell'API MemoryDB è consentito tramite l'endpoint. Per ulteriori informazioni, consulta [Controllo degli accessi ai servizi con endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) nella *Guida per l’utente di Amazon VPC.*
### Creazione di un endpoint VPC di interfaccia per l'API MemoryDB
Puoi creare un endpoint VPC per l'API MemoryDB utilizzando la console Amazon VPC o il. AWS CLI Per ulteriori informazioni, consultare [Creazione di un endpoint di interfaccia](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) nella *Guida per l’utente di Amazon VPC*.
Una volta creato un endpoint VPC di interfaccia, è possibile abilitare nomi host DNS privati per l'endpoint. Quando lo fai, l'endpoint MemoryDB predefinito (https://memorydb. *Region*.amazonaws.com) si risolve nel tuo endpoint VPC. Per ulteriori informazioni, consultare [Accesso a un servizio tramite un endpoint di interfaccia](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) in *Guida per l'utente di Amazon VPC*.
### Creazione di una policy di endpoint VPC per l'API Amazon MemoryDB
Puoi allegare una policy endpoint al tuo endpoint VPC che controlla l'accesso all'API MemoryDB. La policy specifica quanto segue:
+ Il principale che può eseguire azioni.
+ Le azioni che possono essere eseguite.
+ Le risorse sui cui si possono eseguire operazioni.
Per ulteriori informazioni, consulta [Controllo degli accessi ai servizi con endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) in *Guida per l'utente di Amazon VPC*.
**Example Policy degli endpoint VPC per le azioni dell'API MemoryDB**
Di seguito è riportato un esempio di policy sugli endpoint per l'API MemoryDB. Se collegata a un endpoint, questa policy consente l'accesso alle azioni API MemoryDB elencate per tutti i principali su tutte le risorse.
```
{
"Statement": [{
"Principal": "*",
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster",
"memorydb:UpdateCluster",
"memorydb:CreateSnapshot"
],
"Resource": "*"
}]
}
```
**Example Policy degli endpoint VPC che nega tutti gli accessi da un account specifico AWS**
La seguente politica degli endpoint VPC nega all' AWS account *123456789012* tutti gli accessi alle risorse che utilizzano l'endpoint. La policy consente tutte le operazioni da altri account.
```
{
"Statement": [{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```
# Vulnerabilità ed esposizioni comuni (CVE): vulnerabilità di sicurezza risolte in MemoryDB
CVE (Common Vulnerabilities and Exposures - Vulnerabilità e rischi comuni) è un elenco di voci per vulnerabilità di sicurezza informatica pubblicamente note. Ogni voce è un link che contiene un numero di identificazione, una descrizione e almeno un riferimento pubblico. È possibile trovare in questa pagina un elenco di vulnerabilità di sicurezza che sono state risolte in MemoryDB.
Ti consigliamo di eseguire sempre l'aggiornamento alle versioni più recenti di MemoryDB per proteggerti dalle vulnerabilità note. MemoryDB espone il componente PATCH. Le versioni PATCH riguardano correzioni di bug, correzioni di sicurezza e modifiche non funzionali compatibili con le versioni precedenti.
È possibile utilizzare la tabella seguente per verificare se una particolare versione di MemoryDB include una correzione per una specifica vulnerabilità di sicurezza. Se la cache di MemoryDB è in attesa di aggiornamento del servizio, potrebbe essere vulnerabile a una delle vulnerabilità di sicurezza elencate di seguito. Ti consigliamo di applicare l'aggiornamento del servizio. Per ulteriori informazioni sulle versioni supportate del motore MemoryDB e su come eseguire l'aggiornamento, consulta. [Versioni del motore](engine-versions.md)
**Nota**
Se un CVE è indirizzato in una versione di MemoryDB, significa che è indirizzato anche nelle versioni più recenti.
Un asterisco (\$1) nella tabella seguente indica che è necessario applicare l'ultimo aggiornamento del servizio per il cluster MemoryDB che esegue la versione specificata per risolvere la vulnerabilità di sicurezza. Per ulteriori informazioni su come verificare che sia stato applicato l'ultimo aggiornamento del servizio per la versione di MemoryDB su cui è in esecuzione il cluster, consulta. [Gestire gli aggiornamenti del servizio](managing-updates.md)
| Versione MemoryDB | CVEs Indirizzato |
| --- | --- |
| Valkey 7.3 e tutte le versioni precedenti di Valkey Redis OSS 7.1 e tutte le versioni precedenti di Redis OSS | [https://www.cve.org/CVERecord?id=CVE-2025-49844](https://www.cve.org/CVERecord?id=CVE-2025-49844) |
| Valkey 7.2 e 7.3 | [CVE-2025-21607\$1, CVE-2025-21605\$1, CVE-2024-31449\$1, CVE-2024-31227\$1](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21607) [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449) |
| Valle 7.2.7 | [CVE-2024-51741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-51741) |
| Redis OSS 7.1 e 6.2 | [CVE-2025-21605\$1, CVE-2024-31449 \$1, CVE-2024-31227\$1, CVE-2024-31228\$1](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21605) [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449) |
| Redis OSS 7.0.7 | [CVE-2023-41056 \$1](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41056) |
| Sistema operativo Redis 6.2.7 | [CVE-2024-46981](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-46981) |
| Sistema operativo Redis 6.2.6 | [CVE-2022-24834 \$1, CVE-2022-35977 \$1, CVE-2022-36021](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24834) [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36021](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36021) [CVE-2023-45145:](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45145) Si noti che questo CVE è stato risolto in Redis OSS 6.2 e 7.0 ma non in Redis OSS 7.1. |
| Redis OSS 6.0.5 | [CVE-2022-24735 \$1, [CVE-2022-24736 \$1](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24735)](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24736) |
# Aggiornamenti del servizio in MemoryDB
MemoryDB monitora automaticamente la tua flotta di cluster e nodi per applicare gli aggiornamenti del servizio non appena diventano disponibili. In genere, si imposta una finestra di manutenzione predefinita in modo che MemoryDB possa applicare questi aggiornamenti. Tuttavia, in alcuni casi potreste trovare questo approccio troppo rigido e suscettibile di limitare i flussi aziendali.
Con[Aggiornamenti del servizio in MemoryDB](#service-updates), puoi controllare quando e quali aggiornamenti vengono applicati. Puoi anche monitorare lo stato di avanzamento di questi aggiornamenti nel cluster MemoryDB selezionato in tempo reale.
# Gestire gli aggiornamenti del servizio
Gli aggiornamenti del servizio MemoryDB vengono rilasciati regolarmente. Se disponi di uno o più cluster idonei per tali aggiornamenti del servizio, ricevi notifiche tramite e-mail, SNS, Personal Health Dashboard (PHD) ed CloudWatch eventi Amazon quando gli aggiornamenti vengono rilasciati. Gli aggiornamenti vengono visualizzati anche nella pagina **Service Updates della console** MemoryDB. Utilizzando questa dashboard, è possibile visualizzare tutti gli aggiornamenti del servizio e il relativo stato per la flotta di MemoryDB.
Si controlla quando applicare un aggiornamento prima dell’avvio dell'aggiornamento automatico. Ti consigliamo vivamente di applicare qualsiasi aggiornamento di tipo **security-update** il prima possibile per garantire che MemoryDB disponga sempre delle patch di sicurezza correnti. up-to-date
Le seguenti sezioni esplorano queste opzioni in dettaglio:
**Topics**
+ [Panoramica della manutenzione gestita di Amazon MemoryDB e degli aggiornamenti dei servizi](#managing-updates-maintenance)
## Panoramica della manutenzione gestita di Amazon MemoryDB e degli aggiornamenti dei servizi
Aggiorniamo spesso la nostra flotta di MemoryDB, con patch e aggiornamenti applicati alle istanze senza problemi. Lo facciamo in due modi:
1. Manutenzione gestita continua.
1. Aggiornamenti del servizio.
Questi aggiornamenti di manutenzione e assistenza sono necessari per applicare aggiornamenti che rafforzano la sicurezza, l'affidabilità e le prestazioni operative.
La manutenzione gestita continua viene eseguita di tanto in tanto e direttamente nelle finestre di manutenzione senza richiedere alcuna azione da parte dell'utente. È importante notare che gli intervalli di manutenzione sono obbligatori per tutti i clienti e non è possibile disattivarli. Consigliamo vivamente di evitare qualsiasi attività critica o importante durante queste finestre di manutenzione stabilite. Inoltre, tieni presente che gli aggiornamenti critici non possono essere ignorati per garantire la sicurezza e le prestazioni ottimali del sistema.
Gli aggiornamenti del servizio offrono la flessibilità necessaria per applicarli autonomamente. Sono temporizzati e possono essere spostati nella finestra di manutenzione per essere applicati da noi dopo la scadenza della data di scadenza.
Puoi gestire gli aggiornamenti applicandoli non appena possibile o sostituendo i nodi, poiché gli aggiornamenti vengono applicati automaticamente al momento della sostituzione. Non vi sarà alcuna attività di aggiornamento durante le finestre di manutenzione in entrata se gli aggiornamenti sono stati applicati a tutti i nodi precedenti.
### Aggiornamenti di servizio
[Aggiornamenti del servizio in MemoryDB](service-updates.md)consentirti di applicare determinati aggiornamenti del servizio a tua discrezione. Questi aggiornamenti possono essere dei seguenti tipi: patch di sicurezza o aggiornamenti software minori. Questi aggiornamenti aiutano a rafforzare la sicurezza, l'affidabilità e le prestazioni operative dei cluster.
Il valore di questi aggiornamenti del servizio è che è possibile controllare quando applicare l'aggiornamento (ad esempio, è possibile ritardare l'applicazione degli aggiornamenti del servizio quando si verifica un evento aziendale importante che richiede la disponibilità 24 ore su 24, 7 giorni su 7 dei cluster di MemoryDB).
[Se disponi di uno o più cluster idonei per tali aggiornamenti del servizio, ricevi notifiche tramite e-mail, [Amazon SNS](mdbevents.sns.md), Dashboard ed eventi [ CloudWatch Amazon](monitoring-cloudwatch.md) Events quando gli aggiornamenti vengono rilasciati.AWS Health](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) Gli aggiornamenti vengono visualizzati anche nella pagina **Service Updates** sulla console MemoryDB. Utilizzando questa dashboard, è possibile visualizzare tutti gli aggiornamenti del servizio e il relativo stato per la flotta di MemoryDB.
Si controlla quando applicare un aggiornamento prima dell’avvio dell'aggiornamento automatico. Ti consigliamo vivamente di applicare qualsiasi aggiornamento di tipo security-update il prima possibile per garantire che MemoryDB disponga sempre delle patch di sicurezza correnti. up-to-date
Il tuo cluster potrebbe far parte di diversi aggiornamenti del servizio. La maggior parte degli aggiornamenti non richiede l'applicazione separata. L'applicazione di un aggiornamento al cluster contrassegnerà gli altri aggiornamenti come completati, laddove applicabile. Potrebbe essere necessario applicare più aggiornamenti allo stesso cluster separatamente se lo stato non cambia automaticamente in «completato».
#### Impatto degli aggiornamenti del servizio e tempi di inattività
Quando tu o Amazon MemoryDB applicate un aggiornamento del servizio a uno o più cluster MemoryDB, l'aggiornamento viene applicato a non più di un nodo alla volta all'interno di ogni shard fino a quando tutti i cluster selezionati non vengono aggiornati. I nodi in fase di aggiornamento subiranno un periodo di inattività di pochi secondi, mentre il resto del cluster continuerà a servire il traffico.
+ Non ci saranno modifiche nella configurazione del cluster.
+ Noterai un ritardo nelle tue CloudWatch metriche che verranno recuperate il prima possibile.
**In che modo la sostituzione di un nodo influisce sulla mia applicazione?** - Per i nodi MemoryDB, il processo di sostituzione è progettato per garantire durata e disponibilità. Per i cluster MemoryDB a nodo singolo, MemoryDB avvia dinamicamente una replica, ripristina i dati dai nostri componenti di durabilità e quindi esegue il failover su di essa. Per i gruppi di replica composti da più nodi, MemoryDB sostituisce le repliche esistenti e sincronizza i dati dai nostri componenti di durabilità con le nuove repliche. MemoryDB è Multi-AZ solo quando è presente più di un nodo, quindi in questo scenario, la sostituzione del primario innesca un failover su una replica di lettura. Le sostituzioni dei nodi pianificate vengono completate mentre il cluster soddisfa le richieste di scrittura in entrata. Se è presente un solo nodo, MemoryDB sostituisce il principale e quindi sincronizza i dati dai nostri componenti di durabilità. Il nodo primario non è disponibile durante questo periodo, con conseguenti interruzioni di scrittura più lunghe.
**Quali best practice devo seguire per un'esperienza di sostituzione fluida e ridurre al minimo la perdita di dati?** - In MemoryDB, i dati sono estremamente durevoli e la perdita di dati non è prevista nemmeno nelle implementazioni a nodo singolo. Si consiglia tuttavia di implementare strategie Multi-AZ e di backup per ridurre al minimo le possibilità di perdita nell'improbabile caso di guasto. Per un'esperienza di sostituzione senza problemi, cerchiamo di sostituire solo un numero sufficiente di nodi dello stesso cluster alla volta per mantenere stabile il cluster. È possibile effettuare il provisioning di repliche primarie e di lettura in diverse zone di disponibilità abilitando Multi-AZ. In questo caso, quando un nodo viene sostituito, il ruolo principale eseguirà il failover su una replica nello shard. Questo shard ora servirà il traffico e i dati verranno ripristinati dai componenti di durabilità. Se la configurazione include solo una replica primaria e una singola per shard, si consiglia di aggiungere altre repliche prima dell'applicazione delle patch. Ciò impedirà una riduzione della disponibilità durante il processo di patching. Consigliamo di programmare la sostituzione durante un periodo in cui il traffico di scrittura in entrata è basso.
**Quali best practice di configurazione del client devo seguire per ridurre al minimo le interruzioni delle applicazioni durante la manutenzione?** - In MemoryDB, la configurazione in modalità cluster è sempre abilitata, il che offre la migliore disponibilità durante le operazioni gestite o non gestite. Gli endpoint dei singoli nodi dei nodi di replica possono essere utilizzati per tutte le operazioni di lettura. In MemoryDB, il failover automatico è sempre abilitato nel cluster, il che significa che il nodo primario può cambiare. Pertanto, l'applicazione deve confermare il ruolo del nodo e aggiornare tutti gli endpoint di lettura per assicurarsi di non causare un carico importante sul nodo primario. Allo stesso modo, evitate di sovraccaricare le repliche con richieste di lettura durante le finestre di manutenzione. Un modo per raggiungere questo obiettivo è assicurarsi di disporre di almeno due repliche di lettura per evitare interruzioni di lettura durante la manutenzione.
È importante testare le applicazioni client per confermare che siano conformi al protocollo Redis/Valkey Cluster e che le richieste possano essere reindirizzate correttamente tra i nodi. È consigliabile implementare strategie di back-off e retry per evitare di sovraccaricare i nodi MemoryDB durante le attività di manutenzione e sostituzione.
**Riprogrammazione: è possibile posticipare l'aggiornamento del servizio modificando la** [finestra di manutenzione.](maintenance-window.md) L'aggiornamento pianificato verrà applicato al cluster solo se la data pianificata corrisponde alla finestra di manutenzione del cluster. Una volta modificata la finestra di manutenzione e trascorsa la data pianificata, l'aggiornamento del servizio verrà riprogrammato nella nuova finestra specificata nelle settimane successive. Riceverai una nuova notifica una settimana prima del raggiungimento della nuova data.
La sicurezza AWS è una responsabilità condivisa. Ti consigliamo vivamente di applicare l'aggiornamento il prima possibile.
**Disattivazione degli aggiornamenti del servizio**: è possibile determinare se è possibile disattivare un aggiornamento del servizio verificando il valore dell'attributo «Data di inizio dell'aggiornamento automatico». Se è impostato il valore dell'attributo «Data di inizio dell'aggiornamento automatico» di un aggiornamento del servizio, MemoryDB pianificherà l'aggiornamento del servizio su tutti i cluster rimanenti per la prossima finestra di manutenzione e non è possibile disattivarlo. Tuttavia, se si applica l'aggiornamento del servizio ai cluster rimanenti prima della finestra di manutenzione, MemoryDB non riapplicherà l'aggiornamento del servizio durante la finestra di manutenzione. Per ulteriori informazioni, consulta [Applicazione degli aggiornamenti di servizio](applying-updates.md).
**Perché gli aggiornamenti del servizio non possono essere applicati direttamente da MemoryDB durante le finestre di manutenzione?** - Tieni presente che lo scopo degli aggiornamenti del servizio è darti flessibilità su quando applicarli. I cluster che non partecipano ai programmi di [conformità](memorydb-compliance.md) supportati da MemoryDB possono scegliere di non applicare questi aggiornamenti o di applicarli con una frequenza ridotta durante tutto l'anno. Si consiglia tuttavia di applicare gli aggiornamenti per rimanere conformi alle normative. Questo è vero solo quando il valore dell'attributo «Auto-update start date» di un aggiornamento del servizio non è presente. Per ulteriori informazioni, consulta [Convalida della conformità per MemoryDB](memorydb-compliance.md).
**In che modo gli aggiornamenti applicati nella finestra di manutenzione sono diversi dagli aggiornamenti del servizio?** - Gli aggiornamenti applicati tramite la manutenzione gestita continua vengono programmati direttamente nelle finestre di manutenzione senza che sia necessaria alcuna azione da parte dell'utente. Gli aggiornamenti del servizio sono temporizzati e consentono all'utente di decidere quando effettuare la richiesta entro la «data di inizio dell'aggiornamento automatico». Se non sono ancora stati applicati entro tale data, MemoryDB può pianificare questi aggiornamenti nella finestra di manutenzione.
### Aggiornamenti continui di manutenzione gestita
Questi aggiornamenti sono obbligatori e vengono applicati direttamente nelle finestre di manutenzione senza che sia necessaria alcuna azione da parte dell'utente. Questi aggiornamenti sono distinti da quelli offerti dagli aggiornamenti del servizio.
#### Impatto e tempi di inattività continui della manutenzione
**Quanto tempo richiede la sostituzione di un nodo?** - Una sostituzione viene in genere completata entro 30 minuti. La sostituzione può richiedere più tempo in determinate configurazioni di istanze e schemi di traffico.
**In che modo la sostituzione di un nodo influisce sulla mia applicazione?** - Gli aggiornamenti continui della manutenzione gestita vengono applicati allo stesso modo degli «aggiornamenti del servizio», tramite la sostituzione dei nodi. Per ulteriori dettagli, consulta la sezione precedente relativa all'impatto degli aggiornamenti del servizio e ai tempi di inattività.
**Come posso gestire autonomamente le sostituzioni dei nodi?** - Hai la possibilità di gestire autonomamente queste sostituzioni in qualsiasi momento prima della finestra di sostituzione pianificata dei nodi. Se scegli di gestire personalmente la sostituzione, puoi intraprendere varie azioni a seconda del caso d'uso.
+ [Sostituisci un nodo del cluster con uno o più shard](nodes.nodereplacement.md)[: puoi utilizzare il [backup e il ripristino](snapshots-restoring.md) o lo scale-out seguito da uno scale-in per sostituire i nodi.](cluster-resharding-online.md)
+ [Modifica la finestra di manutenzione](maintenance-window.md): inoltre, puoi modificare la finestra di manutenzione del cluster. Per modificare la finestra di manutenzione in un momento più comodo in un secondo momento, è possibile utilizzare l'[UpdateCluster API](clusters.modify.md), la [CLI update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) o fare clic su [Modifica](clusters.modify.md) nella console di gestione di MemoryDB. Una volta modificata la finestra di manutenzione, MemoryDB pianificherà la manutenzione del nodo durante la finestra appena specificata.
Per vedere come funziona in pratica, supponiamo che attualmente sia giovedì 11/09 alle 15:00 e la finestra di manutenzione successiva sia venerdì 11/10 alle 17:00. Ecco 3 scenari:
+ La finestra di manutenzione viene impostata su venerdì alle 16:00 (dopo la data e l'ora corrente e prima della successiva finestra di manutenzione programmata). Il nodo sarà sostituito venerdì 10 novembre, alle ore 16
+ Si modifica la finestra di manutenzione a sabato alle 16:00 (dopo la data e ora corrente e dopo la successiva finestra di manutenzione programmata). Il nodo sarà sostituito sabato 11 novembre, alle ore 16.
+ La finestra di manutenzione viene impostata su mercoledì alle 16:00 (prima della settimana rispetto alla data e ora corrente). Il nodo sarà sostituito il mercoledì successivo 15/11, alle 16.
Per ulteriori informazioni, consulta [Gestione della manutenzione](maintenance-window.md).
Tieni presente che i nodi di cluster diversi di regioni diverse possono essere sostituiti contemporaneamente, a condizione che la finestra di manutenzione per questi cluster sia configurata in modo che sia la stessa.
**Come posso trovare informazioni sulle sostituzioni programmate imminenti?** - Dovresti ricevere una notifica sullo stato di salute sulla dashboard AWS sanitaria. Inoltre puoi trovare lo stato dei diversi aggiornamenti dei servizi con l' DescribeServiceUpdates API. Tieni presente che ci impegniamo al massimo per informare in modo proattivo i clienti in merito alle sostituzioni prevedibili. Tuttavia, in casi eccezionali come guasti imprevedibili, potrebbero esserci sostituzioni senza preavviso.
**Posso modificare la manutenzione programmata in un momento più opportuno?** - Sì, è possibile posticipare la manutenzione programmata a un orario più opportuno modificando la [finestra di manutenzione](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html).
**Perché state facendo queste sostituzioni di nodi?** - Queste sostituzioni sono necessarie per applicare gli aggiornamenti software obbligatori all'host sottostante. Gli aggiornamenti aiutano a rafforzare la nostra sicurezza, affidabilità e prestazioni operative.
**Queste sostituzioni influiscono contemporaneamente sui miei nodi in più zone di disponibilità e cluster di diverse regioni?** - Le sostituzioni possono essere eseguite in più zone o regioni di disponibilità in parallelo, a seconda della finestra di manutenzione per i cluster.
# Applicazione degli aggiornamenti di servizio
Puoi iniziare ad applicare gli aggiornamenti di servizio al parco istanze dal momento in cui lo stato degli aggiornamenti è **available**. Gli aggiornamenti di servizio sono cumulativi. In altre parole, tutti gli aggiornamenti non ancora applicati sono inclusi con l'ultimo aggiornamento.
Se per un aggiornamento di servizio è abilitato l'aggiornamento automatico, puoi scegliere di non eseguire alcuna operazione quando diventa disponibile. **MemoryDB pianificherà l'applicazione dell'aggiornamento durante la finestra di manutenzione dei cluster dopo la data di inizio dell'aggiornamento automatico.** Riceverai notifiche correlate per ogni fase dell'aggiornamento.
**Nota**
Puoi applicare solo aggiornamenti di servizio con stato **available**o**scheduled**.
Per ulteriori informazioni sulla revisione e l'applicazione di eventuali aggiornamenti specifici del servizio ai cluster MemoryDB applicabili, vedere. [Applicazione degli aggiornamenti del servizio tramite la console](#applying-updates-console-APIReferenceconsole)
Quando è disponibile un nuovo aggiornamento del servizio per uno o più cluster di MemoryDB, è possibile utilizzare la console di MemoryDB, l'API o applicare l'aggiornamento. AWS CLI Le sezioni seguenti illustrano le opzioni che puoi utilizzare per applicare gli aggiornamenti.
## Applicazione degli aggiornamenti del servizio tramite la console
Per visualizzare l'elenco degli aggiornamenti di servizio disponibili, assieme ad altre informazioni, accedi alla pagina **Aggiornamenti di servizio** nella console.
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Nel riquadro di navigazione, sceglie **Aggiornamenti di servizio**.
In **Dettagli dell'aggiornamento del servizio** è possibile visualizzare quanto segue:
+ **Nome aggiornamento di servizio**: il nome univoco dell'aggiornamento di servizio
+ **Descrizione dell'aggiornamento**: informazioni dettagliate sull'aggiornamento del servizio
+ **Data di inizio dell'aggiornamento automatico**: se questo attributo è impostato, MemoryDB inizierà a pianificare l'aggiornamento automatico dei cluster nelle finestre di manutenzione appropriate dopo questa data. **Riceverai notifiche in anticipo nell'esatta finestra di manutenzione pianificata, che potrebbe non essere quella immediata dopo la data di inizio dell'aggiornamento automatico.** Puoi comunque applicare l'aggiornamento ai tuoi cluster ogni volta che lo desideri. Se l'attributo non è impostato, l'aggiornamento del servizio non è abilitato all'aggiornamento automatico e MemoryDB non aggiornerà automaticamente i cluster.
Nella sezione **Stato aggiornamento cluster** puoi visualizzare un elenco di cluster in cui l'aggiornamento di servizio non è stato applicato o è stato applicato recentemente. Per ogni cluster puoi visualizzare:
+ **Nome cluster**: il nome del cluster
+ **Nodi aggiornati:** il rapporto tra i singoli nodi in un cluster specifico che sono stati aggiornati o rimangono disponibili per l'aggiornamento di servizio specifico.
+ **Tipo di aggiornamento**: il tipo di aggiornamento di servizio, cioè **security-update** o **engine-update**
+ **Stato**: lo stato dell'aggiornamento di servizio sul cluster, cioè:
+ *available:* l'aggiornamento è disponibile per i cluster richiesti.
+ *in-progres*: è in corso l'applicazione dell'aggiornamento a questo cluster.
+ *scheduled (pianificato)*: la data di aggiornamento è stata pianificata.
+ *complete (completo)*: l'aggiornamento è stato applicato correttamente. Il cluster con uno stato completo verrà visualizzato per 7 giorni dopo il completamento.
Se hai scelto uno o tutti i cluster con stato **available** o **scheduled** e hai selezionato **Applica ora**, l'aggiornamento inizierà ad essere applicato su tali cluster.
## Applicazione degli aggiornamenti del servizio utilizzando il AWS CLI
Dopo aver ricevuto la notifica che gli aggiornamenti del servizio sono disponibili, puoi esaminarli e applicarli utilizzando la AWS CLI:
+ Per recuperare una descrizione degli aggiornamenti del servizio disponibili, esegui il comando seguente:
`aws memorydb describe-service-updates --status available`
Per ulteriori informazioni, consulta [describe-service-updates](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-service-updates.html).
+ Per applicare un aggiornamento di servizio a un elenco di cluster, utilizza il comando seguente:
`aws memorydb batch-update-cluster --service-update ServiceUpdateNameToApply=sample-service-update --cluster-names cluster-1 cluster2`
Per ulteriori informazioni, consulta [batch-update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/batch-update-cluster.html).