Amazon Web Services (AWS) provides an extremely flexible set of services for hosting web applications in the cloud with a web-based console for selecting options to quickly provision a set of IT resources. This post will explore the various aspects of hosting a custom .NET web application in AWS, focusing on high-availability options and disaster recovery scenarios and how to do so under cost constraints.

When building a solution in AWS you have to understand the difference between affinity and availability, and the terminology that Amazon uses. We will define affinity as the physical location of resources within a data center and availability as the isolation of resources for disaster recovery scenarios.

The AIS solution I’ll reference throughout this post uses a Virtual Private Cloud (VPC) to enable our engineers to develop a multi-tiered application within a private sub-netted network split across two availability zones. The VPC as defined by Amazon allows for “… you to create a virtual network topology—including subnets and route tables—for your Amazon Elastic Compute Cloud (Amazon EC2) resources.” The use of a VPC ensures you have high affinity for your EC2 resources. Availability zones refer to the geographically separated data centers Amazon uses for hosting EC2 resources.  Therefore, your disaster recovery architecture must account for placement of EC2 resources in different Availability Zones.

High Availability vs. Disaster Recovery in AWS

To muddy the terminology waters further, we have the concept of high availability, where the effects of hardware or software failure are essentially masked and downtime for end users reduced, such as in Microsoft’s SQL Server. Our solution had to address the issue of high availability and allow for a swift recovery in the event of a disaster or failure of EC2 resources in one availability zone. A high-level picture of what we needed to achieve is shown below.

Read More…

I was recently asked to write my own custom performance metric and publish it to Amazon’s CloudWatch using PowerShell.

Part I: How do I get this thing running already?

I initially used this blog post as a general guide, but since I had some experience with PowerShell already, the real learning part for me was how to call the API through .NET. (There is a second part, which actually shows you how to publish the metric. Unfortunately, his test “Tutorial” namespace ended up in the wrong region [US East] as compared to my instance [US West Oregon].

I figured out the correct way to do this by teasing apart the free community scripts available on AWS, which I will discuss later (see Part 2).

Read More…