You've deployed an application using AWS Lambda and the API gateway service.
You need to deploy a newer version of the application.
Management has instructed that the newer version should be tested before being fully deployed, while the base version is still in continuity.
How can you accomplish this in the easiest way possible?
Click on the arrows to vote for the correct answer
A. B. C. D.Answer - C.
The AWS Documentation mentions the following.
Canary release deployment in API Gateway.
In API Gateway, a canary release deployment uses the deployment stage for the production release of the base version of an API and attaches to the stage a canary release for the new versions, relative to the base version, of the API.
The stage is associated with the initial deployment and the canary with subsequent deployments.
In the beginning, both the stage and the canary point to the same API version.
We use stage and production release interchangeably and use canary and canary release interchangeably throughout this section.
When you enable API execution logging, the canary release has its own logs and metrics generated for all canary requests.
They are reported to a production stage CloudWatch Logs log group as well as a canary-specific CloudWatch Logs log group.
The same applies to access logging.
The separate canary-specific logs are helpful to validate new API changes and decide whether to accept the changes and promote the canary release to the production stage or to discard the changes and revert the canary release from the production stage.
Options A and B are incorrect.
Even though possible, they would add too much of maintenance overhead.
Option C is CORRECT because a small portion of traffic goes to the canary version before the traffic is fully switched to the new release.
Option D is incorrect because this is not the right way for a new deployment.
For more information on the canary release, please refer to the below URL-
https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.htmlThe correct answer is C. Create a canary release in the API Gateway service.
Explanation:
When deploying a new version of an application, it is important to test it before fully deploying it to avoid any issues or unexpected behavior. In this case, the easiest way to accomplish this is by creating a canary release in the API Gateway service.
A canary release is a deployment technique where a small subset of users or traffic is routed to the new version of the application while the majority of the traffic still uses the old version. This allows for testing the new version in production without affecting all users.
To create a canary release in the API Gateway service, you can follow these steps:
Create a new version of the existing Lambda function: This can be done by creating a new version in the AWS Lambda console or by using the AWS CLI. This new version will contain the updated code.
Create a new deployment in the API Gateway: In the API Gateway console, create a new deployment that uses the new version of the Lambda function.
Create a canary release configuration: In the API Gateway console, create a canary release configuration that specifies the percentage of traffic to route to the new deployment.
Test the new version: Monitor the traffic to the new deployment and test the new version with a small subset of users.
Gradually increase traffic to the new version: Once the new version has been tested and verified, gradually increase the percentage of traffic routed to the new deployment until all traffic is using the new version.
Option A is not the best approach as it would require creating a new API Gateway endpoint and a new Lambda function, which could cause confusion for users and result in unnecessary maintenance overhead.
Option B is also not the best approach as it only creates a new version of the existing Lambda function and does not provide any way to test the new version before fully deploying it.
Option D is not the best approach as it requires creating a new resource and method, which could also cause confusion for users and result in unnecessary maintenance overhead. Additionally, it does not provide any way to test the new version before fully deploying it.