Lý Thuyết Cốt Lõi
1. App Service Plan — Nền Tảng Hosting
App Service Plan định nghĩa tập hợp các compute resource (CPU, RAM, storage) mà một hoặc nhiều App Service apps chạy trên đó. Plan xác định region, OS (Windows/Linux), số lượng VM instance, và pricing tier. Một plan có thể host nhiều apps — tất cả chia sẻ cùng compute resource.
- • Region: vùng địa lý nơi VM instances được cấp phát (vd: southeastasia)
- • OS: Windows hoặc Linux — không thể đổi sau khi tạo
- • Pricing tier: quyết định hardware profile, tính năng, và giá tiền
- • Instance count: số VM đang chạy (scale out)
- • VM size: CPU/RAM của mỗi instance (scale up)
- • Bị tính phí theo Plan, không theo từng app
- • Plan chạy liên tục kể cả khi không có app hoặc app đang dừng
- • Nhiều apps trên cùng 1 plan = tiết kiệm chi phí
- • Free/Shared tier: chia sẻ VM với các tenant khác, không đảm bảo SLA
- • Basic trở lên: dedicated VM riêng cho tenant
2. Pricing Tiers — Các Cấp Độ Dịch Vụ
Azure App Service cung cấp 6 nhóm pricing tier, mỗi nhóm phục vụ nhu cầu khác nhau từ dev/test đến production enterprise với yêu cầu isolation cao.
| Tier | Use case | Custom domain | SSL | Scale out | Slots |
|---|---|---|---|---|---|
| Free (F1) | Thử nghiệm, học | ✗ | ✗ | 1 instance | ✗ |
| Shared (D1) | Dev nhỏ, custom domain | ✓ | ✗ | 1 instance | ✗ |
| Basic (B1/B2/B3) | Dev/Test dedicated | ✓ | ✓ | Max 3 | ✗ |
| Standard (S1/S2/S3) | Production workload | ✓ | ✓ | Max 10 | 5 slots |
| Premium (P1v3/P2v3/P3v3) | High traffic, VNet integration | ✓ | ✓ | Max 30 | 20 slots |
| Isolated (I1v2/I2v2/I3v2) | Enterprise, compliance, ASE | ✓ | ✓ | Max 100 | 20 slots |
Shared infrastructure với các tenant khác. CPU time quota giới hạn (F1: 60 min/ngày). Không có SLA. Chỉ dùng để học và thử nghiệm.
Dedicated VMs. Standard+ hỗ trợ autoscale, deployment slots, Traffic Manager. Premium thêm VNet integration, Zone Redundancy.
App Service Environment (ASE) — dedicated hardware trong VNet riêng. Inbound/outbound traffic hoàn toàn trong VNet. Dùng cho fintech, y tế, chính phủ.
3. Scale Up vs Scale Out
Azure App Service hỗ trợ 2 chiến lược scaling độc lập và bổ sung cho nhau. Hiểu rõ từng chiến lược giúp tối ưu chi phí và hiệu năng.
Nâng cấp tier của App Service Plan lên cấu hình mạnh hơn — nhiều CPU, RAM, disk hơn. Tương đương việc chuyển sang máy chủ vật lý mạnh hơn.
- • Thay đổi plan từ B1 → S1 → P1v3 → I1v2
- • Xảy ra downtime ngắn (vài giây) khi scale
- • Cho phép truy cập tính năng cao hơn (slots, autoscale)
- • Giới hạn bởi tier cao nhất (Isolated I3v2)
- • Thích hợp khi app bị giới hạn bởi tài nguyên đơn instance
Tăng số lượng VM instance đang chạy app. Requests được phân phối qua nhiều instance — tăng khả năng chịu tải mà không cần nâng cấp phần cứng.
- • Manual scale: đặt số instance cố định (vd: 3 instances)
- • Autoscale (Standard+): tự động tăng/giảm instance theo metrics
- • Metrics trigger: CPU %, memory %, HTTP queue, custom
- • Scale rule: min/max instance count, cooldown period
- • Không có downtime khi thêm/bớt instance
4. Autoscale, Shared Plan & Chiến Lược Tối Ưu
Yêu cầu Standard tier trở lên. Cấu hình gồm:
- • Scale-out rule: khi CPU > 70% trong 5 phút → thêm 1 instance
- • Scale-in rule: khi CPU < 30% trong 10 phút → bớt 1 instance
- • Min/Max instances: giới hạn không bị scale quá nhiều/ít
- • Cooldown: thời gian chờ giữa 2 lần scale (default: 5 phút)
- • Profile: schedule-based (giờ cao điểm) hoặc metric-based
Cho phép nhưng cần cân nhắc:
- • Apps chia sẻ CPU/RAM — 1 app tải cao ảnh hưởng app khác
- • Tiết kiệm chi phí cho môi trường dev/staging
- • Production: mỗi app quan trọng nên có plan riêng
- • Clone app: tạo bản sao sang plan/region khác dễ dàng
Isolated tier chạy trong ASE — môi trường dedicated hoàn toàn bên trong VNet. ASEv3 hỗ trợ Zone Redundancy. Phí ASE = phí plan + phí stamp ($. Thường dùng cho ngân hàng, bảo hiểm, cơ quan chính phủ VN cần data residency và network isolation.
- • Dev/Test: Free F1 hoặc Basic B1
- • Production nhỏ: Standard S1 (autoscale + slots)
- • Production lớn: Premium P1v3/P2v3 (VNet, zone redundancy)
- • Compliance cao: Isolated I1v2 trong ASEv3
- • Serverless: xem xét Azure Functions thay vì App Service
Bài Tập Thực Hành (Lab)
Tạo Resource Group và App Service Plan (Standard S1)
# Tạo Resource Group tại Southeast Asia
az group create \
--name rg-az104-m23 \
--location southeastasia \
--tags Course=AZ-104 Module=23 Environment=Lab
# Tạo App Service Plan SKU Standard S1 (Windows)
az appservice plan create \
--name asp-az104-m23-standard \
--resource-group rg-az104-m23 \
--location southeastasia \
--sku S1 \
--is-windows
# Kiểm tra plan vừa tạo
az appservice plan show \
--name asp-az104-m23-standard \
--resource-group rg-az104-m23 \
--query "{name:name, sku:sku.name, tier:sku.tier, workers:sku.capacity, os:kind}" \
--output table
asp-az104-m23-standard xuất hiện với Pricing Tier = Standard S1, Region = Southeast Asia, OS = Windows.
Scale Up — Nâng cấp từ Standard S1 lên Premium P1v3
# Xem pricing tier hiện tại
az appservice plan show \
--name asp-az104-m23-standard \
--resource-group rg-az104-m23 \
--query "sku" --output table
# Scale Up: nâng từ S1 lên P1v3 (thêm VNet integration, Zone Redundancy support)
az appservice plan update \
--name asp-az104-m23-standard \
--resource-group rg-az104-m23 \
--sku P1V3
# Verify sau scale up
az appservice plan show \
--name asp-az104-m23-standard \
--resource-group rg-az104-m23 \
--query "{sku:sku.name, tier:sku.tier, size:sku.size}" \
--output table
asp-az104-m23-standard → Scale up (App Service plan) → xác nhận tier hiện tại là P1v3 Premium, và tùy chọn "Deployment slots" đã tăng lên 20 slots.
Scale Out thủ công — Đặt 3 instances
# Scale Out thủ công: đặt số instance = 3
az appservice plan update \
--name asp-az104-m23-standard \
--resource-group rg-az104-m23 \
--number-of-workers 3
# Xác nhận số workers hiện tại
az appservice plan show \
--name asp-az104-m23-standard \
--resource-group rg-az104-m23 \
--query "sku.capacity" \
--output tsv
# Liệt kê tất cả plans trong resource group
az appservice plan list \
--resource-group rg-az104-m23 \
--output table
asp-az104-m23-standard → Scale out (App Service plan) → xác nhận Instance count = 3 và trạng thái là "Manual scale".
Cấu hình Autoscale theo CPU metric
# Lấy resource ID của App Service Plan
PLAN_ID=$(az appservice plan show \
--name asp-az104-m23-standard \
--resource-group rg-az104-m23 \
--query id --output tsv)
echo "Plan ID: $PLAN_ID"
# Tạo autoscale setting với scale-out khi CPU > 70% và scale-in khi CPU < 30%
az monitor autoscale create \
--resource-group rg-az104-m23 \
--resource "$PLAN_ID" \
--resource-type "Microsoft.Web/serverfarms" \
--name "autoscale-m23-cpu" \
--min-count 1 \
--max-count 5 \
--count 2
# Thêm rule scale-out: CPU > 70% → thêm 1 instance
az monitor autoscale rule create \
--resource-group rg-az104-m23 \
--autoscale-name "autoscale-m23-cpu" \
--condition "Percentage CPU > 70 avg 5m" \
--scale out 1 \
--cooldown 5
# Thêm rule scale-in: CPU < 30% → bớt 1 instance
az monitor autoscale rule create \
--resource-group rg-az104-m23 \
--autoscale-name "autoscale-m23-cpu" \
--condition "Percentage CPU < 30 avg 10m" \
--scale in 1 \
--cooldown 10
# Xem cấu hình autoscale
az monitor autoscale show \
--resource-group rg-az104-m23 \
--name "autoscale-m23-cpu" \
--output yaml
asp-az104-m23-standard → Scale out → xác nhận "Custom autoscale" đang bật với min=1, max=5 instances và 2 rules CPU-based. Tab "Run history" sẽ hiển thị lịch sử scale events.
Cleanup — Dọn dẹp tài nguyên
# Xóa toàn bộ Resource Group (bao gồm plan, autoscale settings, apps)
az group delete --name rg-az104-m23 --yes --no-wait
# Xác nhận RG đang được xóa
az group show --name rg-az104-m23 --query "properties.provisioningState" -o tsv
# Kết quả mong đợi: Deleting (hoặc lỗi Not Found sau khi xóa xong)
Kết Quả Đầu Ra
Hiểu plan là đơn vị billing và compute, phân biệt plan với app, biết tác động khi nhiều app chia sẻ plan
So sánh Free/Shared/Basic/Standard/Premium/Isolated theo tính năng, SLA, giới hạn scale, deployment slots
Nâng tier plan từ Standard lên Premium, xác nhận tính năng mới được mở khóa sau scale up
Đặt instance count cố định và tạo autoscale rules CPU-based với scale-out/in conditions
Nắm khi nào cần Isolated tier/ASEv3, lợi ích network isolation và compliance cho doanh nghiệp lớn
Áp dụng decision framework để chọn tier tối ưu chi phí và đáp ứng SLA cho từng môi trường
Ứng Dụng Thực Tế
Tình huống 1: Sàn TMĐT Việt Nam — Autoscale theo giờ cao điểm
Website bán lẻ có traffic thấp ban ngày nhưng đột biến 10x vào buổi tối (20h-23h) và các dịp sale lớn (12/12, Tết).
Dùng Standard S2 plan với autoscale: min 2 instances ban ngày, scale out lên 10 instances khi CPU > 60%. Thêm schedule-based profile cho ngày sale: pre-scale lên 8 instances trước 20h.
App Service Plan S2 tại Southeast Asia. Autoscale profile "Peak Hours" (20h-24h): min 5, max 15 instances. Profile "Off-peak": min 2, max 5. Cooldown 3 phút. Alert email khi scale-out xảy ra.
Chi phí giảm 40% so với chạy cố định 15 instances. Zero downtime khi traffic tăng đột biến. Response time ổn định dưới 500ms ngay cả ngày sale 12/12.
Tình huống 2: Ngân hàng số — Isolated Plan cho compliance
Ứng dụng mobile banking cần tuân thủ quy định NHNN về data residency và bảo mật, không được chia sẻ hạ tầng với tenant khác.
Triển khai ASEv3 (Isolated I2v2) trong VNet riêng tại Southeast Asia. Internal load balancer chỉ accessible trong VNet. Private endpoint cho Azure SQL và Key Vault.
ASEv3 với Zone Redundancy (3 AZ). I2v2 plan: 4 vCPU, 16 GB RAM/instance. Scale out 3–10 instances. WAF policy tại Application Gateway phía trước. TLS 1.3 bắt buộc.
Đạt tiêu chuẩn ISO 27001 và PCI-DSS. Data không bao giờ rời VNet nội bộ. Kiểm toán nội bộ dễ dàng — toàn bộ traffic log qua NSG flow logs và Azure Firewall.
Tình huống 3: Startup EdTech — Tối ưu chi phí Dev/Staging/Prod
Startup nhỏ với 3 môi trường cần cân bằng giữa chi phí thấp và trải nghiệm dev tốt.
Dev: Free F1 (1 plan, host 3 apps khác nhau). Staging: Basic B1 (1 plan, 1 app). Production: Standard S1 với deployment slots — staging slot trên cùng plan production để swap zero-downtime.
CI/CD pipeline deploy lên staging slot, chạy smoke test, sau đó slot swap sang production. S1 autoscale: min 1, max 3 instances theo HTTP queue length. Tắt plan dev ngoài giờ làm để tiết kiệm thêm.
Chi phí tổng ~$80/tháng thay vì $300+ nếu dùng Standard cho cả 3 env. Deploy không downtime. Dev team test trên env gần giống production nhất. Rollback trong 30 giây bằng swap ngược.