|
|
Las organizaciones están adoptando arquitecturas de microservicios para crear aplicaciones resilientes y escalables mediante AWS Lambda. Estas aplicaciones se componen de múltiples funciones sin servidor que implementan la lógica empresarial. Cada función se asigna a los puntos finales, métodos y recursos de la API mediante servicios como Amazon API Gateway y Application Load Balancer.
Pero a veces, todo lo que necesita es una forma sencilla de configurar un punto final HTTPS frente a su función sin tener que aprender, configurar y operar servicios adicionales además de Lambda. Por ejemplo, es posible que necesite implementar un controlador de webhook o un validador de formulario simple que se ejecute dentro de una función de Lambda individual.
Hoy, me complace anunciar la disponibilidad general de las URL de la función Lambda, una nueva característica que le permite agregar puntos finales HTTPS a cualquier función Lambda y, opcionalmente, configurar Encabezados de uso compartido de recursos de origen cruzado (CORS).
Esto le permite concentrarse en lo que importa mientras nosotros nos encargamos de configurar y monitorear un servicio HTTPS altamente disponible, escalable y seguro.
Cómo funcionan las URL de la función Lambda
Cree una nueva URL de función y asígnela a cualquier función. Cada URL de función es globalmente única y se puede asociar con el alias de una función o el ARN no calificado de la función, que invoca implícitamente el $LATEST versión.
Por ejemplo, si asigna una URL de función a su $LATEST versión, cada actualización de código estará disponible inmediatamente a través de la función URL. Por otro lado, recomendaría asignar una URL de función a un alias, para que pueda implementar nuevas versiones de manera segura, realizar algunas pruebas de integración y luego actualizar el alias cuando esté listo. Esto también le permite implementar cambios de tráfico ponderados e implementaciones seguras.
Las URL de funciones son compatibles de forma nativa con la API de Lambda y puede comenzar a usarlas a través de la Consola de administración de AWS o los SDK de AWS, así como herramientas de infraestructura como código (IaC) como AWS CloudFormation, AWS SAM o AWS Cloud Development Kit (AWS CDK).
URL de función Lambda en acción
Puede configurar una URL de función para una función nueva o existente. Veamos cómo implementar una nueva función para manejar un webhook.
Al crear una nueva función, compruebo Habilitar URL de función en Ajustes avanzados.
Aquí, selecciono el tipo de autenticación: AWS_IAM o NINGUNA. Mi webhook utilizará una lógica de autorización personalizada basada en una firma proporcionada en los encabezados HTTP. Por lo tanto, elegiré AuthType None, lo que significa que Lambda no verificará ninguna firma de AWS IAM Sigv4 antes de invocar mi función. En su lugar, extraeré y validaré un encabezado personalizado en mi controlador de funciones para la autorización.
Tenga en cuenta que cuando use AuthType None, la política basada en recursos de mi función aún debe permitir explícitamente el acceso público. De lo contrario, las solicitudes no autenticadas serán rechazadas. Puede agregar permisos programáticamente usando el Agregar permiso API. En este caso, la consola de Lambda agrega automáticamente la política necesaria para mí, ya que el rol de IAM que estoy usando está autorizado para llamar al Agregar permiso API en mi cuenta.
Con un clic, también puedo habilitar CORS. La configuración predeterminada de CORS permitirá todos los orígenes. Luego, agregaré más controles granulares después de crear la función. En caso de que no esté familiarizado con CORS, es un mecanismo de seguridad basado en encabezados implementado por los navegadores para asegurarse de que solo ciertos hosts puedan cargar recursos e invocar API. Si un sitio web puede consumir su API, deberá incluir algunos encabezados CORS que declaren qué orígenes, métodos y encabezados personalizados están permitidos. Las nuevas URL de función se encargan de eso por usted, por lo que no tiene que implementar todo esto en su controlador de Lambda.
Unos segundos más tarde, la URL de la función está disponible. También puedo encontrarlo y copiarlo fácilmente en la consola de Lambda.
El código de función que maneja mi webhook en Node.js se ve así:
exports.handler = async (event) => {
// (optional) fetch method and querystring
const method = event.requestContext.http.method;
const queryParam = event.queryStringParameters.myCustomParameter;
console.log(`Received ${method} request with ${queryParam}`)
// retrieve signature and payload
const webhookSignature = event.headers.SignatureHeader;
const webhookPayload = JSON.parse(event.body);
try {
validateSignature(webhookSignature); // throws if invalid signature
handleEvent(webhookPayload); // throws if processing error
} catch (error) {
console.error(error)
return {
statusCode: 400,
body: `Cannot process event: ${error}`,
}
}
return {
statusCode: 200, // default value
body: JSON.stringify({
received: true,
}),
};
};
El código extrae algunos parámetros de los encabezados de la solicitud, la cadena de consulta y el cuerpo. Si ya está familiarizado con la estructura de eventos proporcionada por API Gateway o Application Load Balancer, esto debería resultarle muy familiar.
Después de actualizar el código, decido probar la URL de la función con un cliente HTTP.
Por ejemplo, así es como lo haría con curl:
$ curl "https://4iykoi7jk2kp5hhd5irhbdprn40yxest.lambda-url.us-west-2.on.aws/?myCustomParameter=squirrel"
-X POST
-H "SignatureHeader: XYZ"
-H "Content-type: application/json"
-d '{"type": "payment-succeeded"}'O con un script de Python:
import json
import requests
url = "https://4iykoi7jk2kp5hhd5irhbdprn40yxest.lambda-url.us-west-2.on.aws/"
headers = {'SignatureHeader': 'XYZ', 'Content-type': 'application/json'}
payload = json.dumps({'type': 'payment-succeeded'})
querystring = {'myCustomParameter': 'squirrel'}
r = requests.post(url=url, params=querystring, data=payload, headers=headers)
print(r.json())No olvide configurar la solicitud Content-type para application/json o text/* en sus pruebas, de lo contrario, el cuerpo estará codificado en base64 de forma predeterminada y deberá decodificarlo en el controlador de Lambda.
Por supuesto, en este caso estamos hablando de un webhook, por lo que esta función recibirá solicitudes directamente del sistema externo con el que me estoy integrando. Solo necesito proporcionarles la URL de la función pública y comenzar a recibir eventos.
Para este caso de uso específico, no necesito ninguna configuración de CORS. En otros casos en los que se llama a la URL de la función desde el navegador, necesitaría configurar algunos parámetros CORS más, como Access-Control-Allow-Origin, Access-Control-Allow-Methodsy Access-Control-Expose-Headers. Puedo revisar y editar fácilmente estos parámetros de CORS en la consola de Lambda o en mis plantillas de IaC. Así es como se ve en la consola:
Además, tenga en cuenta que cada URL de función es única y se asigna a un alias específico o al $LATEST versión de su función. Esto le permite definir varias URL para la misma función. Por ejemplo, puede definir uno para probar el $LATEST versión durante el desarrollo y una para cada etapa o alias, como staging, productiony así.
Compatibilidad con infraestructura como código (IaC)
Puede comenzar a configurar las URL de la función Lambda directamente en sus plantillas de IaC hoy utilizando AWS CloudFormation, AWS SAM y AWS Cloud Development Kit (AWS CDK).
Por ejemplo, aquí se explica cómo definir una función de Lambda y su URL pública con AWS SAM, incluido el mapeo de alias:
WebhookFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: webhook/
Handler: index.handler
Runtime: nodejs14.x
AutoPublishAlias: live
FunctionUrlConfig:
AuthType: NONE
Cors:
AllowOrigins:
- "https://example.com"Si tiene funciones Lambda existentes en sus plantillas de IaC, puede definir una nueva URL de función con unas pocas líneas de código.
Precio de la URL de la función
Las direcciones URL de las funciones se incluyen en los precios de solicitud y duración de Lambda. Por ejemplo, imaginemos que implementa una sola función de Lambda con 128 MB de memoria y un tiempo de invocación promedio de 50 ms. La función recibe cinco millones de solicitudes cada mes, por lo que el costo será de $1.00 por las solicitudes y $0.53 por la duración. El total general es de $1.53 por mes, en la región EE.UU. Este (Norte de Virginia).
Cuándo usar URL de función frente a Amazon API Gateway
Las URL de función son mejores para los casos de uso en los que debe implementar un microservicio de una sola función con un punto final público que no requiere la funcionalidad avanzada de API Gateway, como validación de solicitudes, limitación, autorizadores personalizados, nombres de dominio personalizados, planes de uso o almacenamiento en caché Por ejemplo, cuando implementa controladores de webhook, validadores de formularios, procesamiento de pagos móviles, colocación de anuncios, inferencia de aprendizaje automático, etc. También es la forma más sencilla de invocar sus funciones de Lambda durante la investigación y el desarrollo sin salir de la consola de Lambda ni integrar servicios adicionales.
Amazon API Gateway es un servicio completamente administrado que le facilita la creación, publicación, mantenimiento, monitoreo y protección de API a cualquier escala. Utilice API Gateway para aprovechar capacidades como JWT/autorizadores personalizados, validación y transformación de solicitudes/respuestas, planes de uso, compatibilidad integrada con AWS WAF, etc.
Generalmente disponible hoy
Actualmente, las URL de función están disponibles en general en todas las regiones de AWS donde está disponible Lambda, excepto en las regiones de China de AWS. El soporte también está disponible a través de muchos socios de AWS Lambda, como Datadog, Lumigo, Pulumi, Serverless Framework, Thundra y Dynatrace.
Estoy ansioso por saber cómo está utilizando esta nueva funcionalidad para simplificar sus arquitecturas sin servidor, especialmente en casos de uso de una sola función en los que desea mantener las cosas simples y rentables.
Consulte la documentación de las nuevas URL de la función Lambda.
— Alex
