Migra de AWS a Google Cloud: Migra de AWS Lambda a Cloud Run

Last reviewed 2025-12-31 UTC

Google Cloud proporciona herramientas, productos, orientación y servicios profesionales para ayudar a migrar cargas de trabajo sin servidores de Amazon Web Services (AWS) Lambda a Google Cloud. Aunque Google Cloud proporciona varios servicios en los que puedes desarrollar e implementar aplicaciones sin servidores, este documento se enfoca en la migración a Cloud Run, un entorno de ejecución sin servidores. Tanto AWS Lambda como Cloud Run comparten similitudes, como el aprovisionamiento automático de recursos, el escalamiento por parte del proveedor de servicios en la nube y un modelo de precios de pago por uso.

Este documento te ayuda a diseñar, implementar y validar un plan para migrar cargas de trabajo sin servidores de AWS Lambda a Cloud Run. Además, ofrece orientación para quienes evalúan los posibles beneficios y el proceso de esta migración.

Este documento pertenece a una serie de varias partes sobre la migración de AWS a Google Cloud que incluye los siguientes documentos:

Si deseas obtener más información para elegir el entorno de ejecución sin servidores adecuado para tu lógica empresarial, consulta Selecciona un entorno de ejecución de contenedor administrado. Para obtener una asignación completa entre los servicios de AWS y Google Cloud , consulta Compara los servicios de AWS y Azure con los servicios de Google Cloud .

Para esta migración a Google Cloud, te recomendamos que sigas el framework de migración que se describe en Migra a Google Cloud: Comienza ahora.

En el siguiente diagrama, se ilustra la ruta del recorrido de tu migración.

Ruta de migración con cuatro fases

Puedes migrar de tu entorno de origen a Google Cloud en una serie de iteraciones, por ejemplo, puedes migrar algunas cargas de trabajo primero y otras más tarde. Para cada iteración de migración independiente, debes seguir las fases del framework de migración general:

  1. Evalúa y descubre las cargas de trabajo y los datos.
  2. Planifica y compila una base en Google Cloud.
  3. Migra tus cargas de trabajo y datos a Google Cloud.
  4. Optimiza tu entorno de Google Cloud .

Para obtener más información sobre las fases de este framework, consulta Migra a Google Cloud: Comienza ahora.

Para diseñar un plan de migración eficaz, te recomendamos que valides cada paso del plan y te asegures de tener una estrategia de reversión. Para ayudarte a validar tu plan de migración, consulta Migra a Google Cloud: Prácticas recomendadas para validar un plan de migración.

La migración de cargas de trabajo sin servidores suele extenderse más allá de solo mover funciones de un proveedor de servicios en la nube a otro. Debido a que las aplicaciones basadas en la nube dependen de una red interconectada de servicios, la migración de AWS a Google Cloud puede requerir el reemplazo de los servicios de AWS dependientes por servicios de Google Cloud . Por ejemplo, considera una situación en la que tu función de Lambda interactúa con Amazon SQS y Amazon SNS. Para migrar esta función, es probable que debas adoptar Pub/Sub y Cloud Tasks para lograr una funcionalidad similar.

La migración también presenta una oportunidad valiosa para que revises de forma exhaustiva las decisiones de arquitectura y diseño de tu aplicación sin servidores. A través de esta revisión, puedes descubrir oportunidades para hacer lo siguiente:

  • Optimiza con las funciones integradas de Google Cloud : Explora si los servicios deGoogle Cloud ofrecen ventajas únicas o se alinean mejor con los requisitos de tu aplicación.
  • Simplifica tu arquitectura: Evalúa si es posible optimizarla consolidando la funcionalidad o usando los servicios de manera diferente dentro de Google Cloud.
  • Mejora la rentabilidad: Evalúa las posibles diferencias de costos de ejecutar tu aplicación refactorizada en la infraestructura que se proporciona en Google Cloud.
  • Mejora la eficiencia del código: Refactoriza tu código junto con el proceso de migración.

Planifica tu migración de forma estratégica. No veas tu migración como un ejercicio de cambio de hosting (lift-and-shift). Usa la migración como una oportunidad para mejorar el diseño general y la calidad del código de tu aplicación sin servidores.

Evalúa el entorno de origen|

En la fase de evaluación, determinarás los requisitos y las dependencias para migrar tu entorno de origen a Google Cloud.

La fase de evaluación es fundamental para el éxito de la migración. Debes obtener un conocimiento profundo sobre las cargas de trabajo que deseas migrar, sus requisitos, sus dependencias y tu entorno actual. Debes saber cuál es tu punto de partida para planificar y ejecutar de forma correcta una migración de Google Cloud.

La fase de evaluación consta de las siguientes tareas:

  1. Crea un inventario completo de tus aplicaciones.
  2. Cataloga tus cargas de trabajo según sus propiedades y dependencias.
  3. Capacitar y educar a tus equipos sobre Google Cloud
  4. Crea experimentos y pruebas de concepto en Google Cloud.
  5. Calcular el costo total de propiedad (TCO) del entorno de destino
  6. Elige la estrategia de migración para tus cargas de trabajo.
  7. Elige tus herramientas de migración.
  8. Define el plan y el cronograma de migración.
  9. Valida tu plan de migración.

Para obtener más información sobre la fase de evaluación y estas tareas, consulta Migra a Google Cloud: Evalúa y descubre tus cargas de trabajo. Las siguientes secciones se basan en la información de ese documento.

Crea un inventario de tus cargas de trabajo de AWS Lambda

Para definir el alcance de la migración, crea un inventario y recopila información sobre tus cargas de trabajo de AWS Lambda.

Para crear el inventario de tus cargas de trabajo de AWS Lambda, te recomendamos que hagas lo siguiente:

  1. Para descubrir tus recursos de AWS Lambda, usa Migration Center. Migration Center es la plataforma unificada deGoogle Cloudque te ayuda a acelerar tu recorrido a la nube de extremo a extremo, desde tu entorno actual hasta Google Cloud.

  2. Para definir mejor el inventario de tus cargas de trabajo de AWS Lambda, usa la interfaz de línea de comandos (CLI) de AWS. Por ejemplo, puedes usar la AWS CLI para obtener una lista de funciones de AWS Lambda. Luego, para cada función, obtén sus detalles de configuración y sus activadores.

  3. Para revisar los registros y las duraciones de las invocaciones recientes de AWS Lambda, las ejecuciones simultáneas y los errores, usa CloudWatch. CloudWatch proporciona varios tipos de métricas para AWS Lambda. Para obtener más información sobre cómo ver las métricas de AWS Lambda, consulta Visualiza métricas de las funciones de AWS Lambda.

  4. Para evaluar tu inventario de cargas de trabajo de AWS Lambda, usa la CLI de Gemini. Por ejemplo, puedes agregar los archivos de inventario que enumeran las cargas de trabajo de AWS Lambda al contexto de Gemini CLI y, luego, pedirle a Gemini que te ayude a evaluar esos objetos. Para obtener más información, consulta Migraciones potenciadas por Gemini a Google Cloud.

Después de crear tu inventario, te recomendamos que recopiles información sobre cada carga de trabajo de AWS Lambda que se encuentre en él. Para cada carga de trabajo, enfócate en los aspectos que te ayuden a anticipar posibles fricciones. Además, analiza esa carga de trabajo para comprender cómo podrías necesitar modificarla y sus dependencias antes de migrar a Cloud Run. Te recomendamos que comiences por recopilar datos sobre los siguientes aspectos de cada carga de trabajo de AWS Lambda:

  • El caso de uso y el diseño
  • El repositorio de código fuente
  • Los artefactos de implementación
  • La invocación, los activadores y los resultados
  • Los entornos de ejecución
  • La configuración de la carga de trabajo
  • Los controles de acceso y permisos
  • Los requisitos de cumplimiento y reglamentarios
  • Los procesos operativos y de implementación

Caso de uso y diseño

Recopilar información sobre el caso de uso y el diseño de las cargas de trabajo ayuda a identificar una estrategia de migración adecuada. Esta información también te ayuda a comprender si necesitas modificar tus cargas de trabajo y sus dependencias antes de la migración. Para cada carga de trabajo, te recomendamos que hagas lo siguiente:

  • Obtén estadísticas sobre el caso de uso específico que entrega la carga de trabajo y, además, identifica cualquier dependencia con otros sistemas, recursos o procesos.
  • Analiza el diseño y la arquitectura de la carga de trabajo.
  • Evalúa los requisitos de latencia de la carga de trabajo.

Repositorio del código fuente

Hacer un inventario del código fuente de tus funciones de AWS Lambda es útil si necesitas refactorizar tus cargas de trabajo de AWS Lambda para que sean compatibles con Cloud Run. La creación de este inventario implica hacer un seguimiento de la base de código, que suele almacenarse en sistemas de control de versión como Git o en plataformas de desarrollo como GitHub o GitLab. El inventario de tu código fuente es esencial para tus procesos de DevOps, como las canalizaciones de integración continua y desarrollo continuo (CI/CD), ya que estos procesos también deberán actualizarse cuando migres a Cloud Run.

Artefactos de implementación

Saber qué artefactos de implementación necesita la carga de trabajo es otro componente que te ayuda a comprender si es posible que debas refactorizar tus cargas de trabajo de AWS Lambda. Para identificar qué artefactos de implementación necesita la carga de trabajo, recopila la siguiente información:

  • Es el tipo de paquete de implementación para implementar la carga de trabajo.
  • Cualquier capa de AWS Lambda que contenga código adicional, como bibliotecas y otras dependencias.
  • Cualquier extensión de AWS Lambda de la que dependa la carga de trabajo.
  • Los calificadores que configuraste para especificar versiones y alias.
  • Es la versión de la carga de trabajo implementada.

Invocación, activadores y resultados

AWS Lambda admite varios mecanismos de invocación, como activadores, y diferentes modelos de invocación, como la invocación síncrona y la invocación asíncrona. Para cada carga de trabajo de AWS Lambda, te recomendamos que recopiles la siguiente información relacionada con los activadores y las invocaciones:

  • Los activadores y las asignaciones de fuentes de eventos que invocan la carga de trabajo.
  • Si la carga de trabajo admite invocaciones síncronas y asíncronas.
  • Las URLs de la carga de trabajo y los extremos HTTP(S)

Tus cargas de trabajo de AWS Lambda pueden interactuar con otros recursos y sistemas. Debes saber qué recursos consumen los resultados de tus cargas de trabajo de AWS Lambda y cómo esos recursos consumen esos resultados. Este conocimiento te ayuda a determinar si necesitas modificar algo que pueda depender de esos resultados, como otros sistemas o cargas de trabajo. Para cada carga de trabajo de AWS Lambda, te recomendamos que recopiles la siguiente información sobre otros recursos y sistemas:

  • Los recursos de destino a los que la carga de trabajo podría enviar eventos.
  • Son los destinos que reciben registros de información para invocaciones asíncronas.
  • Es el formato de los eventos que procesa la carga de trabajo.
  • Cómo interactúan tu carga de trabajo de AWS Lambda y sus extensiones con las APIs de AWS Lambda o con otras APIs de AWS

