Diccionario

azurerm_subscription crea un alias para una suscripción y necesita un billing scope; el recurso no "crea" la relación con el tenant. En GCP, además de crear el proyecto, cada API se habilita aparte (google_project_service).

↗ registry.terraform.io↗ registry.terraform.io

El resource group de Azure es dueño del ciclo de vida de sus recursos (borrarlo los borra). En AWS, aws_resourcegroups_group es una consulta por tags o por stack, no un contenedor; en GCP el contenedor más cercano es el propio proyecto.

↗ learn.microsoft.com↗ registry.terraform.io

En GCP cada API se habilita por proyecto y un terraform apply sobre un proyecto nuevo falla hasta que está habilitada. En Azure el provider registra los resource providers que necesita de forma automática salvo que lo desactives. En AWS no hay un paso equivalente por servicio.

↗ registry.terraform.io↗ registry.terraform.io

Limitan cosas distintas: Azure Policy evalúa propiedades de los recursos (y puede auditar, denegar o modificar), las SCP de AWS ponen un techo a las acciones de IAM, y las org policies de GCP aplican constraints predefinidos o custom. Definición y asignación son recursos separados en Azure y AWS.

↗ learn.microsoft.com↗ aws.amazon.com↗ cloud.google.com

aws_iam_role junta identidad, trust policy y (con policies adjuntas) permisos. En Azure y GCP la identidad es un recurso y los permisos son role assignments o bindings aparte.

En GCP cada recurso tiene tres variantes: _iam_policy (autoritativa sobre toda la policy), _iam_binding (autoritativa por rol) y _iam_member (aditiva). Mezclar una autoritativa con _iam_member sobre el mismo recurso hace que se pisen en cada apply. En Azure el scope va en el propio role assignment.

↗ registry.terraform.io

Un rol custom de Azure o GCP es una lista de acciones que después se asigna sobre un scope. Una policy de AWS es un documento que puede incluir condiciones y recursos concretos, y se adjunta a una identidad.

En Azure cada credencial es un par issuer + subject exacto sobre una identidad. En AWS el provider es uno por URL y por cuenta, y la confianza vive en la trust policy del rol. En GCP pool y provider llevan la condición CEL, y el acceso se da con bindings sobre principalSet.

La VNet y la VPC de AWS son regionales; la VPC de GCP es global y sus subnets son regionales.

aws_subnet vive en una sola zona de disponibilidad (availability_zone); la subnet de Azure abarca la región y la de GCP también es regional. Alta disponibilidad en AWS = una subnet por AZ.

El NSG se asocia a subnets o NICs. El security group de AWS se adjunta a interfaces de red y es stateful (las NACL son por subnet y stateless). En GCP las reglas son de la VPC y apuntan a instancias por network tags o service accounts.

Azure y AWS asocian una tabla de rutas a cada subnet. En GCP no hay tabla por subnet: cada ruta es un recurso de la VPC y se puede aplicar a instancias por network tags.

En Azure y GCP hace falta un recurso por cada lado del peering. En AWS es una conexión que el otro lado acepta (aws_vpc_peering_connection_accepter cuando es otra cuenta o región).

En Azure el NAT gateway se asocia a la subnet. En AWS vive en una subnet pública y las privadas llegan con una ruta. En GCP Cloud NAT es una configuración de un Cloud Router.

aws_vpc_endpoint cubre los tipos Interface y Gateway (vpc_endpoint_type). En GCP depende del servicio: un endpoint de Private Service Connect es una forwarding rule, y la IP privada de Cloud SQL usa private services access (google_service_networking_connection).

En Azure la zona privada es un tipo de recurso propio y se vincula a cada VNet. En AWS y GCP es el mismo recurso que una zona pública, con un bloque vpc (AWS) o visibility = private (GCP).

Azure y AWS modelan endpoints de entrada y salida. En GCP la entrada es una server policy y la salida es un bloque forwarding_config dentro de una managed zone.

