Guía

Cambiar el gasto de TI de grandes compras iniciales de hardware a un modelo de pago por uso.

→Aprovechar el modelo basado en el consumo de la nube.

Por qué: Esto convierte el Gasto de Capital (CapEx) en Gasto Operacional (OpEx) predecible, eliminando la necesidad de adquisición y gestión de centros de datos.

Comprender la división de las responsabilidades de seguridad y gestión entre el proveedor de la nube y el cliente.

→El proveedor es responsable de la seguridad *de* la nube; el cliente es responsable de la seguridad *en* la nube. El cliente siempre es dueño de sus datos, identidades y puntos finales.

Por qué: En IaaS, el cliente gestiona el SO y lo que está por encima. En PaaS, el proveedor gestiona el SO, y el cliente gestiona la aplicación y los datos. En SaaS, el proveedor gestiona todo excepto los datos y la configuración de acceso.

Referencia↗

Elegir un modelo de despliegue basado en los requisitos de control, tenencia y ubicación.

→Utilizar Nube Pública (infraestructura compartida), Privada (infraestructura dedicada, local o alojada) o Híbrida (mezcla de Pública y Privada).

Por qué: La nube Híbrida es clave para retener sistemas locales por regulación/latencia mientras se utiliza la nube pública para escalabilidad y servicios modernos. La Privada ofrece control máximo.

Seleccionar el modelo de servicio en la nube adecuado según el nivel de control de gestión deseado.

→IaaS (p. ej., Azure VMs) para máximo control sobre el SO. PaaS (p. ej., Azure App Service, Azure SQL) para enfocarse en el código, no en la infraestructura. SaaS (p. ej., Microsoft 365) para software listo para usar.

Por qué: La compensación es control versus conveniencia. A medida que se avanza de IaaS a SaaS, el proveedor gestiona más de la pila, reduciendo la carga operativa del cliente.

Manejar picos de tráfico dinámicos e impredecibles versus un crecimiento planificado y sostenido.

→Usar Elasticidad para el escalado automático (entrada/salida) para igualar la demanda en tiempo real. Usar Escalabilidad para el aumento de capacidad planificado (horizontal/vertical) para manejar el crecimiento proyectado.

Por qué: La Elasticidad es automatizada y reactiva, ideal para cargas de trabajo con picos para optimizar costos. La Escalabilidad es un concepto más amplio de añadir capacidad, que puede ser manual o automatizado.

Proteger contra fallas de componentes dentro de una región versus una interrupción regional catastrófica.

→Implementar Alta Disponibilidad (HA) usando Zonas de Disponibilidad para sobrevivir a fallas de centros de datos. Implementar Recuperación ante Desastres (DR) usando replicación entre regiones (p. ej., GRS) para sobrevivir a un desastre regional.

Por qué: HA se trata de mantener el servicio con mínima interrupción. DR se trata de recuperar el servicio después de una interrupción importante. HA es típicamente automatizada con conmutación por error rápida; DR a menudo implica un proceso de recuperación formal.

Desplegar recursos para una entidad gubernamental que requiere cumplimiento específico y residencia de datos.

→Utilizar una nube soberana como Azure Government.

Por qué: Son instancias de Azure físicamente aisladas, gestionadas por personal filtrado y diseñadas para cumplir estrictas normas de cumplimiento gubernamental (p. ej., FedRAMP, DoD).

Diseñar una aplicación resiliente que pueda soportar una falla de centro de datos.

→Desplegar recursos en múltiples Zonas de Disponibilidad dentro de una única Región de Azure.

Por qué: Las Zonas de Disponibilidad son centros de datos físicamente separados con energía, refrigeración y redes independientes. Esto proporciona alta disponibilidad dentro de una región sin la latencia de despliegues entre regiones.

Referencia↗

Agrupar recursos de Azure relacionados para una gestión unificada, control de acceso y facturación.

→Colocar todos los recursos de una aplicación en un único Grupo de Recursos de Azure.

Por qué: Los grupos de recursos son contenedores de metadatos. Eliminar un grupo de recursos elimina todos los recursos dentro de él, convirtiéndolo en un límite crítico para la gestión del ciclo de vida.

Seleccionar el servicio de cómputo apropiado para una carga de trabajo.

→VMs (IaaS) para control total. App Service (PaaS) para aplicaciones web/APIs. Azure Functions para código serverless basado en eventos. AKS para orquestación de contenedores. ACI para instancias de contenedor simples.

