Perguntas frequentes sobre o Amazon Aurora

O Amazon Aurora é um serviço de banco de dados relacional moderno que oferece desempenho e alta disponibilidade em grande escala, edições compatíveis com MySQL e PostgreSQL totalmente em código aberto e uma variedade de ferramentas para desenvolvimento de aplicações sem servidor e orientadas por 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é 256 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 fornece 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.

Consulte as informações de compatibilidade da versão atual do Amazon Aurora MySQL 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 ele para tratar de questões específicas sobre o Aurora.

O Amazon Aurora é totalmente compatível com os bancos de dados de código aberto PostgreSQL existentes e oferece suporte para novos lançamentos regularmente. Assim, você pode migrar facilmente bancos de dados PostgreSQL entrando e saindo do Aurora usando ferramentas padrão de importação e 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 no Aurora com pouca ou nenhuma alteração.

Consulte as informações de compatibilidade da versão atual do Amazon Aurora PostgreSQL na documentação.

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

Consulte a disponibilidade do Aurora por região aqui.

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 atributo 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 do SQL Server para o Amazon Aurora edição compatível com PostgreSQL, é possível 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.

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 atributo de migração do snapshot de banco de dados do Amazon RDS para transferir um snapshot de banco de dados do Amazon RDS para MySQL ao 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 obter mais informações, consulte Best Practices for Migrating MySQL Databases to Amazon Aurora.

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/seg, cinco vezes mais que o MySQL, executando o mesmo teste comparativo no mesmo hardware. Consulte as instruções detalhadas sobre esse parâmetro comparativo e como replicá-lo no Guia de avaliações comparativas de desempenho 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. Consulte as instruções detalhadas sobre esse parâmetro comparativo e como replicá-lo no Guia de avaliações comparativas de desempenho do Amazon Aurora, edição compatível com PostgreSQL.

O Amazon Aurora é projetado para ser compatível com o MySQL, de forma 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 workload no Amazon Aurora, recomendamos que você desenvolva as aplicações para gerar um grande número de consultas simultâneas.

O Amazon Aurora foi criado para ser compatível com o PostgreSQL a fim de permitir a execução de aplicações e ferramentas atuais do PostgreSQL sem 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 workload no Amazon Aurora, recomendamos que você desenvolva as aplicações para gerar um grande número de consultas simultâneas.

Consulte a página de preços do Aurora para obter 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. Não há cobranças pelos snapshots durante o período de retenção de backup que você configurou para o cluster de banco de dados.

Sim, você pode comprar um Savings Plans para banco de dados para usar o Amazon Aurora e reduzir seus custos em até 35% ao se comprometer com uma quantidade consistente de uso por um período de 1 ano. Mais informações sobre o uso qualificado podem ser encontradas na página de preços do Savings Plans para bancos de dados.

Não, a replicação do Aurora está incluída no preço. A cobrança é feita com base no armazenamento consumido pelo seu banco de dados na camada 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 criado para remover operações de E/S desnecessárias, de modo a reduzir custos e garantir a disponibilidade de recursos para atender ao tráfego de leitura e 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. Serão feitas cobranças pelas operações de E/S de leitura e gravação ao configurar os clusters de banco de dados com a configuração Aurora Standard. Não serão feitas cobranças pelas operações de E/S de leitura e gravação ao configurar os 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. Retorne 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 GiB. Com base na utilização do banco de dados, seu armazenamento do Aurora aumentará automaticamente até 256 TiB, em incrementos de 10 GiB, sem afetar o desempenho do banco de dados. Não é necessário provisionar o armazenamento antecipadamente. O Aurora oferece escalabilidade horizontal automatizada com o Amazon Aurora PostgreSQL Limitless Database, que escala o armazenamento além de 256 TiB. Para saber mais, acesse Como usar o Aurora PostgreSQL Limitless Database.

Existem três maneiras de escalar os recursos computacionais associados ao seu banco de dados do Amazon Aurora: usando o Amazon Aurora Serverless, o Aurora PostgreSQL Limitless Database ou com a escalabilidade manual. Independentemente da opção escolhida, você paga apenas pelo que usa.

Você pode usar o Aurora Serverless, uma configuração de escalabilidade automática sob demanda para o Aurora, para escalar recursos de computação de banco de dados com base nas demandas das aplicações. Ele ajuda você a executar seu banco de dados na nuvem sem se preocupar com o gerenciamento da capacidade do banco de dados. Especifique o intervalo de capacidade do banco de dados desejado, e seu banco de dados será escalado com base nas necessidades de sua aplicação. Leia mais no Guia do usuário do Aurora Serverless).

