EG334S · HyEnt Multi-Cloud Project

Bonus marks (only after M4 · core working)

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.

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.

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

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.

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.

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.