Qué cambió en la letra chica

CloudTrail crea el trail de organización en las cuentas miembro aunque falle la validación de un recurso; la documentación da como ejemplos una bucket policy incorrecta y permisos insuficientes para cifrar con una clave KMS. Que el apply termine bien no prueba que haya entrega. Revisá get-trail-status: si hay un problema con el bucket, el campo LatestDeliveryError muestra el error de S3 (solo aparece por problemas del bucket de destino, no por requests que expiran). Corregilo con la bucket policy, o creando otro bucket y llamando a update-trail.

Alcance de la fuente: el ejemplo oficial es de un bucket que pertenece a la cuenta de management de la organización; la documentación no cubre un bucket en otra cuenta (como la de log archive de este módulo), así que probalo en un entorno de prueba. El bucket de un trail de organización necesita una policy que deje a CloudTrail escribir los logs de la organización: el ejemplo oficial tiene tres sentencias (GetBucketAcl, PutObject en el prefijo de la cuenta de management y PutObject en el prefijo AWSLogs/o-<id de la organización>/). El aws:SourceArn tiene que ser el ARN de un trail de la cuenta de management, con el ID de esa cuenta. Esa policy no da acceso a usuarios de las cuentas miembro: por defecto, los logs de la organización son accesibles solo para la cuenta de management. Listá de forma explícita a quién querés dar lectura y no asumas que las cuentas miembro leen.

Si el trail de organización es multi-región y su home Region es una región opt-in, las cuentas miembro no envían actividad al trail a menos que habiliten esa región; el ejemplo de la documentación es Europe (Spain): solo las cuentas que la habilitaron envían su actividad. Los trails de organización creados desde la consola son multi-región. Elegí como home Region una región habilitada por defecto, o verificá que cada cuenta habilitó la región; si una cuenta no aparece en el bucket, revisá este punto.

Si el trail está mal configurado (por ejemplo, el bucket no es alcanzable), CloudTrail intenta reentregar los logs al bucket durante 30 días, y esos intentos de entrega se cobran como CloudTrail estándar. Para evitar los cargos de un trail mal configurado hay que borrarlo. Corregí la bucket policy y la key policy antes de crear el trail (en Terraform, con depends_on del trail sobre ambas) y revisá get-trail-status después.

AWS recomienda con énfasis no adjuntar una SCP a la raíz sin probar su impacto en las cuentas: crear una OU y mover las cuentas de a una, o en grupos chicos, para no dejar a nadie sin acceso a servicios clave. Para las RCP recomienda empezar por cuentas de prueba, subir por las OU y revisar en CloudTrail los errores de acceso denegado. Además, no hay que quitar la política FullAWSAccess sin modificarla o reemplazarla por otra con las acciones permitidas: si no, fallan todas las acciones de AWS de las cuentas miembro. Para una S3 policy, después de cada cambio revisá la política efectiva de cuentas representativas con DescribeEffectivePolicy.

La guía de Front Door para un origen de Storage indica que, si el blob o el contenedor no permiten acceso anónimo, los pedidos contra ellos deben autorizarse, por ejemplo con shared access signatures, y lista como error común no usar SAS contra una cuenta que no permite acceso anónimo. Según la misma guía, el acceso desde internet público a la cuenta queda deshabilitado una vez que se habilita el private endpoint. Entonces hay queSi elegir:el contenedor con lectura anónima de blobs,no quepermite soloacceso seanónimo, alcanzano porconectes el private endpoint, oorigen SASsin enautorizar los pedidos. Decidilo de forma explícita y no dejes el contenedor privado sin SAS.

Para que las URLs firmadas protejan el contenido, el origen no debe dar acceso público: la documentación indica sacar los permisos de lectura de allUsers (y allAuthenticatedUsers, si aplica) del bucket, que es habitual dejar públicos durante las pruebas. Aun sin acceso público, quien ya tiene permiso sobre el bucket, por ejemplo OWNER, puede acceder a Cloud Storage sin URL firmada. Y una URL firmada da acceso por tiempo limitado a cualquiera que la tenga, sea o no usuario de Google. La misma página advierte que Cloud CDN no bloquea los pedidos sin parámetro Signature ni cookie Cloud-CDN-Cookie (rechaza los de parámetros inválidos) y que el origen debe validar las firmas y aceptar o rechazar los pedidos sin firma. Revisá que el bucket no tenga allUsers ni allAuthenticatedUsers antes de dar la entrada por cerrada, y firmá solo URLs HTTPS.

