AWS (as in any cloud provider) for spinning something up ondemand for a quick test. Need an Oracle database? Couple of clicks and you’re done.
With the RDS options on AWS be careful of the EC2 type if you’re trying to keep costs down. For example if you leave the DB Instance Size at ‘Standard’, you only get db.m4 and db.m5 instances which are definitely not your cheapest options:
If you select ‘Burstable’, the smallest instance size you can select is a db.t3.small:
According to the Simple Monthly Calculator, at 100% 24/7 usage for a month the cost is around $57/month:
If you’re usage for development is going to be low, and/or if you can stop the instance when you’re not using it (and only pay for storage), for example at 10% usage for a month you can get the cost down to around $8:
I’m looking for a low cost managed db in the cloud for a small project, so thought I’d take a look at setting up an Aurora Serverless db, as depending on usage (and my usage will be very low) it looks like it’s definitely the cheapest of all AWS RDS options.
From the Console, from RDS, I pressed the ‘Create Database’ button:
If you select Aurora, the Serverless option is way down the page here:
I kept all the defaults, but changes the capacity to the smallest options:
After taking note of generated credentials and pressing the last ‘Create Database’ button, the dialog said it would take a couple of minutes to provision, and it sure did. I wasn’t timing it but it was at least 10 minutes before it was ready. This was probably the longest I’ve every waiting to provision anything on AWS.
Once it was ready, I tried to use the online query editor, but looks like there’s an additional step to create a user:
This option is under Network and Security:
After applying the change with the immediate option, I created a test table:
It’s been 2 years since I migrated this site from a native install on a VPS to another VPS running Docker. I covered my migration in a number of posts, the first of which is here:
The surprising thing (maybe? maybe not?) is that the site has been up and running for the past 2 years with no issues. I think I rebooted the VPS a couple of times for reasons I can’t remember, but other than that the site’s been up reliably for the past 2 years.
It’s also been 2 years since I last renewed my SSL certificate, so time to do a couple of updates. More to come later.
Following on from Part 1 and subsequent posts, I now have the app deployed locally on WildFly 17, up and running, and also redeployed to a small 1 cpu 1 GB VPS: http://www.spotviz.info . At this point I’m starting to think about how I’m going to redesign the system to take advantage of the cloud.
Here are my re-design and deployment goals:
monthly runtime costs since this is a hobby project should be low. Less that $5 a month is my goal
take advantage of AWS services as much as possible, but only where use of those services still meet my monthly cost goal
if there are AWS free tier options that make sense to take advantage of, favor these services if they help keep costs down
Here’s a refresher on my diagram showing how the project was previously structured and deployed:
As of September 2019, the original app is now redeployed as a monolithic single .war again to WildFly 17, running on a single VPS. MongoDB is also running on the same VPS. The web app is up at: http://www.spotviz.info
There’s many options for how I could redesign and rebuild parts of this to take advantage of the cloud. Here’s the various parts that could either be redesigned, and/or split into separate deployments:
WSJT-X log file parser and uploader client app (the only part that probably won’t change, other than being updated to support the latest WSJT-X log file format)
Front end webapp: AngularJS static website assets
JAX-WS endpoint for uploading spots for processing
MDB for processing the upload queue
HamQTH api webservice client for looking up callsign info
MongoDB for storing parsed spots, callsigns, locations
Rest API used by AngularJS frontend app for querying spot data
Here’s a number of options that I’m going to investigate:
Option 1: redeploy the whole .war unchanged as previously deployed to OpenShift back in 2015, to a VM somewhere in the cloud. Cheapest options would be to a VPS. AWS LightSail VPS options are still not as a cheap as VPS deals you can get elsewhere (check LowEndBox for deals), and AWS EC2 instances running 24×7 are more expensive (still cheap, but not as cheap as VPS deals)
Update September 2019: COMPLETE: original app is now deployed and up and running
Option 2: Using AWS services: If I split the app into individual parts I can incrementally take on one or more of these options:
