Guia

Autenticação de identidade híbrida onde os hashes de senha devem permanecer on-prem, com failover.

→Azure AD Connect com Autenticação de Passagem (PTA) e Sincronização de Hash de Senha (PHS) habilitada como backup.

Por quê: PTA mantém os hashes on-prem validando contra o AD local. PHS fornece failover de autenticação se o AD on-prem ou o agente Connect estiver indisponível.

Referência↗

Implementar Zero Trust aplicando controle de acesso granular baseado em usuário, localização, saúde do dispositivo e risco.

→Políticas de Acesso Condicional do Microsoft Entra combinando Localizações Nomeadas, conformidade do dispositivo (Intune) e risco de login (Identity Protection) com controles de concessão como MFA.

Por quê: O Acesso Condicional é o motor de aplicação para Zero Trust, avaliando múltiplos sinais por solicitação antes de conceder acesso. Uma única política não pode aplicar controles diferentes a condições diferentes.

Referência↗

Aplicar políticas consistentes (ex: marcação, regiões permitidas) em dezenas ou centenas de assinaturas.

→Uma hierarquia de grupos de gerenciamento com iniciativas de Azure Policy atribuídas no nível do grupo de gerenciamento raiz ou pai.

Por quê: Grupos de Gerenciamento fornecem um escopo de governança acima das assinaturas, permitindo que as políticas sejam herdadas. As iniciativas agrupam múltiplas políticas para atribuição simplificada.

Referência↗

Fornecer aos administradores acesso privilegiado just-in-time (JIT) com fluxos de trabalho de aprovação e auditoria.

→Microsoft Entra Privileged Identity Management (PIM) para tornar os usuários elegíveis para funções em vez de permanentemente ativos.

Por quê: PIM impõe o princípio do menor privilégio exigindo que os usuários ativem funções por um período limitado, com MFA opcional, justificativa e aprovação, criando um rastro de auditoria completo.

Referência↗

Coletar logs de todos os recursos do Azure em múltiplas assinaturas para análise e consulta centralizadas.

→Um único workspace centralizado do Log Analytics com RBAC de contexto de recurso para controle de acesso.

Por quê: Um workspace centralizado permite consultas entre assinaturas, simplifica o gerenciamento e evita a duplicação de dados. O RBAC de contexto de recurso garante que os usuários consultem apenas logs de recursos aos quais eles podem acessar.

Um recurso do Azure (ex: App Service, Function, VM) precisa acessar com segurança outros recursos do Azure (Key Vault, SQL, Storage) sem credenciais armazenadas.

→Atribuir uma identidade gerenciada (atribuída pelo sistema ou pelo usuário) ao recurso de computação e conceder-lhe funções RBAC nos recursos de destino.

Por quê: Identidades gerenciadas eliminam o gerenciamento de credenciais (segredos, certificados), lidando automaticamente com a aquisição e rotação de tokens. Use identidades atribuídas pelo usuário para compartilhar uma identidade entre múltiplos recursos.

Referência↗

Remediar automaticamente recursos Azure existentes e não conformes identificados por uma Azure Policy.

→Use um efeito de política "DeployIfNotExists" ou "Modify". Para recursos existentes, uma tarefa de remediação deve ser criada para a atribuição da política, o que requer uma identidade gerenciada com permissões suficientes.

Por quê: As políticas com esses efeitos aplicam-se apenas a recursos novos/atualizados por padrão. Uma tarefa de remediação é necessária para escanear e corrigir recursos existentes não conformes.

Aplicar tags obrigatórias em todos os recursos e herdar tags automaticamente (ex: CostCenter) do grupo de recursos pai.

→Use uma Azure Policy com efeito "Deny" para tags obrigatórias e uma política separada com efeito "Modify" para herdar tags do grupo de recursos se ausentes.

Por quê: Deny impõe a conformidade na criação. O efeito Modify automatiza a propagação de tags, reduzindo o esforço manual e garantindo a consistência.

Monitorar uma aplicação de várias camadas ou microsserviços para rastrear transações de ponta a ponta e identificar gargalos de desempenho.

→Instrumentar todos os serviços com Application Insights. Usar o Mapa da Aplicação para visualizar dependências e rastreamento distribuído para análise de requisições de ponta a ponta.

