Customzing EC2 Windows instances without using a Custom AMI

Question

We are currently setting up a CloudFormation stack based on the template created by AWS Toolkit for Visual Studio when deploying using "Load balanced template". We need to create a script that customizes the EC2-instances somewhat. More specifically we want to: 1. Install two certificates into the certificate store. 2. Configure IIS to use one of the certificates. 3. Enable TLS 1.2 on IIS.

We need to install these certs at the IIS, instead of the load balancer, because we need to support client cert authentication.

We'd like to achieve this without having to create a custom AMI, because we want to be able to easily update the AMI as new versions arrive. We are using the following: ami-f6803f9f (which is the default used by the template).

We therefore want to do these customizations as part of the CloudFormation template. I've tried to create a simple file (just to make sure the scripting works) by using the "AWS::CloudFormation::Init" part of the template. However, when I launch the stack the file never gets created. The part of the template that is supposed to create the file looks like this:

 "Metadata" : {
    "AWS::CloudFormation::Init" : {
      "config" : {
      "files" : {
        "C:/ClientCA.pfx" : {
          "content" : { "Fn::Join" : ["", [
            "test1\n",
            "test2\n"
            ]]}
        }
      }
    }
  }
}

My questions are therefore: 1. Why is the file not being created? Is it because there's something wrong with the template or does this AMI not supported these types if init-scripts? 2. We are planning on downloading the certs from S3 using "AWS::CloudFormation::Init" and the installing them using a PowerShell-script that we add to UserData. Is this a good approach or should we do it differently?

Answer 1

I've just tested your snippet with a current Windows Server 2012 AMI and it worked just fine. Therefore my best guess is that ami-f6803f9f is a custom AMI already (at least I can't find it anywhere official) and lacks the required orchestration for Deploying Applications with AWS CloudFormation (this is the generic explanation for Unix/Linux, see Bootstrapping AWS CloudFormation Windows Stacks for a short Windows oriented example):

AWS CloudFormation includes a set of helper applications ( cfn-init , cfn-signal, cfn-get-metadata , and cfn-hup) that are based on cloud-init. These helper applications not only provide functionality similar to cloud-init, but also allow you to update your metadata after your instance and applications are up and running. [...] [emphasis mine]

The emphasized applications are those responsible for reading and acting on the metadata defined in the template, ie creating C:/ClientCA.pfx in your example. These helper applications are nowadays included in all current Amazon EBS-Backed Windows Server 2012 RTM AMIs , but haven't in the Amazon EBS-Backed Windows Server 2008 R2 AMIs usually, except for dedicated ones like the Amazon EBS-Backed Windows Server 2008 R2 English 64-bit - Base for CloudFormation .

Obviously you can also install these CloudFormation Helper Scripts on a custom AMI and move on from there, but if you haven't any specific reason to do so, I highly recommend to start with a current Amazon EBS-Backed Windows Server 2012 RTM AMI , which provides these and a few other likewise desired administrative productivity components out of the box (eg Windows PowerShell 3.0 and the new AWS Tools for Winodws PowerShell ).

Answer 2

Old question - but I'm tipping that the reason the file is not being created is that the cloudformation script is not executing cfn-init.

The key part is to ensure that you've updated the userdata scripts...

                "UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [
                "<script>\n",
                    "powershell.exe add-windowsfeature web-webserver -includeallsubfeature -logpath $env:temp\\webserver_addrole.log \n",
                    "powershell.exe add-windowsfeature web-mgmt-tools -includeallsubfeature -logpath $env:temp\\mgmttools_addrole.log \n",
                    "cfn-init.exe -v -s ", {"Ref" : "AWS::StackId"}, " -r WebServerLaunchConfiguration --region ", {"Ref" : "AWS::Region"}, "\n",
                "</script>\n",
                "<powershell>\n",
                    "new-website -name", {"Ref" : "Name"}, " -port 80 -physicalpath c:\\inetpub\\", {"Ref" : "Name"}, " -ApplicationPool \".NET v4.5\" -force \n",
                    "remove-website -name \"Default Web Site\" \n",
                    "start-website -name ", {"Ref" : "Name"}, " \n",
                "</powershell>"

The above script adds the web server features, the management tools, and then kicks of the cfn-init. It's cfn-init that is responsible for parsing of the meta data.

There are more details about bootstrapping IIS on AWS on my Kloud blog.