AWS security guardrails that keep delivery moving

An oil and gas company needed to give application teams room to deliver while retaining central control of its AWS security baseline. Different workloads needed different services. Platform automation needed to maintain the landing zone. Approved engineering initiatives sometimes needed an architecture exception.

The work brought those requirements into a reusable policy delivery platform. Security controls became versioned infrastructure, workload boundaries became small configuration changes, and each deployment became visible in the build pipeline.

One principal engineer carried the work across several stages: organisation-wide policy engineering, a reusable OU deployment framework, controlled exceptions for an engineering sandbox, and a new internet-exposure pilot. The July framework was built over three days. The October policy implementation and initial pilot attachment followed over two days, using the same delivery foundation.

The result is a practical operating model for AWS governance: teams can work within agreed boundaries, and the platform can tighten those boundaries through a tested rollout.

Make central policy usable by delivery teams

AWS accounts provide a useful separation between workloads, but account ownership alone does not define what a team should be able to build or change.

The organisation already had controls around procurement, tagging and networking. The work extended that foundation with reusable security baselines: protect central security automation and audit services, retain encryption requirements, control network creation, and restrict member accounts from leaving the organisation.

Those controls establish responsibilities that continue to apply when an application team receives broad administrative access in its own account. The team can operate its workload while central security and platform functions retain authority over the shared foundation.

A second layer adapts the boundary to the workload. An approved service catalogue for one application can differ from another without requiring a separate copy of the whole security baseline.

Zoom outZoom inReset100%Close

The organisation owns the common baseline. Workload teams work within a tailored service boundary and their own delivery permissions.

Give engineers a small interface

The most useful interface was a configuration file, rather than a policy editor.

A folder represents an organisational unit, or OU, in AWS Organizations. A configuration file inside it selects a reusable policy template and supplies the workload-specific parameters. Adding another workload follows the same pattern.

The Azure DevOps pipeline resolves the intended OU, validates the configuration and deploys the policy through CloudFormation. It creates a separate job for each policy stack, with its own result, logs and timing. Up to four stack deployments run concurrently.

Engineers can therefore propose a change to an application’s approved services without editing the pipeline or redesigning the organisation’s policy structure. Security reviewers can assess the change in the same place as the infrastructure that implements it.

The operating model also covers retirement. Removing a configuration file lets the pipeline remove the policy stack it owns, after the remaining deployments succeed. That keeps onboarding, change and offboarding within one managed process.

Keep administration inside the boundary

Service approval and administrative authority answer different questions.

An application may need an AI service, storage and compute. That does not mean every administrator should be able to change audit collection, model-invocation logging or central storage governance.

The framework therefore supports an additional policy for nominated administrative roles. It restricts a defined set of governance actions while leaving the workload’s approved delivery activity to its normal permissions.

This creates a useful separation for external engagements and application teams: substantial authority to build and operate, with specific central responsibilities retained by the organisation.

Make exceptions part of the architecture

The engineering sandbox needed to own its network, departing from the established shared-network model. That required an exception to the normal VPC-creation control.

The exception was tied to one deployment role in one account. Other accounts could not acquire it simply by creating a role with the same name. Protection of the deployment identity was considered alongside the exception.

That is a valuable pattern for enterprise AI delivery. A new initiative can have different platform requirements while still entering through an explicit design decision, an approved identity and reviewed infrastructure changes.

Tighten internet exposure through a tested pilot

The latest stage adds three policy groups—network, applications and data—plus an EC2 declarative policy that manages service configuration.

The intent is to preserve approved private deployment paths while constraining how workloads create public exposure. That includes the network resources they can create, the endpoint types they can select and the public-sharing settings the platform maintains.

Before expansion, the validation tooling evaluated a 90-day activity sample across 62 AWS accounts. Automated checks covered policy rendering, condition behaviour and the interpretation of service requests. Live checks then exercised the controls in a dedicated pilot account, including the provisioning of eight private resource-stack types.

Zoom outZoom inReset100%Close

Historical replay, automated checks and live private deployments test different aspects of the policy. The exposure controls are at pilot stage, ahead of a wider rollout.

The historical evaluations test compatibility with proposed policies. The live deployments test whether useful private workloads still function after attachment. Both matter when a security control can affect many teams at once.

The pilot has its policies attached. A monitored soak and staged expansion remain the next steps.

Delivery cadence built on an existing foundation

The work developed in stages rather than as a single policy release:

Stage	Delivery focus
2024	Deployment-aware tagging work around serverless infrastructure
June–September 2025	Root-policy refactoring, reusable security baselines and protection of deployment identities
April 2026	Member-account exit controls
July 2026	Configuration-driven OU policies, separate pipeline jobs and targeted administrator restrictions
September 2026	An account-scoped networking exception for the engineering sandbox
October 2026	Internet-exposure policies, historical replay, automated validation and initial pilot attachment

Each stage added a capability to the same operating model. The October pilot could reuse the framework’s configuration, attachment and deployment lifecycle, concentrating the new work on control behaviour and verification.

A governance platform that can evolve with the business

The business outcome is a clearer division of responsibility and a repeatable way to change it.

Central teams maintain shared controls. Application teams request the services their workloads need. Approved exceptions have an owner and an implementation path. Policy deployments have visible results, and broader enforcement starts with compatibility testing and a pilot.

That gives an organisation a foundation for adopting new AWS services and AI workloads while retaining control of the boundaries around them.

For the implementation details, read SCP guardrails as code: policy layers, pipelines and tested rollout.