KMS-645: Enable API Gateway response caching and access logging for KMS read endpoints, with cache settings controlled via environment variables.

[cgokey]

Overview

What is the feature?

Enable API Gateway response caching and access logging for KMS read endpoints, with cache settings controlled via environment variables.

What is the Solution?

Solution?
    •    Add API Gateway stage cache configuration (TTL, cluster size, enabled flag) and apply caching method options for selected GET routes.
    •    Add API Gateway access logs to a dedicated CloudWatch Log Group (disabled when running against LocalStack).
    •    Introduce helper utilities to centralize cache method options and to patch method/integration settings for cache keys/query params.
    •    Wire new env vars into the CDK app defaults.

What areas of the application does this impact?

 •    CDK infrastructure: KmsStack.ts
    •    API Gateway stage configuration (cache + logs)
    •    Read endpoints under /concepts (GET routes listed in ApiCacheSetup.cacheMethodOptions)
    •    Deployment configuration via new env vars in main.ts

Testing

Accessing API Gateway Logs:

1. Navigate to the AWS API Gateway console.
2. Locate your API in the list of available APIs.
3. In the left navigation panel, look for a section related to monitoring or logs.
4. Find an option for "Access Logs" or "Log/Tracing".
5. You should see a link or URL provided for accessing the logs.
6. Click on this link to view detailed access logs for your API.

To verify that caching is working correctly:

1. Monitor CloudWatch logs for the /concepts endpoint.

2. Test caching behavior:
   a. Make an initial request to /concepts.
   b. Repeat the same request within 1 hour.
   c. Check CloudWatch logs to confirm the Lambda function is not invoked on the second request.

3. Verify cache configuration:

   • Responses should be cached for 1 hour (this duration is configurable).
   • Both path and query parameters contribute to unique cache keys.

4. Test with variations:

   • Try different query parameters to ensure they result in separate cache entries.
   • Confirm that identical requests (including query parameters) hit the cache.

5. After 1 hour, verify that the cache expires and a new Lambda invocation occurs.

Remember: The absence of a Lambda invocation log for repeated requests within the cache period indicates successful caching.

Attachments

Please include relevant screenshots or files that would be helpful in reviewing and verifying this change.

Checklist

• I have added automated tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.59%. Comparing base (8dfe8d0) to head (8030e79).

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #91   +/-   ##
=======================================
  Coverage   99.59%   99.59%           
=======================================
  Files         143      143           
  Lines        2478     2478           
  Branches      608      608           
=======================================
  Hits         2468     2468           
  Misses          9        9           
  Partials        1        1           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.