Azure DevOps to Amazon EC2 instance in 4 steps

After having completed the first few articles on “Getting started with Azure DevOps”, I thought of working on an interesting use case. The objective I set for myself was to create a CI/CD pipeline to deploy Azure DevOps build artifacts to Amazon EC2 instances. Later on, I realized that the timing of the use case couldn’t have been better as we were able to utilize the experience.

In the process of working on the use case, I took notes of what I learned, and I share them here.
Note: if you are new to Azure DevOps, I’d suggest reading through the 8-part series on Getting started with Azure DevOps. I borrow heavily from the concepts discussed in those notes.

Broadly, I can classify this use case into 4 steps:
Step 1: Create a build definition and build artifact in Azure DevOps
Step 2: Create an Amazon EC2 instance in AWS
Step 3: Add an Amazon EC2 instance to a deployment group in Azure DevOps
Step 4: Create a release definition to deploy build artifact to the Amazon EC2 instance in a deployment group

Step 1: Create a build definition and build artifact
A build definition creates build artifacts that can be used to deploy to a resource (in this case, an Amazon EC2 instance). In Azure DevOps, there are two ways to create a build definition. I have two detailed articles on this at Getting started with Azure DevOps -create a build pipeline -Part 1 (YAML pipeline) and Getting started with Azure DevOps -create a build pipeline -Part 2 (Classic Editor)
Please note: Although the reference articles state that they are part of an 8-part series, you do not need to go through each to understand how to create a build definition.

Step 2: Create an Amazon EC2 instance in AWS
Amazon Elastic Compute Cloud (EC2) is Amazon web services’ way of identifying virtual machines. I created a Windows virtual machine with a key pair so that I was able to log in. I did not specify any particular security group and went ahead with the default one. Here is a link to AWS documentation.
Note: Any virtual machines provisioned in cloud infrastructure must have proper security to protect from malicious access. The default security group does not provide that protection.

Step 3: Add an Amazon EC2 instance to a deployment group
A deployment group is a collection of machines with the same lifecycle -all virtual machines in an environment can belong to the same deployment group.
This step too is covered in detail in the following article Getting started with Azure DevOps -create a deployment group.
Please note: As stated in the previous note, you do not have to go through all 8 articles to understand how to add a VM to a deployment group.

Step 4: Create a release definition to deploy build artifact to the Amazon EC2 instance in a deployment group
A release definition is the last part of this chain wherein the build artifacts are deployed to the VMs of a deployment group which is the Amazon EC2 instance that we added in the previous step. This step, too (sorry for sounding like a broken record on this post), is covered in detail in the following article Getting started with Azure DevOps -create a release definition.

Conclusion: Having followed the above steps extensively at work (private cloud), I must say that deploying to an Amazon EC2 instance (public cloud) was not a novelty or any different than deploying to a VM on-premise (private cloud). My doubts were whether Azure DevOps would be able to communicate with an instance in a separate virtual cloud. With appropriate security groups in place, it was not too difficult.

If you are new and want to attempt this, I highly recommend you share your findings. If you have any questions, please do not hesitate to ask. It’ll be an opportunity for both of us to learn something new.

2 thoughts on “Azure DevOps to Amazon EC2 instance in 4 steps

    1. Thank you for the question. There are multiple conditions to consider. Primary among them is where you host Azure DevOps. If you host that in a data center, you will require a VPN connection with the AWS VPC, specific ports in the firewall, and appropriate changes in the security group if required.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s