In order to fully determine how the ‘Microsoft Active Directory Quick Start: AD DS with AWS Directory Service on the AWS Cloud’ template works, I implemented the template into AWS CloudFormation’s ‘Create Stack’ option.
The creation of this stack involved many specific details that I hadn’t previously considered would be of importance. However, as I went through the details, I recalled seeing them within the JSON scripts that I had been altering.
There were a few things that had me momentarily confused. One of these was with my availability zones, as I had not realized that my account region was set to Oregon. As I live in New Zealand, the Sydney region is the most optimal for reducing latency. To change this, I needed to quit this stack creation and start it again within the Sydney region. Also, because of initial lack of realization of setting up the template within a different region, I did not understand why I could access my key pair. The revelation of being in the wrong region helped my realize that key pairs are region specific, something which I did not know earlier.
The next step in setting up the stack was the ‘Options’, in which I created a tag for the stack, but did not change any of the permission settings as I currently don’t want to create more potential complication than necessary. This is something that I could consider adjusting once I manage to successfully recreate the CloudFormer version of this stack.
Upon reviewing the reviewing the stack template to be created, and pressing ‘create’, the site responded with the following error:
In my ignorance of what information was required for the stack creation, I had left the Remote Desktop Gateway (RDGW) CIDR blank in the ‘Network Configuration’ section. I had also left the ‘Microsoft Active Directory’ section blank, as I didn’t fully understand why it was needed, and so had left it clear.
My first attempt to solve to the RDGW CIDR was to input the VPC CIDR into it. However, this did not work. One of my classmates suggested using the CIDR from the first public subnet, which ended up working, as it appears that the gateway required a larger mask than the one that is supplied with the VPC.
I also filled in the Microsoft Active Directory section once I realized that it required input.
Once these problems were resolved, I was able to create the stack.
This particular template created four stacks; an AD stack, a VPC stack, an RDGW stack, and a general stack. Each of which, implemented certain AWS services.
The RDGW stack had the following outputs:
The AD stack had the following outputs:
The VPC stack had the following outputs:
The general stack had no outputs:
The outputs from the stacks are important to know as they can be selected in CloudFormer, but don’t necessarily have a tag attached, which can make them hard to distinguish from any other service objects that still exist within the AWS system. It is also important because not all of them exist on the free tier, which means that if the stacks are left running, a large fee can quickly accrue. The simplest way to stop the fees is to delete the stacks as that deletes all of the service objects involved. This is not always the optimal choice, but it is the best one for me once I’ve mapped the stacks through CloudFormer.