Com o Aurora PostgreSQL Limitless Database, você pode escalar automaticamente seus recursos de computação horizontalmente com base nas necessidades das suas workloads para oferecer suporte a aplicações em alta escala. Ele ajuda você a escalar suas aplicações além do throughput de gravação e dos limites de armazenamento de uma única instância de banco de dados, mantendo a simplicidade de operar em um único banco de dados. 

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 "Aplicar imediatamente" para alterar o tipo de instância de banco de dados imediatamente.

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 o desempenho do banco de dados.

Sim, e não há impacto no desempenho durante a criação de snapshots. Observe que restaurar dados de snapshots de bancos de dados exige a criação de uma instância de banco de dados.

O Amazon Aurora torna automaticamente 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 restaurar a partir de um snapshot do banco de dados ou realizar uma operação de restauração em um ponto anterior no tempo para uma nova instância. Observe que o último momento restaurável para uma operação de restauração em um ponto anterior no tempo pode ser de até cinco minutos atrás.

Você pode escolher criar um snapshot do banco de dados final ao excluir sua instância de banco de dados. Se fizer isso, pode usar este snapshot do banco de dados para restaurar a instância de banco de dados excluída posteriormente. O Amazon Aurora retém esse snapshot do banco de dados final criado pelo usuário junto com todos os outros snapshots de banco de dados criados manualmente após a instância de banco de dados ser excluída. Apenas DB snapshots são retidos depois da exclusão da instância de banco de dados (ou seja, os backups automáticos criados para restauração point-in-time 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).

Use esse atributo 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, poderão 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 os 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 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 continuamente em busca de erros e corrigidos automaticamente.

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 comprometimentos de desempenho.

As edições do Amazon Aurora compatíveis com MySQL e PostgreSQL são compatíveis com as 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 instância primária são reproduzidos na 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 principal no cluster e as réplicas do Aurora no cluster, geralmente, apresentam um atraso de dez milissegundos com relação à principal.

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 Guia do usuário do Amazon Aurora.

Sim, você pode 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 para réplicas que você não deseja promover para a instância principal. No entanto, se as réplicas de prioridade mais alta no cluster não estiverem saudáveis 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 o desempenho 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 enquanto preserva as conexões da aplicação. O proxy torna os failovers transparentes para as aplicações e reduz os tempos de failover em até 66%. 
• O Aurora Serverless v2 funciona como provisionado para failover e outros atributos de alta disponibilidade. Para obter mais informações, consulte Aurora Serverless 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 Serverless, 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 desastres 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 o 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.

Sim, você pode configurar a replicação de binlog 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 compatível com MySQL 5.7, considere configurar a replicação de binlog baseada em GTIDs. 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.

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.

O Amazon Aurora Global Database é um atributo que permite a um único banco de dados do Amazon Aurora abranger várias regiões da AWS. Ele replica seus dados sem gerar impacto para o desempenho 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 atributo está disponível para o 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. Ou você pode usar o Kit de Desenvolvimento de Software (SDK) ou a Interface da Linha de Comando (CLI) da AWS. Use uma configuração mista de tipos de classes de instâncias provisionadas ou sem servidor entre suas regiões primária e secundária. Também é possível configurar sua região primária como a configuração de cluster otimizada para E/S do Aurora e suas regiões secundárias como Aurora Standard ou vice-versa. Para saber mais, acesse Criar um 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 no desempenho do banco de dados.

Não. Se sua região principal ficar indisponível, você poderá usar a operação gerenciada de failover do Aurora Global Database entre regiões para promover uma região secundária a ter recursos completos de leitura e gravação. Você também pode usar o endpoint de gravador do Aurora Global Database para evitar a necessidade de fazer alterações no código da aplicação para se conectar à região recém-promovida. Para saber mais, acesse Conectar-se a um Amazon Aurora Global Database.

Sim, todas as instâncias de banco de dados do Amazon Aurora devem ser criadas em uma VPC. Com o 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 gerenciadas 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 Guia do usuário do Amazon RDS.

No momento, a criptografia de uma instância do Aurora não criptografada não tem suporte. 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 ativada e migre seus dados para ela.

Os bancos de dados do Aurora devem ser acessados pela porta do banco de dados informada na criação deles. Isso proporciona uma camada adicional de segurança para seus dados. Instruções detalhadas sobre como se conectar ao 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 obter mais informações sobre como criar aplicações em conformidade usando a AWS, consulte Provedores 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 possíveis ameaças aos dados armazenados em bancos de dados do 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 Serverless é uma configuração com ajuste de escala automático e sob demanda do Amazon Aurora. Com o Aurora Serverless, 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 ele estiver ativo. Saiba mais sobre o Aurora Serverless e comece a usá-lo em apenas algumas etapas no Console de Gerenciamento do Amazon RDS.

Informações sobre a compatibilidade do Aurora Serverless 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 Serverless 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 Serverless.

Embora o Aurora Serverless escale automaticamente de acordo com a workload ativa do banco de dados, a capacidade pode não escalar com velocidade suficiente para absorver uma mudança súbita 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 Serverless tenta encontrar um ponto de alteração de escala, que é o momento em que 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, o Aurora Serverless poderá não encontrar um ponto de alteração de escala.

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 Serverless v2.

