AWS frente a Azure KMS

AWS Key Management Service (KMS) y Azure Key Vault son los servicios nativos de administración de claves para AWS y Microsoft Azure, respectivamente. La elección correcta depende de su modelo de IAM, los requisitos de HSM y las necesidades de rotación. La mayoría de los equipos que trabajan con dos nubes deberían optar por el servicio nativo de cada proveedor para las cargas de trabajo que permanecen en esa nube, y recurrir a un administrador de claves de terceros o multinube solo cuando necesiten un plano de control único para ambas.

Publicado: octubre de 2018. Actualizado: agosto de 2026. Escrito por Aryan Kumar , revisado por el equipo de seguridad en la nube de Encryption Consulting.

Esta comparación se centra en AWS y Azure, ya que es la combinación de dos nubes más común que observamos en la práctica. Si también le interesa Google Cloud, consulte nuestro artículo complementario, AWS KMS vs. Azure Key Vault vs. GCP KMS , que utiliza este mismo marco para los tres proveedores.

¿Qué son AWS KMS y Azure Key Vault?

AWS Key Management Service (KMS) es el servicio administrado de AWS para crear, almacenar y controlar el acceso a las claves de cifrado, llamadas claves KMS, que protegen los datos en servicios de AWS como S3, EBS y RDS. Azure Key Vault es el servicio administrado de Microsoft para claves, secretos y certificados, y también funciona como la capa de administración de claves nativa de Azure para servicios como Storage, SQL Database y Disk Encryption. Ambos son plataformas de control para claves criptográficas, no administradores de secretos de propósito general que compitan con soluciones como HashiCorp Vault, aunque ambos también almacenan secretos de aplicaciones. El resto de este artículo trata la "administración de claves" como la función común de ambos servicios y señala las diferencias en sus enfoques.

¿Cómo almacenan AWS KMS y Azure Key Vault las claves de forma nativa?

AWS KMS proporciona a cada cliente protección de nivel HSM para claves administradas de forma predeterminada; Azure Key Vault divide esa garantía entre los diferentes niveles de precios, por lo que el nivel que elija determina el hardware que respalda sus claves.

Control	AWS KMS	Azure Key Vault
Protección de clave predeterminada	Módulos de seguridad de hardware (HSM) validados según FIPS 140-3 Nivel 3 para cada clave gestionada por el cliente.	Nivel estándar: claves protegidas por software, FIPS 140-2 Nivel 2
Opción HSM dedicada para un solo inquilino	AWS CloudHSM (servicio independiente) para un control completo de un solo inquilino.	HSM gestionado: grupo de HSM FIPS 140-3 de nivel 3 para un solo inquilino con su propio modelo RBAC.
Nivel de Key Vault respaldado por HSM	No aplica (KMS ya cuenta con el respaldo de HSM)	Nivel Premium: Claves protegidas por HSM, FIPS 140-3 Nivel 3, grupo HSM compartido para múltiples inquilinos.
Tipos de teclas compatibles	Simétrico (AES-256), RSA, curva elíptica (curvas NIST y SEC), HMAC	Solo RSA y curva elíptica; no hay un tipo de clave de cifrado simétrico nativo.
Portabilidad clave	Las claves KMS no se pueden exportar; el Almacén de claves externo (XKS) puede mantener el material de clave completamente fuera de AWS.	Se pueden importar claves (BYOK); la gestión de claves externa (versión preliminar) puede delegar operaciones a un HSM externo.

Dos aclaraciones terminológicas importantes: AWS dejó de usar el término "Clave maestra de cliente (CMK)" hace años y lo reemplazó por "clave KMS". Por lo tanto, cualquier documentación o publicación de blog que aún utilice CMK describe una convención de nomenclatura obsoleta, no una función diferente. Además, el nivel Estándar de Azure, protegido por software, sigue respaldado por HSM compartidos; "protegido por software" describe cómo Azure expone la operación de clave, no que el material de la clave se encuentre en memoria sin protección.

¿Deberías usar claves nativas, BYOK o HYOK en AWS y Azure?

Utilice claves nativas a menos que un requisito contractual o de cumplimiento específico obligue al control externo; utilice BYOK cuando necesite incorporar material de clave existente al HSM del proveedor de la nube; reserve HYOK para el caso excepcional en el que sus claves nunca deban ser generadas ni almacenadas en el proveedor de la nube.

Modelo	AWS	Azure
Nativo	Claves KMS administradas por AWS o administradas por el cliente, generadas y almacenadas dentro de KMS.	Claves generadas por la bóveda en HSM estándar, premium o gestionado
BUENO	Importe el material de clave externo a una clave KMS administrada por el cliente (el material de clave permanece en AWS una vez importado).	Importe el material clave mediante un blob de transferencia segura a Key Vault o Managed HSM.
HYOK (la clave permanece fuera de la nube)	Almacén de claves externo (XKS): AWS actúa como proxy para cada operación criptográfica a través de un punto final de VPC en su administrador de claves externo; listo para producción, pero agrega una dependencia externa estricta para cada llamada a KMS.	Administración de claves externas (EKM): solo vista previa, las operaciones de encapsulado y desencapsulado se realizan a través de un HSM externo, se excluyen explícitamente del SLA de Azure.

La disyuntiva es la misma en ambas nubes: HYOK ofrece la justificación contractual más sólida («el proveedor de la nube nunca tuvo nuestras claves»), pero también implica que cada operación de cifrado o descifrado depende de la disponibilidad del gestor de claves externo. La mayoría de los equipos con los que trabajamos optan por claves nativas gestionadas por el cliente, además de BYOK para las claves que ya existen en otros lugares, y reservan HYOK para los mandatos regulatorios que lo exigen específicamente.

¿En qué se diferencia el modelo IAM entre AWS KMS y Azure Key Vault?

AWS KMS superpone una política de claves a nivel de recurso debajo de las políticas IAM estándar, por lo que dos documentos separados deben coincidir antes de que una llamada tenga éxito; Azure Key Vault aplica el acceso a nivel de bóveda o clave a través de políticas de acceso heredadas o Azure RBAC, por lo que los permisos en Azure suelen ser más fáciles de auditar, pero su alcance es más impreciso.

• AWS KMS: Cada clave KMS tiene su propia política de claves basada en recursos, que constituye la raíz de confianza para dicha clave. Las políticas de identidad IAM solo pueden otorgar permisos adicionales dentro de los límites permitidos por la política de claves. Los permisos otorgan autorizaciones temporales y revocables para entidades principales específicas, comúnmente utilizadas para el acceso entre cuentas.
• Azure Key Vault: Las directivas de acceso al almacén (heredado) o las asignaciones de roles de Azure RBAC (recomendado) controlan quién puede administrar o usar las claves. Managed HSM utiliza su propio modelo RBAC local, independiente del resto de Azure RBAC, algo que los equipos que migran de Key Vault Premium a Managed HSM deben tener muy en cuenta.

Un despliegue práctico basado en el principio de mínimo privilegio se ve similar en ambas nubes:

1. Inventarie cada entidad principal (usuario, rol, servicio) que actualmente interactúa con el material clave, en cualquiera de las dos nubes.
2. Reemplace cualquier clave comodín o permisos de bóveda con concesiones con ámbito vinculadas a un ARN de clave KMS específico o a un ID de recurso de Key Vault.
3. Separe la administración de claves (creación, rotación, eliminación) del uso de claves (cifrado, descifrado, firma) para que ningún rol pueda realizar ambas funciones.
4. Habilite el acceso entre cuentas o entre inquilinos únicamente mediante concesiones explícitas (AWS) o asignaciones de roles limitadas a la identidad que realiza la llamada (Azure), nunca mediante una confianza general en la cuenta.
5. Revise las políticas clave y las asignaciones de RBAC con una periodicidad fija, no solo en el momento del aprovisionamiento, ya que la desviación de permisos es el hallazgo de auditoría más común que observamos en las revisiones de administración de claves en la nube.

¿Cómo funciona la rotación de claves en AWS KMS frente a Azure Key Vault?

AWS KMS automatiza la rotación una vez que la activas; Azure Key Vault te ofrece un control más detallado sobre el intervalo de rotación, pero tienes que diseñar y supervisar la política tú mismo.

• AWS KMS: La rotación automática está disponible para las claves de cifrado simétrico gestionadas por el cliente con origen AWS_KMS, en un ciclo configurable de 90 a 2,560 días (365 días por defecto). Las claves asimétricas y HMAC KMS no pueden rotar automáticamente y deben rotarse manualmente creando una nueva clave y actualizando las referencias. Las claves con material de clave importado (origen EXTERNO) admiten la rotación bajo demanda en lugar de la rotación automática.
• Azure Key Vault: Las directivas de rotación pueden configurarse con intervalos de tan solo 7 días desde la creación de la clave o desde su fecha de caducidad, y pueden activarse según una programación fija o un porcentaje de la vida útil restante de la clave. Tanto la versión antigua como la nueva de la clave permanecen habilitadas durante la rotación, por lo que los datos cifrados con la versión anterior se siguen descifrando. Azure no elimina automáticamente las versiones antiguas, por lo que el crecimiento de versiones debe gestionarse como parte de la directiva de rotación.

