Building a controlled AWS environment for enterprise experimentation

Define what an experiment may access, express the boundary in code and distinguish a working prototype from an accepted platform.

An experiment needs enough access to answer a useful question. It also needs a clear limit on what it can affect. In an enterprise environment, those requirements have to be designed together: the data the team may use, the connections the workload needs, the actions it may take and the evidence required before its scope expands.

We built an engineering sandbox prototype for an oil and gas company to explore workload designs in a defined AWS environment. Infrastructure as code, scoped implementation tasks and review made the design repeatable and gave the team a concrete starting point for further experiments.

The fictional reference environment below explains how to apply that approach to a small experiment.

Define the experiment before drawing the network

Start with a short contract. For example: a document-processing workload reads a synthetic fixture set, produces a report in a designated location and has no permission to modify source data. A named team owns the experiment and decides when its access expires or changes.

That description gives infrastructure and security engineers something specific to implement. It also gives the agent a useful task boundary. The model can help write templates and checks, while the experiment’s permitted data and actions remain explicit decisions.

Question	A concrete answer for the reference experiment
What question are we testing?	Whether a document-processing workflow preserves required fields
What data may it read?	An approved synthetic fixture set
What may it change?	Its own generated report output
What connections does it need?	Only the service endpoints and destinations agreed for that test
When does access end?	At the experiment’s review point unless the owner approves an extension

An owner tag and an expiry date make intent visible. Enforcing expiry requires an operating process or automation; the presence of a tag does not stop a workload.

Give each boundary a responsible control

A useful reference separates the AWS account or environment boundary, network reachability, workload identity and data permissions. Each answers a different question. A private subnet does not decide which object an application can read. An IAM role does not determine every route a packet can take.

Reference experiment boundary with a workload inside, approved fixture data and an approved service outside, and labelled checks for identity, network access and output. — Illustrative boundaries for a small experiment. Each allowed path needs a defined purpose and a way to verify it.

An organisation-level policy can establish a permissions ceiling, while workload policies grant the specific actions needed for the experiment. Service control policies do not grant permissions themselves, and their coverage has documented exceptions. The effective result depends on the applicable policies together. AWS Organizations documentation.

Store secrets through an approved managed mechanism, with scoped access and a defined rotation process. Our reference approach uses SSM Parameter Store SecureString for secrets. The application should retrieve only what it needs and avoid writing values into logs or error messages. Parameter Store documentation.

Make allowed connections reviewable

Templates turn a verbal boundary into reviewable configuration. For the HTTPS application used in the migration companion, the same small rule builder can express one permitted ingress path:

taskIngress — from controls.ts

// taskIngress generates ONE CloudFormation security group ingress resource for
// an HTTPS task listener — not a complete network security configuration.
 
const SG_RE = /^sg-[a-f0-9]{8}([a-f0-9]{9})?$/;
 
export function taskIngress(
  loadBalancerSecurityGroupId: string,
  taskSecurityGroupId: string,
) {
  if (!SG_RE.test(loadBalancerSecurityGroupId) || !SG_RE.test(taskSecurityGroupId)) {
    throw new Error("Invalid security group");
  }
  if (loadBalancerSecurityGroupId === taskSecurityGroupId) {
    throw new Error("Invalid security group");
  }
  return {
    Type: "AWS::EC2::SecurityGroupIngress",
    Properties: {
      GroupId: taskSecurityGroupId,
      SourceSecurityGroupId: loadBalancerSecurityGroupId,
      IpProtocol: "tcp",
      FromPort: 443,
      ToPort: 443,
    },
  };
}

Its tests require distinct, valid security-group identifiers and a source-group reference for exactly port 443. The returned fragment does not configure a load balancer, certificates, task roles, egress or routes. Those remain separate parts of an actual environment design.

This is why the control should be described precisely: the fragment permits a particular inbound path. It does not establish that every other path is blocked, especially if other rules are attached. Review the effective configuration and then test the running environment. CloudFormation ingress resource reference.

The same discipline applies to service endpoints and outbound traffic. An approved destination should have a business purpose. Its network path and resource policy should be reviewed together, including any path that bypasses an inspection point. A diagram labelled “isolated” is not the evidence that resolves those questions.

Connect configuration checks to running behaviour

Check the configuration locally, then test the behaviour in the deployed environment. Each stage answers a different question.

Verification layer	Example check	What remains to establish
Template or unit check	The ingress resource names the intended source group and port	Whether the effective deployed rules and routes match the intention
Deployed configuration check	Inspect the actual rule, role and resource configuration	Whether the relevant workload behaves as expected
Behavioural check	An allowed request succeeds and a prohibited request fails	Whether the tested cases cover the experiment’s acceptance criteria
Operating review	Inspect recorded actions, ownership and recovery steps	Whether the team can maintain the environment as its use changes

A useful test plan includes rejection. Attempt an unapproved operation using the experiment’s identity. Check that a denied action produces enough diagnostic information for the operator without revealing sensitive input. Verify that legitimate work still succeeds.

Run those checks in an authorised test environment with agreed scope. The companion examples for this series run locally and make no AWS calls; they demonstrate decision and configuration checks, not a live isolation assessment.

Structure the infrastructure work for an agent

We organised the sandbox work around a specification, bounded implementation tasks and review of each change. Each task connected an infrastructure decision to the code that implemented it and the checks needed to accept it.

An effective task might add a template parameter and its validation, or implement one boundary check. Its acceptance criteria should say which configuration is valid, which must be rejected and which external dependencies are still unresolved. If two tasks depend on the same resource, combine them or sequence them so each claimed check can actually run.

Keep the agent’s authoring environment separate from authority to change the live environment. Read-only inspection, local template checks and production deployment have different permission needs. A reviewed change can progress to deployment through the agreed pipeline without giving every implementation task broad credentials.

Expand scope when the evidence supports it

We first built and checked the prototype’s infrastructure, then worked through integration and documentation. Before expanding its use, the next step is to test access boundaries in the deployed environment and agree who will operate it.

For a new engagement, the next decision should follow the experiment’s result. Did it answer the original question? Were the intended access limits demonstrated? Is there a named operating owner? What additional control or integration would broader use require?

That creates a practical path from experimentation to a delivery decision. The Enterprise AI Delivery Assessment can define that first bounded experiment, its AWS architecture, security controls and acceptance evidence before a larger implementation is commissioned.