Checking live state…

EG334S · HyEnt Multi-Cloud Project

On-prem VPC ↔ AWS public VPC ↔ Azure VNet, joined by two Site-to-Site VPN connections

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
Overall progress
67%
Multi-cloud proven · only demo + teardown left

Key dates · official milestones (Project Information)

All times SGT. The VPN #2 rebuild on 25 Aug is an internal action, not an assessed milestone: the Azure tunnel is parked for cost and comes back in ~30-45 min (REBUILD.md phase D) so the 26 Aug demo runs 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)

Team's proposed section order

    The brief labels its contents page as a sample for reference only. This team structure is therefore a deliberate, logical choice rather than a compulsory order. Click a section to see what the submitted report actually contains under it. Owners on the right. Drag a name from the roster onto a section to assign it, drag a chip between sections to move it, or use the × on a chip to remove it. Changes save to the shared 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.

        Architecture · 3 cells, 2 tunnels

        reading state…
        VPN #1 · ~69 ms VPN #2 · ~189 ms 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 Azure VNet southeastasia · Singapore 10.2.0.0/16 Positions are the real regions. The latency gap is distance, not configuration. Click a site or a link for live identifiers.

        Live status · VPN #1 live; VPN #2 proven, torn down between sessions to control cost

        M4 ✓ PROVEN VPN #2 · REBUILD FOR DEMO

        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

        Tunneltorn down · gateway + connection deleted to control cost · rebuilds to 34.243.188.162, reusing 40.119.233.66
        Data planelast verified · 0% loss, ttl 254, ~192 ms, HTTP 200 across clouds on the 26 Jul rebuild test
        DesignAzure VpnGw1AZ ↔ AWS VGW, IKEv2
        PathIreland ↔ Singapore (half the world)
        Alarm
        To restore~30 min, Azure-only · rebuild the gateway (IP 40.119.233.66 kept) + connection the day before the demo (see REBUILD.md phase D)
        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 route table carries 10.0.0.0/16 from VPN #1 by propagation; 10.2.0.0/16 re-propagates automatically when VPN #2 is rebuilt.

        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 single VGW terminates both VPN connections, each with two AWS-provided tunnel endpoints. 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 connection 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 torn down to control cost. It was rebuilt and verified end-to-end on 26 Jul, then the Azure gateway, the connection and the VM were removed, leaving Azure at about $0.44/day. Both static IPs are kept, including 40.119.233.66 that the AWS customer gateway is pinned to, so rebuilding for the demo is a ~30-minute Azure-only job (REBUILD.md phase D).

        Deployed inventory · every resource, read from the accounts

        Loading inventory…

        Nothing on this list is typed by hand. It is produced by scripts/inventory.sh, which only ever calls describe and list. Re-run it after any change. 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.

        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

          ScrumMaster

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

          §1, §2, §8

          Jeff

          Team Member

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

          §5

          Bernard

          Team Member

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

          §3, §5.7

          Adelene

          Team Member

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

          §4

          Soo Fern

          Team Member

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

          §6, Annex A

          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 16-page draft, MD5 7c9736f48cc63e97948d2f67076220b1. 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.

          Interactive access is still a single point of failure. The automated refresh uses short-lived OIDC access, but the demo sessions, SSH keys and recovery path still depend 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. MD5 7c9736f48cc63e97948d2f67076220b1, 883,567 bytes, 26 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. MD5 2265d87c38e2122e9cf93760168a43cc, 339,377 bytes, 26 Jul. 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

          The core network and compute resources in all three cells were declared as code, not clicked. Two CloudFormation templates cover the AWS cells and a Bicep template covers Azure. Monitoring, budgets, the dashboard feed and other out-of-band controls are tracked separately because they are not part of those stacks.

          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 Site-to-Site VPN connections, 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.

          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. Above them sits the infrastructure as code that builds them; below them, the three groups of services that operate them: detect (CloudWatch tunnel-state alarms into a confirmed SNS subscription), record (CloudTrail for the control plane, VPC Flow Logs for the data plane, both into one S3 bucket) and control cost (AWS Budgets, Cost Anomaly Detection and the Azure budget). Two things are called out honestly rather than hidden: none of these services lives in a CloudFormation stack, so delete-stack will leave every one of them running at teardown, and Cost Anomaly Detection cannot fire at this project's scale because the default monitor needs a $100 swing.

          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. 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
          2 monitored
          VPN #1 is normally OK. VPN #2 is ALARM while Azure is parked and should clear after rebuild. The control tracks the cycle · current counts are in the live banner.
          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-065016cdb8d06a873 · tunnel 54.77.211.189, metric-math across both tunnels
          EG334S-VPN2-TunnelDownpresent · ALARM while parked · vpn-03dcb879c286f5ecd · TunnelState < 1.0. This is the monitoring proving itself. The alarm detected the real Azure-side teardown and the SNS email fired. It should return to OK once rebuild-azure-vpn.sh restores the Azure gateway and connection; current aggregate alarm counts are shown in the live banner.
          CloudTrailEG334S-audit-trail · IsLogging: true · tamper-evident via log-file validation
          Flow Logsfl-0963dc40ce2f1c698 (eu-west-1) + fl-0ef531e2d2d6d1173 (us-east-1) → s3://eg334s-flowlogs-980195619820
          CloudWatch dashboardEG334S-MultiCloud-Monitoring (eu-west-1) · tunnel state, tunnel traffic, EC2 CPU
          SSH postureThe 25 Jul deployment was hardened to a single administrative /32 on the on-premises hosts, with no public SSH ingress on the hub server. The published CloudFormation templates still default AdminCidr to 0.0.0.0/0, so every rebuild must explicitly override that default and verify the resulting security-group rules.

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

          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 · automation uses short-lived OIDC access, but the interactive demo sessions, SSH keys and recovery access still depend on Bernard's laptop. If he is unavailable on demo day the team cannot demonstrate anything. Owner: Bernard (holds the operational access). 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 torn down to control cost · the Azure gateway and connection are deleted and the VM deallocated, so Azure idles at about $0.44/day instead of ~$7.85/day. Action: rebuild the day before the demo, not the week before. The public IP 40.119.233.66 is kept, which is why the AWS customer gateway cgw-03e47b4fe8c6e27f1 pinned to it needs no change and the rebuild is Azure-only. About 30 minutes via REBUILD.md phase D. Owner: Bernard.
          !
          Decommission slippage · the brief states a real mark penalty for AWS resources left after 30 Aug 23:59 SGT. The wider project requirement is to decommission the private and public cloud environment, so the team's completion target also covers Azure and project-specific Cloudflare services. 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 · full audit snapshot

          This is the dated full-audit snapshot, not the hourly operational reading. Current tunnel, alarm, compute and cost summaries come from the live banner and map. Identifiers and artefact metadata below were rechecked after the 25–26 Jul rebuild.

          AWS identifiersre-verified 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.
          Addressesall confirmed · 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 · 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 · both alarms exist, CloudTrail IsLogging: true with delivery at 18:48 SGT, SNS subscribed to bernard.tay@hotmail.com with a real ARN, both AWS budgets at $40 and $3, Azure budget 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 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 MD5 7c9736f48cc63e97948d2f67076220b1, 883,567 bytes, 16 pages; deck MD5 2265d87c38e2122e9cf93760168a43cc, 339,377 bytes, 13 slides.

          Assessment documents verified 27 Jul 2026. The assessment weightings, scope, report requirements and both rubrics were checked against the supplied official PDFs. The report content order shown in the brief is an example for reference, not a mandatory sequence. Report page numbers come from a rendered PDF, and Word may paginate a page differently once the contents field is updated. 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. ~/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 (now vgw-0bf466d711cc93ac4). 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. Live status is in the banner and the 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.