Novidades da Semana – 26 a 30 de abril

Todos os dias a AWS lança uma série novidades e atualizações em seus produtos que visam melhorar a vida de seus usuários. Reunimos algumas delas que fazem mais sentido para nosso mercado e que certamente aplicaremos em nosso dia a dia. Confira as novidades das últimas semanas.

Security & Governance

AWS Systems Manager – Integração do OpsCenter e Explorer com AWS Security Hub
O AWS Systems Manager anunciou a integração das ferramentas OpsCenter e Explorer com o AWS Security Hub. Isso permite examinar, investigar e solucionar falhas de segurança, juntamente com outros problemas operacionais nessas ferramentas.

AWS Service Catalog – Suporte a aplicações do AppRegistry
O AWS Service Catalog adicionou o suporte de seu console para aplicações do AppRegistry. Essa atualização possibilita criar e gerenciar seus metadados de aplicações em uma experiência de console totalmente otimizada.

AWS Control Tower – Disponibilização de softwares de terceiros no AWS Marketplace
O AWS Control Tower anunciou a disponibilização de uma coleção de softwares de terceiros desenvolvidos para o serviço no AWS Marketplace. Os usuários podem escolher entre serviços profissionais e soluções de software, como gerenciamento de identidade, segurança para um ambiente de várias contas, rede centralizada, entre outros recursos.

AWS Secrets Manager – Novo driver para Kubernetes
O AWS Secrets Manager anunciou um novo driver para Kubernetes, o AWS Secrets and Configuration Provider (ASCP), que permite que as aplicações em execução nos pods do Kubernetes recuperem segredos do AWS Secrets Manager facilmente, sem a necessidade de código personalizado.

Analytics & Operations

Amazon Cloudwatch – Anúncio do Moving Graphics
O Amazon Cloudwatch anunciou o recurso Moving Graphics que permite a animação do painel do CloudWatch, bem como a visualização simplificada da progressão da integridade e das tendências da performance operacional de seu sistema.
https://aws.amazon.com/pt/about-aws/whats-new/2021/04/announcing-moving-graphs-for-cloudwatch-dashboards/

AWS SAM CLI – Suporte a aplicações do AWS CDK
O AWS Serverless Application Model (SAM) CLI, ferramenta de desenvolvimento de aplicações severless agora suporta aplicações AWS Cloud Development Kit (CDK) em preview público.

AWS Distro for Open Telemetry – Suporte a camadas Lambda e outros recursos
O AWS Distro for OpenTelemetry, adicionou suporte a camadas Lambda de forma gerenciada, permitindo inicializar o OpenTelemetry SDK e o Collector em suas funções AWS Lambda para coleta de dados de rastreamento.

Amazon Kendra – Lançamento do recurso de ajuste dinâmico de relevância
O Amazon Kendra é um serviço de pesquisa inteligente com tecnologia de machine learning, e lançou um novo recurso que dá mais controle aos usuários ao obter resultados de pesquisa otimizadas.

Networking & Compute

AWS Network Firewall – Disponível em 10 novas regiões
O AWS Network Firewall, o serviço de firewall gerenciado da AWS, anunciou disponibilidade em 10 novas regiões, incluindo São Paulo.

AWS Nitro Enclaves – Compatível com Windows
O AWS Nitro Enclaves, agora é compatível com sistemas operacionais Windows, o que permite a criação de ambientes isolados de computação de instâncias do EC2 executadas em Windows.

Database & Storage

AWS Snow Family – Agora permite long-term pricing em jobs da ferramenta
O AWS Snow Family agora permite que você gerencie os Jobs do Snowball Edge com long-term pricing diretamente do console ou através de APIs.

Amazon Cloudwatch – Lançamento do Amazon CloudWatch Monitoring Framework for Apache
O Amazon Cloudwatch anunciou o lançamento do Amazon CloudWatch Monitoring Framework for Apache, que auxilia na configuração de dashboards do Cloudwatch para monitorar workloads do Apache rodando em AWS.

Amazon Redshift – Suporte a Recursive Common Table Expression (CTE)
O Amazon Redshift agora oferece suporte a Recursive Common Table Expression (CTE), que permite consultar dados hierárquicos.

Amazon Redshift – Suporte a dados semiestruturados e JSON
O Amazon Redshift anunciou suporte nativo a dados semiestruturados e JSON. Ele é baseado no novo tipo de dados “SUPER”, que permite a ingestão e o armazenamento de dados semiestruturados.

AWS Glue – Suporte a autenticação de streams do Apache Kafka
O AWS Glue agora oferece suporte à autenticação de certificado de cliente SSL com produtores de stream do Apache Kafka. O que permite fornecer um certificado personalizado ao definir uma conexão do AWS Glue com um cluster Apache Kafka, que o AWS Glue usará ao se autenticar nele.

Driver Java (JDBC) for PostgreSQL – Disponível em demonstração
O Driver Java (JDBC) para PostgreSQL da AWS agora está disponível em versão de demonstração. Esse driver de banco de dados de código aberto permite que as aplicações que se conectam ao Amazon Aurora PostgreSQL minimizem o tempo de failover, monitorando de perto o status do cluster de banco de dados.

Novos lançamentos

AWS for Media and Entertainment – Lançamento
O AWS lançou um novo serviço, o AWS for Media and Entertainment, que oferece soluções e ferramentas voltadas especialmente para produtores de conteúdo, proprietários de direitos, , emissoras e distribuidores.

Amazon Ninble Studio – Lançamento
A AWS lançou mais um serviço: o Amazon Nimble Studio. O Nimble Studio é um serviço gerenciado com o qual estúdios criativos podem produzir efeitos visuais, animação e conteúdo interativo inteiramente na nuvem, desde o esboço do storyboard até a entrega final.

Performance Dashboard on AWS – Lançamento
O outro lançamento da AWS é o Performance Dashboard on AWS. Que consiste em uma nova implementação de soluções da AWS de open source, para criar, implantar e manter painéis personalizáveis projetados para aumentar a transparência entre governos e seus constituintes acerca do desempenho de serviços e iniciativas do setor público.

Quer saber as novidades da AWS das últimas semanas? Leia nosso blog!

E acompanhe toda sexta-feira em nosso canal do Youtube nossa live sobre as Novidades da Semana.

Novidades da semana – 22 a 26 de março

Por Flávio Rescia
Todos os dias a AWS lança uma série novidades e atualizações em seus produtos que visam melhorar a vida de seus usuários. Reunimos algumas delas que fazem mais sentido para nosso mercado e que certamente aplicaremos em nosso dia a dia. Confira as novidades da última semana.

Segurança e Governança

AWS Cost Categories – Suporte a hierarquia e valores default
O AWS Cost Categories permite criar uma visão baseada em categorias compostas de contas, tags, tipos de serviços etc. Ou seja, agora é possível ter subcategorias baseadas nesses atributos e “setar” uma categoria padrão para o que não for categorizado

AWS License Manager – Recurso de exclusão de condições para licenças
AWS License Manager é um serviço gratuito da AWS que permite controlar licenças na AWS e onPremise, e agora é possível excluir determinadas condições para não consumirem licenças gerenciadas pelo serviço.

AWS Security Hub – Suporte à integração com dados do Amazon Macie
AWS Security Hub, que concentra diversos serviços de segurança da AWS agora suporta adicionar automaticamente os dados do Macie, serviço gerenciado que busca por dados sensíveis em massa de dados.

AWS Audit Manager – Compatibilidade com PCI e suporte a CIS AWS Foundation Benchmark
AWS Audit Manager, um serviço que foi lançado no Re:Invent 2020 e que concentra inventário para auditoria, já é compatível com PCI, e agora também suporta CIS AWS Foundation Benchmark Level 1 e 2.

AWS Backup – Recurso de deleção em lote
AWS Backup, o serviço de gerenciamento de backup compatível com diversos serviços como EFS, RDS, S3, FSx e outros, agora possui recurso para deleção em lote, o Bulk Deletion, onde é possível deletar diversos pontos de restore em apenas uma chamada.

AWS SSO – Suporte a Virtual Studio Code Toolkit
AWS SSO agora é suportado pelo Visual Studio Code Toolkit, ou seja, a novidade possibilita integrar a autenticação do serviço diretamente com seu VSCode. Na postagem do Blog da AWS, Garret Sweetwood dá detalhes de como usar a integração.

Amazon CloudTrail – Versão com DynamoDB com nova funcionalidade
Nova funcionalidade do CloudTrail com o DynamoDB, agora no CloudTrail é possível registrar eventos que aconteceram no nível do banco de dados, podendo incluir quem e quando foi feito chamadas no DynamoDB, sendo possível habilitar baseado em tabelas ou filtros de leitura e escrita.

Database & Compute

Amazon Timestream – Suporte a VPC
Amazon Timestream, o banco de dados time series da AWS agora possui suporte a VPC Endpoint, o que traz mais segurança além de redução de custo para alguns cenários.

AWS Proton – Novo recurso para templates do serviço
AWS Proton, serviço de gerenciamento e criação de microserviços usando Container e Serverless, adicionou o recurso “Termination Protection” para uso nos seus templates.

Amazon EC2 – suporte a UEFI Boot
Amazon EC2 agora suporta UEFI Boot quando migrado de on-premises, esse recurso não era suportado no passado, agora ele possibilita migrar servidores ou VMs com Boot UEFI usando ferramentas como Server Migration Services ou CloudEndure.

AWS Fargate – Versão LATEST 1.4.0 disponibilizado
AWS Fargate, a modalidade de Containers Serverless da AWS disponibiliza como versão LATEST 1.4.0, que conta entre outras coisas com o esperado suporte à EFS, o NFS gerenciado da AWS, e o Amazon ECS Exec, que permite acessar a CLI de containers via web console. Um Blog post bem legal escrito por Massimo Re Ferre é possível traz todos os detalhes

Amazon EKS – Aumento na velocidade do controle Plane
Novidade no Amazon EKS, agora a criação do controle Plane está mais rápida. O processo se dá no máximo em 9 minutos, isso é ótimo para produtividade, mas principalmente para cenários onde o plano de DR depende da criação de um novo cluster.
Detalhes em: https://aws.amazon.com/blogs/containers/aws-fargate-launches-platform-version-1-4/

ROSA – Nova solução
A Amazon em conjunto com a RedHat lançaram Openshift Gerenciado, nomeado de ROSA, RedHat Openshift Service on AWS. O Kubernetes “com roupinha de sair da turma do chapéu vermelho” já vem compatível com SOC-2, PCI e ISO-27001 e já pode ser iniciado em minutos ao custo de $20/mês + $15/mês para cada node de 4vCPU, é cobrado por hora e possui valores para reserva de 1 ano.

Analytics

Amazon Lookout for Metrics – Novo serviço
Amazon Lookout for Metrics é um novo serviço da AWS, que analisa diversos tipos de Datasets, como Cloudwatch, ou um SQL Server por exemplo, buscando por anomalias de comportamento, e assim poder, por exemplo gerar alarmes mais assertivos.
Detalhes em:
https://www.youtube.com/watch?v=nT6Jn-eoviw
https://www.youtube.com/watch?v=nX_YipA_-QQ

AWS Glue Studio – Suporte a transformações com Queries SQL
AWS Glue Studio agora suporta transformações usando Queries SQL, além do tradicional suporte a Py Spart, e agora é possível usar o novo Spark SQL.

Amazon QuickSight – Novo recurso de “tootips”
Amazon QuickSight, o visualizador de BI Serverless da AWS ganhou “tootips”, que dá dicas de novas visualizações e dimensões para o usuário. Além disso, o já conhecido Detector de Anomalias que permite analisar e notificar anomalias com uma métrica de top-level, sendo um agregador das outras métricas e não dos detalhes. Outra novidade é possibilidade de adicionar no dashboard quem é o autor, além de gerenciar acessos.

Quer saber as novidades da AWS das últimas semanas? Leia nosso blog!

E acompanhe toda sexta-feira em nosso canal do Youtube nossa live sobre as Novidades da Semana.

Descomplicando Rede e Conectividade – Parte 2

Era hora de evoluir para uma arquitetura mais avançada, como pode ser visto no diagrama abaixo:

Parece complicado certo? Mas vamos explicar pouco mais sobre este conceito:

VGW

O “Virtual Gateway” é um componente lógico (e sem custo) na AWS que conecta a VPC às redes externas. Assim é possível configurar rotas, estáticas ou dinâmicas, em minha tabela de roteamento, para alcançar redes externas.

VPN:

A AWS possuí um serviço chamado “AWS Site-to-Site VPN“, que é uma VPN Gerenciada L2TP (as conhecidas VPN IPSec), que você pode configurar em apenas 5 minutos, já com redundância, exportar o arquivo de configuração do roteador/firewall OnPremises e a partir daí já está pronto para aplicar, ou enviar para seu parceiro. Esse serviço suporta roteamento estático e dinâmico via BGP, que é opcional. Podemos também configurar a VPN em uma instância EC2, nesse caso usamos um Appliance terceiro (ou um Linux). EExistem diversas opções sem custo, também é possível usar soluções de mercado disponíveis no AWS Marketplace, como PFSense, Fortinet, Sophos, Cisco, entre outros.
Peering: Se a necessidade é conectar redes AWS, com o VPC Peering, conseguimos enviar um convite para outro VPC, uma vez aceito, rotas podem ser configuradas. É importante saber/lembrar que as redes não podem conflitar (overlaping). O VPC Peering não tem custo, é pago apenas a transferência de dados realizada por ele.

Com isso percebemos que não só conseguimos realizar tudo que fizemos na camada de rede fora da Cloud, como ganhamos diversos recursos e benefícios inerentes antes indisponíveis.

Como próximo passo, surgiu a necessidade de migrar o ambiente produtivo da Corretora de Valores, a Mirae Asset Securities CCTVM para AWS. O que incluí não apenas workloads corporativos tradicionais como FileServer, Active Directory, Exchange e Aplicações WEB, mas também workloads específicos do mercado financeiro, como SINACOR, Order Management System (OMSs), Marketdata e Sistemas de Risco com bancos de dados em Oracle, SQL e MySQL.

Um ambiente híbrido de alta performance, resiliência e disponibilidade foi requerido, devido a características desse mercado, como:

• Necessidade de interligação com Bolsa de Valores (B3) via “Rede de Comunicação BM&FBOVESPA” (RCB);
Interconectividade com Banco Central e outros órgãos financeiros (via RTM);
• Uso de Multicast para o Marketdata (UMDF);
• Transição entre OnPremises e AWS;

Com isso, mais uma leva de perguntas tiveram que ser respondidas:

• Posso me conectar fisicamente à AWS? Mas é muito caro, certo?
• E para interligar com Regiões diferente de São Paulo?
• Mas a latência não é alta?
• Preciso me conectar via sub-redes públicas certo? (Não, rs!)
• Como fica a questão de redundância?
• E o DNS, dentro do VPC o DNS é deles certo? Mas eu uso DNS Interno (nesse caso via Windows DNS)
• Sei que é uma boa prática usar várias contas AWS, preciso de vários Links?

Para responder a essas perguntas, trazemos o diagrama com suas modificações necessárias para atender as demandas requeridas:

Vamos aos componentes e seu entendimento:

Direct Connect(DX): Você precisa contratar da AWS (tudo via console, ou API) e se conectar fisicamente até um dos pontos de presença utilizando uma operadora;
Private VIF: É a interface virtual do lado da AWS para conexão com o rotador do ambiente OnPremises. Através do IP do VIF, estabelecemos uma sessão BGP (sim BGP é um pré-requisito para uso de Direct Connect)
Public VIF: É possível subir uma sessão BGP para alcançarmos os serviços públicos AWS (todos IPs públicos da AWS), via Direct Connect, dessa forma, não usamos nem os links de Internet OnPremises, nem Data Transfer Out no VPC. Funciona como um PPT entre sua estrutura OnPremises e a rede pública da Amazon. É possível inclusive subir a VPN por essa conexão, assim temos uma camada extra de criptografia, além de servir de redundância para o caso de falhas nos links físicos.
Direct Connect Gateway (DX-GW): É um recurso lógico da AWS (sem custo) que pode ser utilizado para conectar 1 VIF a vários VGW, logo várias VPCs.

Na América Latina os únicos pontos de presença de Direct Connect são:

• Tivit São Paulo
• Equinix São Paulo (SP4)
• Equinix Rio de Janeiro (RJ2)

É possível subir o link diretamente com uma região diferente de São Paulo, a Equinix, por exemplo, possui esse serviço, mas os custos fixos são elevados. Se conectando via São Paulo, a comunicação com outras regiões é segura e isolada, porém pagamos o valor de Data Transfer entre regiões, de São Paulo para Virgínia do Norte (EUA) por exemplo é 0,04 extra por GB.

Os custos são compostos por para implantação de Direct Connect são:

1. Direct Connect (AWS): Os custos são compostos de valor hora/mês pela conexão/interface e transferência utilizada. Detalhes de custo em link;
2. Operadora: Link de conectividade para chegar até um dos pontos de presença;
3. Customer Gateway: Roteador ou firewall OnPremises com suporte à BGP.

Note que a transferência de dados é mais barata via Direct Connect do que via Internet. Para São Paulo, por exemplo, o custo Data Transfer Out para Internet é de $0,25, enquanto dentro do Direct Connect é $0,11 ( ou seja, 56% mais econômico). Temos notado em cenários de clientes que assim como a Mirae Asset, que com $1.000 de Data Transfer que podem ser roteados via Direct Connect, os custos de conexão (links, interface, etc) “se pagam”.

“Mas o Direct Connect não tem redundância?”

Tem sim, se dermos um Zoom nesse ponto, vemos que não somente temos redundância via VPN, como também de links físicos com Direct Connect:

Além disso, no diagrama acima, conseguimos visualizar que é possível interligar contas diferentes com VIFs diferentes, existe a possibilidade de fazer isso entre VGW x DX-GW, mas essa é uma discussão para um outro post.

Direct Connect Dedicado x Hosted

Essa é uma dúvida bem recorrente também: “qual usar? E quais são as diferenças de ambos para nosso cenário?”
A resposta mais direta para essa pergunta é:
“No dedicado, você chega até um desses datacenteres, e contrata um cross-connection (Golden Jump) até o equipamento da AWS com 1 ou 10Gbps, e tem 50 VIFs por conexão. Já no “Hosted” ou compartilhado, a operadora (Parceiro de Direct Connect, como Telium, Mundivox, Embratel, Algar, etc) se conecta à AWS e te oferece 1 VIF entre 50 e 500Mbps.”

Sendo assim, é preciso entender sua arquitetura, pois em geral o Direct Connect Dedicado tem mais funcionalidades, mas traz um custo um pouco maior, além da gerência, que no Direct Connect Hosted, costuma ter gestão completa feita pelos Parceiros de Direct Connect, ou pela Darede .

DNS

Para resolução de nomes DNS, também há diversas soluções que variam desde o uso de seus próprios servidores DNS, OnPremises ou na AWS, até a integração do serviço de DNS da AWS, Route53 com suas zonas internas para ter o melhor das duas tecnologias! Mas esses detalhes também ficarão para um próximo post.

Além disso na AWS temos diversos outros recursos como o VPC Flow logs que registra todas as conexões que passam pelo VPC, VPC Port Mirror, ferramentas de detecção de ameaças como o GuardDuty, Web Application Firewall.

Dessa forma chegamos em um cenário onde temos a transição entre OnPremises para Cloud, aproveitando os benefícios dos dois mundos com escalabilidade, alta performance, alta disponibilidade, ótimos níveis de segurança e custos alcançáveis ao negócio.

Quer conhecer mais nossos projetos ou trabalhar com a Darede? Estamos procurando clientes e profissionais interessados em viver esse mundo de inovações conosco!


Flávio Rescia
CTO & Co-Fundador
flavio.rescia@darede.com.br

Sócio Fundador da empresa Darede, graduado em Redes de Computador e Sistemas de Informação, docente em Redes de Computadores no SENAI e hoje ministra diversos treinamentos de serviços AWS. Possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

Descomplicando Rede e Conectividade – Parte 1

Quase sempre que falamos sobre redes na AWS, todos os tipos de dúvidas aparecem. Eu costumo dividi-las em três categorias:

1. Cloud Native: Do ambiente corporativo tradicional a startup mais descolada, sempre há dúvidas. Também somada àquela sensação de desconhecimento com o ambiente operacional, esta questão traz uma certa insegurança para os clientes.
2. Integração com OnPremises: Normalmente as dúvidas daqui são de clientes vindos de um ambiente corporativo maduro, eles querem saber quais são as diferenças entre as redes tradicionais e o Cloud Native, além de “como se conectar fisicamente às AWS”;
3. Serviços Integração: O campeão aqui é o DNS, mas há diversas dúvidas com Load Balancer, Endpoints e WAF. Estes serviços costumam se tornar um grande ponto de interrogação na cabeça dos clientes.

Com o grupo Mirae Asset não foi diferente. As dúvidas existiram desde o primeiro projeto (Cloud Native), passando também por interligações com VPN Site-to-Site, até uma estrutura complexa, com arquitetura híbrida, Direct Connect triplamente redundante, para operações financeiras de alta performance e baixa latência.

Nesse post tentaremos sanar o maior número de dúvidas possíveis, criando uma relação à realidade da Mirae Asset e sua trajetória na adoção de Cloud focada no mercado latino-americano e a realidade da Darede.

A Mirae Asset

A Mirae Asset é um grupo multinacional coreano de serviços financeiros. Composto por diversas células de negócio: Banco de Investimentos, Gestora de Fundos, Seguradora, Corretora e Gestora de Patrimônio. A Mirae Asset está em 15 países, com mais de 25 escritórios espalhados pelo mundo. No Brasil o grupo trabalha com a células: corretora de valores e gestora de fundos. No Brasil o grupo é atendido pela Darede há muitos anos.

O primeiro workload que realizamos na Mirae Asset, foi uma aplicação para hospedar uma aplicação web, sem integração com o ambiente OnPremises. Apesar de ser uma aplicação Cloud Native, algumas questões começaram a aparecer:

• Mas vai ficar tudo público?
• É seguro?
• Posso instalar um firewall? (acredite, em diversos casos você não precisará de um firewall)
• Posso segregar o banco de dados, backend e frontend?
• Eu subi uma instância EC2 com IP Público, mas ela só tem IP Privado, por quê?
• Qual a velocidade do link de Internet e seu preço?

Quando recebo uma variedade de perguntas como estas, eu digo: “Fique tranquilo, todas as respostas serão aquelas que você espera!”

O diagrama abaixo representa uma arquitetura padrão, implementada na maioria dos nossos clientes e que atende quase todos os cenários:

Agora vamos as explicações:

VPC: É como um Switch Core (L3) em uma Região, porém estendido em múltiplos Datacenters (ou Avaliabilty Zones, as AZs);
Sub-redes: Elas são como as VLANs em uma rede OnPremises, uma sub-rede só pode estar em um Datacenter. Por padrão, todas as sub-redes de um mesmo VPC tem conectividade entre elas;
Tabelas de Roteamento: É aqui que definimos se uma sub-rede é pública ou privada, o que determina isso é a rota que existe, principalmente para default gateway (“0.0.0.0” e “::/0”). Fica claro aqui, que podemos ter redes totalmente isoladas se decidirmos dessa forma, e é assim configurarmos.
IGW: O Internet Gateway é a interconexão mais usada entre a rede privada e a Internet na AWS. Somente com o uso de IGW, você consegue acesso originado na Internet para um recurso com IP Público no VPC, uma vez que é apenas por um deles que IPs Públicos funcionam para expor serviços privados (novamente, podemos filtrar por porta, origem, etc com Security Group).

NAT Gateway ou NAT Instance: É um recurso que permite que serviços internos ao VPC acessem serviços na Internet, usando Source NAT (Tradução de Endereço IP de Origem). Porém, requisições originadas na Internet não alcançam os serviços internos à VPC. NAT Instance é quando usamos uma instância EC2 (Windows, Linux, FreeBSD, etc.) para essa função, é assim que implementamos um Firewall Appliance (Fortinet, Sophos, Cisco, etc). Já NAT Gateway é um serviço gerenciado pela AWS que realiza essa função.

Serviços Públicos: Alguns serviços da AWS são originalmente públicos, esses serviços funcionam sem o VPC (mas veremos mais a frente que funcionam também com VPC), claramente há outros controles que garantem a segurança, mas é importante entender essa característica. São exemplos de serviços originalmente públicos: S3, SQS, SNS, DynamoDB, CloudFront, Secret Manager, Rekognition e outros. Lambda é um exemplo de serviço que antigamente não suportava VPC, mas agora suporta.

IPs Privados: Assim como no mundo OnPremises, são IPs não roteados à Internet e são distribuídos em TODAS as sub-redes, o que incluí nos servidores (EC2).

IPs Públicos: São IPs acessíveis apenas no IGW, a AWS faz um NAT 1:1 para o “IP Privado” do recurso ao qual o “IP Público” foi associado. É assim que mesmo com IP privado, conseguimos alcançar uma instância EC2 pelo seu IP público.

Além disso há camadas extras de segurança, como “Security Group”, que são regras de firewall statefull em cada recurso, ou ACL, que são regras de firewall stateless que funcionam no nível de todo o VPC.

Dito isso, há duas boas notícias.

A primeira boa notícia, além de perceber como é flexível rede na AWS, é que todos esses serviços podem ser usados sem custo, pois o modelo de cobrança é por uso, você paga por dados (bytes) transferidos de dentro para fora da VPC, do contrário não há cobrança. A segunda boa notícia é que não há limitação de transferência na sua rede da AWS. Sim, você tem acesso a banda do backbone AWS para download e upload! As limitações são os gargalos convencionais, como uma interface de rede de uma instância/servidor e escrita em disco.

AWS Endpoints

E se eu precisar usar serviços AWS que respondem somente publicamente? Para isso existem os ‘endpoints’, que são como gateways que te levam aos serviços da AWS sem passar pela Internet, sem necessidade de IGW ou NAT como demostrado abaixo:

Tão logo a Mirae Asset percebeu as vantagens no uso da AWS, o interesse pelo Cloud cresceu surgindo a necessidade de trazer outros workloads para Cloud, alguns desses precisavam de conectividade com o ambiente físico para projetos como “Disaster Recovery Site” e “Backup em Cloud”. A necessidade de uma rede hibrida surgiu, e com ela algumas dúvidas do time de TI também apareceram:
• Como interligar OnPremises e AWS de forma segura?
• Como fica a redundância?
• Preciso usar a Região São Paulo para algumas aplicações, mas queremos usar outras Regiões para outros workloads;
• Como conectar duas VPCs AWS?

Era hora de evoluir para uma arquitetura mais avançada. Clique aqui e confira a parte 2!


Flávio Rescia
CTO & Co-Fundador
flavio.rescia@darede.com.br

Sócio Fundador da empresa Darede, graduado em Redes de Computador e Sistemas de Informação, docente em Redes de Computadores no SENAI e hoje ministra diversos treinamentos de serviços AWS. Possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

Active Directory Federation Services da Microsoft

Hoje vamos falar um pouco sobre o ADFS, Active Directory Federation Services da Microsoft.

O AD FS é um serviço baseado em padrões, que permite o compartilhamento seguro de informações de identidade entre parceiros de negócios confiáveis (conhecidos como Federação) em uma extranet. Quando um usuário precisa acessar um aplicativo Web de um de seus parceiros de Federação, a própria organização do usuário é responsável por autenticá-lo e fornecer informações de identidade na forma de “Claims”, para o parceiro que hospeda o aplicativo Web. O parceiro de hospedagem usa sua diretiva de confiança para mapear as declarações de entrada para declarações que são compreendidas pelo seu aplicativo da Web, que usa as declarações para tomar decisões de autorização.

Resumindo, já pensou ter vários serviços como Office 365, Azure, AWS e Google GSuite todos utilizando o mesmo login, isso mesmo, o mesmo login da sua rede Active Directory. Tudo isso e ainda contar com duplo fator de autenticação usando Google Autenticator ou Microsoft Autenticator?

A proposta do ADFS é justamente essa, trazer cada vez mais integração ao Active Diretory com ferramentas externas e tornar o SSO (Login Único) o mais seguro possível.

O ADFS portal, é basicamente um portal para autenticação dos usuários em ferramentas de terceiros, cada aplicação tem sua forma de autenticação, se formos falar de AWS, após criar as roles necessárias, os usuários acessarão o portal ADFS e serão redirecionados para a AWS após autenticação, se formos falar de O365 e Gsuite, o usuário faz o login no portal O365/Gsuite e é redirecionado automaticamente para autenticação no ADFS Portal.

A Darede já possui a bagagem técnica necessária para implantação, customização e administração do seu ambiente ADFS, a infraestrutura inicial para até 1000 usuários é de certa forma simples. Você precisará de alguns itens básicos de infraestrutura que são eles:

• Ambiente rodando Microsoft Active Directory com pelos menos 2 domain controllers;
• Servidor dedicado com ip válido com poucos recursos executando o ADFS Proxy;
• Servidor dedicado ou domain controller executando ADFS Server;
• Certificado Wildcard Válido,

Existem alguns fatores importantes frente a segurança nesse cenário, recomenda-se subir a infraestrutura em um ambiente em nuvem (AWS/Azure), com isso garante-se disponibilidade do portal de autenticação em casos de falha na estrutura On-Premise. Outra dica valiosa, é manter o ADFS Proxy isolado ao Active Directory, ou seja, o servidor deve permanecer em WorkGroup evitando assim em uma hipótese de invasão, seu ambiente AD está seguro.

Por fim, aplicar uma solução WAF (Web Application Firewall) que garante tranquilidade e segurança para os administradores.

Agora que já falamos bastante sobre a federação, vamos a um exemplo prático de como ela acontece, no exemplo abaixo vamos realizar o login no portal AWS:

Para isso, bastará acessar o portal ADFS da sua organização:

Após escolher a aplicação AWS – Amazon Web Services, o usuário é redirecionado a tela de login, onde deve-se inserir as credenciais de domínio AD:

Como sempre usamos o MFA para esse tipo de acesso, o usuário será redirecionado para a tela de inserção de código de acesso que já foi previamente cadastrada:

Automaticamente após inserir o código MFA corretamente o usuário é direcionado ao console AWS:

Viram, o processo de autenticação ADFS é fácil e seguro. Venham executar seu projeto de Federação Conosco!


Flávio Rescia
Gerente de Operações
flavio.rescia@darede.com.br

Afinal, o que é Cloud?

O termo tem uma conotação muito abrangente e nos últimos anos um apelo de Marketing muito maior que uma definição técnica, tudo hoje é relacionado com Cloud/Nuvem com o intuito de agregar valor comercial ao produto ofertado.
Qualquer definição dada ao termo pode ser contestada, uma vez que não existe um órgão, instituição ou comitê que especifique termos de tecnologia, até projetos como o Techterms e Wikipédia, são a opinião de pessoas a respeito do uso do termo e não uma unanimidade. Assim o conteúdo desse artigo é nossa opinião sobre o uso do termo Cloud e mais importante nossa definição do que ”Cloud Computing” (que para nós são coisas diferentes).

O início

Desde o primeiro diagrama de tecnologia que vi, o desenho da nuvem representa a Internet ou uma conexão WAN (externa à rede Interna).

Fica claro então, que Cloud está relacionado a rede pública, ou o que está externo ao ambiente de rede interna.
Muito antes do termo Cloud ser usado, serviços já eram oferecidos na Internet, como hospedagem de sites, email, streaming de vídeo, etc. Tudo mudou com o conceito de “Cloud Computing”, que foi largamente difundido com o lançamento dos primeiros produtos da AWS (Amazon Web Services).

Com o sucesso dos produtos da AWS e da popularização do termo, outros serviços passaram a ser associado a Cloud, inclusive serviços de Internet que já existiam se associaram ao termo Cloud como apelo de Marketing e como símbolo de inovação.

Como diversos produtos são associados ao termo Cloud, organizamos eles em grupos, ou tipos de produtos Cloud. Uma abordagem mais utilizada (inclusive pela Microsoft) organiza os produtos Cloud em:

• OnPremise: Ao que está desassociado da nuvem, fora da Cloud;
• Infrastucture As A Service (IaaS): Quando os equipamentos, ou Infraestrutura, são oferecidos como serviço, e o Sistema Operacional (Windows, Linux, etc) é responsabilidade nossa (quem contrata);
• Plataform As A Service (PaaS): Aqui o Sistema Operacional não é responsabilidade do cliente, não temos acesso ao Windows/Linux, usamos por exemplo, apenas o Banco de Dados, Servidor Web, etc.
• Software As A Service (SaaS): Aplicação completa oferecida como serviço, o cliente apenas consome o App, exemplo são ERP, Serviço de Email, Spotfy, Netflix, etc.

Porém para nós da Darede, a visão acima não é o melhor agrupamento, uma vez que não agrupa serviços que devem/podem ser comparados entre si, e a linha entre eles é muito tênue e pode causar confusões.

• Cloud Computing: Aqui é o que a maior parte dos profissionais de TI entendem por Cloud, funciona como uma terceirização de hardware. Porém diferente de colocation, VPS e Servidor dedicado, que já existiam antes do conceito de ”Cloud Computing”, aqui falamos em:
o AWS,
o Azure,
o e Google Cloud Platform.

• Licenciamento como Serviço (LaaS): É muito comum ver software sendo vendidos ‘em Cloud’. A ideia aqui é pagar pelo tempo que usa e não um valor pela aquisição de licença como o antigo modelo praticado desde a década de 80. A receita tem sido boa tanto para quem vende, como para quem compra. Exemplos de LaaS:
o Adobe;
o Pacote Office;
o AutoCAD,.
• Software como Serviço (SaaS): Aqui incluímos sistemas que são contratados como serviço e hospedados na Internet. O fornecedor usa sua grande infraestrutura de equipamentos e vende em pequenas fatias, por exemplo $1 por usuário por mês. Aqui alguns produtos em SaaS:
o Google G Suite;
o Office 365;
o Pipedrive;
o SalesForce;
o Dropbox;
o Spotfy;
o Netflix.

Agora fica mais fácil entender qual ‘Set’ de produtos você irá utilizar em cada um dos Modelos de Cloud, ou usar onPremise se fizer sentido.

Aqui algumas perguntas que pode lhe ajudar a montar esse ‘Set’ de fornecedores de serviços em cloud:
1. Utilizar email corporativo próprio ou SaaS?
2. Adquirir uma licença de 10 mil reais ou pagar 200 reais por mês para usa-la?
3. Qual fornecedor de “Cloud Computing” usar?
4. Hospedar uma aplicação onPremise ou em “Cloud Computing”?
5. Vou armazenar meus arquivos onPremise, em “Cloud Computing” ou usando algum SaaS?

Cloud Computing

Agora vamos nos aprofundar um pouco em ”Cloud Computing”, que é a maior área de atuação Darede, pois está diretamente associada ao uso de poder computacional para nossas aplicações.

É muito comum ver fornecedores de serviços de Infraestrutura na Internet que se intitula “Cloud Computing”, quando está na verdade oferecendo produtos anteriores a “Cloud Computing” abaixo exemplo de produtos que NÃO SÃO “Cloud Computing”:

• Colocation: Espaço com energia, ar-condicionado e acesso à Internet para instalarmos nosso computador;
• Servidor Dedicado: Quando o servidor é instalado na estrutura do provedor de serviço e nós temos acesso ao Sistema Operacional;
• VPS: Sigla para Virtual Private Server, que é simplesmente um servidor virtual contratado como serviço;
Mas afinal, qual o limite entre Cloud Computing e Infraestrutura com Serviço na Internet? Entendemos que para ser considerado “Cloud Computing”, o produto precisa ter, no mínimo:
• Política do “Pague somente pelo que use”;
• Capacidade Ilimitada* de crescimento imediato;
• Estrutura “scriptável” onde é possível interagir com 100% através de APIs, ou outro método.

*Capacidade Ilimitada pode ser muito abrangente, afinal sempre há um ou alguns limites, mas o que quero dizer, é ter uma capacidade disponível de centenas ou milhares de vezes maior que a capacidade mínima contratada.
Com isso, muitos de vocês que estão lendo devem ter percebido (e esse é o intuito principal desse artigo), que Cloud Computing é muito mais que Infraestrutura Como Serviço na Internet e talvez até descoberto coisas que não sabia! =)

Aqui uma lista de coisa que você pode fazer com “Cloud Computing” e talvez não soubesse:

• Pagar por servidor por segundo ligado (sim se um servidor fica liga 90 segundos, você pagará apenas por esses segundos, caso desligue, para de pagar);
• Aumentar sua capacidade computacional em 10, 100, 1000 vezes por apenas algumas horas e pagar somente por isso;
• Possuir um site de contingência pagando R$0, e pagar por ele apenas pelos dias utilizados (e se forem utilizados);
• Hospedar sua aplicação em Datacenters distintos sem pagar nada por isso;
• Criar um script para subir uma estrutura em poucos segundos, seja ela de 1 serviço/servidor ou de centenas de milhares;
• Ter a mesma capacidade computacional de empresas referência em tecnologia e inovação (como Amazon, americanas.com.br, MercadoLivre, R7) pagando proporcionalmente ao tamanho do seu negócio;
• Fazer seu backup pagando U$0,004 (sim, menos de meio centavo);
• Ter velocidade de Internet ILIMITADA!

As maiores vantagens das soluções Cloud que você precisa conhecer!

Primeiramente, vamos esclarecer do que se trata: Computação em nuvem, ou Cloud Computing, descreve o ato de armazenar, gerenciar e processar dados online, em nuvem, em vez de em seu próprio computador. Essa tecnologia fornece uma maneira simples de acessar servidores, armazenamento, banco de dados e um amplo conjunto de aplicativos pela internet. Funciona como uma terceirização de hardware, mas como assim? Empresas administram e orquestram grandes Datacenters que possuem hardwares, disco rígidos, GPUS, e recursos de rede capazes de atender demandas gigantes de infraestrutura.

Cloud computing é um termo que surgiu com o avanço e aprimoramento da tecnologia, claro que anos atrás já era utilizada para serviços específicos. Porém com o passar do tempo a computação em nuvem se tornou mais comum e barata, empresas e usuários viram ótimas oportunidades de empreendimentos utilizando essa estrutura.

A Cloud Computing já é uma realidade não só no mercado mundial, como também no brasileiro. A série de vantagens que ela proporciona é bastante extensa, e é compreensível o motivo pelo qual esse mercado se tornou tão atrativo de maneira tão rápida e intensa: Cada vez mais empresas estão migrando seus sistemas para a Cloud Computing!

Mas quais são essas vantagens? Confira abaixo algumas delas:

Otimização de processos

A cloud computing automatiza a maioria das tarefas, como análise, manutenção e backup. São coisas simples que, quando somadas, fazem muita diferença no fim do dia de trabalho.

Mobilidade

A Cloud Computing permite o acesso móvel a dados corporativos por meio de dispositivos e smartphones, e essa é uma ótima maneira de garantir que ninguém seja deixado de lado.

Custo-benefício

Aqui, estamos falando de ROI – Retorno sobre investimento. Uma vez que sua empresa estiver na nuvem, o acesso fácil aos dados do negócio economizará dinheiro a cada processo. O serviço em Cloud é vendido e utilizado ‘as a service’, ou seja, você paga pelo recurso que utiliza. A diferença no cenário Cloud de hoje se da pela variedade de integração e recursos que a plataforma oferece, agregando custos extras em troca do serviço e gerenciamento do seu workflow. Para aqueles preocupados em pagar por recursos que não utilizam, a nuvem é ideal, pois para a maioria de seus serviços, você só paga pelo que consumir.

Recuperação de desastres

Outra das grandes vantagens da Cloud Computing é como ela permite que sua empresa contorne imprevistos. Serviços baseados em nuvem oferecem uma fácil recuperação de dados para todos os cenários de emergência, sejam eles desastres naturais ou simples quedas de energia.

Sustentabilidade

Por sua não exigência do uso de muitos equipamentos próprios, a computação em nuvem traz muitos benefícios de sustentabilidade, como economia de energia, de espaço, menor necessidade de sistemas de refrigeração, redução na emissão de dióxido de carbono, entre outros.

Com tantas possibilidades de agregar valor ao negócio, a Cloud Computing é uma transformação que deve ser buscada por quem deseja se diferenciar e obter um maior sucesso frente à concorrência no mercado.

O que você precisa, Office 365 ou Exchange Server? – Parte 2

Levantamos os custos de cada um dos itens envolvidos em uma solução de Exchange Server e montamos uma planilha que pode ser baixada sem custo aqui. Dessa forma conseguimos uma estimativa do custo inicial (lembrando que o ideal é trabalhar com depreciação total em 36 meses).

Assim conseguimos comparar os planos para pequenas e médias empresas (Business) onde chegamos ao comparativo abaixo, como esses planos são limitados a 300 contas, limitamos dessa forma.

Para fazer o comparativo acima, dividimos o investimento inicial por 36 (número de meses até a necessidade de troca dos equipamentos e licenças).

Agora para planos Enterprise (E1,E3 e E5) não há limite de contas, caso você não precise do pacote Office Offline, temos o ponto de encontro próximo há 300 contas. Coincidência, não?

Agora se você precisa do pacote Office Offline temos duas opções:
• Exchange Server + Pacote Office (em nosso exemplo usamos o standard)
• Office 365 Business ou >E3

Assim fizemos uma comparativo para essas opções, com o valor do Office Standard mentalizado (valor dividido por 36 meses) lembrando que o Business Essentials permite apenas 300 contas.

Considerações

Não consideramos custo com backup para solução com Exchange Server por entender que uma possível contingência e o de recursos do próprio Exchange Server (como archive e journaling) se equiparam a funcionalidades do Office 365.
O valor com Microsoft Windows foi considerado no valor do servidor.

Conclusão

Dessa forma, conseguimos chegar às seguinte conclusões:
• Do ponto de vista de funcionalidades, ambas as soluções possuem suas vantagens e desvantagens;
• Os custos iniciais com Exchange Server são sempre muito elevados;
• Para empresas com poucos usuários, o uso de Exchange não possuí um bom custo vs benefício;
• Os planos Business do Office 365 se mostram sempre com melhor custo que as soluções com Exchange Server.

DNS, dúvidas quando precisa hospedar uma aplicação? – PARTE 2

DNS, você sabe o que é, mas sempre tem dúvidas quando precisa hospedar uma aplicação?

Até então falamos apenas de solução de nomes para IP, porém não existe apenas esse tipo de resposta, essa é a principal função do DNS, porém não é a única.
Agora vamos entender as entradas DNS que podem ser utilizadas e quando utilizamos:

Entrada Tipo A

É a que falamos até agora, serve para resolver um nome como www.xpto.com.br para um IP como 200.200.200.1

Entrada do Tipo CNAME

Para facilitar a configuração são usadas entradas CNAME (do inglês Canonical Name, Apelido), que são entradas que apontam nomes DNS como www.xpto.com.br para outro nome como www.darede.com.br.

(Ferrou, agora babei!)

A sacada aqui é evitar a necessidade de mudar o DNS de www.xpto.com.br sempre que o IP mudar.
Imagina que o site www.xpto.com.br esteja no mesmo servidor que o www.darede.com.br que aponta para 200.1.1.1, caso tenhamos que mudar nosso provedor e trocar o IP 200.1.1.1 para outro IP, como 202.1.1.1, precisaremos trocar apenas a entrada www.darede.com.br e não o www.xpto.com.br. Uma vez que www.xpto.com.br continuará apontando para www.darede.com.br. Parece bobagem? Imagina que você tenha 1000 sites apontando para www.darede.com.br e mude a operadora 😱!

DNS

A desvantagem no uso de CNAME é que será necessário o cliente resolver duas vezes:
• www.xpto.com.br > www.darede.com.br
• www.darede.com.br > 200.1.1.1
Entradas CNAME hoje são muito utilizadas por serviços gerenciados (como AWS CloudFront, AWS ELB), uma vez que o serviço lhe oferece um nome e você cria um CNAME de seu domínio (como www.darede.com.br) e aponta para o nome oferecido pelo provedor do serviço. Caso os IPs da AWS mudem, nós não precisamos nos preocupar.

DICA:

De acordo com a RFC não é possível criar entradas do tipo CNAME para ‘naked domain’ (exemplo darede.com.br). Nesse caso temos que configurar uma entrada ‘A’ direto para o IP. Quando precisamos apontar o ‘naked domain’ para um serviço gerenciado (que não há IP fixo), temos duas opções:

1. Apontar para um servidor (esse sim com um IP fixo), e fazer um redirecionamento HTTP 301 para ele;

2. Para AWS, podemos usar uma entrada A com Alias. Alias é um recurso da AWS para criar entradas ‘A’ para serviços gerenciados AWS (como Elastic LoadBalancer, S3, CloudFront, API Gateway, etc). O AWS Route53 garante que a entrada sempre aponte para os IPs atuais do serviço gerenciado.

Entrada Tipo MX

Um e-mail é enviado para voce@seudominio.com.br certo? Qual o nome DNS do seu servidor de RECEBIMENTO de e-mails?
seudominio.com.br? NÃO. Geralmente seudominio.com.br aponta para seu site e não para seu servidor de recebimento de e-mail.
E agora? Para isso existe a entrada do tipo MX, que vem de Mail eXchange (também acho bizarro devia ser ME, kk!). O MX aponta para nossos servidores de recebimento de e-mails (SMTP/S).
Esse tipo de entrada pode apontar tanto para IP quanto para nomes, e possui uma particularidade, cada entrada possui dois valores:
• Nome ou IP do servidor de recebimento de e-mail;
• Prioridade, que é usada para redundância de servidores;

Entradas do tipo TXT

Para muitos serviços que surgiram anos após a primeira versão do protocolo HYPERLINK “https://www.ietf.org/rfc/rfc1034.txt”DNSs era preciso validar se um domínio é mesmo de propriedade de determinada pessoa/empresa. Como fazer isso?

Simples, lhe faço um desafio ao mantenedor do domínio. Crio um código de teste (como 123codigo) e peço para o mantenedor configurar uma entrada 123codigo.dominio.com.br, se essa entrada for criada, significa que realmente ele tem acesso ao SOA, logo posso confiar que ele é responsável por esse domínio.

Mas criar uma entrada ‘perdida’ para isso, parece uma gambiarra né? Como tudo em tecnologia que parece gambiara vira padrão. As entradas do tipo TXT surgiram para isso. É possível atribuir um texto qualquer (não apenas um nome ou IP) a essa entrada, que funciona como uma variável para qualquer finalidade.

O SPF que surgiu anos depois, é um exemplo de utilização de entrada TXT. Como o serviço de e-mail, que foi criado HYPERLINK “https://tools.ietf.org/html/rfc821” à HYPERLINK “https://tools.ietf.org/html/rfc821” HYPERLINK “https://tools.ietf.org/html/rfc821″décadas atrás, não possuía uma validação da origem do e-mail, qualquer um podia (e ainda pode) enviar e-mails em nome qualquer domínio. O SPF surgiu como um padrão para garantir o dono do domínio de origem possa informar ao servidor de recebimento (destino) os IPs que podem enviar e-mail em nome de @dominiodeorigem.com.br. Para isso era/é usada uma entrada TXT. Em 2014 foi criado um outro tipo de entrada DNS dedicada a SPF.

Um uso típico de entradas TXT é a validação de serviços cloud, como Google, AWS e Azure se você pode mesmo usar seu domínio.

Entrada Tipo PTR

É o contrário de entradas do Tipo ‘A’, usada para apontar um IP (200.1.1.1) para um nome (www.xpto.com.br).
Essa entrada causa muita confusão, uma vez que ela só pode ser usada pelo mantenedor do IP e não do domínio.
Em geral o mantenedor do IP é o provedor de seu Link de Internet ou serviço na nuvem. Assim somente o provedor poderá configurar o reverso de seu IP, caso precise, a única forma é abrir um chamado com eles.
Os usos práticos desse tipo de entrada são poucos, mas importantes:
• Identificação em caso de testes como traceroute por exemplo:

Note que alguns saltos não possuem Reverso (PTR) configurado

• Velocidade de algumas aplicações, como SSH e traceroute, uma vez que essas aplicações, de forma nativa, resolve o Reverso do IP, o que causa lentidão quando a entrada não existe por ficar tentando resolver;
• Controle SPAM, novamente o e-mail kkk! Como o SMTP foi inventado antes da invenção do SPAM, ele não previu seu uso, uma das técnicas para evitar SPAM é garantir que haja um vínculo entre o mantenedor do IP e seu utilizador, a técnica é simples. Se você está em uma LAN House, não vai conseguir pedir para configurar o reverso nele, então o servidor SMTP de recebimento espera que o IP aponte para um nome, e que esse nome aponte para o próprio IP. Caso isso não aconteça, o e-mail é considerado SPAM.

Trocando SOAs – Futuro
Tempo de replicação – Futuro

Modificando Parâmetro “Copy Tags to Snapshot” Aurora Postgres

Poucos sabem, mas todos os recursos da AWS são disponíveis via API, esse é um dos segredos do sucesso da AWS e de outras soluções de Cloud, pois dessa forma você pode automatizar qualquer operação da infraestrutura.

Porém alguns recursos não são disponíveis na Console (interface web), em geral a AWS lança novas funcionalidades primeiro apenas em API e posteriormente disponibiliza esse recurso na Console WEB.

Esse é um exemplo, em bancos de dados RDS Aurora Postgres não conseguimos alterar o valor “Copy tags to snapshots” (que é usado para colocar a mesma TAG que estão no RDS nos snaphots criados à partir dele), via Console WEB. Provavelmente essa funcionalidade deve ser implementada em breve, enquanto isso pode fazer via API, como via aws cli por exemplo:

—————————————————————

Opção desabilitada e pode ser vista em RDS > Instances > rds_name

—————————————————————

Ao tentar modificar essa opção não existe:

—————————————————————

Alteração não disponível em: RDS > Instances > instance_name > Modify

—————————————————————

Primeiro listamos os bancos que não estão com essa opção habilitada:

$ aws rds describe-db-instances --output table --region us-east-1 --query 'DBInstances[*].[DBInstanceIdentifier,CopyTagsToSnapshot]' | grep False
| db1-123445566123123 | False |
| db2-123445566123123 | False |
| db3-123445566123123 | False |
| db5-123445566123123 | False |
| db7-123445566123123 | False |
| db8-123445566123123 | False |
| db0-123445566123123 | False |

Agora podemos habilitar essa opção com o comando abaixo

$ aws rds modify-db-instance --db-instance-identifier db1-123445566123123 --copy-tags-to-snapshot --apply-immediately

O comando deverá retornar um json, com as informações atuais do banco (já com a modificação), que pode ser constatada inclusive via Console WEB.