Domande frequenti su AWS Storage Gateway

Gateway di file Amazon S3 è una configurazione del servizio Gateway di archiviazione AWS che fornisce alle tue applicazioni un'interfaccia file per un'archiviazione ininterrotta dei file come oggetti in Simple Storage Service (Amazon S3) e accedervi utilizzando protocolli file con standard di settore.

Gateway di file Amazon S3 può essere utilizzato nei seguenti casi: (a) migrazione di dati dei file on-premises verso Simple Storage Service (Amazon S3), mantenendo al tempo stesso un rapido accesso locale per i dati recentemente visionati, (b) backup dei dati dei file on-premises come oggetti in Simple Storage Service (Amazon S3) (inclusi database e log Microsoft SQL Server e Oracle), con la possibilità di utilizzare funzionalità S3 come la gestione del ciclo di vita e la replica tra regioni e (c) flussi di lavoro cloud ibridi utilizzando i dati generati dalle applicazioni on-premise per l'elaborazione da parte dei servizi AWS come il machine learning, l'analisi dei Big Data o le funzioni serverless.

Amazon S3 File Gateway consente ad applicazioni, dispositivi e flussi di lavoro esistenti basati su file di utilizzare Simple Storage Service (Amazon S3) senza dover effettuare modifiche. Amazon S3 File Gateway memorizza in modo sicuro e durevole sia i contenuti dei file sia i metadati come oggetti, fornendo al tempo stesso alle tue applicazioni on-premise un accesso a bassa latenza ai dati nella cache.

Amazon S3 File Gateway supporta Amazon S3 Standard, S3 Intelligent-Tiering, S3 Standard - Infrequent Access (S3 Standard-IA) e S3 One Zone-IA. Per i dettagli sulle classi d'archiviazione, consulta la documentazione di Simple Storage Service (Amazon S3). Puoi configurare la classe di storage iniziale per gli oggetti creati dal gateway, quindi puoi utilizzare le policy di gestione del ciclo di vita del bucket per trasferire file da Amazon S3 su Amazon S3 Glacier. Se un'applicazione tenta di accedere a un file/oggetto archiviato attraverso l'Amazon File Gateway che si trova in Amazon S3 Glacier, riceverai un errore generico I/O.

Amazon S3 File Gateway supporta i client Linux che si collegano al gateway utilizzando Network File System (NFS) versioni 3 e 4.1 e supporta i client Windows che si collegano al gateway utilizzando Server Message Block (SMB) versioni 2 e 3.

È possibile creare una condivisione di file NFS o SMB utilizzando la Console di gestione AWS o un'API di servizi e associare la condivisione di file a un bucket di Amazon S3 nuovo o esistente. Per accedere alla condivisione di file dalle tue applicazioni, montala dalla tua applicazione utilizzando comandi standard UNIX o Windows. Per praticità, nella console di gestione sono mostrate alcune linee di comando di esempio per ciascun ambiente.

La condivisione di file NFS è configurabile con controlli amministrativi come la limitazione dell'accesso a determinati client NFS o a reti specifiche, l'accesso in sola lettura o in lettura-scrittura o l'abilitazione dello squashing dei permessi utente.

È possibile configurare la condivisione di file SMB perché siano accessibili solo da parte degli utenti Active Directory (AD) o fornire accesso ospite autenticato agli utenti della propria organizzazione. Inoltre, è possibile limitare ulteriormente l'accesso alla condivisione di file come sola lettura o lettura e scrittura, oppure a specifici utenti e gruppi AD.

Sì, è possibile configurare l'enumerazione basata sull'accesso per le condivisioni di file SMB per impedire agli utenti di visualizzare cartelle e file che non sarebbero in grado di aprire in base alle loro autorizzazioni di accesso. Inoltre, è possibile controllare se le condivisioni di file su Amazon S3 File Gateway sono consultabili dagli utenti.

Sì, Amazon S3 File Gateway si integra con Microsoft Active Directory on-premise come anche con soluzioni Active Directory nel cloud, quali Managed Microsoft AD.

Sì. È possibile esportare una condivisione di file SMB utilizzando un nome utente e password ospite. Sarà necessario modificare la password predefinita utilizzando la Console o l'API del servizio prima di configurare la condivisione del file per l'accesso ospite.

Sì.

No, attualmente i metadata dei file, come i metadata di proprietà, archiviati come oggetti S3, non possono essere mappati su protocolli differenti.

Amazon S3 File Gateway utilizza un ruolo AWS Identity and Access Management (IAM) per accedere al tuo bucket S3. Puoi configurare un ruolo IAM in autonomia o farlo configurare automaticamente dalla Console di gestione di Gateway di archiviazione AWS. Per la configurazione automatica, AWS Storage Gateway crea un nuovo ruolo IAM nel tuo account e lo associa a una policy di accesso IAM per accedere al tuo bucket S3. Il ruolo e la policy di accesso IAM vengono creati nel tuo account e puoi gestirli completamente da solo.

Per utilizzare la condivisione di file, montala dalla tua applicazione utilizzando comandi standard UNIX o Windows. Per praticità, nella Console di gestione sono mostrate alcune righe di comando di esempio.

La condivisione di file può essere mappata al root nel bucket S3 oppure può essere mappata su un prefisso S3 all'interno di un bucket S3. Se specifichi un prefisso S3 quando crei una condivisione di file, colleghi tale condivisione al prefisso S3. Se non specifichi un prefisso S3 quando crei una condivisione di file, tale condivisione viene collegata al root del bucket S3.

Sì, il nome della condivisione di file non deve necessariamente essere lo stesso del bucket S3 o del prefisso S3.

Sì, puoi cambiare il nome della tua condivisione di file.

I file sono archiviati come oggetti nei bucket S3 e puoi configurare la classe di archiviazione iniziale per gli oggetti che il gateway di file crea. Fra i file e gli oggetti c'è una relazione uno-a-uno e la classe di archiviazione iniziale può essere configurata per gli oggetti creati da Amazon S3 File Gateway.

La chiave oggetto deriva dal percorso del file nel file system. Ad esempio, se è presente un gateway con nome host file.amazon.com ed è stato mappato my-bucket/my-prefix, il nome del punto di montaggio a cui si collega Gateway di file è file.amazon.com:/export/my-bucket/my-prefix. Se viene quindi montato in locale in /mnt/my-bucket/my-prefix e viene creato un file di nome file.html in una directory /mnt/my-bucket/my-prefix/dir, questo file sarà archiviato come oggetto nel bucket my-bucket con la chiave my-prefix/dir/file.html. La creazione di file sparse genererà un oggetto non-sparse costituito da soli zeri in S3.

I tuoi client possono creare, leggere, aggiornare ed eliminare file e directory. Inoltre, possono modificare le autorizzazioni e la proprietà di file e cartelle. I file vengono memorizzati come oggetti singoli in Amazon S3. Le directory sono gestite come oggetti folder in S3, utilizzando la stessa sintassi usata nella console S3. I collegamenti simbolici e fissi non sono supportati. Il tentativo di creare un collegamento causerà un errore. Le operazioni comuni sui file, infatti, modificano i metadati dei file. Questo comporta l'eliminazione dell'oggetto S3 corrente e la creazione di un nuovo oggetto S3.

Le operazioni di ridenominazione appariranno come atomiche ai tuoi client, ma S3 non supporta la ridenominazione degli oggetti. Quando si rinomina un file o una directory, il gateway esegue delle richieste copy-put per creare una copia degli oggetti in S3 con nuove chiavi e quindi elimina gli oggetti originali. In questo modo si evita di dover inviare di nuovo attraverso la rete file di grandi dimensioni. La ridenominazione delle directory contenenti un grande numero di file non è istantanea e comporta l'archiviazione di due copie dei dati in S3, inoltre le operazioni nelle directory saranno bloccate fino al completamento dell'operazione di ridenominazione.

I tuoi client possono accedere a metadata stile POSIX, tra cui proprietà, autorizzazioni e timestamp che sono memorizzati in modo durevole in S3 nei metadata utente dell'oggetto associato al file. Quando crei una condivisione dati su un bucket esistente, i metadata archiviati verranno ripristinati e resi accessibili ai tuoi client.

Per ogni condivisione di file, è possibile abilitare la determinazione dei tipi MIME per gli oggetti caricati al momento della creazione oppure in un secondo momento. Se questa caratteristica viene abilitata, il File Gateway utilizzerà l'estensione del nome per determinare il tipo MIME del file e impostare il parametro Content-Type degli oggetti S3. Si tratta di una funzione utile se si utilizza File Gateway per gestire gli oggetti in S3 a cui si accede direttamente tramite URL o che vengono implementati tramite Amazon CloudFront.

Sì. Quando gli oggetti sono archiviati in S3, vi si può accedere direttamente in AWS per i carichi di lavoro nel cloud senza passare per Amazon S3 File Gateway. Gli oggetti ereditano le proprietà del bucket S3 nel quale sono immagazzinati, come la gestione del ciclo di vita e la replica in più regioni.

