API Security, scalability design best practices

Question

Hi Everyone,

We have developed a set of APIs to centrally manage all our internal secrets. The current architecture looks like this:

Account A (API Layer)
	1.	API Gateway (PUT/GET/POST/DELETE) → API Lambda Handler → DynamoDB
	•	Stores metadata such as secret owner, last password reset date, reminder settings, etc.
	2.	API Lambda Handler (Update/ADD/DELETE/Search secret) → Cross-account permissions to a dedicated Account B, where secrets are stored in AWS Secrets Manager.
	3.	Auto-rotation is enabled on each secret in Account B. When rotation is triggered, it sends an SQS message back to Account A → Step Function.
	4.	The Step Function rotates the secret and updates it in Secrets Manager (Account B).

Security setup:
	1.	IAM Authorization: Only designated Organization IDs are allowed to invoke the API (enforced in the API Gateway resource policy).
	2.	API Keys: Mandatory in headers, required per team based on usage.
	3.	Owner Name Header: Also mandatory. The owner name is validated against the secret’s tags before allowing access.
	4.	TLS/SSL: AWS-managed certificates bound to our DNS name.

Scale:
	•	We have 500+ AWS accounts, 200+ Azure subscriptions, and 100+ GCP projects that need to invoke these APIs.
	•	For non-AWS environments, we are using OIDC for authorization.
	•	Resources such as Lambda, EC2, or containers across all these accounts should be able to securely call the APIs.

Challenge:
	•	Currently, API Gateway resource policies are restricted by Organization ID, since we cannot manage 500+ individual AWS accounts or IAM roles in the resource policy.
	•	While this works, we feel this may not be the most secure or scalable approach for building a long-term API framework.

We’re looking for suggestions or recommendations on how to improve this design to make it more secure and scalable across multi-cloud and multi-account environments.

Thanks in advance for your input!

re:Post Agent · Answer

Based on your current architecture for managing internal secrets across multiple cloud environments, I can offer several recommendations to enhance security and scalability.

For security improvements:

1. Implement least privilege access using IAM policies to control who can create, read, update, or delete APIs and secrets. Your current approach of using Organization IDs in resource policies is broad - consider implementing more granular controls.

2. Enhance your logging strategy by implementing CloudWatch Logs or Amazon Data Firehose to log all requests to your APIs. This will help with auditing and troubleshooting.

3. Set up CloudWatch alarms to monitor API metrics and receive notifications when thresholds are exceeded, which can help detect unusual activity.

4. Enable AWS CloudTrail to record API actions, capturing details like IP addresses and user information for comprehensive audit trails.

5. Consider using AWS Config to monitor your API Gateway resource configurations and evaluate compliance.

6. Leverage AWS Security Hub to monitor API usage and compliance with security best practices.

For secrets management:

1. Use client-side caching components when retrieving secrets to improve performance and reduce costs associated with frequent API calls to Secrets Manager.

2. Implement regular secret rotation schedules beyond your current auto-rotation setup to minimize risk.

3. Use tools like CodeGuru Reviewer or Amazon Q to scan your codebase for any unprotected secrets.

For scalability across multi-cloud environments:

1. Consider implementing a more sophisticated authentication mechanism that can work across your AWS, Azure, and GCP environments. Your current OIDC approach for non-AWS environments is good, but you might benefit from a more unified strategy.

2. For your API Gateway, instead of broad Organization ID restrictions, consider implementing a token-based authentication system that can work across all your environments while maintaining fine-grained access control.

3. Replicate critical secrets across multiple regions for improved resilience and disaster recovery.

4. Run your infrastructure on private networks where possible to add an additional layer of security.

These recommendations should help make your secrets management architecture more secure and scalable across your multi-cloud environment while maintaining the centralized approach you've established.  
**Sources**  
[Security best practices in Amazon API Gateway - Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/security-best-practices.html)  
[API Management - API Tools, Services, and Best Practices](https://aws.amazon.com/api-gateway/api-management/)  
[AWS Secrets Manager best practices - AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html)  
[SEC02-BP03 Store and use secrets securely - AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/2025-02-25/framework/sec_identities_secrets.html)

API Security, scalability design best practices

Add your answer

Relevant content