I hope you can provide a quick response to my question.
Is it possible to create auto scaling group which spans across regions ? Consider this scenario - Lets say all the availability zones in west are unavailabe. Can we configure auto scaling so that if the instance in US.West are down, create an instance in east zone ?
I dont think it is possible, because we need to specify the region for AWS_AUTO_SCALING_URL while using Command line scripts, which restricts the creation of launch configs, auto scaling group within that region only.
So we can only hope all the AZ's in that region are not down or move to VPC is that right ?
Elastic load balancing and Elastic IP are both region specific, I would assume that auto scaling is region specific and only between the availability zones in that region. The white paper on building fault tolerant applications doesn't explicitly state that you could auto-scale across regions but it does say that you can across zones.
"Auto Scaling can work across multiple Availability Zones in an AWS Region, making it easier to automate increasing and
decreasing of capacity."
I would believe if they supported multi-region, they would explicitly say so.
Thinking about this further, I'm not so sure it's even a good idea to auto-scale across regions. Auto-scale is more geared for a specific tier of your application.
For example, if a region was to go down, you would not want some of your web servers to use services across a slow link to another region (potentially) across the country.
Instead you would want route 53 to route the traffic to an autonomous stack running it's own auto-scaled layers in a separate region.
see this hosting chart everything from ELB down is region specific.
An Auto Scaling group can contain EC2 instances from multiple Availability Zones within the same region. However, an Auto Scaling group can't contain EC2 instances from multiple regions.
Read Note in this AWS Document
EC2 Auto Scaling groups are regional constructs. They can span Availability Zones, but not AWS regions.
PS. AWS Documentation
https://aws.amazon.com/ec2/autoscaling/faqs/
Related
Is it possible to have ASG as a DR between two AZ? For example, I have 5 instance in AZ1 servicing requests. During the AZ outage, I wanted to spin-up the 5 Instances in AZ2 and serve the request. Is it possible to control the isntance spinning up in AZ2 if only AZ1 Fails ?
You can use AWS AutoScaling across multiple AZ, but only in a specific Region.
"Auto Scaling can work across multiple Availability Zones in an AWS
Region, making it easier to automate increasing and decreasing of
capacity."
If you are trying to have high availability you can use aws global services like AWS CloudFront or AWS Global Accelerator. Example Scenario:
Currently, we have running our application in one of AWS Region/data centers. Are there any strategies or principles we can follow to extends our application to another data center?
How we can quickly bring up the same or minimum set of services/AWS-stack to another region quickly?
Do any trade-offs need to be considered?
Current AWS resources in existing DC: EC2, S3, Dynamodb, RDS, VPC, security groups, ELB, Lambda, API G/W
All of the services you have listed (except for Amazon EC2) automatically run across multiple Availability Zones within the Region. This means that, if an AZ fails, those services are not impacted.
An Availability Zone is a physically separate data center within the Region. It is sufficiently distant and has different networking such that a failure in one AZ should not impact another AZ. Running your services across multiple AZs should be sufficient for high-availability rather than running across multiple Regions.
Each Amazon EC2 instance, however, resides in only one AZ since it is a virtual machine running on a single host computer. To make your application highly-available, you should:
Run EC2 across at least two AZs
Configure the Elastic Load Balancer to distribute traffic across all of those instances
This way, if an AZ fails and the EC2 instances in that AZ are not available, the app will continue to run in the other AZs.
Amazon RDS offers multi-AZ capabilities if you choose 'multi-AZ' when launching the database. This will run a primary database in one AZ and a secondary database in another AZ. If the primary AZ fails, the secondary database will take over. The data is automatically replicated to the secondary database, so no data will be lost. (Extra charges apply for this feature.)
There is lots of information available online on this topic. Just search for "aws multiple AZs".
A workload in an Amazon VPC consist of a single web-server launched from a custom AMI.Session state is stored in database. How should the Solutions Architect modify this workload to be both highly available and scalable?
I am hesitating between A and C. Lots of my friends, including me, prefer C. But why the answer is A from an unofficial testing agency? Is the agency wrong?
A. Create a launch configuration with a desired capacity of two web servers across multiple Availability Zones. Create an Auto Scaling group with the AMI ID of the web server image. Use Amazon Route 53 latency-based routing to balance traffic across the Auto Scaling group.
B. Create a launch configuration with the AMI ID of the web server image. Create an Auto Scaling group using the newly-created launch configuration, and a desired capacity of two web servers across multiple regions. Use an Application Load Balancer (ALB) to balance traffic across the Auto Scaling group.
C. Create a launch configuration with the AMI ID of the web server image. Create an Auto Scaling group using the newly-created launch configuration, and a desired capacity of two web servers across multiple Availability Zones. Use an ALB to balance traffic across the Auto Scaling group.
D.Create a launch configuration with the AMI ID of the web server image. Create an Auto Scaling group using the newly-created launch configuration, and a desired capacity of two web servers across multiple Availability Zones. Use Route 53 weighted routing to balance traffic across the Auto Scaling group.
Choice A cannot be correct. Where did you see this question (and answer)?
This question requires knowledge of how Auto Scaling (AS) works:
AS launch configurations have an AMI id
AS groups have desired capacity and a launch configuration
AS groups contain EC2 instances from multiple AZs within a region, but not multiple regions
So, applying that knowledge to the available choices:
A is incorrect because a launch configuration does not have a desired capacity
B is incorrect because AS groups are cross AZ, not cross region
So, the only possible correct choices are C and D. At that point you need to decide if cross-AZ ALB is correct vs Route 53 weighted routing.
Is this an exam question??
The Correct answer is C.
The architecture is like Internet->Route53 (points to ALB Endpoint)->ALB->ASG Instances
The other choices cannot be correct
A) This statement is wrong. It doesn't make any sense to use latency based routing when you use only one ALB.
B) You cannot use multiple regions in the same Auto Scaling Group.
D) Same as A
As a newbie to AWS concepts, I am trying to understand ASG concept.
a) Does it work per region or per Availability Zones?
b) Do I need to have an ASG for each Availability zone, or it can scale up and down the instances from different AZs on a shared region?
You can have an autoscale group work across availability zones, but not across regions.
Though it is possible to have an ASG in a single AZ, you would certainly want the ASG to be in multiple AZ's, otherwise you have no real fault tolerance in the case where an AZ has problems.
my aws auto-scaled instances are not picked up by load-balancer and the auto-scaled instances are recreated frequently,
also is there any problem in using auto-scaled instances and static instances at the same time in aws ELB ?
what are the precautions to take when doing so if it is possible
is there any disadvantages doing so ?
Need to make sure that your autoscaling group is registered with the load balancer appropriately, and that you have the appropriate policies. Really need more details to answer this though.
Don't do it. If you need an instance to be running all the time, configure your group to have a minimum of the number of "static" instances. If you need to run a "static" instance, and a scaling group - you're probably thinking about the problem the wrong way.
One reason could be: If you have configured your autoscaling group for multiple availability zones, but those zones are not added to the associated load balancer. In Management Console, go to Load Balancers -> Instances and verify Availability Zones.
I would go with #Peter H. Modify your design so you don't depend on any particular instance for persistent data. Store persistent data externally in a database or on S3.