AZURE FUNDAMENTAL

Mục lục

• Phần 1: Giới thiệu Tổng quan và Các khái niệm Cốt lõi của Azure

  • 1.1. Giới thiệu về Microsoft Azure: Lịch sử và Vị thế trên thị trường Cloud
  • 1.2. So sánh Triết lý và Kiến trúc Tổng thể: AWS vs. Azure
  • 1.3. Cấu trúc Toàn cầu của Azure: Regions, Availability Zones, và Edge Locations
    • Ánh xạ với AWS Global Infrastructure
  • 1.4. Mô hình Tổ chức và Quản lý Tài nguyên trong Azure: Subscriptions, Resource Groups, và Tagging
    • So sánh với AWS Accounts, Organizations, và Tagging
  • 1.5. Giao diện và Công cụ Quản lý: Azure Portal, Azure CLI, PowerShell, và Azure Cloud Shell
    • Tương quan với AWS Management Console, AWS CLI, và CloudShell
  • 1.6. Azure Resource Manager (ARM): Trái tim của việc Quản lý Tài nguyên
    • So sánh với AWS CloudFormation và Infrastructure as Code (IaC)

• Phần 2: Dịch vụ Compute - Chạy ứng dụng của bạn trên Azure

  • 2.1. Azure Virtual Machines (VMs): Nền tảng IaaS
    • Ánh xạ từ Amazon EC2: Các loại máy ảo (Series), Kích thước, và Gia đình (Families)
    • Use case thực tế: Triển khai một Web Server trên Azure VM
  • 2.2. Azure App Service: Nền tảng PaaS cho ứng dụng Web và API
    • So sánh với AWS Elastic Beanstalk và AWS Lambda (cho một số use case)
    • Use case thực tế: Triển khai một ứng dụng Node.js lên App Service với CI/CD từ GitHub Actions
  • 2.3. Azure Functions: Điện toán Serverless
    • Tương quan với AWS Lambda: Triggers, Bindings, và mô hình thực thi
    • Use case thực tế: Xử lý ảnh được tải lên Blob Storage một cách tự động
  • 2.4. Azure Kubernetes Service (AKS): Dịch vụ Kubernetes được quản lý
    • So sánh với Amazon Elastic Kubernetes Service (EKS)
    • Use case thực tế: Triển khai một ứng dụng microservices trên AKS
  • 2.5. Azure Container Instances (ACI): Chạy container đơn lẻ không cần máy chủ
    • Tương quan với AWS Fargate (cho các tác vụ đơn giản)
    • Use case thực tế: Chạy một tác vụ xử lý dữ liệu theo lô (batch processing)

• Phần 3: Dịch vụ Lưu trữ (Storage) - Lưu trữ dữ liệu của bạn một cách an toàn và hiệu quả

  • 3.1. Azure Blob Storage: Lưu trữ đối tượng (Object Storage)
    • Ánh xạ từ Amazon S3: Tiers (Hot, Cool, Archive), và các tính năng
    • Use case thực tế: Lưu trữ hình ảnh, video và các tài sản tĩnh cho một trang web
  • 3.2. Azure Disk Storage: Lưu trữ khối (Block Storage) cho Máy ảo
    • So sánh với Amazon EBS: Các loại đĩa (Standard HDD, Standard SSD, Premium SSD, Ultra Disk)
    • Use case thực tế: Cấu hình đĩa cho một máy chủ cơ sở dữ liệu trên Azure VM
  • 3.3. Azure Files: Dịch vụ chia sẻ tệp được quản lý (Managed File Share)
    • Tương quan với Amazon EFS và Amazon FSx
    • Use case thực tế: Chia sẻ tệp giữa nhiều máy ảo trong một môi trường hybrid
  • 3.4. Azure Table Storage: Lưu trữ NoSQL dạng Key-Value
    • So sánh với Amazon DynamoDB (ở mức độ cơ bản)
    • Use case thực tế: Lưu trữ dữ liệu người dùng và metadata

• Phần 4: Mạng và Phân phối Nội dung (Networking & Content Delivery)

  • 4.1. Azure Virtual Network (VNet): Nền tảng mạng ảo của bạn
    • Ánh xạ từ Amazon VPC: Subnets, Network Security Groups (NSGs), và Route Tables
    • Use case thực tế: Thiết kế một kiến trúc mạng an toàn cho một ứng dụng đa tầng
  • 4.2. Azure Load Balancer và Application Gateway: Cân bằng tải
    • So sánh với AWS Elastic Load Balancer (ELB), Application Load Balancer (ALB), và Network Load Balancer (NLB)
    • Use case thực tế: Phân phối lưu lượng truy cập cho một cụm máy chủ web
  • 4.3. Azure DNS: Dịch vụ DNS
    • Tương quan với Amazon Route 53
  • 4.4. Azure CDN: Mạng phân phối nội dung toàn cầu
    • So sánh với Amazon CloudFront
  • 4.5. Azure VPN Gateway và ExpressRoute: Kết nối Hybrid
    • Ánh xạ từ AWS Site-to-Site VPN và Direct Connect

• Phần 5: Cơ sở dữ liệu (Databases)

  • 5.1. Azure SQL Database: Dịch vụ cơ sở dữ liệu quan hệ được quản lý (PaaS)
    • So sánh với Amazon RDS
    • Use case thực tế: Xây dựng một ứng dụng web với cơ sở dữ liệu SQL được quản lý hoàn toàn
  • 5.2. Azure Cosmos DB: Cơ sở dữ liệu NoSQL đa mô hình, phân tán toàn cầu
    • So sánh với Amazon DynamoDB và các dịch vụ NoSQL khác
    • Use case thực tế: Xây dựng một ứng dụng IoT với yêu cầu độ trễ thấp trên toàn cầu
  • 5.3. Azure Database for MySQL/PostgreSQL/MariaDB: Dịch vụ cơ sở dữ liệu mã nguồn mở được quản lý
    • Tương quan với Amazon RDS for MySQL/PostgreSQL/MariaDB
  • 5.4. Azure Synapse Analytics: Dịch vụ phân tích dữ liệu hợp nhất
    • So sánh với AWS Redshift, AWS Glue, và các dịch vụ phân tích khác

• Phần 6: Nhận dạng và Bảo mật (Identity & Security)

  • 6.1. Azure Active Directory (Azure AD): Dịch vụ quản lý danh tính và truy cập
    • Ánh xạ từ AWS Identity and Access Management (IAM)
    • Use case thực tế: Quản lý người dùng, nhóm, và quyền truy cập vào các ứng dụng Azure
  • 6.2. Role-Based Access Control (RBAC): Kiểm soát truy cập dựa trên vai trò
    • So sánh với AWS IAM Policies
  • 6.3. Azure Key Vault: Quản lý bí mật và khóa mã hóa
    • Tương quan với AWS Key Management Service (KMS) và AWS Secrets Manager
  • 6.4. Azure Security Center: Quản lý tư thế bảo mật và bảo vệ khỏi mối đe dọa
    • So sánh với AWS Security Hub và Amazon GuardDuty

• Phần 7: Giám sát và Quản lý (Monitoring & Management)

  • 7.1. Azure Monitor: Dịch vụ giám sát toàn diện
    • Ánh xạ từ Amazon CloudWatch
    • Use case thực tế: Theo dõi hiệu suất của máy ảo và thiết lập cảnh báo
  • 7.2. Azure Log Analytics: Phân tích log
    • So sánh với Amazon CloudWatch Logs
  • 7.3. Azure Advisor: Các đề xuất được cá nhân hóa để tối ưu hóa Azure
    • Tương quan với AWS Trusted Advisor

• Phần 8: Chi phí và Tối ưu hóa (Cost & Optimization)

  • 8.1. Azure Cost Management + Billing: Quản lý và phân tích chi phí
    • So sánh với AWS Cost Explorer và AWS Budgets
  • 8.2. Các mô hình định giá và chiến lược tiết kiệm chi phí trong Azure
    • Reservations, Azure Hybrid Benefit, và Spot VMs

---

Phần 1: Giới thiệu Tổng quan và Các khái niệm Cốt lõi của Azure

Phần này đặt nền móng cho toàn bộ hành trình chuyển đổi của bạn. Chúng ta sẽ khám phá những điểm tương đồng và khác biệt cốt lõi trong triết lý thiết kế, cấu trúc hạ tầng và mô hình quản lý giữa hai gã khổng lồ đám mây.

1.1. Giới thiệu về Microsoft Azure: Lịch sử và Vị thế trên thị trường Cloud

Microsoft Azure, ban đầu có tên là "Windows Azure", được công bố vào năm 2008 và chính thức ra mắt vào năm 2010. Đây là nỗ lực của Microsoft nhằm cạnh tranh trực tiếp với Amazon Web Services (AWS), vốn đã đi tiên phong trong lĩnh vực điện toán đám mây công cộng.

Khác với AWS, vốn có khởi đầu từ cơ sở hạ tầng của trang thương mại điện tử Amazon.com, Azure được xây dựng dựa trên nền tảng kinh nghiệm sâu rộng của Microsoft trong việc cung cấp phần mềm và dịch vụ cho doanh nghiệp. Điều này thể hiện rõ qua việc Azure có sự tích hợp sâu sắc với các sản phẩm doanh nghiệp khác của Microsoft như Office 365, Dynamics 365, và đặc biệt là Active Directory.

Ngày nay, Azure là một trong hai nhà cung cấp dịch vụ đám mây hàng đầu thế giới, cạnh tranh trực tiếp với AWS ở mọi phân khúc thị trường. Azure có thế mạnh đặc biệt trong các doanh nghiệp lớn (enterprise) và các môi trường hybrid (kết hợp giữa on-premises và cloud), nhờ vào các lợi thế về bản quyền phần mềm (Azure Hybrid Benefit) và các giải pháp hybrid như Azure Arc và Azure Stack.

1.2. So sánh Triết lý và Kiến trúc Tổng thể: AWS vs. Azure

Mặc dù cả hai nền tảng đều cung cấp một bộ dịch vụ tương tự (compute, storage, networking, database,...), triết lý và cách tiếp cận của chúng có những điểm khác biệt tinh tế nhưng quan trọng:

• AWS - "Primitive" Services (Dịch vụ nguyên thủy): AWS thường cung cấp các dịch vụ dưới dạng các "viên gạch LEGO" cơ bản, rất mạnh mẽ và linh hoạt. Người dùng có toàn quyền kiểm soát để xây dựng và tùy chỉnh kiến trúc của mình từ những thành phần cơ bản này. Điều này mang lại sự linh hoạt tối đa nhưng cũng đòi hỏi người dùng phải có kiến thức sâu hơn để kết hợp chúng một cách hiệu quả. Ví dụ, để xây dựng một môi trường web hoàn chỉnh, bạn cần tự kết hợp EC2, ELB, VPC, RDS, Route 53,...
• Azure - "Solution-oriented" Services (Dịch vụ hướng giải pháp): Azure, với nền tảng từ thế giới doanh nghiệp, thường có xu hướng cung cấp các giải pháp được đóng gói sẵn, tích hợp cao hơn để giải quyết các bài toán cụ thể. Ví dụ, Azure App Service không chỉ là một máy chủ web mà là một nền tảng PaaS hoàn chỉnh, tích hợp sẵn các tính năng như CI/CD, custom domains, SSL, auto-scaling, và deployment slots. Điều này giúp giảm bớt gánh nặng quản lý và tăng tốc độ phát triển, đặc biệt là với các ứng dụng web và API.

Sự khác biệt này không có nghĩa là nền tảng nào tốt hơn, mà chỉ đơn giản là chúng có những điểm mạnh khác nhau, phù hợp với các đối tượng và use-case khác nhau.

1.3. Cấu trúc Toàn cầu của Azure: Regions, Availability Zones, và Edge Locations

Kiến trúc hạ tầng toàn cầu của Azure rất giống với AWS, giúp bạn dễ dàng nắm bắt.

• Regions (Vùng):

  • Azure: Một Region là một tập hợp các trung tâm dữ liệu (datacenters) được triển khai trong một khu vực địa lý xác định và được kết nối với nhau bằng một mạng có độ trễ thấp.
  • AWS: Tương đương trực tiếp với AWS Regions.
  • Lưu ý: Khi bạn triển khai một tài nguyên, bạn phải chọn một Region. Không phải tất cả các dịch vụ đều có sẵn ở mọi Region. Azure có khái niệm "Recommended Regions" (Vùng được đề xuất) là những vùng cung cấp bộ dịch vụ rộng nhất và thường được ưu tiên cho các dịch vụ mới.

• Availability Zones (AZs - Vùng sẵn sàng):

  • Azure: Availability Zones là các vị trí vật lý riêng biệt trong một Azure Region. Mỗi AZ bao gồm một hoặc nhiều trung tâm dữ liệu với hệ thống điện, làm mát, và mạng độc lập.
  • AWS: Tương đương trực tiếp với AWS Availability Zones.
  • Use-case: Triển khai các máy ảo hoặc dịch vụ trên nhiều AZ để đạt được tính sẵn sàng cao (High Availability - HA). Nếu một AZ gặp sự cố, ứng dụng của bạn vẫn có thể hoạt động bình thường trên các AZ còn lại. Các dịch vụ của Azure như Virtual Machines, SQL Database, AKS,... đều hỗ trợ triển khai đa AZ.

• Region Pairs (Cặp Vùng):

  • Đây là một khái niệm độc đáo của Azure. Mỗi Azure Region được ghép cặp với một Region khác trong cùng một khu vực địa lý (ví dụ: East US được ghép cặp với West US).
  • Lợi ích:
    • Phục hồi sau thảm họa (Disaster Recovery - DR): Azure ưu tiên việc khôi phục một Region trong cặp nếu có sự cố ngừng hoạt động trên diện rộng.
    • Cập nhật tuần tự: Các bản cập nhật hệ thống của Azure được triển khai tuần tự đến từng Region trong cặp, giảm thiểu nguy cơ ảnh hưởng đồng thời đến cả hai.
  • AWS: AWS không có khái niệm tương đương trực tiếp, việc thiết lập DR giữa các Region là do người dùng tự cấu hình.

1.4. Mô hình Tổ chức và Quản lý Tài nguyên trong Azure: Subscriptions, Resource Groups, và Tagging

Đây là một trong những điểm khác biệt lớn và quan trọng nhất mà bạn cần nắm vững khi chuyển từ AWS sang Azure.

Khái niệm Azure	Tương đương gần đúng trong AWS	Mô tả và Chức năng
Management Group	AWS Organizations	Cấp cao nhất trong hệ thống phân cấp, dùng để nhóm các Subscriptions lại với nhau và áp dụng các chính sách (Azure Policy) và kiểm soát truy cập (RBAC) một cách đồng bộ. Rất hữu ích cho các doanh nghiệp lớn.
Subscription	AWS Account	Đây là đơn vị cốt lõi của Azure. Một Subscription là một thỏa thuận với Microsoft để sử dụng các dịch vụ Azure và là một ranh giới cho việc thanh toán (billing boundary). Mọi tài nguyên Azure đều phải thuộc về một Subscription.
Resource Group	(Không có tương đương trực tiếp)	Đây là khái niệm quan trọng nhất. Một Resource Group là một container logic để nhóm các tài nguyên Azure có liên quan lại với nhau. Ví dụ, tất cả các tài nguyên cho một ứng dụng (VM, VNet, DB,...) nên được đặt trong cùng một Resource Group. Một tài nguyên chỉ có thể thuộc về một Resource Group. Resource Group cũng là một đơn vị để quản lý vòng đời (life-cycle) và áp dụng quyền truy cập (RBAC).
Resource	AWS Resource (EC2 instance, S3 bucket,...)	Là một thực thể có thể quản lý được trong Azure, ví dụ như Virtual Machine, Storage Account, Virtual Network,...
Tagging	AWS Tagging	Tương tự như AWS, dùng để gán metadata cho tài nguyên dưới dạng key-value pair, giúp cho việc tổ chức, quản lý chi phí, và tự động hóa.

So sánh trực tiếp:

• AWS: Bạn có nhiều AWS Accounts, mỗi account là một ranh giới cứng về tài nguyên và thanh toán. Bạn dùng AWS Organizations để quản lý tập trung các accounts này.
• Azure: Bạn thường bắt đầu với một Azure AD Tenant (chúng ta sẽ nói ở Phần 6), trong đó bạn có thể có một hoặc nhiều Subscriptions. Subscription là ranh giới thanh toán, nhưng không phải là một ranh giới cứng về tài nguyên như AWS Account. Resource Group mới là đơn vị nhóm tài nguyên chính.

Use-case thực tế về Resource Group:

Hãy tưởng tượng bạn đang triển khai một ứng dụng web ba tầng (web, application, database).

• Cách tiếp cận Azure: Bạn sẽ tạo một Resource Group duy nhất, ví dụ my-webapp-rg. Bên trong Resource Group này, bạn sẽ tạo ra tất cả các tài nguyên cần thiết:
  • Azure App Service cho tầng web.
  • Azure Functions cho tầng application.
  • Azure SQL Database cho tầng database.
  • Virtual Network, Application Gateway,...
• Lợi ích:
  • Quản lý vòng đời: Khi ứng dụng này không còn cần thiết, bạn chỉ cần xóa Resource Group my-webapp-rg, và tất cả các tài nguyên bên trong sẽ được xóa theo. Điều này cực kỳ tiện lợi và tránh tình trạng "tài nguyên mồ côi".
  • Kiểm soát truy cập: Bạn có thể cấp quyền cho một đội phát triển (development team) chỉ được phép thao tác trên các tài nguyên trong Resource Group này.
  • Báo cáo chi phí: Dễ dàng xem chi phí của toàn bộ ứng dụng bằng cách lọc theo Resource Group.

Đây là một sự thay đổi tư duy lớn so với AWS, nơi bạn thường nhóm tài nguyên bằng cách sử dụng tags hoặc đặt chúng trong cùng một VPC.

1.5. Giao diện và Công cụ Quản lý: Azure Portal, Azure CLI, PowerShell, và Azure Cloud Shell

Giống như AWS, Azure cung cấp nhiều cách để tương tác và quản lý tài nguyên.

• Azure Portal (portal.azure.com):

  • Tương quan: AWS Management Console.
  • Mô tả: Giao diện web trực quan, cho phép bạn thực hiện hầu hết mọi tác vụ quản lý. Portal của Azure được đánh giá cao về khả năng tùy biến (customizable dashboards) và tích hợp.

• Azure CLI (Command-Line Interface):

  • Tương quan: AWS CLI.
  • Mô tả: Công cụ dòng lệnh đa nền tảng (Windows, macOS, Linux) để quản lý tài nguyên Azure. Cú pháp của Azure CLI (lệnh bắt đầu bằng az) được thiết kế để dễ học và dễ nhớ.
  • Ví dụ (tạo một Resource Group):

    az group create --name my-webapp-rg --location "East US"

• Azure PowerShell:

  • Tương quan: AWS Tools for PowerShell.
  • Mô tả: Một module PowerShell cung cấp các cmdlet để quản lý tài nguyên Azure. Đây là lựa chọn phổ biến cho những người đã quen thuộc với hệ sinh thái Windows và PowerShell.
  • Ví dụ (tạo một Resource Group):

    New-AzResourceGroup -Name my-webapp-rg -Location "East US"

• Azure Cloud Shell:

  • Tương quan: AWS CloudShell.
  • Mô tả: Một môi trường shell tương tác, dựa trên trình duyệt, được tích hợp sẵn trong Azure Portal. Cloud Shell cho phép bạn lựa chọn giữa Bash (với Azure CLI được cài sẵn) và PowerShell. Nó cũng đi kèm với nhiều công cụ phổ biến khác (git, terraform, kubectl,...). Cloud Shell yêu cầu một Azure Files share để lưu trữ dữ liệu người dùng.

1.6. Azure Resource Manager (ARM): Trái tim của việc Quản lý Tài nguyên

• Tương quan: AWS CloudFormation.

Azure Resource Manager (ARM) là dịch vụ triển khai và quản lý cho Azure. Nó cung cấp một lớp quản lý nhất quán cho phép bạn tạo, cập nhật và xóa tài nguyên trong Azure subscription của mình. Bất kể bạn sử dụng công cụ nào (Portal, CLI, PowerShell), mọi yêu cầu đều đi qua ARM API.

ARM Templates:

• Tương quan: AWS CloudFormation Templates.
• Mô tả: ARM Templates là các tệp JSON (hoặc sử dụng ngôn ngữ Bicep mới hơn, dễ đọc hơn) định nghĩa các tài nguyên bạn muốn triển khai. Đây là cách tiếp cận Infrastructure as Code (IaC) nguyên bản của Azure.
• Các thành phần chính của một ARM Template:
  • $schema: Liên kết đến tệp schema JSON, giúp validation và IntelliSense.
  • contentVersion: Phiên bản của template.
  • parameters: Các giá trị đầu vào để tùy biến việc triển khai (ví dụ: tên máy ảo, kích thước).
  • variables: Các biến được sử dụng bên trong template.
  • resources: Mảng chứa các tài nguyên Azure cần triển khai.
  • outputs: Các giá trị trả về sau khi triển khai thành công (ví dụ: địa chỉ IP công cộng của máy ảo).

So sánh ARM vs. CloudFormation:

Đặc điểm	Azure ARM	AWS CloudFormation
Ngôn ngữ	JSON, Bicep (ngôn ngữ DSL mới, biên dịch ra JSON)	JSON, YAML
Mô hình triển khai	Mặc định là song song (parallel), tăng tốc độ triển khai. Phụ thuộc (dependencies) được định nghĩa rõ ràng.	Mặc định là tuần tự (sequential) dựa trên DependsOn.
Trạng thái (State)	Không trạng thái (Stateless). ARM kiểm tra trạng thái hiện tại của tài nguyên trước khi áp dụng thay đổi.	Có trạng thái (Stateful). CloudFormation quản lý một tệp trạng thái (stack state) để theo dõi các tài nguyên.
Khả năng xem trước	Chế độ "What-if" cho phép xem trước các thay đổi trước khi áp dụng.	Change Sets cung cấp chức năng tương tự.

Bicep - Sự cải tiến của ARM:

Microsoft đã giới thiệu Bicep, một ngôn ngữ Domain-Specific Language (DSL) mới, được thiết kế để đơn giản hóa việc viết mã IaC trên Azure. Bicep có cú pháp rõ ràng, ngắn gọn hơn nhiều so với JSON và cung cấp các tính năng như module hóa, IntelliSense tốt hơn. Mã Bicep được biên dịch (transpile) thành ARM JSON trước khi triển khai.

Ví dụ Bicep (tạo một Storage Account):

param location string = resourceGroup().location
param storageAccountName string = 'mystorage${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

Đây là một sự cải tiến đáng kể so với việc phải viết hàng trăm dòng JSON phức tạp. Nếu bạn bắt đầu với IaC trên Azure, Bicep là con đường được khuyến nghị.

---

Phần 2: Dịch vụ Compute - Chạy ứng dụng của bạn trên Azure

Đây là trái tim của mọi nền tảng đám mây. Hãy cùng xem cách Azure cung cấp các dịch vụ tính toán, từ máy ảo truyền thống đến các nền tảng serverless hiện đại.

2.1. Azure Virtual Machines (VMs): Nền tảng IaaS

• Tương quan trực tiếp: Amazon EC2.

Azure Virtual Machines là dịch vụ Infrastructure as a Service (IaaS) cốt lõi, cho phép bạn tạo và quản lý các máy ảo trong đám mây.

Ánh xạ từ Amazon EC2:

