Escribe para buscar notas, herramientas y páginas...

Comparación de controles multi-cloud: AWS, Azure, GCP, Alibaba Cloud

Referencia comparativa de los controles que importan en una zona de aterrizaje. Filtra por área, activa o desactiva proveedores y copia lo que necesites.

Última revisión completa: August 2026. Si ves algo desactualizado, contáctame directamente.

Proveedores
Área

Desplaza en horizontal para comparar proveedores. La columna de control permanece visible.

Comparación de controles entre AWS, Azure, GCP y Alibaba Cloud
ControlAWSAzureGCPAlibaba Cloud

Preguntas frecuentes

AWS IAM usa documentos de política JSON con reglas Allow/Deny asociadas a identidades o recursos. Azure RBAC asigna roles integrados o personalizados en un ámbito (suscripción, grupo de recursos o recurso). Ambos siguen el principio de mínimo privilegio, pero el lenguaje de políticas y el modelo de asignación no son portables. Federar ambos a través de un IdP central como Entra ID u Okta es el enfoque estándar. Ver: RBAC patterns for production cloud environments.

Sí. El provider de Terraform aliyun/alicloud está listo para producción. Soporta Resource Directory (multi-cuenta), roles RAM, VPC, OSS y SLS. El locking del state se gestiona con OSS + Table Store (OTS). Hay módulos oficiales de zona de aterrizaje en alibabacloud-automation en GitHub.

Las VPC de GCP son globales por defecto. Las subnets son regionales, pero una sola VPC abarca todas las regiones. Las VPC/VNet de AWS y Azure son regionales. Esto cambia las asunciones de peering entre regiones. GCP usa Shared VPC para compartir red entre cuentas. AWS usa Transit Gateway. Azure usa Virtual WAN o VNet Peering.

GCP Cloud Logging por defecto son 30 días. Los log groups de AWS CloudWatch por defecto son Never Expire. Azure Log Analytics por defecto son 30 días interactivos. Alibaba SLS por defecto son 30 días. Para la mayoría de marcos de cumplimiento, configura al menos 90 días y, idealmente, 1 año para logs de auditoría de management. Define la retención de forma explícita en el provisionamiento.

Estandariza el formato de runbook y la vía de escalado de on-call. Enruta todas las alertas de los proveedores a una única plataforma de on-call. Diverge en el tooling nativo de alerting, porque es nativo de cada proveedor y abstraerlo añade coste sin beneficio.