DEV Community: ontrack

I Stopped Learning Cloud Networking as Services

ontrack — Sat, 05 Sep 2026 11:55:18 +0000

I Stopped Learning Cloud Networking as Services

The moment I started thinking about packets instead of memorizing cloud products.

For a while, cloud networking felt like a list of services I needed to memorize.

VPC.

Subnet.

Route table.

Security group.

NAT Gateway.

Internet Gateway.

Network ACL.

The more services I learned, the more complicated networking seemed.

Then I changed the way I looked at it.

Instead of asking:

"What does this AWS service do?"

I started asking:

"Where is the packet going?"

That question made cloud networking much easier.

Start with the packet

Imagine a Linux server trying to reach another server.

The packet has:

Source IP
Destination IP
Protocol
Source port
Destination port

The machine then has to figure out where to send it.

Linux gives us tools to inspect that process.

For example:

ip addr

shows the interfaces and addresses.

And:

ip route

shows how the operating system decides where traffic should go.

You can think of the route table as a set of directions:

Destination
    ↓
Route
    ↓
Next hop
    ↓
Network interface

That same way of thinking works surprisingly well in the cloud.

Then move the idea into a VPC

Take a simple architecture:

VPC
└── Private Subnet
    └── EC2

The EC2 instance needs to reach something outside its subnet.

Don't start with:

"Which AWS service do I need?"

Start with:

"Where is the destination?"

Then:

"What route should the packet follow?"

You might eventually discover a path such as:

EC2
  ↓
Subnet
  ↓
Route Table
  ↓
NAT Gateway
  ↓
Internet

Now the architecture isn't a collection of AWS services anymore.

It's a packet path.

That mental shift matters.

Linux already taught us most of this

Before cloud networking, Linux was already teaching us the fundamentals.

You had:

ip addr
ip route
ss
ping
traceroute
dig
iptables
nftables

Each tool answers a different networking question.

For example:

dig example.com

asks:

"Can I resolve the name?"

While:

ip route

asks:

"Where will my machine send the traffic?"

And:

ss -tulpn

asks:

"What is actually listening on this machine?"

These questions don't disappear when you move into AWS.

They simply become part of a larger system.

Cloud networking adds another layer

This is where things become interesting.

A request might travel through several layers:

Application
    ↓
Linux networking
    ↓
Cloud network interface
    ↓
Subnet
    ↓
Route table
    ↓
Cloud security controls
    ↓
Network gateway
    ↓
Destination

If something fails, don't immediately change everything.

Find the layer where the packet stopped.

That is much more useful than guessing.

The firewall is only one piece

A common troubleshooting mistake is assuming:

"The security group must be blocking it."

Maybe.

But networking can fail before the firewall even becomes the problem.

For example:

DNS failure
     ↓
Wrong destination IP
     ↓
Missing route
     ↓
Network filtering
     ↓
Linux firewall
     ↓
Application not listening

All of these can produce what looks like:

"The server can't connect."

The symptom is similar.

The cause isn't.

The question I use now

When something can't connect, I start with five questions:

1. What is the destination IP?

2. Which route should handle it?

3. What is the next hop?

4. Where can the traffic be allowed or blocked?

5. What is supposed to receive the connection?

This works whether I'm looking at a Linux server or a cloud environment.

Why this changed how I learn AWS

I stopped trying to memorize isolated definitions.

Instead of:

"A NAT Gateway does X."

I think:

"A private workload needs an outbound path."

Instead of:

"A route table contains routes."

I think:

"The packet needs a decision about where to go."

Instead of:

"A security group allows traffic."

I think:

"Something needs to decide whether this connection is permitted."

The terminology becomes easier once the problem makes sense.

The real advantage of Linux knowledge

Cloud platforms abstract away a huge amount of networking.

That's convenient.

But abstraction can also hide what's happening.

Linux gives you a place where you can see many of the fundamentals directly:

