diff --git a/_projects/secure-ingress-via-frontdoor.md b/_projects/secure-ingress-via-frontdoor.md
new file mode 100644
index 0000000..e9f5e23
--- /dev/null
+++ b/_projects/secure-ingress-via-frontdoor.md
@@ -0,0 +1,146 @@
+---
+layout: page
+author: Felix Eyetan
+title: Secure Hub-and-Spoke Architecture on Azure
+level: Intermediate
+description: "Securing ingress traffic via Azure frontdoor private link and Palo Alto firewall"
+is_blog: false
+---
+
+## Project Summary
+
+Partedwaves Ltd delivers web-based services to a global client base. To support secure and scalable internet-facing applications, they require an Azure-based architecture that enables reliable access to backend services developed by their engineering team.
+
+They are considering Azure Front Door for global traffic distribution and CDN capabilities.
+
+Your objective is to design and deploy the necessary infrastructure to securely expose these services to users worldwide, ensuring performance, availability, and protection.
+
+## Pre-requisite and Assumptions
+
+- You have you own Azure account or have and Azure account where you have sufficient permissions to deploy resources.
+- You can login to your Azure portal via `az` cli from your terminal.
+- To limit complexity of the project, we'll not be deploying via a CI/CD pipeline.
+- You own a domain name that you can use.
+- You have Terraform installed on your local machine
+
+## What we will build
+
+In this project, we'll design and deploy a secure, scalable hub-and-spoke network architecture in Azure. The setup includes two spoke virtual networks—each hosting a virtual machine—connected to a central hub that provides shared security and connectivity services.
+
+The hub network hosts:
+
+- Palo Alto firewall for traffic inspection
+- NAT Gateway for secure outbound internet access
+- Azure Bastion for remote administration without public IPs
+
+Inbound traffic is routed through Azure Front Door Premium, integrated with Private Link and protected by WAF policies for Layer 7 inspection.
+
+Spoke VMs use user-defined routes (UDRs) to send traffic through an internal load balancer connected to the firewall, ensuring centralized inspection. East-west traffic between spokes is routed via the hub, enforcing a single control point.
+
+This architecture will demonstrate centralized security, controlled outbound access, and full inspection of north-south and east-west traffic—aligning with Zero Trust principles using Azure-native services and third-party security tooling.
+
+## Architecture
+
+
+Project Architecture Diagram
+
+
+
+
+
+## Project Repository
+
+You can find the project repository the [secure-Ingress-via-azure-frontdoor](https://github.com/madjava/secure-Ingress-via-azure-frontdoor) repository.
+
+Clone the repo
+```bash
+git clone
+```
+
+After cloning, follow the `README.md` file and go through the steps.
+
+## Pros and Cons of the Design
+
+### Pros (Advantages)
+
+* **Centralized Security Control**
+
+ All inbound, outbound, and east-west traffic is funneled through the Palo Alto firewall, enabling consistent inspection, policy enforcement, and unified logging.
+
+* **Simplified Management**
+
+ Shared services like NAT Gateway, Bastion, and Front Door are hosted centrally in the hub—simplifying operations and updates.
+
+* **Enhanced Outbound Security**
+ The NAT Gateway provides predictable outbound traffic with static egress IPs, improving security and compliance tracking.
+
+* **Layer 7 Protection**
+ Azure Front Door WAF adds application-layer (L7) defense, protecting against web attacks such as SQL injection, XSS, and DDoS.
+
+* **Improved East-West Visibility**
+
+ With no direct spoke-to-spoke peering, all lateral traffic passes through the hub firewall, improving visibility and preventing lateral movement.
+
+* **Scalable and Modular**
+
+ New spokes or workloads can be added seamlessly—each benefits from the existing centralized controls and security stack.
+
+* **Zero Trust Alignment**
+
+ The design enforces segmentation, centralized inspection, and least-privilege access—core Zero Trust principles.
+
+### Cons (Trade-offs / Limitations)
+
+* **Increased Complexity**
+
+ The architecture requires careful configuration of UDRs, load balancers, and firewall policies, increasing design complexity.
+
+* **Added Latency**
+
+ Routing all east-west and north-south traffic through the hub firewall introduces additional hops and potential latency.
+
+* **Higher Costs**
+
+ Premium services—Azure Front Door, NAT Gateway, Palo Alto firewall, and Bastion—add to overall deployment cost.
+
+* **Throughput Bottlenecks**
+
+ Improper sizing of the firewall or load balancer can limit performance under heavy workloads.
+
+* **Reliance on Custom Routing**
+
+ Azure’s non-transitive VNet peering model requires manual routing (via UDRs) for spoke-to-spoke communication, adding maintenance overhead.
+
+## Estimated Cost Considerations
+
+In any medium to large-scale cloud project, understanding and managing infrastructure costs is critical. Cloud operational expenses can escalate rapidly if not planned and monitored effectively. A proactive approach to cost estimation ensures that investments are aligned with business value and technical requirements.
+
+### Common Cost Drivers
+
+#### Networking Costs
+
+* **East-West Traffic:** Internal service-to-service communication within a region or across zones.
+* **North-South Traffic:** Ingress and egress to/from the internet, often impacted by firewall, load balancer, and NAT gateway configurations.
+* **Cross-Region Traffic:** Data transfer between Azure regions can be significantly more expensive and should be justified by business continuity or latency requirements.
+
+#### Storage Costs
+
+* **Log Retention:** Services like Log Analytics Workspace and Azure Monitor can accumulate large volumes of logs. Long retention periods and high ingestion rates drive up costs.
+* **Blob Storage:** Used for backups, telemetry, and diagnostics. Costs vary by redundancy tier (LRS, GRS) and access patterns (hot, cool, archive).
+* **Premium Storage SKUs:** Often used for performance-sensitive workloads but must be justified by actual IOPS requirements.
+
+#### Resource SKU Selection
+
+Choosing the right VM sizes, AKS node pools, or App Service plans is essential.
+Over-provisioning leads to waste; under-provisioning affects performance.
+Use Azure Advisor and workload profiling to guide right-sizing decisions.
+
+## Room for Improvement
+
+While this is a common architecture pattern, there is room for improvement or adaptation. Happy to hear your ideas.
+
+## Next steps
+
+- **Challenge yourself:** Attempt to deploy the project code via Azure DevOps pipeline, Github Actions, Jenkins, Argos CD or whatever CI tool you are comfortable with. You can find some blogs on how to do this at [Thomas Thornton Blog](https://thomasthornton.cloud/)
+- **Redundancy & High Availability:** How can you improve on this, where do you see single points of failure in this design and how can you mitigate against that
+- **Further learning:** Azure has lots of great content regarding [network architectures](https://learn.microsoft.com/en-us/azure/architecture/networking/), do check them out and try
diff --git a/assets/images/azure/blog-fd-pls-architecture.png b/assets/images/azure/blog-fd-pls-architecture.png
new file mode 100644
index 0000000..78a7b98
Binary files /dev/null and b/assets/images/azure/blog-fd-pls-architecture.png differ