# EG334S school deployment — individual runbooks

Status: **validated against the accepted school deployment; retained for repeatable team execution**
Target AWS account: the authorised school account identified only through the
protected `EG334S_EXPECTED_ACCOUNT_ID` environment value.
Scope: VPN #1 Virginia-Ireland and VPN #2 Ireland-East Asia (Hong Kong). Direct VPN #3 and
Virginia-Azure private connectivity are not required.

## Rules that apply to everyone

1. Use only your own school identity. Never share passwords, access keys, MFA
   devices, private keys or VPN pre-shared keys.
2. Before every write, run `aws sts get-caller-identity`; the account must be
   the protected `EG334S_EXPECTED_ACCOUNT_ID` value and the region must match
   the assigned stage.
3. Use the extracted, checksum-verified school IaC package. Keep completed
   environment and strongSwan secret files outside Git with mode `600`.
4. One operator performs the change; the named peer reads the account, region,
   stack name and parameters back before approval.
5. Capture timestamps, stack events, outputs and test results, but redact
   student identifiers, account credentials, private keys and PSKs.
6. Stop on an unexpected account, `AccessDenied`, quota failure, replacement of
   an owner resource, open administrative CIDR, failed required query or cost
   anomaly. Record the failure; do not improvise around it.
7. A task is complete only when deployment, verification, evidence and handoff
   are all complete.

## Shared preparation

Each member performs these steps in their own session:

1. Extract `EG334S_School_Account_IaC_Package.zip` into a private working
   directory.
2. Verify `shasum -a 256 -c MANIFEST.sha256`.
3. Copy `docs/iac/school-account.env.example` outside the repository and fill
   the approved profile, exact account ID, administrator `/32`, regional key
   pairs, monitoring email and stack prefix.
4. Run `./scripts/validate-iac.sh`.
5. Source the protected environment file and run
   `./scripts/school-deploy.sh plan`. This action must remain read-only.
6. Save a sanitized caller/account/preflight record for Casper's execution log.

## Casper — deployment governance and teardown control

Peer verifier: **Soo Fern**
Target effort: **2-3 hours**, distributed across the deployment window.

### Before deployment

1. Collect the four sanitized preflight records and confirm every caller is in
   the protected expected school account.
2. Confirm `us-east-1` and `eu-west-1`, regional key pairs, administrator `/32`,
   quotas and monitoring email.
3. Run the full static validation and record the result.
4. Review the proposed stack order and ownership:
   `onprem -> hub -> ALB -> recovery`, with Azure VPN #2 staged separately.
5. Review each CloudFormation change set before execution. Reject unexpected
   replacement, deletion, IAM expansion or resource names tied to the personal
   account.
6. Open the execution log with columns for time, operator, peer, account,
   region, action, result, evidence link and rollback decision.
7. Give a recorded GO only when the account, parameters, cost owner and
   rollback owner are confirmed.

### During deployment

1. Announce the current stage and require the operator and peer to repeat the
   account, region and stack name.
2. Record every stack transition and any retry; no unrecorded console changes.
3. Monitor billable resources and stop the run if costs or quotas deviate from
   the plan.
4. Verify Jeff's Virginia and VPN #1 handoff before allowing VPN #2 acceptance.
5. Verify Adelene's hub and routing handoff before allowing the ALB/recovery
   stage.
6. Confirm Soo Fern's acceptance matrix has evidence for every required claim.

### Teardown or parking

1. Obtain the team decision: demonstrate, park or teardown.
2. Enforce borrower-before-owner deletion: recovery, ALB, Azure VPN connection,
   Azure gateway if approved, Ireland hub, then Virginia.
3. Run `scripts/verify-teardown.sh` for both AWS regions and the approved Azure
   scope.
4. Reconcile retained S3, CloudTrail, Flow Log, CloudWatch, SNS and evidence
   resources explicitly.
5. Have Soo Fern independently verify the residual-resource report.

### Casper deliverables

- Preflight and change-approval log
- Cost and rollback decision record
- Final deployment/teardown sign-off
- A short explanation of stack ownership and deletion order

## Jeff — Virginia cell, strongSwan and VPN #1

Peer verifier: **Adelene**
Target effort: **2-3 hours**.

### Deploy the Virginia cell

1. Confirm the caller and set region `us-east-1`.
2. Review `vpn1-onprem-us-east-1.yaml`, especially VPC `10.0.0.0/16`, subnet,
   administrator `/32`, key pair and central evidence bucket settings.
3. With the write gate enabled only for the attended window, run:

   ```bash
   export EG334S_EXECUTE=DEPLOY
   ./scripts/school-deploy.sh deploy-onprem
   ```

4. Wait for `CREATE_COMPLETE` and record the VPC, subnet, route table,
   strongSwan EC2, private test host, Elastic IP, security group, Flow Log and
   evidence-bucket outputs.
5. Confirm the strongSwan EC2 has source/destination check disabled and IPv4
   forwarding persistently enabled.
6. Confirm the private test host routes `10.1.0.0/16` through the strongSwan
   private address.

### Establish VPN #1

