Currently I have hosted 150+ sites in one AWS EC2 instance. And continuously I am adding more websites, approximate 10 to 15 websites per month. So I need suggestion for this. One EC2 instance is good or I need to divide it in multiple EC2 instances. And another thing EC2 auto scaling is good for this or not ?. I can't use beanstalk due to the limitation.
Depends on what you mean by 'good'.
Good for your wallet is to host them all on a single ec2 instance, in a single region and hope that singe instance (or AZ) doesn't go down or have problems.
Good for uptime would be to host all of the websites together on multiple ec2 instances, across multiple AZ's and use a load balancer to distribute traffic across several identical instances.
Better for uptime and performance would be multiple larger ec2 instances in multiple AZ's behind a load balancer
Best for uptime, performance and your wallet would mean multiple smaller ec2 instances, behind a load balancer and with autoscaling enabled to bring up (and turn off) instances depending on traffic load.
Besides the above, you can also offload some of your static assets (css, js, images etc) to an s3 bucket which should save some $$ and reduce the load on your web servers (thus needing smaller or less of them) and then put cloudfront in front of everything to cache assets/pages closer to your end users.
So lots of options, but what you are doing now is perhaps a bit risky.
If you are looking on a perspective of cost saving I would suggest to go with docker and ECS. Since you are adding multiple websites there's a chance some of the websites will have more or less load. Use ECS tasks along with application load balancer and autoscaling group. You'll have reliability and separation between applications.
Related
So basically I have this EC2 Linux Instance with 8GB memory and I am having multiple applications running on it. It doesn't happen often, but when there is huge traffic, 8GB memory isn't enough, and the whole instance stops responding. To make things work like normal, I have to reboot the instance every time.
I have heard that Elastic Load Balancing might scale the memory as required. But how to achieve that? Is there any other way to solve my problem? Is there a tutorial that'd guide me through this?
I have heard that Elastic Load Balancing might scale the memory
ELB does not scale a memory of your instance. Instead it can distribute your connections among multiple instances. Thus, instead of having one instance which servers all your traffic, you would have two or more. In this setup, ELB would distribute traffic equally among your instances, so that collectively they can server more connections then a single instance.
What's more you usually use ELB with autoscaling so that the number of instances is adjusted automatically up and down, depending on the incoming traffic.
Is there a tutorial that'd guide me through this?
You can start with offical AWS tutorial Set up a scaled and load-balanced application .
The title might be a little too much, but i am unable to find any statements regarding this. I am trying to set up computes in multiple AZ's (in a region) with auto-scaling. i am also trying to see if i can get away with only one ELB to do the load balancing act.
In this setup, the ELB is a single point of failure so, I would like to know, if anyone knows the recovery associated with ELB's. There are documentations about scaling in ELB but not the recovery/higher availability.
thanks
Make sure you select multiple AZs for the load balancer as well. You will have to in order for it to work with EC2 instances in multiple AZs anyway. When you do that, multiple ELB instances are created for you behind the scenes, one in each AZ. So the ELB isn't really a "single point of failure".
The most common issue you may see with an ELB is if you have a very quick, large burst of traffic, which will take the ELB a few minutes to scale up to meet the demand. If you know ahead of time you will be getting a large increase in traffic you can send a request to AWS support to pre-warm the ELB for you.
I recommend reading the section titled "Common Pitfalls When Testing Elastic Load Balancing" in this article.
An ELB is a logical entity that consists of multiple (at least 2 - one per AZ - and generally more) instances that route traffic to your back ends.
If an individual ELB instance were to fail, it would be replaced automatically, much in the way autoscaling replaces failed instances.
You can usually tell how many instances are in your ELB by doing a DNS lookup - you will see multiple IP addresses returned.
ELBs can become overloaded if you have a sudden burst of traffic, so they are not failure proof, but for most loads they do a very good job.
Right now our small-ish business has 3 clients who we have assigned to 3 elastic IPs in Amazon Web Services (AWS).
If we restart an instance no one loses access because the IPs are the same after restart.
Is there a way to handle expanding to 3 more clients without having things fall apart if there's a restart?
I'm trying to request more IPs, but they suggest it depends on our architecture, and I'm not sure what architecture they're looking for (or why some would warrant more elastic IPs than others or if this is an unchecked suggestion box).
I realize this is a very basic question, but googling around only gets me uninformative docs from the vendors mouth.
EDIT:
There is a lot of content on the interwebs (mostly old) about AWS supporting IPv6, but that functionality appears to be deprecated.
You can request more EIPs in the short run. Up to 5 EIP is free depending on your account. You should also considering using name based URLs and assign each of your clients to a subdomain, for example,
clientA.example.com
clientB.example.com
clientC.example.com
This way you will not be needing an additional IP for every client you add. Depending on your traffic, one EC2 instance can serve many clients, and as you scale, you can put multiple EC2 instances behind an AWS Elastic Load Balaner, and this will scale to serve exponentially more clients.
If the client wants to keep their servers separate and can pay for them, you can purchase EIP as many as you need. You should also consider separating database into one database instance for each client, which is probably what clients desire more than separation of IPs.
For IPv6, a quick workaround would be to use a front-end ELB that supports both IPv6 and IPv4.
If you use elastic IPs from VPC, you get 5 per region for an AWS account. See Amazon VPC Limits.
So, you can go to console and select VPC. Then click on elastic IPs, create it. Once created, assign it to a relevant instance.
So, atleast for now, you can solve the problem if you are not bothered about region.
Please tell me what are the risk mitigation features to consider when choosing a cloud service provider for an organization? Reliability seems to be an issue considering Nirvanix's shut down and Amazon's outage in August 2013. Thank You.
-Nandhini
Quite the open-ended question, I'm sure just about everyone could spend weeks about risk mitigation. There are many procedures put in place and using Amazon as a provider I'll go through a few.
Amazon has a plethora of tools for disaster recovery, redundancy and general good practise for the Cloud Environment but it is totally up to you if you choose to use them. Let's take Availability Zones as an example.
In each AWS Region (a location where their datacentres are held) they have what they call Availability Zones which are completely separated datacentres in order to improve redundancy. An entire AZ could go offline and not affect the other AZ. A well executed Cloud migration strategy would utilise several of the following:
Spread of all necessary VMs, appliances, databases etc. spread evenly over a single or multiple geographic region
Utilising auto-scaling groups to allow rapid increase of Infrastructure of a single AZ in case of massive outage in another AZ (also good for flash traffic or periods of high server loads)
Utilising Route 53 DNS records to automatically re-route traffic through to nearby Elastic Load Balancers, thus causing your site to have near-zero downtime through an AZ failure as traffic switches over to a new Region or AZ in milliseconds (done at the Amazon level so no waiting for TTL DNS changes)
Elastic Load Balancers in general to near automatically place newly spun VMs straight into serving traffic
Managed Relational Database Service can place a warm back-up in another AZ in a single Region, instantly spin up multiple Read Replicas and second level Read Replicas
I could go on for days but for a service like AWS with a properly implemented Cloud Strategy they offer a plethora of services and techniques (their white papers at http://aws.amazon.com/whitepapers/ allow you to get your feet wet in Security and Deployment)
Is it possible to have most of our server hardware outside of EC2, but with some kind of load balancer to divert traffic to EC2 when there's load that our servers can't handle, or as a backup incase these servers go down?
For example, have a physical server serving out our service (let's ignore database consistency for the moment), but there's a huge spike due to some coolness - can we spin up some EC2 instances and divert traffic off to it? This is much like Amazon's own auto scaling.
And also, if our server hardware dies for some reason (gremlins eat the power cables for example) - can we route all our traffic over to EC2 instances?
Thanks
Yes you can but you will have to code. AWS has Command Line Tools for doing EC2/Autoscaling/S3 stuff with simple commands in bash or other interfaces and SDKs, like Boto for Python etc.
You can find it here: http://aws.amazon.com/code/
Each Ec2 instance has a public network interface associated with it. Use a DNS CNAME record to "switch" your site traffic to the Ec2 instance. If you need to load-balance across multiple machines you can use round-robin DNS, or start a ELB and put any number of Ec2 instances behind it.
Ec2 infrastructure is extremely easy to scale. Deploying your application on top of an Ec2 is a whole other matter. It could be trivial -- or insanely complicated.