O Aurora Serverless v2 é compatível com todos os atributos do Aurora provisionado, incluindo réplicas de leitura, configuração multi-AZ, Aurora Global Database, RDS Proxy e Insights de desempenho.

No Aurora Serverless, a capacidade do banco de dados é medida em unidades de capacidade do Aurora (ACUs). Você paga uma taxa fixa por segundo de uso do ACU. Os custos de computação para executar as workloads no Aurora Serverless 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 Aurora PostgreSQL Limitless Database fornece escalabilidade horizontal automatizada para processar milhões de transações de gravação por segundo e gerencia petabytes de dados, mantendo a simplicidade proporcionada pela operação em um único banco de dados. Você pode se concentrar na criação de aplicações de alta escala sem precisar criar e manter soluções complexas para escalar seus dados em várias instâncias de banco de dados para suportar suas workloads. O Aurora PostgreSQL Limitless Database é dimensionado com base na workload da sua aplicação e você paga somente pelo que a aplicação consome. Para saber mais, acesse o Guia do usuário do Aurora PostgreSQL Limitless Database.

Use o Aurora PostgreSQL Limitless Database para aplicações que precisam ser escaladas horizontalmente e exigem mais throughput de gravação ou capacidade de armazenamento de dados do que uma única instância de banco de dados do Aurora é capaz de suportar. Por exemplo, uma aplicação de contabilidade pode ser particionada horizontalmente por um usuário, pois os dados contábeis de cada usuário são independentes dos outros. O Aurora PostgreSQL Limitless Database é escalado automaticamente para oferecer suporte a suas aplicações maiores e de mais rápido crescimento. 

Existem dois atributos existentes para escalabilidade: Amazon Aurora Auto Scaling com réplicas do Aurora e Aurora Serverless v2.

As réplicas do Aurora permitem que você aumente a capacidade de leitura do seu cluster Aurora além dos limites do que uma única instância de banco de dados pode oferecer. As aplicações que conseguem separar a workload de leitura da workload de gravação podem se beneficiar de até 15 réplicas de leitura para obter um maior throughput geral de leitura. As réplicas do Aurora não exigem que a aplicação divida horizontalmente seus dados. Todos os dados estão disponíveis em cada réplica. As réplicas do Aurora não aumentam a capacidade de armazenamento de um cluster ou o throughput de gravação do Aurora.

O Aurora Serverless v2 é uma configuração de escalabilidade vertical sob demanda para o Aurora que fornece ajuste de escala automático da computação e da memória do banco de dados com base nas necessidades da aplicação dentro das restrições de capacidade de uma única instância de computação. O Aurora Serverless v2 é compatível com instâncias de gravador e leitor. No entanto, ele não aumenta a capacidade de armazenamento de um cluster do Aurora. Se sua aplicação foi projetada para escalar horizontalmente, o Aurora PostgreSQL Limitless Database permite escalar o throughput de gravação e a capacidade de armazenamento do seu banco de dados além dos limites de uma única instância de gravador do Aurora

O Aurora PostgreSQL Limitless Database divide dados em instâncias de banco de dados usando valores especificados pelo cliente em uma coluna da tabela – também chamada de chave de fragmento. Por exemplo, uma tabela que armazena informações do usuário pode ser dividida usando a coluna User-ID como chave de fragmento. Nos bastidores, o Aurora PostgreSQL Limitless Database é uma implantação distribuída de nós sem servidor. Os nós são roteadores ou fragmentos. Os roteadores gerenciam a natureza distribuída do banco de dados. Cada fragmento armazena um subconjunto de seus dados, permitindo que o processamento paralelo alcance um alto throughput de gravação.

À medida que os requisitos de computação ou armazenamento aumentam, o Aurora primeiro aumenta a escala verticalmente de cada instância de forma automática e seu armazenamento associado e depois é escalado horizontalmente para atender à workload do banco de dados para diferentes valores de chave de fragmento. A qualquer momento, um valor de chave de fragmento passa a pertencer e é servido por uma única instância sem servidor. Quando as aplicações se conectam ao Aurora PostgreSQL Limitless Database e emitem uma solicitação, a solicitação é analisada primeiro. Em seguida, ela é enviada para a instância de computação que possui o valor da chave de fragmento especificado pela solicitação ou uma consulta em várias instâncias é orquestrada.

Várias instâncias de computação, cada uma servindo valores distintos de chave de fragmento, podem atender simultaneamente a solicitações de aplicações para o mesmo Aurora PostgreSQL Limitless Database. O Aurora PostgreSQL Limitless Database fornece a mesma semântica de transação dos sistemas Aurora PostgreSQL de gravador único, eliminando a complexidade de gerenciar diferentes domínios de transação em sua aplicação.

