I installed a LAMP stack in my AWS EC2 instances so that I can use the MySQL server. Somebody recommended using RDS. But RDS is not free and also a MySQL server. My question is what makes RDS so special comparing with my MySQL server in EC2 instances?
Thanks. By the way, I'm quite new to AWS.
RDS is a managed solution. Which means, AWS staff will take care of:
Patches
Backups
Maintenance
Making sure it's alive
Hosting your database in a second EC2 instance means that:
You have to manage everything of the above
Using a LAMP stack and co-hosting Apache and MySQL is the cheapest, but:
You have to manage everything of the above
You're probably hosting a database on an instance exposed to the internet
That said, if you're planning to host a production website / service that's more than a personal website / blog / experiment you'll probably need to host webserver and database in different instances. Picking RDS is less of a headache.
For anything thats not that important, a LAMP stack makes more sense. Less scalability, potentially less security but also less administrative overhead and costs.
Related
We have a java application running on Tomcat that was hosted on AWS EC2 with a RDS database. We migrated the application to Azure, and the performance dropped significantly. In EC2 we had a md5.large machine (2 CPUs, 8GB) and in Azure we have P2V2 (2 CPUs, 7GB).
The database stayed in RDS, so one of our hypothesis is that we are losing performance with database traffic, since they are on different hosts now. Could that be it? If so, would creating a VPN help in any way?
The short answer is yes, you will now have lag between your application server and the DB. The VPN would not make that much of a difference. What you want is to have your DB close to your application server again. One of the ways to do that would be to either also migrate your RDS to Asure or if your RDS need to stay in AWS then see if you can replicate your DB to Asure (Depends on DB type).
Imagine two cases:
I have web server running in an EC2 instance and it is connected to the database in the RDS, the managed database service.
I have web server and database running in the same EC2 instance.
Is my database in RDS going to be slower to access because it's not in the same machine?
How many milliseconds, approximately, does it add to your latency between the two?
Does this become bottleneck?
What about other managed database services like Azure, GCP, Digital Ocean, etc?
Do they behave the same?
Yes, it will be slower to RDS instances from your Webserver than a database on the same host, because you need to go over the network and that adds latency.
The drawback of running the DB on the same server is that you can't use a managed service to take care of your database and you're mixing largely stateless components (webserver) with stateful components (database). This solution is typically not scalable either. If you add more webservers, things get messy.
Don't know about Azure, GCP or Digital Ocean, but I'd be very surprised if things are different there. There's good reasons to separate these components.
We're considering to implement an ELB in our production Amazon environment. It seems it will require that production server instances be synched by a nightly script. Also, there is a Solr search engine which will need to replicated and maintained for each paired server. There's also the issue of debugging - which server is it going to? If there's a crash, do you have to search both logs? If a production app isn't behaving, how do you isolate which one is is, or do you just deploy debugging code to both instances?
We aren't having issues with response time or server load. This seems like added complexity in exchange for a limited upside. It seems like it may be overkill to me. Thoughts?
You're enumerating the problems that arise when you need high availability :)
You need to consider how critical is the availability of the service and take that into account when defining what is the right solution or just over-engineering :)
Solutions to some caveats:
To avoid nightly syncs: Use an EC2 with NFS server and mount share in both EC2 instances. (Or use Amazon EFS when it's available)
Debugging problem: You can configure the EC2 instances behind the ELB to have public IPs, limited in the Security Groups just to the PCs of the developers, and when debugging point your /etc/hosts (or Windows equivalent) to one particular server.
Logs: store the logs in S3 (or in the NFS server commented above)
I am new to Amazon Web Services. I was reading about Amazon ElastiCache and wanted to clarify if it is like (may be more than that) using RAM filesystem in Linux where we use a portion of system memory as a file system. As I referred AWS documentation it says ElastiCache is a web service. Is it like an EC2 instance with few memory modules attached? I really want to understand how it exactly works.
Our company has decided to migrate our physical servers into AWS cloud. We use Apache web server and MySQL Database running in Linux. We provide a SaaS platform for e-mail marketing and event scheduling for our customers. There is usually a high web traffic to our website during 9am-5pm on weekdays. I would like to understand if we want to use ElastiCache service, how it will be configured in AWS.? We have planned two EC2 instances for our web server and an RDS instance for the database.
Thanks.
Elastic cache is simply managed Redis or Memcached. Depending which one you choose, you would use the client for the cache with your application.
How you would implement it depends on what kind of caching you are trying to accomplish.
We're planning to upgrade our AWS to more recent hardware. The current setup is EC2 Classic intance-based servers attached to volumes which contain all of the apps data. The concept behind it is that if one of the instance-based servers were lost, we could recreate the server from its AMI and re-attach the volume with the data an be up and running again.
As we upgrade to servers as EC2/EBS volumes (and into a VPC), the risk of server being destroyed is mitigated. Is it worth it just keep all the apps on the new servers and forget about keeping them on attached volumes?
The strategy we used when moving to VPC was to make as few changes as possible. Just launch new servers in a public VPC, nothing else. If you start to change too much at once and encounter a problem, it will be harder to identify the source of the problem because there are so many changes.
For that reason, I recommend keeping your current setup. There might be advantages of a new architecture, but wait until after you've safely migrated to VPC.