Beyond shared networking: an AWS sandbox for engineering

An oil and gas company wanted to give engineers a controlled place to build AI-assisted solutions, with enough flexibility to explore new tools and approved data sources. The longer-term ambition was an on-demand workspace platform using Amazon WorkSpaces.

That required a significant departure from the organisation’s standard AWS networking model. Existing workloads used centrally owned networking and shared subnets. The engineering sandbox would own its VPCs, Transit Gateway, routing and supporting network services inside a dedicated account.

One engineer carried the implementation from an agreed architecture into an EC2 prototype, deployment automation and verification tooling, using AI agents for substantial parts of the build. The initial implementation and review were concentrated over two days, with integration and documentation continuing over the following week.

The outcome was a network foundation designed to support the move from one experimental machine to managed engineering workspaces.

Why the shared-network model needed an exception

The existing platform centralised VPCs and network services in network accounts, then shared workload subnets through AWS Resource Access Manager. Application accounts could run compute in those subnets while the network team retained ownership of routing and connectivity.

That was an established enterprise pattern. The sandbox had different requirements: a separate lifecycle for experiments, a clear boundary around their reach, and a future compute platform built around WorkSpaces.

The WorkSpaces target drove an early decision to place VPC ownership in the sandbox account. The design went further by placing the Transit Gateway and supporting network services there too. VPC ownership supported the target desktop model; TGW ownership kept the sandbox’s routing decisions within its own platform boundary.

Zoom outZoom inReset100%Close

The change is in ownership and lifecycle. Both models retain enterprise security controls; WorkSpaces is the next compute stage.

This made the architecture exception purposeful. It gave the sandbox its own operating boundary while keeping enterprise connectivity subject to the organisation’s controls.

Why the local Transit Gateway mattered

An owned VPC could have attached directly to the central Transit Gateway. We chose a sandbox-owned TGW so the platform could manage initiative routing locally and expose a deliberate connection to the wider environment through peering.

That choice added cost and configuration to maintain. It also made the boundary explicit: connecting the platforms required acceptance by the receiving side, route-table configuration and defined routes in both directions. AWS Transit Gateway peering uses static routes, which makes route changes a deliberate part of the integration. AWS peering documentation.

The following simplified CloudFormation fragment illustrates the local routing posture:

Resources:
  SandboxTransitGateway:
    Type: AWS::EC2::TransitGateway
    Properties:
      AutoAcceptSharedAttachments: disable
      DefaultRouteTableAssociation: disable
      DefaultRouteTablePropagation: disable

These settings leave route-table associations and propagation to explicit configuration. The remaining templates define the attachments, route tables, routes and inspection paths. The fragment alone does not create an isolated network. CloudFormation resource reference.

One VPC per initiative also gives provisioning and teardown a useful unit. Isolation between initiatives still depends on the routing and access controls connecting those VPCs. We treated those relationships as part of the implementation and its checks.

The preparation extended beyond the sandbox repository

Moving networking into a workload account affected deployment authority, organisation policies, address allocation and integration with the existing network. The work crossed several repositories and required coordination with the teams responsible for those controls.

Deployment sequencing mattered as much as the templates. The initial network deployment created a peering request. Configuration that depended on the accepted connection followed the receiving network’s approval. That kept cross-account consent visible and allowed the subsequent routing changes to remain reproducible in code.

The design could then be built into the organisation’s environment without treating all of those dependencies as last-minute deployment problems.

Prepare the network for WorkSpaces from the start

The prototype used Windows 11 on EC2. Amazon WorkSpaces remained the intended managed desktop platform. WorkSpaces Core Managed Instances had also been considered during design; the implemented prototype used plain EC2.

We separated the infrastructure into three CloudFormation stacks: the account-level network foundation, each initiative’s VPC and network services, and its compute. This created a place to change the compute layer while preserving the network’s ownership and routing model.

Address planning accounted for more than a single machine. Workload subnets were sized for future desktop capacity, with headroom for supporting services. Reserving that space early reduced the chance of having to rebuild the environment around a larger address plan later. AWS’s WorkSpaces guidance also recommends planning subnet capacity for growth. WorkSpaces VPC design guidance.