Por qué: La elección depende de la compensación entre control, sobrecarga de gestión y patrón arquitectónico (p. ej., monolito, microservicios, basado en eventos).

Ejecutar una aplicación compleja de microservicios en contenedores que requiera autoescalado, descubrimiento de servicios y actualizaciones continuas.

→Usar Azure Kubernetes Service (AKS).

Por qué: AKS es la oferta gestionada de Kubernetes para la orquestación de contenedores a gran escala. Usar esto en lugar de ACI cuando se necesita gestión de clústeres e interacciones de servicios complejas.

Ejecutar un único contenedor simple para una tarea de corta duración (p. ej., un trabajo por lotes) sin gestión de infraestructura.

→Usar Azure Container Instances (ACI).

Por qué: ACI es la forma más rápida y sencilla de ejecutar un contenedor en Azure. Es serverless y se factura por segundo, ideal para tareas sin necesidad de orquestación.

Establecer una conexión dedicada, privada y de alto ancho de banda desde un centro de datos local a Azure.

→Usar Azure ExpressRoute.

Por qué: ExpressRoute NO atraviesa la internet pública, ofreciendo mayor fiabilidad, seguridad y menor latencia que una VPN Gateway, que se tuneliza a través de internet.

Referencia↗

Distribuir el tráfico a VMs de backend basándose en reglas de nivel de red versus nivel de aplicación.

→Usar Azure Load Balancer para distribución de Capa 4 (TCP/UDP). Usar Azure Application Gateway para características de Capa 7 (HTTP/HTTPS) como descarga SSL y enrutamiento basado en URL.

Por qué: Elegir Application Gateway cuando necesite tomar decisiones de enrutamiento basadas en encabezados HTTP, rutas o nombres de host. Load Balancer es más simple y rápido para tráfico no HTTP.

Enrutar el tráfico web global al backend óptimo, proporcionar caché CDN y proteger con un WAF.

→Usar Azure Front Door.

Por qué: Front Door es un punto de entrada global que opera en la Capa 7 y combina balanceo de carga global, CDN, WAF y protección DDoS en un solo servicio.

Almacenar grandes cantidades de datos no estructurados como imágenes, videos, copias de seguridad y archivos de registro.

→Usar Azure Blob Storage.

Por qué: Blob storage es altamente escalable y rentable para datos de objetos. Es distinto de Azure Files (para recursos compartidos de archivos SMB) y Azure Disk Storage (para discos de VM).

Minimizar los costos de almacenamiento de datos según su frecuencia de acceso.

→Usar las capas de acceso de Blob Storage: Hot (acceso frecuente), Cool/Cold (acceso infrecuente) y Archive (acceso raro, retención a largo plazo).

Por qué: La capa Archive tiene el costo de almacenamiento más bajo pero el costo de acceso y la latencia más altos (horas para rehidratar). Usar políticas de gestión del ciclo de vida para automatizar la jerarquización.

Elegir una estrategia de replicación de datos para proteger contra fallas de hardware, centro de datos o regionales.

→LRS (centro de datos único), ZRS (en AZs en una región), GRS (a una región secundaria), GZRS (ZRS en primaria + LRS en secundaria).

Por qué: ZRS protege de una falla de centro de datos. GRS/GZRS protege de un desastre regional. La compensación es un costo más alto para una mayor resiliencia.

Permitir que una VM en una VNet acceda a un servicio PaaS (como Azure SQL o Storage) sin que el tráfico salga de la red de Microsoft.

→Crear un Private Endpoint para el servicio PaaS dentro de la VNet de la VM.

Por qué: Un Private Endpoint asigna al servicio PaaS una dirección IP privada de su VNet, asegurando que todo el tráfico fluya sobre la red troncal privada de Microsoft, no sobre la internet pública.

Migrar un servidor de archivos de Windows local a un servicio en la nube gestionado accesible a través del protocolo SMB.

→Usar Azure Files.

Por qué: Azure Files proporciona recursos compartidos de archivos totalmente gestionados que pueden ser montados por VMs en la nube o locales, actuando como un reemplazo directo de los servidores de archivos tradicionales.

Aplicar gobernanza (políticas, RBAC) y gestionar el acceso en numerosas suscripciones de Azure.

