I have taken a AWS Lightsail Unix Instance for one of my pilot project, I wanted to explore AWS ecosystem and thought this would be a easy playground to start with. The plan I opted was a USD 5 per month, which gives 1 GB Memory, 1 Core Processor, 40 GB SSD Disk and 2 TB Transfer.
After subscribing I created a LAMP instance and a Plesk Instance, assigned static IPs to both instances and setup connections from my PC to transfer files using PuTTY; also setup access to Plesk and phpMyAdmin to start work.
In the first month itself, I am seeing a huge bill of USD 985 for using AWS RDS, details in bill are as below:
Amazon Relational Database Service for MySQL Community Edition
$1.080 per RDS db.r4.xlarge Multi-AZ instance hour (or partial hour) running MySQL
My question is - When I created LAMP, does it create a AWS RDB service automatically, I have hardly used MySql for anything. It seems AWS Lightsail is throwing hidden charges without notifying customers about actuals.
No, creating a LAMP stack on Lightsail does not create an RDS instance on your behalf. With the LAMP stack on Lightsail, the MySQL database is installed on that instance alongside PHP and Apache - there is no charge beyond the $5.00 / month (in your case) as long as you don't go over the data transfer limit.
I can't say why you're getting charged for RDS, but it's not because you fired up Lightsail instances.
Thank you folks!
I tried to go through several docs AWS provides on pricing. There is no indication that AWS RDB services automatically starts on LAMP installation. I wanted to take second opinion before raising a complaint with them. I have opened a case, and they have confirmed to revert the charges, however there is no clarity how AWS RDS service has started. At present I have removed all DB snapshots and backups.
Related
I have a small single-instance deployment running on an EC2 instance which hosts both a web application and its database (MySQL). I've been looking to separate the deployment out into an EC2 instace for the web app and an RDS cluster for the database, and wanted to take advantage of the new AWS Savings Plans for both if possible.
My questions the are:
AWS Savings Plans seem to only apply to 'pure' compute EC2 instances, not to RDS instances as well. Can someone confirm or disprove this?
If Savings Plans did apply to RDS instances, is there a reason to not use them, and instead just use an Instance Reservation?
Since August 2020, AWS Savings Plans includes:
Amazon EC2
AWS Lambda
AWS Fargate
They do not apply to Amazon RDS db instances. For those, you can continue to use Amazon RDS Reserved Instances.
I want to clarify that even though Savings Plans do not cover RDS instances, they do cover EC2 instances that are part of EMR, ECS and EKS Clusters. Based on this link:
"Both plan types apply to EC2 instances that are a part of Amazon EMR, Amazon EKS, and Amazon ECS clusters. Amazon EKS charges will not be covered by Savings Plans, but the underlying EC2 instances will be. "
Also, Compute Savings Plans also apply to your Fargate and Lambda usage.
We moved to RDS from EC2 instances running self installed MySQL years ago. For me, at has been great. All of the RDS features work flawlessly, point and click, without the mundane work of spinning up, replicating, backing up, and failing over databases. It simply works great. Use reserved instances if you plan on keeping for at least a year. At 30% savings the cost is awash even if you bail on the server after about 9 months and don't use the entire year. Plus you can sell the unused remaining on the marketplace.
Downsides?
You do NOT get command line OS access to the MySQL server. You get an admin login to mySQL. The only way to manage it is through the AWS UI and the mysql client command line or managing client (like MySQL Workbench or Heidi).
You may want to run a mysqldump script on a separate EC2 to dump databases separately/additionally. AWS does SNAPSHOTS which require an entire restore of a sandbox server just to get a single table someone botched up, for example. I go to the MySQLdump files all the time. Never have needed the SNAPSHOT unless I am spinning up a sandbox copy of the entire instance for some reason.
In a nutshell, mySQL on RDS is great.
One other side note. We migrated an app using MySQL5.7 to Aurora MySQL with absolutely zero issues. Complete drop-in replacement (in our case).
I'm working on a small personal project with a free-tier account.
I have one linux instance which I have my nodejs app running. The app basically listens for any incoming websocket data and uses AWS SNS to send the data to my iPhone. App needs to access RDS DB that I set up every time this happens.
Today I got an email saying that I used 85% of the usage limit for AWS EBS snapshot storage. I left it for few hours and now it used 100% and it says the Month-end forecasted usage is 3 GB-mo 310.00%.
It seems like this EBS snapshot is just a backup so is there a way to disable this to keep my cost $0? If not, how much will it cost me to run this app? Would moving the RDS DB to ec2 help reduce some cost?
I need to host Accounting desktop application on Windows server. SQL database of this application will be used as a source for ecommerce website, so there will be quite often read/write operations to this database (from different linux server). Is using AWS a good idea here? Does the read/write database operations count for usage? Meaning, if I have a cron that reads DB every 5 minutes, does it mean I will be billed for 24/7 usage?
Thanks.
In databases PaaS = RDS (like in EC2, so with VMs) you're paying per hour of instance that you have available, it doesn't matter if you use it or not.
Answering your question - it doesn't matter if you will be querying the DB every 5 minutes, 1 second or 1 hour. You will pay for the database the same amount (transfer costs are in most cases negligible when compared to EC2/RDS costs) = for the availability you need. If you need it to be available 24x7, you will pay for 24x7. If you need your database to run only during specific hours during the day (or only Mon-Fri) you can automate starting/stopping it (e.g. with CloudWatch Events + AWS Lambda) to lower your cost.
But then I guess if it's ecommerce, you anyway need the database to be available 24x7 :)
Depends. If you want to setup your own SQL server on an EC2 instance or use AWS RDS.
In case of former you SQL server is like any other application running on an EC2 instance and the costs are simply a factor of EC2 pricing
In case of latter refer AWS RDS pricing for SQL Server
I am trying Amazon Aurora instance and I can not see an option to stop it. The only options are Delete and Reboot.
Am I missing something.
Edit: 2018/09/25 - Amazon Aurora Now Supports Stopping and Starting of Database Clusters
Per this announcement, Aurora now supports starting and stopping the db instance. This feature was released for other RDS configurations last year and generally behaves the same in this implementation. Stopping the database cluster stops the primary instance and any Aurora replicas. The database will remain stopped for 7 days, after which it will be automatically restarted.
Additionally, see:
AWS Documentation - Stopping and Starting a DB Instance
AWS CLI Documentation - aws rds start-db-instance
AWS CLI Documentation - aws rds stop-db-instance
Edit: 2018/08/13 - Serverless Aurora supports infrequent access workloads
Per this announcement, Serverless Aurora has been released and has a feature to pause compute capacity after N consecutive minutes of inactivity. Here's an example of this configuration from the announcement blog:
This value is configurable up to 1440 minutes (24 hours), and would be comparable to "stopping" an Aurora Instance because you are not paying for compute capacity while compute capacity is paused, only database storage.
If your use case includes infrequent access (example: a dev instance that is not used after-hours), then this is currently the easiest option available.
Edit: 2017/06/01 - RDS can now be stopped/started, per this announcement, but does not support Aurora yet.
In the AWS console, a 'Stop' option has been mentioned to the same menu described in the question body. A stopped instance retains its storage but cannot be modified until it is started again. Instances cannot be permanently stopped -- after seven days, a stopped instance will be automatically started again.
Unfortunately, some configurations still don't support this feature. See below the break for an alternative.
Additionally, see:
AWS Documentation - Stopping and Starting a DB Instance
AWS CLI Documentation - aws rds start-db-instance
AWS CLI Documentation - aws rds stop-db-instance
Alternative suggestion for incompatible configurations:
This includes:
Aurora via old SDKs prior to September 2018
Old SDKs prior to June 2017
RDS with Multi-AZ
RDS with read replica
RDS with SQL Server Mirroring
RDS instances in these situations cannot be stopped and started at-will like an EC2 instance. You can, however, approximate this behavior by deleting the RDS instance with a final snapshot, and then returning later to restore an RDS instance from that DB snapshot.
This is approximate to "stopping" because no new data will be written once your final snapshot is taken, and you also won't be paying for a running RDS instance. In the same way that you would pay for any EBS volumes attached to your stopped EC2 instance, you will likewise continue paying for the storage of the DB snapshot while it exists.
This behavior diverges from stopping an EC2 instance inthat the underlying infrastructure will no longer exist. When you restore from snapshot, that will be on a new RDS instance and that restoration will take some time to complete, depending on the size of both your infrastructure and snapshot.
Further Reading
AWS RDS Documentation - Delete Instance with Final Snapshot
AWS RDS Documentation - Restoring From a DB Snapshot
They did add support for stopping/starting RDS instances this month (June 2017). The key bit of info from #Venkata's link is: "The stop/start feature is available for database instances running in a Single-AZ deployment which are not part of a Read Replica (both source and replica) configuration."
This means it does not work for Aurora because it is Multi-AZ by default. You do not even receive the option in the interface.
It also will not work for MySQL if a read replica is configured. You will not get the option on the slave and you get the option on the master but it fails if you try to use it.
You can achieve the same thing with a restore from a snapshot... but the down side is that takes roughly an hour with our large db instance whereas stopping it and starting it can happen in ~5 minutes.
They just added support for this today:
https://aws.amazon.com/about-aws/whats-new/2017/06/amazon-rds-supports-stopping-and-starting-of-database-instances/
Enjoy! :)
I have created a web service with a NoSQL database, I wish to host this using some sort of cloud storage so I can access the web service and database anywhere. I have never done this before so I'm not sure where to start. Any suggestions of where I could host the service and database would be hugely helpful.
I use AWS, a lot of people like Rackspace. However any hosting company can store your DB for you.
Heres what I use, Check out AWS Free Tier with Amazon RDS, Its free under the teir limit
https://aws.amazon.com/rds/free/
750 hours of Amazon RDS Single-AZ db.t2.micro Instance usage running MySQL, MariaDB, PostgreSQL, Oracle BYOL or SQL Server (running SQL Server Express Edition) – enough hours to run a DB Instance continuously each month
20 GB of DB Storage: any combination of General Purpose (SSD) or Magnetic storage
10 million I/Os
20 GB of backup storage for your automated database backups and any user-initiated DB Snapshots
In addition to these services, the AWS Management Console is available at no additional charge to help you build and manage your DB Instances on Amazon RDS.