Improving Rest API Performance Using Cloudfront


Recently we started working with a healthcare company that was facing slow API response time causing a bad user experience. The customer is a US-based Healthcare company solving the lack of healthcare interoperability with its patient-centered mobile platform, from where patients can engage, communicate and participate in their healthcare across various providers that might be using different PM/EHR/EMR products.

The product includes a SaaS platform for healthcare providers to share and communicate patient health information along with its cutting-edge point-of-service patient check-in app for waiting rooms.

Due to the complex nature of the product, one of the requirements of the product team was to solve this issue without changing a lot of existing code. The client had already evaluated a couple of paid tools that were working great but very costly, so another challenge was to find an open-source tool that can serve the purpose. Hence, we had a two-pronged challenge- Improve performance and reduce cost.

We started doing some research and found tools like Solr which seemed like a good fit for us initially, but while we were almost close to setting it up, we thought to get some detailed insights from API response times which opened up new revelations for us making Solr insignificant. Some of the stats from different APIs were like this –

Before Cloudfront:

PCP 2192 ms 662 ms 30%
Allergy 3758 ms 475 ms 12%

So after looking at low level timings, it was found that database call was not that a bigger culprit, there were some calculations happening on backend which were causing the major delays along with SSL handshake and a few other things. So we started rethinking about a new approach to solve this problem.

Few months back I had seen Slack case study on AWS and how they improved their API performance using Cloudfront. This triggered me to go back and check AWS documentation for the same. I started playing around with Cloudfront for custom origins. Till now, we had used CloudFront alongside S3 for static website hosting which had worked well. After configuring cloudfront for one API we were able to achieve almost 233% improvements in API response time without changing single line of code on backend. Below figure depicts the results after using Cloudfront.

PCP 2192 ms 14 ms 197%
Allergy 3758 ms 16 ms 233%

We Helped Our Client To Convert The Old Application Into A New Stack

So far all good, but how to configure Cloudfront to achieve such results? Below are the steps which can help anyone to configure Cloudfront with existing APIs.

Create Cloudfront Distribution:

  1. In the CloudFront console, choose to Create Distribution.
  2. On the first page of the Create Distribution Wizard, in the Web section, choose to Get Started.
  3. For Origin Domain Name, enter your API URL, which is nothing but your current API URL(or base url e.g
  4. In Origin Path, keep as it is.
  5. For Origin Protocol Policy, choose HTTPS Only.
    Note: API Gateway does not support unencrypted (HTTP) endpoints. For more information, see Amazon API Gateway FAQs.
  6. To forward custom headers to your origin, enter one or more custom headers for Origin Custom Headers.
    Note: There are several custom headers that CloudFront can’t forward to your origin.
  7. Choose to Create Distribution.
  8. Wait for your distribution to deploy. This might take about 30 minutes. When its Status appears as Deployed in the console, the distribution is ready.

Configure Caching Using Behaviours:

Assuming Cloudfront is deployed, it’s time to configure behaviors for caching. I am using the above example to configure two APIs /search/pcp and /search/allergy to cache the content based on our needs. Here are the steps for same –

  1. Click on CF distribution
  2. Go to Behaviour Tab and click on Create Behaviour
  3. Enter path pattern – in my case of pcp API it was /search/pcp
  4. I will skip other settings which are self-explanatory, lets move to the main settings, select customize from Object Caching section, enter minimum TTL as 0, maximum and default value 31536000(this is max)
  5. Under Query string forwarding and caching select the option Forward all, cache based on whitelist, in text box enter all your query parameters which you want to be cached(meaning when these changes backend API response changes), in my case, it was Keyword, Limit, Page, PracticeId and Zipcode, enter one in each line
  6. Save the behavior

Once the distribution is ready, you can copy the Cloudfront URL and hit the API. Note down the response time. Now hit the same API again and compare the response time. You will see a big difference in the response time which means caching is working. Follow the above steps for adding multiple behaviors.


  • Handling Selecting Caching

While implementing one of the challenges was that we needed to cache the response only when certain request parameter value is available. In our case, our backend was sometimes hitting our own database or hitting third party depending on request parameter value. Whenever we are hitting third-party API we don’t want to cache the result. We have handled this using max-age=1 parameter in API response, so whenever Cloudfront finds max-age=1 it caches for 1 second and overrides default settings. Now backend has control on what to cache and when.

  • Automating Cache Updates

One of the requirements was to update the cache whenever the backend database is updated, so we wrote the AWS Lambda function to invalidate specific cache entries using Cloudfront invalidate API. We exposed this lambda function using AWS API gateway so that our backend can call the API and invalidate the specific cache entries based on which DB values are updated. I will cover this in our upcoming blogs.



The new architecture turned the response time down to less than half of the original resulting in faster responses which in turn made the end-user delighted. All this was done without having to change any aspects of the core application or any downtime for the application.

In the end, the customer was happy to see savings for a time as well as cost.

Pravin Uttarwar

CTO, Mindbowser

Pravin has 16+ years of experience in the tech industry. A high energy individual who loves to use out of the box thinking to solve problems. He not only brings technical expertise to the table but also wears an entrepreneurial hat – benefiting any project with cost savings and adding more value to business strategy. Pravin is also chapter director of StartupGrind Pune, hosting events and startup conferences.

The founder's survey report on "What Matters For Startup" is released - Get your copy and learn the trends of successful companies :)

Download Free eBook Now!

Get in touch for a detailed discussion.

Hear From Our 100+ Customers

Mindbowser helped us build an awesome iOS app to bring balance to people's lives.

Addie Wootten
CEO, Smiling Mind

We had very close go live timeline and MindBowser team got us live a month before.

Shaz Khan
CEO, BuyNow WorldWide

They were a very responsive team! Extremely easy to communicate and work with!

Kristen M.
Founder & CEO, TotTech

We’ve had very little-to-no hiccups at all—it’s been a really pleasurable experience.

Chacko Thomas
Co-Founder, TEAM8s

Mindbowser is one of the reasons that our app is successful. These guys have been a great team.

Dave Dubier
Founder & CEO, MangoMirror