This blog discusses some of the lessons learned in implementing a Web Architecture with RDS. We walk through some key elements and highlight some gotchas  to be mindful of.

Scenario

The components for this scenario include:

• Virtual Private Cloud (VPC) with a public subnet and a private subnet.
  
• ELB for  Web Traffic
  
• IIS Web Server instance
  
• MS SQL RDS instance
  
• Jump box for management connectivity
  

One of the first implementation considerations in AWS is how you will setup your network. The recommended AWS Web architecture is running a public-facing web application on a public subnet and backend servers such as a Database Server on a subnet that isn’t publicly accessible. This is the scenario we will examine more closely and whilst there are many approaches to implement this architecture, there are some important elements to look out for:

Routing

The essential steps in establishing your VPC and related Network elements are listed below along with the essential routes that must be established for internet connectivity. You need to ensure that your Internet Gateway is added to the custom route table and your public subnet associated with this route table.

Creating a VPC

1. Create Internet Gateway
   
2. Create Public Subnet
   
3. Create Custom Route Table and associate Public Subnet
   
4. Create Private Subnet (Automatically associated to the Main Route Table)
   

Main Route table – Subnet Association: 10.0.2.0/24

Custom Route Table – Subnet Association: 10.0.1.0/24

When setting up your web servers in this scenario they will need to be dual homed.

Security

In a VPC you are able to apply security at the Instance (Security Groups) or subnet level (ACLs).In this scenario we are using security groups. We expose the web servers via ELB only for web traffic & secure RDP access to only those that need access using security groups, via the Jump box. We also provide access to the RDS SQL server via the Jump box for the use of SQL Tools for example.

ELB and Certificates

With Windows you’ll need to consider how you are going to manage the certificates, certificate requests, certificate chains, private keys and how you will get the cert installed on the IIS Server. You also need to consider how you’ll get the certificate installed on the ELB with Backend Authentication enabled. Traditional methods such as creating the certificate request on the IIS server can be used but I would suggest looking at OpenSSL. This is a great utility to simplify your ability to manage certificate assets and this process, providing a flexible way to import into both ELB and IIS. Some useful references:

• AWS OpenSSL tutorial: http://docs.aws.amazon.com/IAM/latest/UserGuide/InstallCert.html
  
• OpenSSL Command Line Reference: http://www.openssl.org/docs/apps/openssl.html
  
• ELB SSL configuration:  http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/US_SettingUpLoadBalancerHTTPS.html
  
• IAM command line reference for installing your certificate  http://aws.amazon.com/developertools/AWS-Identity-and-Access-Management/4143 
  

ELB HTTPS Configuration

Working with OpenSSL I suggest you maintain a folder with all your relevant certificate assets in it. Where necessary you’ll need to combine certs together to generate certificate chains and be able to generate different kinds of formats for the relevant technology stacks you are installing them onto.

DNS Considerations

There are many considerations for implementing DNS for your website and key is your approach to root domain and subdomain name resolution. The below looks at this scenario in AWS and considers the use of Route 53

An A record is provided for the ELB, this should be used in configuration as the IP address of the ELB’s may change without notice. When configuring your DNS to point to a site you can create a CNAME or A Record to point to the relevant subdomain by ensuring that the relevant record refers to the ELB Domain Name as the Target.  For example you could create a CNAME with an Alias that points to www.example.com. However this will not help you for the zone apex e.g. example.com
as there is a limitation with associating a CNAME in Route 53 for your Zone Apex that is discussed below.

Encountered Issues and Resolutions

 Multiple Gateways for Windows Dual homed servers will cause routing issues.

The web server in this scenario will have NICs on both 10.0.1.0/24 and 10.0.2.0/24 you will likely experience issues connecting to one of the interfaces. A typical approach to resolve this to set up some static routes for the various networks. In this example however this is not required and all that is needed is to identify the primary routing NIC and remove the default gateway from the secondary NIC. This will clear up the confusion with multiple gateways and allow your traffic to route as expected. Other approaches to resolving this are usually to review the NIC binding order and adjust accordingly however this proved ineffective on a Windows 2012 server.

Only the default security group contains rules that allow instances to communicate with each other by default.

So in this example if you were to have multiple web servers in WebServerSG group that you needed to communicate you’d need to explicitly define these rules. Just as is required for communication between security groups such as for the Jump Box and the Webserver to communicate.

Certificate Chain order matters.

 When constructing your certificate chain you may find the order of the certificates matters. In this example the certificate could only be added to the ELB with a certificate chain that was in the order of Subordinate CA followed by Root CA.

—–BEGIN CERTIFICATE Subordinate CA—–
MIIEnDCCA4SgAwIBAgIQaUiiayAapCHomLHEksfFjjANBgkqhkiG9w0BAQUFADBY….

………………………………………
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE RootCA —–
MIIEnDCCA4SgAwIBAgIQaUiiayAapCHomLHEksfFjjANBgkqhkiG9w0BAQUFADBY
……………………….

—–END CERTIFICATE—–

One of the next challenges you may encounter is enabling multiple certificates on an ELB.

 ELB restricts the use of multiple certificates and only supports one SSL cert per ELB.

An ELB can only point to the primary IP address of the instance. This is limitation of ELB and is not configurable at this point.  If you require multiple bindings for your site (for example for multiple SSL Certs) you’ll only be able to have HTTPS using one SSL Cert load balanced through the ELB. In such a scenario you’ll need to consider a wild card certificate.

 RDS Instances are not publically accessible unless connected to a public subnet.

As an RDS instance in this scenario will be provisioned on a private subnet it will not be “Publicly Accessible” even if you select this setting when launching your RDS instance. Hence the provisioning of a jump box above to provide an isolated access point for database connectivity once you’ve installed SQL Tools

MS SQL RDS is not available in a Multi-AZ configuration.

If a more resilient solution is required you’ll need to look at setting this up via non-RDS SQL instances or alternative DB technologies such as MySQL or Oracle which are supported in a Multi-AZ configuration.

In a single AZ Scenario like this one you’ll also need to create a third but unused subnet for the second availability Zone in order to complete the creation of your DB Subnet group and be able to launch your DB instance.

Route 53 “you can’t use a CNAME record to associate your zone apex with your Elastic Load Balancing instance. DNS rules prohibit the creation of a CNAME record at the zone apex (e.g., example.com). For example, if you own the example.com domain name, you can use a CNAME record for the www.example.com subdomain name, but not for the example.com zone apex.”  Associating domain names with ELB’s: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/using-domain-names-with-elb.html).

This leads you down the path of  a hosted Zone in Route 53 to associate the apex or root, or alternatively finding an alternative strategy to point your zone root to the ELB such as via an A record, etc.

Conclusion

As you can see there are numerous considerations to establishing an AWS Web Architecture that requires careful consideration in the planning and design phase of your AWS Solution. Once these foundational designs are in place, you will be better position to take advantage of AWS features which include scalability, resiliency, and automation.