I’m working on an AWS setup with multiple environments: master (production) and qa.

Recently, our Flutter app was getting 500 errors when calling the master API Gateway endpoints that are integrated with master Lambda functions. As a quick workaround, I:

  • Pointed the master API Gateway routes to the QA Lambda functions instead.
  • Verified that the QA Lambdas are working and returning 200 responses.
  • Confirmed that, in the repo, the auth Lambda code for master and qa is currently identical (same handler code, just different stacks/environments).

However, the QA Lambda functions are configured to talk to QA DynamoDB tables, not the master/production DynamoDB tables. We’re planning to update the configuration so they point to the correct production resources.

My questions are:

  1. Is it considered bad practice to route a production (master) API Gateway endpoint to QA Lambda functions, even if the code is identical?
  2. What are the potential security issues with using QA Lambda functions for production traffic?
  • For example, IAM roles/permissions, environment variables, logging, or data exposure concerns.
  1. Are there any specific vulnerabilities or risks I should be aware of when:
    • Production users hit a QA Lambda (even temporarily)?
    • QA Lambdas are wired to different resources (e.g., QA DynamoDB) than expected in production?
  2. From an architecture/best practices perspective, is there a recommended way to handle this scenario? For example:
    • Using separate Lambda aliases/versions per environment
    • Using separate stacks with shared code but different configuration
    • Using feature flags vs. pointing prod directly to QA resources

I’m mostly concerned about any hidden security or reliability risks this workaround might introduce, even if it "works" in the short term.

Environment:

  • AWS API Gateway (REST)
  • AWS Lambda (Python 3.8+)
  • AWS DynamoDB
  • Flutter frontend