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

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 indicator	Excellent (top band)	What it takes
Organisation & Content (60) Organisation & supporting materials; Content	Agenda exists, coherent & interesting sequence; supporting materials used innovatively & explained in context; can explain all details, constraints and work-arounds.	Have a clear agenda; every diagram/screenshot explained in context; be able to explain the whole project's details, limits and how you worked around them.
Presentation Skills (40) Delivery; Q&A	Interesting, eloquent, enthusiastic delivery (not heavily scripted); handles all Q&A well and anticipates questions.	Rehearse so you're not reading slides; pre-empt likely assessor questions and prepare answers.

Report rubric · what assessors score (group, 20%)

Performance indicator	Excellent (top band)	What it takes
Report Presentation (20) Writing; Presentation & supporting materials	Exceptionally clear, precise, concise English; few typos; professional layout; all illustrations well formatted.	Proofread hard; consistent styles/margins; clean, labelled figures and screenshots.
Technical Content (30) Organisation & structure; Literature survey; Quality of analysis	Structure entirely correct, all sections placed; exemplary range of references; well-informed, authoritative discussion of a complex problem with depth.	Use a logical, complete structure; cite an exemplary range of authoritative references; show reasoned technical analysis, not just description.

Verified on 27 Jul 2026 against the supplied official Presentation Assessment Rubrics and Report Assessment Rubrics PDFs. Presentation is marked out of 100 (60 + 40); the report rubric has 50 rubric marks (20 + 30) and the report contributes 20% of the module assessment.

Report requirements & structure (Project Information §5)

Working section-order proposal PROVISIONAL

Not yet confirmed by the team. The brief labels its contents page as a sample for reference only, so the order and owner chips shown here are planning placeholders. Use the matrix to develop the proposal; do not treat it as the approved Responsibility Assignment Table. Changes save to the shared planning matrix that every visitor sees.

Must include

start Responsibility Assignment Table (name, admin no., role, topic, section, remarks)
evidence Diagrams, screenshots, YAML files & configuration
refs Bibliography of all references cited (incl. URLs)
format Cover page + content page
submit Softcopy uploaded to PoliteMall by due date

Scope & tasks (Project Information §3) · built with Amazon Q → CloudFormation YAML

Networks & compute

IPSec site-to-site VPN

Bonus marks (only after M4 · core working)

