Compartir datos seguros entre cuentas con Lambda y S3

Introducción

En entornos de AWS con múltiples cuentas es habitual que un servicio alojado en una cuenta consuma o deposite datos en otra. Un ejemplo clásico es una función Lambda en una cuenta que necesita leer o escribir en un bucket S3 de otra cuenta. A continuación encontrarás una guía clara para habilitar este acceso cruzado entre cuentas con políticas de S3 e IAM, traducida y reescrita en español con foco práctico y seguro.

El escenario

Cuenta A 1111111111 aloja la función Lambda. Cuenta B 2222222222 es propietaria del bucket S3 llamado account_b_bucket. Objetivo permitir que la Lambda de la Cuenta A pueda subir y leer objetos en el bucket de la Cuenta B de forma segura.

Arquitectura resumida

La configuración consta de tres piezas principales

1 Rol IAM de ejecución en la Cuenta A llamado account_a_lambda_role con una política que otorga permisos s3 GetObject y s3 PutObject sobre el recurso arn aws s3 ::: account_b_bucket y sus objetos arn aws s3 ::: account_b_bucket barra asterisco. Esta política se adjunta al rol que usa la Lambda. Con ello la función está autorizada a solicitar acciones S3 sobre el bucket de la otra cuenta respetando el principio de privilegio mínimo al limitarse a las acciones y recursos necesarios.

2 Política de confianza del rol de ejecución Lambda que permite que el servicio Lambda asuma el rol. El principal es el servicio lambda.amazonaws.com y la acción autorizada es sts AssumeRole. Así la infraestructura de Lambda puede obtener credenciales temporales para ejecutar la función con los permisos del rol.

3 Política del bucket en la Cuenta B que confía en el rol de la Cuenta A. En la política del bucket se autoriza el principal AWS con el ARN del rol arn aws iam doble dos puntos 1111111111 dos puntos role barra account_a_lambda_role y se permite s3 GetObject y s3 PutObject sobre el recurso arn aws s3 ::: account_b_bucket barra asterisco. Esta relación cruzada es imprescindible porque S3 evalúa tanto los permisos del llamador como la política del bucket.

Flujo de ejecución

La función Lambda en la Cuenta A se invoca. La infraestructura de Lambda asume el rol account_a_lambda_role. La política del rol permite realizar acciones S3 sobre el bucket de destino. La política del bucket en la Cuenta B autoriza el ARN del rol de la Cuenta A. Con ambas políticas alineadas, la Lambda accede de forma segura al bucket entre cuentas.

Ejemplo de implementación en Lambda

1 Define una variable de entorno llamada TARGET_BUCKET con el nombre del bucket de la Cuenta B. 2 En el código Python inicializa un cliente S3 con boto3.client paréntesis s3 paréntesis. 3 Genera un contenido simple con una marca temporal en UTC y define una clave de objeto con un prefijo identificable por ejemplo lambda guion bajo output guion bajo marca de tiempo punto txt. 4 Llama a s3_client punto put_object indicando Bucket igual al nombre del bucket, Key igual al nombre del archivo y Body con el contenido codificado en utf guion ocho. 5 Implementa manejo de excepciones para devolver un estado 200 en éxito y 500 con el detalle del error en caso de fallo. Este patrón funciona para escrituras y lecturas, y puede ampliarse con encabezados de control de cache, cifrado del lado del servidor y metadatos personalizados.

Buenas prácticas de seguridad

Aplica privilegio mínimo en políticas IAM y del bucket limitando acciones y recursos. Considera cifrado con KMS gestionando una clave en la cuenta propietaria del bucket y permitiendo su uso al rol de la otra cuenta. Registra accesos con CloudTrail y Server Access Logging o S3 Access Logs. Añade condiciones en políticas con aws PrincipalArn o aws SourceArn cuando uses invocaciones orquestadas. Versiona objetos y activa bloqueo de objetos si necesitas retención. Evalúa restricciones por IP o VPC Endpoint para un perímetro de red más estricto.

Cómo extender el patrón

Este enfoque no se limita a Lambda. Puede aplicarse a instancias EC2, tareas ECS, Step Functions, Glue y otros servicios que asumen roles IAM para operar con recursos S3 entre cuentas. La clave es alinear permisos en el rol del llamador y la política del recurso destino.

Q2BSTUDIO puede ayudarte

En Q2BSTUDIO somos una empresa de desarrollo de software con foco en aplicaciones a medida y software a medida, especialistas en servicios cloud AWS y Azure, inteligencia artificial e IA para empresas, ciberseguridad y servicios de inteligencia de negocio con power bi. Diseñamos arquitecturas seguras de acceso entre cuentas, automatizamos despliegues y monitorización, y creamos agentes IA para potenciar tus procesos. Si quieres llevar tu plataforma al siguiente nivel y optimizar costes, rendimiento y seguridad, descubre nuestros servicios cloud AWS y Azure y cuéntanos tu reto.

Conclusión

Para permitir que una Lambda en una cuenta escriba o lea en un bucket S3 de otra, necesitas 1 un rol IAM de ejecución con permisos s3 mínimos sobre el bucket remoto, 2 una política de confianza que permita a Lambda asumir el rol y 3 una política del bucket que autorice el ARN del rol externo. Con esta configuración coordinada obtienes un acceso entre cuentas seguro, auditable y extensible a otros servicios. Palabras clave relacionadas aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi.