Which solution will meet this requirement?
Store the third-party service endpoints in Lambda layers that correspond to the stage.
Store the third-party service endpoints in API Gateway stage variables that correspond to the stage.
Encode the third-party service endpoints as query parameters in the API Gateway request URL.
Store the third-party service endpoint for each environment in AWS AppConfig.
Explanations:
Storing third-party service endpoints in Lambda layers is not appropriate because layers are meant for sharing libraries and code across Lambda functions rather than for storing configuration data. Additionally, layers are not tied to deployment stages in API Gateway.
Storing the third-party service endpoints in API Gateway stage variables is the best approach. Stage variables can be defined per stage (e.g., development, UAT, production) and can be accessed by the associated Lambda functions or API configurations. This allows for easy configuration management based on the environment.
Encoding third-party service endpoints as query parameters in the API Gateway request URL is not a secure or manageable solution. This method exposes sensitive information in the URL and does not allow for easy configuration per deployment stage, making it less suitable for managing different environments.
While AWS AppConfig is useful for managing configuration data, it adds unnecessary complexity for this use case. It requires additional setup and may not be as straightforward as using API Gateway stage variables, which are specifically designed for this purpose.
From my point of view, the answer is:
Store the third-party service endpoints in API Gateway stage variables that correspond to the stage.
From what I’ve heard, the answer is:
Store the third-party service endpoints in API Gateway stage variables that correspond to the stage.