DEV Community: Remus Kalathil

Running Argo CD across regions: four topologies, one reference setup

Remus Kalathil — Wed, 07 Oct 2026 23:33:49 +0000

Argo CD on one cluster is easy. Add a second region and a new set of questions appears. Where does Argo CD itself run? What happens when that region goes down? How do you stop one bad commit from landing in every region at once?

This guide covers the topologies, the trade-offs, and a reference setup you can adapt, with Amazon EKS as the example.

First, what Argo CD actually needs

Git is the source of truth.
Kubernetes objects in the Argo CD cluster hold the rest: Application, ApplicationSet and AppProject objects, cluster Secrets and repo credentials.
Redis is only a cache, so losing it is not data loss.
It is not in the data path. If Argo CD is down, your workloads keep running. You lose the ability to deploy and to self-heal until it is back.

That last point shapes everything below. Multi-region design for Argo CD is about blast radius and recovery time, not user traffic.

Four topologies

Topology	Good for	Watch out for
1. Central hub	One pane of glass, up to a few dozen clusters, small team	Cross-region API latency; the hub's region is a single point of failure for changes; wide credentials
2. Hub per region	Failure isolation, data-residency or compliance boundaries, 50+ clusters	More Argo CD instances to run; fleet view needs extra tooling
3. One per cluster	Strongest isolation, air-gapped or regulated clusters	N control planes to upgrade; you need a bootstrap story
4. Agents (pull)	Clusters that can't be reached inbound	Newer model (the Argo CD agent project); check its maturity for your version

Choose with four questions:

How many clusters do you have?
Can your compliance rules allow one control plane to hold credentials for all regions?
How long can you tolerate being unable to deploy?
Do teams need to own their own Argo CD?

My default for multi-region production is a hub per region (or per region group), driven from one Git repo, because it keeps a regional failure regional. That is an opinion, not a rule. A central hub is fine below a few dozen clusters if the hub region has a standby.

Building blocks

1. Clusters as labelled Secrets

Labels carry the metadata that everything else selects on: environment, region, and a rollout wave.

apiVersion: v1
kind: Secret
metadata:
  name: cluster-prod-uswest-2-01
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
    env: prod
    region: us-west-2
    wave: "1"
type: Opaque
stringData:
  name: prod-us-west-2-01
  server: https://EXAMPLE1234567890.gr7.us-west-2.eks.amazonaws.com
  config: |
    {
      "awsAuthConfig": {
        "clusterName": "prod-us-west-2-01",
        "roleARN": "arn:aws:iam::111122223333:role/argocd-deployer"
      },
      "tlsClientConfig": { "caData": "BASE64_CLUSTER_CA" }
    }

2. EKS authentication with no long-lived tokens

Give the Argo CD controller an AWS identity (IRSA or EKS Pod Identity).
Allow it to sts:AssumeRole into the roleARN above (one role per account).
Map that role in the target cluster with an EKS access entry to a Kubernetes role. Scope that role down where you can, instead of defaulting to cluster-admin.

Tokens come from awsAuthConfig at call time, so there is nothing to rotate by hand.

3. One repo layout, three layers of values

Don't copy a directory per region. Layer the differences:

addons/                          # the chart or kustomize base
values/global.yaml               # shared by everything
values/env/prod.yaml             # prod-only
values/region/us-west-2.yaml     # region-only (endpoints, quotas, replicas)

4. A project to bound the blast radius

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata: { name: platform, namespace: argocd }
spec:
  sourceRepos: ["https://github.com/example/platform-gitops"]
  destinations:
    - { server: "*", namespace: platform }
    - { server: "*", namespace: monitoring }
  clusterResourceWhitelist:
    - { group: "", kind: Namespace }
  orphanedResources: { warn: true }

5. One ApplicationSet, one Application per cluster