interfaces
addresses
routes
sockets
DNS
firewall rules

That knowledge becomes extremely valuable when cloud networking doesn't behave the way you expect.

You can go one layer deeper.

Final thoughts

I don't think cloud engineers need to memorize every networking service.

I'd rather understand how a packet moves.

Start here:

Who sent it?

Where is it going?

What route handles it?

What happens next?

What can block it?

Who receives it?

Once you start thinking this way, VPCs stop looking like complicated cloud diagrams.

They start looking like something much simpler:

A collection of decisions about where packets are allowed to go.

And that is a much better way to learn cloud networking.

Thanks

The Terraform Advantage

ontrack — Sat, 05 Sep 2026 11:49:32 +0000

The Terraform Advantage: Infrastructure That Can Explain Itself

Why I think Terraform is more than an infrastructure deployment tool.

When I first started working with Terraform, I thought its main advantage was simple:

It creates cloud infrastructure without making me click through the AWS console.

That's useful.

But the more I use it, the more I think that's actually one of the least interesting things about Terraform.

The real advantage is that Terraform gives infrastructure something that manual infrastructure often doesn't have:

A clear explanation of what should exist, why it exists, and what will change before the change happens.

The problem with clicking everything

Imagine creating an AWS environment manually.

You create a VPC.

Then subnets.

Then route tables.

Then security groups.

Then EC2 instances.

Then IAM roles.

Then load balancers.

A few weeks later, someone asks:

"Why does this security group allow that traffic?"

You might have to search through the AWS console and try to remember.

With Terraform, the answer can be sitting in a .tf file.

For example:

resource "aws_security_group" "web" {
  name = "web-server"

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }
}

The configuration isn't just instructions.

It's documentation that can actually create the infrastructure.

That's a powerful difference.

Terraform makes infrastructure reviewable

One of my favorite Terraform commands is:

terraform plan

Before changing infrastructure, Terraform shows what it intends to do.

That changes the workflow completely.

Instead of:

"I think this change is safe."

You can have:

"Here is exactly what Terraform wants to change."

For example:

Plan: 2 to add, 1 to change, 0 to destroy.

That gives engineers an opportunity to stop and ask:

"Why is Terraform destroying this resource?"

That question can prevent a very bad production deployment.

Infrastructure becomes part of the codebase

This is where Terraform becomes especially useful.

Your application has:

Git
Pull requests
Code review
CI/CD
Tests
History

Why shouldn't infrastructure have the same treatment?

With Terraform, infrastructure can live alongside the same engineering workflow.

A change can look like:

Developer
    ↓
Change Terraform
    ↓
Git commit
    ↓
Pull request
    ↓
terraform plan
    ↓
Review
    ↓
Apply
    ↓
Infrastructure

Now infrastructure changes aren't mysterious console actions.

They are changes that can be reviewed.

The same infrastructure can be recreated

Another reason I prefer Terraform is repeatability.

Imagine you manually build a development environment.

Then someone asks:

"Can we create the same environment for testing?"

With manual infrastructure, you have to remember what you created.

With Terraform, the configuration already describes it.

You can use variables for different environments:

environment = "development"

or:

environment = "production"

The architecture can remain consistent while the values change.

This makes Terraform especially useful when you need development, staging, and production environments that follow the same design.

Terraform doesn't care only about one cloud

Another major advantage is that Terraform isn't limited to one infrastructure platform.

A single Terraform workflow can manage resources across different providers.

For example:

AWS
Azure
Kubernetes
GitHub
Cloudflare
DNS providers

That doesn't mean every organization needs multi-cloud infrastructure.

It means you don't necessarily need a completely different infrastructure workflow every time another platform enters the environment.

Terraform's provider model is one of the reasons it can manage both cloud and non-cloud services through a common configuration approach.

Modules turn infrastructure into building blocks

Terraform also becomes much more interesting when you start using modules.

Instead of repeatedly writing the same infrastructure:

