Step 2: Architecture Assessment - aks-platform

🏗️ Step 2: Architecture Assessment - aks-platform

• ✅ Requirements Validation
• 💮 Executive Summary
• 🏗️ WAF Pillar Assessment
• 📦 Resource SKU Recommendations
• 🎯 Architecture Decision Summary
• 🚀 Implementation Handoff
• 🔒 Approval Gate
• References

Generated by architect agent | 2026-02-15

✅ Requirements Validation

💮 Executive Summary container platform with WAF-protected ingress

(Application Gateway with AGIC), Azure SQL Database backend, and NAT Gateway for deterministic outbound traffic. The architecture follows the AKS baseline reference architecture with additions for WAF ingress, SQL integration, and NAT Gateway egress.

The design prioritizes Security and Reliability as primary WAF pillars, with enterprise compliance (SOC 2, GDPR, ISO 27001) driving private endpoint adoption and network isolation. Cost optimization is achieved through right-sized SKUs and reserved instance eligibility while staying within the $3,000–5,000/month budget envelope.

Estimated monthly cost: ~$1,880–2,400 (pay-as-you-go), well within budget. Reserved instances can reduce this further by ~$150–250/month.

Recommended Architecture

flowchart TB
    Users["🌐 Users / Clients"] --> AppGW["🛡️ Application Gateway\nWAF v2 + AGIC"]

    subgraph VNet["Virtual Network (10.0.0.0/16)"]
        direction TB

        subgraph AppGWSub["App GW Subnet (10.0.4.0/24)"]
            AppGW
        end

        subgraph AKSSub["AKS Subnet (10.0.0.0/22)"]
            AKS["☸️ AKS Cluster\nStandard Tier"]
            SystemPool["System Pool\n2× D2s_v5"]
            UserPool["User Pool\n3-8× D4s_v5"]
        end

        subgraph PESub["Private Endpoint Subnet (10.0.5.0/24)"]
            SQLPE["SQL PE"]
            ACRPE["ACR PE"]
            KVPE["KV PE"]
        end
    end

    AKS --> SystemPool
    AKS --> UserPool
    AKSSub --> NATGW["📤 NAT Gateway\n(Deterministic Egress)"]
    NATGW --> Internet["🌐 External APIs"]

    AKS --> SQLPE --> SQL["🗄️ Azure SQL\nGP 4 vCore (ZR)"]
    AKS --> ACRPE --> ACR["📦 ACR Premium"]
    AKS --> KVPE --> KV["🔑 Key Vault"]
    AKS --> Monitor["📊 Container Insights\n+ Log Analytics"]

    AppGW --> AKS

🏗️ WAF Pillar Assessment

Overall Scores

Composite WAF Score: 7.6/10 Primary Pillar Optimized: Security Trade-offs Accepted: Slightly higher cost for Premium ACR (required for private endpoints); non-private AKS API server (required for AGIC addon — mitigated with authorized IP ranges)

%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#4FC3F7"}}}%%
xychart-beta
    title "WAF Pillar Scores"
    x-axis ["Security", "Reliability", "Performance", "Cost", "Operations"]
    y-axis "Score" 0 --> 10
    bar [8, 8, 7, 8, 7]

Service Maturity Assessment

AGIC addon rated 🟡 Medium because Microsoft recommends evaluating the standalone AGIC Helm chart for advanced scenarios. The addon approach is simpler but has fewer customization options.

🔒 Security Assessment (8/10)

Strengths:

• Private endpoints for all data-plane services (SQL, ACR, Key Vault) — zero public access to backends
• WAF v2 in Prevention mode with OWASP 3.2 ruleset blocking malicious traffic at the edge
• Managed identity throughout: Workload Identity for pods, kubelet identity for ACR pull and KV access
• Azure AD-only authentication for both AKS and SQL — local accounts disabled
• Network isolation via Azure CNI + Calico network policies + NSGs on all subnets
• TLS 1.2 enforced on all endpoints; Key Vault for certificate and secret management
• Defender for Containers enabled for runtime threat detection

Gaps:

• AKS API server is not private (required for AGIC addon compatibility) — mitigated by authorized IP ranges
• No Azure DDoS Protection Standard plan (relies on built-in Basic protection + WAF)
• No Microsoft Defender for SQL explicitly budgeted (though ATP is included in requirements)

Recommendations:

1. Configure AKS authorized IP ranges to restrict API server access to known corporate CIDRs and CI/CD runners
2. Enable diagnostic settings on all resources to send security logs to Log Analytics (AKS audit logs, NSG flow logs, SQL audit logs)
3. Evaluate Azure DDoS Protection Standard if public-facing traffic grows beyond initial projections
4. Implement Kubernetes Pod Security Standards via Azure Policy (Baseline profile minimum, Restricted for prod namespaces)

🔄 Reliability Assessment (8/10)

Strengths:

• AKS Standard tier with Uptime SLA → 99.95% API server availability
• Zone-redundant SQL Database General Purpose (automatic failover across AZs)
• Multi-node system pool (2 nodes min) with taint — dedicated to critical workloads
• User pool with autoscale (3→8 nodes) absorbs load spikes
• PITR backups for SQL (35-day short-term + weekly LTR for 1 year)
• Key Vault soft-delete (90 days) + purge protection for secret recovery
• GitOps-based cluster config recovery — infrastructure fully reproducible from Bicep

Gaps:

• Single-region deployment (swedencentral only) — no active-passive DR for AKS workloads
• NAT Gateway is a single point of failure for outbound traffic (though it has built-in HA within a zone)
• No Velero or equivalent backup for Kubernetes persistent state

Recommendations:

1. Document RTO/RPO recovery procedures: rebuild AKS from Bicep + GitOps in germanywestcentral
2. Implement Velero for stateful workload backups if persistent volumes are used
3. Configure AKS cluster auto-upgrade channel (stable) to maintain patch currency
4. Test SQL geo-restore to germanywestcentral annually as part of DR drill

⚡ Performance Assessment (7/10)

Strengths:

• D4s_v5 user nodes (4 vCPU, 16 GB) well-suited for typical microservices workloads
• Azure CNI provides native VNet IP assignment — no overlay network latency penalty
• Application Gateway autoscale (2→10 instances) handles traffic bursts
• SQL General Purpose 4 vCores provides adequate IOPS for 50–200 GB dataset
• HPA planned for CPU/memory-based pod autoscaling

Gaps:

• No Redis Cache layer for high-frequency read operations
• <200 ms p95 API target not validated — requires load testing against actual workloads
• SQL provisioned compute has fixed ceiling; may need right-sizing after workload profiling
• No CDN for static asset delivery (not required but could improve frontend performance)

Recommendations:

1. Conduct load testing with Azure Load Testing service before production launch
2. Profile SQL query performance under realistic load; consider scaling to 8 vCores if p95 > 200 ms
3. Evaluate Azure Cache for Redis (Basic C1 or Standard C0) if caching patterns emerge
4. Ensure HPA thresholds align with Application Gateway health probe intervals

💰 Cost Assessment (8/10)

Cost Optimization Applied:

• Linux-only nodes (no Windows licensing surcharge)
• AKS Standard tier (not Premium) for 99.95% SLA at lower management plane cost
• SQL General Purpose (not Business Critical) — sufficient for non-OLTP-intensive workloads
• Log Analytics ingestion capped at ~20 GB/mo; configure diagnostic settings selectively
• Spot node pool eligible for dev/test workloads (requirements mention this — saves ~40–60% on dev VMs)

🔧 Operational Excellence Assessment (7/10)

Strengths:

• Full Infrastructure as Code via Bicep with AVM modules
• Container Insights + Log Analytics for centralized observability
• Diagnostic settings planned for all resources
• Change management via pull request on Bicep templates
• Maintenance windows defined (Sundays 02:00–06:00 CET)

Gaps:

• GitOps tooling (Flux/ArgoCD) not yet specified for workload delivery
• No runbook or incident response playbook defined
• Alert rules and action groups not yet configured
• No chaos engineering or game day testing planned

Recommendations:

1. Implement Azure Monitor alert rules for: node NotReady, pod CrashLoopBackOff, SQL DTU > 80%, App GW 5xx rate
2. Configure Action Groups routing P1 alerts to Teams + PagerDuty/email within 5 minutes
3. Adopt GitOps (Flux v2 via AKS extension) for workload deployment — keeps cluster config separate from infra
4. Create operational runbooks for common scenarios: node pool scaling, AKS upgrade, SQL failover, certificate rotation

📦 Resource SKU Recommendations

Selected: D2s_v5 (system) + D4s_v5 (user) — current generation with best price/performance ratio. Upgrade to D8s_v5 only if pods require > 14 GB allocatable memory.

Selected: GP Gen5 4 vCore (zone-redundant) — meets performance needs with HA across availability zones. Scale to 8 vCores if profiling shows CPU pressure.

Selected: WAF v2 — mandatory per requirements (WAF Prevention mode, OWASP 3.2). Capacity units add ~$100/mo based on estimated throughput.

🎯 Architecture Decision Summary

🚀 Implementation Handoff

Ready for bicep-plan

The architecture is approved for implementation with the following key parameters:

Resources to Provision

Security Requirements for Implementation

Monitoring Requirements for Implementation

🔒 Approval Gate

[!IMPORTANT] 🏗️ Architecture Assessment Complete

Pillar	Score
Security	8/10
Reliability	8/10
Performance	7/10
Cost	8/10
Operations	7/10

Composite WAF Score: 7.6/10

Estimated Monthly Cost: ~$1,880 (within budget of $3,000–5,000)

Confidence Level: High

• Approved — proceed to bicep-plan
• Approver: ___
• Date: ___

Reply "approve" to proceed to bicep-plan, or provide feedback for revisions.

References

[!NOTE] 📚 The following Microsoft Learn resources informed this assessment.

Generated by Azure Agentic InfraOps | GitHub