Por quê: Application Insights é a solução APM nativa que correlaciona automaticamente a telemetria entre componentes para fornecer uma visão unificada de uma transação, identificando problemas de latência.

Governar o acesso para parceiros externos, incluindo solicitações, aprovações, acesso com tempo limitado e revisões periódicas.

→Gerenciamento de entitlements do Microsoft Entra ID Governance. Criar pacotes de acesso que agrupam recursos, definem fluxos de trabalho de aprovação, configuram políticas de expiração e agendam revisões de acesso.

Por quê: Fornece um ciclo de vida completo e automatizado para acesso externo, reduzindo a sobrecarga administrativa e o risco de segurança em comparação com o gerenciamento manual de contas de convidado.

Um provedor de serviços gerenciados ou equipe de TI central precisa gerenciar recursos em múltiplos tenants do Azure AD de clientes/departamentos.

→Azure Lighthouse. Integrar assinaturas de clientes para conceder ao tenant gerenciador acesso delegado com funções RBAC específicas.

Por quê: Lighthouse fornece um único plano de controle para gerenciamento entre tenants sem alternar diretórios ou gerenciar contas de convidado, enquanto o cliente mantém controle total e propriedade.

Fornecer acesso remoto seguro a uma aplicação web on-premises para usuários externos sem uma VPN ou expor a aplicação à internet.

→Microsoft Entra Application Proxy.

Por quê: Application Proxy usa um conector on-premises leve que faz uma conexão de saída para o Azure. Ele atua como um proxy reverso, permitindo a pré-autenticação do Entra ID e acesso seguro sem regras de firewall de entrada ou um IP público na aplicação.

Uma aplicação distribuída globalmente requer um banco de dados com latência de leitura/escrita abaixo de 10ms, esquema flexível e disponibilidade de 99.999%.

→Azure Cosmos DB com escrita multi-região habilitada. A chave de partição deve ser escolhida para distribuir a carga de trabalho uniformemente.

Por quê: Cosmos DB é construído especificamente para distribuição global com escritas multi-região prontas para uso, fornecendo baixa latência garantida e o mais alto SLA de disponibilidade. Outros bancos de dados requerem replicação manual e não conseguem igualar a latência de escrita.

Ingerir telemetria IoT de alto volume no Cosmos DB, permitindo consultas eficientes por dispositivo e arquivamento automático de dados antigos.

→Usar `/deviceId` como a chave de partição. Configurar TTL no contêiner para excluir automaticamente documentos antigos. Usar Change Feed para capturar dados antes da exclusão para arquivamento em armazenamento frio (ex: Blob Storage).

Por quê: Particionar por `deviceId` co-localiza dados para um único dispositivo, tornando as consultas eficientes. TTL fornece exclusão automática e gratuita. Change Feed permite um pipeline de arquivamento reativo.

Selecionar um modelo de precificação do Azure SQL DB com boa relação custo-benefício para uma carga de trabalho com tráfego imprevisível e intermitente, e períodos de inatividade significativos.

→Usar o modelo baseado em vCore com a camada de computação Serverless.

Por quê: Serverless escala automaticamente a computação com base na demanda e pausa automaticamente durante períodos de inatividade, cobrando apenas pela computação usada por segundo. Isso é muito mais econômico para cargas de trabalho intermitentes do que as camadas provisionadas.

Uma solução de armazenamento para uma plataforma de análise de dados em larga escala que requer um namespace hierárquico e ACLs no nível de diretório.

→Azure Data Lake Storage Gen2 (uma conta com namespace hierárquico habilitado).

Por quê: ADLS Gen2 é otimizado para análise de big data, combinando a escalabilidade do armazenamento de objetos com um sistema de arquivos hierárquico verdadeiro e ACLs compatíveis com POSIX para segurança granular.

Escolher redundância de armazenamento com base em requisitos de nível: durabilidade máxima com acesso de leitura, apenas para DR e proteção contra falha de datacenter na região.

→1. Durabilidade máxima/leitura: RA-GZRS. 2. Apenas DR: GRS. 3. Na região: ZRS.

Por quê: Corresponder a opção de redundância aos requisitos específicos de RPO/RTO e acesso. RA-GZRS é o nível mais alto. GRS é apenas para failover. ZRS protege contra falha de datacenter dentro de uma região.

Consultar grandes dados estruturados em um data warehouse e dados semiestruturados em um data lake usando uma plataforma de análise unificada.

→Azure Synapse Analytics. Usar um pool SQL dedicado para dados estruturados e um pool SQL serverless para consultas ad-hoc no data lake.

Por quê: Essa abordagem híbrida otimiza tanto o desempenho quanto o custo. O pool dedicado oferece alto desempenho para o data warehouse gerenciado, enquanto o pool serverless fornece acesso pay-per-query aos dados brutos no lake.

Uma solução de cache para estado de sessão e dados de produto que requer mais de 100 GB de memória e alta disponibilidade.

→Azure Cache for Redis Enterprise ou Premium com clustering habilitado.

Por quê: O clustering nas camadas Premium/Enterprise permite que o cache escale além dos limites de memória de um único nó, fragmentando dados entre múltiplos nós, o que também melhora o throughput.

Uma arquitetura de banco de dados para uma aplicação SaaS que isola tenants enquanto otimiza custos para muitas cargas de trabalho pequenas e intermitentes.

→Azure SQL Elastic Pools. Agrupar tenants em pools para compartilhar recursos, com bancos de dados dedicados para tenants grandes e "vizinhos barulhentos".

Por quê: Elastic Pools fornecem os benefícios de custo do compartilhamento de recursos enquanto impõem limites de desempenho por banco de dados, oferecendo um equilíbrio entre o problema do "vizinho barulhento" e o alto custo de um banco de dados por tenant.

Migrar um banco de dados SQL Server on-premises complexo que usa recursos como SQL Agent, consultas entre bancos de dados e CLR para um serviço PaaS.

→Azure SQL Managed Instance.

Por quê: SQL Managed Instance oferece compatibilidade de quase 100% com o motor do SQL Server on-premises, suportando recursos no nível da instância que o Azure SQL Database não suporta. Isso é ideal para lift-and-shift com mínimas alterações de código.

Garantir que todos os dados e chaves de criptografia gerenciadas pelo cliente permaneçam dentro de um limite geográfico específico (ex: a UE).

→Implantar todos os recursos em regiões dentro do limite. Usar uma Azure Policy com o efeito "Allowed locations" para aplicar isso. Armazenar chaves gerenciadas pelo cliente (CMK) em um Azure Key Vault também localizado dentro do limite.

Por quê: Uma combinação de localização de implantação física, aplicação baseada em política e residência de chaves é necessária para atender a regulamentações estritas de soberania de dados.

Descobrir, classificar e rastrear a linhagem de dados em um ambiente de dados híbrido (Azure, on-prem, outras nuvens).

→Microsoft Purview.

Por quê: Purview fornece uma solução unificada de governança de dados com varredura automatizada, um glossário de negócios, classificação e rastreamento de linhagem em uma ampla gama de fontes de dados.

Armazenar dados (ex: registros financeiros) em um estado não-apagável e não-modificável (WORM) por um período de retenção definido.

→Azure Blob Storage com uma política imutável baseada em tempo no contêiner, que é então bloqueada.

Por quê: Políticas imutáveis bloqueadas impedem a exclusão ou modificação de blobs por qualquer usuário, incluindo administradores, até que o período de retenção expire, atendendo a requisitos rigorosos de conformidade regulatória.

Projetar uma solução de DR para uma aplicação web (App Service + SQL DB) com um RPO de minutos e um RTO abaixo de uma hora.

→Grupo de failover automático do Azure SQL Database, uma implantação secundária do App Service e Azure Front Door ou Traffic Manager para roteamento.

Por quê: Este padrão aborda o DR para cada camada. O grupo de failover SQL lida com a replicação e failover de dados. O App Service pré-implantado evita atrasos na implantação. Um roteador global (Front Door/Traffic Manager) direciona o tráfego para a região ativa.

O SLA composto de uma aplicação serial (A -> B -> C) é muito baixo. Como você o melhora?

→Identificar o componente com o menor SLA individual (o "elo mais fraco") e torná-lo redundante implantando instâncias paralelas (ex: entre regiões ou zonas com um balanceador de carga).