Para funcionar, tus cargas de trabajo de AWS Lambda pueden almacenar datos persistentes y, además, interactuar con otros servicios de AWS. Para cada carga de trabajo de AWS Lambda, te recomendamos que recopiles la siguiente información sobre los datos y otros servicios:

  • Si la carga de trabajo accede a nubes privadas virtuales (VPC) o a otras redes privadas.
  • Cómo la carga de trabajo almacena datos persistentes, como el uso de almacenamiento de datos efímero y Amazon Elastic File System (EFS).

Entornos de ejecución

AWS Lambda admite varios entornos de ejecución para tus cargas de trabajo. Para asignar correctamente los entornos de ejecución de AWS Lambda a los entornos de ejecución de Cloud Run, te recomendamos que evalúes lo siguiente para cada carga de trabajo de AWS Lambda:

  • Es el entorno de ejecución de la carga de trabajo.
  • La arquitectura del conjunto de instrucciones del procesador de la computadora en la que se ejecuta la carga de trabajo.

Si tus cargas de trabajo de AWS Lambda se ejecutan en entornos de ejecución específicos del lenguaje, ten en cuenta lo siguiente para cada carga de trabajo de AWS Lambda:

  • El tipo, la versión y el identificador único del entorno de ejecución específico del lenguaje.
  • Cualquier modificación que hayas aplicado al entorno de ejecución.

Configuración de las cargas de trabajo

Para configurar tus cargas de trabajo a medida que las migras de AWS Lambda a Cloud Run, te recomendamos que evalúes cómo configuraste cada carga de trabajo de AWS Lambda.

Para cada carga de trabajo de AWS Lambda, recopila información sobre los siguientes parámetros de configuración de simultaneidad y escalabilidad:

  • Los controles de simultaneidad
  • La configuración de escalabilidad.
  • La configuración de las instancias de la carga de trabajo, en términos de la cantidad de memoria disponible y el tiempo de ejecución máximo permitido.
  • Si la carga de trabajo usa AWS Lambda SnapStart, simultaneidad reservada o simultaneidad aprovisionada para reducir la latencia.
  • Las variables de entorno que configuraste, así como las que configura AWS Lambda y de las que depende la carga de trabajo.
  • Las etiquetas y el control de acceso basado en atributos
  • La máquina de estado para controlar condiciones excepcionales.
  • Las imágenes base y los archivos de configuración (como el Dockerfile) para los paquetes de implementación que usan imágenes de contenedor.

Controles de acceso y permisos

Como parte de tu evaluación, te recomendamos que analices los requisitos de seguridad de tus cargas de trabajo de AWS Lambda y su configuración en términos de controles de acceso y administración. Esta información es fundamental si necesitas implementar controles similares en tu entorno de Google Cloud . Para cada carga de trabajo, considera lo siguiente:

  • El rol y los permisos de ejecución.
  • La configuración de administración de identidades y accesos que usan la carga de trabajo y sus capas para acceder a otros recursos.
  • Es la configuración de administración de identidades y accesos que usan otras cuentas y servicios para acceder a la carga de trabajo.
  • Los controles de administración.

Requisitos de cumplimiento y reglamentarios

Para cada carga de trabajo de AWS Lambda, asegúrate de comprender sus requisitos de cumplimiento y reglamentarios. Para ello, haz lo siguiente:

  • Evalúa los requisitos normativos y de cumplimiento que debe cumplir la carga de trabajo.
  • Determinar si la carga de trabajo cumple con estos requisitos
  • Determina si hay requisitos futuros que se deban cumplir.

Los requisitos de cumplimiento y reglamentarios pueden ser independientes del proveedor de servicios en la nube que uses, y estos requisitos también pueden tener un impacto en la migración. Por ejemplo, es posible que debas asegurarte de que los datos y el tráfico de red permanezcan dentro de los límites de ciertas ubicaciones geográficas, como la Unión Europea (UE).

Evalúa los procesos operativos y de implementación

Es fundamental comprender claramente cómo funcionan los procesos operativos y de implementación. Estas son una parte fundamental de las prácticas que preparan y mantienen tu entorno de producción y las cargas de trabajo que se ejecutan allí.

Es posible que tus procesos operativos y de implementación compilen los artefactos que tus cargas de trabajo necesitan para funcionar. Por lo tanto, debes recopilar información sobre cada tipo de artefacto. Por ejemplo, un artefacto puede ser un paquete de sistema operativo, un paquete de implementación de aplicaciones, una imagen de sistema operativo, una imagen de contenedor o algo más.

