Perguntas frequentes sobre o Amazon Aurora

O Amazon Aurora é um serviço de banco de dados relacional moderno que oferece performance e alta disponibilidade em grande escala, edições compatíveis com MySQL e PostgreSQL totalmente em código aberto e uma variedade de ferramentas de desenvolvedores para desenvolver aplicações sem servidor e baseadas em machine learning (ML).

O Aurora oferece um sistema de armazenamento distribuído, tolerante a falhas e com autorrecuperação que é independente dos recursos de computação e aumenta a escala verticalmente de maneira automática para até 128 TiB por instância de banco de dados. Ele oferece alta performance e disponibilidade com até 15 réplicas de leitura de baixa latência, recuperação a um ponto anterior no tempo, backup contínuo para o Amazon Simple Storage Service (Amazon S3) e replicação entre três zonas de disponibilidade (AZs).

O Aurora também é um serviço totalmente gerenciado que automatiza tarefas de administração demoradas, como provisionamento de hardware, configuração de banco de dados, aplicação de patch e backups, ao mesmo tempo que oferece segurança, disponibilidade e confiabilidade de bancos de dados comerciais por uma fração do custo.

O Amazon Aurora é totalmente compatível com bancos de dados MySQL de código aberto existentes e adiciona suporte para novos lançamentos regularmente. Isso significa que você pode migrar bancos de dados MySQL com facilidade, de e para o Aurora, ao usar as ferramentas padrão de importação e exportação ou os snapshots. Isso também significa que a maior parte do código, aplicações, drivers e ferramentas que você já usa com bancos de dados MySQL hoje pode ser usada com o Aurora com pouca ou nenhuma alteração. Isso torna mais fácil mover aplicações entre os dois mecanismos.

É possível ver as informações atuais sobre a compatibilidade com MySQL do lançamento do Amazon Aurora na documentação.

O Amazon Aurora é compatível com os bancos de dados de código aberto PostgreSQL existentes e adiciona suporte para novos lançamentos regularmente. Assim, você pode migrar facilmente bancos de dados PostgreSQL de e para o Aurora usando ferramentas padrão de importação/exportação ou snapshots. Isso também significa que a maior parte do código, aplicações, drivers e ferramentas que você já usa com bancos de dados PostgreSQL atualmente pode ser usada com o Aurora com pouca ou nenhuma alteração.

É possível ver as informações atuais sobre a compatibilidade com PostgreSQL do lançamento do Amazon Aurora na documentação.

A Amazon oferece suporte total ao Aurora edição compatível com PostgreSQL e a todas as extensões disponibilizadas com o Aurora. Se você precisar de suporte para o Aurora edição compatível com PostgreSQL, entre em contato com o AWS Support. Se você tiver uma conta ativa do AWS Premium Support, basta entrar em contato com o AWS Premium Support para tratar de questões específicas sobre o Aurora.

Para testar o Aurora, faça login no Console de Gerenciamento da AWS, selecione RDS na categoria Database (Banco de dados) e escolha o Amazon Aurora como seu mecanismo de banco de dados. Para orientações detalhadas e recursos, confira a nossa página Conceitos básicos do Amazon Aurora.

É possível ver a disponibilidade do Aurora por região aqui.

Se quiser migrar do MySQL para o Aurora e vice-versa, há várias opções:

• Use o utilitário padrão mysqldump para exportar dados do MySQL e o utilitário mysqlimport para importar dados para o Aurora, e vice-versa.
• Você também pode usar o recurso de migração do Snapshot do BD Amazon RDS para migrar um snapshot do BD Amazon RDS para MySQL para o Aurora usando o Console de Gerenciamento da AWS.

Para a maioria dos clientes, a migração para o Aurora é concluída em menos de uma hora, embora a duração dependa do formato e do tamanho do conjunto de dados. Para mais informações, consulte Práticas recomendadas para a migração de bancos de dados MySQL para o Amazon Aurora.

Se você deseja migrar do PostgreSQL para o Aurora e vice-versa, há diversas opções:

• É possível usar o utilitário padrão pg_dump para exportar dados do PostgreSQL e o utilitário pg_restore para importar dados para o Aurora, e vice-versa.
• Use também o recurso de migração do snapshot do banco de dados do RDS para migrar um snapshot do banco de dados do Amazon RDS para PostgreSQL para o Aurora usando o Console de Gerenciamento da AWS.

Para a maioria dos clientes, a migração para o Aurora é concluída em menos de uma hora, embora a duração dependa do formato e do tamanho do conjunto de dados.

Para migrar bancos de dados SQL Server para o Amazon Aurora edição compatível com PostgreSQL, você pode usar o Babelfish para Aurora PostgreSQL. Suas aplicações funcionarão sem nenhuma alteração. Consulte a documentação do Babelfish para obter mais informações.

Não, o Aurora funciona com drivers de banco de dados PostgreSQL padrão.

O Amazon Aurora oferece aumentos consideráveis de performance em relação ao MySQL, integrando totalmente o mecanismo de banco de dados com uma camada de armazenamento virtualizada baseada em SSD criada especificamente para workloads de banco de dados, reduzindo as gravações no sistema de armazenamento, diminuindo a contenção por bloqueio e eliminando atrasos causados por threads de processo do banco de dados.

Nossos testes com o SysBench em instâncias r3.8xlarge mostram que o Amazon Aurora entrega mais de 500.000 SELECTs/s e 100.000 UPDATEs/s, cinco vezes mais que o MySQL, executando o mesmo teste comparativo no mesmo hardware. Veja as instruções detalhadas sobre este parâmetro de comparação e sobre como replicá-lo no Amazon Aurora MySQL-Compatible Edition Performance Benchmarking Guide (Guia de benchmarking de performance do Amazon Aurora edição compatível com MySQL).

O Amazon Aurora oferece aumentos consideráveis de performance em relação ao PostgreSQL, integrando totalmente o mecanismo de banco de dados com uma camada de armazenamento virtualizada baseada em SSD criada especificamente para workloads de banco de dados, reduzindo as gravações no sistema de armazenamento, diminuindo a contenção por bloqueio e eliminando atrasos causados por threads de processo do banco de dados.

Nossos testes com o SysBench em instâncias r4.16xlarge mostram que o Amazon Aurora entrega um número de SELECTs/s e UPDATEs/s mais de três vezes maior que o PostgreSQL executando o mesmo teste comparativo no mesmo hardware. Veja as instruções detalhadas sobre este parâmetro de comparação e sobre como replicá-lo no Amazon Aurora PostgreSQL-Compatible Edition Performance Benchmarking Guide (Guia de benchmarking de performance do Amazon Aurora edição compatível com PostgreSQL).

O Amazon Aurora é projetado para ser compatível com o MySQL, de maneira que as aplicações e ferramentas existentes do MySQL possam ser executadas sem a necessidade de modificações. No entanto, uma área em que o Amazon Aurora oferece melhorias em relação ao MySQL é no uso de workloads altamente simultâneas. Para maximizar o throughput da sua workload no Amazon Aurora, recomendamos que você desenvolva suas aplicações para gerarem um grande número de consultas e transações simultâneas.

O Amazon Aurora foi projetado para ser compatível com o PostgreSQL, de maneira que as aplicações e ferramentas existentes do PostgreSQL possam ser executadas sem a necessidade de modificações. No entanto, uma área em que o Amazon Aurora oferece melhorias em relação ao PostgreSQL é no uso de workloads altamente simultâneas. Para maximizar o throughput da sua workload no Amazon Aurora, recomendamos que você desenvolva suas aplicações para gerar um grande número de consultas e transações simultâneas.

Consulte a página de preços do Aurora para informações atualizadas sobre preços.

Não há nenhuma oferta de nível gratuito da AWS para o Aurora no momento. No entanto, o Aurora armazena seus dados de forma durável em três zonas de disponibilidade em uma região e cobra por apenas uma cópia dos dados. Você não é cobrado por backups de até 100% do tamanho do seu cluster de banco de dados. Você também não é cobrado pelos snapshots durante o período de retenção de backup que você configurou para seu cluster de banco de dados.

