aws vpc subnet 小常識

Search for a command to run...

No comments yet. Be the first to comment.
書本連結 前言 會挑這本書看的人,應該都是關心自己負責專案的軟體架構的人。不只希望開發的軟體能滿足客戶的明確需求,也希望能滿足可維護性(maintainability)的隱性需求,以及自己對結構與美觀習慣的要求。 要能滿足上述這些要求很難,因為專案通常不會按照計畫進行。可能變因有 deadline,最後的 API 與承諾的不同,又或者我們的設計無法很好的貼合需求的變化所需。。因此完美的架構只有在一

我們的 AIOps agent 有個很具體的問題:它會捏造 trace ID。 當 on-call 工程師問「payment service 有沒有 error trace?」,agent 有時會信心滿滿地回答「是的,見 trace a1b2c3d4...」——但這串 ID 根本不存在 Tempo 裡。工程師點進去,404。壞的不只是使用者體驗,而是這讓整個 RCA 結論失去可信度。 另一個問題是

o11y-bench 深入剖析:讓 AI 真正面對 on-call 現場 從任務設計、合成環境、Agent 架構、評分機制到報告輸出,逐一解析這個開放 benchmark 的每個組件——以及 Gemini 3 Flash Preview 的完整實測結果 先說清楚這在解決什麼問題 目前多數 LLM benchmark 測的是「知識」:模型知不知道 PromQL 的語法,知不知道什麼是 p99

臥龍神算奇術完全兵書:從兵法原理到實戰,徹底搞懂奇術機制

稟告主公:此乃司馬懿進呈之兵書,詳解如何以 OpenTelemetry 陣法,令臥龍神算之一舉一動盡在掌握,知糧草消耗、察兵器效能、辨戰報異常,使主公運籌帷幄於大帳之中。 為何需要斥候情報? 司馬懿稟告主公: 臥龍神算(Claude Code)乃當世利器,然若無斥候回報,主公便如蒙眼行軍——兵器耗損幾何、糧草消費幾許、哪路斥候出了差錯,一概不知。臣以為,此乃兵家大忌。 無情報之弊,有四: 軍

在 AWS 的服務中,可以透過 AWS Virtual Private Cloud
來把部署的運算資源做有效的管控以及隔離
每當開啟一個 VPC 時,預設會開啟一個網路區段的空間來配置資源
舉例來說: 一般會是 10.0.0.0/16 代表有 16bit 被 lock 只剩 16bit 可分配
而 VPC 內會在把該網路區段隔離成多個更小的子網段稱為 subnet
舉例來說: 以下圖來說,切隔成 10.0.1.0/24 與 10.0.2.0/24 兩個子網段

且在假設都在相同網段且相同 Available Zone 的子網段彼此可以相通
而其中兩個子網段的連通性會根據其設定 route table 來做路由處理
比如說 路徑是在 10.0.1.x 的 target 會被導向 local
而 public subnet 因為有設定連接到 Internet Gateway
所以 route table 可以解析外部的 request 所以跟外部做互通
一般會把 Subnet 有沒有連接到 Internet Gateway 與否分成兩種 Subnet
一般會放置需要接收外部 request 的服務的比如 front-end web server 或是 api server
一般會放置不需要對外的服務,比如內部 cronjob 或是 ETL 等等內部服務
甚至是 DB service 通常也會配置 private subnet 並且限定特殊 Security Group 存取
為了避免因為單一 Available Zone 出事導致服務無法運行
通常會把一個服務配置到兩個不同 Available Zone 的地方

以上圖來說 AZ1, AZ2, AZ3 只要還有兩個 AZ 有正常 服務就可以正常運行
當 subnet 為 10.0.1.0/24 時,代表有 24bit 被 lock 只剩下 (32-24) = 8 bit 可以使用
所以代表有 2^8 = 256 個 ip 可以用
然而以下有幾個特殊的 IP是無法使用的
10.0.1.0 ---> NETWORK ADDRESS 用來界定 subnet 10.0.1.1 ---> AWS ROUTING 10.0.1.2 ---> AWS DNS 10.0.1.3 ---> AWS FUTURE 10.0.1.255 ---> BROADCAST
所以實際上能使用的只有 256 - 5 = 251 個 ip