EG334S · HyEnt Multi-Cloud Project

On-prem VPC ↔ AWS public VPC ↔ Azure VNet, joined by two IPSec tunnels

Decommission deadline
--
Sun 30 Aug 2026, 23:59 SGT · marks deducted if late
Project week
1 / 5
Plan & set up (ahead: AWS build already live)
Milestones done
4 / 6
M1 + M2 + M3 + M4 · the system works
Overall progress
67%
Multi-cloud proven · only demo + teardown left
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. Follow the required section order; cite real references (not just www); show reasoned technical analysis, not just description.

Report requirements & structure (Project Information §5)

Proposed section order

    Click a section to see what the submitted report actually contains under it. Owner shown on the right.

    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 status · VPN #1 carrying traffic, VPN #2 stood down to control cost

        M4 ✓ PROVEN VPN #2 REBUILD BEFORE DEMO

        VPN #1 · on-prem ↔ AWS public

        TunnelUP · 34.247.143.4
        Ping 10.0.x → 10.1.1.900% loss, ttl 254, ~69 ms
        DesignstrongSwan CGW ↔ AWS VGW, IKEv1
        PathN. Virginia ↔ Ireland (trans-Atlantic)

        VPN #2 · AWS public ↔ Azure

        TunnelDOWN by choice · both tunnels down since the Azure gateway was deleted 25 Jul
        When last up, 25 Jul0% loss, ttl 254, ~189 ms, plus HTTP across clouds
        DesignAzure VpnGw1AZ ↔ AWS VGW, IKEv2
        PathIreland ↔ Singapore (half the world)
        To restore~/eg334s-build/rebuild-azure-vpn.sh · about 30 min · run the day before the demo
        Application-layer proofcurl http://10.1.1.90 from Azure returned the AWS web server page · a real workload across clouds
        Hub routingeu-west-1 route table now carries 10.0.0.0/16 only. 10.2.0.0/16 withdrew itself the moment the Azure tunnel dropped, which is route propagation working exactly as it should.

        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.

        Architecture · 3 cells, 2 tunnels

        On-prem DC
        AWS VPC 1 · us-east-1
        N. Virginia · 10.0.0.0/16
        built
        IPSec UP
        VPN #1 · ~69 ms
        AWS public
        AWS VPC 2 · eu-west-1
        Ireland · 10.1.0.0/16
        built
        IPSec DOWN
        VPN #2 · ~189 ms when up
        Azure VNet
        Southeast Asia (Singapore)
        10.2.0.0/16
        built VM deallocated

        AWS public cloud is the hub: its single VGW terminates both tunnels. Latencies are measured round-trip times from the ICMP tests, and both replies returned ttl=254, which proves the packets crossed a gateway rather than being answered locally. The difference is purely physical distance: trans-Atlantic versus half-way round the world. Azure was placed in Singapore rather than Ireland so the assessed demo runs at local latency, the trade being a longer VPN #2 tunnel that is invisible to the viewer. Note that the VGW does not perform transitive routing, so on-prem cannot reach Azure directly. That is hub-and-spoke by design. Teardown must clear us-east-1, eu-west-1 and Azure separately. Current state: VPN #2 is intentionally down. The Azure VPN gateway was deleted on 25 Jul because at $0.21/hr it was 64% of the project's entire real spend. The VNet, NSG and VM all survive, the VM deallocated, so the rebuild needs only the gateway and the connection.

        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.

        Milestones · tick to update the counter

          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

          Casper

          Team Lead · Cloud Architect

          Architecture, exec summary, conclusion. CIDR sign-off.

          Chief Editor · §1, §7

          Jeff

          Network Engineer

          VPC/VNet build + both IPSec tunnels. VGW Ireland, customer gateway Virginia.

          Editor · §3, §5

          Bernard PM

          Technical PM + Security/Monitoring

          Delivery, critical path, risk & teardown. CloudWatch, CloudTrail, VPC Flow Logs.

          PM · Editor §3, §5.1

          Adeline

          Web & Database Engineer

          IP addressing scheme, routing, web-server instance in public subnet.

          Editor · §4

          Soo Fern

          DC Ops Manager

          EC2 (Virginia private server), DNS/DHCP, problems & solutions log.

          Researcher/Editor · §2, §6

          Team readiness · can each member defend their own section?

          Casper · §1, §2, §8
          report p4, p4, p15
          Introduction, objectives, conclusion. Must be able to state why a VPN and not VPC peering, and summarise the trade-offs in §8.2 without reading them.
          Jeff · §5
          report p6 to p11
          Highest exposure. The largest and most technical section. Must be able to explain VGW versus customer gateway, why SourceDestCheck is disabled, and what route propagation does.
          Bernard · §3, §5.7
          report p4 to p5, p11
          Delivery, critical path, security and monitoring, cost. Has the deck and the run sheet. Ready.
          Adelene · §4
          report p5
          IP addressing and routing. Must be able to say why non-overlapping CIDRs are non-negotiable and read the hub route table aloud.
          Soo Fern · §6, Annex A
          report p11 to p13, p16
          Nine problems and the bibliography. Must be able to walk any one problem as symptom, cause, solution. §6.5 and §6.7 are the two an assessor is most likely to pick.

          Page numbers refer to the current draft, fingerprint e4016ba3, 16 pages. They come from a rendered PDF of that file, so Word may differ by a page here or there once the contents field is updated.

          The test to apply before demo day. Have someone outside the team open the report at random inside your section and ask you one question. If you reach for the document, you are not ready. This matters more than polish: an assessor who finds one member cannot explain their own section will doubt the whole submission, including the parts that are genuinely strong.

          Access is a single point of failure. The SSH key, the Azure login and the AWS session all sit on one laptop. At minimum, one other member should rehearse the demo end to end from the run sheet so the team is not one illness away from having nothing to show.

          4Evidence we are on trackThe artefacts and the proof, measured against the standard above.

          Deliverables · the actual submission artefacts

          Project report

          Group report, 16 pages. Cover, contents, responsibility assignment table, sections 1 to 8, Annex A bibliography. Carries both drawn diagrams, five console screenshots, the CloudFormation and Bicep extracts, the strongSwan configuration and all six test results.

          DOCX 862 KB 16 pp DRAFT

          Download report

          This is the current version. Fingerprint e4016ba3, 882,239 bytes, 25 Jul. If the copy you are holding does not match, it is an older draft. Check with md5 <file> on a Mac or certutil -hashfile <file> MD5 on Windows.

          All five admin numbers are in. Still to do before submission: delete the red draft note in Annex A (Soo Fern), open in Word and Update Field on the contents page (Casper), remove the DRAFT marking from the cover (Casper).

          Individual presentation

          Bernard's individual deck, 13 slides, speaker notes on every slide. Delivery and critical path, security and monitoring posture, cost guardrails, constraints and workarounds, the transitive-routing finding, results and anticipated Q&A.

          PPTX 13 slides 331 KB CURRENT

          Download deck

          This is the current version. Fingerprint 07ba1727, 338,843 bytes. Two earlier builds are in circulation and both are wrong: one denies the monitoring exists, the other carries the old cost figures.

          Slide 6 and the Q&A slide both reflect the live monitoring build. The old "no, those were bonus items" answer has been removed.

          Infrastructure as Code

          Every resource in all three cells was declared, not clicked. Two CloudFormation templates for the AWS cells and a Bicep template for Azure, which is what makes teardown a small number of delete commands rather than a console hunt.

          Extracts are reproduced in report sections 5.3.1 to 5.3.3. Full templates are held with the team repository.

          Diagrams · as submitted in the report

          Architecture as built: three cells, two IPSec tunnels, hub and spoke

          Figure 5.0. Logical architecture as built. Each cell is an isolated private network with a non-overlapping CIDR. The two links are genuine IPSec security associations over the public internet, not VPC peering. AWS public cloud is the hub because its single Virtual Private Gateway terminates both connections.

          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.

          Evidence · console captures taken while the system was live

          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.90, 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.90, 0% loss, ttl 254, ~189 ms
          4. VPN #2 application layerPASS · HTTP from Azure returned the AWS web server page
          5. Azure web serverPASS · reachable on its public IP
          6. Transitive routingEXPECTED FAIL · on-prem cannot reach Azure, 100% loss, correct by design

          Test 4 is the strongest single result in the project. A real application request crossed an encrypted tunnel between two different cloud providers and returned a response. Test 6 was run deliberately: knowing where an architecture stops is part of knowing the architecture.

          5ControlsWhat stops this going wrong quietly.

          Security & monitoring · detective controls live (Bernard · Security/Monitoring)

          CloudWatch alarms
          1 OK 1 ALARM
          VPN #2 alarm fired 08:11 UTC when the gateway went. Working as designed.
          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-VPN1-TunnelDownOK · vpn-02cff3a74008a9cd4 · tunnel 34.247.143.4
          EG334S-VPN2-TunnelDownIN ALARM since 25 Jul 08:11 UTC · vpn-0f2dd8409e8290710 · TunnelState 0.0 < 1.0. This is the monitoring proving itself. The alarm detected a genuine tunnel outage within minutes of the Azure gateway being deleted, and the SNS email fired. It is expected to clear on its own once rebuild-azure-vpn.sh restores the tunnel. Better viva material than an alarm that has only ever read OK.
          CloudTrailEG334S-audit-trail · IsLogging: true · tamper-evident via log-file validation
          Flow Logsfl-08c0fdca54d7dd957 (eu-west-1) + fl-09ed4fed7a0b7fa2c (us-east-1) → s3://eg334s-flowlogs-980195619820
          CloudWatch dashboardEG334S-MultiCloud-Monitoring (eu-west-1) · tunnel state, tunnel traffic, EC2 CPU
          Known gapSSH open to 0.0.0.0/0 on lab hosts · in a graded build this is a single admin /32

          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.

          Cost monitoring · guardrails active (Bernard · Security/Monitoring)

          Azure · actually spent
          $1.25
          July to date, Cost Management · VPN GW $0.99, VMs $0.20, network $0.05
          AWS · actually billed
          $0.00
          Cost Explorer, July to date · list price would be ~$3.66/day
          If fully rebuilt
          ~$11.50/day
          Azure VPN GW alone is $5.04 · rebuild only for the demo
          Guardrails
          4 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. 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 $11.50/day, so the $100 condition can never be met. An earlier note claimed it alerted on a $5 spike. That was wrong and untested. It also notifies bernard.tay@hotmail.sg, a different address from the one on the SNS topic (.com) , worth confirming which inbox is actually read.
          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 spend comes from the Azure Cost Management API and AWS Cost Explorer. Unit rates come from the Azure Retail Prices API and the AWS Price List API, multiplied by the real resource inventory. Nothing here is estimated. Azure VPN Gateway VpnGw1AZ is $0.21/hr, the Azure VM Standard_D2als_v7 is $0.101/hr, and each AWS Site-to-Site VPN connection is $0.05/hr.

          Actual versus projected, and why they differ so much. The $283 figure quoted earlier was a projection of what leaving everything running to the deadline would have cost. Real Azure spend to date is $1.25, because the expensive gateway only ever existed for a few hours before being deleted. Both numbers are true and they answer different questions: one is money spent, the other is the money the decision avoided.

          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. Refresh with ~/eg334s-build/refresh-cost.sh, which rewrites these figures and pushes.

          An earlier version of this card was wrong. It read "AWS ~$4.50 + Azure ~$3.50", which inverted the split. Azure was the larger cost by a wide margin and was in fact the only real cash cost, because AWS Cost Explorer reports $0.00 billed to this account for July. Correcting it also exposed the real gap: every cost guardrail was aimed at the AWS account being billed nothing, while the Pay-As-You-Go Azure subscription that was actually charging had no budget, no alert and no spending limit. That is now fixed.

          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 · every credential lives on one laptop. The SSH key, the az login and the AWS session are all Bernard's. If he is unavailable on demo day the team cannot demonstrate anything. Owner: Bernard (holds the credentials). Action on Jeff: rehearse the demo once from the run sheet so the team is not one laptop deep.
          !
          Section defensibility · the report is a group deliverable and each member is named against sections in the responsibility table. Being listed as owner is not the same as being able to answer questions on it. Owner: each member, for their own section. Escalation to Casper as group leader and chief editor. The TPM tracks this one, he cannot discharge it for anyone else. Read your section, rewrite anything that does not sound like you, and be able to defend it unaided.
          !
          Individual presentations · 30% of each member's grade is individual and separate from the group demo. One deck exists: Bernard's, 13 slides with speaker notes, published in Deliverables above (download) and usable as a template for structure, not content. Four still to produce. Owner: Casper, Jeff, Adelene and Soo Fern, each for their own.
          !
          VPN #2 is currently down · the Azure gateway was deleted on 25 Jul to stop it burning $5.04/day. The public IP was deliberately kept: eg334s-vpngw-pip = 40.119.233.66, Standard, Static, zones 1 2 3, currently unattached and costing $0.12/day. That matters because the AWS customer gateway cgw-072f6b49c61f06f30 is pinned to that address, so the rebuild touches Azure only. Lose the IP and you would have to recreate the AWS customer gateway and VPN connection too, which regenerates the tunnel addresses and pre-shared keys. rebuild-azure-vpn.sh checks the IP first and refuses to run if it has changed. About 30 minutes. Run it the day before, not on the day. Owner: Bernard.
          !
          Decommission slippage · a real mark penalty past 30 Aug 23:59 SGT. Three places, and the monitoring resources are not in any CloudFormation stack, so delete-stack alone will not remove them. Owner: Bernard.
          Administrative tail · admin numbers are in (all five, 25 Jul). Still open: the DRAFT marking on the cover, the contents field needs updating in Word, and the bibliography still carries a red draft note. None are hard. All are visible to an assessor. Owner: Casper (contents field, DRAFT marking) and Soo Fern (the red draft note in Annex A).
          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

          Every machine-checkable claim on this page was verified against its live source at the time stamped above. Six were found wrong during that pass and corrected. The wrong ones all had something in common: they were written from memory rather than from a query.

          AWS identifiers6 of 6 confirmed · vgw-0ec51dbc5e8d65f46, cgw-072f6b49c61f06f30, both VPN connections, both flow logs. Verified with describe-vpn-connections, describe-customer-gateways, describe-flow-logs.
          Addresses6 of 6 confirmed · web server 10.1.1.90, Azure VM 10.2.1.4, tunnel 34.247.143.4 and 52.49.122.112, on-prem Elastic IP 52.201.145.0, Azure gateway IP 40.119.233.66.
          Design assertionsconfirmed · 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 pointing at 52.49.122.112 for 10.1.0.0/16.
          Monitoring and budgetsconfirmed · both alarms exist, CloudTrail IsLogging: true with delivery at 10:48 UTC, SNS subscribed to bernard.tay@hotmail.com with a real ARN, both AWS budgets at $40 and $3, Azure budget at $25.
          Cost arithmeticrecomputed · $0.21/hr + $0.101/hr + 2 IPs + disk = $7.85/day Azure. Now $0.39/day. AWS list $3.66/day. Combined $11.51, shown as $11.50. Azure actual $1.25 month to date from Cost Management.
          Latencyre-measured today · VPN #1 returned 0% loss at 70.3 ms average with ttl=254, against the ~69 ms recorded earlier. Within normal jitter, same path.
          Deliverablesconfirmed · report serves at e4016ba3, 16 pages; deck at 07ba1727, 13 slides; all three IaC templates and both diagrams return HTTP 200 at their original byte sizes.

          Not machine-verifiable, treat as unconfirmed. The assessment weightings and both rubrics are transcribed from the project brief and cannot be checked against any API, so read them against the brief itself before relying on them. The report page numbers come from a rendered PDF, and Word may paginate a page differently once the contents field is updated. 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. ~/eg334s-build/verify-teardown.sh checks what still exists, and refresh-cost.sh refreshes the money. Both refuse to report if they cannot authenticate, rather than showing everything as clear.

          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

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

          Why the AWS order matters

          The two AWS stacks are not independent. eg334s-vpn1-awspublic owns the virtual private gateway vgw-0ec51dbc5e8d65f46. eg334s-vpn2-aws does not create a gateway of its own, it attaches to that one, and it also adds two security-group rules to a group the first stack owns. Verified from describe-stack-resources on both stacks.

          CloudFormation only tracks resources it created, and the gateway was passed between the stacks as a parameter rather than an Export. So CloudFormation has no record of the dependency and will not stop you deleting the first stack. It will simply try to delete the gateway, AWS will refuse because a VPN connection is still attached to it, and the stack lands in DELETE_FAILED with resources half gone.

          Delete eg334s-vpn2-aws first and its VPN connection disappears cleanly. The gateway is then unattached and the first stack deletes without complaint. The general rule: delete borrowers before owners, and if you ever build this again, use Export and ImportValue so CloudFormation enforces the order for you instead of relying on someone remembering it.

          Evidence, not tick boxes

          A ticked box is a claim. M6 is graded on nothing being left running, so the artefact worth keeping is a machine-generated transcript. ~/eg334s-build/verify-teardown.sh interrogates both AWS regions and the Azure subscription and prints PASS, FAIL or ERROR for every line above, naming any resource that survived. Run it after teardown and keep the output.

          It checks the things a console sweep misses: virtual private gateways, customer gateways, unattached Elastic IPs, key pairs, orphaned IAM roles, and the monitoring resources that are not in any CloudFormation stack, meaning the CloudWatch alarms and dashboard, CloudTrail, both flow logs, the S3 bucket and the SNS topic.

          One caution, learned the hard way. The first version of that script reported PASS on every AWS line while the CLI session was expired, because a failed query returns nothing and "nothing" looked like "nothing left". It now refuses to run unless both clouds authenticate, and reports ERROR rather than PASS for any query that fails. If a verification tool cannot tell clear from could not look, it is worse than having no tool at all.

          Interactive tracker · milestone ticks are per-session. Times in Asia/Singapore. Built for EG334S. Updated 25 Jul 2026 · M4 achieved, both tunnels UP, monitoring live.

          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.