It seems like you got this working, but the answer may be incomplete if you are using a customer managed CMK. When you use a customer managed KMS CMK, you are in control of who (what) can use your CMK in KMS. For example, if you put in an explicit deny in your CMK Key Policy for kms:creategrant for all principles and restart the database, you will find that the database won't start because it will be unable to load the data. (If you do such a test, make sure you use a single-AZ since the multi-AZ will have a warm failover ready when you reboot it). By default, the key policy enables delegation to IAM, so you can manage access to the key in IAM, but this is not required. You have fine grained control over access to items like creategrant in a customer managed CMK. You can even use conditions of the encryption context to grant some services and deny others, or even specific rds instances or ebs volumes: https://docs.aws.amazon.com/kms/latest/developerguide/services-rds.html
See here for some more information on RDS and the types of encryption supported. https://aws.amazon.com/blogs/database/securing-data-in-amazon-rds-using-aws-kms-encryption/
Also, see here for what is needed for the use of EBS encryption, which is what is used by RDS for storage: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#ebs-encryption-requirements