¿Qué información se debe registrar y supervisar en AWS KMS y Azure Key Vault?

Cada llamada a la API de KMS se registra en AWS CloudTrail de forma predeterminada como un evento de administración; cada operación de Key Vault solo se registra en Azure Monitor una vez que se activan explícitamente las configuraciones de diagnóstico, que es la deficiencia de registro más común que encontramos en las auditorías de administración de claves de Azure.

• AWS: CloudTrail registra cada llamada a la API de KMS (cifrado, descifrado, generación de clave de datos, etc.) con el principal que realiza la llamada, la IP de origen y el ARN de la clave, activados de forma predeterminada para los eventos de administración. Envíe estos registros a CloudWatch o a un SIEM y reciba alertas sobre llamadas de descifrado inesperadas, eliminaciones de claves o cambios en las políticas.
• Azur: Key Vault emite una categoría de registro de eventos de auditoría a través de la configuración de diagnóstico de Azure Monitor, que no está habilitada de forma predeterminada y debe configurarse para cada almacén. Una vez habilitada, dirija los registros a un espacio de trabajo de Log Analytics o a SIEM y configure alertas para las mismas categorías: uso inesperado de claves, eliminación de claves o almacenes, y cambios en la directiva de acceso o RBAC.

¿Cómo se comparan los costos de AWS KMS y Azure Key Vault?

El precio de AWS KMS es sencillo y fijo por clave; el precio de Azure Key Vault depende en gran medida del nivel que elija, y Managed HSM en particular utiliza un modelo de facturación diferente, basado en grupos, en lugar de un precio por clave.

Servicio	Modelo de precios aproximado
AWS KMS	$1 por clave administrada por cliente al mes (prorrateado), más $0.03 por cada 10,000 solicitudes de API que superen las 20,000 solicitudes gratuitas al mes.
Azure Key Vault Standard	Sin cargo por clave; aproximadamente $0.03 por cada 10,000 operaciones en claves y secretos protegidos por software.
Azure Key Vault Premium	Aproximadamente 1 dólar por clave RSA 2048 protegida por HSM al mes, más cargos por operación, con precios por clave más altos para claves RSA 3072/4096 y ECC.
Azure Managed HSM	Se factura por grupo HSM por hora en lugar de por clave, y suele rondar entre 3 y 3.20 dólares por hora para el nivel estándar, independientemente del volumen de uso.

Considere las cifras de Azure anteriores como orientativas. La página oficial de precios de Azure carga dinámicamente las tarifas específicas de la región y la moneda, así que confirme los precios actuales para su región antes de elaborar un presupuesto, especialmente para Managed HSM, donde la tarifa plana por hora del pool puede resultar más cara que Premium para equipos que administran solo unas pocas claves.

¿Qué ocurre si añades Google Cloud más adelante? Una nota sobre la gestión de claves en múltiples nubes.

Si se incorpora una tercera nube al conjunto, la comparación entre AWS y Azure que se presenta en esta publicación se convierte en un dato más para una decisión más amplia, no en una decisión que haya que replantear desde cero.

Los equipos que planean agregar GCP Cloud KMS, o que ya utilizan las tres nubes, deberían leer nuestra comparación principal, AWS KMS vs. Azure Key Vault vs. GCP KMS , que amplía todas las comparaciones de esta publicación (almacenamiento nativo, BYOK/HYOK, IAM, rotación, registro, costo) a los tres proveedores. Para patrones de arquitectura que centralizan la administración de claves en las nubes en lugar de ejecutar tres servicios nativos separados en paralelo, consulte nuestra guía de arquitectura PKI-as-a-Service multi-nube y la descripción general de la administración de claves multi-nube del Centro de Educación.

¿Cuáles son las limitaciones de AWS KMS y Azure Key Vault?

• AWS KMS: No hay rotación automática para claves asimétricas o HMAC; External Key Store añade una dependencia estricta de la infraestructura externa para cada llamada criptográfica; las claves KMS nunca se pueden exportar una vez creadas dentro de AWS (solo XKS mantiene el material fuera de AWS).
• Azure Key Vault: No hay un tipo de clave de cifrado simétrico nativo; el modelo RBAC local de Managed HSM es independiente del RBAC estándar de Azure, lo que añade un segundo modelo de permisos que mantener; la administración de claves externas solo está en vista previa, sin SLA, y el registro de diagnóstico es opcional en lugar de estar activado de forma predeterminada.

