As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # .NET Desenvolver e implantar aplicações .NET é um fator chave para ajudar você a alcançar a escala e a agilidade oferecidas pela computação em nuvem. Para muitos aplicativos.NET legados, a opção computacional mais adequada para executar aplicativos AWS é usar máquinas virtuais, seja por meio do AWS Elastic Beanstalk Amazon Elastic Compute Cloud (Amazon EC2). Também é possível executar aplicações .NET em contêineres Windows e Linux. A introdução do .NET Core permite que você crie aplicações .NET Modern que aproveitam todas as vantagens da nuvem. Os aplicativos modernos podem usar o conjunto tradicional de opções de computação e também atingir vários tipos de ambientes sem servidor, incluindo ou. AWS Fargate AWS Lambda O .NET 6\$1 agora oferece hospedagem de alta performance de workloads em instâncias ARM64 do EC2, como as famílias EC2 Graviton2. Isso permite o acesso à última geração de processadores disponíveis no Amazon EC2. Isso significa que suas aplicações podem ser hospedadas em computação especializada para seu tipo de workload, como codificação de vídeo, servidores web e computação de alta performance (HPC). ![\[Otimização dos custos do.NET para workloads da Microsoft\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/compute_options_net.png) Esta seção fornece recomendações para ajudar você a adaptar suas aplicações .NET para aproveitar os benefícios da nuvem com foco na eficiência de custos. **Topics** + [ # Refatorar para o .NET Modern e migrar para o Linux ](net-refactor-linux.md) + [ # Conteinerizar aplicações .NET ](net-containerize.md) + [ # Usar instâncias e contêineres do Graviton ](net-graviton.md) + [ # Suporte à escalabilidade dinâmica para aplicações .NET Framework estáticas ](net-static.md) + [ # Use o armazenamento em cache para reduzir a demanda do banco de dados ](net-caching.md) + [ # Considerar o .NET sem servidor ](net-serverless.md) + [ # Considerar bancos de dados com propósito específico ](net-purpose.md) # Refatorar para o .NET Modern e migrar para o Linux ## Visão geral do A modernização de aplicações .NET Framework legadas pode ajudar a melhorar a segurança, a performance e a escalabilidade. Uma forma eficaz de modernizar as aplicações .NET Framework é migrá-las para uma versão do .NET Modern (6\$1). Confira algumas das principais vantagens de migrar essas aplicações para o. NET de código aberto: + Para reduzir os custos de licenciamento do Windows executando-os em um sistema operacional Linux + Aproveitar a disponibilidade de linguagens modernas + Obtenha performance otimizada para execução no Linux Muitas organizações ainda estão executando versões mais antigas do .NET Framework. Isso pode representar riscos de segurança, já que as vulnerabilidades nas versões mais antigas não são mais tratadas pela Microsoft. A Microsoft encerrou o suporte para as versões recentes do. NET Framework 4.5.2, 4.6 e 4.6.1. É muito importante avaliar os riscos e as vantagens de continuar executando as versões mais antigas do framework. Para reduzir o risco e os custos, pode valer a pena investir tempo e esforço na refatoração para uma versão moderna do. NET. ## Impacto do custo Considere um tipo de instância do EC2 de uso geral (m5), que oferece um equilíbrio entre recursos de computação, memória e rede. Essas instâncias são adequadas para uma variedade de aplicações, como servidores web, bancos de dados de médio porte e repositórios de código-fonte. Por exemplo, uma instância m5.xlarge sob demanda com 4 V CPUs e 16 GB de memória no Windows Server (licença incluída) no Leste dos EUA (Norte da Virgínia) custa 274,48 USD mensais. Os mesmos recursos em um servidor Linux custam USD 140,16 por mês. Neste exemplo, há uma redução de 49% no custo quando você migra sua aplicação do. NET Framework para uma versão moderna do .NET e executa a aplicação em um servidor Linux. Seu custo pode variar dependendo das opções (por exemplo, tipo de instância, sistema operacional, armazenamento) que você escolher ao selecionar uma [instância do EC2](https://aws.amazon.com/ec2/instance-explorer/?ec2-instances-cards.sort-by=item.additionalFields.category-order&ec2-instances-cards.sort-order=asc&awsf.ec2-instances-filter-category=*all&awsf.ec2-instances-filter-processors=*all&awsf.ec2-instances-filter-accelerators=*all&awsf.ec2-instances-filter-capabilities=*all). Você pode otimizar ainda mais os custos usando [Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html) ou [Instâncias Reservadas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-reserved-instances.html). Para obter mais detalhes, use a [AWS Calculadora de Preços](https://calculator.aws/#/) para executar estimativas de custo. Para instâncias incluídas no Windows, o custo da licença é de [USD 0,046 por vCPU por hora](https://aws.amazon.com/ec2/dedicated-hosts/pricing/#Pricing_for_Dedicated_Hosts), independentemente do modelo de preços. A portabilidade dessas aplicações .NET Framework para o .NET Modern exige esforço do desenvolvedor. Você deve avaliar seus aplicativos e suas dependências para ver se eles são compatíveis com a versão da plataforma de destino. [AWS Assistente de Portabilidade para .NET](https://aws.amazon.com/blogs/aws/announcing-the-porting-assistant-for-net/) é uma ferramenta auxiliar que verifica aplicações .NET Framework e gera uma avaliação de compatibilidade do .NET, ajudando você a portar suas aplicações para serem compatíveis com o Linux mais rapidamente. O Assistente de Portabilidade para .NET identifica incompatibilidades com o .NET, encontra substitutos conhecidos e gera uma avaliação detalhada da compatibilidade. Depois de portar sua solução, você deve fazer alterações manuais no código para que seu projeto seja compilado com êxito com dependências. Isso reduz o esforço manual envolvido na modernização das suas aplicações para Linux. Se sua aplicação for compatível com processadores ARM, migrar para o Linux vai permitir usar instâncias do Graviton. Isso pode ajudar você a obter mais 20% em reduções adicionais de custos. Para obter mais informações, consulte [Powering .NET 5 com AWS Graviton2: Benchmarks](https://aws.amazon.com/blogs/compute/powering-net-5-with-aws-graviton2-benchmark-results/) in the Compute Blog. AWS Há outras ferramentas, como o [Kit de ferramentas da AWS para refatoração do .NET](https://docs.aws.amazon.com/tk-dotnet-refactoring/latest/userguide/what-is-tk-dotnet-refactoring.html) e o [Assistente de Portabilidade para .NET](https://learn.microsoft.com/en-us/dotnet/core/porting/upgrade-assistant-overview), que podem ajudar a portar aplicações .NET Framework legadas para o .NET Modern. ## Recomendações de otimização de custos Para migrar aplicações .NET Framework, faça o seguinte: 1. **Pré-requisitos**: para usar o Assistente de Portabilidade para .NET, você deve instalar o .NET 5\$1 na máquina em que planeja analisar o código-fonte da aplicação. Os recursos na máquina devem ter no mínimo 1,8 velocidade de GHz processamento, 4 GB de memória e 5 Gb de espaço de armazenamento. Para obter mais informações, consulte [Prerequisites](https://docs.aws.amazon.com/portingassistant/latest/userguide/porting-assistant-prerequisites.html) na documentação do Assistente de Portabilidade para .NET. 1. **Avaliação**: baixe o Assistente de Portabilidade para .NET como um arquivo [executável](https://s3.us-west-2.amazonaws.com/aws.portingassistant.dotnet.download/latest/windows/Porting-Assistant-Dotnet.exe) (download). Você pode baixar e instalar a ferramenta em sua máquina para iniciar a avaliação de suas aplicações. A página de avaliação contém projetos e pacotes portados APIs que são incompatíveis com o.NET moderno. Por esse motivo, você recebe erros de criação na solução após a avaliação. Você pode visualizar ou baixar as decobertas da avaliação em um arquivo CSV. Para obter mais informações, consulte [Port a solution](https://docs.aws.amazon.com/portingassistant/latest/userguide/porting-assistant-port.html) na documentação do Assistente de Portabilidade para .NET. 1. **Refatoração**: depois de avaliar a aplicação, você pode portar seus projetos para a versão do framework de destino. Ao portar uma solução, seus arquivos de projeto e parte do código serão modificados pelo Assistente de Portabilidade. Você pode verificar os logs para analisar as alterações em seu código-fonte. Na maioria dos casos, o código exigirá um esforço adicional para concluir a migração e os testes para deixá-lo pronto para produção. Dependendo da aplicação, algumas das alterações podem incluir o framework de entidades, a identidade e a autenticação. Para obter mais informações, consulte [Port a solution](https://docs.aws.amazon.com/portingassistant/latest/userguide/porting-assistant-port.html) na documentação do Assistente de Portabilidade para .NET. Esta é a primeira etapa para modernizar suas aplicações em contêineres. Pode haver vários fatores comerciais e técnicos para modernizar suas aplicações .NET Framework para contêineres Linux. Um dos fatores mais importantes é reduzir o custo total de propriedade ao mudar de um sistema operacional Windows para o Linux. Isso reduz os custos de licenciamento ao migrar sua aplicação para uma versão multiplataforma do .NET e para contêineres para otimizar a utilização dos recursos. Depois que sua aplicação for portada para o Linux, você poderá usar o [AWS App2Container](https://aws.amazon.com/app2container/) para conteinerizar sua aplicação. O App2Container usa o Amazon ECS ou o Amazon EKS como serviços de endpoint em que você pode implantar diretamente. O App2Container fornece todos os artefatos de implantação de infraestrutura como código (IaC) necessários para conteinerizar suas aplicações repetidamente. ## Considerações e recursos adicionais + Se você tiver aplicativos criados no VB.NET (uma estrutura legada de 2002) e quiser portá-los para o.NET 6, consulte a postagem Portar [aplicativos VB.NET legados para o.NET 6.0 com o Porting Assistant para.NET no blog](https://aws.amazon.com/blogs/modernizing-with-aws/port-legacy-vb-net-applications-to-net-6-0-with-porting-assistant-for-net/) Microsoft Workloads on. AWS + Se você tiver aplicações legadas no Windows Communication Foundation (WCF) e quiser executá-las no .NET Modern, você pode adotar o CoreWCF. Para obter mais informações, consulte a postagem [Modernizando aplicativos WCF legados para CoreWCF usando o Porting Assistant para.NET](https://aws.amazon.com/blogs/modernizing-with-aws/migrate-wcf-apps-to-wcfcore-using-porting-assistant/) no blog Microsoft Workloads on. AWS + Você pode adicionar o assistente de portabilidade como uma extensão ao seu IDE do Visual Studio. Isso permite que você execute todas as tarefas necessárias para converter seu código sem precisar alternar entre o IDE e a ferramenta Assistente de Portabilidade para .NET. Para obter mais informações, consulte a postagem [Acelere a modernização do aplicativo.NET com o Porting Assistant for .NET Visual Studio IDE](https://aws.amazon.com/blogs/modernizing-with-aws/net-modernization-with-pa-vs-ide-extension/) no blog Microsoft Workloads on AWS . + [O Assistente de Portabilidade para .NET da AWS agora é uma ferramenta de código aberto](https://aws.amazon.com/blogs/opensource/open-sourcing-the-porting-assistant-for-net/) com o código-fonte e os componentes de análise de compatibilidade da avaliação. Isso pode incentivar seus desenvolvedores a usar e compartilhar o conhecimento e as práticas recomendadas de portabilidade do .NET. + Você pode portar aplicativos do.NET framework para o.NET moderno no Linux usando o AWS Toolkit for .NET Refactoring. Para obter mais informações, consulte a postagem [Acelere a modernização do.NET com o AWS Toolkit for .NET Refactoring no blog](https://aws.amazon.com/blogs/modernizing-with-aws/aws-toolkit-for-net-refactoring-launch/) Microsoft Workloads on. AWS + Você pode [acelerar a conteinerização e a migração de aplicativos ASP.NET Core](https://aws.amazon.com/blogs/modernizing-with-aws/containerize-asp-net-core-applications-using-aws-app2container/) para o uso. AWS AWS App2Container # Conteinerizar aplicações .NET ## Visão geral do Os contêineres são uma forma leve e eficiente de empacotar e implantar aplicações de maneira consistente e reproduzível. Esta seção explica como você pode usar o AWS Fargate, um serviço de contêiner sem servidor para reduzir os custos de suas aplicações .NET e, ao mesmo tempo, fornecer uma infraestrutura escalável e confiável. ## Impacto do custo Alguns fatores que influenciam a eficácia do uso de contêineres para a redução de custos incluem o tamanho e a complexidade da aplicação, o número de aplicações que precisam ser implantadas e o nível de tráfego e demanda das aplicações. Para aplicações pequenas ou simples, os contêineres podem não oferecer reduções de custo significativas em comparação com as abordagens tradicionais de infraestrutura, pois a sobrecarga do gerenciamento dos contêineres e dos serviços associados pode, na verdade, aumentar os custos. No entanto, para aplicações maiores ou mais complexas, o uso de contêineres pode proporcionar uma redução de custos, melhorando a utilização de recursos e reduzindo o número de instâncias necessárias. Recomendamos que você tenha em mente o seguinte ao usar contêineres para redução de custos: + **Tamanho e complexidade da aplicação**: aplicações maiores e mais complexas são mais adequadas para a conteinerização porque tendem a exigir mais recursos e podem se beneficiar mais com a melhor utilização deles. + **Número de aplicações**: quanto mais aplicações sua organização precisar implantar, maior será a redução de custos por meio da conteinerização. + **Tráfego e demanda**: as aplicações que experimentam alto tráfego e demanda podem se beneficiar da escalabilidade e elasticidade que os contêineres oferecem. Isso pode resultar em uma redução de custos. Arquiteturas e sistemas operacionais diferentes afetam os custos dos contêineres. Se você estiver usando contêineres Windows, os custos podem não diminuir devido a considerações de licenciamento. Os custos de licenciamento são menores ou não existem com os contêineres Linux. O gráfico a seguir usa uma configuração básica AWS Fargate na região Leste dos EUA (Ohio) com as seguintes configurações: 30 tarefas por mês, cada uma sendo executada por 12 horas com 4 V CPUs e 8 GB de memória alocada. Você pode escolher entre duas plataformas de computação principais para executar seus contêineres AWS: [hosts de contêineres baseados em EC2 e](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US/module2-ecs/lab1-deploy-ecs-cluster) sem servidor ou. [AWS Fargate](https://aws.amazon.com/blogs/containers/running-windows-containers-with-amazon-ecs-on-aws-fargate/) Se você usar o Amazon Elastic Container Service (Amazon ECS) em vez do Fargate, mantenha a computação em execução (instâncias) para permitir que o mecanismo de posicionamento instancie contêineres quando necessário. Se você usar o Fargate, somente a capacidade computacional necessária será provisionada. O gráfico a seguir mostra a diferença entre contêineres equivalentes usando o Fargate e o Amazon EC2. Devido à flexibilidade do Fargate, as tarefas de uma aplicação podem ser executadas 12 horas por dia, sem utilização fora do horário de pico. No entanto, para o Amazon ECS, você deve controlar a capacidade computacional usando um [grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) de instâncias do EC2. Isso pode fazer com que a capacidade opere ininterruptamente, 24 horas por dia, o que pode, em última análise, aumentar os custos. ![\[Custos mensais do Fargate versus custos mensais do EC2\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/graph_fargate_ec2_costs.png) ## Recomendações de otimização de custos ### Use contêineres Linux em vez de Windows Você pode obter economias significativas se usar contêineres Linux em vez de contêineres Windows. Por exemplo, você pode obter uma economia de aproximadamente 45% nos custos de computação se executar o .NET Core em instâncias EC2 Linux em vez de executar o .NET Framework em instâncias EC2 Windows. Você pode obter uma economia adicional de 40% se usar a arquitetura ARM (AWS Graviton) em vez da x86. Se você planeja executar contêineres baseados em Linux para aplicações .NET Framework existentes, você deve portar essas aplicações para versões modernas e multiplataforma do .NET ([como o.NET 6.0](https://learn.microsoft.com/en-us/dotnet/core/releases-and-support)) para usar contêineres Linux. Uma consideração importante é ponderar o custo da refatoração em comparação com a economia de custos obtida com a redução do custo dos contêineres Linux. Para obter mais informações sobre como portar suas aplicações para o .NET Modern, consulte [Assistente de Portabilidade para .NET](https://aws.amazon.com/porting-assistant-dotnet/) na documentação da AWS . Outro benefício de migrar para o .NET Modern (ou seja, sair do .NET Framework) é que oportunidades adicionais de modernização ficam disponíveis. Por exemplo, você pode considerar a redefinição da arquitetura de sua aplicação para uma arquitetura baseada em microsserviços que seja mais escalável, ágil e econômica. O diagrama a seguir ilustra o processo de tomada de decisão para explorar oportunidades de modernização. ![\[Árvore de decisão da redefinição da plataforma\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/replatform_decision_tree.png) ### Aproveitar os Savings Plans Os contêineres podem ajudar você a aproveitar os [Savings Plans para computação](https://aws.amazon.com/savingsplans/compute-pricing/) para reduzir seus custos com o Fargate. O modelo de desconto flexível oferece os mesmos descontos que as Instâncias Reservadas Conversíveis. Os preços do Fargate são baseados nos recursos de vCPU e de memória usados desde o início do download da imagem do contêiner até o término da tarefa do Amazon ECS (arredondado para o segundo mais próximo). Os [Savings Plans do Fargate](https://aws.amazon.com/fargate/pricing/) oferecem economias de até 50% no uso do Fargate em troca do compromisso de utilizar uma quantidade específica de uso de computação (medida em dólares por hora) por um período de um ou três anos. Você pode usar o [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html) para ajudar você a escolher um dos Savings Plans. É importante entender que os Savings Plans para computação são aplicadoa ao uso que gera a maior economia em primeiro lugar. Por exemplo, se você estiver executando uma instância t3.medium do Linux em `us-east-2` e uma instância t3.medium idêntica do Windows, a instância do Linux receberá primeiro o benefício dos Savings Plans. Isso ocorre porque a instância do Linux tem um potencial de economia de 50%, enquanto a mesma instância do Windows tem um potencial de economia de 35%. Se você tiver outros recursos elegíveis do Savings Plans em execução no seu Conta da AWS, como Amazon EC2 ou Lambda, não é necessário que seus Savings Plans sejam aplicados primeiro ao Fargate. Para obter mais informações, consulte [Entendendo como os Savings Plans se aplicam ao seu AWS uso](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html) na documentação do Savings Plans e na seção [Otimizar gastos para Windows no Amazon EC2](savings-plans.md) deste guia. ### Tarefas do Fargate do tamanho certo É importante garantir que as tarefas do Fargate sejam dimensionadas corretamente para alcançar o grau máximo de otimização de custos. Frequentemente, os desenvolvedores não têm todas as informações de uso necessárias ao determinar inicialmente as configurações das tarefas do Fargate usadas em suas aplicações. Isso pode levar ao provisionamento excessivo de tarefas e, em seguida, resultar em gastos desnecessários. Para evitar isso, recomendamos que você carregue as aplicações de teste em execução no Fargate para entender a performance de uma configuração de tarefa específica em diferentes cenários de uso. Você pode usar os resultados do teste de carga, a vCPU, a alocação de memória das tarefas e as políticas de ajuste de escala automático para encontrar o equilíbrio certo entre performance e custo. O diagrama a seguir mostra como o Compute Optimizer gera recomendações para o tamanho ideal da tarefa e do contêiner. ![\[Recomendações do Compute Optimizer para o tamanho da tarefa e do contêiner\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/container_size_recommendations.png) Uma abordagem é usar uma ferramenta de teste de carga, como a descrita em [Distributed Load Testing on AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/), para estabelecer uma linha de base para a utilização da vCPU e da memória. Depois de executar o teste de carga para simular uma carga típica da aplicação, você pode ajustar a configuração da vCPU e da memória para a tarefa até que a utilização básica seja alcançada. ## Recursos adicionais do + [Cost Optimization Checklist for Amazon ECS and AWS Fargate](https://aws.amazon.com/blogs/containers/cost-optimization-checklist-for-ecs-fargate/) (publicação do blog AWS Containers) + [Otimização teórica de custos pelo tipo de lançamento do Amazon ECS: Fargate vs](https://aws.amazon.com/blogs/containers/theoretical-cost-optimization-by-amazon-ecs-launch-type-fargate-vs-ec2/) EC2 AWS (publicação no blog de contêineres) + [Assistente de portabilidade para.NET](https://aws.amazon.com/porting-assistant-dotnet/) (AWS documentação) + [Teste de carga distribuída em AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) (Biblioteca de AWS soluções) + [AWS Compute Optimizer lança suporte para serviços Amazon ECS em AWS Fargate(publicação no](https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-compute-optimizer-launches-support-for-amazon-ecs-services-on-aws-fargate/) blog AWS Cloud Financial Management) # Usar instâncias e contêineres do Graviton ## Visão geral do AWS As instâncias Graviton são alimentadas por processadores ARM projetados AWS para oferecer a melhor relação preço/desempenho para suas cargas de trabalho em nuvem executadas no Amazon Elastic Compute Cloud (Amazon EC2), incluindo contêineres em execução. AWS Atualmente, há três gerações do Graviton disponíveis para uso no Amazon EC2. Este guia se concentra no uso do Graviton 2 e 3 com aplicações .NET porque há uma economia significativa quando você usa as versões mais recentes do Graviton. Lembre-se de que instâncias do Graviton só executam o sistema operacional Linux. Como resultado, as instâncias do Graviton são uma boa oferta para o .NET em execução no Linux, mas não são uma opção para o sistema operacional Windows ou aplicações NET Framework legadas. O Graviton 3 é 60% mais eficiente do que as instâncias comparáveis do EC2, com performance até 40% melhor. Este guia se concentra nos benefícios de custo do uso do Graviton, mas é importante observar que o Graviton oferece os benefícios adicionais de melhorias de performance e maior sustentabilidade ambiental. ## Impacto do custo Você pode obter até 45% de economia ao mudar para o Graviton. Depois de refatorar qualquer aplicação .NET Framework legada para uma versão do .NET Modern, você habilita a capacidade de usar instâncias do Graviton. Mudar para o Graviton é uma técnica eficaz de otimização de custos para desenvolvedores .NET. O exemplo na tabela a seguir mostra o potencial de melhorias de performance que você pode obter ao migrar para instâncias do Graviton. ![\[Grafo de performance do Graviton\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/graph_graviton_performance.png) Para obter uma análise e uma explicação completas da abordagem de benchmarking usada para criar os resultados no diagrama anterior, consulte [Powering .NET 5 with AWS Graviton2: Benchmarks](https://aws.amazon.com/blogs/compute/powering-net-5-with-aws-graviton2-benchmark-results/) in the Compute Blog. AWS Uma das razões para a eficiência aprimorada é a diferença no significado de vCPU entre a x86 e o Graviton. Na arquitetura x86, uma vCPU é um núcleo lógico obtido pelo hyperthreading. No Graviton, vCPU equivale a um núcleo físico que permite que a vCPU esteja totalmente comprometida com a workload. O resultado com o Graviton2 é uma relação preço/performance 40% melhor do que instâncias x86/x64 comparáveis. O Graviton3 oferece as seguintes vantagens em relação ao Graviton2: + Um perfil de performance aprimorado com performance até 25% melhor + Performance de ponto flutuante até duas vezes maior + Performance da workload criptográfica até duas vezes mais rápida + Performance de machine learning até três vezes melhor Além disso, o Graviton3 é a primeira instância na nuvem a apresentar DDR5 memória. As tabelas a seguir mostram a diferença na redução de custos entre instâncias baseadas em Graviton e instâncias equivalentes baseadas em x86. Esta tabela mostra uma economia do Graviton de 19,20%. **** | Tipo de instância | Arquitetura | vCPU | Memória (GB) | Custo por hora (sob demanda) | | --- | --- | --- | --- | --- | | t4g.xlarge | Arm | 4 | 16 | \$10,134 | | t3.xlarge | x86 | 4 | 16 | 0,164 US\$1 | Esta tabela mostra uma economia do Graviton de 14,99%. **** | Tipo de instância | Arquitetura | vCPU | Memória (GB) | Custo por hora (sob demanda) | | --- | --- | --- | --- | --- | | c7g.4xlarge | Arm | 16 | 32 | \$10,5781 | | c6i.4xlarge | x86 | 16 | 32 | \$10.6800 | É importante testar o perfil de performance da sua aplicação ao considerar o Graviton. O Graviton não substitui práticas sólidas de desenvolvimento de software. Você pode usar os testes para verificar se está aproveitando ao máximo seus recursos computacionais subjacentes. ## Recomendações de otimização de custos Há várias maneiras de aproveitar as instâncias/processadores Graviton. Esta seção apresenta as mudanças necessárias para passar do uso de uma máquina com arquitetura x86 para instâncias do Graviton (ARM). ### Alterar a configuração de runtime no Lambda Recomendamos que você ative as configurações de tempo de execução AWS Lambda. Para obter mais informações, consulte [Modificar ambiente de runtime](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-modify.html) na documentação do Lambda. Como o .NET é uma linguagem compilada, você deve seguir um processo de criação para que isso funcione. Para obter um exemplo de como fazer isso, consulte. [NET em Graviton](https://github.com/aws/aws-graviton-getting-started/blob/main/dotnet.md) em GitHub. ### Contêineres Para uma workload conteinerizada, crie uma imagem de contêiner com várias arquiteturas. Você pode fazer isso especificando várias arquiteturas no comando de criação do Docker. Por exemplo: ``` docker buildx build -t "myImageName:latest" --platform linux/amd64,linux/arm64 --push . ``` Você também pode usar uma ferramenta AWS Cloud Development Kit (AWS CDK) para ajudar a [orquestrar a construção](https://aws.amazon.com/blogs/devops/build-and-deploy-net-web-applications-to-arm-powered-aws-graviton-2-amazon-ecs-clusters-using-aws-cdk/). Para obter exemplos do Docker, consulte [Building Multi-Arch Images for Arm and x86 with Docker Desktops](https://www.docker.com/blog/multi-arch-images/) na documentação do Docker. ### Amazon EC2 Para migrar de x86/x64 para o ARM, direcione a arquitetura ARM na etapa de compilação. No Visual Studio, você pode criar uma ARM64 CPU. Para obter instruções, consulte [To configure a project to target Arm64 and other platforms](https://learn.microsoft.com/en-us/visualstudio/ide/how-to-configure-projects-to-target-platforms?view=vs-2022) na documentação da Microsoft. Se você estiver usando a CLI do .NET, a execução da criação em uma máquina ARM produz uma criação compatível com o Graviton. Para ver uma demonstração, assista ao [desempenho do Accelerate .NET 6 com o Arm64 no AWS Graviton2 ligado](https://www.youtube.com/watch?v=iMlyZI9NhFw). YouTube Problemas de dependência resultarão em erros de tempo de compilação que podem ser resolvidos individualmente. Desde que existam bibliotecas ARM para qualquer dependência, a transição deve ser relativamente simples. ## Recursos adicionais do + [Como criar seus contêineres para ARM e economizar com instâncias Graviton e Spot no Amazon ECS (blog](https://aws.amazon.com/blogs/containers/how-to-build-your-containers-for-arm-and-save-with-graviton-and-spot-instances-on-amazon-ecs/))AWS + [AWS Lambda Funções alimentadas pelo processador AWS Graviton2 — Execute suas funções no Arm e obtenha um preço/desempenho até 34% melhor (](https://aws.amazon.com/blogs/aws/aws-lambda-functions-powered-by-aws-graviton2-processor-run-your-functions-on-arm-and-get-up-to-34-better-price-performance/)blog)AWS + [Migrando AWS Lambda funções para processadores AWS Graviton2 baseados em ARM](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-to-arm-based-aws-graviton2-processors/) (blog)AWS + [Crie e implante aplicativos web.NET em clusters Amazon ECS AWS Graviton 2 baseados em ARM](https://aws.amazon.com/blogs/devops/build-and-deploy-net-web-applications-to-arm-powered-aws-graviton-2-amazon-ecs-clusters-using-aws-cdk/) usando (blog) AWS CDKAWS + [Graviton Fast Start — Um novo programa para ajudar a transferir suas cargas de trabalho para o AWS Graviton](https://aws.amazon.com/blogs/aws/graviton-fast-start-a-new-program-to-help-move-your-workloads-to-aws-graviton/) (blog)AWS + [Alimentando o.NET 5 com AWS Graviton2: Benchmarks](https://aws.amazon.com/blogs/compute/powering-net-5-with-aws-graviton2-benchmark-results/) (blog)AWS # Suporte à escalabilidade dinâmica para aplicações .NET Framework estáticas ## Visão geral do Uma das principais vantagens de usar a nuvem para aplicações é a elasticidade, ou seja, a capacidade de aumentar ou reduzir horizontalmente a computação com base na demanda. Isso permite que você pague apenas pela capacidade computacional de que precisa, em vez de provisionar para o uso de pico. A Cyber Monday, em que os varejistas on-line podem obter rapidamente muito mais tráfego do que o normal (por exemplo, [milhares de pontos percentuais em questão de minutos](https://aws.amazon.com/blogs/startups/how-clicktale-uses-aws-to-power-a-successful-cyber-monday/)), é um bom exemplo de elasticidade. Se você estiver trazendo aplicações web .NET legadas para a nuvem (por exemplo, aplicações ASP.NET Framework executadas no IIS), a capacidade de escalar rapidamente os parques de servidores com balanceamento de carga pode ser difícil ou impossível devido à natureza estável da aplicação. Os dados da sessão do usuário são armazenados na memória da aplicação, geralmente com o [estado da sessão do ASP.NET](https://learn.microsoft.com/en-us/previous-versions/aspnet/ms178581(v=vs.100)) ou variáveis estáticas que contêm dados de solicitações cruzadas que devem ser persistidos. A afinidade da sessão do usuário geralmente é mantida por meio de sessões persistentes do balanceador de carga. Isso se prova um desafio operacional. Quando é necessário aumentar a capacidade, você deve provisionar e adicionar servidores intencionalmente. Isso pode ser um processo lento. Colocar os nós fora de serviço em caso de aplicação de patches ou falhas inesperadas pode ser problemático para a experiência do usuário final, perdendo o estado de todos os usuários associados aos nós afetados. Na melhor das hipóteses, os usuários precisarão fazer login novamente. Ao centralizar o estado da sessão para aplicações ASP.NET e aplicar regras de escalonamento automático às aplicações ASP.NET legadas, você pode aproveitar a elasticidade da nuvem e, possivelmente, aproveitar a redução de custos ao executar aplicações. Por exemplo, você obtém reduções de custo por meio da escalabilidade computacional, mas também pode escolher entre os diferentes modelos de preços disponíveis, como reduzir o [uso de instâncias reservadas](https://aws.amazon.com/ec2/pricing/reserved-instances/) e usar os [preços das instâncias spot da Amazon](https://aws.amazon.com/ec2/spot/). Duas técnicas comuns incluem o uso do [Amazon DynamoDB como provedor de estado de sessão](https://github.com/aws/aws-dotnet-session-provider) e o uso do [ ElastiCache Amazon (Redis OSS)](https://aws.amazon.com/blogs/developer/elasticache-as-an-asp-net-session-store/) como armazenamento de sessões do ASP.NET. O diagrama a seguir mostra uma arquitetura que usa o DynamoDB como provedor de estado de sessão. ![\[DynamoDB como provedor de estado de sessão\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/session_state_dynamodb.png) O diagrama a seguir mostra uma arquitetura que usa ElastiCache (Redis OSS) como provedor de estado de sessão. ![\[ElastiCache (Redis OSS) como provedor de estado de sessão\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/session_state_elasticache.png) ## Impacto do custo Para determinar as vantagens do dimensionamento para uma aplicação de produção, recomendamos que você modele a demanda real. Esta seção faz as seguintes suposições para modelar uma aplicação de exemplo: + As instâncias adicionadas e removidas da rotação são idênticas, e nenhuma variação no tamanho da instância é introduzida. + A utilização do servidor nunca cai abaixo de dois servidores ativos a fim de manter a alta disponibilidade da aplicação. + A quantidade de servidores é escalada linearmente com o tráfego (ou seja, o dobro do tráfego exigirá o dobro da computação). + O tráfego é modelado ao longo de um mês em incrementos de seis horas, com variação intradiária e um pico anormal de tráfego (por exemplo, uma venda promocional) em um dia de tráfego dez vezes maior. O tráfego de fim de semana é modelado com base na utilização básica. + O tráfego noturno é modelado com base na utilização básica, enquanto o tráfego durante a semana é modelado com uma utilização 4 vezes maior. + O preço de instância reservada usa o modelo de um ano, sem pagamento antecipado. O preço normal durante o dia usa o modelo sob demanda, enquanto a demanda de expansão usa o preço de instância spot. O diagrama a seguir ilustra como esse modelo aproveita a elasticidade em uma aplicação .NET em vez do provisionamento para uso de pico. Isso resulta em uma economia de aproximadamente 68%. ![\[Grafo dos custos do Auto Scaling\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/graph_autoscaling_costs.png) Se você usa o DynamoDB como um mecanismo de armazenamento do estado da sessão, use os seguintes parâmetros: ``` Storage: 20GB Session Reads: 40 million Session Writes: 20 million Pricing Model: On demand ``` O custo mensal estimado desse serviço é de aproximadamente USD 35,00 por mês. Se você usa ElastiCache (Redis OSS) como um mecanismo de armazenamento do estado da sessão, use os seguintes parâmetros: ``` Number of Nodes: 3 Node size: cache.t4g.medium Pricing Model: 1y reserved ``` O custo mensal estimado desse serviço é de aproximadamente USD 91,00 por mês. ## Recomendações de otimização de custos A primeira etapa é implementar o estado da sessão em uma aplicação .NET legada. Se você estiver usando ElastiCache como seu mecanismo de armazenamento de estado, siga as orientações de [ElastiCache como um repositório de sessões do ASP.NET no blog](https://aws.amazon.com/blogs/developer/elasticache-as-an-asp-net-session-store/) de ferramentas para AWS desenvolvedores. Se você estiver usando o DynamoDB, siga as orientações [de O que é AWS SDK para .NET o na documentação](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/welcome.html). SDK para .NET Se o aplicativo usar a **InProc**sessão para começar, certifique-se de que todos os objetos que você planeja armazenar na sessão possam ser serializados. Para fazer isso, use o atributo `SerializableAttribute` para marcar classes cujas instâncias serão armazenadas na sessão. Por exemplo: ``` [Serializable()] public class TestSimpleObject { public string SessionProperty {get;set;} } ``` Além disso, o .NET `MachineKey` deve ser o mesmo entre todos os servidores em uso. Normalmente é o caso quando instâncias são criadas de uma Imagem de máquina da Amazon (AMI) comum. Por exemplo: ``` ``` No entanto, é importante garantir que, se uma imagem base for alterada, ela será configurada com a mesma imagem de máquina .NET (configurável no IIS ou no nível do servidor). Para obter mais informações, consulte [SystemWebSectionGroup. MachineKey Propriedade](https://learn.microsoft.com/en-us/dotnet/api/system.web.configuration.systemwebsectiongroup.machinekey?view=netframework-4.8.1) na documentação da Microsoft. Finalmente, você deve determinar o mecanismo para adicionar servidores a um grupo do Auto Scaling em resposta a um evento de escalabilidade. Existem diversas maneiras de realizar isso. Recomendamos os seguintes métodos para implantar facilmente aplicações .NET Framework em uma instância do EC2 em um grupo do Auto Scaling: + Use o [EC2 Image Builder](https://aws.amazon.com/image-builder/) para configurar uma AMI que contenha o servidor e a aplicação totalmente configurados. Em seguida, você pode usar essa AMI para configurar o [modelo de inicialização do seu grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template.html). + Use [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)para implantar seu aplicativo. CodeDeploy permite a integração diretamente com o [Amazon EC2 Auto](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws-auto-scaling.html) Scaling. Isso fornece uma alternativa à criação de uma nova AMI para cada versão da aplicação. ## Recursos adicionais do + [Create images with EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/create-images.html) (documentação do EC2 Image Builder) + [Implantando aplicativos Web.NET usando o AWS CodeDeploy Visual Studio Team Services](https://aws.amazon.com/blogs/developer/deploying-net-web-applications-using-aws-codedeploy-with-visual-studio-team-services/) (blog de ferramentas para AWS desenvolvedores) # Use o armazenamento em cache para reduzir a demanda do banco de dados ## Visão geral do Você pode usar o armazenamento em cache como uma estratégia eficaz para ajudar a reduzir os custos de suas aplicações .NET. Muitas aplicações usam bancos de dados de backend, como o SQL Server, quando as aplicações exigem acesso frequente aos dados. O custo de manter esses serviços de backend para lidar com a demanda pode ser alto, mas você pode usar uma estratégia eficaz de armazenamento em cache para reduzir a carga nos bancos de dados de backend, reduzindo os requisitos de dimensionamento e escalabilidade. Isso pode ajudar a reduzir os custos e a melhorar a performance de suas aplicações. O armazenamento em cache é uma técnica útil para economizar nos custos relacionados à leitura de workloads pesadas que usam recursos mais caros, como o SQL Server. É importante usar a técnica certa para sua workload. Por exemplo, o armazenamento em cache local não é escalável e exige que você mantenha um cache local para cada instância de uma aplicação. Você deve ponderar o impacto na performance em comparação com os possíveis custos, para que o menor custo da fonte de dados subjacente compense quaisquer custos adicionais relacionados ao mecanismo de armazenamento em cache. ## Impacto do custo O SQL Server exige que você leve em consideração as solicitações de leitura ao dimensionar seu banco de dados. Isso pode afetar os custos, pois talvez seja necessário introduzir réplicas de leitura para acomodar a carga. Se você estiver usando réplicas de leitura, é importante entender que elas estão disponíveis somente na edição SQL Server Enterprise. Essa edição exige uma licença mais cara do que a edição SQL Server Standard. O diagrama a seguir foi projetado para ajudar você a entender a eficácia do armazenamento em cache. Ele mostra o Amazon RDS para SQL Server com quatro nós db.m4.2xlarge executando a edição SQL Server Enterprise. Ele é implantado em uma configuração multi-AZ com uma réplica de leitura. O tráfego de leitura exclusivo (por exemplo, consultas SELECT) é direcionado às réplicas de leitura. Em comparação, o Amazon DynamoDB usa um cluster r4.2xlarge de dois nós do DynamoDB Accelerator (DAX). O gráfico a seguir mostra os resultados da remoção da exigência de réplicas de leitura dedicadas que lidem com alto tráfego de leitura. ![\[Gráfico mostrando os resultados da remoção de réplicas de leitura dedicadas\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/graph_rds_dax.png) Você pode obter economias de custo significativas usando o armazenamento em cache local sem réplicas de leitura ou introduzindo o DAX lado a lado com o SQL Server no Amazon RDS como uma camada de armazenamento em cache. Essa camada é descarregada do SQL Server e reduz o tamanho do SQL Server necessário para executar o banco de dados. ## Recomendações de otimização de custos ### Armazenamento em cache local O armazenamento em cache local é uma das formas mais usadas de armazenar conteúdo em cache para aplicações hospedadas em ambientes on-premises ou na nuvem. Isso ocorre porque é relativamente fácil e intuitivo de implementar. O armazenamento em cache local envolve pegar conteúdo de um banco de dados ou de outra fonte e armazenar em cache localmente na memória ou no disco para acesso mais rápido. Essa abordagem, embora fácil de implementar, não é ideal para alguns casos de uso. Por exemplo, isso inclui casos de uso em que o conteúdo do armazenamento em cache precisa persistir ao longo do tempo, como preservar o estado da aplicação ou do usuário. Outro caso de uso é quando o conteúdo em cache precisa ser acessado de outras instâncias da aplicação. O diagrama abaixo ilustra um cluster do SQL Server altamente disponível com quatro nós e duas réplicas de leitura. ![\[Cluster do SQL Server altamente disponível com quatro nós e duas réplicas de leitura\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/dax_cluster.png) Com o armazenamento em cache local, talvez você precise balancear a carga do tráfego entre várias instâncias do EC2. Cada instância deve manter seu próprio cache local. Se o cache armazenar informações com estado, é necessário que haja commits regulares no banco de dados, e talvez os usuários precisem ser encaminhados para a mesma instância em cada solicitação subsequente (sessão persistente). Isso representa um desafio ao tentar escalar aplicações, pois algumas instâncias podem ser superutilizadas, enquanto outras são subutilizadas devido à distribuição desigual do tráfego. Você pode usar o armazenamento em cache local, na memória ou usando armazenamento local, para aplicações .NET. Para fazer isso, você pode adicionar funcionalidade para armazenar objetos em disco e recuperá-los quando necessário, ou consultar dados do banco de dados e persisti-los na memória. Para realizar o armazenamento em cache local na memória e no armazenamento local de dados de um SQL Server em C\$1, por exemplo, você pode usar uma combinação das bibliotecas `MemoryCache` e `LiteDB`. A `MemoryCache` fornece armazenamento em cache em memória, enquanto a `LiteDB` é um banco de dados NoSQL incorporado baseado em disco que é rápido e leve. Para realizar o armazenamento em cache em memória, use a biblioteca .NET `System.Runtime.MemoryCache`. O exemplo de código a seguir mostra como usar a classe `System.Runtime.Caching.MemoryCache` para armazenar dados em cache na memória. Essa classe fornece uma forma de armazenar dados temporariamente na memória da aplicação. Isso pode ajudar a melhorar a performance de uma aplicação ao reduzir a necessidade de buscar dados de um recurso mais caro, como um banco de dados ou uma API. Confira como o código funciona: 1. Uma instância estática privada de `MemoryCache` denominada `_memoryCache` é criada. O cache recebe um nome (`dataCache`) para identificá-lo. Em seguida, o cache armazena e recupera os dados. 1. O método `GetData` é um método genérico que usa dois argumentos: uma chave `string` e um delegado `Func` chamado `getData`. A chave é usada para identificar os dados em cache, enquanto o delegado `getData` representa a lógica de recuperação de dados que é executada quando os dados não estão presentes no cache. 1. O método primeiro verifica se os dados estão presentes no cache usando o método `_memoryCache.Contains(key)`. Se os dados estiverem no cache, o método recuperará os dados usando `_memoryCache.Get(key)` e os converterá no tipo esperado T. 1. Se os dados não estiverem no cache, o método chamará o delegado `getData` para buscar os dados. Em seguida, ele adiciona os dados ao cache usando `_memoryCache.Add(key, data, DateTimeOffset.Now.AddMinutes(10))`. Essa chamada especifica que a entrada do cache deve expirar após dez minutos, momento em que os dados são removidos do cache automaticamente. 1. O método `ClearCache` usa uma chave `string` como argumento e remove os dados associados a essa chave do cache usando `_memoryCache.Remove(key)`. ``` using System; using System.Runtime.Caching; public class InMemoryCache { private static MemoryCache _memoryCache = new MemoryCache("dataCache"); public static T GetData(string key, Func getData) { if (_memoryCache.Contains(key)) { return (T)_memoryCache.Get(key); } T data = getData(); _memoryCache.Add(key, data, DateTimeOffset.Now.AddMinutes(10)); return data; } public static void ClearCache(string key) { _memoryCache.Remove(key); } } ``` É possível usar o seguinte código: ``` public class Program { public static void Main() { string cacheKey = "sample_data"; Func getSampleData = () => { // Replace this with your data retrieval logic return "Sample data"; }; string data = InMemoryCache.GetData(cacheKey, getSampleData); Console.WriteLine("Data: " + data); } } ``` O exemplo a seguir mostra como usar o [LiteDB](https://www.litedb.org/) para armazenar dados em cache no armazenamento local. Você pode usar o LiteDB como alternativa ou complemento ao cache em memória. O código a seguir demonstra como usar a biblioteca LiteDB para armazenar dados em cache no armazenamento local. A classe `LocalStorageCache` contém as principais funções para gerenciar o cache. ``` using System; using LiteDB; public class LocalStorageCache { private static string _liteDbPath = @"Filename=LocalCache.db"; public static T GetData(string key, Func getData) { using (var db = new LiteDatabase(_liteDbPath)) { var collection = db.GetCollection("cache"); var item = collection.FindOne(Query.EQ("_id", key)); if (item != null) { return item; } } T data = getData(); using (var db = new LiteDatabase(_liteDbPath)) { var collection = db.GetCollection("cache"); collection.Upsert(new BsonValue(key), data); } return data; } public static void ClearCache(string key) { using (var db = new LiteDatabase(_liteDbPath)) { var collection = db.GetCollection("cache"); collection.Delete(key); } } } public class Program { public static void Main() { string cacheKey = "sample_data"; Func getSampleData = () => { // Replace this with your data retrieval logic return "Sample data"; }; string data = LocalStorageCache.GetData(cacheKey, getSampleData); Console.WriteLine("Data: " + data); } } ``` Se você tem um cache ou arquivos estáticos que não mudam com frequência, é possível armazenar esses arquivos no armazenamento de objetos do Amazon Simple Storage Service (Amazon S3). A aplicação pode recuperar o arquivo de cache estático na inicialização para usar localmente. Para obter mais detalhes sobre como recuperar arquivos do Amazon S3 usando o .NET, consulte [Baixar objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/download-objects.html) na documentação do Amazon S3. ### Armazenamento em cache com o DAX Você pode usar uma camada de cache que pode ser compartilhada entre todas as instâncias da aplicação. O [DynamoDB Accelerator (DAX](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.concepts.html)) é um cache em memória totalmente gerenciado e altamente disponível para o DynamoDB que pode proporcionar um aumento de dez vezes na performance. Você pode usar o DAX para reduzir custos diminuindo a necessidade de superprovisionar unidades de capacidade de leitura nas tabelas do DynamoDB. Isso é especialmente útil para workloads com muita leitura e que exigem leituras repetidas para chaves individuais. O preço do DynamoDB é baseado no modelo sob demanda ou mediante capacidade provisionada, portanto, o número de leituras e gravações por mês contribui para o custo. Se você leu workloads pesadas, os clusters do DAX podem ajudar a cortar os custos ao reduzir o número de leituras nas tabelas do DynamoDB. Para obter instruções sobre como configurar o DAX, consulte [Aceleração em memória com o DynamoDB Accelerator (DAX)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.html) na documentação do DynamoDB. Para obter informações sobre a integração de aplicativos.NET, assista [Integrando o Amazon DynamoDB DAX](https://www.youtube.com/watch?v=ZMkLhD8OxYQ) em seu aplicativo ASP.NET em. YouTube ## Recursos adicionais do + [Aceleração em memória com o DynamoDB Accelerator (DAX) - Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.html) (documentação do DynamoDB) + [Integrando o Amazon DynamoDB DAX](https://www.youtube.com/watch?v=ZMkLhD8OxYQ) em seu aplicativo ASP.NET () YouTube + [Baixar objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/download-objects.html) (documentação do Amazon S3) # Considerar o .NET sem servidor ## Visão geral do A computação sem servidor tornou-se uma abordagem conhecida para criar e implantar aplicações. Isso se deve principalmente à escalabilidade e à agilidade que a abordagem sem servidor oferece ao criar uma arquitetura moderna. No entanto, é importante considerar o impacto nos custos da computação sem servidor em alguns cenários. O Lambda é uma plataforma de computação sem servidor que permite que os desenvolvedores executem códigos sem a necessidade de servidores dedicados. O Lambda é uma opção particularmente atraente para desenvolvedores .NET que buscam reduzir os custos de infraestrutura. Com o Lambda, os desenvolvedores .NET podem desenvolver e implantar aplicações altamente escaláveis e com potencial para otimizar custos. Ao usar uma abordagem sem servidor, os desenvolvedores não provisionam mais servidores para lidar com solicitações de aplicações. Em vez disso, os desenvolvedores podem criar funções que são executadas sob demanda. Isso torna uma abordagem sem servidor mais escalável, gerenciável e potencialmente mais econômica do que executar, gerenciar e escalar máquinas virtuais. Como resultado, você paga apenas pelos recursos usados pela aplicação, sem precisar se preocupar com os recursos subutilizados ou os custos de manutenção do servidor. Os desenvolvedores podem usar versões modernas e multiplataforma do .NET para criar aplicações sem servidor que sejam rápidas, eficientes e econômicas. O .NET Core e as versões mais recentes são um framework gratuito e de código aberto que é mais adequado para execução em plataformas sem servidor em relação às versões anteriores do .NET Framework. Isso permite que os desenvolvedores reduzam o tempo de desenvolvimento e aumentem a performance da aplicação. O .NET Modern também é compatível com diversas linguagens de programação, incluindo C\$1 e F\$1. Por esse motivo, é uma opção atraente para desenvolvedores que desejam criar arquiteturas modernas na nuvem. Esta seção explica como você pode obter redução de custos usando o Lambda como uma opção sem servidor. Você pode otimizar ainda mais os custos fazendo o ajuste fino dos perfis de execução de suas funções do Lambda, dimensionando corretamente a alocação de memória das suas funções do Lambda, usando [AOT nativo](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7%2Cwindows) e migrando para funções baseadas em Graviton. ## Impacto do custo O quanto você pode reduzir custos depende de vários fatores, incluindo quantas execuções suas funções sem servidor executarão, além da quantidade de memória alocada e da duração de cada função. AWS Lambda oferece um nível gratuito, que inclui um milhão de solicitações gratuitas por mês e 400.000 GB de segundos de tempo de computação por mês. Você pode reduzir significativamente os custos mensais de workloads que estão dentro ou perto desses limites de nível gratuito. Também pode haver custos adicionais ao usar um balanceador de carga com funções do Lambda como destino. Isso é calculado como a quantidade de dados processados pelo balanceador de carga para os [destinos do Lambda](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html). ## Recomendações de otimização de custos ### Dimensionar corretamente suas funções do Lambda O dimensionamento correto é uma prática essencial para a otimização de custos em funções do Lambda baseadas em .NET. Esse processo envolve a identificação da configuração de memória ideal que equilibra performance e economia, sem exigir alterações no código. Ao configurar a memória para uma função do Lambda, variando de 128 MB a 10.240 MB, você também ajusta a quantidade de vCPU disponível durante a invocação. Isso permite que aplicações vinculadas à memória ou à CPU acessem recursos adicionais durante a execução, levando a uma possível redução na duração da invocação e no custo geral. No entanto, identificar a configuração ideal para suas funções do Lambda baseadas em .NET pode ser um processo manual e demorado, especialmente se as alterações forem frequentes. A [ferramenta Power Tuning do AWS Lambda](https://github.com/alexcasalboni/aws-lambda-power-tuning) pode ajudar você a identificar a configuração apropriada analisando um conjunto de configurações de memória em relação a um exemplo de carga útil. Por exemplo, aumentar a memória de uma função do Lambda baseada em .NET pode levar a um melhor tempo total de invocação e a um custo reduzido sem afetar a performance. A configuração de memória ideal para uma função pode variar. A ferramenta AWS Lambda Power Tuning pode ajudar a identificar a configuração mais econômica para cada função. No gráfico de exemplo a seguir, o tempo total de invocação melhora à medida que a memória aumenta para essa função do Lambda. Isso leva a uma redução no custo da execução total sem afetar a performance original da função. Para essa função, a configuração de memória ideal para a função é de 512 MB, pois é aqui que a utilização de recursos é mais eficiente para o custo total de cada invocação. Isso varia de acordo com a função, e o uso da ferramenta em suas funções do Lambda pode identificar se elas se beneficiam do dimensionamento correto. ![\[Grafo do tempo de invocação\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/graph_invocation_time.png) Recomendamos que você conclua esse exercício regularmente, como parte de qualquer teste de integração quando novas atualizações forem lançadas. Se houver atualizações com pouca frequência, faça esse exercício periodicamente para garantir que as funções estejam ajustadas e dimensionadas corretamente. Depois de identificar a configuração de memória apropriada para suas funções do Lambda, você pode adicionar o dimensionamento correto aos seus processos. A ferramenta AWS Lambda Power Tuning gera uma saída programática que pode ser usada por seus fluxos de trabalho de CI/CD durante o lançamento do novo código. Isso permite que você automatize a configuração de memória. Você pode baixar a [ferramenta Power Tuning do AWS Lambda](https://github.com/alexcasalboni/aws-lambda-power-tuning) gratuitamente. Para obter instruções sobre como usar a ferramenta, consulte [Como executar a máquina de estado](https://github.com/alexcasalboni/aws-lambda-power-tuning/blob/master/README-EXECUTE.md) em GitHub. O Lambda também é compatível com o AOT nativo, o que permite que aplicações .NET sejam pré-compiladas. Isso pode ajudar a reduzir custos ao diminuir os tempos de execução das funções .NET. Para obter mais informações sobre a criação de funções nativas de AOT, consulte [.NET functions with native AOT compilation](https://docs.aws.amazon.com/lambda/latest/dg/dotnet-native-aot.html) na documentação do Lambda. ### Evitar tempo de espera ocioso A duração da função do Lambda é uma dimensão usada para calcular o faturamento. Quando o código de função faz uma chamada de bloqueio, você é cobrado pelo tempo que ele espera para receber uma resposta. Esse tempo de espera pode aumentar quando as funções do Lambda são encadeadas ou quando uma função está atuando como orquestradora para outras funções. Se você tiver fluxos de trabalho, como operações em lote ou sistemas de entrega de pedidos, isso aumenta a sobrecarga de gerenciamento. Além disso, talvez não seja possível concluir toda a lógica do fluxo de trabalho e o tratamento de erros dentro do tempo limite máximo do Lambda de 15 minutos. Em vez de lidar com essa lógica no código da função, recomendamos que você reestruture sua solução para usar o [AWS Step Functions](https://aws.amazon.com/step-functions/) como orquestrador do fluxo de trabalho. Ao usar um fluxo de trabalho padrão, você é cobrado por cada transição de [estado](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-states.html) dentro do fluxo de trabalho, em vez da duração total do fluxo de trabalho. Além disso, você pode mover o suporte para novas tentativas, condições de espera, fluxos de trabalho de erro e [retornos de chamada](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token) para a condição de estado a fim de permitir que suas funções do Lambda se concentrem na lógica de negócios. Para obter mais informações, consulte [Otimizando seus AWS Lambda custos — Parte 2](https://aws.amazon.com/blogs/compute/optimizing-your-aws-lambda-costs-part-2/) no blog sobre AWS computação. ### Migrar para funções baseadas em Graviton As funções do Lambda alimentadas pelos processadores Graviton2 de próxima geração agora estão disponíveis ao público em geral. As funções do Graviton2, usando uma arquitetura de processador baseada em ARM, foram projetadas para oferecer uma performance até 19% melhor a um custo 20% menor para uma variedade de workloads sem servidor. Com menor latência e melhor performance, as funções baseadas em processadores Graviton2 são ideais para alimentar aplicações sem servidor de missão crítica. A migração para funções do Lambda baseadas em Graviton pode ser uma opção econômica para desenvolvedores .NET que desejam otimizar seus custos do Lambda. As funções baseadas em Graviton usam processadores baseados em ARM em vez dos processadores x86 tradicionais. Isso pode levar a uma economia significativa de custos sem sacrificar a performance. Embora haja vários benefícios em migrar para funções baseadas em Graviton, também há vários desafios e considerações que recomendamos que você considere. Por exemplo, funções baseadas em Graviton exigem o uso do Amazon Linux 2, que pode não ser compatível com todas as aplicações .NET. Além disso, pode haver problemas de compatibilidade com bibliotecas ou dependências de terceiros que não são compatíveis com processadores baseados em ARM. Se você estiver executando aplicações .NET Framework e quiser aproveitar as vantagens da tecnologia sem servidor com o Lambda, considere a possibilidade de portar as aplicações para o .NET Modern usando o [Assistente de Portabilidade para .NET](https://aws.amazon.com/porting-assistant-dotnet/). Isso pode ajudar você a acelerar a migração de aplicações .NET legadas para o .NET Modern, permitindo que a aplicação seja executada no Linux. O gráfico a seguir compara os resultados das arquiteturas x86 e ARM/Graviton2 para uma função que calcula números primos. ![\[Comparação entre as arquiteturas x86 e ARM/Graviton2\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/graph_prime_numbers.png) A função está usando um único thread. A menor duração para as duas arquiteturas é relatada quando a memória é configurada com 1,8 GB. Acima disso, as funções do Lambda têm acesso a mais de uma vCPU, mas, nesse caso, a função não pode usar a capacidade adicional. Pelo mesmo motivo, os custos ficam estáveis com uma memória de até 1,8 GB. Com mais memória, os custos aumentam porque não há benefícios adicionais de performance para essa workload. O processador Graviton2 está claramente fornecendo melhor performance e custos mais baixos para essa função de computação intensiva. Para configurar sua função para usar um processador baseado em ARM com Graviton, faça o seguinte: 1. Faça login no Console de gerenciamento da AWS e abra o console [Lambda](https://console.aws.amazon.com/lambda/). 1. Escolha a opção **Criar função**. 1. Em **Function name (Nome da função)**, insira um nome. 1. Em **Runtime**, escolha **.NET 6 (C\$1/ PowerShell**). 1. Em **Arquitetura**, selecione **amd64**. 1. Faça as configurações adicionais necessárias e escolha **Criar função**. ## Recursos adicionais do + [Funções do Lambda como alvos (documentação](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html))AWS + [Otimizando o AWS Lambda custo e o desempenho usando AWS Compute Optimizer](https://aws.amazon.com/blogs/compute/optimizing-aws-lambda-cost-and-performance-using-aws-compute-optimizer/) (AWS Compute Blog) + [Otimizando seus AWS Lambda custos — Parte 1](https://aws.amazon.com/blogs/compute/optimizing-your-aws-lambda-costs-part-1/) (AWS Compute Blog) + [Otimizando seus AWS Lambda custos — Parte 2](https://aws.amazon.com/blogs/compute/optimizing-your-aws-lambda-costs-part-2/) (AWS Compute Blog) + [Criando aplicativos.NET sem servidor AWS Lambda usando o.NET 7](https://aws.amazon.com/blogs/compute/building-serverless-net-applications-on-aws-lambda-using-net-7/) (AWS Compute Blog) # Considerar bancos de dados com propósito específico ## Visão geral do Um dos aspectos mais caros da execução de workloads baseadas na Microsoft é o licenciamento de bancos de dados comerciais, como o SQL Server. As empresas geralmente padronizam o SQL Server como a plataforma de banco de dados preferencial, e ele passa a fazer parte da cultura de desenvolvimento da organização. Os desenvolvedores geralmente escolhem um modelo relacional baseado no SQL Server, independentemente do caso de uso. Os motivos para isso incluem: + A empresa já tem and/or licenças de instâncias do SQL Server disponíveis. + As equipes se habituaram ao modelo de programação SQL por meio do uso de bibliotecas compartilhadas e lógica de negócios. ORMs + A gerência não está ciente das alternativas. + Os desenvolvedores não estão cientes das alternativas. Bancos de dados com propósito específico podem acomodar os padrões de acesso aos dados do seu caso de uso. Esses bancos de dados são cada vez mais adotados pelas empresas à medida que adotam arquiteturas mais modernas (como microsserviços) e que o escopo de aplicações individuais é reduzido. Um banco de dados com propósito específico não inviabiliza um modelo relacional nem exige um modelo NoSQL (não relacional). Na verdade, um banco de dados relacional é considerado como propósito específico quando selecionado em resposta às necessidades específicas de uma workload. O uso de banco de dados com propósito específico pode ajudar as equipes a reduzir os custos de banco de dados associados às suas aplicações .NET, além de obter as vantagens padrão da nuvem, como escalabilidade, resiliência e redução esforço indiferenciado e pesado. A tabela a seguir mostra os bancos de dados desenvolvidos especificamente oferecidos pelo. AWS **** | Banco de dados | Tipo | Características | | --- | --- | --- | | [Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html) ou [Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.html) | Relacional | Casos de uso em que os dados têm uma estrutura fixaOs bancos de dados relacionais mantêm naturalmente a consistência de dados por meio de transações ACID | | [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) | Par de chave/valor | Banco de dados NoSQL que armazena dados usando uma estrutura de dados de tabela hashArmazenamento e recuperação de dados não estruturados de alta performanceOs casos de uso incluem perfis de usuário, estado da sessão e dados do carrinho de compras | | [Amazon ElastiCache](https://aws.amazon.com/elasticache/) | Na memória | Banco de dados NoSQL de alta performance que armazena dados não estruturados na memória com tempo de acesso inferior a um milissegundoUsado para dados efêmeros acessados com frequência, como sessões de usuário e como uma camada de cache na frente de outros armazenamentos de dados mais lentosInclui suporte para ElastiCache (Redis OSS) e ElastiCache (Memcached) | | [Amazon MemoryDB](https://aws.amazon.com/memorydb/) | Em memória durável | Banco de dados com propósito específico compatível com Redis com armazenamento durável | | [Amazon Timestream](https://aws.amazon.com/timestream/) | Séries temporais | Banco de dados projetado para ingestão de dados de throughput em ordem temporalOs casos de uso incluem aplicações de Internet das Coisas (IoT) e armazenamento de dados de telemetria ou métricas. | | [ Amazon DocumentDB](https://aws.amazon.com/documentdb/) | Documento | Banco de dados NoSQL que armazena dados sem uma estrutura prescrita ou relações forçadas com outros dadosGeralmente usado para workloads intensivas em leitura, como catálogos de produtos | | [Amazon Neptune](https://aws.amazon.com/neptune/) | Gráfico | Banco de dados NoSQL que contém dados e uma representação das conexões entre itens de dadosOs casos de uso incluem detecção de fraudes, mecanismos de recomendações e aplicações sociais | | [Amazon Keyspaces](https://aws.amazon.com/keyspaces/) | Coluna larga | Banco de dados distribuído de alta performance baseado no Apache CassandraOs casos de uso incluem aplicações de IoT, processamento de eventos e aplicações de jogos | Um fator significativo para a adoção de bancos de dados com propósito específico pode ser atribuído à remoção da necessidade do licenciamento comercial. No entanto, a capacidade de ajuste de escala automático de bancos de dados como o [DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) (incluindo o [modo sob demanda](https://aws.amazon.com/blogs/aws/amazon-dynamodb-on-demand-no-capacity-planning-and-pay-per-request-pricing/)), [Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html), [Amazon Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/manage-console-autoscaling.html) e [Amazon Keyspaces](https://docs.aws.amazon.com/keyspaces/latest/devguide/autoscaling.html) permite que você provisione capacidade para o caso médio, em vez de para o uso de pico. Bancos de dados com propósito específico, como o Timestream, usam tecnologia sem servidor e são escalados automaticamente para atender à demanda sem nenhum pré-provisionamento. AWS oferece o [Babelfish for Aurora PostgreSQL](https://aws.amazon.com/rds/aurora/babelfish/) se você quiser usar um banco de dados relacional de código aberto compatível com um propósito específico, mas não puder ou não quiser fazer alterações significativas no código do seu aplicativo. Em alguns casos, o Babelfish permite que você use um código de acesso existente do SQL Server, quase sem alterações. Ao escolher um banco de dados relacional com propósito específico para aplicações, é importante manter os mesmos recursos (ou funcionalmente equivalentes) de que você precisa para suas aplicações. Essa recomendação aborda bancos de dados com propósito específico como um armazenamento de dados primário para aplicações. Aplicações específicas (como armazenamento em cache) são abordadas em outras recomendações. ## Impacto do custo A adoção de bancos de dados específicos para cargas de trabalho do.NET, embora seja improvável que afete diretamente a computação, pode influenciar consumption/cost diretamente o custo dos serviços de banco de dados consumidos pelos aplicativos.NET. Na verdade, a economia de custos pode ser uma meta secundária, quando comparada aos benefícios adicionais de agilidade, escalabilidade, resiliência e durabilidade dos dados. Está fora do escopo deste guia explicar o processo completo de escolha de um banco de dados com propósito específico para aplicações e a redefinição da arquitetura de uma estratégia de dados para usá-los de forma eficaz. Para obter mais informações, consulte [Purpose-built databases](https://aws.amazon.com/tutorials/purpose-built-databases/) no diretório de tutoriais da AWS . As tabelas a seguir mostram vários exemplos de como a substituição do SQL Server por um banco de dados com propósito específico pode alterar os custos da aplicação. Observe que estas são apenas estimativas aproximadas. São necessárias avaliações comparativas e otimização das workloads reais para calcular o custo exato de produção. Estas são algumas estimativas comumente usadas para bancos de dados com propósito específico, que incluem computação sob demanda e SSD de 100 GB e bancos de dados de instância única em `us-east-1`. Os custos de licença incluem a licença do SQL Server e a garantia de software. A tabela a seguir mostra os custos estimados para exemplos de bancos de dados comerciais. **** | mecanismo de banco de dados | Modelo de licenciamento | Tipo/espec. da instância | AWS custo de computação \$1 armazenamento | Custo da licença | Custo mensal total | | --- | --- | --- | --- | --- | --- | | Edição SQL Server Standard no Amazon EC2 | Licença incluída | r6i.2xlarge (8 CPU/64 GB de RAM) | \$11.345,36 | \$10,00 | \$11.345,36 | | Edição SQL Server Enterprise no Amazon EC2 | Licença incluída | r6i.2xlarge (8 CPU/64 GB de RAM) | \$12.834,56 | \$10,00 | \$12.834,56 | | Edição SQL Server Standard no Amazon EC2 | BYOL | r6i.2xlarge (8 CPU/64 GB de RAM) | \$1644,56 | \$1456,00 | \$11.100,56 | | Edição SQL Server Enterprise no Amazon EC2 | BYOL | r6i.2xlarge (8 CPU/64 GB de RAM) | \$1644,56 | \$11.750,00 | \$12.394,56 | | Edição SQL Server Standard no Amazon RDS |   | db.r6i.2xlarge (8 CPU/64 GB de RAM) | \$12.318,30 | \$10,00 | \$12.318,30 | | Edição SQL Server Enterprise no Amazon RDS |   | db.r6i.2xlarge (8 CPU/64 GB de RAM) | \$13.750,56 | \$10,00 | \$13.750,56 | A tabela a seguir mostra os custos estimados para exemplos com propósito específico. **** | mecanismo de banco de dados | Tipo/espec. da instância | AWS custo de computação \$1 armazenamento | Custo da licença | Custo mensal total | | --- | --- | --- | --- | --- | | Amazon Aurora PostgreSQL | r6g.2xlarge (8 CPU/64 GB de RAM) | \$1855,87 | \$10,00 | \$1855,87 | | DynamoDB | Base provisionada de 100 WCU/400 RCU | \$172,00 |   | \$172,00 | | Amazon DocumentDB | db.r6i.2xlarge (8 CPU/64 GB de RAM) | \$1778.60 |   | \$1778.60 | **Importante** A tabela é baseada nos custos estimados de licenciamento do SQL Server com o Software Assurance, durante os primeiros três anos da compra. Para a edição SQL Server Standard: USD 4.100, pacote de 2 núcleos, 3 anos. Para a edição SQL Server Enterprise: USD 15.700, pacote de 2 núcleos, 3 anos. Recomendamos considerar as implicações de custos antes de adotar bancos de dados com propósito específico. Por exemplo, o custo de atualizar aplicações para usar um banco de dados com propósito específico está relacionado à complexidade da aplicação e do banco de dados de origem. Certifique-se de considerar o custo total de propriedade ao planejar essa mudança de arquitetura. Isso inclui refatorar suas aplicações, requalificar a equipe em novas tecnologias e planejar cuidadosamente a performance e o consumo previstos para cada workload. Com base nisso, você pode determinar se o investimento vale a redução de custos. Na maioria dos casos, manter um end-of-support produto é um risco de segurança e conformidade, e o custo de remediá-lo vale o esforço e o investimento inicial. ## Recomendações de otimização de custos Para aplicações .NET que acessam o SQL Server, existem bibliotecas substitutas para bancos de dados relacionais com propósito específico. Você pode implementar essas bibliotecas em sua aplicação para substituir funcionalidades de aplicação semelhantes às do SQL Server. A tabela a seguir destaca algumas bibliotecas que podem ser usadas em muitos cenários comuns. **** | Biblioteca | Banco de dados | Substituição para | Compatibilidade do Framework | | --- | --- | --- | --- | | [Npgsql Entity Framework Core Provider](https://www.npgsql.org/efcore/index.html) | Amazon Aurora PostgreSQL | Entity Framework Core SQL Server Provider | Modern .NET | | [Npgsql Entity Framework 6 Provider](https://www.npgsql.org/ef6/index.html) | Amazon Aurora PostgreSQL | Entity Framework 6.0 SQL Server Provider | NET Framework | | [Npgsql](https://www.npgsql.org/doc/index.html) (biblioteca PostgreSQL compatível com ADO.NET) | Amazon Aurora PostgreSQL | ADO.NET | Framework/Modern .NET | | [MySQL Entity Framework Core Provider](https://dev.mysql.com/doc/connector-net/en/connector-net-entityframework-core.html) | Amazon Aurora MySQL | Entity Framework Core SQL Server Provider | Modern .NET | | [Pomelo. EntityFrameworkCore. MySql](https://www.nuget.org/packages/Pomelo.EntityFrameworkCore.MySql) | Amazon Aurora MySQL | Entity Framework Core SQL Server Provider | Modern .NET | [Conectar-se ao Amazon Aurora PostgreSQL usando o Babelfish](https://babelfishpg.org/docs/client/csharp/) não requer nenhuma codificação especial. No entanto, todo código deve ser exaustivamente testado antes de ser usado. Outros bancos de dados com propósito específico têm bibliotecas para acessar bibliotecas compatíveis com o .NET que permitem acessar bancos de dados com propósito específico. Os exemplos incluem: + [Usando bancos de dados NoSQL do Amazon DynamoDB (documentação)](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/dynamodb-intro.html)AWS SDK para .NET + [MongoDB C\$1 Driver](https://www.mongodb.com/docs/drivers/csharp/current/) (documentação do MongoDB) + [.NET](https://docs.aws.amazon.com/timestream/latest/developerguide/getting-started.dot-net.html) (documentação do Timestream) + [Using a Cassandra .NET Core client driver to access Amazon Keyspaces programmatically](https://docs.aws.amazon.com/keyspaces/latest/devguide/using_dotnetcore_driver.html) (documentação do Amazon Keyspaces) + [Using .NET to connect to a Neptune DB instance](https://docs.aws.amazon.com/neptune/latest/userguide/access-graph-gremlin-dotnet.html) (documentação do Neptune) Se você migrar para bancos de dados criados especificamente, poderá usar essas ferramentas AWS para ajudar no processo de migração: + O [AWS Schema Conversion Tool (AWS SCT)](https://aws.amazon.com/dms/schema-conversion-tool/) pode ajudar a transformar os esquemas do SQL Server para o Amazon Aurora e no Amazon DynamoDB. + O [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/schema-conversion-tool/) pode ajudar a migrar dados, uma vez ou continuamente, do SQL Server para o Aurora ou o DynamoDB. + O [Babelfish Compass](https://github.com/babelfish-for-postgresql/babelfish_compass) pode ajudar a verificar a compatibilidade do seu banco de dados SQL Server para uso com o Babelfish para Aurora PostgreSQL. ## Recursos adicionais do + [Guidance for migrating SQL Server to Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-sql-server-to-amazon-aurora-postgresql-using-best-practices-and-lessons-learned-from-the-field/) (blog AWS Database) + [Dia de Imersão na Modernização do Babelfish APP](https://catalog.workshops.aws/babelfish-app-modernization/en-US) (Workshop Studio)AWS + [Dia de imersão do.NET](https://catalog.us-east-1.prod.workshops.aws/workshops/02696107-09ac-4313-a6cb-3798048b07d7/en-US/3-choosing-a-cloud-native-database-for-my-net-application) (AWS Workshop Studio) + [Introdução ao Amazon Timestream com](https://github.com/awslabs/amazon-timestream-tools/tree/mainline/sample_apps/dotnet) o.NET () GitHub + [Bancos de dados específicos para aplicativos.NET modernos em AWS](https://d1.awsstatic.com/events/Summits/reinvent2022/XNT304_Purpose-built-databases-for-modern-NET-applications-on-AWS.pdf) (apresentação)AWS