Perguntas frequentes sobre o AWS Storage Gateway

O Amazon S3 File Gateway é uma configuração do serviço AWS Storage Gateway que fornece às aplicações uma interface de arquivo para armazenar facilmente arquivos como objetos no Amazon S3 e acessá-los usando protocolos de arquivo padrão do setor.

Os casos de uso do Amazon S3 File Gateway incluem: (a) migração de dados de arquivos on-premises para o Amazon S3, mantendo o acesso local rápido a dados acessados recentemente, (b) backup de dados de arquivos on-premises como objetos no Amazon S3 ( incluindo bancos de dados e logs do Microsoft SQL Server e Oracle), com a capacidade de usar recursos do S3, como gerenciamento de ciclo de vida e replicação entre regiões e, (c) fluxos de trabalho de nuvem híbrida usando dados gerados por aplicações on-premises para processamento por serviços da AWS, como machine learning, análise de big data ou funções sem servidor.

O Amazon S3 File Gateway permite que suas aplicações, dispositivos e fluxos de trabalho baseados em arquivos existentes usem o Amazon S3, sem modificação. O Amazon S3 File Gateway armazena de forma segura e durável o conteúdo do arquivo e metadados como objetos, fornecendo ao mesmo tempo às aplicações on-premises acesso de baixa latência aos dados armazenados em cache.

O Amazon S3 File Gateway é compatível com Amazon S3 Standard, S3 Intelligent-Tiering, S3 Standard - Infrequent Access (S3 Standard – IA) e S3 One Zone – IA. Para obter mais detalhes sobre as categorias de armazenamento, consulte a documentação do Amazon S3. Você configura a categoria de armazenamento inicial para objetos criados pelo gateway, bem como usar políticas de ciclo de vida do bucket para mover arquivos do Amazon S3 para o Amazon S3 Glacier. Se um aplicativo tentar acessar um arquivo/objeto armazenado pelo Amazon File Gateway que já está no Amazon S3 Glacier, você receberá um erro de E/S genérico.

O Amazon S3 File Gateway oferece suporte a clientes Linux que se conectam ao gateway usando o Network File System (NFS) versões 3 e 4.1 e oferece suporte a clientes Windows que se conectam ao gateway usando Server Message Block (SMB) versões 2 e 3.

É possível criar um compartilhamento de arquivos NFS ou SMB usando o Console de Gerenciamento da AWS ou a API de serviços e associar esse compartilhamento a um bucket novo ou já existente do Amazon S3. Para acessar o compartilhamento de arquivos, monte-o no aplicativo usando comandos padrão do UNIX ou do Windows. Por conveniência, exemplos de linhas de comando para cada ambiente são mostrados no console de gerenciamento.

Você pode configurar o compartilhamento de arquivos NFS com controles administrativos, como limitação do acesso a clientes ou redes NFS específicos, somente leitura ou leitura/gravação, ou a ativação de squashing de permissões de usuário.

Você pode configurar o compartilhamento de arquivos do SMB para acesso por usuários do Active Directory (AD) ou oferecer acesso de convidados autenticados aos usuários da organização. Também é possível limitar o acesso ao compartilhamento de arquivos como somente leitura ou leitura/gravação, ou a usuários e grupos específicos do AD.

Sim, é possível configurar enumeração baseada em acesso para seus compartilhamentos de arquivos SMB para evitar que usuários vejam pastas e arquivos que eles não poderiam abrir com base em suas permissões de acesso. Você também pode controlar se os usuários podem navegar nos compartilhamentos de arquivos no Amazon S3 File Gateway.

Sim. O Amazon S3 File Gateway é integrado ao Microsoft Active Directory on-premises, bem como às soluções do Active Directory na nuvem, como o Managed Microsoft AD.

Sim. Você pode exportar um compartilhamento de arquivos do SMB usando um nome de usuário e senha de usuário convidado. Será preciso alterar a senha padrão usando o console ou a API do serviço antes de configurar o compartilhamento de arquivos para acesso por usuários convidados.

Sim.

Não. No momento, não é possível mapear metadados de arquivos, como propriedade, armazenados como metadados de objetos do S3 entre protocolos diferentes.

O Amazon S3 File Gateway usa uma função do AWS Identity and Access Management (IAM) para acessar seu bucket do S3. Você mesmo pode configurar uma função do IAM ou optar pela configuração automática do console de gerenciamento do AWS Storage Gateway. Para a configuração automática, o AWS Storage Gateway cria uma nova função do IAM na sua conta e a associa a uma política de acesso do IAM para acessar o bucket do S3. A função do IAM e a política de acesso do IAM são criadas na sua conta e elas podem ser totalmente gerenciadas por você.

Para usar o compartilhamento de arquivos, monte-o na aplicação usando comandos padrão do UNIX ou do Windows. Por conveniência, exemplos de linhas de comando são mostrados no console de gerenciamento.

O compartilhamento de arquivos pode ser mapeado para a raiz do bucket do S3 ou para um prefixo do S3 dentro de um bucket do S3. Se você especificar um prefixo do S3 ao criar um compartilhamento de arquivos, estará vinculando-o ao prefixo do S3. Se você não criar um prefixo do S3 ao criar um compartilhamento de arquivos, ele será vinculado à raiz do bucket do S3.

Sim, o nome do compartilhamento de arquivos não precisa ser o mesmo que os nomes de buckets do S3 ou de prefixos do S3.

Sim, você pode alterar o nome do compartilhamento de arquivos.

Os arquivos são armazenados como objetos nos buckets do S3 e você pode configurar a categoria de armazenamento inicial para os objetos criados pelo gateway de arquivos. Existe um relacionamento de um para um entre arquivos e objetos e é possível configurar a categoria de armazenamento inicial para objetos criados pelo Amazon S3 File Gateway.

A chave de objeto é derivada do caminho de arquivo dentro do sistema de arquivos. Por exemplo, se você tiver um gateway com o nome de host file.amazon.com e tiver mapeado o my-bucket/my-prefix, o File Gateway exporá um ponto de montagem chamado file.amazon.com:/export/my-bucket/my-prefix. Se você montar esse ponto localmente em /mnt/my-bucket/my-prefix e criar um arquivo chamado file.html em um diretório /mnt/my-bucket/my-prefix/dir , esse arquivo será armazenado como um objeto no bucket my-bucket com uma chave de my-prefix/dir/file.html. A criação de arquivos dispersos resultará em um objeto não disperso preenchido com zeros no S3.

Os clientes podem criar, ler, atualizar e excluir arquivos e diretórios. Seus clientes também podem gerenciar permissões e a propriedade de arquivos e pastas. Os arquivos são armazenados como objetos individuais no Amazon S3. Os diretórios são gerenciados como objetos de pasta no S3, usando a mesma sintaxe do console do S3. Links simbólicos e hard links não têm suporte. Se você tentar criar um link, ocorrerá um erro. Operações comuns de arquivos alteram seus metadados, o que resulta na exclusão do objeto S3 atual e na criação de um novo objeto S3.

As operações de renomear parecerão atômicas para os clientes. No entanto, o S3 não permite renomear objetos. Quando você renomear um arquivo ou diretório, o gateway executará solicitações copy-put para criar uma cópia dos objetos no S3 com as novas chaves e excluir os objetos originais. Dessa forma, não é necessário enviar novamente arquivos grandes pela rede. Renomear diretórios contendo um grande número de arquivos não é instantâneo, resultará no armazenamento de duas cópias dos seus dados no S3, e as operações nos diretórios serão bloqueadas até que a operação de renomeação seja concluída.

Os clientes podem acessar metatados no estilo do POSIX, incluindo propriedade, permissões e time stamps armazenados com resiliência no S3 nos metadados do usuário do objeto associado ao arquivo. Quando você cria um compartilhamento de arquivos em um bucket existente, os metadados armazenados são restaurados e disponibilizados a seus clientes.

Para cada compartilhamento de arquivo, você pode habilitar a suposição de tipos MIME para os objetos carregados no momento da criação ou habilitar o recurso posteriormente. Se habilitado, o gateway de arquivos usará a extensão do nome do arquivo para determinar o tipo MIME do arquivo e definir o Content-Type do objeto do S3 de forma correspondente ao tipo determinado. Essa determinação será útil se você usar o File Gateway para gerenciar objetos no S3 acessados diretamente por meio de uma URL ou distribuídos por meio do Amazon CloudFront.

Sim. Depois que os objetos são armazenados no S3, você pode acessá-los diretamente na AWS para cargas de trabalho na nuvem sem exigir o Amazon S3 File Gateway. Os objetos herdam as propriedades do bucket do S3 em que são armazenados, como gerenciamento do ciclo de vida e replicação entre regiões.

Um objeto que precise ser acessado usando um compartilhamento de arquivos só deve ser gerenciado pelo gateway. Se você substituir ou atualizar diretamente um objeto gravado anteriormente pelo Amazon S3 File Gateway, isso resultará em um comportamento indefinido quando o objeto for acessado por meio do compartilhamento de arquivos.

Se o seu bucket já contiver objetos quando for configurado para uso com o Amazon S3 File Gateway, as chaves de objeto serão usadas para apresentar os objetos como arquivos aos clientes NFS e SMB. Os arquivos receberão metadados padrão do sistema de arquivos.

Para reduzir a latência e o número de solicitações do Amazon S3, o Amazon S3 File Gateway só verifica os cabeçalhos em busca de metadados de arquivo associados aos objetos quando você lista explicitamente os arquivos ou diretórios. Os metadados de arquivos são coletados como parte dessa verificação. O conteúdo do arquivo será obtido por download somente quando o objeto for lido.

O gateway não faz automaticamente download de objetos inteiros nem de todos os dados que existem em um bucket. Os dados só serão obtidos por download quando forem acessados explicitamente pelos clientes. Além disso, para reduzir a sobrecarga da transferência de dados, o gateway de arquivos usa carregamentos fracionados e copy put. Portanto, somente os dados alterados dos arquivos são carregados para o S3.

Para objetos carregados diretamente para o bucket do S3, ou seja, que não usam o gateway de arquivos e um compartilhamento do NFS, você pode configurar a propriedade e as permissões padrão.

Para objetos submetidos a upload diretamente para o bucket do S3, ou seja, sem usar o Amazon S3 File Gateway e um compartilhamento SMB, metadados como propriedade e permissões serão herdados da pasta pai do objeto. As permissões na raiz do compartilhamento são fixas e os objetos criados diretamente na pasta raiz herdarão essas permissões fixas. Consulte a documentação sobre definições de metadados de objetos criados fora do gateway.

É possível ter vários clientes NFS acessando um único gateway de arquivos. No entanto, como ocorre com qualquer servidor NFS, a modificação simultânea de vários clientes NFS pode resultar em um comportamento imprevisível. A coordenação no nível da aplicação é exigida para que isso seja feito de modo seguro.

Não. Recomendamos um único gravador para os objetos no bucket do S3. A substituição ou a atualização direta de um objeto anteriormente gravado pelo File Gateway resulta em um comportamento indefinido quando o objeto é acessado por meio do compartilhamento de arquivos. A modificação simultânea do mesmo objeto (ex.: por meio da API do S3 e do Amazon S3 File Gateway) pode gerar resultados imprevisíveis. Esta configuração não é recomendada.

Não recomendamos configurar vários gravadores em um único bucket, pois isso pode gerar resultados imprevisíveis. É possível aplicar nomes ou prefixos únicos de objeto por meio do fluxo de trabalho da aplicação. O S3 File Gateway emitirá notificações de integridade quando ocorrerem conflitos em tal configuração.

Sim, você pode ter vários leitores em um bucket gerenciado por meio de um Amazon S3 File Gateway. Você pode configurar um compartilhamento de arquivos como somente leitura e permitir que vários gateways leiam objetos do mesmo bucket. Além disso, você pode atualizar o inventário de objetos que seu gateway conhece usando o console do Storage Gateway, o processo automatizado de atualização periódica do cache ou a RefreshCache API.

No entanto, observe que se você não configurar um compartilhamento de arquivos como somente leitura, o Amazon S3 File Gateway não monitorará nem impedirá esses leitores de gravar acidentalmente no bucket. Cabe a você manter uma configuração de gravador único/multileitor do seu aplicativo.

Sim, você pode monitorar o uso do seu compartilhamento de arquivos usando métricas do Amazon CloudWatch e receber uma notificação após a conclusão das operações com arquivos por meio do CloudWatch Events. Para saber mais, acesse Monitoramento do compartilhamento de arquivos.

Quando você grava arquivos no compartilhamento de arquivos com o Amazon S3 File Gateway, primeiro os dados são armazenados localmente e depois carregados de forma assíncrona para o bucket do S3. É possível solicitar notificações por meio do AWS CloudWatch Events quando o upload de um arquivo individual for concluído. Essas notificações podem ser usadas para acionar fluxos de trabalho adicionais, como invocar uma função do AWS Lambda ou do Amazon EC2 Systems Manager Automation que dependam dos dados que foram disponibilizados no S3. Para saber mais, consulte a documentação sobre a notificação de upload de arquivo.

A notificação de upload de arquivo oferece uma notificação para cada arquivo individual que é carregado no Amazon S3 por meio do S3 File Gateway. As notificações de eventos do S3 oferecem avisos que incluem uploads parciais de arquivos, de forma que não é possível saber pela notificação de evento do S3 se o upload do arquivo foi concluído.

Quando você grava arquivos no compartilhamento de arquivos com o Amazon S3 File Gateway, primeiro os dados são armazenados localmente e depois carregados de forma assíncrona para o bucket do S3. É possível solicitar notificações por meio do Amazon CloudWatch Events quando o upload de um conjunto de arquivos de trabalho for concluído. Essas notificações podem ser usadas para acionar fluxos de trabalho adicionais, como invocar uma função do AWS Lambda ou do Amazon EC2 Systems Manager Automation que dependam dos dados que foram disponibilizados no S3. Para saber mais, consulte a documentação sobre a notificação de upload de conjunto de arquivos de trabalho.

Sim, você pode atualizar o inventário de objetos conhecidos pelo Amazon S3 File Gateway usando o console, o processo de renovação de cache impulsionado pelo sistema de arquivos ou a API RefreshCache. Você receberá notificações por meio do AWS CloudWatch Events quando a operação da API RefreshCache tiver sido concluída. Essas notificações podem ser usadas para enviar e-mails usando o Amazon SNS ou para acionar o processamento local usando os conteúdos atualizados. Para saber mais, consulte a documentação.

Sim, você pode usar o gateway para acesso entre contas aos buckets. Para saber mais, consulte a documentação para uso do compartilhamento de arquivos para acesso entre contas.

Sim, ao criar seu compartilhamento de arquivos, você pode habilitar o acesso aos buckets do S3 do Pagamento a cargo do solicitante. Como um solicitante, você incorrerá nas cobranças associadas ao acesso aos dados por buckets do Pagamento pelo solicitante.

Você pode criar vários compartilhamentos de arquivos para um único bucket do S3 especificando um prefixo do S3 durante o processo de criação do compartilhamento de arquivos.

Você pode criar até 50 compartilhamentos para um bucket do S3 em um único gateway. Não limitamos o número de compartilhamentos de arquivos por bucket em vários gateways, mas cada gateway é limitado a 50 compartilhamentos. No entanto, recomendamos ter um único gravador para o bucket, um Gateway de Arquivos do Amazon S3 ou um cliente acessando o S3 diretamente.

Sim, você pode alterar o nome de um compartilhamento de arquivos.

O tamanho máximo de um arquivo individual é de 5 TB, que é o tamanho máximo de um objeto individual no S3. Se você gravar um arquivo maior do que 5 TB, receberá a mensagem de erro "file too large" e apenas os primeiros 5 TB serão carregados.

O gateway retorna um número elevado (8 EB) como sua capacidade total. O Amazon S3 não limita o armazenamento total.

Sim. As políticas do bucket para gerenciamento do ciclo de vida, replicação entre regiões e notificação de eventos do S3 são aplicadas diretamente aos objetos armazenados no bucket por meio do AWS Storage Gateway.

É possível usar as políticas de ciclo de vida do S3 para alterar a camada de armazenamento de um objeto ou excluir versões de objetos ou objetos antigos. No caso de objetos excluídos pela política de ciclo de vida, você precisará habilitar o recurso de atualização periódica do cache ou chamar a RefreshCache API para refletir essas alterações em seus clientes NFS.

Ao usar um bucket do S3 que é o destino para replicação entre regiões, você pode precisar habilitar o recurso de atualização periódica do cache ou usar a API RefreshCache para garantir que o cache de gateway e bucket do S3 estejam sincronizados.

Se usar notificações de eventos do S3, você poderá receber eventos para arquivos parciais criados pelo gateway para garantir o armazenamento de dados com resiliência no S3. Arquivos parciais podem ocorrer por diversos motivos, como a necessidade de o gateway liberar espaço no cache ou uma alta taxa de gravações em um arquivo. Esses arquivos parciais podem não ser consistentes entre aplicativos.

O Amazon S3 File Gateway oferece suporte às versões 2 e 3 do SMB, bem como às versões 3, 4.0 e 4.1 do NFS. Estamos sempre realizando testes contínuos com aplicações de backup comuns. Entre em contato conosco pelo AWS Support ou por meio de sua conta da AWS com a equipe de quaisquer aplicações específicas para testar a compatibilidade.

Não. O Amazon S3 File Gateway permite que você armazene arquivos como objetos no S3.

Você pode usar o Amazon S3 File Gateway quando quiser acessar objetos no S3 como arquivos usando operações de sistema de arquivos padrão. O Amazon S3 File Gateway também fornece acesso local de baixa latência e transferência de dados eficiente. É possível usar a API do S3 quando a aplicação não exige operações de sistema de arquivos e pode gerenciar a transferência de dados diretamente.

O armazenamento de disco local no gateway é usado para manter temporariamente dados alterados que precisem ser transferidos para a AWS e para armazenar dados em cache localmente para obter acesso de leitura de baixa latência. O gateway de arquivos gerencia automaticamente o cache que mantém os dados acessados mais recentemente com base nas operações de leitura e gravação do cliente. Os dados só serão removidos do cache quando o espaço for necessário para armazenar os dados usados mais recentemente.

Para maximizar a performance de gravação, o gateway usa um mecanismo de write-back em que os dados são primeiramente persistidos no disco e, depois, carregados de modo assíncrono no S3. O gateway distribui os dados do cache local para maximizar a performance de leitura. Caso não estejam presentes, os dados são obtidos de modo síncrono e eficiente por meio do Amazon S3 usando obtenções com intervalo de bytes.

De modo geral, o cache local deve ser dimensionado para o conjunto de dados de trabalho que você precisa acessar com baixa latência. Se o cache for muito pequeno, as latências de leitura aumentarão, pois os dados solicitados deverão ser obtidos por meio do S3. Além disso, as leituras poderão falhar se não houver espaço livre no cache para armazenar dados no local com upload pendente no S3.

Você deve provisionar o cache com base em:
1. O tamanho do conjunto de dados de trabalho para o qual você precisa de acesso de baixa latência; portanto, você pode reduzir latências de leitura diminuindo a frequência com que os dados são solicitados do S3, e
2. O tamanho dos arquivos gravados no gateway pelos aplicativos.

Discos de cache menores podem resultar em baixa performance e falhas durante as gravações se não houver espaço de cache disponível para armazenar os dados localmente enquanto o upload para o S3 estiver pendente. Para saber mais sobre o monitoramento do uso do cache, consulte Monitoramento do compartilhamento de arquivos na documentação.

Os dados gravados no cache pelos aplicativos ou por meio da recuperação do Amazon S3 serão removidos do cache apenas quando houver necessidade de armazenar dados acessados mais recentemente.

Não. Os arquivos são mapeados para objetos individuais no bucket sem modificações, permitindo que você acesse dados diretamente no S3 sem a necessidade de usar o gateway ou implantar software adicional para atualizar os dados.

O Amazon S3 File Gateway usa carregamentos fracionados e copy put. Portanto, somente os dados alterados são carregados no S3, o que pode reduzir a transferência de dados. O gateway não faz download de objetos completos nem todos os dados que existem em um bucket automaticamente. Os dados só serão obtidos por download quando forem acessados explicitamente pelo cliente NFS.

O File Gateway não usará os endpoints acelerados, mesmo que o bucket esteja configurado para o S3 Transfer Acceleration.

Todos os dados transferidos entre o gateway e o armazenamento da AWS são criptografados usando SSL. Como padrão, todos os dados armazenados no S3 são criptografados no lado do servidor usando chaves de criptografia gerenciadas do Amazon S3 (SSE-S3). Como opção, para cada compartilhamento de arquivo, é possível definir uma configuração que criptografe objetos com chaves gerenciadas do AWS KMS usando o SSE-KMS. Para saber mais, consulte Como criptografar seus dados usando o AWS Key Management Service no guia do usuário do Storage Gateway, que inclui detalhes essenciais sobre o uso do recurso.  

O Amazon FSx File Gateway otimiza o acesso on-premises a compartilhamentos de arquivos do Windows no Amazon FSx, facilitando o acesso dos usuários ao FSx para dados do Servidor de Arquivos do Windows com baixa latência e conservando a largura de banda compartilhada. Os usuários se beneficiam de um cache local de dados usados com frequência que eles podem acessar, permitindo uma performance mais rápida e reduzindo o tráfego de transferência de dados. As operações do sistema de arquivos, como leitura e gravação de arquivos, são todas realizadas no cache local, enquanto o Amazon FSx File Gateway sincroniza os dados alterados no FSx for Windows File Server em segundo plano. Com esses recursos, você pode consolidar todos os seus dados de compartilhamento de arquivos on-premises na AWS no FSx for Windows File Server e se beneficiar de sistemas de arquivos protegidos, resilientes e totalmente gerenciados.

Muitas aplicações de desktop on-premises são sensíveis à latência, o que pode causar atrasos aos usuários finais e diminuir a performance quando eles acessarem arquivos diretamente na AWS de locais remotos. Além disso, permitir que um grande número de usuários acessem diretamente os dados na nuvem pode causar congestionamento em seus recursos de largura de banda compartilhada, como links do AWS Direct Connect. O Amazon FSx File Gateway permite que você use o Amazon FSx for Windows File Server para essas cargas de trabalho e ajuda a substituir seu armazenamento on-premises por armazenamento de arquivos totalmente gerenciado, escalável e altamente confiável na AWS sem afetar suas aplicações ou a rede.

O Amazon FSx File Gateway fornece um servidor de protocolo de arquivo SMB para os clientes se conectarem e um cache on-premises dos dados usados com frequência que eles podem acessar com a mesma baixa latência que teriam dentro da AWS. As operações do sistema de arquivos, como leitura e gravação de arquivos, são todas realizadas no cache local, enquanto o Amazon FSx File Gateway sincroniza os dados alterados no Amazon FSx for Windows File Server em segundo plano. O Amazon FSx File Gateway também ajuda a minimizar a quantidade de transferência de dados, ao mesmo tempo que otimiza o uso da largura de banda da rede para a AWS.

Para usar o Amazon FSx File Gateway, você precisa ter pelo menos um sistema de arquivos do Amazon FSx em execução e garantir que tenha acesso on-premises ao Amazon FSx for Windows File Server por meio de uma VPN ou de uma conexão do AWS Direct Connect. Para começar a usar o FSx for Windows File Server, consulte as instruções da documentação aqui. Em seguida, você começa fazendo download e implantando um dispositivo virtual do Amazon FSx File Gateway VMware ou um dispositivo de hardware do AWS Storage Gateway em seu ambiente on-premises. Depois que seu Amazon FSx File Gateway estiver instalado e você puder acessar o FSx for Windows File Server, você pode usar o Console de Gerenciamento da AWS para anexar um sistema de arquivos do FSx for Windows File Server. O Console de Gerenciamento da AWS guiará você por todas as etapas necessárias para tornar os compartilhamentos de arquivos acessíveis on-premises.

Depois que os compartilhamentos de arquivos são configurados, os sistemas clientes podem navegar e se conectar aos compartilhamentos de arquivos no Amazon FSx File Gateway que correspondem aos sistemas de arquivos selecionados do Amazon FSx. Quando os compartilhamentos de arquivos estão conectados, os usuários podem ler e gravar seus arquivos localmente, enquanto se beneficiam de todos os recursos disponíveis no FSx for Windows File Server. 

O Amazon FSx File Gateway pode ser usado para acessar os sistemas de arquivos do Windows em todas as regiões da AWS em que o FSx for Windows File Server é oferecido.

A cobrança pelo Amazon FSx File Gateway é feita por hora. Para obter informações sobre preços, visite a página de preços do AWS Storage Gateway.

O Amazon FSx File Gateway oferece suporte às versões 2.x e 3.x do protocolo Server Message Block (SMB). O SMB é compatível com os sistemas operacionais Microsoft Windows, MacOS e Linux.

O Amazon FSx File Gateway mapeia compartilhamentos de arquivos locais e seus respectivos conteúdos para compartilhamentos de arquivos armazenados remotamente no Amazon FSx for Windows File Server. Há uma correspondência individual entre os arquivos remotos e visíveis localmente e seus compartilhamentos.

Sim. Você pode acessar seus compartilhamentos de arquivos do Amazon FSx File Gateway, bem como diretamente do Amazon FSx na AWS; no entanto, você deve garantir que os arquivos só possam ser gravados em um único local por vez. Nesta versão, o Amazon FSx File Gateway não impedirá que gravações de vários locais se sobreponham de forma a criar conflitos.

Você pode gerenciar o Amazon FSx for Windows File Server por meio de uma interface de gerenciamento remoto usando todas as ferramentas fornecidas pelo FSx for Windows File Server.

Sim. Você tem permissão para anexar um gateway a compartilhamentos em até cinco sistemas de arquivos, desde que todos sejam membros do mesmo domínio do Active Directory. O Amazon FSx File Gateway unirá apenas um único domínio do Active Directory.

Você pode implantar uma máquina virtual contendo o software Amazon FSx File Gateway no VMware ESXi, no Microsoft Hyper-V ou no Linux KVM, ou pode implantar o Storage Gateway como um dispositivo de hardware.

O Amazon FSx File Gateway torna-se membro do domínio do Active Directory se a infraestrutura do AD estiver hospedada no AWS Directory Service ou se for gerenciada on-premises. Depois que o Amazon FSx File Gateway é membro do domínio, ele tem acesso a todos os usuários e políticas definidas nesse domínio para fins de segurança. O Amazon FSx File Gateway se comportará de forma idêntica a qualquer Windows Server e aplicará todas as políticas de acesso a arquivos relevantes com base no que está configurado no Active Directory. 

O Amazon FSx File Gateway usa controles de acesso nativos do Windows e é compatível com qualquer lista de acesso estática existente que funcione com o Microsoft Windows. O tamanho máximo de uma ACL é 64 KB ou aproximadamente 1820 entradas de controle de acesso. Isso é idêntico aos hosts do Windows Server. Os controles de acesso são definidos e armazenados no FSx for Windows File Server, portanto, você só precisa criá-los uma vez e eles serão aplicados a todos os File Gateways anexados.

Sim. O Amazon FSx File Gateway oferece suporte à criptografia SMB até a especificação SMB v3.1.1 mais recente, incluindo AES 128 CCM e AES 128 GCM. Os clientes compatíveis se conectarão usando criptografia automaticamente. Além disso, o Amazon FSx File Gateway usa criptografia SMB quando se comunica com o FSx for Windows File Server na AWS. Você deve configurar uma VPN ou uma comunicação com o Direct Connect para a AWS e definir políticas apropriadas para permitir que o tráfego SMB e o tráfego de gerenciamento passem para a AWS.

Assim como o Amazon S3 File Gateway, o Amazon FSx File Gateway obtém alta disponibilidade no VMware executando uma série de verificações de integridade contínuas na operação do gateway que se conecta ao serviço de monitoramento do VMware. Diante de uma falha de hardware, software ou rede, o VMware acionará a reinicialização do gateway em um novo host ou no host existente se este ainda estiver operando. Usuários e aplicativos terão, no máximo, até 60 segundos de inatividade durante uma reinicialização. Após uma reinicialização, as conexões com o gateway são automaticamente restabelecidas, sem a necessidade de intervenção manual. Na reinicialização, o gateway enviará métricas de volta à nuvem para oferecer aos clientes uma visão completa do evento de disponibilidade. 

O Amazon FSx File Gateway, com VMware de alta disponibilidade habilitado e monitoramento de aplicações configurado, detectará e se recuperará de falhas de hardware, falhas de hipervisor, falhas de rede, bem como problemas de software que levam a tempos limite de conexão ou indisponibilidade de compartilhamento de arquivos. 

O Amazon FSx File Gateway oferece suporte a até 50 compartilhamentos e 500 sessões de cliente ativas conectadas a instâncias do Amazon FSx File Gateway em uma configuração de instância única.

Você obtém praticamente 100% de durabilidade de dados, verificações regulares de estabilidade da AWS, criptografia de dados, dados corretos ao restaurar e redução de custos ao armazenar as fitas virtuais na AWS usando o Tape Gateway com S3 Glacier Deep Archive em comparação com o armazenamento de fitas físicas externas. Primeiro, todas as fitas virtuais armazenadas no S3 Glacier Deep Archive são replicadas e armazenadas em pelo menos três Zonas de disponibilidade distribuídas geograficamente, protegidas por praticamente 100% de durabilidade. Segundo, a AWS realiza verificações de estabilidade regularmente, a fim de confirmar se os dados podem ser lidos e se nenhum erro foi inserido. Terceiro, todas as fitas armazenadas no S3 Glacier Deep Archive são protegidas pela Server Side Encryption do S3 usando chaves padrão ou chaves KMS. Além disso, você também evita riscos de segurança física associados à portabilidade da fita. Quarto, em comparação com a experiência de armazenamento de fitas externas, na qual você pode receber uma fita incorreta ou quebrada durante a restauração, com o Tape Gateway, você sempre obtém os dados corretos. Por fim, você pode economizar nos custos mensais de armazenamento ao armazenar seus dados no S3 Glacier Deep Archive em comparação com o armazenamento de fitas externas.

O Tape Gateway é compatível com as categorias de armazenamento S3 Standard, S3 Glacier e S3 Glacier Deep Archive. Os dados das fitas virtuais são armazenados na biblioteca de fitas virtuais do Amazon S3 quando a aplicação de backup está gravando os dados nas fitas. Depois de ejetar as fitas do aplicativo de backup, elas serão arquivadas no S3 Glacier ou S3 Glacier Deep Archive.

Em um Gateway de Fitas, é possível criar fitas virtuais de, no mínimo, 100 GiB e de, no máximo, 15 TiB. Note que você paga apenas pela quantidade de dados armazenada em cada fita e não pelo tamanho da fita.

Um único Tape Gateway pode ter até 1.500 fitas virtuais na VTL, com uma capacidade agregada máximo de 1 PB. No entanto, não há limita para a quantidade de dados ou número de fitas virtuais que podem ser arquivados. Você também pode implantar Tape Gateways adicionais para escalar o armazenamento de fitas virtuais não arquivadas. Para obter mais informações, consulte nossa documentação sobre os limites do Storage Gateway.

Não há limites para a quantidade ou o tamanho das fitas virtuais que você pode arquivar.

É possível recuperar uma fita virtual arquivada no S3 Glacier ou no S3 Glacier Deep Archive para o S3. Uma fita arquivada no S3 Glacier é recuperada para o S3 usando o método de recuperação padrão, o que, geralmente, dura entre três e cinco horas. Uma fita arquivada no S3 Glacier Deep Archive é recuperada para o S3 usando o método de recuperação padrão, o que geralmente ocorre dentro de 12 horas.

A fita virtual que contém os dados deve ser armazenada em uma biblioteca de fitas virtuais antes de poder ser acessada. O acesso às fitas virtuais da biblioteca de fitas virtuais é instantâneo. Se a fita virtual que contém os dados estiver arquivada, será possível recuperá-la usando o Console de Gerenciamento da AWS ou API. Primeiro, selecione a fita virtual, depois escolha a biblioteca de fitas virtuais na qual deseja que a fita virtual seja carregada. O tempo de recuperação de fitas arquivadas para o S3 é normalmente de 3 a 5 horas para o S3 Glacier e de 12 horas para o S3 Glacier Deep Archive. Quando a fita virtual for disponibilizada na VTL, será possível usar a aplicação de backup para fazer uso da fita virtual para restaurar dados.

Não. Não é possível acessar dados de fitas virtuais usando as APIs do Amazon S3 ou do Amazon S3 Glacier. No entanto, é possível usar as APIs do Tape Gateway para gerenciar a biblioteca de fitas virtuais e a prateleira de fitas virtuais.

Ao criar novas fitas por meio do console ou do Storage Gateway ou via API, é possível definir o destino de armazenamento de arquivos para o S3 Glacier Deep Archive. Quando o software de backup ejeta as fitas, elas serão arquivadas no S3 Glacier Deep Archive. É possível recuperar uma fita virtual arquivada no S3 Glacier Deep Archive para o S3 usando o método de recuperação padrão, o que geralmente ocorre dentro de 12 horas.

Sim. O gateway de fitas é compatível com a movimentação de fitas do S3 Glacier para o S3 Glacier Deep Archive. Você pode atribuir a fita inserida no Glacier Pool ao Deep Archive Pool usando a API ou o console do AWS Storage Gateway. Em seguida, o Tape Gateway moverá a fita virtual para o Deep Archive Pool associado com a classe de armazenamento do S3 Glacier Deep Archive. Será cobrada uma taxa para movimentação da fita do S3 Glacier para o S3 Glacier Deep Archive, e, se aplicável, uma taxa de exclusão antecipada para o S3 Glacier, em caso de movimentação da fita do S3 Glacier para o S3 Glacier Deep Archive antes de 90 dias.

Não, não é possível mover uma fita do S3 Glacier Deep Archive para o S3 Glacier. Você pode recuperar uma fita do S3 Glacier Deep Archive para o S3 ou excluir uma fita do S3 Glacier Deep Archive.

A interface da VTL é compatível com aplicativos de backup e arquivamento que usam a interface de biblioteca de fitas baseada em iSCSI padrão do setor. Para obter uma lista completa das aplicações de backup compatíveis, consulte a página de visão geral do Storage Gateway.

Todos os dados transferidos entre o gateway e o armazenamento da AWS são criptografados usando SSL. Como padrão, todos os dados armazenados pelo gateway de fitas no S3 são criptografados no lado do servidor usando chaves de criptografia gerenciadas do Amazon S3 (SSE-S3).

Opcionalmente, você pode configurar a criptografia de fitas usando chaves gerenciadas do AWS KMS por meio da API do Storage Gateway. Você poderá especificar uma das Customer Master Keys (CMKs – Chaves mestre do cliente) como chave do KMS. A CMK configurada para criptografar uma fita não pode ser alterada após a criação. Para saber mais, consulte Como criptografar seus dados usando o AWS Key Management Service no guia do usuário do Storage Gateway, que inclui detalhes essenciais sobre o uso do recurso.

Cada Volume Gateway pode comportar até 32 volumes. No modo armazenado em cache, cada volume pode ter até 32 TB para um máximo de 1 PB de dados por gateway (32 volumes, cada um com 32 TB de tamanho). No modo armazenado, cada volume pode ter até 16 TB para um máximo de 512 TB de dados por gateway (32 volumes, cada um com 16 TB de tamanho). Para obter mais informações, consulte nossa documentação sobre os limites do Storage Gateway.

Os gateways de volumes compactam os dados antes de eles serem transferidos para a AWS e enquanto estiverem armazenados na AWS. Essa compactação pode reduzir as taxas de transferência e armazenamento de dados. O armazenamento de volume não é provisionado previamente. Será cobrada apenas a quantidade de dados armazenada no volume, não o tamanho do volume criado.

Os volumes são armazenados em um bucket do Amazon S3 mantido pelo serviço AWS Storage Gateway. Os volumes podem ser acessados para operações de E/S por meio do AWS Storage Gateway. Não é possível acessá-los diretamente usando as ações de API do Amazon S3. Você pode criar snapshots point-in-time dos volumes de gateway, que são disponibilizados no formato de snapshots do Amazon EBS e podem ser convertidos para volumes do Storage Gateway ou do EBS. Use o gateway de arquivos para trabalhar com os dados de modo nativo no S3.

Todos os dados transferidos entre o gateway e o armazenamento da AWS são criptografados usando SSL. Como padrão, todos os dados armazenados pelo Volume Gateway no S3 são criptografados no lado do servidor usando chaves de criptografia gerenciadas do Amazon S3 (SSE-S3).

Opcionalmente, você pode configurar a criptografia para dados armazenados na AWS em volumes usando as chaves gerenciadas do AWS KMS por meio da API do Storage Gateway. Você poderá especificar uma das Customer Master Keys (CMKs – Chaves mestre do cliente) como chave do KMS. A CMK configurada para criptografar um volume não pode ser alterada após a criação. Para saber mais, consulte Como criptografar seus dados usando o AWS Key Management Service no guia do usuário do Storage Gateway, que inclui detalhes essenciais sobre o uso do recurso.

Sim. Você pode criar um snapshot do EBS de um volume criptografado pelo KMS da AWS usando a API. O snapshot do EBS será criptografado usando a mesma chave usada para a criptografia de volumes.

Sim. Você pode criar um volume criptografado de um snapshot do EBS criptografado pelo KMS usando a API. O volume criptografado pode usar a mesma chave utilizada para criptografar o snapshot do EBS, ou você pode especificar uma chave de criptografia diferente para criptografar o volume.

Você pode criar snapshots point-in-time de volumes do Volume Gateway na forma de snapshots do Amazon EBS. Também é possível usar um snapshot do volume como o ponto inicial para um novo volume do Amazon EBS, que poderá ser então vinculado a uma instância do Amazon EC2. Com essa abordagem, é possível disponibilizar facilmente dados das aplicações locais para as aplicações em execução no Amazon EC2, caso seja necessária mais capacidade computacional sob demanda para processamento de dados ou capacidade de substituição para fins de recuperação de desastres.

Para volumes armazenados em cache, em que os dados de volume já estejam armazenados no Amazon S3, é possível usar snapshots para preservar versões dos seus dados. O uso dessa abordagem possibilita a reversão para uma versão anterior, quando necessário, ou a redefinição de uma versão point-in-time como um novo volume. É possível iniciar snapshots de acordo com a programação ou ad hoc. Ao criar um novo snapshot, apenas os dados alterados desde o último snapshot serão armazenados. Se você tiver um volume com 100 GB de dados, mas somente 5 GB de dados tiverem sido modificados desde o último snapshot, somente os 5 GB adicionais de dados serão armazenados no Amazon S3. Ao excluir um snapshot, somente os dados que não são necessários para qualquer outro snapshot são removidos.

Para os volumes armazenados, em que os dados de volume são armazenados localmente, os snapshots oferecem backups externos resilientes no Amazon S3. É possível criar um novo volume por meio de um snapshot, caso seja necessário recuperar um backup. Também é possível usar um snapshot do volume como o ponto inicial para um novo volume do Amazon EBS, que poderá ser então vinculado a uma instância do Amazon EC2.

Os snapshots representam uma cópia pontual do volume no momento em que o snapshot é solicitado. Eles contêm todas as informações necessárias para restaurar os dados (do momento em que o snapshot foi obtido) para um novo volume. Os dados gravados no volume pela aplicação antes de gerar o snapshot, mas ainda não carregados na AWS, serão incluídos no snapshot.

Em termos práticos, o snapshot receberá um ID e ficará visível imediatamente no Console de Gerenciamento da AWS e na AWS Command Line Interface (AWS CLI), mas inicialmente apresentará o status PENDING. Quando todos os dados gravados no volume antes da solicitação de snapshot tiverem sido carregados do gateway para o EBS, o status será alterado para AVAILABLE. Nesse momento, será possível usar o snapshot como base para um novo gateway ou volume do EBS.

Cada snapshot recebe um identificador único que pode ser visto usando o Console de Gerenciamento da AWS. É possível criar volumes do AWS Storage Gateway ou do Amazon EBS com base em qualquer um dos snapshots atuais, especificando esse identificador único.

Usando o Console de Gerenciamento da AWS, é possível criar um novo volume por meio de um snapshot armazenado no Amazon S3. Em seguida, será possível montar esse volume como um dispositivo iSCSI no servidor de aplicações local.

Como os volumes armazenados em cache armazenam os dados principais no Amazon S3, ao criar um novo volume de um snapshot, o gateway manterá os dados do snapshot no Amazon S3, onde se tornarão os dados principais do novo volume.

Como os volumes armazenados guardam os dados principais localmente, ao criar um novo volume de um snapshot, o gateway fará o download dos dados contidos no snapshot no hardware local. Lá, eles se tornarão os dados principais do novo volume.

Não, obter snapshots não exige que você desvincule os volumes, nem isso causa impacto no desempenho de seu aplicativo. No entanto, as snapshots capturam somente dados que foram redigidos para o volume do AWS Storage Gateway, o que poderá excluir quaisquer dados que foram localmente armazenados em memória temporária pelo aplicativo ou SO.

Sim. É possível criar uma programação de snapshots para cada um dos seus volumes. É possível modificar o horário de criação do snapshot a cada dia, bem como a frequência (a cada 1, 2, 4, 8, 12 ou 24 horas).

O tempo necessário para concluir um snapshot depende muito do tamanho do volume e da velocidade de sua conexão de Internet para a AWS. O AWS Storage Gateway compacta todos os dados antes do upload, reduzindo o tempo necessário para obter um snapshot.

Não. Os snapshots são acessíveis apenas por meio do AWS Storage Gateway e do Amazon EBS. Além disso, eles não podem ser acessados diretamente usando APIs do Amazon S3.

Não há limite para a quantidade de snapshots ou de dados de snapshot que um único gateway pode produzir.

O uso do AWS Backup para fazer backup de volumes do Volume Gateway simplifica e centraliza o gerenciamento de backups, reduzindo assim a carga operacional e facilitando o cumprimento de requisitos de conformidade em todos os seus recursos da AWS. O AWS Backup permite definir políticas de backup programadas personalizáveis que cumprem seus requisitos de backup. Usando o AWS Backup, você pode definir regras de retenção e expiração de backup, eliminando a necessidade de desenvolver scripts personalizados ou gerenciar manualmente os backups point-in-time dos volumes do Volume Gateway. Finalmente, você pode usar uma única visualização centralizada para gerenciar e monitorar backups em vários Volume Gateways e outros recursos da AWS, como volumes do EBS e bancos de dados RDS.

Você pode usar o AWS Backup para fazer um backup único ou definir uma programação de backup para volumes do Volume Gateway. Os backups de volume são armazenados no Amazon S3 como snapshots do Amazon EBS e são visíveis nos consoles do AWS Backup e do Amazon EBS. Os backups de volume criados pelo AWS Backup podem ser excluídos do console do AWS Backup manual ou automaticamente.

Você pode gerenciar os backups no console do Storage Gateway ou do AWS Backup. Se você usar o console do Storage Gateway, poderá navegar até o console do AWS Backup para concluir a configuração do plano de backup ou iniciar um backup sob demanda. Como alternativa, você usar o console do AWS Backup para configurar o plano de backup ou iniciar um backup de volumes do Volume Gateway sob demanda.

Não. Toda a funcionalidade de snapshots do Volume Gateway e todos os snapshots do Amazon EBS existentes continuam disponíveis e inalterados. Você pode continuar a usar o console do Storage Gateway para criar volumes de snapshots do EBS e o console do Amazon EBS para visualizar ou excluir snapshots.

Sim. Você pode continuar a usar os recursos de snapshot atuais do Volume Gateway para criar snapshots do Amazon EBS e usar snapshots criados anteriormente para fins de restauração. A programação de backup do AWS Backup opera independentemente dos snapshots programados do Volume Gateway e oferece uma maneira adicional de gerenciar centralmente todas as políticas de backup e retenção.

Sim. O AWS Backup faz backup de volumes criptografados pelo KMS no Volume Gateway com a mesma chave usada para a criptografia de volumes.

O AWS Backup oferece suporte ao backup de volumes do Volume Gateway na mesma região em que o AWS Backup opera.

O AWS Storage Gateway está disponível como um dispositivo de hardware com o software do Storage Gateway pré-instalado em um servidor com configuração validada. Você gerencia o dispositivo usando o Console da AWS.

O dispositivo de hardware oferece suporte ao Amazon S3 File Gateway com interfaces NFS e SMB, Amazon FSx File Gateway com SMB, volumes em cache do Volume Gateway com iSCSI e Tape Gateway com iSCSI-VTL.

O dispositivo de hardware simplifica ainda mais a implantação e o gerenciamento do AWS Storage Gateway on-premises para ambientes de TI como escritórios e departamentos remotos, que não contam com infraestrutura de servidores virtuais, recursos adequados de disco e memória ou equipe qualificada para o gerenciamento do hipervisor. Com o dispositivo, não é necessário comprar a infraestrutura adicional necessária para um ambiente virtual que comporte a operação do dispositivo de VM do Storage Gateway no local.

Existem dois modelos que oferecem 5 TB ou 12 TB de cache SSD local.

O dispositivo de hardware é baseado em configurações de servidor validadas. Consulte a página do produto do dispositivo de hardware do Storage Gateway para obter as especificações.

O dispositivo de hardware é compatível com 16 regiões da AWS, incluindo Leste dos EUA (Norte da Virgínia, Ohio), Oeste dos EUA (Norte da Califórnia, Oregon), Canadá (Central), América do Sul (São Paulo), Europa (Irlanda, Frankfurt, Londres, Paris, Stockholm) e Ásia-Pacífico (Mumbai, Seul, Singapura, Sydney, Tóquio).

Você configura um endereço IP por meio do console do dispositivo de hardware local e usa esse endereço IP no console do AWS Storage Gateway para ativar o dispositivo. Essa ativação associa o dispositivo de hardware à sua conta da AWS. Depois que o dispositivo de hardware é ativado, você cria o tipo de gateway desejado para ser executado no dispositivo de hardware. O tipo de gateway selecionado é habilitado no dispositivo. Você gerencia e usa seu dispositivo de hardware Storage Gateway a partir do Console da AWS, da mesma forma que faria com o dispositivo virtual. Para obter mais informações, consulte a documentação do dispositivo de hardware.

Não. O dispositivo de hardware oferece suporte à execução de um gateway por vez.

Sim. Para alterar o tipo de gateway após a instalação em um dispositivo de hardware, selecione Remove Gateway no console do Storage Gateway para excluir o gateway e todos os recursos associados. Nesse momento, você pode executar um novo gateway no dispositivo de hardware.

Você pode adicionar mais armazenamento ao modelo de 5 TB para aumentar a capacidade de cache local utilizável para 12 TB adicionando 5 SSDs adicionais ao dispositivo. Se você já ativou o dispositivo e o associou à sua conta da AWS, precisará restaurar as configurações de fábrica do dispositivo antes de adicionar o armazenamento.

Não. Adicione somente os SSDs que forem disponibilizados pelo fabricante do dispositivo. Esses SSDs são qualificados para uso no dispositivo de hardware do Storage Gateway.

Sim. O dispositivo de hardware usa RAID ZFS baseado em software e oferece proteção contra falhas da unidade de armazenamento. O modelo de 5 TB tolera a falha de 1 SSD e o modelo de 12 TB tolera a falha de até 2 SSDs.

O Storage Gateway obtém alta disponibilidade executando uma série de verificações de integridade contínuas na operação do gateway que se conectam ao serviço de monitoramento do VMware. Diante de uma falha de hardware, software ou rede, o VMware acionará a reinicialização do gateway em um novo host ou no host existente se este ainda estiver operando. Usuários e aplicativos terão, no máximo, até 60 segundos de inatividade durante uma reinicialização. Após uma reinicialização, as conexões com o gateway são automaticamente restabelecidas, sem a necessidade de intervenção manual. Na reinicialização, o gateway enviará métricas de volta à nuvem para oferecer aos clientes uma visão completa do evento de disponibilidade.

No momento, a alta disponibilidade do Storage Gateway pode ser ativada em ambientes do VMware vSphere em cluster que tenham o HA do VMware ativado e um armazenamento de volume compartilhado disponível.

Não há custo adicional para executar o Storage Gateway com a integração de alta disponibilidade ativada.

Com o HA do VMware habilitado e o monitoramento de aplicações configurado, o Storage Gateway irá detectar e solucionar o panorama oriundo de falhas de hardware, falhas de hipervisor, falhas de rede e problemas de software que levam a tempos limite de conexão ou indisponibilidade de compartilhamento de arquivos, volume ou biblioteca virtual de fitas.

Sim.

Os clientes NFS conectados a File Gateways podem esperar até 60 segundos em uma operação de leitura ou gravação enquanto o gateway reinicia e, em seguida, tentar novamente, desde que os clientes usem as configurações de montagem recomendadas. Dependendo das configurações de clientes, pode ser que clientes SMB rejeitem uma leitura ou gravação de arquivo durante uma reinicialização. Todas as leituras e gravações do iSCSI para o Volume Gateway e Tape Gateway irão aguardar durante reinicializações de gateway. Em seguida, novas tentativas serão automaticamente feitas.

Sim, os gateways serão reinicializados usando o mesmo armazenamento compartilhado subjacente, preservando o cache local e as filas de upload

Não, os gateways serão reinicializados usando o mesmo armazenamento compartilhado subjacente, preservando o cache local e as filas de upload.

Se o gateway for implantado no VMware com o HA do VMware ativado, você poderá configurar a sensibilidade de reinicialização do VM do Storage Gateway no centro de controle do VMware vSphere. As frequências do VM do Storage Gateway estarão disponíveis, permitindo que você reinicie automaticamente o gateway em um tempo limite específico.

O HA do VMware monitora a infraestrutura subjacente, como armazenamento e rede. O Storage Gateway fornece uma variedade de verificações de integridade, como disponibilidade do sistema de arquivos, disponibilidade de endpoints SMB e disponibilidade de endpoints NFS que monitoram todas as operações críticas do gateway, garantindo que todo o serviço e não apenas a infraestrutura subjacente estejam continuamente disponíveis para seus usuários e aplicações..

Sim. A alta disponibilidade do Storage Gateway pode ser usada no VMware Cloud sem nenhuma exigência adicional. O VMware Cloud on AWS possui um HA do VMware habilitado por padrão e os volumes compartilhados estão disponíveis.

Ao configurar um novo gateway para o VMware, você terá a opção de testar o HA. Você também pode testar se um gateway implantado é compatível com HA, escolhendo a ação "Testar o HA do VMware" no console.

O console do AWS Storage Gateway exibirá eventos de disponibilidade em tabelas de log e interrupções nos gráficos de performance durante as reinicializações do gateway.

Sim, se você tiver configurado a integração com o CloudWatch, os eventos de disponibilidade acionados no gateway ficarão disponíveis no CloudWatch.

Se você tiver configurado a integração com o CloudWatch, os eventos do CloudWatch serão acionados na reinicialização. Além disso, os gráficos de performance vão exibir as métricas operacionais do gateway, incluindo o número de sessões ativas.

Sim, administradores serão capazes de definir um tempo limite no console do vSphere que poderá acionar a reinicialização do serviço caso o gateway não esteja acessível por um determinado número de segundos.

Todos os dados transferidos entre qualquer tipo de dispositivo de gateway e o armazenamento da AWS são criptografados usando SSL. Como padrão, todos os dados armazenados pelo AWS Storage Gateway no S3 são criptografados no lado do servidor usando chaves de criptografia gerenciadas pelo Amazon S3 (SSE-S3). Além disso, você pode opcionalmente configurar vários tipos de gateway para criptografar dados armazenados com o AWS Key Management Service (KMS) por meio da API do Storage Gateway. Veja a seguir informações específicas sobre o suporte ao KMS oferecido pelos serviços de File Gateway, Tape Gateway e Volume Gateway.

Sim. O AWS Storage Gateway está qualificado pela HIPAA. Se você tiver um acordo de associação comercial (BAA) com a AWS, poderá usar o Storage Gateway para armazenar, fazer backup e arquivar informações de integridade protegidas (PHIs) em serviços de armazenamento da AWS seguros, escaláveis e econômicos, incluindo o Amazon S3, Amazon S3 Glacier, Amazon S3 Glacier Deep Archive, Amazon FSx for Windows File Server e Amazon EBS, que também estão qualificados pela HIPAA.

As informações sobre os produtos da AWS qualificados pela HIPAA podem ser encontradas em nossa página de conformidade com a HIPAA. Você pode inserir um BAA com a AWS nessa página. A qualificação da HIPAA para o Storage Gateway se aplica a todos os tipos de gateway (arquivos, volumes e fitas).

Sim. De acordo com avaliações recentes, o AWS Storage Gateway está em conformidade com o Payment Card Industry Data Security Standard (PCI DSS). Os clientes atuais podem baixar os relatórios atestado de conformidade (AOC) e resumo de responsabilidades do PCI no Console de Gerenciamento da AWS pelo AWS Artifact. Os clientes em potencial podem solicitar os relatórios trabalhando com a equipe de vendas da AWS.

Sim, o AWS Storage Gateway está em conformidade com o FedRAMP com nível de autorização alto nas regiões AWS GovCloud (EUA) e nível de autorização moderado nas regiões comerciais dos EUA. Para obter mais informações, acesse a página de conformidade do AWS FedRAMP.

O S3 File Gateway, o Amazon FSx File Gateway, o Volume Gateway e o Tape Gateway oferecem suporte a endpoints compatíveis com FIPS 140-2.

O AWS Storage Gateway suporta endpoints compatíveis com o FIPS 140-2 nas seguintes regiões da AWS: Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Norte da Califórnia), Oeste dos EUA (Oregon), Canadá (Central), GovCloud (EUA-Oeste) e GovCloud (EUA-Leste).

Para obter uma lista dos endpoints FIPS disponíveis para o AWS Storage Gateway, consulte o guia de referência de endpoints do AWS Storage Gateway ou o guia do usuário do AWS GovCloud (EUA).

Não, o AWS Storage Gateway Hardware Appliance não é compatível com FIPS 140-2.

Sim, os logs de auditoria do gateway de arquivos podem ser usados para monitorar operações de clientes em pastas e arquivos dentro de compartilhamentos de arquivos do SMB.

Você pode configurar os logs de auditoria do gateway de arquivos para monitorar operações de usuários em pastas e arquivos por compartilhamento do SMB.

Os logs de auditoria do gateway de arquivos são compatíveis com compartilhamentos do SMB.

Você pode ver detalhes sobre as seguintes operações, registradas em arquivos e diretórios: abrir, excluir, ler, gravar, renomear, alterar permissões e operações de arquivo bem-sucedidas. Informações de usuário para cada operação, incluindo time stamp, domínio do Active Directory, nome do usuário e endereço IP do cliente, também são registradas nos logs.

Você pode acessar os logs de auditoria do gateway de arquivos no Amazon CloudWatch. Os logs de auditoria podem ser enviados do CloudWatch para um bucket do Amazon S3 à sua escolha. Os logs de auditoria podem ser visualizados do Amazon S3 usando o Amazon Athena. Além disso, eles podem ser exportados para aplicações de Security Information and Event Management (SIEM – Gerenciamento de informações e eventos de segurança) para análises nessas ferramentas.

Sim, ao criar novas fitas virtuais manualmente ou usar a configuração de criação automática de fita no Tape Gateway, é possível selecionar o tipo de fita WORM. Os dados nas fitas virtuais WORM não podem ser apagados intencional ou acidentalmente da aplicação de backup. Além disso, o recurso de bloqueio de retenção de fita do Tape Gateway evita que fitas virtuais arquivadas sejam excluídas por um período definido de tempo ou até mesmo indefinidamente.

Sim. Você também pode usar o AWS Direct Connect para aumentar a taxa de transferência e reduzir os custos de rede ao estabelecer uma conexão de rede dedicada entre o gateway on-premises e a AWS. O AWS Storage Gateway usa com eficiência a largura de banda da Internet para ajudar a acelerar o upload dos dados de aplicações on-premises para a AWS.

Sim. Os gateways de volumes e fitas oferecem suporte à configuração de um proxy Socket Secure versão 5 (SOCKS5) entre o gateway on-premises e a AWS. Os gateways de arquivos oferecem suporte à configuração de um proxy HyperText Transfer Protocol (HTTP).

Sim. Sim. Você poderá implantar um Storage Gateway em uma rede privada não roteável se essa rede estiver conectada à Amazon VPC por meio de DX ou VPN. O tráfego do Storage Gateway será roteado por VPC endpoints baseados no AWS PrivateLink, uma tecnologia que habilita a conectividade privada entre serviços da AWS usando interfaces de rede elástica (ENI) com IPs privados nas VPCs. Para saber mais sobre o PrivateLink, acesse a documentação do PrivateLink. Para configurar o AWS PrivateLink para o Storage Gateway, consulte a documentação do AWS PrivateLink para Storage Gateway.

Sim. O serviço oferece suporte ao PrivateLink para todos os tipos de gateway (arquivo, volume e fita).

Você será cobrado por hora de provisionamento do endpoint da VPC. As cobranças de processamento de dados também são aplicadas a cada gigabyte processado pelo endpoint da VPC, independentemente da origem ou do destino do tráfego.

Os gateways habilitados pelo PrivateLink poderão ser ativados pelo Console AWS se o navegador da web tiver acesso à Internet e à rede privada, ou pela ILC na região em que estão baseados.

Para usar o gateway de arquivos on-premises com o PrivateLink e interfaces virtuais privadas (VIFs) para acessar buckets do Amazon S3, será necessário configurar um servidor de proxy baseado no Amazon EC2. Para acessar o Amazon S3 por uma rede privada, será necessário usar endpoints de gateway do S3. Esses endpoints não podem ser acessados diretamente de ambientes on-premises. O servidor de proxy oferecerá acesso ao S3 por meio do VPC endpoint, que poderá ser acessado por um gateway de arquivos no local. Recomendamos usar uma família de instâncias do EC2 otimizada para largura de banda de rede.

Não.

Os gateways de volumes e fitas conectam-se diretamente a serviços da AWS por meio do VPC endpoint do Storage Gateway, sem necessidade de um proxy para o S3.

As interfaces de rede do dispositivo de hardware devem ser capazes de se comunicar com os endpoints públicos da AWS para uma operação adequada. No entanto, as interfaces virtuais da VM do gateway podem ser configuradas para usar o PrivateLink e se comunicar somente com endpoints da VPC.

O AWS Storage Gateway fica entre as aplicações e os serviços de armazenamento da Amazon. A performance experimentada depende da plataforma do host (dispositivo de hardware, máquina virtual, instância do Amazon EC2) usada para executar o software do Storage Gateway e de vários outros fatores. Eles incluem a largura de banda entre o iniciador iSCSI ou o cliente e o gateway do NFS, a velocidade e a configuração dos discos locais subjacentes, a configuração da VM, a quantidade alocada de armazenamento local para o gateway e a largura de banda entre o gateway e o armazenamento da Amazon. Nossa documentação técnica oferece instruções sobre como otimizar o ambiente do AWS Storage Gateway para obter uma melhor performance.

Para executar o AWS Storage Gateway em uma máquina virtual ou em uma instância do Amazon EC2, consulte a seção de requisitos do Guia do usuário do AWS Storage Gateway. O AWS Storage Gateway também está disponível como um dispositivo de hardware com especificações pré-validadas.

Os gateways de volumes e fitas executam a compactação de dados em trânsito e ociosos, o que pode reduzir as cobranças de transferência e armazenamento de dados. O AWS Storage Gateway faz o upload apenas dos dados que foram alterados, minimizando a quantidade de dados enviada pela Internet.

Sim, é possível controlar a utilização da largura de banda de rede que o gateway usa para sincronizar dados com a AWS com base em um cronograma para volume e Tape Gateways. Você pode especificar o dia da semana, hora e taxas de largura de banda para tráfego de entrada e saída.

Você pode usar o Amazon CloudWatch para monitorar as métricas de performance e alarmes do seu gateway e obter insights sobre armazenamento, largura de banda, taxa de transferência e latência. Essas métricas e alarmes são acessíveis diretamente do CloudWatch ou seguindo os links no console do AWS Storage Gateway, que o levam diretamente para as métricas e alarmes do CloudWatch para o recurso que está sendo visualizado. Consulte as páginas de detalhes e definição de preço do CloudWatch para obter informações adicionais.

É possível fazer isso usando as métricas do Amazon CloudWatch, como CachePercentDirty, CacheHitPercent, CacheFree e CachePercentUsed. Essas podem ser visualizadas seguindo o link Monitoramento na guia de detalhes do gateway no Console do AWS Storage Gateway.

É possível fazer isso usando as métricas do Amazon CloudWatch, como CloudBytesUploaded e CloudBytesDownloaded.

Você pode criar alarmes recomendados do Amazon CloudWatch ao criar um novo gateway ou após a criação de um novo gateway pelo console do AWS Storage Gateway. Você também pode criar alarmes para o gateway no console do Amazon CloudWatch.

O AWS Storage Gateway implanta periodicamente atualizações importantes e patches de software à máquina virtual do gateway. É possível configurar uma programação de manutenção semanal, o que permite o controle de quando essas atualizações serão aplicadas ao gateway. Como opção, também é possível aplicar atualizações manualmente quando forem disponibilizadas usando o console ou a API do AWS Storage Gateway. As atualizações devem levar somente alguns minutos para concluir. Para obter mais informações, acesse a seção Como Gerenciar Atualizações de Gateway na nossa documentação.

Existem 3 elementos que serão faturados no AWS Storage Gateway: armazenamento, solicitações e transferência de dados. Para obter informações detalhadas sobre a definição de preço, acesse a página de definição de preço do AWS Storage Gateway.

Os gateways de arquivos armazenam dados diretamente no Amazon S3. O Amazon S3 cobrará os objetos armazenados e as solicitações feitas pelo gateway de arquivos. Para obter mais informações, acesse a página de definição de preço do Amazon S3.

A cobrança será feita pela quantidade de dados de volume e fitas virtuais armazenados na AWS. Essa taxa terá um valor pro rata diário e os preços variam por região. Será cobrada apenas a parcela da capacidade de volume ou fita virtual utilizada, não o tamanho provisionado do recurso. Todos os dados de volume e fita virtual serão compactados antes de serem transferidos para a AWS pelo gateway, o que pode reduzir as cobranças de armazenamento. Para obter informações detalhadas sobre a definição de preço, acesse a página de definição de preço do AWS Storage Gateway.

O snapshots do EBS criados por meio dos volumes do Storage Gateway serão armazenados e cobrados pelo Amazon EBS. Ao criar um novo snapshot, apenas os dados alterados desde o último snapshot serão armazenados para reduzir as cobranças de armazenamento. Para obter mais informações, acesse a página de definição de preço do Amazon EBS.

Quando o gateway gravar dados na AWS, a cobrança será feita a uma taxa fixa de 0,01 USD por GB de dados gravados na AWS e pode atingir um máximo mensal de 125 USD por gateway. A leitura de dados por meio da AWS não é cobrada. Como o gateway executa o armazenamento em cache, a otimização da largura de banda (e, para gateways de volumes e fitas, a compactação), a quantidade de dados gravada na AWS pode ser menor do que a quantidade de dados gravada no gateway pelo aplicativo. É possível monitorar a quantidade de dados gravada pelo gateway na AWS usando as métricas disponibilizadas pelo Amazon CloudWatch. Além disso, você pode configurar limites de largura de banda no gateway para gerenciar custos.

A cobrança será feita durante a recuperação de um fita virtual arquivada no S3 Glacier a uma taxa fixa de 0,01 USD por GB de dados armazenados na fita. Por exemplo, a recuperação de 5 fitas contendo 100 GB cada uma custaria 5 x 100 GB x 0,01 USD = 5 USD.

Se uma fita virtual for excluída dentro de três meses após o arquivamento no S3 Glacier ou dentro de seis meses de arquivamento do S3 Glacier Deep Archive, será cobrada uma taxa de exclusão antecipada. Se a fita virtual tiver sido armazenada por três meses ou mais no S3 Glacier ou por seis meses ou mais no S3 Glacier Deep Archive, não haverá cobrança pela exclusão.

Na região Leste dos EUA (Norte da Virgínia), será cobrada uma taxa de exclusão antecipada pro rata de USD 0,012 por GB excluído antes do período de três meses. Por exemplo, se você excluir uma fita virtual contendo 1 GB de dados um mês após fazer o upload do arquivamento no S3 Glacier, será cobrada uma taxa de USD 0,008 por exclusão antecipada. Se, em vez disso, você excluir a mesma fita virtual após dois meses, será cobrada uma taxa de exclusão antecipada de USD 0,004.

As fitas virtuais armazenadas no S3 Glacier Deep Archive serão cobradas com a taxa da categoria de armazenamento do S3 Glacier Deep Archive. Você pode visitar a página de definição de preço do Storage Gateway para verificar a definição de preço do gateway de fitas.

O uso e o custo das fitas virtuais armazenadas no Deep Archive Pool aparecerão como um item de linha de serviço independente em sua fatura mensal da AWS com o nome AWS Storage Gateway Deep Archive, separado do AWS Storage Gateway e custos. No entanto, se você estiver usando a ferramenta de Gerenciamento de custos da AWS, o uso e o custo das fitas virtuais armazenadas no Deep Archive Pool serão incluídos no AWS Storage Gateway em seus relatórios detalhados de gastos mensais, e não divididos como um item de linha de serviço separado.

No Leste dos EUA (Norte da Virgínia), você será cobrado quando mover uma fita virtual arquivada no S3 Glacier para o S3 Glacier Deep Archive a uma taxa de USD 0,032 por GB de dado armazenado na fita. Por exemplo, mover uma fita de 100 GB arquivada no S3 Glacier para o S3 Glacier Deep Archive custará 100 GB x USD 0,032/GB = USD 3,2. Movendo uma fita arquivada por menos de 90 dias no S3 Glacier para o S3 Glacier Deep Archive, também será cobrada uma taxa de exclusão antecipada para armazenamento da fita no S3 Glacier.

Será cobrada a transferência de dados pela Internet para cada GB baixado da AWS para o seu gateway. Toda a transferência de dados para carregamento na AWS é gratuita.

O console de gerenciamento de cobranças e custos mostra uma estimativa do uso de cada serviço no mês até a data atual, inclusive de volumes e fitas virtuais do AWS Storage Gateway. Para uma análise do uso por volume individual ou fita virtual, use Relatórios de faturamento detalhados para ver o uso de cada recurso diariamente.

Você pagará pelas solicitações do S3 efetuadas em seu nome pelo gateway de arquivos para armazenar e recuperar arquivos no S3 como objetos. O gateway armazena dados em cache até a capacidade dos discos locais alocados, o que pode ajudar a reduzir os custos da recuperação de dados.

Se você configurar logs de auditoria do gateway de arquivos, serão cobradas as taxas padrão dos serviços Amazon CloudWatch Logs, Amazon CloudWatch Events Amazon CloudWatch Metrics.

O sistema de cobrança segue o Tempo Universal Coordenado (UTC). O mês corrido começa à meia-noite do fuso UTC no primeiro dia de cada mês.

Salvo indicação em contrário, nossos preços excluem impostos e taxas aplicáveis, incluindo o IVA e o imposto de vendas aplicável. Para clientes com endereço de pagamento no Japão, o uso da região Ásia-Pacífico (Tóquio) está sujeito ao imposto sobre consumo japonês.

Sim, o AWS Premium Support abrange os problemas relacionados ao uso do AWS Storage Gateway. Consulte a página de detalhes do AWS Premium Support para obter mais informações e o preço.

Você pode obter informações sobre a grande quantidade de conhecimentos existentes sobre a comunidade AWS por meio do fórum de discussão do AWS Storage Gateway.

Entre em contato com o AWS Support, que oferece suporte ao software e ao serviço AWS Storage Gateway. O AWS Support também coordena todos os casos relacionados a hardware com a equipe de suporte do fabricante do hardware. Recomendamos que você compre o AWS Premium Support.

A etiqueta de serviço no dispositivo de hardware pode ser encontrada na visualização Hardware do console do AWS Storage Gateway.

O AWS Support trabalha com o fabricante do hardware para suporte de hardware. O suporte de hardware está incluído na compra do dispositivo e oferece 36 meses de suporte telefônico 24 horas por dia, sete dias por semana, além de serviço no local no próximo dia útil para substituição de peças.

O dispositivo de hardware vem com três anos de garantia e serviço no local no dia útil seguinte para substituição de peças fornecidas pelo fabricante do hardware. Você pode encontrar informações de garantia aqui.