Checking live state…
EG334S Smart Multi-Cloud Project

Hybrid Enterprise Multi-Cloud

Three regional cloud cells with two current Site-to-Site VPNs, a two-Availability-Zone application entry and an approved Ireland Transit Gateway migration.

3 cloud cells 2 IPsec VPNs live Ireland TGW planned 2-AZ application entry 10-minute recovery objective

Deployment environments · current and planned

Personal AWS · integrated live hub LIVE

This is the existing Ireland hub infrastructure, not a separate website or VPC. Its internet-facing Application Load Balancer spans eu-west-1a and eu-west-1b and distributes HTTP traffic across two healthy Apache instances: the original hub at 10.1.1.61 and an ASG-managed secondary at 10.1.2.110.

Open live AWS hub

Personal AWSTEST BED · LIVE · existing Ireland hub · external HTTP 200
School AWSDEMO TARGET · PENDING · access and deployment not started
Load balancingPASS · two healthy targets · 30-request sample split 15/15 with zero failures
Hub resilienceACTIVE-ACTIVE · one running instance in each Availability Zone · ASG desired capacity 1
VPN #1available · one AWS tunnel endpoint UP
Last verified31 Jul 2026, 17:22 SGT

Claim boundary. This proves two normally running Ireland application servers behind one two-AZ ALB. Steady-state distribution passed. An abrupt primary stop on 31 Jul produced 143 HTTP 200 responses and 7 transient failures across 150 samples while ALB health detection converged; therefore the deployment is active-active but is not claimed as zero-interruption failover. Planned maintenance should deregister and drain a target before stopping it. The dated 30 Jul cold-recovery drill remains valid historical evidence of a 218-second recovery against the accepted 600-second objective. This is application resilience, not full 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

Class calendar · official 15-session timetable

