It's Friday at 6pm. Your Developer Can't Restart Staging Without You.

The 6pm Slack message

Without per-environment RBAC, every ECS staging restart requires a platform engineer — turning a 30-second fix into a 2–14 hour wait and an off-hours Slack message.

It's Friday, 6:47pm. You're at dinner. Your phone buzzes.

You open the AWS Console on your phone. Fargate console on mobile is a special kind of awful — tiny text, nested dropdowns, a task definition ARN you have to scroll sideways to read. You find the service, stop the broken task, wait for it to restart. The new task fails to start too. You check the CloudWatch logs. Missing environment variable. You update the task definition, force a new deployment. Fifteen minutes. By the time the service is healthy, dinner is cold and you've lost the conversation.

Monday, Jamie finishes the smoke test in 20 minutes and the deploy goes out fine.

Jamie didn't need you to debug a config issue. Jamie needed to restart a service. The entire incident was a permission problem — and it happens on most teams with 10+ environments, at least twice a week.

Why this keeps happening

IAM has no environment-scoped ECS permissions — ecs:UpdateService grants account-wide access — so platform engineers become the default gatekeeper rather than risking broad console access.

“Platform engineers become the single point of failure for staging ops when developers have no safe, scoped way to act.”

— Observed pattern across ECS teams at scale

Developers don't have scoped AWS access because the alternative — broad IAM — is dangerous. But 'no access' creates a single point of failure: the platform engineer. The middle ground — scoped, per-environment RBAC — is the solution nobody bothers to set up.

AWS IAM doesn't have environment-scoped permissions for ECS. You can grant someone ecs:UpdateService — but that's access to every ECS service in the account, including production. You can try to scope it by resource ARN, but when your environments have 15 services each, maintaining those policies manually becomes its own full-time job. The challenges of managing ECS multi-environment strategies compound quickly once a team grows past three or four envs.

So most platform engineers made the only rational decision available to them: they kept the keys and became the gatekeeper. Developers file a Slack request, platform engineer handles it, developers wait.

The cost is invisible because it's spread across the week in small increments. A Slack ping here, a 15-minute console task there. But count the interruptions in a month: 3–8 per week for a mid-sized team. Each one breaks a flow state that takes 20 minutes to rebuild. Each Friday or weekend message is unpaid on-call work for a non-incident.

The 5 ops that cause 80% of interruptions

Five actions — restart a service, redeploy the latest image, read logs, flush Redis, and run a one-off task — account for 80% of platform-engineer interruptions on ECS staging teams.

Most platform engineers, when they audit their staging-ops interruptions, find the same five actions accounting for nearly all of them:

1. 1.
   Restart a crashed or stuck service. A task died, maybe due to a failed health check or OOM. The developer knows it — they can't restart it.
2. 2.
   Redeploy the latest image. A new build was pushed to ECR. The developer wants to pick it up in staging without waiting for the next CI run to trigger a deployment.
3. 3.
   Read logs. The service is behaving strangely. The developer needs to tail CloudWatch — not navigate five levels of AWS console to get there.
4. 4.
   Flush a Redis cache. Bad data got written. A key needs to be cleared so the service reads fresh state. One operation, one line of code if they had access.
5. 5.
   Run a one-off task. A database migration, a data backfill, a cleanup script. Not a deployment — a single-run task against staging data.

None of these require infrastructure knowledge. None of them should require a platform engineer.

Why raw AWS Console access is the wrong answer

IAM cannot scope ecs:UpdateService by environment — a policy allowing staging restarts also covers production — so granting console access trades one risk for a bigger one.

The obvious first instinct: give them limited AWS access. Create a developer IAM role with read and restart permissions.

In practice, this goes wrong in predictable ways:

• ·IAM doesn't scope ECS permissions by environment — it scopes by account, region, and ARN. A policy that allows restarting staging services also allows restarting production services in the same account.
• ·ARN-scoped policies break every time a service is renamed, a new environment is added, or an account is restructured. Someone has to maintain them.
• ·AWS Console access gives visibility into things developers shouldn't see: secret ARNs, network config, IAM role names. Not a security catastrophe, but not ideal.
• ·There's no audit trail per action. CloudTrail tells you which IAM user ran which API call — but not why, from what context, or what the environment state was before and after.

The right answer isn't broader AWS access — it's a permission layer that understands environments. Teams following ECS Fargate best practices at scale consistently land on environment-scoped RBAC rather than direct console access for exactly these reasons.

How Fortem solves it

Fortem adds SSO-based, per-environment RBAC to ECS Fargate: developers see only assigned environments and can restart, redeploy, view logs, and flush Redis without any AWS Console access.

Fortem's self-service layer gives each developer a scoped view of environments they own. You assign ownership in the dashboard — takes about 15 minutes for a typical team. From that point, developers log in via SSO and see only their environments.

Within their assigned environments, the full permission breakdown:

The key point is the last four rows. Production is off. AWS credentials are off. Infrastructure config is off. The scope boundary is enforced server-side — it's not UI hiding.

No IAM changes required on your end. Fortem uses a cross-account role with the minimum permissions needed to perform ECS operations. Your developers authenticate via SSO — they never interact with AWS directly.

Before and after

With per-environment self-service, a Friday staging restart drops from a 2–14 hour Slack wait to 40 seconds — and the platform engineer never has to open AWS Console on their phone at dinner.

The most common feedback from platform engineers after turning on self-service: the first week felt like they gave something up. The second week, they realized the thing they gave up was being woken up on Friday night.

What gets logged

Every Fortem action records actor, environment, operation, timestamp, and service state before and after — queryable in 30 seconds with no CloudTrail cross-referencing required.

Every action through Fortem creates an audit entry: who, what environment, what action, what time, what the service state was before and after.

When your SOC 2 auditor asks who restarted staging last Tuesday, this is the answer — filtered and exported in under 30 seconds. You don't need to cross-reference CloudTrail against IAM users against a timezone conversion.

Audit retention is configurable: 90 days on the Fortem plan, 365 days on Enterprise.

FAQ