AWS en 2025: lo que crees saber, pero ahora está mal

 (lastweekinaws.com)
8 puntos por GN⁺ 2025-08-21 | 3 comentarios | Compartir por WhatsApp
  • Los servicios clave de AWS están evolucionando rápidamente
  • Funciones principales como EC2, S3 y Lambda ahora ofrecen un rendimiento y una flexibilidad que superan las expectativas de los usuarios frente al pasado
  • También ha habido muchos cambios y optimizaciones en redes, autenticación y estrategias de ahorro de costos
  • Las publicaciones de blog antiguas y desactualizadas o la información vieja pueden causar confusión
  • Conocer las actualizaciones más recientes y los cambios de políticas es esencial para aprovechar AWS

AWS 2025: el presente cambió frente a la percepción del pasado

  • AWS es una plataforma en la nube con casi 20 años de historia, y por eso el “sentido común” sobre sus servicios sigue cambiando
  • Incluso para los usuarios actuales, hay tantas mejoras en funciones clave que resulta difícil seguir el ritmo de los cambios
  • Todavía hay muchas publicaciones de blog con información antigua, así que es importante entender bien qué cambió realmente en las configuraciones

EC2

  • Los grupos de seguridad y roles de IAM de las instancias EC2 ahora pueden modificarse sin interrupciones
  • Es posible cambiar el tamaño de los volúmenes EBS y adjuntarlos o separarlos en instancias en ejecución
  • Ahora se pueden detener o terminar forzosamente instancias EC2 recientes, sin necesidad de esperar timeouts largos
  • Se introdujo la función de migración en vivo entre hosts físicos, por lo que las alertas de degradación de rendimiento de instancias son menos frecuentes
  • La confiabilidad de las instancias aumentó mucho, y ya casi no ocurre que desaparezcan sin previo aviso como antes
  • La variación de precios de las instancias Spot ahora es gradual, así que ya no hace tanta falta vigilarlas en tiempo real como si fuera un mercado especulativo
  • Los casos en los que se necesitan instancias dedicadas se volvieron extremadamente raros (ni siquiera HIPAA BAA las requiere desde hace casi 10 años)
  • AMI Block Public Access viene activado por defecto en cuentas nuevas (desde 2023 también aplica a cuentas sin AMI públicas propias durante más de 90 días)

S3

  • S3 ya no es Eventually Consistent y ahora ofrece Read-After-Write Consistency
  • Ya no hace falta aleatorizar el prefijo de las claves de objeto, lo que reduce la preocupación por la distribución de datos y los hotspots
  • Las ACLs (Access Control List) ya no se recomiendan y vienen desactivadas por defecto en buckets nuevos
  • Los buckets nuevos traen Block Public Access configurado por defecto
  • El cifrado de datos almacenados se aplica automáticamente
  • Antes de que Glacier se convirtiera en una clase de almacenamiento de S3, era un servicio separado, pero ahora están integrados. Solo quedan rastros de eso en elementos como la facturación
  • Los costos y tiempos de restauración de Glacier son hoy mucho más predecibles y baratos que antes. El terror a los costos de restauración del pasado ya no refleja la realidad

Redes (Networking)

  • EC2-Classic desapareció por completo
  • Las direcciones IPv4 públicas ya no son gratuitas y ahora tienen el mismo costo que una Elastic IP
  • En lugar de VPC Peering, aparecieron mejores opciones como Transit Gateway, compartir VPC/recursos y Cloud WAN
  • VPC Lattice y Tailscale permiten resolver problemas complejos de red con más facilidad
  • El tiempo de propagación de actualizaciones de CloudFront bajó de 45 minutos a alrededor de 5 minutos (aunque todavía puede sentirse largo al esperar despliegues de CloudFormation)
  • ELB Classic cobraba transferencia de datos entre AZ, mientras que ALB solo cobra por LCU. Ojo: NLB sigue cobrando tráfico entre AZ
  • Se añadió soporte de grupos de seguridad a Network Load Balancer
  • Antes el ID de las zonas de disponibilidad variaba entre cuentas, pero ahora es posible alinear los Zone ID con Resource Access Manager

Lambda

  • Lambda pasó de un límite de 5 minutos a 15 minutos de ejecución, y ahora también admite imágenes de contenedor (Docker), almacenamiento compartido con EFS, hasta 10 GB de RAM y /tmp de 10 GB
  • La velocidad de invocación de Lambda dentro de una VPC mejoró drásticamente
  • El problema de los cold starts se redujo mucho frente al pasado

