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

Live status . multi-cloud proven, both IPSec tunnels passing traffic

M4 ✓ THE SYSTEM WORKS

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

TunnelUP . 52.49.122.112 / Azure Connected

Ping 10.2.1.4 → 10.1.1.900% loss, ttl 254, ~189 ms

DesignAzure VpnGw1AZ ↔ AWS VGW, IKEv2

PathIreland ↔ Singapore (half the world)

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 carries both 10.0.0.0/16 and 10.2.0.0/16, propagated via VGW

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.

Deliverables . the actual submission artefacts

Project report

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

DOCX 860 KB DRAFT

Download report

Outstanding before submission: admin numbers, delete the bibliography note to the team, update the contents field in Word, remove the DRAFT marking.

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 UPLOADING

Not yet published here. The corrected build is being uploaded; this card will carry a download link once it is in place.

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.

YAML Bicep

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.

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

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

CloudWatch alarms

2 × OK

TunnelState < 1 → SNS . missing data = breaching

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-TunnelDownOK . vpn-0f2dd8409e8290710 . tunnel 52.49.122.112

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. Both alarms reading OK against live telemetry is the proof these are operating, not merely configured.

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

Biggest cost

Azure VPN GW

VpnGw1AZ . tear down between sessions

Full run rate

~$8/day

AWS ~$4.50 + Azure ~$3.50 approx

Monthly budget

$40

alerts 50 / 80 / 100% + forecast

Daily tripwire

catches "left running" within a day

AWS Budgetsactive . EG334S-Monthly-40 + EG334S-Daily-Tripwire-3 → email

Cost Anomaly Detectionactive . service-level, alerts on ≥ $5 spike → email

Daily still-running checkscheduled . 09:00 SGT, push + email, teardown commands attached

Auto-stop on breachnot available . lab IAM blocks Budget Actions (alert-only)

Cost-allocation tagProject tag not activatable . linked account (payer-only); budgets are account-wide

Guardrails are alert-only: AWS emails you, you (or the daily check) act. Cheapest guardrail is still teardown . delete-stack both regions between work sessions.

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.

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.	Follow the required section order; cite real references (not just www); show reasoned technical analysis, not just description.

Report requirements & structure (Project Information §5)

Required section order

1 . Introduction
2 . Project Objectives
3 . Schedule, Milestones & Deliverables
4 . Project Team & Organization
5 . AWS Infrastructure Design & Implementation
6 . Problems Encountered & Solutions
7 . Test Results
8 . Conclusion
Annex A . Bibliography

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)

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

Milestones . tick to update the counter

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 UP

VPN #2 . ~189 ms

Azure VNet

Southeast Asia (Singapore)
10.2.0.0/16

built

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.

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.

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.

Risk watch . the things that actually bite

Overlapping CIDR ranges . #1 cause of "tunnel up, traffic won't route". Locked non-overlapping at M1 (10.0 / 10.1 / 10.2).

Decommission slippage . real mark penalty past 30 Aug 23:59. Rehearse teardown via CloudFormation delete-stack.

Cross-region teardown . resources are per-region across us-east-1 + eu-west-1 + Azure. Clear each separately or orphans survive and cost marks.

▲

Gold-plating . don't start bonus (HA, auto-scaling, monitoring) until M4 done.

▲

Evidence debt . screenshot + save YAML as you build. Can't capture a resource after teardown.

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.