Every week, there are new OS patches, package updates, and security advisories. Manually logging into each instance, checking updates, and documenting compliance quickly turns into a repetitive and error-prone nightmare.

That’s exactly the challenge I faced while managing multiple Linux EC2 instances in AWS. I wanted a way to automate patch checks, apply only critical updates, and generate a compliance report without logging into a single server manually. So I built my Ansible-based automation project that does just that.
It scans every running EC2 instances in your AWS environment, identifies pending updates, applies only approved or critical patches, and automatically emails an HTML report summarising patch status, reboot requirements, and compliance metrics.

What started as a small script evolved into a fully modular Ansible-driven system built to automate security patching and compliance reporting across servers. It’s designed not just to simplify patch management, but also to demonstrate essential Ansible concepts in a real-world DevOps scenario along with AWS best practices.

🌱 This project leverages everything I’ve learned along my Ansible journey:

1. Roles: Modular structure split into check_updates, apply_patches, and report for clarity and reusability.

2. Loops: Efficiently iterate through multiple servers and update lists.

3. Conditionals: Apply only critical patches or skip already compliant hosts.

4. Ansible Vault: Securely store sensitive data like AWS credentials and email passwords.

5. Dynamic AWS Inventory file: Automatically fetch live EC2 instances based on environment tags.

6. HTML Reporting: Generate professional, CSS-styled compliance reports with Jinja2 templates.

7. Automated Email: Send visual compliance summaries directly to your team’s inbox.

8. Playbooks: Orchestrate all roles through a single master playbook for streamlined execution.

9. Ansible Configuration (ansible.cfg): Simplifies setup by customizing inventory, SSH behavior, and remote user defaults.

10. Automation Scripts:

    • tagging.sh: Assigns sequential names to EC2 instances for easy identification.

    • copy-public-key.sh: Enables passwordless SSH between the Ansible master and target nodes.

Problem statement →

Managing patch compliance manually is time-consuming and prone to errors, especially when:

• You have multiple servers across different environments (development, staging, production).

• You need to prioritize critical security updates without accidentally breaking stable systems.

• Tracking compliance for reporting purposes becomes tedious and inconsistent.

Ansible addresses these challenges by:

1. Scanning all servers dynamically using AWS EC2 inventory tags.

2. Applying only critical or approved updates, using Ansible conditionals.

3. Generating a clear HTML report showing compliance status, pending updates, critical security updates, and patch history.

4. Automating notifications by sending the report to the DevOps or management team, removing manual effort entirely.

Project File Structure →

Autopatch-Ansible/
├── ansible.cfg                          # Ansible configuration
├── vault.pass                           # Vault password
├── ansible-key.pem                      # SSH private key
├── inventory/
│   └── ec2_hosts.yaml                   # AWS EC2 dynamic inventory
├── group_vars/
│   └── all/
│       ├── pass.yml                     # Encrypted secrets
│       └── vars.yml                     # Plain variables
├── playbooks/
│   ├── check_and_report.yaml           # Compliance check only
│   ├── apply_patches_and_report.yaml   # Apply patches + report
│   └── execute_playbook.yaml           # Main execution
├── roles/
│   ├── check_updates/                   # Scan for updates
│   │   ├── tasks/main.yml
│   │   └── defaults/main.yml
│   ├── apply_patches/                   # Apply system patches
│   │   └── tasks/main.yml
│   └── report/                          # Generate & email reports
│       └── tasks/main.yml
├── templates/
│   └── patch_report.html.j2            # HTML email template
├── tagging.sh
└── copy-public-key.sh                  # Distribute SSH keys

Now that we’ve covered what this project does and how it’s structured, let’s jump right in and start implementing Autopatch-Ansible step by step.

Step 1 → Set up the Ansible Control Node

We’ll begin by creating the Ansible Control Node which will be the central server that runs all your playbooks and connects to other instances(target servers/manage nodes) to automate tasks.

• Create a Security Group → Configure inbound rules → Allow relevant ports

Demonstration :

• Open AWS Console → Log in using your AWS credentials → Navigate to EC2 dashboard

Demonstration :

• Create a new EC2 instance with the following configuration:

  1. Name: ansible-control-node (This will serve as the central server for all automation tasks)

  2. AMI: Ubuntu 24.04 LTS

  3. Instance Type: t2.medium

  4. VPC: Create a VPC [project-vpc in my case]

  5. Key Pair: Create/use an existing key [ansible-key.pem in my case]

  6. Security Group: [AnsibleSecurityGroup in my case]

  7. Storage: 20 GB

Demonstration :

• Click Launch Instance → Wait for the instance to initialize → Copy the Public IP address.
  You’ll use this IP to connect via SSH and install Ansible in the next step + required configurations.

Demonstration :

Step 2 → Create an IAM user

Instead of using your root account credentials, always create a dedicated IAM user for automation.
This approach enhances security and follows AWS recommended practices for account and credential management.

• Go to AWS → IAM → Users → Create User

Demonstration :

• Attach policies directly → AmazonEC2FullAccess → Create user

Demonstration :

“ansible-user” IAM gets created →

Step 3 → Generate IAM Access Keys

We create IAM access keys so our Ansible control node can talk to AWS securely. This way, it can spin up, configure, and manage instances without ever touching your root account which keeps things safe and smooth.

Demonstration :

Make sure to download the .csv file so you have a copy handy when you need it later →

Step 4 → Connect to the Ansible Control Node

Now that our EC2 instance is up and running, it’s time to connect to it from your local terminal.

• Open your terminal → Navigate to the folder where your private key (.pem file) is stored

Commands used :

chmod 600 ansible-key.pem
ssh -i ansible-key.pem ubuntu@<public_ip_address>

Demonstration :

Step 5 → Install Dependencies & Configure AWS + Ansible Environment

• Update and upgrade system packages

Command used :

sudo apt update && sudo apt-get upgrade -y

Demonstration :

• Install Python and pip

Commands used :

sudo apt install -y python3
python3 --version

sudo apt install python3-pip -y
pip --version

Demonstration :

• Install AWS CLI

Commands used :

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
sudo apt install unzip
unzip awscliv2.zip
sudo ./aws/install

Demonstration :

• Configure AWS credentials

Commands used :

aws configure

Demonstration :

• Create and activate a Python virtual environment

Commands used :

sudo apt install python3-venv -y
python3 -m venv ansible-env
source ansible-env/bin/activate

Demonstration :

• Install Ansible

Commands used :

pip install ansible
ansible --version

Demonstration :

Step 6 → Set Up Ansible AWS Collection

Now that Ansible and AWS CLI are ready, we’ll install the required AWS collection and dependencies that allow Ansible to interact with EC2 instances(manage/target nodes) dynamically.

• Install supporting Python packages

Command used :

pip install boto3 botocore docker

Demonstration :

• Install the Amazon AWS Ansible collection

Command used :

ansible-galaxy collection install amazon.aws --force

Demonstration :

Step 7 → Clone the Autopatch-Ansible Repository

Commands used :

git clone https://github.com/sneywi/Autopatch-Ansible.git

cd Autopatch-Ansible

Demonstration :

Step 8 → Add Your Existing .pem Key & Set Up SSH Access

• Add your existing .pem key that was used to SSH into Ansible Control Node instance
  This lets you connect to your managed nodes easily using passwordless authentication

Command used :

vi ansible-key.pem

Demonstration :

• Create a new SSH keypair on your control node

  With this, Ansible can log into your managed nodes without asking for passwords every time

Command used :

ssh-keygen -t rsa -b 4096

Demonstration :

Step 9 → Create & Prepare Managed Nodes

Next, we set up the target servers (managed nodes) that Ansible will automate. These could be AWS EC2 instances or any other Linux machines.

Demonstration :

With these configurations →

1. Key: Environment, Value: Development

2. AMI: Ubuntu 24.04 LTS

3. Instance Type: t2.micro

4. Key Pair: Use an existing key [ansible-key.pem]

5. Security Group: [AnsibleSecurityGroup]

6. Storage: 15 GB

Click Launch instance → 5 instances get created

Step 10 → Name Manage Nodes Sequentially

To make automation easier, we’ll assign sequential, unique names to each EC2 instance.

Commands used :

# To give executable permissions
sudo chmod +x tagging.sh

./tagging.sh

Demonstration :

• They get sequentially named like below:

Demonstration :

Step 11 → Setup Passwordless SSH to All Managed Nodes

Commands used :

# To give executable permissions
sudo chmod +x copy-public-key.sh

./copy-public-key.sh

Demonstration :

Step 12 → Visualizing your inventory after SSH is set up

Commands used :

ansible-inventory -i inventory/aws_ec2.yaml --graph

# To log in without password, testing passwordless authentication
ssh ubuntu@<any_instance_ip>.compute.amazon.aws.com

Demonstration :

Step 13 → Configure and Secure Credentials with Ansible Vault

Commands used :

ansible-vault edit group_vars/all/pass.yml --vault-password-file vault.pass

Demonstration :

Add your credentials →

Step 14 → Run your playbook!

Command used :

ansible-playbook playbooks/execute_playbook.yaml

Demonstration :

🔴 LIVE

Applies patches if updates are available.

It finally executes the playbook to finish with no errors!

Step 15 → Verify Email Notifications

Checking for updates →

After applying patches →