Azure Firewall es un recurso que se despliega en la VNet (en una subnet propia) y una policy aparte lleva sus reglas. Network Firewall crea un endpoint por zona de disponibilidad en las subnets que indicás y las route tables tienen que apuntar a él. En GCP el firewall endpoint es zonal y se asocia a cada VPC; no inspecciona nada hasta que una regla de la network firewall policy con la acción apply_security_profile_group le manda el tráfico (ver firewall-rules).

↗ learn.microsoft.com↗ aws.amazon.com↗ cloud.google.com

En Azure las reglas viven en collection groups de una firewall policy, y las de FQDN pueden ser de aplicación o de red. En AWS el filtrado por dominio es un rule group stateful (que después se referencia desde la firewall policy) y Network Firewall usa Suricata. En GCP las reglas son de una network firewall policy que se asocia a la VPC, y los FQDN objects son una capacidad del tier Standard.

↗ learn.microsoft.com↗ aws.amazon.com↗ cloud.google.com

Son las alternativas al peering cuando querés tránsito entre spokes: Virtual WAN (el hub es una red administrada por Microsoft con un router propio), Transit Gateway (attachments con una route table por asociación y propagación explícita) y Network Connectivity Center (hub global con spokes; los VPC spokes intercambian subnet routes). Los módulos del patrón usan peering en Azure y GCP (no transitivo) y Transit Gateway en AWS: no son la misma topología.

↗ learn.microsoft.com↗ aws.amazon.com↗ cloud.google.com

Azure tiene un nivel más: la storage account (red, Shared Key, cifrado) y adentro los contenedores. En el provider de AWS la configuración del bucket está repartida en recursos separados (aws_s3_bucket_versioning, _public_access_block, _lifecycle_configuration…). En GCP casi todo es un bloque del bucket.

↗ registry.terraform.io

En GCP no es un recurso aparte sino un bloque lifecycle_rule dentro de google_storage_bucket.

Para Aurora PostgreSQL en AWS el recurso es aws_rds_cluster (con aws_rds_cluster_instance).

Key Vault es un contenedor con su propio modelo de acceso, y los secretos viven adentro. En AWS y GCP cada secreto es un recurso de primer nivel y el valor es una versión aparte.

En GCP los key rings y las crypto keys no se pueden borrar: un terraform destroy las saca del state y destruye sus versiones, pero el nombre queda tomado.

↗ registry.terraform.io

En Azure el acceso a los datos del vault se da con un role assignment (por ejemplo Key Vault Secrets User), recomendado al scope del vault; asignarlo sobre un secreto individual es la excepción. En AWS se puede combinar una resource policy del secreto con una política de la identidad. En GCP el binding (Secret Manager Secret Accessor) se puede dar sobre el secreto.

↗ learn.microsoft.com↗ aws.amazon.com↗ cloud.google.com

Solo AWS tiene un recurso que programa la rotación (con una función Lambda para la mayoría de los secretos). En GCP el bloque rotation del secreto solo publica notificaciones a Pub/Sub y un suscriptor tiene que crear la versión nueva. En Azure Key Vault no hay recurso de rotación para secretos: publica un evento de casi vencimiento a Event Grid y una función hace la rotación.

↗ aws.amazon.com↗ cloud.google.com↗ learn.microsoft.com

En Azure los resource logs del vault (categoría AuditEvent) no se recolectan hasta crear un diagnostic setting. En GCP los Data Access audit logs están apagados por defecto y se activan con la audit config del proyecto. En AWS CloudTrail registra las llamadas a Secrets Manager; un trail (aws_cloudtrail) sirve para conservar los eventos más allá de los 90 días del historial.

↗ learn.microsoft.com↗ cloud.google.com↗ aws.amazon.com

Service Bus tiene un namespace (tier, red, autenticación) con colas adentro. SQS es un recurso por cola. Pub/Sub separa topic y suscripción, y los mensajes se retienen por suscripción.

Una Function App de Azure necesita un plan y una storage account propios; Lambda y Cloud Functions son un solo recurso.

Container Apps separa environment (red, logs) y app. ECS separa cluster, task definition y service. Cloud Run es un único recurso por servicio.

AKS exige un default node pool como bloque dentro del cluster. En GKE la documentación del provider recomienda borrar el pool por defecto (remove_default_node_pool) y manejar los pools como recursos aparte. En EKS los node groups siempre son recursos aparte.

↗ registry.terraform.io

En Azure la NIC es un recurso aparte que la VM referencia; en AWS y GCP la interfaz principal se declara dentro de la instancia.

En Azure los logs de recursos no llegan al workspace hasta que creás un diagnostic setting por recurso. En GCP los logs ya entran al proyecto; los sinks los enrutan a otro bucket o destino.

↗ learn.microsoft.com↗ cloud.google.com

En CloudFront una sola distribución declara orígenes, cache behaviors y seguridad. Front Door lo reparte en profile, origin group, origin y route. En GCP no hay un recurso de CDN aparte: Cloud CDN se habilita en un backend bucket que cuelga de un Application Load Balancer externo (url map, proxy HTTPS y forwarding rule), y si no se habilita en ese paso el balanceador sirve desde Cloud Storage sin cache.

↗ learn.microsoft.com↗ aws.amazon.com↗ cloud.google.com

Tres mecanismos distintos. Front Door Premium crea un private endpoint hacia el storage (bloque private_link del origin) y hay que aprobar la conexión del lado del origen antes de que pase tráfico. CloudFront firma cada pedido a S3 con un OAC y el bucket necesita una policy que permita al principal cloudfront.amazonaws.com con una condición sobre la distribución. En GCP no hay un recurso equivalente al OAC: hay que dar lectura sobre el bucket a la cuenta de servicio de Cloud CDN, que recién existe cuando se agrega la primera signed URL key al backend bucket.

↗ learn.microsoft.com↗ aws.amazon.com↗ cloud.google.com

En Front Door la WAF policy es un recurso y se asocia al endpoint o dominio con un security policy aparte; las managed rules son solo de Premium. En CloudFront se crea un web ACL de AWS WAF y se lo asocia a la distribución. En GCP, a un backend bucket solo se le pueden aplicar edge security policies de Cloud Armor (type CLOUD_ARMOR_EDGE), que se adjuntan al backend service.

↗ learn.microsoft.com↗ aws.amazon.com↗ cloud.google.com

Azure Policy tiene un objeto exemption propio, con categoría (waiver o mitigated), vencimiento opcional (expiresOn; al vencer no se borra, deja de honrarse) y metadata de quién lo pidió y aprobó. En GCP no hay objeto de excepción: se pone una org policy en el recurso hijo, que reemplaza a la heredada. En AWS no hay recurso equivalente: un Deny de una SCP aplica a todo lo que cuelga del nivel donde está adjunta.

↗ learn.microsoft.com↗ cloud.google.com↗ aws.amazon.com

En AWS un organization trail (is_organization_trail, creado desde la cuenta de management) registra los eventos de todas las cuentas en un mismo bucket de S3. En GCP un sink agregado en la organización o una carpeta (include_children) enruta los logs de todo lo que cuelga de ahí, y su writer identity necesita permisos en el destino. En Azure el activity log es por suscripción y sale con un diagnostic setting por suscripción; el de un management group no cubre todos los eventos de nivel suscripción.

↗ aws.amazon.com↗ cloud.google.com↗ learn.microsoft.com

Los eventos de plano de datos no se registran por defecto en ninguna nube. En GCP los Data Access audit logs vienen apagados (salvo algunos de BigQuery) y se activan por servicio y tipo (ADMIN_READ, DATA_READ, DATA_WRITE) en la organización, carpeta o proyecto; los Admin Activity no se pueden apagar. En Azure los resource logs se activan con las categorías de un diagnostic setting por recurso. En CloudTrail son los data events del trail, que se eligen por recurso.

↗ cloud.google.com↗ learn.microsoft.com↗ aws.amazon.com