Amazon RDS Reviews

The primary use case for Amazon RDS is to optimize database management. The technology is utilized to ensure high availability, deploying the RDS technology across multiple availability zones for better fault tolerance and minimized downtime. 

Its use case is critical for applications that require high availability. Additionally, it is valuable for scalability with features like read replicas and storage auto-scaling, allowing easy scaling with increased users.

Amazon RDS provides data encryption using services like KMS, crucial for securing high-sensitive data and meeting compliance requirements such as HIPAA or PCI DSS. 

The best practices we've employed with RDS help design a well-architected framework, encompassing security, encryption, scalability with multi-availability zone deployment, and operational excellence with automated backups. RDS features, such as reserved instances, storage auto-scaling, monitoring with technologies like CloudWatch, and proxies, contribute to cost optimization. 

The solution enhances security with IAM authentication and offers high availability to end users.

Amazon RDS is my primary database. I store and perform CRUD operations in it.

We used to have a separate database. We managed everything, including scaling. We faced memory issues when there were too many hits, so we manually increased or cleaned the memory. Amazon RDS is automatically scalable. No intervention is needed. Upscaling and downscaling happen automatically.

Now, we have tighter controls. Earlier, we had roles mapped with AD integrations to the server where the database is. We used to do a lot of work. Now, we have IAM integration. If a person has a particular IAM role, they can access it. Amazon RDS has good authentication, operation, and autoscaling. It has features similar to an ordinary database. We get to do the same job without worrying about the infrastructure.

We are more on the development side of it. We develop software using RDS.

So, use cases are specific to our clients. We work for our clients, so whatever use cases they have, we generally support them on the cloud. Mostly for transaction processing of the application software that we develop for our clients. It could be in the health care domain, transport domain, or anything like that.

It's a fully managed database, so that makes our life easier from the operational standpoint. That is the key, basically.

Mostly from the operational standpoint, it is fairly easy to scale disaster recovery and all that. It becomes easier while we use Postgres and MySQL flavors of it. So whatever benefits we get from those databases are in addition to what AWS provides as a PaaS solution.

I use Amazon RDS to support scalability, with multi-AZ support being an essential aspect. It offers a managed service that simplifies my work significantly. I use it across multiple companies, supporting all scalability and availability needs.

The most valuable features of Amazon RDS are its availability and security support, which are crucial for managing the system effectively. Additionally, the scalability is impressive as it allows configuration and expansion quickly. It simplifies the process of scaling, especially when transitioning from MySQL to Amazon RDS. Before, I maintained scaling myself, but with Amazon RDS, tasks like in-place scaling of CPUs and memory are efficiently handled.

I am using Amazon RDS and CDMS clients for monitoring databases. I have set up multi-level servers for data collection and application development.

Amazon RDS makes it easier for me to manage databases compared to traditional databases like MongoDB or local host servers. It offers an easy-to-use interface that allows me to monitor instances and update necessary features conveniently. This convenience is significant for both local and remote data management.

When I was working for at my previous organization, we wanted to bring stability to all our MySQL databases. As a DBA, at first, it was scary as I thought I would be out of a job, however, the RDS managed DB allowed me to focus more on optimization and less on administration. (both hardware and software). 

When I was working at another organization we had a large amount of MySQL on-prem to manage. It required lots of time to set them up, monitoring, and maintain them. RDS really allowed us to remove all the painful administration parts. 

Less time was spent maintaining MySQL. Having to configure each server and spinning up a new MySQL in RDS takes 10 to 15min. It's a huge time-saving in maintenance. 

By using RDS, AWS takes care of the maintenance of the hardware and software updates. Being able to scale quickly or downsize with no impact is also great.

All of your databases are nicely organized under 1 interface; you have quick access to some monitors and Cloudwatch can be used to set up alerts based on thresholds and notify you. 

Today, with Terraform, you can automate the full process of creating RDS servers, deprecating them, changing their size, adding a replica, etc.

We have a SaaS-based application. We use the RDS version of SQL Server because it is self-managed by AWS in terms of patch management, SQL server patch management, and OS patch management.

Amazon RDS handles database backup mechanisms and patch management. Since the solution handles OS and database-level patches, we need not worry about security breaches. Amazon RDS has some metrics to show with respect to SQL performance or query running.

The product is pretty good for small or mid-scale organizations that don't have the luxury of proper DBAs or a large infra team. Scaling up and down is relatively easy without a proper setup. And apart from reducing these overheads, you have better performance insights if you use a server. And if you are serverless, your costs are lower. So we use both.

Concerning performance, when a cluster upgrades from lower to upper config, the connection drops. This could be solved by better coding and settings and included in the next release.

It's supposed to be scalable, but we don't feel that. True, there won't be any drops. The solution they gave was to maintain our cluster at a level sufficient for our peak load. However, that will probably defeat the whole purpose of on-demand scalability. So that is certainly where we might need to rethink the solution. It actually works in real-time, but it's not at a level where we can think of five seconds or 10 seconds there.