Amazon Web Services: Migrating your .NET Enterprise Application: Evaluate your Cloud requirements and successfully migrate your .NET Enterprise Application to the Amazon Web Services Platform

AWS offers numerous services; during this chapter, we will look at the most common of these services. However, it should be noted that there are services offered by Amazon, which are not covered in this chapter as they do not directly relate to our enterprise application.

Over the course of this chapter, I will be referring to the AWS EC2 console or the AWS console. The AWS console can be accessed from the following location https://console.aws.amazon.com/ec2, and the details on accessing the console will be provided in Chapter 3, Getting Started with AWS and Amazon EC2.

To access the Simple Storage Service (S3), select the Amazon S3 tab at the top of the AWS Console.

S3 was one of the first services provided by Amazon and is arguably the largest. S3 is at its core an object store, or in other words, a place to store things. It is not, however, a file system. You cannot access things in S3 as you would in a normal file system; instead AWS provides an API to access data stored in S3. This is one of its key strengths, but also one of its key weaknesses.

It is a strength that S3 provides an API, as other third-party providers can write applications that access this API; however, the weakness is that, by default, getting access to S3 is a multi-step process.

Some things to remember for S3 are:

To access the Elastic Compute Cloud (EC2) functionality, access the Amazon EC2 table in the AWS Console.

Elastic Compute Cloud (EC2) is the engine room of AWS. This is where your servers will operate and run on a day-to-day basis. However, the 'elastic' in EC2 is there for a reason. EC2 is much more than just a bunch of servers! EC2 provides 'resizable compute capacity', or in other words can scale tremendously depending on your capacity requirements at a particular point in time.

EC2 provides the ability to start and stop multiple servers from a single server image, as well as modifying the number of these instances dynamically.

However, there have been some significant differences in the past on how this is implemented, which requires some up-front planning on how you will use the EC2 environment.

The Elastic Block Store (EBS) functionality is accessed from the Amazon EC2 tab, and then via the Volumes link in the Navigation pane.

Elastic Block Store (EBS) is the disk storage system for AWS and operates similarly to an external Storage Area Network (SAN) in a typical data center. EBS is a system that enables EC2 instances to access disks, which are configured, created, and managed externally to each EC2 instance.

EBS disks can be created independently of an EC2 instance and can be moved between EC2 instances at will.

In fact, if EC2 is the engine of AWS, you could consider EBS to be the fuel tank, holding all the resources for applications running on EC2.

EBS disks are a powerful feature of AWS and hold persistent data. This means that any data stored on an EBS volume will persist after an EC2 instance has been stopped or terminated.

EBS disk is also faster than the instance disk associated with an EC2 running instance if the instance uses the S3 instance store...

The Security Group functionality is accessed from the Amazon EC2 tab, and then via the Security Groups link in the Navigation pane.

Security groups define the access policies for new EC2 instances. Every instance started is required to exist in a security group. However, a security group does not provide firewall security to a group of servers (the word "group" is somewhat misleading in this context). Instead a security group is similar to a personal firewall, in that the security policies defined within a security group apply to each server individually within that group. Multiple servers defined in the same group do not share subnets and do not have unrestricted access to each other.

When starting Windows instances, AWS provides a group called "quick-start-1", which opens the single port 3389 for RDP. This allows you to access your instance initially. However, you should be aware that everyone else could also access this port, as the quick-start-1 security group does not...

The Virtual Private Cloud (VPC) functionality is accessed from the Amazon VPC tab in the AWS Console.

The virtual private cloud is a service that Amazon provides to allow enterprises to create computer resources on demand that are not accessible from the public Internet, but are accessible from their own internal network.

At this point in time some limitations exist for VPC.

Creating a VPC is straightforward and can be done from the AWS EC2 console; however, your enterprise will need to configure your firewall to allow the VPC to connect using the industry standard IPSec tunnel mode (with IKE-PSK, AES-128, HMAC-SHA-1, and PFS).

Currently, not all AWS functionality is supported within VPC, and in fact at the...

The basic CloudWatch functionality can be accessed from the Amazon EC2 tab via the Instances link in the Navigation pane, and then via the Monitoring tab in the EC2 Instance window.

CloudWatch allows you to monitor basic metrics of your AWS components from within the AWS EC2 console. CloudWatch can be a valuable tool to provide diagnostics on performance issues, which can be accessed from a central location. CloudWatch doesn't replace Windows Perfmon (The Microsoft performance monitoring tool), but works in parallel with Perfmon and Windows Management Instrumentation (WMI) counters to give a balanced overview.

CloudWatch can be enabled during instance startup or can be enabled after an instance has started from the AWS console.

The following basic statistics are supported by CloudWatch. These are collected at five minute intervals and provide the following counters:

Amazon has recently released a more detailed version of CloudWatch, which is now available in its own tab.

The new version of CloudWatch has a comprehensive list of metrics to choose from as well as the ability to associate alarms and notifications using Amazon SNS.

Elastic Load Balancing (ELB) is an AWS service that allows incoming IP traffic to be distributed among several servers. Typically an ELB would be used to direct incoming traffic to multiple web servers in a load-balanced fashion.

Elastic Load Balancing can also be used to create a fault-tolerant architecture, with ELB capable of detecting unhealthy EC2 instances and redirecting traffic to the remaining instances on demand.

Setting up an ELB with AWS can be done within the AWS console.

The Amazon Relational Database Service (RDS) may be accessed from the Amazon RDS tab of the AWS Console.

The Amazon Relational Database Service (RDS) provides SQL services within the AWS infrastructure using MySQL as the database engine. The RDS provides access to the full featured database engine provided by MySQL and allows full access to the database.

RDS features automatic backups, that can be retained for up to eight days. In the event that a more permanent backup is required, a snapshot can be taken of an RDS instance and stored in S3 indefinitely.

The Amazon Simple Notification Service (SNS) may be accessed from the Amazon SNS tab of the AWS Console.

Amazon Simple Notification Service (SNS) provides event and notification services from and to the AWS framework. SNS events may be sent from AWS to inform subscribers of alerts and critical thresholds. SNS alerts can be linked to CloudWatch performance alerts, although at this point this functionality is not supported within the AWS console.

We have finally looked at the majority of what AWS offers, and now we can begin the process of mapping each of the functions of our sample application to the functions provided by AWS.

Let's start by breaking our sample application into infrastructure areas, which we can map to AWS infrastructure services. The following are the infrastructure services required by our sample application.

Let's look at each of these in turn.

Now that we have mapped the requirements of our sample application to AWS, let's look at the other most common enterprise requirements.

In this chapter, we looked at each of the offerings of AWS in more detail, and then we mapped each of these offerings against our sample application. We looked at what our sample architecture looked like and compared that to what it looked like in AWS. We were surprised to find that the architecture didn't change at all! AWS provided all of the services we required either at the same level or at a better level of offering than was provided in our original sample application. We also looked at how security and regulatory requirements may affect your decision to migrate to AWS.

In the next chapter, we will be actually getting our hands dirty and creating an account on AWS, logging in and starting an EC2 instance!