AWS

1. Log into the console

2. Ensure you’re in the closes region

3. Open EC2 Section

4. Launch Instance

5. Choose you AMI (VM) - Probably the Amazon Linux AMI

Different Virtual Machine Types are available: (PV) Paravirtual, (HVM) Hardware Virtual Machine

6. Choose Instance Type i.e. t2 Micro

7. Configure Instance Details

• Request spot instances and configure them or use on-demand instances
• Network uses default VPC in all regions
• Choose your subnet (1 subnet= 1 availability zone)
• Auto-assign Public IP will use the subset provided by default
• Choose IAM role (previously set up)
• Choose shutdown behaviour (either stop or terminate)
• Enable termination protection (Not enabled by default)
• Monitoring (Can enable detailed monitoring by CloudWatch at a cost - basic is enabled by default)
• Tenancy - determines whether the instance is run on a shared or dedicated host
• Advanced Details: User Data - (Not compulsory) This is where you can opt to automatically run scripts on provisioning. An example to target the path and run updates would be:
  

#!bash/bin

yum update -y

8. Add Storage - EBS (Elastic Block Storage) Volume Type is Root, meaning that it is where the operating system is installed.

Delete on termination is selected by default which will also delete the EBS volume.

The root volume (where the O/S is installed) is not encrypted by default and that cannot be changed. Additional volumes, however, can be encrypted

9. Tag Instances - Always a key-val pair. Can have up to 10 keys per EC2, can be useful later on for resource tagging/ billing purposes and seeing what is allocated to which resources

10. Configure Security Groups - kind of like a virtual firewall.

Create a new security group

Create rules for SSH and HTTP (automatically detects port range) & select a source option (port from anywhere/my IP/Custom IP)

11.  Review and Launch - allows you to Select an existing key pair or create a new one

• Create a New key pair
• Give it an appropriate name and download your private key
• Launch instances

12. View instances - can take up about a minute to finish launching

13. Open your terminal

• Open terminal
• Navigate to your download key that you downloaded when launching your instance
• Change the permissions for your private key $ chmod 600 key pair.pem
• Connect into your Amazon Linus AMI $ ssh c2-user@-i Keypair.pem
• Add authenticity to list of known hosts
• Once connected, elevate privileges to root $ sudo su
• Run an update (if you haven’t set your EC2 to automatically do this) $ yum update -y

14. If you have trouble terminating your instance, it’s because you will need to disable termination protection on your instance.

Create a Windows EC2 Instance with a RAID Group

1. Log into EC2

2. Security Groups

3. Select a security group and under ‘Inbound Rules’ - Add Remote Desktop Protocol (RPD)

4. Back on the dash board, Launch a new Instance

5. Choose Machine Image AMI - Microsoft Windows Server 2012 R2 Base

6. Use a t2 Micro

7. Configure Instance Details

8. Add Storage with 4 additional ABS Volumes which are all SSD and 8GB in size

9. Tag the Instance

10. Add the instance to the security group above which was configured with Inbound RDP

11. Launch Instance with a new key pair and download your private key - Windows VMs typically take longer than Linux to initialise on Cloud infrastructure, including AWS.

12. Log into the Windows VM using RDP, Username: Administrator, Password: comes from AWS platform

• Select the instance
• Under actions, click “Get Windows Password”
• Upload your private key to the pop up window
• Decrypt password

13. To access the windows instance from a mac, Open Microsoft Remote Desktop (downloadable from the app store)

• Create a new connection with the connection name (Pulbic IP), username and password
• Click on connect
• Click continue on the “Verify Certificate” pop-up (Can take a while to establish the session)

14. Now in the Windows session, you can use the windows desktop

• Click on Start => “Disk Management”
• You can see Disk 1-4 which represent the seperate EBS volumes previously created. Right click and delete all of them.
• Right click on the first unallocated volume and slept “Create New Striped Volume” which is effectively a RAID-0
• Follow the set up wizard and add all available disks
• Assign the new volume to drive “D” and select “Perform a quick format”

1. Log into console

2. Select s3 - Under Storage, content and Delivery

3. Create a Bucket

4. Bucket Name is a unique namespace globally (regardless of region) and must be lowercase characters only.

* Under permissions you can set permissions and ass bucket policies.
* Can enable static website hosting which turns your bucket into a static website and is infinitely scalable.
* Can enable logging to log all actions on the bucket. Can be logged either to the bucket itself or to another bucket (probably better in terms of security)
* Can trigger events such as an SNS or SQS event or a Lambda function i.e. if someone uploads a file to this bucket.
* Can allow versioning
* Can allow lifecycle rules
* Cross-region replication allows anything uploaded to a bucket to be automatically cross-replicated to another bucket in another region (Versioning must be enabled)
* Tags can be added to buckets which can very helpful when it comes to billing.
* Requester pays means that every time someone else with an AWS account tries to do a request/data transfer from the bucket that person pays. If this function is turned on, it means you cannot have anonymous access to your bucket.

5. To upload new files: Open test bucket => upload => select a file

6. Files uploaded are automatically private but can be made public. All files can be stored in different storage classes within the same bucket.

s3 Versioning

1. Select bucket => properties => Versioning.

2. Once enabled, versioning cannot be disabled. It can only be suspended. The only way to remove it is to delete the bucket and create a new one.

* If you accidentally delete a file, you can restore it by deleting the “delete marker”
* Every version stored in a bucket takes up space, including old and deleted versions.

3. Cross-region Replication is a great way to maintain backups. MUST have versioning enabled on BOTH source and destination buckets.

a) Cross-region replication replicated every FUTURE upload of every object to another bucket. Existing objects will NOT be replicated.

s3 Life Cycle Management

1. Apply a rule to the whole bucket to help manage storage costs.

2. Allows you to automatically move files around i.e. move an object to infrequently accessed bucket 30 days after upload (must wait a minimum of 30 days before it can be moved), move to glacier archival 30 days after that (must wait a minimum of another 30 days before it can be moved) and permanently delete 3 years after that. (Cannot be deleted on the same day as it is moved, must wait a minimum of 1 day after it has been moved).

3. Once versioning is enabled, you have the option to apply different actions to the both the current and previous versions. i.e. you might want to expire the current version 30 days after it is uploaded and permanently delete the previous version 30 days after it becomes the previous version.

The following is a step by step tutorial on how to set up Identity Access management or IAM with AWS on your first login. It runs through multifactor authentication on the root account as well as setting up new users and assigning them to groups. There are also two examples of assigning policies, either to individual users to a whole groups.

1. Log into your console

2. Select a region (Set by default to US West Oregon) close to your geographic location if you haven’t previously done so. This will help reduce latency.

3. Open IAM and customise the login link: You can see a sign-in link at the top which is formatted as randomnumber.signin.aws.com/console. You can change this to be a name more suited to you or your company, keep in mind that IAM is not region specific and it uses an international DNS so the alias name must be unique. Once you have chosen a unique name, it will be updated on the console. This will be the link that all users which you specify can follow to log in.

4. Next, you’ll need to complete the security status checks to ensure your account is secure and that users have appropriate policies assigned to them.

a) Activate Multifactor Authentication (MFA) on your root account. Best practice is to set up MFA on the root account and never log in using the root account once users are set up. When managing the MFA, you can opt to either set up with a virtual device such as Google Authenticator or a hardware devise such as RSA tokens. The instructions will provide you with a inquire QR code to scan once you have downloaded the MFA device of your choosing to your mobile phone. Simply enter the unique codes provided and you’re good to go!

b) Create Individual IAM Users. Upon creating an account, you’re automatically logged in as the root user but as mentioned before, it is best practice to set up users, even if you control the root account too. When creating new users, be sure to generate an access key for each user. For each user, you are provided with a KeyID (which acts like a username) and a SecretKey (which acts like a password), which together act as way of interacting with the AWS platform using APIs or the command line. You are only given this information once so it is important to download the credentials (over HTTPs) before leaving this screen. To give users a password, simply:

• Select the user
• Under “User Actions” select “Manage Passwords”
• Assign an auto-generated password and allow users to change their password on first login, again the password will be generated automatically only once and it can be downloaded.

c) Use groups to assign permissions. By default, all users have no permissions so it is vital to ensure new users, even admins, are assigned to groups with permissions by the root user before trying to use the platform as one of those new users.

• Under ‘Groups’, create a new group i.e. “Admin”
• Attach a policy to that group by selecting from one of the predefined policy documents, such as “AdminPolicy” and select “Create”
• Now that your user belongs to a group, you can add users to the group too. Under “Groups”, select the Admin group that was just created
• Under “Group Actions” select “Add users to group”
• Add the users you want to have admin rights and select “Add users”.

d) Apply an IAM password policy. This allows you to decide what is required for the password and set a custom policy, i.e. character types allowed/required, minimum password length, users can change their own password, password expires etc. Once your policy is determined, select “Apply password policy” and this will apply the password policy to all users with access to your account.

Assign Policies to a single User

You can use Policies to grant full access to AWS console to one user, however, assigning policies to individual users can become quite difficult to manage and it is best practice to assign policies to groups who share the same permissions. If you still want to do this then:

• Under ‘Policies’, select the policy you want to assign
• Under to ‘policy actions’, select “Attach”
• Select the user you want to attach the policy to and click “Attach” at the bottom of the screen.

The following is a step by step instruction set on how to build your own AWS Virtual Private Cloud with public and private subnets and a Network Address Translation server to run between them. This example assumes the reader has some knowledge of SSH/Linux, VPC, AWS and has access to an AWS account.

**Be sure to choose an region which has a minimum of 2 availability zones

1. Under VPC/your VPCs/Create VPC with the IP 10.0.0.0/16

2. Under Subnets, create 2x Subnets 10.0.1.0/24 & 10.0.2.0/24 at different availability zones

3. Create an Internet Gateway to allow internet access, all subnets are detached from the internet by default.

4. Select ‘Attach to VPC’ and attach the internet gateway to your new Virtual Private Cloud

