Guia

Mudar os gastos de TI de grandes compras iniciais de hardware para um modelo de pagamento conforme o uso.

→Aproveitar o modelo de consumo baseado em nuvem.

Por quê: Isso converte Despesas de Capital (CapEx) em Despesas Operacionais (OpEx) previsíveis, eliminando a necessidade de aquisição e gerenciamento de data centers.

Entender a divisão das responsabilidades de segurança e gerenciamento entre o provedor de nuvem e o cliente.

→O provedor é responsável pela segurança *da* nuvem; o cliente é responsável pela segurança *na* nuvem. O cliente sempre possui seus dados, identidades e endpoints.

Por quê: Em IaaS, o cliente gerencia o OS e acima. Em PaaS, o provedor gerencia o OS, e o cliente gerencia a aplicação e os dados. Em SaaS, o provedor gerencia tudo, exceto dados e configuração de acesso.

Referência↗

Escolher um modelo de implantação com base nos requisitos de controle, posse e localização.

→Usar Público (infraestrutura compartilhada), Privado (infraestrutura dedicada, on-prem ou hospedada) ou Híbrido (combinação de Público e Privado).

Por quê: Híbrido é fundamental para reter sistemas on-prem para regulamentação/latência, enquanto utiliza a nuvem pública para escalabilidade e serviços modernos. Privado oferece controle máximo.

Selecionar o modelo de serviço de nuvem correto com base no nível de controle de gerenciamento desejado.

→IaaS (por exemplo, Azure VMs) para controle máximo sobre o OS. PaaS (por exemplo, Azure App Service, Azure SQL) para focar no código, não na infraestrutura. SaaS (por exemplo, Microsoft 365) para software pronto para uso.

Por quê: A compensação é controle versus conveniência. À medida que você avança de IaaS para SaaS, o provedor gerencia mais da pilha, reduzindo a carga operacional do cliente.

Lidar com picos de tráfego dinâmicos e imprevisíveis versus crescimento planejado e sustentado.

→Usar Elasticidade para escalonamento automático (para dentro/para fora) para corresponder à demanda em tempo real. Usar Escalabilidade para aumento de capacidade planejado (para fora/para cima) para lidar com o crescimento projetado.

Por quê: A Elasticidade é automatizada e reativa, ideal para cargas de trabalho com picos para otimizar custos. Escalabilidade é um conceito mais amplo de adição de capacidade, que pode ser manual ou automatizada.

Proteger contra falha de componente dentro de uma região versus uma interrupção regional catastrófica.

→Implementar Alta Disponibilidade (HA) usando Zonas de Disponibilidade para sobreviver a falhas de data center. Implementar Recuperação de Desastres (DR) usando replicação entre regiões (por exemplo, GRS) para sobreviver a um desastre regional.

Por quê: HA trata de manter o serviço com interrupção mínima. DR trata de recuperar o serviço após uma grande interrupção. HA é tipicamente automatizada com failover rápido; DR frequentemente envolve um processo formal de recuperação.

Implantar recursos para uma entidade governamental que exige conformidade específica e residência de dados.

→Usar uma nuvem soberana como o Azure Government.

Por quê: Estas são instâncias fisicamente isoladas do Azure, gerenciadas por pessoal verificado e projetadas para atender a rigorosos padrões de conformidade governamental (por exemplo, FedRAMP, DoD).

Projetar uma aplicação resiliente que possa suportar uma falha de data center.

→Implantar recursos em várias Zonas de Disponibilidade dentro de uma única Região do Azure.

Por quê: Zonas de Disponibilidade são data centers fisicamente separados com energia, refrigeração e rede independentes. Isso oferece alta disponibilidade dentro de uma região sem a latência de implantações entre regiões.

Referência↗

Agrupar recursos relacionados do Azure para gerenciamento unificado, controle de acesso e faturamento.

→Colocar todos os recursos de uma aplicação em um único Grupo de Recursos do Azure.

Por quê: Grupos de recursos são contêineres para metadados. A exclusão de um grupo de recursos exclui todos os recursos dentro dele, tornando-o um limite crítico de gerenciamento do ciclo de vida.

Selecionar o serviço de computação apropriado para uma carga de trabalho.