El principalSetAl yotorgar elroles workload_identity_providera queidentidades leexternas pasásse ausa lael actionnúmero sonde projects/NÚMERO/locations/global/...,proyecto, no el IDID: delel proyecto.principalSet es principalSet://iam.googleapis.com/projects/NÚMERO_DE_PROYECTO/locations/global/workloadIdentityPools/.... Además, un cambio de IAM suele aplicarse en 2 minutos pero puede tardar 7 o más, así que un pipeline que se acaba de configurar puede fallar en la primera corrida sin que nada esté mal.más.

Cloud DNS no usa IPs deel turango VPC35.199.192.0/19 para reenviar:todos todalos consultaclientes, y es el origen de las consultas a untargets forwardingType target1 saley desdeType 35.199.192.0/19.2 El(IP firewallinterna de VPC y on-premises tienepor queVPN permitiro UDPInterconnect). yLos TCPtargets 53Type desde3 eseusan rango,los rangos de Google Public DNS, y on-premisesen necesitaType una4 rutael rango depende de vueltalas porIPs losa túneleslas VPNque oresuelve attachmentsel denombre. InterconnectPara deun target Type 2, on-premises necesita una ruta a 35.199.192.0/19 cuyo next hop esté en la misma VPC.VPC, Conpor BGPun esotúnel esCloud unVPN anuncioo customun delattachment Cloudde Router.Interconnect. SinCon laBGP ruta,eso eles DNSun on-premisesanuncio recibede laruta consultacustom yen la respuestasesión seBGP pierde.del Cloud Router.

PrivateLas GoogleVMs Accessque solo permitetienen queIP VMsinterna sinpueden IPusar públicaPrivate lleguenGoogle Access para llegar a las APIs y servicios de Google. ParaEso resuelve el alcance, no el filtrado de origen. Bucket IP filtering permite restringir el origenacceso necesitásal bucket según rangos de IP filteringdel ocliente VPCy Serviceredes Controls.VPC, y funciona junto con IAM.

Con ingress internal, Cloud Run rechazasolo acepta requests quede nofuentes vengancomo delas VPCs del mismo proyectoproyecto, (oun perímetro de VPC SC)SC o deun otrosinternal serviciosApplication Load Balancer, y de Google,productos auncomo usandoCloud Scheduler, Cloud Tasks, Eventarc, Pub/Sub o Workflows si están en el mismo proyecto o perímetro y usan la URL run.app.run.app por defecto. Las demás fuentes, incluida internet, no llegan. Pero la autenticación IAM sigue aplicando: el cliente tiene que presentar un ID token y su cuenta de servicio necesita roles/run.invoker.

IAM valida el certificado de GitHub contra su librería de CAs raíz confiables, así que thumbprint_list es opcional y, en el provider de Terraform, para IdPs como GitHub se guarda pero no se usa para verificar. Los thumbprints solo entran en juego si el IdP usa un certificado que no firma una de esas CAs, o si AWS no puede obtener el certificado TLS o se requiere TLS v1.3. Muchos módulos viejos todavía hardcodean un thumbprint "que hay que actualizar": para GitHub no es lo que rompe el login.

El resolverAWS deindica laque VPCreenviar (baseconsultas delDNS CIDRprivadas +a 2)cualquier contestadirección abase losdel recursosCIDR de la VPC. AWS indica queVPC reenviarle+ consultas2 desde on-premises u otros servidores DNS de VPC no está soportado y puede dar resultados inestables, aunque a veces parezca funcionar. Para eso existe el inbound endpoint,inestables. igualEn quesu ellugar, deAWS Azurerecomienda ousar laun inbound policyendpoint de GCP.Resolver.

El inbound endpoint resuelve con loPara que ve suel VPC.Resolver Side la zona está asociada soloVPC aresuelva las VPCs de aplicación, on-premises recibe NXDOMAINconsultas aunqueentrantes desdecon laslos VMsregistros todode resuelvauna bien.private Enhosted multi-cuenta,zone, la zona también tiene que estar asociada a la VPC deldonde hub.creaste el inbound endpoint.

DesdePor default, Object Ownership es BucketOwnerEnforced y todas las ACLs están deshabilitadas. AWS anunció que, a partir de abril de 20232023, S3 habilitahabilitaría Block Public Access y deshabilitadeshabilitaría las ACLs en todos los buckets nuevos (Object Ownership en BucketOwnerEnforced). Ya nonuevos, essin "la"cambios diferenciapara conlos Azure.existentes. Igual declaralos en IaC: los buckets existentes no cambiaron, y declarar el estado evita drift si alguien los toca desde la consola.

El token vence a los 15 minutos y se usa solo para autenticar: no afecta la sesión una vez establecida, pero un token vencido hace que se rechace una conexión nueva. Una app que abre una conexión por requestsi tieneintentás queconectarte generarcon un token fresco cada vez; mantené un pool y renová el tokenvencido, alla abrirconexión conexionesse nuevas.rechaza.