O Aurora PostgreSQL Limitless Database oferece suporte a três tipos de tabelas que contêm seus dados: fragmentadas, de referência e padrão.

Tabelas fragmentadas: essas tabelas são distribuídas em vários fragmentos. Os dados são divididos entre os fragmentos com base nos valores das colunas designadas na tabela, chamadas de chaves de fragmento. Eles são úteis para escalar as tabelas maiores e mais intensivas de E/S em sua aplicação.

Tabelas de referência: essas tabelas copiam os dados na íntegra em cada fragmento para que as consultas de junção possam funcionar mais rapidamente, removendo a movimentação desnecessária de dados. Elas geralmente são usadas para dados de referência modificados com pouca frequência, como catálogos de produtos e códigos postais.

Tabelas padrão: essas tabelas são como tabelas normais do Aurora PostgreSQL. As tabelas padrão são todas colocadas juntas em um único fragmento para que as consultas de junção possam funcionar mais rapidamente, removendo a movimentação desnecessária de dados. É possível criar tabelas fragmentadas e de referência a partir de tabelas padrão.

Para saber mais sobre as considerações de compatibilidade com o PostgreSQL, acesse Requisitos e considerações do Aurora PostgreSQL Limitless Database.

Comece a usar o banco de dados Aurora PostgreSQL Limitless no console do Amazon RDS ou nas APIs da Amazon para criar um novo cluster do Aurora PostgreSQL com a versão do mecanismo compatível. Para saber mais sobre como começar, visite o Guia do usuário do Aurora PostgreSQL Limitless Database.

Sua aplicação se conecta ao Aurora PostgreSQL Limitless Database da mesma forma que se conectaria a um cluster padrão do Aurora PostgreSQL. Você simplesmente se conecta ao endpoint do cluster. Para saber mais, acesse Como usar o Aurora PostgreSQL Limitless Database.

Sim, talvez seja necessário ajustar o esquema do banco de dados para usar o Aurora PostgreSQL Limitless Database. É necessário que todas as tabelas fragmentadas contenham a chave de fragmento, portanto, esses dados talvez precisem ser preenchidos. Por exemplo, uma aplicação de contabilidade pode dividir seus dados por usuário, usando a coluna User-ID, já que cada usuário é independente dos outros. Embora a própria tabela do usuário contenha naturalmente essa
coluna, outras tabelas podem não contê-la, como uma tabela que possui os itens de linha das faturas. Como essas tabelas também precisam ser divididas pelo usuário para colocação a fim de otimizar o desempenho da consulta, a coluna ID do usuário precisa ser adicionada à tabela.

Não há restrições de nomenclatura na coluna usada para dividir os dados, mas a definição da coluna deve corresponder. Você precisará adicionar a chave do fragmento às consultas da aplicação e talvez também precise ajustar suas consultas e transações para obter o desempenho ideal. Por exemplo, pesquisar uma fatura usando o ID da fatura quando a tabela é dividida apenas pelo ID do usuário seria lento porque a consulta precisaria ser executada em todas as instâncias do banco de dados. No entanto, se a consulta também especificar o ID do usuário, a consulta será roteada para a única instância do banco de dados que contém todos os pedidos desse ID de usuário, reduzindo a latência da consulta.

Sim. É possível escolher uma opção de alta disponibilidade ao definir a redundância computacional como maior que zero para seu Aurora PostgreSQL Limitless Database, fornecendo disponibilidade de 99,99%. Cada instância de computação que armazena e acessa dados do seu banco de dados Aurora PostgreSQL Limitless pode ter um ou dois standbys que podem assumir as solicitações se a primária não estiver disponível. Os roteadores redirecionarão automaticamente o tráfego para um impacto mínimo em sua aplicação.

O Aurora PostgreSQL Limitless Database está disponível para a configuração de cluster otimizado para E/S do Aurora com compatibilidade com o PostgreSQL 16.4. Informações adicionais sobre a disponibilidade regional da AWS para o Aurora PostgreSQL Limitless Database estão disponíveis na página de preços do Aurora.

No Aurora PostgreSQL Limitless Database, a capacidade do banco de dados é medida em ACUs. Você paga uma taxa fixa por segundo de uso do ACU. As tarifas de armazenamento de configuração otimizada para E/S do Aurora são aplicadas. Para obter mais informações, acesse a página de preços do Aurora.

O Parallel Query do Amazon Aurora refere-se à capacidade de transferir e distribuir a carga computacional de uma única consulta entre milhares de CPUs na camada de armazenamento do Aurora. Sem o Parallel Query, uma consulta emitida para um banco de dados do Amazon Aurora seria executada inteiramente em uma instância do cluster de banco de dados, de forma semelhante à operação da maioria dos bancos de dados.

O Parallel Query é adequado para workloads analíticas que exigem dados atualizados e bom desempenho da consulta, mesmo em tabelas grandes. Muitas vezes, as workloads desse tipo são de natureza operacional.