Un oggetto al quale si deve accedere utilizzando una condivisione di file deve essere gestito unicamente dal gateway. Se si sovrascrive o aggiorna direttamente un oggetto scritto precedentemente da Amazon S3 File Gateway, ne risulterà un comportamento non definito quando si accede all'oggetto mediante la condivisione di file.

Se un bucket contiene già oggetti quando viene configurato per l'utilizzo con Amazon S3 File Gateway, verranno utilizzate chiavi oggetto per presentare gli oggetti come file ai client NFS e SMB. Ai file vengono attribuiti metadata di sistemi di file predefiniti.

Per ridurre la latenza e il numero di richieste a Simple Storage Service (Amazon S3), Amazon S3 File Gateway esegue la scansione solo delle intestazioni dei metadati dei file associati agli oggetti quando elenchi esplicitamente i file o le directory. I metadati dei file sono raccolti come parte della scansione, i contenuti dei file sono scaricati solo quando viene letto l'oggetto.

Il gateway non scarica automaticamente tutti gli oggetti o i dati esistenti nel bucket, ma solo quando vengono esplicitamente consultati dai client. Inoltre, per ridurre il carico del trasferimento dei dati, File Gateway utilizza il caricamento in più parti e i comandi PUT COPY, in modo da caricare in S3 solo i dati con modifiche nei file.

È possibile configurare proprietà e autorizzazioni di default per gli oggetti che sono stati caricati nel bucket S3 direttamente, ovvero senza utilizzare il gateway di file e una condivisione NFS.

Per gli oggetti che sono stati caricati nel bucket S3 direttamente, ovvero senza utilizzare Amazon S3 File Gateway e una condivisione SMB, i metadati come proprietà e autorizzazioni verranno ereditati dalla cartella padre dell'oggetto. Le autorizzazioni nella root della condivisione sono fisse e gli oggetti creati direttamente nella cartella root erediteranno queste autorizzazioni fisse. Fai riferimento alla documentazione sulle impostazioni dei metadata degli oggetti creati al di fuori del gateway.

A un solo File Gateway possono accedere più client NFS. Tuttavia, come con qualunque server NFS, le modifiche simultanee da parte di più client NFS possono provocare un comportamento imprevedibile. Per farlo in modo sicuro è necessario un coordinamento a livello dell'applicazione.

No, consigliamo di avere un solo scrittore di oggetti nel bucket S3. Se si sovrascrive o aggiorna direttamente un oggetto scritto precedentemente da File Gateway, ne risulterà un comportamento non definito quando si accede all'oggetto mediante la condivisione di file. Le modifiche simultanee allo stesso oggetto (ad esempio, tramite l'API S3 e Amazon S3 File Gateway) possono provocare risultati imprevedibili, perciò questo tipo di configurazione è sconsigliato.

Sconsigliamo di configurare più scrittori in un solo bucket per evitare risultati imprevedibili. Si possono imporre nomi di oggetti o prefissi univoci tramite il flusso di lavoro dell'applicazione. S3 File Gateway crea notifiche sull'integrità quando si verificano conflitti in tale configurazione.

Sì, ci possono essere più lettori su un bucket gestito tramite un Amazon S3 File Gateway. Puoi configurare una condivisione di file come solo in lettura e permettere a più gateway di leggere gli oggetti dello stesso bucket. Inoltre, puoi aggiornare l'inventario degli oggetti noti al gateway utilizzando la Console di Gateway di archiviazione, il processo automatico di aggiornamento periodico della cache o l'API RefreshCache.

Tuttavia, è importante notare che se non si configura la condivisione in sola lettura, Amazon S3 File Gateway non monitorerà né impedirà le eventuali modifiche accidentali al bucket da parte degli utenti. Per questo devi mantenere nella tua applicazione una configurazione scrittore singolo/lettore multiplo.

Sì, puoi monitorare l'utilizzo della condivisione di file mediante i parametri Amazon CloudWatch e ricevere una notifica del completamento delle operazioni di file mediante CloudWatch Events. Per ulteriori informazioni, consulta la pagina Monitoraggio della tua condivisione di file.

Quando vengono apportate modifiche a file in condivisione con Amazon S3 File Gateway, i dati vengono prima memorizzati in locale, quindi caricati in modo asincrono sul bucket S3. È possibile richiedere notifiche tramite AWS CloudWatch Events una volta che il caricamento di un singolo file viene completato. Le notifiche di questo tipo possono anche essere utilizzate per attivare flussi di lavoro aggiuntivi, ad esempio invocando una funzione AWS Lambda o un'automazione di Amazon EC2 Systems Manager il cui funzionamento dipende dai dati caricati in S3. Per ulteriori informazioni, consulta la documentazione per la notifica di caricamento dei file.

La notifica di caricamento di file fornisce una notifica per ogni singolo file caricato su Amazon S3 tramite S3 File Gateway. Le notifiche degli eventi S3 consistono in notifiche che includono caricamenti di file parziali, pertanto non è possibile comprendere se il caricamento del file è stato completato.

Quando vengono apportate modifiche a file in condivisione con Amazon S3 File Gateway, i dati vengono prima memorizzati in locale, quindi caricati in modo asincrono sul bucket S3. Puoi richiedere di ricevere notifiche tramite Eventi Amazon CloudWatch quando il caricamento di un set di file funzionante è terminato. Le notifiche di questo tipo possono anche essere utilizzate per attivare flussi di lavoro aggiuntivi, ad esempio invocando una funzione AWS Lambda o un'automazione di Amazon EC2 Systems Manager il cui funzionamento dipende dai dati caricati in S3. Per ulteriori informazioni, consulta la documentazione per la notifica di caricamento di un set di file funzionante.

Sì, puoi aggiornare l'inventario degli oggetti noti ad Amazon S3 File Gateway utilizzando la Console, il processo di aggiornamento della cache gestito dal file system o l'API RefreshCache. Riceverai notifiche mediante AWS CloudWatch Events una volta completata l'operazione dell'API RefreshCache. Queste notifiche possono essere utilizzate per inviare e-mail mediante Amazon SNS, oppure attivare l'elaborazione locale utilizzando i contenuti aggiornati. Per ulteriori informazioni, consulta la documentazione.

Sì, puoi utilizzare il gateway per l'accesso da altri account ai bucket. Per ulteriori informazioni, consulta la documentazione per utilizzare la condivisione di file per l'accesso multi-account.

Sì, quando crei la tua condivisione di file puoi abilitare l'accesso ai bucket S3 Requester Pays. Come richiedente, dovrai sostenere i costi associati all'accesso dei dati dai bucket Requester Pays.

Puoi creare più condivisioni di file per un singolo bucket S3 specificando un prefisso S3 durante il processo di creazione della condivisione di file.

Puoi creare fino a 50 condivisioni per un bucket S3 in un singolo gateway. Non limitiamo il numero di condivisioni di file per bucket su più gateway, ma ogni gateway è limitato a 50 condivisioni. Tuttavia, è consigliabile di conservare un solo processo di scrittura nel bucket, un gateway di file di Amazon S3 o un client che accede direttamente ad S3.

Sì, puoi cambiare il nome di una condivisione di file.

La dimensione massima di un singolo file è 5 TB, che è la dimensione massima di un singolo oggetto in S3. Se scrivi un file di dimensioni superiori a 5 TB, riceverai il messaggio di errore "file troppo grande" e solo i primi 5 TB del file verranno caricati.

Il gateway restituisce un grande numero (8 EB) come capacità totale. Amazon S3 non pone limiti allo storage totale.

Sì. Le policy del tuo bucket per gestione del ciclo di vita, replica in più regioni e notifiche di eventi S3 vengono applicate direttamente agli oggetti memorizzati nel bucket mediante AWS Storage Gateway.

Puoi utilizzare le policy di gestione del ciclo di vita di S3 per modificare il livello di storage di un oggetto ed eliminare oggetti vecchi o versioni obsolete. Quando un oggetto viene eliminato da una policy sul ciclo di vita, è necessario abilitare la funzionalità di aggiornamento periodico della cache o richiamare l'API RefreshCache per riflettere le modifiche sui client NFS.

Se un bucket S3 è configurato come destinazione di una replica in più regioni, potrebbe essere necessario abilitare la funzionalità di aggiornamento periodico della cache o utilizzare l'API RefreshCache per accertarsi che la cache del gateway e il bucket S3 siano sincronizzati.

Quando sono in uso le notifiche di eventi di S3, si potranno ricevere eventi per file parziali creati dal gateway per verificare che i dati siano memorizzati in modo durevole in S3. I file parziali possono essere creati per diversi motivi, ad esempio quando il gateway necessita di liberare spazio nella cache oppure in caso di frequenze di scrittura elevate su un file. I file creati in questo modo non offriranno consistenza con l'applicazione.

Amazon S3 File Gateway supporta le versioni 2 e 3 di SMB oltre alle versioni 3, 4.0 e 4.1 di NFS. Continuiamo a eseguire test con app di backup comuni. Informaci tramite AWS Support o tramite il team dell'account AWS di eventuali app specifiche per cui vorresti che effettuassimo un test di compatibilità.

No. Amazon S3 File Gateway permette di archiviare file come oggetti in S3.