The cluster generator reads the labels from step 1.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata: { name: platform-addons, namespace: argocd }
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
    - clusters:
        selector: { matchLabels: { env: prod } }
  strategy:
    type: RollingSync
    rollingSync:
      steps:
        - matchExpressions: [{ key: wave, operator: In, values: ["1"] }]
        - matchExpressions: [{ key: wave, operator: In, values: ["2"] }]
          maxUpdate: 50%
        - matchExpressions: [{ key: wave, operator: In, values: ["3"] }]
  template:
    metadata:
      name: "addons-{{.name}}"
      labels:
        wave: "{{.metadata.labels.wave}}"
        region: "{{.metadata.labels.region}}"
    spec:
      project: platform
      source:
        repoURL: https://github.com/example/platform-gitops
        targetRevision: stable
        path: addons
        helm:
          valueFiles:
            - values/global.yaml
            - "values/env/{{.metadata.labels.env}}.yaml"
            - "values/region/{{.metadata.labels.region}}.yaml"
      destination: { server: "{{.server}}", namespace: platform }
      syncPolicy: { syncOptions: [CreateNamespace=true] }

If you run a hub per region, each hub gets the same ApplicationSet with an extra region selector in the generator, so every hub only manages its own clusters.

Rolling out region by region

Waves, not region names. The wave label orders the rollout (a canary region first, then the rest). You can rename or reorder regions without touching the ApplicationSet.
Progressive Syncs (RollingSync) let the ApplicationSet controller sync wave 1, wait for health, then sync wave 2. It sits behind a feature flag on the ApplicationSet controller in current versions. I left auto-sync out of the example on purpose, so check your version's docs on how the two interact.
Don't let the fleet track main. Point targetRevision at a branch or tag that moves only after a successful earlier wave (stable above). One merge to main should never reach every region.

High availability and disaster recovery

HA install. The HA manifests give you several API server and repo-server replicas and a Redis HA setup.
Everything that matters is declarative. Applications, projects and cluster Secrets live in Git (secrets via an external secrets operator, not in plain Git). A lost Argo CD can be rebuilt from Git.
Active/passive for a central hub. Run a second Argo CD in another region with the controllers scaled to zero. Two active controllers will fight over the same clusters. To fail over, scale the standby's controller up.
Per-region hubs make this mostly moot. Losing a region's Argo CD only pauses changes for that region.

Scaling knobs

Controller sharding. The application controller is a StatefulSet. Set its replica count and let it spread clusters across shards. Newer versions offer a round-robin and a consistent-hashing algorithm, via controller.sharding.algorithm in argocd-cmd-params-cm.
Cross-region API latency. The controller watches every managed cluster, so distance and jitter show up as timeouts. This is a main reason to put the controller near its clusters.
Polling vs webhooks. The default Git poll is about three minutes (timeout.reconciliation). Use webhooks, and put your repo-server behind a cache that survives restarts.
Large clusters. Use resource exclusions and ignoreDifferences (for example HPA-managed replicas) to cut noise and controller memory.

Security

Use AppProjects as the permission boundary: allowed repos, destinations and cluster-scoped kinds.
Use SSO via OIDC with group claims mapped in argocd-rbac-cm. Debug it in layers: is the claim in the token, does the IdP's group filter match, and only then RBAC.
Keep RBAC config in Git, so hotfixes don't get silently reverted.
Keep secrets out of Git and out of Applications.

Failure modes cheat sheet

Symptom	Likely cause
Apps flip to "Unknown" or "Unreachable" for one region	API-server reachability or latency from the controller, expired exec-auth credentials
Hub outage	Nothing breaks at runtime; you can't deploy until it's back or you fail over
Everything resyncs after a restart	Expected after losing the controller cache; plan for the load
One bad commit hits all regions	The fleet tracks `main`; add promotion and waves
"permission denied" for users after SSO	Missing group claim or a filter mismatch, before RBAC

Checklist