→VMs (IaaS) para controle total. App Service (PaaS) para aplicativos web/APIs. Azure Functions para código serverless baseado em eventos. AKS para orquestração de contêineres. ACI para instâncias de contêiner simples.

Por quê: A escolha depende da compensação entre controle, sobrecarga de gerenciamento e padrão arquitetural (por exemplo, monolítico, microsserviços, baseado em eventos).

Executar uma aplicação de microsserviços complexa e conteinerizada que requer autoescalonamento, descoberta de serviço e atualizações contínuas.

→Usar Azure Kubernetes Service (AKS).

Por quê: AKS é a oferta gerenciada de Kubernetes para orquestração de contêineres em grande escala. Use-o em vez de ACI quando precisar de gerenciamento de cluster e interações de serviço complexas.

Executar um único e simples contêiner para uma tarefa de curta duração (por exemplo, um job em lote) sem gerenciamento de infraestrutura.

→Usar Azure Container Instances (ACI).

Por quê: ACI é a maneira mais rápida e simples de executar um contêiner no Azure. É serverless e faturado por segundo, ideal para tarefas sem necessidades de orquestração.

Estabelecer uma conexão dedicada, privada e de alta largura de banda de um data center on-premises para o Azure.

→Usar Azure ExpressRoute.

Por quê: O ExpressRoute NÃO atravessa a internet pública, oferecendo maior confiabilidade, segurança e menor latência do que um VPN Gateway, que tunela pela internet.

Referência↗

Distribuir tráfego para VMs de backend com base em regras de nível de rede versus nível de aplicação.

→Usar Azure Load Balancer para distribuição de Camada 4 (TCP/UDP). Usar Azure Application Gateway para recursos de Camada 7 (HTTP/HTTPS) como descarregamento de SSL e roteamento baseado em URL.

Por quê: Escolha Application Gateway quando precisar tomar decisões de roteamento com base em cabeçalhos HTTP, caminhos ou nomes de host. Load Balancer é mais simples e rápido para tráfego não-HTTP.

Roteamento de tráfego web global para o backend ideal, fornecimento de cache CDN e proteção com um WAF.

→Usar Azure Front Door.

Por quê: Front Door é um ponto de entrada global que opera na Camada 7 e combina balanceamento de carga global, CDN, WAF e proteção contra DDoS em um único serviço.

Armazenar grandes quantidades de dados não estruturados como imagens, vídeos, backups e arquivos de log.

→Usar Azure Blob Storage.

Por quê: O armazenamento de Blob é altamente escalável e econômico para dados de objetos. Ele é distinto do Azure Files (para compartilhamentos de arquivos SMB) e do Azure Disk Storage (para discos de VM).

Minimizar os custos de armazenamento de dados com base na sua frequência de acesso.

→Usar as camadas de acesso do Blob Storage: Hot (acesso frequente), Cool/Cold (acesso infrequente) e Archive (acesso raro, retenção de longo prazo).

Por quê: A camada Archive tem o menor custo de armazenamento, mas o maior custo de acesso e latência (horas para reidratar). Usar políticas de gerenciamento de ciclo de vida para automatizar a categorização.

Escolher uma estratégia de replicação de dados para proteger contra falha de hardware, data center ou regional.

→LRS (único data center), ZRS (entre Zonas de Disponibilidade em uma região), GRS (para uma região secundária), GZRS (ZRS na primária + LRS na secundária).

Por quê: ZRS protege contra falha de data center. GRS/GZRS protege contra desastre regional. A compensação é maior custo por maior resiliência.

Permitir que uma VM em uma VNet acesse um serviço PaaS (como Azure SQL ou Storage) sem que o tráfego saia da rede Microsoft.

→Criar um Private Endpoint para o serviço PaaS dentro da VNet da VM.

Por quê: Um Private Endpoint fornece ao serviço PaaS um endereço IP privado da sua VNet, garantindo que todo o tráfego flua pela rede privada da Microsoft, e não pela internet pública.

Migrar um servidor de arquivos Windows on-premises para um serviço de nuvem gerenciado acessível via protocolo SMB.

→Usar Azure Files.

Por quê: Azure Files oferece compartilhamentos de arquivos totalmente gerenciados que podem ser montados por VMs na nuvem ou on-premises, atuando como um substituto direto para servidores de arquivos tradicionais.