Khái niệm AWS EC2	Khái niệm Azure VM	Ghi chú và So sánh
Instance Types (e.g., t3.micro, m5.large)	VM Sizes (e.g., Standard_B1s, Standard_D2s_v3)	Cả hai đều cung cấp một loạt các kích thước máy ảo được tối ưu hóa cho các mục đích khác nhau (đa dụng, tối ưu cho tính toán, tối ưu cho bộ nhớ, GPU,...). Tên gọi của Azure có cấu trúc hơn: Series_Subfamily`vCPU count[Constraints]\_Version. Ví dụ: Standard_D4s_v3`.
Amazon Machine Image (AMI)	Image	Azure cung cấp các image từ Azure Marketplace (tương tự AWS Marketplace) hoặc bạn có thể tự tạo và quản lý các custom image của riêng mình.
Elastic Block Store (EBS)	Azure Disk Storage	Dịch vụ lưu trữ khối (block storage) được gắn vào máy ảo. Chúng ta sẽ tìm hiểu chi tiết ở Phần 3.
Security Groups	Network Security Groups (NSGs)	Tường lửa trạng thái (stateful firewall) để kiểm soát lưu lượng ra/vào máy ảo. NSG trong Azure có thể được gắn vào cả card mạng (NIC) và subnet.
Elastic IP (EIP)	Public IP Address (Static)	Cung cấp một địa chỉ IP công cộng cố định cho máy ảo của bạn.
User Data	Custom Data	Dùng để chạy các script khởi tạo khi máy ảo được tạo lần đầu tiên.
Auto Scaling Groups	Virtual Machine Scale Sets (VMSS)	Cho phép bạn tự động tăng hoặc giảm số lượng máy ảo dựa trên các chỉ số hiệu suất hoặc lịch trình. VMSS trong Azure tích hợp chặt chẽ với Azure Load Balancer.

Các Series Máy ảo phổ biến trong Azure:

• B-series (Burstable): Tương tự T-series của AWS. Lý tưởng cho các workload có hiệu suất không liên tục, như web server nhỏ, môi trường dev/test. Chúng tích lũy "credits" khi CPU thấp và sử dụng chúng khi cần hiệu suất cao.
• D-series (General Purpose): Tương tự M-series của AWS. Cung cấp sự cân bằng tốt giữa CPU, memory và disk. Phù hợp cho hầu hết các ứng dụng doanh nghiệp.
• E-series (Memory Optimized): Tương tự R-series của AWS. Có tỷ lệ RAM-to-CPU cao, lý tưởng cho các cơ sở dữ liệu trong bộ nhớ (in-memory), ứng dụng phân tích dữ liệu lớn.
• F-series (Compute Optimized): Tương tự C-series của AWS. Có tỷ lệ CPU-to-RAM cao, phù hợp cho các ứng dụng yêu cầu xử lý tính toán chuyên sâu như batch processing, web server có lưu lượng truy cập cao.
• L-series (Storage Optimized): Tương tự I-series và D-series của AWS. Tối ưu cho các workload yêu cầu I/O cao, độ trễ thấp, sử dụng ổ đĩa NVMe cục bộ.
• N-series (GPU Optimized): Tương tự P-series, G-series của AWS. Được trang bị GPU của NVIDIA, dành cho các tác vụ AI, machine learning, và đồ họa chuyên sâu.

Use case thực tế: Triển khai một Web Server (Nginx) trên Azure VM (Ubuntu)

Sử dụng Azure CLI, quá trình này sẽ trông như sau:

1. Tạo Resource Group:

   az group create --name nginx-rg --location "East US"

2. Tạo Máy ảo: Lệnh này sẽ tạo một máy ảo Ubuntu, mở port 80 (HTTP), và tự động tạo các tài nguyên liên quan như VNet, NSG, Public IP. Nó cũng sẽ tự tạo SSH keys cho bạn.

   az vm create \
     --resource-group nginx-rg \
     --name myNginxVM \
     --image UbuntuLTS \
     --admin-username azureuser \
     --generate-ssh-keys \
     --custom-data 'apt-get update && apt-get install -y nginx'
   ```    *   `--custom-data`: Tương đương với User Data trong EC2, dùng để cài đặt Nginx ngay khi máy ảo khởi động.

3. Kiểm tra: Lấy địa chỉ IP công cộng của máy ảo và truy cập bằng trình duyệt.

   az vm show --resource-group nginx-rg --name myNginxVM -d --query publicIps -o tsv

Đây là một ví dụ đơn giản nhưng cho thấy sự tương đồng trong quy trình làm việc so với việc khởi chạy một EC2 instance.

2.2. Azure App Service: Nền tảng PaaS cho ứng dụng Web và API

• Tương quan: AWS Elastic Beanstalk, nhưng tích hợp và mạnh mẽ hơn. Một số use-case đơn giản có thể so sánh với AWS Amplify hoặc thậm chí là Lambda + API Gateway.

Azure App Service là một dịch vụ PaaS được quản lý hoàn toàn, được thiết kế để xây dựng, triển khai và mở rộng quy mô các ứng dụng web, ứng dụng di động back-end, và API. Đây là một trong những dịch vụ phổ biến và được yêu thích nhất của Azure.

Các tính năng nổi bật:

• Hỗ trợ đa ngôn ngữ và framework: .NET, .NET Core, Java, Ruby, Node.js, PHP, Python. Bạn cũng có thể chạy các ứng dụng được đóng gói trong container (Web App for Containers).
• Tích hợp CI/CD: Tích hợp sâu với Azure DevOps, GitHub, Bitbucket, cho phép bạn thiết lập các quy trình CI/CD một cách dễ dàng.
• Mở rộng quy mô (Scaling): Hỗ trợ cả scale-up (tăng sức mạnh của máy chủ) và scale-out (tăng số lượng máy chủ) một cách tự động hoặc thủ công.
• Deployment Slots: Một tính năng cực kỳ mạnh mẽ, cho phép bạn triển khai phiên bản mới của ứng dụng vào một môi trường "staging" (slot). Sau khi kiểm tra, bạn có thể "swap" slot này với slot "production" một cách nhanh chóng và không có downtime. Nếu có lỗi, bạn có thể swap ngược lại. AWS Elastic Beanstalk cũng có tính năng tương tự (blue/green deployment) nhưng cách thực hiện của App Service được đánh giá là trực quan và dễ sử dụng hơn.
• Bảo mật và Tuân thủ: Tích hợp với Azure AD, hỗ trợ custom domains và SSL, VNet integration, Private Endpoints.
• App Service Plan: Đây là khái niệm cốt lõi. Một App Service Plan định nghĩa một tập hợp các tài nguyên tính toán (Region, số lượng máy ảo, kích thước máy ảo, SKU) để chạy các ứng dụng App Service của bạn. Bạn trả tiền cho App Service Plan, không phải cho từng ứng dụng riêng lẻ. Nhiều ứng dụng có thể chạy trên cùng một App Service Plan. Điều này tương tự như cách bạn có thể chạy nhiều ứng dụng trên cùng một môi trường Elastic Beanstalk.

So sánh App Service vs. Elastic Beanstalk:

Tính năng	Azure App Service	AWS Elastic Beanstalk
Mức độ quản lý	PaaS hoàn chỉnh. Bạn gần như không cần quan tâm đến OS bên dưới.	PaaS, nhưng bạn vẫn có thể truy cập (SSH) vào các EC2 instances bên dưới để tùy chỉnh sâu hơn.
Blue/Green Deployment	Deployment Slots - tích hợp sẵn, dễ sử dụng, swap nhanh chóng.	Môi trường có thể clone. Quá trình swap thường liên quan đến việc thay đổi CNAME của DNS, có thể mất nhiều thời gian hơn.
Tích hợp	Tích hợp sâu với hệ sinh thái Azure và Microsoft (Azure DevOps, GitHub Actions, Visual Studio).	Tích hợp tốt với hệ sinh thái AWS.
Mô hình chi phí	Dựa trên App Service Plan (tài nguyên tính toán được cấp phát trước). Có cả tầng Free và Shared.	Dựa trên các tài nguyên AWS mà nó tạo ra (EC2, S3, ELB,...).

Use case thực tế: Triển khai một ứng dụng Node.js lên App Service với CI/CD từ GitHub Actions

1. Chuẩn bị mã nguồn: Một ứng dụng Express.js đơn giản trên GitHub.
2. Tạo App Service:
   • Vào Azure Portal, tạo một "Web App".
   • Chọn "Code" làm phương thức publish, chọn "Node.js" làm runtime stack.
   • Tạo một App Service Plan mới (ví dụ, SKU là B1 - Basic).
3. Cấu hình CI/CD:
   • Trong App Service, vào mục "Deployment Center".
   • Chọn GitHub làm nguồn.
   • Ủy quyền cho Azure truy cập vào repository của bạn.
   • Azure sẽ tự động phát hiện đây là một ứng dụng Node.js và đề xuất một file workflow cho GitHub Actions.
   • Commit file workflow này vào repository.
4. Kết quả:
   • Ngay lập tức, một GitHub Action sẽ được kích hoạt, build ứng dụng của bạn và triển khai lên App Service.
   • Mỗi khi bạn git push lên nhánh main, GitHub Action sẽ tự động build và triển khai phiên bản mới. Quá trình này hoàn toàn tự động và liền mạch.

Đây là một ví dụ điển hình cho thấy sức mạnh của các giải pháp hướng PaaS của Azure, giúp nhà phát triển tập trung vào việc viết mã thay vì quản lý hạ tầng. Tuyệt vời, chúng ta sẽ tiếp tục xây dựng bộ tài liệu chuyên sâu này.

---

Phần 2: Dịch vụ Compute - Chạy ứng dụng của bạn trên Azure (Tiếp theo)

2.3. Azure Functions: Điện toán Serverless

• Tương quan trực tiếp: AWS Lambda.

Azure Functions là giải pháp điện toán hướng sự kiện (event-driven) và không máy chủ (serverless) của Azure. Nó cho phép bạn chạy các đoạn mã nhỏ (gọi là "functions") để phản hồi lại các sự kiện mà không cần phải cung cấp hay quản lý hạ tầng.

So sánh Trực tiếp và Ánh xạ Khái niệm:

Khái niệm AWS Lambda	Khái niệm Azure Functions	Ghi chú và So sánh
Lambda Function	Function / Function App	Đây là một điểm khác biệt quan trọng. Trong Azure, bạn tạo một Function App, đây là tài nguyên chính. Function App đóng vai trò là một container, một đơn vị triển khai và mở rộng quy mô, chứa một hoặc nhiều Functions. Mỗi function bên trong sẽ có một trigger và mã thực thi riêng.
Event Source / Trigger	Trigger	Tương tự nhau. Một trigger định nghĩa cách một function được gọi. Azure Functions hỗ-trợ một danh sách trigger rất phong phú: HTTP, Timer, Queue Storage, Blob Storage, Service Bus, Event Hub, Cosmos DB, và nhiều hơn nữa.
Lambda Execution Role (IAM Role)	Managed Identity / App Settings	Để một function tương tác với các dịch vụ Azure khác (ví dụ: đọc từ Blob Storage), bạn nên sử dụng Managed Identity. Đây là tương đương của IAM Role for EC2/Lambda, cung cấp một định danh cho Function App trong Azure AD để xác thực với các dịch vụ khác mà không cần lưu trữ credentials trong code.
Lambda Layers	(Không có tương đương 1:1)	AWS Lambda Layers cho phép bạn đóng gói thư viện và các dependencies khác để chia sẻ giữa nhiều functions. Trong Azure Functions, việc quản lý dependency thường được thực hiện thông qua các công cụ quản lý gói tiêu chuẩn của ngôn ngữ (ví dụ: requirements.txt cho Python, package.json cho Node.js).
Deployment Package (.zip)	Deployment Methods (Zip Deploy, Git, etc.)	Tương tự, bạn có thể triển khai code của mình dưới dạng một file zip. Azure cũng hỗ trợ triển khai trực tiếp từ Git, Visual Studio Code, và các quy trình CI/CD.

Sức mạnh của Triggers và Bindings:

Đây là tính năng nổi bật và là một trong những điểm mạnh nhất của Azure Functions.

• Triggers: Như đã đề cập, đây là thứ kích hoạt function của bạn. Mỗi function chỉ có đúng một trigger.
• Bindings (Input & Output): Đây là cách khai báo để kết nối với các dịch vụ khác mà không cần viết mã kết nối (boilerplate code). Một function có thể có nhiều input và output bindings.
  • Input Binding: Cung cấp dữ liệu vào function của bạn dưới dạng tham số. Ví dụ, bạn có một HTTP trigger, bạn có thể thêm một input binding từ Azure Table Storage để tự động lấy một bản ghi dựa trên một tham số trong URL.
  • Output Binding: Cho phép bạn gửi dữ liệu ra từ function một cách dễ dàng. Ví dụ, sau khi xử lý một tin nhắn từ Queue, bạn có thể dùng output binding để ghi kết quả vào một Blob khác hoặc gửi một tin nhắn đến một Queue khác, chỉ bằng cách trả về một giá trị từ function.

Việc sử dụng bindings giúp mã của bạn gọn gàng, sạch sẽ và tập trung hoàn toàn vào logic nghiệp vụ, thay vì phải viết mã để khởi tạo SDK, kết nối, và xử lý lỗi cho các dịch vụ khác.

Các mô hình Hosting Plan:

Đây là một điểm khác biệt lớn so với AWS Lambda, vốn chỉ có một mô hình định giá.

1. Consumption Plan (Gói Tiêu thụ):

   • Tương đương Lambda: Đây là mô hình serverless thực thụ.
   • Cách hoạt động: Bạn chỉ trả tiền khi code của bạn thực sự chạy. Azure sẽ tự động cung cấp và mở rộng quy mô tài nguyên tính toán dựa trên số lượng sự kiện đến.
   • Nhược điểm: Có thể gặp phải "cold starts" (khởi động nguội) - độ trễ khi function của bạn được gọi lần đầu tiên sau một thời gian không hoạt động.

2. Premium Plan (Gói Cao cấp):

   • Tương đương Lambda Provisioned Concurrency: Giải quyết vấn đề cold starts.
   • Cách hoạt động: Bạn cung cấp trước một số lượng "pre-warmed instances" (các máy chủ luôn sẵn sàng). Các máy chủ này không bao giờ tắt, giúp loại bỏ độ trễ cold start. Kế hoạch này cũng cung cấp các tính năng cao cấp hơn như tích hợp VNet.
   • Chi phí: Bạn trả phí theo giờ cho các pre-warmed instances, cộng với phí tiêu thụ khi quy mô vượt quá số lượng đã cung cấp.

3. Dedicated (App Service) Plan (Gói Chuyên dụng):

   • Cách hoạt động: Chạy Functions của bạn trên cùng một App Service Plan mà bạn có thể đang sử dụng cho các ứng dụng web.
   • Use-case: Phù hợp cho các kịch bản có tải trọng liên tục, dự đoán được, hoặc khi bạn muốn tận dụng một App Service Plan hiện có mà chưa sử dụng hết công suất.

Use case thực tế: Xử lý ảnh được tải lên Blob Storage một cách tự động

Đây là một kịch bản serverless kinh điển.

• Mục tiêu: Khi một người dùng tải một ảnh vào container images-original, tự động tạo một phiên bản thumbnail và lưu nó vào container images-thumbnails.
• Thiết lập:
  1. Tạo một Storage Account với hai container: images-original và images-thumbnails.
  2. Tạo một Function App (sử dụng Consumption Plan).
  3. Bên trong Function App, tạo một Function mới với cấu hình sau:
     • Trigger: Azure Blob Storage trigger.
     • Path: images-original/{name} (trigger sẽ kích hoạt khi có blob mới trong container này, và {name} sẽ là tên của file).
     • Input Binding: Function sẽ tự động nhận nội dung của blob vừa được tải lên dưới dạng một tham số đầu vào (ví dụ: inputBlob).
     • Output Binding: Azure Blob Storage output binding.
     • Path: images-thumbnails/thumb-{name} (định nghĩa nơi để ghi kết quả đầu ra).
• Mã (ví dụ bằng Python):

  import logging
  from PIL import Image
  import io
  
  def main(inputBlob: bytes, outputBlob: func.Out[bytes]):
      logging.info(f"Python blob trigger function processed blob")
  
      # Sử dụng thư viện Pillow để tạo thumbnail
      image = Image.open(io.BytesIO(inputBlob))
      image.thumbnail((128, 128))
  
      # Lưu thumbnail vào một buffer
      buf = io.BytesIO()
      image.save(buf, format='JPEG')
      
      # Gán buffer vào output binding, Azure sẽ tự động ghi ra blob
      outputBlob.set(buf.getvalue())
  ```*   **Điều kỳ diệu ở đây là gì?** Bạn không cần viết bất kỳ dòng mã nào sử dụng Azure Storage SDK. Bạn không cần khởi tạo client, không cần xử lý chuỗi kết nối. Bạn chỉ cần khai báo "khi có blob ở đây, tôi muốn ghi kết quả ra kia" thông qua cấu hình trigger và binding. Function của bạn chỉ tập trung vào việc xử lý ảnh.

2.4. Azure Kubernetes Service (AKS): Dịch vụ Kubernetes được quản lý

• Tương quan trực tiếp: Amazon Elastic Kubernetes Service (EKS).

AKS là dịch vụ của Azure giúp bạn đơn giản hóa việc triển khai, quản lý và vận hành các cụm Kubernetes.

So sánh AKS vs. EKS:

Đặc điểm	Azure Kubernetes Service (AKS)	Amazon Elastic Kubernetes Service (EKS)
Control Plane	Miễn phí. Microsoft tài trợ cho control plane (master nodes). Bạn chỉ trả tiền cho các worker nodes (Azure VMs) và các tài nguyên khác (load balancer, storage).	Có tính phí. Bạn trả một khoản phí theo giờ cho mỗi cụm EKS để vận hành control plane.
Nâng cấp (Upgrades)	Có thể thực hiện nâng cấp control plane và node pools thông qua Azure Portal hoặc CLI với vài cú nhấp chuột/lệnh. Hỗ trợ tự động nâng cấp.	Tương tự, hỗ trợ nâng cấp được quản lý. Quá trình này có thể được thực hiện thông qua AWS Console, CLI, hoặc các công cụ IaC.
Node Pools	Rất linh hoạt. Hỗ trợ nhiều node pools trong một cụm, cho phép bạn có các loại máy ảo khác nhau (ví dụ: GPU nodes, general purpose nodes) cho các workload khác nhau. Hỗ trợ cả Linux và Windows nodes.	Cũng hỗ trợ Managed Node Groups và Fargate Profiles, cho phép có nhiều loại nodes khác nhau.
Tích hợp Định danh	Tích hợp sâu và mượt mà với Azure Active Directory (Azure AD). Bạn có thể sử dụng Azure AD để quản lý quyền truy cập vào Kubernetes API (sử dụng RBAC của Kubernetes).	Tích hợp với AWS IAM. Việc ánh xạ người dùng/vai trò IAM vào Kubernetes RBAC đòi hỏi cấu hình trong aws-auth ConfigMap.
Ảo hóa Nodes	Virtual Nodes (dựa trên dự án mã nguồn mở Virtual Kubelet). Cho phép bạn chạy các pods trên Azure Container Instances (ACI), cung cấp khả năng "bursting" serverless mà không cần quản lý các VM nodes.	AWS Fargate Profiles. Cho phép bạn chạy các pods trên Fargate. Bạn định nghĩa các Fargate profiles để xác định pods nào (dựa trên namespace và labels) sẽ chạy trên Fargate.
Networking (CNI)	Hai lựa chọn chính: kubenet (cơ bản) và Azure CNI (cao cấp hơn, mỗi pod có một IP riêng trên VNet, cho phép tích hợp sâu hơn với các dịch vụ Azure khác).	Sử dụng Amazon VPC CNI plugin theo mặc định. Mỗi pod cũng nhận một địa chỉ IP từ VPC.

Use case thực tế: Triển khai một ứng dụng microservices trên AKS

• Mục tiêu: Triển khai một ứng dụng bán lẻ đơn giản gồm 3 microservices: product-api, order-api, và frontend-web.
• Các bước chính:
  1. Đóng gói ứng dụng: Containerize mỗi microservice bằng Docker.
  2. Đẩy images: Đẩy các Docker images lên một container registry. Azure Container Registry (ACR) là tương đương của Amazon Elastic Container Registry (ECR).
  3. Tạo cụm AKS: Sử dụng Azure CLI để tạo một cụm AKS.

     # Tạo Resource Group
     az group create --name my-aks-rg --location "East US"
     
     # Tạo cụm AKS (ví dụ: 2 nodes) và tích hợp với ACR
     az aks create \
       --resource-group my-aks-rg \
       --name myAKSCluster \
       --node-count 2 \
       --enable-managed-identity \
       --attach-acr <your-acr-name> \
       --generate-ssh-keys

  4. Kết nối với cụm:

     az aks get-credentials --resource-group my-aks-rg --name myAKSCluster

     Lệnh này sẽ cấu hình kubectl để kết nối đến cụm AKS của bạn.
  5. Triển khai:
     • Tạo các file manifest YAML cho Kubernetes (Deployment, Service) cho mỗi microservice.
     • Trong file Deployment của frontend-web, bạn sẽ tạo một Service có type: LoadBalancer.
     • Khi bạn áp dụng file manifest này (kubectl apply -f frontend-service.yaml), AKS sẽ tự động tạo một Azure Load Balancer công cộng và gán cho nó một địa chỉ IP.
  6. Kết quả: Bạn có thể truy cập ứng dụng của mình thông qua địa chỉ IP công cộng của Azure Load Balancer. Các microservices bên trong cụm sẽ giao tiếp với nhau thông qua các tên service Kubernetes DNS nội bộ.

Sự tích hợp chặt chẽ của AKS với các dịch vụ Azure khác như Azure AD, ACR, Azure Monitor, và Azure Disks làm cho nó trở thành một lựa chọn rất mạnh mẽ để chạy các ứng dụng container hóa trên Azure.

2.5. Azure Container Instances (ACI): Chạy container đơn lẻ không cần máy chủ

• Tương quan: AWS Fargate (đặc biệt cho các tác vụ đơn lẻ, không phải là một phần của cụm EKS).

ACI là cách nhanh nhất và đơn giản nhất để chạy một container trên Azure. Bạn không cần phải quản lý bất kỳ máy ảo hay hạ tầng phức tạp nào. ACI là một dịch vụ "container-as-a-service".

Khi nào nên dùng ACI?

• Các tác vụ đơn giản: Chạy các tác vụ build trong quy trình CI/CD.
• Xử lý dữ liệu theo lô: Các công việc ETL đơn giản, xử lý hàng đợi.
• Phát triển và Thử nghiệm: Nhanh chóng khởi chạy một ứng dụng để kiểm tra mà không cần một cụm Kubernetes đầy đủ.
• "Bursting" từ AKS: Như đã đề cập ở trên, sử dụng Virtual Nodes để mở rộng quy mô AKS ra ACI một cách liền mạch khi có tải trọng đột biến.

So sánh ACI vs. Fargate:

• Mô hình: Cả hai đều là serverless container platforms.
• Đơn vị triển khai: Trong ACI, đơn vị cơ bản là một Container Group, có thể chứa một hoặc nhiều container chia sẻ cùng một host, mạng, và storage. Điều này tương tự như một Pod trong Kubernetes.
• Định giá: Cả hai đều tính phí dựa trên vCPU và bộ nhớ được yêu cầu cho container của bạn, tính theo giây. ACI có một mô hình định giá rất chi tiết và minh bạch.
• Tích hợp: Fargate tích hợp chặt chẽ với EKS và ECS. ACI là một dịch vụ độc lập nhưng cũng có thể tích hợp với AKS thông qua Virtual Nodes.

Use case thực tế: Chạy một tác vụ xử lý dữ liệu theo lô (batch processing)

• Kịch bản: Hàng đêm, bạn cần chạy một script Python để đọc dữ liệu từ một file CSV trong Azure Blob Storage, xử lý nó, và ghi kết quả vào Azure SQL Database.
• Giải pháp với ACI:
  1. Đóng gói script: Tạo một Docker image chứa script Python và các dependencies cần thiết (ví dụ: pandas, pyodbc).
  2. Đẩy image: Đẩy image lên Azure Container Registry (ACR).
  3. Tạo ACI: Thay vì chạy script thủ công hoặc trên một VM, bạn có thể tạo một Azure Container Instance để chạy tác vụ này. Bạn có thể định nghĩa các biến môi trường (environment variables) để truyền chuỗi kết nối cơ sở dữ liệu và các thông tin khác một cách an toàn.

     az container create \
       --resource-group my-batch-rg \
       --name my-batch-job \
       --image <your-acr-name>.azurecr.io/batch-processor:v1 \
       --cpu 1 \
       --memory 1.5 \
       --restart-policy OnFailure \
       --environment-variables 'DB_CONNECTION_STRING'=<your_conn_string>

  4. Tự động hóa: Bạn có thể sử dụng Azure Logic Apps hoặc Azure Data Factory để lên lịch chạy lệnh az container create này vào mỗi đêm. restart-policy OnFailure đảm bảo container sẽ không tự động khởi động lại sau khi hoàn thành công việc thành công.
• Lợi ích:
  • Hiệu quả chi phí: Bạn chỉ trả tiền cho vài phút mà container chạy mỗi đêm.
  • Không cần quản lý: Không có VM để vá lỗi, không có OS để bảo trì.
  • Đơn giản: Một lệnh duy nhất để khởi chạy tác vụ của bạn.

---

Phần 3: Dịch vụ Lưu trữ (Storage) - Lưu trữ dữ liệu của bạn một cách an toàn và hiệu quả

Dịch vụ lưu trữ của Azure rất toàn diện và có thể được ánh xạ gần như 1:1 với các dịch vụ của AWS. Đơn vị trung tâm là Azure Storage Account. Không giống như AWS, nơi S3, EBS, EFS là các dịch vụ hoàn toàn riêng biệt, trong Azure, khi bạn tạo một Storage Account, nó đóng vai trò là một không gian tên (namespace) duy nhất để bạn có thể sử dụng các dịch vụ lưu trữ khác nhau bên trong nó: Blobs, Files, Queues, và Tables.

3.1. Azure Blob Storage: Lưu trữ đối tượng (Object Storage)

• Tương quan trực tiếp: Amazon S3 (Simple Storage Service).

Blob Storage được tối ưu hóa để lưu trữ một lượng lớn dữ liệu phi cấu trúc, chẳng hạn như văn bản hoặc dữ liệu nhị phân.

Ánh xạ từ Amazon S3:

Khái niệm AWS S3	Khái niệm Azure Blob Storage	Ghi chú và So sánh
Bucket	Container	Một container trong Blob Storage là một cách để nhóm một tập hợp các blobs. Tên bucket của S3 là duy nhất trên toàn cầu, trong khi tên container chỉ cần là duy nhất trong phạm vi Storage Account.
Object	Blob	Là đối tượng mà bạn lưu trữ. Azure có 3 loại blob: Block Blobs (tối ưu cho streaming và lưu trữ các đối tượng lớn, tương tự object S3 thông thường), Append Blobs (tối ưu cho các hoạt động ghi nối tiếp, như logging), và Page Blobs (dùng để lưu trữ các tệp VHD cho Azure VMs, nền tảng của Azure Disk Storage).
Storage Classes (Standard, IA, Glacier)	Access Tiers (Hot, Cool, Archive)	Cả hai đều cung cấp các tầng lưu trữ khác nhau để tối ưu hóa chi phí dựa trên tần suất truy cập. Hot (tương đương S3 Standard) cho dữ liệu truy cập thường xuyên. Cool (tương đương S3 Infrequent Access) cho dữ liệu ít truy cập nhưng cần có sẵn ngay lập tức. Archive (tương đương S3 Glacier/Glacier Deep Archive) cho dữ liệu lưu trữ dài hạn với chi phí thấp nhất nhưng có độ trễ khi truy xuất.
S3 Lifecycle Policies	Lifecycle Management Policies	Cho phép bạn tự động chuyển blobs giữa các tầng lưu trữ (ví dụ: chuyển dữ liệu từ Hot sang Cool sau 30 ngày, và sang Archive sau 180 ngày) hoặc xóa blobs sau một khoảng thời gian nhất định.
S3 Object Lock / Versioning	Immutability Policies / Versioning for blobs	Cung cấp các tính năng tương tự để bảo vệ dữ liệu khỏi bị ghi đè hoặc xóa (WORM - Write Once, Read Many) và để duy trì các phiên bản trước đó của một blob.

Use case thực tế: Lưu trữ hình ảnh, video và các tài sản tĩnh cho một trang web

Đây là use-case phổ biến nhất cho lưu trữ đối tượng.

• Kịch bản: Một ứng dụng web (ví dụ chạy trên Azure App Service) cho phép người dùng tải lên ảnh đại diện và xem các video hướng dẫn.
• Giải pháp:
  1. Tạo một Azure Storage Account.
  2. Bên trong, tạo một container tên là static-assets và thiết lập quyền truy cập công cộng (public access) cho container này.
  3. Khi người dùng tải lên ảnh đại diện, ứng dụng của bạn sẽ sử dụng Azure Storage SDK để tải tệp đó lên container static-assets.
  4. URL của tệp đó sẽ là: https://<storage_account_name>.blob.core.windows.net/static-assets/<file_name.jpg>.
  5. Trong mã HTML của trang web, bạn sẽ trỏ các thẻ <img> và <video> đến các URL này.
  6. Tối ưu hóa: Để tăng tốc độ phân phối nội dung trên toàn cầu và giảm tải cho Storage Account, bạn nên đặt một Azure CDN (sẽ nói ở Phần 4) phía trước Blob Storage.

3.2. Azure Disk Storage: Lưu trữ khối (Block Storage) cho Máy ảo

• Tương quan trực tiếp: Amazon EBS (Elastic Block Store).

Azure Disk Storage cung cấp các ổ đĩa hiệu suất cao, bền bỉ cho các máy ảo Azure.

So sánh các loại đĩa:

Loại đĩa AWS EBS	Loại đĩa Azure Disk	Đặc điểm và Use-case
General Purpose SSD (gp2, gp3)	Standard SSD / Premium SSD	Standard SSD: Cân bằng giữa chi phí và hiệu suất, phù hợp cho web servers, các ứng dụng doanh nghiệp ít quan trọng, môi trường dev/test. Premium SSD: Hiệu suất cao, độ trễ thấp, dựa trên SSD, phù hợp cho các workload sản xuất và các cơ sở dữ liệu như SQL Server, Oracle.
Provisioned IOPS SSD (io1, io2)	Premium SSD / Ultra Disk	Ultra Disk: Cung cấp IOPS và thông lượng cực cao với độ trễ dưới mili giây. Đây là loại đĩa hiệu suất cao nhất của Azure, lý tưởng cho các cơ sở dữ liệu quan trọng nhất như SAP HANA. Bạn có thể thay đổi IOPS và thông lượng một cách linh hoạt mà không cần khởi động lại VM.
Throughput Optimized HDD (st1)	Standard HDD	Dựa trên đĩa từ (magnetic drives), chi phí thấp nhất, phù hợp cho các workload cần thông lượng cao nhưng không nhạy cảm với IOPS, như Big Data, Data Warehousing, và các máy chủ file.
Cold HDD (sc1)	Standard HDD	Azure không phân biệt rõ ràng giữa "throughput" và "cold" HDD như AWS. Standard HDD phục vụ cho cả hai mục đích này.

Các khái niệm quan trọng:

• Managed Disks: Đây là mô hình được khuyến nghị. Với Managed Disks, bạn chỉ cần chọn loại đĩa (Standard/Premium/Ultra) và kích thước, Azure sẽ tự động quản lý Storage Account bên dưới. Điều này đơn giản hóa việc quản lý và tăng cường khả năng phục hồi. Đây là mặc định và tương tự như cách EBS hoạt động.
• OS Disk: Mỗi máy ảo có một OS disk chứa hệ điều hành.
• Data Disks: Bạn có thể gắn thêm nhiều data disks vào một máy ảo để lưu trữ dữ liệu ứng dụng.
• Snapshots: Tạo một bản sao lưu tại một thời điểm (point-in-time backup) của một ổ đĩa.
• Shared Disks: Một tính năng của Premium SSD và Ultra Disk cho phép bạn gắn cùng một ổ đĩa vào nhiều máy ảo, hữu ích cho các ứng dụng cluster như SQL Server Failover Cluster.

Use case thực tế: Cấu hình đĩa cho một máy chủ cơ sở dữ liệu trên Azure VM

• Kịch bản: Triển khai một máy chủ SQL Server quan trọng trên một Azure VM. Yêu cầu hiệu suất cao cho các tệp dữ liệu (data files) và nhật ký (log files), và chi phí hợp lý cho sao lưu.
• Cấu hình tối ưu:
  • VM Size: Chọn một VM size hỗ trợ Premium Storage (ví dụ: D-series, E-series).
  • OS Disk: Một Premium SSD nhỏ (P10) là đủ.
  • Data Disk (cho tệp .mdf, .ndf): Một hoặc nhiều Premium SSD (P30, P40) được gộp lại với nhau bằng Storage Spaces trong Windows Server để tăng IOPS và thông lượng.
  • Log Disk (cho tệp .ldf): Một Premium SSD hoặc Ultra Disk riêng biệt. Các tệp nhật ký yêu cầu độ trễ ghi rất thấp, vì vậy việc tách chúng ra một ổ đĩa riêng là một thực hành tốt nhất.
  • TempDB Disk: Đặt TempDB trên ổ đĩa tạm thời (temporary disk - ổ D:) đi kèm với hầu hết các VM của Azure. Ổ đĩa này dựa trên SSD cục bộ, cung cấp hiệu suất rất cao và không tính phí, nhưng dữ liệu trên đó sẽ bị mất khi VM khởi động lại hoặc di chuyển host. Điều này hoàn toàn phù hợp với bản chất của TempDB.
  • Backup Disk: Một Standard HDD lớn để lưu các bản sao lưu cơ sở dữ liệu với chi phí thấp.

3.3. Azure Files: Dịch vụ chia sẻ tệp được quản lý (Managed File Share)

• Tương quan: Amazon EFS (Elastic File System) và Amazon FSx.

Azure Files cung cấp các chia sẻ tệp (file shares) được quản lý hoàn toàn trên đám mây, có thể truy cập thông qua giao thức Server Message Block (SMB) và Network File System (NFS).

So sánh Azure Files với EFS và FSx:

• Azure Files vs. EFS:
  • Giao thức: Azure Files hỗ trợ cả SMB (native cho Windows) và NFS (native cho Linux). EFS chủ yếu là NFS.
  • Use-case: EFS rất phổ biến cho các ứng dụng Linux cần một hệ thống tệp chia sẻ. Azure Files có thế mạnh đặc biệt trong các môi trường Windows và hybrid, nơi bạn muốn "lift-and-shift" các máy chủ tệp (file servers) lên đám mây hoặc chia sẻ tệp giữa on-premises và Azure VMs.
• Azure Files vs. FSx:
  • Tương đồng: FSx for Windows File Server rất giống với Azure Files về mặt chức năng (hỗ trợ SMB, tích hợp Active Directory).
  • Khác biệt: FSx cung cấp các hệ thống tệp của bên thứ ba được quản lý (Windows File Server, Lustre, NetApp ONTAP), trong khi Azure Files là một dịch vụ do Azure tự phát triển.

Tính năng nổi bật của Azure Files:

• Azure File Sync: Một tính năng tuyệt vời cho các kịch bản hybrid. Nó cho phép bạn đồng bộ hóa các tệp giữa Azure Files và các máy chủ Windows Server on-premises. Các tệp ít được truy cập có thể được lưu trữ hoàn toàn trên đám mây (cloud tiering), giải phóng dung lượng đĩa cục bộ, trong khi vẫn duy trì một bộ cache các tệp được truy cập thường xuyên tại chỗ để có hiệu suất nhanh.
• Tích hợp Active Directory: Hỗ trợ xác thực với cả Active Directory Domain Services (AD DS) on-premises và Azure AD Domain Services, cho phép bạn duy trì các quyền truy cập NTFS hiện có.

Use case thực tế: Chia sẻ tệp giữa nhiều máy ảo trong một môi trường hybrid

• Kịch bản: Một công ty có một ứng dụng kế toán chạy trên nhiều máy chủ Windows on-premises. Ứng dụng này cần truy cập vào một kho lưu trữ tài liệu chung. Công ty muốn mở rộng ứng dụng này lên các máy ảo Azure và cần các máy ảo này cũng truy cập vào cùng một kho tài liệu.
• Giải pháp với Azure Files và File Sync:
  1. Tạo một Azure Files share.
  2. Trên một máy chủ tệp Windows Server on-premises, cài đặt agent của Azure File Sync.
  3. Cấu hình File Sync để đồng bộ hóa thư mục chứa tài liệu kế toán với Azure Files share. Bật tính năng cloud tiering để chỉ giữ lại 20% dữ liệu được truy cập gần đây nhất trên máy chủ cục bộ.
  4. Trên các máy ảo Azure, mount Azure Files share trực tiếp bằng cách sử dụng giao thức SMB.
• Kết quả:
  • Cả máy chủ on-premises và máy ảo Azure đều có thể truy cập và sửa đổi cùng một tập hợp tệp.
  • Dữ liệu được tập trung hóa trên Azure Files, đơn giản hóa việc sao lưu và phục hồi sau thảm họa.
  • Máy chủ on-premises tiết kiệm được dung lượng đĩa đáng kể nhờ cloud tiering.

---

Phần 4: Mạng và Phân phối Nội dung (Networking & Content Delivery)

Kiến thức về mạng trong AWS VPC sẽ giúp bạn chuyển đổi sang Azure VNet một cách dễ dàng, vì các khái niệm cốt lõi rất tương đồng. Tuy nhiên, có những khác biệt tinh tế trong cách triển khai và tên gọi của các dịch vụ.

4.1. Azure Virtual Network (VNet): Nền tảng mạng ảo của bạn

• Tương quan trực tiếp: Amazon VPC (Virtual Private Cloud).

VNet là khối xây dựng cơ bản cho mạng riêng của bạn trong Azure. Nó cho phép nhiều loại tài nguyên Azure, chẳng hạn như Azure Virtual Machines (VM), giao tiếp an toàn với nhau, với internet và với các mạng on-premises.

Ánh xạ từ Amazon VPC:

Khái niệm AWS VPC	Khái niệm Azure VNet	Ghi chú và So sánh
VPC	Virtual Network (VNet)	Cả hai đều cung cấp một không gian địa chỉ IP riêng, bị cô lập trong đám mây. Bạn định nghĩa dải địa chỉ CIDR của riêng mình.
Subnet	Subnet	Tương đương trực tiếp. Bạn chia VNet của mình thành một hoặc nhiều subnet. Mỗi subnet phải nằm trong dải địa chỉ của VNet. Tài nguyên Azure được triển khai vào các subnet cụ thể.
Security Group	Network Security Group (NSG)	Tường lửa trạng thái (stateful firewall) để kiểm soát lưu lượng truy cập. Một điểm khác biệt quan trọng: Security Groups trong AWS được gắn vào tài nguyên (ENI/EC2 instance), trong khi NSGs trong Azure có thể được gắn vào cả card mạng (NIC) và toàn bộ Subnet. Việc gắn vào Subnet giúp đơn giản hóa việc quản lý các quy tắc chung cho nhiều tài nguyên.
Network ACL (NACL)	Network Security Group (NSG)	Azure không có khái niệm riêng biệt tương đương với NACL (tường lửa không trạng thái - stateless). NSG của Azure thực hiện cả hai vai trò này nhưng hoạt động theo kiểu trạng thái (stateful) giống Security Group. Để có chức năng tường lửa nâng cao hơn, bạn sẽ sử dụng Azure Firewall.
Route Table	Route Table	Tương đương trực tiếp. Mỗi subnet được liên kết với một route table để xác định lưu lượng truy cập mạng được định tuyến đi đâu. Azure tự động tạo các "system routes" để cho phép giao tiếp trong VNet, ra internet, và giữa các VNet được peering. Bạn có thể tạo User-Defined Routes (UDRs) để ghi đè các tuyến đường mặc định này.
Internet Gateway (IGW)	(Tích hợp sẵn)	Azure đơn giản hóa điều này. Theo mặc định, tất cả tài nguyên trong một VNet đều có thể truy cập ra internet. Bạn không cần phải tạo và gắn một Internet Gateway. Để chặn truy cập internet, bạn sẽ sử dụng NSG hoặc UDR.
NAT Gateway	NAT Gateway	Tương đương trực tiếp. Cung cấp kết nối internet đi (outbound) cho các máy ảo trong subnet riêng tư mà không để lộ chúng qua các kết nối đến (inbound).
VPC Peering	VNet Peering	Tương đương trực tiếp. Cho phép bạn kết nối hai VNet một cách riêng tư, làm cho chúng hoạt động như một mạng duy nhất cho mục đích kết nối. Hỗ trợ cả peering trong cùng một region (VNet Peering) và giữa các region khác nhau (Global VNet Peering).
VPC Endpoint	Private Endpoint / Service Endpoint	Đây là một điểm khác biệt quan trọng. Cả hai đều cho phép truy cập riêng tư vào các dịch vụ PaaS của Azure (như Storage, SQL DB) từ VNet của bạn mà không cần đi qua internet. Service Endpoint giữ lưu lượng truy cập trên mạng backbone của Microsoft nhưng vẫn kết nối đến public endpoint của dịch vụ. Private Endpoint (tương tự VPC Interface Endpoint) tạo một card mạng (NIC) riêng trong VNet của bạn, gán cho nó một địa chỉ IP riêng từ VNet, và ánh xạ nó đến dịch vụ PaaS. Private Endpoint được coi là giải pháp an toàn và linh hoạt hơn.

Use case thực tế: Thiết kế một kiến trúc mạng an toàn cho một ứng dụng đa tầng

• Kịch bản: Triển khai một ứng dụng web 3 tầng (Web, App, Data) với yêu cầu bảo mật cao.
• Thiết kế:
  1. Tạo một VNet: Ví dụ, với dải địa chỉ 10.0.0.0/16.
  2. Tạo ba Subnets:
     • web-subnet (10.0.1.0/24)
     • app-subnet (10.0.2.0/24)
     • data-subnet (10.0.3.0/24)
  3. Cấu hình Network Security Groups (NSGs):
     • web-nsg (gắn vào web-subnet):
       • Inbound: Cho phép traffic trên port 80 (HTTP) và 443 (HTTPS) từ Any (Internet). Cho phép traffic RDP/SSH từ địa chỉ IP của bạn để quản lý.
       • Outbound: Cho phép traffic đến app-subnet trên port ứng dụng (ví dụ: 8080).
     • app-nsg (gắn vào app-subnet):
       • Inbound: Chỉ cho phép traffic từ web-subnet trên port 8080.
       • Outbound: Cho phép traffic đến data-subnet trên port cơ sở dữ liệu (ví dụ: 1433 cho SQL Server).
     • data-nsg (gắn vào data-subnet):
       • Inbound: Chỉ cho phép traffic từ app-subnet trên port 1433.
       • Outbound: Chặn tất cả traffic ra ngoài trừ khi cần thiết.
  4. Triển khai tài nguyên:
     • Đặt các máy chủ web (hoặc App Service) trong web-subnet.
     • Đặt các máy chủ ứng dụng (hoặc Functions) trong app-subnet.
     • Đặt cơ sở dữ liệu (VM hoặc Private Endpoint của SQL DB) trong data-subnet.
• Kết quả: Một kiến trúc defense-in-depth, nơi mỗi tầng chỉ có thể giao tiếp với các tầng được phép, giảm thiểu bề mặt tấn công.

4.2. Azure Load Balancer và Application Gateway: Cân bằng tải

Azure cung cấp nhiều dịch vụ cân bằng tải, mỗi dịch vụ hoạt động ở một lớp khác nhau của mô hình OSI. Việc hiểu rõ sự khác biệt này là rất quan trọng.

Dịch vụ Azure	Lớp OSI	Tương đương AWS	Use-case
Azure Load Balancer	Lớp 4 (Transport - TCP/UDP)	Network Load Balancer (NLB)	Cân bằng tải hiệu suất cao, độ trễ thấp cho lưu lượng TCP/UDP. Không nhận biết được nội dung HTTP/HTTPS. Thường dùng để phân phối traffic cho các VM trong backend pool.
Azure Application Gateway	Lớp 7 (Application - HTTP/HTTPS)	Application Load Balancer (ALB)	Cân bằng tải thông minh dựa trên các thuộc tính của yêu cầu HTTP như URL path, host header. Cung cấp các tính năng như SSL termination, cookie-based session affinity, và Web Application Firewall (WAF).
Azure Front Door	Lớp 7 (Application - Global)	Amazon CloudFront (cho routing) + AWS Global Accelerator	Dịch vụ cân bằng tải HTTP/HTTPS toàn cầu. Nó định tuyến người dùng đến backend có độ trễ thấp nhất. Cung cấp khả năng chuyển đổi dự phòng (failover) giữa các region, WAF, và tăng tốc ứng dụng.
Azure Traffic Manager	DNS	Amazon Route 53 (chính sách routing)	Cân bằng tải dựa trên DNS. Nó định tuyến các yêu cầu đến các endpoint khác nhau (có thể ở các region khác nhau) dựa trên các phương pháp định tuyến như performance (độ trễ thấp nhất), weighted, priority (failover). Lưu ý: Traffic Manager không xử lý lưu lượng truy cập thực tế, nó chỉ trả về một bản ghi DNS.

Use case thực tế: Phân phối lưu lượng truy cập cho một cụm máy chủ web có khả năng mở rộng

• Kịch bản: Một trang web thương mại điện tử chạy trên một cụm máy chủ web (triển khai bằng Virtual Machine Scale Sets - VMSS) cần tính sẵn sàng cao, bảo mật, và khả năng định tuyến dựa trên URL.
• Giải pháp:
  1. Triển khai các máy chủ web vào một VMSS.
  2. Triển khai một Application Gateway ở phía trước VMSS.
  3. Cấu hình Application Gateway:
     • Frontend IP Configuration: Gán một Public IP cho Application Gateway. Đây sẽ là điểm truy cập công cộng của trang web.
     • Backend Pool: Trỏ đến VMSS. Application Gateway sẽ tự động nhận biết các máy chủ trong scale set.
     • HTTP Listeners: Cấu hình một listener trên port 443 cho traffic HTTPS và tải lên chứng chỉ SSL của bạn (SSL termination).
     • Rules: Tạo các quy tắc định tuyến. Ví dụ:
       • Traffic đến /images/* sẽ được định tuyến đến một backend pool riêng chứa các máy chủ tối ưu cho việc phục vụ nội dung tĩnh.
       • Traffic đến /api/* sẽ được định tuyến đến một backend pool khác chứa các máy chủ ứng dụng.
       • Traffic còn lại sẽ đến backend pool web chính.
     • Health Probes: Cấu hình các health probes để Application Gateway có thể kiểm tra tình trạng của các máy chủ backend và tự động loại bỏ những máy chủ không khỏe mạnh.
  4. Bật WAF: Kích hoạt tính năng Web Application Firewall (WAF) trên Application Gateway (sử dụng SKU là WAF_v2) để bảo vệ ứng dụng khỏi các cuộc tấn công phổ biến như SQL injection và cross-site scripting (XSS).

---

Phần 5: Cơ sở dữ liệu (Databases)

Azure cung cấp một danh mục cơ sở dữ liệu phong phú, từ các dịch vụ quan hệ được quản lý hoàn toàn đến các cơ sở dữ liệu NoSQL phân tán toàn cầu.

5.1. Azure SQL Database: Dịch vụ cơ sở dữ liệu quan hệ được quản lý (PaaS)

• Tương quan trực tiếp: Amazon RDS (Relational Database Service).

Azure SQL Database là một dịch vụ cơ sở dữ liệu-as-a-service (DBaaS) thông minh, có khả năng mở rộng, được xây dựng trên công cụ Microsoft SQL Server. Nó xử lý hầu hết các chức năng quản lý cơ sở dữ liệu như nâng cấp, vá lỗi, sao lưu và giám sát mà không cần sự can thiệp của người dùng.

So sánh Azure SQL Database và Amazon RDS:

Đặc điểm	Azure SQL Database	Amazon RDS
Mức độ quản lý	PaaS thực thụ. Bạn không có quyền truy cập vào máy ảo bên dưới. Microsoft quản lý hoàn toàn OS và công cụ SQL Server.	PaaS, nhưng bạn có nhiều quyền kiểm soát hơn đối với công cụ cơ sở dữ liệu (thông qua Parameter Groups). Bạn cũng có thể SSH vào một số loại instance nhất định.
Công cụ (Engine)	Chỉ hỗ trợ Microsoft SQL Server.	Hỗ trợ nhiều công cụ: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, và Amazon Aurora.
Mô hình triển khai	Single Database: Một cơ sở dữ liệu độc lập với tài nguyên tính toán riêng. Elastic Pool: Một tập hợp các cơ sở dữ liệu chia sẻ cùng một nhóm tài nguyên tính toán (lý tưởng cho các ứng dụng SaaS đa khách hàng). Managed Instance: Tương thích gần như 100% với SQL Server on-premises, được thiết kế để "lift-and-shift" các ứng dụng SQL Server hiện có lên đám mây. Nó nằm trong VNet của bạn.	Dựa trên Instance. Bạn chọn một loại instance (kích thước CPU/RAM) và triển khai một hoặc nhiều cơ sở dữ liệu trên đó.
Tính sẵn sàng cao	Tích hợp sẵn. Các tầng dịch vụ Business Critical cung cấp các bản sao (replicas) và khả năng chuyển đổi dự phòng tự động.	Hỗ trợ triển khai Multi-AZ, tự động tạo một standby instance ở một AZ khác và đồng bộ hóa dữ liệu.
Serverless	Có. Tầng Serverless tự động mở rộng quy mô tính toán dựa trên nhu cầu workload và có thể tự động tạm dừng (auto-pause) trong các giai đoạn không hoạt động để tiết kiệm chi phí.	Có. Aurora Serverless cung cấp chức năng tương tự cho công cụ Aurora.

Use case thực tế: Xây dựng một ứng dụng web với cơ sở dữ liệu SQL được quản lý hoàn toàn

• Kịch bản: Một ứng dụng quản lý nhân sự mới được phát triển bằng ASP.NET Core, cần một cơ sở dữ liệu quan hệ đáng tin cậy, có khả năng mở rộng và yêu cầu quản lý tối thiểu.
• Giải pháp:
  1. Tạo một máy chủ logic Azure SQL Server. Đây chỉ là một cấu trúc quản lý logic, không phải là một máy chủ thực tế mà bạn trả tiền.
  2. Trên máy chủ logic đó, tạo một Azure SQL Database.
  3. Chọn mô hình mua hàng và tầng dịch vụ:
     • Mô hình DTU (Database Transaction Unit): Một thước đo kết hợp của CPU, memory và I/O. Đơn giản để bắt đầu.
     • Mô hình vCore: Cho phép bạn chọn số lượng vCores và dung lượng lưu trữ một cách độc lập. Linh hoạt hơn và được khuyến nghị cho các workload sản xuất.
     • Chọn tầng General Purpose (cân bằng giữa chi phí và hiệu suất) hoặc Business Critical (hiệu suất cao nhất, có bản sao đọc). Đối với giai đoạn đầu, có thể chọn tầng Serverless để tối ưu chi phí.
  4. Cấu hình Tường lửa: Thiết lập các quy tắc tường lửa trên máy chủ logic để chỉ cho phép các kết nối từ dải IP của ứng dụng web (ví dụ: Azure App Service) và từ máy tính của nhà phát triển.
  5. Kết nối: Lấy chuỗi kết nối (connection string) từ Azure Portal và cấu hình nó trong ứng dụng ASP.NET Core của bạn.
• Lợi ích: Đội ngũ phát triển không cần lo lắng về việc cài đặt, vá lỗi, hay sao lưu SQL Server. Azure tự động xử lý tất cả. Các tính năng như Point-in-time restore, geo-replication, và long-term backup retention đều có sẵn chỉ với vài cú nhấp chuột.

5.2. Azure Cosmos DB: Cơ sở dữ liệu NoSQL đa mô hình, phân tán toàn cầu

• Tương quan: Amazon DynamoDB, nhưng với phạm vi rộng hơn nhiều.

Cosmos DB là dịch vụ cơ sở dữ liệu NoSQL đa mô hình, được phân phối toàn cầu, độc quyền của Microsoft. Nó được thiết kế từ đầu với khả năng phân phối toàn cầu và mở rộng quy mô theo chiều ngang.

Các tính năng nổi bật làm nên sự khác biệt:

• Phân phối Toàn cầu Chìa khóa trao tay (Turnkey Global Distribution): Đây là điểm mạnh nhất của Cosmos DB. Bạn có thể sao chép dữ liệu của mình đến bất kỳ Azure region nào trên thế giới chỉ bằng một cú nhấp chuột. Ứng dụng của bạn có thể ghi và đọc từ bản sao gần nhất, mang lại độ trễ cực thấp cho người dùng trên toàn cầu.
• Đa mô hình (Multi-model): Cosmos DB lưu trữ dữ liệu trong một định dạng "atom-record-sequence" (ARS) nội bộ. Trên đỉnh của nó, nó cung cấp nhiều API khác nhau để bạn có thể tương tác với dữ liệu:
  • SQL (Core) API: API gốc, sử dụng cú pháp SQL để truy vấn tài liệu JSON. Tương tự DynamoDB với PartiQL.
  • MongoDB API: Tương thích với giao thức của MongoDB. Cho phép bạn "lift-and-shift" các ứng dụng MongoDB hiện có sang Cosmos DB.
  • Cassandra API: Tương thích với Apache Cassandra.
  • Gremlin (Graph) API: Dành cho cơ sở dữ liệu đồ thị.
  • Table API: Dành cho các ứng dụng được viết cho Azure Table Storage.
• Đảm bảo SLA: Microsoft cung cấp các SLA toàn diện cho Cosmos DB, bao gồm độ trễ (dưới 10ms cho đọc và ghi), tính sẵn sàng (99.999%), thông lượng, và tính nhất quán.
• Năm mức độ nhất quán (Consistency Levels): Không giống như nhiều cơ sở dữ liệu NoSQL chỉ cung cấp hai lựa chọn (strong và eventual), Cosmos DB cung cấp năm mức độ nhất quán được định nghĩa rõ ràng: Strong, Bounded Staleness, Session, Consistent Prefix, và Eventual. Điều này cho phép bạn chọn sự cân bằng phù hợp giữa tính nhất quán, tính sẵn sàng và hiệu suất.

Use case thực tế: Xây dựng một ứng dụng IoT với yêu cầu độ trễ thấp trên toàn cầu

• Kịch bản: Một công ty sản xuất các thiết bị theo dõi thể dục được bán trên toàn thế giới. Các thiết bị này liên tục gửi dữ liệu (nhịp tim, số bước chân, vị trí) về máy chủ. Người dùng cần có thể xem dữ liệu của họ gần như ngay lập tức trên ứng dụng di động, bất kể họ ở đâu.
• Giải pháp với Cosmos DB:
  1. Tạo một tài khoản Azure Cosmos DB với SQL API.
  2. Phân phối Toàn cầu: Trong Azure Portal, vào mục "Replicate data globally" và chọn các Azure region nơi có nhiều người dùng nhất (ví dụ: East US, West Europe, East Asia). Bật tính năng multi-region writes.
  3. Mô hình dữ liệu: Thiết kế một tài liệu JSON để lưu trữ dữ liệu từ thiết bị. Chọn một Partition Key tốt (ví dụ: deviceId) để phân phối dữ liệu đều trên các phân vùng logic.
  4. Kiến trúc:
     • Các thiết bị IoT sẽ gửi dữ liệu đến một Azure IoT Hub hoặc Event Hubs.
     • Một Azure Function sẽ được trigger bởi các sự kiện từ IoT Hub/Event Hubs.
     • Function này sẽ xử lý dữ liệu và ghi nó vào Cosmos DB. Nhờ có multi-region writes, Function có thể ghi vào region gần nhất, giảm độ trễ.
  5. Ứng dụng di động: Ứng dụng di động sẽ được cấu hình để đọc từ region Cosmos DB gần nhất với người dùng. SDK của Cosmos DB sẽ tự động xử lý việc định tuyến này.
• Kết quả: Cả việc ghi dữ liệu từ thiết bị và đọc dữ liệu từ ứng dụng di động đều có độ trễ cực thấp, mang lại trải nghiệm người dùng tuyệt vời trên toàn cầu. Hệ thống có thể mở rộng quy mô để xử lý hàng triệu thiết bị một cách dễ dàng.

---

Phần 6: Nhận dạng và Bảo mật (Identity & Security)

Với nền tảng là một công ty phần mềm doanh nghiệp, Microsoft rất chú trọng đến nhận dạng và bảo mật. Trái tim của hệ thống này là Azure Active Directory.

6.1. Azure Active Directory (Azure AD): Dịch vụ quản lý danh tính và truy cập

• Tương quan: AWS Identity and Access Management (IAM), nhưng với phạm vi lớn hơn rất nhiều.

Đây là một điểm khác biệt cơ bản mà bạn cần nắm vững.

• AWS IAM: Là một dịch vụ dành riêng cho việc quản lý quyền truy cập vào các tài nguyên bên trong AWS. Nó quản lý người dùng, nhóm, vai trò và chính sách cho các dịch vụ AWS.
• Azure AD: Là một giải pháp Quản lý Danh tính và Truy cập (Identity and Access Management - IDaaS) toàn diện trên đám mây. Nó không chỉ quản lý quyền truy cập vào các tài nguyên Azure mà còn là:
  • Nhà cung cấp danh tính (Identity Provider - IdP): Quản lý người dùng và nhóm cho các ứng dụng SaaS khác như Office 365, Salesforce, Dropbox,...
  • Nền tảng xác thực: Hỗ trợ các giao thức hiện đại như OAuth 2.0, OpenID Connect, SAML.
  • Dịch vụ thư mục: Tương tự như Windows Server Active Directory on-premises, nhưng được thiết kế cho đám mây.

Mọi Azure Subscription đều được liên kết với một Azure AD Tenant. Tenant này là nơi chứa tất cả người dùng, nhóm, và đăng ký ứng dụng của bạn.

Các khái niệm chính:

• User: Một danh tính trong Azure AD (ví dụ: user@yourcompany.com).
• Group: Một tập hợp các người dùng.
• Service Principal: Tương đương với IAM Role trong nhiều trường hợp. Đây là một danh tính cho một ứng dụng, dịch vụ, hoặc công cụ tự động hóa để truy cập vào tài nguyên Azure.
• Managed Identity: Một loại Service Principal đặc biệt được quản lý tự động bởi Azure. Khi bạn bật Managed Identity cho một dịch vụ (như VM, App Service, Function), Azure sẽ tự động tạo một Service Principal cho nó và quản lý credentials. Đây là cách được khuyến nghị để xác thực giữa các dịch vụ Azure.

6.2. Role-Based Access Control (RBAC): Kiểm soát truy cập dựa trên vai trò

• Tương quan trực tiếp: AWS IAM Policies.

RBAC là hệ thống mà Azure sử dụng để cấp quyền truy cập vào tài nguyên. Thay vì gán quyền trực tiếp cho người dùng, bạn gán các vai trò (roles).

Cấu trúc của một Role Assignment (Gán vai trò):

Một gán vai trò trong Azure bao gồm ba phần:

1. Security Principal (Đối tượng được cấp quyền): Ai được cấp quyền? (User, Group, Service Principal, Managed Identity).
2. Role Definition (Định nghĩa vai trò): Họ được phép làm gì? (ví dụ: Contributor, Reader, Virtual Machine Contributor). Một vai trò là một tập hợp các quyền (permissions) như Microsoft.Compute/virtualMachines/start/action. Azure có nhiều vai trò tích hợp sẵn và bạn cũng có thể tạo vai trò tùy chỉnh.
3. Scope (Phạm vi): Họ được phép thực hiện các hành động đó trên tài nguyên nào? Đây là một điểm mạnh của Azure. Phạm vi có thể được áp dụng ở các cấp khác nhau:
   • Management Group (áp dụng cho tất cả Subscriptions bên dưới).
   • Subscription (áp dụng cho tất cả Resource Groups bên dưới).
   • Resource Group (áp dụng cho tất cả tài nguyên trong Resource Group).
   • Individual Resource (chỉ áp dụng cho một tài nguyên cụ thể).

Use case thực tế: Quản lý quyền truy cập cho đội ngũ phát triển

• Kịch bản: Bạn có một đội ngũ phát triển đang làm việc trên một ứng dụng mới. Bạn muốn họ có toàn quyền trên các tài nguyên của dự án đó, nhưng không được phép xem hoặc sửa đổi các tài nguyên của các dự án khác.
• Giải pháp:
  1. Tạo một Resource Group cho dự án, ví dụ project-alpha-rg. Đặt tất cả tài nguyên của dự án (VMs, DBs, App Service) vào đây.
  2. Trong Azure AD, tạo một Group tên là Project Alpha Developers. Thêm tất cả các nhà phát triển của dự án vào nhóm này.
  3. Thực hiện một Role Assignment:
     • Security Principal: Nhóm Project Alpha Developers.
     • Role Definition: Vai trò Contributor. Vai trò này cho phép quản lý mọi thứ, nhưng không thể cấp quyền truy cập cho người khác.
     • Scope: Resource Group project-alpha-rg.
• Kết quả: Các nhà phát triển trong nhóm giờ đây có toàn quyền tạo, sửa, xóa tài nguyên bên trong project-alpha-rg, nhưng họ sẽ không thấy hoặc không thể chạm vào bất cứ thứ gì bên ngoài Resource Group đó. Việc quản lý rất đơn giản: khi có một nhà phát triển mới, bạn chỉ cần thêm họ vào nhóm Azure AD.

6.3. Azure Key Vault: Quản lý bí mật và khóa mã hóa

• Tương quan: AWS Key Management Service (KMS) và AWS Secrets Manager.

Azure Key Vault là một dịch vụ đám mây an toàn để lưu trữ và quản lý quyền truy cập vào các bí mật, khóa, và chứng chỉ.

• Secrets: Lưu trữ các chuỗi bí mật như chuỗi kết nối cơ sở dữ liệu, khóa API, mật khẩu. Tương tự AWS Secrets Manager.
• Keys: Lưu trữ các khóa mã hóa. Bạn có thể sử dụng các khóa này để mã hóa dữ liệu. Tương tự AWS KMS. Key Vault hỗ trợ cả khóa được bảo vệ bằng phần mềm và khóa được bảo vệ bằng Hardware Security Modules (HSMs).
• Certificates: Lưu trữ và quản lý các chứng chỉ TLS/SSL.

Use case: Thay vì hard-code chuỗi kết nối cơ sở dữ liệu vào file appsettings.json của một ứng dụng App Service, bạn lưu nó như một Secret trong Key Vault. Sau đó, bạn bật Managed Identity cho App Service và cấp cho nó quyền get secrets từ Key Vault đó. Ứng dụng của bạn bây giờ có thể đọc chuỗi kết nối một cách an toàn lúc khởi động mà không cần lưu trữ bất kỳ credentials nào trong mã nguồn hoặc cấu hình.

---

Phần 7: Giám sát và Quản lý (Monitoring & Management)

7.1. Azure Monitor: Dịch vụ giám sát toàn diện

• Tương quan trực tiếp: Amazon CloudWatch.

Azure Monitor là một dịch vụ toàn diện để thu thập, phân tích và hành động dựa trên dữ liệu đo lường (telemetry) từ môi trường đám mây và on-premises của bạn. Nó là một dịch vụ ô dù (umbrella service) bao gồm nhiều thành phần.

Ánh xạ từ Amazon CloudWatch:

Khái niệm AWS CloudWatch	Khái niệm Azure Monitor	Ghi chú và So sánh
CloudWatch Metrics	Azure Monitor Metrics	Thu thập dữ liệu số (time-series data) từ các tài nguyên Azure. Ví dụ: % CPU của VM, số lượng yêu cầu đến App Service. Dữ liệu này được thu thập tự động cho hầu hết các dịch vụ.
CloudWatch Logs	Azure Monitor Logs (Log Analytics)	Thu thập và tổ chức dữ liệu log và hiệu suất từ các nguồn được giám sát. Dữ liệu được lưu trữ trong một Log Analytics Workspace. Bạn sử dụng ngôn ngữ truy vấn Kusto Query Language (KQL) để phân tích dữ liệu này. KQL rất mạnh mẽ và linh hoạt, được coi là một trong những điểm mạnh của Azure Monitor.
CloudWatch Alarms	Azure Monitor Alerts	Cho phép bạn tạo các quy tắc cảnh báo dựa trên Metrics, Logs, hoặc Activity Log. Khi một điều kiện được đáp ứng, nó sẽ kích hoạt một Action Group.
(SNS for actions)	Action Group	Một tập hợp các hành động cần thực hiện khi có cảnh báo, chẳng hạn như gửi email, SMS, gọi webhook, chạy một Azure Function, hoặc tạo một ticket trong hệ thống ITSM.
CloudWatch Dashboards	Azure Dashboards	Cho phép bạn tạo các bảng điều khiển tùy chỉnh để trực quan hóa dữ liệu từ Metrics và Logs.
Application Insights	Application Insights	Tương tự AWS X-Ray. Đây là một dịch vụ Application Performance Management (APM) được tích hợp vào Azure Monitor. Nó giúp bạn phát hiện, phân loại và chẩn đoán các vấn đề trong ứng dụng web và dịch vụ của bạn.

Use case thực tế: Theo dõi hiệu suất của máy ảo và thiết lập cảnh báo

• Kịch bản: Bạn cần đảm bảo một máy chủ web quan trọng trên Azure VM không bao giờ bị quá tải CPU.
• Giải pháp:
  1. VM của bạn tự động gửi các chỉ số hiệu suất cơ bản (host-level metrics) đến Azure Monitor Metrics.
  2. Vào Azure Monitor, chọn "Alerts" và tạo một quy tắc cảnh báo mới.
  3. Điều kiện (Condition):
     • Tài nguyên: Chọn máy ảo của bạn.
     • Tín hiệu (Signal): Chọn Metric "Percentage CPU".
     • Logic cảnh báo: Average Percentage CPU > 80% trong khoảng thời gian 15 phút.
  4. Hành động (Action):
     • Tạo một Action Group mới.
     • Thêm một hành động: "Email Azure Resource Manager Role" và chọn vai trò "Owner".
     • Bạn cũng có thể thêm hành động gọi một webhook để gửi thông báo đến Microsoft Teams hoặc Slack.
• Kết quả: Nếu CPU trung bình của VM vượt quá 80% trong 15 phút, tất cả những người có vai trò Owner trên tài nguyên đó sẽ nhận được một email cảnh báo.

---

Phần 8: Chi phí và Tối ưu hóa (Cost & Optimization)

8.1. Azure Cost Management + Billing: Quản lý và phân tích chi phí

• Tương quan: AWS Cost Explorer và AWS Budgets.

Đây là công cụ tích hợp trong Azure Portal giúp bạn hiểu, quản lý và tối ưu hóa chi phí Azure của mình.

• Cost Analysis: Giao diện tương tác để phân tích chi phí theo các chiều khác nhau (dịch vụ, vị trí, resource group, tag). Tương tự Cost Explorer.
• Budgets: Cho phép bạn đặt ngân sách cho các phạm vi khác nhau (subscription, resource group) và nhận thông báo khi chi tiêu thực tế hoặc dự báo vượt quá ngưỡng. Tương tự AWS Budgets.
• Advisor Recommendations: Tích hợp các đề xuất tiết kiệm chi phí từ Azure Advisor.

8.2. Các mô hình định giá và chiến lược tiết kiệm chi phí trong Azure

• Pay-as-you-go (Trả tiền theo mức sử dụng): Mô hình mặc định, tương tự On-Demand của AWS.
• Reservations (Đặt trước):
  • Tương quan: Reserved Instances (RIs) và Savings Plans của AWS.
  • Bạn cam kết sử dụng một lượng tài nguyên nhất định (ví dụ: một loại VM cụ thể hoặc một lượng vCore SQL DB) trong 1 hoặc 3 năm để nhận được mức giảm giá đáng kể so với pay-as-you-go.
• Azure Hybrid Benefit:
  • Khái niệm độc đáo của Azure. Nếu bạn đã có giấy phép Windows Server hoặc SQL Server với Software Assurance, bạn có thể sử dụng các giấy phép đó trên Azure. Điều này có nghĩa là bạn chỉ trả tiền cho phần hạ tầng cơ bản, không phải trả tiền cho phần mềm, giúp tiết kiệm chi phí đáng kể. Đây là một lợi thế cạnh tranh lớn của Azure trong các môi trường doanh nghiệp sử dụng sản phẩm Microsoft.
• Spot VMs:
  • Tương quan: Spot Instances của AWS.
  • Cho phép bạn sử dụng công suất tính toán chưa được sử dụng của Azure với mức giảm giá rất lớn (lên đến 90%). Tuy nhiên, Azure có thể thu hồi các máy ảo này bất cứ lúc nào. Rất phù hợp cho các workload có thể bị gián đoạn, như xử lý theo lô, render, hoặc môi trường dev/test.

Kết luận

Hành trình chuyển đổi từ AWS sang Azure là một quá trình học hỏi các khái niệm và công cụ mới, nhưng nền tảng kiến thức về đám mây mà bạn đã có là một lợi thế vô giá. Hãy nhớ những điểm khác biệt chính:

• Tổ chức tài nguyên: Nắm vững hệ thống phân cấp Management Group > Subscription > Resource Group. Resource Group là chìa khóa để quản lý vòng đời và quyền truy cập.
• Định danh: Hiểu rằng Azure Active Directory không chỉ là IAM của Azure, mà là một nền tảng nhận dạng toàn diện.
• Triết lý dịch vụ: Azure thường cung cấp các dịch vụ PaaS tích hợp cao (như App Service) bên cạnh các khối xây dựng IaaS cơ bản.
• Điểm mạnh độc đáo: Tận dụng các tính năng như Azure Hybrid Benefit, Azure File Sync cho môi trường hybrid, và khả năng phân phối toàn cầu chìa khóa trao tay của Cosmos DB.

Hy vọng bộ tài liệu chuyên sâu này sẽ là một người bạn đồng hành hữu ích, giúp bạn tự tin chinh phục và thành công trên nền tảng Microsoft Azure. Chúc bạn may mắn