AWS环境下NLB基于每目标请求数动态扩缩容实现及ALB的mTLS证书传递方案咨询

1. Can I create a custom metric to scale EC2 instances based on requests per server? #

Absolutely! Since Network Load Balancers (NLB) don’t natively expose the Request Count Per Target metric that ALBs provide, you have two reliable ways to build this custom metric for auto scaling:

Option 1: Use CloudWatch Agent on EC2 Instances #

• Install and configure the CloudWatch Agent on every EC2 instance in your Auto Scaling group. You can set it up to collect request counts directly from your application:
  • If your app has a metrics endpoint (like /metrics for Prometheus-compatible services), configure the agent to scrape this endpoint and send request count data to CloudWatch.
  • Alternatively, parse your app’s access logs (e.g., Nginx/Apache logs) to count requests per instance, then have the agent send this aggregated number as a custom metric.
• Create a CloudWatch Alarm tied to this custom metric (e.g., scale out if average requests per instance exceed 1000 over 5 minutes, scale in if it drops below 200).
• Link the alarm to your Auto Scaling Group via a scaling policy (target tracking or step scaling) to automatically add/remove instances.

Option 2: Parse NLB Access Logs with Lambda #

• Enable NLB access logs to be stored in an S3 bucket. These logs include details like the target instance ID/IP that handled each request.
• Build an AWS Lambda function that runs on a schedule (e.g., every minute) to fetch new logs from S3, parse them, and calculate requests per target instance.
• Have the Lambda function publish these counts as a custom CloudWatch metric (e.g., NLBRequestCountPerTarget with dimensions for instance ID or Auto Scaling group).
• Set up CloudWatch Alarms and Auto Scaling policies using this custom metric, just like in Option 1.

Note: Whichever method you pick, use 1-minute metric granularity to avoid scaling delays, and double-check IAM permissions for the agent/Lambda to write to CloudWatch.

2. Can I keep using ALB and pass mTLS client certificates to backend instances? #

Yes! ALB fully supports mTLS authentication and can pass client certificate details to your backend servers. Here’s the step-by-step setup:

Step 1: Import Your Client CA Certificate into ACM #

• Upload the root/intermediate CA certificates you trust for client authentication to AWS Certificate Manager (ACM). This tells the ALB which client certificates are valid.

Step 2: Configure mTLS on Your ALB HTTPS Listener #

• Go to your ALB’s HTTPS listener settings and enable Mutual TLS authentication.
• Select your imported CA certificate(s) as the trust store. The ALB will now validate that incoming client certificates are signed by one of these trusted CAs.

Step 3: Configure the ALB to Pass Client Certificate Details to Backend #

• In your ALB listener’s forwarding rules, ensure the X-Forwarded-Client-Cert HTTP header is included in requests sent to the backend. This header contains:
  • The full PEM-encoded client certificate
  • Certificate fingerprint, serial number, and other metadata
• You can also enable additional headers like X-Forwarded-Cert-Chain if you need the full certificate chain.

Step 4: Update Your Backend Server to Use the Certificate #

• Modify your application code to read the X-Forwarded-Client-Cert header, extract the client certificate, and run any extra authentication checks (e.g., verifying validity, checking a revocation list).

Important Notes:

• ALB will reject requests with untrusted client certificates before they reach your backend, so you only need to handle additional checks at the server level if required.
• mTLS is supported on ALB HTTPS listeners in all AWS Regions where ALBs are available.

内容的提问来源于stack exchange，提问作者S A R