Skip to content

API Gateway v1: Getting 403 Forbidden when using custom domain with basepath routing

0

This may be an architectural design flaw, based in misunderstanding of how basepath mapping works.

Goal: To have multiple API endpoints with 3 levels of exposure: Public, Private, Vendor. Each of these will have different authentication needs.

My plan was to house them all in the same API Gateway, and categorize them based on the path structure, e.g.:

  • /public/orders/
  • /private/users/
  • /vendor/contacts/ etc...

Then, according to my plan, I would create 3 subdomains:

  • api.example.com
  • private-api.example.com
  • vendor-api.example.com

Along with this, I would have 3 basepath mappings:

DomainAPIStagePath
api.example.commy-api-nameprodpublic
private-api.example.commy-api-nameprodprivate
vendor-api.example.commy-api-nameprodvendor

With the ultimate goal being this:

This setup is not working as planned. I get a 403 Forbidden response when trying to hit any of these urls. My configuration and what I am experiencing sounds very similar to this post.

If anyone is interested in more details on my configuration, I would be happy to share them. The questions I have for now are:

  1. Conceptually, is this plan flawed?
  2. If so, why? What would be a better approach?
  3. Is this a flawed understanding of basepath mapping?
2 Answers
0
Accepted Answer

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.

answered 10 months ago
EXPERT
reviewed 10 months ago
0

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:

  1. 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.

  2. 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.

  3. 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:

  1. Create three separate API Gateways: one for public, one for private, and one for vendor endpoints.

  2. Set up custom domain names for each:

    • api.example.com for public
    • private-api.example.com for private
    • vendor-api.example.com for vendor
  3. 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.

  4. 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

answered 10 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.