Pick a topology from the four questions.
Register clusters as labelled Secrets, with cross-account roles and no static tokens.
One repo, layered values, one ApplicationSet, waves for ordering.
The fleet tracks a promoted branch, never main.
HA install, a rebuild-from-Git runbook, and an active/passive standby if you run a central hub.
Shard the controller, use webhooks, and tune exclusions.
Projects and RBAC in Git, SSO tested in layers.

How are you running Argo CD across regions? Hub per region, or something else? Let me know in the comments.

EKS Pod Identity vs IRSA: A Practical Migration Guide and the Gotchas Nobody Mentions

Remus Kalathil — Mon, 28 Sep 2026 00:54:03 +0000

If you're running workloads on EKS, your IAM strategy was probably built around IRSA. At re:Invent 2023, AWS introduced EKS Pod Identity as a simpler alternative to it. This post walks through the practical migration path, and, more importantly, five gotchas I hit that aren't covered in the official docs.

Quick context (skip if you already know this)

IRSA relies on OIDC federation. You create a per-cluster identity provider, write trust policies with sub/aud conditions, and annotate the service account with the target role ARN. At runtime, a mutating webhook injects a projected OIDC token into the pod, and the AWS SDK exchanges it for temporary credentials via sts:AssumeRoleWithWebIdentity.

Pod Identity replaces this flow with an EKS Pod Identity Agent daemonset running on every node, plus a PodIdentityAssociation resource that maps a (cluster, namespace, service account) triple to an IAM role. Trust is established through the pods.eks.amazonaws.com service principal instead of per-cluster OIDC conditions. No OIDC provider to create, rotate, or track, and no per-role trust-policy sprawl.

Why migrate (the real wins)

No per-cluster OIDC identity provider lifecycle to manage. One less resource to create, rotate certificates for, and keep in sync across clusters.
Uniform trust policy shape across every role. Every role trusts the same pods.eks.amazonaws.com principal, so auditing and policy-as-code checks get simpler. You're not diffing sub/aud conditions role by role.
Easier cross-account and cross-cluster role reuse. One association model instead of juggling OIDC provider ARNs per cluster.
Faster credential rotation. The agent proactively fetches and rotates credentials, versus the webhook-injected token flow which ties rotation to token TTL.

Migration steps

Enable the EKS Pod Identity Agent add-on on the cluster (via console, eksctl, or Terraform's aws_eks_addon).
Update role trust policies to include the Pod Identity principal. Important: this can coexist with the existing OIDC trust condition during migration. You don't need a hard cutover; a role can trust both pods.eks.amazonaws.com and the old OIDC provider simultaneously.
Create a PodIdentityAssociation per (cluster, namespace, service account) triple, mapping it to the target IAM role ARN.
Verify empirically. Don't trust that the association exists in the console. Check CloudTrail's userIdentity field or application logs to confirm the pod is actually assuming the new role via the new path.
Drop the old eks.amazonaws.com/role-arn annotation only after verification passes for that workload.

Recommendation: run both trust paths in parallel for at least one deploy cycle per workload. It costs nothing and gives you an instant rollback if something's wrong.

Reference: trust policy and association

Trust policy — before (IRSA only):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:my-namespace:my-service-account",
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

Trust policy — during migration (both trusts active):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:my-namespace:my-service-account",
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}

Trust policy — after (Pod Identity only, drop the OIDC statement once verified):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}

Creating the association — AWS CLI:

aws eks create-pod-identity-association \
  --cluster-name my-cluster \
  --namespace my-namespace \
  --service-account my-service-account \
  --role-arn arn:aws:iam::111122223333:role/my-app-role

Creating the association — Terraform:

resource "aws_eks_pod_identity_association" "my_app" {
  cluster_name    = "my-cluster"
  namespace       = "my-namespace"
  service_account = "my-service-account"
  role_arn        = aws_iam_role.my_app_role.arn
}

Verifying via CloudTrail (gotcha #4 check):

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
  --query "Events[?contains(CloudTrailEvent, 'pods.eks.amazonaws.com')]" \
  --max-results 20

The gotchas nobody mentions

1. Native subprocess libraries don't inherit Pod Identity credentials automatically

If your application forks its own binary (a native library, a CLI tool it shells out to, anything that doesn't go through your language's AWS SDK credential chain), that subprocess resolves its own default credential chain. Without explicit environment propagation, it can fall through to the node's IMDS role instead of the Pod Identity credentials.

This fails silently. No error, no warning log. The subprocess just authenticates as the wrong principal. You only catch it by explicitly checking which identity made a given API call: aws cloudtrail lookup-events filtered on userIdentity.arn, or equivalent logging in your observability stack. If you have any workload that shells out to a native binary for AWS calls (some data-processing tools, some legacy CLIs), audit this explicitly before you assume the migration is clean.

2. One (cluster, namespace, service account) triple = exactly one association

PodIdentityAssociation enforces a strict 1:1 mapping. Try to create a second association for the same triple without deleting the first, and the API returns ResourceInUseException.

This is a real trap for IaC-managed associations. A Terraform or Crossplane "destroy and recreate" apply (the kind that happens when you change an immutable field, or when a module gets refactored) will hit this if the delete and create aren't sequenced correctly. Plan for an explicit delete-then-create step in your pipeline, not a blind replace.

3. IaC provider version drift leaves orphaned associations

If you migrate between provider versions, for example moving from an older Crossplane AWS provider to the newer Upbound-maintained one, associations created under the old provider version can be left behind, unmanaged, after the upgrade. They don't get cleaned up automatically, and they don't show up as drift in the new provider's state.

Before any cleanup pass, check for a tag identifying which provider or provider version created the association (most providers tag their managed resources). Don't assume "not in current Terraform state" means "safe to delete." Check the tag first.

4. Startup-time credential propagation race

A freshly created PodIdentityAssociation's credentials aren't always instantly available to a pod that starts immediately after. If your application reads AWS credentials very early in its boot sequence, before the Pod Identity Agent has had a moment to establish the mapping, you can see intermittent failures on first start that resolve on restart.

This looks exactly like flakiness, and it's easy to misdiagnose as an unrelated bug (a race in your own init code, a transient network blip). If you see credential failures that only happen on cold start and never on restart, this is the first thing to check. Mitigate with a startup retry/backoff around your first AWS call rather than chasing a phantom bug in application code.

5. Compliance and security tooling built for IRSA won't recognize Pod Identity's trust shape

Any scanner or policy-as-code check that looks for OIDC provider ARN conditions in trust policies (a common IRSA-era check: "does this role's trust policy scope to a specific OIDC provider and sub condition?") won't recognize the pods.eks.amazonaws.com principal pattern at all.

Until that tooling is updated, it will misreport actively-used, correctly-scoped roles as "unused" or "unscoped by OIDC condition." Depending on how your organization handles those findings, this can generate false-positive remediation tickets, or worse, feed an automated cleanup process that deletes roles still in active use. Audit your IAM scanning rules for OIDC-specific logic before rolling Pod Identity out broadly, not after.

Decision checklist

Migrate now if:

You're managing OIDC providers across many clusters and the operational overhead is real.
Your compliance tooling can be updated in the same timeframe as the migration (or already supports Pod Identity).
You can tolerate a parallel-run verification window per workload.

Wait if:

Your security scanning pipeline hasn't been updated for the new trust policy shape.
You have subprocess-heavy workloads you haven't audited for credential inheritance.
Your IaC is already mid-provider-version-migration. Don't stack two migrations.

The one-line takeaway

"The association exists" is not the same as "the pod is using it." Verify via logs and CloudTrail identity, not console state.

Written as an AWS Community Builder. If you've hit other gotchas in your own migration, I'd like to hear about them in the comments.

I Got Selected as an AWS Community Builder – Containers on My First Try. Here's My Honest Story.

Remus Kalathil — Sun, 15 Mar 2026 07:29:15 +0000

I had been selected for the AWS Community Builder program Containers category.

First-time applicant. No conference speaking history. No massive LinkedIn following. Just consistent writing and 9+ years of real production experience with AWS and Kubernetes.

This is my honest writeup of how it happened, what I submitted, and what I'd tell anyone thinking about applying.

How I Even Found Out This Program Existed

I'll be upfront. I had zero idea the AWS Community Builder program existed until I joined the SA (Solutions Architect) bootcamp by Rajdeep Saha last year.

A few people in my cohort already had the CB badge on their LinkedIn profiles. I asked one of them about it and got the full picture what the program is, what you actually get out of it, and that applications open on a rolling basis, with a waitlist.

That one conversation changed everything. I had spent 9+ years building cloud infrastructure with my head down. Running Kubernetes at scale, migrating workloads to AWS, designing multi-account architectures at Expedia Group. I had been doing it mostly quietly.

The idea that there was a program specifically designed to recognize practitioners who share knowledge publicly was genuinely new to me.

So I didn't just apply immediately I was intentional about it. I started posting regularly on LinkedIn, sharing real production insights and lessons from my work. I began writing longer-form technical articles on Hashnode. I built a habit of sharing knowledge publicly before I ever submitted an application.

I joined the waitlist. When the application window opened I applied. First attempt. Got in.

The Bootcamp That Started It All

I want to give proper credit here because it matters.

The SA bootcamp was run by Rajdeep Saha at Cloud With Raj. If you don't know Raj, here's some context: he's a Stealth EdTech Startup Founder and former L7 Principal Solutions Architect at AWS, has presented at AWS re:Invent, KubeCon, and AWS Summits, co-authored the official Karpenter 1.0 announcement blog on AWS, and has trained over 350,000 students globally. LinkedIn awarded him "Top Systems Design Voice."

The bootcamp attracts serious practitioners. So when multiple people in my cohort already had the AWS Community Builder badge, I paid attention.

Raj's program didn't just teach cloud architecture. It created a community of people who push each other. That peer exposure is what made me aware of the CB program in the first place, and what motivated me to start sharing publicly.

If you're an SA or cloud engineer looking to level up, check out cloudwithraj.com. It's the real deal.

What the AWS Community Builder Program Actually Is

For anyone reading this in the same position I was here's the quick version.

The AWS Community Builder program recognizes AWS enthusiasts and emerging thought leaders who are actively creating content and contributing to the technical community. It is:

Not a certification
Not a job
A recognition and support program with real, tangible perks

What you get:

$500–$1,000 in AWS credits for personal projects and experimentation
Certification exam vouchers (Associate, Professional, Specialty)
Early access to new AWS services and features
A private Slack community with other builders and AWS service teams
Support to amplify your content. AWS often reshares CB posts
Invitations to re:Invent builder sessions and AWS Summits

There are multiple specialty categories. I applied for Containers, which covers EKS, ECS, Kubernetes, Docker, Karpenter, and everything in the container ecosystem.

My Background Going Into the Application

I'm a Solutions Architect at Expedia Group with 9+ years in cloud infrastructure. My day-to-day involves:

Running 6XX+ Kubernetes clusters across multiple AWS accounts
Supporting 1X,XXX+ microservices on platform infrastructure I own
Karpenter-based autoscaling and GitOps with ArgoCD
GPU infrastructure for AI/ML inference workloads
Large-scale cloud migrations (150+ servers, RTO ≤ 5 min, RPO ≤ 1 min)

I also hold a NVIDIA-Certified AI Infrastructure & Operations certification and am completing a PG Diploma in AI at Texas McCombs.

I mention this not to flex but because it directly shaped what I highlighted in my application, and why that specificity mattered.

What I Highlighted in My Application

The application asks you to describe your community contributions and provide three public links. I kept mine focused on two things.

1. My writing LinkedIn and Hashnode

I had been posting regularly on LinkedIn about cloud architecture, Kubernetes, and platform engineering. Nothing viral. Just consistent, technical posts grounded in real production experience. I also had a Hashnode blog with longer-form technical content.

I didn't have hundreds of thousands of followers. What I had was a body of work showing I was genuinely trying to help other practitioners not just building a personal brand.

2. Real production context in everything I wrote

When I wrote about Karpenter, I was writing from experience running it across hundreds of clusters. When I wrote about migration, I was describing a project where we achieved RTO ≤ 5 minutes on 150+ servers.

That specificity matters. AWS is looking for people whose community contributions come from genuine depth not people who summarize AWS documentation.

What I Did NOT Have

I want to be honest about this because a lot of CB posts make the bar sound impossibly high.

I did not have:

A massive LinkedIn following or viral posts
Conference speaking credits
Open source project maintainer status
Prior AWS recognition of any kind
A perfectly polished content portfolio

I was a first-time applicant with consistent writing and real production experience in the Containers space. That was enough.

The Moment I Found Out

I read the email twice to make sure I was reading it correctly.

Then I updated my LinkedIn headline. Then I messaged the people in my bootcamp cohort who had encouraged me to apply which felt like the right way to close that loop.

What I'm Doing With It

Being selected is the beginning, not the end. The CB program is only valuable if you actually show up.

Here's what I'm committing to:

Write consistently at least one deep technical post per month on Dev.to (primary) and Hashnode (mirror). The program encourages quarterly content but I want to do more than the minimum.

Cover the Containers category with production depth Karpenter at scale, GitOps patterns with ArgoCD, GPU scheduling on EKS, multi-cluster architectures, ECS-to-EKS migration lessons. These are topics I live in daily.

Engage with the community the CB Slack is active and the builders in there are sharp. I want to learn as much as I contribute.

Use the credits wisely I have specific GPU infrastructure experiments I've wanted to run for a while. The AWS credits make that possible without the overhead of approvals.

Should You Apply?

Yes if you're actively sharing knowledge in any AWS category, apply.

A few things I'd tell my pre-application self:

Don't wait until you feel ready. The program is for emerging thought leaders, not established ones. You don't need 10,000 followers. You need genuine contributions and real knowledge. I almost talked myself out of applying because I didn't feel like I had enough. I was wrong.

Be specific about your experience. Generic answers don't stand out. If you've run something at scale, migrated something complex, or solved a real production problem say so. Specific always beats impressive-sounding.

Pick the right category. Apply where you have genuine depth, not where you think the competition is lighter. I chose Containers because I work in it every single day. That authenticity comes through.

Your three links are everything. The application asks for three public links showcasing your contributions. These should demonstrate technical depth, community value, and consistency. Start building that body of work before you apply, not during.

Just start writing. The single thing that helped my application most was having a public body of work. You don't need to write perfectly. You need to write consistently. Start now, even if applications are not open yet.

Quick Tips by Category

If you're targeting the Containers category like I did:

Write about EKS, ECS, Karpenter, ArgoCD, Helm
Share real architecture decisions and trade-offs
Document production lessons, not just setup tutorials

If you're targeting AI / ML:

Share posts about Bedrock, SageMaker, or AWS AI services
Show practical projects with AWS AI services
Participate in AI-focused AWS events or hackathons

For any category:

Contribute at least 3 to 6 months before applying. The team looks for momentum, not a last-minute burst
Engage with others' content commenting, answering questions, participating in forums
Show a consistent voice across your contributions

What's Next

This post is the first of many. I'll be writing regularly about what I'm actually doing in production Kubernetes at scale, AWS platform engineering, AI/ML infrastructure, GitOps patterns, and the real lessons from 9+ years in cloud.

If you're an SA, cloud engineer, platform engineer, or just someone building on AWS follow along.

And if you're thinking about applying for the CB program, drop a comment. Happy to answer questions from where I'm standing.

Remus Kalathil is a Solutions Architect at Expedia Group and an AWS Community Builder – Containers. He writes about Kubernetes, AWS, and production platform engineering.

LinkedIn · GitHub · Hashnode · Website