This post explores the process of setting up an approval workflow for Patch Manager, so you can delegate the responsibility of applying patches to your EC2 instance owners. I assume you are already familiar with AWS Systems Manager Patch Manager and have it configured.

A side note about AWS Patch Manager:

Patch Manager policies can be for Scan-and-Install or Scan-only purposes. So, start by creating a patch policy that only scans. We want to delegate the patching decision to the end user. I like the approach to targeting the instances to be patched using a [patch-policy] tag. This option provides a lot of flexibility. For example, you can create two patch policies, one for scan-and-install-on-schedule based on a maintenance window and the second for scan-on-approval. With a tag [patch-policy] that accepts any of the previous values, you can let your users choose what strategy they want to follow to keep the EC2s up to date in terms of security.

Check the following article in case you want to enforce a tagging strategy: https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/.

Possible tag convention:

• Tag name: patch-policy

• Tag values:

  • patch-on-approval: This tag value indicates that the instance should only be patched after explicit approval. It is useful when the instance can't be patched during a maintenance window or if you want to give more control to the instance owner over when the patching is done.

  • patch-on-schedule: This tag value indicates that the instance should be patched according to a schedule. You can configure a maintenance window for your instances using AWS Systems Manager Maintenance Windows and apply the patches during the window. This option is useful to ensure that your instances are always up-to-date without requiring manual intervention from the instance owner.

1. Workflow Overview

If you're building basic integrations in AWS, your first instinct might be to create some Lambda functions to "glue" services together. While Lambdas are great, if you're planning to grow your solution beyond a couple of functions, consider using Step Functions. After learning about Step Functions, you may even consider using them for one-step workflows.

Main benefits of Step Functions:

• Reduce Lambda functions development: You can directly interact with many AWS services from within the state machine tasks using Step Functions. This means that you don't have to write and manage as many Lambda functions, which can save time and effort.

• Easier Debugging: Step Functions provide a visual representation of your state machine, showing you all the inputs and outputs of each step in your workflow. This makes it easier to diagnose and fix any issues that may occur during execution.

• Task re-run: If a task fails, you can easily re-run that task within the state machine. This can help to recover from any issues encountered during execution quickly.

• Manual Workflow Execution: You can manually trigger a state machine execution with a custom input, which can be useful for testing and debugging.

• Retry mechanisms: AWS Step Functions provides a built-in retry mechanism that allows you to configure retries for each step in your workflow. If a step fails, the retry mechanism automatically retries the step based on the configuration you set. This helps to increase the reliability of your workflow and reduces the need for custom retry logic in your Lambda functions.

We're going to implement the workflow with AWS Step Functions. The workflow should be triggered every time a critical patch is missing on an EC2 instance tagged with the patch policy [patch-on-approval].

Assuming the patch policy, EC2 instances, and tagging are already in place, the integration between Systems Manager Patch Manager and the workflow will be handled by AWS EventBridge. EventBridge is a message bus that receives and delivers events from AWS services or your applications. All the AWS-supported messages are already passing through that bus. We just need to create a rule that triggers the workflow. We will work on that later. Before doing that, we need to develop the workflow.

This is an overview of the workflow we'll develop with Step Functions:

• Validate Event: The workflow starts with some validation to make sure that we are proceeding with the correct type of event. I'm using this validation step during the development phase to be more permissive about the type of events that can trigger the workflow and have more flexibility and control. It allows you to inspect the payload on the events that are triggering the workflow to fine-tune your EventBridge rule later. This step will probably go away once in production.

• Prompt User for Approval: We already know a critical patch is pending, so the next step is to notify the user and wait for their answer. A Lambda function will handle this task. The Lambda will compose the message and send the communication out to the user explaining that there is a critical path pending their approval. This Lambda will send the message to an SNS topic.

  Also, this is where we will pause the workflow execution until we get approval from the user to proceed with the patching.

  We are also going to need an API Gateway public endpoint that the user can access to approve the patch, and a second Lambda function will handle the approval response and reactivate the execution of the state machine. These two components are external to the workflow, but they are essential to process the user response and reactivate the execution of the state machine.

• Approval Choice: this is the conditional branching logic that determines whether to proceed with patching the instance if the approval is given or reject the patch if any other answer is received.

• Patch Instance: Our last main component is a Systems Manager SendCommand task that will install the security patches. This is exactly the kind of task that can save you from writing another Lambda function. The integration is already there provided by AWS.

2. Creating the SNS topic

The communication out to the end user to get their approval is handled by an SNS topic. SNS will provide us with the flexibility to add or remove people who need to be notified and abstract the workflow from the communication channel used to send the message. We are going to start simple, with email notifications, but this can be easily extended with Lambda functions to send the notifications via Slack, MS Teams, etc.

So, browse your AWS Console, choose the SNS service, and create a topic. Take note of the topic's ARN once created; you are going to need it later.

3. Creating the Workflow

Step Functions are a service provided by AWS that enables you to design and build applications using a visual workflow editor or the JSON-based Amazon State Language (ASL). ASL allows you to define the states, events, and transitions of your state machine using a structured format that is easy to read and understand.

Here you have an example of a single-step workflow that invokes a Lambda function:

{
  "Comment": "A simple state machine that executes a single task named HelloWorld",
  "StartAt": "HelloWorld",
  "States": {
    "HelloWorld": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:FUNCTION_NAME",
      "End": true
    }
  }
}

In this example, the Comment field is optional and allows you to add a description or notes about the state machine.

The StartAt field is required and specifies the initial state of the state machine.

The States field is required and contains one or more states that define the logic of the state machine.

In this example, we have only one state named HelloWorld. The Type field specifies the type of the state, which in this case is Task. The Resource field specifies the Amazon Resource Name (ARN) of the Lambda function that will be executed as the task.

The End field is optional and indicates that this is the final state of the state machine. We set End: true to indicate that the state machine should terminate after executing the task.

4. Triggering the workflow from Systems Manager Patch Manager

As we stated before, the integration between Patch Manager and AWS Step Function workflow will be handled by AWS EventBridge. All AWS events currently flow on the default bus of each account, perhaps without you even noticing it. Let's go to our default bus in the account and create a new rule. This rule will trigger our Step Function every time there is an EC2 instance going off compliance in terms of patching. EventBridge will also pass the original event payload as input to the state machine. We will get the instance ID that needs to be patched from there.

Example of the event payload:

{
  "version": "0",
  "id": "da802c23-0364-5de4-02c4-8f2389f89233",
  "detail-type": "Configuration Compliance State Change",
  "source": "aws.ssm",
  "account": "252525252525",
  "time": "2023-05-01T18:48:11Z",
  "region": "us-east-1",
  "resources": [
    "arn:aws:ssm:us-east-1:252525252525:managed-instance/i-0933335a5598"
  ],
  "detail": {
    "severity": "UNSPECIFIED",
    "patch-baseline-id": "pb-0be1ccde3be43f5",
    "compliance-status": "non_compliant",
    "resource-type": "managed-instance",
    "resource-id": "i-0933335a5598",
    "compliance-type": "Patch"
  }
}

Create the EventBridge rule

Step 1: Define rule detail

Name your rule, and make sure that it is created on the default event bus. Also, check that the rule type is "Rule with an event pattern".

Step 2: Build event pattern

Select the event source as:

Scroll down and enter the event pattern that will be used by the rule to filter what messages you are interested in:

{
  "source": ["aws.ssm"],
  "detail-type": ["Configuration Compliance State Change"]
}

Step 3: Select target(s)

Select AWS Service as the target type. Then select "Step Functions state machine" as the target and choose the state machine that you created before:

5. Resources

You can refer to this article for an example of how to implement a manual approval workflow: https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-human-approval.html. This is the article that I used to learn about manual approvals AWS Step Functions.

6. Conclusion

In conclusion, the integration of AWS Step Functions and Systems Manager Patch Manager provides a resilient and scalable solution for automating and delegating the patch management of EC2 instances. The use of Step Functions over Lambda enables easier troubleshooting, retries, and invocation with different parameters.

However, there are limitations and potential drawbacks, such as delayed patching if users do not respond to the patch notice.

Limitations and Drawbacks of the current implementation:

• Potential for delayed patching if users do not respond to the patch notice.

• Backups. I would like to take a backup of the instance right before the patches are applied.

• I'll try to create an AWS CDK script or Terraform to automate the deployment of this solution.

Future improvements:

• Take backups of instances before applying the security patches

• Automate the deployment process with Terraform or CDK

• Add more notifications, for example, when the process fails or when the instance is up to date

Overall, this project provides a foundation for those looking to streamline their patch management process and improve their security posture.

Nowadays, deploying web applications with containers is the norm, but who wants to go down the rabbit hole managing containers when you can instead use that time to work on your product?

In this post, we will create and deploy a Phoenix web application in AWS App Runner. App Runner simplifies the deployment and management of your dockerized application, providing some extra features out of the box like:

• Automated Deployments

• Load Balancing

• Auto Scaling

• Logs and Metrics

• SSL/TLS Certificate Management

App Runner takes care of starting, running, scaling, and load balancing your service. It works with two types of repository sources, source code –directly from GitHub– or docker images –from Amazon Elastic Container Registry (ECR)–. When using a code-based source like GitHub, then App Runner supports several runtimes such as Go, Java, .NET, Node.js, PHP, Python, and Ruby. I found the Docker image-based flavor handy when your programming platform is not supported directly by App Runner or you need full control of the environment that will be running your application.

Because Elixir is not supported by App Runner, we will be deploying our application through the Docker image option.

During this step-by-step we are going to going to focus on three different areas:

1. Creating the App: We need a dockerized web application to deploy in App Runner, and that is what we are going to build in this section. If you already have a web application or API running in docker, feel free to jump to the next section.

2. Automating the Docker image build: Our next step will be to automate the build of the Docker image, from GitHub to Amazon ECR.

3. Hosting the app in App Runner: Lastly, we will configure App Runner to host our web application.

Let's start!

1. Creating the App

Installing dependencies

There are two dependencies that we need to install to create a Phoenix app, the programing language, Elixir and the Phoenix Framework.

Installing Elixir

On macOS, it can be easily installed through homebrew; for other options, check Elixir's installation guideline: https://elixir-lang.org/install.html.

brew install elixir

The command above will install Elixir and Erlang and all the required dependencies on macOS.

Installing the Phoenix Framework

Let's use Mix, Elixir's built-in tool to manage dependencies and other tasks to install the Phoenix Framework.

mix archive.install hex phx_new

Once Phoenix is installed, the phx.new generator will be available to create our first application. Full instructions to install Phoenix here: https://hexdocs.pm/phoenix/installation.html.

Creating a new Phoenix app

To keep things simple as possible we are creating a web app without a database. Ecto is the go-to database toolkit for Elixir apps and it is configured by default for new Phoenix apps. So, we need to tell phoenix to create an app omitting the database layer. We will use the --no-ecto flag to achieve that.

Our app is called demo and we are telling Phoenix to create it without support for databases:

mix phx.new demo --no-ecto

https://hexdocs.pm/phoenix/up_and_running.html

Locally testing our app

Once the application has been created, browse in your terminal to the application directory and launch a local phoenix server:

cd demo
mix phx.server

Yes, that is all you need to run a local Phoenix server. The output will be similar to this:

Point your web browser to http://localhost:4000 and our Phoenix demo application will be there:

Creating a Docker image

To create our docker image we need a Dockerfile, this file specifies the steps to create the docker image, like a cooking recipe. Again, Phoenix can give you a working dockerfile for your project, just ask for it with the phx.gen.release generator, then create the docker image. Run the following commands on the main folder of your application:

mix phx.gen.release --docker
docker image build -t demo .

Generating a secret key

The secret key base is used to sign/encrypt cookies and other secrets. A default value is used in config/dev.exs and config/test.exs but you want to use a different value for production and you most likely don't want to check this value into version control, so we use an environment variable instead:

# generate a new secret key
mix phx.gen.secret
XevO6j...JZHk/JQ...jY2rb/4K...pCk/O83...UY+i

# set the secret key as an environment variable
export SECRET_KEY_BASE=XevO6j...JZHk/JQ...jY2rb/4K...pCk/O83...UY+i

Locally testing our docker image

Before moving forward to the next step, make sure that your web application can run inside a Docker container with no issues. The command below will run a Docker container, exposing port 400 to the localhost. The -e flag tells docker to read the environment variable SECRET_KEY_BASE and pass it inside the container:

docker run -dp 4000:4000 -e SECRET_KEY_BASE demo

2. Automating the Docker image build

Our next step is to automate the build process of our Docker image.

The image-based flavor version of App Runner that we are going to use can automatically deploy our application every time we push a new image to Amazon ECR. The process looks like this:

App Runner gets notified when a new image is available in ECR and deploys a new version of our containers. But, how can we automate the deployment workflow to detect when a new commit has been pushed to our git repository? To solve this part of the deployment workflow we are going to introduce AWS CodePipeline and AWS CodeBuild:

CodePipeline can detect changes in our GitHub repository and invoke CodeBuild with the latest version of our code in the main branch. Then CodeBuild is going to generate a docker image with the latest version of our code and push it into our private ECR repository. Then we already know the rest of the story, App Runner will get notified about the new image in ECR and deploy one or more containers based on our App Runner Deployment Configuration.

So, let's start by creating our Amazon ECR repository. Then we will move forward with setting up CodePipeline and CodeBuild to complete our CI/CD pipeline.

Creating a Git repository

I'm using GitHub, but CodePipeline also supports AWS CodeCommit and Atlassian Bitbucket.

I'm not covering the details of this step but here you have the GitHub documentation to create a repository and upload your existing local code. I'm sure that you are already familiar with this: https://docs.github.com/en/get-started/importing-your-projects-to-github/importing-source-code-to-github/adding-locally-hosted-code-to-github.

Creating the Amazon ECR repository

In your web browser, access the Amazon ECR console https://us-east-1.console.aws.amazon.com/ecr/repositories to create a new ECR repository. This is your docker registry repository, where your docker images will be stored.

I'll go with all the defaults in my case for a private repository:

Note: at the time of writing, ECR is the only Docker repository supported by App [Runner. Other repositories like Docker Hub will not work.

Verify if ECR is working:

Once the ECR repository is created, access it in the ECR web console and click on View push command button located at the top bar.

Follow the instructions provided based on your operative system, macOS/Linux or Window:

After running your docker push, you should see your docker image listed in the ECR repository web console.

CodeBuild and CodePipeline

With the git repository and the ECR registry created, it is time to configure our CI/CD pipeline with CodePipeline and CodeBuild AWS services.

Let's start by creating the pipeline. This is a five-step wizard that walks us through all the settings.

Define a new CodePipeline and CodeBuild step

Access the CodePipeline web console and click on "Create pipeline" button.

Add source stage: this is where we are going to connect our GitHub repository. Select GitHub (Version 2) as the source provider, then click on Connect to GitHub. This will open a dialog to grant the AWS Connector for GitHub access to your GitHub repository. As a best practice, I like to give access to the repository involved instead of all the repositories in my GitHub account. Once the AWS Connector is configured, the pipeline screen should look similar to this:

Add build stage: this is where CoudeBuild will create a new docker image and push it to ECR every time a code change in the main branch is detected.

Choose CodeBuid as the build provider and click on "Create project" button.

We need to define a CodeBuild project. This is where we can set up all the configurations related to the build process, like the operative system used for the build machine, pre-installed runtimes, support for GPU during the build process, etc.

In my case, I choose:

• Operative system: Amazon Linux 2

• Runtime(s): standard

• Image: latest image available

• Image version: "Always use the latest image for this runtime version"

• Environment type: Linux

• Privileged: check this box. The build instance needs privileged access to build Docker images.

Buildspec: make sure to keep the default values for the Buildspec section. The expectation is that CodeBuild will look for a file named buildspec.yml at the root level of our git repository. That is the file where we can define the commands for the build process. We are going to configure this in a few minutes.

Click on "Continue to CodePipeline". This will create the CodeBuild and bring us back to the pipeline wizard:

Click on "Next" and then "Skip deploy stage". The deployment component of our pipeline will be provided by App Runner itself, which is why we are skipping this stage. Review the settings and click on "Create pipeline".

The CI/CD pipeline is almost ready. We need to adjust some permissions and add our buildspec.yml file to the repository.

Setting up the IAM permissions:

CodeBuild needs permission to push the new docker images in Amazon ECR. Access the IAM console, search for the role created by CodeBuild and attach a new IAM policy to the role with the following permissions adjusting the arn ECR repository path:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ReadAndWriteAccessToDemoAppRepository",
            "Effect": "Allow",
            "Action": [
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage",
                "ecr:CompleteLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:InitiateLayerUpload",
                "ecr:PutImage",
                "ecr:BatchCheckLayerAvailability"
            ],
            "Resource": "arn:aws:ecr:us-east-1:552334911378:repository/demo-app-repository"
        },
        {
            "Sid": "ListECRImages",
            "Effect": "Allow",
            "Action": [
                "ecr:DescribeImages",
                "ecr:GetAuthorizationToken"
            ],
            "Resource": "*"
        }
    ]
}

Buildspec.yml: create a new file at the root level of your git repository named buildspec.yml and paste the code below renaming the ECR repository URI. The buildspec file has two phases defined, a pre_build phase to get the ECR credentials and pull the latest existing image from ECR and the build phase, which has the commands to build a new Docker image and push it into the ECR repository. Replace the ECR URI with your own:

version: 0.2

env:
  variables:
    CONTAINER_REPOSITORY_URL: 552334911378.dkr.ecr.us-east-1.amazonaws.com/demo-app-repository
    TAG_NAME: latest

phases:
  pre_build:
    commands:
      - aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 552334911378.dkr.ecr.us-east-1.amazonaws.com
      - docker pull $CONTAINER_REPOSITORY_URL:$TAG_NAME || true

  build:
    commands:
      - docker build --tag demo-app-repository .
      - docker tag demo-app-repository:latest 552334911378.dkr.ecr.us-east-1.amazonaws.com/demo-app-repository:latest
      - docker push 552334911378.dkr.ecr.us-east-1.amazonaws.com/demo-app-repository:latest

Now it is time to commit and push the buildspec.yml file, this time it should trigger the CI/CD. pipeline and after a couple of minutes we should see a new Docker image in our ECR repository.

3. Hosting the app in App Runner

Configure App Runner

Open the AWS App Runner console and click on "Create service". Once in the App Runner wizard, select the Container registry and Amazon ECR as the source type. Then click on Browse and select the latest Docker image.

Select the deployment settings that you prefer and click on Next. I choose Automatic deployments:

The next and last step is to configure the details for the App Runner service, here is where we have some control over the environment that will be running our app like the number of CPUs, memory per container, and when App Runner needs to automatically scale the number of containers.

For this application I'll go with the minimum environment possible, 1 vCPU, 2 GB of memory, and a custom auto-scaling configuration that will create up to 4 instances. By default App Runner will scale up to 25 instances, and it will deploy a new instance when the number of simultaneous requests per instance exceeds 100.

Another import setting that makes on this page is the port number. Our Phoenix app is running on the default port, 4000. Also, we need to specify the SECRET_KEY_BASE environment variable:

Click on "Create and deploy", and after a couple of minutes –it took around 4 minutes in my case– you will see your app running. App Runner will create a domain name for us that will look similar to this:

https://SOME-RANDOM-NAME.REGION.awsapprunner.com

And that is the end of this guide. I hope it helped you with your project!

Conclusion

We learned how to create an Elixir Phoenix web application, store the code in GitHub, containerize our application, create a CI/CD pipeline and host a web application in AWS without having to worry about any piece of infrastructure. We are not managing virtual machines, container infrastructure, or tools, everything is managed by AWS.

We also got some interesting features out of the box like:

• SSL/TLS certificate

• Auto-scaling and load-balancing capability based on the number of requests

• Easy access to the application logs

• Important metrics like:

  • Number of successful requests (2XX)

  • Number of failed requests (5XX)

  • Number of active instances

  • Request latency

Some of the limitations that I have faced so far:

• Access to databases in a VPC requires more advanced network configuration since App Runner lives in a VPC managed by AWS

• The observability feature can be configured only during the App Runner Service definition. Once you create the service, this cannot be changed.

• When using the App Runner source code repository option instead of ECR, then only GitHub is supported.

• When using the Container registry option, then only Amazon ECR is supported. No chance to host your docker image in Docker Hub and connect it with App Runner.

App Runner is a great service, especially for those developing minimum viable products. It allows you to focus on your project, providing in minutes an initial setup that can serve for many years and customers to come.

Resources

Official AWS App Runner Workshop:

• Getting started with AWS App Runner :: AWS App Runner Workshop: https://www.apprunnerworkshop.com/getting-started/

For those who want to run the extra mile, here you have great information to optimize the docker build process and general best practices for your docker files:

• Speed up your Docker builds with –cache-from:https://lipanski.com/posts/speed-up-your-docker-builds-with-cache-from

• Best practices when writing a Dockerfile for a Ruby application:

  https://lipanski.com/posts/dockerfile-ruby-best-practices

• Reducing Docker image build time on AWS CodeBuild using an external cache:https://aws.amazon.com/blogs/devops/reducing-docker-image-build-time-on-aws-codebuild-using-an-external-cache/

Enjoy!

API: ec2:RunInstances Not authorized for images: [ami-003a480a3489b1c5c]

If you are in a hurry, below, you can find a version of this template that includes a fix and some other minor improvements like support to deploy in a non-default VPC. And please, feel free to read the rest of this post to find out what was wrong with the original template, how to fix it, and the improvements.

CloudFormation template: https://public-cf-templates.s3.amazonaws.com/windows-active-directory/Windows_Single_Server_Active_Directory.template.json

Full story

I was looking for help to have an AD working on AWS to perform a proof of concept on a Single Sign On solution based on Cognito + SAML 2.0 and + Active Directory Federation Services (ADFS). Windows administration is not my thing, so I was looking for a shortcut to start with a working Active Directory installation. In that search, I found the following post that explains how to get an AD up and running quickly; it failed.

Original post: Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0: https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/

What was wrong with the original CF template?

The AMI IDs embedded in the template are outdated. The original post is from 2013, yep, nine years old. Maybe you are thinking, how can I trust an ancient post like that? Ok, you are right; you can expect this ancient blog post to point you to a broken CF template. I got that. But what happens if I tell you that the CloudFormation web console also has a link to the same broken template? Here it is:

In the case of the web console, it's using a different S3 endpoint, but it's pointing to the same template in the same bucket.

Link 1 - Found in the blog post: https://s3.amazonaws.com/cloudformation-templates-us-east-1/Windows_Single_Server_Active_Directory.template

Link 2 - Found in CloudFormation Web Console: https://s3-external-1.amazonaws.com/cloudformation-templates-us-east-1/Windows_Single_Server_Active_Directory.template

How to fix it?

To fix it, you need to edit the template and add an updated AMI id. You can get the AMI ID from the EC2 launch wizard or the AWS CLI. Here is an example to list the latest Windows Server 2022 images in the North Virginia region. You can use CloudShell to run the following command:

# Listing Windows Server 2022 AMIs on the us-east-1 region: 
aws ec2 describe-images --owners amazon --filters "Name=name,Values=Windows_Server-2022*" --query 'sort_by(Images, &CreationDate)[].[ImageId, Name, Description]' --region us-east-1 --no-include-deprecated

Note: I removed the AMI mapping on my version of the template. It defaults to Windows Server 2022 English Full Base in the us-east-1 region. You can get the AMI you need by running the AWS CLI command above.

Still failing, no default VPC

I fixed the AMI ID issue, but the template is still not working. Now what? Well, a limitation that I found is that the original template only works on accounts with a default VPC. In my scenario, the VPC is shared from another account, so I don't have a default VPC.

To solve the default VPC issue, I included two new parameters in the template. These are the VPC and Subnet parameters where you can specify the network to deploy the template's resources.

Then, I faced another issue related to how the security groups are created. The original template relies on the property SourceSecurityGroupName when creating the SecurityGroupIngress rules. But that is not compatible with a non-default VPC. I replaced it with SourceSecurityGroupId.

Defining the instance type

The EC2 Instance Type parameter is no more than a preconfigured list of allowed values. This approach is vulnerable to aging as new types of instances are released, so I converted it into a string with m5.large as the default value. I believe that if you are still reading this, you are very familiar with the EC2 instance types, and you can change the parameter to any other valid value.

I hope this post has helped you get an Active Directory and un running in AWS. I'm not pretending to use this template in production, but it can be handy when testing things. Enjoy! 🙂

Other resources:

Active Directory Domain Services on the AWS Cloud - Quick Start Reference Deployment

Query for the Latest Windows AMI Using Systems Manager Parameter Store