From 1439371d9638777c0ceb651bd49d33b3cf69afe1 Mon Sep 17 00:00:00 2001 From: joeyouss Date: Thu, 26 Dec 2024 15:33:54 +0530 Subject: [PATCH] new changes --- kb/cloud-cost-management/cloud-cost-management-faqs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kb/cloud-cost-management/cloud-cost-management-faqs.md b/kb/cloud-cost-management/cloud-cost-management-faqs.md index 9e08330407b..29b824d9fd2 100644 --- a/kb/cloud-cost-management/cloud-cost-management-faqs.md +++ b/kb/cloud-cost-management/cloud-cost-management-faqs.md @@ -584,7 +584,7 @@ To clone an autostopping rule, click on the three dots on the rule on the overvi This behavior is expected and stems from the nature of AWS's infrastructure. Starting and stopping certain RDS instances is inherently slower compared to EC2 instances, as confirmed in the AWS RDS documentation. To address this issue: -- Increase the cooldown duration: This prevents the database from stopping too frequently, ensuring it aligns with actual usage and minimizes disruptions. +- Increase the idle time duration: This ensures the database does not stop too frequently, allowing it to stay running for longer periods of inactivity, which reduces disruptions. - Implement an uptime schedule: For workloads with predictable usage patterns, scheduling instance availability can reduce startup delays while still maintaining cost savings. While these steps can improve the experience, the startup time itself cannot be reduced as it is dependent on AWS's underlying processes