Perguntas frequentes sobre o Amazon EBS

Quando vinculados a instâncias otimizadas para o EBS, os volumes SSD de IOPS provisionadas (io2 Block Express e io1) são projetados para operar dentro de 10% da performance de IOPS provisionadas 99,9% do tempo em um determinado ano. O desempenho exato depende dos requisitos de E/S do aplicativo.

Quando conectados a instâncias otimizadas do EBS, os volumes io2 Block Express de IOPS provisionadas podem atingir latências inferiores a dez milissegundos, enquanto os volumes io1 podem atingir latências inferiores a milissegundo de um dígito. O desempenho exato depende dos requisitos de E/S do aplicativo.

Sim, é compatível. Quando você provisiona IOPS para volumes io2 Block Express, a taxa de IOPS obtida dependerá do tamanho de E/S das leituras e gravações de suas aplicações. Os volumes de IOPS provisionadas têm um tamanho de E/S base de 16 KB. Portanto, se você provisionou um volume com 40.000 IOPS para um tamanho de E/S de 16 KB, ele alcançará até 40.000 IOPS nesse tamanho. Se o tamanho de E/S for aumentado para 256 KB, você obterá até 16.000 IOPS, já que o throughput máximo de 4.000 MiB/s é atingido em 16.000 IOPS. Para obter mais detalhes, visite a documentação técnica sobre volumes de IOPS provisionadas. Você pode usar o Amazon CloudWatch para monitorar seu throughput e tamanhos de E/S.

Os volumes SSD de IOPS provisionadas (io2 Block Express e io1) vinculados às instâncias otimizadas para o EBS são criados para oferecer uma performance consistente, operando dentro de 10% da performance das IOPS provisionadas, 99,9% do tempo em um determinado ano. Para obter a máximo consistência de performance com novos volumes criados a partir de um instantâneo, recomendamos habilitar o Fast Snapshot Restore (FSR) em seus instantâneos. Os volumes do EBS restaurados a partir de snapshots com a FSR habilitada receberão a performance total instantaneamente.

Outro fator que pode afetar sua performance é se sua aplicação não estiver enviando solicitações suficientes de E/S. Isso pode ser monitorado verificando o comprimento da fila do volume. O comprimento da fila é o número de solicitações pendentes de E/S do aplicativo para o volume. Para obter a máxima consistência, um volume de IOPS provisionadas precisa manter um comprimento médio de fila (arredondado para o número inteiro mais próximo) de um para cada 1.000 IOPS provisionadas em um minuto. Por exemplo, para um volume provisionado com 3.000 IOPS, a média de comprimento da fila deve ser três. Para obter mais informações sobre como garantir um desempenho consistente dos volumes, consulte Como aumentar a performance de EBS.

Ao serem vinculados a instâncias otimizadas para o EBS, volumes HDD otimizados para throughput (st1) e HDD inativos (sc1) são criados para disponibilizar execução dentro de 10% da performance de throughput esperada, 99% do tempo em um determinado ano. Seu desempenho exato depende dos requisitos de E/S do aplicativo e do desempenho da instância do EC2.

Sim. A taxa de transferência que você obtém depende da extensão de E/S das leituras e gravações do seu aplicativo. Os volumes sustentados por HDD processam leituras e gravações em extensões de E/S de 1 MB. E/S sequenciais são combinadas e processadas como unidades de 1 MB, enquanto cada E/S não sequencial é processada com 1 MB, mesmo se a extensão de E/S for menor. Portanto, embora uma workload transacional com E/S pequenas e aleatórias, como um banco de dados, não apresente uma boa performance em volumes sustentados por HDD, E/S sequenciais e E/S extensas atingirão a performance anunciada de st1 e sc1 por um período maior.

Os volumes HDD otimizados para throughput (st1) e HDD inativos (sc1) vinculados a instâncias otimizadas para o EBS são criados para oferecer performance estável, disponibilizando execução dentro de 10% da performance de throughput esperada, 99% do tempo em um determinado ano. Há vários fatores que podem afetar o nível de estabilidade observado. Por exemplo, o equilíbrio relativo entre operações de E/S aleatórias e sequenciais no volume pode afetar seu desempenho. O excesso de operações de E/S aleatórias e pequenas esgotará rapidamente seus créditos de E/S e diminuirá seu desempenho até a taxa parâmetro. Sua taxa de transferência também pode ser menor, dependendo da instância selecionada. Embora o st1 possa impulsionar o throughput para até 500 MB/s, a performance será restringida pelo limite do nível de instância separado para o tráfego do EBS. Outro fator é a criação de um snapshot, que diminuirá o desempenho de gravação esperado para a taxa parâmetro, até que o snapshot seja concluído. Esse fator é específico dos volumes st1 e sc1.

Seu desempenho também pode ser afetado se o seu aplicativo não estiver enviando solicitações de E/S suficientes. Isso pode ser monitorado ao verificar o comprimento da fila e a extensão de E/S do seu volume. O comprimento da fila é o número de solicitações pendentes de E/S do aplicativo para o volume. Para consistência máxima, os volumes em HDD devem manter um comprimento médio de fila (arredondado para o número inteiro mais próximo) de quatro ou mais para cada 1 MB de E/S sequencial. Para obter mais informações sobre como garantir um desempenho consistente dos volumes, consulte Increasing EBS Performance.

Sim. É possível juntar vários volumes para atingir até 400.000 IOPS ou 12.500 Mbps quando vinculados a instâncias maiores do EC2. Recomendamos o uso de volumes io2 Block Express para requisitos de desempenho maiores sem precisar do gerenciamento operacional do striping de vários volumes. A performance de st1 e sc1 é escalada linearmente com o tamanho do volume de forma que talvez não haja muito benefício em agrupar esses volumes.

O EBS é um serviço multilocatário de armazenamento em bloco. Empregamos a limitação de taxas como um dos mecanismos para evitar a contenção de recursos. Isso começa com a presença de critérios definidos de performance para os volumes. Nossos tipos de volumes (gp2, PIOPS, st1 e sc1) têm características de performance definidas em termos de IOPS e throughput. A próxima etapa é a definição do desempenho a nível de instância. Cada instância otimizada do EBS tem o desempenho definido (tanto throughput quanto IOPS) para o conjunto de volumes do EBS vinculado à instância. Portanto, um cliente pode dimensionar instâncias e volumes para obter o nível de desempenho desejado. Além disso, os clientes podem usar nossas métricas relatadas para observar o desempenho a nível de instância e a nível de volume. Eles podem definir alarmes para determinar se o que estão visualizando não corresponde ao desempenho esperado – as métricas também podem ajudar a determinar se os clientes estão ou não configurados no tipo correto de instância e com o montante correto de desempenho a nível de volume. Do lado do EBS, usamos o desempenho configurado para informar como alocamos a instância adequada e a infraestrutura do EBS para oferecer suporte aos volumes. Ao alocar a infraestrutura adequadamente, evitamos a contenção de recursos. Além disso, monitoramos constantemente nossa infraestrutura. Esse monitoramento nos permite detectar falhas na infraestrutura (ou falhas iminentes na infraestrutura) e, consequentemente, mover os volumes proativamente para hardware funcional enquanto a infraestrutura subjacente passa por reparos ou é substituída (conforme adequado).

Quando vinculados a instâncias otimizadas para o EBS, os volumes SSD de uso geral (gp3 e gp2) são projetados para execução dentro de 10% da performance das IOPS provisionadas, 99% do tempo em um determinado ano. O desempenho exato depende dos requisitos de E/S do aplicativo.

Quando conectados a instâncias otimizadas para EBS, os volumes SSD de uso geral (gp3 e gp2) podem atingir latências inferiores a 10 milissegundos. O desempenho exato depende dos requisitos de E/S do aplicativo.

Não. Todos os volumes SSD de uso geral (gp3) incluem 3.000 IOPS e 125 MB/s de performance consistente sem custo adicional. Os volumes podem sustentar 3.000 IOPS e 125 MB/s indefinidamente.

Volumes SSD de uso geral (gp2) que estão abaixo de 1.000 GB recebem um pico de performance de IOPS de até 3.000 IOPS por pelo menos 30 minutos de performance sustentada. Além disso, os volumes gp2 oferecem performance consistente de 3 IOPS por GB provisionado. Por exemplo, um volume de 500 GB é capaz de gerar 1.500 IOPS de modo consistente e fazer o bursting para 3.000 IOPS por 60 minutos (3.000 IOPS * 60 segundos * 30 minutos / 1.500 IOPS / 60 segundos).

Os volumes io2 oferecem armazenamento em blocos de alta performance para todas as instâncias do EC2. Para aplicações que requerem performances ainda maiores, é possível anexar volumes io2 para as instâncias do Amazon EC2 que são executadas no Block Express e oferecem performance quatro vezes maior que o io2. Isso possibilitará alcançar até 64 TiB de capacidade, 256 mil IOPS e 4 mil MB/s de throughput de um único volume io2 com latência média de IO inferior a um milissegundo.

O EBS Block Express é a próxima geração da arquitetura de servidor de armazenamento do Amazon EBS, criado especificamente para oferecer os mais altos níveis de performance com latência abaixo de um milissegundo para armazenamento em bloco em escala de nuvem. O Block Express faz isso usando o Scalable Reliable Datagrams (SRD), um protocolo de rede de baixa latência de alta performance, para se comunicar com instâncias do EC2 baseadas no Nitro System. Esta é a mesma interface de rede de alta performance e baixa latência usada para comunicação entre instâncias no Elastic Fabric Adapter (EFA) para workloads de High Performance Computing (HPC) e Machine Learning (ML). Além disso, o Block Express oferece blocos de construção de software e hardware modulares que podem ser montados de muitas maneiras diferentes, dando flexibilidade para projetar e fornecer performance aprimorada e novos recursos em um ritmo mais rápido.

O io2 Block Express é adequado para workloads com alta performance e capacidade que se beneficiam de latência mais baixa, IOPS mais alta, maior throughput ou maior capacidade em um único volume. Essas workloads incluem bancos de dados relacionais e NoSQL, como SAP HANA, Oracle, MS SQL, PostgreSQL, MySQL, MongoDB, Cassandra e workloads de operação empresarial crítica, como SAP Business Suite, NetWeaver, Oracle eBusiness, PeopleSoft, Siebel e workloads ERP, como Infor LN e Infor M3.

Se um volume io2 estiver anexado a essas instâncias do Amazon EC2, ele será executado no Block Express, que oferece latência inferior a um milissegundo e capacidade de gerar até 256 mil IOPS, além de throughput de 4 mil MB/s e até 64 TiB de tamanho para um único volume. Os volumes io2 anexados a todas as outras instâncias não são executados no Block Express e oferecem latência de milissegundos de um dígito e capacidade de gerar até 64 mil IOPS, além de throughput de 1 GB/s e até 16 TiB de tamanho para um único volume.
 

Esse recurso pode ser usado por meio das seguintes APIs que podem ser chamadas usando o AWS CLI ou via AWS SDK.

• Blocos de lista do snapshot: a operação da API ListSnapshotBlocks retorna os indexes e tokens dos blocos para blocos em snapshots específicos.
• Bloco de listas mudadas: a operação da API ListChangedBlocks retorna os indexes e tokens de blocos para blocos que são diferentes entre dois snapshots específicos do mesmo volume/linhagem de snapshot.
• Obtenha blocos de snapshot: a operação da API GetSnapshotBlock retorna dados em um bloco para o ID, índice e token de bloco de snapshot específico.
• Inicie o snapshot: a operação StartSnapshot inicia um snapshot, seja como incremental a partir de um existente ou como um novo snapshot. O snapshot iniciado permanece no estado pendente até ser concluído usando a ação CompleteSnapshot.
• Enviar bloco de snapshots: a operação PutSnapshot acrescenta dados na forma de blocos individuais a um snapshot iniciado que está no estado pendente. Especifique uma soma de verificação SHA256 codificada como Base64 para o bloco de dados transmitido. O serviço valida a soma de verificação após a conclusão da transmissão. A solicitação falha se a soma de verificação calculada pelo serviço não corresponde à que você especificou.
• Conclua o snapshot: a operação CompleteSnapshot conclui um snapshot iniciado que está no estado pendente. Em seguida, os snapshots são alterados para um estado concluído.

