Cost for My Serverless Pageviews Counter with AWS Lambda and Google Analytics

A closer look at serverless framework costs breakdown for Pageviews Counter.

Read Now

Donnie Prakoso
Developer, self-proclaimed barista and cafe racer enthusiast. This blog is a collection of my writings on technology.
Published
Saturday, August 19, 2017
Info
views
Category
article

Pageviews counter is that kind of little nice-to-have feature on every blog, to show your readers how many hits the respective article has been viewed. While its process might be quite challenging to build, but the main objective of this feature is giving your readers a confidence that it is worth to spend their time to read.

There are several methods in how to put this feature works, e.g. by building an API and increment page counter every time the article is viewed. However, whenever users refresh the page, it will auto increments the counter and this is not the desired behavior we might need since it will show your readers a false data. So, fetching data from Google Analytics (GA) is considered as the most suitable solution in this case.

Google has a nice write up how to use GA reporting API (currently v4), here. You might want to take a look at it as a start.

Sequence Diagram

In a nutshell, how I build pageviews counter for this blog, could be described like this:

sequenceDiagram User->>Donnie.id: View an article Donnie.id->>GA: Send pageviews Donnie.id->>+AWS API Gateway: Request for pageviews counter AWS API Gateway->>+AWS Lambda: Invoke method AWS Lambda->>+GA: Query GA-->>-AWS Lambda: Return data AWS Lambda-->>-AWS API Gateway: Return data AWS API Gateway-->>-Donnie.id: Return data Donnie.id-->>User: Render pageviews and show
Seq1. Request process overview.

This is quite a simple and straightforward microservice architecture, so I don’t think that I should elaborate more. The only difference is it is based on AWS serverless framework, which includes AWS API Gateway and AWS Lambda.

Since its launch, I’ve been closely monitoring its performance. By relying on AWS, it relieves me from the scalability and maintenance matters. Furthermore, I delegated these duties to AWS, so I could focus more on development. However, since I’ve managed the scalability, it is time for me to take a closer look at operational cost.

AWS API Gateway

As service that acts as a door for every request, AWS API Gateway will process both failed or success requests after processing. AWS has a free tier that gives users free 1,000,000 API calls per month. Note that this offer would expire after 1 year period from the sign-up date. Unfortunately, I’m way over that. Pppfftt. So, let’s dive into how AWS API Gateway pricing works.

API Gateway pricing model consists of 3 things, API Calls, Data Transfer Costs, and Caching, although the latter is optional. I’m going to use AWS Singapore region (ap-southeast-1), as a base for pricing breakdown.

API Calls pricing, for Singapore region, is $4.25 per million API calls. As for the data transfer rates starts from $0.12/Gb for the first 10TB. I think that’s quite huge for my case, so I’m going to use it as the cap.

Let’s say that I am expecting no more than 100,000 page views per month for my viewed articles. That could be said that all requests to API Gateway would be 100,000. Size per requests could be varied, but let’s just say that I have a medium sized data to be transferred in and out, around 10Kb. So, the pricing would go this way:

API Calls = ($4.25/1,000,000) * 100,000 = $0.425
Data Transfer Costs = (10Kb*100,000) * (0.12/1024) = $0.11
Total API Gateway Costs = $0.535

Not bad at all for 100,000 pageviews.

Let’s move on to the next pricing, AWS Lambda.

AWS Lambda

Lambda’s pricing model is somehow more generous that API Gateway. AWS gives free for first 1,000,000 requests. AWS Lambda pricing model consists of 2 things, the number of requests, and duration. AWS Lambda pricing could be a bit confusing at first because pricing for duration includes 2 factors, allocated memory and number of requests.

I’m allocating 128MB memory and from my benchmark, the average duration of call requests to Google Analytics API is around 4s. Here we go for computing charges:

Free 400,000 GB-s compute time per month
Computing price $0.00001667 per GB-s
Monthly Requests = 100,000

Total compute (s) = 100,000 * 4s = 400,000s
Total compute (GB-s) = 400,000s * 128MB/1024 = 50,000GB-s
Total compute (GB-s) with free tier = 50,000GB-s - 400,000GB-s ~ 0 GB-s

Total monthly compute charges = 0GB-s * $0.00001667 = $0

So, for Lambda compute charges, I don’t have to pay at all for 100,000 requests.

As for request charges, AWS free tier which gives free for 1,000,000 requests per month is really good from my perspective. However, if the requests exceed 1,000,000 requests, it will costs you $0,20 per 1 million requests. Still, really good pricing for me.

Total requests = 100,000
Free tier 1,000,000 requests per month
Costs for next per requests after free tier = $0.0000002 per request

Monthly requests = 100,000 - 1,000,000 ~ 0
Total monthly requests charges = 0 * $0.0000002 = $0

With 100,000 requests, that means I’m still covered. Okay, case closed. I will pay $0 for AWS Lambda requests.

Okay, moving on to Google API for Analytics Reporting.

Google API Analytics

For an unknown reason, I can’t find pricing details for Google API Analytics although they have well-documented limits and quotas here. Google Analytics API has a limit for 50,000 requests/day. Otherwise, it will return error 403 and 429.

Since I expect no more than 100,000 requests/month, I don’t think this limitation will affect my pageviews counter service.

Going Serverless

So, in total, I only have to pay for AWS API Gateway, $0.535 per month. In comparison with traditional development, which requires servers for the app to be deployed (it costs $5 with Digital Ocean and AWS Lightsail), I found this approach is much more convenient for me, both in terms of scalability and financially.

I am personally having benefits from this serverless approach. Finally, I could focus on my product development, although there are few conventions/rules to follow. However, the use case and pricing might vary for far more complex systems.

My advice is, do your math when it comes to pricing so you could compare and decide which approach you would feel more confident to use.

Like this article?
Give this article a love or you can share this article with others.
Read Next
Being Evangelist at AWS

A big update! I'm starting a new journey with a new role as Technology Evangelist at AWS.

Read More
Published
Saturday, August 19, 2017
Info
views
Category
article

Donnie Prakoso
Developer, self-proclaimed barista and cafe racer enthusiast. This blog is a collection of my writings on technology.

Codes & Notes. by Donnie Prakoso
© @donnieprakoso · 2019