DEV Community: Ilyas Rufai

IAM Role Design Patterns for Multi-Account AWS Environments

Ilyas Rufai — Wed, 24 Jun 2026 04:09:26 +0000

Your team starts with one AWS account. Six months later, you have five: production, staging, shared services, security, and a sandbox nobody remembers creating. Someone creates an Admin IAM user in each account. CI/CD stores access keys in three different secret stores. An auditor asks who assumed full access in production last Tuesday, and the answer is a spreadsheet.

Multi-account AWS is a security win, but only if access is role-based, scoped, and observable. Copying single-account IAM habits into an organization creates credential sprawl, unclear blast radius, and reviews that fail the moment someone says "shared admin user."

In this article, you will learn five IAM role design patterns that scale across AWS Organizations, when to use each one, and how to implement them with trust policies, guardrails, and Terraform.

Who this is for: Platform engineers, DevSecOps engineers, and cloud architects building or maturing multi-account AWS environments.

What you will learn: How to design roles for humans, automation, audit, cross-account resources, and third-party access, without defaulting to long-lived keys or duplicated admin policies.

Prerequisites:

Basic familiarity with IAM roles and policies
An AWS Organization (or plans to adopt one)
Optional: Terraform for the implementation snippets

Related work: If you are new to role-based EC2 access in a single account, start with Terraform EC2 and S3 Upload Access.

TL;DR

Use IAM Identity Center (successor to AWS SSO) for human access across accounts, not IAM users in every account.
Give CI/CD a dedicated role in a tooling account that assumes short-lived deployment roles in workload accounts.
Centralize audit with read-only cross-account roles into a security/logging account wired to CloudTrail and AWS Config.
For shared resources (S3, KMS), combine resource policies with role trust and do not make roles overly broad to "make it work."
Lock the org with Service Control Policies (SCPs); use permission boundaries on custom roles so teams cannot escalate past intent.
Every cross-account trust policy should name a specific principal, add conditions (aws:PrincipalOrgID, aws:PrincipalAccount), and be visible in CloudTrail.

Why single-account IAM thinking fails at scale

Habit from one account	What breaks in multi-account
IAM users with access keys per engineer	Keys multiply; rotation and offboarding become error-prone
One `AdministratorAccess` role cloned everywhere	No separation between prod and sandbox; blast radius is the whole org
CI/CD keys stored per environment	Leaked key in staging can affect production if policies are loose
"We'll clean it up later" bucket policies	Cross-account access becomes permanent `Principal: "*"` debt

Key idea: In multi-account AWS, identity lives in one place, authorization is scoped per account and per job function, and guardrails apply above IAM with SCPs.

Reference account model

You do not need a perfect landing zone on day one, but roles make more sense when accounts have intent:

Organization
├── Security OU
│   └── security-audit (log archive, read-only aggregation)
├── Infrastructure OU
│   └── shared-networking (optional)
├── Workloads OU
│   ├── prod
│   ├── staging
│   └── dev
└── Sandbox OU
    └── sandbox

Each pattern below maps to a different trust direction. Mixing them into one "super role" is the most common design mistake.

Pattern 1 — Human access with IAM Identity Center

Use when: Engineers, operators, or auditors need console or CLI access to multiple accounts.

Do not: Create IAM users in every account and email access keys.

IAM Identity Center issues short-lived credentials via permission sets mapped to groups (for example, PlatformAdmins, Developers, ReadOnlyAuditors). AWS automatically creates corresponding roles in member accounts.

Design rules:

Map job function to permission sets, not individuals to admin.
Prefer ReadOnlyAccess or custom read sets for most engineers; reserve power access for break-glass workflows.
Use account assignments so Developers get PowerUserAccess in dev but ReadOnlyAccess in prod.
Enable IAM Identity Center in the management account (or a dedicated identity account if your org design uses one).

Verification signal: A user in the Developers group can open the dev account console but receives AccessDenied when attempting the same action in prod.

IAM Identity Center → Permission sets; predefined

IAM Identity Center → Permission sets; custom

Pattern 2 — CI/CD deployment role (tooling → workload)

Use when: GitHub Actions, GitLab CI, Jenkins, or CodePipeline deploys infrastructure or applications into workload accounts.

Trust flow:

Tooling account (CI role)
        |
        | sts:AssumeRole
        v
Workload account (deployment role)
        |
        v
Deploy EC2 / ECS / Lambda / Terraform resources

Trust policy in the workload account (deployment role)

This role lives in production (or staging) and trusts a specific role in the tooling account, not the whole organization.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowToolingDeployRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/github-actions-deploy"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-a1b2c3d4e5"
        }
      }
    }
  ]
}

Permissions policy on the deployment role (example)

Scope to what the pipeline actually does, not AdministratorAccess.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DeployApplicationStack",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ecs:UpdateService",
        "ecs:DescribeServices",
        "iam:PassRole"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "ecs-tasks.amazonaws.com"
        }
      }
    }
  ]
}

Terraform: workload account role

variable "tooling_account_id" {
  type = string
}

variable "organization_id" {
  type = string
}

variable "tooling_deploy_role_name" {
  type    = string
  default = "github-actions-deploy"
}

resource "aws_iam_role" "workload_deploy" {
  name = "deployment-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid    = "AllowToolingDeployRole"
      Effect = "Allow"
      Principal = {
        AWS = "arn:aws:iam::${var.tooling_account_id}:role/${var.tooling_deploy_role_name}"
      }
      Action = "sts:AssumeRole"
      Condition = {
        StringEquals = {
          "aws:PrincipalOrgID" = var.organization_id
        }
      }
    }]
  })
}

Design rules:

One deployment role per environment (deployment-role-prod, deployment-role-staging).
CI authenticates to the tooling account first (prefer OIDC federation, not stored keys).
Pipeline assumes the workload role immediately before deploy steps.
Add aws:PrincipalAccount if multiple accounts exist in the org and you want extra-tight trust.

Verification signal: CloudTrail shows AssumeRole from the tooling role ARN into the workload deployment role, followed only by expected API calls, no stray iam:CreateUser.

Pattern 3 — Central audit and security read role

Use when: A security account aggregates CloudTrail, AWS Config, GuardDuty, or Security Hub findings from member accounts.

Trust flow: Member accounts expose a read-only role that the security account (or a security automation role) can assume, or use organization-wide services (Security Hub, GuardDuty delegated admin) where applicable.

Example member-account role trust:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999999999999:role/security-read-automation"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-a1b2c3d4e5"
        }
      }
    }
  ]
}

Attach a read-only policy (SecurityAudit or tighter custom read).

Design rules:

Security account is for read and detect, not daily deploys.
Prefer organization-level service delegation (GuardDuty, Security Hub) where available instead of hundreds of custom trust relationships.
Log every cross-account assumption; alert on unexpected principals.

Verification signal: A security account can describe Config rules in member accounts but cannot ec2:TerminateInstances.

Pattern 4 — Cross-account resource access (S3 and KMS)

Use when: A workload in account A must read/write a bucket or key in account B (logs, artifacts, shared datasets).

Do not: Give the compute role in account A s3:* on * and call it done.

You need both sides:

Identity policy on the role in account A (what the role is allowed to request).
Resource policy on the bucket or KMS key in account B (what the resource allows).