VPC
Subnets
Security Groups
IAM
Load Balancer

you can package a common architecture into a module.

Then another project can reuse it.

For example:

module "network" {
  source = "./modules/network"

  environment = "production"
  cidr_block  = "10.0.0.0/16"
}

Now infrastructure can be treated like a reusable software component.

That can dramatically reduce duplication.

Terraform doesn't eliminate mistakes

This is important.

Terraform isn't magic.

You can still write bad Terraform.

You can still destroy the wrong resource.

You can still create overly permissive security groups.

You can still lose control of your state.

Terraform simply gives you better tools for managing those risks.

That's why I don't think the real question is:

"Can Terraform make infrastructure perfect?"

It can't.

The better question is:

"Can Terraform make infrastructure easier to understand, review, reproduce, and control?"

For me, the answer is yes.

The part I value most

If I had to choose one reason to use Terraform, it wouldn't be multi-cloud.

It wouldn't even be automation.

It would be visibility.

When infrastructure is written as code, I can open the repository and start understanding the environment.

I can see:

What exists
What depends on what
Which resources belong together
What changed
Who changed it
What Terraform plans to do next

That is difficult to achieve with infrastructure that exists only through console clicks.

Terraform changes the mindset

The biggest change isn't technical.

It's mental.

Without infrastructure as code, the mindset can become:

"How do I create this server?"

With Terraform, it becomes:

"What should the infrastructure look like?"

That is a much better question.

You stop thinking only about individual servers and start thinking about the entire desired environment.

For example:

Network
   ↓
Security
   ↓
Compute
   ↓
Storage
   ↓
Application
   ↓
Monitoring

Terraform can represent those relationships as code.

So, is Terraform the best?

I don't think there is one infrastructure tool that is objectively the best for every organization.

CloudFormation can make sense for AWS-focused teams.

Pulumi can be attractive if you want to use general-purpose programming languages.

OpenTofu is another important option in the Terraform ecosystem.

The right tool depends on the environment, team, requirements, and existing workflows.

But Terraform remains my preferred choice when I want infrastructure that is:

Declarative
Repeatable
Reviewable
Version-controlled
Reusable
Provider-independent

And that's why I keep coming back to it.

Terraform isn't just a way to create infrastructure.

It gives infrastructure a language.

And once infrastructure can be expressed as code, it becomes much easier to review, improve, reproduce, and understand.

That's the real Terraform advantage.

thanks ontrack

Automating AWS IAM with Python

ontrack — Sat, 05 Sep 2026 11:41:55 +0000

Hello There , here some docs about Automating AWS IAM with Python: Practical Patterns for Safer Access

Practical IAM automation patterns using Boto3, role design, and least-privilege principles.

Managing AWS IAM manually works when you have a few resources and a small team.

Then the environment grows.

A few roles become dozens. Temporary access becomes permanent. Someone creates a policy with * because "it was only for testing." Another person copies an existing role and changes two permissions. Eventually, nobody is completely sure which role exists for which workload.

That is where IAM automation becomes useful.

Python and Boto3 can turn IAM from something we click through in the AWS Console into something we can define, review, reproduce, and automate.

The goal isn't simply to automate IAM API calls.

The goal is to make access predictable and intentionally limited.

Why automate IAM?

IAM is configuration, but it is also security configuration.

That makes manual changes particularly uncomfortable.

Imagine deploying three environments:

development
staging
production

Each environment has applications that need access to different AWS resources.

Without automation, you might end up manually creating:

app-dev-role
app-staging-role
app-production-role

Then attaching policies to each one.

The problem isn't creating the roles.

The problem is keeping them consistent.

Automation gives us a repeatable process:

Python configuration
        ↓
Validate desired access
        ↓
Create/update IAM role
        ↓
Create/update policy
        ↓
Attach policy
        ↓
Verify configuration

Now IAM changes can be reviewed like code.

The IAM model we actually need