→Organizar las suscripciones en una jerarquía de Grupos de Gestión.

Por qué: Los grupos de gestión son un ámbito superior a las suscripciones. Las políticas y asignaciones de roles aplicadas a nivel de grupo de gestión son heredadas por todas las suscripciones dentro de él.

Referencia↗

Aplicar estándares organizacionales, como restringir despliegues a regiones específicas o requerir etiquetas en todos los recursos.

→Usar Azure Policy.

Por qué: La Política aplica reglas sobre las configuraciones de los recursos. Esto es para gobernanza, mientras que RBAC controla los permisos de usuario (acciones).

Distinguir entre controlar las acciones del usuario y controlar las propiedades de los recursos.

→Usar Control de Acceso Basado en Roles (RBAC) para definir qué acciones puede realizar un usuario (p. ej., "Colaborador" puede crear VMs). Usar Azure Policy para definir qué configuraciones están permitidas (p. ej., "Las VMs solo pueden ser de tamaño serie D").

Por qué: RBAC se trata de "quién puede hacer qué". La Política se trata de "qué está permitido". Trabajan juntos para una gobernanza integral.

Proteger un recurso de producción crítico de la eliminación accidental, incluso por parte de los administradores.

→Aplicar un Bloqueo de Recurso `CanNotDelete` al recurso o a su grupo de recursos.

Por qué: Los bloqueos de recursos anulan los permisos RBAC. Un Propietario no puede eliminar un recurso bloqueado hasta que el bloqueo se elimine explícitamente. Un bloqueo `ReadOnly` impide cualquier modificación.

Organizar lógicamente los recursos para el seguimiento de costos, la automatización o la identificación de la propiedad.

→Aplicar Etiquetas (pares clave-valor) a los recursos.

Por qué: Las Etiquetas son metadatos utilizados para filtrar y agrupar recursos a través de grupos de recursos, permitiendo un potente análisis y gestión de costos.

Una etiqueta aplicada a un grupo de recursos no aparece en los recursos dentro de él.

→Las etiquetas no se heredan automáticamente de los grupos de recursos. Cada recurso debe ser etiquetado explícitamente.

Por qué: Para aplicar la herencia de etiquetas, use una Azure Policy con un efecto "Modify" o "DeployIfNotExists" para adjuntar etiquetas del grupo de recursos padre.

Estimar costos futuros de Azure versus calcular ahorros de una migración local.

→Usar la Calculadora de Precios para estimar el costo de servicios específicos de Azure. Usar la Calculadora de Costo Total de Propiedad (TCO) para comparar costos locales versus costos de Azure.

Por qué: La Calculadora de Precios es para despliegues nuevos o para añadir nuevos servicios. La Calculadora de TCO es para construir un caso de negocio para la migración.

Rastrear el gasto actual de Azure, establecer alertas de gasto y encontrar oportunidades de ahorro.

→Usar Azure Cost Management. Crear Presupuestos para activar alertas cuando se alcanzan los umbrales de gasto.

Por qué: Los Presupuestos proporcionan notificación proactiva del gasto, ayudando a prevenir excesos de costos. El análisis de Cost Management ayuda a identificar anomalías y tendencias de gasto.

Reducir costos para cargas de trabajo predecibles y en ejecución continua como VMs o bases de datos.

→Comprar Instancias Reservadas de Azure o Planes de Ahorro por un plazo de 1 o 3 años.

Por qué: Las Reservas ofrecen descuentos significativos (hasta un 72%) sobre los precios de pago por uso a cambio de un compromiso a largo plazo. Ideal para cargas de trabajo de estado estable.

Desplegar infraestructura de Azure de forma repetible, consistente y bajo control de versiones.

→Usar Infraestructura como Código (IaC) declarativa con Plantillas ARM (JSON) o Bicep.

Por qué: Bicep es un lenguaje específico de dominio (DSL) más simple y conciso que se transpila a ARM JSON, proporcionando una mejor experiencia de autoría y legibilidad.

Gestionar y gobernar servidores que se ejecutan on-premises o en otras nubes utilizando herramientas de Azure.

→Integrar los servidores no-Azure en Azure Arc.

Por qué: Azure Arc proyecta recursos externos en Azure Resource Manager, permitiéndole usar Azure Policy, RBAC y monitoreo para activos híbridos y multinube desde un único plano de control.

Referencia↗

Proporcionar una solución única de gestión de identidad y acceso basada en la nube para todas las aplicaciones.

→Usar Microsoft Entra ID (anteriormente Azure AD).

Por qué: Entra ID es el plano de control de identidad, proporcionando Inicio de Sesión Único (SSO), Autenticación Multifactor (MFA) y Acceso Condicional para aplicaciones en la nube y on-prem.

Requerir MFA para usuarios que inician sesión desde una red no confiable pero no desde la oficina corporativa.

→Configurar una política de Acceso Condicional de Microsoft Entra.

Por qué: El Acceso Condicional actúa como un motor de políticas "si-entonces". Si se cumple una condición de usuario/ubicación/dispositivo, entonces se aplica un control de acceso (como requerir MFA).

Permitir que un recurso de Azure (como una VM o App Service) se autentique a otro servicio de Azure (como Key Vault) sin almacenar secretos en el código.

→Asignar una Identidad Administrada al recurso y otorgarle permisos RBAC en el servicio de destino.

Por qué: Azure gestiona el ciclo de vida de las credenciales automáticamente, eliminando el riesgo de fugas de secretos de archivos de configuración o código.

Almacenar y gestionar de forma segura secretos, claves y certificados de aplicaciones.

→Usar Azure Key Vault.

Por qué: Key Vault proporciona un repositorio centralizado, protegido por hardware y auditado para secretos, evitando que se codifiquen directamente en las aplicaciones.

Evaluar continuamente la postura de seguridad de las cargas de trabajo en la nube, obtener una Puntuación Segura y recibir protección contra amenazas.

→Usar Microsoft Defender for Cloud.

Por qué: Defender for Cloud proporciona Gestión de Postura de Seguridad en la Nube (CSPM) y Protección de Cargas de Trabajo en la Nube (CWP) en entornos Azure, híbridos y multinube.

Filtrar el tráfico de red a nivel de subred/NIC versus centralmente para toda la VNet.

→Usar Grupos de Seguridad de Red (NSG) para filtrado básico de paquetes con estado de Capa 3/4. Usar Azure Firewall para un firewall como servicio centralizado, totalmente con estado, con filtrado de Capa 7 e inteligencia de amenazas.

Por qué: Los NSG son simples y distribuidos. Azure Firewall proporciona capacidades avanzadas y gestión de políticas centralizada, a menudo utilizado en una topología hub-spoke.

Reducir la superficie de ataque de las VMs manteniendo los puertos de gestión (RDP/SSH) cerrados por defecto.

→Habilitar el acceso Just-In-Time (JIT) a VMs en Microsoft Defender for Cloud.

Por qué: JIT concede acceso temporal a los puertos de gestión bajo demanda por un tiempo limitado, cerrándolos automáticamente después. Esto es más seguro que dejar los puertos perpetuamente abiertos.

Supervisar el estado de la infraestructura de Azure versus el rendimiento del código de la aplicación.

→Usar Azure Monitor para métricas y registros de plataforma. Usar Application Insights (una característica de Azure Monitor) para Gestión del Rendimiento de Aplicaciones (APM).

Por qué: Azure Monitor recopila datos de infraestructura (CPU, memoria). Application Insights proporciona diagnósticos profundos a nivel de código (tiempos de respuesta, dependencias, excepciones).

Recibir alertas personalizadas sobre interrupciones del servicio de Azure, mantenimiento planificado y avisos de estado.

→Usar Azure Service Health.

Por qué: Service Health está personalizado para sus suscripciones, regiones y servicios, a diferencia de la página de estado pública de Azure. Es para problemas de la plataforma Azure, no para el estado de sus propios recursos.

Recibir recomendaciones personalizadas y accionables para optimizar los recursos de Azure.

→Revisar las recomendaciones de Azure Advisor.

Por qué: Advisor analiza su configuración y telemetría de uso y proporciona recomendaciones en cinco pilares: Fiabilidad, Seguridad, Rendimiento, Costo y Excelencia Operacional.

Establecer una base estandarizada, gobernada y escalable para todas las cargas de trabajo de Azure en una empresa.

→Implementar una arquitectura de Azure Landing Zone.

Por qué: Las Landing Zones proporcionan un marco prescriptivo del Cloud Adoption Framework, incluyendo estructura de grupos de gestión, redes, identidad y políticas de gobernanza, para acelerar la adopción segura de la nube.