-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize AWS costs, focused on lower-traffic operation #2117
Comments
Overall, I'm broadly on board with this. I hit a mental block at "we can't use ACM anymore", so I'm glad you're pushing this forward. A few specific notes:
|
jpd236
added a commit
to jpd236/jolly-roger
that referenced
this issue
Jun 29, 2024
In this mode, only memory and swap usage is captured. At two metrics per instance, this usage should remain in the free tier (10 custom metrics total). Total CPU usage is available as a built-in metric in EC2, so this should give a reasonable picture of CPU/memory usage for basic monitoring. The additional metrics around detailed CPU, disk, and network are available in the "detailed" mode (the default). This also fixes an issue with the indentation in the YAML when CloudWatch is enabled. We also have to be careful when creating the CloudWatch JSON config via string substitution, which unfortunately makes for a somewhat cludgier YAML file. See deathandmayhem#2117
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current CloudFormation scheme scales nicely for higher traffic events, but is a bit overkill for running with low traffic throughout the rest of the year. I'd like to optimize the costs a bit to make keeping it running a bit more palatable, even if it comes at the cost of some overall reliability.
I think the main win here would be to support a single-instance of EC2 so the NLB could be dropped, as that is the most expensive component. If we assume coturn is necessary for full voice chat reliability, I think we have no choice but to support terminating TLS within the EC2 instance and managing our own certificate. (If it were just HTTP(S) traffic, I think we could use Cloudfront, which has a pretty large always-free tier). Amazon's certificate manager can't be used directly within EC2.
So for single instance, I believe we need to:
As I understand it, this would eliminate a ~$16.20/month cost for the NLB. Data transfer costs look higher from EC2 but only after the first 100 GB which is free.
From there, two other ideas I have for optimization:
Replace credstash with AWS Systems Manager Parameter Store. The KMS key that credstash depends on is $1/month. While the parameter store uses KMS under the covers, I believe that the only charges for it are the per-request ones which should be negligible here.
Reduce the number of metrics tracked in Cloudwatch. I haven't actually enabled Cloudwatch yet, so I'm less sure how this works, but I believe that every metric beyond the 10th is $0.30/month. IIUC, with single instance, we'd just have 13 metrics, so $0.90/month, but we could probably drop 3 less essential ones to make it free.
Overall, I think that puts baseline costs at $3.60 for the IP + $0.50 for the Route 52 config + the EC2 costs ($8.35 for t2.micro) = $12.45/month. Higher than a simple Heroku instance, but much more reasonable than the ~$30 I think it would run to right now.
I'm not super familiar with AWS so the above may have some flaws/misunderstandings, and/or there may be better ways of optimizing here. Thoughts welcome :)
The text was updated successfully, but these errors were encountered: