Cleaning up AD when doing Blue/Green deployments on AWS

I’m getting ready to deploy the last part of our first application in AWS. It has been a long road, but we are almost at our first destination. One of our main goals was to do blue/green deployments with immutable infrastructure. We’ve been doing blue/green like deployments in our on-premise environment for many years but this is the first when building our infrastructure each time.

Part of our application requires active directory integration with Amazon’s Relational Database Service, specifically with SQL Server. I’ve been tuning our deployment over the last couple of weeks and as a result all of these blue/green deployment runs have littered our AD OU with quite a few terminated instances. At some point our AD administrators are NOT going to be happy with me, so I figured now was a good time to do something about it.

Let’s get started. The basic premise is we need to compare what we have running in AWS to the list of computers joined to the domain in our account OU.

First you’ll notice me installing the AWS Powershell Tools required in this script. By installing with -Scope CurrentUser, you can be assured the correct tools are installed for execution later. This way you don’t need to install the tools permanently on the machine you are running the script. Everyting is self contained, this way if you wanted to run it on TeamCity, Jenkins, or another “runner” type system all of the dependencies are included.

Next, since we are following best practices we have separated our non-production and our production accounts. We take the account number in as a PowerShell parameter and use it to decide what OU string and AD server we are going to use.

Next we initialize the default configuration for this script so that we don’t have to pass the profile name and location on every command. We have a fairly complex set of authentication requirements in our organization, which I won’t get into detail here. The short answer is this allows us to run this script as another AD user and use the proper settings for authentication.

Next we set our search string and our AWS AD server. These strings are highly dependent on your setup. We use multiple accounts in the same directory, so we inject the account number in here.

So that’s it for the setup. We then query active directory to get a list of computers and pipe their names into $adComputers.

Next we call the AWS API using Get-Ec2Instance and extract the instance information from the response. When the instance was initially created, we set the Name tag on our instance to be the EC2 hostname in the User Data of the launch template. We extact the hostname from the Name tag property. The result is a list of host names in $ec2Instance.

Now we have 2 lists and need to figure out which should be in the AWS AD Directory and which should not. We loop through the $adComputers list and see if that value appears in the EC2 instances list. If it is not, we query AD to get the actual AD object and pipe that to the Remove-ADComputer command. The -Confim:$false performs a slient removal with no user interaction as we plan on running this as a scheduled job/task.

Below is the full script with our specifics removed. If you have any questions, hit me up on twitter.