AWS 日誌應分流到 OpenSearch 與 S3，而不是硬塞進單一平台

AWS 日誌最好的做法，是用 OpenSearch 做即時搜尋、用 S3 做長期保存，而不是把所有需求塞進同一套系統。

AWS 的集中式日誌應該拆成兩條路：OpenSearch 處理熱查詢，S3 負責歸檔，硬把兩者合一只會先把成本拉高，再把可用性拖垮。

這不是抽象主張。Anblicks 的架構就是用 Fluent Bit 在 EKS 上並行送出日誌，一路進 Amazon OpenSearch 做即時排障，一路進 Amazon S3 做長期保留，歷史查詢再交給 Athena。這種設計符合事故現場的真實需求：故障發生時，工程師要的是秒級搜尋；事故結束後，審計、鑑識、趨勢分析要的是低成本保存。把這兩件事塞進同一個儲存層，日誌系統很快就會先變成成本問題，再變成觀測問題。

第一個論點：熱日誌和冷日誌本來就不是同一種工作

OpenSearch 的強項是速度，不是永久保存。當 production 出現異常時，真正有價值的是能立刻搜尋最近的日誌、依服務過濾、把事件串起來。Anblicks 把 OpenSearch 放在即時路徑上、再用 OpenSearch Dashboards 做前端，正是因為排障需要的是低延遲讀取，不是把過去兩年的每一行 log 都索引進去。

S3 則正好相反，它便宜、耐久，適合大規模保留。AWS 將日誌持續歸檔到 S3 的做法是對的，因為日誌量通常長得比團隊預期快得多。若把所有資料都留在 OpenSearch，成本會同時從 shard、儲存和叢集維運三個方向上升。分流架構把昂貴的搜尋索引維持在小而快的狀態，把歷史資料放進低成本儲存，這才是可持續的設計。

第二個論點：Fluent Bit 讓分流變成可操作方案

這個架構最有力的地方，是 Fluent Bit 可以同時送往兩個目的地，而且不會把收集器本身變成瓶頸。文章中的 Fluent Bit 以 DaemonSet 跑在 EKS 上，代表每個節點都有一個輕量收集器貼近工作負載。這很重要，因為集中式日誌最常失敗的原因之一，就是收集器太重，開始和應用程式搶資源。Fluent Bit 足夠小，幾乎不會被感知，卻又足夠靈活，可以把同一份串流同時送到 OpenSearch 和 S3。

雙寫才是把架構變成營運能力的關鍵。團隊不必在「即時可見」和「長期保留」之間二選一，管線本身就同時滿足兩者。當資安團隊要回頭查上個月的登入尖峰，Athena 可以直接查 S3 archive；當 SRE 要追一波 5xx 暴增，OpenSearch 已經完成索引、可以立刻搜尋。這套平台之所以成立，不是因為它極簡，而是因為每一層都只做自己最擅長的事。

反方可能怎麼說

最強的反對意見是：分流日誌會增加零件數。OpenSearch、S3、Athena、Glue、SNS、Fluent Bit，整套看起來比單一觀測平台複雜得多。對小團隊來說，一個把 ingestion、search、retention、dashboard、alerting 全包的雲端產品，確實更像「少一個控制平面、少一張帳單」的答案。這個理由很真實，因為當團隊很小、事故量也低時，營運簡化本身就是價值。

另一個反對點是成本與維運。開源加 AWS 並不等於免費，反而代表有人得管 retention policy、index lifecycle、查詢模式、壓縮、partition 和告警規則。若團隊沒有能力把這些細節調好，架構就可能從「可控」變成「吵雜且昂貴」。

但這個反方論點只在一個前提下成立：你把日誌當成看板功能，而不是營運基礎設施。若目標是能長期支撐 production，分流就不是多餘複雜度，而是必要複雜度。把低延遲搜尋和低成本保存拆開，才能同時保住可用性與成本控制。對極小團隊，單一平台可以接受；但只要你已經在跑 EKS、EC2、Lambda 和 load balancer，這種分工就是正確答案。

你能做什麼

如果你是工程師，先按日誌年齡和查詢目的設計管線：最近、最常查的日誌放 OpenSearch，全部原始資料歸檔到 S3，歷史分析交給 Athena。若你是 PM 或創辦人，把日誌當成基礎設施預算與保留政策來管理，不要把它當成一個漂亮的儀表板。要為現在的事故設計，也要為六個月後的審計設計。