Background:
A travel company has a set of APIs they expose to other companies.
Information about open reservations and trip schedules can be stored and fetched easily by their B2B customers. The current solution is deployed as a 3 tier web app behind an Application Load Balancer with CloudFront “on top”.
Although this solution has served them well, the variable load on the service is such that significant cost savings could be achieved by moving to a Serverless stack.
Better performance and lower operational overhead are also of interest.
A team was put together to design the new generation API and will be using AWS API Gateway (Edge optimized) with Lambda. The main database will remain DynamoDB as with the current solution.
A variety of HTTP clients across the world rely on the existing API that is exposed via a default Amazon CloudFront DNS name (xxxxxxxxxxxxxx.cloudfront.net).
Many clients don’t have an easy way to update the DNS endpoint. A change will require careful planning and coordination.
A decision was made to move forward and to migrate some of the more “problematic” API’s (As in those that have a spiky traffic pattern and for which the new stack will provide the biggest advantage) in a seamless way.
Later more functionality will be moved to the new solution, until all the functionality is available from a new DNS name resolving to a new API Gateway endpoint.
At that stage, the HTTP clients will be updated to use the new endpoint exclusively and the old environment will be decommissioned (After a grace period).
One low hanging fruit identified is the following API:
https://xxxxxxxxxxxxxx.cloudfront.net/reservations
More specifically the HTTP GET method associated with the above path/resource, which is by far the most common request.
Bounty:
- Points: 30
- Path: Cloud Engineer
Difficulty:
- Level: 3
- Estimated time: 1-12 hours
Deliverables:
- A live CloudFront deployment with a redirect feature (implemented with CloudFront only or with a custom Origin)
Prototype description:
The team has agreed that a good solution at this time would be to set up an HTTP redirect (301 response code) for the GET method on the resource/path mentioned earlier (https://xxxxxxxxxxxxxx.cloudfront.net/reservations).
The existing 3-tier web application stack behind the ALB can’t be updated or changed.
The redirect needs to be implemented before the request reaches the web/application servers themselves.
A prototype should be created with Amazon CloudFront to simulate the existing environment that will demonstrate this capability. When a specific path is accessed with a GET request, the HTTP client should be redirected to a new domain name as described in the requirements below.
Solutions that will minimize the latency added by the redirect are preferred (A redirect as close as possible to the HTTP client).
Requirements:
-
The prototype shall be deployed using the AWS CloudFront service.
The URL provided for the redirection test must have the following structure:https://[distribution-id].cloudfront.net
-
A GET request to the following path:
https://[distribution-id].cloudfront.net/reservations
Shall result in a HTTP 301 Redirect response to the following location:
https://ooggi.com/the_blog/
-
A GET request to a different path shall not result in a HTTP 301 Redirect response. For example:
https://[distribution-id].cloudfront.net/
https://[distribution-id].cloudfront.net/cases
- Any other HTTP method (POST, DELETE, etc) to any path shall not result in a HTTP 301 Redirect response.
- The prototype shall be deployed with a valid HTTPS certificate and accessible with HTTPS.
- The prototype can be deployed as a public API. There’s no need to implement authentication/authorization on Amazon CloudFront.
Your mission, if you choose to accept it,
is to create a prototype with Amazon CloudFront based on the requirements and share the URL with the customer.