Para obter mais informações, consulte a documentação técnica.

As APIs GetSnapshotBlock e PutSnapshotBlock são compatíveis com o tamanho de bloco de 512 KiB.

Não, os snapshots estão disponíveis somente por meio das APIs do Amazon EC2.

Não, os snapshots podem ser feitas em tempo real enquanto o volume está anexado e em uso. No entanto, os snapshots capturam somente os dados que foram gravados no volume do Amazon EBS, o que poderá excluir quaisquer dados que foram localmente armazenados em cache pelo aplicativo ou SO. Para assegurar snapshots consistentes em volumes anexados a uma instância, recomendamos desanexar completamente o volume, emitir o comando de snapshot e, em seguida, anexar novamente o volume. Para os volumes do Amazon EBS que atuam como dispositivos-raiz, recomendamos o desligamento da máquina para obter um snapshot nítido.

De acordo com a sua concepção, a criação de um snapshot do EBS de um volume inteiro de 16 TB não deve demorar mais do que a criação de um snapshot de um volume inteiro de 1 TB. No entanto, o tempo necessário real dependerá de vários fatores, como a quantidade de dados que foram alterados desde o último snapshot criado do volume do EBS em questão.

Cada snapshot recebe um identificador exclusivo e os clientes podem criar volumes com base em qualquer um de seus snapshots existentes.

Você pode localizar snapshots que foram compartilhados com você selecionando Snapshots privados na lista da seção Snapshots do Console de Gerenciamento da AWS. Esta seção lista tanto snapshot seus quanto snapshot compartilhados com você.

Você pode localizar snapshots globalmente compartilhados selecionando Snapshots públicos na lista da seção Snapshots do Console de Gerenciamento da AWS. Você também pode restringir o acesso público aos snapshots em uma conta habilitando Bloquear acesso público a snapshots do EBS.

Você pode usar o Console de Gerenciamento da AWS para encontrar bancos de dados públicos armazenados como snapshots da Amazon. Faça login no Console, selecione Amazon EC2 Service, selecione Snapshots e aplique o filtro em Public Snapshots. Todas as informações sobre bancos de dados públicos estão disponíveis na nossa central de recursos de bancos de dados públicos da AWS.

Você deve habilitar a FSR de snapshots se estiver preocupado com a latência do acesso a dados no processo de restauração de dados de um snapshot para um volume e quiser evitar a queda inicial de performance durante a inicialização. A FSR serve para ajudar em casos de infraestrutura de desktop virtual (VDI), backup e restauração, cópias de volumes de teste/desenvolvimento e inicialização a partir de AMIs personalizadas. Ao habilitar a FSR no snapshot, você perceberá que a performance fica melhor e previsível sempre que é necessário usar esse snapshot para restaurar dados.

Não. Snapshots com FSR habilitada melhoram o processo de restauração de dados de backup do snapshot para seus volumes. Snapshots com FSR habilitada não aceleram o processo de criação de snapshot.

Para usar esse recursos, invoque a nova API enable-fast-snapshot-restores em um snapshot dentro da zona de disponibilidade (AZ) onde os volumes inicializados serão restaurados.

O snapshot com FSR habilitada pode estar com um dos estados a seguir: habilitando, otimizando, habilitado, desabilitando, desabilitado. Transições de estado são publicadas como eventos do CloudWatch e o estado da FSR pode ser verificado usando a API describe-fast-snapshot-restores.

Habilitar a FSR em um snapshot não altera as interações existentes do snapshot com API. Não é necessário mudar os fluxos de trabalhos atuais. A FSR só pode ser habilitada ou desabilitada em snapshots da conta. Não é possível aplicar a FSR em snapshots compartilhados. Você pode ver a lista dos snapshots com FSR habilitada pela API ou pelo console.

