First of all, let’s assume you have the following files with you:
- yourdomain.key Your domain’s private Key
- yourdomain.crt Your domain’s public Key
- sf_bundle.crt The Certificate Chain
Step 1 – Preparing the files
Create a PEM-encoded version of your private key
openssl rsa -in yourdomain.key -outform PEM -out yourdomain.pem
Step 2 – Setting the certificate on Amazon
On your Amazon account go to Load Balancers > Your Load Balencer > Listeners
Load Balencer Protocol: HTTPS
Load Balencer Port: 443
Instance Protocol: HTTP
Instance Port: 80
Certificate Name: Yourdomain.com
Private Key: <past yourdomain.pem file here>
Public Key Certificate: <past yourdomain.crt file here>
Certificate Chain: <past sf_bundle.crt file here>
Note: This means every request to the Load Balancer will be made on HTTPS. The traffic from the Load Balancer to the destiny instance will be regular HTTP. This way you don’t have to setup any certificate on your instance’s Apache/Nginx web server.
Step 3 – Test
If everything went as expected you should be able to open https://yourdomain.com.
Now, use a SSL check tool to see if everything is OK: http://www.sslshopper.com/ssl-checker.html#hostname=https://yourdomain.com
You should see something like this:
So you wanna move your domain from, let’s say GoDaddy to AWS Route53 , and you need to test if AWS Route53 is replying correctly to your requests.
If the reply pleases you go ahead and change your name server information in your registrar.
If you want to know the instance-id, run the following command while connected via ssh:
curl http://169.254.169.254/latest/meta-data/instance-id && echo " "
Amazon EC2 is spread across several regions in the globe (US/Virginia, US/Oregon, US/North California, Europe/Ireland, Asia/Singapore, Asia/Tokyo, Asia Pacific/Sidney, South America/S. Paulo). Some of these regions are very recent (Tokyo, Sidney and also S. Paulo).
To support our Brazil operations we have a set of servers setup on Amazon. Some of them were created prior to the launch of S. Paulo region on Amazon or were created from a Amazon Marketplace image that was not available on S. Paulo region.
We’re in the process of optimizing our infrastructure and it makes sense to move Brazil dedicated servers to S. Paulo region. One of them we had to move from US/Virginia to S.Paulo was a EC2 server based on Ubuntu 12.0.4 LTS (different than the standard image for Amazon EC2, Amazon Machine Image Linux).
Amazon recently released a new feature for EC2 that is key to this process. The new feature is the ability to copy EBS snapshots between regions.
So, to move a Ubuntu 12.0.4 LTS EC2 instance from US/Virginia to South America/S. Paulo you need to:
-Stop the machine on US/Virginia – only to make sure no changes are done to the filesystem
-Create a snapshot of the EBS volume attached to the machine on U/Virginia – Go to the Volumes page, identify the volume that is attached to the machine and do the snapshot. If there are multiple volumes attached to the EC2 instance, create a snapshot for each volume. Important: Take note of the size of EC2 instance root volume. It will be required later.
-On the Snapshot list, for each snapshot that you have created, press “Copy” on the toolbar and select South America/S. Paulo as the destination. This operation may take some time depending on the snapshots size. 10 Gb took less than 30 minutes in our case.
-Now selecting South America/S.Paulo in the EC2 management console, press “Launch Instance” to create a new EC2 instance and select “Classic Wizard”
-Choose Ubuntu 12.0.4.x LTS as the type of instance you need (this was the type of our original EC2 instance, it should work with other non-AMI instances).
-When selecting the root volume type and size, make sure you select the same size as the root volume size of the original instance. Select the key pairs and the availability zone as you wish. Take note of the availability zone where the EC2 machine was launched.
-When the snapshot that you copied from the original region (root volume) is available on the new region, create a new volume for the snapshot. Make sure you select the same availability zone where the new EC2 instance was created.
-Stop the new EC2 machine.
-Go to the volumes list, check the volume that is currently attached to the new instance (this is a completely new volume without the data from the original machine that you want to migrate) and choose “Force detach”
-Now select the volume you created from the snapshot of the EC2 original machine root volume and attach to the newly created EC2 instance. Choose the same device as the previous volume that was attached (normally /dev/sda1)
-Create volumes (in the correct availability zone) for the remaining snapshots you want to carry forward from the original machine (in our case, we didn’t have any) and attach to the new machine,.
-Start the machine on South America/S. Paulo.
Then, don’t forget to update your DNS records and monitoring alert applications (e.g. Nagios) to point to the new IP address of the machine.
Amazon’s LB has a health-check feature that will try a GET call to the first vhost that you have on your instances. (alphabetically ordered)
So, if by a chance, the first vhost “aa.example.com.conf” isn’t replying properly to the LB’s GET, your LB will consider that instance off service, which means none of the other vhosts will be serving until you fix whatever is wrong with that first vhost, even if all the other vhosts are working perfectly.