Unknown ENI Delete Action in CloudTrail


一直有透過 Cloudtrail 在了解資源的使用狀況 (為了方便監控,把訊息放到 Slack),可是發現每天都有一些奇怪的 event 如下圖:

這些 event 的特性有:

  • 都是用 root account 在執行 (OMG)
  • 都是刪除 ENI (網卡)
  • 大多都是晚上發生的

一直搞不懂為啥會有這動作,也去問了同事,有沒人在做這樣的動作,可是沒有結論,直到最近我在規劃 VPC 網路架構時 ….

VPC NAT Gateway

今天在實驗 VPC NAT Gateway 時,本來以為他不會有 SPOF 的問題 (我們有另一個環境是使用 NAT Instance 就有此問題) 但是因為在建立 NAT Gateway 時要選擇 Subnet, Subnet 又是直接在指定的 Zone 裡,所以表示可能也沒有 SPOF ,找了手冊發現以下這段文字,更加確認了:

If you have resources in multiple Availability Zones and they share one NAT gateway, in the event that the NAT gateway’s Availability Zone is down, resources in the other Availability Zones lose Internet access. To create an Availability Zone-independent architecture, create a NAT gateway in each Availability Zone and configure your routing to ensure that resources use the NAT gateway in the same Availability Zone.

回到一開始的問題,因為今天的實驗,想到 NAT Gateway 背後的原理應該也是用一台特殊的 EC2 在跑,他的特性是這樣:

  • Low computing: 只是做 NAT 的工作,不需要運算能力
  • High Network Bandwidth: 都在做網路傳輸,需要大量的頻寬,需要一張 ENI 和對外的 EIP
  • Storageless: 不儲存資料,不需要儲存設備

更多 NAT Gateway 請參閱:Migrate to AWS NAT Gateway

ELB Pre-warming

這樣特性 (PaaS) 的機器跟另一個服務很像,就是 ELB。而之前曾經因為業務需求,跟 AWS Support 提出 ELB Pre-warming Request,也跟 AWS 台灣的技術支援瞭解過背後運作原理:

ELB EC2 Instance 實際上會根據流量,自己 Scale-out,也就是自己增減 Instance,只是一般的狀況之下,是緩增緩減。如果是 Pre-warming,AWS Support 會詢問預計的 request 數量大概多少,以及時間,ELB Team 則會預先把這些 Scale-out 的機器在預計的時間開好。

依據這樣的描述,歸納出 ELB Instance 可能會有這樣的特性:

  • Low computing: 只是做 Forward 的工作,不需要運算能力
  • High Network Bandwidth: 都在做網路傳輸,需要大量的頻寬,需要一張 ENI 和對外的 EIP
  • Storageless: 不儲存資料,不需要儲存設備
  • 他會自己 Scale-out/in –> ENI 會自動增減

這不就跟 NAT Gateway 差不多了,唯一的差異他會自己 Scale-in/out

原來 …

到這裡回到一開始的問題就不難瞭解了,NAT Gateway 需要 ENI,當然 ELB 也需要 ENI,只是 ELB 會自己根據流量 Scale-out/in,所以我們系統流量每天晚上的增減,背後 ELB Instance 的增減,同時 ENI 也就會自動增減了。只是都忠實地被 Cloudtrail 記錄下來,所以會看到一開始的現象。

Updated

2017/02/04: 後來在這篇找到官方的回覆 My AWS CloudTrail logs show root credentials are being used to authenticate actions I didn’t initiate

延伸閱讀 (站內)

參考資料


Comments