Lista de verificación para la toma de decisiones: ¿AWS KMS o Azure Key Vault?

1. Identifique qué nube ya aloja la carga de trabajo; utilice por defecto el servicio nativo de esa nube a menos que un requisito específico indique lo contrario.
2. Confirme el nivel de validación HSM real de su requisito de cumplimiento (FIPS 140-2 Nivel 2, FIPS 140-3 Nivel 3 o Criterios Comunes) y asócielo con el nivel de Azure correcto o confirme que AWS KMS ya lo cumple de forma predeterminada.
3. Decide si necesitas claves de cifrado simétrico (solo AWS KMS las admite de forma nativa) o si puedes trabajar completamente con RSA/ECC.
4. Defina quién administra las claves y quién las utiliza, y diseñe la política de IAM o la división de roles RBAC antes del aprovisionamiento, no después.
5. Si existe un requisito real de HYOK, confirme si su mandato de cumplimiento puede aceptar el estado de producción de AWS External Key Store o si realmente requiere la fase de vista previa de External Key Management de Azure, ya que la brecha del SLA no es meramente estética.

¿Qué recomendaría Encryption Consulting?

Para la mayoría de los equipos que trabajan con dos nubes, recomendamos comenzar con el servicio de administración de claves nativo de cada proveedor, claves KMS administradas por el cliente en AWS y Key Vault gobernado por RBAC (Premium, si se requiere respaldo de HSM) en Azure, en lugar de introducir un administrador de claves de terceros desde el primer día. La complejidad que realmente causa incidentes suele ser un diseño de IAM inconsistente y un registro sin supervisión, no la elección del servicio nativo en sí. Donde sí vemos que los equipos se benefician de centralizar el control es cuando el volumen de claves, el alcance de la auditoría o un requisito genuino de HYOK hacen que administrar dos consolas nativas separadas sea poco práctico; en ese punto, una capa administrada como HSM-as-a-Service o una implementación más amplia de protección de datos en la nube puede brindarle un plano de control, una política de rotación y un registro de auditoría en ambas nubes en lugar de dos de todo.

Preguntas frecuentes

¿Una "clave maestra de cliente (CMK)" es lo mismo que una clave KMS?

Sí. AWS cambió el nombre de Customer Master Key a "clave KMS" en su documentación y consola; cualquier referencia a una CMK hoy en día describe el mismo tipo de recurso con su nombre anterior, no una función obsoleta.

¿Puede Azure Key Vault almacenar claves de cifrado simétrico como AWS KMS?

No. Azure Key Vault solo admite de forma nativa claves RSA y de curva elíptica. Los equipos que necesitan administrar claves simétricas en Azure suelen generar y encapsular claves de datos simétricas en el código de la aplicación utilizando una clave RSA o EC almacenada en Key Vault, en lugar de almacenar directamente el tipo de clave simétrica.

¿HYOK está disponible actualmente en Azure?

Solo en versión preliminar. La función de administración de claves externas de Azure redirige las operaciones de encapsulado y desencapsulado a un HSM externo, pero Microsoft la excluye explícitamente del SLA estándar de Azure mientras permanezca en versión preliminar, por lo que aún no es un sustituto de nivel de producción para AWS External Key Store.

¿Podemos migrar claves directamente entre AWS KMS y Azure Key Vault?

No directamente, y mucho menos para las claves KMS de AWS creadas dentro de AWS, ya que las claves KMS nunca se pueden exportar. El material de clave que usted mismo generó originalmente e importó a una nube (BYOK) también se puede, en principio, importar a la otra, pero esto requiere que conserve y administre ese material de clave original fuera de ambas nubes, que es precisamente la carga operativa que la mayoría de los equipos intentan evitar con las claves nativas.

¿La actividad de Azure Key Vault se registra de forma predeterminada del mismo modo que AWS CloudTrail registra las llamadas a KMS?

No. AWS CloudTrail registra automáticamente las llamadas a la API de KMS como eventos de administración. Los registros de AuditEvent de Azure Key Vault requieren que configure explícitamente una configuración de diagnóstico en cada almacén; hasta que lo haga, las operaciones con claves y secretos en ese almacén no se registrarán.

¿Tiene alguna pregunta específica sobre la migración de la administración de claves de AWS a Azure o sobre el diseño de IAM? Póngase en contacto con nuestro equipo en [email protected].