In the start when I was new to aws I was not knowing that how much the selection of regions impact the performance of the system. At that time I created my ec2 and rds instances in sydney but the system will be used in Mexico which is 14000+ km away from Sydney.
Now a lot of configurations are done on those instances. Is there any way I can move these instances to another region?
similarly how i can move other configuration like route 53 and elastic ips as well?
It's not possible to move an existing instance to another subnet, Availability Zone, or VPC. Instead, you can manually migrate the instance by creating a new Amazon Machine Image (AMI) from the source instance. Then, launch a new instance using the new AMI in the desired subnet, Availability Zone, or VPC. Finally, you can reassign any Elastic IP addresses from the source instance to the new instance.
More details in: Move an Amazon EC2 instance to another subnet, Availability Zone, or VPC
Related
I have 3 AWS Elastic Beanstalk instances which are running Spring microservices. All microservices are making POST requests to each other and using RDS service for database.
Should I isolate database traffic and microservices traffic into separate subnets?
In case it's a good practice is it possible to assign 2 private network IP's for each subnet for every AWS Elastic Beanstalk instance?
I think you cannot do it using EBS as the instances will auto create and terminate. So you should try to create instances separately and add autoscaling policy on it.
What I usually do is create my EC2 instances in Public subnet and RDS in private subnet and use RDS Security Group and add EC2 instance's Elastic IP, so that all the traffic is going through the EC2 instance and all the traffic coming to EC2 instance is HTTPS coming from ELB.
Adding the below steps as requested:
Ok, So I am assuming you already know a bit about how to create the servers and RDS etc.
Create an EC2 instance for each of your microservices.
Attach an EIP to each of these instances.
Add an Auto-Scaling policy to increase or decrease the instances based on the traffic/CPU Utilization. Make sure you terminate the newest created instance.
Add an ELB for this instance and add HTTPS/SSL certificate to secure your traffic.
Create RDS in a Private subnet and add instance EIP in RDS SG for 3306 port.
I think you should be able to do this then.
It's not a good practice to directly communicate between instances in EB. The reason is that that EB instances run in autoscalling group. So they can be terminated and replaced at any time by AWS leading to change in their private Ip addresses.
The change in IP will break your application sooner or later. Instances in EB should be accessed using Load Balancer or private IP.
So if you have some instances that are meant for private access only you could separate them to internal EB environment.
We have an AWS account with multiple EC2 instances and an RDS instance. These have been running since before VPCs were introduced. Now I need to upgrade the RDS instance class and the new class can only be established in a VPC. So if our RDS instance is modified (converted) into the new class and the new RDS instance is in a VPC will the EC2 instances that use this RDS need to be moved into the VPC at the same time or can this be a separate process?
RDS and EC2 security groups are not cross-compatible between classic and vpc EC2. If you have an RDS with an EC2 sec group reference you will not be able to add a classic ec2 sec group to your vpc RDS sec group.
Differences Between Security Groups for EC2-Classic and EC2-VPC
Your best bet is to migrate your EC2 infrastructure to VPC along with your RDS. You can of course grant global access to your RDS if you want to separate the process and then lock it back down when you've migrated your EC2 infrastructure but this is a big no no (huge security risk).
This is a non trivial process and I feel your pain. The least complex thing is to incur downtime during migration so that you don't have divergence between RDS instances. But that's not ideal especially when you have a large RDS storage-wise. BTW, you will want to test how long the process takes to snapshot and restore the RDS since it might take a while.
An alternative if you can manage it is to force your app to use read-only replicas while you migrate the RDS. That way your app can still function (kind of) and you won't have to worry about reconciliation between RDS instances post-migration. But obviously your app needs to be aware that it's in read-only mode or you'll end up with erratic behavior.
Forgot to mention there is something called classic-link which might help here but I've personally never used classic-link. Check it out in an AWS whitepaper write up here:
Move Amazon RDS MySQL
Databases to Amazon VPC
using Amazon EC2
ClassicLink and Read
Replicas
Can we launch an instance in multiple region in AWS? I know the concept of Elastic IP or taking a snapshot or copying an IAM. Can we do this in other regions without minimal downtime?
It's not possible to launch an EC2 instance in multiple regions. An EC2 instance can only exist in a single availability zone, in a single region.
You can launch multiple copies of your AMI images (EC2 instances) in multiple availability zones, in multiple regions.
Once you have your EC2 instance running in a single availability zones, you can create an AMI image from that EC2 instance and launch copies in other availability zones in the same region. Creating an AMI doesn't have to cause downtime, however, it is recommended to stop the EC2 instance while the AMI image is created. So best to create the AMI image before the EC2 instance needs to be up 100% of the time.
You can also copy that AMI from the original region to another region. Once copied, you can launch new EC2 instances in that second region.
Elastic IP addresses can only be attached to a single EC2 instance in a single region at a time. It is not possible to move or copy Elastic IP addresses between regions.
How Can I change instance EC2 from Oregon to Virginia? Is there any form by console? I have one Instance RDS and one Instance EC2.
Take a snapshot of the RDS instance, and either a snapshot of your EBS volume(s) on EC2, or create an AMI from your EC2 instance.
Move the snapshot(s) and AMI to the new region.
Create a new RDS instance in the new region using the RDS snapshot you copied there.
Create a new EC2 instance in the new region from the AMI or EBS snapshots you copied there.
Update your application on your new EC2 instance to point to the new RDS location.
Move any DNS entries or Elastic IP addresses to point to the new servers and shut down the old ones.
I am rather lost how to implement AWS auto scaling in my usage scenarion?
I have an EC2 instance with elastic IP, in VPC as my webserver . This elastic IP is mapped to my website address in R53. Now if I create auto scaling group with the same AMI, which I used to create my first ec2 instance, with say two instances, then two new instances are created with new IP addresses. How these new instances can share the traffic?
If I delete the original instance, and use IP address of one of these instances in R53, how can I ensure that this perticular instance whose IP address I am using in R53, will survive after scale down?
Look into creating an Elastic Load Balancer (ELB):
http://aws.amazon.com/elasticloadbalancing/
The DNS record for your site will point to the ELB, and the ELB will spread the traffic between all the instances. When an instance is created or destroyed in an ASG, it will automatically register or de-register from the ELB.
You don't need their ELB to use autoscale, but you do need some sort of load balancer to perform that distribution. It can be an instance that you create in the VPC on an EC2 instance(s). It seems to be a little tough to identify the "must haves" and prescriptive architecture elements (or reference architectures) vs the wide range of alternative solutions.