Amazon S3 File Gateway può essere utilizzato quando si vuole accedere a oggetti in S3 come file utilizzando operazioni di file system standard. Amazon S3 File Gateway inoltre fornisce accesso locale a bassa latenza e trasferimento di dati efficiente. Puoi utilizzare l'API S3 quando la tua applicazione non necessita operazioni di sistemi di file e può gestire direttamente il trasferimento dei dati.

L'archiviazione su disco locale nel gateway viene utilizzato per memorizzare temporaneamente i dati modificati da trasferire in AWS e per memorizzare nella cache locale i dati per l'accesso in lettura a bassa latenza. File Gateway gestisce automaticamente la cache conservando i dati consultati più di recente in base alle operazioni di lettura e scrittura del client. I dati vengono rimossi dalla cache solo quando lo spazio è necessario per memorizzare dati utilizzati più di recente.

Per ottimizzare le prestazioni di scrittura, il gateway utilizza un meccanismo di writeback nel quale i dati vengono salvati in modo permanente su disco e caricati in modo asincrono in S3. Il gateway utilizza i dati tramite la cache locale per ottimizzare le prestazioni di lettura. Se non sono presenti, i dati vengono recuperati in modo sincrono da Amazon S3 utilizzando richieste GET in intervalli di byte.

Il dimensionamento della cache locale dovrebbe essere deciso in base ai set di dati operativi a cui è necessario accedere a bassa latenza. Se le dimensioni della cache non sono sufficienti, la latenza in lettura aumenterà, perché i dati da recuperare dovranno essere ricercati in S3, mentre le operazioni in scrittura potrebbero non riuscire se non è presente sufficiente spazio nella cache per memorizzare i caricamenti di dati in locale in sospeso in S3.

Dovresti eseguire il provisioning della tua cache in base a:
1/ Le dimensioni del tuo dataset di lavoro per cui necessiti di accesso a bassa latenza, così puoi ridurre le latenze di lettura diminuendo la frequenza con cui vengono richiesti i dati da S3 e
2/ Le dimensioni dei file scritti nel gateway dalle tue applicazioni.

Dischi di cache più piccoli possono comportare prestazioni inadeguate ed errori durante le operazioni di scrittura se non c'è spazio libero nella cache per memorizzare i dati in locale in attesa dell'upload in S3. Per ulteriori informazioni sul monitoraggio del tuo utilizzo della cache, fai riferimento alla sezione Monitoraggio della tua condivisione di file nella documentazione.

I dati scritti nella cache dalle tue applicazioni o tramite il recupero da Amazon S3 vengono rimossi dalla cache solo quando lo spazio è necessario per memorizzare dati consultati più di recente.

No. I file vengono mappati in modo univoco con gli oggetti nel bucket senza modifiche, consentendone l'accesso diretto in S3 senza dover utilizzare il gateway o distribuire software aggiuntivo per riattivare i dati.

Amazon S3 File Gateway utilizza la copia e il caricamento in più parti, in modo che solamente i dati modificati vengono caricati in S3, riducendo così il volume dei dati trasferiti. Il gateway non scarica automaticamente tutti gli oggetti o i dati esistenti nel bucket, ma solo quando vengono esplicitamente consultati dal client NFS.

Il gateway di file non utilizzerà gli endpoint accelerati anche se il tuo bucket è configurato per S3 Transfer Acceleration.

Tutti i dati trasferiti fra il gateway e lo storage AWS sono crittografati con SSL. Per impostazione predefinita, tutti i dati memorizzati in S3 vengono crittografati lato server con le chiavi di crittografia gestite di Amazon S3 (SSE-S3). Come opzione si può configurare ciascuna condivisione di file per crittografare gli oggetti con chiavi gestite da AWS KMS utilizzando SSE-KMS. Per ulteriori informazioni, consulta la sezione "Crittografia dei dati con AWS Key Management System" della guida per l'utente di Gateway di archiviazione, che include dettagli d'importanza fondamentale sull'utilizzo della funzionalità.  

Amazon FSx File Gateway ottimizza l'accesso on-premise alle condivisioni file Windows in Amazon FSx, semplificando l'accesso degli utenti ai dati di FSx per Windows File Server con bassa latenza e conservando la larghezza di banda condivisa. Gli utenti traggono vantaggio da una cache locale di dati utilizzati di frequente a cui possono accedere, consentendo prestazioni rapide e un traffico di trasferimento dei dati ridotto. Le operazioni del file system, come la lettura e la scrittura di file, vengono tutte eseguite sulla cache locale, mentre Amazon FSx File Gateway sincronizza i dati modificati su FSx for Windows File Server in background. Con queste funzionalità, puoi consolidare tutti i dati delle condivisioni di file on-premise in AWS su FSx for Windows File Server e trarre vantaggio da file system protetti, resilienti e completamente gestiti.

Molte applicazioni desktop on-premise sono sensibili alla latenza e questo potrebbe causare ritardi per gli utenti finali e un rallentamento delle prestazioni quando essi accedono direttamente ai file in AWS da posizioni remote. Inoltre, permettere a un numero elevato di utenti di accedere direttamente ai dati nel cloud può causare la congestione delle risorse con larghezza di banda condivisa, come i collegamenti AWS Direct Connect. Amazon FSx File Gateway permette di utilizzare Amazon FSx for Windows File Server per questi carichi di lavoro e contribuisce a sostituire lo storage on-premise con uno storage di file completamente gestito, scalabile e altamente affidabile in AWS, senza influire sulle applicazioni o sulla rete.

Amazon FSx File Gateway fornisce un protocollo file SMB a cui i client possono connettersi e una cache on-premise dei dati utilizzati di frequente a cui possono accedere con la stessa bassa latenza presente in AWS. Le operazioni del file system, come la lettura e la scrittura di file, sono tutte eseguite sulla cache locale, mentre Amazon FSx File Gateway sincronizza i dati modificati su Amazon FSx per Windows File Server in background. Amazon FSx File Gateway contribuisce inoltre a ridurre al minimo la quantità di trasferimenti di dati, ottimizzando l'utilizzo della larghezza di banda di rete in AWS.

Per utilizzare Amazon FSx File Gateway, devi avere almeno un file system Amazon FSx in esecuzione e devi assicurarti di disporre dell'accesso on-premise ad Amazon FSx per Windows File Server tramite VPN o attraverso una connessione AWS Direct Connect. Per iniziare a utilizzare FSx per Windows File Server, consulta le istruzioni della documentazione qui. Puoi iniziare scaricando e distribuendo un'appliance virtuale VMware per Amazon FSx File Gateway o un'appliance hardware per AWS Storage Gateway nel tuo ambiente on-premise. Dopo aver installato Amazon FSx File Gateway e aver effettuato l'accesso a FSx for Windows File Server, puoi utilizzare la Console di gestione AWS per collegare un file system FSx for Windows File Server. La Console di gestione AWS indicherà la procedura da seguire per rendere le condivisioni di file accessibili on-premise.

Dopo aver configurato le condivisioni di file, i sistemi client potranno sfogliare e connettersi alle condivisioni di file su Amazon FSx File Gateway che corrispondono ai file system Amazon FSx. Quando le condivisioni di file sono connesse, gli utenti possono leggere e scrivere i propri file localmente, sfruttando tutte le caratteristiche disponibili su FSx per Windows File Server. 

Amazon FSx File Gateway può essere utilizzato per accedere a file system Windows AWS in tutte le regioni in cui è offerto FSx per Windows File Server.

L'addebito per Amazon FSx File Gateway è su base oraria. Per informazioni sui prezzi, consulta la pagina dei prezzi di Gateway di archiviazione AWS.

Gateway di file Amazon FSx supporta le versioni 2.x e 3.x del protocollo Server Message Block (SMB). SMB è supportato da Microsoft Windows, MacOS e Linux.

Amazon FSx File Gateway esegue la mappatura delle condivisioni di file locali e del relativo contenuto nelle condivisioni di file archiviate in remoto in Amazon FSx per Windows File Server. Esiste una corrispondenza di 1:1 tra i file remoti e visibili localmente e le relative condivisioni.

Sì. Puoi accedere alle condivisioni di file sia da Amazon FSx File Gateway che direttamente da Amazon FSx in AWS. Tuttavia, devi assicurarti che i file possano essere scritti solo da un'unica posizione alla volta. In questa versione, Gateway di file Amazon FSx non impedisce che scritture effettuate da più posizioni si sovrappongano creando conflitti.

Puoi gestire Amazon FSx per Windows File Server tramite un'interfaccia di gestione remota utilizzando tutti gli strumenti forniti da FSx per Windows File Server.

Sì. Ti è permesso collegare un gateway a condivisioni su un massimo di 5 file system, a condizione che facciano tutte parte del dominio Active Directory. Amazon FSx File Gateway può partecipare a un solo dominio di Active Directory Domain.

Puoi implementare una macchina virtuale che contiene il software Gateway di file Amazon FSx su VMware ESXi, Microsoft Hyper-V o Linux KVM, oppure puoi implementare Gateway di archiviazione come appliance hardware.

Amazon FSx File Gateway diventa membro del dominio di Active Directory se l'infrastruttura di AD è ospitata in AWS Directory Service o se è gestita on-premise. Quando Amazon FSx File Gateway è membro del dominio, può accedere a tutti gli utenti e le policy impostate in tale dominio per applicare la sicurezza. Gateway di file Amazon FSx si comporterà quindi in modo identico a qualsiasi server Windows e applicherà tutte le policy di accesso ai file applicabili in base alla configurazione di Active Directory. 

Amazon FSx File Gateway utilizza controlli di accesso a Windows nativi ed è compatibile con qualsiasi elenco di accesso statico che funziona con Microsoft Windows. La dimensione massima di un ACL è 64 KB o circa 1820 voci di controllo di accesso. È identica a quella degli host dei server Windows. I controlli di accesso vengono impostati e memorizzati su FSx Windows File Server, quindi devi crearli solo una volta e verranno riflessi in tutti i gateway di file collegati.

Sì. Amazon FSx File Gateway supporta la crittografia SMB fino alle specifiche SMB v3.1.1 più recenti, incluse AES 128 CCM e AES 128 GCM. I client compatibili si connetteranno utilizzando la crittografia automaticamente. Amazon FSx File Gateway inoltre utilizza la crittografia SMB quando comunica con FSx for Windows File Server in AWS. È necessario configurare una VPN o un collegamento Direct Connect ad AWS e impostare policy appropriate per permettere al traffico SMB e al traffico di gestione di passare attraverso AWS.

Proprio come Amazon S3 File Gateway, Amazon FSx File Gateway raggiunge una disponibilità elevata in VMware eseguendo una serie di controlli dell’integrità continui rispetto all'operazione di connessione del gateway al servizio di monitoraggio VMware. Durante un errore relativo all'hardware, al software o alla rete, VMware indurrà un riavvio del gateway su un nuovo host o su un host già esistente, se è ancora operativo. Gli utenti e le applicazioni subiranno un downtime di un massimo di 60 secondi durante il riavvio. Dopo il riavvio, le connessioni al gateway vengono ristabilite automaticamente e senza bisogno di intervento manuale. Durante la reinizializzazione, il gateway invia di nuovo i parametri al cloud per fornire ai clienti una visione completa dell'evento di disponibilità. 

Gateway di file Amazon FSx con VMware HA abilitato e il monitoraggio delle applicazioni configurato individuerà e ripristinerà gli errori hardware, di hypervisor e di rete, così come problemi software che portano ai timeout della connessione o alla mancata disponibilità delle condivisioni di file. 

Amazon FSx File Gateway supporta un massimo di 50 condivisioni e 500 sessioni di client attivi connessi a istanze di Amazon FSx File Gateway nella configurazione di una singola istanza.

Rispetto al warehousing di nastri fisici in remoto, l'archiviazione dei nastri virtuali in AWS mediante Tape Gateway con S3 Glacier Deep Archive offre una durabilità dei dati pari al 99,999999999% (gli undici nove), controlli a intervalli regolari da parte di AWS, dati corretti in caso di ripristino e risparmio sui costi. Innanzitutto, tutti i nastri virtuali archiviati in S3 Glacier Deep Archive sono replicati e archiviati in almeno tre zone di disponibilità geograficamente distribuite, protetti dal 99,999999999% di durabilità. Secondo, AWS effettua controlli ad intervalli regolari per verificare che i tuoi dati siano leggibili e che non siano stati introdotti errori. Terzo, tutti i nastri archiviati in S3 Glacier Deep Archive sono protetti da S3 Server Side Encryption mediante chiavi di default o le tue chiavi KMS. Inoltre, si evitano i rischi per la sicurezza fisica associati alla portabilità dei nastri. Quarto, mentre con il warehousing dei nastri in remoto c'è il rischio di errori o danni al nastro durante un ripristino, Tape Gateway garantisce sempre dati corretti. Infine, se archivi i dati in S3 Glacier Deep Archive, puoi risparmiare sui costi mensili di storage rispetto al warehousing dei nastri in remoto.

Tape Gateway supporta le classi di archiviazione S3 Standard, S3 Glacier e S3 Glacier Deep Archive. I dati sui tuoi nastri virtuali sono archiviati all'interno della libreria dei nastri virtuali in Simple Storage Service (Amazon S3) quando l'applicazione di backup scrive i dati sui nastri. Una volta estratti i nastri dall'applicazione di backup, i tuoi nastri vengono archiviati in S3 Glacier o S3 Glacier Deep Archive.

Le dimensioni minime e massime di un nastro virtuale creabile su un Gateway di nastri virtuali sono rispettivamente 100 GiB e 15 TiB. In ogni caso, saranno solo addebitati i costi dello spazio occupato dai dati memorizzati, non delle dimensioni totali.

Un singolo Tape Gateway può contenere fino a 1.500 nastri virtuali nella VTL, con una capacità massima totale di 1 PB. Tuttavia non ci sono limiti alla quantità di dati o al numero di nastri che si possono archiviare. Si possono anche distribuire Tape Gateway aggiuntivi per dimensionare l’archiviazione per i nastri virtuali non archiviati. Per ulteriori informazioni, consulta la nostra documentazione sui limiti di Gateway di archiviazione.

Non è previsto alcun limite al numero o al volume di nastri virtuali che è possibile archiviare.

Puoi recuperare un nastro virtuale archiviato in S3 Glacier o S3 Glacier Deep Archive in S3. Un nastro archiviato in S3 Glacier può essere recuperato in S3 utilizzando il metodo di recupero standard che, in genere, avviene in 3–5 ore. Un nastro archiviato in S3 Glacier Deep Archive può essere recuperato in S3 utilizzando il metodo di recupero standard che, in genere, avviene in 12 ore.

Per poter accedere ai nastri virtuali contenenti i dati, questi devono essere memorizzati in una libreria di nastri virtuali. L'accesso ai nastri nella libreria è istantaneo. Per recuperare un nastro virtuale archiviato, puoi utilizzare la Console o l'API di gestione AWS. Devi prima selezionare il nastro virtuale, quindi selezionare la libreria di nastri virtuali in cui desideri caricarlo. Puoi recuperare un nastro archiviato su S3 Glacier e S3 Glacier Deep Archive su S3 rispettivamente in un periodo di tempo che va dalle tre e cinque ore e dodici ore. Quando il nastro virtuale è disponibile nella libreria, usa l'applicazione di backup per ripristinare i dati desiderati.

No. Non è possibile accedere ai dati contenuti nei nastri virtuali usando le API di Amazon S3 o di Amazon S3 Glacier. È tuttavia possibile gestire VTL e VTS tramite le API di Tape Gateway.

Quando crei nuovi nastri utilizzando la console o l'API di Storage Gateway, puoi impostare S3 Glacier Deep Archive come destinazione dell'archiviazione. Quando il software di backup espelle i nastri, questi vengono archiviati in S3 Glacier Deep Archive. Puoi recuperare in S3 un nastro archiviato in S3 Glacier Deep Archive utilizzando il metodo di recupero standard che, in genere, avviene in 12 ore.

Sì. Il gateway di nastri supporta lo spostamento dei tuoi nastri in S3 Glacier su S3 Glacier Deep Archive. Puoi assegnare il nastro situato nel Glacier Pool al Deep Archive Pool utilizzando la console o l'API di AWS Storage Gateway. Tape Gateway sposterà il nastro virtuale nel Deep Archive Pool relativo alla classe di archiviazione S3 Glacier Deep Archive. Lo spostamento di un nastro da S3 Glacier a S3 Glacier Deep Archive comporta il pagamento di una commissione e, se trasferisci un nastro da S3 Glacier a S3 Glacier Deep Archive entro 90 giorni, verrà applicata una commissione di cancellazione per S3 Glacier.

No, non è possibile spostare un nastro in S3 Glacier Deep Archive su S3 Glacier. È possibile recuperare un nastro da S3 Glacier Deep Archive su S3 o cancellare un nastro da S3 Glacier Deep Archive.

L'interfaccia VTL è compatibile con applicazioni di backup e di archiviazione che usano l'interfaccia della libreria di nastri basata su iSCSI standard di settore. Per un elenco completo delle applicazioni di backup supportate, consulta la pagina con la panoramica di Gateway di archiviazione.

Tutti i dati trasferiti fra il gateway e l’archiviazione AWS sono crittografati con SSL. Per impostazione predefinita, tutti i dati memorizzati in S3 da Tape Gateway vengono crittografati lato server con le chiavi di crittografia gestite di Amazon S3 (SSE-S3).

È anche possibile configurare la crittografia su nastri con chiavi gestite in AWS KMS tramite l'API Storage Gateway. Potrai specificare una delle chiavi master del cliente (CMK) come chiave KMS. La chiave master del cliente utilizzata per crittografare i dati dei nastri non può essere modificata dopo la creazione. Per ulteriori informazioni, consulta la sezione "Crittografia dei dati con AWS Key Management System" della guida per l'utente di Gateway di archiviazione, che include dettagli d'importanza fondamentale sull'utilizzo della funzionalità.