Para bajar la imagen y mandar logs sin salida a internet, la tarea necesita interface endpoints de ECR (api y dkr) y CloudWatch Logs,dkr), más el gateway endpoint de S3 (donde ECR guarda las capas). Si usa el driver de logs awslogs, también necesita el interface endpoint de CloudWatch Logs. Cada interface endpoint se cobra por hora por AZ. La alternativa (NAT Gateway) también tiene cargo por hora y por GB.

Para crear un listener HTTPS hay que desplegar al menos un certificado de servidor SSL (de ACM o de IAM). ACM exige probar la propiedad del dominio de un certificado público por DNS, mail o HTTP, y no puede validar recursos en una private hosted zone de VPC ni en ningún otro dominio privado, aunque el ALB sea interno. ACM no valida la propiedad del dominio en certificados importados ni firmados por una CA privada.

Con manage_master_user_password = true, RDS genera la contraseña del master y la guarda en Secrets Manager. El provider de Terraform no permite combinarlo con password, y RDS no lo soporta en algunos escenarios (por ejemplo Blue/Green deployments), así que decidilo de entrada.

Private Endpoints, reglas de VNet y CMK solo existenrequieren ennamespaces Premium, que se cobracobran por messaging unit por hora aunque no haya mensajes.unit. Standard solo admite reglas de firewall por IP. Este patrón usa Standard con autenticación solo Entra ID: si el requisito es red privada, hay que pasar a Premium. En AWS, SQS se conecta por un interface VPC endpoint.

KEDA consulta el largoPara deque la cola por su cuenta. Pararegla quede loescalado hagause conuna identidad administrada, la regla de escaladose usaconfigura la propiedad identity en lugar de auth. El portal no permitelo configurarlo:soporta: hacelo por IaC o CLI.

EnAzure S3Storage acotásadmite larole policyassignments a arn:...:bucket/incoming/* y en GCP usásnivel IAMde Conditionscuenta pory prefijo.de Encontenedor. AzurePara unacotar rolepor assignmentprefijo llegao comoruta mínimohacen alfalta contenedor;condiciones paraABAC acotarsobre porel rutarole necesitásassignment condiciones(atributos ABACBlob sobreprefix ely roleBlob assignment.path). Alternativa simple: un contenedor dedicado a la ingesta (lo que hace este módulo).

Crear el Private Endpoint no alcanza: el FQDN <cuenta>.blob.core.windows.net tiene que resolver a la IP privada vía la zona privatelink.blob.core.windows.net vinculada a la VNet (o a tu DNS híbrido). Si resuelve a la IP pública,pública ely firewallla delcuenta serviciotiene firewall, este rechaza la request con 403 y parece un problema de permisos.

Terraform/ARMDesde agregael portal de Azure o la ARM API se agregan principals Entra como administradoresadministradores. (azure_pg_admin,Con CREATEROLE,isAdmin=true, CREATEDB).pgaadauth_create_principal les da azure_pg_admin, CREATEROLE y CREATEDB. Para que la identidad de la app sea un usuario común, un admin Entra puede ejecutar pgaadauth_create_principal('<nombre>', false, false). Para identidades administradas y service principals el nombre es el display name. El módulo deja el SQL exacto como output.

ACA puede bajar a cero réplicas, pero PostgreSQL Flexible factura cómputo mientras está encendido. Detenerlo corta el cobro de cómputo (no el de storage), pero el servicio lo vuelve a arrancar automáticamente a los 7 días. Para entornos de desarrollo, automatizá el stop en vez de confiar en un stop manual.

El peering entre VNets es una relación no transitiva: dos spokes peereados con el mismo hub no se ven entre sí. Para que el hub los conecte, las subnets de cada spoke necesitan una UDR que apunte al Azure Firewall como gateway por defecto, y los peerings tienen que aceptar tráfico reenviado. Si falta cualquiera de las dos cosas, el tráfico entre spokes no llega o no pasa por el firewall. Cargá la UDR como parte del alta de cada spoke, no como un paso manual aparte.

Cuando el modo appliance no está habilitado, el Transit Gateway mantieneintenta mantener el tráfico en la AZ de origen. Con el modo habilitado, elige una única interfaz de red de la VPC de inspección por flow hash para toda la vida del flujo y usa la misma para el retorno, de modo que el tráfico bidireccional es simétrico. Un firewall stateful necesita ver el pedido y la respuesta. Habilitalo en el attachment de la VPC de inspección (en Terraform, appliance_mode_support = "enable") y conectá un solo Transit Gateway a esa VPC: con varios, AWS no garantiza la persistencia del flujo. Cambiarlo en un attachment existente puede alterar su ruteo actual.

Las rutas de subnet se intercambian siempre (salvo las de subnets con IPv4 públicas de uso privado), pero las rutas dinámicas y las estáticas IPv4 sin network tags con un next hop distinto del internet gateway por defecto no se exportan ni se importan por defecto. Se habilitan con --export-custom-routes en la VPC que las tiene y --import-custom-routes en la que las recibe. Las estáticas con network tags o con el internet gateway por defecto como next hop no se pueden exportar ni importar. UnPara spokedar un camino desde on-premises hacia la VPC peereada, además hay que noconfigurar importaCloud lasRouter rutasen delmodo hubcustom noadvertisement llegacon alos on-premisesrangos porde elsubnet hub.de la VPC peereada.

Los VPC spokes de NCC intercambianpueden exportar e importar todas las rutas de subnet conde los demás spokes delVPC hub.spokes. No se puede usar VPC Network Peering entre dos VPC spokes que yatambién estén conectados por un hub de NCC, y el intercambio de rutas estáticas entre VPC spokes no está soportadosoportado. ySí ense lapuede topologíatener estrellaun VPC spoke de NCC peereado con una VPC separada que no conectaes entreparte síde aNCC, losy spokesusar delpeering edgeentre group.dos ElegíVPC elspokes modelodel antesedge group de crearun lashub VPC,con topología estrella, porque NCC no seconecta puedenentre mezclarsí entrea los mismosspokes spokes.de ese grupo.

Un firewall endpoint es un recurso zonal, y la asociación lo vincula a una VPC en la misma zona. Una VPC puede asociarse a un solo endpoint por zona, sea de organización o de proyecto. Cloud NGFW redirige el tráfico al endpoint solo cuando coincide con una regla de política con la acción apply_security_profile_group. ParaUn cubrirendpoint lasse zonaspuede dondeasociar correna losuna workloads,o creámás unVPC endpointde la misma zona, y si una asociaciónVPC abarca varias zonas se asocia un endpoint por zona; en una zona ysin porendpoint VPC,asociado yno verificáhay inspección de capa 7. Verificá que cada flujo a inspeccionar tenga su regla.

Una VM sin método de salida explícito recibe una IP pública de salida por defecto. Esa IP es propiedad de Microsoft y puede cambiar sin aviso, así que no sirve para un allowlist de terceros. Para la versión de API publicada después del 31 de marzo de 2026, las subnets de las VNets nuevas tienen defaultOutboundAccess en false; las VNets existentes no cambian, y sus VMs nuevas siguen recibiendo la IP por defecto salvo que la subnet se haga privada. Las herramientas que fijan una versión de API anterior (la doc nombra a Terraform) dejan el valor en null, que permite la salida implícita. Declará un método explícito (NAT Gateway) y fijá la subnet como privada de forma explícita; las VMs que ya existen tienen que pasar por stop/deallocate para que el cambio les aplique. SinEn una subnet privada sin salida explícita, Windows Update y la activación de Windows no funcionan.

La página de precios del NAT Gateway cobra horas de recurso y datos procesados (tráfico de salida y de respuesta), y aclara que la tarifa por hora se cobra aunque el NAT Gateway no tenga subnets ni IPs asociadas; además aplican cargos de ancho de banda. Azure Firewall cobra una tarifa fija por hora por deployment, independiente de la escala, más un cargo por GB procesado. Con los dos en el camino corren los dos medidores. Si no necesitás filtrar por destino, el NAT Gateway solo ya da la IP fija sin el firewall.

Para HTTPS Network Firewall usa el SNI del handshake TLS y para HTTP el encabezado Host; no pausa la conexión para hacer consultas DNS ni evalúa las IPs, así que se apoya en lo que declara el cliente. Una lista de dominios no puede acotar por puerto ni por un único protocolo: para eso hacen falta reglas Suricata o stateful de 5-tupla. Por defecto la inspección usa como HOME_NET el CIDR de la VPC donde está el firewall; para filtrar tráfico de otras VPCs (por ejemplo vía transit gateway) hay que definir HOME_NET con esos CIDR. Con la acción Allow el firewall deniega lo que no coincide solo si la política usa default action order; con strict order esa denegación no aplica. Si querés validar además el dominio por el que se resolvió la IP de destino, existe el target AWS_ROUTE_53_RESOLVED_DOMAIN.

Cada IP de NAT ofrece 64.512 puertos de origen TCP. Si no indicás el mínimo de puertos por VM se usa el valor por defecto, 64 con asignación estática y 32 con dinámica, y en Public NAT la asignación por defecto es la estática. Con asignación estática una VM no puede usar más que sus puertos asignados, ni siquiera en picos de tráfico. Además, el gateway procesa hasta 1.024 conexiones simultáneas a cada 3-tupla de destino único. La doc recomienda la asignación dinámica si el uso de egress varía, pero no se puede combinar con endpoint-independent mapping y, mientras se asignan puertos adicionales, puede haber timeouts o latencia. Los paquetes descartados solo se registran sicuando activásusás el logging de erroresCloud deNAT Cloudpara NAT.activar el logging de errores. El módulo habilita asignación dinámica y logging de errores.

Para Public NAT, la página de precios define el costo total como el cargo por hora del gateway más el costo por GiB procesado por el gateway, el costo por hora de las IPs externas que usa y el costo de transferencia de datos saliente. El cargo por hora del gateway depende de la cantidad de VMs que lo usan y tiene un tope en 32 VMs. Al presupuestar, sumá las cuatro partes: con IPs estáticas reservadas para el allowlist, cada IP se cobra por hora. Aparte, la página de precios de Cloud NGFW indica que cuando un flujo se evalúa con una regla que contiene funciones de Cloud NGFW Standard se cobra procesamiento de datos, y presenta los FQDN objects entre esas funciones.

Cloud NGFW resuelve periódicamente cada FQDN object a IPs, siguiendo el orden de resolución de nombres de Cloud DNS de la VPC. No admite comodines (`*`) ni dominios de primer nivel. Cada FQDN object se mapea a un máximo de 32 direcciones IPv4 y 32 IPv6, y las que sobran se descartan. Si la respuesta es NXDOMAIN, no trae IPs utilizables o el servidor DNS no responde, el objeto se ignora. La doc pide evitar registros A con TTL menor a 90 segundos y aclara que la mayoría de los dominios de Google, como googleapis.com, caen en estas situaciones: recomienda usar IPs o address groups. Tampoco se puede usar si la VPC tiene una outbound server policy.policy con un servidor de nombres alternativo. Una consulta DNS puede devolver respuestas distintas según la ubicación del cliente, así que las IPs programadas pueden no incluir todas las del dominio. Usá FQDN para APIs de terceros con DNS estable y verificá el TTL de cada dominio.

La doc de Cloud NAT dice que el tráfico hacia las APIs y servicios de Google se enruta por Private Google Access, incluso cuando la VM usa Public NAT. Esas llamadas no salen con las IPs del NAT, así que un control que dependa de la IP de salida no aplica a esos destinos. No esperes ver la IP del NAT en esas llamadas, y tratáTratá los dominios de Google aparte en las reglas de egress.

Para que la VNet llegue al vault por el Private Endpoint hace falta una zona privada llamada exactamente privatelink.vaultcore.azure.net, enlazada a esa VNet y con el registro A del vault. Si la zona no está enlazada, la consulta devuelve la IP pública. Con el acceso de red público deshabilitado y sin allow-list en el firewall, el servicio rechaza todas las solicitudes en ese ingress, así que el síntoma es un error de acceso y no tráfico público.ingress. Desde on-premises hacen falta forwarders condicionales para vault.azure.net y vaultcore.azure.net hacia un resolver con acceso a la resolución de Azure (ver el patrón DNS privado híbrido). El nombre del vault sigue resolviendo en DNS público aunque sea privado: no pongas entorno ni cliente en el nombre si eso es parte de tu modelo de amenazas.

Treinta días antes de la fecha de expiración de un secreto, Key Vault publica el evento SecretNearExpiry en Event Grid. Para rotar, tenés que crear la suscripción al evento y aportar la función que crea la versión nueva en el vault y actualiza el servicio externo. El tutorial de Microsoft lo muestra para una contraseña de SQL Server. Entre esos dos pasos puede haber un desfase en el que el secreto del vault no autentica, y si un paso falla Event Grid reintenta durante dos horas. El evento depende de que el secreto tenga fecha de expiración. Si el vault es privado, la función tiene que llegar a él: el template del tutorial de dos credenciales pide plan Premium solo cuando el vault está detrás de un firewall.

Key Vault guarda todos los secretos como datos cifrados, con una jerarquía de claves del servicio, y la documentación aclara que ese cifrado es transparente y no requiere acción tuya. Las claves que guardás en Key Vault sirven, por ejemplo, como clave envolvente (BYOK) para cifrar datos de Azure Storage. En AWS, al crear un secreto podés elegir una clave administrada por el cliente de KMS, y en GCP una clave de Cloud KMS (CMEK). Si un requisito de cumplimiento exige controlar la clave del propio almacén de secretos, revisá que Key Vault lo cubra antes de elegirlo; el rol de clave de este patrón es parcial en Azure.

Secrets Manager cobra según la cantidad de secretos guardados y las llamadas a la API. Una réplica cuenta como un secreto distinto y se factura aparte; crear versiones nuevas al rotar no se cobra y un secreto marcado para borrado tampoco. Cada clave de KMS que creás tiene un costo mensual (prorrateado por hora), y el interface endpoint se factura por cada hora que permanece aprovisionado en cada AZ. Usá una subnet por AZ que realmente necesites, un secreto por credencial y réplicas solo si hay un requisito de otra región. Cada GetSecretValue es una llamada facturable: leé el secreto al arrancar o cacheá el valor.

El alias latest apunta a la versión agregada más recientemente. Google lo describe como cómodo para desarrollo pero problemático para algunas cargas de producción, porque un valor malo puede desplegarse de inmediato y causar una caída de todo el servicio. La guía de best practices pide referenciar los secretos por número de versión y desplegar los cambios con tu proceso de release, y deshabilitar una versión antes de destruirla para que el paso sea reversible. Cada rotación agrega una versión y mueve latest:versión: resolvé el número al rotar, guardalo en la configuración del deploy y leelo al arrancar.

AccessSecretVersion requiere un permiso DATA_READ y genera un Data Access audit log. Esos logs están deshabilitados por defecto para todos los servicios salvo algunos de BigQuery, así que hay que habilitarlos explícitamente. Mientras tanto,Las losoperaciones Adminque Activitymodifican logsversiones registran(agregar, losdeshabilitar, cambiosdestruir) sobreson elde secretotipo peroADMIN_WRITE noy quiénvan leyóa elAdmin valor.Activity. La guía de best practices recomienda habilitar los data access logs para analizar los pedidos AccessSecretVersion, y hacerlo a nivel de carpeta u organización para no configurarlo en cada proyecto.

Private Google Access es un setting por subnet: deja que las VMs que solo tienen IP interna lleguen a las IPs externas de las APIs de Google, y no tiene efecto en instancias con IP externa. Si lo deshabilitás, esas VMs pierden el acceso. No soporta los endpoints regionales y multirregionales, los que terminan en rep.googleapis.com. El servicio regional de Secret Manager se accede con un endpoint regional (secretmanager.<location>.rep.googleapis.com en los ejemplos de la documentación) y sus secretos solo se pueden acceder desde esa región. Para esoGoogle hacedocumenta faltacómo unusar endpointendpoints de Private Service Connect haciapara llegar a los endpoints regionales.

Private Endpoints, reglas de VNet y CMK solo existen en Premium, que se cobra por messaging unit por hora aunque no haya mensajes. Standard solo admite reglas de IP. Este patrón usa Standard con autenticación solo Entra ID: si el requisito es red privada, hay que pasar a Premium. En AWS, SQS admite unse interfaceconecta endpointpor sinun cambiarinterface deVPC tier.endpoint.

Private Endpoints, reglas de VNet y CMK solo existen en Premium, que se cobra por messaging unit por hora aunque no haya mensajes. Standard solo admite reglas de IP y además tiene un cargo base mensual.IP. Este patrón usa Standard con autenticación solo Entra ID: si el requisito es red privada, el piso de costo cambiahay deque ordenpasar dea magnitud.Premium. En AWS, SQS admite un interface endpoint sin cambiar de tier.

Antescaling_config.maximum_concurrency limita cuántas instancias concurrentes de la función puede invocar la cola. Es un picosetting del event source mapping, independiente del reserved concurrency de mensajesla Lambdafunción escalay rápidosin cargo, y puedeevita saturarque una cola consuma toda la baseconcurrencia reservada o la APIcuota de destino.la scaling_configcuenta. .maximum_concurrencyOjo: limitael cuántasreserved invocacionesconcurrency concurrentestiene disparaque ser mayor o igual que la cola,suma sinde los efectosmáximos colateralesde deltodos reservedlos concurrencyevent sources de la funciónfunción; (quesi ademásno, Lambda puede provocarhacer throttling yde reintentos).tus mensajes.

Pub/Sub considera procesado el mensaje cuando el endpoint responde 2xx.con Si102, el200, worker201, tarda202 máso que204; elcualquier ackotro deadlinecódigo (máximoes 600un s),nack Pub/Suby loPub/Sub reentregareenvía mientrasel siguemensaje. corriendo.Lo Alineámismo ack_deadline_secondspasa consi el timeout del servicio deworker Cloudtarda Runmás y,que parael trabajosack largos,deadline: usáPub/Sub pulllo oreentrega Cloudmientras Runsigue Jobs.corriendo.

Es el único de losPub/Sub tressoporta serviciosexactly-once deldelivery patrónsolo con exactly-once delivery nativo,suscripciones peropull: push (lo que dispara a Cloud Run) no lo soporta. Con push, igualsoporta, queporque enel Servicecliente Busno ysabe SQSsi Standard,Pub/Sub elrecibió workerla tienerespuesta quey serla idempotente.procesó.

Crear un segundo provider para token.actions.githubusercontent.com en la misma cuenta fallafalla: conIAM EntityAlreadyExists.no permite registrar la misma URL dos veces en una cuenta. Si cada repo trae su propio stack de Terraform con el provider adentro, el segundo apply rompe. Crealo una vez (en el stack de la cuenta) y referencialo con el data source; el módulo lo permite con create_oidc_provider = false.

IAM valida el certificado de GitHub contra su librería de CAs raíz confiables, así que thumbprint_list es opcional y, en el provider de Terraform desde la 5.0Terraform, y,para siIdPs locomo cargás,GitHub se guarda pero no se usa para verificar. Los thumbprints solo entran en juego si el IdP usa un certificado que no firma una de esas CAs, o si AWS no puede obtener el certificado TLS o se requiere TLS v1.3. Muchos módulos viejos todavía hardcodean un thumbprint "que hay que actualizar": para GitHub no es lo que rompe el login.

El principalSet y el workload_identity_provider que le pasás a la action son projects/NÚMERO/locations/global/..., no el ID del proyecto: con el ID el token exchange falla.proyecto. Además, un cambio de IAM suele aplicarse en 2 minutos pero puede tardar 7 o más, así que un pipeline que se acaba de configurar puede fallar en la primera corrida sin que nada esté mal.

Si en una VPC hay una regla FORWARD para corp.example.com y también una private hosted zone corp.example.com, gana la regla. Entre reglas gana la más específica, y con una regla SYSTEM excluís un subdominio del reenvío. En Azure es al revés: la zona privada vinculada se consulta antes que el ruleset.

Cloud DNS no usa IPs de tu VPC para reenviar: toda consulta a un forwarding target sale desde 35.199.192.0/19. El firewall on-premises tiene que permitir UDP y TCP 53 desde ese rango, y on-premises necesita una ruta de vuelta por los túneles VPN o attachments de Interconnect de la misma VPC y región.VPC. Con BGP eso es un anuncio custom del Cloud Router. Sin la ruta, el DNS on-premises recibe la consulta y la respuesta se pierde: parece un timeout.pierde.

Una VPC peereadaNetwork Peering no vecomparte lasautomáticamente zonasla privadasinformación nide lasDNS, forwardingasí zonesque autorizadasuna soloVPC parapeereada no resuelve por sí sola las zonas de la VPC hub. En hub-and-spoke, cada spoke necesita una DNS peering zone hacia el hub, y el DNS peering transitivo llega a un solo salto. Es la diferencia con Azure, donde un ruleset se linkea a VNets que ni siquiera están peereadas.

Crear el Private Endpoint no alcanza: el FQDN <cuenta>.blob.core.windows.net tiene que resolver a la IP privada vía la zona privatelink.blob.core.windows.net vinculada a la VNet (o a tu DNS híbrido). Si resuelve a la IP pública, conel accesofirewall públicodel deshabilitadoservicio rechaza la request falla con 403 y parece un problema de permisos.

S3 encola las expiraciones y puede tardar días en borrarlas físicamente.procesa Ade diferenciaforma deasincrónica: Azure,puede nopasar pagásdesde storagedías dehasta unsemanas objetoentre vencidola aunquefecha todavíade aparezcaexpiración eny el listado. Igualborrado quereal. enNo lasse otrascobra nubes:la noexpiración esni unel controltiempo de seguridad, el objeto siguestorage siendode legibleun hastaobjeto que seya borra.venció.

LasS3 retiene las partes de un multipart upload hasta que nuncalo secompletás completóo ocupanlo storageabortás, y nose aparecencobra alsu listarstorage objetos.durante todo ese tiempo. Agregá siempre una regla AbortIncompleteMultipartUpload; en un bucket deAbortIncompleteMultipartUpload: ingestaabortar esel dondeupload másborra selas acumulan.partes.

Private Google Access solo permite que VMs sin IP pública lleguen a las APIs de Google. El bucket sigue aceptando requests autenticadas desde internet. Para restringir el origen necesitás bucket IP filtering o VPC Service Controls; este último es a nivel organización y suele no estar al alcance de un equipo de aplicación.Controls.

ACA puede bajar a cero réplicas, pero PostgreSQL Flexible factura cómputo mientras está encendido. Detenerlo corta el cobro de cómputo (no el de storage), pero el servicio lo vuelve a arrancar automáticamente a los 7 días. Para entornos de desarrollo, automatizá el stop en vez de confiar en un stop manual.

Para bajar la imagen y mandar logs sin salida a internet, la tarea necesita interface endpoints de ECR (api y dkr) y CloudWatch Logs, más el gateway endpoint de S3 (donde ECR guarda las capas). Cada interface endpoint se cobra por hora por AZ: es el costo fijo que en ACA y Cloud Run no existe.AZ. La alternativa (NAT Gateway) también tiene cargo por hora y por GB.

Private services access se implementa con VPC Network Peering hacia la red de Google. OtraSolo VPCpermite peereadaconexiones condesde launa tuyaVPC, noy llegael apeering lano base,ofrece yruteo paratransitivo: on-premisesotra tenésVPC quepeereada exportarcon customla routestuya enno elllega peering.a la base. Si tu topología es hub-and-spoke, evaluá Private Service Connect en lugar de PSA.

KEDA consulta el largo de la cola por su cuenta. SiPara elque namespacelo tienehaga localcon authidentidad deshabilitada,administrada, la regla de escalado tiene que usarusa la identidad administradapropiedad (identity_ididentity en la regla); con un connection stringlugar node funciona.auth. El portal no permite configurarlo: hacelo por IaC o CLI.

Contributor no tienepermite Microsoft.Authorization/roleAssignments/write.asignar roles en Azure RBAC (excluye Microsoft.Authorization/*/Write). Si tu Terraform asigna roles (por ejemplo, la identidad de una app sobre un Key Vault), el apply fallaContributor conno AuthorizationFailed.alcanza. La salida rápida es darle Owner o User Access Administrator al pipeline, y es justo lo que no querés. La salida correcta es Role Based Access Control Administrator con una condición que limite qué roles puede asignar (y que excluya los roles privilegiados).

