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.
Related
I have an EC2 instance which hosts a windows service, .net API and a simple .net website. There's also the added complication of a Route 53 endpoint pointing to it and an https cert being allocated via Amazon certificate manager. Yes, it's a lot of apps on a single instance and I will look at separating them later. I got a message from AWS saying that due to the underlying infrastructure becoming unstable, they'll need to terminate the instance in a week.
Lot of options come to mind, none of which I've tried before or know much about. These options include spinning up another instance, backing up and restoring this instance on to the new one. OR using AWS elastic beanstalk or something to automate the infrastructure setup and code deployment. Which of these (or another) options is most feasible and quick to get working and where should I start looking?
If it's just the instance, I'd go for an EBS snapshot and then restore the ec2 instance from it. Finally, swap the IP in Route 53.
It's a relatively quick and rather straight-forward process, that's well documented by AWS and there are loads of how-to's on the Web too.
Here's where to start:
Create Amazon EBS Snapshot
and here's how to restore it.
On the other hand, you could go for a .Net app on Elastic Beanstalk but that requires a bit more work to set up the environment and prepare the app for deployment.
More on how to create and deploy .NET on Elastic Beanstalk.
I've been tasked with getting a new SSL installed on a website, the site is hosted on AWS EC2.
I've discovered that I need the key pair in order to connect to the server instance, however the client doesn't have contact with the former web master.
I don't have much familiarity with AWS so I'm somewhat at a loss of how to proceed. I'm guessing I would need the old key pair to access the server instance and install the SSL?
I see there's also the Certificate Manager section in AWS, but don't currently see an SSL in there. Will installing it here attach it to the website or do I need to access the server instance and install it there?
There is a documented process for updating the SSH keys on an EC2 instance. However, this will require some downtime, and must not be run on an instance-store-backed instance. If you're new to AWS then you might not be able to determine whether this is the case, so would be risky.
Instead, I think your best option is to bring up an Elastic Load Balancer to be the new front-end for the application: clients will connect to it, and it will in turn connect to the application instance. You can attach an ACM cert to the ELB, and shifting traffic should be a matter of changing the DNS entry (but, of course, test it out first!).
Moving forward, you should redeploy the application to a new EC2 instance, and then point the ELB at this instance. This may be easier said than done, because the old instance is probably manually configured. With luck you have the site in source control, and can do deploys in a test environment.
If not, and you're running on Linux, you'll need to make a snapshot of the live instance and attach it to a different instance to learn how it's configured. Start with the EC2 EBS docs and try it out in a test environment before touching production.
I'm not sure if there's any good way to recover the content from a Windows EC2 instance. And if you're not comfortable with doing ops, you should find someone who is.
Can an AWS Elastic Load Balancer be setup so it sends all traffic to a main server and if that server fails, only then send traffic to a second server.
Have an existing web app I picked up that was never built to run on multiple servers and the client has become worried about redundancy. They don't want to invest enough to make it run well across multiple servers so I was thinking I could setup a second EC2 server with a MySQL slave and periodically copy files from the primary server to the secondary using rsync. Then have an AWS ELB send traffic to the primary server and only if that fails send it to the second server.
AWS load balancers don't support "backup" nodes that only take traffic when the primary is down.
Beyond that, you are proposing a complicated scenario.
was thinking I could setup a second EC2 server with a MySQL slave
If you do that, you can only fail over once, then you can't fail back, because the master database will then be obsolete. For a configuration like this to work and be useful, your two MySQL servers need to be configured with master/master (circular) replication, so that each is a replica of the other. This is an advanced configuration that requires expertise and caution.
For the MySQL component, an RDS instance with multi-AZ enabled will provide you with hands-off fault tolerance of the database.
Of course, the client may be unwilling to pay for this as well.
A reasonable shortcut for small systems might be EC2 instance recovery which will bring the site back up if the underlying hardware fails. This feature replaces a failed instance with a new instance, reattaches the EBS volumes, and starts it back up. If the system is stable and you have a solid backup strategy for all data, this might be sufficient. Effective redundancy as a retrofit is non-trivial.
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 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.