|
| 1 | +Consider these strategies for optimizing your |service| costs. |
| 2 | + |
| 3 | +Underutilized {+Clusters+} |
| 4 | +~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 5 | + |
| 6 | +- Enable :ref:`auto-scaling <cluster-autoscaling>` on your {+cluster+} |
| 7 | + tier to match your usage and prevent over-provisioning. |
| 8 | + |
| 9 | + Scaling down only occurs once every 24 hours and must match |
| 10 | + specific conditions. To learn more, see :atlas:`Scaling Down a Cluster Tier |
| 11 | + </cluster-autoscaling/#scaling-down-a-cluster-tier>`. |
| 12 | + |
| 13 | + You can also manually move to a lower {+cluster+} tier by regularly |
| 14 | + monitoring the cluster's |cpu|, WireTiger cache, memory, and IOPs |
| 15 | + over a rolling 30 day period of normal use. Generally, if the usage |
| 16 | + is steadily below 30% of allocated resources, we recommend that you |
| 17 | + scale down. |
| 18 | + |
| 19 | +- For {+dedicated-clusters+}, consider scaling down |
| 20 | + to a lower tier or :ref:`pausing <pause-terminate-cluster>` the {+cluster+} |
| 21 | + if you won't use it for an extended period. |
| 22 | + |
| 23 | + We recommend that you |
| 24 | + use ``M10`` {+clusters+} only for development and test environments. To learn more, see :ref:`arch-center-cluster-size-guide`. |
| 25 | + |
| 26 | +- For development and test environments, we recommend that you: |
| 27 | + |
| 28 | + - Enable a cron job to |
| 29 | + pause dev and test {+clusters+} during the night when no one actively develops against the {+cluster+}. You can pause {+clusters+} with the |
| 30 | + {+atlas-admin-api+} by using the :oas-atlas-op:`Modify One Cluster |
| 31 | + </updateCluster>` endpoint to set the ``paused`` field to ``true``. |
| 32 | + |
| 33 | + - Set an alert that triggers if a dev or test |
| 34 | + {+cluster+} has not had any activity in over one week. You can |
| 35 | + create alert configurations with the |
| 36 | + {+atlas-admin-api+} by using the :oas-atlas-tag:`Alert Configurations |
| 37 | + <Alert-Configurations>` endpoints. To learn more about |
| 38 | + monitoring and alert recommendations, see |
| 39 | + :ref:`arch-center-monitoring-alerts`. |
| 40 | + |
| 41 | + - Consider terminating unused dev and test {+clusters+} after a |
| 42 | + set amount of time and sufficient email alerts to the {+cluster+} |
| 43 | + owner. You can |
| 44 | + terminate a {+cluster+} with the |
| 45 | + {+atlas-admin-api+} by using the :oas-atlas-op:`Remove One Cluster |
| 46 | + </deleteCluster>` endpoint. |
| 47 | + |
| 48 | + |
| 49 | +High Backup Frequency |
| 50 | +~~~~~~~~~~~~~~~~~~~~~ |
| 51 | + |
| 52 | +- :ref:`Continuous backups <pit-restore>` are expensive, but they give |
| 53 | + you the most safety to recover data in case of disaster or code logic |
| 54 | + error. We recommend that you enable continuous backups only for |
| 55 | + production applications at the most critical data tier. |
| 56 | + |
| 57 | +- :ref:`Lower the frequency of backups <creating-backup-policy>` for |
| 58 | + {+clusters+} that store less critical data. Consider terminating |
| 59 | + these {+clusters+} entirely for development environments. |
| 60 | + |
| 61 | +Optimize Data Transfer Patterns |
| 62 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 63 | + |
| 64 | +Whenever possible, opt for same-provider, same-region data transfer to minimize |
| 65 | +costs. Only use inter-region or internet transfers when necessary, |
| 66 | +such as for disaster recovery scenarios where you need to restore the application in a different region. Locating your |
| 67 | +{+cluster+} in the same region as most of your traffic — likely where you host your |
| 68 | +application — can greatly reduce data transfer costs. |
| 69 | + |
| 70 | +Optimize Queries |
| 71 | +~~~~~~~~~~~~~~~~ |
| 72 | + |
| 73 | +Queries that take a long time to execute can increase resource usage, |
| 74 | +requiring higher-tier {+clusters+}. :ref:`Optimize these queries <performance-advisor>` |
| 75 | +to reduce resource consumption and lower costs as a result. |
| 76 | + |
| 77 | +Optimize Storage |
| 78 | +~~~~~~~~~~~~~~~~ |
| 79 | + |
| 80 | +Use features like :ref:`online archive <online-archive-overview>` |
| 81 | +or :manual:`TTL indexes </core/index-ttl/>` to |
| 82 | +move older data from more expensive hot storage to less expensive cold |
| 83 | +storage. After you archive data, you can access the data through |
| 84 | +:ref:`Atlas Data Federation <data-federation-overview>`. |
| 85 | + |
| 86 | +Use Cost Explorer |
| 87 | +~~~~~~~~~~~~~~~~~ |
| 88 | + |
| 89 | +Regularly use the :ref:`Cost Explorer <cost-explorer>` tool to monitor spending |
| 90 | +patterns at the organization, project, {+cluster+}, and service levels. Set a |
| 91 | +frequency that works for your needs. |
| 92 | + |
| 93 | +Set Alerts |
| 94 | +~~~~~~~~~~ |
| 95 | + |
| 96 | +Configure :ref:`billing alerts <billing-alerts>` for key thresholds, such as |
| 97 | +when your monthly costs exceed a certain amount. For example, set an alert when |
| 98 | +costs exceed $100. This proactive approach helps you avoid surprises. |
| 99 | + |
| 100 | +Review Invoices |
| 101 | +~~~~~~~~~~~~~~~ |
| 102 | + |
| 103 | +Each month, review your invoice to assess the highest-cost services using the |
| 104 | +previous billing optimization suggestions. This is a recommended best practice |
| 105 | +to identify cost reduction opportunities. |
| 106 | + |
| 107 | +If you see unexpected changes on your invoice, check your cloud |
| 108 | +computing costs, which are often the largest portion of your bill. You |
| 109 | +can review cloud computing costs in the :guilabel:`Summary By Service` |
| 110 | +card of any invoice within the |service| :guilabel:`Billing` section. |
| 111 | +The :guilabel:`Summary By Service` view shows the costs of all |
| 112 | +{+clusters+} by provider, tier, and region. |
0 commit comments