laspsandoval
commented
1 year ago Solution 1 : domain.com/api
Pros:
- Easier SSL management: A single SSL certificate can cover the entire domain, simplifying the process of obtaining, installing, and renewing SSL certificates.
- Simpler DNS management: Requires only a single DNS record for the main domain, which makes it easier to manage and maintain.
- Centralized logging: All APIs under the same domain can share the same logging system, simplifying log aggregation and analysis.
Cons:
- Less flexible: If you want to add more APIs later, organizing them under the same domain can become messy, especially if they have different requirements or need to be isolated from one another.
- Limited isolation: Since all APIs live under the same domain, it's harder to manage security settings and configurations for individual APIs.
- Versioning complexity: Implementing and managing API versioning can be more challenging with the route after the domain approach, as all versions live under the same domain.
Solution 2 : api.domain.com
Pros:
- Better organization: Subdomains provide a clear separation of concerns, making it easier to manage and organize your APIs, especially if you have multiple APIs or a microservices architecture.
- Enhanced isolation: Each API has its own separate subdomain, allowing for better isolation of security settings, configurations, and management of individual APIs.
- Independent scalability: Subdomains enable you to scale each API independently, which can be beneficial for performance and resource allocation.
- Flexible versioning: Managing API versions is easier with subdomains, as each version can have its own subdomain or path, reducing the chances of conflicts and simplifying deprecation.
Cons:
- More complex SSL management: SSL certificates are used to secure the communication between a client (like a web browser) and a server. When you have multiple subdomains (e.g., api1.domain.com, api2.domain.com), you need an SSL certificate for each one. This can lead to increased management overhead, as you need to obtain, install, and renew SSL certificates for each subdomain. However, we can mitigate this by using a wildcard SSL certificate, which covers all subdomains under a single domain (e.g., *.domain.com).
- More complex DNS management: DNS (Domain Name System) is a system used to translate human-readable domain names (e.g., example.com) into IP addresses that computers can understand. DNS management involves configuring and maintaining DNS records, which are essentially mappings between domain names and IP addresses or other resources. When you use subdomains, you need to create and manage separate DNS records for each one (e.g., api1.domain.com, api2.domain.com), which can increase the complexity of your DNS management tasks.
- Distributed logging: Logs for each API are stored separately, making it harder to aggregate and analyze log data across all APIs.
Additional Information
Requirements:
- The choice between domain.com/api and api.domain.com does not depend on the AWS service being used (Lambda Functions, API Gateway, EC2, etc.). Instead, the decision is based on factors such as organization, scalability, ease of management, and security.
- Integration with Amazon Cognito is independent of the domain style we choose.
Notes:
- API Gateway is a fully managed service that allows you to create, publish, maintain, and secure APIs. It acts as a "front door" for your API, handling the incoming requests and routing them to the appropriate backend service
- Amazon Route 53 is a scalable and highly available Domain Name System (DNS) web service provided by Amazon Web Services (AWS). It is designed to provide a reliable and cost-effective way for developers and businesses to route end users to Internet applications by translating human-readable domain names (like www.example.com)(http://www.example.com/)) into the numeric IP addresses (like 192.0.2.1) that computers use to connect to each other.
- In general, the difference in complexity between the two methods should not be significant when using the AWS CDK. Both methods involve creating and configuring resources like Amazon Route 53 records and API Gateway, and the CDK makes it relatively simple to define and manage these resources.
Summary
After evaluating the pros and cons, as well as considering our concerns related to security groups, we have decided to opt for the ANAME/subdomain method (api.domain.com) for organizing our APIs. This approach provides several benefits: better organization, enhanced isolation, independent scalability, and flexible versioning.
By choosing the api.domain.com method, we are selecting a more scalable and flexible solution that addresses our security concerns and better aligns with the needs of a growing API ecosystem. While this approach may introduce slightly more complex SSL and DNS management, we can mitigate these drawbacks by using a wildcard SSL certificate and proper DNS management practices.
greglucas
bryan-harter
bmcclellan-cu
Description
We are going to want our APIs to live at some easy to remember url (
domain.com/apiorapi.domain.com). We need to investigate how we want to set this up within AWS's architecture.Requirements
domain.com/apivsapi.domain.comNice to have or Goal Requirements
Additional notes
A few other things to consider: Do we know how many endpoints we want? Do we want everything living at the URL, or do we want multiple urls (api1, api2, ...).
Related tickets
43
65
Follow up tickets
This spike is not considered complete until at least one follow up issue is created.
Below is the template for the response to this ticket. Add as many solutions as needed, but preferably include 2-5 for discussion. The response should be posted as a comment on this issue, or linked in a comment.
Solution 1
Write an overview of the solution here.
Pros:
Cons:
Additional notes:
Solution 2
Write an overview of the solution here.
Pros:
Cons:
Additional notes:
Summary
Write up a summary of your findings, including your preferred solution.