Aplicar governança (políticas, RBAC) e gerenciar acesso em diversas assinaturas do Azure.

→Organizar assinaturas em uma hierarquia de Management Groups.

Por quê: Management groups são um escopo acima das assinaturas. Políticas e atribuições de função aplicadas no nível de um management group são herdadas por todas as assinaturas dentro dele.

Referência↗

Impor padrões organizacionais, como restringir implantações a regiões específicas ou exigir tags em todos os recursos.

→Usar Azure Policy.

Por quê: A Policy impõe regras sobre as configurações de recursos. Isso é para governança, enquanto o RBAC controla as permissões de usuário (ações).

Distinguir entre controlar ações de usuário e controlar propriedades de recursos.

→Usar Role-Based Access Control (RBAC) para definir quais ações um usuário pode realizar (por exemplo, "Colaborador" pode criar VMs). Usar Azure Policy para definir quais configurações são permitidas (por exemplo, "VMs só podem ser do tamanho D-series").

Por quê: RBAC é sobre "quem pode fazer o quê". Policy é sobre "o que é permitido". Eles trabalham juntos para uma governança abrangente.

Proteger um recurso de produção crítico contra exclusão acidental, mesmo por administradores.

→Aplicar um Bloqueio de Recurso `CanNotDelete` ao recurso ou ao seu grupo de recursos.

Por quê: Bloqueios de recursos substituem as permissões RBAC. Um Proprietário não pode excluir um recurso bloqueado até que o bloqueio seja explicitamente removido. Um bloqueio `ReadOnly` impede qualquer modificação.

Organizar logicamente os recursos para rastreamento de custos, automação ou identificação de propriedade.

→Aplicar Tags (pares chave-valor) aos recursos.

Por quê: Tags são metadados usados para filtrar e agrupar recursos em grupos de recursos, permitindo uma poderosa análise de custos e gerenciamento.

Uma tag aplicada a um grupo de recursos não está aparecendo nos recursos dentro dele.

→Tags não são automaticamente herdadas de grupos de recursos. Cada recurso deve ser explicitamente marcado.

Por quê: Para impor a herança de tags, usar uma Azure Policy com um efeito "Modify" ou "DeployIfNotExists" para anexar tags do grupo de recursos pai.

Estimar custos futuros do Azure versus calcular economias de uma migração on-premises.

→Usar a Calculadora de Preços para estimar o custo de serviços específicos do Azure. Usar a Calculadora de Custo Total de Propriedade (TCO) para comparar os custos on-prem com os custos do Azure.

Por quê: A Calculadora de Preços é para implantações greenfield ou adição de novos serviços. A Calculadora de TCO é para construir um caso de negócios para migração.

Monitorar os gastos atuais do Azure, configurar alertas de gastos e encontrar oportunidades de economia.

→Usar Azure Cost Management. Criar Orçamentos para acionar alertas quando os limites de gastos forem atingidos.

Por quê: Os Orçamentos fornecem notificação proativa dos gastos, ajudando a prevenir estouros de custo. A análise do Cost Management ajuda a identificar anomalias e tendências de gastos.

Reduzir custos para cargas de trabalho previsíveis e continuamente em execução, como VMs ou bancos de dados.

→Adquirir Azure Reserved Instances ou Planos de Economia por um período de 1 ou 3 anos.

Por quê: As Reservas oferecem descontos significativos (até 72%) sobre o preço pago conforme o uso em troca de um compromisso de longo prazo. Ideal para cargas de trabalho de estado estacionário.

Implantar a infraestrutura do Azure de forma repetível, consistente e sob controle de versão.

→Usar Infrastructure as Code (IaC) declarativa com ARM Templates (JSON) ou Bicep.

Por quê: Bicep é uma linguagem específica de domínio (DSL) mais simples e concisa que transpila para ARM JSON, proporcionando uma melhor experiência de autoria e legibilidade.

Gerenciar e governar servidores executados on-premises ou em outras nuvens usando ferramentas do Azure.

→Integrar os servidores não-Azure ao Azure Arc.

Por quê: O Azure Arc projeta recursos externos no Azure Resource Manager, permitindo que você use Azure Policy, RBAC e monitoramento para ativos híbridos e multi-cloud a partir de um único plano de controle.

Referência↗

Fornecer uma solução única de gerenciamento de identidade e acesso baseada em nuvem para todas as aplicações.

→Usar Microsoft Entra ID (anteriormente Azure AD).

Por quê: Entra ID é o plano de controle de identidade, fornecendo Single Sign-On (SSO), Multi-Factor Authentication (MFA) e Acesso Condicional para aplicações na nuvem e on-prem.

Exigir MFA para usuários que fazem login de uma rede não confiável, mas não do escritório corporativo.

→Configurar uma política de Acesso Condicional do Microsoft Entra.

Por quê: O Acesso Condicional atua como um motor de política "se-então". Se uma condição de usuário/localização/dispositivo for atendida, então um controle de acesso (como exigir MFA) é imposto.

Permitir que um recurso do Azure (como uma VM ou App Service) se autentique em outro serviço do Azure (como Key Vault) sem armazenar segredos no código.

→Atribuir uma Managed Identity ao recurso e conceder a ele permissões RBAC no serviço de destino.

Por quê: O Azure gerencia o ciclo de vida da credencial automaticamente, eliminando o risco de vazamento de segredos de arquivos de configuração ou código.

Armazenar e gerenciar com segurança segredos, chaves e certificados de aplicações.

→Usar Azure Key Vault.

Por quê: Key Vault fornece um repositório centralizado, seguro por hardware e auditado para segredos, impedindo que sejam codificados diretamente nas aplicações.

Avaliar continuamente a postura de segurança de cargas de trabalho na nuvem, obter uma Pontuação de Segurança e receber proteção contra ameaças.

→Usar Microsoft Defender for Cloud.

Por quê: O Defender for Cloud fornece Cloud Security Posture Management (CSPM) e Cloud Workload Protection (CWP) em ambientes Azure, híbridos e multi-cloud.

Filtrar o tráfego de rede no nível da sub-rede/NIC versus centralmente para toda a VNet.

→Usar Network Security Groups (NSGs) para filtragem básica de pacotes stateful de Camada 3/4. Usar Azure Firewall para um firewall-as-a-service centralizado e totalmente stateful com filtragem de Camada 7 e inteligência de ameaças.

Por quê: NSGs são simples e distribuídos. Azure Firewall oferece recursos avançados e gerenciamento centralizado de políticas, frequentemente usado em uma topologia hub-spoke.

Reduzir a superfície de ataque de VMs mantendo as portas de gerenciamento (RDP/SSH) fechadas por padrão.

→Habilitar o acesso Just-In-Time (JIT) a VMs no Microsoft Defender for Cloud.

Por quê: JIT concede acesso temporário às portas de gerenciamento sob demanda por um tempo limitado, fechando-as automaticamente depois. Isso é mais seguro do que deixar as portas permanentemente abertas.

Monitorar a saúde da infraestrutura do Azure versus o desempenho do código da aplicação.

→Usar Azure Monitor para métricas e logs de plataforma. Usar Application Insights (um recurso do Azure Monitor) para Application Performance Management (APM).

Por quê: Azure Monitor coleta dados de infraestrutura (CPU, memória). Application Insights fornece diagnósticos aprofundados no nível do código (tempos de resposta, dependências, exceções).

Receber alertas personalizados sobre interrupções de serviço do Azure, manutenção planejada e avisos de saúde.

→Usar Azure Service Health.

Por quê: Service Health é personalizado para suas assinaturas, regiões e serviços, ao contrário da página pública de Status do Azure. É para problemas da plataforma Azure, não para a saúde dos seus próprios recursos.

Receber recomendações personalizadas e acionáveis para otimizar os recursos do Azure.

→Revisar as recomendações do Azure Advisor.

Por quê: O Advisor analisa sua configuração e telemetria de uso e fornece recomendações em cinco pilares: Confiabilidade, Segurança, Desempenho, Custo e Excelência Operacional.

Estabelecer uma base padronizada, governada e escalável para todas as cargas de trabalho do Azure em uma empresa.

→Implementar uma arquitetura de Azure Landing Zone.

Por quê: Landing Zones fornecem uma estrutura prescritiva do Cloud Adoption Framework, incluindo estrutura de grupos de gerenciamento, rede, identidade e políticas de governança, para acelerar a adoção da nuvem com segurança.