O Parallel Query resulta em um desempenho mais rápido, acelerando as consultas analíticas em até duas ordens de magnitude. Também proporciona simplicidade operacional e dados atualizados, pois você pode emitir uma consulta diretamente para os dados transacionais atuais no cluster do Aurora. E o Parallel Query possibilita workloads transacionais e analíticas no mesmo banco de dados, permitindo que o Aurora mantenha um alta throughput de transações juntamente com consultas analíticas simultâneas.

A maioria das consultas em conjuntos de dados grandes que ainda não estão no grupo de buffers esperam obter benefícios. A versão inicial do Parallel Query pode transferir e aumentar a escala horizontalmente do processamento de mais de 200 funções, associações de igualdade (equijoins) e projeções de SQL.

O aumento de desempenho de uma consulta específica depende do volume do plano de consulta que pode ser transferido para a camada de armazenamento do Aurora. Os clientes relataram mais do que uma melhoria da ordem de magnitude para a latência das consultas.

Sim, mas esperamos que esses casos sejam raros.

Não é necessário alterar a sintaxe da consulta. O otimizador de consultas decidirá automaticamente se o Parallel Query será usado para uma consulta específica. Para verificar se uma consulta está usando o Parallel Query, você pode ver o plano de execução da consulta executando o comando EXPLAIN. Se você quiser ignorar a heurística e forçar a utilização do Parallel Query para fazer testes, use a variável de sessão aurora_pq_force.

O Parallel Query pode ser habilitado e desabilitado dinamicamente no nível global ou de sessão usando o parâmetro aurora_pq.

Não haverá nenhuma cobrança além do que você já paga pelas instâncias, pela E/S e pelo armazenamento.

Não. Os custos de E/S do Parallel Query para a sua consulta são calculados na camada de armazenamento, e serão iguais ou maiores com o Parallel Query ativado. O seu benefício é o aumento na performance de consultas.

Há dois motivos para os custos de E/S possivelmente mais altos com o Parallel Query. Primeiro, mesmo se parte dos dados de uma tabela estiver no grupo de buffers, o Parallel Query exige que todos os dados sejam varridos na camada de armazenamento, o que consome E/S. Segundo, um efeito colateral de evitar a contenção no grupo de buffers é que a execução de uma consulta com Parallel Query não atualiza o grupo de buffers. Consequentemente, execuções consecutivas da mesma consulta do Parallel Query incorrerão o custo completo de E/S.

Saiba mais sobre o Parallel Query na documentação.

Não. No momento, é possível usar o Parallel Query com instâncias na família de instâncias R*.

O Parallel Query está disponível para o Amazon Aurora na versão compatível com MySQL 5.7 e MySQL 8.0.

O Parallel Query é compatível com o Aurora Serverless v2 e o Backtrack.

Não. Embora esperemos que o Parallel Query melhore a latência das consultas na maioria dos casos, poderá haver custos de E/S mais altos. Recomendamos que você teste completamente a workload com o recurso habilitado e desabilitado. Quando estiver convencido de que o Parallel Query é a opção correta, poderá deixar que o otimizador decida automaticamente quais consultas o utilizarão. Quando o otimizador não tomar a decisão ideal, o que deve ocorrer raramente, você poderá substituir a configuração.

O Aurora Parallel Query não é um data warehouse e não oferece a funcionalidade que costuma ser encontrada nesses sistemas. Ele foi projetado para acelerar o desempenho de consultas no banco de dados relacional e é adequado para casos de uso, como análises operacionais, quando você precisa executar consultas analíticas rápidas em dados atualizados no banco de dados.

Para obter um data warehouse de nuvem na escala de exabytes, considere o Amazon Redshift.

As Leituras otimizadas pelo Amazon Aurora, disponíveis para Aurora PostgreSQL, são uma nova opção de preço e desempenho que oferece latência de consulta até oito vezes maior e redução de custos de até 30% em comparação às instâncias sem elas. Elas são ideais 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 o desempenho de consultas que envolvem classificações, agregações de hash, junções de alta carga e outras operações com uso intenso de dados.

As Leituras otimizadas pelo Amazon Aurora para Aurora PostgreSQL oferecem aos clientes que possuem aplicações sensíveis à latência e conjuntos de trabalho grandes uma alternativa atraente de preço e desempenho para atender aos SLAs de sua empresa e aproveitar ainda mais as instâncias.

O Amazon Aurora Optimized Reads está disponível em instâncias R6id baseadas em Intel e R6gd baseadas em Graviton. Consulte 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, as leituras otimizadas do Amazon Aurora estão disponíveis 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 com leitura pesada, as instâncias de leitura otimizadas no Aurora PostgreSQL configuradas para usar automaticamente os dados removidos da memória do Aurora I/O-Optimized 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 os clusters de banco de dados do Aurora existentes para incluir as instâncias R6id e R6gd ou criar novos clusters de banco de dados usando essas instâncias. Consulte a documentação das Leituras otimizadas pelo Amazon Aurora 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. A duração da recuperação pode ser acelerada com a habilitação do 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 do desempenho do cache, antes de habilitar o CCM.

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

Use o pgvector para armazenar, pesquisar, indexar e consultar bilhões de incorporações geradas com base em modelos de machine learning (ML) e inteligência artificial (IA) no seu banco de dados, como os do Amazon Bedrock ou do Amazon SageMaker. Uma incorporação de vetor é uma representação numérica que representa o significado semântico do conteúdo, como texto, imagens e vídeo.

Com o pgvector, é possível consultar incorporações em seu banco de dados Aurora PostgreSQL para realizar pesquisas de similaridade semântica eficientes desses tipos de dados, representados como vetores, combinadas com outros dados tabulares no Aurora. Isso permite o uso da IA generativa e outros sistemas de IA/ML para novos tipos de aplicações, como recomendações personalizadas com base em descrições de texto ou imagens semelhantes, correspondência de candidatos com base em notas de entrevista, chatbots e recomendações de próximas ações para atendimento ao cliente com base em transcrições bem-sucedidas ou diálogos de sessões de chat e muito mais. 

Leia nosso blog sobre recursos de banco de dados de vetores e saiba como armazenar incorporações usando a extensão pgvector em um banco de dados do Aurora PostgreSQL, criar um chatbot interativo para responder a perguntas e usar a integração nativa entre o pgvector e o machine learning do Aurora para análise de sentimentos.

Sim. O machine learning (ML) do Aurora expõe modelos de ML como funções SQL, permitindo usar 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 massa para o Aurora PostgreSQL.

O ML do Aurora pode transformar esse processo em uma operação 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, o que retorna as incorporações mais recentes do seu modelo.

Sim. Há dois métodos para integrar bancos de dados do Amazon Aurora com o Amazon Bedrock e potencializar aplicações de IA generativa. Primeiro, o ML do Amazon Aurora fornece acesso aos modelos de base disponíveis no Amazon Bedrock diretamente por meio do SQL para o Aurora MySQL e o Aurora PostgreSQL. Em seguida, você pode configurar o Aurora como seu armazenamento de vetores nas Bases de conhecimento do Amazon Bedrock com apenas um clique e armazenar incorporações geradas no Bedrock no Aurora. As Bases de conhecimento do Amazon Bedrock são compatíveis com o Aurora PostgreSQL como um armazenamento de vetor para casos de uso como geração aumentada via recuperação (RAG). Leia nosso blog e nossa documentação sobre como usar o Aurora PostgreSQL como base de conhecimento para o Amazon Bedrock.

As Leituras otimizadas pelo Amazon Aurora PostgreSQL com pgvector aumentam as consultas por segundo para pesquisa vetorial em até nove vezes em workloads que excedem a memória disponível da instância. 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 em memória para o armazenamento local a fim de acelerar os acessos subsequentes desses dados.

Leia nosso blog e nossa documentação sobre como melhorar o desempenho do Aurora PostgreSQL com as Leituras otimizadas pelo Aurora.

Use a Integração ETL zero do Amazon Aurora com o Amazon Redshift quando precisar 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 Amazon Aurora com o Amazon SageMaker permite trazer dados dos bancos de dados e aplicações operacionais para o lakehouse quase em tempo real. Com a arquitetura lakehouse do SageMaker, você pode criar um lakehouse aberto sobre seus investimentos em dados existentes, sem alterar sua arquitetura de dados e usar suas ferramentas de análise e mecanismos de consulta preferidos, como SQL, Apache Spark, BI e ferramentas de IA/ML.

A integração ETL zero do Aurora com o Amazon Redshift está disponível na edição compatível com MySQL do Aurora para a versão 3.05.2 (compatível com MySQL 8.0.32) e posteriores. A Integração ETL zero do Aurora com o Amazon Redshift está disponível na edição compatível com o Aurora PostgreSQL para a versão 16.4 e superior.

A integração ETL zero do Aurora com o Amazon SageMaker está disponível na edição compatível com Aurora MySQL para a versão 3.05.0 (compatível com MySQL 8.0.32) e posterior. A integração ETL Zero do Aurora com o Amazon SageMaker está disponível na edição compatível com o Aurora PostgreSQL para Aurora PostgreSQL versão 16.4 e superior e Aurora PostgreSQL versão 17.4 e superior.

Acesse os atributos compatíveis no Aurora por região da AWS e o mecanismo de banco de dados Aurora para saber mais sobre disponibilidade na região da AWS para as integrações ETL zero do Aurora.