Volumes criados a partir de um snapshot com FSR habilitada são totalmente inicializados. No entanto, o número de volumes que podem ser criados com performance imediata completa é limitado. Esses limites são expressados na forma de um bucket de crédito associado a um snapshot com FSR habilitada em uma determinada AZ. As coisas mais importantes que você precisa saber sobre créditos:

1. Cada operação de criação de volume consume um crédito
2. O número de créditos é uma função do tamanho do snapshot com FSR habilitada
3. Os créditos são renovados ao longo do tempo
4. O tamanho máximo do bucket de crédito é 10

Para estimativa do tamanho do bucket de crédito e da taxa de renovação, divida 1.024 pelo tamanho do snapshot. Por exemplo, um snapshot de 100 GiB com FSR habilitada terá um saldo máximo de 10 créditos com uma taxa de renovação de 10 créditos por hora. Um snapshot de 4 TiB terá um saldo máximo de 1 com taxa de renovação de 1 crédito a cada 4 horas.

É importante observar que o tamanho do bucket de crédito é uma função do tamanho do snapshot com FSR habilitada, não do tamanho dos volumes criados. Por exemplo, é possível criar até dez volumes de 1TiB a partir de um snapshot de 100GiB de uma só vez.

Por último, cada AZ em que o snapshot tiver a FSR habilitada receberá um bucket de crédito independente de outras AZs.

O tamanho do bucket de crédito de criação representa o número máximo, enquanto o saldo do bucket de crédito representa o número disponível de criações. Quando estiver cheio, é possível criar até 10 volumes inicializados a partir de um snapshot com FSR habilitada de uma só vez. Tanto o tamanho máximo do bucket de crédito quando o saldo do bucket de crédito são publicados como métricas do CloudWatch. Caso sejam criados mais volumes do que o limite, o processo acontecerá como se a FSR não tivesse habilitada no snapshot.

Quando a FSR é usada, um novo atributo específico do EBS (fastRestored) é adicionado à API DescribeVolumes para denotar o status no momento da criação. Quando um volume for criado a partir de um snapshot com FSR habilitada sem créditos suficientes de criação de volumes, a criação será realizada com êxito, mas o volume não será inicializado.

Quando você excluir um snapshot, a FSR dele será desabilitada automaticamente e o respectivo faturamento será encerrado.

Sim, é possível habilitar a FSR para snapshots públicos e snapshots privados na sua conta. Para habilitar a FSR de snapshots compartilhados, use o mesmo conjunto de chamadas de API que você usa para habilitar a FSR em seus próprios snapshots.

Quando você habilita a FSR no snapshot compartilhado, o faturamento segue as taxas padrão de FSR (consulte as páginas de preços). Observe que somente a sua conta será faturada pela FSR do snapshot compartilhado. O proprietário do snapshot não será cobrado quando você habilitar a FSR no snapshot compartilhado.

Quando o proprietário do snapshot compartilhado o exclui ou deixa de compartilhá-lo com você revogando suas permissões para criar volumes a partir dele, a respectiva FSR é desabilitada automaticamente e o faturamento da FSR correspondente é encerrada.

Você pode usar o Amazon Data Lifecycle Manager e o AWS Systems Manager (SSM) para coordenar o congelamento, a liberação de E/S e o descongelamento da sua aplicação ou do banco de dados, bem como a inicialização dos snapshots do EBS. Você precisará fornecer comandos para executar as ações específicas da sua aplicação ou banco de dados. Você também pode consultar a nossa documentação para obter o código fornecido pela AWS e documentos SSM para aplicações MySQL, PostgreSQL e Windows.

A criptografia do Amazon EBS oferece criptografia contínua de volumes de dados, volumes de inicialização e snapshots do EBS, eliminando a necessidade de criar e manter uma infraestrutura segura de gerenciamento de chaves. A criptografia do EBS habilita a segurança de dados em repouso ao criptografar seus dados usando chaves gerenciadas pela Amazon ou chaves que você cria e gerencia usando o AWS Key Management Service (KMS). A criptografia ocorre nos servidores que hospedam instâncias do EC2, proporcionando criptografia de dados em trânsito entre as instâncias do EC2 e armazenamento do EBS. Para obter mais detalhes, consulte a criptografia do Amazon EBS no Guia do usuário do Amazon EC2.