5. Create a New Route table and add a new route with the settings a) Destination: all b) Local:‘VPC-name’

6. Edit 1 of your Subnet to access the new Route Table allowing internet traffic. This will be your public subnet.

7. Back on the dashboard, create a new EC2 instance for your public subnet

• Use an amazon AMI, t2 micro
• Configure to ‘VPC-name’ and your public subnet
• Select auto-assign public IP
• Create a new security group which allows SSH & HTTP access
• Launch the instance and remember to download/save its key-pair value

8. Create a second EC2 instance for the second subnet with no public IP but the same security group. This subnet will remain private and inaccessible from the internet

9. open up your terminal and create a file to store your private key making it easy to access and log into the public instance of your VPC

$ nano VPCKeyPair.pem

$ chmod 600 VPCVPCKeyPair.pem

$ ssh ec2-user@IPaddress -i VPCKeyPair.pem (log in using public IP address, ie 194.153.205.26)

10. Test that the public instance works by running the update command as the root user

$ sudo yum update -y

11. Create another Private Key file on the public instance (exactly the same as above, using the same key and log into it to test that it works too).

$ nano VPCKeyPair.pem

$ chmod 600 VPCKeyPair.pem

$ ssh ec2-user@10.0.2.178 -i VPCKeyPair.pem (log in using the private IP address that you configured when creating your subnets)

You now have a Virtual Private Cloud with a public subnet which can access the internet. That public subnet also links to a second private subnet which does not have internet access. You can also test this by running the update command from your private subnet, the update won’t work because there is no internet.

Create a NAT (Network Address Translation Server) Instance for your VPC

When utilising your VPC, it is likely that you will have a use for both public and private subnets, each containing information which you may or may not want others to be able to view. Your private subnets, however, may still require internet access for some activities (ie running updates). In order to securely allow access to your private subnet, you will need to create a Network Address Translation Server. This can be done manually in a few simple steps with AWS

1. In the EC2 dashboard, Create a new Security Group which allow inbound and outbound traffic for HTTP and HTTPs

2. Launch a new EC2 NAT instance

• Search community AMIs for a NAT ami, t1 or t2 micro instance
• Configure the instance to be a Public Instance
• Assign your new Security Group to the instance
• Launch the Instance with the KeyPair from your VPC (above)

3. Assign an Elastic IP to your NAT Instance

• allocate a new address
• assign address to NAT VM

4. Under NAT/Actions/Networking/Change Source Destination: Disable (ensure you disable source destination checks, otherwise the internet access will NOT work).

5. Under VPC/Create New Route

• Add another route: Target NAT, destination: 0.0.0.0/0 (all)
• Subnet Association: Associate Private subnet with NAT Route

8. SSH into your private instance via your public instance (as above) and run an update to test the internet access is working correctly

$ sudo yum update -y

9. If the update works you have configured your NAT instance correctly, if not go back and check to ensure that you have disabled source destination checks.

The following article will go through redirecting a domain on a privately hosted server with AWS. And some of the things to be aware of before you go and do it! This particular example uses a website build with WordPress but is relevant to all web apps.

1. Log into your AWS account and redirect the name servers

In your ec2 hosted zone, set up a new type A record set for the name server you’d like to redirect, give it an appropriate subdomain and point it at the IP address of your server. In this case, selenasmall.com will be redirecting to subdomain www.selenasmall.com

Now you can change the values of the original name server to be pointing at ALIAS www.selenasmall.com with a simple routing policy.

2. In the command line, ssh into your ubuntu server

$ ssh selena

3. Find the .config file for the site you’re redirecting

If you’re unsure where to find it, it’s most likely to be located in the /etc dir for your site which usually stores config files, so you can run a search using the following command which will recursively search for case-insensitive text in files containing the term ‘vhosts’

$ sudo grep -R -i ‘vhosts’ /etc/*

4. Once you find the file, open it and edit the redirects to match up to your ec2 instance

$ sudo nano /etc/apache2/sites-available/blog.selenasmall.com.conf

Original 

Updated

Save and exit the file

Restart the server

$ sudo service apache2 restart

5. Log in to your database in your server and update the ‘siteurl’ file

If you’re unsure where the mysql database is located, you can always search history for it.

$ history | grep mysql

Log in to the database

$ mysql -u root wordpress -p

Find the site’s domain name as referenced in the database

$ select * from wp_options where option_name = ‘siteurl’;

Update the domain name

$ update wp_options set option_value = ‘http://www.selenasmall.com' where option_name = ‘siteurl’;

Check that it was correctly updated > $ select * from wp_options where option_name = ‘siteurl’;

6. Now that you’ve successfully re-routed your domain to another namespace, you’ll notice that your previous links and images are all broken. This is because the path has changed. If you’ve got a big application with a lot of links and images, that could mean a massive amount of work to try and go through to correct all the mistake.

You’ll probably want an easy function or plugin to go through the app and perform a find&replace of all references to the old domain. In the case of WordPress, the Better Search Replace plugin does the trick. https://wordpress.org/plugins/better-search-replace/