How Moeve scales AWS governance with automated AWS Organization Service Control Policies

Moeve, formerly known as Cepsa, is a global integrated energy company with over 90 years of experience and more than 11,000 employees. Moeve is committed to driving Europe’s energy transition and accelerating decarbonization efforts. The company has embraced digital transformation to enhance energy efficiency, safety, and sustainability, focusing on investments in green hydrogen, second-generation biofuels, and ultra-fast electric vehicle charging infrastructure.

AWS Organizations and AWS Control Tower are the foundation for operating and governing Moeve’s cloud environment in a centralized and scalable way. Moeve’s Cloud Center of Excellence (CCoE) governs more than 300 AWS accounts across three AWS Organizations, serving 450 managed users. Service Control Policies (SCPs) are the preventive controls that maintain alignment with security and compliance standards. As the account count grew, SCP management became a bottleneck. When the CCoE reviewed and applied every change manually, application teams waited and the operational load kept growing. Letting each team manage its own restrictions was not an option either, because policies would drift and become difficult to audit.

To address this challenge, Moeve worked with Keepler, an AWS Partner Network (APN) partner, to manage the complete SCP lifecycle as code. Policies live in a central Git repository and every change is proposed through a pull request, reviewed, and deployed to AWS Organizations by GitHub Actions pipelines. Stable corporate controls are attached at the OU level, while account-level policies cover workload-specific baselines and temporary exceptions. Amazon EventBridge and AWS Lambda notify the CCoE whenever the organizational structure or a policy attachment changes. This post describes how Moeve designed the model, how the automation works, and the results measured in production.

Prerequisites

To implement a similar model, you need the following:

• A multi-account environment managed with AWS Organizations, and working knowledge of SCPs
• AWS Control Tower deployed as the foundation of the landing zone
• A central Git repository and a CI/CD system (GitHub Actions in this example), with experience deploying infrastructure as code using AWS Cloud Development Kit (AWS CDK) or AWS CloudFormation
• Familiarity with Amazon EventBridge
• A tagging strategy that identifies accounts and workloads

Solution overview

The model separates SCPs into two layers according to their purpose and lifecycle. Structural SCPs are attached at the OU level. They define corporate restrictions related to security, compliance, and the protection of critical services, and they rarely change. Account-level SCPs serve two purposes. First, during onboarding, they set the contextual baseline for a specific account type, such as a generative AI environment with restricted data. Second, after onboarding, they implement temporary exceptions that allow a controlled deviation from the baseline, for example to evaluate a newly released AWS service.

This separation limits the blast radius of every change. A modification to a shared OU policy affects dozens or hundreds of accounts at once, so those policies stay stable. Baselines and exceptions are attached only to the accounts that need them. When Moeve started, AWS Organizations allowed 5 SCPs per entity, which forced multiple controls into monolithic policies that were hard to maintain. The limit is now 10, but the segmentation model addresses needs that exist regardless of the quota: isolating changes, tracing them, and keeping shared controls untouched.

Figure 1. Structural SCPs attached at the Organizational Unit level, and account-level SCPs used for contextual baselines and temporary exceptions.

Automated account onboarding

Account provisioning starts in AWS Control Tower. On top of it, Moeve runs an onboarding layer built with the AWS CDK that completes the organizational configuration of each new account. During onboarding, the account receives a set of metadata describing its purpose, environment, workload type, and compliance context. The automation reads this metadata and attaches the corresponding SCPs before the account is handed over to its team.

Governance therefore does not depend only on where the account sits in the OU structure. A base infrastructure account, a generative AI environment, and a standard application workload each receive a different policy set from the moment they are created, with no manual intervention from the CCoE.

The following metadata identifies a generative AI account with restricted compliance requirements:

account_metadata:
  environment: prod
  workload: genai
  compliance: restricted

Based on that metadata, the onboarding automation attaches these SCPs:

attached_genai_scps:
  - baseline-security
  - genai-restrictions
  - restricted-workload-controls

Figure 2. Automated onboarding flow and dynamic attachment of SCPs.

Managing the SCP lifecycle as code

All SCPs live in a central Git repository, together with a mapping file that defines where each policy is attached, whether to an OU or to an individual account. To create, modify, attach, or detach a policy, the CCoE opens a pull request. After peer review and approval, a GitHub Actions pipeline validates the change and deploys it to AWS Organizations.

Moeve chose this approach for the traceability it provides. Git history shows who changed a policy, when, and under which review it was approved. No one modifies SCPs from the console, so there are no undocumented changes to reconcile later. The same review and deployment discipline that Moeve applies to application code now applies to organizational governance.

The mapping file decouples the definition of a policy from its assignment:

scp_mappings:
  - policy: baseline-infra
    target: ou-infra
  - policy: genai-restrictions
    target: account-genai-dev
  - policy: cloud-security-baseline
    target: ou-cloud-platform

Securing the governance pipeline

The pipeline follows the same least privilege and separation of duties principles that the SCPs enforce on the rest of the organization. It assumes a dedicated IAM role scoped exclusively to SCP actions in AWS Organizations. Production deployments require both a peer-reviewed pull request and a manual approval, so no single person can authorize and deploy the same change. Access to the management account is secured by a break-glass role (protected with multi-factor authentication), which remains available for emergencies, and using it triggers an automatic notification to the security team. Every change leaves evidence in three places: Git history, pipeline logs, and AWS CloudTrail.

Observability of the governance plane

Automating the governance plane without watching it would move the risk instead of removing it, so Moeve monitors the organizational layer itself. AWS CloudTrail records the management events of AWS Organizations. Amazon EventBridge rules filter the events the CCoE needs to act on: creation of new accounts, movement of accounts between OUs, and attachment or detachment of SCPs. An AWS Lambda function enriches each event with the account metadata and delivers it to the CCoE notification channels.

For more details on how Moeve built this notification system, see Scaling AWS Governance: How Moeve reduced response times with automated notifications.

Figure 3. Organizational events are captured by AWS CloudTrail, filtered by Amazon EventBridge rules, enriched by AWS Lambda, and delivered to CCoE notification channels.

Exception handling in practice

A real scenario shows the model working: a team wants to evaluate a newly released AWS service that Moeve’s baseline SCPs still deny.

The team proposes the change through the standard GitOps flow, updating the SCP mapping of its own account. After review and approval, the pipeline attaches a temporary exception SCP to that account only. The shared policies protecting the rest of the OU never change. From that moment, the CCoE receives an automated notification that the account is running a non-standard SCP configuration, and the notification repeats daily while the exception stays active.

The exception closes in one of two ways. If the evaluation ends or the service is rejected, the exception SCP is detached and the account returns to its baseline. If the service is approved for corporate use, the baseline itself is updated through the same GitOps flow and the change becomes standard for the relevant account types. Either way, every exception has an owner, a scope, a review path, and an explicit closure. There are no informal deviations applied from the console.

Results

As of August 2026, the framework manages 150 SCPs across more than 300 AWS accounts in three AWS Organizations, alongside more than 250 AWS Control Tower controls, with a CCoE that processes around 4,000 access requests per year. Since the SCP lifecycle moved to the pipeline, manual changes in the AWS Organizations console have dropped to zero, and so have the configuration errors those manual actions used to cause. Every change is traceable end to end, and the estate has kept growing without adding people to the governance team.

These results extend the governance automation program Moeve started with AWS Control Tower in 2022. Account deployment time has fallen by 75%, the notification system has cut the staff effort dedicated to cloud governance by 45%, and its notifications have reached an adoption rate of over 85% among Moeve’s teams.

Conclusion

Moeve set out to remove a governance bottleneck and ended up with an operating model. The same governance-as-code foundations now manage Tag Policies, Resource Control Policies (RCPs), and permission boundaries, so new control types are added without changing how the CCoE works. Governance effort no longer grows in proportion to the number of accounts: automation handles the routine attachments, exceptions are scoped and visible, and the CCoE concentrates on the decisions that need human judgment. That combination is what allows Moeve to keep growing on AWS without choosing between speed and control.