High availability & load balancing of web servers Auto-scaling + simulated load test CloudWatch + CloudTrail + VPC Flow Logs (Bernard's slice)

2Where we standWhere we are against that standard, and the system it refers to.

Architecture · 3 cells, 2 tunnels

reading state…

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 onlycurl 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

…

VPN #1 · ~69 ms

HUB

AWS public

AWS VPC 2 · eu-west-1
Ireland · 10.1.0.0/16

…

VPN #2 · ~189 ms when up

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

Current preparation focus: architecture, executive summary, conclusion and CIDR sign-off.

PROPOSED FOCUS

Jeff

Team Member

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

PROPOSED FOCUS

Bernard

Team Member

Current preparation focus: delivery, critical path, risk, teardown, CloudWatch, CloudTrail and VPC Flow Logs.

PROPOSED FOCUS

Adelene

Team Member

Current preparation focus: IP addressing, routing and the public-subnet web server.

PROPOSED FOCUS

Soo Fern

Team Member

Current preparation focus: Virginia private server, DNS/DHCP and the problems-and-solutions log.

PROPOSED FOCUS

Readiness planning · provisional preparation map

Preparation guide, not ownership sign-off. Exact sections and page numbers are deliberately omitted until the team confirms the report order and Responsibility Assignment Table. Select a member's proposed focus to download the current team-review report.

Casper · proposed focusArchitecture, objectives and project conclusions. Prepare to explain why a VPN was selected and summarise the main design trade-offs. Needs team confirmation.

Jeff · proposed focusNetwork construction and VPN implementation. Prepare to explain VGW versus customer gateway, SourceDestCheck and route propagation. Needs team confirmation.

Bernard · proposed focusDelivery, critical path, security, monitoring, cost control and teardown. The working deck and run sheet support preparation. Needs team confirmation.

Adelene · proposed focusIP addressing and routing. Prepare to explain non-overlapping CIDRs and how the hub route table supports the design. Needs team confirmation.

Soo Fern · proposed focusCompute, DNS/DHCP and the problems log. Prepare to explain one problem from symptom through cause to resolution. Needs team confirmation.

Confirmation sequence: agree the report order → assign one accountable owner to each section → update the Responsibility Assignment Table and this page → then add page references and 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, 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 · current working artefacts

Project report

Group report prepared for team review, 18 pages. Cover, fixed contents, a provisional responsibility assignment table, sections 1 to 8 and Annex A bibliography. Includes the design basis and literature review, both drawn diagrams, five console screenshots, infrastructure-as-code extracts, the strongSwan configuration, all six tests and the complete teardown checklist.

DOCX 864 KB 18 pp TEAM REVIEW

Download report

This is the current working copy, pending team review and approval. MD5 d5ccec6b656b23540b67f21e81ddc513, 884,448 bytes, 27 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.

Draft markings and the red bibliography note have been removed, page numbers and contents are fixed for this copy, Test 5 is explicitly documented, and the technical claims and sources have been corrected. Team feedback may still change the submission.

Individual presentation

Bernard's individual deck prepared for team review, 13 slides, with presentation cues and source lists in the speaker notes on every slide. Covers delivery and critical path, security and monitoring, cost guardrails, constraints and workarounds, the transitive-routing finding, test evidence and anticipated Q&A.

PPTX 13 slides 67 KB TEAM REVIEW

Download deck

This is the current working copy, pending team review and approval. MD5 cefb7dfe82a3a2f0a56c0b74cc46f5ef, 68,280 bytes, 27 Jul. Earlier builds contain superseded monitoring, cost and tunnel wording.

The deck now distinguishes two VPN connections from four AWS tunnel endpoints, treats TTL as supporting evidence, states AWS cost after credits, and includes the out-of-stack teardown checks.

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.

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 below

Click to enlarge

Figure 5.7. The VPN environment and the services around it. The two VPN connections are the assets being protected; AWS supplies two tunnel endpoints for each connection. 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 to the simulated on-premises cell. Customer gateway 52.201.145.0, tunnel 34.247.143.4 Up.

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

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

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

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

Cost Management actual cost · refreshed with the live state feed

AWS · month to date

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 ownership is not confirmed · the current report order and owner mapping are a working proposal. Until the team agrees them, readiness and page-level accountability cannot be assessed reliably. Owner: the full team, coordinated by Casper. Confirm the order and accountable owner for every section, then update the Responsibility Assignment Table, dashboard and preparation plan together.

Individual presentations · 30% of each member's grade is individual and separate from the group demo. One team-review deck exists: Bernard's, 13 slides with sourced 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.

✓

Closed · report administration · all five admin numbers are present; the DRAFT marking and red bibliography note are removed; the contents and footer page numbers are fixed in the current 18-page team-review copy.

✓

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 27 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 25 Jul · 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 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 MD5 d5ccec6b656b23540b67f21e81ddc513, 884,448 bytes, 18 pages; deck MD5 cefb7dfe82a3a2f0a56c0b74cc46f5ef, 68,280 bytes, 13 slides with sourced speaker notes.

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. The current working report was rendered and checked at 18 pages, with fixed contents and footer numbering. It remains 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. ~/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.

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 gateway was passed between the stacks as a parameter rather than a CloudFormation Export, so the service does not enforce their deletion order. A future build should use Export and ImportValue.

The verification script also checks resources outside the stacks—alarms, dashboard, CloudTrail, Flow Logs, S3, SNS, Elastic IPs, key pairs and IAM—and fails closed with ERROR if either cloud session cannot authenticate.

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.