Create a parallel environment behind the ALB with the new build and configure API Gateway canary release to send a small portion of requests to it is correct because it lets you route a small percentage of API traffic to the new EC2 instances behind the existing ALB and observe behavior before increasing the rollout.

This canary release approach requires no changes to application code and only minimal configuration at the API stage. You deploy a parallel backend behind the ALB and then use API Gateway canary weights to shift traffic incrementally. If a defect is detected you can quickly revert by reducing the canary weight or disabling the canary which gives fast rollback without touching DNS or redeploying the fleet.

Use AWS CodeDeploy blue/green with the Auto Scaling group behind the ALB and shift production traffic to the new revision can achieve safe cutovers but it is more invasive because it typically requires deployment agents and AppSpec configuration and introduces additional deployment tooling compared with controlling traffic at the API layer.

Stand up a duplicate environment and update the Route 53 alias to the new stack forces a full DNS cutover that exposes all users at once and can be slower to roll back due to DNS propagation and caching which makes progressive validation harder.

Create a new target group for the ALB and have API Gateway weight requests directly to that target group is not viable because API Gateway does not natively weight traffic across ALB target groups. The supported weighted exposure mechanism when API Gateway fronts a backend is a canary deployment at the API stage.

Full AWS Practitioner Certification Question