We have web app and DB installed on the same EC2 instance.
The os is Windows.
We want to save costs and was thinking of going with spot instances but would consider RI and saving plans.
Some of the application data is stored in the os registry (I know it is not the best approach, but this is the situation till we'll get next version).
What is the best way to launch the app with the DB on a spot instance and to make sure it remains the data in case the instance is taken ?
You're looking in the wrong place to try to save money. Spot is for stateless and fault-tolerant workloads, your app is not stateless as the DB lives on the same single instance.
Related
i am newbie to use AWS system.
well, my freetier is just expired recently.
so far, i run an instance all day and use ssh to make code there.
but now, i realized it could charge me more than i expected. so i decided to terminate the instance.
then, how can i connect to instance easily? do i need to turn it on everytime i want to code?
And which is better? whether using DynamicDB(in AWS) or make a separated instance and install linux and mongodb(or something else).
Thanks =)
Best practices to save on cost is to stop (not terminate) your instance when you are not using it.
You will not pay for your instance in STOPped mode. You will just pay for the storage of your EBS volumes (boot drive).
When you Terminate your instance, you cannot restart it. If you Terminate you instance, be sure your data are saved on a secondary EBS volume or a snapshot or stored on S3.
Regarding your second question, it really depends on your application needs : at what scale do you expect to run ? How large will be your data store ? What type of query are you going to perform ?
For most cases, DynamoDB will be more cost effective than running a couple of EC2 instances with a Mongo DB cluster. And you will not need to maintain and to operate the infrastructure, AWS will do it for you.
You might have other point of view from this question : DynamoDB vs MongoDB NoSQL
Might be easier to just use MongoHQ: https://bridge.mongohq.com/signup
If you're interested in learning how to set up the servers, digitalocean is a good bet as they don't charge you for the IOPS and give you SSDs on the instance:
http://www.digitalocean.com
Enjoy!
As far as I understand for new created amazon instance ephermeral data store is used by default, unless EBS store is configured.
After stop of the instance, which uses ephermeral data store, I will loose all data. Is it correct ?
I noticed that EBS store has been created automatically for my instance. I have created few files in home directory, but this files were not deleted after reboot. So where is ephermeral data is stored ?
I want to install database to Amazon host. Should I worry about data loose with default setup and what is the common configuration, for example
Create instance
Install and configure database on ephermeral data store
Make AMI
Create EBS store and configure database to use it as storages
After stop of the instance, which uses ephermeral data store, I will loose all data. Is it correct ?
To be specific, after you terminate or stop a node, any data on instance-specific storage will be lost. A reboot is different, and your data is intact in those cases. I am using these terms to match the terms in the AWS console.
To confuse matters slightly, some EBS-backed nodes also have some instance-specific storage. All instance-storage nodes are 100% instance-backed, though. So you really need to understand whether your data is hitting an EBS disk or instance-local storage.
I noticed that EBS store has been created automatically for my instance. I have created few files in home directory, but this files were not deleted after reboot. So where is ephermeral data is stored ?
Several points here:
For an EBS-backed instance, your /home partition is on the EBS root device, and hence data will persist provided the volume exists.
Again a reboot wouldn't delete your data even if you had an instance-storage node, but it sounds like you chose an EBS-backed node.
If you had instead created these files in /mnt, then stopped your instance and later started it again, you might have lost them. Again it depends exactly which ec2 node type you're running.
Regarding your last point - I would recommend that you just make sure your data is being stored on some EBS backed disk. Whether that is your root device or a separate EBS volume is up to you and depends on your specific needs.
I want to install database to Amazon host.
You should give some thought to not installing and maintaining your own database. Doing so is complex, error prone, and can be quite time consuming. I
A better option for most folks is a turnkey database solution like RDS. This is a performant database that you don't have to really think about - it'll just work. RDS isn't for everyone, as there are some restrictive permission issues, but generally speaking it's great. I use it every day.
You can run databases on top of EBS and it'll work just fine. But you are biting off being a database admin at that point, and need to worry about all the complexity that comes with it. In my opinion, better to focus your time & energy on things like database schema, queries, and other aspects of your business.
So the whole purpose of me moving my mobile app from shared server to Amazon Web Services is so that I can hopefully start out with minimal storage space and cpu usage and expand as I need to without any app downtime. In other words, in my app all I am doing is calling some php scripts that then store data to a MySql db and upload / save some data files to disk. Is it possible to expand without having to create a whole new instance that has more CPU / Storage / Ram capabilities and then having to migrate all my php scripts over to the new instance? I'm new to AWS so I'm hoping to learn.
Stop the running instance and change the instance type and start it back.
Update:
Here's the screenshot on how to upgrade your instance:
You can create an image of your current instance called an AMI (requires reboot of your instance). Then you can create a new instance of any size using that AMI (so you won't have to migrate anything).
You can eliminate downtime by having both your new instance and your original instance running simultaneously, switch your Elastic IPs (if you have any) and take the original server offline.
The only downtime will be a minute or 2 while your machine reboots from the AMI creation.
Documentation: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html
Note: This is all assuming that your database is somewhere else (like in an RDS instance) that is not installed on your EC2 instance. If it is (or you save files and other stateful information on the webserver), then I suggest following Mar Cejas's advice and just take the server down and start it back up as a different size.
Curious if this is possible:
We have a web application that at MOST times, works just fine with our single small instance. However, when we get multiple customers running simultaneously intense queries (we are a cloud scheduling service); our instance bogs way down to near 80% cpu load and becomes pretty unresponsive.
Is there a way to have AWS fire up another small instance (or a few), quickly, only for the times that its operating under this intense load? BUT, the real question is how does this work when we have very frequent programming updates to our application? Do we have to manually create a new image everytime we upload a code change???
Thanks
You should never be running anything important on a single EC2 instance. Instances can--and do--go offline randomly. Always use an autoscaling (AS) group that spans multiple availability zones. An AS group will automatically bring new instances online when you hit a certain trigger (in your case, CPU utilization). And then it will scale down the instances when traffic subsides. Autoscaling is the heart and soul of AWS and if you're not using it, you might as well be using a cheaper (and more durable) VPS host.
No, you don't want to be creating a new AMI for each code release. Ideally you should use a base AMI (like one of Amazon's official ones) and then have it auto-provision at boot. You can use the "user data" field when you launch an AMI to bootstrap this process. It can be as simple as a bash script that pulls from your Git repo to as something as sophisticated as Puppet or Chef.
The only time I create custom AMI's is if the provisioning process just takes too long. However that can almost always be solved by storing the needed files in S3.
I have an Amazon EC2 Micro instance running using EBS storage. This more than meets my needs 99.9% of the time, however I need to perform a very intensive database operation as a once off which kills the Micro instance.
Is there a simple way to restart the exact same instance but with lots more power for a temporary period, and then revert back to the Micro instance when I'm done? I thought this seemed more than possible under the cloud based model Amazon uses but it doesn't appear to simply be a matter of shutting down and restarting with more power as I first thought it might be.
If you are manually running the database operation, then you can just create the image of the server, launch a small or a high cpu instance using the same image, run the database operation and then create the image and launch it again as a micro instance. You can also automate this process by writing scripts using AWS APIs.
In case you're using an EBS-backed AMI you don't have to create a new image and launch it. Just stop the machine and issue a simple EC2 API command to change the instance type:
ec2-modify-instance-attribute --instance-type <instance_type> <instance_id>
Keep in mind that not all instance types work for every AMI. The applicable instance types depend on the machine itself and the kernel. You can find a list of available instance types here: http://aws.amazon.com/ec2/instance-types/