How Do You Manage ECS Fargate Across Multiple AWS Accounts?

Why managing ECS across accounts is hard

A multi-account AWS Org buys you isolation and clean billing — but AWS ships no single control plane for ECS. There's no "Lens for ECS", so you operate each account by hand.

This is not a hypothetical complaint. On AWS re:Post, a practitioner running "lots of AWS Accounts" asked the obvious question: is there a way to manage ECS clusters across them "without logging back and forth between the accounts" — ideally a tool like Lens, the Kubernetes IDE. The answer, from an AWS-side responder, was blunt:

"First of all, I don't think there is a tool quite like Lens, for ECS. That is, centrally manage and store credentials of various clusters and provide single plane of glass for cluster management."

— AWS re:Post, "How to manage ECS Clusters across accounts?"

The recommended path is exactly the manual stitching you'd expect: named CLI profiles per account, cross-account IAM roles, and a centralized CI/CD pipeline that assumes into each target account. None of that is wrong. But you — not AWS — are the integration layer. A "what's running in euw1-stag-main?" question becomes a context switch, an assume-role, and a fresh console tab.

This guide assumes you've already decided to go multi-account. If you're still working out how to structure those accounts in the first place — one account per environment group versus a single shared account — that decision comes first, and it's a different article. The short version: prod gets its own account for blast radius; non-prod usually shares one until Fargate quota or audit scope forces a split. Once that's settled, the question becomes operational: how do you run the fleet day to day?

Ready to use: a cross-account fleet-viewer role

Deploy one read-only IAM role to every member account, assumable from a single ops account. Now one set of credentials can list and describe ECS across the whole Org — no console hopping.

Drop this Terraform into each member account (via your account-baseline module or StackSets). The role trusts only your ops account and grants ECS read plus the cost and tag reads you need for a fleet view. From the ops account you then aws sts assume-role into each account and run aws ecs list-clusters against all of them with one identity.

# Deploy in EVERY member account. ops_account_id is your single
# operations/admin account that does the cross-account reading.
variable "ops_account_id" { type = string }

data "aws_iam_policy_document" "trust" {
  statement {
    actions = ["sts:AssumeRole"]
    principals {
      type        = "AWS"
      identifiers = ["arn:aws:iam::${var.ops_account_id}:root"]
    }
    # Require an external ID to block the confused-deputy problem.
    condition {
      test     = "StringEquals"
      variable = "sts:ExternalId"
      values   = ["fortem-fleet-viewer"]
    }
  }
}

data "aws_iam_policy_document" "read" {
  statement {
    sid    = "EcsFleetRead"
    effect = "Allow"
    actions = [
      "ecs:List*",
      "ecs:Describe*",
      "ce:GetCostAndUsage",        # per-account cost for the fleet view
      "tag:GetResources",          # owner / env tags
      "cloudwatch:GetMetricData",  # task counts, CPU/mem
    ]
    resources = ["*"]
  }
}

resource "aws_iam_role" "fleet_viewer" {
  name               = "fortem-fleet-viewer"
  assume_role_policy = data.aws_iam_policy_document.trust.json
}

resource "aws_iam_role_policy" "fleet_viewer" {
  name   = "fleet-read"
  role   = aws_iam_role.fleet_viewer.id
  policy = data.aws_iam_policy_document.read.json
}

The five surfaces you have to operate

Operating ECS across accounts means solving five surfaces: fleet visibility, cross-account IAM access, image distribution, networking, and deploy. AWS gives you a primitive for each, not a system.

Each surface has a native AWS answer. The work — and the cost — is that none of them connect to each other, and you own the glue. Here's the map the rest of this guide follows:

Distributing images: central ECR done right

Pick one: ECR cross-account replication (push once, pull locally) or a shared repo via repository policy. The aws:PrincipalOrgID shortcut works but exposes the repo to every account in the Org.

Most teams build once in a shared services or CI account, then need that image in every workload account. Two clean answers. Replication: ECR copies the image to a local repo in each destination account, so pulls are in-region, in-account, and cheap — best when you have many accounts. Shared repository: one repo with a repository policy granting pull to specific account IDs — simplest when you have a handful.

The tempting shortcut is to skip the account list and grant pull to your whole Organization with a single condition. It works. It's also exactly what a re:Post answer flagged:

"Beware: this allows all accounts in an Organization to access the ECR repository! Double check with your security team if this is allowed!"

— AWS re:Post, "Central ECR for ECS in multiple accounts"

For a regulated buyer — the kind tracking the fixed overhead every environment carriesdown to the dollar — "every account in the Org can pull this image" is the kind of finding an auditor circles in red. Name the accounts explicitly, or use replication.

Deploying the same service to N accounts

One image, N accounts means one pipeline assuming a deploy role per target account. Parameterize the account ID and role ARN; never copy a pipeline per account — that's how environments drift.

The centralized model is the one AWS recommends and the one that scales: the pipeline lives in a single CI/CD account, and each stage assumes a deploy role in the target account to register the task definition and update the service. The image is built once and pulled from your central or replicated ECR. The task-definition template is one file; the account ID, role ARN, and environment-specific variables are inputs.

The anti-pattern is a copy of the pipeline per account. It feels faster on day one and it guarantees drift by month three — one account gets a CPU bump, another a new env var, a third a hotfix that never makes it back to the template. Multi-account already costs you a single pane of glass; don't also give up a single source of truth for what you deploy.

If you read this, you might also want to know

FAQ