I need to save data in a single table for later reference. The volume will not be more than 1000 per day and there will not be any joins. The DB will contain only single table.
I do not want to create on Amazon RDS as the cost is high for my corporation and also the connectivity between EC2 and RDS will require approvals and will take time.
I have root access, so is there a DB I can create on EC2 on any port which my web app running on port 80 can use?
Just access the EC2 instance via SSH and install a mySQL database.
Guide for Ubuntu, but should work for Amazon Linux as well:
https://support.rackspace.com/how-to/installing-mysql-server-on-ubuntu/
However, if it is that low volume, you may want to check out DynamoDB. That may be a much more cost-effective (and easier to maintain) solution
If you have ssh access and root permissions then you can install any community edition of databases.
For an RDBMS, mysql can be an easier choice
For a noSQL DB, mongoDB is quite easy to setup
Can some one please advise the steps required for migrating a web application which is currently running on tomcat server at onpremise to AWS ec2 instance. I understand this is not a straight forward and requires some detailed process.
The code is wrriten in Java and database used as oracle.
So it would be helpfull if someone can suggest me any relavent document or any website which gives some demo to refer me and proceed with this scenario.
If it's a personal project then I would recommend Lightsail as the simplest way to deploy existing Java application.
For a database a small instance of MySQL or if relational database is not needed then a document database like DynamoDB. https://aws.amazon.com/products/databases/?nc2=h_m1
There are multiple choices one how to migrate a Java application to AWS.
You could potentially use existing AWS services like:
Lightsail - https://aws.amazon.com/lightsail/
Beanstock - https://aws.amazon.com/elasticbeanstalk/
or
EC2 instance and install Tomcat manually
Use ECS with Docker https://aws.amazon.com/getting-started/tutorials/deploy-docker-containers/?nc2=type_a
As for Database solution Oracle is an option but quite expensive one.
When moving to AWS it's better to use one of the RDS managed databases like MySQL, Postgress or more expensive like Aurora.
In order to propose an architecture some details would be needed on predicted load, the size of the application and volume of data. Is the product regional or global, are there any additional issues that need to be addressed while moving to a cloud (performance, availability etc), how users are authenticated (are any other services needed).
As my website is going to AWS, can SQL Server 2008 R2 be imported to Amazon RDS for SQL Server ?
Appreciate if anyone can provide some guideline or any limitation . Thank You
Backup and restore for Microsoft SQL Server databases can be done using full backup files (.bak files) in Amazon RDS service. You can create a full backup from your local server, store it on S3, and then restore it onto an existing Amazon RDS DB instance.
Limitations and Recommendations as given by AWS are as follows:
The following are some limitations to using native backup and restore:
You can't back up to, or restore from, an Amazon S3 bucket in a different AWS Region than your Amazon RDS DB instance.
We strongly recommend that you don't restore backups from one time zone to a different time zone. If you restore backups from one time zone to a different time zone, you must audit your queries and applications for the effects of the time zone change.
Native backups of databases larger than 1 TB are not supported.
RDS supports native restores of databases up to 5 TB. Native restores of databases on SQL Server Express are limited by the
MSSQL edition to 10 GB or less.
You can't do a native backup during the maintenance window, or any time Amazon RDS is in the process of taking a snapshot of the database.
On Multi-AZ DB instances, you can only natively restore databases that are backed up in full recovery model.
Calling the RDS procedures for native backup and restore within a transaction is not supported.
Native backup files are encrypted with the specified AWS Key Management Service key using the "Encryption-Only" crypto mode.
When you are restoring encrypted backup files, be aware that they
were encrypted with the "Encryption-Only" crypto mode.
You can refer to this link for more details on migration.
Using AWS Aurora database service - you can configure master-slave replication and slave autoscaling (e.g. if slave CPU is higher than 75 percent - create a second slave).
Newly created database has a new endpoint (host) which is not registered by django yet.
What would be the best approach to firstly discover the newly created database and add it to a running django application?
I am thinking about pinging every X seconds using, lets say, aws cli and checking how many slaves are there. But the problem with this is if a slave is destroyed by an autoscaling group - my django application would start erroring, so an appropriate handling is also required...
You shouldn't be configuring each read replica's endpoint with django. You should configure it to use the reader endpoint provided by Aurora, which will load-balance the requests across all read replicas in the cluster. Then when a new read replica is added to the cluster django will automatically be using it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
We have a web application on Windows Server and SQL Server and want to move it to Amazon AWS.
We will have an EC2 Windows Server running IIS but we have a question about if it better to have an RDS SQL Server database or if we should better have an EC2 bundled with SQL Server.
For performance and replication what do you recommend?
I appreciate your help.
We recently migrated a SQL database with some deadlock issues to AWS and looked carefully at AWS -- it was not a match for us due to a huge performance risk vis a vis deadlocks, so we went with EC2 instances. The users have been very happy with the performance.
From a performance perspective, Amazon's provisioned IOPS features are excellent, and these are available on both RDS and on the EC2 server instances. RDS also has killer automated backup capabilities. It's truly a set up and forget type of system.
AWS RDS does not support SQL Server replication. If your intent is to replicate something from your site to the AWS instance, then your options are to use a Windows Server base instance with your own SQL Server ISO/license, or to use a pricier EC2 AMI based on SQL Server. RDS has its own replication system that will support replication to another RDS instance (even on a different availability zone) to increase resilience or automate failover. With RDS you could also roll your own site to cloud snapshot replication by using bcp on prem, but that might require you to alter your application or schema.
A couple of advantages we found to using an EC2 instance over RDS:
With an EC2 instance, you get sysadmin on the database instance and administrator on the underlying Windows Server. RDS does not allow this, and in fact, with RDS you lose access to the shell and to the underlying Windows Server administration tools. This means that you cut out some basic tools for performance management: System Monitor, tracerpt.exe, Windows System Resource Manager, etc.
With an EC2 instance, you can use SQL Server Agent to run jobs that include command line or powershell scripts. RDS does not allow this.
Assuming your IIS is on one EC2 instance and SQL on another EC2 vs RDS...
RDS performance vs EC2 performance vs price seems fluid but there is one major impact for Microsoft SQL Server users and RDS that may help you decide.
You can not use Backup / Restore to move DBs in and out of RDS.
If this matters, EC2 is the only way to go.
Of course, there are a number of options other than Backup / Restore including a decent data migration designed to work with Azure that also works with RDS but it often fails for some complex environments.
Its clearly best practice to keep the DB and web layer on separate machines, so an EC2 instance for your IIS and RDS for the database would work fine.
You could also use 2 EC2 instances, one for IIS and one for the DB - that will also work.
RDS is probably the best option, if you don't take into account price - without knowing the traffic on your site, how important the DB is (i.e. could you afford to be down for 8 hours? could you afford to lose the last 15 minutes worth of db changes etc), there is no right answer...your budget and your requirements will be the deciding factors...
All that said, I have some low traffic sites that run with IIS and SQL Server express on a single EC2 instance, and they run just fine - and is very affordable and easy way to get on AWS, with the option of improving that config as your budget allows and traffic dictates.
Answering after experiencing both -
if all new development -fresh database(no production level data) - no need to think and just go with RDS.
But if working with existing application and database. easiest way is SqlServer Instance on EC2. this will save you lot of hassle of datatype errors not supported by RDS.
Moving existing Data to RDS can be a big pain. i learned my lesson by hard way. And end up using ec2 sql server instance.
Have a look at the AWS Architecture Center. The Web Application Hosting datasheet fits your scenario. Deploying each application layer to a suitable infrastructure service will help you building a reliable and performant application.
You have to definitely go with RDS. Moving existing data to RDS used to be a big pain for us too, before we found the Cloudbasic SQL RDS AlwaysOn tool on the AWS Marketplace:
https://aws.amazon.com/marketplace/pp/B00OU0PE5M/ref=_ptnr_blg_’blg4’
This tool was designed to continuously geo-replicate RDS from one region to another for HA/DR and reporting. But it can also be used for moving data in and out of RDS. The best part is, it supports DB instance replication for SQL Server Web Edition. You can even replicate from SQL Standard to Web edition, from SQL 2008 to 2014 etc.
Another reason RDS is recommended over EC2 with SQL Server is the Multi-AZ HA feature. However note that it works for the pricey Standard and Enterprise editions only, and the replica is not accessible (it is for mySQL and oracle, but is not for SQL Server). It cannot be used for reporting. You just know it is there but cannot actually access it. And Multi-AZ works within the AWS region only. If you are fine with the cost and the limitations, it is definitely recommended. Alternatively you can use the Cloudbasic tool to continuously replicate RDS SQL Web edition from i.e. your primary AWS Virginia RDS to RDS in Oregon for reporting and DR. And it costs a lot less compared to RDS Multi-AZ with SQL Standard.