pricing encrypting RDS with KMS - amazon-web-services

i want to encrypt my RDS instance from Amazon Web Service but i dont know the explanation of the pricing.
It says that each API request of AWS Key Management Service costs $0.03 per 10,000 requests.
Every query means an API request or every connection ?
Hope you can help me.

If you are encrypting your RDS storage volumes, using the default kms/rds key, then you will pay $1/month for the key, but your API requests will be negligible.
If you look at the KMS pricing example for EBS, the key is only used when creating the volume. It should be the same for RDS.
Update: This is not 100% correct. There will be a KMS call every time an encrypted volume is attached to an instance, which means every time you reboot an RDS instance you should have a KMS call. But overall cost should be negligible, and you should not be at risk of hitting any sort of query limits.

Related

AWS RDS disaster recovery using cross-account

We are running AWS RDS PostgreSQL, with daily automatic snapshots, encrypted by AWS managed KMS key. My objective is to minimize risks and data loss, in case when main AWS account (running RDS) got compromised or RDS deleted/damaged in some way.
What we've implemented so far: RDS snapshots are shared with different (backup) account, periodically copied to backup account and re-encrypted with the KMS key from the backup account, to make copies local, and independent from the main AWS account.
I'm wondering if there are better ways to minimize recovery time objective and recovery point objective in case of a disaster event?
This AWS blog post seems to weigh the options well.
Automated backups are limited to a single AWS Region while manual snapshots and Read Replicas are supported across multiple Regions.
Having cross region Read replica would give you the best RPO and RTO as you can promote replica to be an independent instance which should improve your RPO / RTO
Alternatively, if you choose to use Amazon Aurora Backtrack it seems to offer a similar option to having a read replica but I do not have a personal experience with this feature so can't say how effective it is in improving RTO and RPO.
I wrote two scripts implementing flow at the diagram drawn above ^^^, the idea is to run them daily:
src_acc_take_share_rds_snapshot.py in src account:
list available RDS snapshots according to provided regexp
recrypt them with KMS key, shared from dst account
share recrypted RDS snapshots with the dst account
remove old decrypted snapshots
dst_acc_copy_shared_rds_snapshot_to_local.py in dst account
list RDS snapshots, shared in src account with dst account
copy RDS snapshots from src account to dst account
remove old decrypted snapshots
fire an SNS message if desired snapshot count != actual
and put them at GitHub https://github.com/mvasilenko/dr-rds-share-snapshot

Distributed Database Access in aws cloud front

I have MYSQL Database in AWS RDS and Web Application in Mumbai Region. I want to access the web application from the USA with good latency/speed. I have used AWS CloudFront still the application is very slow.
Any Suggestions.
Best,
Syed
AWS CloudFront
How about a cross-region read replica of your MySQL database in the USA? If the majority of your database operations are read rather than write, this will give you a significant improvement in response time.
In standard, it is recommended to keep databases and apps should be in the same regions(eventually can try to keep in the same zone) from the majority of end-user belongs to
As of now, you can create a cross-region replica but you need to be ready for replica lag and data transfer charges. In the long term, plan to move your setup to N.Virgania or any other USA region.

AWS Multi-AZ verification

I modified my RDS instance to "Multi AZ : Yes". My primary RDS instance is in us-west-1a and for multi-AZ the secondary zone is shown as us-west-1c. I wanted to verify if whatever changes I am making on my primary database are getting copied to the Multi-AZ standby database quickly.
But I am not able to understand what endpoint URL should I use to login into Multi-AZ database. I am thinking the end point URL would be different from primary. Could you please help me on this?
You do not have access to the secondary RDS instance in a Multi-AZ configuration. You just need to trust that AWS is replicating data correctly. In a Multi-AZ configuration, RDS will write to both replicas syncronously. It will not return the write request until both replicas have written correctly.
To access a Multi-AZ instance, you issue your reads and writes to the single RDS endpoint. In case of an issue, AWS will modify the DNS entry for that endpoint to point to the secondary replica. So as long as you are using the endpoint DNS record, and not caching the IP address when accessing the RDS instance, the failover process should be transparent to you with only a minute or so of "downtime".
take a look at https://aws.amazon.com/rds/details/multi-az/. You don't typically interact with the replica(s) of RDS resources directly; AFAIK ( I'm not an rds expert ) you can't do what you're describing. The idea is that RDS does that for you, automatically keeping a consistent replica in a different AZ, and providing to you a consistent DNS endpoint.
Although OP asks for "verify data is copied quickly", Google pointed me here to "verify a multi-AZ RDS deploy". I'll share what I found in hopes that it's halfway helpful.
In the RDS console, there is an option on reboot to Reboot from failover which doesn't appear on a standard deploy.
Standard deploys do not have this option, which was a small but satisfying indication that the multi-AZ was acting as expected.
Source (and generally a pretty good read)
Q: Can I initiate a “forced failover” for my Multi-AZ DB instance
deployment?
Amazon RDS will automatically fail over without user intervention
under a variety of failure conditions. In addition, Amazon RDS
provides an option to initiate a failover when rebooting your
instance. You can access this feature via the AWS Management Console
or when using the RebootDBInstance API call.

Amazon RDS billing

My doubt is how the Amazon RDS instance is billed. I read somewhere that it is a component based billing based on the CPU/hour, number of input/output requests, etc.,
How are the I/O requests interpreted? I have a model in which I am trying to reduce the number of input queries that go into the cloud. Will it reduce my yearly cost to a good extent?
Full pricing information is available on the Amazon RDS Pricing page. It involves:
An hourly charge for the RDS instance
A charge for data storage based on amount of storage (including backup storage beyond the provisioned storage size)
A Data Transfer for traffic flowing out of AWS to the Internet
A minor charge for traffic flowing between Availability Zones
There are no charges relating to database requests. In fact, these requests are directly between client apps and the database and are not visible to AWS.
Update: Amazon Aurora also charges an "I/O request" charge. See comments below.

Turn off Amazon EC2/RDS

I am in the process of learning more about Amazon AWS. I want to turn off my Amazon Elastic Beanstalk EC2/RDS services. I have selected the minimum service entries, but I am still racking up small service charges. How do I do this?
have selected the minimum service entries, but I am still racking up
small service charges.
It isn't clear what you are saying with that sentence. Do you mean to say that you are within the limits of the free tier and yet you are still getting charged?
If you want to just "turn off" your EC2 and RDS instances then delete/terminate them. Afterwards look at the EBS snapshots and volumes, and the RDS snapshots and delete any of those that are still there. That will most likely stop the charges.
If you want to know exactly what you are being charged for so that you can zero in on the culprit you can enable detailed billing.
AWS has pretty good documentation on setting up and terminating instances. Here's a page with instructions on how to terminate an environment using the AWS Management Console:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.terminating.html.