SW BBANG E

Diseñaste tu tabla DynamoDB con una clave primaria que funciona perfectamente para el patrón de acceso principal, y ahora el equipo de producto pide filtrar por un atributo completamente diferente. Antes de duplicar datos o rediseñar la tabla, entender la diferencia entre un Local Secondary Index (LSI) y un Global Secondary Index (GSI) en DynamoDB puede ahorrarte semanas de refactorización. TL;DR: LSI vs GSI en DynamoDB Característica LSI GSI Partition key Misma que la tabla base Cualquier atributo Sort key Atributo diferente al de la tabla Cualquier atributo (opcional) Creación Solo en el momento de crear la tabla En cualquier momento Consistencia de lectura Fuerte o eventual Solo eventual Límite de tamaño por partition key 10 GB por valor de partition key Sin límite adicional Capacidad Comparte con la tabla base Capacidad independiente Casos de uso típicos Consultas alternativas dentro ...

Cuando el equipo crece de dos a veinte ingenieros, adjuntar políticas directamente a cada usuario de IAM deja de ser un problema de estilo y se convierte en un problema operacional real: permisos inconsistentes, auditorías imposibles y el clásico 'ese usuario tiene acceso a producción pero no sé por qué'. Los grupos de IAM existen precisamente para evitar ese caos. TL;DR: Grupos IAM vs. Políticas Directas en Usuarios Criterio Política directa en usuario Política en grupo IAM Escalabilidad Cada usuario requiere gestión individual Un cambio en el grupo afecta a todos los miembros Consistencia de permisos Alta probabilidad de desviación entre usuarios Permisos uniformes garantizados por diseño Auditoría Requiere revisar cada usuario individualmente Un solo punto de revisión por rol Onboardi...

Cuando configuras cifrado en un bucket S3 por primera vez, la pantalla de la consola te presenta opciones que parecen equivalentes pero tienen implicaciones operativas y de costos muy distintas. Elegir entre una clave administrada por AWS y una clave administrada por el cliente (CMK) no es solo una decisión de seguridad — define quién controla el acceso, quién paga por cada operación criptográfica, y qué tan rápido puedes revocar acceso en una emergencia. TL;DR: AWS Managed Key vs. CMK para S3 Dimensión AWS Managed Key (aws/s3) Customer Managed Key (CMK) Creación y rotación Automática, gestionada por AWS Manual o programada, controlada por ti Política de clave No editable Totalmente configurable Costo por API call Sin cargo directo para S3 SSE-KMS Cargo por cada llamada a la API de KMS Auditoría ...

La primera vez que abres una política IAM en JSON y ves cuatro claves que controlan todo el acceso a tu infraestructura, la tentación es asumir que son intercambiables o que alguna tiene prioridad implícita sobre otra. No es así. Cada elemento resuelve una pregunta distinta, y entender exactamente qué pregunta responde cada uno es lo que separa una política que funciona de una que abre brechas silenciosas. TL;DR — Estructura básica de una política IAM Elemento Pregunta que responde Obligatorio Effect ¿Se permite o se deniega? Sí Action ¿Qué operación de API? Sí Resource ¿Sobre qué recurso específico? Sí (en la mayoría de tipos de política) Condition ¿Bajo qué circunstancias adicionales? No Cómo evalúa AWS una política IAM Antes de diseccionar cada elemento, es importante entender el modelo de evaluación. AWS no lee una política IAM como un programa secuencial. Cuando una entidad (usuario, rol, serv...