Não, a replicação do Aurora está incluída no preço. A sua cobrança é feita com base no armazenamento consumido pelo seu banco de dados na camada de do banco de dados, e não pelo armazenamento consumido na camada de armazenamento virtualizado do Aurora.

As operações de E/S são executadas pelo mecanismo de banco de dados Aurora na sua camada de armazenamento virtualizado com base em SSDs. Cada operação de leitura de página de banco de dados conta como uma E/S.
O mecanismo de banco de dados Aurora emite leituras na camada de armazenamento para obter as páginas do banco de dados que não estão presentes na memória no cache:

• Se o seu tráfego de consultas puder ser totalmente atendido pela memória ou pelo cache, você não receberá a cobrança pela recuperação de nenhuma página de dados da memória.
• Se o tráfego de consulta não puder ser atendido inteiramente pela memória, você será cobrado pelas páginas de dados que precisem ser recuperadas do armazenamento.
  Cada página de banco de dados tem 16 KB no Amazon Aurora edição compatível com MySQL e 8KB no Aurora edição compatível com PostgreSQL.

O Aurora foi projetado para remover operações de E/S desnecessárias para reduzir custos e garantir a disponibilidade de recursos para atender ao tráfego de leitura/gravação. As operações de E/S de gravação são consumidas apenas ao persistir os registros de log de repetição no Aurora edição compatível com MySQL ou os registros de log de gravação antecipada no Aurora edição compatível com PostgreSQL na camada de armazenamento com o objetivo de tornar as gravações duráveis.

As operações de E/S de gravação são contadas em unidades de 4 KB. Por exemplo, um registro de log com 1.024 bytes conta como uma operação de E/S de gravação. No entanto, se o registro de log for maior que 4 KB, mais de uma operação de E/S de gravação é necessária para persisti-lo.

Operações de gravação simultâneas com registros de log inferiores a 4 KB podem ser armazenadas juntas em lotes pelo mecanismo de banco de dados Aurora para otimizar o consumo de E/S. Ao contrário dos mecanismos de banco de dados tradicionais, o Aurora nunca libera páginas de dados sujos para armazenamento.

Você pode ver quantas solicitações de E/S a instância do Aurora está consumindo verificando o Console de Gerenciamento da AWS. Para localizar o seu consumo de E/S, consulte a seção Amazon RDS do console, pesquise na sua lista de instâncias, selecione as suas instâncias do Aurora e procure pelas métricas “VolumeReadIOPs” e “VolumeWriteIOPs” na seção de monitoramento.

Para obter mais informações sobre os preços das operações de E/S, visite a página de preços do Aurora. Você é cobrado pelas operações de E/S de leitura e gravação ao configurar seus clusters de banco de dados com a configuração Aurora Standard. Você não é cobrado pelas operações de E/S de leitura e gravação ao configurar seus clusters de banco de dados para o Amazon Aurora I/O-Optimized.

O Aurora oferece a flexibilidade de otimizar seus gastos com o banco de dados, escolhendo entre duas opções de configuração com base em suas necessidades de desempenho e previsibilidade de preço. As duas opções de configuração são: Aurora Standard e Aurora I/O-Optimized. Nenhuma das opções requer provisionamento inicial de E/S ou de armazenamento e ambas podem ajustar a escala para operações de E/S com a finalidade de oferecer suporte às aplicações mais complexas.

O Aurora Standard é uma configuração de cluster de banco de dados que oferece preços econômicos para a grande maioria das aplicações com uso de E/S baixo a moderado. Com o Aurora Standard, você paga por instâncias de banco de dados, armazenamento e E/S com pagamento por solicitação.

O Aurora I/O-Optimized é uma configuração de cluster de banco de dados que oferece melhor relação entre preço e performance para aplicações com uso intensivo de E/S, como sistemas de processamento de pagamentos, sistemas de comércio eletrônico e aplicações financeiras. Além disso, se o gasto de E/S exceder 25% do gasto total do banco de dados do Aurora, é possível economizar até 40% nos custos das workloads com uso intensivo de E/S ao usar o Aurora I/O-Optimized. O Aurora I/O-Optimized oferece preços previsíveis para todas as aplicações, pois não há cobrança para operações de E/S de leitura e gravação, tornando essa configuração ideal para workloads com alta variabilidade de E/S.

O Aurora I/O-Optimized é a escolha ideal quando você precisa de custos previsíveis para qualquer aplicação. Ele oferece uma relação entre preço e performance aprimorada para aplicações com uso intensivo de E/S, que requerem um alto throughput de gravação ou que executam consultas de análises que processam grandes quantidades de dados. Para clientes com um gasto de E/S superior a 25% da fatura do Aurora, é possível economizar até 40% nos custos de workloads com uso intensivo de E/S usando o Aurora I/O-Optimized.

Você pode usar a experiência de um clique disponível no Console de Gerenciamento da AWS para alterar o tipo de armazenamento de seus clusters de banco de dados existentes para que passem para o Aurora I/O-Optimized. Você também pode invocar a AWS Command Line Interface (AWS CLI) ou o AWS SDK para fazer essa alteração.

Você pode mudar seus clusters de banco de dados existentes uma vez a cada 30 dias para o Aurora I/O-Optimized. Você pode voltar para o Aurora Standard a qualquer momento.

Sim, o Aurora I/O-Optimized funciona com as instâncias reservadas do Aurora existentes. O Aurora contabiliza automaticamente a diferença de preço entre o Aurora Standard e o Aurora I/O-Optimized com instâncias reservadas. Com descontos em instâncias reservadas com o Aurora I/O-Optimized, você pode economizar ainda mais em seus gastos de E/S.

Não há alterações no preço do backtrack, do snapshot, da exportação ou do backup contínuo com o Aurora I/O-Optimized.

Sim, as cobranças pelas operações de E/S necessárias para replicar dados entre regiões continuam sendo aplicadas. O Aurora I/O-Optimized não cobra pelas operações de E/S de leitura e gravação, o que é diferente da replicação de dados.

Não há cobranças adicionais pelo Amazon Aurora Optimized Reads para Aurora PostgreSQL, além do preço das instâncias R6id baseadas em Intel e R6gd baseadas em Graviton. Para obter mais informações, acesse a página de preços do Aurora.

O armazenamento mínimo é de 10 GB. Com base na utilização do seu banco de dados, o seu armazenamento do Amazon Aurora aumentará automaticamente até 128 TiB, em incrementos de 10 GB, sem afetar a performance do banco de dados. Não é necessário provisionar o armazenamento antecipadamente.

Há duas formas de escalar os recursos de computação associados à instância de banco de dados do Amazon Aurora: pelo Aurora Sem Servidor ou por meio de um ajuste manual.

Você pode usar o Aurora Sem Servidor, uma configuração de escalabilidade automática sob demanda para o Amazon Aurora, para escalar recursos de computação de banco de dados com base em demandas de aplicações. Ele permite que você execute seu banco de dados na nuvem sem se preocupar com o gerenciamento da capacidade do banco de dados. Você pode especificar o intervalo de capacidade de banco de dados desejado, e seu banco de dados será dimensionado com base nas necessidades de sua aplicação. Leia mais no Aurora Serverless User Guide (Guia do usuário do Aurora Sem Servidor).

Também é possível escalar manualmente os seus recursos de computação associados ao seu banco de dados selecionando o tipo de instância de banco de dados desejado no Console de Gerenciamento da AWS. A alteração solicitada será aplicada durante a sua janela de manutenção especificada. Alternativamente, você pode usar o sinalizador "Apply Immediately" (Aplicar imediatamente) para alterar o tipo de instância de banco de dados imediatamente.

As duas opções afetarão a disponibilidade por alguns minutos enquanto a operação de escalabilidade é realizada. Note que qualquer outra alteração pendente do sistema também será aplicada.

Os backups automáticos contínuos estão sempre habilitados nas instâncias de banco de dados do Amazon Aurora. Os backups não afetam a performance do banco de dados.

Sim, e não há impacto na performance durante a criação de snapshots. Observe que restaurar dados de DB snapshots exige a criação de uma nova instância de banco de dados.

O Amazon Aurora torna automaticamente os seus dados duráveis em três zonas de disponibilidade (AZs) em uma região e tentará recuperar, de forma automática, o banco de dados em uma AZ íntegra, sem perda de dados. No caso improvável de seus dados estarem indisponíveis no armazenamento do Amazon Aurora, você pode fazer a restauração utilizando um snapshot de banco de dados ou fazer uma operação de restauração para um ponto no tempo para uma nova instância. Observe que o último momento restaurável para uma operação de restauração a um ponto anterior no tempo pode ser de até cinco minutos atrás.

Você pode escolher criar um DB snapshot final ao excluir a sua instância de banco de dados. Se o fizer, poderá usar o DB snapshot para restaurar a instância de banco de dados excluída posteriormente. O Amazon Aurora retém esse DB snapshot final criado pelo usuário junto com todos os outros DB snapshots criados manualmente após a exclusão da instância de banco de dados. Apenas DB snapshots são retidos após a exclusão da instância de banco de dados (ou seja, os backups automáticos criados para uma restauração a um ponto anterior no tempo não são mantidos).

Sim. O Aurora permite criar snapshots de bancos de dados, que podem ser usados posteriormente para restaurar um banco de dados. Você pode compartilhar um snapshot com uma conta diferente da AWS e o proprietário da conta de destino pode usar esse snapshot para restaurar um banco de dados com os seus dados. Você pode até mesmo optar por tornar seus snapshots públicos, ou seja, qualquer pessoa pode restaurar um BD contendo seus dados (públicos).

É possível usar este recurso para compartilhar dados entre seus vários ambientes (produção, desenvolvimento/teste, preparação, etc.) que tenham contas diferentes da AWS, como também manter backups de todos os seus dados seguros em uma conta separada, caso sua conta principal da AWS sofra uma ameaça em algum momento.

Não há cobrança pelo compartilhamento de snapshots entre contas. No entanto, podem haver cobranças pelos snapshots em si, como também por qualquer banco de dados que você restaurar usando os snapshots compartilhados. Saiba mais sobre a definição de preços do Aurora.

Nós não oferecemos suporte ao compartilhamento automático de DB snapshots. Para compartilhar um snapshot, será necessário criar manualmente uma cópia do snapshot e, em seguida, compartilhá-la.

É possível compartilhar snapshots manuais com até 20 IDs de conta da AWS. Caso deseje compartilhar um snapshot com mais de 20 contas, torne-o público ou entre em contato com o suporte para aumentar a sua cota.

Você pode compartilhar seus snapshots do Aurora em todas as regiões da AWS onde o Aurora estiver disponível.

Não. Seus snapshots compartilhados do Aurora só poderão ser acessados por contas na mesma região da conta que os compartilha.

Sim, você pode compartilhar snapshots criptografados do Aurora.

O Amazon Aurora divide automaticamente o volume do seu banco de dados em segmentos de 10 GB em vários discos. Cada bloco de 10 GB do seu volume de banco de dados é replicado seis vezes em três zonas de disponibilidade. O Amazon Aurora é projetado para tratar de maneira transparente a perda de até duas cópias de dados sem afetar a disponibilidade de gravação do banco de dados e até três cópias sem afetar a disponibilidade de leitura.

O armazenamento do Amazon Aurora também tem autorrecuperação. Os blocos e discos de dados são verificados de maneira contínua em busca de erros e, então, são automaticamente corrigidos.

Diferente de outros bancos de dados, depois de uma falha, o Amazon Aurora não precisa reproduzir o log de repetição do último ponto de verificação do banco de dados (normalmente cinco minutos) e confirmar que todas as alterações foram aplicadas antes de disponibilizar o banco de dados para operações. Isso reduz os tempos de reinicialização do banco de dados para menos de 60 segundos na maioria dos casos.

O Amazon Aurora move o cache do buffer para fora do processo do banco de dados e o disponibiliza imediatamente no momento da reinicialização. Isso evita que você tenha que controlar o acesso até que o cache esteja preenchido novamente para evitar quedas de energia.

O Amazon Aurora edição compatível com MySQL e o Amazon Aurora edição compatível com PostgreSQL oferecem suporte a réplicas do Amazon Aurora, que compartilham o mesmo volume subjacente da instância primária na mesma região da AWS. As atualizações feitas pela instância primária são visíveis para todas as réplicas do Amazon Aurora.

Com o Amazon Aurora edição compatível com MySQL, você também pode criar réplicas de leitura do MySQL entre regiões usando o mecanismo de replicação baseado em logs binários do MySQL. Nas réplicas de leitura do MySQL, os dados da sua instância primária são reproduzidos em sua réplica como transações. Para a maioria dos casos de uso, inclusive escalabilidade e alta disponibilidade de leitura, recomendamos o uso de réplicas do Amazon Aurora.

Você tem a flexibilidade de misturar e corresponder esses dois tipos de réplicas com base nas necessidades do seu aplicativo:

Você tem duas opções de replicação adicionais, além das listadas acima. Você pode usar o Amazon Global Database para obter uma replicação física muito mais rápida entre clusters do Aurora em diferentes regiões. E, para a replicação entre bancos de dados do Aurora e externos ao Aurora, edições compatíveis com MySQL (mesmo fora da AWS), você pode configurar a sua própria replicação autogerenciada de logs binários.

Sim, você pode configurar réplicas do Aurora em várias regiões usando replicação lógica ou física. A replicação física, chamada Amazon Aurora Global Database, usa uma infraestrutura dedicada que deixa seus bancos de dados inteiramente disponíveis para atender à aplicação, podendo replicar para até cinco regiões secundárias com latência típica de menos de um segundo. Está disponível para Aurora edição compatível com MySQL e Aurora edição compatível com PostgreSQL.

Para leituras globais de baixa latência e recuperação de desastres, recomendamos o uso do banco do Amazon Aurora Global Database.
O Aurora é compatível com a replicação lógica nativa em cada mecanismo de banco de dados (log binário para slots de replicação de MySQL e PostgreSQL para PostgreSQL), de maneira que você possa replicar para bancos de dados Aurora e externos ao Aurora, mesmo entre regiões.

O Aurora edição compatível com MySQL também oferece um recurso lógico de réplica de leitura entre regiões fácil de usar compatível com até cinco regiões da AWS secundárias. Essa replicação é baseada na replicação de log binário do MySQL com thread único, assim o atraso da replicação será influenciado pela taxa de alteração/aplicação e demoras na comunicação de rede entre as regiões específicas selecionadas.

Sim, você pode adicionar até 15 réplicas do Aurora em cada cluster entre regiões e elas compartilharão o mesmo armazenamento subjacente que a réplica entre regiões. Uma réplica entre regiões atua como a instância primária no cluster e as réplicas do Aurora no cluster, geralmente, apresentam um atraso de dez milissegundos em relação à primária.

Sim, você pode promover a sua réplica entre regiões como a nova instância primária no console do Amazon RDS. Para replicação lógica (binlog), o processo de promoção costuma levar alguns minutos, dependendo da sua workload. A replicação entre regiões será interrompida quando você iniciar o processo de promoção.

Com o Amazon Aurora Global Database, você pode promover uma região secundária para receber workloads completas de leitura/gravação em menos de um minuto.

Sim. Você pode atribuir uma camada de prioridade de promoção para cada instância no seu cluster. Quando a instância principal falhar, o Amazon RDS promoverá a réplica com a maior prioridade como principal. Se duas ou mais Réplicas do Aurora compartilham a mesma prioridade, o Amazon RDS promove a réplica de maior tamanho. Se duas ou mais Réplicas do Aurora compartilham a mesma prioridade e tamanho, o Amazon RDS promove uma réplica arbitrária no mesmo nível de promoção.

Para obter mais informações sobre a lógica de failover, leia o Amazon Aurora User Guide (Guia do usuário do Amazon Aurora).

Sim, é possível modificar a camada de prioridade para uma instância a qualquer momento. Um failover não é acionado apenas com a modificação de camadas de prioridade.

É possível atribuir camadas de prioridade mais baixas a réplicas que você não deseja promover como a instância primária. No entanto, se as réplicas de prioridade mais alta no cluster não estiverem íntegras ou disponíveis por alguma razão, o Amazon RDS promoverá a réplica de prioridade mais baixa.

Você pode adicionar réplicas do Amazon Aurora. As réplicas do Aurora na mesma região da AWS compartilham o mesmo armazenamento subjacente da instância principal. Qualquer réplica do Aurora pode ser promovida a principal sem nenhuma perda de dados e, portanto, pode ser usada para melhorar a tolerância a falhas no caso de falha de uma instância do banco de dados primário.

Para aumentar a disponibilidade do banco de dados, basta criar de uma a 15 réplicas em qualquer uma das três zonas de disponibilidade, e o Amazon RDS as incluirá automaticamente na seleção de failover principal no caso de interrupção de um banco de dados. Você poderá usar o Amazon Aurora Global Database se quiser que seu banco de dados abranja várias regiões da AWS. Isso replicará seus dados sem impactos para a performance do banco de dados, fornecendo recuperação de desastres em caso de interrupções em toda a região.

O failover é controlado automaticamente pelo Amazon Aurora para que suas aplicações possam retomar as operações de banco de dados o mais rapidamente possível sem intervenção administrativa manual.

• Se você tiver uma réplica do Aurora na mesma zona de disponibilidade ou em outra, ao fazer o failover, o Aurora alterará o registro de nome canônico (CNAME) da sua instância de banco de dados para apontar para a réplica saudável que é promovida e se torna a nova principal. Normalmente, o failover é concluído em até 30 segundos. Para maior resiliência e failovers mais rápidos, considere usar o Amazon RDS Proxy, que se conecta automaticamente à instância de banco de dados de failover e, ao mesmo tempo, preserva as conexões da aplicação. O proxy torna os failovers transparentes para suas aplicações e reduz os tempos de failover em até 66%.
• Se você estiver executando o Aurora Sem Servidor v1 e a instância de banco de dados ou zona de disponibilidade ficar indisponível, o Aurora irá automaticamente recriar uma instância de banco de dados em outra zona de disponibilidade. O Aurora Serverless v2 funciona como provisionado para failover e outros recursos de alta disponibilidade. Para obter mais informações, consulte Aurora Sem Servidor v2 e alta disponibilidade. 
• Se você não tiver uma réplica do Aurora (ou seja, uma instância única) e não estiver executando o Aurora Sem Servidor, o Aurora tentará criar uma nova instância de banco de dados na mesma zona de disponibilidade da instância original. Essa substituição da instância original é realizada por meio do melhor esforço possível e pode ser que não seja concluída se, por exemplo, houver um problema que potencialmente afete a zona de disponibilidade.
  

Em caso de perda de conexão, o seu aplicativo deve tentar novamente fazer as conexões do banco de dados. A recuperação de desastre entre regiões é um processo manual em que você promove uma região secundária para receber workloads de leitura/gravação.

O Amazon Aurora detectará automaticamente um problema afetando a sua instância primária e acionará um failover. Se você estiver usando o Cluster Endpoint, suas conexões de leitura/gravação serão automaticamente redirecionadas para uma réplica do Amazon Aurora que será promovida como principal.

Além disso, o tráfego de leitura atendido pelas réplicas do Aurora será brevemente interrompido. Se você estiver usando o endpoint de leitor do cluster para direcionar seu tráfego de leitura para a réplica do Aurora, as conexões configuradas somente para leitura serão direcionadas para a réplica do Aurora recém-promovida até que o nó primário anterior seja recuperado como uma réplica.

Como as réplicas do Amazon Aurora compartilham o mesmo volume de dados que a instância primária na mesma região da AWS, praticamente não há atraso na replicação. Normalmente, observamos defasagens de dezenas de milissegundos.

Para a replicação entre regiões, o atraso de replicação logica baseada em logs binários pode aumentar indefinidamente com base na taxa de alteração/aplicação, bem como atrasos na comunicação da rede. No entanto, em condições normais, é comum um atraso na replicação de menos de um minuto. As réplicas entre regiões que usam o processo de replicação física do Amazon Aurora Global Database terão uma defasagem típica de menos de um segundo.

Sim, você pode configurar a replicação de logs binários entre uma instância do Aurora edição compatível com MySQL e um banco de dados MySQL externo. O outro banco de dados pode ser executado no Amazon RDS ou como um banco de dados autogerenciado na AWS ou completamente fora da AWS.

Se você estiver executando o Aurora edição 5.7 compatível com MySQL, considere configurar a replicação de logs binários baseada em GTID. Isso oferecerá consistência total para que a replicação não perca transações ou gere conflitos, mesmo após o failover ou um tempo de inatividade.

O Amazon Aurora Global Database é um recurso que permite que um único banco de dados do Amazon Aurora abranja várias regiões da AWS. Ele replica seus dados sem gerar impactos para a performance do banco de dados, permitindo leituras locais rápidas em cada região com latência típica de menos de um segundo, fornecendo recuperação de desastres em casos de interrupção em toda a região. No evento improvável de degradação ou interrupção regional, uma região secundária poderá ser promovida para oferecer recursos completos de leitura/gravação em menos de um minuto. Esse recurso está disponível para Aurora edição compatível com MySQL e Aurora edição compatível com PostgreSQL.

Você pode criar um Aurora Global Database com apenas alguns cliques no console do Amazon RDS. Alternativamente, você pode usar o kit de desenvolvimento de software (SDK) ou a AWS Command Line Interface (CLI) . Você precisa provisionar pelo menos uma instância por região no seu Amazon Aurora Global Database.

Você pode criar até cinco regiões secundárias para um Amazon Aurora Global Database.

Sim. Se o seu objetivo é analisar a atividade do banco de dados, considere o uso de auditoria avançada do Aurora, logs gerais e logs de consulta lenta, para evitar impactos na performance do banco de dados.

Não. Se a região primária ficar indisponível, você poderá remover uma região secundária manualmente de um Amazon Aurora Global Database e promovê-la para receber leituras e gravações completas. Você também precisará direcionar o aplicativo para a região recém-promovida.

Sim, todas as instâncias de banco de dados do Amazon Aurora devem ser criadas em uma VPC. Com a Amazon VPC, é possível definir uma topologia de rede virtual que lembra muito uma rede tradicional que você poderá operar no seu próprio datacenter. Isso oferece a você total controle sobre quem acessa seus bancos de dados do Amazon Aurora.

Sim. O Amazon Aurora usa SSL (AES-256) para proteger a conexão entre a instância de banco de dados e a aplicação. O Amazon Aurora permite criptografar bancos de dados usando chaves que você gerencia por meio do AWS Key Management Service (AWS KMS).

Em uma instância de banco de dados em execução com a criptografia do Amazon Aurora, os dados ociosos mantidos no armazenamento subjacente são criptografados, bem como os backups automáticos, as réplicas e os snapshots desses dados no mesmo cluster. A criptografia e a descriptografia são processadas de forma transparente. Para obter mais informações sobre o uso do AWS KMS com o Amazon Aurora, consulte o Amazon RDS User's Guide (Guia do usuário do Amazon RDS).

No momento, não há suporte para criptografia de uma instância do Aurora não criptografada. Para usar a criptografia do Amazon Aurora para um banco de dados descriptografado existente, crie uma nova instância de banco de dados com criptografia habilitada e migre seus dados para ela.

Os bancos de dados do Aurora devem ser acessados pela porta de banco de dados informada na criação do banco de dados. Isso fornece uma camada adicional de segurança para seus dados. Instruções detalhadas sobre como conectar ao seu banco de dados do Amazon Aurora são fornecidas no Guia de conectividade do Amazon Aurora.

Sim, as edições do Aurora compatíveis com MySQL e PostgreSQL são qualificadas pela HIPAA. Você pode usá-las para criar aplicações em conformidade com a HIPAA e armazenar informações relacionadas à saúde, inclusive Informações protegidas de saúde (PHI) nos termos de um Acordo de associado comercial (BAA) com a AWS. Se você já tiver um BAA assinado com a AWS, nenhuma ação adicional será necessária para começar a usar esses serviços nas contas cobertas pelo BAA. Para mais informações sobre como usar o AWS para criar aplicações em conformidade, consulteProvedores de serviços de saúde.

No momento, essa lista de CVEs pode ser encontrada em Atualizações de segurança do Amazon Aurora.

O Aurora é integrado ao Amazon GuardDuty para ajudar você a identificar ameaças potenciais aos dados armazenados em bancos de dados Aurora. O GuardDuty RDS Protection monitora e cria perfis da atividade de login em bancos de dados novos na sua conta e usa modelos de ML para detectar logins suspeitos em bancos de dados do Aurora. Para obter mais informações, consulte Monitorar ameaças com o GuardDuty RDS Protection e o Guia do usuário do GuardDuty RDS Protection.

O Aurora Serveless é uma configuração com escalabilidade automática e sob demanda do Amazon Aurora. Com o Aurora Serveless, você pode executar seu banco de dados na nuvem sem gerenciar a capacidade do banco de dados. O gerenciamento manual da capacidade do banco de dados pode ser demorado e levar ao uso ineficiente dos recursos do banco de dados. Com o Aurora Serveless, você cria um banco de dados, especifica o intervalo da capacidade desejada para o banco de dados e conecta suas aplicações. O Aurora ajusta automaticamente a capacidade dentro do intervalo especificado com base nas necessidades de sua aplicação.

Você paga por segundo pela capacidade do banco de dados que usa quando o banco de dados está ativo. Saiba mais sobre o Aurora Serveless  e comece a usá-lo em apenas algumas etapas no Console de Gerenciamento do Amazon RDS.

O Aurora Sem Servidor v2 oferece suporte a todo tipo de workload de banco de dados, desde ambientes de desenvolvimento e teste, sites e aplicações com workloads pouco frequentes, intermitentes ou imprevisíveis, até aplicações mais exigentes e essenciais aos negócios que exigem uma escala elevada e alta disponibilidade. Ele reduz a escala horizontalmente no local adicionando mais CPU e memória sem precisar fazer failover do banco de dados para uma instância de banco de dados maior ou menor. Como resultado, pode ser escalado mesmo quando há transações de longa duração, bloqueios de tabela e muito mais.

Além disso, ele escala a capacidade do banco de dados em incrementos tão pequenos quanto 0,5 da Unidade de capacidade do Aurora (ACU) para que a capacidade do banco de dados corresponda às necessidades de sua aplicação.

O Aurora Serverless v1 é uma opção relativamente simples e econômica para workloads pouco frequentes, intermitentes ou imprevisíveis. Ele é inicializado automaticamente, escala a capacidade computacional para corresponder ao uso de sua aplicação e é desligado quando não está em uso. Para saber mais, acesse o Guia do usuário do Aurora.

O Aurora Serverless v2 oferece suporte a todos os recursos do Aurora provisionado, incluindo réplicas de leitura, configuração multi-AZ, Aurora Global Database, RDS Proxy e Insights de Performance.

Sim, você pode começar a usar o Aurora Serverless v2 para gerenciar a capacidade computacional do banco de dados em seu cluster de banco de dados do Aurora existente. Um cluster que contém as instâncias provisionadas e o Aurora Serverless v2 é chamado de cluster de configuração mista. Você pode optar por ter qualquer combinação de instâncias provisionadas e Aurora Serverless v2 em seu cluster.

Para testar o Aurora Serverless v2, adicione um leitor ao cluster de banco de dados do Aurora e selecione Serverless v2 como o tipo de instância. Depois que o leitor for criado e estiver disponível, você poderá começar a usá-lo para workloads de somente leitura. Depois de confirmar que o leitor está funcionando conforme o esperado, você pode iniciar um failover para começar a usar o Aurora Serverless v2 para leituras e gravações. Essa opção oferece uma experiência mínima de tempo de inatividade para começar a usar o Aurora Sem Servidor v2.

Sim, você pode migrar do Aurora Sem Servidor v1 para o Aurora Sem Servidor v2. Para saber mais, consulte o Guia do usuário do Aurora.

As informações sobre a compatibilidade do Aurora Sem Servidor v1 podem ser encontradas aqui. As informações sobre a compatibilidade do Aurora Sem Servidor v2 podem ser encontradas aqui.

Sim. Você pode restaurar um snapshot obtido de um cluster provisionado existente do Aurora para um cluster de banco de dados do Aurora Servidor e vice-versa.

Acesse um cluster de banco de dados do Aurora Sem Servidor de uma aplicação de cliente que esteja em execução na mesma VPC. Não é possível associar um endereço IP público a um cluster de banco de dados do Aurora Sem Servidor.

Embora o Aurora Sem Servidor escale automaticamente de acordo com a workload ativa do banco de dados, em alguns casos, pode ser que a capacidade não escale com velocidade suficiente para atender a uma mudança repentina da workload, como um grande número de novas transações. Nesses casos, você pode definir explicitamente a capacidade para um valor específico no Console de Gerenciamento da AWS, na AWS CLI ou na API do Amazon RDS.

Após o início de uma operação de escalabilidade, o Aurora Sem Servidor tenta encontrar um ponto de alteração de escala, que é um momento no qual o banco de dados pode concluir a alteração de escala com segurança. Se você tiver consultas com execução demorada, transações em andamento ou bloqueios temporários em tabelas ou tabelas temporárias, pode ser que o Aurora Sem Servidor não encontre um ponto de alteração de escala.

No Aurora Serverless, a capacidade do banco de dados é medida em ACUs. Você paga uma taxa fixa por segundo de uso do ACU. Os custos de computação para executar as workloads no Aurora Sem Servidor dependerão da configuração do cluster de banco de dados que você escolher: Aurora Standard ou Aurora I/O-Optimized. Acesse a página de preços do Aurora para obter informações sobre os preços e a disponibilidade regional.

O Amazon Aurora Optimized Reads, disponível para Aurora PostgreSQL, é uma nova opção de preço/performance que oferece latência de consulta até 8 vezes maior e economia de custos de até 30% em comparação com instâncias sem ele. Ele é ideal para aplicações com grandes conjuntos de dados que excedem a capacidade de memória de uma instância de banco de dados.

As instâncias do Amazon Aurora Optimized Reads usam armazenamento SSD local em nível de bloco baseado em NVMe (disponível em instâncias r6gd baseadas em Graviton e r6id baseadas em Intel) para melhorar a latência de consulta de aplicações com conjuntos de dados que excedem a capacidade de memória de uma instância de banco de dados. O Optimized Reads incluei aprimoramentos de performance, como armazenamento em cache hierárquico e objetos temporários.

O armazenamento em cache hierárquico oferece latência de consulta até 8 vezes maior e economia de custos de até 30% para aplicações com leituras pesadas e uso intenso de E/S, como painéis operacionais, detecção de anomalias e pesquisas de semelhanças com base em vetores. Esses benefícios são obtidos por meio do armazenamento em cache automático dos dados removidos do cache de buffer do banco de dados na memória para o armazenamento local, a fim de acelerar os acessos subsequentes desses dados. O cache hierárquico somente está disponível para o Amazon Aurora PostgreSQL-Edition com a configuração otimizada para E/S do Aurora.

Objetos temporários alcançam um processamento de consultas mais rápido ao colocar tabelas temporárias geradas pelo Aurora PostgreSQL no armazenamento local, melhorando a performance de consultas que envolvem classificações, agregações de hash, junções de alta carga e outras operações com uso intenso de dados.

O Amazon Aurora Optimized Reads para Aurora PostgreSQL oferece a clientes que possuem aplicações sensíveis à latência e conjuntos de trabalho grandes, uma alternativa atraente de preço/performance para atender aos SLAs de seus negócios e aproveitar ainda mais suas instâncias.

O Amazon Aurora Optimized Reads está disponível em instâncias R6id baseadas em Intel e R6gd baseadas em Graviton. É possível ver a disponibilidade do Aurora por região aqui.

O Amazon Aurora Optimized Reads está disponível para a edição compatível com PostgreSQL do Aurora em instâncias R6id e R6gd. As versões de mecanismo com suporte são 15.4 e superiores e 14.9 e superiores no Aurora PostgreSQL.

O Amazon Aurora Optimized Reads não está disponível no Aurora Serverless v2 (ASv2).

Sim, o Amazon Aurora Optimized Reads está disponível com ambas as configurações. Em ambas as configurações, as instâncias habilitadas para o Optimized Reads mapeiam automaticamente tabelas temporárias para o armazenamento local baseado em NVMe para melhorar a performance de consultas analíticas e reconstruções de índices.

Para workloads com uso intenso de E/S e leitura pesada, as instâncias otimizadas habilitadas para Optimized Reads no Aurora PostgreSQL configuradas para usar a configuração Otimizada para E/S do Aurora armazenam automaticamente os dados removidos da memória no armazenamento local baseado em NVMe para oferecer latência de consulta até 8 vezes maior e até 30% de economia em comparação com instâncias que não utilizam esse recurso, para aplicações com conjuntos de dados grandes que excedem a capacidade de memória de uma instância de banco de dados.

Os clientes podem começar a usar o Amazon Aurora Optimized Reads por meio do Console de Gerenciamento da AWS, da CLI e do SDK. O Optimized Reads está disponível em todas as instâncias R6id e R6gd por padrão. Para usar esse recurso, os clientes podem simplesmente modificar seus clusters de banco de dados do Aurora existentes para incluir instâncias R6id e R6gd ou criar novos clusters de banco de dados usando essas instâncias. Consulte a documentação do Amazon Aurora Optimized Reads para começar.

Cerca de 90% do armazenamento local disponível nas instâncias R6id e R6gd está disponível para o Optimized Reads. O Aurora reserva 10% do armazenamento NVMe para reduzir o impacto da amplificação de gravação em SSD. A alocação do armazenamento disponível depende de quais atributos do Optimized Reads estão habilitados.

Ao usar i Optimized Reads com os atributos Objetos temporários e Armazenamento em cache hierárquico, o espaço disponível para objetos temporários no armazenamento local é equivalente a duas vezes o tamanho da memória disponível nessas instâncias de banco de dados. Isso corresponde ao tamanho atual do armazenamento temporário de objetos no Aurora PostgreSQL. O espaço em disco de armazenamento local restante está disponível para armazenar dados em cache.

Ao usar o Optimized Reads somente com o atributo Objetos temporários, todo o espaço em disco de armazenamento local disponível fica disponível para objetos temporários. Por exemplo, ao usar uma instância r6gd.8xlarge com os atributos Objetos temporários e Armazenamento em cache hierárquico, 534 GiB (capacidade de memória 2x) são reservados para objetos temporários e 1054 GiB para cache hierárquico.

Se o armazenamento local falhar, o Aurora executará automaticamente a substituição do host. Em um cluster de banco de dados de vários nós, isso aciona um failover na região.

No caso de um failover do banco de dados, a latência da consulta aumentará temporariamente após o failover. Esse aumento de latência diminuirá com o tempo e, eventualmente, alcançará a latência da consulta antes do failover. Essa duração de recuperação pode ser acelerada habilitando o gerenciamento de cache de cluster (CCM). Com o CCM, os clientes podem designar uma instância específica do banco de dados Aurora PostgreSQL como o destino do failover.

Quando o CCM está habilitado, o cache de armazenamento local do destino de failover designado reflete de perto o cache de armazenamento local da instância primária, reduzindo o tempo de recuperação após o failover. No entanto, a habilitação do CCM poderá afetar a eficácia a longo prazo do cache de armazenamento local se o destino de failover designado também estiver sendo usado para atender a uma workload de leitura separada da workload na instância do gravador.

Portanto, os clientes que executam workloads que exigem que um leitor seja designado como o failover em espera devem permitir que o CCM aumente a probabilidade de recuperar rapidamente a latência da consulta após o failover. Os clientes que executam workloads separadas em seus destinos de failover designados podem querer equilibrar suas necessidades de recuperação imediata de latência após o failover com a eficácia de longo prazo da performance do cache, antes de habilitar o CCM.

O pgvector é uma extensão de código aberto para PostgreSQL com suporte para o Amazon Aurora edição compatível com PostgreSQL.

Sim. O machine learning (ML) do Aurora expõe modelos de ML como funções SQL, permitindo que você use o SQL padrão para chamar modelos de ML, transmitir dados para eles e retornar previsões como resultados de consulta. O pgvector requer que as incorporações vetoriais sejam armazenadas no banco de dados, o que exige a execução do modelo de ML em dados de texto ou imagem de origem para gerar incorporações e migrá-las em lote para o Aurora PostgreSQL.

O Aurora ML pode transformar esse processo em tempo real, permitindo que as incorporações sejam mantidas atualizadas no Aurora PostgreSQL fazendo chamadas periódicas para o Amazon Bedrock ou o Amazon SageMaker que retorna as incorporações mais recentes do seu modelo.

O Amazon Aurora PostgreSQL Optimized Reads com pgvector aumenta as consultas por segundo para pesquisa vetorial em até 9 vezes em workloads que excedem a memória de instância disponível. Isso é possível devido ao recurso de armazenamento em cache hierárquico disponível no Optimized Reads, que armazena automaticamente os dados removidos do cache de buffer do banco de dados na memória para o armazenamento local a fim de acelerar os acessos subsequentes desses dados.

Você deve usar a Integração ETL zero do Amazon Aurora com o Amazon Redshift quando precisa de acesso quase em tempo real a dados transacionais. Essa integração permite que você aproveite o Amazon Redshift ML com comandos SQL simples.

A Integração ETL zero do Aurora com o Amazon Redshift está disponível na edição compatível com Aurora MySQL do Aurora MySQL 3.05 (compatível com o MySQL 8.0.32) e superior nas regiões Leste dos EUA (Ohio), Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Ásia-Pacífico (Tóquio), Ásia-Pacífico (Singapura), Ásia-Pacífico (Sydney), Europa (Irlanda), Europa (Frankfurt) e Europa (Estocolmo). A Integração ETL zero do Aurora com o Amazon Redshift está disponível na edição compatível com Aurora PostgreSQL para o Aurora PostgreSQL 15.4 na região Leste dos EUA (Ohio).

A integração ETL zero do Aurora com o Amazon Redshift elimina a necessidade de criar e manter pipelines de dados complexos. Você pode consolidar dados de um ou vários clusters do banco de dados do Aurora em um único cluster de banco de dados do Amazon Redshift e executar análises e ML quase em tempo real usando o Amazon Redshift em petabytes de dados transacionais do Aurora. 

A Integração ETL zero do Aurora com o Amazon Redshift é compatível com o Aurora sem Servidor v2. Ao usar o Amazon sem Servidor v2 e o Amazon Redshift sem Servidor, você pode gerar análises quase em tempo real sobre dados transacionais sem precisar gerenciar infraestruturas de pipelines de dados.

Você pode começar usando o console do Amazon RDS para criar a Integração ETL zero especificando a origem do Aurora e o destino do Amazon Redshift. Depois que a integração for criada, o banco de dados do Aurora será replicado para o Amazon Redshift, e você poderá começar a consultar os dados assim que a propagação inicial for concluída. Para obter mais informações, leia o guia de introdução das Integrações ETL zero do Aurora com o Amazon Redshift.

O processamento contínuo e de ETL zero de alterações de dados é oferecido sem custos adicionais. Você paga pelos recursos existentes do Amazon RDS e do Amazon Redshift usados para criar e processar os dados de alterações gerados como parte de uma Integração ETL zero. Esses recursos podem incluir:

• E/S e armazenamento adicionais usados ao habilitar o binlog avançado
• Custos de exportação de snapshots para a exportação inicial de dados a fim de propagar seus bancos de dados do Amazon Redshift
• Armazenamento adicional do Amazon Redshift para armazenar dados replicados
• Custos de transferência de dados entre AZs para mover dados da origem para o destino

Para obter mais informações, acesse a página de preços do Aurora.

O Amazon DevOps Guru para RDS é uma nova funcionalidade com a tecnologia de ML para o Amazon RDS (o que inclui o Amazon Aurora) desenvolvida para detectar e diagnosticar automaticamente problemas operacionais e de performance do banco de dados, permitindo que você solucione problemas em minutos em vez de dias.

O Amazon DevOps Guru para RDS é um recurso do Amazon DevOps Guru que detecta problemas operacionais e de performance em todos os mecanismos do Amazon RDS e em dezenas de outros tipos de recurso. O DevOps Guru para RDS amplia as capacidades do DevOps Guru para detectar, diagnosticar e remediar vários problemas relacionados a bancos de dados no Amazon RDS (como, por exemplo, a utilização excessiva de recursos e o comportamento indevido de determinadas consultas SQL).

Quando ocorre um problema, o Amazon DevOps Guru para RDS é projetado para notificar desenvolvedores e engenheiros de DevOps imediatamente e fornecer informações de diagnóstico, detalhes sobre a extensão desse problema e recomendações de remediação inteligentes para ajudar os clientes a resolver rapidamente gargalos de performance e problemas operacionais relacionados ao banco de dados.

O Amazon DevOps Guru para RDS foi projetado para eliminar o esforço manual e reduzir o tempo (de horas e dias para minutos) para detectar e resolver gargalos de performance difíceis de encontrar na workload de banco de dados relacional.

Você pode habilitar o DevOps Guru para RDS para cada banco de dados do Amazon Aurora e ele detectará automaticamente problemas de performance em suas workloads, enviará alertas sobre cada problema, explicará as descobertas e recomendará ações para solucioná-los.
O DevOps Guru para RDS ajuda a tornar a administração de banco de dados mais acessível para usuários comuns e auxilia especialistas em banco de dados para que possam gerenciar ainda mais bancos de dados.

O Amazon DevOps Guru para RDS usa ML para analisar dados de telemetria coletados pelo recurso Insights de Performance do Amazon RDS (PI). O DevOps Guru para RDS não usa nenhum dos seus dados armazenados no banco de dados em sua análise. O PI mede a carga do banco de dados, uma métrica que caracteriza como uma aplicação passa o tempo no banco de dados e as métricas selecionadas geradas pelo banco de dados, como variáveis de status do servidor no MySQL e tabelas pg_stat no PostgreSQL.

Para começar a usar o DevOps Guru para RDS, certifique-se de que o recurso Insights de Performance esteja habilitado no console do RDS. Em seguida, basta habilitar o DevOps Guru para os seus bancos de dados do Amazon Aurora. Com o DevOps Guru, você pode escolher seu limite de cobertura de análise como toda a sua conta da AWS, prescrever as pilhas específicas do AWS CloudFormation que deseja que o DevOps Guru analise ou usar as etiquetas da AWS para criar o agrupamento de recursos que deseja que o DevOps Guru analise.

O Amazon DevOps Guru para RDS ajuda a identificar uma ampla variedade de problemas de performance que podem afetar a qualidade do serviço de aplicações, como empilhamento de bloqueios, tempestades de conexão, regressões de SQL, contenção de CPU e E/S e problemas de memória.

O Insights de Performance do Amazon RDS é um recurso de ajuste e monitoramento de performance que coleta e visualiza métricas de performance de bancos de dados do Amazon RDS, ajudando você a avaliar rapidamente a carga do seu banco de dados, além de determinar quando e onde agir. O Amazon DevOps Guru para RDS foi projetado para monitorar essas métricas, detectar quando seu banco de dados enfrenta problemas de performance, analisar as métricas e, em seguida, dizer o que está errado e o que deve ser feito.

Você deve usar a API de dados para novos aplicativos modernos, especialmente os criados com o AWS Lambda, que precisam acessar o Aurora em um modelo de solicitação/resposta. Você deve usar drivers de banco de dados em vez da API de dados e gerenciar conexões de banco de dados persistentes quando um aplicativo existente está altamente acoplado a drivers de banco de dados, quando há consultas de longa duração ou quando o desenvolvedor deseja aproveitar os atributos do banco de dados, como tabelas temporárias, ou caso as variáveis de sessão sejam utilizadas.

A disponibilidade da região da AWS e da versão do banco de dados da API de dados para instâncias provisionadas do Aurora Serverless v2 e do Aurora pode ser encontrada em nossa documentação. Recomenda-se aos clientes que atualmente usam a API de dados para o Aurora Serverless v1 a migrar para o Aurora Serverless v2, para aproveitar a API de dados redesenhada e o dimensionamento mais granular do Aurora Serverless v2.

A API de dados permitirá que você simplifique e acelere o desenvolvimento moderno de aplicativos. A API de dados é uma API baseada em HTTP segura e fácil de usar que elimina a necessidade de implantar drivers de banco de dados, de gerenciar pools de conexões do lado do cliente ou de configurar redes VPC complexas entre o aplicativo e o banco de dados. A API de dados também melhora a escalabilidade ao agrupar e compartilhar automaticamente conexões de banco de dados, o que reduz a sobrecarga computacional de aplicativos que abrem e fecham conexões com frequência. 

A API de dados existente para o Aurora Serverless v1 continuará sendo um atributo do Aurora Serverless v1 tanto para a edição compatível com PostgreSQL quanto para a edição compatível com MySQL do Aurora. A API de dados para instâncias provisionadas do Aurora Serverless v2 e do Aurora não oferece suporte ao Aurora Serverless v1. A API de dados para instâncias provisionadas do Aurora Serverless v2 e do Aurora oferece suporte às instâncias de gravação do Aurora Global Database.

Os usuários podem invocar as operações da API de dados somente se tiverem a permissão necessária. Os administradores podem conceder permissão ao usuário para usar a API de dados mediante a anexação de uma política do AWS Identity and Access Management (IAM) que define seus privilégios. Você também pode anexar a política a um perfil, se estiver usando perfis do IAM. Ao realizar uma chamada de API de dados, você pode autorizar credenciais para o cluster de banco de dados Aurora usando um código no AWS Secrets Manager. 

O uso da API de dados com o Aurora Serverless v1 permanece disponível sem custo adicional. A API de dados para instâncias provisionadas do Aurora Serverless v2 e do Aurora é calculada pelo volume de solicitações da API, conforme descrito na página de preços do Aurora. A API de dados para instâncias provisionadas do Aurora Serveless v2 e do Aurora usa eventos do plano de dados do AWS CloudTrail para registrar atividades em vez de eventos de gerenciamento, da mesma forma que é feito na API de dados para Aurora Serverless v1.

Você pode ativar o registro de eventos de dados por meio do console, da CLI ou do SDK do CloudTrail, caso queira acompanhar essa atividade. Isso incorrerá em cobranças conforme estabelecido na página de preços do CloudTrail. Além disso, o uso do AWS Secrets Manager incorrerá em cobranças conforme estabelecido na página de preços do AWS Secrets Manager. 

O AWS CloudTrail captura a atividade da API da AWS como eventos de gerenciamento ou eventos de dados. Os eventos de gerenciamento do CloudTrail (também conhecidos como “operações do ambiente de gerenciamento”) mostram operações de gerenciamento realizadas nos recursos da sua conta da AWS, como criar, atualizar e excluir um recurso. Os eventos de dados do CloudTrail (também conhecidos como “operações do plano de dados”) mostram as operações de recursos realizadas no recurso ou entre um recurso na conta da AWS.

A API de dados executa operações no plano de dados, uma vez que as consultas são realizadas em dados do seu banco de dados Aurora. Portanto, registraremos a atividade da API de dados como eventos de dados, pois essa é a categorização correta dos eventos. As cobranças só serão realizadas por eventos de dados do CloudTrail caso o log de eventos de dados seja ativado.

Sim, a versão gratuita da API de dados inclui um milhão de solicitações por mês, agregadas em todas as regiões da AWS, para o primeiro ano de uso. Depois de um ano, os clientes começarão a pagar pela API de dados conforme descrito na página de preços do Aurora.

As implantações azuis/verdes do Amazon RDS estão disponíveis nas versões 5.6 e superior do Amazon Aurora, edição compatível com MySQL, e nas versões 11.21 e superiores, 12.16 e superiores, 13.12 e superiores, 14.9 e superiores e 15.4 e superiores do Amazon Aurora, edição compatível com PostgreSQL. Saiba mais sobre as versões disponíveis na documentação do Aurora.

As implantações azuis/verdes do Amazon RDS estão disponíveis em todas as regiões da AWS aplicáveis e nas regiões AWS GovCloud.

As implantações azuis/verdes do Amazon RDS permitem que você faça alterações mais seguras, simples e rápidas no banco de dados. As implantações azuis/verdes são ideais para casos de uso como atualizações do mecanismo de banco de dados de versões principais ou secundárias, atualizações do sistema operacional, alterações de esquema em ambientes verdes que não interrompem a replicação lógica, como adicionar uma nova coluna no final de uma tabela ou alterações na configuração dos parâmetros do banco de dados.

Você pode usar implantações azuis/verdes para fazer várias atualizações de banco de dados ao mesmo tempo usando uma única transição. Isso permite ficar em dia sobre os patches de segurança, melhorar a performance do banco de dados e acessar novos atributos do banco de dados com um tempo de inatividade curto e previsível. Se você deseja realizar apenas uma pequena atualização de versão no Aurora, recomendamos que usar o Aurora Zero Downtime Patching (ZDP).

Você pagará o mesmo preço se executar suas workloads em instâncias verdes ou azuis. O custo de execução em instâncias verdes e azuis inclui o nosso preço padrão atual para instâncias de bancos de dados, custo de armazenamento, custo de leitura/gravação de E/S e todos os recursos habilitados, como o custo de backups e de Insights de Performance do Amazon RDS. Efetivamente, você paga aproximadamente o dobro do custo de execução de workloads em uma instância de banco de dados pela vida útil de uma implantação azul/verde.

Por exemplo, você tem um cluster Aurora edição compatível com MySQL 5.7 em execução em duas instâncias r5.2xlarge, uma instância primária de gravação e uma instância de leitura na região us-east-1 da AWS. Cada uma das instâncias r5.2xlarge está configurada para 40 GiB de armazenamento e tem 25 milhões de E/S por mês. Você cria um clone da topologia da instância azul usando implantações azuis/verdes do Amazon RDS, executa-a durante 15 dias (360 horas) e cada instância verde tem 3 milhões de leituras de E/S durante esse tempo. Em seguida, você exclui as instâncias azuis após uma transição bem-sucedida. As instâncias azuis (leitura e gravação) custam USD 849,20 por 15 dias a uma taxa sob demanda de USD 1,179/hora (instância + armazenamento + E/S). As instâncias verdes (leitura e gravação) custam USD 840,40 por 15 dias a uma taxa sob demanda de USD 1,167/hora (instância + armazenamento + E/S). O custo total de uso de implantações azuis/verdes durante esses 15 dias é de USD 1689,60, o que é aproximadamente o dobro da execução em instâncias azuis nesse período.

As Implantações azuis/verdes do Amazon RDS ajudam você a fazer alterações no banco de dados de forma mais segura, simples e rápida, como atualizações de versão principal ou secundária, alterações de esquema, escalonamento de instâncias, alterações de parâmetro do mecanismo e atualizações de manutenção.

Em implantações azuis/verdes do Amazon RDS, o ambiente azul é o seu ambiente de produção atual. O ambiente verde é seu ambiente de preparação que se tornará seu novo ambiente de produção após a transição.

Quando as implantações azuis/verdes do Amazon RDS iniciam uma transição, a gravação é bloqueada em ambos os ambientes, verde e azul, até que a transição seja concluída. Durante a transição, o ambiente de preparação, ou ambiente verde, é atualizado com o sistema de produção, garantindo que os dados estão consistentes entre os ambientes de produção e preparação. Assim que os ambientes de produção e preparação estiverem em total sincronia, as implantações azuis/verdes promoverão o ambiente de preparação como o novo ambiente de produção, redirecionando o tráfego para o ambiente de produção recém-promovido.

As Implantações azuis/verdes do Amazon RDS são projetadas para habilitar a gravação no ambiente verde após a conclusão da transição, garantindo que não houve perda de dados durante o processo.

As implantações azuis/verdes do Amazon RDS não excluem o seu ambiente de produção antigo. Se for necessário, você poderá acessá-lo para validações adicionais e testes de performance/regressão. Se você não precisar mais do seu ambiente de produção antigo, você poderá excluí-lo. Instâncias de produção antigas serão cobradas de acordo com a taxa padrão até que sejam excluídas.

Se seu ambiente azul for uma réplica lógica autogerenciada ou um assinante, bloquearemos a transição. Recomendamos que você primeiro interrompa a replicação para o ambiente azul, continue com a transição e, em seguida, retome a replicação. Por outro lado, se o seu ambiente azul for uma fonte para uma réplica lógica autogerenciada ou publicador, você poderá continuar a fazer a transição. No entanto, você precisará atualizar a réplica autogerenciada para replicá-la do ambiente verde após a transição.

Não, as implantações azuis/verdes do Amazon RDS não oferecem suporte a bancos de dados globais do Amazon Aurora, ao Amazon RDS Proxy ou a réplicas de leitura entre regiões.

Não, no momento, você não pode usar implantações azuis/verdes do Amazon RDS para reverter alterações.

O Trusted Language Extensions (TLE) para PostgreSQL permite que os desenvolvedores para criar extensões de alta performance do PostgreSQL e as executem com segurança no Amazon Aurora. Ao fazer isso, a TLE melhora o seu tempo de introdução no mercado e elimina a carga imposta aos administradores de banco de dados para certificar códigos personalizados e de terceiros para uso em workloads de banco de dados de produção. Você pode prosseguir assim que decidir que uma extensão atende às suas necessidades. Com o TLE, os provedores de software independentes (ISVs) podem fornecer novas extensões do PostgreSQL aos clientes que executam no Aurora.

O TLE para PostgreSQL está disponível para Amazon Aurora edição compatível com PostgreSQL nas versões 14.5 e superiores. O TLE é implementado como uma extensão PostgreSQL em si e você pode ativá-lo pela função rds_superuser similar a outras extensões compatíveis com o Aurora.

Você pode executar o TLE para PostgreSQL no PostgreSQL 14.5 ou superior no Amazon Aurora.

O TLE para PostgreSQL está disponível em todas as regiões da AWS (exceto Regiões da AWS na China) e na AWS GovCloud.

O TLE para PostgreSQL está disponível para clientes do Aurora sem custo adicional.

O Aurora e o Amazon RDS oferecem compatibilidade para uma lista selecionada de 85 extensões para PostgreSQL. A AWS gerencia os riscos de segurança para cada uma dessas extensões no âmbito do Modelo de Responsabilidade Compartilhada da AWS. A extensão que implementa o TLE para PostgreSQL está incluída nessa lista. As extensões que você escreve ou obtém de terceiros e instala em TLE são consideradas como parte do código da sua aplicação. Você é responsável pela segurança das suas aplicações que usam extensões TLE.

Você pode criar funções de desenvolvedor, como compressão de bitmap e privacidade diferencial (como consultas estatísticas com acesso público que protegem a privacidade de indivíduos).

No momento, o TLE para PostgreSQL é compatível com JavaScript, PL/pgSQL, Perl e SQL.

Assim que a função rds_superuser ativa o TLE para PostgreSQL, você pode implantar as extensões do TLE usando o comando SQL CREATE EXTENSION de qualquer cliente PostgreSQL, como o psql. É semelhante à forma como você cria uma função definida pelo usuário em uma linguagem procedural como PL/pgSQL ou PL/Perl. Você pode controlar quais usuários tem permissão para implantar extensões TLE e usar extensões específicas.

O TLE para PostgreSQL só pode acessar o banco de dados PostgreSQL por meio da API TLE. As linguagens compatíveis com TLE incluem todas as funções da interface de programação do servidor (SPI) do PostgreSQL e PostgreSQL hooks, incluindo o de verificação de senha.

Você pode saber mais sobre o projeto do TLE para PostgreSQL na página oficial do TLE no GitHub.