- Newest
- Most votes
- Most comments
After taking the time to post this, I have come to the conclusion that this was a poor design to begin with. It would have been very difficult to maintain as each api domain grows. I am rebuilding as three separate APIs, which I think will solve all my problems now and in the future.
Your plan has some conceptual flaws in how you're trying to use API Gateway's custom domain and base path mapping features. Let me explain the issues and suggest a better approach:
-
Conceptually, your plan is flawed because base path mapping doesn't work exactly as you've envisioned. The base path is meant to route requests to different APIs or stages, not to different paths within the same API.
-
The better approach would be to create separate API Gateways for each level of exposure (Public, Private, Vendor) rather than trying to use base path mapping to route within a single API. This separation allows for better security control and management of each API independently.
-
Your understanding of base path mapping is indeed flawed. Base path mapping is used to route requests to different APIs or stages, not to different paths within the same API. When you set up a base path mapping, it essentially "removes" that part of the path before forwarding the request to the API.
Here's a revised approach that would work better:
-
Create three separate API Gateways: one for public, one for private, and one for vendor endpoints.
-
Set up custom domain names for each:
- api.example.com for public
- private-api.example.com for private
- vendor-api.example.com for vendor
-
For each custom domain, create a base path mapping that points to the corresponding API Gateway and stage. You can use '/' (root) as the path if you don't need to differentiate between multiple APIs on the same domain.
-
Structure your API routes without the 'public', 'private', or 'vendor' prefixes, as these will be implicit based on the domain used.
This approach allows you to manage security and access control separately for each API, which is more in line with best practices for API management in AWS. It also resolves the 403 Forbidden error you're experiencing, which is likely due to the mismatch between your base path mapping and the actual API structure.
Remember to ensure that your SSL certificates are correctly set up for each custom domain, and that your DNS settings are pointing to the correct API Gateway endpoints.
Sources
403 Forbidden Error When Accessing API Gateway via Custom Domain with Regional Endpoint | AWS re:Post
How to use custom domain name with private API gateway | AWS re:Post
Using custom domain name for CloudFront Distribution with an HTTP API | AWS re:Post
Relevant content
- asked 7 years ago
- asked 2 years ago
