DEV Community: Diana Castro

Diario de una builder: El camino hacia la orquestación de dos mundos

Diana Castro — Mon, 18 May 2026 00:38:32 +0000

Aprender una segunda nube sin empezar desde cero

En tecnología hay una verdad incómoda, pero también liberadora: nunca terminamos de dominar completamente un tema. Lo que sabías ayer puede quedar obsoleto mañana y, en el mundo de las nubes públicas, donde los servicios evolucionan constantemente, es prácticamente imposible conocer cada detalle de cada herramienta.

Más que aspirar a saberlo todo, el verdadero enfoque está en comprender los fundamentos y especializarse en ciertos dominios. Se trata de reconocer qué servicios existen, para qué fueron diseñados y en qué escenarios aportan valor. Así, cuando enfrentas un problema real, no partes desde cero: sabes qué buscar y dónde apoyarte.

El reto de aprender otra nube

Más que dominar una nube en su totalidad, el enfoque real está en el aprendizaje continuo y en desarrollar criterio técnico para entender cómo funcionan los servicios y cuándo utilizarlos.

Y por esas oportunidades que da la vida —que se agradecen enormemente— terminé frente a un nuevo desafío: aprender una segunda nube.

Un reto que impone respeto.

Que incluso puede generar cierta incertidumbre.

Pero que también expande la forma en que pensamos la arquitectura.

La pregunta entonces fue:

¿Cómo abordar este reto sin empezar completamente desde cero?

La respuesta estuvo en reutilizar el conocimiento base.

En lugar de aprender desde una hoja en blanco, comencé a buscar patrones, equivalencias y analogías:

Este servicio se parece a este otro.
Esta solución resuelve un problema similar en otra nube.
Este concepto cambia de nombre, pero no necesariamente de propósito.

Y sí, ese enfoque funciona… hasta que deja de funcionar.

Cuando las equivalencias dejan de ser suficientes

El primer impulso al aprender una segunda nube es buscar traducciones directas entre servicios. Algo natural. Necesitamos referencias conocidas para orientarnos.

Pero eventualmente llegan las diferencias importantes.

Descubres que:

Los Region Pairs en Azure abordan Disaster Recovery de una forma distinta.
El modelo de identidad no se mapea 1:1 con AWS.
Las suposiciones sobre failover automático pueden estar completamente invertidas.
La organización de recursos responde a filosofías diferentes.
Incluso la forma de operar y navegar la plataforma cambia.

Y ahí ocurre algo interesante: dejas de intentar traducir una nube hacia la otra y comienzas a entender cómo piensa cada proveedor.

Ese suele ser el punto donde realmente empieza el aprendizaje.

El modelo de responsabilidad compartida

(AWS Shared Responsibility Model & Azure Shared Responsibility Model)

El modelo de responsabilidad compartida es conceptualmente el mismo en AWS y Azure: el proveedor asegura la infraestructura de la nube, mientras que el cliente es responsable de la configuración, los datos y el acceso.

Sin embargo, aunque el principio es equivalente, su implementación varía según el nivel de abstracción del servicio y la filosofía de cada proveedor.

A simple vista puede parecer un concepto sencillo… hasta que llegas a los detalles.

Los valores por defecto, las configuraciones iniciales y la forma en que cada nube aplica sus controles no son idénticos. Y, como suele ocurrir en tecnología, el diablo está en los detalles.

Podemos pensar en la clásica analogía de la casa:

El proveedor construye la estructura.
Garantiza que la infraestructura sea segura.
Pero tú decides quién entra, qué permisos tiene y cómo proteges lo que guardas dentro.

El problema es que no todas las casas vienen configuradas igual.

Algunas plataformas habilitan más controles desde el inicio.

Otras requieren que el cliente los defina explícitamente.

Y ahí es donde se vuelve evidente que, aunque el modelo sea el mismo en teoría, la implementación cambia significativamente en la práctica.

Porque en multi-cloud no basta con entender qué eres responsable de proteger.

También necesitas entender:

cómo cada proveedor interpreta esa responsabilidad,
qué controles vienen habilitados por defecto,
qué configuraciones requieren intervención manual,
y qué supuestos de seguridad estás heredando sin darte cuenta.

Ese suele ser uno de los primeros momentos donde descubres que aprender una segunda nube no es memorizar servicios… sino ajustar la manera en que piensas la seguridad.

Estructura de la nube

Sería un error intentar definir equivalencias entre servicios sin comprender primero cómo está organizada cada nube. Antes de hablar de servicios, redes o seguridad, necesitamos entender la base sobre la que todo está construido.

Porque aunque AWS y Azure comparten muchos conceptos, la forma en que estructuran su infraestructura refleja filosofías bastante distintas.

Este recorrido no busca ser exhaustivo.

La idea es construir un mapa mental rápido que ayude a entender dónde empiezan las similitudes… y dónde aparecen las diferencias importantes.

Organización global

A nivel global, Azure y AWS adoptan estrategias diferentes para organizar y aislar su infraestructura.

En Azure, la organización global se basa en Geographies, que agrupan múltiples regiones dentro de un mismo límite orientado principalmente a:

cumplimiento normativo,
residencia de datos,
y latencia.

Estas geografías forman parte de un entorno altamente interconectado donde los servicios, la identidad y la gobernanza se gestionan de forma relativamente unificada.

AWS, en cambio, estructura su organización global mediante Partitions, que representan límites de aislamiento mucho más marcados tanto a nivel técnico como regulatorio.

Cada partición funciona prácticamente como un entorno independiente:

servicios separados,
endpoints distintos,
controles propios,
e incluso aislamiento de IAM.

Ese enfoque hace que AWS priorice mucho más el desacoplamiento entre entornos globales.

Regiones y Zonas de Disponibilidad

En este nivel, la organización entre AWS y Azure se vuelve mucho más comparable, aunque siguen existiendo diferencias importantes.

Ambos proveedores operan con regiones distribuidas globalmente, cada una compuesta por múltiples Availability Zones (AZs) diseñadas para ofrecer alta disponibilidad y resiliencia.

Sin embargo, la implementación cambia bastante.

Una de las diferencias más relevantes es que Azure trabaja con el concepto de Region Pairs, donde cada región tiene una contraparte definida para escenarios de recuperación ante desastres.

Esto permite que Microsoft:

coordine actualizaciones,
priorice recuperación,
y mantenga estrategias de continuidad más estructuradas.

En AWS no existe un equivalente automático.

Las estrategias multi-región deben diseñarse explícitamente por el arquitecto.

Eso entrega más flexibilidad, pero también más responsabilidad.

A nivel de AZs también existen diferencias relevantes.

AWS mantiene una cobertura bastante consistente: la mayoría de regiones cuentan con entre 2 y 6 zonas de disponibilidad.

En Azure, aunque muchas regiones modernas sí disponen de múltiples AZs, no todas las regiones ofrecen soporte completo de Availability Zones, algo que puede afectar decisiones de arquitectura dependiendo de la ubicación elegida.

Datacenters y extensiones de baja latencia

En el nivel más bajo de infraestructura, ambos proveedores operan sobre datacenters físicos.

Tanto en Azure como en AWS, estos datacenters forman parte de una abstracción superior: las Availability Zones, que agrupan múltiples instalaciones físicas para reducir puntos únicos de fallo.

En Azure, aunque el datacenter no se expone directamente como recurso, existen conceptos importantes como: Fault Domains, Update Domains

Estos permiten distribuir máquinas virtuales minimizando el impacto de fallos físicos o mantenimientos programados.

AWS no expone exactamente la misma granularidad.

En su lugar, utiliza mecanismos como:Placement Groups, distribución entre AZs y diseño de resiliencia a nivel regional.

Local Zones y edge computing

Más allá del datacenter tradicional, ambos proveedores han extendido su infraestructura hacia ubicaciones más cercanas al usuario final para reducir latencia.

En AWS, esto se materializa mediante Local Zones, que extienden una región hacia áreas metropolitanas específicas permitiendo ejecutar cargas con latencias extremadamente bajas sin desplegar una región completa.

Azure ofrece iniciativas similares como: Azure Local Zones, Azure Stack Edge. Aunque actualmente su disponibilidad es más limitada y el enfoque suele combinar baja latencia con integración híbrida.

Resumen comparativo

Concepto	Azure	AWS
Nivel 1: Global	Geography (`US`, `Europe`, `Asia Pacific`) • Agrupa múltiples regiones • Define residencia de datos • Boundary de compliance • Entorno unificado	Partition (`aws`, `aws-cn`, `aws-us-gov`) • Agrupa múltiples regiones • Aislamiento completo de IAM, servicios y endpoints • Boundary legal y regulatorio • Entornos independientes
Nivel 2: Regional	Region (`East US`, `West Europe`) • Múltiples regiones globales • Cada región puede tener múltiples AZs • Region Pairs definidos • Updates coordinados • Priorización de recuperación	Region (`us-east-1`, `eu-west-1`) • Múltiples regiones globales • Cada región tiene múltiples AZs • No existe emparejamiento automático • Estrategia multi-región definida por el arquitecto
Nivel 3: Availability Zones	Availability Zone (AZ) • 3 o más AZs en regiones compatibles • Datacenters físicamente separados • Baja latencia entre AZs • No todas las regiones tienen AZs	Availability Zone (AZ) • La mayoría de regiones tienen múltiples AZs • Datacenters físicamente separados • Baja latencia entre AZs • Cobertura más consistente
Nivel 4: Datacenter	Datacenter (no expuesto al usuario) • Múltiples datacenters por AZ • Fault Domains • Update Domains • Abstracción gestionada por plataforma	Datacenter (no expuesto al usuario) • Múltiples datacenters por AZ • Placement Groups • Distribución gestionada por arquitectura • Sin equivalente directo a Update Domains
Extensiones locales	Azure Local Zones / Azure Stack Edge • Baja latencia • Escenarios híbridos • Disponibilidad más limitada	Local Zones / Wavelength Zones • Extensión metropolitana de regiones • Latencia ultra baja • Integración 5G y edge computing

💡 Pro Tip

Las similitudes entre AWS y Azure facilitan el aprendizaje, pero las diferencias en su implementación son las que realmente definen una buena arquitectura.

Diseñar correctamente implica adaptar patrones, no traducirlos literalmente.

Cómo se organizan las nubes

Uno de mis primeros choques mentales en el proceso multi nube fue entender que AWS y Azure no organizan sus recursos de la misma manera. Parece un detalle administrativo sin demasiada importancia… hasta que empiezan las conversaciones sobre ambientes, permisos, facturación, gobernanza o separación de cargas. Ahí uno entiende rápidamente que la estructura organizacional de cada nube impacta muchísimo más de lo que imaginaba al inicio.

De hecho, probablemente este ha sido uno de los temas más difíciles tanto de entender como de explicar cuando converso con colegas que vienen principalmente de trabajar con una sola nube.

En AWS, el modelo mental gira alrededor de la cuenta. Desde mi punto de vista, ahí es donde normalmente se establece la primera gran separación organizacional. Por ejemplo, si alguien plantea:

“quiero separar ambientes”

La respuesta natural suele ser crear cuentas distintas para producción, desarrollo, seguridad o logging, algo muy alineado con las buenas prácticas de AWS.

Sobre esas cuentas se construyen estructuras organizacionales mediante Amazon Web Services Organizations, que permiten agruparlas con fines administrativos y de control. A partir de ahí aparecen conceptos como Organizational Units (OU), Service Control Policies (SCP) e identidades centralizadas que ayudan a establecer reglas comunes entre múltiples cuentas.

En Azure, el enfoque se siente mucho más jerárquico e integrado desde el inicio. El modelo normalmente se entiende así:

Tenant → Subscription → Resource Group → Resource

Cada nivel cumple un propósito distinto relacionado con organización, facturación, permisos y administración. La suscripción no representa el mismo nivel de separación operativa que una cuenta AWS; muchas veces funciona más como un contenedor administrativo dentro de una jerarquía mayor controlada por el tenant.

Desde mi perspectiva, AWS prioriza más explícitamente la separación mediante cuentas, mientras Azure aborda la organización desde una jerarquía profundamente integrada al modelo operativo de la plataforma. Y ojo, eso no significa que AWS no tenga jerarquías o estructuras organizacionales; simplemente la cuenta suele convertirse en el elemento principal alrededor del cual se diseñan muchas decisiones arquitectónicas.

Veamos con más detalle cada elemento desde la perspectiva de cada proveedor.

Enfoque de Azure

Tenant

Es el nivel más alto. Representa la organización completa en Azure y está asociado a una instancia de Microsoft Entra ID (anteriormente Azure Active Directory). Cuando una empresa contrata Azure, se crea un tenant. Todo lo demás vive dentro de él.

Management Group

Es opcional, pero muy útil en organizaciones grandes. Permite agrupar suscripciones para aplicar políticas y permisos de forma centralizada.

Por ejemplo, puedes tener un Management Group para todas las suscripciones de producción y otro para desarrollo, aplicando reglas distintas sin tener que configurar cada suscripción individualmente. También podrías tener un Management Group que agrupe todas las suscripciones de la organización únicamente para gobierno y cumplimiento.

Subscription

Es el contenedor administrativo y financiero principal. Todo recurso que se crea en Azure vive dentro de una suscripción. También es donde se aplican cuotas y donde se consolida la facturación.

Muchas organizaciones usan suscripciones separadas para producción, desarrollo o unidades de negocio, más por administración y control financiero que por separación técnica entre entornos.

Un detalle importante —y fuente frecuente de confusión— es que, aunque la suscripción sea un contenedor administrativo, no puedes mezclar recursos de distintas suscripciones dentro del mismo Resource Group.

Resource Group

Es un contenedor lógico dentro de una suscripción que agrupa recursos relacionados con una carga de trabajo: App Services, bases de datos, Cosmos DB, redes, etc.

Mientras los recursos pertenezcan al mismo scope administrativo, pueden agruparse dentro de un Resource Group. Además de organizar recursos, permite aplicar permisos mediante RBAC y gestionar el ciclo de vida completo de una solución: si eliminas el Resource Group, eliminas todo lo que contiene.

Personalmente, este es uno de los elementos que más me ayudó durante mi proceso de adopción de Azure.

Resource

Es el recurso concreto: una VM, un Storage Account, un NAT Gateway o una base de datos. Representa la unidad mínima de infraestructura o servicio dentro de Azure.

Enfoque AWS

Root Account

Es la cuenta inicial que se crea cuando una organización comienza a utilizar AWS. Tiene acceso total e irrestricto a todos los recursos y servicios.

La recomendación general es no usarla para trabajo diario, protegerla con MFA y reservarla únicamente para tareas administrativas muy específicas.

AWS Organizations

Es la estructura que permite gobernar múltiples cuentas AWS desde un punto centralizado. Se habilita desde la Root Account, que pasa a convertirse en la Management Account de la organización.

Desde ahí pueden crearse cuentas hijas, agruparlas y aplicar políticas comunes.

Organizational Unit (OU)

Es un contenedor dentro de AWS Organizations que agrupa cuentas con un propósito común.

Por ejemplo, puedes tener una OU para producción, otra para desarrollo y otra para seguridad, incluyendo los niveles de anidación que necesites.

Las políticas aplicadas a una OU se heredan a todas las cuentas contenidas dentro de ella, permitiendo gobernar a escala sin configurar cada cuenta individualmente.

Service Control Policy (SCP)

Es un mecanismo de control aplicado sobre OUs o cuentas.

Define el máximo nivel de acciones permitidas dentro de una cuenta. Aunque un usuario tenga permisos amplios mediante IAM, si una SCP restringe una acción, la restricción prevalece.

Las SCP no otorgan permisos por sí mismas; únicamente establecen límites.

Cuenta AWS

Es probablemente la unidad organizacional más importante dentro del modelo AWS.

Cada cuenta posee sus propios recursos, redes, facturación y límites de servicio. El acceso entre cuentas no ocurre automáticamente; normalmente requiere configuraciones explícitas mediante IAM, networking o servicios compartidos.

Es el equivalente conceptual más cercano a una Subscription de Azure, aunque con una separación operativa mucho más marcada desde el diseño de la plataforma.

Equivalencias conceptuales

Nivel Azure	Equivalente conceptual AWS	Nota clave
Tenant	AWS Organizations / Root Context	En Azure todo vive dentro de un tenant asociado a Entra ID; en AWS el contexto organizacional suele construirse alrededor de Organizations y la cuenta raíz
Management Group	Organizational Unit (OU)	Ambos permiten agrupar contenedores hijos para aplicar políticas y gobernanza centralizada
Subscription	Cuenta AWS	Ambos funcionan como contenedores administrativos y financieros, aunque la cuenta AWS suele representar una separación operativa más marcada
Resource Group	No existe equivalente directo	AWS utiliza tags, stacks y convenciones organizacionales para agrupar recursos, pero no existe un contenedor con el mismo peso operativo y ciclo de vida que un Resource Group
Resource	Resource	La unidad mínima consumible de infraestructura o servicio en ambas nubes

Y esto nos lleva al tema de facturación, que también refleja bastante la filosofía de organización de cada nube.

En Azure, la suscripción tiene un peso administrativo y financiero muy importante; muchas estrategias de gobernanza, límites y control de costos se construyen alrededor de ella.

En AWS, aunque la cuenta sigue siendo un elemento financiero clave, la granularidad del análisis de costos suele apoyarse muchísimo más en estrategias de tagging y consolidación mediante AWS Organizations.

Mi impresión personal es que Azure incentiva más una segmentación jerárquica desde la propia estructura organizacional, mientras AWS favorece una separación basada en cuentas complementada con modelos detallados de etiquetado para gobierno financiero y operacional.

Veamos un ejemplo práctico

Imaginemos una organización dedicada a investigación y desarrollo que está iniciando su adopción cloud y necesita construir una estructura ordenada, segura y escalable tanto en AWS como en Azure.

La organización quiere separar claramente sus ambientes de:

Desarrollo
Pruebas
Preproducción
Producción

Además, busca implementar controles bien definidos para:

permisos y accesos
facturación y control de costos
gobernanza
cumplimiento
networking compartido
servicios de seguridad centralizados

A simple vista, el objetivo parece idéntico en ambas nubes: organizar recursos, separar ambientes y aplicar políticas. Sin embargo, cuando empezamos a diseñar la estructura, rápidamente aparecen diferencias importantes en la filosofía organizacional de cada proveedor.

En AWS, el diseño suele inclinarse hacia una separación por cuentas, donde cada ambiente vive en una cuenta independiente administrada mediante AWS Organizations y Organizational Units (OU).

En Azure, el enfoque normalmente se construye alrededor de una jerarquía organizacional basada en:

Tenant → Management Groups → Subscriptions → Resource Groups

donde la gobernanza y la administración se integran profundamente dentro de la estructura jerárquica de la plataforma.

El siguiente diagrama muestra cómo podría modelarse este mismo escenario en ambas nubes y ayuda a visualizar por qué, aunque los objetivos sean similares, la forma de pensar y organizar la infraestructura cambia considerablemente entre AWS y Azure.}

Identidad: donde todo inicia

Puedes replicar infraestructura entre nubes, pero si no entiendes cómo funciona la identidad, no puedes gobernarlas. Y esta es, quizá, una de las particularidades más complejas cuando estás transitando entre dos mundos.

En lo personal, este tema me costó un poco. Ambos entornos resuelven la misma necesidad de formas similares, pero —y aquí está el punto clave— similar no es lo mismo.

Mi mayor confusión venía de esto:

AWS te da control fino desde el inicio, mientras que Azure te ofrece una capa de abstracción inicial y luego te permite profundizar.

Analicémoslo con más detalle.

AWS: identidad y permisos en un mismo sistema

En AWS, la identidad y los permisos se definen dentro de un mismo sistema: AWS Identity and Access Management (IAM).

Aquí tienes control granular a través de políticas, donde defines exactamente qué puede hacer cada identidad sobre cada recurso.

Yo lo veo así:

Usuarios / Grupos / Roles
Policies (JSON)
Permisos a servicios y recursos

Las asignaciones son altamente granulares.

Ese control fino permite aplicar el principio de mínimo privilegio desde el inicio, aunque puede resultar más complejo y, en ocasiones, un poco árido al principio.

Azure: identidad y autorización como capas separadas

En Azure, en cambio, el modelo se separa en dos capas bien definidas.

Por un lado está la identidad, gestionada en Microsoft Entra ID:

Usuarios
Grupos
Aplicaciones / Service Principals

Aquí es donde defines quién eres.

Por otro lado está la autorización, gestionada mediante Azure Role-Based Access Control (RBAC):

Roles: Owner, Contributor, Reader (y muchos más)

Asignaciones a nivel de:
- Subscription
- Resource Group
- Recurso específico

Aquí es donde defines qué puede hacer esa identidad.

La diferencia importante

Esta separación es clave para entender Azure.

Mientras en AWS todo vive en un mismo sistema, en Azure debes pensar en dos dimensiones:

identidad
permisos

Y aunque ambos modelos terminan resolviendo el mismo problema, la forma en que llegas ahí cambia bastante entre plataformas.

Cómo se comunican los recursos - Networking

Y aquí es donde realmente empiezan las diferencias filosóficas fuertes entre ambas nubes. Y siendo muy honesta, el networking no es mi fuerte. AWS y Azure se parecen bastante superficialmente, pero me parece que el diseño mental cambia un poco, por lo que les compartiré mi “Piedra Roseta” para tratar de hacer más fácil el proceso de adaptación a otra nube y algunas reflexiones sobre los elementos de networking más destacables.

VPC vs VNet

Conceptualmente, ambos servicios cumplen el mismo objetivo: crear redes privadas lógicas dentro de la nube para aislar y conectar recursos de forma segura.

Tanto AWS como Azure permiten:

definir CIDR,
segmentar mediante subnets,
controlar tráfico,
conectar entornos on-premises,
e incluso otras nubes.

Hasta aquí, pareciera que hablamos exactamente de lo mismo. Pero nuevamente, el modelo puede parecer similar mientras la filosofía detrás del diseño cambia bastante.

En AWS, la VPC se siente muy explícita en el aislamiento. El arquitecto define de forma muy consciente cómo se segmenta la red, cómo se enruta el tráfico y qué componentes permiten la salida o entrada hacia Internet. Soy de software, eso siempre me ha costado.

Muchos elementos deben declararse explícitamente:

Internet Gateways
Route Tables
NAT Gateways
asociaciones de subnets

Desde el inicio hay mucho control y consciencia de lo que es permitido y no, y por supuesto muchos dolores de cabeza cuando no le puedes llegar a un recurso.

En Azure, la VNet se percibe más integrada al ecosistema general de la suscripción y la región. El modelo suele sentirse más abstraído y conectado al diseño operativo de Azure.

Aunque también existen tablas de ruteo, gateways y segmentación, varios comportamientos vienen más integrados dentro del modelo de la plataforma.

Uno de los detalles más importantes es la relación entre subnets y zonas de disponibilidad.

En AWS, una subnet pertenece a una Availability Zone específica.
En Azure, las subnets viven a nivel regional y los recursos son los que posteriormente se distribuyen entre zonas cuando el servicio lo soporta.

Es un pequeño detalle que cambia bastante la forma de pensar en términos de resiliencia y diseño de red.

Al momento de escribir este artículo una región solo tenía una AZ.

NSG vs Security Groups ¿qué tan parecidos?

Al inicio, los Network Security Groups (NSG) de Azure y los Security Groups de AWS parecen prácticamente lo mismo, pero no hay que dejarse engañar. Al principio es solo ese falso sentimiento de:

“esto lo conozco”.

Ambos permiten controlar tráfico de entrada y salida hacia recursos dentro de la red. Sin embargo, conforme se profundiza, aparecen diferencias importantes en filosofía y funcionamiento.

En AWS, los Security Groups son stateful y se enfocan principalmente en proteger workloads o interfaces de red específicas como:

Funcionan únicamente mediante reglas ALLOW; si el tráfico no está explícitamente permitido, se deniega implícitamente.

No existen reglas DENY.

AWS además separa otro componente llamado Network ACL (NACL), que funciona a nivel subnet.

Los NACL son:

stateless,
permiten reglas ALLOW,
permiten reglas DENY.

Esto crea una separación bastante clara entre controles a nivel subnet y controles a nivel workload.

En Azure, los NSG consolidan parte de ambos conceptos.

También son stateful, pero pueden aplicarse tanto a:

subnets,
como directamente a NICs.

A diferencia de los Security Groups de AWS, los NSG sí soportan reglas DENY explícitas.

Ese pequeño detalle cambia bastante el enfoque mental.

AWS separa más explícitamente las capas de seguridad de red.
Azure tiende a integrar más funcionalidades dentro de un mismo componente.

Pro Tip

Mientras en AWS se trabajan capas de control separadas — NACL para subnet y Security Groups a nivel de servicios — Azure consolida el modelo en NSG.

Esto permite entrever la diferencia filosófica de que AWS tiende a separar componentes mientras que Azure consolida funcionalidades.

Tal y como les prometí: mi “Piedra Rosetta”

Azure VNet	AWS VPC	Diferencias Clave
Red virtual privada regional	Red virtual privada regional	Azure integra la VNet más visiblemente dentro del modelo de suscripción y Resource Groups, mientras AWS trata la VPC como un boundary de aislamiento más explícito y desacoplado
Subnets regionales	Subnets asociadas a una AZ específica	En Azure las subnets pertenecen a la VNet regional; en AWS cada subnet vive dentro de una Availability Zone específica
NSG aplicable a subnet o NIC	Security Groups aplicados a interfaces/instancias	Azure permite aplicar controles tanto a nivel subnet como NIC y permite Allows y Deny; en AWS los Security Groups se enfocan principalmente en interfaces y workloads, solo permiten Allows y el concepto NACL no existe aislado en Azure
User Defined Routes (UDR)	Route Tables	Azure maneja el routing de forma más integrada dentro de la plataforma; en AWS las asociaciones entre subnets y Route Tables suelen ser más explícitas
VPN Gateway	Site to Site VPN	Ambos servicios permiten conectar redes on-premises con la nube mediante túneles IPsec, soportando escenarios híbridos y routing dinámico con BGP. Sin embargo, Azure expone de forma más explícita conceptos tradicionales de networking como tipos de VPN (route-based y policy-based), SKUs, configuraciones active-active y opciones avanzadas desde el proceso inicial de despliegue. En AWS, aunque estas capacidades también existen, el servicio administrado abstrae más parte de la complejidad operativa y el flujo suele sentirse más guiado desde la experiencia de implementación
ExpressRoute	Direct Connect	Tanto Azure ExpressRoute como AWS Direct Connect suelen requerir la participación de carriers o partners especializados para establecer la conectividad física. Ambos servicios buscan reducir la dependencia de Internet pública y ofrecer conexiones más estables y predecibles. Sin embargo, históricamente ExpressRoute ha tenido una orientación más integrada hacia el ecosistema Microsoft mediante distintos modelos de peering que permiten conectividad privada no solo hacia VNets, sino también hacia servicios Microsoft y plataformas SaaS asociadas. Direct Connect, por su parte, suele percibirse más enfocado en conectividad dedicada hacia VPCs, redes y workloads específicos dentro de AWS
Service Endpoints / Private Endpoints	VPC Endpoints	Azure diferencia dos enfoques explícitos: Service Endpoints restringen el acceso al servicio a VNets autorizadas sin crear interfaces de red adicionales, mientras que Private Endpoints asignan una IP privada dentro de la VNet y permiten resolución mediante DNS privado, posibilitando además deshabilitar opcionalmente el acceso público al servicio. AWS agrupa estos patrones bajo el concepto de VPC Endpoints, diferenciando internamente entre Gateway Endpoints — integrados mediante route tables y limitados principalmente a S3 y DynamoDB — e Interface Endpoints, que crean una ENI con IP privada y permiten conectividad privada hacia una amplia variedad de servicios AWS y servicios compatibles con PrivateLink, incluso en escenarios híbridos mediante VPN o Direct Connect
NAT Gateway	NAT Gateway	Ambas nubes usan NAT Gateway para que recursos en subnets privadas accedan a internet sin exponer su IP directamente. En Azure basta con asociarlo a la subnet sin tocar route tables. En AWS el proceso es más explícito: requiere un Internet Gateway, una subnet pública donde reside el NAT Gateway, y una entrada manual en la route table de cada subnet privada — lo que da más control pero también más superficie de error, especialmente en arquitecturas multi-zona
Public IP	Elastic IP	Azure trata la IP pública como un recurso independiente que puede asociarse a componentes como NICs, Load Balancers o NAT Gateways. Aunque la IP existe como recurso separado, operativamente suele crearse y administrarse en conjunto con el servicio asociado. Para conservarla basta con utilizar asignación estática y desasociarla sin eliminar el recurso, permitiendo reutilizarla posteriormente. AWS el modelo mental es algo distinto: utiliza Elastic IPs como mecanismo principal para direcciones públicas persistentes. Estas se reservan explícitamente dentro de la cuenta y pueden asociarse o moverse entre instancias y servicios de manera independiente. Ambas nubes cobran por IPs públicas estáticas no asociadas; la diferencia es que AWS hace de la reasignación explícita parte natural del modelo operativo, mientras que Azure suele integrar más la administración de la IP al ciclo de vida del recurso que la consume

Interactuando con la nube

No podía cerrar esta primera parte sin hablar de algo que también cambia muchísimo entre proveedores: la forma en que interactuamos con la nube día a día.

Ambas plataformas cuentan con:

consola web,
APIs,
SDKs,
Infrastructure as Code,
y CLI.

Sin embargo, nuevamente la filosofía detrás del diseño se siente bastante distinta.

A nivel de consola, en Azure Resource Manager (ARM) funciona como una capa unificada de administración para despliegues, permisos, políticas y organización de recursos. Esa integración hace que muchas operaciones se perciban más centralizadas y coherentes con la estructura jerárquica previamente resaltada.

En AWS, la experiencia suele sentirse más orientada a servicios individuales.

Aunque existen mecanismos unificadores como:

Organizations,
CloudFormation,
o Control Tower,

la interacción diaria muchas veces implica navegar entre servicios relativamente desacoplados entre sí.

Eso ofrece muchísimo control y flexibilidad, pero también puede requerir entender mejor cómo interactúan múltiples componentes para operar con fluidez.

No considero que un enfoque sea “mejor” que el otro; más bien destacan la diferencia de filosofía entre ambas nubes.

Reflexiones finales

Este es apenas un primer acercamiento al reto de convertirse en un arquitecto multi nube.

En un momento donde cada vez más organizaciones dejan atrás la idea de depender de un único proveedor, necesitamos desarrollar la capacidad de comprender las fortalezas, limitaciones y filosofía operativa de cada plataforma.

Ser multi nube no significa solamente aprender servicios equivalentes entre AWS y Azure. También implica entender cómo piensa cada ecosistema, cómo organiza sus recursos, cómo gobierna su infraestructura y cómo toma decisiones operativas.

Al final, el verdadero reto es saber qué pieza ajustar en cada ambiente para construir soluciones que sean:

sostenibles,
eficientes,
y financieramente responsables.

Yo sigo aprendiendo en ese proceso y más adelante quiero compartirles también mis experiencias y estrategias alrededor de IA en ambos mundos cloud.

Sabías que un porcentaje significativo de modelos no falla por el algoritmo, sino por la calidad de los datos En este artículo abordo el proceso de Feature Engineering: cómo seleccionar limpiar transformar datos crudos en Features

Diana Castro — Wed, 18 Feb 2026 15:06:00 +0000

Diana Castro for AWS Community Builders

Feb 15

Diario de una builder: Feature Engineering

#ai #aws #machinelearning

Comments

20 min read

Diario de una builder: Feature Engineering

Diana Castro — Sun, 15 Feb 2026 02:58:04 +0000

Feature Engineering: El siguiente paso después de preparar los datos

Existen muchas etapas que debemos recorrer antes de iniciar el entrenamiento de un modelo de Machine Learning. En las entregas pasadas de esta saga hemos trabajado en la exploración de los datos: identificamos outliers, detectamos columnas sin sentido, valores duplicados y comprendimos, en cierta medida, la distribución de los datos.

Esta es una etapa inicial y fundamental dentro del trabajo de cualquier científico de datos.

En nuestro caso, los datos provienen de un origen bastante controlado, ya que se trata de un ejercicio meramente didáctico. No obstante, en escenarios reales los orígenes de datos pueden ser muy variados: tablas, archivos PDF, bases de datos transaccionales, logs, entre otros. Por esta razón, la preparación de los datos suele ser una tarea laboriosa y altamente iterativa.

Este es solo el inicio del camino. Una vez que contamos con los datos crudos debidamente preparados, podemos avanzar al siguiente paso: el proceso de selección y construcción de features, conocido como Feature Engineering.

En esta etapa, el objetivo es ir un paso más allá y enriquecer el dataset, transformándolo en un conjunto de datos más representativo, consistente y adecuado para su uso en modelos de Machine Learning.

Para lograrlo, no basta con aplicar técnicas de forma mecánica. Es fundamental comprender la teoría que respalda el Feature Engineering, ya que las decisiones que tomamos en esta fase impactan directamente en:

La calidad del modelo
Su capacidad de generalización
La reutilización futura de los datos

🔁 Un proceso altamente iterativo

Como verán, estos procesos son altamente iterativos. Y aunque pueda parecer que ya hemos “limpiado nuestro set de datos”, la realidad es que se requieren más iteraciones para convertirlo en un conjunto verdaderamente adecuado para que un modelo logre aprender de forma precisa.

Y algo muy importante: debemos presentar los features de la manera más apropiada posible.

Es por esto que en las siguientes secciones hablaremos de Feature Engineering y continuaremos preparando el dataset. Al final, no tendremos simplemente datos curados: los habremos transformado en features.

🧠 Feature Engineering – Comprendiendo lo que implica

El Feature Engineering no es un término elegante ni una práctica cosmética dentro de un pipeline de Machine Learning; es una de las fases con mayor impacto técnico en el desempeño final del modelo.

En términos prácticos, la capacidad predictiva de un algoritmo está fuertemente condicionada por la calidad, relevancia y representatividad de las variables con las que aprende.

Al igual que la etapa de preparación de datos —donde exploramos distribuciones, detectamos outliers, tratamos valores nulos y eliminamos inconsistencias— el Feature Engineering es inherentemente iterativo. No es un paso lineal que se ejecuta una sola vez; implica ciclos continuos de:

Hipótesis
Transformación
Validación
Ajuste

📚 Conceptos base

En aprendizaje supervisado:

Feature: cada variable o atributo que se entrega al modelo como entrada durante el entrenamiento.
Label (o variable objetivo): la variable que deseamos predecir.

Las features constituyen el espacio de representación del problema. Es sobre ellas que el modelo identifica patrones, estima relaciones y construye su función de predicción.

🎴 Aplicado a nuestro ejemplo práctico

En nuestro caso:

Tipo	Variable	Descripción
Feature	Rareza	Nivel de rareza asociado a la carta
Feature	Costo máximo	Valor máximo del rango de costo
Feature	Costo mínimo	Valor mínimo del rango de costo
Label	Costo de la carta	Variable numérica que deseamos predecir

🔎 Punto clave: El modelo no aprende directamente del “concepto” de una carta, sino de cómo representamos matemáticamente sus atributos.

🔬 ¿Qué abarca el Feature Engineering?

Desde una perspectiva técnica, el Feature Engineering incluye principalmente:

1️⃣ Selección de variables relevantes

Eliminación de ruido y reducción de dimensionalidad para conservar únicamente aquellas variables con verdadera capacidad explicativa.

2️⃣ Transformación de variables existentes

Escalamiento (normalización o estandarización).
Codificación de variables categóricas (One-Hot Encoding, Target Encoding, etc.).
Transformaciones matemáticas (logarítmica, polinómica, interacción entre variables).

3️⃣ Creación de nuevas features (Feature Construction)

Generación de variables derivadas que capturen mejor la señal del problema, por ejemplo:

Variables agregadas.
Indicadores binarios derivados de umbrales.

El objetivo es mejorar las entradas para que el modelo capture la estructura real del problema y no lo carguemos simplemente con ruido.

🎯 ¿Qué ganamos con una correcta aplicación?

1️⃣ Reducción de costos computacionales

Un conjunto de features optimizado reduce dimensionalidad innecesaria, lo que implica:

Menor tiempo de entrenamiento.
Menor consumo de memoria.
Menor costo de cómputo (especialmente relevante en entornos cloud).

2️⃣ Mejora del rendimiento del modelo

Seguramente han escuchado la frase: garbage in, garbage out.

En Machine Learning, esto es especialmente relevante.

Features bien diseñadas ayudan a:

Mejorar la relación señal–ruido.
Reducir el overfitting.
Mejorar la capacidad de generalización.

💡 Pro Tip: En muchos escenarios prácticos, una mejora en la calidad de las features tiene mayor impacto que cambiar de algoritmo.

🧩 ¿Cuál es la naturaleza del problema?

Las transformaciones y estrategias dependen directamente de la naturaleza del problema. Algunos tipos comunes son:

📈 Problema de regresión

Cuando el objetivo es predecir un valor numérico continuo (por ejemplo, el valor de un auto, un inmueble o una carta).

El modelo estima una función:
f(X) → y donde y ∈ ℝ

🏷️ Problema de clasificación

Cuando el objetivo es predecir una categoría discreta (por ejemplo, fraude vs. no fraude, correo auténtico vs. spam).

Aquí el modelo aprende fronteras de decisión en el espacio de features.

Puede tratarse de:

Clasificación binaria
Clasificación multiclase

En ambos casos, el objetivo es la categorización.

Cada tipo de problema impone distintos criterios de evaluación, distintas transformaciones y distintas consideraciones estadísticas.

🏁 En síntesis

El Feature Engineering es el puente entre los datos crudos y la capacidad de realizar predicciones reales y efectivas.

De nada sirve un modelo sofisticado si está alimentado con malas features.

🔄 Feature Transformation

Las técnicas de transformación que apliquemos dependen directamente del tipo de dato con el que estemos trabajando y del objetivo del modelo. No intento desarrollar una tesis exhaustiva sobre el tema, sino establecer criterios técnicos que nos permitan tomar decisiones informadas al momento de convertir un dataset en un conjunto de features útiles.

En Feature Transformation no existen recetas de cocina. La elección correcta depende de múltiples factores:

La naturaleza del problema (regresión o clasificación).
La distribución de los datos.
El volumen de información disponible.
El algoritmo que utilizaremos.
Restricciones operativas como costo o latencia.

La transformación no es un proceso automático. En una ocasión formé parte de un equipo que recibió un dataset con el histórico de ventas de los últimos 14 años. A primera vista parecía un volumen considerable; sin embargo, al analizar la frecuencia real de transacciones por año, el tamaño efectivo de muestra era limitado.

Esto impactaba directamente las decisiones de transformación y modelado, ya que ciertas técnicas requieren suficiente densidad estadística para aportar valor real.

🧮 Transformaciones por tipo de variable

📊 Datos numéricos o cuantitativos

Pueden ser discretos o continuos y suelen requerir tratamiento cuando presentan:

Diferencias significativas de escala.
Distribuciones altamente asimétricas.
Presencia de outliers.
Valores faltantes.

Técnicas comunes:

Imputación (media, mediana, modelos predictivos).
Escalado (Min-Max o estandarización Z-score).
Transformaciones logarítmicas o de potencia para reducir sesgo.

🏷️ Datos categóricos o cualitativos

Representan atributos no numéricos y requieren conversión a formato numérico antes del entrenamiento.

Se clasifican en:

Nominales: no poseen orden inherente (por ejemplo, tipo de carta o categoría).
Ordinales: existe un orden lógico entre categorías (por ejemplo, nivel de rareza).

Técnicas utilizadas:

One-Hot Encoding para variables nominales.
Ordinal Encoding cuando el orden tiene significado real.
Target Encoding, con especial cuidado para evitar data leakage.

Una mala codificación puede introducir relaciones artificiales o sesgos en el modelo, por lo que esta decisión debe ser cuidadosamente evaluada.

🧾 Datos de texto e imágenes

No pueden ser utilizados directamente por la mayoría de los algoritmos tradicionales y requieren transformaciones más sofisticadas.

En texto:

Bag of Words
TF-IDF
Embeddings

En imágenes:

Extracción de vectores de características.
Representaciones generadas por redes convolucionales.

En ambos escenarios, el objetivo es transformar datos no estructurados en representaciones numéricas que capturen información semántica relevante.

Existen numerosas técnicas adicionales. Me centraré principalmente en aquellas que utilicé en el esquema práctico del artículo y compartiré un listado de las más relevantes según el tipo de dato trabajado.

⚙️ Técnicas aplicadas y justificación técnica

El dataset base presenta una combinación de variables numéricas y categóricas, además de valores extremos que, tras el análisis exploratorio, no correspondían a ruido sino a comportamientos inherentes al dominio del problema.

Este punto es crítico: no todo outlier debe eliminarse.

En algunos casos representa señal relevante, y removerlo podría introducir sesgo o pérdida de información.

A continuación, detallo las transformaciones aplicadas según el tipo de dato, junto con su justificación.

🏷️ Técnicas aplicadas a datos categóricos

🔹 One-Hot Encoding

El One-Hot Encoding se utiliza cuando trabajamos con variables categóricas nominales, es decir, aquellas donde no existe un orden inherente entre sus categorías.

Asignar valores numéricos directos (por ejemplo, 1, 2, 3) a este tipo de variable introduce un orden artificial que el modelo puede interpretar como relación de magnitud, generando sesgos en el aprendizaje.

La técnica consiste en:

Crear una columna binaria por cada categoría posible.
Asignar valor 1 cuando la categoría está presente.
Asignar valor 0 cuando no lo está.

🧪 Ejemplo práctico

Supongamos el atributo type_1 de un Pokémon, cuyos valores posibles son:

Fire, Water, Grass.

Después de aplicar One-Hot Encoding, la representación se transforma de la siguiente manera:

Pokémon	type_1_Fire	type_1_Water	type_1_Grass
Personaje 1	1	0	0
Personaje 2	0	1	0
Personaje 3	0	0	1

Nota: Los personajes de Pokémon se utilizan con fines exclusivamente didácticos.

✅ Resultado de la transformación

Con esta técnica:

No se introduce un orden implícito entre categorías.
Cada categoría es tratada como una dimensión independiente.
Se evita que el modelo asuma relaciones inexistentes (por ejemplo, que Fire sea “mayor” que Water).

Si en lugar de esto se hubieran asignado valores secuenciales (1, 2, 3), un modelo lineal podría interpretar diferencias de magnitud entre categorías, lo cual no refleja la naturaleza real del dato.

⚠️ Consideración sobre cardinalidad

En este ejemplo, el atributo presenta baja cardinalidad, es decir, un número reducido de categorías posibles. En estos escenarios, One-Hot Encoding es una técnica apropiada y computacionalmente manejable.

Sin embargo, cuando trabajamos con variables de alta cardinalidad (por ejemplo, cientos o miles de categorías únicas), esta técnica puede:

Incrementar excesivamente la dimensionalidad.
Aumentar el riesgo de overfitting.
Elevar el costo computacional.

Este tipo de escenarios requiere estrategias alternativas.

🔢 Ordinal Encoding

Aunque esta técnica no fue aplicada en el dataset del caso práctico —porque no existían variables categóricas con orden inherente— es importante mencionarla, ya que forma parte del conjunto fundamental de herramientas en Feature Transformation.

El Ordinal Encoding se utiliza cuando trabajamos con variables categóricas ordinales, es decir, cuando el orden entre las categorías tiene significado semántico y forma parte de la naturaleza del dato.

A diferencia de las variables nominales, en este escenario asignar valores numéricos no introduce un sesgo artificial, siempre que el orden refleje correctamente la jerarquía real del atributo.

🧪 Ejemplo práctico

Un ejemplo clásico es el nivel de riesgo crediticio dentro del dominio financiero. Las categorías presentan un orden natural explícito definido por el negocio.

Por ejemplo:

Low Risk = 1
Medium Risk = 2
High Risk = 3

Mediante Ordinal Encoding, cada categoría se transforma en un valor numérico que preserva la jerarquía del riesgo. De esta forma, el modelo puede interpretar correctamente que un cliente clasificado como High Risk representa mayor riesgo que uno Medium Risk.

Es importante notar que el objetivo no es modelar una distancia exacta entre categorías, sino capturar la relación de orden.

⚠️ Consideraciones técnicas importantes

Al aplicar Ordinal Encoding, se debe validar cuidadosamente que:

El orden asignado refleje fielmente la estructura del dominio.
La codificación no introduzca interpretaciones erróneas de distancia si el modelo es sensible a magnitudes (por ejemplo, modelos lineales).
No se asuma que la diferencia entre 1 y 2 es equivalente a la diferencia entre 2 y 3, salvo que la representación real del problema lo respalde.

En síntesis, el Ordinal Encoding es una técnica adecuada cuando el orden es parte intrínseca del dato.

De haber existido y sido relevante la evolución del personaje (primera, segunda o tercera evolución), esta técnica habría sido apropiada.

💡 Pro Tip: La clave no está en convertir categorías en números, sino en respetar la semántica real del problema.

📊 Técnicas para datos numéricos

Las variables numéricas suelen concentrar gran parte de la señal predictiva, pero también son las que más fácilmente pueden introducir sesgos si no se transforman adecuadamente.

A continuación, presento un resumen de las técnicas más relevantes y posteriormente profundizaremos en las utilizadas en el caso práctico.

📋 Resumen de técnicas

#	Técnica	¿Qué hace?	¿Cuándo aplicar?	Fórmula
1	Imputation	Sustituye valores nulos o ausentes	Datos con valores faltantes	Media, mediana, moda o valor constante
2	Log / Log1p	Reduce asimetría y comprime valores extremos	Variables long-tail, precios, conteos	log1p(x) = ln(1 + x)
3	Standardization	Centra y escala por desviación estándar	Modelos sensibles a escala (regresión, PCA)	(x − μ) / σ
4	Min-Max Scaling	Escala a un rango fijo (ej. 0–1)	Cuando se requiere preservar proporciones	(x − min) / (max − min)
5	Robust Scaling	Usa estadísticos robustos frente a outliers	Datos con valores extremos frecuentes	(x − mediana) / IQR
6	Clipping / Capping	Limita valores extremos a umbrales definidos	Control de outliers por reglas de negocio	x = min(max(x, l), u)
7	Binning	Convierte variables continuas en intervalos	Capturar relaciones no lineales	Discretización por rangos

🧮 Imputation (Imputación de valores faltantes)

La imputación es una de las primeras transformaciones que deben abordarse en cualquier pipeline de Feature Engineering. Muchos algoritmos de Machine Learning no manejan valores nulos de forma nativa; ignorarlos o eliminar registros indiscriminadamente puede reducir el tamaño efectivo de la muestra y alterar la distribución original de los datos.

La elección del método debe basarse en la distribución de la variable y en el contexto del dominio.

🧪 Ejemplo: impacto de media vs mediana

Supongamos una variable que representa el valor de venta (en miles):

[10, 12, 11, 13, 12, 200]

Aquí existe un valor extremo (200).

Cálculo de la media

Media = (10 + 12 + 11 + 13 + 12 + 200) / 6

Media = 258 / 6 = 43

Cálculo de la mediana

Ordenando los valores:

[10, 11, 12, 12, 13, 200]

La mediana es el promedio de los valores centrales (12 y 12):

Mediana = 12

🔎 Observación técnica

La media (43) se ve fuertemente desplazada por el outlier.
La mediana (12) representa mejor el comportamiento típico del conjunto.

Si imputáramos valores faltantes usando la media, estaríamos introduciendo un valor artificialmente alto respecto a la mayoría de los datos. En cambio, la mediana preserva mejor la tendencia central cuando la distribución es asimétrica o presenta valores extremos.

📌 Técnicas de imputación más utilizadas

Imputación por la media

Adecuada cuando la distribución es aproximadamente normal y no existen outliers significativos.
Imputación por la mediana

Más robusta ante asimetrías y valores extremos. Es una de las más utilizadas en datasets reales.
Imputación por la moda

Más común en variables categóricas o discretizadas.
Imputación con valor constante

Útil cuando el valor faltante tiene significado propio (por ejemplo, “sin historial”).
Imputación basada en modelos (KNN, regresión)

Utiliza la relación entre variables para estimar valores faltantes de forma más informada. Es más compleja, pero potencialmente más precisa.

⚠️ Consideración crítica

La imputación no es una simple operación matemática; introduce supuestos estadísticos sobre la distribución de los datos. Cada método modifica la varianza, la media o incluso la estructura de correlación entre variables.

Por ello, la decisión debe alinearse con:

La naturaleza estadística de la variable.
El volumen de datos disponibles.
El impacto que puede tener en el modelo final.
El contexto del negocio.

Una imputación mal elegida puede distorsionar la señal original más que los valores faltantes que intenta corregir.

📉 Transformaciones logarítmicas (log / log1p)

Las transformaciones logarítmicas son ampliamente utilizadas en Feature Engineering para reducir la asimetría (skewness) de variables numéricas y comprimir valores extremos.

Resultan especialmente útiles cuando una pequeña fracción de observaciones concentra valores significativamente más altos que el resto, situación común en precios, conteos, ingresos o métricas de uso.

En el análisis del dataset de cartas Pokémon, esta técnica fue aplicada durante la estandarización de los precios. La distribución presentaba un comportamiento long-tail: la mayoría de las cartas tenía precios bajos o moderados, mientras que unas pocas alcanzaban valores considerablemente altos.

Sin una transformación adecuada, estos valores extremos podrían dominar el entrenamiento y distorsionar el ajuste del modelo, especialmente en algoritmos sensibles a magnitudes.

🔎 ¿Qué es log1p?

La transformación log1p se define como:

log1p(x) = ln(1 + x)

Se prefiere sobre la transformación tradicional ln(x) por varias razones técnicas:

Permite manejar valores iguales a cero sin generar errores matemáticos.
Ofrece mayor estabilidad numérica en rangos pequeños.
Es adecuada para distribuciones long-tail típicas en precios, ingresos o conteos.

Mientras que ln(0) es indefinido, ln(1 + 0) = 0, lo que evita problemas durante el preprocesamiento.

🧪 Ejemplo práctico

Supongamos los siguientes precios:

x = [0, 5, 20, 100, 1000]

Al aplicar la transformación:

Valor original (x)	log1p(x) = ln(1 + x)
0	0.000
5	1.792
20	3.045
100	4.615
1000	6.909

📊 Interpretación del resultado

Observaciones clave:

El valor 0 no genera errores.
Las distancias entre valores altos se comprimen significativamente.
El orden relativo se mantiene (1000 sigue siendo mayor que 100).
La distribución resultante es más balanceada y menos sesgada.

Por ejemplo:

Diferencia original entre 100 y 1000 → 900
Diferencia después de log1p → aproximadamente 2.29

Esto reduce la dominancia de valores extremos sin perder información ordinal.

🎯 Casos de uso típicos

Las transformaciones logarítmicas son especialmente útiles en:

Costos y precios.
Volúmenes de transacciones.
Frecuencia de eventos.
Métricas financieras o de uso acumulativo.

En términos prácticos, aplicar log1p no elimina la señal de valores altos; la reescala para que el modelo pueda aprender patrones más estables.

Es una transformación matemática simple, pero con impacto significativo en estabilidad y capacidad de generalización.

🛠️ Camino al dataset model-ready

Seré muy honesta: aplicar transformaciones dentro de la herramienta es, en sí mismo, un proceso operativo sencillo. Basta con seleccionar la transformación, elegir la técnica adecuada y definir los parámetros correspondientes. Desde el punto de vista técnico, el flujo es claro y accesible.

Lo verdaderamente complejo no es la herramienta, sino el manejo del dataset.

Cuando trabajamos con datos reales, aparecen inevitablemente los desafíos propios de entornos productivos:

Valores inconsistentes.
Registros mal tipados.
Categorías mal formateadas.
Outliers que no son ruido, sino comportamiento legítimo del negocio.
Casos excepcionales que no resultan evidentes en una primera revisión.

Es durante la construcción del flujo cuando se hace evidente que existen factores no considerados inicialmente. Esto obliga a iterar: revisar, ajustar, deshacer transformaciones, validar nuevamente y reconstruir el pipeline.

Este proceso iterativo no es señal de error, sino parte natural del ciclo de ingeniería de datos.

💡 Pro Tip: Antes de aplicar cualquier transformación estructural —como un One-Hot Encoding— es indispensable revisar los datos exhaustivamente.

Herramientas como Data Wrangler incorporan capacidades de análisis visual que permiten observar distribuciones, detectar anomalías y validar supuestos antes de modificar el espacio de features.

En mi caso particular, identifiqué un único valor numérico dentro de una variable categórica que había pasado desapercibido. Ese solo registro fue suficiente para provocar un error durante la aplicación del One-Hot Encoding.

Este tipo de situaciones refuerza una lección fundamental: la calidad del encoding depende directamente de la limpieza previa del dato.

🧩 Tratamiento de la variable `extrarity`

En el dataset, extrarity es una variable categórica relevante para el modelo. Sin embargo, presenta un 10,32 % de valores nulos, lo que obliga a intervenirla antes de aplicar cualquier técnica de codificación.

Dado que su cardinalidad es baja, el One-Hot Encoding es una técnica adecuada y no genera una expansión excesiva del espacio de características.

1️⃣ Tratamiento de valores nulos

El primer paso consistió en crear una categoría explícita para los valores faltantes, asignando el valor: unknown

Esta decisión técnica permite:

Evitar la pérdida de registros.
Preservar el tamaño de muestra.
Hacer explícita la ausencia de información.
Permitir que el modelo determine si la falta de dato tiene valor predictivo.

Es importante entender que un valor faltante no siempre es irrelevante; en ciertos contextos, la ausencia de información puede estar correlacionada con el comportamiento objetivo.

Para implementarlo, se agregó una transformación visual en Data Wrangler destinada al manejo de valores nulos, especificando el reemplazo por la categoría definida.

Con esto, se garantiza consistencia antes de aplicar el One-Hot Encoding en etapas posteriores del pipeline.

🔄 Aplicación de One-Hot Encoding

Una vez tratados los valores faltantes en extrarity, la variable queda lista para aplicar One-Hot Encoding sin riesgo de errores derivados de nulos o inconsistencias tipológicas.

En esta etapa es fundamental definir correctamente el formato de salida (output style), ya que esta decisión impacta la interpretabilidad, la reutilización y la integración del dataset en etapas posteriores del pipeline.

📦 Selección del formato de salida

En este caso, se seleccionó el formato columnar, por las siguientes razones:

El formato vectorial suele emplearse en escenarios de deep learning o en pipelines cerrados donde la interpretabilidad no es prioritaria y el consumo lo realiza directamente un modelo.
El formato columnar es preferido cuando las features deben ser:
- Interpretables.
- Reutilizables.
- Persistidas en un Feature Store.
- Inspeccionadas por equipos de datos o negocio.

En términos prácticos, “salida en columnas” significa que cada categoría se convierte en una columna independiente, manteniendo un prefijo asociado al nombre original de la variable.

Por ejemplo, si la variable es extrarity, las nuevas columnas podrían materializarse como:

extrarity_common
extrarity_rare
extrarity_ultra_rare
extrarity_unknown

🧭 Buenas prácticas

Conservar el prefijo del nombre original de la variable no es un detalle menor. Esta práctica:

Facilita la trazabilidad de las features.
Mejora la legibilidad del dataset transformado.
Reduce ambigüedad cuando existen múltiples variables categóricas.
Simplifica el mantenimiento y la reutilización en otros modelos o proyectos.

En entornos productivos, donde múltiples pipelines conviven, la nomenclatura consistente es parte de la gobernanza de datos.

💡 Pro Tip: Es prácticamente inevitable realizar ajustes durante la construcción del pipeline.

En Data Wrangler no es posible insertar directamente un nodo intermedio en la vista visual sin que se genere una nueva rama del flujo.
La forma correcta de aplicar una corrección consiste en:

Ir a la vista Data.

Localizar el listado de transformaciones aplicadas.

Crear el nuevo paso intermedio.

Reordenarlo arrastrándolo hasta la posición adecuada dentro del flujo. Este enfoque permite mantener un pipeline limpio, reproducible y coherente, evitando bifurcaciones innecesarias que puedan dificultar la trazabilidad del proceso de transformación.

Veamos ahora como se ven las columnas

El nuevo flujo es este como pueden ver no hay errores

🔐 La importancia de la llave primaria antes de registrar en el Feature Store

Después de aplicar las transformaciones sobre las variables categóricas y numéricas, el siguiente paso fue registrar el dataset en el Feature Store para definir explícitamente qué columnas correspondían a features y cuáles no.

Fue en ese momento cuando surgió un problema crítico: el dataset no contaba con una llave única por registro.

Un Feature Store requiere identificar cada entidad de forma inequívoca. Si no es posible distinguir cada fila de manera única, no se puede:

Versionar correctamente los datos.
Actualizar registros sin ambigüedad.
Garantizar integridad en entrenamiento e inferencia.
Evitar sobrescrituras accidentales.

En otras palabras, sin clave primaria, el pipeline pierde trazabilidad y consistencia.

🔎 Identificación del problema

Al revisar el dataset en detalle, se evidenció que no existía una columna que identificara de forma única cada carta. Esto implicaba que, aunque las features estuvieran correctamente transformadas, el registro en el Feature Store sería inconsistente.

Era necesario crear una llave compuesta, pero no podía ser arbitraria. La clave debía construirse a partir de atributos que, combinados, garantizaran unicidad real dentro del dominio.

