-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
rds: DatabaseInstance
requires 2 AZs even with multi_az
set to False
#30520
Comments
multi_az
set to False
DatabaseInstance
requires 2 AZs even with multi_az
set to False
You can deploy an Amazon RDS database in a single Availability Zone by not selecting the "Multi-AZ" option when creating the DB instance. [1] However, you still need to configure a DB subnet group that contains subnets in at least two different Availability Zones within the same AWS Region. [2] Even though the RDS instance will only be deployed in a single Availability Zone, having the DB subnet group span multiple AZs provides redundancy and failover capabilities if there is an issue with the primary AZ. The RDS instance will only actively use one of the Availability Zones in the DB subnet group, but the other AZ(s) serve as standby in case a failover is needed. [3] With that being said, the subnetGroup created for your DbInstance would still require subnets across multi-AZ as its vpcPlacement. aws-cdk/packages/aws-cdk-lib/aws-rds/lib/instance.ts Lines 795 to 800 in 665396f
|
DatabaseInstance
requires 2 AZs even with multi_az
set to False
DatabaseInstance
requires 2 AZs even with multi_az
set to False
We should improve the document and even check that in the code though. |
Thank you for the great reply. In our case - we don't really care about HA or redundancy for this use-case and are seeking to reduce costs. Is there no option to create a single-AZ database, then, or is that a pattern enforced by Amazon? |
The restriction you mentioned appears to be specific to AWS CloudFormation and not the CDK. Regarding your question about multiple Availability Zones (AZs), deploying resources across multiple AZs can incur cross-AZ data transfer charges, but these charges are usually minimal, as mentioned in the AWS Data Transfer # documentation. The benefit of high availability by using multiple AZs outweighs the potential cost, as it mitigates the risk of an entire AZ failure, as explained in the AWS Availability Zones documentation. Are you trying to optimize for cost savings by limiting the number of AZs used in your deployment? |
This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one. |
Describe the bug
Creating an RDS
DatabaseInstance
withmulti_az
set toFalse
should allow for a single AZ to be used, per the documentation:AWS also offers tons of documentation making mention of single-AZ RDS instances:
https://aws.amazon.com/blogs/database/best-practices-for-converting-a-single-az-amazon-rds-instance-to-a-multi-az-instance/
However, if you try to launch a
DatabaseInstance
in a single-AZ VPC, you get an error.Expected Behavior
Single-AZ VPC should be allowed.
Current Behavior
Reproduction Steps
Possible Solution
Remove the requirement for covering 2 AZs when
multi_az
is set toFalse
This seems to have caused confusion in the community even back to the CloudFormation days:
https://stackoverflow.com/questions/63974936/db-subnet-group-doesnt-meet-availability-zone-coverage-requirement-please-add
Additional Information/Context
For those of us setting up QA instances, or on bootstrap budgets, we can't always afford failover or multi-AZ. A single AZ DB solution seems to be supported - but the documented method of creating one doesn't seem to work.
CDK CLI Version
2.145.0 (build fdf53ba)
Framework Version
No response
Node.js Version
v22.2.0
OS
macOS
Language
Python
Language Version
3.12.0
Other information
No response
The text was updated successfully, but these errors were encountered: