Cloud & DevOps · Managed Services · Cloud Security

Client overview

A Fortune 500 manufacturer and retailer operating in 180 countries, serving 150 million consumers worldwide through a next-generation digital engagement platform built on AWS.

The platform is a multi-account AWS organization of more than 1,000 accounts, in which autonomous product teams — consumer engagement, loyalty, commerce, supply chain, data and analytics — each own their own account and release on their own cadence.

We operate as the client’s Managed Service Provider: running the platform, securing it automatically, and supporting the teams that build on it.

Business challenge

The client needed to maintain availability and security compliance across an estate where every product team owns its own AWS account and deploys independently.

Configuration risk is distributed. A misconfigured ECS service, an over-permissive IAM role, or an unprotected container workload in a single account can affect a regional customer journey or produce a compliance finding that blocks releases.

Security remediation did not scale. The client’s internal standard mandates runtime protection on every container workload. Detection was already in place — scanners flagged non-compliant workloads daily — but remediation was manual. Findings were routed to product teams as tickets, competing with feature work, and the backlog grew faster than it was cleared.

The client required a partner to take ownership of remediation across the estate: applying fixes inside each workload account, on live services, without disrupting them.

Technology solution

Key milestones

• Assumed day-to-day operations of the client’s AWS estate, providing product teams with a single operational front door.
• Replaced ticket-driven security remediation with an event-driven auto-remediation platform — Terraform-deployed Lambda modules that repair non-compliant resources inside the owning account, with no work required from the team that owns it.
• Delivered the flagship remediation: automated container runtime-protection injection across ECS Fargate, validated end-to-end against live services and now rolling out estate-wide.
• Extended the same security standard to Amazon EKS, covering both container orchestrators.
• Progressed from reactive maintenance to owning the platform’s engineering direction — the remediation modules, the infrastructure-as-code standards, and the paved-road patterns teams build on.

Automated security remediation

Remediation runs from a hardened central security account and assumes a least-privilege, ExternalId-scoped role in each of the client’s thousand-plus workload accounts, mitigating confused-deputy risk in cross-account automation. A security finding raises an EventBridge event; a Lambda module repairs the resource; every action is logged, measured, alarmed, and auditable.

Each remediation is a reusable, versioned, peer-reviewed Terraform module, shipped through the same pipelines as the rest of the estate.

Because the modules act on live production workloads in accounts owned by other teams, each is built to be safe by construction: idempotent, so re-running never double-patches; equipped with a dry-run mode that produces the fix without activating it; waiting for the workload to reach a stable state before reporting success; and refusing to delete any resource it cannot prove is unreferenced.

Worked example — container runtime protection. The standard requires a runtime-protection sidecar in every ECS Fargate task. Applied manually, each task definition requires adding one sidecar per application container, mounting its shared volume, rewriting the application’s entrypoint to the agent binary, re-supplying the image’s original entrypoint and command, wiring the agent’s environment variables, and fetching the correct per-product token. Across more than 3,000 task definitions in a thousand accounts, owned by teams with their own roadmaps, this is not achievable by hand.

The remediation module performs it automatically: it reads the non-compliant task definition, resolves the correct enforcer token from the vendor API with the key held in Secrets Manager, injects one sidecar per application container while preserving the original command, registers the patched revision, and — where the team has opted in — rolls it out to the running service, waits for stability, and then retires the previous revision.

Kubernetes platform operations

Alongside ECS, the estate runs Amazon EKS. The runtime-protection standard automated on Fargate tasks is enforced across the cluster fleet as well, giving the client a single security posture across both orchestrators.

Cluster configuration is defined in code and delivered through the same reviewed pipelines as the rest of the estate. Workloads are right-sized and distributed across availability zones. The clusters sit behind the same monitoring, alerting, and support function as the rest of the platform.

Support for internal product teams

We operate the support function for the teams building on the platform: a single intake integrated with alerting, so an alarm and a ticket are the same object; escalation that terminates with the engineers who wrote the remediation modules; blameless post-incident reviews tracked to closure; and proactive monitoring.

Every recurring incident produces a runbook, and recurring runbooks are converted into automation, reducing support volume over time.

AWS technology stack

Team contributions

Our team designed and built the cross-account remediation platform end to end: the event-driven flow, the ExternalId-scoped assume-role model used across the estate, and the remediation modules themselves — including the container runtime-protection injector, built to be idempotent, dry-runnable, and safe to run against live production services.

Alongside it, we run the client’s EKS fleet, operate the support function for internal product teams, and convert recurring incidents into runbooks and recurring runbooks into automation.

Business impact