A integração ETL Zero do Aurora com o Amazon Redshift e Amazon SageMaker elimina a necessidade de criar e manter pipelines de dados complexos. Consolide dados de várias tabelas de vários clusters de bancos de dados do Aurora em um único cluster de bancos de dados do Amazon Redshift, ou à arquitetura de lakehouse do SageMaker e execute análises e ML em tempo real nos dados operacionais do Aurora.

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

A Integração ETL zero do Aurora com o Amazon SageMaker é compatível com o Aurora Serverless v2.

Comece usando o console do Amazon RDS para criar a Integração ETL zero especificando a origem e o destino do Aurora. Depois que a integração for criada, o banco de dados Aurora será replicado no destino, 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 às integrações ETL Zero do Aurora com o Amazon Redshift e integração ETL Zero do Aurora com o Amazon SageMaker.

O processamento contínuo de alterações de dados pela Integração ETL zero é oferecido sem custo adicional. Você paga pelos recursos existentes usados para criar e processar os dados alterados 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 os bancos de dados
• Armazenamento adicional para armazenar dados replicados
• Computação adicional para processar a replicação de dados
• 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.

Sim, você pode gerenciar e automatizar a configuração e a implantação dos recursos necessários para uma Integração ETL zero do Aurora usando o AWS CloudFormation. Para obter mais informações, acesse os modelos do CloudFormation com a Integração ETL zero.

O CloudWatch Database Insights é uma solução de monitoramento e métricas que simplifica e aprimora a solução de problemas do banco de dados. Ele automatiza a coleta de telemetria, incluindo métricas, logs e rastreamentos, eliminando a necessidade de instalação e configuração manuais. Ao consolidar essa telemetria no Amazon CloudWatch, o CloudWatch Database Insights fornece um panorama unificado do desempenho e da integridade do banco de dados.

Os principais benefícios do CloudWatch Database Insights incluem:

1. Coleta de telemetria sem esforço: reúne automaticamente métricas, logs e rastreamentos do banco de dados, minimizando o tempo de configuração.
2. Informações selecionadas: fornece painéis pré-criados, alarmes e informações para monitorar e otimizar o desempenho do banco de dados, com o mínimo de configuração necessária para começar.
3. Exibição unificada do CloudWatch: combina a telemetria de vários bancos de dados em uma única exibição para simplificar o monitoramento.
4. Recursos de IA e ML: usa IA e ML para detectar anomalias, reduzindo os esforços manuais de solução de problemas.
5. Monitoramento do contexto da aplicação: permite que os usuários correlacionem o desempenho do banco de dados com o desempenho da aplicação.
6. Exibições em nível de frota e instância: oferece monitoramento de frota de alto nível e exibições detalhadas de instâncias para análise de causa raiz.
7. Integração perfeita com a AWS: integra-se com o Amazon CloudWatch Application Signals e o AWS X-Ray, permitindo uma experiência abrangente de observabilidade.

O Amazon DevOps Guru para RDS é um recurso com tecnologia de ML do Amazon RDS (o que inclui o Amazon Aurora) desenvolvido para detectar e diagnosticar automaticamente problemas operacionais e de desempenho do banco de dados, permitindo que você os solucione em minutos em vez de dias.

O Amazon DevOps Guru para RDS é um atributo do Amazon DevOps Guru, que detecta problemas operacionais e de desempenho 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 correções inteligentes para ajudar os clientes a resolver rapidamente gargalos de desempenho 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 do banco de dados mais acessível para usuários comuns e auxilia os 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 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.

Antes de começar a usar o DevOps Guru para RDS, habilite o recursoInsights de Performance no console do RDS. Em seguida, basta habilitar o DevOps Guru para os bancos de dados do Amazon Aurora. Com o DevOps Guru, você pode escolher seu limite de cobertura de análise para ser toda a conta da AWS, prescrever as pilhas específicas do AWS CloudFormation que o DevOps Guru deve analisar ou usar tags da AWS para criar o agrupamento de recursos a ser analisado pelo DevOps Guru.

O Amazon DevOps Guru for RDS ajuda a identificar uma ampla variedade de problemas de desempenho que podem afetar a qualidade do serviço da aplicação, 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 atributo de ajuste e monitoramento de desempenho que coleta e visualiza métricas de desempenho dos 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 criado para monitorar essas métricas, detectar quando o banco de dados estiver enfrentando problemas de desempenho, analisar as métricas e, em seguida, dizer o que está errado e o que deve ser feito.

O CloudWatch Database Insights monitora recursos e aplicações do Aurora em tempo real e apresenta dados por meio de painéis personalizáveis. Por outro lado, o Amazon DevOps Guru é um serviço de machine learning (ML) que analisa as métricas do CloudWatch para entender o comportamento de uma aplicação ao longo do tempo, detectar anomalias e oferecer insights e recomendações para a resolução de problemas. Além disso, o DevOps Guru analisa dados de várias fontes, incluindo o AWS Config, o AWS CloudFormation e o AWS X-Ray. Use os painéis do CloudWatch para monitorar insights do DevOps Guru por meio das métricas publicadas no namespace AWS/DevOps-Guru. Isso ajuda você a consultar todos os insights e anomalias em um único painel no console do CloudWatch.

O Insights de desempenho do RDS é um atributo de monitoramento e ajuste do desempenho do banco de dados que permite aos clientes avaliar a carga do banco de dados e determinar quando e onde agir. O CloudWatch Database Insights é um novo recurso de observabilidade do banco de dados que herda todos os atributos do Insights de desempenho, além de monitoramento em nível de frota, integração com monitoramento de desempenho das aplicações e correlação de métricas de banco de dados com logs e eventos.

Use a API de dados para novas aplicações modernas, especialmente as criadas com o AWS Lambda, que precisam acessar o Aurora em um modelo de solicitação e resposta. Você deve usar os drivers de banco de dados em vez da API de dados e gerenciar as conexões do banco de dados persistentes quando uma aplicação existente estiver altamente acoplada aos drivers do banco de dados, quando houver consultas de longa duração ou quando o desenvolvedor quiser 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 das instâncias provisionadas do Aurora pode ser encontrada em nossa documentação.

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 das aplicações que abrem e fecham conexões com frequência. 

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 do Aurora usando um segredo no AWS Secrets Manager. 

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.

Ative 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 superiores 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 na 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 o desempenho 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 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 azuis/verdes inclui o nosso preço padrão atual para instâncias de bancos de dados, custo de armazenamento, custo de leitura e gravação de E/S e todos os atributos 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 a fazer alterações no banco de dados de forma mais segura, simples e rápida, como atualizações de versão grandes ou pequenas, alterações de esquema, ajuste de escala em 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 é o 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 se mantenham 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 foram criadas 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.

As barreiras de proteção da alternância das implantações azuis/verdes do Amazon RDS bloqueiam a gravação nos seus ambientes azul e verde até que o ambiente verde esteja atualizado antes de concluir a troca. As implantações azuis/verdes também realizam verificações de integridade do principal e das réplicas nos seus ambientes azul e verde. Elas também realizam verificações de integridade da replicação, por exemplo, para ver se a replicação foi interrompida ou se há erros. Elas detectam transações de longa duração nos seus ambientes azul e verde. Você pode especificar um tempo de inatividade máximo tolerável de, no mínimo de 30 segundos, e se você tiver uma transação que exceda esse tempo, a transição será interrompida.

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.

Sim, as implantações azuis/verdes do Amazon RDS são compatíveis com o Aurora Global Database. Para saber mais, leia o Guia do usuário das implantações azuis/verdes para o Amazon Aurora Global Database.

Não, as implantações azuis/verdes do Amazon RDS não são compatíveis com o Amazon RDS Proxy ou com as 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.

A Trusted Language Extensions (TLE) para PostgreSQL permite que os desenvolvedores criem extensões de alto desempenho do PostgreSQL e as executem com segurança no Amazon Aurora. Ao fazer isso, o 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.

As extensões do PostgreSQL são executadas no mesmo espaço do processo para obter alta performance. No entanto, as extensões podem conter defeitos no software e causar uma pane no banco de dados.

A TLE para PostgreSQL oferece várias camadas de proteção para reduzir esse risco. O TLE foi projetado para limitar o acesso aos recursos do sistema. O perfil rds_superuser pode determinar quem tem permissão para instalar extensões específicas. No entanto, essas alterações só podem ser feitas por meio da API do TLE. O TLE foi projetado para limitar o impacto de um defeito na extensão a uma única conexão ao banco de dados. Além dessas medidas de proteção, a TLE é projetada para fornecer controle online e granular aos DBAs no perfil rds-superuser sobre quem pode instalar extensões e eles podem criar um modelo de permissão para executá-las. Apenas usuários com privilégios suficientes serão capazes de executar e criar usando o comando “CREATE EXTENSION” em uma extensão TLE. Os DBAs também podem criar uma lista de “PostgreSQL hooks” permitidos que são necessários para extensões mais sofisticadas que modificam o comportamento interno do banco de dados e geralmente requerem privilégios elevados.

A TLE para PostgreSQL está disponível para o 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 a TLE para PostgreSQL no PostgreSQL 14.5 ou superior no Amazon Aurora.

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

A 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 a 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, a TLE para PostgreSQL é compatível com JavaScript, PL/pgSQL, Perl e SQL.

Assim que o perfil rds_superuser ativa a TLE para PostgreSQL, você pode implantar as extensões TLE usando o comando SQL CREATE EXTENSION de qualquer cliente PostgreSQL, como 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.

A TLE para PostgreSQL só pode acessar o banco de dados PostgreSQL via 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.

Saiba mais sobre o projeto TLE para PostgreSQL na página oficial do TLE no GitHub.