1. Wait for Adelene's Ireland hub stack and VGW handoff.
2. Run `./scripts/school-deploy.sh configure-vpn1-firewall` to restrict UDP
   500/4500 to the generated AWS tunnel peers.
3. Retrieve the AWS vendor configuration into a protected local file.
4. Complete the supplied strongSwan configuration and secrets templates outside
   Git. Do not display or record PSKs.
5. Install the root-owned configuration, restart strongSwan and record only
   sanitized service/tunnel status.
6. Confirm the AWS VPN is `available`, at least one tunnel is `UP`, and the
   Virginia private host can ping and reach HTTP on the Ireland private server.
7. Ask Adelene to verify the reciprocal Ireland route and tunnel endpoint.

### Jeff deliverables

- Virginia stack outputs and route evidence
- Persistent IPv4-forwarding and disabled source/destination-check evidence
- Sanitized VPN #1 status plus private ICMP/HTTP results
- A short explanation of why the private host routes through strongSwan

## Adelene — Ireland hub, routing and VPN #2

Peer verifier: **Jeff**
Target effort: **2-3 hours**. Bernard performs Azure writes if Adelene has
Reader rather than Contributor access.

### Deploy the Ireland hub

1. Confirm the caller and set region `eu-west-1`.
2. Verify Jeff's Virginia stack outputs, especially the strongSwan Elastic IP
   and central log bucket.
3. Review `vpn1-awspublic-eu-west-1.yaml`, VPC `10.1.0.0/16`, public subnet,
   VGW, customer gateway, route propagation, Flow Log, CloudTrail, SNS and
   alarms.
4. Run `./scripts/school-deploy.sh deploy-hub` during the attended write window.
5. Wait for `CREATE_COMPLETE`; record the VPC, subnet, route table, hub EC2,
   VGW, VPN #1, monitoring and audit outputs.
6. Verify the Ireland route table learns `10.0.0.0/16` through VGW propagation
   and that no route claims the VGW provides VPN-to-VPN transit.
7. Hand the VGW and VPN #1 endpoint information to Jeff without exposing PSKs.

### Coordinate VPN #2

1. Review the Azure VNet `10.2.0.0/16`, workload subnet and GatewaySubnet
   parameters with Bernard.
2. Run Azure Bicep `what-if`; Bernard executes Azure writes unless Adelene has
   approved Contributor access.
3. Stage the AWS VPN #2 customer gateway using the Azure gateway public IP.
4. Transfer the AWS-generated PSK through the approved protected channel only.
5. Complete the Azure local-network gateway and connection using the supplied
   Bicep runbook.
6. Verify AWS and Azure both report the connection established and confirm
   Ireland-East Asia private ICMP/HTTP tests.
7. Verify routes for `10.1.0.0/16` and `10.2.0.0/16`; do not add or test a
   Virginia-East Asia direct path.
8. Have Jeff independently check the VPN endpoints and reciprocal routes.

### Adelene deliverables

- Ireland hub/VGW and propagated-route evidence
- Sanitized VPN #2 control-plane evidence from both providers
- Ireland-East Asia private ICMP/HTTP results
- A short explanation of route propagation and the non-transitive boundary

## Soo Fern — two-AZ service, monitoring and acceptance

Peer verifier: **Casper**
Target effort: **2-3 hours**.

### Deploy the application entry and active secondary

1. Confirm the caller and set region `eu-west-1`.
2. Verify Adelene's hub stack is complete and obtain its VPC, primary subnet,
   route table, hub instance and security-group outputs.
3. Review `hub-alb-eu-west-1.yaml`; confirm it creates the second Ireland
   subnet in a different AZ and an internet-facing ALB on HTTP/80.
4. Run `./scripts/school-deploy.sh deploy-alb` and record the ALB URL, two
   subnets, listener, target group and health alarm.
5. Review `hub-recovery-eu-west-1.yaml`, including named-IAM capability and
   desired capacity one.
6. Run `./scripts/school-deploy.sh deploy-recovery` and confirm one healthy
   target in each AZ.

### Test and record acceptance

1. Request the ALB repeatedly and record successful responses from both
   targets.
2. Stop or isolate one target using the approved failure-test procedure.
3. Confirm the ALB routes only to the surviving healthy target and measure any
   transient errors and recovery time.
4. Restore both targets and confirm both return healthy.
5. Verify CloudTrail logging, both VPC Flow Logs, CloudWatch alarms/dashboard,
   SNS subscription and retained S3 evidence.
6. Consolidate the required tests: VPN #1, VPN #2, Virginia-Ireland private
   reachability, Ireland-East Asia private reachability, ALB HTTP, active-active
   failure routing and monitoring.
7. Mark failures as failures or provisional results; never convert missing
   evidence into PASS.
8. Give Casper the sanitized evidence register and independently verify
   Casper's teardown report.

### Soo Fern deliverables

- ALB/two-AZ topology and two-healthy-target evidence
- Failure-routing and restoration result
- Monitoring/audit control evidence
- Completed acceptance and evidence register

## Final team sign-off

All four members sign only after they can explain their own deployment, routes,
tests, failure conditions, costs and teardown. Bernard then performs the final
integration review and records whether the school environment is **accepted**,
**accepted with provisional items**, or **rolled back**.