A company has a mobile app. The app includes an Amazon API Gateway REST API that invokes AWS Lambda functions. The Lambda functions process data from the app.
The company needs to test updated Lambda functions that have new features. The company must conduct these tests with a subset of users before deployment. The tests must not affect other users of the app.
Which solution will meet these requirements with the LEAST amount of operational effort?
The most efficient approach to test updated Lambda functions with new features for a subset of users without affecting others involves creating a new version of each Lambda function with a weighted alias. This solution requires less operational effort as it avoids creating and managing new APIs, unlike other options that involve more complex configurations. By using weighted aliases, the company can precisely control the distribution of traffic to different versions of the Lambda functions, ensuring that only a small, controllable subset of users is exposed to the updated functions while keeping the process streamlined and manageable.
This is the least amount of effort. I originally thought answer A but then you will have more effort because will have to update API Gateway configuration to use new ARN etc. Unless there are other thoughts on this?
Prefer A, because creating a new REST API (B) involves more operational overhead and complexity compared to using weighted aliases. Moreover, setting up a Lambda proxy integration to connect to multiple Lambda functions can increase complexity, especially when handling different versions for canary testing.
Option A involves using weighted aliases for Lambda functions, which is a valid approach but requires more effort to manage and update the aliases in the API Gateway configuration.
Lambda with weighted alias with weight configured for each version of the function. The canary situation is much suitable for deployments.
The wording is screaming out weighted alias. During a canary deployment, we are moving code from testing to prod. We can define a subset of users i.e. 10% for a set period of time. After this the other users will be impacted as the percentage will increment or the deployment will push new code to 100% of users. With a weighted alias we can define a subset of users and use this as our guinea pigs to test new code. As this isn't a canary deployment we have no risk of more users becoming impacted. Operational overhead is minimal as we only need to point to a new alias. With weighted alias we can deploy for testing purposes. From my understanding lambda proxy is grouping lambda functions. the traffic splitting would need to be set at the lambda level as this is testing prior to deployment.
Should be B
It says: with the LEAST amount of operational effort B --- NEVER A!!!
https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
This is possible but the question stated less operational effort.
Opção A
Option A is typically the most straightforward and requires the least operational effort while providing high control over traffic distribution directly from the Lambda configuration. This method avoids the overhead of managing additional services or creating new APIs and is directly supported by AWS services for testing purposes with actual users.
A is the correct answer.
} El desarrollador debe crear una nueva API REST en Amazon API Gateway y configurar una integración Lambda sin proxy para conectarse a múltiples funciones Lambda. Luego, debe especificar los parámetros y propiedades necesarios en API Gateway y habilitar la configuración canary en la etapa de implementación. Especifique un porcentaje menor de tráfico API para ir a la nueva versión de la función Lambda. Al utilizar una nueva API REST en API Gateway con una configuración canary, el desarrollador puede probar las funciones Lambda actualizadas con nuevas características con un subconjunto de usuarios antes de la implementación completa. Esto permite realizar pruebas sin afectar a otros usuarios de la aplicación y con un menor esfuerzo operativo.