O AWS KMS é um serviço gerenciado que facilita a criação e o controle de chaves de criptografia usadas para criptografar seus dados. O AWS Key Management Service está integrado a outros serviços da AWS, inclusive Amazon EBS, Amazon S3 e Amazon Redshift, para simplificar a criptografia de seus dados com chaves de criptografia gerenciadas por você. O AWS Key Management Service também é integrado com o AWS CloudTrail para fornecer logs contendo toda a utilização das chaves para ajudar a cumprir requisitos normativos e de conformidade. Para saber mais sobre o KMS, acesse a página de produto do AWS Key Management Service.

Você pode usar a criptografia do Amazon EBS para satisfazer requisitos de conformidade de segurança e criptografia de dados em repouso na nuvem. A combinação da criptografia com as políticas de controle de acesso atuais da IAM aprimora a estratégia de defesa completa da sua empresa.

A criptografia do Amazon EBS cuida do gerenciamento de chaves para você. Cada volume criado obtêm uma chave AES exclusiva de 256 bits. Os volumes criados a partir dos snapshots compartilham essa chave. Essas chaves são protegidas pela nossa própria infraestrutura de gerenciamento, que implementa controles robustos de segurança lógica e física para evitar acesso não autorizado. Seus dados e as chaves associadas são criptografados usando o algoritmo AES-256, padrão do setor.

Sim.

Sim, usando chaves mestre do cliente (CMKs) gerenciadas pela AWS ou pelo cliente. Você pode especificar os detalhes e a criptografia do volume por meio de uma chamada para a API RunInstances com o parâmetro BlockDeviceMapping ou por meio do Assistente de execução no console do EC2.

Sim. Você pode criar um volume de dados criptografado com criptografia CMK padrão ou personalizada no momento da execução das instâncias. É possível especificar os detalhes e a criptografia do volume por meio do objeto BlockDeviceMapping na chamada da API RunInstances ou por meio de Launch Wizard no console do EC2.

Sim. Consulte a documentação técnica para mais detalhes.

Sim. Você pode compartilhar snapshots e AMIs criptografados usando uma Customer Master Key (CMK – Chave mestra do cliente) gerenciada pelo cliente com outras contas da AWS. Consulte a documentação técnica para mais detalhes.

Sim, você pode habilitar a Criptografia por padrão do EBS com uma única configuração por região. Isto garante que todos os novos volumes criados estão criptografados. Consulte a documentação técnica para obter mais detalhes. 

Sim, você será cobrado pelas IOPS provisionadas quando ele for desconectado de uma instância. Quando um volume é desacoplado, recomendamos que considere criar um snapshot e excluir o volume para reduzir os custos. Para obter mais informações, veja a verificação de otimização de custos para "Volumes subutilizados do Amazon EBS" no Trusted Advisor. Este item verifica as configurações do volume do Amazon Elastic Block Store (Amazon EBS) e alerta quando os volumes parecem estar subutilizados.

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 AWS está sujeito ao imposto sobre consumo japonês. Saiba mais.

Não. O Multi-Attach pode ser ativado em um volume de IOPS provisionadas do EBS e cobranças serão feitas pelo armazenamento (GB-Mo) e as IOPS (IOPS-Mo) provisionadas.

Não.

O comportamento do deleteOnTermination do volume é determinado pela configuração da última instância anexada que é finalizada. Para garantir a exclusão previsível no comportamento de finalização, ative ou desative o 'deleteOnTermination' para todas as instâncias às quais o volume está anexado.

Se desejar que o volume seja excluído quando as instâncias anexadas forem encerradas, ative 'deleteOnTermination' para todas as instâncias às quais o volume está anexado. Se desejar reter o volume após o término das instâncias anexadas, desative 'deleteOnTermination' para todas as instâncias anexadas. Para obter mais informações, consulte a documentação técnica do Multi-Attach.

Sua aplicação poderá usar o Multi-Attach se ela for criada no Windows Server Failover Cluster, se coordenar o acesso seguro ao armazenamento compartilhado usando reservas NVMe ou coordenar o acesso seguro no nível da aplicação.