Ciascun Gateway di volumi può supportare fino a 32 volumi. Nella modalità cache, ciascun volume può arrivare a 32 TB per un massimo di 1 PB di dati per gateway (32 volumi, ognuno dei quali di 32 TB). Nella modalità storage, ciascun volume può arrivare a 16 TB per un massimo di 512 TB di dati per gateway (32 volumi, ognuno dei quali di 16 TB). Per ulteriori informazioni, consulta la nostra documentazione sui limiti di Gateway di archiviazione.

I Volume Gateway comprimono i dati prima che vengano trasferiti su AWS e mentre sono memorizzati in AWS. Questa modalità consente di ridurre le spese di storage e di trasferimento dei dati. Lo storage del volume non è sottoposto a provisioning preventivo; saranno addebitati i costi solo per la quantità di dati memorizzati nel volume, non per le dimensioni totali del volume creato.

I tuoi volumi sono archiviati in un bucket Amazon S3 mantenuto dal servizio AWS Storage Gateway. Sono accessibili per operazioni I/O tramite AWS Storage Gateway. Non è possibile accedervi direttamente utilizzando azioni API di Amazon S3. Puoi acquisire snapshot point-in-time dei Volume Gateway disponibili sotto forma di snapshot Amazon EBS, che possono essere convertiti in volumi Storage Gateway o volumi EBS. Per lavorare nativamente con i tuoi dati in S3, utilizza il File Gateway.

Tutti i dati trasferiti fra il gateway e l’archiviazione AWS sono crittografati con SSL. Per impostazione predefinita, tutti i dati memorizzati in S3 da Volume Gateway vengono crittografati lato server con le chiavi di crittografia gestite di Amazon S3 (SSE-S3).

È possibile scegliere di configurare la crittografia dei dati memorizzati in AWS su volumi utilizzando chiavi gestite da AWS KMS tramite l'API Storage Gateway. Potrai specificare una delle chiavi master del cliente (CMK) come chiave KMS. La chiave master del cliente configurata utilizzata per crittografare un volume non può essere modificata dopo la creazione. Per ulteriori informazioni, consulta la sezione "Crittografia dei dati con AWS Key Management System" della guida per l'utente di Gateway di archiviazione, che include dettagli d'importanza fondamentale sull'utilizzo della funzionalità.

Sì. È possibile creare uno snapshot EBS da un volume crittografato con AWS KMS utilizzando l'API. Lo snapshot EBS sarà crittografato utilizzando la stessa chiave utilizzata per il volume.

Sì. È possibile creare un volume crittografato da uno snapshot EBS crittografato con KMS utilizzando l'API. Il volume può utilizzare la stessa chiave impiegata per la crittografia dello snapshot EBS, oppure è possibile specificare una chiave di crittografia differente.

Puoi acquisire snapshot point-in-time di volumi Volume Gateway disponibili sotto forma di snapshot Amazon EBS. Puoi anche usare gli snapshot del volume per creare un nuovo volume Amazon EBS da collegare a un'istanza Amazon EC2. In questo modo potrai fornire facilmente dati provenienti dalle applicazioni locali alle applicazioni in esecuzione in Amazon EC2, nel caso occorra ulteriore capacità di elaborazione on demand per l'elaborazione di dati o capacità sostitutiva a scopo di disaster recovery.

Per i volumi nella cache, i cui dati sono già memorizzati in Amazon S3, gli snapshot possono essere usati per conservare più versioni dei dati. In questo modo potrai ripristinarli a una versione precedente quando necessario o riutilizzare una versione point-in-time come un nuovo volume. Si possono avviare degli snapshot in modo programmato o secondo le esigenze. Quando viene acquisito un nuovo snapshot, vengono memorizzati solo i dati che hanno subito modifiche dall'ultimo snapshot. Se disponi di un volume con 100 GB di dati, ma ne hai modificati solo 5 GB dall'ultimo snapshot, verranno memorizzati in Amazon S3 solo questi 5 GB aggiuntivi. Quando elimini uno snapshot, vengono rimossi solo i dati che non sono necessari per altri snapshot.

Per i volumi nello storage i cui dati vengono memorizzati in locale, gli snapshot garantiscono un'opzione di backup durevole in remoto in Amazon S3. Nel caso in cui fosse necessario recuperare un backup, puoi creare un nuovo volume da uno snapshot. Puoi anche usare gli snapshot del volume per creare un nuovo volume Amazon EBS da collegare a un'istanza Amazon EC2.

Gli snapshot rappresentano copie point-in-time del volume acquisite nel momento in cui viene inoltrata la richiesta dello snapshot. Contengono tutte le informazioni necessarie per ripristinare i dati (al momento in cui lo snapshot è stato acquisito) in un nuovo volume. Saranno anche inclusi i dati scritti sul volume da un'applicazione prima dell'acquisizione dello snapshot, ma non ancora caricati in AWS.

In pratica, allo snapshot sarà assegnato un ID e sarà immediatamente visibile nella Console di gestione AWS e nell'interfaccia a riga di comando di AWS (AWS CLI), anche se inizialmente lo stato assegnato sarà PENDING. Quando tutti i dati scritti sul volume prima della richiesta di snapshot saranno caricati dal gateway in EBS, lo stato verrà modificato in AVAILABLE. A questo punto lo snapshot può essere utilizzato come base per un nuovo gateway o volume EBS.

Ogni snapshot riceve un identificatore univoco consultabile nella Console di gestione AWS. Puoi creare volumi di AWS Storage Gateway o di Amazon EBS partendo da qualsiasi snapshot specificando questo identificatore univoco.

Puoi creare un nuovo volume del da uno snapshot memorizzato in Amazon S3 tramite la Console di gestione AWS. Puoi anche montare il volume come dispositivo iSCSI al server di applicazioni locale.

Poiché i volumi nella cache memorizzano i dati più importanti in Amazon S3, quando crei un nuovo volume da uno snapshot, il gateway ne conserva i dati in Amazon S3, che diventerà sede dei dati più importanti del nuovo volume.

Poiché i volumi nello storage memorizzano i dati più importanti in locale, quando crei un nuovo volume da uno snapshot, il gateway ne scarica i dati sull'hardware locale. Questi diventano i dati più importanti del nuovo volume.

No, l'acquisizione di snapshot non richiede lo smontaggio dei volumi e non interferisce con le prestazioni dell'applicazione. Tuttavia, gli snapshot acquisiscono solo i dati scritti nel tuo volume di AWS Storage Gateway, che potrebbe escludere i dati salvati localmente nel buffer dalla tua applicazione o dal sistema operativo.

Sì, puoi creare una pianificazione per ognuno dei volumi di Puoi scegliere sia l'orario di acquisizione di uno snapshot sia la frequenza (ogni 1, 2, 4, 8, 12 o 24 ore).

Il tempo richiesto per completare uno snapshot dipende in larga parte delle dimensioni del volume e dalla velocità della connessione a Internet verso AWS. AWS Storage Gateway comprime i dati prima del caricamento per ridurre il tempo richiesto per l'acquisizione.

No; non puoi accedere agli snapshot direttamente con le API di Amazon S3, ma è necessario utilizzare AWS Storage Gateway o Amazon EBS.

Non è previsto alcun limite massimo al numero di snapshot o alla quantità di dati inclusa negli snapshot di un singolo gateway.

L'utilizzo di AWS Backup per eseguire il backup dei volumi del Gateway di volumi semplifica e centralizza la gestione del backup, riducendo così il carico operativo e rendendo più facile soddisfare i requisiti di conformità per tutte le risorse AWS. AWS Backup consente di impostare policy personalizzabili di backup programmato che soddisfano i requisiti per il backup. Utilizzando AWS Backup, è possibile impostare regole di conservazione e scadenza dei backup, per cui non è più necessario sviluppare script personalizzati né gestire manualmente backup point-in-time dei volumi del Gateway di volumi. Infine, è possibile gestire e monitorare backup su più Gateway di volumi, nonché altre risorse AWS come volumi EBS e database RDS, da una vista centralizzata.

AWS Backup può essere usato per eseguire un backup una tantum oppure per definire un programma di backup per i volumi del Gateway di volumi. I backup dei volumi sono archiviati in Simple Storage Service (Amazon S3) come snapshot Amazon EBS e sono visibili nella console AWS Backup o nella console Amazon EBS. I backup dei volumi creati da Backup AWS possono essere eliminati manualmente o automaticamente dalla console Backup AWS.

Per gestire i backup si può iniziare o dalla console Storage Gateway o dalla console AWS Backup. Se si inizia dalla console Storage Gateway, è possibile navigare alla console AWS Backup per completare la configurazione del piano di backup o per avviare un backup on-demand. In alternativa, è possibile iniziare dalla console AWS Backup per configurare il piano di backup o avviare un backup on-demand dei volumi del Gateway di volumi.

No. Tutte le funzionalità di snapshot del Gateway di volumi esistenti e gli snapshot Amazon EBS in essere restano disponibili e invariati. È possibile continuare a usare la console Storage Gateway per creare volumi dagli snapshot EBS e usare la console Amazon EBS per visualizzare o eliminare gli snapshot.