Before writing Python, it helps to separate two concepts that are often confused.

Trust policy

The trust policy answers:

Who is allowed to assume this role?

For example, an EC2 instance, Lambda function, or another AWS account might be allowed to assume a role.

Permissions policy

The permissions policy answers:

What can the role do after it is assumed?

For example:

s3:GetObject
s3:ListBucket

These are different responsibilities.

A role can have the correct permissions but an overly broad trust policy.

It can also have a tightly restricted trust policy but excessive permissions.

Good IAM design requires both sides to be intentional.

Setting up Boto3

Install Boto3:

pip install boto3

Then create an IAM client:

import boto3

iam = boto3.client("iam")

Boto3 uses the AWS credential/provider chain rather than requiring credentials to be hard-coded into the Python script.

For example, you can work with a configured AWS profile:

import boto3

session = boto3.Session(profile_name="dev")
iam = session.client("iam")

Avoid putting access keys directly into source code.

Pattern 1: Define policies as Python data

Instead of scattering IAM JSON throughout the program, define policies as Python dictionaries.

For example:

backup_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::company-backups"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::company-backups/*"
        }
    ]
}

This gives us something important:

IAM configuration becomes data.

Once permissions are represented as data, we can validate them, test them, generate them, and store them in Git.

Pattern 2: Create the role separately from its permissions

Let's create a role for our application.

First, define the trust relationship:

import json
import boto3

iam = boto3.client("iam")

trust_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

response = iam.create_role(
    RoleName="backup-reader",
    AssumeRolePolicyDocument=json.dumps(trust_policy),
    Description="Role used by the backup application"
)

print(response["Role"]["Arn"])

The important part is:

"Principal": {
    "Service": "ec2.amazonaws.com"
}

We are saying that EC2 is allowed to assume the role.

This does not mean the EC2 workload automatically has access to S3.

The role still needs permissions.

Pattern 3: Attach only the permissions the application needs

Now we can create a managed policy.

policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::company-backups"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::company-backups/*"
        }
    ]
}

Create the policy:

response = iam.create_policy(
    PolicyName="BackupReaderPolicy",
    PolicyDocument=json.dumps(policy),
    Description="Read-only access to the company backup bucket"
)

policy_arn = response["Policy"]["Arn"]

Then attach it:

iam.attach_role_policy(
    RoleName="backup-reader",
    PolicyArn=policy_arn
)

A complete small example

Putting the pieces together:

import json
import boto3

ROLE_NAME = "backup-reader"
POLICY_NAME = "BackupReaderPolicy"

iam = boto3.client("iam")

trust_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

permissions_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::company-backups"
        },
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::company-backups/*"
        }
    ]
}

role = iam.create_role(
    RoleName=ROLE_NAME,
    AssumeRolePolicyDocument=json.dumps(trust_policy),
    Description="Read-only backup access"
)

policy = iam.create_policy(
    PolicyName=POLICY_NAME,
    PolicyDocument=json.dumps(permissions_policy),
    Description="Read-only access to backup objects"
)

iam.attach_role_policy(
    RoleName=ROLE_NAME,
    PolicyArn=policy["Policy"]["Arn"]
)

print(f"Created role: {role['Role']['Arn']}")
print(f"Created policy: {policy['Policy']['Arn']}")

This works as a demonstration, but I would not stop here for production.

Why?

Because running it twice can fail when the role or policy already exists.

That brings us to a more interesting problem.

IAM automation should be idempotent

A good automation script should be safe to run repeatedly.

Consider:

python iam_setup.py

The first run creates everything.

What should happen on the second run?

Ideally:

Role already exists
        ↓
Check its configuration
        ↓
Policy already exists
        ↓
Check/update its version
        ↓
Verify attachment
        ↓
Done

Not:

EntityAlreadyExistsException

This is one of the biggest differences between a quick automation script and a useful infrastructure tool.

A simple existence check can be implemented like this:

def role_exists(iam, role_name):
    try:
        iam.get_role(RoleName=role_name)
        return True
    except iam.exceptions.NoSuchEntityException:
        return False

Then:

if role_exists(iam, ROLE_NAME):
    print(f"{ROLE_NAME} already exists")
else:
    iam.create_role(
        RoleName=ROLE_NAME,
        AssumeRolePolicyDocument=json.dumps(trust_policy)
    )

This pattern can be extended to policies, attachments, tags, and trust relationships.

Role design: one role, one responsibility

A useful rule for IAM design is:

A role should represent a workload or responsibility, not a collection of unrelated permissions.

For example, avoid creating:

ApplicationEverythingRole

with:

S3
DynamoDB
EC2
RDS
IAM
Lambda
CloudWatch
Secrets Manager

Instead, consider roles based on actual workload responsibilities:

orders-api-role
backup-reader-role
monitoring-role
deployment-role

Then permissions follow the workload.

For example:

orders-api-role
    ├── DynamoDB access
    ├── SQS access
    └── CloudWatch logging

backup-reader-role
    └── S3 read access

monitoring-role
    └── CloudWatch read access

This makes access easier to understand and audit.

Don't confuse "working" with "least privilege"

This is probably the most important lesson in IAM automation.

Suppose your application receives:

AccessDenied

The fastest solution is tempting:

"Action": "*",
"Resource": "*"

The application works.

But the security model is now much worse.

Instead, identify the exact API call that failed.

If the application needs:

s3:GetObject

give it:

"Action": "s3:GetObject"

not:

"Action": "s3:*"

And if possible, restrict the resource:

"Resource": "arn:aws:s3:::company-backups/*"

rather than:

"Resource": "*"

Least privilege is not about making policies tiny for the sake of being tiny.

It is about making the permissions match the actual job.

Use conditions when they make sense

Actions and resources are only part of the IAM policy.

Conditions can provide another layer of control.

For example:

"Condition": {
    "StringEquals": {
        "aws:RequestedRegion": "ap-northeast-2"
    }
}

Now the permission can be constrained by context.

Conditions can be useful for things such as:

source VPC endpoints
requested regions
resource tags
principal tags
MFA requirements
request attributes

The exact condition should depend on the threat model and workload.

The important idea is:

Don't automatically treat every permission as unconditional.

Tags make automated IAM easier to manage

If you create IAM resources programmatically, tag them.

For example:

tags = [
    {
        "Key": "ManagedBy",
        "Value": "Python"
    },
    {
        "Key": "Environment",
        "Value": "Production"
    },
    {
        "Key": "Application",
        "Value": "Backup"
    }
]

Then:

iam.create_policy(
    PolicyName=POLICY_NAME,
    PolicyDocument=json.dumps(permissions_policy),
    Description="Read-only backup access",
    Tags=tags
)

Now you can answer questions such as:

Which IAM resources are managed automatically?
Which application owns this policy?
Which environment is this role for?

A better architecture: configuration first

For larger projects, I wouldn't hard-code every role inside Python.

Instead, imagine a configuration file:

roles:

  backup-reader:
    trusted_service: ec2.amazonaws.com

    permissions:
      - actions:
          - s3:GetObject
        resources:
          - arn:aws:s3:::company-backups/*

      - actions:
          - s3:ListBucket
        resources:
          - arn:aws:s3:::company-backups

Python becomes the engine that translates this configuration into AWS resources.

The architecture becomes:

YAML / JSON
     ↓
Validation
     ↓
Python
     ↓
Boto3
     ↓
AWS IAM

Now changing access doesn't necessarily mean changing application logic.

You change the desired configuration.

Add a "plan" mode before making changes

This is another pattern I strongly recommend.

Before changing IAM, show what the script intends to do.

For example:

IAM PLAN

Role:
  backup-reader

Trust:
  ec2.amazonaws.com

Permissions:
  s3:GetObject
  s3:ListBucket

Resources:
  arn:aws:s3:::company-backups/*
  arn:aws:s3:::company-backups

Then require an explicit flag:

python iam.py --plan

versus:

python iam.py --apply

This gives you a chance to catch mistakes before they become AWS changes.

It also makes the tool much easier to integrate into CI/CD.

Treat IAM changes like code

Once IAM is automated, put the configuration in Git.

For example:

iam-automation/
├── policies/
│   ├── backup-reader.json
│   └── monitoring.json
├── roles/
│   ├── backup-reader.json
│   └── monitoring.json
├── iam.py
├── requirements.txt
└── README.md

Now a permission change can go through:

Developer
   ↓
Git commit
   ↓
Pull request
   ↓
Review
   ↓
Validation
   ↓
CI/CD
   ↓
AWS

That is a major improvement over:

Someone opens AWS Console
        ↓
Clicks around
        ↓
Changes a policy
        ↓
Nobody knows why

Validate before deploying

Automation can make bad changes very quickly.

So automation needs guardrails.

AWS IAM Access Analyzer can validate IAM policies and help identify overly permissive access.

A useful pipeline could therefore look like:

Policy definition
       ↓
JSON/schema validation
       ↓
IAM policy validation
       ↓
Security review
       ↓
Plan
       ↓
Apply
       ↓
Verification

The Python script shouldn't be the only safety mechanism.

Don't create long-lived credentials for automation

Another important distinction:

Automating IAM doesn't mean creating access keys everywhere.

For AWS workloads, prefer temporary credentials and IAM roles where possible.

For example:

EC2
  ↓
IAM Role
  ↓
Temporary credentials
  ↓
AWS API

rather than:

EC2
  ↓
Hard-coded access key
  ↓
AWS API

This reduces the number of secrets you have to manage.

What I would automate first

If you're building your first IAM automation project, don't try to automate the entire AWS account on day one.

Start small.

I'd automate these operations first:

1. Create role
2. Configure trust policy
3. Create customer-managed policy
4. Attach policy
5. Add tags
6. Verify configuration
7. Detect drift
8. Produce a plan before changes

Then add:

9. Policy version management
10. Access review
11. Unused permission detection
12. CI/CD integration
13. Multi-account support

This progression keeps the project understandable while giving you room to grow it.

A practical mental model

When designing IAM automation, I use five questions.

1. Who?

Who should be able to assume this role?

EC2?
Lambda?
Another AWS account?
Human identity?
CI/CD system?

2. What?

What actions does the workload actually perform?

s3:GetObject?
dynamodb:GetItem?
logs:PutLogEvents?

3. Where?

Which resources should those actions apply to?

Specific bucket?
Specific table?
Specific log group?

4. Under what conditions?

Can the permission be restricted further?

Region?
Tags?
Network path?
MFA?
Principal attributes?

5. How do we prove it?

Can we validate and monitor the access?

Policy validation
Access Analyzer
CloudTrail
Code review
Automated tests

If you can answer those five questions, your IAM design is usually heading in the right direction.

Final thoughts

IAM automation isn't really about Python.

Python is simply the tool that lets us turn our access model into something repeatable.

The bigger idea is:

Manual IAM
    ↓
Defined IAM
    ↓
Automated IAM
    ↓
Validated IAM
    ↓
Auditable IAM

Boto3 gives us the API layer. The important engineering work is deciding what access should exist and why.

Start with the workload.

Define the trust relationship.

Define the minimum permissions.

Restrict the resources.

Add conditions where useful.

Put the configuration in Git.

Validate before applying.

And make the automation safe to run more than once.

The best IAM automation isn't the script that creates the most roles.

It's the one that makes it difficult to accidentally create too much access.

Useful References

AWS IAM — Policies and permissions
AWS IAM — Least-privilege permissions
Boto3 IAM documentation
Boto3 IAM examples