前面我們花了許多篇幅介紹 Observability 2.0 的理念，以及如何透過 Data Lakehouse（Parquet + Iceberg）建立 Single Source of Truth。我們也深入探討了 ClickHouse Exporter 如何將 OTLP 資料轉換成扁平的 table schema。

筆者自己在研究架構時，除了參考目前現有的 exporter 處理資料的做法，同時也會好奇，那麼其他企業是怎麼設計可觀測性系統的？我們目前的設計和其他人的做法有何不同？

今天，讓我們來看一下 AWS 針對企業認證推出的 Claude Code + AWS Bedrock 解決方案，雖然這個 repo 和可觀測性沒有直接的關係，不過它在文件中也有詳細說明要如何架設觀測此系統的可觀測性架構。

架構概覽

如前面所說，這個解決方案的目的是幫助組織在使用 Claude Code + Amazon Bedrock 的情境下，整合企業現有的身份驗證機制（OIDC／SSO 等）。它會在後端建立必要的 AWS 資源（例如 OIDC provider、Cognito 或 IAM 信任關係、角色與政策、觀察用的 CloudWatch 或監控資源等）來支援身份交換與權限控制。然後對使用者端提供一個可以在本地跑的認證流程（credential process），讓用户在呼叫 Claude / Bedrock 時，不需要擁有或管理 API 金鑰。

它背後所架設的可觀測性系統架構圖如下：

圖片出處：https://github.com/aws-solutions-library-samples/guidance-for-claude-code-with-amazon-bedrock/blob/main/assets/images/architecture-diagram.md

可以從這個架構圖看到幾個重點：

1. OTel Collector 架設在 ECS Fargate
2. 將 OTLP 轉換成 CloudWatch 的 Embedded Metric Format (EMF)
3. CloudWatch 儲存 Metrics、Traces、Logs
4. 存進 CloudWatch 的 log 可再透過 Firehose 儲存進 S3，作為長期資料以便進行分析

可以看到整體的架構分為兩部分，一部分是可以開箱即用的 CloudWatch，一部分是可以長期放置資料的 S3。在 Firehose 到 S3 的這部分設計比較符合我們之前所說的 observability 2.0 架構，可以統一從一個地方來做可觀測性資料的查詢。但是為什麼前面要再放一層 CloudWatch?

為什麼要先經過 CloudWatch？理解 CloudWatch 所扮演的角色

CloudWatch 所提供的服務大家應該都不陌生，它一直都扮演即時監控與事件告警的角色。儘管它不是一個開放的 data lakehouse 或其他分析平台，但若你的服務都是架設在 AWS 上，它與 AWS 生態的緊密連結可能會是一個可考慮的方案。

CloudWatch 主要負責三大類訊號：Metrics、Logs、Traces。其實也是我們所熟悉的三大支柱。

1. Metrics（指標）

• 提供時間序列型監控資料，例如 CPU 使用率、Lambda 延遲、ECS 任務健康狀況等。
• 可自訂維度（dimensions）並建立 Alarm，一旦超出閾值即可觸發 SNS 通知或自動執行修復動作（如 Lambda remediation）。
• 延遲極低，通常數秒內即可在 Dashboard 顯示。

2. Logs（日誌）

• 以 CloudWatch Logs Group 為單位儲存應用或基礎設施的原始 log。
• 可與 Logs Insight 結合進行查詢與過濾（類似 SQL 語法）。
• 同時支援透過 Subscription Filter 將資料流送到 Lambda、Firehose 或第三方分析系統。

3. Traces（追蹤）

• 整合 AWS X-Ray，可視化分散式系統中服務間的延遲與錯誤分佈。
• 透過 OTel Collector 導出至 X-Ray，可快速識別 bottleneck 與異常節點。

這三者組合起來，讓 CloudWatch 成為一個 高即時性、以營運為中心的可觀測性解決方案。

EMF（Embedded Metric Format）：CloudWatch 的橋樑

不過，我們可能不只收集來自 AWS 服務的 signals，例如我們現在看的這個解決方案，就需要收集從 claude code 所暴露出來的 signals，而 claude code 原生就支援 OTLP 格式的觀測資料。

因為 CloudWatch 的 Metrics 並不是原生支援 OTLP（OpenTelemetry Protocol）的格式。所以並沒有辦法直接將 claude code 的 signals 打進 CloudWatch。

而 EMF 是 AWS 設計的一種「橋樑格式」，可以讓應用程式或代理程式直接在 log 中嵌入結構化的 metric 資料，然後由 CloudWatch 自動解析、轉換成 Metrics。

簡單來說，EMF 的目的就是讓 log 與 metrics 可以共生（logs as metrics）。

如此一來，我們既可以使用標準的 OTLP 格式來處理可觀測性資料，又能夠使用開箱即用的 CloudWatch 即時監控工具，不需要等待資料進入到 data lakehouse 才能進行分析。

同時，對於異常的系統指標也有內建的告警系統可以快速觸發警報。

結語

從這個案例可以看到，AWS 的設計並非要完全取代 Observability 2.0 的資料湖架構，而是讓 CloudWatch 承擔「即時監控」與「事件響應」的角色。
透過 EMF 這層轉換機制，系統能在第一時間將 OTLP 資料送進 CloudWatch，達到快速可視化與告警；
同時又能透過 Firehose 將相同資料長期儲存在 S3，保留資料湖分析的彈性與延展性。

這樣的架構在實務上其實相當務實：前端 CloudWatch 提供即時反應，後端 S3 維持長期觀測與趨勢分析。
它提醒我們，可觀測性系統並非單一技術的選擇，而是一種「資料流動與分層思維」的體現。

下一篇，我們就來比較這種 CloudWatch + S3 的雙層架構，和我們前面所設計的 Data Lakehouse Observability 架構之間的差異，看看兩者在資料治理、查詢效率與成本權衡上的取捨，能帶給我們哪些新的啟發。

參考資料

Amazon CloudWatch Documentation

AWS Documenation - Specification: Embedded metric format

guidance-for-claude-code-with-amazon-bedrock