EG334S · HyEnt Multi-Cloud Project

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.

Bonus marks (only after M4 · core working)

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

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.

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.

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.

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.

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

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.

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.

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.