GitHub armaincluye el environment en el sub concuando prioridad:el environment,job despuéslo referencia; pull_request y reciénla despuésref lasolo ref.entran si el job no referencia un environment. Un job en main con environment production presenta repo:org/repo:environment:production, así que una trust policy que espera repo:org/repo:ref:refs/heads/main rechaza el AssumeRoleWithWebIdentity. Pasa lo mismo en Azure y GCP; acá el error es "Not authorized to perform sts:AssumeRoleWithWebIdentity".

En S3 acotás la policy a arn:...:bucket/incoming/* y en GCP usás IAM Conditions por prefijo. En Azure un role assignment llega como mínimo al contenedor; para acotar por ruta necesitás condiciones ABAC sobre el role assignment. Alternativa simple: un contenedor dedicado a la ingesta (lo que hace este módulo).

Desde abril de 2023 losS3 bucketshabilita nuevosBlock sePublic creanAccess cony Blockdeshabilita Publiclas AccessACLs activoen ytodos Objectlos buckets nuevos (Object Ownership en BucketOwnerEnforced.BucketOwnerEnforced). Ya no es "la" diferencia con Azure. Igual declaralos en IaC: los buckets viejosexistentes no cambiaron, y declarar el estado evita drift si alguien los toca desde la consola.

Terraform/ARM agrega principals Entra como administradores (azure_pg_admin, CREATEROLE, CREATEDB). Para que la identidad de la app tengasea permisosun mínimos,usuario común, un admin Entra tiene quepuede ejecutar pgaadauth_create_principal('<nombre>', false, false) y después los GRANT.false). Para identidades administradas y service principals el nombre es el display name. El módulo deja el SQL exacto como output.

ElPara crear un listener HTTPS requierehay que desplegar al menos un certificado ende ACM.servidor UnSSL certificado(de públicoACM o de IAM). ACM seexige validaprobar contrala DNSpropiedad odel maildominio de un dominio real aunquecertificado elpúblico ALBpor seaDNS, interno;mail lao alternativaHTTP, esy AWSno Privatepuede CA,validar querecursos tieneen cargouna mensual.private Enhosted ACAzone yde CloudVPC Runni elen certificadoningún delotro dominio porprivado, defectoaunque loel gestionaALB lasea plataforma.interno.

Con manage_master_user_password = true, RDS genera la contraseña del master y la guarda en Secrets Manager: nunca pasa por variables ni porManager. elEl estadoprovider de Terraform. Es incompatibleTerraform conno pasarpermite passwordcombinarlo acon mano,password, y RDS no estálo soportadosoporta en algunos escenarios (por ejemplo Blue/Green deployments), así que decidilo de entrada.

Con ingress internal, Cloud Run rechaza requests que no vengan de VPCs del mismo proyecto (o perímetro de VPC SC) o de otros servicios de Google, aun usando la URL run.app. Pero además,la porautenticación defaultIAM exigesigue run.routes.invoke:aplicando: el cliente tiene que mandarpresentar un ID token de una identidad con roles/run.invoker. En ACA y en el ALB interno la red es el único control salvo quesu agreguescuenta authde enservicio lanecesita app.roles/run.invoker.

El resolver de la VPC (base del CIDR + 2) contesta a los recursos de la VPC. AWS indica que reenviarle consultas desde on-premises u otros DNS no está soportado y puede dar resultados inestables, aunque a veces parezca funcionar. Para eso existe el inbound endpoint, igual que el de Azure o la inbound policy de GCP.