Además del tipo de artefacto, considera cómo completar las siguientes tareas:

  • Desarrolla tus cargas de trabajo. Evalúa los procesos que tienen los equipos de desarrollo para compilar tus cargas de trabajo. Por ejemplo, ¿cómo diseñan, programan y prueban tus cargas de trabajo los equipos de desarrollo?
  • Genera los artefactos que implementas en tu entorno de origen. Para implementar tus cargas de trabajo en tu entorno de origen, es posible que generes artefactos implementables, como imágenes de contenedor o de sistema operativo, o que personalices artefactos existentes, como imágenes de sistema operativo de terceros, instalando y configurando software. La recopilación de información sobre cómo generas estos artefactos te ayuda a garantizar que los artefactos generados sean adecuados para la implementación en Google Cloud.

  • Almacena los artefactos. Si produces artefactos que almacenas en un registro de artefactos en tu entorno de origen, debes hacer que los artefactos estén disponibles en tu entorno de Google Cloud . Para ello, puedes emplear estrategias como las siguientes:

    • Establece un canal de comunicación entre los entornos: Haz que se pueda acceder a los artefactos de tu entorno de origen desde el entorno de destino deGoogle Cloud .
    • Refactoriza el proceso de compilación de artefactos: Completa una refactorización menor de tu entorno de origen para que puedas almacenar artefactos en el entorno de origen y en el de destino. Este enfoque respalda tu migración, ya que compila infraestructura, como un repositorio de artefactos, antes de que tengas que implementar procesos de compilación de artefactos en el entorno de Google Cloud destino. Puedes implementar este enfoque directamente o puedes basarte en el enfoque anterior de establecer primero un canal de comunicación.

    Tener artefactos disponibles en los entornos de origen y de destino te permite enfocarte en la migración sin tener que implementar procesos de compilación de artefactos en el entorno de Google Cloud de destino como parte de la migración.

  • Analiza y firma el código. Como parte de tus procesos de compilación de artefactos, es posible que uses el análisis de código para protegerte contra vulnerabilidades comunes y la exposición no deseada de la red, y la firma de código para asegurarte de que solo se ejecute código de confianza en tus entornos.

  • Implementa artefactos en tu entorno de origen. Después de generar artefactos implementables, puedes implementarlos en tu entorno de origen. Te recomendamos que evalúes cada proceso de implementación. La evaluación ayuda a garantizar que tus procesos de implementación sean compatibles con Google Cloud. También te ayuda a comprender el esfuerzo que se necesitará para refactorizar los procesos con el tiempo. Por ejemplo, si tus procesos de implementación funcionan solo con tu entorno de origen, es posible que debas refactorizarlos para que se orienten a tu entorno de Google Cloud .

  • Incorpora la configuración del entorno de ejecución. Es posible que estés insertando una configuración del entorno de ejecución para clústeres, entornos de ejecución o implementaciones de cargas de trabajo específicos. La configuración puede inicializar variables de entorno y otros valores de configuración, como secretos, credenciales y claves. Para garantizar que los procesos de inserción de configuración del entorno de ejecución funcionen en Google Cloud, te recomendamos que evalúes cómo estás configurando las cargas de trabajo que se ejecutan en tu entorno de origen.

  • Registro, supervisión y generación de perfiles. Evalúa los procesos de registro, supervisión y generación de perfiles que tienes implementados para supervisar el estado de tu entorno de origen, las métricas de interés y cómo consumes los datos que proporcionan estos procesos.

  • Autenticación. Evalúa cómo te autenticas en tu entorno de origen.

  • Aprovisiona y configura tus recursos. Para preparar tu entorno de origen, es posible que hayas diseñado e implementado procesos que aprovisionen y configuren recursos. Por ejemplo, puedes usar Terraform junto con las herramientas de administración de configuración para aprovisionar y configurar recursos en tu entorno de origen. Si usas Terraform, puedes compilar tus bases y la zona de destino en Google Cloud con las siguientes herramientas, según el punto de partida que prefieras:

Completa la evaluación

Después de compilar los inventarios de tu entorno de AWS Lambda, completa el resto de las actividades de la fase de evaluación como se describe en Migra a Google Cloud: Evalúa y descubre tus cargas de trabajo.

Planifica y compila tu base

En la fase de planificación y compilación, aprovisionarás y configurarás la infraestructura para hacer lo siguiente:

  • Admitir tus cargas de trabajo en tu entorno de Google Cloud .
  • Conectar tu entorno de origen y tu entorno de Google Cloud para completar la migración

La fase de planificación y compilación se compone de las siguientes tareas:

  1. Compila una jerarquía de recursos.
  2. Configura Identity and Access Management (IAM) de Google Cloud.
  3. Configura la facturación.
  4. Configura la conectividad de red.
  5. Endurece tu seguridad.
  6. Configurar el registro, la supervisión y las alertas

Para obtener más información sobre cada una de estas tareas, consulta Migra a Google Cloud: Planifica y compila tu base.

Migra tus cargas de trabajo de AWS Lambda

Para migrar tus cargas de trabajo de AWS Lambda a Cloud Run, haz lo siguiente:

  1. Diseñar, aprovisionar y configurar tu entorno de Cloud Run
  2. Si es necesario, refactoriza tus cargas de trabajo de AWS Lambda para que sean compatibles con Cloud Run.
  3. Refactorizar tus procesos de implementación y operativos para implementar y observar tus cargas de trabajo en Cloud Run
  4. Migra los datos que necesitan tus cargas de trabajo de AWS Lambda.
  5. Valida los resultados de la migración en términos de funcionalidad, rendimiento y costo.

Para ayudarte a evitar problemas durante la migración y estimar el esfuerzo necesario para la migración, te recomendamos que evalúes cómo se comparan las funciones de AWS Lambda con las funciones similares de Cloud Run. Las funciones de AWS Lambda y Cloud Run pueden parecer similares cuando las comparas. Sin embargo, las diferencias en el diseño y la implementación de las funciones de los dos proveedores de servicios en la nube pueden tener efectos significativos en la migración de AWS Lambda a Cloud Run. Estas diferencias pueden influir en tus decisiones de diseño y refactorización, como se destaca en las siguientes secciones.

Diseña, aprovisiona y configura tu entorno de Cloud Run

El primer paso de la fase de migración es diseñar tu entorno de Cloud Run para que pueda admitir las cargas de trabajo que migrarás desde AWS Lambda.

Para diseñar correctamente tu entorno de Cloud Run, usa los datos que recopilaste durante la fase de evaluación sobre cada carga de trabajo de AWS Lambda. Estos datos te ayudan a hacer lo siguiente:

  1. Elegir los recursos de Cloud Run adecuados para implementar tu carga de trabajo
  2. Diseñar la configuración de tus recursos de Cloud Run
  3. Aprovisionar y configurar los recursos de Cloud Run

Elige los recursos de Cloud Run adecuados

Para cada carga de trabajo de AWS Lambda que se migrará, elige el recurso de Cloud Run adecuado para implementar tus cargas de trabajo. Cloud Run admite los siguientes recursos principales:

  • Servicios de Cloud Run: Es un recurso que aloja un entorno de ejecución alojado en contenedores, expone un extremo único y escala automáticamente la infraestructura subyacente según la demanda.
  • Trabajos de Cloud Run: Es un recurso que ejecuta uno o más contenedores hasta su finalización.

En la siguiente tabla, se resume cómo se asignan los recursos de AWS Lambda a estos recursos principales de Cloud Run:

Recurso de AWS Lambda Recurso de Cloud Run
Función de AWS Lambda que se activa con un evento, como los que se usan para sitios web y aplicaciones web, APIs y microservicios, procesamiento de datos de transmisión y arquitecturas controladas por eventos. Servicio de Cloud Run que puedes invocar con activadores.
Función de AWS Lambda que se programó para ejecutarse, como las de tareas en segundo plano y trabajos por lotes. Trabajo de Cloud Run que se ejecuta hasta su finalización.

Además de los servicios y los trabajos, Cloud Run proporciona recursos adicionales que extienden estos recursos principales. Para obtener más información sobre todos los recursos disponibles de Cloud Run, consulta Modelo de recursos de Cloud Run.

Diseña la configuración de tus recursos de Cloud Run

Antes de aprovisionar y configurar tus recursos de Cloud Run, debes diseñar su configuración. Algunas opciones de configuración de AWS Lambda, como los límites de recursos y los tiempos de espera de las solicitudes, son comparables con opciones de configuración similares de Cloud Run. En las siguientes secciones, se describen las opciones de configuración que están disponibles en Cloud Run para los activadores de servicios y la ejecución de trabajos, la configuración de recursos y la seguridad. En estas secciones, también se destacan las opciones de configuración de AWS Lambda que son comparables con las de Cloud Run.

Activadores de servicios y ejecución de trabajos de Cloud Run

Los activadores de servicios y la ejecución de trabajos son las decisiones de diseño principales que debes tener en cuenta cuando migras tus cargas de trabajo de AWS Lambda. Cloud Run proporciona una variedad de opciones para activar y ejecutar las cargas de trabajo basadas en eventos que se usan en AWS Lambda. Además, Cloud Run proporciona opciones que puedes usar para cargas de trabajo de transmisión y trabajos programados.

Cuando migras tus cargas de trabajo, suele ser útil comprender primero qué activadores y mecanismos están disponibles en Cloud Run. Esta información te ayuda a comprender cómo funciona Cloud Run. Luego, puedes usar esta información para determinar qué funciones de Cloud Run son comparables con las de AWS Lambda y cuáles se podrían usar cuando se refactoricen esas cargas de trabajo.

Para obtener más información sobre los activadores de servicios que proporciona Cloud Run, usa los siguientes recursos:

Para obtener más información sobre los mecanismos de ejecución de trabajos que proporciona Cloud Run, usa los siguientes recursos:

Para ayudarte a comprender qué mecanismos de invocación o ejecución de Cloud Run son comparables con los mecanismos de invocación de AWS Lambda, usa la siguiente tabla. Para cada recurso de Cloud Run que necesites aprovisionar, asegúrate de elegir el mecanismo de invocación o ejecución correcto.

Función de AWS Lambda Función de Cloud Run
Activador HTTPS (URLs de funciones) Invocación HTTPS
Activador HTTP/2 (compatible de forma parcial con una puerta de enlace de API externa) Invocación de HTTP/2 (compatible de forma nativa)
WebSockets (compatibles con la puerta de enlace de API externa) WebSockets (compatibles de forma nativa)
N/A (no se admiten conexiones de gRPC) Conexiones de gRPC
Invocación asíncrona Integración de Cloud Tasks
Invocación programada Integración de Cloud Scheduler
Activador basado en eventos en un formato de evento de propiedad Invocación basada en eventos en formato de CloudEvents
Integración de Amazon SQS y Amazon SNS Integración en Pub/Sub
AWS Lambda Step Functions Integración de Workflows
Configuración de recursos de Cloud Run

Para complementar las decisiones de diseño que tomaste para activar y ejecutar tus cargas de trabajo migradas, Cloud Run admite varias opciones de configuración que te permiten ajustar varios aspectos del entorno de ejecución. Estas opciones de configuración consisten en servicios y trabajos de recursos.

Como se mencionó antes, puedes comprender mejor cómo funciona Cloud Run si primero comprendes todas las opciones de configuración que están disponibles en Cloud Run. Esta comprensión te ayuda a comparar las funciones de AWS Lambda con funciones similares de Cloud Run y a determinar cómo refactorizar tus cargas de trabajo.

Para obtener más información sobre los parámetros de configuración que proporcionan los servicios de Cloud Run, consulta los siguientes recursos:

Para obtener más información sobre los trabajos que proporciona Cloud Run, usa los siguientes recursos:

Para ayudarte a comprender qué opciones de configuración de Cloud Run son comparables con las opciones de configuración de AWS Lambda, usa la siguiente tabla. Para cada recurso de Cloud Run que necesites aprovisionar, asegúrate de elegir las opciones de configuración correctas.

Función de AWS Lambda Función de Cloud Run
Simultaneidad aprovisionada Cantidad mínima de instancias
Simultaneidad reservada por instancia
(el grupo de simultaneidad se comparte entre las funciones de AWS Lambda en tu cuenta de AWS).		 Cantidad máxima de instancias por servicio
N/A (no admitido, una solicitud se asigna a una instancia) Solicitudes simultáneas por instancia
N/A (depende de la asignación de memoria) Asignación de CPU
Configuración de escalabilidad Ajuste de escala automático de instancias para servicios
Paralelismo para trabajos
Configuración de la instancia (CPU, memoria) Límites de CPU y memoria
Tiempo máximo de ejecución Tiempo de espera de la solicitud para los servicios
Tiempo de espera de la tarea para los trabajos
AWS Lambda SnapStart Aumento de CPU de inicio
Variables de entorno Variables de entorno
Almacenamiento de datos efímero Activaciones de volúmenes en memoria
Conexiones de Amazon Elastic File System Activaciones de volúmenes NFS
No se admiten las activaciones de volúmenes de S3 Activaciones de volúmenes de Cloud Storage
AWS Secrets Manager en cargas de trabajo de AWS Lambda Secrets
URLs de cargas de trabajo y extremos HTTP(S) URLs asignadas automáticamente
Integraciones de Cloud Run con productos de Google Cloud
Sesiones fijas (con un balanceador de cargas externo) Afinidad de sesión
Clasificatorias Revisiones

Además de las funciones que se enumeran en la tabla anterior, también debes considerar las diferencias entre la forma en que AWS Lambda y Cloud Run aprovisionan instancias del entorno de ejecución. AWS Lambda aprovisiona una sola instancia para cada solicitud simultánea. Sin embargo, Cloud Run te permite establecer la cantidad de solicitudes simultáneas que puede entregar una instancia. Es decir, el comportamiento de aprovisionamiento de AWS Lambda equivale a establecer en 1 la cantidad máxima de solicitudes simultáneas por instancia en Cloud Run. Establecer la cantidad máxima de solicitudes simultáneas en más de 1 puede ahorrar costos de forma significativa, ya que la CPU y la memoria de la instancia se comparten entre las solicitudes simultáneas, pero solo se facturan una vez. La mayoría de los frameworks de HTTP están diseñados para controlar solicitudes en paralelo.

Seguridad y control de acceso de Cloud Run

Cuando diseñes tus recursos de Cloud Run, también debes decidir los controles de seguridad y acceso que necesitas para tus cargas de trabajo migradas. Cloud Run admite varias opciones de configuración para ayudarte a proteger tu entorno y establecer roles y permisos para tus cargas de trabajo de Cloud Run.

En esta sección, se destacan los controles de seguridad y acceso que están disponibles en Cloud Run. Esta información te ayuda a comprender cómo funcionarán tus cargas de trabajo migradas en Cloud Run y a identificar las opciones de Cloud Run que podrías necesitar si refactorizas esas cargas de trabajo.

Para obtener más información sobre los mecanismos de autenticación que proporciona Cloud Run, consulta los siguientes recursos:

Para obtener más información sobre las funciones de seguridad que proporciona Cloud Run, usa los siguientes recursos:

Para ayudarte a comprender qué controles de seguridad y acceso de Cloud Run son comparables con los que están disponibles en AWS Lambda, usa la siguiente tabla. Para cada recurso de Cloud Run que necesites aprovisionar, asegúrate de elegir los controles de acceso y las funciones de seguridad adecuados.

Función de AWS Lambda Función de Cloud Run
Control de acceso con AWS Identity and Access Management Control de acceso con la IAM de Google Cloud
Rol de ejecución Rol de IAM deGoogle Cloud
Límites de permisos Permisos de IAM y públicos personalizados deGoogle Cloud
Controles de administración Servicio de políticas de la organización
Firma de código Autorización Binaria
Acceso completo a la VPC Controles de acceso detallados para la salida de VPC

Aprovisionar y configurar recursos de Cloud Run

Después de elegir los recursos de Cloud Run para implementar tus cargas de trabajo, aprovisionas y configuras esos recursos. Para obtener más información sobre el aprovisionamiento de recursos de Cloud Run, consulta los siguientes vínculos:

Refactoriza las cargas de trabajo de AWS Lambda

Para migrar tus cargas de trabajo de AWS Lambda a Cloud Run, es posible que debas refactorizarlas. Por ejemplo, si una carga de trabajo basada en eventos acepta activadores que contienen eventos de Amazon CloudWatch, es posible que debas refactorizar esa carga de trabajo para que acepte eventos en el formato de CloudEvents.

Para ayudarte con la refactorización de tus cargas de trabajo de AWS Lambda, te recomendamos que uses Gemini Code Assist y Gemini CLI. Para obtener más información, consulta Migraciones potenciadas por Gemini a Google Cloud.

