Bị Tính Phí Elastic IP Sau Khi Dừng EC2 — Cần Disassociate Hay Release?

Bạn vừa stop EC2 instance để tiết kiệm chi phí, nhưng cuối tháng nhìn vào hóa đơn AWS vẫn thấy dòng phí Elastic IP xuất hiện đều đặn. Đây là một trong những 'bẫy chi phí' phổ biến nhất trên AWS — Elastic IP không tự động miễn phí khi instance dừng, và nhiều kỹ sư mất vài tháng mới nhận ra.

TL;DR — Tóm Tắt Nhanh

Trạng tháiElastic IP có bị tính phí không?Hành động cần làm
Instance đang running, EIP đã gắnMiễn phíKhông cần làm gì
Instance đã stopped, EIP vẫn gắnCó — bị tính phí theo giờRelease EIP nếu không dùng nữa
EIP không gắn với bất kỳ resource nàoCó — bị tính phí theo giờRelease EIP
EIP đã ReleasedMiễn phí hoàn toànXong

Elastic IP Tính Phí Như Thế Nào?

AWS cung cấp Elastic IP miễn phí với một điều kiện duy nhất: địa chỉ đó phải đang được gắn vào một EC2 instance đang chạy (running). Ngay khi instance bị stop hoặc EIP bị tách ra mà chưa release, AWS bắt đầu tính phí theo giờ — lý do là AWS muốn tránh tình trạng người dùng 'gom' địa chỉ IPv4 công khai mà không sử dụng, vì IPv4 là tài nguyên có giới hạn toàn cầu.

Hãy hình dung Elastic IP như một chỗ đậu xe thuê theo giờ. Khi xe bạn đang đậu (instance running), bạn không mất thêm phí. Nhưng nếu xe bạn lái đi (instance stopped) mà vẫn giữ chỗ đó, bạn vẫn phải trả tiền chỗ đậu — dù xe không ở đó.

Kể từ tháng 2 năm 2024, AWS đã thay đổi chính sách: tất cả các địa chỉ IPv4 công khai đều bị tính phí, bao gồm cả Public IPv4 tự động gán cho instance (không chỉ Elastic IP). Tuy nhiên, bài viết này tập trung vào Elastic IP — loại địa chỉ bạn chủ động cấp phát và quản lý.

stateDiagram-v2 [*] --> Associated : Allocate & Associate Associated --> Unassociated : Disassociate Associated --> Released : Release Unassociated --> Associated : Associate lại Unassociated --> Released : Release Released --> [*] Associated : EIP gắn với Running Instance ✅ Miễn phí Unassociated : EIP không gắn với resource nào 💸 Bị tính phí theo giờ Released : EIP đã trả về AWS ✅ Không còn phí
  1. Instance Running + EIP gắn: Trạng thái bình thường, miễn phí.
  2. Instance Stopped + EIP vẫn gắn: AWS bắt đầu tính phí EIP theo giờ ngay lập tức.
  3. EIP không gắn (unassociated): Cũng bị tính phí — trạng thái này nguy hiểm nhất vì dễ bị bỏ quên.
  4. EIP Released: Địa chỉ trả lại pool của AWS, không còn phí.

Disassociate vs. Release — Khác Nhau Ở Điểm Nào?

Đây là chỗ nhiều người nhầm lẫn nhất. Hai thao tác này trông giống nhau trên console nhưng có hậu quả hoàn toàn khác nhau về chi phí và khả năng phục hồi.

Disassociate (Tách liên kết): Gỡ EIP khỏi instance nhưng vẫn giữ địa chỉ IP trong tài khoản của bạn. Sau bước này, EIP ở trạng thái 'unassociated' và vẫn bị tính phí. Dùng Disassociate khi bạn muốn chuyển EIP sang instance khác mà không mất địa chỉ IP đó.

Release (Giải phóng): Trả địa chỉ IP về pool của AWS. Sau bước này, địa chỉ IP đó biến mất khỏi tài khoản bạn và không còn phí. Nếu sau này bạn cần IP tĩnh, bạn sẽ nhận được một địa chỉ khác — không thể lấy lại địa chỉ cũ.

graph TD A[Instance Stopped
EIP vẫn gắn] --> B{Bạn muốn làm gì?} B --> C[Chuyển EIP sang
instance khác] B --> D[Không dùng EIP nữa] C --> E[Disassociate] E --> F[Associate với
instance mới] F --> G[✅ Miễn phí
instance đang running] D --> H[Disassociate] H --> I[Release] I --> J[✅ Dừng hoàn toàn phí] E --> K[⚠️ Nếu chỉ Disassociate
mà không làm gì thêm] K --> L[💸 Vẫn bị tính phí
EIP unassociated]
  1. Disassociate đơn thuần không dừng phí — EIP chỉ chuyển sang trạng thái unassociated và vẫn bị tính tiền.
  2. Release mới thực sự dừng phí hoàn toàn.
  3. Nếu cần giữ IP để dùng lại sau, bạn phải chấp nhận trả phí trong thời gian đó.

Cách Dừng Phí Elastic IP — Từng Bước Cụ Thể

Bước 1: Xác định các EIP đang bị tính phí trong tài khoản

Trước khi làm gì, cần biết mình đang có bao nhiêu EIP và trạng thái của chúng. EIP ở trạng thái unassociated hoặc gắn với instance đang stopped đều là nguồn phí tiềm ẩn.

aws ec2 describe-addresses \
  --query 'Addresses[*].{AllocationId:AllocationId,PublicIp:PublicIp,InstanceId:InstanceId,AssociationId:AssociationId}' \
  --output table \
  --region us-east-1

Cột InstanceId trống nghĩa là EIP đang ở trạng thái unassociated — đang bị tính phí ngay lúc này. Nếu có InstanceId nhưng instance đó đang stopped, kiểm tra thêm bước dưới.

Bước 2: Kiểm tra trạng thái instance đang gắn với EIP

Bước này xác nhận instance có đang chạy không — nếu stopped, EIP đang tốn tiền vô ích.

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[*].Instances[*].{InstanceId:InstanceId,State:State.Name}' \
  --output table \
  --region us-east-1

Bước 3: Disassociate EIP khỏi instance (nếu instance đang stopped)

Nếu instance đang stopped và bạn quyết định release EIP, cần disassociate trước. Lưu ý: nếu instance đang running, bạn có thể release trực tiếp mà không cần disassociate thủ công — AWS sẽ tự xử lý. Nhưng với instance stopped, thao tác tường minh hơn.

aws ec2 disassociate-address \
  --association-id eipassoc-0123456789abcdef0 \
  --region us-east-1

Lấy association-id từ kết quả của bước 1 (cột AssociationId).

Bước 4: Release EIP để dừng hoàn toàn phí

Đây là bước quan trọng nhất. Sau khi release, địa chỉ IP này không còn thuộc tài khoản bạn nữa.

aws ec2 release-address \
  --allocation-id eipalloc-0123456789abcdef0 \
  --region us-east-1

Lấy allocation-id từ kết quả của bước 1 (cột AllocationId).

Bước 5: Xác nhận không còn EIP nào bị tính phí

Chạy lại lệnh describe-addresses để đảm bảo không còn EIP unassociated nào sót lại.

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].{AllocationId:AllocationId,PublicIp:PublicIp}' \
  --output table \
  --region us-east-1

Nếu output trống, bạn đã sạch phí EIP.

CLI examples omitted for steps không có — tất cả 5 bước đều có CLI đầy đủ.

Trường Hợp Thực Tế: Sai Lầm Phổ Biến Nhất

Một kịch bản hay gặp: kỹ sư tạo EC2 instance cho môi trường dev, gắn EIP để có IP cố định, sau đó stop instance vào cuối ngày làm việc. Sau 2 tuần, hóa đơn tăng bất thường. Nhìn vào Cost Explorer thấy dòng 'EC2-EIP IdleAddress' — đó là dấu hiệu EIP đang ở trạng thái idle (không gắn với running instance).

Phản ứng đầu tiên thường là vào console, nhấn 'Disassociate', rồi nghĩ xong. Nhưng Disassociate chỉ tách EIP khỏi instance — không dừng phí. EIP lúc này chuyển sang unassociated và tiếp tục tính tiền. Phải nhấn thêm 'Release' mới thực sự dừng.

Nguyên nhân gốc rễ không phải là thiếu kiến thức về EIP — mà là UI console không làm rõ rằng Disassociate và Release là hai bước riêng biệt với hậu quả tài chính khác nhau. Nhiều người đọc 'Disassociate' và hiểu là 'đã xong'.

IAM Policy Tối Thiểu Để Quản Lý EIP

Nếu bạn cần cấp quyền cho một role hoặc user để thực hiện các thao tác trên, đây là policy tối thiểu theo nguyên tắc least privilege:

🔽 Xem IAM Policy mẫu 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeEIP",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeAddresses",
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ManageEIP",
      "Effect": "Allow",
      "Action": [
        "ec2:DisassociateAddress",
        "ec2:ReleaseAddress"
      ],
      "Resource": "*"
    }
  ]
}

Lưu ý: ec2:DescribeAddresses và ec2:DescribeInstances yêu cầu "Resource": "*" vì các Describe action không hỗ trợ resource-level restriction theo AWS Service Authorization Reference.

Ngăn Chặn Phí EIP Trong Tương Lai

Dùng AWS Cost Anomaly Detection

Thiết lập Cost Anomaly Detection cho service EC2 để nhận cảnh báo khi chi phí tăng bất thường. EIP idle thường tạo ra spike nhỏ nhưng đều đặn — loại anomaly này dễ bị bỏ qua nếu không có alert.

Tạo AWS Config Rule để phát hiện EIP unassociated

AWS Config có managed rule eip-attached — rule này đánh dấu bất kỳ EIP nào không được gắn với running instance là non-compliant. Kết hợp với SNS notification, bạn sẽ nhận cảnh báo ngay khi có EIP bị bỏ lơ.

aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "eip-attached",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "EIP_ATTACHED"
    }
  }' \
  --region us-east-1

Cân nhắc dùng Public IPv4 tự động thay vì EIP

Với môi trường dev/test, nếu không cần IP cố định, hãy dùng Public IPv4 tự động gán của instance thay vì EIP. Khi instance stop rồi start lại, IP sẽ thay đổi — nhưng với môi trường dev, điều đó thường chấp nhận được và tránh được phí EIP idle.

Dừng Phí Elastic IP — Kết Luận

Để dừng phí Elastic IP hoàn toàn, bạn phải Release địa chỉ đó — không phải chỉ Disassociate. Disassociate chỉ tách EIP khỏi instance nhưng vẫn giữ địa chỉ trong tài khoản và tiếp tục tính phí. Release mới thực sự trả địa chỉ về AWS và dừng hoàn toàn mọi khoản phí liên quan.

Nếu bạn cần giữ IP tĩnh cho sau này, bạn phải chấp nhận trả phí trong thời gian đó hoặc tìm giải pháp thay thế như Route 53 với DNS failover. Kiểm tra định kỳ các EIP trong tài khoản bằng describe-addresses hoặc thiết lập AWS Config rule eip-attached để tự động phát hiện EIP bị bỏ lơ.

Tham khảo thêm: AWS Elastic IP Addresses Documentation và AWS Config Rule: eip-attached.

Glossary — Thuật Ngữ Chính

Thuật ngữGiải thích
Elastic IP (EIP)Địa chỉ IPv4 tĩnh công khai do bạn cấp phát và quản lý trong tài khoản AWS.
DisassociateTách EIP khỏi instance hoặc network interface, nhưng vẫn giữ EIP trong tài khoản.
ReleaseTrả EIP về pool của AWS, xóa khỏi tài khoản, dừng hoàn toàn phí.
Allocation IDĐịnh danh duy nhất của EIP trong tài khoản AWS (dạng eipalloc-xxx).
Association IDĐịnh danh của liên kết giữa EIP và một instance/network interface cụ thể (dạng eipassoc-xxx).

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

EC2 Không Có Internet Trong Custom VPC: Cách Gắn Internet Gateway và Cập Nhật Route Table

Bạn tạo một custom VPC, launch EC2 instance vào public subnet, SSH vào được — nhưng ping google.com trả về timeout hoàn toàn. Đây là một trong những lỗi phổ biến nhất khi làm việc với EC2 không có internet trong custom VPC, và nguyên nhân gần như luôn nằm ở một trong ba lớp: thiếu Internet Gateway, route table chưa có default route, hoặc Security Group/NACL chặn traffic ra ngoài. TL;DR — EC2 Không Có Internet Trong Custom VPC Lớp kiểm tra Triệu chứng Fix Internet Gateway Không có IGW hoặc IGW chưa attach vào VPC Tạo IGW, attach vào VPC Route Table Không có route 0.0.0.0/0 → igw-xxx Thêm default route trỏ vào IGW Subnet Association Subnet dùng main route table không có IGW route Associate subnet với route table đúng Public IP EC2 không có public IP hoặc Elastic IP Enable auto-assign public IP hoặc gắn EIP Security Group Outbound rule bị xóa hoặc quá hạn chế Thêm outbound rule cho port 80/443 hoặc all...
Đọc thêm

RDS Multi-AZ: Lợi Ích Thực Sự Là Gì và Khi Nào Nên Bật?

Một trong những câu hỏi hay gặp nhất khi thiết kế hệ thống trên AWS là: bật Multi-AZ cho RDS có giúp tăng hiệu năng đọc không, hay nó chỉ phục vụ mục đích failover? Câu trả lời ngắn gọn là: Multi-AZ không cải thiện hiệu năng đọc — nhưng nếu bạn đang vận hành hệ thống production mà thiếu nó, bạn đang chấp nhận một rủi ro downtime không cần thiết. TL;DR — RDS Multi-AZ là gì và có lợi ích gì? Multi-AZ là cơ chế high availability của RDS, không phải cơ chế scale-out. Bảng dưới tóm tắt những điểm quan trọng nhất: Khía cạnh Multi-AZ Read Replica Mục đích chính High availability, failover tự động Scale-out đọc, giảm tải primary Standby có nhận traffic đọc không? Không (với Multi-AZ DB Instance) Có Replication Synchronous Asynchronous Failover tự động Có Không (thủ công) RTO mục tiêu Thường dưới 2 phút (tùy engine) Không áp dụng Ảnh hưởng hiệu năng ghi Có thể tăng nhẹ latency do sync replication Không...
Đọc thêm

Lỗi CORS trên API Gateway: Cách bật CORS và Lambda phải trả về header gì

Frontend gọi API Gateway và nhận ngay lỗi 'Access-Control-Allow-Origin' — đây là một trong những lỗi phổ biến nhất khi tích hợp React/Vue với backend AWS, và cũng là lỗi dễ chẩn đoán sai nhất. Vấn đề không chỉ nằm ở việc bật CORS trong console, mà còn ở chỗ Lambda của bạn có thực sự trả về đúng headers trong response hay không. TL;DR — Tóm tắt nhanh Vấn đề Nguyên nhân Fix CORS error trên preflight OPTIONS API Gateway chưa có method OPTIONS hoặc chưa enable CORS Enable CORS trong console hoặc thêm OPTIONS method thủ công CORS error trên request thực (GET/POST) Lambda response thiếu header Access-Control-Allow-Origin Thêm header vào Lambda response body CORS error khi Lambda trả về lỗi (4xx/5xx) Lambda Proxy Integration không tự inject CORS headers vào error response Lambda phải tự trả về CORS headers ngay cả khi có lỗi CORS hoạt động như thế nào với API Gateway Trước khi đi vào fix, cần hiểu đún...
Đọc thêm