S3 bucket policy (account B)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowWorkloadRoleUpload",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222222222222:role/app-upload-role"
      },
      "Action": [
        "s3:PutObject",
        "s3:AbortMultipartUpload"
      ],
      "Resource": "arn:aws:s3:::shared-artifacts-prod/uploads/*"
    }
  ]
}

Identity policy (account A, on `app-upload-role`)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WriteSharedArtifacts",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:AbortMultipartUpload"
      ],
      "Resource": "arn:aws:s3:::shared-artifacts-prod/uploads/*"
    }
  ]
}

For KMS, include kms:Encrypt, kms:GenerateDataKey, and a key policy that names the same principal.

Design rules:

Name the exact role ARN in the resource policy; avoid account-root principals unless you truly mean the entire account.
Scope to prefix (uploads/*) or specific key aliases.
Prefer moving the resource closer to the consumer account if daily cross-account access is heavy.

Verification signal: Upload succeeds from the app role; s3:DeleteObject or access from a different role fails with AccessDenied.

Pattern 5 — Third-party and vendor access with ExternalId

Use when: A SaaS vendor, partner, or integration must assume a role in your account (monitoring, backup, security scanning).

Always require sts:ExternalId in the trust policy to mitigate confused deputy problems.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::333333333333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "your-unique-external-id-from-vendor"
        }
      }
    }
  ]
}

Design rules:

One role per vendor integration; never reuse a vendor role for internal automation.
Rotate or revoke ExternalId when offboarding the vendor.
Prefer vendor-specific managed policies over ReadOnlyAccess if the vendor documents minimum requirements.

SCPs and permission boundaries: guardrails above IAM

IAM roles express intent. SCPs express organizational maximums. Permission boundaries cap what a role can ultimately grant, even if someone attaches a broader policy (by mistake).

Control	What it does	Example
SCP	Org-wide deny ceiling	Deny all actions outside `af-south-1` and `eu-west-1`
Permission boundary	Max permissions for a custom role	Allow EC2 and ECS, deny IAM and Organizations
Session policy	One-time session scoping	CLI assume-role with a tighter inline session policy

A common SCP pattern for workload accounts:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIAMUserAndAccessKeys",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateAccessKey"
      ],
      "Resource": "*"
    }
  ]
}

SCPs do not grant access; instead, they filter it. IAM roles still need explicit allow policies.

Decision matrix: which pattern when?

Need	Pattern	Primary mechanism
Engineer console/CLI access	Identity Center	Permission sets + account assignments
Pipeline deploys to prod	CI/CD deployment role	Cross-account `AssumeRole` + OIDC in tooling account
Security team visibility	Audit read role	Cross-account read + delegated security services
App writes to shared bucket	Resource + identity policy	S3/KMS policies naming specific role ARNs
Vendor integration	Vendor assume-role	Trust policy + `sts:ExternalId`
Prevent IAM users org-wide	SCP guardrail	Deny `iam:CreateUser` / `CreateAccessKey`

How to verify your design

Run this review before calling the model "done":

No long-lived IAM user keys in workload or tooling accounts for automation.
Every cross-account trust policy names a specific principal ARN (or Identity Center pattern), not *.
aws:PrincipalOrgID (or aws:PrincipalAccount) appears on cross-account trust where possible.
CloudTrail logs show who assumed which role and which API calls followed.
A negative test fails as expected (for example, staging deploy role cannot assume production role).
SCP deny rules block the risk you fear most (root usage, unapproved regions, public S3 ACLs).

Quick CLI negative test (deployment roles)

From the tooling role session, attempt to assume a role that you should not reach:

aws sts assume-role \
  --role-arn arn:aws:iam::PROD_ACCOUNT_ID:role/deployment-role \
  --role-session-name deploy-test

Repeat with the allowed workload role and confirm success. Then run a single deploy action and confirm that CloudTrail captures the chain.

When this breaks down

Account vending without role standards: New accounts get bespoke admin users because there is no template for trust policies.
Role chaining depth: Chaining multiple AssumeRole calls hits session limits and makes debugging painful; keep chains shallow.
Overloaded deployment roles: One role deploys EC2, edits IAM, and reads Secrets Manager; incident response becomes guesswork.
SCP vs IAM confusion: Teams think an IAM Allow fixes an SCP Deny; it does not.
Missing break-glass: Identity Center power access with no emergency process leads to shared root usage in outages.

Frequently asked questions

Q: Should I use IAM users at all in member accounts?

For human access, no, use IAM Identity Center. Limited exceptions exist for break-glass automation accounts with strict controls, but that is not the default pattern.

Q: Is AdministratorAccess ever okay for deployment roles?

Rarely in mature environments. Start tight; broaden only with recorded justification. Admin deploy roles turn pipeline compromise into organization compromise.

Q: Do I need a separate tooling account?

Not on day one, but CI/CD roles benefit from isolation. Many teams start with a shared-services account and split later.

Q: How does this relate to AWS Control Tower?

Control Tower encodes opinionated OU and account factory patterns. The role designs here still apply; Control Tower helps enforce account baseline and guardrails.

What I learned designing roles across accounts

Trust policies are the real contract between accounts; review them like production code.
Conditions are cheap insurance; aws:PrincipalOrgID stops a surprising amount of cross-account trust mistakes.
Readable role names (deployment-role-prod, security-read-member) beat generic cross-account-role when auditors and on-call engineers ask questions at 2 a.m.

References

Terraform EC2 and S3 Upload Access: A Simple IAM Role Setup Without Access Keys

Ilyas Rufai — Sun, 21 Jun 2026 07:05:28 +0000

You need a small virtual machine that can upload files to object storage. The fast-but-wrong path is to create an Identity and Access Management (IAM) access key, SSH into the box, and paste credentials into ~/.aws/credentials. That works once, then those keys live on disk, get copied into scripts, and eventually leak.

In this article, you will use Terraform to launch an Elastic Compute Cloud (EC2) instance and attach an IAM role so the instance can upload to one Simple Storage Service (S3) bucket without storing AWS access keys on the server.

Who this is for: Developers and DevOps engineers learning Terraform on AWS.

What you will build: One EC2 instance, one private S3 bucket, one IAM role with least-privilege upload permissions, and a working aws s3 cp test from the instance.

Prerequisites:

An AWS account with permissions to create EC2, S3, IAM, and security groups
Terraform 1.5+ installed locally
AWS CLI configured locally (aws configure)
An EC2 key pair already created in your target AWS Region (for SSH access)

Versions used in this tutorial:

Terraform 1.5+
AWS provider ~> 5.0
Amazon Linux 2023 AMI

TL;DR

Do not put IAM access keys on EC2 for S3 uploads; use an IAM instance profile instead.
Create the S3 bucket first, then attach a role policy scoped to that bucket and an uploads/ prefix.
Launch EC2 in your default virtual private cloud (VPC) with a security group that allows SSH only from your IP.
Verify access from the instance with aws s3 cp credentials that come from instance metadata automatically.
Run terraform destroy when finished to avoid ongoing EC2 charges.

Why putting access keys on EC2 fails

Approach	Why teams use it	Why it breaks
IAM user access keys on the server	Fast to test uploads	Keys sit on disk, are hard to rotate, and expand blast radius if the instance is compromised
Overly broad IAM policy (`s3:` on ``)	Fewer permission errors during setup	One compromised instance can read, delete, or overwrite unrelated buckets
Manual console clicks only	No infrastructure as code (IaC) history	Drift, no repeatable setup, hard to audit

Key idea: The EC2 instance should assume an IAM role at boot. AWS injects short-lived credentials through the instance metadata service. Your Terraform code documents exactly what the instance can do.

What you are building

Your laptop (Terraform)
        |
        v
   AWS API calls
        |
        +--> S3 bucket (uploads/ prefix)
        |
        +--> IAM role + instance profile
        |
        +--> EC2 instance (assumes role, uploads via AWS CLI)

Step 1: Create the project layout

Create a new folder and four files:

mkdir terraform-ec2-s3-upload && cd terraform-ec2-s3-upload
touch versions.tf variables.tf main.tf outputs.tf

Your layout should look like this:

terraform-ec2-s3-upload/
  versions.tf
  variables.tf
  main.tf
  outputs.tf

Step 2: Pin provider versions

Add provider constraints in versions.tf:

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

Step 3: Define input variables

Add tunable values in variables.tf:

variable "aws_region" {
  description = "AWS region to deploy resources"
  type        = string
  default     = "us-east-1"
}

variable "project_name" {
  description = "Prefix for resource names"
  type        = string
  default     = "tf-ec2-s3-demo"
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

variable "key_name" {
  description = "Existing EC2 key pair name in this region"
  type        = string
}

variable "ssh_cidr" {
  description = "Your public IP in CIDR format for SSH access (example: 203.0.113.10/32)"
  type        = string
}

Create a terraform.tfvars file with your values:

aws_region = "us-east-1"
key_name   = "your-key-pair-name"
ssh_cidr   = "YOUR_PUBLIC_IP/32"

To find your public IP:

curl -s https://checkip.amazonaws.com

Append /32 to that IP for ssh_cidr.

Step 4: Create the S3 bucket

Add the bucket and hardening settings in main.tf:

resource "aws_s3_bucket" "uploads" {
  bucket = "${var.project_name}-${data.aws_caller_identity.current.account_id}"
}

resource "aws_s3_bucket_public_access_block" "uploads" {
  bucket = aws_s3_bucket.uploads.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

data "aws_caller_identity" "current" {}

Bucket name includes your account ID to reduce naming collisions.

Step 5: Create IAM role and least-privilege S3 policy

Still in main.tf, define what the EC2 instance is allowed to do:

data "aws_iam_policy_document" "ec2_assume_role" {
  statement {
    actions = ["sts:AssumeRole"]

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

resource "aws_iam_role" "ec2_upload_role" {
  name               = "${var.project_name}-ec2-role"
  assume_role_policy = data.aws_iam_policy_document.ec2_assume_role.json
}

data "aws_iam_policy_document" "s3_upload_policy" {
  statement {
    sid    = "ListBucketPrefix"
    effect = "Allow"
    actions = [
      "s3:ListBucket",
    ]
    resources = [aws_s3_bucket.uploads.arn]
    condition {
      test     = "StringLike"
      variable = "s3:prefix"
      values   = ["uploads/*"]
    }
  }

  statement {
    sid    = "UploadObjectsOnly"
    effect = "Allow"
    actions = [
      "s3:PutObject",
      "s3:AbortMultipartUpload",
    ]
    resources = ["${aws_s3_bucket.uploads.arn}/uploads/*"]
  }
}

resource "aws_iam_policy" "s3_upload_policy" {
  name   = "${var.project_name}-s3-upload"
  policy = data.aws_iam_policy_document.s3_upload_policy.json
}

resource "aws_iam_role_policy_attachment" "attach_upload_policy" {
  role       = aws_iam_role.ec2_upload_role.name
  policy_arn = aws_iam_policy.s3_upload_policy.arn
}

resource "aws_iam_instance_profile" "ec2_profile" {
  name = "${var.project_name}-instance-profile"
  role = aws_iam_role.ec2_upload_role.name
}

This role can upload only to uploads/* inside one bucket. It cannot delete objects or read unrelated buckets.

Step 6: Use default VPC networking and security group

For a beginner-friendly setup, use the default VPC and one public subnet:

data "aws_vpc" "default" {
  default = true
}

data "aws_subnets" "default" {
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.default.id]
  }
}

resource "aws_security_group" "ec2_sg" {
  name        = "${var.project_name}-sg"
  description = "Allow SSH from your IP only"
  vpc_id      = data.aws_vpc.default.id

  ingress {
    description = "SSH from admin IP"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [var.ssh_cidr]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Step 7: Launch the EC2 instance

Add the Amazon Linux 2023 AMI lookup and EC2 instance:

data "aws_ami" "amazon_linux_2023" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*-kernel-*-x86_64"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

resource "aws_instance" "app" {
  ami                    = data.aws_ami.amazon_linux_2023.id
  instance_type          = var.instance_type
  subnet_id              = data.aws_subnets.default.ids[0]
  vpc_security_group_ids = [aws_security_group.ec2_sg.id]
  key_name               = var.key_name
  iam_instance_profile   = aws_iam_instance_profile.ec2_profile.name

  user_data = <<-EOF
              #!/bin/bash
              dnf update -y
              dnf install -y awscli
              EOF

  tags = {
    Name = "${var.project_name}-ec2"
  }
}

Add outputs in outputs.tf:

output "ec2_public_ip" {
  description = "Public IP for SSH"
  value       = aws_instance.app.public_ip
}

output "s3_bucket_name" {
  description = "Target bucket for uploads"
  value       = aws_s3_bucket.uploads.id
}

output "ssh_command" {
  description = "SSH command example"
  value       = "ssh -i ~/.ssh/${var.key_name}.pem ec2-user@${aws_instance.app.public_ip}"
}

Step 8: Initialize and apply Terraform

Run Terraform from the project folder:

terraform init
terraform plan
terraform apply

terraform init

terraform plan

terraform apply; Type yes when prompted.

Instance running:

Step 9: SSH into the instance

Use the output SSH command:

ssh -i ~/.ssh/your-key-pair-name.pem ec2-user@<EC2_PUBLIC_IP>

If the connection fails, confirm:

ssh_cidr matches your current public IP.
Your key file permissions are chmod 400.
The instance status is running.

Step 10: Verify S3 upload from EC2

On the EC2 instance, confirm AWS CLI identity:

aws sts get-caller-identity

You should see the role ARN for ${project_name}-ec2-role, not an IAM user.

Upload a test file:

echo "upload test $(date)" > /tmp/upload-test.txt
aws s3 cp /tmp/upload-test.txt s3://<BUCKET_NAME>/uploads/upload-test.txt
aws s3 ls s3://<BUCKET_NAME>/uploads/

Replace <BUCKET_NAME> with the s3_bucket_name Terraform output.

How to verify this works

Run this quick checklist:

terraform output shows ec2_public_ip and s3_bucket_name.
aws sts get-caller-identity on EC2 returns the instance role ARN.
aws s3 cp to uploads/ succeeds from EC2.
Upload to a different prefix (for example, secrets/) fails with AccessDenied.
No access keys exist in /home/ec2-user/.aws/credentials on the instance.

The last check confirms you are using role-based access, not static keys.

Clean up to avoid charges

When you finish testing:

terraform destroy

Type yes to remove EC2, IAM, and S3 resources created by this tutorial.

When this breaks down

Default VPC missing: Some AWS accounts disable the default VPC. You will need to create a VPC and public subnet first.
SSH blocked by IP change: If your home IP changes, update ssh_cidr and run terraform apply again.
Too open security groups: Never set SSH to 0.0.0.0/0 in real environments.
Policy too broad: s3:* on * is convenient for demos but unsafe for production workloads.
No remote state backend: This tutorial uses local Terraform state. For team use, move state to S3 with locking (DynamoDB).

Frequently asked questions

Q: Why not attach an IAM user access key to EC2?

Access keys are long-lived secrets. IAM roles provide temporary credentials that rotate automatically and are tied to the instance lifecycle.

Q: Can this instance read objects from S3?

Not with the policy in this tutorial. It can upload to uploads/* only. Add explicit s3:GetObject permissions only if your workload needs reads.

Q: Is this production-ready?

It is a strong learning baseline, not a production baseline. Production setups usually add private subnets, Systems Manager (SSM) Session Manager instead of public SSH, encryption, logging, and tighter network controls.

What I learned building this

IAM instance profiles are the default pattern for EC2-to-AWS service access.
Prefix-scoped S3 policies reduce damage if an instance is compromised.
Terraform makes role and bucket permissions reviewable in pull requests.

Project on GitHub

Terraform project on GitHub with EC2, IAM role, and S3 upload policy.

References

Secret Scanning in CI: What Pre-Commit, Pull Request, and Main Branch Each Actually Catch

Ilyas Rufai — Wed, 17 Jun 2026 11:32:18 +0000

A teammate pastes an AWS access key into a PR comment to "debug quickly." Another commits .env.production because .gitignore was wrong on a new microservice. A third rotates nothing after a contractor laptop compromise because "we never committed secrets, probably fine."

Secret scanners are not interchangeable at every stage of the software development lifecycle (SDLC). Running only on main means the secret already lived in git history. Running only locally means it never ran on the machine that mattered. Layers matter, and each layer should have a different job.

In this article, you will implement a practical three-layer secret-scanning model with Gitleaks and GitHub Actions, then verify each layer and handle real incidents without creating scanner fatigue.

Who this is for: Engineers owning GitHub Actions security checks for application repos.

What you'll build: Pre-commit hook, PR scan, and post-merge history scan with shared allowlist discipline.

Prerequisites: Git, GitHub repo, optional Gitleaks binary locally.

TL;DR

Use three layers with different goals: pre-commit for fast local feedback, pull request as a merge gate, and scheduled default-branch scans for hygiene.
Block merges on PR findings; treat default-branch findings as incidents plus historical cleanup.
Share one .gitleaks.toml across local and CI runs, and allowlist only specific safe paths.
Rotation and revocation matter more than history rewrite; deleting git history without credential rotation does not contain compromise.

Why one scanner in one place fails

Layer	Catches	Misses
Pre-commit	Keys before they enter any remote	Skipped hooks (`--no-verify`), new clones without hooks installed
Pull request	Keys introduced in the diff; blocks merge	Secrets only in comments, wiki, or release assets
Default branch/history	Deep scan, scheduled; finds old leaks	Still too late for keys already exfiltrated from an open PR

Treat findings like production incidents at the PR layer; treat main-branch scans as hygiene and audit evidence.

Layer 1 — Pre-commit (fast feedback)

Start with local feedback so engineers catch leaks before pushing.
Install Gitleaks and wire a hook:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks

pre-commit install

Developers see failures in under two seconds on staged files. Allowlist test fixtures explicitly, never disable rules globally:

# .gitleaks.toml (repo root)
[allowlist]
paths = [
  '''^tests/fixtures/''',
  '''^docs/examples/fake-credentials\.json$'''
]

Rule: If a path needs a real secret for tests, use a vault-injected env var in CI—not a committed file with "fake" in the name and a real-looking key format.

Layer 2 — Pull request scan (merge gate)

The PR layer is your enforcement point. Scan only the PR diff so developers are not punished for historical debt on day one:

name: Secret scan (PR)

on:
  pull_request:

permissions:
  contents: read
  pull-requests: write

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run Gitleaks on PR diff
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          config-path: .gitleaks.toml

Configure branch protection: this check is required before the merge.

Fork PRs: GITHUB_TOKEN from forks is read-only; gitleaks-action still scans the diff but cannot comment with elevated permissions, acceptable for public repos; for private repos, consider org-level secret scanning (GitHub Advanced Security) as a parallel signal.

Layer 3 — Main branch and history (hygiene)

The default-branch layer catches historical debt and supply-chain surprises.
Run a weekly full-history scan:

name: Secret scan (history)

on:
  schedule:
    - cron: "0 6 * * 1"
  workflow_dispatch:

jobs:
  gitleaks-history:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: gitleaks/gitleaks-action@v2
        with:
          config-path: .gitleaks.toml
          # no PR context: full repo scan

When this fires on main, assume rotation: revoke the credential, purge from history (git filter-repo or BFG) only after revocation—scrubbing git without rotating the secret fixes nothing.

How to verify this works

Use these checks to confirm each layer is doing the right job:

Pre-commit check: add a fake test secret string in a staged file and confirm pre-commit blocks the commit.
PR gate check: Open a test pull request with the same string and confirm the workflow fails before merge.
History scan check: run workflow_dispatch for the history workflow and confirm it scans the full repository.
Allowlist check: Place the same test token in an allowlisted fixture path and confirm scanner behavior matches your policy.

Use clearly fake values in tests and examples. Never use production-like secrets for scanner testing.

Reducing false positives without going blind

Allowlist paths, not regexes for "AWS" — Broad entropy exceptions hide real keys.
Separate example keys: Use obviously invalid formats (AKIAFAKE00000000000) in docs; scanners and humans both win.
Custom rules sparingly: Add org-specific patterns (internal API key prefix) via Gitleaks [[rules]]; do not fork the entire ruleset unless you can maintain it.
Teach the escape hatch: If pre-commit blocks a docs change, fix the example, not SKIP=gitleaks.

When a secret is found anyway

Revoke in the provider (AWS, Stripe, Slack) immediately.
Rotate dependent systems; assume compromise if the repo is public or the PR was open.
Purge history if the secret touched git; coordinate with legal/comms if customer data access was possible.
Post-incident: add a rule or allowlist fix so the same mistake is a one-liner next time.

Pair this scanning pipeline with short-lived cloud credentials (for example, OIDC-based CI federation) so leaked CI identity material has reduced blast radius.

When this breaks down

Teams can bypass local hooks, so pre-commit cannot be your enforcement layer by itself.
Diff-only PR scans do not catch existing secrets already in history, release assets, or external systems.
Aggressive allowlists can silently reduce coverage if they are not reviewed during security change management.
Scanner success can create false confidence if incident response, revocation, and rotation are weak.

Summary

Use three layers: pre-commit (speed), PR (gate), scheduled main (history).
Share one .gitleaks.toml; allowlist paths, not categories of secrets.
Block merge on PR findings; treat main-branch hits as incident + hygiene work.
Rotation beats history rewriting; scanning is detection, not prevention alone.

Amazon S3 Bucket Names Aren’t Always Globally Unique Anymore — Here’s What Changed (and Why I’m Excited)

Ilyas Rufai — Thu, 19 Mar 2026 11:54:35 +0000

I still remember the first time S3 humbled me.

I was following a “hello AWS” tutorial, feeling confident, and then S3 hit me with:

Bucket name already exists

I tried again. And again. And again.

Different names, different variations, still taken!

That’s when I learned the “classic rule”:

S3 bucket names are globally unique (within an AWS partition).

Meaning: if someone anywhere already owns that bucket name, you can’t have it.

But here’s the big update I recently learned, and it’s huge for builders, platform teams, and security folks:

Amazon S3 now supports creating general-purpose buckets inside an “account regional namespace”, which removes the “find a globally unique name” pain.

AWS announced this on Mar 12, 2026:
https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-account-regional-namespaces/

In this article, I’ll break down what changed, how it works, why it matters, and how I’d explain it if I were designing bucket naming at scale.

What used to be true (and is still true by default)

By default, general purpose buckets exist in a global namespace.

AWS puts it plainly:

“Each bucket name must be unique across all AWS accounts in all the AWS Regions within a partition.” Official docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

That means:

my-company-logs can only exist once (in that partition).
If the bucket is deleted, the name becomes available again — and someone else could recreate it later.

What changed: Account regional namespaces (Mar 2026)

AWS introduced a second option:

You can now create a general purpose bucket in a namespace reserved only for your account:

“You can also choose to create a bucket in your account regional namespace. Your account regional namespace is a subdivision of the global namespace that only your account can create buckets in.”

Official docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

AWS also summarizes the “why” in the announcement:

eliminates the need to find globally unique bucket names
makes it easier to build workloads like “one bucket per customer/team/dataset”
can be enforced using IAM policies/service control policies (SCPs)

Announcement: https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-account-regional-namespaces/

The nuance I want to keep clear:

Global namespace is still the default
But now you have a reserved namespace you can opt into

How the naming looks (the new naming convention)

Buckets in your account regional namespace follow this naming pattern:

bucket-name-prefix-accountId-region-an

Official example:

amzn-s3-demo-bucket-111122223333-us-west-2-an

Source: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

So instead of fighting to get:

my-company-logs

…you can choose a predictable prefix like:

my-company-logs

and the final name will include your account + region suffix that makes it unique to you.

Why this matters (in real systems)

1) It kills the “I spent 20 minutes naming a bucket” problem

If you’ve ever created buckets for different environments, you know this loop:

myapp-prod-logs (taken)
myapp-prod-logs-1 (taken)
myapp-prod-logs-2026 (taken)
myapp-prod-logs-<random> (finally works, but now it’s ugly)

Account regional namespaces support a much more predictable naming scheme.

2) It reduces risk after deletion (a security win)

In the shared global namespace, once a bucket is deleted, the name becomes available again. Another account can recreate the name later and potentially receive requests intended for that name.

Official docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

In contrast, for account regional namespace buckets:

Only your account can create buckets in that namespace
Another account cannot recreate your account-regional bucket name

Official docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

3) It scales for bucket-per-customer / bucket-per-team designs

AWS explicitly calls out bucket-per-customer/team/dataset workloads in the announcement:

https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-account-regional-namespaces/

That’s a very modern SaaS/platform pattern, and it’s nice to see S3 making it easier to do it safely and predictably.

Creating an account-regional namespace bucket (AWS CLI)

The official docs show creating a bucket using the AWS CLI like this:

aws s3api create-bucket \
    --bucket amzn-s3-demo-bucket-012345678910-us-west-1-an \
    --bucket-namespace account-regional \
    --region us-west-1 \
    --create-bucket-configuration LocationConstraint=us-west-1

Source: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

Note: Before you run the command, make sure your aws cli command is updated.

How I’d enforce this in an organization (IAM/SCP policy)

If I were working on a platform team, I’d want consistent naming and fewer security foot-guns. AWS provides a clean enforcement pattern using the condition key:

s3:x-amz-bucket-namespace

Here’s an example IAM policy from the docs that denies s3:CreateBucket unless the request is using account-regional:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireAccountRegionalBucketCreation",
      "Effect": "Deny",
      "Action": "s3:CreateBucket",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-bucket-namespace": "account-regional"
        }
      }
    }
  ]
}

Source: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

Bucket naming rules (still important)

Even with namespaces, S3 bucket names still follow the general naming rules, like:

3–63 characters
lowercase letters, numbers, periods (.), and hyphens (-) only
must start and end with a letter or number
no two adjacent periods
cannot look like an IP address

Official rules: https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html

Also note:

-an is reserved for account regional namespace buckets
the account/regional suffix counts toward the 63-character limit

Official docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

The mental model I use

This is how I explain it to myself:

Global namespace (default)

Like a global username system
If someone owns it, you can’t use it
If deleted, someone else might grab it later

Account regional namespace (new)

Like a reserved “username space” under my account + my region
I still choose the prefix, but uniqueness is guaranteed by the suffix
Another account can’t recreate my account-regional bucket name

Final takeaway

When I first learned S3 bucket names had to be globally unique, I accepted it as “just an AWS thing.”

But account regional namespaces feel like AWS responding to how people actually build today: lots of environments, lots of teams, and a need for predictable and secure naming.

If I’m building something new, I’d strongly consider defaulting new buckets to the account regional namespace — especially if naming conventions matter, or if I want to reduce the risk of name reuse after deletion.

References (official)

AWS announcement (Mar 12, 2026): https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-account-regional-namespaces/
Namespaces for general purpose buckets: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html
General purpose bucket naming rules: https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html

I built a zero-cost end-to-end DevOps pipeline (GitHub Actions + Docker + Kubernetes + Docker Hub)

Ilyas Rufai — Wed, 04 Mar 2026 11:27:47 +0000

I just finished a small but real DevOps project and I want to share it in case you’re trying to build your own portfolio.

The idea was simple: take a tiny app and wire the whole path from git push → CI/CD → container registry → Kubernetes, without paying for any cloud resources.

You can grab the code here:

GitHub repo: https://github.com/rufilboss/devops-e2e-pipeline
Docker Hub image: docker.io/asruf/demo-app:latest

What I built (high level)

Concretely, the project contains:

App: Tiny Flask API (app/main.py)
Container: Dockerfile (app/Dockerfile)
CI/CD: GitHub Actions workflow that builds and pushes images to Docker Hub (.github/workflows/ci-cd.yaml)
Kubernetes: Deployment + Service (k8s/*.yaml)
Terraform (optional): creates the Kubernetes namespace (terraform/*.tf)

Everything here runs for free on a local cluster (kind or minikube) and a free Docker Hub + GitHub account.

Prerequisites I used

To follow exactly what I did, you’ll want:

Git + GitHub repo
Docker
kubectl
One local Kubernetes option:
- kind (what I used), or
- minikube
Terraform (optional, only for the IaC part)
A Docker Hub account (I used mine asruf)

Project layout

This is the layout of the repo:

devops-e2e-pipeline/
├── app
│   ├── Dockerfile
│   ├── main.py
│   └── requirements.txt
├── k8s
│   ├── namespace.yaml
│   └── deployment.yaml
├── terraform
│   ├── main.tf
│   └── k8s.tf
└── .github
    └── workflows
        └── ci-cd.yaml

1) The app I used (simple Flask service)

I deliberately kept the app tiny so the focus is on the pipeline, not the code.

It exposes:

/ — info about the service (name, version, env, status)
/health — liveness
/ready — readiness

app/main.py:

import os
from flask import Flask, jsonify

app = Flask(__name__)

VERSION = os.environ.get("APP_VERSION", "1.0.0")
ENV = os.environ.get("ENV", "dev")

@app.route("/")
def index():
    return jsonify({
        "service": "demo-app",
        "version": VERSION,
        "env": ENV,
        "status": "ok",
    })

@app.route("/health")
def health():
    return jsonify({"status": "healthy"}), 200

@app.route("/ready")
def ready():
    return jsonify({"status": "ready"}), 200

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Dependencies:

app/requirements.txt:

flask>=3.0.0

The app listens on port 8080, which I re-use everywhere (Docker, Kubernetes, port-forward, etc.).

2) Containerizing it with Docker

My Dockerfile is intentionally straightforward but shows some basic good practices:

Slim base image
Non-root user
Requirements installed in their own layer

app/Dockerfile:

FROM python:3.12-slim AS runtime

WORKDIR /app

RUN adduser --disabled-password --gecos "" appuser

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt && pip freeze > requirements.lock

COPY main.py .

USER appuser
EXPOSE 8080

ENV FLASK_APP=main.py
CMD ["python", "-m", "flask", "run", "--host=0.0.0.0", "--port=8080"]

Local sanity check

From the repo root:

cd devops-e2e-pipeline

docker build -t demo-app:local ./app
docker run --rm -p 8080:8080 --name demo-app-test demo-app:local

# In another terminal:
curl -s http://localhost:8080/health
curl -s http://localhost:8080/

That gave me:

{"status": "healthy"} from /health
{"env":"dev","service":"demo-app","status":"ok","version":"1.0.0"} from /

Once that worked, I moved on to Kubernetes.

Here are the screenshots from my terminal while doing this:

3) Running it on Kubernetes (kind or minikube)

I wanted a “real” deployment with:

A dedicated namespace
2 replicas
Liveness/readiness probes
Resource requests/limits

Starting a local cluster

You can use either tool; I used kind, but here are both options.

minikube:

minikube start

kind:

kind create cluster --name demo

Here’s what that looked like for me:

Making the image visible to the cluster

Kubernetes can’t automatically see demo-app:local unless you either:

build inside the cluster’s Docker daemon (minikube), or
load the image into kind.

Option A: minikube

eval "$(minikube docker-env)"
docker build -t demo-app:local ./app

Option B: kind (what I used):

docker build -t demo-app:local ./app
kind load docker-image demo-app:local --name demo

And the kind load output:

Kubernetes manifests I used

Namespace:

k8s/namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: demo-app
  labels:
    app.kubernetes.io/name: demo-app

Deployment + Service:

k8s/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  namespace: demo-app
  labels:
    app: demo-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: app
          # Local image for kind/minikube:
          # image: demo-app:local
          # Docker Hub image (asruf/demo-app) when using CI/CD:
          image: docker.io/asruf/demo-app:latest
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
              name: http
          env:
            - name: ENV
              value: "production"
            - name: APP_VERSION
              value: "1.0.0"
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 200m
              memory: 128Mi
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: demo-app
  labels:
    app: demo-app
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
      name: http
  selector:
    app: demo-app

Applying and testing

kubectl apply -f k8s/namespace.yaml
kubectl apply -f k8s/deployment.yaml

kubectl get pods,svc -n demo-app

kubectl port-forward -n demo-app svc/demo-app 8080:80

Then in another terminal:

curl -s http://localhost:8080/health
curl -s http://localhost:8080/ready
curl -s http://localhost:8080/

Here’s the kubectl apply / kubectl get snapshot:

And the port-forward:

At this point, I had the app running as 2 replicas in a local cluster, fronted by a Service, with working probes.

4) Pushing to Docker Hub

My Docker Hub username is asruf. I first pushed manually to make sure everything worked:

docker tag demo-app:local asruf/demo-app:latest
docker push asruf/demo-app:latest

After that, the image was available at:

docker.io/asruf/demo-app:latest

That’s the image the Kubernetes manifest uses by default in this repo.

5) CI/CD with GitHub Actions → Docker Hub

I wanted the pipeline to:

Build the image on every push / PR
Push to Docker Hub on pushes (not PRs)
Tag images with:
- the commit SHA
- latest (for the default branch)

The workflow is at ./.github/workflows/ci-cd.yaml.

Docker Hub secrets

In my GitHub repo I created 2 Actions secrets:

DOCKERHUB_USERNAME — asruf
DOCKERHUB_TOKEN — a Docker Hub access token

You can find these in:

GitHub repo → Settings → Secrets and variables → Actions

What the workflow does

High level:

Check out code
Set up Buildx
Log in to Docker Hub with DOCKERHUB_USERNAME + DOCKERHUB_TOKEN
Build the Docker image from ./app
Tag it with SHA + latest
Push to docker.io/asruf/demo-app

So every push to main automatically gives me a fresh image on Docker Hub, ready for Kubernetes.

6) Optional: Terraform for the namespace

I also wanted at least one Infrastructure as Code piece in here, so I used Terraform’s Kubernetes provider to create the namespace.

terraform/main.tf (provider + versions) and terraform/k8s.tf (namespace resource) are already in the repo.

If your ~/.kube/config points at a running cluster:

cd terraform

terraform init
terraform plan
terraform apply

This is small on purpose, but it’s enough to say “I manage part of the Kubernetes infrastructure with Terraform”.

Here’s what my terraform init + terraform plan looked like:

7) How can you reuse this

If you want to adapt this project for yourself:

Fork the repo or copy the layout
Change the Docker Hub username and repo name
Update:
- k8s/deployment.yaml image: field
- GitHub Actions secrets (DOCKERHUB_USERNAME, DOCKERHUB_TOKEN)
Swap the Flask app for your own service if you like

The nice part is that the pattern stays the same:

App → Docker → Docker Hub → Kubernetes → (optional) Terraform

Once this pipeline is in your portfolio, you can honestly tell people:

“I’ve built and maintained an end-to-end CI/CD pipeline with GitHub Actions, Docker, Kubernetes, Docker Hub, and Terraform. Here’s the repo and here’s the running app.”

Final thoughts

This project is small, but it touches a lot of the buzzwords you see in job posts and freelance gigs:

GitHub Actions
Docker
Docker Hub
Kubernetes
Terraform

If you’re trying to break into DevOps or just want something concrete to show, feel free to clone my repo, run it locally, and then customize it to match your own style and stack.

Are You Planning to Get Into DevOps in 2026? A Practical Guide for the Real World

Ilyas Rufai — Wed, 24 Dec 2025 21:57:09 +0000

It’s December 2025, almost January 2026, and if you’re asking yourself “Should I start DevOps now?” Then this article is for you.

Not because DevOps is trending (it is, most companies now practice DevOps workflows and advanced automation standards), but because the demand for real DevOps skill — not surface-level tool knowledge — is only going to grow faster in the AI-augmented era we’re entering.

Why Now is the Right Time (But Also the Hardest Time)

Over the last five years, DevOps has shifted from pure automation to intelligent automation:

GitOps — treating Git as the single source of truth for infrastructure and app deployments — is becoming mainstream.
Cloud-native, serverless, and event-driven designs are reshaping how systems are built.
AI is now embedded in pipelines, observability, and even predictive deployments, automating decisions that used to require senior engineers.

The payoff? Teams deploy faster, with fewer errors, and automation frees engineers from repetitive toil.
The catch? AI can mask gaps in understanding. You can have something running and still not know why it runs, and that’s where most beginners crash.⁣

In 2026, DevOps without deep fundamentals is like driving a car you can’t fix when it breaks.

What Works (Based on Real Industry Signals)

Here’s what industry trends say about DevOps evolution:

GitOps adoption is expected to grow sharply, improving reliability and consistency.
DevSecOps — embedding security into every pipeline is essential, not optional.
Observers and AI-powered observability tools help engineers find problems before they hit users.
Serverless pipelines are reshaping how we think about infrastructure abstraction and event wiring.

These aren’t buzzwords; they are what you’ll see in job descriptions, production systems, and real-world infrastructure teams.

But First — A Reality Check

Before we talk tools: DevOps is not a checklist of technologies. It’s a cultural and engineering mindset rooted in:

Continuous Delivery
Automated, high-confidence pipelines
Reproducible infrastructure
Collaboration between development and operations

AI will help you generate configs, but it won’t give you intuition around:

Why a pipeline failed
How a Kubernetes pod behaves under pressure
What happens when your Terraform state drifts
Why observability matters more than logging

That intuition is what separates copy-paste from craftsmanship.

The Practical DevOps Path

Here’s how you should think about your journey if you’re starting now:

1. Master Linux and Command Line

Everything in DevOps runs on CLI, shells, permissions, networking, logs, and processes. Your laptop is your first “cluster.”
If you can’t diagnose why SSH fails, nothing else will help.

In 2026, this fundamental still underpins container workloads, cloud instances, observability agents, and automation scripts.

2. Scripting & Automation

If you automate only once manually, that’s already DevOps:

Bash/Python/Go for straightforward automation
Tools like Make, just to organize tasks
A mindset of automate early, fix once

AI can suggest scripts — but always read and refactor them yourself.

3. Containers & Microservices

Docker, Kubernetes, and sidecar architectures aren’t going anywhere.
These technologies form the backbone of cloud-native systems and service distribution.

Remember:

Docker makes shipping easier; Kubernetes makes scaling easier —
you still need to know what each component does.

4. Real Cloud Practice (Practically)

Cloud isn’t just AWS, Azure, or GCP; it’s how production systems run. AI-native cloud services are replacing old workloads, and multi-cloud/hybrid strategies are increasingly popular.

Instead of incurring huge bills while you learn, consider tools like LocalStack (https://github.com/localstack/localstack) — it lets you practice cloud APIs locally without risk. That’s real hands-on learning.

5. CI/CD and Beyond (From Commit to Deployment)

This is where theory intersects practice.

You won’t just be writing pipelines, you treat them like policies:

Automated testing
Security scanning
Version-controlled provisioning
Fast rollback strategies

In 2026, AI isn’t replacing CI/CD engineers, it’s augmenting them via smart predictions and autonomous decision loops.

6. Security & Resilience

DevSecOps is now standard practice:
Security checks must happen before deployments, not after!

You need broad fluency with:

Secrets management (Vault, AWS Secrets Manager)
Policy as code (OPA, Kyverno)
Automated vulnerability scanning

Security is not a separate discipline; it’s a microbial process embedded throughout your pipelines.

How AI Helps (And When It Hurts)

✔️ Where AI Adds Massive Value

Generating boilerplate Terraform/CI/CD
Explaining error logs in clear language
Offering alternative solutions fast
Flagging potential configuration problems early

❌ Where AI Can Mislead

Blindly copying code without understanding it
Masking architectural tradeoffs
Assuming generated configs are optimal
Trusting AI output without testing it thoroughly

Rule of thumb:
If AI helps you understand a solution — it’s good.
If it only helps you run a solution — it’s dangerous.

These Resources Will Accelerate Your Journey

You might find these extremely useful:

🔗 100 Days of DevOps — a proven, hands-on progression:
https://github.com/rufilboss/100DaysOfDevOps

🔗 DevOps Guide (fork & extend it):
https://github.com/rufilboss/DevOps-Guide/

🔗 DevOps Books curated by the community:
https://github.com/DevOps-Projects-Ideas/DevOps-Books/
(500+ stars | 270+ forks — real community validation)

🔗 Cloud infrastructure local practice (Low cost/no risk):
https://github.com/localstack/localstack

These are not ads, they are battle-tested resources used by beginners and pros alike.

The Real Takeaway

DevOps in 2026 is not just another career.
It’s about thinking in systems, not tools.

AI will let you explore more, but only fundamentals will let you master more.

You don’t need to learn everything today, but you do need to build confidence through repetition, testing, failure, and curiosity.

If you’re ready to dive in, you’re already ahead of the crowd.

A Practical Guide to Organizing an AWS Community Day (From Scratch)

Ilyas Rufai — Tue, 23 Dec 2025 11:59:50 +0000

What is AWS Community Day?

AWS Community Day is a one-day, community-led conference organized by AWS communities such as AWS User Groups or AWS Cloud Clubs. It brings cloud practitioners, students, and enthusiasts together to learn, network, and share real-world AWS knowledge.

Community Days range from:

Large, multi-country events (e.g., AWS Community Day DACH)
To smaller, single-community events organized by one User Group or Cloud Club

This guide documents what it takes to plan, organize, and execute an AWS Community Day successfully, especially if you’re doing it for the first time.

Phase 1: Foundations (Before Anything Else)

1. Define Your Scope

Before tools, sponsors, or speakers, be clear on:

Target audience: students, professionals, beginners, mixed?
Event size goal: (e.g. 1000–1500 attendees)
Event type: free or paid
Location: city, campus, venue type

📌 Placeholder:

Expected attendees: ___
Target audience: ___
City/Campus: ___

2. Official AWS Alignment (Very Important)

AWS Community Day Page

Start here:
👉 https://aws.amazon.com/developer/community/community-day/

This page explains:

What qualifies as an AWS Community Day
Branding rules
FAQs
Organizer expectations

AWS Organizer Slack

Join the community-day-organizers Slack channel.
This is critical for:

Avoiding date clashes in the same region
Learning from other organizers
Funding guidance
Shared templates and experiences

Phase 2: Online Presence & Registration

3. Event Website

You will need a simple website containing:

Event details
Agenda
Speakers
Registration link
Sponsors

Options:

Build your own
Use a template (e.g. Hugo-based AWS Community Day templates)

📌 Placeholder:

Website URL: ___

4. Registration

Common tools:

Eventbrite
Google Forms
Konfhub
Other ticketing platforms

Choose one that:

Handles attendee limits
Exports attendee data
Supports QR codes (nice bonus)

📌 Placeholder:

Registration platform: ___

5. Call for Speakers (CfS)

You’ll need speakers early.

Tools:

Sessionize
Google Forms

Collect:

Topic title
Abstract
Speaker bio
Preferred time slot
Session level (Beginner / Intermediate / Advanced)

📌 Placeholder:

CfS link: ___
Submission deadline: ___

Phase 3: AWS Support & Resources

6. AWS-Provided Materials

AWS provides downloadable assets that help a lot:

Logos
Fonts
Slide templates
Organizer resources

Look for:

UG Toolkit / Community Toolkit

7. Funding (Yes, It’s Possible 💵)

AWS may provide financial or material support depending on:

Event size
Community maturity
Region

Funding requests are usually discussed in:

AWS organizer Slack
Via AWS Community contacts

📌 Placeholder:

Funding requested? Yes / No
Amount / type: ___

Phase 4: Planning the Actual Event

8. Attendee Estimation (Be Realistic)

Estimating attendance is tricky.

Consider:

Size of your community
Average meetup attendance
Travel distance
Marketing reach
Exam periods / holidays

Rule of thumb:

Expect less → Be pleasantly surprised later

Also expect last-minute registrations.

9. Venue Selection

Choose a venue that:

Can scale up or down
Supports multiple rooms
Has reliable power & internet

Minimum rooms:

Main session room(s)
Speakers’ room
Storage / quiet room

📌 Tip:
Sponsors/expo area should be where attendees naturally pass, not isolated.

10. Catering

Keep it simple:

Snacks
Lunch
Drinks

Don’t forget:

Speakers’ room refreshments

📌 Placeholder:

Catering plan: ___

11. Tracks & Agenda Design

Less is more.

Avoid:

Too many parallel tracks
Overlapping highly attractive sessions

Recommended format (per session):

30 min talk
15 min Q&A
15 min break / expo

Sample Agenda

08:00 – Registration
09:00 – Opening Remarks
09:15 – Keynote
10:00 – Break / Expo
10:30 – Session Slot 1
11:30 – Session Slot 2
12:30 – Lunch
13:30 – Session Slot 3
14:30 – Session Slot 4
15:30 – Break
16:00 – Final Session
16:30 – Closing

12. Speakers

Aim for balance:

AWS employees
Community speakers
First-time speakers
Local & external speakers

Always ask:

Preferred speaking time
Travel needs
Slide sharing permission

13. Free vs Paid Event

Free Event

Higher no-shows
More inclusive

Paid Event

Fewer no-shows
More admin (tax, accounting)

Choose what fits your context.

Phase 5: Marketing & Sponsors

14. Marketing (Don’t Underestimate This)

Channels to use:

WhatsApp groups
LinkedIn
Twitter/X
Campus clubs
Word of mouth
Sponsors’ channels

Start early.

15. Sponsors

Sponsors fund your event.

Prepare:

Clear sponsorship packages
Benefits list (booth, logo, talk, etc.)
Venue layout
Simple agreement

Some sponsors may qualify for AWS MDF funding.

📌 Placeholder:

Sponsor tiers: ___
Confirmed sponsors: ___

Phase 6: Operations & Logistics

16. Organizing Team

Small teams can work:

2–5 core organizers
Clear roles (logistics, speakers, sponsors, media)

17. Volunteers

Volunteers help with:

Registration
Directions
Speaker support

Tip:

Ask sponsors if they can assign volunteers.

18. Badges, Lanyards & Printing

Decide:

Pre-printed vs on-site printing
Badge color coding (Organizers, Speakers, Sponsors, Attendees)

Reusable materials save money long-term.

Phase 7: Communication & Experience

19. Communication Channels

Recommended:

Slack (organizers + speakers)
WhatsApp (organizers + volunteers)
WhatsApp (real-time event coordination)

20. Speaker Slides & Content

Attendees often ask for slides.

Before the event:

Ask speakers if slides can be shared After the event:
Upload to website or shared drive

21. Speaker Dinner (Highly Recommended)

If budget allows:

Host a speaker dinner
Builds relationships
Improves speaker experience

Reality Check 😅

People will:

Complain
Ask last-minute questions
Need help

This is normal. Expect it.

Final Thoughts

Organizing an AWS Community Day is:

Hard work
Time-consuming
Extremely rewarding

From idea to execution, expect months of planning.

If you’re thinking about doing it:

Yes — do it.
The impact on your community is worth it.

DEV Community: Ilyas Rufai

IAM Role Design Patterns for Multi-Account AWS Environments

TL;DR

Why single-account IAM thinking fails at scale

Reference account model

Pattern 1 — Human access with IAM Identity Center

Pattern 2 — CI/CD deployment role (tooling → workload)

Trust policy in the workload account (deployment role)

Permissions policy on the deployment role (example)

Terraform: workload account role

Pattern 3 — Central audit and security read role

Pattern 4 — Cross-account resource access (S3 and KMS)

S3 bucket policy (account B)

Identity policy (account A, on app-upload-role)

Pattern 5 — Third-party and vendor access with ExternalId

SCPs and permission boundaries: guardrails above IAM

Decision matrix: which pattern when?

How to verify your design

Quick CLI negative test (deployment roles)

When this breaks down

Frequently asked questions

What I learned designing roles across accounts

References

Terraform EC2 and S3 Upload Access: A Simple IAM Role Setup Without Access Keys

TL;DR

Why putting access keys on EC2 fails

What you are building

Step 1: Create the project layout

Step 2: Pin provider versions

Step 3: Define input variables

Step 4: Create the S3 bucket

Step 5: Create IAM role and least-privilege S3 policy

Step 6: Use default VPC networking and security group

Step 7: Launch the EC2 instance

Step 8: Initialize and apply Terraform

Step 9: SSH into the instance

Step 10: Verify S3 upload from EC2

How to verify this works

Clean up to avoid charges

When this breaks down

Frequently asked questions

What I learned building this

Project on GitHub

References

Secret Scanning in CI: What Pre-Commit, Pull Request, and Main Branch Each Actually Catch

TL;DR

Why one scanner in one place fails

Layer 1 — Pre-commit (fast feedback)

Layer 2 — Pull request scan (merge gate)

Layer 3 — Main branch and history (hygiene)

How to verify this works

Reducing false positives without going blind

When a secret is found anyway

When this breaks down

Summary

Further reading

Amazon S3 Bucket Names Aren’t Always Globally Unique Anymore — Here’s What Changed (and Why I’m Excited)

What used to be true (and is still true by default)

What changed: Account regional namespaces (Mar 2026)

How the naming looks (the new naming convention)

Why this matters (in real systems)

1) It kills the “I spent 20 minutes naming a bucket” problem

2) It reduces risk after deletion (a security win)

3) It scales for bucket-per-customer / bucket-per-team designs

Creating an account-regional namespace bucket (AWS CLI)

How I’d enforce this in an organization (IAM/SCP policy)

Bucket naming rules (still important)

The mental model I use

Global namespace (default)

Account regional namespace (new)

Final takeaway

References (official)

I built a zero-cost end-to-end DevOps pipeline (GitHub Actions + Docker + Kubernetes + Docker Hub)

What I built (high level)

Prerequisites I used

Project layout

1) The app I used (simple Flask service)

2) Containerizing it with Docker

Local sanity check

3) Running it on Kubernetes (kind or minikube)

Identity policy (account A, on `app-upload-role`)