Soru

Zorluk: Çok zorModernizing Workloads with Serverless Architectures (Lambda and API Gateway)

An organization is modernizing its legacy logistics tracking application by migrating its backend logic to AWS Lambda functions fronted by Amazon API Gateway. The Lambda functions must access an Amazon RDS for PostgreSQL database located in a private subnet of a VPC, and must also invoke external carrier APIs over the internet. Additionally, the application must write encrypted daily tracking reports to an S3 bucket in a separate billing-focused AWS account managed by a compliance team.

The system regularly experiences sudden, high-volume bursts of requests. The modernization architecture must meet the following constraints:
- High Availability: Internet-bound outbound traffic from the Lambda functions must remain functional even during an Availability Zone outage.
- Security: The compliance reports in S3 must be encrypted using a key managed by the compliance account, with permission safely granted to the logistics Lambda function.
- Resource Protection: A sudden surge in tracking API requests must not exhaust the execution capacity of other critical serverless workloads running in the same regional AWS account.
- Deployment Safety: Deployments of new Lambda function versions must shift traffic progressively and rollback automatically if execution errors spike.

Which of the following architectural designs satisfies all of these requirements?

  1. A
    Deploy the Lambda functions in private subnets across multiple Availability Zones, routing outbound internet traffic via redundant NAT Gateways (one per Availability Zone). Configure Reserved Concurrency on the Lambda functions to protect the shared account concurrency pool. Use AWS CodeDeploy with a Canary configuration and CloudWatch Alarms to handle deployments and rollbacks. Configure the compliance S3 bucket to use the default AWS-managed KMS key (aws/s3) in the compliance account, and grant the Lambda function's IAM role permissions to use this key.
  2. Deploy the Lambda functions in private subnets across multiple Availability Zones, routing outbound internet traffic via redundant NAT Gateways (one per Availability Zone). Configure Reserved Concurrency on the Lambda functions to protect the shared account concurrency pool. Use AWS CodeDeploy with a Canary configuration and CloudWatch Alarms to handle deployments and rollbacks. Configure the compliance S3 bucket to use a KMS Customer Managed Key in the compliance account, and update its key policy to allow access from the Lambda function's IAM role.Cevap
  3. C
    Deploy the Lambda functions in private subnets across multiple Availability Zones, routing outbound internet traffic through a single NAT Gateway located in a single public subnet to simplify the network topology. Configure Reserved Concurrency on the Lambda functions to protect the shared account concurrency pool. Use AWS CodeDeploy with a Canary configuration and CloudWatch Alarms to handle deployments and rollbacks. Configure the compliance S3 bucket to use a KMS Customer Managed Key in the compliance account, and update its key policy to allow access from the Lambda function's IAM role.
  4. D
    Deploy the Lambda functions in private subnets across multiple Availability Zones, routing outbound internet traffic via redundant NAT Gateways (one per Availability Zone). Rely on the regional unreserved concurrency pool to allow the Lambda functions to scale dynamically during spikes. Use AWS CodeDeploy with a Canary configuration and CloudWatch Alarms to handle deployments and rollbacks. Configure the compliance S3 bucket to use a KMS Customer Managed Key in the compliance account, and update its key policy to allow access from the Lambda function's IAM role.

Cevap

Deploy the Lambda functions in private subnets across multiple Availability Zones with redundant NAT Gateways, configure Reserved Concurrency, use CodeDeploy Canary shifting with CloudWatch Alarms, and encrypt S3 uploads with a cross-account KMS Customer Managed Key.
The correct solution addresses all architecture requirements: 1) deploying redundant NAT Gateways across Availability Zones prevents a single AZ outage from interrupting outbound internet connectivity; 2) specifying Reserved Concurrency prevents concurrency exhaustion for other applications in the same account; 3) configuring AWS CodeDeploy with a Canary configuration allows automated progressive shifting and metric-based rollback; 4) a Customer Managed Key in the compliance account can be explicitly shared with the Lambda role via key policy, which is impossible with AWS-managed keys.

Adım Adım Çözüm

1
Configure networking and NAT Gateways for multi-AZ high availability.
Deploying the Lambda function across private subnets in multiple Availability Zones and routing internet-bound traffic through redundant NAT Gateways (one per Availability Zone) ensures that an outage in a single Availability Zone does not impact outbound traffic.
Outbound internet access is required to connect to external carrier APIs, and redundant NAT Gateways prevent single points of failure.
2
Configure Lambda Reserved Concurrency.
Reserved Concurrency limits the maximum concurrent executions of the tracking function and guarantees that execution capacity is set aside for it.
This prevents a sudden, high-volume spike from consuming the entire regional unreserved concurrency limit, protecting other serverless workloads in the account from throttling.
3
Establish progressive traffic shifting and rollback mechanism.
CodeDeploy handles progressive traffic shifting (Canary) between Lambda versions, monitoring CloudWatch Alarms for errors to trigger an automatic rollback.
This meets the deployment safety constraint to shift traffic gradually and roll back on failures automatically.
4
Configure cross-account KMS Customer Managed Key.
The compliance account creates a Customer Managed Key (CMK) and updates its key policy to allow the tracking Lambda's execution role to perform encryption operations. The Lambda function uses this CMK when uploading to S3.
AWS-managed KMS keys (like aws/s3) cannot be shared across accounts because their key policies cannot be customized. Only Customer Managed Keys support cross-account sharing.

Anahtar Kavram

Designing highly available, secure, and isolated serverless architectures involving cross-account resource access, redundant VPC networking, and concurrency controls.
Tahmini Süre:3m 0s
Bu soruyu puanla