Sì. È possibile continuare a usare le funzionalità esistenti di snapshot del Gateway di volumi per creare snapshot Amazon EBS e utilizzare snapshot creati in precedenza a fini di ripristino. Il programma di backup di AWS Backup funziona in modo indipendente dagli snapshot programmati del Gateway di volumi e offre un modo addizionale per gestire centralmente tutte le policy di backup e conservazione.

Sì. AWS Backup esegue il backup dei volumi crittografati KMS di Volume Gateway con la stessa chiave utilizzata per la crittografia dei volumi.

AWS Backup supporta il backup di volumi di Volume Gateway all'interno della stessa regione in cui è in funzione AWS Backup.

Il Gateway di archiviazione AWS è disponibile come dispositivo hardware con il software Gateway di archiviazione preinstallato su un server con una configurazione convalidata. Il dispositivo può essere gestito dalla Console AWS.

L'appliance hardware supporta Amazon S3 File Gateway con interfacce NFS e SMB, Amazon FSx File Gateway con SMB, volumi archiviati nella cache di Volume Gateway con iSCSI e Tape Gateway con iSCSI-VTL.

Un dispositivo hardware semplifica notevolmente l'implementazione e la gestione di un Gateway di archiviazione AWS on-premises per gli ambienti IT quali filiali e dipartimenti che non dispongono di un'infrastruttura di server virtuale, risorse di disco e di memoria adeguate o personale con competenze di gestione di hypervisor. Elimina la necessità di procurarsi l'infrastruttura aggiuntiva necessaria per un ambiente virtuale per poter far funzionare il dispositivo VM di Storage Gateway locale.

Esistono due modelli che offrono 5 TB o 12 TB di cache SSD locale.

L'appliance hardware si basa su configurazioni server convalidate. Le specifiche sono reperibili nella pagina del prodotto Dispositivo hardware di gateway di archiviazione.

Il dispositivo hardware è supportato in 16 Regioni AWS tra cui Stati Uniti orientali (Virginia settentrionale, Ohio), Stati Uniti occidentali (California settentrionale, Oregon), Canada (Centrale), Sud America (San Paolo), Europa (Irlanda, Francoforte, Londra, Parigi, Stoccolma) e Asia Pacifico (Mumbai, Seoul, Singapore, Sydney, Tokyo).

Dopo aver ricevuto il dispositivo hardware, configura l'indirizzo IP tramite la console di hardware locale e usa tale indirizzo IP nella console del Gateway di archiviazione AWS per attivare il dispositivo. Tale operazione associa il dispositivo hardware con il tuo account AWS. Una volta attivato il dispositivo hardware, si crea il tipo di gateway desiderato da eseguire sul dispositivo hardware. Il tipo di gateway selezionato è quindi abilitato sul dispositivo. Puoi gestire e utilizzare il tuo dispositivo hardware Storage Gateway dalla Console AWS, in modo simile a come faresti con il dispositivo virtuale. Per ulteriori informazioni, consulta la documentazione sul dispositivo hardware.

No. Un dispositivo hardware può eseguire un solo gateway alla volta.

Sì. Per modificare il tipo di gateway quando è stato installato su un dispositivo hardware, si deve selezionare Remove Gateway dalla Console di Gateway di archiviazione, eliminando così il gateway e tutte le risorse associate. A questo punto, è possibile avviare un nuovo gateway sul dispositivo hardware.

È possibile aggiungere altro spazio di archiviazione al modello da 5 TB per aumentare la capacità di cache locale utilizzabile a 12 TB aggiungendo 5 SSD aggiuntivi al dispositivo. Se il dispositivo è già stata attivata e associata all'account AWS, prima di aggiungere ulteriore spazio di archiviazione occorre ripristinare le impostazioni di fabbrica.

No. Aggiungi solo le unità SSD disponibili presso il produttore del dispositivo. Questi SSD sono qualificati per l'utilizzo nel dispositivo hardware di Storage Gateway.

Sì. Il dispositivo hardware usa ZFS RAID basato su software e protegge dai guasti dell'unità di archiviazione. Il modello da 5 TB tollera il guasto di 1 SSD e il modello da 12 TB tollera il guasto di un massimo di 2 SSD.

Storage Gateway raggiunge una disponibilità elevata eseguendo una serie di controlli di stato continui contro l'operazione di connessione del gateway al servizio di monitoraggio VMware. Durante un errore relativo all'hardware, al software o alla rete, VMware indurrà un riavvio del gateway su un nuovo host o su un host già esistente, se è ancora operativo. Gli utenti e le applicazioni subiranno un downtime di un massimo di 60 secondi durante il riavvio. Dopo il riavvio, le connessioni al gateway vengono ristabilite automaticamente e senza bisogno di intervento manuale. Durante la reinizializzazione, il gateway invia di nuovo i parametri al cloud per fornire ai clienti una visione completa dell'evento di disponibilità.

Attualmente, la disponibilità elevata di Storage Gateway può essere abilitata in ambienti VMware vSphere clusterizzati dotati di VMware HA abilitato e archiviazione di volumi condivisi disponibile.

Non ci sono costi aggiuntivi per l'esecuzione di Storage Gateway con l'integrazione della disponibilità elevata abilitata.

Storage Gateway con VMware HA abilitato e il monitoraggio delle applicazioni configurato individuerà e sistemerà gli errori di hardware, di hypervisor e di rete, così come problemi di software che portano ai timeout di connessione o alla mancata disponibilità di condivisione di file e librerie di nastri virtuali o volumi.

Sì.

I client NFS che si connettono a File Gateway potrebbero rimanere bloccati per un massimo di 60 secondi durante un'operazione di lettura o scrittura quando il gateway si riavvia. Successivamente, se i clienti utilizzano le impostazioni di montaggio consigliate, l'operazione riparte. I client SMB potrebbero rifiutare la lettura o la scrittura di un file durante un riavvio in base alle impostazioni del cliente. Tutte le operazioni di lettura e scrittura iSCSI per i gateway di volumi e i gateway di nastri si bloccheranno durante il riavvio del gateway per poi ripartire automaticamente.

Sì, i gateway si rinizializzano utilizzando la stessa archiviazione condivisa di base, preservando la cache locale e le code di caricamento.

No, i gateway si reinizializzano utilizzando lo stesso spazio di archiviazione condiviso di base, preservando la cache locale e le code di caricamento.

Se il gateway viene distribuito a VMware con HA VMware abilitato, potrai configurare il riavvio del VM Storage Gateway nel centro di controllo VMware vSphere. Il funzionamento del VM Storage Gateway ti darà la possibilità di riavviare automaticamente il gateway in un timeout specifico.

VMware HA monitora le infrastrutture di base, come l'archiviazione e la rete. Storage Gateway fornisce un range di controlli di stato come la disponibilità del sistema dei file, la disponibilità dell'endpoint SMB e la disponibilità dell'endpoint NFS che monitora tutte le operazioni critiche del gateway, assicurandosi che tutto il servizio (non solo l'infrastruttura principale) sia sempre disponibile per i tuoi utenti e le tue applicazioni.

Sì. Storage Gateway High Availability può essere utilizzato su VMware Cloud senza requisiti aggiuntivi. VMware Cloud on AWS ha VMware HA abilitato come impostazione predefinita e i volumi condivisi sono disponibili.

Durante l'impostazione di un nuovo gateway per VMware, ti verrà data la possibilità di testare HA. Potrai anche testare se un gateway distribuito supporta HA scegliendo l'azione "Test VMware HA" nella console.

La console di AWS Storage Gateway mostrerà gli eventi di disponibilità in tabelle di log e interruzioni con grafici delle prestazioni durante il riavvio del gateway.

Sì. Se hai configurato l'integrazione con CloudWatch, gli eventi di disponibilità attivati dal gateway saranno disponibili tramite CloudWatch.

Se hai configurato l'integrazione con CloudWatch, un evento CloudWatch verrà attivato durate la rinizializzazione. Inoltre, i grafici delle prestazioni mostreranno i parametri operativi del gateway con il numero delle sessioni attive.

Sì. Gli amministratori possono impostare un timeout nella console vSphere che riattivi il servizio se il gateway non è raggiungibile per il numero di secondi specificato.

Tutti i dati trasferiti fra ogni genere di appliance gateway e l’archiviazione AWS sono crittografati con SSL. Per impostazione predefinita, tutti i dati memorizzati in S3 da AWS Storage Gateway vengono crittografati lato server con le chiavi di crittografia gestite di Amazon S3 (SSE-S3). Inoltre è possibile configurare diversi tipi di gateway per crittografare i dati archiviati con AWS Key Management Service (KMS) tramite l'API Storage Gateway. Consulta di seguito le specifiche sul supporto KMS per Gateway di file, Gateway di nastri virtuali e Gateway di volumi.

Sì. AWS Storage Gateway è conforme agli standard HIPAA. Se disponi di un Contratto di società in affari (BAA)con AWS, puoi utilizzare il Gateway di archiviazione per archiviare ed eseguire il backup di informazioni sanitarie protette sui servizi scalabili, sicuri e a costi contenuti per l'archiviazione di AWS, tra cui Simple Storage Service (Amazon S3), Amazon S3 Glacier, Amazon S3 Glacier Deep Archive, Amazon FSx per Windows File Server e Amazon EBS, anch'essi conformi agli standard HIPAA.

Le informazioni sui servizi AWS conformi agli standard HIPAA sono reperibili nella nostra pagina sullo Standard HIPAA; nella stessa pagina, puoi anche sottoscrivere un contratto BAA con AWS. L'idoneità agli standard HIPAA per Storage Gateway si applica a tutti i tipi di gateway (file, volumi e nastri).

Sì, AWS Storage Gateway è conforme allo standard PCI DSS (Payment Card Industry Data Security Standard) in base a valutazioni recenti. I clienti esistenti possono scaricare l'attestato di conformità (AOC) e i report di riepilogo delle responsabilità relativi allo standard PCI nella console di gestione AWS con AWS Artifact. I clienti potenziali possono richiedere i report tramite l'ufficio commerciale AWS.

Sì, AWS Storage Gateway è conforme a FedRAMP con un livello di autorizzazione High nelle regioni AWS GovCloud (Stati Uniti) e un livello di autorizzazione Moderate nelle regioni commerciali degli Stati Uniti di AWS. Ulteriori informazioni sono disponibili alla pagina della conformità FedRAMP di AWS.

S3 File Gateway, Amazon FSx File Gateway, Volume Gateway e Tape Gateway supportano endpoint conformi agli standard FIPS 140-2.

AWS Storage Gateway supporta endpoint conformi agli standard FIPS 140-2 nelle seguenti regioni AWS: Stati Uniti orientali (Virginia settentrionale), Stati Uniti orientali (Ohio), Stati Uniti occidentali (California settentrionale), Stati Uniti occidentali (Oregon), Canada (Centrale), GovCloud (Stati Uniti-Ovest) e GovCloud (Stati Uniti-Est).

Per un elenco degli endpoint FIPS disponibili per Gateway di archiviazione AWS, consulta la guida di riferimento agli endpoint di Gateway di archiviazione AWS oppure la guida per l'utente di AWS GovCloud (Stati Uniti).

No, l'appliance hardware di AWS Storage Gateway non è conforme agli standard FIPS 140-2.

Sì, i registri di verifica di File Gateway possono essere utilizzati per monitorare le operazioni client per cartelle e file all'interno di condivisioni file SMB.

È possibile configurare i registri di verifica di File Gateway per monitorare le operazioni degli utenti per cartelle e file a livello di condivisione per ogni condivisione SMB.

I registri di verifica di File Gateway supportano le condivisioni SMB.

Verranno visualizzati i dettagli sulle seguenti operazioni registrate per file e directory: apertura, eliminazione, lettura, scrittura, rinomina, modifica delle autorizzazioni e operazione sul file riuscita. Vengono registrate anche le informazioni dell'utente per ogni operazione, inclusi timestamp, dominio Active Directory, nome utente e indirizzo IP del client.

È possibile accedere ai registri di verifica di File Gateway in Amazon CloudWatch. I registri di verifica possono anche essere inviati da CloudWatch al bucket Amazon S3 di tua scelta. I registri di audit possono essere visualizzati da Amazon S3 utilizzando Amazon Athena e possono anche essere esportati in applicazioni SIEM (Security Information and Event Management) di terze parti per l'analisi all'interno di tali strumenti.

Sì, quando si creano manualmente nuovi nastri virtuali o si utilizza la configurazione per la creazione automatica dei nastri su Tape Gateway, è possibile selezionare il tipo di nastro WORM. I dati sui nastri virtuali WORM non possono essere cancellati intenzionalmente o accidentalmente dall'applicazione di backup. Inoltre, la funzionalità Tape Retention Lock di Tape Gateway impedisce l'eliminazione dei nastri virtuali archiviati per un determinato periodo di tempo, o anche indefinitamente.

Sì, è possibile utilizzare AWS Direct Connect per aumentare il throughput e ridurre i costi di rete creando una connessione di rete dedicata tra il gateway locale e AWS. Ti ricordiamo che AWS Storage Gateway impiega la larghezza di banda di Internet in modo efficiente per velocizzare il caricamento dei dati delle applicazioni locali su AWS.

Sì. Volume Gateway e Tape Gateway supportano la configurazione di un proxy Socket Secure version 5 (SOCKS5) tra il gateway locale e AWS. File Gateway supporta la configurazione di un proxy HyperText Transfer Protocol (HTTP).

Sì. È possibile distribuire uno Storage Gateway su una rete privata non instradabile se la rete è connessa ad Amazon VPC tramite DX o VPN. Il traffico Storage Gateway verrà instradato tramite AWS PrivateLink basato su endpoint VPC, una tecnologia che permette connessioni private tra servizi AWS con interfacce di rete elastiche (ENI) e IP privati in un cloud privato virtuale. Per ulteriori informazioni su PrivateLink, consulta la relativa documentazione. Per configurare AWS PrivateLink per Gateway di archiviazione, consulta la documentazione di AWS PrivateLink per Gateway di archiviazione.

Sì, il servizio supporta PrivateLink per tutti i tipi di gateway (file/volume/nastro).

Saranno fatturate le ore in cui l'endpoint VPC rimane assegnato. Si applicano inoltre tariffe di elaborazione dei dati per ogni gigabyte elaborato tramite l'endpoint VPC, indipendentemente dall'origine o dalla destinazione del traffico.

I gateway abilitati per PrivateLink possono essere attivati tramite la console AWS se il browser Web ha accesso sia ad Internet che alla rete privata, oppure tramite l’interfaccia a riga di comando nella regione in cui sono basati.

Per utilizzare File Gateway on-premise con PrivateLink e interfacce virtuali (VIF) private per accedere ai bucket Amazon S3, è necessario configurare un server proxy basato su Amazon EC2. Per poter accedere a Simple Storage Service (Amazon S3) tramite una rete privata, è necessario utilizzare gli endpoint dei gateway di S3 e questi endpoint non sono accessibili direttamente dagli ambienti in locale. Il server proxy fornirà l'accesso tramite l'endpoint VPC per S3, rendendolo accessibile a un File Gateway locale. Consigliamo di utilizzare una famiglia di istanze EC2 ottimizzata per la larghezza di banda di rete.

No.

I Volume Gateway e i Tape Gateway si collegano direttamente ai servizi AWS tramite l'endpoint VPC di Storage Gateway senza che sia necessario un proxy per S3.

Le interfacce di rete del dispositivo hardware devono essere in grado di comunicare con gli endpoint pubblici di AWS per un corretto funzionamento. Tuttavia, le interfacce virtuali della VM gateway possono essere configurate per utilizzare PrivateLink e comunicare solo con gli endpoint VPC.

L'AWS Storage Gateway si trova tra le tue applicazioni e i servizi di archiviazione di Amazon. Le prestazioni dipendono da quale piattaforma host (appliance hardware, macchina virtuale, istanza Amazon EC2) si utilizza per eseguire il software Storage Gateway e diversi altri fattori. Questi fattori includono la larghezza di banda tra l'iniziatore iSCSI o client NFS e il gateway, la velocità e la configurazione dei dischi locali, la configurazione della macchina virtuale, la quantità di storage locale allocata per il gateway e la larghezza di banda tra il gateway e lo storage di Amazon. Nella nostra documentazione tecnica troverai le istruzioni su come ottimizzare il tuo ambiente di Gateway di archiviazione AWS per potenziarne le prestazioni.

Per eseguire AWS Storage Gateway su una macchina virtuale o un’istanza Amazon EC2, consulta la sezione dei requisiti nella guida per l’utente di AWS Storage Gateway. Il Gateway di archiviazione AWS è inoltre disponibile come appliance hardware con specifiche prevalidate.

I Volume Gateway e i Tape Gateway comprimono i dati in transito e a riposo per ridurre le spese di archiviazione e di trasferimento dei dati. AWS Storage Gateway carica esclusivamente i dati che hanno subito modifiche, limitando la quantità di informazioni da inviare su Internet.

Sì, è possibile limitare la larghezza di banda di rete utilizzata dal gateway per sincronizzare i dati con AWS in base a una pianificazione per i gateway di volumi e di nastri. Per il traffico in entrata e in uscita è possibile specificare le tariffe in base al giorno della settimana, all'ora e alla larghezza di banda.

Per monitorare i parametri e gli allarmi sulle prestazioni del gateway è possibile usare Amazon CloudWatch, che consente di analizzare spazio di archiviazione, larghezza di banda, throughput e latenza. Questi parametri e allarmi sono accessibili direttamente tramite CloudWatch, oppure tramite i collegamenti nella console di AWS Storage Gateway, che reindirizzano direttamente ai parametri o agli allarmi CloudWatch delle risorse visualizzate. Consulta le pagine su dettagli e prezzi di CloudWatch per ulteriori informazioni.

Si possono usare i parametri di Amazon CloudWatch, fra cui CachePercentDirty, CacheHitPercent, CacheFree e CachePercentUsed. Queste informazioni possono essere visualizzate tramite il collegamento di monitoraggio nella scheda dei dettagli del gateway nella console di AWS Storage Gateway.

Si possono usare i parametri di Amazon CloudWatch, fra cui CloudBytesUploaded e CloudBytesDownloaded.

Puoi creare allarmi Amazon CloudWatch consigliati durante la creazione di un nuovo gateway o dopo la creazione di un nuovo gateway dalla console del Gateway di archiviazione AWS. Puoi inoltre creare degli allarmi per il tuo gateway nella console Amazon CloudWatch.

AWS Storage Gateway distribuisce regolarmente aggiornamenti importanti e patch di software alla macchina virtuale (VM) del tuo gateway. Puoi pianificare una manutenzione settimanale che consenta di controllare quando questi aggiornamenti possono essere applicati al gateway. In alternativa, puoi applicare gli aggiornamenti manualmente quando sono disponibili mediante la Console del Gateway di archiviazione AWS o l'API. Gli aggiornamenti richiedono pochi minuti. Per ulteriori informazioni, consulta la sezione Gestione degli aggiornamenti del gateway della nostra documentazione.

La fatturazione di AWS Storage Gateway si basa su 3 elementi: lo storage, le richieste e i trasferimenti di dati. Per ulteriori informazioni sulle tariffe, consulta la pagina dei prezzi del Gateway di archiviazione AWS.

I gateway di file memorizzano di dati direttamente in Amazon S3. Gli oggetti memorizzati e le richieste effettuate dal File Gateway ti vengono addebitate da Simple Storage Service (Amazon S3). Per ulteriori informazioni, consulta la pagina dei prezzi di Amazon S3.

La tariffa è basata sui volumi e sulla quantità di dati nel nastro virtuale memorizzati in AWS. Questa tariffa viene ripartita proporzionalmente su base giornaliera e varia secondo le regioni. Ti verrà fatturata solo la porzione di volume o di capacità del nastro virtuale utilizzata, non la capacità totale della risorsa. Tutti i dati dei volumi e dei nastri virtuali sono compressi prima di essere trasferiti su AWS dal gateway, per ridurre i costi di storage. Per ulteriori informazioni sulle tariffe, consulta la pagina dei prezzi del Gateway di archiviazione AWS.

Gli snapshot EBS effettuati dai volumi di AWS Storage Gateway vengono memorizzati e fatturati da Amazon EBS. Quando viene acquisito un nuovo snapshot, vengono memorizzati solo i dati che hanno subito modifiche rispetto allo snapshot precedente, in modo da ridurre i costi di storage. Per ulteriori informazioni, visita la pagina dei prezzi di Amazon EBS.

Quando il tuo gateway esegue operazioni in scrittura di dati su AWS, ti viene addebitata una tariffa fissa di 0,01 USD per GB di dati scritti su AWS fino a un massimo mensile di non oltre 125 USD per gateway. La lettura di dati da AWS non prevede alcun costo. Poiché il gateway effettua caching, ottimizzazione di larghezza di banda e la compressione, per Volume Gateway e Tape Gateway, la quantità di dati scritta su AWS può essere inferiore alla quantità di dati scritti sul gateway dalla tua applicazione. Puoi monitorare la quantità di dati scritti dal tuo gateway su AWS mediante i parametri Amazon CloudWatch forniti e puoi configurare i limiti di larghezza di banda sul tuo gateway per controllare i costi.

Per recuperare un nastro virtuale archiviato in S3 Glacier ti viene addebitata una tariffa fissa di 0,01 USD per GB di dati memorizzati sul nastro. Ad esempio, recuperare 5 nastri che contengono ciascuno 100 GB costerà 5 x 100 GB x 0,01 USD = 5,00 USD.

Se un nastro virtuale viene eliminato prima dello scadere dei tre mesi dall'archiviazione in S3 Glacier o prima dello scadere dei sei mesi dall'archiviazione in S3 Glacier Deep Archive, sarà applicata una tariffa di eliminazione anticipata. Se il nastro virtuale è stato archiviato per almeno tre mesi in S3 Glacier o per almeno sei mesi in S3 Glacier Deep Archive, non viene addebitato alcun costo.

Nella regione Stati Uniti orientali (Virginia settentrionale), verrebbe addebitata una tariffa di eliminazione anticipata ripartita proporzionalmente di 0,012 USD per GB eliminato entro tre mesi dal caricamento. Ad esempio, se elimini 1 nastro virtuale contenente 1 GB di dati 1 mese dopo averlo archiviato in S3 Glacier, ti sarà addebitata una tariffa di eliminazione anticipata di 0,008 USD. Se invece elimini quello stesso nastro virtuale dopo 2 mesi, la tariffa addebitata sarà di 0,004 USD.

Ai nastri virtuali archiviati in S3 Glacier Deep Archive viene addebitata la tariffa per la classe di storage S3 Glacier Deep Archive. Per informazioni sui prezzi del gateway di nastri virtuali, puoi visitare la pagina Web dei prezzi di gateway di archiviazione.

L’utilizzo e il relativo costo dei nastri virtuali archiviati nel Deep Archive Pool verranno indicati come un elemento a sé stante all’interno della fattura mensile di AWS sotto la categoria di AWS Storage Gateway Deep Archive, con una voce separata dai costi relativi ad AWS Storage Gateway. Tuttavia, se si utilizza lo strumento di gestione dei costi AWS, l'utilizzo e il costo dei nastri virtuali archiviati nel Deep Archive Pool saranno inclusi all’interno dei costi di AWS Storage Gateway nei report dettagliati delle spese mensili e non indicati come voce di un servizio separato.

Per la regione AWS Stati Uniti orientali (Virginia settentrionale), il costo dello spostamento di un nastro virtuale archiviato in S3 Glacier su S3 Glacier Deep Archive ammonta a 0,032 USD per GB di dati archiviati su tale nastro. Per esempio, spostare un nastro da 100 GB archiviato in S3 Glacier su S3 Glacier Deep Archive costerà: 100 GB x 0,032 USD/GB = 3,2 USD. Se sposti un nastro che è stato archiviato in S3 Glacier per meno di 90 giorni su S3 Glacier Deep Archivio, ti sarà anche addebitato un costo aggiuntivo per la cancellazione anticipata dello storage di un nastro in S3 Glacier.

Vengono fatturati i trasferimenti di dati Internet per ogni GB scaricato da AWS verso il gateway. I trasferimenti di dati in caricamento su AWS sono gratuiti.

La console di fatturazione e gestione costi AWS mostra una stima dell'utilizzo mensile di tutti i servizi, inclusi i volumi e i nastri virtuali di AWS Storage Gateway. Per un'analisi dettagliata dell'utilizzo di ogni singolo volume o nastro virtuale, usa la sezione Detailed Billing Report per visionare l'utilizzo di ciascuna risorsa su base giornaliera.

Pagherai per le richieste S3 effettuate mediante File Gateway per tuo conto allo scopo di archiviare e recuperare i file su S3 come oggetti. Il gateway esegue il caching dei dati fino a raggiungere la capacità dei dischi locali che gli assegni: ciò può contribuire a ridurre i costi legati al recupero dei dati.

Se configuri i registri di verifica di File Gateway, ti verranno addebitati i costi standard per Amazon CloudWatch Logs, Amazon CloudWatch Events e Amazon CloudWatch Metrics.

Il sistema di fatturazione si basa sul Tempo Coordinato Universale (UTC). Il mese di calendario inizia alla mezzanotte del primo giorno di ogni mese, secondo il fuso UTC.

Salvo diversamente specificato, i prezzi sono al netto di eventuali tasse e imposte doganali, inclusa l'IVA ed eventuali imposte sulle vendite. Per i clienti con indirizzo di fatturazione in Giappone, l'uso nella regione Asia Pacifico (Tokyo) è soggetto all'imposta giapponese sui consumi.

Sì, AWS Premium Support copre i problemi correlati all'utilizzo di AWS Storage Gateway. Consulta la pagina dei dettagli di del Supporto AWS Premium per ulteriori informazioni e per visionare i prezzi.

Puoi attingere alle enormi conoscenze offerte dalla nostra community AWS nel forum di discussione di Gateway di archiviazione AWS.

Occorre contattare il Supporto AWS, che fornisce il software di gateway di archiviazione AWS e il supporto del servizio. AWS Support coordina inoltre tutti i casi relativi all'hardware con il team di supporto del produttore dell'hardware. Ti consigliamo di acquistare il Supporto AWS Premium.

Il codice di matricola dell'appliance hardware si trova nella vista Hardware della console AWS Storage Gateway.

AWS Support collabora con il produttore dell'hardware per il supporto hardware. Il supporto hardware è incluso nell'acquisto del dispositivo e comprende 36 mesi di supporto telefonico 24 ore su 24, 7 giorni su 7, nonché il servizio in loco il giorno lavorativo successivo per la sostituzione delle parti.

L'appliance hardware è fornita dal produttore con 3 anni di garanzia, compreso il servizio in loco il giorno lavorativo successivo per la sostituzione delle parti. Puoi trovare le informazioni sulla garanzia qui.