🧩 Construcción de la llave compuesta

Al recorrer el dataset, cada carta contenía:

product_id
extNumber

Si bien product_id por sí solo no era único, la combinación con extNumber —que representa una numeración del tipo ###/###— sí permitía diferenciar cada carta de forma inequívoca.

Se creó entonces una nueva columna llave compuesta:
card_id = product_id + "_" + extNumber

Esta columna:

No es una feature.
No participa en el entrenamiento del modelo.
No aporta señal predictiva.
Su propósito es exclusivamente identificador.

Sin embargo, es fundamental para la arquitectura del sistema.

🧹 Eliminación de duplicados

La validación de la nueva llave reveló registros duplicados en el dataset. Esto confirmaba que el problema no era solo la ausencia de clave primaria, sino también la presencia de filas repetidas.

Por lo tanto, fue necesario:

Validar la unicidad de la nueva llave.
Eliminar registros duplicados.
Confirmar que cada fila representara una entidad única.

Solo después de garantizar integridad y unicidad, el dataset quedó en condiciones adecuadas para su registro en el Feature Store.

💡 Pro Tip:

Antes de optimizar features, debemos garantizar identidad e integridad de la entidad.

Un modelo puede estar estadísticamente bien construido, pero si la estructura de identificación es incorrecta, todo el trabajo previo pierde validez operacional.

En este caso, card_id no es una feature, pero es el pilar que permite que todas las features tengan contexto y consistencia dentro del sistema.

📦 Exportación a S3

Aunque Data Wrangler permite continuar el flujo directamente en Canvas, en este laboratorio se optó por exportar el dataset a Amazon S3 para mantener control explícito sobre los datos y preparar las features para su registro en el Feature Store.

Se seleccionó el formato Parquet, adecuado para:

Almacenamiento columnar eficiente.
Compresión optimizada.
Compatibilidad con procesos analíticos y entrenamiento.

🏗 Feature Store como cierre arquitectónico del pipeline

Una vez que las variables fueron limpiadas, imputadas, transformadas y validadas, surge una pregunta fundamental desde una perspectiva de producción:

¿Cómo garantizamos que estas mismas transformaciones se mantengan consistentes en futuros reentrenamientos y en escenarios de inferencia?

Aquí es donde el uso de un Feature Store deja de ser opcional y se convierte en una decisión arquitectónica.

📚 ¿Qué es un Feature Store?

Un Feature Store es un componente dentro de la arquitectura de Machine Learning cuyo propósito es:

Centralizar features ya transformadas.
Versionarlas y gobernarlas.
Servirlas de forma consistente para entrenamiento e inferencia.
Separar la ingeniería de features del código del modelo.

En entornos AWS, este rol lo cumple Amazon SageMaker Feature Store, que permite administrar features como activos de primera clase dentro del ciclo de vida del modelo.

El beneficio principal es eliminar riesgos clásicos como:

Data leakage por transformaciones inconsistentes.
Desalineación entre entrenamiento y producción.
Reprocesamiento manual repetitivo.

🗂 Feature Group: la unidad lógica

Dentro del Feature Store existe un concepto clave: el Feature Group, que es la unidad lógica donde se almacenan las features asociadas a una entidad.

Si el Feature Store es el repositorio central, el Feature Group es la “tabla estructurada” que contiene:

El identificador único de la entidad (Record Identifier).
El timestamp del evento (Event Time).
El conjunto de features relacionadas.

💡 Pro Tip:

Un Feature Group funciona conceptualmente como una tabla versionada con control temporal.

Al crearlo, se deben definir explícitamente:

Record Identifier Name

En este caso: card_id

→ Identifica de forma única cada carta.
Event Time Feature Name

→ Permite versionar las features en el tiempo.
Feature Definitions

→ Nombre y tipo de dato exacto de cada columna.

El esquema actúa como un contrato. Si el dataset no coincide exactamente con esa definición, el servicio devolverá un error de validación.

🔄 Separación entre features estáticas y dinámicas (mejor práctica)

Una decisión arquitectónica relevante fue separar las features según su naturaleza temporal.

1️⃣ Feature Group Estático

Contiene atributos que no cambian en el tiempo, por ejemplo:

Rareza (rarity)
Características físicas de la carta
Identificadores estructurales

Estas features se registran una sola vez por entidad.

2️⃣ Feature Group Dinámico

Contiene variables que evolucionan en el tiempo, como:

Precios históricos
Métricas agregadas temporales
Indicadores de mercado

Estas features requieren versionamiento temporal.

Esta separación sigue una buena práctica en sistemas ML productivos: desacoplar identidad estructural de señales dependientes del tiempo.

🆔 Identificación única: card_id + timestamp

Para que el Feature Store funcione correctamente, cada registro debe tener:

Record Identifier (Primary Key) → card_id
Event Time → timestamp que indica cuándo esa versión del feature fue válida

En el Feature Store, record_identifier_name y event_time_feature_name son obligatorios en cada Feature Group.

⚠ Consideraciones críticas al crear Feature Groups

Al crear los Feature Groups es obligatorio definir:

Nombre exacto de cada columna.
Tipo de dato correcto.
Campo identificador.
Campo temporal.

Si existe cualquier discrepancia entre el esquema declarado y el dataset cargado, el servicio devolverá un error de validación.

🚀 Carga (ingestión) de datos

El siguiente paso natural es poblar los Feature Groups mediante cargas en Python, normalmente desde SageMaker Studio.

El flujo típico consiste en:

Crear el Feature Group.
Esperar a que el estado sea Created.
Ejecutar la ingestión mediante ingest() o PutRecord.
Validar almacenamiento en:
- Online Store (para inferencia en tiempo real).
- Offline Store en S3 (para entrenamiento).

🎯 Conclusión

En proyectos de Machine Learning, el desempeño del modelo suele acaparar la atención. Sin embargo, la verdadera complejidad reside en la calidad estructural de los datos y en la arquitectura que garantiza su consistencia a lo largo del tiempo.

A lo largo de este trabajo se abordaron transformaciones estadísticas necesarias —imputación robusta, reducción de asimetrías y estabilización de varianza— pero el aprendizaje más relevante surgió al enfrentar problemas de identidad, unicidad y versionamiento.

La creación de una llave compuesta (card_id), la eliminación de duplicados y la validación de integridad no fueron ajustes menores: fueron decisiones que aseguraron trazabilidad y coherencia sistémica.

La adopción de Amazon SageMaker Feature Store permitió estructurar las features como activos gobernados, separando atributos estáticos de dinámicos y modelando explícitamente la dimensión temporal mediante event_time.

Este ejercicio reafirma principios fundamentales:

Sin identidad única no existe sistema confiable.
Sin modelado temporal no existe control sobre la evolución del dato.
Sin contratos de esquema no existe gobernanza.
Y sin gobernanza, no existe producción sostenible.

El resultado no es únicamente un conjunto de features preparadas, sino una arquitectura preparada para escalar, evolucionar y sostener modelos en entornos reales.

Diario de una builder: Preparándonos para AWS Machine Learning desde cero – Otro camino para llegar a Roma

Diana Castro — Mon, 29 Dec 2025 00:37:27 +0000

Tal y como mencionaba en el artículo Preparando datos, lo más importante es ser consciente de qué herramienta utilizar en cada escenario. Todo depende del caso de uso, la experticia del equipo, el tiempo disponible y el nivel de complejidad; al final, siempre se trata de trade-offs.

Con el objetivo de tener un panorama lo más completo posible, en este laboratorio exploraremos otro camino para llegar a Roma. En esta ocasión utilizaremos AWS Glue de principio a fin para preparar nuestro ya conocido dataset de tarjetas. El enfoque será distinto: esta vez me centraré en el proceso, ya que el análisis del dataset lo abordamos previamente en el artículo mencionado.

La intención es recorrer el flujo completo, desde que un nuevo archivo es escrito en Amazon S3 hasta que los datos quedan disponibles para su consumo analítico. Para ello, construiremos un pipeline que se dispare automáticamente ante la llegada de nuevos datos, ejecute las transformaciones necesarias y actualice los metadatos en el catálogo.

🧩 Componentes del laboratorio

Para este laboratorio utilizaremos los siguientes componentes:

🪣 Amazon S3

Como almacenamiento de los datasets para fines académicos.
⏱️ Amazon EventBridge

Encargado de disparar el proceso de transformación ante la llegada de un nuevo archivo.
🔁 AWS Glue Workflow

Responsable de la orquestación y de definir la secuencia de pasos necesarios para una limpieza, transformación y entrega exitosa.
🛠️ AWS Glue Job

Donde se realizan las limpiezas y transformaciones básicas de los datos.
🗂️ AWS Glue Crawler

Encargado de poblar y actualizar el Data Catalog.

⚙️ Algunas decisiones técnicas

Ahora que conocemos las herramientas que nos apoyarán, el siguiente diagrama define de forma conceptual la arquitectura que soporta el flujo.

En este caso de uso no conocemos de antemano el momento en el que ingresarán nuevos archivos para ser procesados. No existe una periodicidad definida: los archivos se cargarán conforme se disponga de nuevos datos. No hay un proceso que deposite información cada 24 horas ni una fuente que genere archivos de forma continua.

Bajo estas condiciones, una arquitectura orientada a eventos es la opción más adecuada. Con este enfoque, el procesamiento ocurre únicamente cuando es necesario, evitando ejecuciones innecesarias y consumo de recursos en vano. Archivo nuevo, ejecución nueva.

Para lograr este desacople, Amazon EventBridge actúa como la capa intermedia del flujo. Esto nos permite aislar la ingesta del procesamiento y nos da flexibilidad ante cambios futuros. Hoy el evento dispara un Glue Workflow; mañana podría activar otros destinos o incluso múltiples flujos en paralelo, sin necesidad de rediseñar la arquitectura.

Los pipelines event-driven son ampliamente utilizados porque:

⚡ Se integran de forma natural con arquitecturas serverless.
🧩 Reducen la complejidad operativa.
⏳ Evitan dependencias temporales artificiales.

En nuestro caso, los datos se procesan cuando llegan. Si no llega nada, no hay ejecuciones ni consumo de recursos asociados.

🔁 Orquestación con Glue Workflow

Otro elemento clave del flujo es AWS Glue Workflow. Su función no es transformar datos, sino orquestar el proceso: definir qué operaciones se ejecutan y en qué orden. Conceptualmente, cumple un rol similar al que podría desempeñar AWS Step Functions en otros escenarios.

El Workflow nos permite coordinar los distintos componentes del pipeline y asegurar que cada paso se ejecute solo cuando el anterior ha finalizado correctamente, aportando control y claridad al proceso completo.

🗂️ Separación por capas: raw y curated

Uno de los principios que seguimos en este laboratorio es la separación por capas, comenzando por raw y avanzando hacia curated. Esta distinción no es meramente organizativa; responde a necesidades de trazabilidad, control y calidad del dato.

📥 Capa raw

La capa raw representa el punto de entrada del dato. Aquí se almacenan los archivos tal y como llegan desde la fuente, sin aplicar transformaciones ni validaciones complejas.

Sus principales características son:

📄 Los datos se preservan en su forma original.
🔒 No se modifica el contenido; únicamente se almacena.
♻️ Sirve como respaldo para reprocesamientos, auditorías o correcciones futuras.

En este laboratorio, Amazon S3 actúa como la capa raw, recibiendo el dataset de tarjetas cada vez que un nuevo archivo es cargado.

📊 Capa curated

La capa curated contiene los datos limpios, transformados y listos para consumo. En esta etapa se aplican las reglas necesarias para que el dataset pueda ser utilizado de forma confiable por procesos analíticos.

En esta capa:

🧮 Se normalizan columnas y tipos de datos.
🧹 Se corrigen inconsistencias básicas.
📐 Se definen esquemas más estables y predecibles.

Esta separación permite mantener una arquitectura ordenada, auditable y preparada para evolucionar a medida que el pipeline crece en complejidad.

Para serles honesta, comencé abordando el core del problema: la definición básica de Amazon S3 y el Glue Job encargado de las transformaciones. Sin embargo, al construir el flujo de manera evolutiva, algunos “detalles” quedaron fuera del radar y terminaron complicando el proceso más de lo necesario.

Hubo un punto en el que cada pieza parecía estar correctamente configurada: el evento se disparaba, el trigger funcionaba, incluso validé el flujo utilizando CloudWatch como destino y, aun así, el pipeline no lograba ejecutarse de principio a fin. Después de darle varias vueltas al problema, caí en cuenta de lo más obvio: los permisos.

Sí, fue uno de esos momentos frustrantes en los que todo está bien… excepto lo fundamental. Precisamente por esa experiencia, y para evitar que el laboratorio se vuelva innecesariamente complejo, en las siguientes secciones abordaré todas las consideraciones de configuración desde el inicio, incluyendo roles y permisos, con el objetivo de que el recorrido sea lo más smooth posible y el pipeline funcione correctamente desde el primer intento.

🪣 S3: definamos el almacenamiento

Como en la mayoría de los pipelines de datos, el punto de inicio será nuestro bucket de Amazon S3. En este laboratorio, una de las primeras consideraciones es la organización del almacenamiento, para lo cual definiremos dos directorios (o prefijos):

/raw
/curated

Tal y como lo explicamos previamente, los datos de origen se mantienen separados en la capa raw. Aquí es donde esperaremos la llegada de nuevos archivos de precios, sin aplicar ningún tipo de transformación.

Por su parte, en la capa curated depositaremos los datos ya procesados: limpios, con los tipos de datos adecuados y listos para su consumo analítico.

⚠️ Consideración importante: integración con EventBridge

Dado que utilizaremos Amazon EventBridge para disparar el pipeline, es fundamental activar las notificaciones de EventBridge en el bucket. Sin este paso, los eventos de creación de objetos no podrán ser capturados y el flujo no se iniciará.

🔐 Permisos a nivel de bucket

Aunque aún no hemos definido todos los componentes del pipeline, es importante anticipar los permisos necesarios desde el inicio. A nivel de bucket policy, debemos permitir lo siguiente:

📡 Amazon EventBridge

Debe tener la capacidad de listar objetos y realizar operaciones de lectura (ListBucket y GetObject) para poder reaccionar a los eventos de S3.
🛠️ AWS Glue

Debe ser capaz no solo de leer, sino también de escribir y eliminar objetos en la capa curated.

En este laboratorio, al tratarse de un ejercicio académico, el Glue Job reescribirá el mismo archivo de salida cuando se ejecute nuevamente. Esto implica que primero se realiza un borrado del objeto existente y luego un PutObject.

💡 Pro tip

En un escenario productivo, lo recomendable sería generar archivos nuevos, por ejemplo incorporando un timestamp en el nombre. Sin embargo, para este ejercicio simplificamos el flujo y priorizamos la claridad del proceso.

A continuación, se muestra un ejemplo de la política asociada al bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEventBridgeToReadS3Events",
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::poctarjetasprecios",
        "arn:aws:s3:::poctarjetasprecios/*"
      ]
    },
    {
      "Sid": "AllowGlueWriteToCurated",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::072962861776:role/service-role/AWSGlueServiceRole-Pokemon"
      },
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:AbortMultipartUpload"
      ],
      "Resource": "arn:aws:s3:::poctarjetasprecios/curated/*"
    }
  ]
}

En la siguiente sección entraremos de lleno en AWS Glue, comenzando por la definición del Job y las consideraciones clave para evitar errores comunes durante la ejecución del pipeline.

🧪 AWS Glue: Jobs, Crawlers y Workflow Orchestration

Recordemos que AWS Glue es un servicio de integración de datos totalmente gestionado que facilita la descubierta, preparación y catalogación de datos para casos de uso de analítica, machine learning y data engineering.

En este laboratorio utilizaremos Glue de forma integral:

🛠️ Glue Jobs

Para realizar las transformaciones y limpiezas de los datos.
🗂️ Glue Crawlers

Para poblar y actualizar el Glue Data Catalog.
🔁 Glue Workflow Orchestration

Para coordinar la ejecución de todo el proceso.

Tal y como discutimos en el artículo anterior, el dataset utilizado nos servirá más adelante para entrenar un modelo que permita estimar el valor de mercado de una tarjeta. Los detalles completos del dataset pueden consultarse en ese artículo; sin embargo, a continuación haré una breve reseña de sus características más relevantes desde la perspectiva de transformación.

Las variables más importantes de una carta incluyen su rareza, tipo, hits y precios. En este dataset, los campos de precio se encuentran representados como strings, y la variable marketprice —que será la que deseamos predecir— presenta una cantidad significativa de valores nulos.

Por lo tanto, antes de poder utilizar los datos, es necesario:

🔄 Realizar cambios de tipo de datos en las columnas de precio.
🧹 Eliminar las filas cuyo valor de marketprice sea nulo.

⚠️ Diferencias importantes con Data Wrangler

Un punto importante a destacar es la diferencia con el enfoque utilizado previamente con Data Wrangler. Con AWS Glue, las transformaciones y limpiezas deben implementarse mediante scripts, lo que implica un mayor control, pero también una mayor responsabilidad sobre el proceso.

Los cambios de tipo de datos no pueden realizarse de forma directa. Antes de aplicar el type casting, es necesario limpiar los valores, eliminando cualquier carácter que no corresponda al tipo esperado, como:

💲 símbolos de moneda ($)
␣ espacios en blanco
🔣 otros caracteres no numéricos

Una vez realizada esta limpieza, es posible convertir las columnas al tipo de dato adecuado. Finalmente, se procede a eliminar columnas que no aportan valor para el análisis o el entrenamiento del modelo, dejando un dataset más limpio y enfocado.

🧱 Construyendo el Job paso a paso

En este laboratorio iniciaremos la creación de un AWS Glue Job utilizando el editor de scripts, con el objetivo de comprender la estructura mínima necesaria para ejecutar un Job de forma exitosa antes de avanzar hacia transformaciones más complejas.

🆕 Creación del Job

En la consola de AWS Glue, nos dirigimos al menú ETL Jobs.
Seleccionamos Create Job y elegimos la opción Script Editor.

⚙️ Selección del Engine

Como Engine, seleccionamos Spark.

Esto nos permite trabajar con un Job basado en Apache Spark y acceder directamente al editor de código para definir la lógica del procesamiento.

Una vez dentro del editor:

🧽 Eliminamos todo el código generado automáticamente.
🧩 Construimos el script paso a paso, comenzando con el ejemplo más básico para validar la ejecución del Job.

✅ Primer script: validación de ejecución

Para esta primera prueba no es necesario importar librerías adicionales ni utilizar el contexto de Glue. Utilizamos únicamente el siguiente código:

print("Glue Job ejecutado correctamente")

Este script cumple un propósito claro: verificar que el Job puede ejecutarse correctamente, que el rol IAM está bien configurado y que la infraestructura de ejecución se aprovisiona sin errores.

⚙️ Configuración de Job Details

En la sección Job Details definimos los siguientes parámetros:

🏷️ Name

Nombre identificador del Job dentro de AWS Glue.
📝 Description

Descripción breve del propósito del Job, útil para fines de documentación y mantenimiento.
🔐 IAM Role

Rol que utilizará el Job para ejecutarse.

Este rol debe contar al menos con la política AWSGlueServiceRole, además de los permisos necesarios para acceder a los recursos que el Job vaya a utilizar (por ejemplo, Amazon S3).

⚠️ Sin un rol válido, el Job no puede ejecutarse.

🧱 Worker Type

Para efectos de este laboratorio seleccionamos G.1X, que corresponde al tipo de worker con las especificaciones más bajas disponibles para Spark Jobs.

Un worker es la unidad de capacidad de cómputo que el servicio utiliza para ejecutar un Job. Cada uno provee recursos de CPU, memoria y almacenamiento temporal, y es sobre estos recursos donde se ejecutan las tareas de Apache Spark asociadas al Job.

El número y tipo de workers determinan la capacidad de procesamiento, el tiempo de ejecución y el costo del Job.
🔢 Requested number of workers

Por defecto, AWS Glue asigna 10 workers, lo cual incrementa innecesariamente los costos en pruebas simples.

Para minimizar costos, configuramos el valor mínimo permitido, que en este caso es 2 workers.
🐍 Language

Seleccionamos Python como lenguaje del Job.

Una vez definidos estos detalles, salvamos y ejecutamos el Job. Podemos ver el detalle de la ejecución en OutputLogs, como se muestra en la siguiente imagen.

💡 Pro Tip

En el caso de los AWS Glue Jobs, los costos están asociados directamente a la ejecución del Job. Asegúrate de que los Jobs se encuentren en estado Completed una vez finalizados.

Para un laboratorio de este tipo, utiliza el worker más pequeño disponible y una cantidad máxima de 2 workers para minimizar costos.

🛠️ Continuemos con el Job real

Ahora que ya hemos validado la ejecución de nuestro primer AWS Glue Job, es momento de avanzar hacia el Job real, es decir, el código que implementa las transformaciones necesarias sobre el dataset.

En esta etapa pasamos de un Job de verificación a un Job funcional, cuyo objetivo es leer los datos desde la capa raw, limpiarlos, transformarlos y escribir el resultado en la capa curated.

🎯 Objetivo del Job

El Job realizará las siguientes acciones, en orden:

Importar las librerías necesarias

Incluiremos los módulos requeridos para trabajar con Spark y AWS Glue.
Inicializar una sesión de Spark

Esta sesión será la base sobre la cual se ejecutarán todas las operaciones de lectura, transformación y escritura de datos.
Definir la ruta de entrada en Amazon S3

Declararemos como variable el path donde se encuentra el archivo a transformar, correspondiente a la capa raw.
Cargar los datos en un DataFrame

Leeremos el archivo desde S3 y cargaremos su contenido en un DataFrame de Spark (puedes pensarlo como una tabla en memoria).

Indicaremos que la primera fila del archivo contiene los headers de las columnas.

Antes de aplicar cualquier transformación de tipo de dato, realizaremos una limpieza previa. Las columnas de precio contienen caracteres no numéricos, por lo que primero eliminaremos símbolos y valores indeseados mediante una función de limpieza, y solo después aplicaremos el type casting correspondiente.

Filtrar registros con valores nulos

Eliminaremos las filas cuyo valor en la columna marketprice sea nulo, ya que no aportan valor para el análisis ni para el entrenamiento posterior del modelo.
Escribir el resultado en la capa curated

Finalmente, persistiremos el DataFrame transformado en Amazon S3, dentro del prefijo correspondiente a la capa curated.

💡 Pro Tip

Antes de aplicar transformaciones y escribir los datos de salida, es una buena práctica ejecutar un df.show().

Esto nos permite visualizar los datos y validar los tipos asociados a cada columna. En este punto, y dado que estamos leyendo un archivo CSV, observarás que todas las columnas se interpretan inicialmente como strings, lo cual refuerza la necesidad de realizar las transformaciones de tipo de dato de forma explícita.

A continuación, revisaremos el código final del Job. Incluiré comentarios en cada sección para que el flujo sea más sencillo de seguir y puedas identificar claramente el propósito de cada bloque.

# Importamos las librerías mínimas
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, regexp_replace

# Abrimos la sesión de Spark
spark = SparkSession.builder.getOrCreate()

# En esta variable dejamos la ruta del archivo que esperamos cargar
ruta_s3 = "s3://poctarjetasprecios/raw/BaseSetProductsAndPrices.csv"

# Cargamos el DataFrame indicando que la primera fila contiene los headers
df = spark.read.option("header", "true").csv(ruta_s3)

# En este vector definimos las columnas a limpiar y convertir
# En este paso solo se define el plan de ejecución; Spark aún no aplica las transformaciones
price_columns = [
    "lowPrice",
    "midPrice",
    "highPrice",
    "marketPrice",
    "directLowPrice"
]

for c in price_columns:
    df = df.withColumn(
        c,
        regexp_replace(col(c), "[^0-9.]", "").cast("double")
    )

# Filtramos únicamente los registros con marketPrice no nulo
df = df.filter(col("marketPrice").isNotNull())

# Definimos la ruta de salida en la capa curated
ruta_curated = "s3://poctarjetasprecios/curated/product_prices2/"

# Ahora sí, Spark ejecuta el plan definido y
df.write.mode("overwrite").parquet(ruta_curated)

Esto ya transforma nuestro archivo.

Ahora necesitamos el Crawler.

🗂️ Creación del Glue Crawler

Posteriormente, procedí a crear el Glue Crawler, configurando los siguientes parámetros clave:

🏷️ Nombre del crawler

Identificador claro y descriptivo.
🪣 Fuente de datos (Data Source)

Amazon S3, apuntando específicamente al prefijo donde se encuentra el dataset curated.
🧾 Prefijo para el nombre de la tabla

Definido para mantener consistencia y evitar confusiones en el catálogo.
⏱️ Frecuencia de ejecución

Configurado para ejecutarse bajo demanda, con el objetivo de evitar ejecuciones innecesarias y posibles impactos en la facturación.
🔐 Rol de IAM

El rol asociado al crawler debe contar, como mínimo, con permisos de lectura sobre el bucket de S3 donde residen los datos, además de permisos para escribir metadatos en el Glue Data Catalog.

🔁 Orquestación del flujo con AWS Glue Workflow

Una vez validado el Glue Job de transformación, el siguiente paso fue orquestar el flujo completo utilizando AWS Glue Workflow. El objetivo no es solo ejecutar tareas de forma aislada, sino definir explícitamente el orden y la dependencia entre ellas, algo fundamental en cualquier proceso de preparación de datos.

El workflow implementado sigue una lógica simple pero correcta:

Inicio del flujo

El workflow se dispara de forma controlada (manual o posteriormente mediante eventos), actuando como punto de entrada del proceso.
Ejecución del Glue Job

El Glue Job se encarga de leer los datos desde la zona raw en Amazon S3, realizar transformaciones mínimas y escribir el resultado en la zona curated.
Trigger condicional

Se utiliza un trigger condicional para garantizar que el siguiente paso solo se ejecute si el Glue Job finaliza correctamente.

Esta validación es importante para evitar catalogar datos incompletos o inconsistentes en caso de fallos durante la transformación.
Ejecución del Glue Crawler

Finalmente, el Glue Crawler escanea los datos ya procesados en la capa curated y actualiza el Glue Data Catalog. De esta forma, los datos quedan disponibles para su consumo posterior mediante servicios como Amazon Athena.

🧩 Separación de responsabilidades

Este enfoque permite desacoplar responsabilidades de forma clara:

🛠️ El Job se enfoca en la transformación.
🗂️ El Crawler se enfoca en el descubrimiento y la catalogación.
🔁 El Workflow define la secuencia y las dependencias entre ambos.

💡 Pro Tip

Ejecuta el workflow de manera separada antes de integrarlo con el pipeline. De esta forma podrás validar que este componente se ejecuta correctamente de manera aislada.

Último paso: automatización con Amazon EventBridge

El paso final del laboratorio consiste en utilizar Amazon EventBridge para disparar automáticamente el flujo cada vez que un nuevo archivo es cargado en Amazon S3.

En teoría, esta es la parte más sencilla; en la práctica, fue la que más tiempo me tomó resolver.

Y vale la pena decirlo abiertamente: el problema no fue técnico, sino de orden. Pasé por alto dos aspectos básicos:

Los permisos necesarios para que AWS Glue pudiera ser invocado.
La habilitación de notificaciones de eventos desde S3.

Esta experiencia deja una lección importante: antes de asumir que el problema es complejo, conviene revisar siempre lo más evidente, especialmente permisos e integraciones entre servicios.

Dado que estos prerrequisitos ya habían sido configurados al inicio del laboratorio, el último paso se redujo a crear una regla en Amazon EventBridge con la siguiente lógica:

Origen del evento: Amazon S3
Tipo de evento: Creación de objetos (Object Created)
Destino: AWS Glue Workflow

Con esta configuración, cada vez que un archivo nuevo ingresa al bucket (o prefijo) definido, el workflow se ejecuta automáticamente, iniciando el proceso de transformación y catalogación de datos.

Destinos del evento

Amazon EventBridge permite configurar hasta cinco destinos por regla.

En este caso, además del Glue Workflow, se habilitó Amazon CloudWatch únicamente con fines de observabilidad y validación del evento, aunque no es estrictamente necesario para el funcionamiento del flujo.

A partir de este punto, el proceso queda completamente automatizado:

cada nuevo archivo que llega a S3 desencadena todas las acciones esperadas sin intervención manual, cerrando así el ciclo completo de ingesta, transformación y catalogación.

Conclusiones

Una vez finalizado este laboratorio, se logra implementar una automatización de extremo a extremo para la preparación de un conjunto de datos, integrando varios servicios administrados de AWS y entendiendo el rol específico que cada uno cumple dentro del pipeline.

El uso de AWS Glue Jobs resulta especialmente adecuado cuando se trabaja con datasets de tamaño considerable, donde el procesamiento distribuido de Spark permite escalar transformaciones de forma eficiente.

Por su parte, AWS Glue Workflow simplifica la orquestación del proceso, permitiendo definir dependencias claras entre tareas sin necesidad de introducir herramientas adicionales de orquestación.

Como en toda arquitectura de datos, todo se trata de trade-offs. Elegir Glue implica aceptar ciertos tiempos de arranque y costos asociados a la infraestructura gestionada, a cambio de reducir la complejidad operativa y el mantenimiento.

Durante el desarrollo del laboratorio, hay varios puntos clave que conviene tener siempre presentes:

Spark no ejecuta las transformaciones inmediatamente.

Las operaciones se evalúan de forma perezosa (lazy evaluation) y solo se materializan cuando se ejecutan acciones definitivas como write, show o count. Tener esto claro ayuda a entender el comportamiento del job y a razonar sobre su desempeño.
Los permisos y las relaciones de confianza entre servicios son críticos.

La correcta configuración de IAM roles, policies y trust relationships entre S3, Glue y EventBridge es indispensable para evitar fricciones innecesarias al implementar el pipeline.
Optimización de costos en laboratorios.

Para fines didácticos, es recomendable utilizar el tipo y la cantidad de workers más económicos posibles, evitando dejar los valores por defecto y controlando activamente los costos.
Tiempo de arranque de AWS Glue Jobs.

Los Glue Jobs requieren tiempo para aprovisionar la infraestructura. Un tiempo inicial de arranque es normal y no debe generar alarma; sin embargo, es importante verificar siempre que los jobs finalicen correctamente y no queden en estado running o stopped de forma inesperada.

En conjunto, este laboratorio no solo permite construir un pipeline funcional, sino también comprender mejor las decisiones técnicas y operativas que acompañan el uso de servicios administrados para la preparación y automatización de datos en AWS.

[Boost]

Diana Castro — Mon, 22 Dec 2025 17:28:14 +0000

Diana Castro for AWS Community Builders

Dec 22 '25

Diario de una builder: Preparándonos para AWS Machine Learning desde cero – Preparando Datos

#aws #ai #machinelearning #beginners

Comments

15 min read

Diario de una builder: Preparándonos para AWS Machine Learning desde cero – Preparando Datos

Diana Castro — Mon, 22 Dec 2025 15:40:06 +0000

Resumiendo de forma muy práctica, el ciclo de vida de machine learning puede dividirse en tres grandes fases: preparación de los datos, entrenamiento del modelo e implementación (inferencia).

De estas tres, la preparación de los datos suele ser la más crítica, ya que define directamente la calidad de los resultados obtenidos.

La preparación de datos, a su vez, incluye varias subetapas: obtención de los datos, limpieza y transformación. Como ocurre en cualquier sistema, si los datos de entrada son deficientes, la calidad del modelo resultante será, como mínimo, cuestionable.

Por ello, y como lo prometido es deuda, en esta segunda parte del artículo nos enfocaremos exclusivamente en el proceso de preparación de datos. Desarrollaremos un pequeño laboratorio práctico en el que trabajaremos un conjunto de datos que, más adelante, podría servir como insumo para entrenar un modelo de machine learning.

Desde la perspectiva del examen AWS Machine Learning Associate, se espera que el candidato sea capaz de seleccionar las herramientas adecuadas para la preparación de datos, así como demostrar familiaridad con servicios como SageMaker Data Wrangler y AWS Glue. Con ese objetivo, el ejercicio que presento a continuación es de carácter meramente académico y busca recorrer este proceso de forma guiada y estructurada.

Antes de poner manos a la obra, revisemos brevemente qué nos dice la teoría sobre el proceso de preparación de datos en AWS y las decisiones que debemos tomar.

a. Obtención de los datos

La selección de los datos es fundamental, así como la elección del repositorio de almacenamiento. Podemos trabajar con datos públicos —como lo haré en este laboratorio— o con datos propios de la organización.

La elección del almacenamiento dependerá de factores como:

El volumen de datos
La frecuencia de actualización
Los servicios que se planea utilizar posteriormente

b. Limpieza de los datos

Para mejorar el entrenamiento de los modelos, es indispensable revisar y limpiar los datos según sea necesario. Por ejemplo, es común encontrar filas donde variables clave contienen valores nulos; en estos casos, puede ser conveniente eliminarlas.

Es importante aclarar que la limpieza debe realizarse con criterio: no se trata de reducir la muestra, sino de mejorar su calidad. Si una columna no aporta información relevante o puede inducir al modelo a conclusiones erróneas, es preferible descartarla.

Otro aspecto clave es la cardinalidad de las columnas. Las columnas de alta cardinalidad —aquellas con muchos valores únicos— pueden introducir complejidad innecesaria y aumentar el riesgo de overfitting, es decir, que el modelo memorice patrones en lugar de aprender relaciones generalizables.

En el caso de las cartas de colección, el nombre de la carta es un buen ejemplo de este dilema. Aunque el nombre puede estar asociado a personajes populares, es un valor prácticamente único. El modelo podría inferir incorrectamente que un personaje principal siempre implica un alto precio, cuando en realidad muchas cartas de ese mismo personaje tienen un valor muy bajo.

Esto provoca que el modelo memorice en lugar de aprender variables verdaderamente relevantes como la rareza o si la carta es considerada un hit por los coleccionistas.

c. Transformación de los datos

Finalmente, para mejorar el rendimiento del modelo, suele ser necesario transformar los datos. Esto puede implicar dividir columnas, combinarlas o cambiar su representación.

Recuerdo un dataset de características de automóviles en el que toda la información relevante estaba concentrada en una sola columna. En ese caso, tenía mucho más sentido transformar esa columna en atributos separados como número de puertas, tipo de combustible o tipo de vehículo, facilitando así el aprendizaje del modelo.

SageMaker AI y las herramientas recomendadas para Machine Learning en AWS

Desde el 3 de diciembre de 2024, Amazon SageMaker pasó a denominarse Amazon SageMaker AI. Más allá del cambio de nombre, el servicio se consolida como una plataforma totalmente gestionada que permite construir, entrenar y desplegar modelos de machine learning de forma eficiente, integrándose de manera nativa con el resto de servicios de AWS.

SageMaker AI no es una herramienta aislada, sino el núcleo de un ecosistema de servicios diseñado para cubrir todo el ciclo de vida de machine learning: desde la preparación de los datos hasta la inferencia en producción.

Esta visión integral es precisamente la que se evalúa en el examen AWS Machine Learning Associate, donde no solo se espera conocer los modelos, sino también cuándo y por qué utilizar cada herramienta.

El proceso de preparación de datos algunas recomendaciones

La preparación de los datos abarca los procesos de recopilación, preprocesamiento y organización de los mismos, y su propósito es que cuando se utilicen para entrenar un modelo estos ayuden a que el modelo aprenda de forma eficaz y correcta.

Tal y como comentamos previamente, este proceso implica limpiar (eliminar, cambiar, completar) datos y transformaciones, analizar valores atípicos y verificar qué hacer con ellos (outliners). En mi caso, mi muestra de datos tiene muchos outliners, pero así son las tarjetas: unas valen para el mercado $0.1 y otras $300.

Dependiendo de nuestros datos y situación, tenemos disponibles toda una gama de opciones, las cuales analizaremos a continuación.

AWS ofrece distintas capacidades dentro de SageMaker AI para la preparación de datos, pensadas para perfiles y necesidades diferentes. De forma práctica, estos escenarios pueden agruparse en tres casos de uso principales:

Caso de uso 1: Preparación visual y de bajo código

SageMaker Canvas con Data Wrangler ofrece una opción donde es posible explorar, limpiar y transformar datos tabulares sin necesidad de programar, utilizando transformaciones integradas y, en algunos casos, instrucciones en lenguaje natural asistidas por IA generativa.

Cuándo usarlo

Exploración y limpieza de datasets pequeños o medianos
Creación rápida de pipelines de preparación de datos
Equipos con poca experiencia en Python o Spark

Consideraciones

Menor flexibilidad para lógica de negocio compleja
No es ideal si el equipo ya trabaja cómodamente con código

Caso de uso 2: Preparación basada en SQL y Python

Studio está orientado a usuarios con experiencia técnica que desean mayor control y flexibilidad. Sin entrar en el ecosistema Spark, se pueden ejecutar consultas SQL sobre fuentes como Amazon Redshift, Athena, Snowflake o S3, y posteriormente manipular los resultados usando Python y Pandas en notebooks.

Cuándo usarlo

Datos almacenados en sistemas analíticos o data lakes
Combinación de SQL exploratorio con transformaciones en Python
Preparación de datos tabulares para modelos de ML

Consideraciones

Limitado por la memoria de la instancia de SageMaker
Diseñado principalmente para datos estructurados

Caso de uso 3: Preparación de datos a gran escala y sin servidor

EMR Serverless integrado con SageMaker Studio está dirigido a la preparación de datos distribuida. Permite ejecutar transformaciones a gran escala sobre grandes volúmenes de datos mediante frameworks como Apache Spark y Apache Hive, sin necesidad de gestionar clústeres.

Cuándo usarlo

Grandes volúmenes de datos
Necesidad de procesamiento distribuido
Cargas de trabajo interactivas o de corta duración basadas en Spark

Consideraciones

Curva de aprendizaje más alta
Requiere control de costos en cargas prolongadas
No sustituye EMR tradicional para procesos complejos o de larga duración

Manos a la obra: dataset y exploración inicial

Ahora sí, manos a la obra. Para este laboratorio recurrí a mi hijo, mi coleccionista de tarjetas favorito, y descargué un archivo de tamaño relativamente pequeño que contiene información histórica y de mercado sobre tarjetas coleccionables.

El dataset incluye atributos como precio histórico, precio de mercado, rareza, nombre, código y otras características relevantes de cada carta.

Una vez identificado el conjunto de datos, mi coleccionista estrella me ayudó a destacar cuáles son las características clave que suelen definir las cartas más valiosas: niveles de rareza, cartas hits y otros atributos especialmente apreciados por la comunidad. Con esta información como contexto, procedí a realizar una primera exploración del dataset.

Cabe mencionar que la fuente de datos se encuentra en formato CSV. Como recordarán del artículo anterior, este formato es fácil de leer, compartir y generar, pero no es el más eficiente para el entrenamiento de modelos de machine learning.

Tras la revisión inicial, observé que el conjunto de datos cuenta con pocas columnas y un número reducido de filas, lo cual lo convierte en un candidato ideal para realizar tareas de limpieza, exploración y transformación utilizando SageMaker Data Wrangler como herramienta principal.

Configuración inicial y conceptos clave

Si no has trabajado previamente con SageMaker AI o SageMaker Canvas, será necesario realizar una configuración inicial rápida. Para este laboratorio, la configuración de un solo usuario es suficiente.

Esta opción utiliza valores predeterminados y permite comenzar a trabajar tanto en SageMaker Studio como en Canvas sin configuraciones avanzadas.

Durante este proceso deberás crear un SageMaker Domain, que actúa como el contenedor lógico donde se organizan los perfiles de usuario, las aplicaciones y los recursos asociados.

Un dominio está compuesto principalmente por:

Un volumen asociado de Amazon Elastic File System (Amazon EFS)
Una lista de usuarios autorizados
Configuraciones de seguridad, aplicaciones, políticas y una Amazon VPC

Primer paso: datos crudos

El dataset ha sido cargado previamente en Amazon S3, donde se manejará la data cruda.

Es importante destacar que el rol de IAM asociado al dominio de SageMaker debe contar con permisos de acceso a S3. De lo contrario, no será posible cargar los datos ni exportar los resultados generados durante el laboratorio.

Segundo paso: exploración de los datos con SageMaker Data Wrangler

Dado que nuestro dataset es de tamaño reducido y el objetivo es obtener insights iniciales, la herramienta más adecuada en este escenario es SageMaker Data Wrangler, que proporciona una solución end-to-end para importar, preparar, transformar, caracterizar y analizar datos.

Conforme avancemos en nuestro laboratorio, exploraremos diversas funcionalidades de Data Wrangler.

Para este laboratorio hice uso de SageMaker Canvas. Una vez ahí, se selecciona Data Wrangler. Al iniciar, haremos uso de su primera funcionalidad: Importación, la cual nos permitirá traer nuestro set de datos desde una amplia variedad de fuentes, entre las que se incluyen:

Amazon S3
Amazon Redshift
Amazon RDS
DynamoDB
Archivos locales

En este laboratorio, el dataset se carga directamente desde Amazon S3, aunque también es posible importar archivos desde el almacenamiento local de tu dispositivo si el escenario lo requiere.

Exploración visual y entendimiento de la muestra

La interfaz de Data Wrangler funciona bajo un esquema point and click, lo que facilita moverse entre distintas vistas:

Vista de datos
Flujo de procesamiento
Reportes de insights

Al observar los datos, es posible identificar de forma inmediata la distribución de valores por columna, lo que permite evaluar rápidamente la calidad de la muestra sin mayor esfuerzo.

Este paso es clave para entender si el dataset es representativo y si presenta problemas evidentes antes de avanzar.

Análisis del set de datos: Data Quality and Insights Report

Antes de aplicar cualquier proceso de limpieza o transformación, me apoyé en el Data Quality and Insights Report de SageMaker Data Wrangler. Este reporte proporciona un resumen automático y muy útil del estado general del dataset.

Para generarlo, únicamente fue necesario indicar la columna objetivo (Market Price) y el tipo de problema, que en este caso corresponde a regresión.

¿Por qué regresión?

Porque el objetivo del modelo es inferir un valor numérico continuo, por ejemplo: 0.3, 10, 20 o 300 dólares. Es decir, se busca predecir un valor monetario.

Si el objetivo hubiese sido asignar una etiqueta discreta, como “Rara” o “Común”, entonces estaríamos ante un problema de clasificación.

Hallazgos del Data Quality and Insights Report

Con estos parámetros definidos, el reporte generado arrojó, entre otros, los siguientes hallazgos relevantes:

71.9% de los valores del target no pudieron convertirse a numérico
5.42% de filas duplicadas
Skewness (asimetría): 4.81
Kurtosis: 23.4, lo que indica la presencia de valores extremos (outliers)

A primera vista, el reporte sugiere una alta presencia de valores atípicos. Sin embargo, este comportamiento es esperable y realista en el contexto de tarjetas coleccionables: muchas cartas tienen un valor muy bajo, mientras que unas pocas pueden alcanzar precios significativamente altos o incluso aumentar su valor con el tiempo.

En términos generales, el dataset no se encuentra en mal estado y refleja adecuadamente la naturaleza del dominio.

Más adelante abordaremos el tratamiento de valores extremos y columnas de alta cardinalidad (como los nombres). Por ahora, el principal problema identificado es la presencia de valores no numéricos en la variable objetivo, por lo que el siguiente paso se enfocará en la limpieza de estos valores antes de continuar con el proceso de preparación de datos.

Tercerpaso: Transformaciones y limpieza de datos

En el panel lateral se encuentra un conjunto de herramientas que permiten realizar transformaciones y tareas de limpieza de forma intuitiva.

El primer ajuste realizado fue la corrección de los tipos de datos. Todas las columnas del dataset fueron inicialmente identificadas como string, por lo que procedí a:

Cambiar las columnas relacionadas con precios a tipo float
Ajustar otras características numéricas a tipo long

Manejo de valores faltantes

Tal y como se mencionó en secciones previas, si una columna o fila no aporta valor o genera ruido, lo más recomendable es eliminarla.

En este caso, el objetivo del modelo será inferir el precio de mercado de una nueva carta, por lo que la variable objetivo es la columna Market Price.

Las columnas sin valor no aportan al entrenamiento, por lo que el siguiente paso fue eliminar los registros con valores faltantes utilizando la transformación Drop Missing, especificando la columna correspondiente y aplicando la transformación.

💡 Pro Tip 1: antes de aplicar cualquier transformación, es posible previsualizar el resultado utilizando la opción Preview.

Alta cardinalidad y estrategias de imputación

El dataset contenía varias columnas string de alta cardinalidad que no aportaban valor al modelo, por ejemplo:

Image URL
Clean Name
Name (esta se conservó solo con fines informativos, pero será eliminada antes del entrenamiento)

Finalmente, una columna clave relacionada con los hits presentaba valores únicamente para cartas especiales (poco frecuentes por colección), mientras que muchas cartas comunes tenían valores nulos.

Para este caso se aplicó la transformación Impute, asignando la media como estrategia de imputación.

En la interfaz visual de SageMaker Data Wrangler es posible visualizar el flujo completo de transformaciones aplicadas al dataset. Estas transformaciones pueden gestionarse directamente desde la vista del flujo o, si se prefiere un enfoque más exploratorio, desde la vista de datos, lo que facilita iterar y ajustar los cambios conforme se avanza en el proceso de preparación.

Una vez satisfecha con el resultado de la limpieza y transformación, el siguiente paso fue persistir el dataset curado. Aquí surge una pregunta clásica —y muy relevante para el examen—:

Si deseo entrenar un modelo posteriormente, ¿cuál es el formato de datos más adecuado?

👉 Pregunta de examen. Más adelante verás la elección.

Cuarto paso: Exportación del dataset curado

La conversión se realizó de forma muy sencilla utilizando la opción de exportación de Data Wrangler, tal y como se muestra en la interfaz.

Al tratarse ya de un dataset curado, le asigné el prefijo cu_, lo almacené en mi bucket de Amazon S3 y lo exporté en formato Parquet.

Adicionalmente:

No apliqué compresión, ya que el tamaño del dataset era reducido.
No definí particiones, dado que en este caso no existía una dimensión natural que justificara su uso.

Sin embargo, vale la pena aclarar el criterio detrás de las particiones. Por ejemplo:

En un dataset de reservaciones hoteleras, una partición por fecha tendría sentido.
En un dataset de expedientes clínicos, una partición por ID de paciente (identificador único) sería una opción razonable.

En este laboratorio, al tratarse de un conjunto de datos pequeño y con fines académicos, la partición no aportaba un beneficio claro, por lo que se decidió omitirla.

Quinto paso: Consultando los datos curados

Ahora que el dataset curado se encuentra almacenado en Amazon S3, el siguiente objetivo es consultar los datos utilizando Amazon Athena. Sin embargo, antes de llegar a ese punto, incorporaremos una herramienta clave dentro del ecosistema de datos en AWS y fundamental para el examen: AWS Glue.

Reconozco que, en este escenario particular, podría haberse omitido Glue y definido la tabla de Athena manualmente. No obstante, decidí incluir este paso porque permite introducir un concepto central en arquitecturas de datos modernas en AWS: los Crawlers y el Glue Data Catalog.

¿Qué es AWS Glue?

AWS Glue es un servicio de integración de datos totalmente gestionado que facilita la descubierta, preparación y catalogación de datos para análisis, machine learning y data engineering.

En este laboratorio utilizaremos Glue específicamente para descubrir el esquema del dataset y registrarlo de forma automática en el catálogo.

¿Qué es un Glue Crawler?

Un Glue Crawler es un componente que:

Recorre (crawl) datos almacenados en fuentes como Amazon S3
Inspecciona los archivos (CSV, Parquet, JSON, etc.)
Infiere automáticamente el esquema (columnas, tipos de datos, particiones)
Crea o actualiza tablas en el Glue Data Catalog

¿Qué es el Glue Data Catalog?

El Glue Data Catalog es un metastore centralizado que mantiene:

Bases de datos
Tablas
Esquemas
Ubicación de los datos en S3
Metadatos asociados

Este catálogo no almacena los datos en sí, únicamente los metadatos, y es utilizado por múltiples servicios de análisis y machine learning en AWS.

Este paso es necesario porque Athena no “lee” directamente S3 sin contexto. Necesita saber:

Dónde están los datos
Cómo están estructurados
Qué tipos de datos tienen las columnas

El Glue Data Catalog provee exactamente esa información. Al ejecutar un crawler:

Glue analiza el dataset en S3
Registra la tabla y su esquema en el Data Catalog
Athena puede consultar la tabla inmediatamente usando SQL estándar

Este enfoque no solo reduce errores, sino que además es altamente escalable y reutilizable, especialmente cuando los esquemas evolucionan o se incorporan nuevas particiones.

Desde una perspectiva de examen, es importante recordar que:

Glue Crawlers automatizan el llenado del catálogo
Athena depende del Data Catalog
El catálogo desacopla el almacenamiento (S3) del análisis

En el siguiente paso, con el crawler ejecutado y la tabla registrada, ya estaremos listos para consultar nuestro dataset curado directamente desde Athena.

Configuración del Glue Crawler

Antes de ejecutar el crawler, fue necesario completar una serie de pasos previos que permiten organizar y catalogar correctamente los datos que luego serán consumidos por Athena. A continuación, detallo el proceso que llevé a cabo.

1. Creación de la base de datos en el Glue Data Catalog

En primer lugar, creé una base de datos en el Glue Data Catalog. Esta base de datos actúa como un contenedor lógico de tablas, similar a un esquema en bases de datos relacionales.

Definí que esta base de datos estuviera asociada al bucket de Amazon S3 donde se almacenan los datasets. Es importante aclarar que esta asociación es meramente académica; en la práctica, el Data Catalog puede referenciar datos ubicados en múltiples buckets y prefijos.

2. Creación del Glue Crawler

Posteriormente, procedí a crear el crawler, configurando los siguientes parámetros clave:

Nombre del crawler: identificador claro y descriptivo
Fuente de datos (Data Source): Amazon S3, apuntando específicamente al prefijo donde se encuentra el dataset curado
Prefijo para el nombre de la tabla: definido para mantener consistencia y evitar confusiones en el catálogo
Frecuencia de ejecución: configurado para ejecutarse bajo demanda, con el objetivo de evitar ejecuciones innecesarias y posibles impactos en la facturación
Rol de IAM: el rol asociado al crawler debe contar, como mínimo, con permisos de lectura sobre el bucket de S3 donde residen los datos, además de permisos para escribir metadatos en el Glue Data Catalog

3. Ejecución del crawler

Una vez completada la configuración, el crawler se ejecuta manualmente. Al finalizar:

Glue analiza los archivos almacenados en S3
Infiere el esquema (columnas, tipos de datos y, si aplica, particiones)
Crea o actualiza la tabla correspondiente en el Glue Data Catalog

Con el catálogo poblado correctamente, ya contamos con toda la información necesaria para avanzar al siguiente paso: consultar el dataset curado desde Amazon Athena y empezar a responder preguntas interesantes sobre el mundo de las tarjetas coleccionables utilizando SQL.

Consulta del dataset curado con Amazon Athena

Finalmente, con el Glue Data Catalog poblado, podemos avanzar a Amazon Athena.

Al ingresar a Athena, únicamente es necesario seleccionar la base de datos creada previamente en el Data Catalog. A partir de ese momento, Athena descubre automáticamente las tablas generadas por el crawler y las deja disponibles para su consulta.

Desde Athena ya es posible ejecutar consultas SQL estándar sobre el dataset curado que construimos a lo largo del laboratorio, sin necesidad de mover o duplicar los datos.

Athena consulta directamente los archivos almacenados en Amazon S3, apoyándose en los metadatos definidos en el Data Catalog para interpretar correctamente el esquema.

💡 Pro Tip 2: Una vez finalizado el trabajo en SageMaker Canvas / Data Wrangler, es fundamental cerrar la aplicación y no dejarla abierta innecesariamente.

Al hacerlo, te aseguras de que no queden jobs activos en segundo plano, ya que los costos en este laboratorio están directamente asociados a la ejecución de Jobs.
Amazon Athena: costo por volumen de datos escaneados en las consultas (beneficiado por el uso de Parquet)

Conclusiones importantes

SageMaker Data Wrangler es una herramienta sumamente sencilla de utilizar, y en conjunto con SageMaker Canvas, contribuye de forma clara a democratizar el análisis y la preparación de datos.

Sin embargo, más allá de la facilidad de uso, es fundamental recordar que cuando se trabaja con datos crudos, estos deben analizarse, limpiarse y transformarse con criterio. No todo se debe eliminar, ni todo se debe conservar: el contexto del problema y el objetivo del modelo son determinantes.

La selección de la herramienta adecuada es un punto clave y siempre dependerá del caso de uso, del volumen de datos, del nivel de especialización del equipo y de los recursos disponibles.

Con este laboratorio práctico logramos recorrer un flujo completo y realista en AWS:

Preparamos y limpiamos los datos con SageMaker Data Wrangler
Catalogamos el dataset utilizando AWS Glue Crawlers
Analizamos la información de forma interactiva con Amazon Athena

Este patrón es ampliamente utilizado en arquitecturas de analytics y machine learning en AWS, y resume de manera práctica cómo los servicios trabajan de forma integrada para convertir datos crudos en información lista para análisis y entrenamiento de modelos.

Como puedes observar, a lo largo del proceso también aparecen trade-offs importantes: facilidad de uso versus flexibilidad, automatización versus control, costo versus escalabilidad, que no solo se evalúan en los exámenes de certificación, sino también en escenarios reales de la vida profesional.

Diario de una builder: Preparándonos para AWS Machine Learning desde cero

Diana Castro — Fri, 19 Dec 2025 22:57:18 +0000

Me gusta compartir mi experiencia en la preparación de certificaciones, especialmente cuando el objetivo es construir criterio y no únicamente aprobar un examen. Al final, el valor no está en la certificación en sí, sino en el conocimiento que se adquiere durante el proceso y en cómo este se traduce en crecimiento profesional.

Actualmente estoy enfocada en obtener las certificaciones de Machine Learning y AI Developer en AWS y, siguiendo las buenas prácticas, recorro con cuidado las guías oficiales de cada examen.

En este diario documento el camino que sigo para aterrizar conceptos que suelen parecer abstractos cuando se estudian de manera aislada. En más de una ocasión, durante un examen de certificación, aparece alguno de esos detalles trabajados previamente, y es ahí donde confirmo que aprender construyendo realmente marca la diferencia.

A través de esta serie de artículos comparto ese proceso para que, si estás comenzando en Machine Learning en AWS, puedas apoyarte en experiencias reales y en un enfoque práctico para transitar este camino de aprendizaje.

Formatos de datos: un tema menos glamoroso, pero crítico

Quiero comenzar por un tema que suele parecer secundario hasta aburrido de abordar, pero que tiene un impacto directo tanto en los laboratorios, en el entrenamiento de modelos y por supuesto en las certificaciones: los formatos de datos.

¿Por qué debe importarnos el formato de los datos?

Es común encontrar preguntas en el examen donde no se evalúa un algoritmo, sino la capacidad de elegir cómo almacenar, procesar y consumir los datos dentro de un flujo de Machine Learning en AWS. En escenarios prácticos, la elección del formato impacta directamente en:

El rendimiento de los procesos
Los costos asociados
La capacidad de escalar una solución

El primer dominio del examen está relacionado con Data Preparation for Machine Learning, lo que incluye actividades como la ingesta y el almacenamiento de datos. En este contexto comienzan a aparecer conceptos como formatos de datos validados y no validados, tal como se describen en la guía oficial del examen.

Más allá de memorizar definiciones, este dominio busca que desarrolles criterio para:

Cuándo escoger un formato de datos sobre otro
Para qué tipos de cargas de trabajo son más efectivos
En qué casos de uso aplican dentro de un flujo de ML
Con qué servicios y herramientas de AWS son compatibles o no

Entender estos puntos no solo te ayudará a responder preguntas del examen, sino también a tomar mejores decisiones cuando construyas soluciones reales de Machine Learning en AWS.

Iniciando con algo de teoría

Antes de profundizar en los distintos formatos de datos y sus fortalezas, es importante aclarar algunos conceptos que aparecen de forma recurrente en el examen de AWS Machine Learning.

Formatos validados

Son aquellos formatos que AWS soporta de manera nativa para procesos de entrenamiento, procesamiento o inferencia, y cuyo uso está documentado oficialmente en los servicios correspondientes, como Amazon SageMaker.

Formatos no validados

Son formatos que, aunque pueden almacenarse en Amazon S3 u otros servicios de AWS, requieren transformaciones adicionales antes de poder ser utilizados dentro de un flujo de Machine Learning.

Una vez clara esta distinción, es necesario repasar otro concepto fundamental: la forma en que los datos se organizan internamente. A grandes rasgos, los formatos de datos pueden clasificarse según si almacenan la información por filas (row-based) o por columnas (column-based), una diferencia que tiene un impacto directo en el rendimiento y en los costos cuando trabajamos con Machine Learning.

Una analogía de la vida real: tarjetas coleccionables

Me gusta mucho trabajar con analogías y ejemplos prácticos. Últimamente, mi hijo se ha convertido en un coleccionista experto de tarjetas Pokemon, así que permíteme compartir un ejemplo de mi vida cotidiana.

Para un coleccionista, cada tarjeta es un elemento único que consta de varios atributos importantes para definir su valor: nombre, código, tipo y rareza (créeme, hay muchos más atributos como brillo, edición o estado, pero no nos compliquemos).

Enfoque orientado a filas (Row-based)

En un enfoque orientado a filas, cada tarjeta se almacena como una unidad completa, con todos sus atributos juntos:

Tarjeta A: tipo eléctrico, rareza común
Tarjeta B: tipo dragón, rareza rara
Tarjeta C: tipo psíquico, rareza especial

Desde la perspectiva del coleccionista, este enfoque es ideal cuando:

Quiere revisar una tarjeta específica
Necesita conocer todas las características de una carta en particular
Agrega nuevas cartas a su colección una por una

En los álbumes de mis hijos, cada compartimiento contiene una carta completa. Este enfoque es eficiente cuando se trabaja con registros individuales, pero no es óptimo para analizar grandes volúmenes de tarjetas al mismo tiempo.

Enfoque orientado a columnas (Column-based)

En un enfoque orientado a columnas, los atributos de las tarjetas se almacenan por separado:

Todos los nombres juntos
Todos los tipos juntos
Todas las rarezas juntas
Todos los niveles juntos

Desde la perspectiva del coleccionista, este enfoque resulta ideal cuando quiere:

Encontrar todas las cartas de cierto tipo
Analizar la distribución de rarezas en su colección
Identificar patrones o tendencias dentro de un conjunto grande de cartas

Es como reorganizar la colección para analizarla: en lugar de ver carta por carta, se agrupan los atributos para poder comparar rápidamente.

Formato	Organización	¿Validado?	Casos de uso típicos	¿Comprimido?	Servicios AWS comunes	Observaciones
JSON	Row-based	Sí	Ingesta de eventos, datos semi-estructurados, APIs	No por defecto (puede comprimirse)	S3, Kinesis, Lambda, SageMaker	Legible para humanos. Soporta datos estructurados y semi-estructurados. Mayor latencia de parsing y overhead de tamaño.
CSV	Row-based	Sí	Datasets pequeños, prototipos, carga inicial	No por defecto (puede comprimirse)	S3, SageMaker, Glue	No soporta esquema ni estructuras complejas. Fácil de producir y consumir, pero poco eficiente a gran escala.
RecordIO	Binario	Sí	Entrenamiento optimizado en SageMaker	Sí	SageMaker	Serializado binario, eficiente y secuencial. No legible para humanos. Requiere procesamiento previo.
Parquet	Column-based	Sí	Big Data, entrenamiento ML, análisis	Sí (compresión columnar)	S3, Glue, Athena, SageMaker	Muy eficiente para consultas y ML. Ideal para grandes volúmenes. No todos los algoritmos built-in lo soportan directamente.
Avro	Row-based	No	Streaming, intercambio de datos	Sí	S3, Kafka (MSK), Glue	Común en pipelines con Kafka. Requiere transformación previa. No recomendado para entrenamiento directo en SageMaker.

Esta tabla resume uno de los criterios más importantes que evalúa el examen: no todos los formatos sirven para todo. Elegir correctamente implica entender el volumen de datos, el tipo de procesamiento y el servicio de AWS involucrado.

Practiquemos para el examen

Una empresa está construyendo un pipeline de Machine Learning en AWS para entrenar un modelo de clasificación utilizando un dataset de varios terabytes almacenado en Amazon S3.

El equipo necesita reducir el tiempo de entrenamiento y minimizar los costos de I/O, ya que el modelo solo utiliza un subconjunto de las columnas disponibles en el dataset.

¿Cuál es el formato de datos más adecuado para este escenario?

A. CSV, porque es fácil de producir y compatible con la mayoría de los servicios de AWS

B. JSON, porque permite manejar datos semi-estructurados de forma flexible

C. Parquet, porque almacena los datos de forma columnar y permite leer solo las columnas necesarias

D. Avro, porque es eficiente para intercambio de datos en sistemas distribuidos

Respuesta correcta

Parquet es un formato column-based y comprimido, lo que permite que los procesos de entrenamiento y análisis lean únicamente las columnas requeridas por el modelo. Esto reduce significativamente el I/O, mejora el rendimiento y disminuye los costos, especialmente cuando se trabaja con grandes volúmenes de datos en Amazon S3 y servicios como Amazon SageMaker, Athena o AWS Glue.

Otra historia hubiera sido si la pregunta estuviera enfocada en eventos en tiempo real, si no se enfocara en entrenamiento directo sino en ingesta.

Este pequeño mapa mental puede servir como recordatorio rápido del propósito de los principales formatos de datos, tanto para el examen como para la toma de decisiones en proyectos reales.

Conclusión

Entender cuándo usar un formato orientado a filas o a columnas, distinguir entre formatos validados y no validados, y reconocer el propósito de cada uno dentro de un pipeline permite desarrollar el criterio que el examen busca evaluar. Ese mismo criterio es el que luego se traduce en mejores decisiones técnicas cuando diseñamos soluciones de Machine Learning en entornos productivos.

Este es solo el primer paso del diario. A partir de aquí, el foco estará en cómo transformar, preparar y consumir estos datos.

Estamos incorporando la IA de forma correcta a nuestras organizaciones, el rumbo lo dirige la necesidad del negocio o implementamos por subirnos a la ola tecnológica. Qué criterios considerar para que la IA generativa tenga el impacto que deseamos?

Diana Castro — Wed, 27 Aug 2025 20:36:06 +0000

Diana Castro for AWS Community Builders

Aug 27 '25

Cómo incorporar IA generativa de manera estratégica: metodología para transformar ideas en resultados reales

#aws #ai #cloudcomputing

Comments 1

6 min read

Cómo incorporar IA generativa de manera estratégica: metodología para transformar ideas en resultados reales

Diana Castro — Wed, 27 Aug 2025 20:06:55 +0000

La inteligencia artificial está presente en nuestro día a día y ha llegado para quedarse. Ya no es opcional: se ha convertido en la herramienta que marca la diferencia y que tiene el potencial de potenciar nuestras capacidades. En particular, la inteligencia artificial generativa no solo acelera resultados, sino que nos permite enfocarnos en lo que realmente importa.

De acuerdo con diversos estudios, el 63% de las organizaciones planea incorporar IA en sus operaciones cotidianas. El dilema actual ya no es si adoptarla, sino cómo hacerlo de la manera correcta.

Sin embargo, lo preocupante es que un porcentaje muy alto de estos proyectos no prospera: se estima que hasta un 95% fracasa. Una de las principales razones es la forma equivocada en que se está incluyendo esta tecnología en las organizaciones. Muchas veces la adopción responde más a la ansiedad de “no quedarse atrás” o a la necesidad de parecer innovadores, que a un análisis real de las necesidades del negocio.

La prisa por “subirse al tren de la IA” nos lleva a aplicar la tecnología como una solución universal, cuando en realidad no lo es. La pregunta clave no debería ser:

“Cómo usamos IA en lo que sea”

sino

“Cuáles son nuestros verdaderos problemas y si la IA es la solución adecuada para ellos”.

La IA debe integrarse para marcar una diferencia estratégica, no solo para seguir una moda.

Cómo decidir de manera más acertada sobre la incorporación de la IA

No existe una receta mágica ni un antídoto infalible para evitar fracasos en proyectos de inteligencia artificial. Cada iniciativa es única y está influenciada por múltiples factores. Sin embargo, antes de embarcarnos en cualquier implementación, es fundamental aplicar una serie de filtros que nos ayuden a discernir si realmente tenemos un caso de uso adecuado, si es viable y si nuestras expectativas están bien definidas. Solo así podremos tomar decisiones informadas.

Paso 1: Identificar problemas reales, dolores reales

El punto de partida no debe ser la tecnología, sino las necesidades auténticas del negocio o de tu día a día. Son esos “dolores” los que deben marcar el rumbo.

Detectar áreas de mejora que resuelvan una problemática concreta permite justificar la inversión y definir con claridad qué buscamos resolver y cuál es el resultado esperado. En otras palabras, las decisiones deben ser guiadas por necesidades reales y no por la moda tecnológica.

Si pensamos en inteligencia artificial generativa, conviene analizar el entorno y hacerse preguntas como:

¿Existen procesos repetitivos que consumen demasiado tiempo?
¿Hay tareas que limitan el enfoque en lo realmente importante?
¿De qué actividades tediosas y costosas nos gustaría deshacernos?

Ejemplo:

Imagina un equipo especializado de investigadores que, en lugar de profundizar en sus líneas de estudio, pasa gran parte del día respondiendo consultas académicas básicas. La información está dispersa en miles de documentos, y gran parte de su jornada se destina a recopilar y compilar material. Este tipo de tareas repetitivas y de bajo valor estratégico son candidatas ideales para ser optimizadas con IA generativa.

En la experiencia de usuario, podemos mejorar la atención interna y externa: equipos de soporte responden preguntas repetitivas en lugar de mejorar plataformas. Automatizar estas consultas con IA maximiza el uso del tiempo de los recursos técnicos y agiliza la atención del usuario final.

Paso 2: Medir el impacto potencial

Un principio clave: lo que no se mide, no se puede mejorar. Muchas iniciativas de IA no fracasan porque la tecnología no funcione, sino porque no logran demostrar un retorno de inversión que justifique los recursos involucrados.

Al identificar los puntos de mejora, debemos establecer un ranking de beneficios esperados, definiendo desde el inicio cómo mediremos el impacto. Algunos criterios útiles son:

Tiempo ahorrado: Horas de trabajo liberadas en el equipo.
Reducción de costos: Eliminación de procesos manuales que abaratan producción, servicio o tiempos de entrega.
Incremento de ingresos: Nuevas capacidades o mejor experiencia del cliente que se traduzca en mayores ventas o retención.
Mejora de calidad: Reducción de errores, mayor consistencia y experiencia confiable.
Escalabilidad: Capacidad de atender un mayor volumen de trabajo sin aumentar recursos de forma proporcional.

Ejemplo práctico:

Generación de historias de usuario: inicialmente cada historia tomaba 4 a 8 horas. Un proyecto con 47 historias representaba más de 200 horas de esfuerzo. Con IA generativa, el tiempo por historia se redujo a 5-30 minutos, logrando ahorro de recursos, mejor calidad y reducción de tiempo de entrega.

Paso 3: Evaluar la viabilidad técnica

No todos los problemas son aptos para IA generativa. La clave está en reconocer la naturaleza del problema:

Problemas deterministas: Siempre requieren la misma respuesta, explicable paso a paso. Ejemplo: conciliaciones contables, cálculos matemáticos, balanceo de ecuaciones químicas. Estos corresponden al cómputo tradicional o a modelos clásicos de machine learning, no a IA generativa.
Problemas probabilísticos: La respuesta puede variar según el contexto, sin una única solución “correcta”. Aquí la IA generativa brilla: generación de texto, resúmenes, preguntas y respuestas, análisis de imágenes, entre otros.

Ejemplo real:

Conciliación de cajeros: exige precisión y trazabilidad, un caso para cómputo tradicional. La IA puede actuar como asistente, pero no ejecutar la conciliación.

Casos híbridos:

En soporte técnico, la IA generativa puede analizar sentimiento y clasificar texto, mientras que la contabilización de horas corresponde al cómputo tradicional. El valor está en integrar ambos mundos.

Paso 4: Validación técnica rápida

Antes de invertir en una prueba de concepto formal, conviene realizar una validación rápida que evitará que iniciemos una etapa más avanzada y nos decepcionemos, el objetivo de esta validación rápida es :

Detectar posibles brechas tempranas.
Confirmar disponibilidad de datos en cantidad, calidad y formato adecuado.

Ejemplos:

Test rápido con actas de junta directiva: permite generar resúmenes y preguntas y respuestas.
Chatbot de soporte: verifiquemos los datos sabemos que se tiene información de los casos, pero validemos que la documentación de los workarounds y de las soluciones estén presentes antes de desarrollar la POC. Es común encontrar que los datos no son lo que el patrocinador realmente pensaba que eran.

Por otra parte, esta fase ayuda a ubicar el caso de uso en alguno de los cuerpos de una pirámide, llamemosla pirámide de complejidad técnica entre mas arriba nos ubiquemos en el cuerpo de la misma, mayor será el costo de implementación, propongo esta valoración de complejidad:

Primer cuerpo de la pirámide, su base: Corresponde a los escenarios que pueden ser resueltos con un buen prompt sobre modelo existente, solo debemos escoger los mejores modelos para la situación en la siguiente fase.
Segundo cuerpo RAG (Retrieval Augmented Generation): Estas soluciones requieren conocimiento propio y la capacidad del modelo. Por ejemplo, necesitamos facilitar las actas de la sesiónes, bases de datos estructuradas o no, entre otros.
Tercer cuerpo el afinamiento especializado: es tan particular la respuesta tan especializada que aunque le damos información de la empresa no lo logramos, entonces tenemos que subir aun mas y afinar ese modelo.
La cúspide construir: Ligas mayores, estamos hablando de desarrollo de modelos propios, reservado para problemas de gran escala, gran complejidad, muchísima especialización.

Un gran porcentaje de fracasos proviene de construir soluciones propietarias innecesarias. La recomendación: avanzar gradualmente.

Paso 5: Prueba de Concepto (POC)

Después de los pasos anteriores, llegamos a la POC su objetivo centrarse en lo que realmente importa, se limita en tiempo y alcance, no interesa interfaz, usabilidad, lo que permita establecer que lo medular del proyecto es lograble y alcanzable por lo tanto su objetivo principal es:

Definir el alcance el core del problema.
Validar viabilidad técnica y práctica.
Diseñar arquitectura inicial y resolver iterativamente los desafíos.
Descarta rápidamente si no funciona la solución

Acciones clave:

Definir arquitectura deseada.
Evaluar modelos disponibles: esto no es una receta todo depende del caso de uso y podemos estudiar los modelos disponibles ( mas de 160 en Amazon Bedrock) y aplicar evaluaciones automatizadas donde obtendremos rendimiento y métricas técnicas y aplicar como siempre el criterio humano (pertinencia, usabilidad, alineación con el negocio, costo, hasta gustos y preferencias).

La POC tiene su foco en dos factores críticos: correctitud y costo. Ahora bien una vez que desarrollamos la POC, sabemos si se puede avanzar con este proyecto, elaborarlo completamente ya con mucha más confianza, lo más valioso es que tenemos resultados tangibles, expectativas claras y hasta un vistazo de los costos de la implementación.

Conclusión

La incorporación de IA generativa no debe ser por moda o miedo. Es un paso estratégico que exige:

Claridad de objetivos.
Medición de impacto.
Validación técnica.
Experimentación controlada.

Los cinco pasos presentados —identificación de problemas reales, medición de impacto, evaluación de viabilidad, validación rápida y POC— forman un marco que permite avanzar con seguridad y reducir riesgos.

El éxito no depende solo del modelo o la infraestructura, sino de alinear la tecnología con las necesidades del negocio, priorizar por impacto y avanzar iterativamente.

Palabra clave: intencionalidad. Adoptar la IA con propósito permite transformar procesos, acelerar innovación y liberar talento humano para enfocarse en lo importante. Con estrategia y método, todos podemos ser parte de las grandes ligas de la IA.

Este artículo explica las diferentes opciones de integración de Active Directory con AWS y el uso de Federation mediante una analogía clara: el acceso a edificios y guardias de seguridad. Con este enfoque narrativo, el contenido resulta más accesible para

Diana Castro — Thu, 21 Aug 2025 14:39:11 +0000

Diana Castro for AWS Community Builders

Aug 20 '25

Rumbo AWS Certified Security Specialty. Bitácora de vuelo de una builder - AWS Directory Services y Federation

#aws #security #certification #cloudcomputing

Comments

13 min read

Rumbo AWS Certified Security Specialty. Bitácora de vuelo de una builder - AWS Directory Services y Federation

Diana Castro — Wed, 20 Aug 2025 02:23:37 +0000

Fecha Estelar 2: AWS Directory Services y Federation

Dentro de la preparación para el AWS Certified Security -- Specialty, descubrí que un tema clave merece especial atención: la integración entre Active Directory (AD) y AWS, así como la federación de identidades.

Por eso decidí estructurar un repaso práctico: comprender cómo se conectan los directorios corporativos con AWS sin necesidad de replicar identidades, y qué implicaciones tiene para habilitar un acceso seguro y centralizado a los recursos.

AWS Directory Services

Microsoft Active Directory (AD)

Es básicamente el sistema de identidad y autenticación centralizado que usan una gran mayoría de empresas para gestionar usuarios, computadoras y recursos de red en un entorno Windows. Es el gran libro de contactos de la empresa o visto como un edificio el guardia de seguridad que te detiene en la entrada y decide si puedes entrar o no y a qué parte de las instalaciones te puedes dirigir.

¿Cuál es su función?

Autenticación: Verifica quién eres cuando tratas de ingresar al edificio - el portero o guardia te solicita tu carnet de empleado y verifica tu identidad (equivale a usuario y contraseña)
Autorización: Define a qué pisos y oficinas puedes acceder una vez dentro - tu carnet tiene permisos específicos: tal vez puedes entrar a contabilidad, pero no a recursos humanos (equivale al acceso a carpetas, aplicaciones, servidores)
Gestión centralizada: El departamento de seguridad del edificio mantiene una base de datos central con todos los empleados, sus niveles de acceso y las políticas del edificio (no fumar, no ingresar sin carnet, horarios de acceso). Desde ahí controlan quién puede ir dónde y cuándo.
Directorio de objetos: Es como el directorio telefónico interno del edificio que almacena información sobre todos los empleados (nombre, departamento, extensión, nivel de acceso), equipos (impresoras, computadoras), salas de juntas, y otros recursos del edificio.

¿Por qué es importante el tema para nosotros?

Como lo mencioné anteriormente muchas empresas ya tienen AD on-premises y pueden tener necesidades como las siguientes:

Extender su identidad existente a la nube
Usar las mismas credenciales para recursos AWS y on-premises
Mantener políticas de seguridad consistentes
Permitir Single Sign-On (SSO)

AWS Directory Services permite integrar o replicar esta funcionalidad en la nube, ya sea conectándote a un AD existente o creando uno nuevo completamente gestionado por AWS y tenemos a nuestra disposición diferentes sabores.

Los conceptos básicos detrás de Active Directory que debemos conocer

Revisaremos los conceptos fundamentales de Active Directory, ya que al estudiar AWS Directory Services nos encontraremos con términos técnicos como Kerberos, LDAP, entre otros. Mantendremos nuestra analogía del edificio corporativo para explicar estos conceptos de manera sencilla.

Consideremos al Controlador de Dominio (DC) como el guardia o portero del edificio.

El segundo concepto que estudiaremos es Kerberos, este corresponde al protocolo de autenticación principal en AD. En la entrada el DC te dará un boleto firmado que dice: "Diana es Diana y puede visitar el edificio el día de hoy hasta las 5 p.m.". Cuando lleguemos a la sala de reuniones o al comedor solo tendremos que mostrar el boleto y podremos entrar, en este caso cuando quieras abrir una aplicación como QuickSight o SharePoint o las decenas de aplicaciones que usas en el día a día, no hay que realizar todo el protocolo solo enseñamos el boleto firmado es decir no ingreso mi contraseña 20 veces al día.

El tercer concepto corresponde a LDAP (Lightweight Directory Access Protocol) es el protocolo que usan apps/servicios para consultar información del directorio. Es decir, es el directorio o guía del edificio, y funciona así cuando yo quiero entrar a la sala de junta directiva la secretaria me mira y llama al responsable de la seguridad y le dice tengo a Diana tratando de entrar a la Sala de la Junta Directiva y este le responderá que ni lo sueñe no la encuentro en el directorio como autorizada en ese grupo privilegiado, pero cuando intente entrar al comedor el responsable de la puerta consultará y me dejará ingresar. Cuando yo trato de acceder a QuickSight, este le pregunta al DC: "Dame la lista de todos los usuarios que son del grupo Analistas que son quienes tienen derecho a usar esta aplicación" y DC responde usando LDAP.

En algunos edificios la seguridad es extrema y te pedirán otro elemento para identificarte, un segundo factor por ejemplo tu huella, aquí entra RADIUS (Remote Authentication Dial-In User Service) es un protocolo usado para autenticación centralizada y MFA. RADIUS es el segundo elemento de autenticación es el guarda extra que te pide coloques tu dedo índice para verificar que tú eres tú realmente con un segundo elemento.

Nos queda un elemento importante que veremos más adelante Trusts (confianza) imaginemos que tenemos dos edificios, los guardias de seguridad de cada edificio acuerdan que dejarán ingresar personas del otro edificio siempre que vengan identificadas. La confianza puede ser en un sentido por ejemplo, el guarda del edificio más grande deja pasar a los inquilinos del más pequeño, pero al revés no o en dos vías ambos guardias dejan pasar a los inquilinos de cualquiera de los edificios.

En resumen:

Kerberos: nos ayuda a evitar la fatiga de escribir la contraseña para cada aplicación que tratamos de acceder
LDAP: indica qué permisos tengo y quién soy
RADIUS: agrega una capa de seguridad consultando por algo que tengo
Trust: Confianza, tus amigos son mis amigos también

Los diferentes sabores de AWS Directory Services

AWS Directory Service es un servicio administrado que proporciona capacidades de directorio en la nube AWS y ofrece diversas opciones:

AWS Managed Microsoft AD: Active Directory completo en AWS
AD Connector: Proxy que conecta con AD on-premises existente
Simple AD: Directorio LDAP básico basado en Samba 4

AD Connector

Imaginemos ahora la empresa abre una sucursal (AWS Cloud) pero no quiere replicar toda la infraestructura de seguridad del edificio principal (datacenter on-premises).

Entonces implementamos un mecanismo sencillo que aproveche los recursos que ya tenemos, contratamos a un guardia o portero especializado AD Connector en la sucursal que no tiene acceso directo a la base de datos de empleados y realiza los siguientes pasos:

Cuando alguien quiere entrar, el portero llama por teléfono/radio al edificio principal para verificar credenciales
Si el edificio principal confirma, el portero autoriza el acceso

La siguiente figura ilustra en términos técnicos este flujo

Beneficios:

No es necesario replicar controladores de dominio en AWS
Los empleados usan sus credenciales corporativas
Redirige consultas LDAP/Kerberos al AD original
Permite acceso a WorkSpaces, QuickSight, EC2 Windows y Consola AWS

AD Connector es un proxy service que mantiene toda la información de usuarios en un solo lugar - el Active Directory original. La clave está en que no copia, ni sincroniza usuarios: redirige autenticación y consultas (LDAP/Kerberos) a los controladores de dominio existentes. Así puedes usar tus mismas credenciales corporativas para iniciar sesión en servicios como Amazon WorkSpaces, QuickSight, unir EC2 Windows al dominio, e incluso entrar a la Consola de AWS.

Características

Multi-AZ: el conector se despliega por alta disponibilidad en dos subnets en AZ distintas
Tamaños: Small o Large depende de la cantidad de usuarios y el tamaño de la carga small se recomienda hasta para 500 usuarios y large hasta para 5000
Cifrado/compatibilidad Kerberos: soporta AES-256/128 HMAC y RC4-HMAC
Sitios y subredes de AD: mapea las subnets de tu VPC en Active Directory Sites and Services para que el conector "descubra" DCs cercanos (evita latencias cruzadas)
1:1 por dominio: necesitas un AD Connector por cada dominio (incluye child domains) y cada conector usa su propia cuenta de servicio
No replica ni sincroniza objetos; no guarda contraseñas
MFA vía RADIUS existente
Depende de la conectividad (VPN/Direct Connect) entre VPC y la infraestructura on-premise; si el enlace cae, también caerá la autenticación por AD Connector
La latencia de la red afecta directamente el rendimiento
Algunas funciones avanzadas de AD no están disponibles

La siguiente tabla nos ayudar a clarificar cuando debemos hacer uso de AD Connector y cuando es mejor evitarlo

Cuándo Sí	Cuándo No
Si tienes AD on-prem y quieres acceso inmediato a servicios AWS con las mismas credenciales, sin levantar DCs en AWS	Se requieren integraciones que piden Managed Microsoft AD como RDS SQL Server
Ya tienes un AD bien gestionado y enlaces de red estables/rápidos hacia AWS; buscas bajo costo operativo y cero sincronización	Tienes >5,000 usuarios y/o necesitas trusts administrados entre directorios en AWS y on-prem

AWS Managed Microsoft AD

Cuando hablamos de AWS Managed Microsoft AD, nos referimos a un Active Directory real ejecutándose como servicio administrado en AWS. No es una "compatibilidad" ni un sustituto: es un AD completo, con controladores de dominio (DCs) corriendo en Windows Server, soportando todas las funciones que conocemos: grupos, trusts, Kerberos, LDAP, GPOs, OUs, etc.

La clave está en el modelo de responsabilidad compartida:

Nosotros administramos el directorio, usuarios, grupos, políticas (GPOs), y estructura organizativa (OUs)
AWS se encarga de la infraestructura subyacente: sistema operativo, parches, backups, recuperación ante desastres y disponibilidad

Características destacadas

Alta disponibilidad: por defecto despliega dos Domain Controllers en distintas zonas de disponibilidad, garantizando resiliencia automática
Multi-región: puede implementarse como extensión de tu AD on-premises o bien desplegarse en múltiples regiones para mayor cercanía y continuidad
Escalable: Podemos pasar de pocos objetos a miles para eso tenemos Versión Standard: hasta 30,000 objetos (ideal para PYMEs) y Versión Enterprise hasta 500,000 objetos (grandes corporaciones)
Integración nativa con AWS: se conecta de forma transparente con servicios como Amazon RDS for SQL Server, QuickSight, FSx for Windows File Server, WorkSpaces, entre otros. (Dato clave: RDS no es compatible con AD Connector, pero sí con Managed Microsoft AD).
Trusts (confianzas): permite establecer confianzas bidireccionales con tu AD on-premises, lo que facilita que usuarios locales accedan a recursos en AWS sin duplicar credenciales

¿Qué problemas resuelve?

Elimina la necesidad de administrar tus propios Domain Controllers en la nube
Facilita la autenticación en aplicaciones que requieren Kerberos o NTLM
Permite extender tu AD corporativo a AWS de manera transparente y segura
Soporta la migración de aplicaciones legadas que dependen de AD, sin obligarte a mantener infraestructura on-premises solo para ellas

AWS Managed Microsoft AD es la opción para organizaciones que necesitan toda la potencia y compatibilidad de Active Directory, pero desean delegar en AWS la operación, seguridad, alta disponibilidad y escalabilidad del servicio.

La siguiente tabla nos ayudará a identificar situaciones en las que nos será útil y cuando por el contrario sería contraproducente.

Cuándo Sí	Cuándo No
Si necesitas todas las capacidades de Active Directory real (trusts, GPOs, esquema completo)	Si ya tienes un AD on-premises y solo quieres que los usuarios usen sus credenciales para loguearse en AWS → usa AD Connector
Si quieres administrar usuarios/grupos de forma granular como en tu AD local	Si solo necesitas algo ligero para apps sencillas sin requerimientos avanzados de AD → usa Simple AD
Si tienes apps Windows que no funcionan con Simple AD	Si tu empresa no usa AD en absoluto y no tienes apps que lo requieran
Si necesitas integrarlo con servicios de AWS que requieren AD "de verdad"

Simple AD

El sabor light de la familia. Y ojo, que no por eso debe subestimarse. Está diseñado pensando en pequeñas empresas o startups que necesitan lo esencial de un Active Directory sin toda la complejidad ---y el costo--- de uno completo.

Su mayor virtud es precisamente esa: ser la opción económica y práctica. Con Simple AD puedes manejar usuarios, grupos, unir instancias Windows a un dominio y aplicar algunas GPOs básicas. Si lo que buscas es cubrir lo fundamental sin pagar por funciones que nunca vas a usar, este servicio encaja perfecto en la premisa de "usa solo lo que realmente necesitas".

Además, se despliega automáticamente en dos zonas de disponibilidad dentro de la misma región, lo que le da un nivel de alta disponibilidad muy conveniente para su propósito.

Eso sí, tiene limitaciones claras: no soporta trusts con AD on-premises, no se integra con todos los servicios de AWS (el más doloroso, en mi opinión, es que no funciona con RDS para SQL Server), tiene un límite de 5,000 usuarios y solo puede vivir en una región. Y si me preguntas, lo que más me molesta es que no soporte MFA... pero bueno, ahí ya entramos en preferencias personales.

Resumen comparativo

Servicio	Qué es	Alta disponibilidad	Casos de uso	Limitaciones
AD Connector	Un "puente" hacia tu AD on-premise (no almacena usuarios)	No aplica (solo redirige)	Útil si ya tienes AD local y solo quieres conectar apps en AWS sin replicar nada	Necesita siempre que tu AD on-prem esté disponible
Simple AD	Un AD básico basado en Samba, hospedado en AWS	Sí, en 2 AZs de una región	Apps en AWS que necesitan autenticación AD, pero sin requerir todas las funciones de AD corporativo	No soporta trusts, funciones avanzadas ni multi-región
Managed Microsoft AD	Un AD completo de Microsoft, administrado por AWS	Sí, en 2 AZs y puede extenderse multi-región	Empresas que quieren AD real en la nube, integración con Kerberos/NTLM, migraciones o extender AD on-premises	Más costoso, pero con todas las funciones de AD

Federation

Antes de introducir el concepto permítanme a citar a Les Luthiers pues el tema es similar al anterior pero:

"Parecido no es lo mismo caballero"

Federación significa que con una sola identidad puedo acceder a múltiples servicios sin tener que crear cuentas separadas en cada uno. Veámoslo así: Federation aplica cuando quiero entrar a AWS con mi cuenta corporativa (o la de un proveedor de identidades) sin tener que crear usuarios IAM para cada persona.

En su lugar, otorgamos accesos temporales y seguros mediante STS.

Ahora bien, existen diversos proveedores de identidad, como ADFS, Okta, Azure AD o Google Workspace, que pueden cumplir ese rol de "recepción central" de nuestras identidades.

Conceptos básicos detrás del concepto de federación

Regresemos a los edificios. Pensemos que ahora tenemos alianzas con empresas externas y, definitivamente, los guardias de esos otros edificios no quieren complicarse registrando a tus inquilinos en su directorio.

El guardia del edificio aliado confiará en ti: si tú le dices que Diana trabaja en tu edificio, él te creerá y le dejará pasar. Aquí intervienen todos los conceptos importantes de Federation:

IdP -- Identity Provider: Corresponde a la recepción del edificio corporativo. Emitirá un pase para que tus empleados visiten los edificios aliados Este pase puede ser un SAML Assertion o un token OIDC. Ejemplos de IdP: _ADFS, Okta, Azure AD, Google Workspace
_. Piensa en el IdP como la recepción que sabe quién eres y te da un pase confiable.

Service Provider: Es el edificio aliado. En nuestro caso, la nube de AWS, que no quiere tener un usuario IAM para cada inquilino. Confía en lo que tu IdP le diga y acepta el pase que emitiste. El guardia del edificio aliado no conoce a Diana personalmente, pero confía en el sello de tu recepción.

Protocolos-- Es el pase _SAML*_ un pase o tiquete sellado utilizado por aplicaciones corporativas _OIDC*_un pase más moderno basado en OAuth2, como un QR que llevas en tu celular. Ambos permiten que el Service Provider verifique tu identidad sin que tengas que crear usuarios locales.

AWS STS -- Security Token Service: Cuando ingresas al otro edificio, el guardia interno emite un boleto temporal. Por ejemplo, válido por una hora. Este boleto es una credencial temporal ligada a un rol específico (AssumeRole). Puedes imaginarlo como ponerte una chaqueta o casco que diga "Analista" o "Cocinera", que determina qué puedes hacer dentro del edificio. Esto garantiza que incluso si pierdes el pase, tu acceso temporal expira y nadie puede usarlo indebidamente.

Muchos conceptos y ¿Por qué no Kerberos?

Kerberos solo funciona para recursos internos, dentro de tu AD.

Si todo está administrado por tu AD, Kerberos permite SSO en la red interna
Pero si tenemos recursos externos, como aliados o la nube, necesitamos un pase temporal que sea reconocido fuera del dominio

Es como la diferencia entre identificación nacional y pasaporte: tu DNI te sirve dentro del país, pero para viajar necesitas un documento que otros países reconozcan.

En Resumen

El IdP dice quién eres.
El Service Provider te deja pasar temporalmente
STS + AssumeRole te entrega credenciales temporales con permisos específicos.
Kerberos funciona dentro de tu dominio; Federation es para acceder a recursos externos sin crear usuarios locales.

Un flujo vía Federation

Esta vez Ana será nuestro conejillo de indias:

Ana llega al edificio (AWS Console)
- Ana se presenta en la recepción del edificio aliado -- es decir abre la página de AWS Console
- La pregunta obvia: "¿Quién eres? Yo no te conozco." Y llaman al edificio del que enviaron a ANA. AWS redirige la autenticación hacia el Identity Provider (IdP) configurado, por ejemplo ADFS en su empresa
Va a la recepción de su empresa (IdP)
- Ana ingresa su usuario y contraseña corporativa en la recepción central (ADFS)
- El recepcionista confirma: "Sí, Ana trabaja aquí, aquí está su pase." Técnicamente ADFS autentica contra Active Directory (con Kerberos) y emite un token SAML firmado digitalmente
Recibe el pase universal (SAML Assertion)
- La recepción le da un pase con sello de confianza que dice: "Esta es Ana, del departamento de Finanzas, tiene permiso para acceder como 'Analista'." El token SAML contiene atributos (nombre, grupos, roles permitidos)
Entrega el pase en la ventanilla de seguridad interna (AWS STS)
- Ana llega a AWS con el pase. AWS STS lo revisa: "Este pase viene de ADFS, que es de confianza. Todo bien." AWS STS (Security Token Service) valida el SAML assertion
Le dan una tarjeta temporal con un rol (AssumeRole)
- La ventanilla de AWS le da una tarjeta temporal de visitante con su rol: "Analista -- válido por 1 hora." STS devuelve credenciales temporales ligadas al rol IAM correspondiente
Accede al piso correcto (recursos en AWS)
- Con su tarjeta temporal, Ana entra al piso de "Reportes Financieros" en AWS. Cuando la tarjeta expira, debe volver a pedir otra. Acceso controlado con roles temporales si se filtra una credencial, expira rápidamente

Beneficios

Solo se usa credenciales corporativas no más usuarios en AWS
La empresa mantiene el control en un solo directorio
AWS nunca guarda usuarios solo confía en el pase SAML de su IdP
Los accesos son temporales y seguros

Conclusión

Ya exploramos tres formas de integrar Active Directory con AWS y vimos cómo funciona la federation para permitir un acceso seguro y transparente a los usuarios. La clave está en evaluar tus necesidades: el tamaño de la organización, la complejidad que estás dispuesto a manejar y el presupuesto disponible.

Como siempre, la premisa es clara: usa solo lo que realmente necesitas. Elegir la opción adecuada garantiza seguridad, eficiencia y escalabilidad, sin sobrecargar tu infraestructura ni complicar la administración.

Sostenibilidad no es solo una etiqueta es ventaja competitiva y sostenible. Arquitectos, diseñadores tenemos una gran responsabilidad nuestras decisiones afectan no solo el diseño la seguridad, también la economía y el ambiente

Diana Castro — Sat, 26 Jul 2025 00:11:34 +0000

Diana Castro for AWS Community Builders

Jul 21 '25

AWS y el Pilar de la Sostenibilidad: Futuro Responsable, Ventaja Sostenible

#aws #cloud #sostenibilidad #productivity

Comments

4 min read

DEV Community: Diana Castro

Diario de una builder: El camino hacia la orquestación de dos mundos

Aprender una segunda nube sin empezar desde cero

El reto de aprender otra nube

Cuando las equivalencias dejan de ser suficientes

Lo más valioso no es memorizar servicios

El modelo de responsabilidad compartida

Estructura de la nube

Organización global

Regiones y Zonas de Disponibilidad

Datacenters y extensiones de baja latencia

Local Zones y edge computing

Resumen comparativo

Cómo se organizan las nubes

Enfoque de Azure

Tenant

Management Group

Subscription

Resource Group

Resource

Enfoque AWS

Root Account

AWS Organizations

Organizational Unit (OU)

Service Control Policy (SCP)

Cuenta AWS

Equivalencias conceptuales

Veamos un ejemplo práctico

Identidad: donde todo inicia

AWS: identidad y permisos en un mismo sistema

Azure: identidad y autorización como capas separadas

La diferencia importante

Cómo se comunican los recursos - Networking

VPC vs VNet

NSG vs Security Groups ¿qué tan parecidos?

Tal y como les prometí: mi “Piedra Rosetta”

Interactuando con la nube

Reflexiones finales

Sabías que un porcentaje significativo de modelos no falla por el algoritmo, sino por la calidad de los datos En este artículo abordo el proceso de Feature Engineering: cómo seleccionar limpiar transformar datos crudos en Features

Diario de una builder: Feature Engineering

Diario de una builder: Feature Engineering

Feature Engineering: El siguiente paso después de preparar los datos

🔁 Un proceso altamente iterativo

🧠 Feature Engineering – Comprendiendo lo que implica

📚 Conceptos base

🎴 Aplicado a nuestro ejemplo práctico

🔬 ¿Qué abarca el Feature Engineering?

1️⃣ Selección de variables relevantes

2️⃣ Transformación de variables existentes

3️⃣ Creación de nuevas features (Feature Construction)

🎯 ¿Qué ganamos con una correcta aplicación?

1️⃣ Reducción de costos computacionales

2️⃣ Mejora del rendimiento del modelo

🧩 ¿Cuál es la naturaleza del problema?

📈 Problema de regresión

🏷️ Problema de clasificación

🏁 En síntesis

🔄 Feature Transformation

🧮 Transformaciones por tipo de variable

📊 Datos numéricos o cuantitativos

Técnicas comunes:

🏷️ Datos categóricos o cualitativos

Técnicas utilizadas:

🧾 Datos de texto e imágenes

En texto:

En imágenes:

⚙️ Técnicas aplicadas y justificación técnica

🏷️ Técnicas aplicadas a datos categóricos

🔹 One-Hot Encoding

⚠️ Consideración sobre cardinalidad

🔢 Ordinal Encoding

📊 Técnicas para datos numéricos

📋 Resumen de técnicas

🧮 Imputation (Imputación de valores faltantes)

Cálculo de la media

Cálculo de la mediana

📌 Técnicas de imputación más utilizadas

📉 Transformaciones logarítmicas (log / log1p)

🔎 ¿Qué es log1p?

🛠️ Camino al dataset model-ready

🧩 Tratamiento de la variable `extrarity`