EFS

  • El ajuste del rendimiento de IO de EFS ahora puede hacerse por separado de la capacidad, así que ya no hace falta llenar espacio con datos inútiles

EBS

  • Los volúmenes EBS nuevos pueden usar rendimiento máximo de inmediato si no tienen datos base
  • Los volúmenes creados desde snapshots pueden ser lentos en la primera lectura de datos, así que se recomienda leer el disco completo una vez (también hay opciones más rápidas)
  • Los volúmenes io1 pueden conectarse al mismo tiempo a varias instancias EC2, pero en la práctica solo se recomiendan en casos muy específicos

DynamoDB

  • Ahora se permiten campos vacíos dentro de un ítem
  • El rendimiento es mucho más consistente, así que ya casi no hace falta monitorear aparte los hot keys con herramientas externas como antes
  • Con los cambios de pricing, para la mayoría de los usuarios el modo On Demand tiene más sentido

Opciones de ahorro de costos (Cost Savings Vehicles)

  • Las Reserved Instances están entrando gradualmente en desuso, y los Savings Plans son el estándar hacia adelante. Aunque el descuento de Savings Plans bajó frente a RI, ofrecen mucha más flexibilidad
  • El uso de EC2 se factura por segundo, así que incluso encender una instancia por muy poco tiempo puede ser rentable
  • Cost Anomaly Detector detecta patrones de uso inesperados con gran precisión y es gratuito
  • Compute Optimizer ofrece recomendaciones confiables para varios recursos, incluido EBS. Las recomendaciones de Trusted Advisor siguen siendo poco consistentes

Autenticación (Authentication)

  • Se recomienda otorgar permisos mediante roles de IAM, y los usuarios de IAM quedan más bien para aplicaciones legacy
  • IAM Identity Center reemplaza a AWS SSO y se usa para el acceso a cuentas. Esto todavía genera algo de confusión
  • Se pueden registrar múltiples dispositivos MFA en la cuenta root
  • No hace falta configurar credenciales root por separado para las cuentas miembro de una organización

Otros (Miscellaneous)

  • La confiabilidad y durabilidad de us-east-1 mejoraron mucho frente al pasado. Las caídas que antes eran relativamente frecuentes ahora ya son eventos dignos de noticia
  • La descontinuación (Deprecation) de servicios de AWS sigue siendo poco común, pero va en aumento, así que conviene pensar bien cuánto depender de servicios menores
  • Ya no ocurre que el último punto de los datos de CloudWatch aparezca anormalmente bajo por inconsistencias
  • Desde la cuenta root se pueden cerrar directamente las cuentas miembro de AWS dentro de una organización

Lecturas relacionadas

3 comentarios

 
roxie 2025-08-23

Vaya, realmente ha cambiado muchísimo.
 
howudoin 2025-08-23

Ahora ya no puedes elegir y usar un solo servicio de AWS.
Para hacer cualquier cosa, tienes que conectarlo con un montón de otras cosas.
Definitivamente no es algo simple.
Si lo vas a usar en una startup, no solo tienes que pagar el costo del cloud, también el personal de DevOps.
Si quieres montarlo bien, la carga de trabajo aumenta tanto que terminas perdiendo tiempo de desarrollo en eso.
Además, cada vez hay más casos en los que conviene usar servicios administrados, así que a nivel de código ya terminas dependiendo de la plataforma.
 
