We can save money on instances by decreasing the number of running instances in periods of low traffic and increase in periods of high traffic. We currently set the desired number of instances as the same as the minimum number of instances. If we instead allow the minimum to be much lower than our standard desired level, we can adjust the scaling policy to more dynamically scale our apps up and down according to traffic at different times of the day.
- [x] Reduce instance size of `newsletters-api` and `newsletters-tool` to `t4g.micro` (https://github.com/guardian/newsletters-nx/pull/309)
- [ ] https://github.com/guardian/dotcom-rendering/issues/10962
- [ ] https://github.com/guardian/dotcom-rendering/issues/10968
- [ ] Adjust scaling policy for DCR app to dynamically scale up and down according to latency metric (ie the minimum instances should not always be the _desired_ number of instances)
- [ ] Downsize instances after monitoring performance
Follow-up ticket from https://github.com/guardian/dotcom-rendering/issues/10465
AWS reservations calculation here: https://docs.google.com/spreadsheets/d/18spSMbQfpb46lk-EbkNrRO4hZJ-ZJLXHlFFy0mJYPcA/edit?usp=sharing
We can save money on instances by decreasing the number of running instances in periods of low traffic and increase in periods of high traffic. We currently set the desired number of instances as the same as the minimum number of instances. If we instead allow the minimum to be much lower than our standard desired level, we can adjust the scaling policy to more dynamically scale our apps up and down according to traffic at different times of the day.