Por quê: O SLA composto para uma cadeia serial é calculado multiplicando os SLAs (SLA_A * SLA_B * SLA_C). Adicionar instâncias paralelas a um componente melhora seu SLA efetivo, o que tem o maior impacto positivo no composto.

Alcançar a maior disponibilidade possível para VMs dentro de uma única região do Azure.

→Implantar múltiplas VMs em todas as Zonas de Disponibilidade disponíveis na região.

Por quê: Zonas de Disponibilidade são datacenters fisicamente separados com energia, refrigeração e rede independentes. Isso protege contra falhas no nível do datacenter e fornece o mais alto SLA na região de 99,99%.

Fornecer uma solução de recuperação de desastres para máquinas virtuais VMware ou Hyper-V on-premises para o Azure.

→Azure Site Recovery (ASR). Configurar replicação para o Azure, criar planos de recuperação para failover orquestrado e usar failovers de teste para simulações de DR não disruptivas.

Por quê: ASR é o serviço Azure construído especificamente para replicação de DR de VMs on-prem (e Azure), fornecendo replicação contínua, recuperação orquestrada e capacidades de teste isolado.

Alcançar a mais alta disponibilidade na região para Azure SQL Database com zero perda de dados (RPO=0) e capacidade de escala de leitura.

→Usar a camada de serviço Business Critical com redundância de zona habilitada.

Por quê: A camada Business Critical usa um Grupo de Disponibilidade Always On com replicação síncrona em múltiplas réplicas, fornecendo um RPO de 0. A redundância de zona posiciona as réplicas em diferentes AZs para um SLA de 99,995%. Inclui uma réplica secundária legível.

Uma aplicação global deve servir usuários da região mais próxima e fazer failover de forma automática e instantânea.

→Usar um padrão de implantação ativo-ativo em múltiplas regiões com Azure Front Door para roteamento baseado em latência e failover baseado em health probe.

Por quê: Azure Front Door fornece roteamento anycast global para o backend de menor latência. Seus health probes detectam falhas regionais e redirecionam automaticamente o tráfego para regiões saudáveis em segundos, permitindo uma arquitetura ativo-ativo contínua.

Fazer backup de aplicações stateful no AKS, incluindo tanto as definições de objeto do Kubernetes quanto os dados de volume persistente.

→Usar Azure Backup para AKS.

Por quê: Azure Backup para AKS é a solução nativa que fornece backup integrado e baseado em política tanto para o estado do cluster (etcd) quanto para os dados de volume persistente (via snapshots CSI) em um Backup Vault seguro e centralizado.

Proteger backups contra exclusão acidental ou maliciosa, inclusive por administradores, para conformidade regulatória.

→Habilitar cofres imutáveis no cofre do Azure Backup ou Recovery Services.

Por quê: Imutabilidade é uma configuração no nível do cofre que garante que os pontos de recuperação de backup, uma vez criados, não podem ser excluídos por ninguém antes de sua data de expiração, fornecendo o mais alto nível de proteção de backup.

Um App Service Environment v3 (ASEv3) hospeda uma aplicação crítica em uma região e requer uma solução de DR em outra região.

→Implantar um segundo ASEv3 na região de DR. Usar Azure Front Door para balanceamento de carga global e failover. Replicar dados usando a tecnologia apropriada (ex: grupos de failover automático SQL).

Por quê: ASEv3s são implantações regionais. Para DR, você deve implantar um segundo ASE e usar um roteador global como Front Door para gerenciar o tráfego. ASR não é usado para DR do App Service.

Projetar uma rede escalável para uma empresa com conectividade centralizada (ExpressRoute/VPN), serviços compartilhados e isolamento de carga de trabalho.

→Uma topologia hub-and-spoke. A VNet hub contém o gateway, Azure Firewall e outros serviços compartilhados. As VNets spoke contêm cargas de trabalho de aplicações e são pareadas com o hub.

Por quê: Este é o padrão empresarial padrão e recomendado. Ele centraliza a segurança e a conectividade, reduzindo custos e complexidade, enquanto os spokes fornecem forte isolamento de carga de trabalho.

Uma aplicação web global precisa de balanceamento de carga Layer 7, um Web Application Firewall (WAF), offloading SSL e roteamento baseado em URL.

→Azure Front Door (Standard ou Premium).

Por quê: Front Door é um CDN de nuvem moderno e balanceador de carga global que integra essas capacidades em um único serviço, proporcionando melhor desempenho e gerenciamento mais simples do que combinar Traffic Manager com Application Gateways regionais.

Projetar um cluster AKS de nível de produção para múltiplas equipes com diferentes tipos de carga de trabalho (CPU, GPU, intensivo em memória).

→Usar um pool de nós de sistema dedicado e múltiplos pools de nós de usuário com diferentes SKUs de VM (ex: série F para CPU, série E para memória, série N para GPU). Usar o autoscaler de cluster e habilitar a camada Standard/Premium para o SLA de tempo de atividade.

Por quê: Múltiplos pools de nós permitem corresponder o hardware certo à carga de trabalho certa para desempenho e eficiência de custo. Separar pods de sistema melhora a estabilidade. A camada Standard/Premium é necessária para um SLA com garantia financeira.

Um fluxo de trabalho serverless orientado a eventos requer tempos de execução maiores que o limite de 10 minutos do plano Consumption do Functions.

→Usar Azure Functions em um plano Premium ou um plano App Service, ou usar Azure Durable Functions para orquestração.

Por quê: O plano Premium suporta execução de até 60 minutos (padrão 30) e evita cold starts. Durable Functions são ideais para orquestrar fluxos de trabalho de longa duração e com estado que podem envolver interação humana ou longas esperas.

Escolher um serviço de mensagens para um sistema de notificação de eventos fan-out versus um sistema de processamento de comandos confiável e ordenado.

→Usar Azure Event Grid para fan-out, eventing reativo. Usar Azure Service Bus Queues (com sessões para ordenação) para processamento de comandos transacional e confiável.

Por quê: Event Grid é um serviço de roteamento de eventos leve e baseado em push otimizado para programação reativa. Service Bus é um broker de mensagens robusto com recursos como FIFO (sessões), dead-lettering e transações para mensageria empresarial.

Expor uma API em execução em uma VNet privada para parceiros externos de forma segura, com políticas para limitação de taxa e autenticação.

→Implantar Azure API Management (APIM) no modo VNet interna, com um Azure Application Gateway com WAF na frente para ingresso público.

Por quê: Este padrão fornece defesa em profundidade. O APIM na VNet pode acessar o backend privado. O App Gateway encerra SSL, inspeciona o tráfego com WAF e o encaminha para a instância APIM privada. As políticas do APIM lidam com autenticação, limites de taxa, etc.

Conectar centenas de filiais e VNets globalmente com conectividade automatizada, any-to-any.

→Azure Virtual WAN.

Por quê: Virtual WAN é a solução gerenciada da Microsoft para redes de trânsito globais em larga escala. Ele automatiza roteamento complexo e fornece um hub unificado para conectar VPN, ExpressRoute e spokes de VNet.

Executar um job de lote paralelo em larga escala (ex: simulação CFD) que requer milhares de núcleos e comunicação MPI de baixa latência.

→Azure Batch com um pool de VMs habilitadas para InfiniBand (ex: série HB) usando precificação de baixa prioridade (Spot).

Por quê: Azure Batch é um agendador de jobs projetado para HPC. VMs habilitadas para InfiniBand fornecem a rede RDMA de alta taxa de transferência e baixa latência necessária para MPI. VMs de baixa prioridade reduzem drasticamente o custo para cargas de trabalho tolerantes a falhas.

Uma aplicação em uma VNet precisa acessar serviços PaaS (SQL, Storage) sem que o tráfego atravesse a internet pública.

→Criar private endpoints para os serviços PaaS. Isso atribui ao serviço um endereço IP privado dentro da sua VNet.

Por quê: Private Endpoints são o método mais seguro para conectividade PaaS privada. Eles garantem que o tráfego permaneça na backbone da Microsoft e permite desabilitar completamente o endpoint público do serviço PaaS.

Hospedar uma aplicação de página única (SPA) moderna com um backend API serverless, integração CI/CD e um domínio personalizado.

→Azure Static Web Apps.

Por quê: Este é um serviço simplificado e construído especificamente para este padrão. Ele combina hospedagem de conteúdo estático, Azure Functions integrado para a API, integração GitHub/Azure DevOps e domínios personalizados gerenciados com certificados SSL gratuitos.

Gerenciar e aplicar governança (Azure Policy) a servidores rodando on-premises e em outras nuvens (ex: AWS) a partir do Azure.

→Instalar o agente do Azure Arc nos servidores não-Azure para projetá-los como servidores habilitados para Azure Arc.

Por quê: Azure Arc estende o plano de controle do Azure para qualquer infraestrutura. Uma vez que um servidor é habilitado para Arc, ele pode ser gerenciado com Azure Policy, Monitor, Defender for Cloud, etc., assim como uma VM nativa do Azure.

Migrar incrementalmente a funcionalidade de uma aplicação monolítica legada para novos microsserviços sem um corte "big bang".

→Aplicar o padrão Strangler Fig usando um proxy reverso como Azure API Management ou Application Gateway.

Por quê: O proxy reverso intercepta chamadas para o monólito e roteia seletivamente o tráfego para recursos específicos para os novos microsserviços. Com o tempo, o proxy "estrangulará" o monólito redirecionando cada vez mais tráfego até que o sistema antigo possa ser desativado.

VMs estão em uma VNet com forced tunneling (todo o tráfego da internet roteado on-prem), mas não conseguem acessar serviços Azure PaaS.

→O forced tunneling impede o acesso direto a endpoints públicos do Azure. Use service endpoints ou private endpoints para acesso PaaS. Alternativamente, adicione UDRs para tags de serviço Azure específicas com um next hop "Internet" para contornar o túnel.

Por quê: Os serviços PaaS possuem endpoints públicos. O forced tunneling envia esse tráfego para on-prem. Você deve criar um caminho de exceção, seja tornando o serviço PaaS privado (endpoints) ou criando exceções de rota específicas (UDRs com tags de serviço).

Uma rede hub-spoke precisa resolver nomes DNS on-premises a partir do Azure, e zonas DNS privadas do Azure a partir de on-premises.

→Implantar Azure DNS Private Resolver na VNet hub. Configurar um endpoint de entrada para on-prem resolver DNS do Azure, e um endpoint de saída com conjuntos de regras de encaminhamento para resolver DNS on-prem a partir do Azure.

Por quê: Esta é a solução PaaS moderna para resolução DNS híbrida, substituindo a necessidade de gerenciar VMs de servidor DNS personalizadas. Ela se integra nativamente com zonas DNS privadas e forwarders DNS on-premises.

Múltiplas VNets precisam de um IP público previsível e estático para todo o tráfego de saída para whitelisting por serviços externos.

→Em uma topologia hub-spoke, rotear todo o tráfego de saída (0.0.0.0/0) dos spokes através de um Azure Firewall ou NAT Gateway na VNet hub.

Por quê: Centralizar a saída no hub garante que todo o tráfego de saída use os IPs públicos do firewall/NAT Gateway do hub, simplificando o gerenciamento e o whitelisting externo. NAT Gateway é mais simples para SNAT puro, enquanto Firewall adiciona inspeção de segurança.

Processar dados altamente sensíveis de forma que estejam criptografados mesmo em uso na memória, protegendo-os do operador da nuvem.

→Usar VMs de Computação Confidencial do Azure (série DCsv3/ECsv3) com Intel SGX ou AMD SEV-SNP para executar código em um Ambiente de Execução Confiável (TEE) baseado em hardware ou memória criptografada.

Por quê: A Computação Confidencial aborda o pilar de segurança "dados em uso", o que as criptografias tradicionais em repouso e em trânsito não fazem. Ela fornece isolamento verificável em nível de hardware.

Um provedor SaaS precisa expor seu serviço, rodando em sua VNet, a um cliente na VNet do cliente, inteiramente sobre a rede privada do Azure.

→O provedor cria um Azure Private Link Service em seu Standard Load Balancer. O cliente cria um Private Endpoint em sua VNet que se conecta ao serviço.

Por quê: Private Link é o padrão definitivo para exposição de serviços segura, privada e entre tenants. Ele evita exposição à internet pública, problemas de sobreposição de IP e configurações complexas de peering de VNet.