GN⁺ 2025-08-21
Opinión en Hacker News
  • Al ver que "Block Public Access" de S3 ahora se aplica por defecto a los buckets nuevos, me parece una decisión obviamente correcta; ha habido muchísimas filtraciones de datos enormes por buckets de S3 mal configurados. Pero a veces quiero crear un bucket de S3 con permisos de lectura pública para servir archivos públicamente, y cada vez cambia algo, así que la receta de antes deja de funcionar y termino teniendo que reaprender todo desde cero.
    • Diría que hay que mirar con cuidado la configuración de "Block Public Access"; es una especie de seguro para evitar que la gente cometa errores graves. Aunque configures una bucket policy muy floja o un ACL (anticuado, pero todavía se usa), si Block Public Access está activado no se puede tener acceso público. Al contrario, si desactivas Block Public Access, incluso una bucket policy muy bien diseñada puede estar bien; la bucket policy determina por completo quién puede acceder. Claro, a largo plazo esa policy podría cambiar accidentalmente, podrían agregarse roles de IAM inesperadamente o modificarse trust policies, así que es importante gestionar eso.
    • Yo uso LLMs con frecuencia en este tipo de situaciones. Les pido que lean la documentación y saquen el código de demostración que está regado por toda la documentación oficial de AWS. Una vez que lo obtengo, también les pregunto de inmediato por las modificaciones personalizadas que quiero hacer.
    • Esto me da una sensación de déjà vu, como de "¿esto no ya lo habían hecho antes?". Me parece que hace 10 años también todo el mundo dejaba los buckets abiertos y por eso tomaron este tipo de medidas.
    • Cambios como este hacen que en entrevistas la pregunta "¿conoces esta tecnología?" sea demasiado ambigua. La tecnología cambia cada mes, así que dan ganas de preguntar: ¿según qué momento del tiempo?
    • Oficialmente, para aprenderlo te dejan pagar $250 y hasta presentar un examen de certificación.
  • En EC2, poder cambiar security groups o roles de IAM sin terminar la instancia ya era posible desde hace años. Las spot instances antes eran un mercado de pujas, pero ahora ya ni siquiera hay pujas, así que en realidad es mucho mejor porque ya no hay variaciones de precio tan bruscas ni casos donde solo ciertos usuarios puedan acceder. Y antes se decía que había que aleatorizar el prefijo de las object keys para evitar hotspots, pero eso ya no hace falta. Me tomó bastante tiempo convencer a mis colegas, pero de todos modos estas personas solo estaban guardando archivitos diminutos que ni siquiera tenían relación con cuellos de botella del backend de S3. Lambda antes tenía un límite de 5 minutos y no soportaba imágenes de contenedor; ahora soporta runtime de 15 minutos, imágenes Docker, EFS compartido, hasta 10 GB de RAM y hasta 10 GB de almacenamiento en /tmp. Yo también me di cuenta de algo: el scope global de Python sobrevive igual que /tmp.
  • Restaurar desde Glacier ya no tiene por qué sentirse dolorosamente lento. Siguiendo el estilo Amazon, antes pensaba que el Glacier antiguo probablemente funcionaba en algún almacén físico real de Amazon; cuando pedías datos, daba la impresión de que un trabajador iba al estante, buscaba un medio removible y lo conectaba al servidor. Era parecido a cómo funcionaban los respaldos en cinta en los viejos sistemas de tiempo compartido. En esa época había que cambiar físicamente las cintas.
    • En realidad, creo que es mucho más probable que usaran automatización tipo robot de cintas, ejemplo de foto relacionada. No una persona, sino un robot que busca la cinta, la mete en la unidad, la mueve hasta el offset, lee y luego la rebobina para devolverla. La espera se genera por buscar la cinta, rebobinarla y esperar la unidad. Probablemente, por eficiencia, procesaban todos los requests de una cinta una vez insertada antes de sacarla.
    • No puedo hablar de detalles internos, pero nunca he visto a nadie acertar exactamente cómo estaba diseñado Glacier. Yo también estuve en AWS antes, y sí puedo decir que Glacier se operaba en los mismos datacenters que los demás servicios de AWS. En ingeniería o gestión de producto, lo importante es manejar bien las expectativas del cliente. Si dices que el límite de subida es 10 pero dejas subir 12, el cliente va a empezar a esperar siempre 12. Gestionar expectativas es importante.
    • Como los discos duros son uniformes, imagino que el almacén funciona con robots automáticos. A las personas se las usa para manejar cosas no estándar, como tamaños o formas variadas.
    • En cualquier caso, este tipo de equipos ya lleva décadas robotizado.
  • Ya no puedo iniciar sesión en mi cuenta de AWS porque no había configurado MFA con anticipación. Y para que me emitan un dispositivo, primero necesito iniciar sesión. Ya me habían advertido antes, pero es bastante frustrante que no se pueda solicitar un dispositivo MFA sin iniciar sesión.
    • Probablemente convenga contactar al soporte.
      Contactar a AWS Support
    • Parece un problema que el equipo de soporte podría resolver fácilmente.
  • Creo que hay mucha gente como yo: ya dan ganas de dejar atrás la complejidad típica de AWS —meter mano a API Gateway, Lambda serverless y roles de IAM para que todo encaje— y simplemente quedarse con EC2 o un VPS de LightSail, un bucket de S3, conectar el dominio con Route53 y olvidarse del resto.
    • Si solo vas a usar almacenamiento + VPS, un VPS tradicional es mucho más barato que AWS. Yo más bien tengo la filosofía de que, si vas a usar AWS, hay que usarlo de verdad y bastante. Delegar a Amazon todo lo que se pueda delegar para ganar eficiencia y reducir costos. Step Functions, Lambda y DynamoDB también han superado a sus alternativas. Pero sí me da la impresión de que los desarrolladores aprovechan peor de lo esperado la optimización alrededor del vendor.
    • En realidad, muchas industrias también han simplificado la nube, y las razones son restricciones regionales del servicio o una facturación predecible.
    • Administrar IAM consume demasiado tiempo; siento que el tiempo que antes se iba en administración de sistemas ahora se va completo en administrar permisos. IAM es tan difícil que, en la práctica, termina siendo una pérdida neta. Debe haber un punto ideal entre un VPS y la gestión extrema de mínimo privilegio en serverless. Fargate parece ser un candidato, así que quiero seguir migrando y experimentando.
  • Me gustaría que AWS, en vez de sacar de forma dispersa un montón de cosas de IA por querer alcanzar a otros, se concentrara más en los "servicios básicos pero importantes" que siempre ha hecho bien. Siento que el liderazgo de AWS perdió dirección en GenAI, aunque sigue construyendo bien la infraestructura base. Por culpa de la IA se ven en modo pánico, y desde el lado del cliente eso se siente demasiado disperso e incómodo.
    • La dirección del liderazgo actual es hacer que toda la infraestructura permita que cualquiera pueda elegir un modelo y usarlo de inmediato. Están buscando un entorno que funcione al instante, sin complejidad de setup.
  • Que un bucket de S3 genere cargos de NAT Gateway por pasar por internet pública, incluso si está en la misma región que la VPC, de verdad no tiene sentido. Lo correcto sería que la opción por defecto fuera salirse de eso, no entrar; que sea opt-in por defecto probablemente se deba a que AWS gana dinero extra con esta estructura. Debe haber poquísimos usuarios que realmente quieran la ruta actual.
    • Eso está diseñado pensando en que la seguridad sea el valor por defecto. Si no configuras NAT Gateway, VPC Gateway Endpoint (S3) u otra salida a internet, la carga de trabajo no puede acceder a S3. La red debe estar cerrada, y si un usuario construye algo sin entender bien las rutas, esa responsabilidad es del cliente. Hay que pensar que AWS solo ofrece herramientas crudas de Infrastructure as a Service (IaaS).
    • Para eso existe justamente el S3 VPC Gateway Endpoint, y además no tiene costo.
      Documentación oficial de AWS
    • Después de configurar VPC, subnets, endpoints de PrivateLink y todo eso, de verdad se siente ridículo. Hasta le echaron ganas al nombre PrivateLink (aunque técnicamente sí tiene sentido), pero yo creo que esto debería venir por defecto sin necesidad de setup. Incluso en el caso de usar una subnet privada, ¿no es PrivateLink la única forma de acceder a cosas como S3? Se siente raro.
    • Creo que todos los VPC endpoints deberían aplicarse gratis por defecto. Cobrar extra incluso por usar la API de sus propios servicios ya es demasiado.
    • Esto existe para discriminar precios. A los clientes que no son sensibles al precio no les importa mucho; los que sí se fijan intentan reducir costos, y aun así muchas veces no tienen otra opción que seguir usando AWS.
  • Este artículo me dejó más tranquilo. Siempre me preocupa que Amazon cambie algo grande y me obligue a migrar, pero desde 2013 llevaba usando instancias EC2 bastante bien, casi sin necesidad de administrarlas. Qué bueno que no hubo cambios inesperados.
  • Me impacta que en el pasado las Availability Zones se mapearan aleatoriamente por cuenta.
    • Era para repartir la carga. Si varias cuentas usaban fijamente una AZ específica como 1b, la idea era que la distribución física real quedara mejor balanceada. Después se dieron nombres canónicos por AZ, y creo que fue porque las cuentas que de verdad creaban hotspots y las cuentas que necesitaban metadatos eran distintas.
    • Creo que el objetivo era evitar que, con la configuración por defecto, todo el mundo eligiera us-east-1a y terminara concentrándose en una sola AZ.
    • Al principio era bueno para balancear la carga, pero cuando había que conectar redes entre varias cuentas (PrivateLink y demás), era confuso tener que comprobar una por una qué AZ correspondía a cuál. Por eso hicimos una metodología de mapeo uno a uno por cuenta e incluso armamos tablas internas de consulta, pero después AWS agregó el zone ID a los metadatos y ya fue fácil consultarlo.
    • Esta política sí me hizo sufrir muchísimo.
  • Hay algo que quiero corregir: todo conocimiento inútil podría darse vuelta por completo.
    Weird Al: Everything You Know is Wrong
    Firesign Theatre: Everything You Know is Wrong