Preparation also included provision for a future NAT egress path. Completing and validating its routing through the intended inspection controls remains part of the WorkSpaces transition. A NAT resource in a template is only one component of that change.

The target identity model used native Microsoft Entra ID join and Intune management, avoiding a dependency on joining the corporate AD domain. Conditional Access, enrolment and endpoint-security policy were explicit integration workstreams for that target.

The service-management direction was equally deliberate. An approved request would generate an initiative configuration file and a pull request; the deployment pipeline would build the environment from that configuration. The prototype established the configuration format. The ServiceNow integration remains a subsequent step, preserving the same review and deployment workflow as provisioning becomes automated.

Choose AWS Network Firewall for a different operating model

The existing enterprise network used Palo Alto firewalls. For the sandbox, we chose AWS Network Firewall because we wanted approved firewall requests to become repeatable infrastructure changes through a future ServiceNow workflow. That automation objective was a key reason to depart from the established firewall deployment approach.

AWS Network Firewall puts the sandbox’s rule groups and policies into the same CloudFormation and reviewed deployment process as the rest of its infrastructure. An approved request can therefore become a proposed configuration change, with a visible diff, automated checks and a controlled deployment.

The ServiceNow connection is not built yet. Today, engineers prepare the configuration and rule changes for review. The templates and deployment workflow provide the foundation for connecting the request process later.

The enterprise Palo Alto firewall remains an independent gate owned by Security. Choosing AWS Network Firewall inside the sandbox did not transfer that approval authority to the sandbox team.

Keep east/west access deliberate

Each initiative has its own VPC, and the local Transit Gateway’s routing policy blocks initiative-to-initiative traffic. An approved connection to one enterprise service must not create a path into another initiative. Firewall requests stay within that routing boundary; changes to the boundary require a separate architecture and network review.

For an internal service, two independently owned firewalls must permit the connection. The sandbox’s AWS Network Firewall controls the initiative’s access; the enterprise Palo Alto gate separately controls entry to the destination environment. Security groups add workload-level restrictions. Internet traffic has a separate inspection path and policy.

Zoom outZoom inReset100%Close

A conceptual internal access path. Both firewall gates and the routing policy must permit the connection. Cross-initiative access remains blocked.

The internal AWS Network Firewall policy uses strict rule ordering and an explicit default drop action. Access is added for the approved source, destination, protocol and port. AWS documents how strict ordering and default actions work in its stateful rule evaluation guide.

Verification covers the intended connection and the boundaries around it: the approved service should be reachable, unrelated services and other initiatives should remain blocked, and flow logs should confirm that traffic traversed the inspection controls. Return routing matters too—AWS Network Firewall needs both directions of a flow to pass through the same endpoint. AWS routing guidance.

These checks also belong in the WorkSpaces transition. Reusing the network foundation does not remove the need to validate a new compute and access model.

Relax application controls without relaxing the boundaries

Engineering experiments involve changing SDKs, package dependencies and AI tools. Relaxing the sandbox’s Airlock application-control policy gives engineers room to install and run that software without requesting an exception for every iteration. It also means planning for the possibility that untrusted code will execute.

Consider a compromised npm dependency. If its malicious code runs during an allowed install script or when the application imports it, it can act with the permissions available to that process. Local code, data and accessible credentials may be exposed. Disabling install scripts reduces one route to execution; it does not make a malicious dependency safe to run. npm script documentation.

The containment strategy gives that compromised workspace a limited set of places to go.

Between initiatives: a routing boundary

Each initiative owns a separate VPC. The local TGW routing policy blocks traffic between initiatives, so attaching them to the same gateway does not create a shared internal network. The exception that permits an experiment to reach one approved enterprise service does not grant it access to another initiative.

Between machines: a security-group boundary

Within one VPC, traffic between machines can follow local routes without crossing the TGW or the perimeter firewall. Machine isolation therefore depends on the destination’s security-group rules. The compute template has no general peer-to-peer ingress permission: another workspace is not an approved source simply because it belongs to the same initiative or security group. AWS requires explicit rules to allow traffic between instances sharing a group. AWS security-group guidance.

The prototype currently has one machine per initiative. Adding more machines means preserving those ingress restrictions across every attached security group and testing that a connection initiated from one workspace to another is denied. Any intentional machine-to-machine service needs its own narrowly scoped exception.

Zoom outZoom inReset100%Close

An infected package is a containment scenario, not a claim that malware becomes harmless. The peer-machine view illustrates the controls required as the prototype grows.

Permitted connections and credentials still matter

A firewall cannot distinguish every legitimate request from malicious activity using an allowed connection. A compromised workspace may attempt to misuse an approved internal service or send data through permitted internet access. Application authorisation, endpoint protection and monitoring remain necessary alongside the network controls.

AWS API and management access are a separate boundary. Instance-role permissions, developer sessions and stored tokens can give code authority beyond what direct machine-to-machine networking permits. Systems Manager access is governed by IAM; it is not evidence that peer ingress has been opened. IMDSv2 is useful metadata protection, but it is not a barrier between a malicious local process and all credentials available on that host. AWS guidance on instance roles.

Before expanding the relaxed policy, acceptance must cover effective IAM and management permissions as well as denied network paths. The operating requirements are to keep deployment authority outside experimental sessions, limit accessible secrets and data, use scoped development credentials, and preserve endpoint monitoring. These controls need to be checked together; a blocked port alone does not establish complete machine isolation.

Engineers can still install packages, compile code, run local services and use the destinations approved for their experiment. They do not need broad access to neighbouring workspaces or unrelated enterprise systems to do that work. If compromise is suspected, the response is to isolate the workspace, preserve the evidence, revoke exposed credentials and rebuild from a trusted image. Rebuilding the machine alone does not invalidate a stolen token.

Connect ServiceNow to the change workflow

The planned integration would carry an approved firewall request from ServiceNow into a pull request and the existing deployment process. The objective is to reduce the repeated work between approval and implementation: interpreting a ticket, re-entering addresses and ports, preparing a rule and assembling the change evidence.

Zoom outZoom inReset100%Close

Target workflow. Templates and reviewed deployment already exist; ServiceNow orchestration and ticket feedback remain to be implemented.

A request would identify the initiative, destination, protocol and port, business purpose, owner and review date. After approval, automation would generate the proposed rule change and link it to the ticket. Validation would reject broad or out-of-scope access, and a reviewer would check the exact diff before the pipeline applied it.

The enterprise Palo Alto request would retain its own Security approval and implementation process. The workflow would track that dependency and verify the complete path before closing the request. Approval of the sandbox change alone would never count as approval of the enterprise gate.

Verification results, deployment references and the reviewed change would return to the ticket. Withdrawal or expiry of access would need a corresponding rule-removal change and a check that access had closed; a date on a ticket would not revoke access by itself.

That is the intended delivery benefit: less manual translation and rework for a precisely approved change, with the same separation of duties, east/west segregation and traceable implementation. The ServiceNow integration is the next step in delivering that benefit.

Use AI to carry the architecture into code

The Superpowers workflow organised implementation around a specification, bounded tasks and review checkpoints. Tasks connected architectural decisions to templates, deployment configuration, tests and operating guidance.

AI agents produced substantial implementation work. The engineer resolved architecture choices, coordinated cross-account prerequisites, sequenced dependent changes and reviewed the output. Tests received the same scrutiny as infrastructure: a test needed to detect an incorrect relationship, not just confirm that a named resource existed.

This let one engineer carry a broad implementation across network, compute and deployment concerns while keeping architectural responsibility and acceptance decisions explicit. The follow-through included integration and documentation, so the result could be operated and extended after the initial build.

The business outcome and the next step

The company gained an EC2 sandbox prototype and an implementation path toward on-demand engineering workspaces. The work established the account-local network, controlled connectivity, repeatable deployment and the preparation required to evolve its compute layer.

The next stage is to deliver and validate the WorkSpaces service on that foundation, complete the identity and endpoint-management integrations, and connect ServiceNow approvals to provisioning and scoped firewall changes. Those steps build on the architecture already established.

For an enterprise AI programme, this is often the work that makes a promising use case deliverable: adapting the existing platform model, preserving security ownership and planning how an experiment becomes an operated service.

Our Enterprise AI Delivery Assessment brings those decisions into the first scope—use case, architecture, controls, dependencies and acceptance—before a larger implementation is commissioned. The technical companion explores the boundary and verification approach with illustrative examples.