Forem: David Omokhodion

Stop Getting 'Access Denied': Fixing Cross-Account Access in AWS with IAM STS

David Omokhodion — Tue, 03 Mar 2026 23:56:18 +0000

If you've ever worked in a multi-account AWS environment, you've probably hit the dreaded AccessDenied error when trying to access resources across accounts. Whether it's sharing data between dev and prod accounts, aggregating logs to a central security account, or enabling cross-team collaboration, cross-account access is essential—but it's also where many engineers struggle.

In this post, I'll show you exactly how to implement secure cross-account resource access using AWS Identity & Access Management (IAM) with AWS Security Token Service (STS) with a real-world example: a Lambda function that tracks the International Space Station's location and stores the data in an S3 bucket in a different AWS account.

Prerequisites

Have Terraform installed
Have access to 2 AWS accounts

🏗️ The Architecture

Here's what we're building:

Account A (Source):

Lambda function that fetches ISS position data
IAM execution role with permission to assume a role in Account B
EventBridge trigger (runs every 5 minutes)

Account B (Target):

S3 bucket for storing ISS position logs
IAM role that trusts Account A's Lambda role
Policies granting S3 access to the trusted role

The Flow:

EventBridge triggers Lambda in Account A
Lambda calls sts:AssumeRole to get temporary credentials for Account B
Lambda uses temporary credentials to read/write to S3 bucket in Account B
Lambda fetches ISS position from public API and appends it to a file pulled from s3
Lambda pushes the update file back to s3

🛠️ Let's Implement the Trust Chain

Step 1: Configure the Terraform Providers

Configure you cli with credentials from account A. Then run aws sts get-caller-identity to get your identity.
e.g

{
    "UserId": "<redacted>",
    "Account": "<redacted>",
    "Arn": "arn:aws:iam::<redacted>:user/nobleman"
}

Next, create a role (called terraform, for example) in account B. In its trust relationship, allow the previous identity to assume it.

For example...

{
    ...
    "Statement": [
        {
            ...
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<redacted>:user/nobleman"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Next, configure Terraform providers for both accounts like this...

terraform {
  required_version = ">= 1.0.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
  # role_arn is set in ~/.aws/config
}

provider "aws" {
  region = "us-east-1"
  alias  = "account_b"

  assume_role {
    role_arn = "arn:aws:iam::${var.account_b_id}:role/terraform"
  }
}

Step 2: Lambda's Execution Role (Account A)

Next, create a role that Lambda can assume:

# Account A: Role that Lambda assumes
resource "aws_iam_role" "cross_account_role" {
  name               = "connect-to-bridge"
  assume_role_policy = data.aws_iam_policy_document.ec2_assume_role.json
}

# Trust policy: Allow Lambda service to assume this role
data "aws_iam_policy_document" "ec2_assume_role" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["lambda.amazonaws.com"]
    }
  }
}

What this means: The Lambda service can wear this role like a badge.

Step 3: Grant Role Permission to Assume Cross-Account Role

Now we give this role permission to assume another role in Account B:

# Account A: Policy that allows assuming role in Account B
data "aws_iam_policy_document" "assume_cross_account_role" {
  statement {
    effect    = "Allow"
    actions   = ["sts:AssumeRole"]
    resources = [aws_iam_role.access_s3_bucket.arn]  # Role in Account B
  }
}

resource "aws_iam_role_policy_attachment" "ec2_assume_cross_account" {
  role       = aws_iam_role.cross_account_role.name
  policy_arn = aws_iam_policy.assume_cross_account_role.arn
}

What this means: "Hey Lambda role, you're allowed to assume the access_s3_bucket role in Account B."

Step 4: The Target Role in Account B

Here's the role in Account B with the crucial trust policy:

# Account B: Role that grants S3 access
resource "aws_iam_role" "access_s3_bucket" {
  provider = aws.account_b  # Important: This is in Account B

  name               = "access-s3-bucket"
  assume_role_policy = data.aws_iam_policy_document.allow_role_assumption_a.json
}

# Trust policy: Allow Account A's role to assume this role
data "aws_iam_policy_document" "allow_role_assumption_a" {
  statement {
    effect = "Allow"

    principals {
      type        = "AWS"
      identifiers = [aws_iam_role.cross_account_role.arn]  # Account A role ARN
    }

    actions = ["sts:AssumeRole"]
  }
}

This is the key: Account B explicitly trusts Account A's role. Without this trust relationship, the assume role call will fail.

Step 5: Grant S3 Permissions to the Account B Role

data "aws_iam_policy_document" "s3_bucket_access" {
  statement {
    effect = "Allow"

    actions = [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject",
      "s3:ListBucket"
    ]

    resources = [
      module.reporting-bucket.s3_bucket_arn,
      "${module.reporting-bucket.s3_bucket_arn}/*"
    ]
  }
}

resource "aws_iam_role_policy_attachment" "s3_bucket_access_attachment" {
  provider   = aws.account_b
  role       = aws_iam_role.access_s3_bucket.name
  policy_arn = aws_iam_policy.s3_bucket_access.arn
}

The complete trust chain:

→ Lambda Service assumes Lambda Execution Role (Account A) 
→ Lambda Execution Role (Account A) assumes S3 Access Role (Account B) 
→ S3 Access Role (Account B) has permission to S3 Bucket (Account B)

💻 The Lambda Implementation

Now let's look at how the Lambda function uses STS to assume the cross-account role:

import boto3
import os
import urllib3
import json
from datetime import datetime

def lambda_handler(event, context):
    # Environment variables from Terraform
    account2_role_arn = os.environ['ACCOUNT2_ROLE_ARN']
    bucket_name = os.environ['BUCKET_NAME']
    bucket_region = os.environ['BUCKET_REGION']
    object_key = 'iss_position.txt'

    # Step 1: Assume the role in Account B using STS
    sts_client = boto3.client('sts')
    assumed_role = sts_client.assume_role(
        RoleArn=account2_role_arn,
        RoleSessionName='LambdaCrossAccountS3Access'
    )

    # Step 2: Extract temporary credentials
    credentials = assumed_role['Credentials']

    # Step 3: Create S3 client with temporary credentials
    s3_client = boto3.client(
        's3',
        aws_access_key_id=credentials['AccessKeyId'],
        aws_secret_access_key=credentials['SecretAccessKey'],
        aws_session_token=credentials['SessionToken'],
        region_name=bucket_region
    )

    # Step 4: Read existing file from S3
    response = s3_client.get_object(Bucket=bucket_name, Key=object_key)
    content = response['Body'].read().decode('utf-8')

    # Step 5: Fetch ISS position from public API
    http = urllib3.PoolManager()
    response = http.request("GET", "http://api.open-notify.org/iss-now.json")
    data = json.loads(response.data.decode("utf-8"))
    timestamp = datetime.fromtimestamp(data['timestamp'])

    # Step 6: Append new data
    new_content = content + f"""Time: {timestamp}
Latitude: {data['iss_position']['latitude']}
Longitude: {data['iss_position']['longitude']}

"""

    # Step 7: Write back to S3 using temporary credentials
    s3_client.put_object(
        Bucket=bucket_name,
        Key=object_key,
        Body=new_content
    )

    return {
        'statusCode': 200,
        'body': 'Cross-account S3 access successful'
    }

Key Points:

sts_client.assume_role(): This is where the magic happens. Lambda uses its execution role to request temporary credentials for the Account B role.
Temporary Credentials: STS returns short-lived credentials (valid for 1 hour by default). These credentials have all the permissions of the assumed role.
Session Name: The RoleSessionName appears in CloudTrail logs, making it easier to audit who assumed the role and when.
Explicit Credential Usage: We explicitly pass the temporary credentials to the S3 client. This is different from the default boto3 behavior which uses the Lambda's execution role.

📦 Deployment

Prerequisites:

Two AWS accounts (A & B)
AWS CLI configured with access to Account A
Terraform >= 1.0
A pre-existing terraform role in Account B that Account A can assume

Steps:

Clone the repository:

git clone https://github.com/nobleman97/cross-account-iam.git
cd cross-account-iam

Create a dev.tfvars file:

account_b_id = "123456789012"  # Replace with your Account B ID

Deploy the infrastructure:

cd infra
terraform init
terraform plan -var-file=dev.tfvars
terraform apply -var-file=dev.tfvars

Watch it work:

# Check Lambda logs
aws logs tail /aws/lambda/write-report-to-crossaccount-s3 --follow

# After 5-10 minutes, check the S3 file in Account B
aws s3 cp s3://iss-reporting-24534576df/iss_position.txt - \
  --profile account-b

If setup properly, the file should look something like this:

ISS Location Logs
===================


Time: 2025-12-06 17:19:45
Latitude: -50.5587
Longitude: 122.1887

Time: 2025-12-06 17:29:07
Latitude: -32.9030
Longitude: 163.3656

...

Common Pitfalls and Solutions

Problem 1: "User is not authorized to perform: sts:AssumeRole"

Cause: The role in Account A doesn't have permission to assume the role in Account B.

Solution: Verify the policy attachment:

aws iam list-attached-role-policies --role-name connect-to-bridge

Problem 2: "AccessDenied" when accessing S3

Causes:

The trust policy in Account B doesn't trust Account A's role
The role in Account B doesn't have S3 permissions
The S3 bucket has a restrictive bucket policy

Debug:

# Check trust policy
aws iam get-role --role-name access-s3-bucket \
  --profile account-b --query 'Role.AssumeRolePolicyDocument'

# Check attached policies
aws iam list-attached-role-policies --role-name access-s3-bucket \
  --profile account-b

Problem 3: Terraform Can't Create Resources in Account B

Cause: Terraform doesn't have permission to assume the role in Account B.

Solution: Ensure you have a terraform role in Account B with this trust policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "<arn_of_cli_identity>"
    },
    "Action": "sts:AssumeRole"
  }]
}

🎓 Key Takeaways

Two-Way Trust: Cross-account access requires both accounts to cooperate:
- Account A must be allowed to assume roles in Account B
- Account B must trust Account A's role
STS is Your Friend: Temporary credentials are more secure than permanent access keys. They expire automatically and can be audited.

Conclusion

Cross-account IAM access doesn't have to be scary. By understanding the trust relationships, using STS for temporary credentials, and following least privilege principles, you can securely share resources across AWS accounts.

The pattern I've shown here—Lambda in Account A assuming a role in Account B to access S3—applies to many other scenarios:

EC2 instances accessing DynamoDB in another account
Step Functions orchestrating resources across accounts
EventBridge forwarding events between accounts
Centralized logging and monitoring

Have you implemented cross-account access in your AWS environment? What challenges did you face? Drop a comment below!

Resources

If you found this helpful, consider starring the GitHub repo and sharing it with your team!

Docker Networking 101: A Blueprint for Seamless Container Connectivity

David Omokhodion — Wed, 13 Dec 2023 14:05:42 +0000

Docker is a platform for developing, shipping, and running applications in containers. Containers are lightweight, standalone, and executable software packages that include everything needed to run a piece of software, including the code, runtime, libraries, and system tools. Docker provides a consistent and reproducible environment across different environments, making it easier to build, deploy, and scale applications.

To enable communication between containers, your host and the outside world, docker implements an interesting networking system. It is this system that bridges the gap between isolated containers, allowing them to function as well-coordinated services.

In this article, you will learn about the basics of the different network types and how to use them in development or deployment.

We will cover:

Docker Network Types
Using Docker Networks

Prerequisites

Have Docker Engine Installed
Have a basic understanding of Docker

Docker Network Types

Docker comes with 7 (rumours say there are more) network types. However, we will discuss the most important four. They are:

None
Bridge (default)
Bridge (user-defined)
Host

If you already have Docker setup on your host machine, and you run the command "docker network list", you should get an output similar to this:



$ docker network list
NETWORK ID     NAME      DRIVER    SCOPE
6f23ed77734d   bridge    bridge    local
3bbca0d09738   host      host      local
a67ca10d6dfd   none      null      local

"Driver" in this list, tells us the network type, and by default, docker creates one bridge, host and null(none) network each.

Let's discuss each network type in more detail...

1. None

None is a docker network-type where the container is not attached to any network. As a result, the container is unable to communicate with any external network or other containers. It is isolated from every other network.

You can run an nginx container in a "none" network type using the following command:



docker run -d --network none --name my_nginx nginx

2. Bridge (default)

The bridge network mode sets up an internal private network within the host. This allows communication between containers within such network, but isolates them from the host's network.

When docker containers are created without specifying a network, they are automatically placed in the default bridge network.

For example:



# running a container in the default bridge network
$ docker run -dit --name Rock nginx

3. Bridge (user-defined)

This network type is similar to the user-defined bridge network. It also creates an internal private network within the host, but it does not come already created by Docker. You have to create it yourself.

Here's how you create a user-defined bridge network called "demo_net":



# create a user-defined bridge network
$ docker network create -d bridge demo_net

# list all your docker networks
$ docker network list
NETWORK ID     NAME       DRIVER    SCOPE
6f23ed77734d   bridge     bridge    local
7a824036d47a   demo_net   bridge    local
3bbca0d09738   host       host      local
a67ca10d6dfd   none       null      local

Here's how to attach a container to the user-defined bridge network you just created...



# Attaching containers to bridged network
$ docker run -dit --network demo_net --name service_A nginx

# create another container and publish a port
$ docker run -dit -p 8000:80 --network demo_net --name service_B nginx

service_A and service_B containers are now attached to the 'demo_net' network. By default, all containers within the same network can communicate with one another freely but are isolated from the host network and other user-defined networks.

In order to access applications running on these containers from the host network, we have to publish (or expose) ports from the containers. In the snippet above, port 80 on service_B container is mapped to port 8000 on the host, allowing access to an application running on service_B's container port 80 to be accessed from port 8000 on the host.

4. Host

Containers in host network mode directly utilize your host's network stack, lacking isolation. They do not receive separate IP addresses, and any port bindings are directly exposed on your host's network interface. In practical terms, if a container process is configured to listen on port 80, it will bind to your host machine's IP address on port 80.

Here's an example of a container that binds nginx to a host network:



# bind container to host network
docker run -d --network host --name my_nginx nginx

If you're using the host's network for your web container (like Nginx), it means you can't run multiple web containers on the same host and port. This is because they would all share the same network settings, causing conflicts.

Using Docker Networks

Testing Communications Within and Between Networks

In an earlier step, we attached two containers (service_A and service_B) to the demo_net network. Let's confirm that they can communicate with one another within the same network and whether they can communicate with a container in a different network(e.g the "Rock" container in the default bridge network).



# open a shell into service_A container
$ docker exec -it service_A /bin/bash

# when inside service_A container update its apt repos and install ping
$ apt update && apt install iputils-ping -y

# Then ping service_B using the container name because name resolution is automatically enabled within the network 
$ ping service_B

root@06dbaea8c2a2:/# ping service_B
PING service_B (172.18.0.3) 56(84) bytes of data.
64 bytes from service_B.demo_net (172.18.0.3): icmp_seq=1 ttl=64 time=0.086 ms
64 bytes from service_B.demo_net (172.18.0.3): icmp_seq=2 ttl=64 time=0.154 ms
64 bytes from service_B.demo_net (172.18.0.3): icmp_seq=3 ttl=64 time=0.119 ms
64 bytes from service_B.demo_net (172.18.0.3): icmp_seq=4 ttl=64 time=0.121 ms
...

The results are similar when you exec into service_B and ping service_A container. However, none of the containers can reach the "Rock" container which is in the default bridge network because they exist in different virtual networks.



# Inside service_A
root@06dbaea8c2a2:/# ping Rock
ping: Rock: Temporary failure in name resolution

Reaching Apps Running in Containers via Published Ports

When creating service_B in an earlier step, we ran the following command:



$ docker run -dit -p 8000:80 --network demo_net --name service_B nginx

This command mapped port 80 within the container to port 8000 on the host machine. Hence, when we visit localhost:8000 in our browser, we see the web server running in service_B:

Manipulating Network Connections



# Disconnect service_A
$ docker network disconnect demo_net service_A

# Reconnect service_A to default "bridge" network
docker network connect bridge service_A

#Next, use `docker inspect` to get the ip of the Rock container and try pinging it.

root@06dbaea8c2a2:/# ping 172.17.0.2
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.186 ms
64 bytes from 172.17.0.2: icmp_seq=3 ttl=64 time=0.149 ms

# It works!

List Docker Networks



$ docker network ls
NETWORK ID     NAME       DRIVER    SCOPE
a87871978d59   bridge     bridge    local
747d0aff98fc   demo_net   bridge    local
3bbca0d09738   host       host      local
a67ca10d6dfd   none       null      local

Deleting Docker Networks

To delete a custom network, you must first stop or disconnect all running containers attached to the network. When that's done, proceed to delete the network by running the docker network rm command like this:



$ docker network rm demo_net

# Confirm that the demo_net network has been removed
$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
a87871978d59   bridge    bridge    local
3bbca0d09738   host      host      local
a67ca10d6dfd   none      null      local

Conclusion

Docker's networking system gives you different choices for handling communication between containers, their nearby containers, and your Docker host. In a network, containers can connect with each other using their names or IP addresses.

User-defined bridge networks work well when you want various containers to talk to each other on the same Docker host. On the flip side, host networks are more suitable when you don't want the network stack to be separate from the Docker host, but you still want other parts of the container to be isolated.

Docker's networking system could initially feel overwhelming, but I hope this gives you some clarity.

...

If you have any questions or comments, you can leave them below, or reach out to me on LinkedIn. Till we meet again...

Stay awesome!
~ David Omokhodion

Attributions

How to Provision a Linux EC2 Instance (server) on AWS Step-by-step

David Omokhodion — Sun, 30 Oct 2022 17:58:52 +0000

Have you ever needed a server to deploy a web app, complete a lab or something else? I have had need to do both, and AWS always came through for me.

In this tutorial, you will learn how to set up and connect to your own AWS Linux EC2 instance to meet your needs for a server.

Let's go...

What is an EC2 Instance?

An Amazon EC2 instance is a virtual server in the AWS cloud. With the Amazon EC2 service, you can configure your instance to run operating system or applications of your choice.

Overview

When launching an instance, you have to secure it using security groups(which acts like a virtual firewall to control traffic to and from your instance) and key pairs(a proof of identity).

Here is an architectural diagram of what we will be setting up:

Prerequisites:

An AWS account
Create key pair and security group by following instructions found here

To avoid being billed unnecessarily, please ensure to terminate you instance when you complete this tutorial. Instructions for that are included in the last step here.

Step 1: Launch Your Instance

There are several ways to launch an EC2 instance, but in this tutorial, we will use the AWS console.

Here are the steps:

Open the EC2 console at AWS console link
From the dashboard, click on Launch instance

Next, enter a name for your server.
Under the Application and OS Images (Amazon Machine Image), select the "Quick Start" tab and select the Ubuntu image. This will be the OS for your instance.
Under the Amazon Machine Images(AMI) section, pick an option with the "free tier eligible" label for now.

Next, under Instance type, choose an option that has "free tier eligible" too. These instance types are hardware configurations for your server.
Under Key pair(login) choose a key pair you create before, or create one at this step.

Warning: If you launch your instance without a key pair, then you can't connect to it.

Next, we have to configure Network settings
- Choose "select existing security group"
- From the "Common security groups" dropdown, pick the security group you configured earlier from the Prerequisites section of this blog. If you didn't do that, go here.
In order to easily access your access your instance, check to see whether the "Auto-assign public ip" is enabled. If not, enable it to allow a public Ip to be associated with your instance when it is launched.

Keep the other default selections, review the configurations for your instance and confirm instance launch.
On the Instances screen, you could monitor the status of your instance. It may take some time for the instance to launch. Just wait until the state changes to "running."
Also wait for the Status check to pass before attempting to connect to it.

Step 2: Connect to Your Instance (via SSH)

You can't connect to your instance unless:

You have the .pem file for the key pair you used to create the instance.

Your security group is configured to allow you to connect via SSH from your computer.

...so ensure that you have these setup correctly.

In the Instances page, select your instance and copy the Public IP address.

Head over to your terminal and let's connect to our instance.

The syntax for connecting to the instance is:

$ ssh -i <path_to_pem_file> user@<Instance_public_ip>

In my case, it was:

$ ssh -i ~/Downloads/Davi-test.pem ubuntu@54.175.160.84

Successful connection should look something like this:

If ssh complains about the key permission, ensure to change the permission of the .pem file to 400, using chmod. For example, by running:

sudo chmod 400 <path_to_pem_file>)

If you still can't connect to your instance, see Troubleshoot Connecting to Your Instance for assistance.

Step 3: Clean Up Your Instance

Head over to your EC2 instances page and select the instance you just created.
Click on the "Instance state" dropdown and select Terminate instance.
Amazon will then shutdown and terminate your instance. You will no longer be able to connect to it after termination.

Conclusion

Congratulations! You just provisioned a server in the AWS cloud.

I hope you enjoyed the tutorial.

If you have any questions or had any difficulty following along, kindly drop a comment below or reached out to me on LinkedIn. Till we meet again...

Stay awesome!
~ David Omokhodion.

How to Configure Remote Linux Servers Using Ansible

David Omokhodion — Tue, 18 Oct 2022 09:04:55 +0000

Imagine that you were asked to install a piece of software (e.g apache2) on 250 different Linux servers.

How would you go about it?

Well, you could decide to ssh (open a secure connection) into the servers one after the other, and install the software, but that would take an awefully long time to complete.

A more efficient approach will be to use a configuration management tool like Ansible to automate the process.

In this tutorial, you will learn how to use Ansible to target your servers and:

Install Apache web server and
Change the default timezone of your servers

Here, we will use two servers, but the procedure is similar when configuring 250 (or more) servers.

Prerequisites:

An AWS account
A linux machine (could be a VM)

Let's go...

From an Architectural standpoint, this is how Ansible works:

Step 1: Install Dependencies

For Ansible to function properly you need to ensure you have Python and softwares-properties-common installed. Run the following commands to install them:

$ sudo apt install software-properties-common

$ sudo apt install python3

And then install ansible:

$sudo apt install ansible

Confirm Ansible installation:

$ ansible-playbook -v

Step 2: Provision servers on AWS

For this tutorial, I will provision two Ubuntu servers(EC2 instances on AWS). If you don't already know how to do that, follow the instruction here.

Important:
When you provision your servers, ensure that you download the privatekey file(the file with the ".pem" extension), and that you note down the public ip addresses of the provisioned EC2 instances.
Also, for ease, I like to move my privatekeys to my ~/.ssh/ folder. So mine is located at ~/.ssh/Davi-test.pem

Also ensure that your security group allows ssh and web traffic into the server.

Step 3: Setup host-inventory

Create a directory for my this project

$ mkdir ansible_proj && cd ansible_proj

Then create your host-inventory file:

$ touch host-inventory

Next, using your favourite text editor (vi, nano or even VScode) add the ip addresses (or hostnames) of your servers. Like this:

and save.

You would notice that I grouped all my servers under "webservers."

Grouping targets like this makes it easy to separate different groups of machines and this often comes in handy.

Next, you need to tell ansible how to locate your host-inventory file. If you don't, ansible will try to get it from /etc/ansible/hosts.

But since we have the file at ~/ansible_proj, go ahead and do:

export ANSIBLE_INVENTORY=~/ansible_proj/host-inventory

and we're ready to go.

Step 4: Create the Ansible Playbook

touch test.yaml

And then, using your favourite text editor, paste in the following code in the test.yaml file:

---
  - name: Setup Web Server
    hosts: webservers
    become: true
    become_method: sudo
    tasks:
      - name: Install Apache Server
        apt: name=apache2 state=present

      - name: Set timezone to Africa/Lagos
        timezone:
          name: Africa/Lagos

and save.

In the yaml, we target the webserver group using

hosts: webservers

, and we describe 2 tasks, using the apt and timezone modules respectively.

Step 5: Test the connection

Before proceeding with this step, ensure that your $ANSIBLE_INVENTORY variable is set in your current bash as describe previously.

Based on the location of the key you got earlier, you will need to run:

$ ansible --private-key PRIVATEKEY_FILE -u USER HOST_GROUP -m ping

I want to connect as the "ubuntu" user and target the servers under "webservers" host group. So that will be:

$ ansible --private-key ~/.ssh/Davi-test.pem -u ubuntu webservers -m ping

Step 6: Test the Playbook

Before we run our ansible playbook, it is important to test using the "--check" flag along with the ansible-playbook command. Like this:

$ ansible-playbook --private-key ~/.ssh/Davi-test.pem -u ubuntu test.yaml --check

The output should look something like this:

Before you go ahead to finally run the playbook, ssh into any of the servers and check whether apache2 is running and confirm the timezone. If you don't know how to ssh into your server, go here.

I checked inside one of my servers, and here is what I got:

Apache2 was not not installed and timezone was Etc/UTC.

Now let's run the playbook:

Step 7: Run the Ansible playbook

Apply the intended changes to the servers by running the command we used to check, but without the "--check" flag. i.e

$ ansible-playbook --private-key ~/.ssh/Davi-test.pem -u ubuntu test.yaml

If there are no errors and everything goes well, then ssh into any of the servers and try check apache2 and timezone again. Here's what I got:

Awesome!, right? Ansible did it's thing again!.

Before you leave, here's a little exercise:

Try adjusting the timezone to a different one within the test.yaml and run it again to see what happens.

Step 8: Clean up

Finally, if you don't need the servers for other reasons, ensure that you terminate them from the AWS console to avoid racking up unnecessary bills.

Conclusion

Hey,

I hope you enjoyed this tutorial, and I hope that you learned a thing or two about Ansible.

As of the time of writing this tutorial, I just got started with Ansible myself, but I'll be using it a lot from now on because I think it's an awesome tool.

If you have any questions, or comments, you can leave them below, or reach out to me on LinkedIn. Till we meet again...

Stay awesome!
~ David Omokhodion