amazon-web-servicesamazon-auroraaws-opsworksaws-aurora-serverlessaws-billing

AWS: Start-up launch servers (Node.js + Postgres)


We're getting ready to launch our iOS app and our backend is on Node.js and Postgres database.

We plan to use Aurora Postgresql for storage (text only, no pictures).

Currently, we have an EC2 development server t2.small that I reserved for 36 months (All upfront) and it works great. This server doubles as a Node.js + Postgres on Ubuntu.

We would like to go into production in North America (U.S. and Canada) only. We have 0 users right now. We'd be lucky if we can get 10 users in the next 30-90 days. Each user may use the app for 5-10min a couple of times a week.

Question: I am not sure what size servers I should go with. I would like to save money and happy to pay All Upfront; however, I am not sure:

  1. What size and how many servers I should use for Node.js when reserving?
  2. What size and how many servers I should use to reserve for Aurora Postgres. Should we go Serverless?
  3. How often should I backup my DB and what's a good practice to save money here.
  4. What regions should I choose?

Solution

    1. You can start with t2.small and then scale up the instance if it is bogging down
    2. Since you currently have no users, and only expect the 10 future users to be on for a few minutes a couple times per week, I would recommend going with serverless (you have to select Postgres 10.7), setting it to pause after (at least) 5 minutes of inactivity, if your use case can tolerate a 30-second(ish) cold-start delay when the user first attempts to access the database. You can pre-warm the database by sending it an empty query ";" as soon as the user logs in to the app, which could make the cold-start invisible from the user's point of view. If your use-case can't tolerate a cold start, you can have it scale down to 1 ACU when inactive rather than pausing.
    3. Aurora serverless does daily backups automatically, for the duration between 1 and 35 days that suits your risk tolerance.
    4. Consider us-east-2 for a (mostly) central location if your users are all over the US and Canada.