All dates are SGT. Sessions 1 and 2 are Sync-Physical; sessions 3 to 15 are Sync-Online. Session 8 on 11 Aug is the National Day public-holiday make-up lesson. The VPN #2 rebuild on 25 Aug is a separate internal action so the 26 Aug assessment can run on live infrastructure. Teardown must be verified in us-east-1, eu-west-1, Azure and Cloudflare.

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 indicatorExcellent (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 indicatorExcellent (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…
        VPN #1 · ~5,500 km · ~69 ms RTT VPN #2 · ~11,200 km · ~189 ms RTT On-prem DC us-east-1 · N. Virginia 10.0.0.0/16 AWS public · HUB eu-west-1 · Ireland 10.1.0.0/16 ALB → existing hub EC2 10.1.1.61 active secondary · desired 1 · both healthy Azure VNet southeastasia · Singapore · local Azure region 10.2.0.0/16 AWS EU-WEST-1 · EUROPE - IRELAND DEPLOYED TWO-AVAILABILITY-ZONE APPLICATION ENTRY APPLICATION LOAD BALANCER ACTIVE · HTTP PORT 80 · TWO HEALTHY TARGETS eg334s-personal-demo-site-alb-349585711.eu-west-1.elb.amazonaws.com eu-west-1a · ACTIVE SERVICE STATUS · TARGET HEALTHY Public subnet 10.1.1.0/24 ALB public resolution 108.131.189.140 ALB private ENI 10.1.1.52 Hub EC2 private IP 10.1.1.61 eu-west-1b · ACTIVE SECONDARY STATUS · TARGET HEALTHY · DESIRED CAPACITY 1 Recovery subnet 10.1.2.0/24 ALB public resolution 54.216.79.2 ALB private ENI 10.1.2.24 Hub EC2 private IP 10.1.2.110 · same target group AWS NETWORK EDGE VGW vgw-0bf466d711cc93ac4 Public endpoint IP · none Propagated · 10.0.0.0/16 Propagated · 10.2.0.0/16 AWS-managed VPN termination VPN #1 · VIRGINIA vpn-065016cdb8d06a873 Customer gateway public · 3.214.123.92 AWS tunnel 1 · 54.77.211.189 · UP AWS tunnel 2 · 108.132.14.128 · DOWN Remote private network · 10.0.0.0/16 VPN #2 · AZURE vpn-03dcb879c286f5ecd Azure gateway public · 40.119.233.66 AWS tunnel 1 · 34.243.188.162 · UP AWS tunnel 2 · 54.72.86.174 · DOWN Remote private network · 10.2.0.0/16 Current topology: VPN #1 connects Virginia–Ireland and VPN #2 connects Ireland–Singapore. The Ireland VGW does not provide inter-VPN transit.

        Live status · current two-VPN topology

        VPN #1 + #2 CURRENT

        VPN #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 route10.0.0.0/16 present in the eu-west-1 route table, learned by propagation, not typed

        VPN #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
        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 remains unavailable through the VGW until the approved Transit Gateway migration is implemented.

        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
        HUB
        AWS public
        AWS VPC 2 · eu-west-1
        Ireland · 10.1.0.0/16
        Azure VNet
        Southeast Asia (Singapore)
        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

        Loading inventory…

        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.

          PROVISIONAL

          Open shared team deck

          Jeff

          Team Member

          Proposed speaking focus: VPC/VNet build, both VPN connections, VGW Ireland and customer gateway Virginia.

          PROVISIONAL

          Open shared team deck

          Bernard

          Team Member

          Proposed speaking focus: delivery, critical path, risk, monitoring, recovery and teardown.

          PROVISIONAL

          Open shared team deck

          Adelene

          Team Member

          Proposed speaking focus: IP addressing, routing, test evidence and the public-subnet web server.

          PROVISIONAL

          Open shared team deck

          Soo Fern

          Team Member

          Proposed speaking focus: Virginia workloads, DNS/DHCP, constraints and lessons learned.

          PROVISIONAL

          Open shared team deck

          Readiness 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.

          Deployed network reference · regions, gateways and encrypted paths

          Detailed engineering view Scroll horizontally when required, or open the full-size vector for presentation.
          Open full-size diagram Open packet-flow diagram View connection matrix · 9 paths
          Current engineering reference showing the Virginia strongSwan VPC, Ireland two-availability-zone ALB hub, Singapore Azure VNet, VPN 1, VPN 2, routing, recovery and monitoring controls

          Current architecture. VPN #1 and VPN #2 terminate on the Ireland virtual private gateway. The VGW exchanges routes with each remote network but does not forward traffic from one VPN connection into the other; Virginia–Singapore transit is therefore outside the current topology.

          Evidence boundary. Stable resource identifiers are shown for engineering reference. Provider-managed public addresses can change after replacement; use the live-status banner and live inventory for the latest observed state.

          Component-to-component connectivity · explicit packet flow

          This engineering view traces the public application path, VPN #1 between Virginia and Ireland, and VPN #2 between Ireland and Singapore. It also marks the current VGW routing boundary so the diagram does not imply unsupported inter-VPN transit.

          Explicit packet-flow diagram showing the component-by-component forward and return paths, IP addresses, route tables, VPN endpoints, gateways and application delivery among Virginia, Ireland and Singapore

          Connection matrix · source, destination, route and protocol 9 CURRENT FLOWS

          The table separates application delivery, internal forwarding, encrypted transit and the management/evidence plane. Horizontally scroll on a smaller screen.

          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
          ALB DNS (authoritative)
          eg334s-personal-demo-site-alb-349585711.eu-west-1.elb.amazonaws.com
          Current public DNS resolutions: 108.131.189.140 / 54.216.79.2
          Private ALB ENIs: 10.1.1.52 / 10.1.2.24
          Public DNS resolves the internet-facing ALB; listener selects the shared target group. TCP/80
          HTTP
          Selected target → ALB → client.
          Listener active
          ALB → primary ALB service nodes
          ALB security group
          Apache EC2
          10.1.1.61:80
          eu-west-1a
          Target group sends requests to the registered instance in subnet 10.1.1.0/24. TCP/80
          HTTP + health checks
          Target → ALB → client.
          Target healthy
          ALB → secondary ALB service nodes
          ALB security group
          Apache EC2
          10.1.2.110:80
          eu-west-1b
          Same target group sends requests to the ASG-managed instance in subnet 10.1.2.0/24. TCP/80
          HTTP + health checks
          Target → ALB → client.
          Desired 1 · target healthy
          Virginia workload → VPN router Private test host
          10.0.1.154
          strongSwan EC2/ENI
          10.0.1.77
          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.154.
          IPv4 forwarding enabled · source/destination check disabled
          VPN #1 · Virginia ↔ Ireland strongSwan
          3.214.123.92
          Private CIDR 10.0.0.0/16
          AWS VPN endpoints
          54.77.211.189 active
          108.132.14.128 standby
          vpn-065016cdb8d06a873 terminates on vgw-0bf466d711cc93ac4. IKEv1 · static
          UDP/500
          UDP/4500 NAT-T
          Ireland learns 10.0.0.0/16 through VGW propagation.
          One AWS tunnel endpoint active
          VPN #2 · Ireland ↔ Singapore AWS VPN endpoints
          34.243.188.162 active
          54.72.86.174 standby
          Azure VNet Gateway
          40.119.233.66
          Private CIDR 10.2.0.0/16
          vpn-03dcb879c286f5ecd connects the Ireland VGW to eg334s-vpngw. IKEv2 · route-based/static
          UDP/500
          UDP/4500
          Azure LNG represents 10.1.0.0/16; Ireland learns 10.2.0.0/16 through the VGW.
          Azure gateway → workload VNet Gateway
          GatewaySubnet 10.2.255.0/27
          nginx VM
          10.2.1.4
          Subnet 10.2.1.0/24
          Azure VNet system route delivers traffic to the workload subnet; the workload NSG is evaluated. Private ICMP
          TCP/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 Privileged operator
          Four team Reader users
          Azure control plane
          Azure VM and resource group
          eg334s-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. Four Reader assignments are confirmed; first sign-in has not yet been evidenced.

          Deliverables · current working artefacts

          GROUP SUBMISSION · DOCX

          Project report

          TEAM REVIEW

          A 20-page evidence-led report covering the deployed two-VPN topology, the two-AZ Ireland application entry, the 218-second recovery drill, Azure team access, IaC controls and dependency-ordered teardown.

          Coverage
          Architecture, implementation, testing, controls and teardown
          Review state
          Technical update complete · team approval pending
          Updated
          31 Jul 2026 · 20 rendered pages · 1.1 MB
          Download project report

          Working submission artefact. School-account deployment remains deferred.

          GROUP PRESENTATION · PPTX

          Group presentation

          TEAM REVIEW

          One shared 15-slide presentation for the whole team, aligned to the assessment rubric and the deployed two-VPN architecture, business objectives, team responsibilities, security and monitoring controls, cost, test evidence, ALB recovery, Q&A and teardown.

          Delivery model
          One shared deck · provisional presenter assignments
          Presenter support
          Speaker cues and source references on every slide
          Updated
          31 Jul 2026 · 15 slides · 78 KB
          Download shared presentation

          Current working copy. Final speaking order requires team confirmation.

          COMPLETE REBUILD PACKAGE · 21 FILES + MANIFEST

          Infrastructure as Code

          VALIDATED

          Account-neutral CloudFormation, Azure Bicep and strongSwan configuration for Virginia, Ireland and 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
          5 AWS YAML schemas + 2 Azure Bicep builds passed · 1 Aug 2026
          Portability
          Prepared for controlled school-account deployment; live acceptance pending
          Download complete IaC package · 21 files + checksum
          Quick downloads · core deployment templates

          Provider validation is complete. School-account change sets, quotas, IAM permissions and live acceptance remain pending.

          SCHOOL-ACCOUNT DEPLOYMENT MANIFEST

          Every packaged file · purpose, scope and deployment order

          21 FILES + SHA-256 MANIFEST

          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 the attended deployment and are intentionally absent. “Validated” means AWS schema validation and Azure Bicep compilation passed; it does not claim a completed school-account deployment.

          Deployment templates

          Protected configuration inputs

          Runbooks and ownership records

          Validation and controlled execution

          Team connectivity lab · authenticated private-path tests

          A concise operator view for team members to verify the two supported encrypted paths. It publishes test instructions and resource links—not passwords, SSH keys, access tokens or VPN pre-shared keys.

          Access setup required

          The resources are live, but the AWS instances are not currently managed by Systems Manager and the Azure team accounts have Reader access only. Scoped Session Manager and Azure Run Command permissions must be approved and applied before members can run these tests without the administrator.

          CONTROLLED ENABLEMENT
          VPN #1 · Virginia → Ireland

          10.0.1.154 → 10.1.1.61

          Start from the Virginia Amazon Linux 2 private test host. The 10.1.0.0/16 route uses strongSwan 10.0.1.77, then the encrypted AWS VPN and Ireland VGW.

          ping -c 4 10.1.1.61
          curl -fsS --max-time 10 http://10.1.1.61/

          Expected: ICMP replies and the Ireland Apache page.

          VPN #1 · Ireland → Virginia

          10.1.1.61 → 10.0.1.154

          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.154

          Expected: private-address ICMP replies from the Virginia test host.

          VPN #2 · Ireland → Azure

          10.1.1.61 → 10.2.1.4

          Start from the Ireland primary Apache host. The VGW has learned 10.2.0.0/16 through VPN #2 and the Azure VNet gateway delivers to the workload subnet.

          ping -c 4 10.2.1.4
          curl -fsS --max-time 10 http://10.2.1.4/

          Expected: ICMP replies and the Azure nginx page.

          VPN #2 · Azure → Ireland

          10.2.1.4 → 10.1.1.61

          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.61
          curl -fsS --max-time 10 http://10.1.1.61/

          Expected: ICMP replies and the Ireland Apache page.

          Routing boundary: Virginia ↔ Azure is not a supported current data path. The Ireland Virtual Private Gateway does not forward traffic from VPN #1 into VPN #2. A failed Virginia–Azure ping is therefore not evidence that either deployed VPN is down.

          Open the access, command and evidence runbook

          Demonstration evidence · current, historical and pending

          Seven current-linked genuine-action recordings are available through CloudFront. The earlier 218-second cold-recovery drill is retained as historical evidence. A new active-active failover recording is required: the dashboard previously linked to an object that is not present in the evidence bucket. Credentials and VPN secrets remain excluded.

          1 · Live architecture baselineAuthenticated AWS and Azure identities plus live discovery of the Virginia, Ireland and Singapore cells. ACTION RECORDED
          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 · VPN #2 · Singapore to IrelandConnected Azure VPN telemetry plus Azure Run Command ping and HTTP tests to the Ireland hub; 0% packet loss, about 189 ms. ACTION RECORDED
          5 · Historical cold-recovery drill · 30 JulBefore active-active was enabled, a zero-capacity recovery ASG launched a replacement and restored service in 218 seconds against the 600-second objective. Retained as historical recovery evidence; it is not the current operating model. HISTORICAL · PASS 218 S
          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-runIaC validation and dependency inventory with the safe borrower-before-owner order. Read-only: no resource was stopped, updated or deleted; school deployment remains deferred. DRY-RUN RECORDED
          8 · Two-AZ ALB active-active resilienceNew professional recording required. The previous measured run returned 145/150 HTTP 200 (96.7%) and five transient failures (3.3%) during ALB health detection. That demonstrates recovery, not seamless or zero-interruption failover. RECORDING REQUIRED
          Recommended replacement: record a planned graceful failover (deregister and drain the primary, demonstrate zero observed request failures, then stop it) and a separate abrupt-stop resilience test that reports any health-detection transients honestly. The current baseline is active-active: one healthy target in each Ireland Availability Zone.

          Open capture, redaction, S3 and timing plan

          Diagrams · network, recovery, evidence and build sequence

          1 · Core network and VPN topology

          Core deployed and rebuildable multi-cloud topology showing two AWS VPCs, an Azure VNet, nested subnets, a strongSwan routed test host, Apache and nginx workloads, two Site-to-Site VPN paths, the deployed Azure gateway and the non-transitive VGW boundaryClick 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

          Six-stage AWS hub EC2 recovery sequence from detection through cold Auto Scaling, health validation, Route 53 private DNS switching, measurement and restoration, showing a 218-second pass against the 600-second objectiveClick 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

          Live evidence pipeline from authenticated AWS and Azure APIs through freshness-gated GitHub Actions collection, complete and error-aware records, Workers KV and committed fallbacks, Cloudflare Pages Functions and the assessor-facing public dashboardClick 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

          The cross-cloud build order, six steps

          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

          The VPN environment and the services around it: infrastructure as code above, the two Site-to-Site VPN connections in the middle, and the detect, record and cost-control services belowClick 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 VGW

          Both VPN connections Available on the same Virtual Private Gateway. This single frame is the proof of the hub topology.

          VPN 1 tunnel up

          VPN #1 to the simulated on-premises cell. Customer gateway 52.201.145.0, tunnel 34.247.143.4 Up.

          VPN 2 tunnel up

          VPN #2 to Azure. Customer gateway 40.119.233.66, tunnel 52.49.122.112 Up. This is the cross-cloud link.

          Azure route propagated to VGW

          The Azure network 10.2.0.0/16 propagated to the VGW, Active, Propagated: Yes. Learned automatically, not typed in.

          AWS route table with four routes

          The hub route table. Four routes, with both remote networks learned through Virtual Private Gateway propagation.

          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
          OKHubRecoverySeconds threshold: 600 seconds · fresh recorded drill: 218 seconds
          EG334S-Hub-StatusCheckFailed
          OKPrimary hub EC2 system and instance health checks are normal.
          EG334S-VPN1-TunnelDown
          OKvpn-065016cdb8d06a873 · observed tunnel 54.77.211.189 · metric math covers both AWS tunnel endpoints
          EG334S-VPN2-TunnelDown
          OKvpn-03dcb879c286f5ecd · metric math covers both AWS tunnel endpoints
          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 · IsLogging: true · log-file validation enabled
          VPC Flow Logs
          fl-0963dc40ce2f1c698 (eu-west-1) + fl-0ef531e2d2d6d1173 (us-east-1)
          Destination: s3://eg334s-flowlogs-980195619820
          CloudWatch dashboard
          EG334S-MultiCloud-Monitoring (eu-west-1)
          Tunnel state · tunnel traffic · EC2 CPU
          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 · MeasureEG334S/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.

          Dated test evidence Recovery runbook

          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-recovery first
          • 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=EG334S returns 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.

          Ambience Mozart · 5 recordings
          Track 1 of 5 · in order, loops
          Checking playback mode

          Le nozze di Figaro, K. 492, Act III, No. 21, Sull’aria … Che soave zeffiretto, the Letter Duet. Five interpretations. Press play above. Full tracks need an active Spotify session in this browser, otherwise Spotify serves previews. Turn this off before the assessed demo.