Confirm section ownership, speaking order and outstanding technical actions.
EG334S Smart Multi-Cloud Project
Hybrid Enterprise Multi-Cloud Architecture
Three connected cloud environments, two explicit Site-to-Site VPNs and a resilient two-Availability-Zone application tier in Ireland—supported by monitored recovery and controlled teardown.
3 cloud cells
2 IPsec paths
Non-transitive VGW routing
Two-AZ application tier
10-minute recovery objective
Accepted school deployment · current operating environment
School AWS · integrated live hub ACCEPTED
The authorised school deployment is now operational under the eg334s-team2 project prefix. Its internet-facing Application Load Balancer spans eu-west-1a and eu-west-1b and distributes HTTP traffic across Web Node 1 (10.1.1.119) and Web Node 2 (10.1.2.111).
School AWSLIVE · ACCEPTED · Virginia and Ireland stacks deployed in account
427617722186School AzureLIVE · CONNECTED · East Asia workload and VPN #2 in
eg334s-team2-rgLoad balancingPASS · two healthy targets · one in each Ireland Availability Zone
Hub resilienceACTIVE-ACTIVE · one running instance in each Availability Zone · ASG desired capacity 1
VPN #1available · one AWS tunnel endpoint UP
Last verified1 Aug 2026, 20:26 SGT · Test 9 completed and both targets restored healthy
Claim boundary. Test 9 abruptly stopped the eu-west-1a application target without deregistration or draining. Across 203 one-second requests, 198 returned HTTP 200 and five transient failures were retained while ALB health detection converged in 36.8 seconds. The eu-west-1b target remained healthy and served 129 responses; both targets and private-path pings finished healthy. This proves active-active application resilience, not zero-interruption failover, whole-AZ failure or regional HA.
Decommission deadline
--
Sun 30 Aug 2026, 23:59 SGT · official penalty applies to AWS resources left running
Project week
1 / 5
Plan & set up (ahead: AWS build already live)
Milestones done
4 / 6
M1 + M2 + M3 + M4 · the system works
Programme readiness
AMBER
Engineering proven · people, approval, demo and closure gates remain
Project schedule · assessment runway and official timetable
Validate VPNs, ALB, monitoring and access. Rebuild VPN #2 only if parked or unhealthy.
Deliver the shared team presentation and execute the approved live demonstration.
Complete dependency-ordered decommissioning and retain two-person verification.
Delivery runway · updated for the accepted live environment
Access and checkpoint preparation. Obtain the two AWS administrator controls, verify team logins, confirm report ownership and agree the presentation order.
Checkpoint and decision gate. Record ownership, speaking order and any corrective actions arising from the assessment.
Individual validation. Each member performs the approved connectivity test, reviews the relevant IaC and validates the report and shared-deck statements they may defend.
Integration rehearsal. Rehearse VPN, ALB and resilience evidence; reconcile monitoring, cost, test and teardown records.
Freeze and readiness gate. Run the complete team rehearsal on 24 Aug. On 25 Aug, verify infrastructure health and rebuild VPN #2 only if it was parked or validation fails.
Assess, close and decommission. Present on 26 Aug, complete permitted corrections, then execute and peer-verify teardown before 30 Aug at 23:59 SGT.
Official 15-session class timetable All dates and delivery modes
| Session | Date | Lecturer | Mode | Activity |
|---|---|---|---|---|
| 1 | Fri, 24 Jul | Wilson Huan | Sync-Physical | Project discussion and group formation |
| 2 | Mon, 27 Jul | Wilson Huan | Sync-Physical | Project discussion and group formation |
| 3 | Wed, 29 Jul | Wilson Huan | Sync-Online | Project session |
| 4 | Fri, 31 Jul | Kor Hian Loon | Sync-Online | Project session |
| 5 | Mon, 3 Aug | Kor Hian Loon | Sync-Online | Project session |
| 6 | Wed, 5 Aug | Wilson Huan | Sync-Online | Project session |
| 7 | Fri, 7 Aug | Kor Hian Loon | Sync-Online | Checkpoint assessment |
| 8 | Tue, 11 Aug | Kor Hian Loon | Sync-Online | National Day public-holiday make-up lesson |
| 9 | Wed, 12 Aug | Wilson Huan | Sync-Online | Project session |
| 10 | Fri, 14 Aug | Kor Hian Loon | Sync-Online | Project session |
| 11 | Mon, 17 Aug | Kor Hian Loon | Sync-Online | Project session |
| 12 | Wed, 19 Aug | Wilson Huan | Sync-Online | Project session |
| 13 | Fri, 21 Aug | Kor Hian Loon | Sync-Online | Project session |
| 14 | Mon, 24 Aug | Kor Hian Loon | Sync-Online | Final preparation and rehearsal |
| 15 | Wed, 26 Aug | Wilson Huan | Sync-Online | Group presentation and technical demonstration |
All dates are SGT. The 25 Aug activity is a readiness gate, not an automatic rebuild. Teardown must be verified across us-east-1, eu-west-1, Azure and project-specific Cloudflare services.
1What we are judged onThe standard, first. Nothing further down this page can be judged without it.
Assessment · official weighting (Project Information §4)
Checkpoint
30%
Individual · problem-solving, ownership, attendance
Presentation
30%
Individual · delivery, slides, Q&A
System demo
20%
Technical / team · completeness & troubleshooting
Report
20%
Group · neatness, clarity, logical flow
60% is individual (Checkpoint + Presentation). Build the system as a team; own and defend your own section alone.
Presentation rubric · what assessors score (individual, 30%)
| Performance indicator | Excellent (top band) | What it takes |
|---|---|---|
| Organisation & Content (60) Organisation & supporting materials; Content |
Agenda exists, coherent & interesting sequence; supporting materials used innovatively & explained in context; can explain all details, constraints and work-arounds. | Have a clear agenda; every diagram/screenshot explained in context; be able to explain the whole project's details, limits and how you worked around them. |
| Presentation Skills (40) Delivery; Q&A |
Interesting, eloquent, enthusiastic delivery (not heavily scripted); handles all Q&A well and anticipates questions. | Rehearse so you're not reading slides; pre-empt likely assessor questions and prepare answers. |
Report rubric · what assessors score (group, 20%)
| Performance indicator | Excellent (top band) | What it takes |
|---|---|---|
| Report Presentation (20) Writing; Presentation & supporting materials |
Exceptionally clear, precise, concise English; few typos; professional layout; all illustrations well formatted. | Proofread hard; consistent styles/margins; clean, labelled figures and screenshots. |
| Technical Content (30) Organisation & structure; Literature survey; Quality of analysis |
Structure entirely correct, all sections placed; exemplary range of references; well-informed, authoritative discussion of a complex problem with depth. | Use a logical, complete structure; cite an exemplary range of authoritative references; show reasoned technical analysis, not just description. |
Verified on 27 Jul 2026 against the supplied official Presentation Assessment Rubrics and Report Assessment Rubrics PDFs. Presentation is marked out of 100 (60 + 40); the report rubric has 50 rubric marks (20 + 30) and the report contributes 20% of the module assessment.
Report requirements & structure (Project Information §5)
Working section-order proposal PROVISIONAL
Not yet confirmed by the team. The brief labels its contents page as a sample for reference only, so the order and owner chips shown here are planning placeholders. Use the matrix to develop the proposal; do not treat it as the approved Responsibility Assignment Table. Changes save to the shared planning matrix that every visitor sees.
Must include
- start Responsibility Assignment Table (name, admin no., role, topic, section, remarks)
- evidence Diagrams, screenshots, YAML files & configuration
- refs Bibliography of all references cited (incl. URLs)
- format Cover page + content page
- submit Softcopy uploaded to PoliteMall by due date
Scope & tasks (Project Information §3) · built with Amazon Q → CloudFormation YAML
Networks & compute
IPSec site-to-site VPN
Bonus marks (only after M4 · core working)
High availability & load balancing of web servers
Auto-scaling + simulated load test
CloudWatch + CloudTrail + VPC Flow Logs (Bernard's slice)
2Where we standWhere we are against that standard, and the system it refers to.
Live multi-cloud overview
reading state…
Live status · current two-VPN topology
VPN #1 + #2 CURRENTVPN #1 · on-prem ↔ AWS public
TunnelUP · 54.77.211.189
Ping 10.0.x → 10.1.1.610% loss, ttl 254, ~69 ms
DesignstrongSwan CGW ↔ AWS VGW, IKEv1
PathN. Virginia ↔ Ireland (trans-Atlantic)
Alarm…
Hub route
10.0.0.0/16 present in the eu-west-1 route table, learned by propagation, not typedVPN #2 · AWS public ↔ Azure
ConnectionConnected on 30 Jul · Azure gateway and connection live during the recording window
Data planePASS · 0% loss, ~189 ms, and HTTP 200 from Azure to the Ireland hub
DesignAzure VpnGw1AZ ↔ AWS VGW, IKEv2
PathIreland ↔ Singapore (half the world)
Alarm…
Routing boundaryAzure and Virginia are not connected through the Ireland VGW; AWS VGW does not forward traffic between VPN connections.
Application-layer proof
VPN #2 only
VPN #2 only
curl http://10.1.1.61 from the Azure VM returned the AWS web server page, now served by the template itself · a real workload across clouds. VPN #1 was proven with ICMP, not HTTP, so this row does not apply to it.Hub routingeu-west-1 carries
10.0.0.0/16 from VPN #1 and 10.2.0.0/16 from VPN #2. Azure↔Virginia transit is outside scope because the VGW is intentionally non-transitive.Known by design: on-prem cannot reach Azure directly (tested: 100% loss). An AWS VGW does not do transitive routing between two VPN connections. Topology is hub-and-spoke with AWS public as the hub, matching the brief. Full mesh would need a Transit Gateway.
On-prem DC
AWS VPC 1 · us-east-1
N. Virginia · 10.0.0.0/16
N. Virginia · 10.0.0.0/16
…
HUB
AWS public
AWS VPC 2 · eu-west-1
Ireland · 10.1.0.0/16
Ireland · 10.1.0.0/16
…
Azure VNet
Southeast Asia (Singapore)
10.2.0.0/16
10.2.0.0/16
Reading live state…
AWS public cloud is the hub: its current VGW terminates VPN #1 and VPN #2, each with two AWS-provided tunnel endpoints. Because a VGW is not transitive, Azure↔Virginia routing is intentionally unavailable in the current design. The live banner, map and routing matrix are authoritative for current availability.
Deployed inventory · query-level completeness
Nothing on this list is typed by hand. The
live-data workflow runs scripts/inventory.sh, which only ever calls describe
and list, and refreshes this feed automatically. Every required query records success or
failure; a failed table is shown as unknown, never none. Anything here that is not inside a
CloudFormation stack or the Azure resource group has to be deleted by hand at teardown,
because delete-stack and az group delete will not touch it.
3The plan to get thereCritical path, milestones, schedule and who owns what.
Critical path · protect this chain, cut everything else first
Green = done. Amber = AWS side done, Azure pending. Grey = not started. Anything off this chain (bonus, report polish, slides) is parallel work you sacrifice first if time runs short.
Technical milestones · evidence-backed status
This is a technical milestone count, not an overall completion percentage. Status is defined in the shared page source and changes only with reviewed evidence.
5-week plan · back-planned from teardown
Week 1
24 Jul – 2 Aug
Plan & set up · roles + CIDR + AWS/Azure/Q access. CIDR done AWS build + VPN #1 done (ahead)
Week 2
3 – 9 Aug
Network + compute · CloudFormation for 3 networks. Deploy VPCs + VNet. Web + private servers.
Week 3
10 – 16 Aug
VPN #1: on-prem ↔ AWS · already passing traffic
Week 4
17 – 23 Aug
VPN #2 + integration · Azure ↔ AWS IPSec. End-to-end multi-cloud test. Log problems + fixes.
Week 5
24 – 30 Aug
Bonus, report, demo, TEARDOWN · demo to assessors → decommission all by 30 Aug 23:59.
Team & responsibilities PROVISIONAL
Working allocation only. The team has not confirmed the report section order or final ownership. These cards show current preparation areas and must not be read as approved section assignments.
Casper
ScrumMaster
Proposed speaking focus: architecture, executive summary, conclusion and CIDR sign-off.
PROVISIONALJeff
Team Member
Proposed speaking focus: VPC/VNet build, both VPN connections, VGW Ireland and customer gateway Virginia.
PROVISIONALBernard
Team Member
Proposed speaking focus: delivery, critical path, risk, monitoring, recovery and teardown.
PROVISIONALAdelene
Team Member
Proposed speaking focus: IP addressing, routing, test evidence and the public-subnet web server.
PROVISIONALSoo Fern
Team Member
Proposed speaking focus: Virginia workloads, DNS/DHCP, constraints and lessons learned.
PROVISIONALReadiness planning · provisional preparation map
Preparation guide, not ownership sign-off. The team now has one shared presentation deck. Speaking ownership remains provisional until the team confirms the order and Responsibility Assignment Table. Use the shared TEAM REVIEW deck and the working report.
Casper · proposed focusArchitecture, objectives, CIDR sign-off and project conclusions. Needs team confirmation.
Jeff · proposed focusNetwork construction, VGW/customer-gateway roles and both VPN implementations. Needs team confirmation.
Bernard · proposed focusDelivery, security, monitoring, cost, ALB integration, recovery and teardown. Needs team confirmation.
Adelene · proposed focusIP addressing, subnet design, routing and test evidence. Needs team confirmation.
Soo Fern · proposed focusVirginia workloads, strongSwan forwarding, constraints and lessons learned. Needs team confirmation.
Decision record: report order, accountable section owners and presentation roles are TBD by the full team, coordinated by Casper, target: 7 Aug checkpoint. Confirmation sequence: agree the report order → assign one accountable owner to each section → update the Responsibility Assignment Table and this page → then run the readiness check.
The test to apply after ownership is confirmed. Have someone outside the team open the assigned material at random and ask one question. If the owner must read from the document to answer, more preparation is needed.
Interactive access is still a single point of failure. The automated refresh uses short-lived OIDC access and the operator scripts are shared, but the demo sessions, SSH keys and recovery path have not been proven from a second device. Backup operator TBD by the team by 12 Aug. Closure requires one end-to-end rehearsal with Bernard observing but not operating.
4Evidence we are on trackThe artefacts and the proof, measured against the standard above.
Accepted school deployment · regions, gateways and encrypted paths
DEPLOYED AND ACCEPTED · VERIFIED 1 AUG 2026
The school environment runs under the
The school environment runs under the
eg334s-team2 prefix in AWS Virginia and Ireland. The Azure workload is deployed in East Asia (Hong Kong); VPN #1 and VPN #2 each have one AWS tunnel endpoint UP, and the Ireland ALB has one healthy Apache target in each Availability Zone.
Deployed architecture. VPN #1 and VPN #2 terminate on Ireland VGW vgw-02efe604037a218cf. The VGW exchanges routes with each remote network but does not forward traffic from one VPN connection into the other; Virginia–Azure transit remains outside the topology.
Evidence boundary. The identifiers and addresses below are dated deployment evidence and can change after a rebuild. The live target-health and VPN status must be checked again before a demonstration.
Deployed component connectivity · explicit packet flow
This view traces the public application path, VPN #1 between Virginia and Ireland, and VPN #2 between Ireland and Azure East Asia. It also marks the VGW routing boundary so the design does not imply unsupported inter-VPN transit.
Deployed connection matrix · source, destination, route and protocol 9 VERIFIED FLOWS / CONTROLS
The table separates application delivery, internal forwarding, encrypted transit and the management/evidence plane. Provider-generated values are dated school-environment evidence, not portable inputs.
| Connection | Source component / address | Destination component / address | Route or next hop | Protocol / ports | Return path and observed state |
|---|---|---|---|---|---|
| Public application entry | Internet client Dynamic public source address |
eg334s-team2-alb-alb-705364735.eu-west-1.elb.amazonaws.comAWS-managed ALB node addresses can change. |
Public DNS resolves the internet-facing ALB; listener selects the shared target group. | TCP/80HTTP |
Selected target → ALB → client. Acceptance: listener active and both targets healthy. |
| ALB → Web Node 1 | ALB service nodes ALB security group |
Web Node 1 Apache EC2 · 10.1.1.119:80eu-west-1a |
Target group sends requests to the registered instance in subnet 10.1.1.0/24. |
TCP/80HTTP + health checks |
Target → ALB → client. Acceptance: target healthy in eu-west-1a. |
| ALB → Web Node 2 | ALB service nodes ALB security group |
Web Node 2 Apache EC2 · 10.1.2.111:80eu-west-1b |
Same target group sends requests to the ASG-managed instance in subnet 10.1.2.0/24. |
TCP/80HTTP + health checks |
Target → ALB → client. Acceptance: desired 1 and target healthy in eu-west-1b. |
| Virginia workload → VPN router | Private test host10.0.1.104 |
strongSwan EC2/ENI10.0.1.55 |
Virginia route table targets the strongSwan instance/ENI for 10.1.0.0/16. No current route is published for 10.2.0.0/16. |
Private payload ICMP / permitted test traffic |
Router forwards replies to 10.0.1.104.IPv4 forwarding persistently enabled · source/destination check disabled |
| VPN #1 · Virginia ↔ Ireland | strongSwan Elastic IP 174.129.120.215Private CIDR 10.0.0.0/16 |
AWS endpoints34.247.246.9 UP176.34.108.143 DOWN |
vpn-0304048c980934f5a terminates on vgw-02efe604037a218cf. |
IKEv1 · staticUDP/500UDP/4500 NAT-T |
Ireland learns 10.0.0.0/16 through VGW propagation.Acceptance: at least one tunnel endpoint UP. |
| VPN #2 · Ireland ↔ East Asia | AWS endpoints52.51.60.239 UP52.211.121.132 DOWN |
Azure VNet Gateway Public IP 20.24.123.36Private CIDR 10.2.0.0/16 |
vpn-0106da6f9a20b1302 connects the Ireland VGW to eg334s-team2-vpngw. |
IKEv2 · route-based/staticUDP/500UDP/4500 |
Azure LNG represents 10.1.0.0/16; Ireland learns 10.2.0.0/16 through the VGW. Acceptance requires Azure Connected plus private ICMP/HTTP. |
| Azure gateway → workload | VNet Gateway GatewaySubnet 10.2.255.0/27 |
nginx VM10.2.1.4Subnet 10.2.1.0/24 |
Azure VNet system route delivers traffic to the workload subnet; the workload NSG is evaluated. | Private ICMPTCP/80 HTTP |
VM returns through the VNet Gateway route for the Ireland prefix 10.1.0.0/16. |
| AWS telemetry and evidence flow | Both AWS VPCs CloudTrail CloudWatch |
Retained S3 audit storage CloudWatch dashboard SNS topic |
Provider-managed service delivery; separate from the application data path. | VPC Flow Logs CloudTrail API events CloudWatch metrics |
Provides dated verification, alarm notification and teardown evidence. |
| Azure management flow | Authorised operator Azure control plane |
Azure VM and resource groupeg334s-team2-rg |
Run Command requires VM action permission. Reader permits inspection only; it does not permit command execution. | Azure management-plane HTTPS | Activity Log records changes. Additional team access remains a separate, least-privilege administration task. |
Deliverables · current working artefacts
GROUP SUBMISSION · DOCX
TEAM REVIEW
Project report
A 20-page evidence-led report covering the accepted school deployment, two-VPN topology, two active Ireland application targets, Test 9, IaC controls, evidence boundaries and dependency-ordered teardown.
- Coverage
- Architecture, implementation, testing, controls and teardown
- Review state
- Technical update complete · team approval pending
- Updated
- 1 Aug 2026 · 20 rendered pages · 1.1 MB
Working submission artefact. School deployment and measured Test 9 results are incorporated; final team approval remains pending.
GROUP PRESENTATION · PPTX
TEAM REVIEW
Group presentation
One shared 15-slide presentation aligned to the assessment rubric and accepted school architecture: two VPNs, two active Ireland targets, security and monitoring controls, Test 9 evidence, Q&A and teardown.
- Delivery model
- One shared deck · provisional presenter assignments
- Presenter support
- Speaker cues and source references on every slide
- Updated
- 1 Aug 2026 · 15 slides · 77 KB
Current working copy. Final speaking order requires team confirmation.
COMPLETE REBUILD PACKAGE · 23 FILES + MANIFEST
VALIDATED
Infrastructure as Code
Account-neutral CloudFormation, Azure Bicep and strongSwan configuration for Virginia, Ireland and the Azure second-cloud cell. The accepted deployment uses Azure East Asia because suitable low-cost VM capacity was restricted in Singapore. The package covers VPN #1, VPN #2, the two-AZ ALB, active secondary, audit logging, alarms, evidence storage, validation, deployment and teardown.
- Platforms
- AWS CloudFormation · Azure Bicep · strongSwan
- Safety
- VPN secrets and generated tunnel values supplied at deployment
- Validation
- 6 AWS YAML schemas + 2 Azure Bicep builds passed · 1 Aug 2026
- Portability
- Used for the accepted school deployment; secrets and provider-generated tunnel values remain deployment-time inputs
Individual deployment files · direct downloads
Download a single region or service template below. The complete ZIP remains the recommended option for a coordinated rebuild because it also contains validation scripts, runbooks and the checksum manifest.
AWS CloudFormation · 6 YAML templates
YAMLVirginia cell · us-east-1vpn1-onprem-us-east-1.yaml
YAMLIreland hub and VPNs · eu-west-1vpn1-awspublic-eu-west-1.yaml
YAMLIreland two-AZ application entryhub-alb-eu-west-1.yaml
YAMLIreland active secondaryhub-secondary-eu-west-1.yaml
YAMLOptional advanced recovery controlshub-recovery-eu-west-1.yaml
YAMLOptional evidence distributionvideo-evidence-distribution.yaml
Microsoft Azure · 2 Bicep templates
Download · Virginia YAML
Download · Ireland hub YAML
Download · Ireland ALB YAML
Download · Ireland recovery YAML
Download · Evidence hosting YAML
Download · Azure cell Bicep
Download · Azure VPN #2 Bicep
Download · strongSwan configuration
Download · strongSwan secrets template
Open · complete package index
ALB runbook
Rebuild guide
Recovery runbook
Ownership matrix
School deployment
The account-neutral package was used for the accepted school deployment. The active-secondary stack avoids custom IAM; the advanced IAM/Lambda recovery template remains optional.
SCHOOL-ACCOUNT DEPLOYMENT MANIFEST
23 FILES + SHA-256 MANIFEST
Every packaged file · purpose, scope and deployment order
Completeness boundary. The archive contains every project-controlled template, configuration skeleton, runbook, package index and safety script required for the staged rebuild. AWS-generated tunnel endpoints and VPN pre-shared keys are inserted during attended deployment and are intentionally absent. The package was used for the accepted school deployment; validation and live acceptance are separate evidence records.
Deployment templates
01 · vpn1-onprem-us-east-1.yamlAWS · us-east-1 (N. Virginia)VPC 10.0.0.0/16, subnet, IGW, routes, strongSwan EC2/EIP, private test host, security groups, VPC Flow Log and retained S3 audit bucket.
02 · vpn1-awspublic-eu-west-1.yamlAWS · eu-west-1 (Ireland)VPC 10.1.0.0/16, VGW, Web Node 1, VPN #1, staged VPN #2, route propagation, VPC Flow Log, multi-region CloudTrail, SNS and VPN alarms.
03 · hub-alb-eu-west-1.yamlAWS · eu-west-1 (Ireland)Second-AZ subnet, route association, internet-facing ALB, listener, security-group rule, target group, primary registration and unhealthy-host alarm.
04 · hub-secondary-eu-west-1.yamlAWS · eu-west-1 (Web Node 2)Permission-compatible ASG at desired capacity one; registers Web Node 2 in eu-west-1b without IAM, Lambda, VGW or VPN resources.
05 · hub-recovery-eu-west-1.yamlAWS · optional advanced recovery controlsPrivate DNS, EventBridge/Lambda control, health probing, SNS integration and 600-second recovery alarm. Not required for the accepted baseline.
06 · video-evidence-distribution.yamlAWS · optional evidence planePrivate encrypted S3 origin, retention controls, CloudFront origin access and chapter-delivery outputs. Not required for the network build.
07 · eg334s-azure-cell.bicepAzure · East Asia (accepted school deployment)Parameterised location, VNet 10.2.0.0/16, workload and GatewaySubnet, NSG, Ubuntu/nginx VM at 10.2.1.4, public IP and staged VpnGw1AZ resources.
08 · azure-vpn2.bicepAzure · East Asia (accepted school deployment)Scoped VPN #2 integration for an existing Azure core: VNet gateway, Ireland local network gateway and secure IKEv2 connection.
Protected configuration inputs
09 · strongswan-school-ipsec.conf.templateVPN #1 device configurationTwo AWS tunnel peers, IKEv1/IPsec policies, protected CIDRs, DPD and restart behaviour. Replace runtime placeholders outside Git.
10 · strongswan-school-ipsec.secrets.templateSecret skeleton · mode 600Placeholder-only PSK mapping for both VPN #1 tunnels. The completed file must never be committed or published.
11 · school-account.env.exampleOperator input contractAccount gate, AWS profile, regional key pairs, approved administrator /32, monitoring email and explicit write switch.
Runbooks and ownership records
12 · PACKAGE_CONTENTS.mdArchive indexComplete file manifest, security boundary, validation status and deployment order included inside the ZIP.
13 · SCHOOL_TEAM_DEPLOYMENT_PLAN.mdTeam planRoles, gates, staged timings, acceptance matrix, rollback and cost control.
14 · TEAM_INDIVIDUAL_RUNBOOKS.mdIndividual operator runbooksScoped task, command, evidence and peer-check instructions for each team member.
15 · SCHOOL_ACCOUNT_DEPLOYMENT.mdPrimary deployment runbookAccount-safe build order, VPN seam, verification boundary and stop conditions.
16 · REBUILD.mdRebuild procedureCross-cloud dependencies, required parameters and clean-environment sequence.
17 · HUB_ALB.mdALB runbookTwo-AZ integration, target validation and rollback.
18 · HUB_RECOVERY.mdRecovery runbookObjective, operating model, failure action and restoration.
19 · OWNERSHIP.mdDependency ownershipBorrower-before-owner deletion order and cross-stack responsibility.
Validation and controlled execution
20 · validate-iac.shFail-closed static validationRejects open administrator defaults, embedded account identifiers, unsafe secret handling and recovery/VPN ownership overlap.
21 · preflight-school-account.shRead-only provider preflightConfirms identity and regional access, then validates all six CloudFormation YAML files without creating resources.
22 · school-deploy.shAccount-gated AWS helperBlocks writes unless the authenticated account matches the approved school account and the attended DEPLOY gate is set.
23 · verify-teardown.shFail-closed teardown verificationChecks both AWS regions and reports residual project resources rather than treating failed queries as empty results.
Archive manifest · MANIFEST.sha256Generated inside the ZIPSHA-256 digest for each of the 23 packaged project files; verified successfully after rebuilding the archive.
School team connectivity lab · deployed test endpoints
A concise operator view for team members to verify the two supported encrypted paths after the school build. It publishes target commands—not passwords, SSH keys, access tokens, account identifiers or VPN pre-shared keys.
Accepted school environment
READY FOR TEAM TESTINGBoth AWS regions, the Azure cell and VPN #1/VPN #2 are deployed. Confirm current target health and tunnel state before each test; team-member execution still depends on individually scoped AWS access and Azure Run Command permission.
AWS · Virginia and Ireland
Sign in with an individually assigned school identity. Use the Virginia test host or Ireland hub only after scoped Session Manager access is enabled.
Azure · East Asia
Sign in with the assigned school identity. Reader permits inspection; test execution requires an additional narrowly scoped Run Command role. Target resource group: eg334s-team2-rg.
10.0.1.104 → 10.1.1.119
Start from the Virginia Amazon Linux 2 private test host. The 10.1.0.0/16 route uses strongSwan 10.0.1.55, then VPN #1 and Ireland VGW.
ping -c 4 10.1.1.119
curl -fsS --max-time 10 http://10.1.1.119/Expected: ICMP replies and the Ireland Apache page.
10.1.1.119 → 10.0.1.104
Start from the Ireland primary Apache host. The VGW has learned 10.0.0.0/16 through VPN #1; replies return through strongSwan.
ping -c 4 10.0.1.104Expected: private-address ICMP replies from the Virginia test host.
10.1.1.119 → 10.2.1.4
Start from the Ireland primary Apache host. The VGW learns 10.2.0.0/16 through VPN #2; the Azure VNet gateway then delivers to the East Asia workload subnet.
ping -c 4 10.2.1.4
curl -fsS --max-time 10 http://10.2.1.4/Acceptance: ICMP replies and the Azure nginx page.
10.2.1.4 → 10.1.1.119
Run through authenticated Azure Run Command. The local network gateway represents Ireland 10.1.0.0/16; traffic returns through the same VPN connection.
ping -c 4 10.1.1.119
curl -fsS --max-time 10 http://10.1.1.119/Acceptance: ICMP replies and the Ireland Apache page.
Routing boundary: Virginia ↔ Azure is not a supported target data path. The Ireland Virtual Private Gateway does not forward traffic from VPN #1 into VPN #2. A failed Virginia–Azure ping is therefore expected and does not by itself mean either VPN is down.
Demonstration evidence · current and historical
The accepted school deployment now includes a professional Test 9 genuine-action recording. It shows the live SGT event timeline, ALB target health, continuous HTTP sampling and authenticated Virginia-to-Ireland private pings. Credentials and VPN secrets remain excluded.
1 · Historical architecture baselineEarlier personal-environment discovery of the Virginia, Ireland and Singapore cells; retained as supporting evidence, not the current school snapshot. HISTORICAL RECORD
2 · IaC validationLocal fail-closed controls and provider-native validation of all CloudFormation YAML and Azure Bicep rebuild artefacts; no deployment performed. ACTION RECORDED
3 · VPN #1 · Virginia to IrelandLive AWS tunnel telemetry, temporary EC2 Instance Connect access, four-packet private ping and HTTP response from the Ireland hub; 0% packet loss, about 69 ms. ACTION RECORDED
4 · Historical VPN #2 · Singapore to IrelandEarlier personal-environment Azure Run Command ping and HTTP test; retained for method evidence. The accepted school Azure cell is in East Asia. HISTORICAL RECORD
6 · Monitoring, audit and costLive CloudWatch, CloudTrail, both VPC Flow Logs and fail-closed AWS/Azure billing refresh; four alarms OK and no billing query errors. ACTION RECORDED
7 · Portability and teardown dry-runPersonal-account IaC validation and dependency inventory with the safe borrower-before-owner order. Read-only: no resource was stopped, updated or deleted. REFERENCE DRY-RUN
8 · Planned-drain testIntentionally omitted by project decision. NOT PERFORMED
9 · Abrupt eu-west-1a application-target failureSchool AWS active-active ALB test with SGT timestamps and live private-path terminal. Result: 203 samples, 198 HTTP 200, five retained transients, 36.8-second ALB detection; eu-west-1b remained healthy and both targets were restored healthy. PASS · OBSERVED TRANSIENTS
Evidence boundary: Test 9 is an abrupt failure of one EC2 application target in
eu-west-1a. It is not a whole-Availability-Zone, ALB, VGW, VPC or Ireland Region failure, and it does not claim zero interruption.Historical evidence · former cold-standby operating model
Controlled cold-recovery drill · 30 Jul 2026 — before active-active was enabled, a zero-capacity recovery ASG launched a replacement and restored service in 218 seconds against the accepted 600-second objective. This is retained for audit evidence only and is not part of the current active-active demonstration sequence. HISTORICAL · PASS 218 S
Diagrams · network, recovery, evidence and build sequence
1 · Core network and VPN topology
Click to enlarge
Deployed design reference, not a substitute for live telemetry. The diagram follows the reconciled CloudFormation and Bicep design: Virginia has one public subnet; the Ireland application entry spans public subnets in eu-west-1a and eu-west-1b; Azure has one workload subnet and one GatewaySubnet. VPN #1 and VPN #2 are the current encrypted paths. The strongSwan EC2 owns the Elastic IP, has IPv4 forwarding persistently enabled and source/destination checking disabled, and routes traffic for the separate Amazon Linux 2 ICMP/SSH test host. Provider-managed addresses can change after rebuilding, and the VGW remains deliberately non-transitive. The live map and state banner above are authoritative for current availability. Open editable vector · Open historical commissioning capture.
2 · Hub-service recovery · accepted 10-minute objective
Click to enlarge
Resilience boundary and measured result. The 30 Jul figure records the earlier cold-recovery test, which passed in 218 seconds against the accepted 600-second objective. From 31 Jul the operating baseline is active-active: one healthy target in each Ireland AZ. A 30-request distribution sample split 15/15 with no failure. An abrupt-stop test exposed a short ALB health-detection window (143 HTTP 200 and 7 transient failures across 150 samples), so zero-interruption failover is not claimed. This remains application-service resilience only: the VPC, VGW and VPN connections are separate dependencies. Open historical recovery vector · 30 Jul recovery evidence · 31 Jul active-active evidence.
3 · Live evidence and public-dashboard pipeline
Click to enlarge
Why the public evidence is trustworthy. GitHub Actions uses AWS and Azure OIDC to collect state normally hourly and the larger inventory approximately every three hours. Complete, error-aware JSON is written to Workers KV as the primary path; committed files are the browser fallback. The Cloudflare watchdog checks KV every five minutes and dispatches a freshness-gated workflow only when needed, while the native GitHub schedule is an independent fallback. The dashboard distinguishes fresh, stale, partial and unreachable: freshness never substitutes for completeness, and no VPN PSK, SSH key or cloud credential is published. Open editable vector.
4 · Cross-cloud build sequence
Figure 6.1. The cross-cloud build order. Step 3 is the hinge: AWS only generates the tunnel addresses and pre-shared keys once the VPN connection exists, so neither cloud can be completed first. The seam has to be walked once, in order, by hand.
5 · Supporting service catalogue · report Figure 5.7
Click to enlarge
Figure 5.7. The VPN environment and the services around it. The two VPN connections are the assets being protected; AWS supplies two tunnel endpoints for each connection. The current templates define both VPC Flow Logs, the multi-region CloudTrail, SNS and both VPN alarms. AWS Budgets and the CloudWatch dashboard remain separate account-level controls. The retained central S3 bucket is intentionally left after stack deletion until evidence is preserved and it is explicitly emptied and removed. Current deployed ownership must be proved from describe-stack-resources; until a complete inventory succeeds, it is TBD rather than assumed. Open the ownership matrix.
Evidence · dated console captures taken while the system was live
These screenshots prove the tested topology at the time they were captured. Some identifiers changed during later rebuilds; the live map and current-state banner above are authoritative for the current deployment.
Both VPN connections Available on the same Virtual Private Gateway. This single frame is the proof of the hub topology.
VPN #1 to the simulated on-premises cell. Customer gateway 52.201.145.0, tunnel 34.247.143.4 Up.
VPN #2 to Azure. Customer gateway 40.119.233.66, tunnel 52.49.122.112 Up. This is the cross-cloud link.
The Azure network 10.2.0.0/16 propagated to the VGW, Active, Propagated: Yes. Learned automatically, not typed in.
The hub route table. Four routes, with both remote networks learned through Virtual Private Gateway propagation.
Video evidence · recovered abrupt-stop capture
The abrupt-stop video is now linked from the recovered local backup, so the dashboard no longer points to a dead CloudFront host. Test 9 shows the active-active ALB failure and the earlier 218-second recovery clip remains historical reference only.
Test results · six tests, five pass, one expected fail
1. VPN #1 data planePASS · on-prem to 10.1.1.61, 0% loss, ttl 254, ~69 ms
2. VPN #1 IPSec SAPASS · ESTABLISHED, INSTALLED, ESP in UDP (NAT traversal confirmed)
3. VPN #2 data planePASS · Azure 10.2.1.4 to 10.1.1.61, 0% loss, ttl 254, ~189 ms
4. VPN #2 application layerPASS · HTTP from Azure returned the AWS web server page
5. VGW transitive routing boundaryEXPECTED FAIL · VPN #1 traffic is not forwarded through VPN #2, correct by design
6. Hub-service recoveryPASS · replacement served through the ALB in 218 seconds against the accepted 600-second objective
Test 4 proves application traffic crossed an encrypted path between two cloud providers and returned a response. Test 5 deliberately preserves the VGW negative test: knowing the boundary of the chosen architecture is part of demonstrating it correctly. Test 6 proves the accepted service-recovery objective.
5ControlsWhat stops this going wrong quietly.
Security & monitoring · detective controls live (Bernard · Security/Monitoring)
CloudWatch alarms
4 OK
Hub recovery RTO, hub EC2 health, VPN #1 and VPN #2 all returned to OK after the recorded drill.
CloudTrail
logging
multi-region · log-file validation on
VPC Flow Logs
2 × ACTIVE
both AWS VPCs → S3, objects delivering
SNS alerts
confirmed
email subscription active on the topic
EG334S-Hub-Recovery-Over-10-Minutes
OK
HubRecoverySeconds threshold: 600 seconds EG334S-Hub-StatusCheckFailed
OKPrimary hub EC2 system and instance health checks are normal.
EG334S-VPN1-TunnelDown
OK
vpn-065016cdb8d06a873 EG334S-VPN2-TunnelDown
OK
vpn-03dcb879c286f5ecd
VPN #2 was live for the 30 Jul action recording and the alarm returned to OK. The live banner remains authoritative if the environment changes after this dated evidence.
CloudTrail
EG334S-audit-trail VPC Flow Logs
fl-0963dc40ce2f1c698 (eu-west-1) + fl-0ef531e2d2d6d1173 (us-east-1)CloudWatch dashboard
EG334S-MultiCloud-Monitoring (eu-west-1)SSH posture
The 25 Jul deployment is restricted to one administrative
/32 on the on-premises hosts, with no public SSH ingress on the hub server. The published CloudFormation templates have no permissive default: deployment requires an explicit valid /32, and scripts/validate-iac.sh rejects an open administrator default.Security groups decide what is allowed. Alarms, trails and flow logs decide what is noticed. The VPN #2 alarm firing on a real outage is stronger proof than a pair of green ticks: it shows the detection path works end to end, from metric to alarm to SNS to inbox.
AWS hub automated recovery drill · PASS
Decision: protect the AWS hub application without duplicating or replacing the VPN infrastructure. The accepted objective is to restore the hub web service within 10 minutes of a detected EC2 failure. This is a controlled application-service recoverability drill—not full High Availability, regional disaster recovery, or VGW/VPN failover.
PASS · 3m 38s RTO ≤ 10 min standby 0 EC2 NOT FULL HA Azure proven separately
Drill objective and measured result
Recovery objective
≤ 10 min
Accepted RTO for loss of the hub EC2 application
End-to-end test
3m 38s
218 seconds from stop request to confirmed HTTP 200
Automation interval
187.95 s
CloudWatch metric: controller start to private DNS publication
Normal standby
0 EC2
Cold Auto Scaling group · maximum one replacement
Recovery design and cost choices
DESIGN CHOICE
Replace the service, preserve the network
The failed component is the hub web-server EC2 instance. The recovery stack therefore imports the existing VPC, security group and propagated route table, then launches a replacement in eu-west-1b. It does not create or modify the Virtual Private Gateway, customer gateways or either Site-to-Site VPN connection.
This keeps the blast radius small. The working VPN control plane remains in place while only the stateless application host is replaced.
COST CHOICE
Active-active, one target per AZ
The secondary Auto Scaling group now has min=1, desired=1 and max=1. This keeps one Apache target online in eu-west-1b while the original target remains online in eu-west-1a.
The secondary t3.micro, its 8 GiB gp3 disk and public IPv4 are billed continuously. Route 53, alarms, Lambda, EventBridge, Parameter Store and DNS queries remain additional small control costs. Returning to desired zero would reduce cost but would also end the active-active operating claim.
Seven-step automated recovery sequence
What happens when the primary hub fails
1 · DetectEventBridge reacts to the primary entering
stopped or terminated. A separate two-of-two, one-minute StatusCheckFailed alarm covers EC2 system or instance failure.2 · StartLambda records the recovery start time and changes
eg334s-hub-recovery-HubRecoveryAsg from desired capacity 0 to 1.3 · RebuildThe launch template creates a hardened Amazon Linux replacement, installs Apache, enables automatic service restart and publishes the project health page.
4 · GateTraffic is not moved merely because the instance says
running. The DNS updater waits until both EC2 system and instance status checks report ok.5 · PublishThe 30-second private record
hub.eg334s.internal changes to the replacement private IP. A VPC-attached Lambda then requests the service through that stable name and requires HTTP 200.6 · Measure
EG334S/Recovery:HubRecoverySeconds records the automated interval. EG334S-Hub-Recovery-Over-10-Minutes alarms if the measured recovery exceeds 600 seconds.7 · RestoreAfter the original primary is healthy, DNS returns to
10.1.1.61 and recovery capacity returns to zero. The order matters: never remove the replacement before primary health and DNS restoration are confirmed.Dated evidence and claim boundary
AWS HUB AUTOMATED RECOVERY DRILL · 30 JUL 2026
Primary stop initiated: i-074bf0cb910a99e02 at 14:48:00 SGT. Replacement: i-0007949b2f976f068 at 10.1.2.154. Result: private DNS and the public ALB returned HTTP 200 after 218 seconds. The primary was restarted, private DNS returned to 10.1.1.61, recovery capacity returned to zero, and all four project alarms were OK.
Claim boundary. This proves recovery of the stateless hub EC2 application inside the existing VPC. It does not prove recovery from loss of eu-west-1, the VPC, the VGW, Route 53 or stateful application data. It also does not preserve the instance's public IPv4 address. Team tests should use hub.eg334s.internal from associated private networks rather than treating a public IP as the failover endpoint.
Azure scope. VPN #2 was live and proven with genuine Ireland–Singapore private-path tests before the recovery drill. The 218-second metric measures AWS hub application recovery through private DNS and the public ALB; it does not claim uninterrupted Azure-client service during every transition.
Cost monitoring · guardrails active (Bernard · Security/Monitoring)
Checking billing APIs…
Azure · month to date
loading
Cost Management actual cost · refreshed with the live state feed
AWS · month to date
loading
Net billed and usage before credits · refreshed with the live state feed
Idle now (torn down)
~$0.44/day
Azure = 2 static IPs + disk · ~$7.85/day only while rebuilt for the demo
Guardrails
3 budgets
AWS $40/mo + $3/day · Azure $25/mo
AWS Budgetsactive · EG334S-Monthly-40 + EG334S-Daily-Tripwire-3 → email
Cost Anomaly Detectionpresent but incapable of firing at this scale. It is the AWS
Default-Services-Monitor, not one configured for this project, and its subscription requires an anomaly of ≥ $100 AND ≥ 40%. Peak spend here is about $7.85/day, so the $100 condition cannot be met. Its notification address also differs from the SNS topic address; confirm which inbox is actively monitored.Daily still-running checkscheduled · 09:00 SGT, push + email, teardown commands attached
Auto-stop on breachnot implemented, but it is available.
bernard-admin holds AdministratorAccess and simulate-principal-policy returns allowed for iam:CreateRole, iam:PassRole, budgets:ModifyBudget and ec2:StopInstances. An earlier note claimed lab IAM blocked Budget Actions. That was true of the previous account and of the agent guardrail, not of this account.Azure budgetactive · EG334S-Azure-Guardrail-25, $25/mo, alerts 40 / 75 / 100% + forecast → email
Azure spending limitOff, and it cannot be turned on. The spending limit is not a switch we left off. Azure only offers it on credit-based subscriptions (free trial, Azure for Students, Visual Studio), where its job is to disable the subscription once the included credit runs out rather than start charging a card. This subscription is
PayAsYouGo_2014-09-01, which has no included credit to protect, so Azure reports the limit as Off and offers no way to enable it. That is why spend here is uncapped and why a budget with alerts is the only native control available. For a hard cap you would need a budget wired to an action group that triggers an automation runbook to deallocate resources, which is the Azure equivalent of AWS Budget Actions.Cost-allocation tagactive · the
Project tag was activated on 25 Jul and now reports Status: Active. An earlier note claimed it was not activatable from a linked account. That was wrong, and it was never tested. Note the lag: activation only applies to usage recorded from that point on, so it will not retrospectively split earlier spend.How these numbers were obtained. Actual month-to-date spend comes from the Azure Cost Management API and AWS Cost Explorer. Projected daily run rates are estimates calculated from the Azure Retail Prices API and AWS Price List API against the real resource inventory. At the 25 Jul rate check, Azure VPN Gateway VpnGw1AZ was $0.21/hr, the Azure VM Standard_D2als_v7 was $0.101/hr, and each AWS Site-to-Site VPN connection was $0.05/hr.
Actual versus projected, and why they differ so much. The earlier $283 figure was a projection of what leaving everything running to the deadline would have cost. The current month-to-date values are displayed above from the billing APIs. Azure remains lower than the projection because the gateway runs only in short bursts—built, verified and torn down again—rather than continuously.
How fresh can this be? Azure Cost Management returns same-day data, though the current day keeps trickling in for several hours. AWS Cost Explorer lags a day or more and flags its figures as Estimated. So "live cost" does not exist on either cloud. What is real time is the resource inventory, which is what actually matters for catching something left running. Any team member with the documented read-only access can run ./scripts/refresh-cost.sh; it fails closed if either cloud login or a required billing field is unavailable.
Control lesson. The first guardrails covered AWS even though credits reduce its net bill to approximately zero, while the Pay-As-You-Go Azure subscription carried the cash cost. Azure now has its own monthly budget and alerts.
Guardrails are alert-only: the cloud emails you, you act. The cheapest guardrail is still teardown · delete-stack on AWS and az group delete on Azure between work sessions.
Risk watch · the things that actually bite
Owner means whoever can actually act. The programme manager tracks every risk on this list and chases all of them, but only owns the ones where he holds the lever. A risk assigned to someone who cannot discharge it is not managed, it is just parked.
!
Key-person dependency · OPEN · automation uses short-lived OIDC access and the verification tools are now shared in this repository, but the interactive demo sessions, SSH keys and recovery access have not been proven from a second device. Backup operator: TBD by the team by 12 Aug. Closure evidence is a complete rehearsal in which Bernard does not operate the environment.
!
Section ownership · DECISION PENDING · the current report order and owner mapping are a working proposal. This is deliberately labelled provisional rather than treated as fact. Decision owner: full team; coordinator: Casper; target: 7 Aug checkpoint. Closure requires one accountable owner per section, an approved Responsibility Assignment Table and matching dashboard/readiness records.
!
Shared group presentation · TEAM REVIEW READY · one 15-slide deck now carries the assessment-aligned business case, common technical narrative, provisional speaking map, assessor Q&A and sourced speaker notes. Next action: each member validates the technical statements they may present; the full team confirms the order and ownership before rehearsal.
!
Live cross-cloud cost exposure · the Azure VpnGw1AZ and VPN #2 are live. Action: keep the environment only for the approved demonstration window, monitor the live billing cards, and use the dependency-ordered teardown after assessment. Owner: Bernard.
!
Decommission slippage · the brief states a real mark penalty for AWS resources left after 30 Aug 23:59 SGT. The templates now define Flow Logs, CloudTrail, SNS and VPN alarms, while the central evidence bucket is deliberately retained and budgets/dashboard remain manual. Current deployed ownership is TBD until a complete inventory and stack-resource reconciliation succeed. The Cloudflare evidence-site retention decision is also TBD by the team/lecturer. Owner: Bernard; second verifier: TBD. See the ownership matrix.
!
Public working artefacts · DECISION PENDING · the team-review report and shared group deck are publicly downloadable under the user's explicit approval. The full team should still confirm institutional rules and final submission status; both artefacts remain clearly labelled non-final.
✓
Closed · AWS hub automated recovery drill · the accepted 10-minute objective was re-exercised and recorded on 30 Jul. A controlled primary stop launched a cold replacement in a second Availability Zone; stable private DNS and the public ALB returned HTTP 200 in 218 seconds (3m 38s). Primary health, DNS and zero standby capacity were restored, and all four project alarms were OK. This proves EC2 application recoverability, not full HA, VGW/VPN failover or regional DR. Open the dated evidence.
✓
Closed · report administration · four supplied admin numbers are present; Bernard's remains explicitly TBC. “Adelene” is corrected, pagination defects are removed, and the current team-review copy renders to 21 pages.
✓
Closed · overlapping CIDRs (locked at M1), evidence debt (captured while live), gold-plating (core proven before monitoring was added), cross-region teardown (documented per region and per subscription).
Claim verification · dated evidence record
This is a historical evidence record, not the hourly operational reading. Current tunnel, alarm, compute and cost summaries come from the live banner and map. Infrastructure facts below were captured after the 25 Jul rebuild; working-artefact metadata was updated on 28 Jul.
AWS identifiersre-verified 25 Jul after rebuild ·
vgw-0bf466d711cc93ac4, VPN #1 vpn-065016cdb8d06a873, VPN #2 vpn-03dcb879c286f5ecd, both VPN connections, both flow logs. Verified with describe-vpn-connections, describe-customer-gateways, describe-flow-logs.Addressesconfirmed 25 Jul · web server 10.1.1.61, VPN #1 tunnel 54.77.211.189, on-prem Elastic IP 3.214.123.92, VPN #2 tunnel 34.243.188.162, Azure gateway IP 40.119.233.66.
Design assertionsconfirmed 25 Jul ·
SourceDestCheck=false on the strongSwan instance, GatewaySubnet 10.2.255.0/27 with nsg: None, workload subnet 10.2.1.0/24 with its NSG attached, local network gateway configured for the current AWS VPN #2 endpoint and 10.1.0.0/16.Monitoring and budgetsconfirmed 28 Jul · all four alarms exist (hub recovery duration, hub EC2 health, VPN #1 and VPN #2), CloudTrail
IsLogging: true, SNS has a confirmed email subscription, both AWS budgets remain at $40 and $3, and the Azure budget remains at $25.Cost arithmeticrate basis recomputed 25 Jul · $0.21/hr + $0.101/hr + 2 IPs + disk = approximately $7.85/day Azure when fully rebuilt for the demo. Torn down it idles at approximately $0.44/day. Current month-to-date billing values are shown in the live cost cards above.
Latencyre-measured 25 Jul · VPN #1 returned 0% loss at 70.3 ms average with
ttl=254, against the ~69 ms recorded earlier. Within normal jitter, same path.Working artefactspending team approval · report: 1,123,767 bytes and 21 rendered pages. One 15-slide shared team deck with provisional presenter notes and source blocks: 79,405 bytes.
AWS control auditrecorded verification · 30 Jul · expected EC2 instances, active two-AZ ALB, recovery ASG restored to desired 0, VPN #1 and VPN #2 live during the action window, all four project alarms OK, CloudTrail logging and both VPC Flow Logs active. Open dated audit.
Live state, routes, ownership and costPASS · 30 Jul, 17:42–17:47 SGT · authenticated read-only capture confirmed both AWS VPNs, both Azure connections, three running AWS instances, the running Azure VM, healthy two-AZ ALB, four alarms OK, effective routes/security controls, all active AWS stack and Azure deployment owners, and a pre-parking billing baseline. No infrastructure changed. Open consolidated evidence.
Automated recovery drillPASS · 30 Jul · controlled stop of
i-074bf0cb910a99e02; replacement i-0007949b2f976f068 served HTTP through private DNS and the public ALB at 10.1.2.154 in 218 seconds. Primary, DNS and zero-capacity steady state were restored; all four alarms were OK. This is recoverability evidence, not full HA. Evidence and claim boundary.Assessment documents verified and artefacts reconciled 31 Jul 2026. The assessment weightings, scope, milestones, report requirements and both rubrics were checked against the supplied official files. The report content order shown in the brief is an example for reference, not a mandatory sequence. The current working report was rendered and checked at 21 pages; the shared deck was rendered across all 15 slides. Both include the measured active-active failover boundary and remain subject to team review. One infrastructure limitation remains unverified: the orphaned IAM role sits on the previous lab account, which this session has no access to, so its continued existence is reported, not observed.
Re-run this before the demo. Infrastructure claims decay. The shared ./scripts/verify-teardown.sh and ./scripts/refresh-cost.sh tools are now in this repository. Both refuse to report success if authentication or a required query fails. Use the provisional evidence register to replace historical captures after the 25 Aug rebuild.
6How it endsDecommissioning. This is where marks are lost.
Teardown checklist · run in every region before 30 Aug 23:59
On-prem sim AWS us-east-1
- EC2 private server
- Customer gateway + VPN connection
- VPC, subnets, route tables, IGW
- Elastic IPs released
- Security groups + key pairs
- CloudFormation stack deleted
AWS public AWS eu-west-1
- Delete
eg334s-hub-recoveryfirst - EC2 web server
- Virtual private gateway + VPN conn
- CloudWatch / CloudTrail / Flow Logs
- VPC, subnets, route tables, IGW
- Elastic IPs released
- CloudFormation stack deleted
Azure Southeast Asia
az group delete --name eg334s-rg --yes- Removes VPN gateway (the big cost)
- Removes connection + local network gateway
- Removes VNet, NSG, VM, disks, public IPs
az resource list --tag Project=EG334Sreturns empty
AWS order matters: delete eg334s-vpn2-aws before eg334s-vpn1-awspublic, it borrows that VGW.
Note: an orphaned IAM role from the locked-down lab account (eg334s-vpn1-onprem-SsmRole-*) can't be self-deleted · flag to lab admin. IAM is global, not regional.
Two controls that protect the teardown
1 · DEPENDENCY ORDER
Delete the borrower before the owner
eg334s-vpn2-aws borrows the virtual private gateway owned by eg334s-vpn1-awspublic. Delete VPN #2 first so the owner stack can remove the gateway cleanly.
2 · RETAIN EVIDENCE
Prove that nothing remains
After teardown, run the authenticated verification script across both AWS regions and Azure. Retain its PASS / FAIL / ERROR transcript as the M6 completion evidence.
Technical note
The historical deployment used a separate VPN #2 stack that borrowed the hub VGW by parameter, so CloudFormation did not enforce deletion order. The current published hub template can stage VPN #2 inside the same stack. Which model is live is TBD until stack-resource inventory succeeds; follow the observed model, not an assumption.
The shared verification script checks the project-named AWS resources returned by the complete inventory plus every resource in eg334s-rg, and fails closed with ERROR if authentication or any required query fails. Account-level budgets, the CloudWatch dashboard, key pairs, legacy IAM and the Cloudflare evidence site remain explicit manual/TBD controls in the ownership matrix.
Shared evidence record · technical milestones are source-controlled, not browser-local. Times in Asia/Singapore. Built for EG334S. Live status is in the banner and map above; the update stamp is below.