A CPU-bound Lambda function is configured at 256 MB and its CloudWatch REPORT lines show high billed duration with Max Memory Used staying near 90 MB. The developer needs to cut tail latency for compute-heavy invocations and also empirically find the memory value that minimises cost per invocation, doing so against the real workload with the least manual trial and error. Which TWO actions together meet these goals? (Select TWO.)
- ARaise the memory configuration so the function receives proportionally more vCPU, then confirm whether the faster billed duration offsets the higher per-millisecond price. Correct
- BRun AWS Lambda Power Tuning, a Step Functions state machine that invokes the function across a sweep of memory values and charts billed duration and cost to reveal the optimum. Correct
- CLower the memory configuration toward the observed 90 MB peak so the per-millisecond price drops, since memory usage is the only factor that drives Lambda billing.
- DEnable provisioned concurrency on the function alias so pre-initialised environments shorten the compute time of each individual CPU-bound invocation.
- EIncrease the function timeout so compute-heavy invocations have more time to complete, which reduces their billed duration and overall cost.
Why A is correct: Lambda allocates CPU in proportion to configured memory, so a CPU-bound function gains more vCPU and finishes faster when memory is raised, which can lower total cost despite a higher rate.
Why B is correct: Power Tuning automates the sweep across memory settings using the real payload and plots cost versus speed, finding the optimum with far less manual reconfiguration and re-running.
Why C is wrong: Tempting because Max Memory Used is low, but cutting memory on a CPU-bound function removes vCPU, lengthens billed duration, and billing is duration times memory, not memory alone.
Why D is wrong: Provisioned concurrency removes cold-start init latency for new environments but does nothing for the per-invocation compute time of an already-warm CPU-bound handler.
Why E is wrong: Tempting as a knob for long-running work, but timeout is only an upper bound on runtime; it never speeds execution or lowers billed duration, which is the measured run time.