Existen varios factores que pueden influir en la cantidad de refactorización que necesitas para cada carga de trabajo de AWS Lambda, como los siguientes:

  • Arquitectura. Considera cómo se diseña la carga de trabajo en términos de arquitectura. Por ejemplo, las cargas de trabajo de AWS Lambda que separaron con claridad la lógica empresarial de la lógica para acceder a las APIs específicas de AWS podrían requerir menos refactorización en comparación con las cargas de trabajo en las que se mezclan las dos lógicas.
  • Idempotencia. Considera si la carga de trabajo es idempotente en relación con sus entradas. Una carga de trabajo que es idempotente para las entradas puede requerir menos refactorización en comparación con las cargas de trabajo que necesitan mantener el estado de las entradas que ya procesaron.
  • State. Considera si la carga de trabajo es sin estado. Una carga de trabajo sin estado puede requerir menos refactorización en comparación con las cargas de trabajo que mantienen el estado. Para obtener más información sobre los servicios que admite Cloud Run para almacenar datos, consulta Opciones de almacenamiento de Cloud Run.
  • Entorno de ejecución. Considera si la carga de trabajo hace alguna suposición sobre su entorno de ejecución. Para estos tipos de cargas de trabajo, es posible que debas cumplir con las mismas suposiciones en el entorno de ejecución de Cloud Run o refactorizar la carga de trabajo si no puedes suponer lo mismo para el entorno de ejecución de Cloud Run. Por ejemplo, si una carga de trabajo requiere que ciertos paquetes o bibliotecas estén disponibles, debes instalarlos en el entorno de ejecución de Cloud Run que alojará esa carga de trabajo.
  • Inyección de configuración. Considera si la carga de trabajo admite el uso de variables de entorno y secretos para insertar (establecer) su configuración. Una carga de trabajo que admite este tipo de inserción puede requerir menos refactorización en comparación con las cargas de trabajo que admiten otros mecanismos de inserción de configuración.
  • APIs. Considera si la carga de trabajo interactúa con las APIs de AWS Lambda. Es posible que se deba refactorizar una carga de trabajo que interactúa con estas APIs para usar las API de Cloud y las APIs de Cloud Run.
  • Error Reporting. Considera si la carga de trabajo informa errores con transmisiones de salida estándar y de error. Una carga de trabajo que realiza este informe de errores puede requerir menos refactorización en comparación con las cargas de trabajo que informan errores con otros mecanismos.

Para obtener más información sobre el desarrollo y la optimización de las cargas de trabajo de Cloud Run, consulta los siguientes recursos:

Refactoriza los procesos operativos y de implementación

Después de refactorizar tus cargas de trabajo, refactoriza tus procesos operativos y de implementación para que realicen las siguientes acciones:

  • Aprovisiona y configura recursos en tu entorno de Google Cloud en lugar de aprovisionar recursos en tu entorno de origen.
  • Compila y configura cargas de trabajo, y, luego, impleméntalas en tu Google Cloud en lugar de implementarlas en tu entorno de origen.

Recopilaste información sobre estos procesos durante la fase de evaluación antes en este proceso.

El tipo de refactorización que debes considerar para estos procesos depende de cómo los diseñaste y cómo los implementaste. La refactorización también depende de cuál sea el estado final de cada proceso. Por ejemplo, considera lo siguiente:

  • Es posible que hayas implementado estos procesos en tu entorno de origen y quieras diseñar e implementar procesos similares en Google Cloud. Por ejemplo, puedes refactorizar estos procesos para usar Cloud Build, Cloud Deploy y el Administrador de infraestructura.
  • Es posible que hayas implementado estos procesos en otro entorno de terceros fuera del entorno de origen. En este caso, debes refactorizar estos procesos para orientar tu entorno de Google Cloud en lugar del entorno de origen.
  • Una combinación de los enfoques anteriores.

La refactorización de los procesos operativos y de implementación puede ser complejo y puede requerir un esfuerzo significativo. Si intentas realizar estas tareas como parte de la migración de la carga de trabajo, esta puede volverse más compleja y exponerte a riesgos. Después de evaluar los procesos operativos y de implementación, es probable que comprendas el diseño y la complejidad. Si estimas que necesitas un esfuerzo sustancial para refactorizar tus procesos operativos y de implementación, te recomendamos que consideres la refactorización de estos procesos como parte de un proyecto independiente y dedicado.

Para obtener más información sobre cómo diseñar e implementar procesos de implementación en Google Cloud, consulta los siguientes recursos:

Este documento se enfoca en los procesos de implementación que producen los artefactos que se implementarán y los implementan en el entorno de ejecución de destino. La estrategia de refactorización depende en gran medida de la complejidad de estos procesos. En la siguiente lista, se describe una posible estrategia general de refactorización:

  1. Aprovisiona repositorios de artefactos en Google Cloud. Por ejemplo, puedes usar Artifact Registry para almacenar artefactos y compilar dependencias.
  2. Refactorizar tus procesos de compilación para almacenar artefactos en tu entorno de origen y en Artifact Registry.
  3. Refactoriza tus procesos de implementación para implementar tus cargas de trabajo en tu entorno de Google Cloud de destino. Por ejemplo, puedes comenzar por implementar un subconjunto pequeño de tus cargas de trabajo en Google Cloudcon artefactos almacenados en Artifact Registry. Luego, aumenta de forma gradual la cantidad de cargas de trabajo implementadas en Google Cloudhasta que todas las cargas de trabajo que se migrarán se ejecuten en Google Cloud.
  4. Refactoriza tus procesos de compilación para almacenar artefactos solo en Artifact Registry.
  5. Si es necesario, migra las versiones anteriores de los artefactos que se implementarán desde los repositorios de tu entorno de origen a Artifact Registry. Por ejemplo, para migrar imágenes de contenedor a Artifact Registry, puedes usar herramientas como gcrane o Rackware SWIFT.
  6. Inhabilita los repositorios en tu entorno de origen cuando ya no los necesites.

Para facilitar las reversiones eventuales debido a problemas imprevistos durante la migración, puedes almacenar imágenes de contenedor en tus repositorios de artefactos actuales en Google Cloud mientras la migración a Google Cloud está en curso. Por último, como parte de la baja de tu entorno de origen, puedes refactorizar los procesos de compilación de imágenes de contenedor para almacenar artefactos solo en Google Cloud .

Aunque es posible que no sea crucial para el éxito de una migración, es posible que debas migrar las versiones anteriores de tus artefactos desde tu entorno de origen a tus repositorios de artefactos en Google Cloud. Por ejemplo, para admitir la reversión de tus cargas de trabajo a momentos arbitrarios, es posible que debas migrar versiones anteriores de tus artefactos a Artifact Registry. Para obtener más información, consulta Migra imágenes desde un registro de terceros.

Si usas Artifact Registry para almacenar tus artefactos, te recomendamos que configures controles que te ayuden a proteger tus repositorios de artefactos, como el control de acceso, la prevención de robo de datos, el análisis de vulnerabilidades y la Autorización Binaria. Para obtener más información, consulta Controla el acceso y protege los artefactos.

Refactoriza los procesos operativos

Como parte de la migración a Cloud Run, te recomendamos que refactorices tus procesos operativos para supervisar de forma constante y eficaz tu entorno de Cloud Run.

Cloud Run se integra en los siguientes servicios operativos:

Migrar datos

La fase de evaluación anterior en este proceso debería haberte ayudado a determinar si las cargas de trabajo de AWS Lambda que estás migrando dependen de los datos que residen en tu entorno de AWS o los producen. Por ejemplo, es posible que hayas determinado que necesitas migrar datos de AWS S3 a Cloud Storage, o de Amazon RDS y Aurora a Cloud SQL y AlloyDB para PostgreSQL. Para obtener más información sobre cómo migrar datos de AWS a Google Cloud, consulta Migra de AWS a Google Cloud: Comienza ahora.

Al igual que con la refactorización de los procesos operativos y de implementación, la migración de datos de AWS a Google Cloud puede ser compleja y puede requerir un esfuerzo significativo. Si intentas realizar estas tareas de migración de datos como parte de la migración de tus cargas de trabajo de AWS Lambda, la migración puede volverse compleja y exponerte a riesgos. Después de analizar los datos que se migrarán, es probable que comprendas el tamaño y la complejidad de los datos. Si estimas que necesitas un esfuerzo sustancial para migrar estos datos, te recomendamos que consideres la migración de datos como parte de un proyecto independiente y dedicado.

Valida los resultados de la migración

La validación de la migración de la carga de trabajo no es un evento único, sino un proceso continuo. Debes mantener el enfoque en las pruebas y la validación antes, durante y después de migrar de AWS Lambda a Cloud Run.

Para garantizar una migración exitosa con un rendimiento óptimo y un mínimo de interrupciones, te recomendamos que uses el siguiente proceso para validar las cargas de trabajo que migras de AWS Lambda a Cloud Run:

  • Antes de comenzar la fase de migración, refactoriza tus casos de prueba existentes para tener en cuenta el entorno de destino de Google Cloud .
  • Durante la migración, valida los resultados de las pruebas en cada hito de la migración y realiza pruebas de integración exhaustivas.
  • Después de las migraciones, realiza las siguientes pruebas:
    • Pruebas de referencia: Establece comparativas de rendimiento de la carga de trabajo original en AWS Lambda, como el tiempo de ejecución, el uso de recursos y las tasas de error con diferentes cargas. Replica estas pruebas en Cloud Run para identificar discrepancias que podrían indicar problemas de migración o configuración.
    • Pruebas funcionales: Asegúrate de que la lógica principal de tus cargas de trabajo sea coherente creando y ejecutando casos de prueba que abarquen varias situaciones de entrada y salida esperadas en ambos entornos.
    • Pruebas de carga: Aumenta el tráfico de forma gradual para evaluar el rendimiento y la escalabilidad de Cloud Run en condiciones reales. Para garantizar una migración sin problemas, aborda las discrepancias, como los errores y las limitaciones de recursos.

Optimiza tu entorno de Google Cloud

La optimización es la última fase de la migración. En esta fase, iteras en tareas de optimización hasta que tu entorno de destino cumpla con tus requisitos de optimización. Los pasos de cada iteración son los siguientes:

  1. Evalúa tu entorno actual, los equipos y el ciclo de optimización.
  2. Establece tus requisitos y objetivos de optimización.
  3. Optimiza el entorno y los equipos.
  4. Ajustar el bucle de optimización

Repite esta secuencia hasta que hayas alcanzado tus objetivos de optimización.

Para obtener más información sobre cómo optimizar tu Google Cloud entorno, consulta Migra a Google Cloud: Optimiza tu entorno y Google Cloud Well-Architected Framework: Optimización del rendimiento.

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores: