Soru

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

A company is modernizing a legacy, highly secure internal customer service API and migrating it to a serverless architecture on AWS. The system must meet the following requirements:

* The API must be accessible only from the company's on-premises network (connected via AWS Direct Connect) and specific consumer VPCs in other AWS accounts; it must never be exposed to the public internet.
* The backend logic runs in AWS Lambda, which needs to retrieve data from an Amazon RDS PostgreSQL database located in a private subnet. The database has strict connection limits.
* The architecture must be highly available across multiple Availability Zones, and outbound internet traffic from the Lambda functions (for third-party API verification) must be resilient to Availability Zone failures.
* Updating the Lambda functions must support canary releases with automated rollback based on synthetic test failures.
* High-volume traffic bursts must not allow the database-querying function to exhaust the regional execution pool of the AWS account, which hosts other critical business workloads.

Which combination of actions should the solutions architect take to meet these requirements? (Select THREE.)

  1. Create a private Amazon API Gateway API with interface VPC endpoints. Apply an API Gateway resource policy that restricts access to the VPC endpoints of the consumer VPCs and the corporate Direct Connect gateway.Cevap
  2. Deploy the Lambda functions within private subnets across multiple Availability Zones, and configure route tables to route outbound internet traffic through a dedicated NAT Gateway in each Availability Zone. Deploy an Amazon RDS Proxy in the same private subnets to manage database connection pooling.Cevap
  3. Configure a reserved concurrency limit on the database-querying Lambda function. Use AWS CodeDeploy to manage deployments using a canary release configuration, and set up CloudWatch alarms on function errors to trigger automated rollbacks.Cevap
  4. D
    Route all outbound Lambda traffic through a single NAT Gateway located in a central egress VPC to minimize NAT charges. Set provisioned concurrency on all Lambda functions to pre-warm execution environments and mitigate cold starts during traffic spikes.
  5. E
    Deploy a public API Gateway endpoint and authenticate incoming requests using a custom Lambda Authorizer. Encrypt data payloads using the AWS-managed KMS key for Lambda (aws/lambda) and configure CodeDeploy to perform linear updates with manual rollbacks.
  6. F
    Allow the database-querying Lambda functions to run with default unreserved concurrency to maximize scaling throughput under burst conditions. Set up an Auto Scaling group of EC2 instances running HAProxy to handle database connection pooling instead of serverless proxies.

Cevap

The correct combination of actions consists of: creating a private API Gateway with interface VPC endpoints and an appropriate resource policy to restrict access; deploying the Lambda functions across multiple Availability Zones in private subnets with dedicated NAT Gateways and utilizing Amazon RDS Proxy; and setting a reserved concurrency limit on the function while managing canary deployments and rollbacks with AWS CodeDeploy and CloudWatch Alarms.
The correct solution addresses private network routing, backend high availability, database connection safety, and controlled serverless deployments. Private API Gateway with interface endpoints and resource policies limits access strictly to the corporate Direct Connect and target consumer VPCs. Placing Lambda in private subnets with a dedicated NAT Gateway per Availability Zone guarantees redundant outbound internet paths. Amazon RDS Proxy resolves PostgreSQL database connection limit issues. Defining reserved concurrency on the Lambda function guarantees that burst traffic will not exhaust the regional concurrency limit, protecting other functions in the account. Finally, AWS CodeDeploy canary configurations coupled with CloudWatch Alarms provide automated safe deployments and rollbacks.

Adım Adım Çözüm

1
Ensure the API is kept private and secure from external networks.
Create a private API Gateway with an interface VPC endpoint (VPCE) and configure a resource policy to allow incoming calls only from the corporate Direct Connect gateway and specified consumer VPC endpoints.
This configuration prevents exposure of the endpoint to the public internet while permitting authorized cross-account and hybrid corporate network traffic.
2
Establish highly available, redundant networking for the backend Lambda functions.
Deploy the Lambda functions in private subnets spanning multiple Availability Zones and set up a NAT Gateway in each AZ for outbound traffic.
This guarantees that outbound connection paths to third-party verification APIs remain operational even if a single Availability Zone experiences an outage.
3
Configure database connection management and concurrency safety controls.
Implement Amazon RDS Proxy in the Lambda functions' VPC subnets, and configure a reserved concurrency limit on the Lambda function itself.
RDS Proxy pools database connections to protect the RDS PostgreSQL limits, while reserved concurrency protects the AWS account's regional concurrency pool from exhaustion during burst periods.
4
Set up automated deployment security mechanisms.
Configure AWS CodeDeploy to execute canary deployments and link it to CloudWatch Alarms measuring function errors.
This automates the verification of new versions and triggers automatic rollbacks if synthetic tests or errors exceed defined thresholds.

Anahtar Kavram

Designing secure, resilient, and scalable serverless APIs with private API Gateway endpoints, multi-AZ Lambda networking, connection pooling via RDS Proxy, account concurrency safeguards, and automated canary deployment verification.
Tahmini Süre:3m 0s
Bu soruyu puanla