← Financial Cloud Cloud Cloud Club · AWS Re:cap

極點宏觀|Financial Cloud Cloud · AWS Re:cap

AWS Re:cap 03: Zurich Insurance Group:在 AWS 上建置有效的日誌管理解決方案

講者: Samantha Gignac

場次: 03

場次
Summit Dev Lounge2026 Re:cap
01 把架構寫成 Steering,引導 AI Agent
Summit Dev Lounge2026 Re:cap
02 Agent Harness 才是真正的工程護城河
Summit Dev Lounge2026 Re:cap
03 用白話詢問可觀測性資料
Summit Dev Lounge2026 Re:cap
04 以 Bedrock AgentCore 打造 Serverless AR 遊戲
Summit Dev Lounge2026 Re:cap
05 AgentCore 上的多 Agent 量化回測
Summit Dev Lounge2026 Re:cap
06 三分鐘用 Kiro 把部落格變簡報
Summit Dev Lounge2026 Re:cap
AWS Community Day Hong Kong 2025 Re:cap
02 使用 Terraform 實現 AWS 合規
AWS Community Day Hong Kong 2025 Re:cap
03 從新手到開發者:一段精彩的 AWS 雲端旅程
AWS Community Day Hong Kong 2025 Re:cap
04 以團隊為優先:使用 Laravel 與 Bref 進行無伺服器工程
AWS Community Day Hong Kong 2025 Re:cap
05 活動開幕
AWS Community Day Hong Kong 2025 Re:cap
06 Agent-to-Agent:在 AWS 上打造可互通的 AI
AWS Community Day Hong Kong 2025 Re:cap
07 運用另一種遙測資料,透過 AI Agent 加速改善
AWS Community Day Hong Kong 2025 Re:cap
08 告別 Vibe Coding:運用 Kiro 實踐規格驅動開發(Spec-Driven Development)
AWS Community Day Hong Kong 2025 Re:cap
09 運用 MCP 與 AI 代理進行自動化測試
AWS Community Day Hong Kong 2025 Re:cap
10 以 ML 驅動的方法實現電信安全現代化
AWS Community Day Hong Kong 2025 Re:cap
11 重新思考 GenAI Agent:RAG 與 MCP
AWS Community Day Hong Kong 2025 Re:cap
12 運用 TAK 與 AWS 進行災害及緊急應變
AWS Community Day Hong Kong 2025 Re:cap
13 從測試角度重新思考 Serverless 應用程式工作流程
AWS Community Day Hong Kong 2025 Re:cap
14 運用實務 AWS FinOps 邁向雲端成功
AWS Community Day Hong Kong 2025 Re:cap
15 運用 AWS 打造 AI 驅動的全球 Pure-Alpha 宏觀交易:革新風險調整後資產報酬
AWS Community Day Hong Kong 2025 Re:cap
FSI Recap
01 現代交易生命週期:從交易到結算
FSI Recap
02 Goldman Sachs:透過 Fast Track 將應用程式移至雲端 - AWS Re:cap Q1/2023
FSI Recap
03 Zurich Insurance Group:在 AWS 上建置有效的日誌管理解決方案
FSI Recap
04 FSI Meetup 2025 Q4 - Brex 資料庫災難復原
FSI Recap
05 FSI Meetup 2025 Q4 - Graviton 遷移成功案例
FSI Recap
06 FSI Meetup 2025 Q4 - Stifel 現代化資料平台
FSI Recap
07 FSI Meetup 2025 Q4 - PayPal 金融交易資料對帳器
FSI Recap
08 FSI Meetup 2025 Q4 - 擴展韌性
FSI Recap
09 最大化 AI 推論成本效益:策略性採用 AWS GPU 執行個體
FSI Recap
10 進階代理式 AI 設計模式
FSI Recap
11 在 AWS 上建置全新現代化應用程式
FSI Recap
AWS re:Invent 2025
01 Coinbase re:Invent 回顧 (IND3312)
AWS re:Invent 2025
02 利用 AI 和 AWS 構建未來交易平臺
AWS re:Invent 2025
03 交易創新:Jefferies 在 Amazon Bedrock 上的 AI 助理 (IND3315)
AWS re:Invent 2025
04 FSI 如何運用代理式 AI 徹底改造 HFT 分析 (GBL302)
AWS re:Invent 2025
05 透過 Amazon Time Sync 改善分散式系統,Nasdaq 專題分享
AWS re:Invent 2025
06 Amazon Aurora HA 與 DR 的全球韌性設計模式 (DAT442)
AWS re:Invent 2025
07 建構代理式 AI:Amazon Nova Act 與 Strands Agents 實務應用 (DEV327)
AWS re:Invent 2025
08 深入探討 Amazon Aurora 及其創新 (DAT441)
AWS re:Invent 2025
09 深入探討 Amazon S3 (STG407)
AWS re:Invent 2025
10 Nasdaq:為全球金融服務打造具彈性的基礎設施(HMC327)
AWS re:Invent 2025
11 AWS Lambda 的最新功能 (CNS376)
AWS re:Invent 2025
12 使用 Kiro 進行規格驅動開發 (DEV314)
AWS re:Invent 2025
13 Amazon 的 FinOps:全球電子商務巨擘的雲端成本經驗 (AMZ308)
AWS re:Invent 2025
14 AWS 上的 Tick-to-trade 延遲交易平台
AWS re:Invent 2025
政務資料
01 The AI Era: The Boundary Between Development and Design Is Disappearing
政務資料
02 裝置端多模態 AI 與智慧城市實踐
政務資料
03 大模型能力評測與 AI 專案落地方法論
政務資料
04 基於雲端代理的政府開發全鏈路受控自動化
政務資料
05 從多智能體看 Agent 時代軟體新生態
政務資料
06 AI 驅動的宏觀量化研究與智慧治理
政務資料
07 公共數據授權營運與智慧政務實踐
政務資料
08 数据资产化落地实践:确权合规、工程治理与数字政府案例
政務資料
09 AI技術賦能心理健康公益:可信平台的治理、架構與實踐
政務資料
Amarathon 2025 回顧
01 開發人員的代理架構設計路線圖
Donnie Prakoso
02 Amazon Bedrock 資料自動化
Hafiz Syed Ashir Hassan
03 AgentCore 上的多代理
Tan Xin
04 實務建置代理式 AI:Nova Act 與 Strands Agents
Haowen Huang
04 運用規格驅動開發,以 Kiro 加速移轉專案
Sanchit Dilip Jain
06 從「比對」到「理解」:由 AgentCore Memory 驅動的個人化 AI 搜尋實踐
Liu Cao
07 從觀察到最佳化:從 LLM 可觀測性邁向 AIOps,將即時洞察轉化為智慧自動化
Jimmy Soh
08 部署 TEAM 並打造最佳工程團隊
Yuji Oshima
09 五年來所謂無伺服器資料庫帶來的五個慘痛教訓
Renato Losio
14 如果 AI 替我工作會怎樣:Q Developer CLI 與 Kiro 如何改變我的日常工作
Miguel Angel Muñoz
16 兼顧速度與警覺:Amazon Bedrock Agent 開發的安全要點
Brian Tarbox
26 在單張 H100 上執行 OSS LLM:更聰明、更便宜、更快速
Adit Modi Adit Modi
28 現代化統一中繼資料架構:打破資料孤島的新方法
Shaofeng Shi
29 無伺服器 MediaOps:運用 Amazon Web Services 上的 AI 自動化影片工作流程
Luis Valdivia
30 透過大規模效能測試建構兼具效率與可靠性的架構
Luis Guirigay
31 透過開放原始碼連結世界:技術、社群與全球開發者關係的實踐歷程
Richard Lin
33 建置串流 Iceberg 資料表以進行即時物流分析
Fahad Shah
34 加速大規模機器人策略訓練:以 Kiro、Trainium 與 EKS 為基礎的自動化閉環架構
Junjie Tang
35 透過規格驅動開發,從 Vibe 走向可行方案
Ricardo Sueiras
36 讓雲端成本分析更智慧:使用 Strands 與 AgentCore 建置 FinOps 智慧 Agent
Xiaofei Li
37 使用 CNCF Kagent、K8sGPT 與 Nova Sonic,轉型 K8s 對話式 Agentic AIOps
Shaoyi Li

議程

從基礎開始

● 什麼是日誌管理,以及為何它對金融業組織至關重要

● 日誌管理在法規遵循、安全性與營運效率方面扮演的角色

探討金融機構在日誌管理方面面臨的獨特挑戰

● 處理大量資料

● 符合法規要求

● 管理成本

討論 Zurich 對日誌管理解決方案的具體目標

● 瞭解所採用的方法

深入探討解決方案的技術細節

● 概述所使用的主要 AWS 服務

● 說明可擴展性、成本效益與效率的設計原則

檢視所達成的成果與效益

● 將經驗應用於其他金融業組織

最後總結重點

● 為正在使用或評估使用 AWS 進行日誌管理的組織提供可執行的洞見


內容務實且貼近實際,著重於真實世界的策略,並為聽眾的實踐歷程提供啟發

從基本概念開始:

● 為什麼日誌管理在金融業很重要?

日誌管理的基礎

● 日誌來源:日誌來自伺服器、設備、網路裝置、雲端服務等

● 日誌收集:集中收集日誌對可視性與法規遵循至關重要

● 處理與分析:濾除雜訊、加入脈絡資訊,以及識別模式或警訊

● 儲存與保留:安全、有條理且長期的儲存(例如 S3 儲存層)對法規遵循至關重要

● 洞見與行動:運用資料取得可執行的洞見並採取因應措施

日誌管理對金融服務業至關重要,主要有三個原因:

● 法規遵循:監管機關要求提出已盡適當注意義務的證明,而日誌可作為證據。

● 安全性:日誌對及早偵測與緩解威脅至關重要。

● 營運效率:系統順暢運作能讓客戶、員工與監管機關都感到滿意。

● 日誌管理不只是收集資料,而是將資料轉化為有用的洞見,以保護系統、符合法規並提升營運效率。


主要痛點:

Zurich 在日誌管理方面面臨的具體挑戰:

● 集中式日誌記錄的成本可能迅速攀升。

● 原有方法將所有日誌一視同仁,把一切都存放在高成本儲存空間,並將所有日誌當作關鍵資料處理,導致成本快速增加。

資料量:

● 金融服務業會從各種來源產生大量日誌資料(防火牆規則、存取嘗試、弱點掃描等)。

● 由於需要處理敏感資料,安全系統每天會產生數 TB 的日誌。

● 並非所有安全日誌都同等重要;有些可以稍後分析,而關鍵警示則需要立即處理。

法規遵循要求:

● PCI DSS 與 GDPR 等法規要求保留日誌(例如為稽核保留七年)及詳細的存取紀錄。

● 要確保日誌安全、防竄改且可供存取,同時又不產生過高成本,是一項挑戰。

成本效益:

● 在完整日誌管理需求與具成本效益的解決方案之間取得平衡至關重要。


將所有日誌一視同仁會造成資源浪費:

● 並非所有日誌都需要高成本的即時處理。

● 範例:一次性的偵錯日誌,與包含安全關鍵資訊的 API 存取日誌。

● 需要根據日誌的重要性與潛在用途進行儲存和保留。

複雜性與整合挑戰:

● 日誌來自採用不同格式的各種來源(舊式系統、雲端服務、應用程式、裝置)。

● 在系統之間轉換可能造成延遲與監控盲區。

● 範例:弱點管理系統與 CASB 工具(Cloud Access Security Broke)採用不同格式。

安全性與即時分析:

● SIME(安全資訊與事件管理)日誌對威脅偵測與因應至關重要。

● 需要快速且有效率地分析日誌,以偵測模式(例如登入失敗嘗試可能表示暴力破解攻擊)。

● 信任在金融業至關重要,因此及時偵測威脅不可或缺。

挑戰摘要:

● 龐大的資料量

● 嚴格的法規遵循要求

● 高昂的日誌記錄成本

● 混亂的整合作業

● 即時安全性的需求

解決方案目標:

● 現代化日誌管理方法:

● 不再將每一筆日誌一視同仁。

● 使用可擴展的工具,依重要性排定資料收集的優先順序。

降低成本:

● 在不犧牲效能與法規遵循的前提下,降低每 GB 的擷取成本。

● 在擷取前濾除不必要的日誌,以更聰明的方式管理資料。


淘汰舊有 SIME(安全資訊與事件管理)基礎設施:

● 停用舊式系統,以減少技術債、高額維護成本、效能緩慢及擴展能力有限等問題。

● 釋出資源,投入更現代化且有效率的解決方案。

改善分析效能:

● 降低延遲並縮短日誌搜尋時間,以更快取得洞見並進行即時決策。

● 著重提供更佳效能,避免不必要的延遲。

目標摘要:

● 實現更聰明的日誌管理,以降低成本、簡化環境並提供更佳效能。

● 專注於最重要的事項。


解決方案架構:

依重要性排定日誌優先順序:

● 高優先順序日誌(例如安全事件)會路由至即時分析。

● 較低優先順序日誌(例如法規遵循相關日誌)則存放在 S3 等具成本效益的封存空間。

● 確保資源集中於關鍵資料,同時控制成本。

ETL 管線:

● 如同日誌的交通指揮,濾除不必要的資料以降低擷取成本。

● 以額外的中繼資料豐富資料內容,讓日誌更具可操作性。

● 將資料路由至適當目的地(即時分析或長期儲存)。

● 這對降低每 GB 擷取成本,以及確保有價值的資料能在需要之處使用至關重要。

將日誌路由至 SIME 與 AWS 基礎設施:

● 經過優先排序和處理後,日誌會導向 SIME(安全資訊與事件管理)與 AWS 基礎設施,以進行進一步分析和儲存。


AWS 基礎設施元件及其角色:

Amazon OpenSearch Service:

● 透過快速日誌搜尋實現即時分析。

● 為 DevOps 與安全團隊提供儀表板和監控工具。

● 有助於快速找出根本原因(例如登入失敗嘗試突然激增)。

Amazon S3:

● 儲存所有日誌以供法規遵循使用。

● 可擴展、安全且具成本效益。

● 非常適合法規遵循需求。

AWS Glue 與 Data Catalog:

● 整理日誌並使其可供搜尋。

● 減少搜尋原始資料所花費的時間。

Amazon Athena:

● 無須移動資料,即可直接查詢 S3 中的資料。

● 適合以具成本效益的方式進行深入調查與臨時分析。

● 適用於調查潛在的法規遵循問題。


結合資料優先排序、ETL 功能與 AWS 服務:

● 將日誌管理方法現代化。

● 僅儲存及處理最重要的日誌,以降低成本。

● 停用舊式 SIME(安全資訊與事件管理)系統,以簡化基礎設施。

● 透過更快速的日誌搜尋和更完善的分析來改善效能。

解決方案的效益與成果:

節省成本:

● 將 SIME(安全資訊與事件管理)的擷取量從每天 5 TB 降至每天 500 GB。

● 透過部署具備版本控制與自動備份功能的 Cribl 達成。

● 在擷取前濾除不必要的日誌。

● 使用 Terraform 快速擴展。

效能改善:

● 用於計算每個防火牆事件數量的範例查詢,執行時間從 93 秒縮短至 2 秒。

● OpenSearch 經證實速度快且易於管理。

● 一鍵部署與升級。

● 使用具版本控制的 Terraform,實現一致且可靠的推出作業。

清理環境並減少技術債:

● 停用舊有 SIME(安全資訊與事件管理)基礎設施,消除技術債。

● 轉換至簡潔、現代化的架構。

可擴展性:

● 使用 S3 等 AWS 服務進行分層資料儲存(頻繁存取、低頻存取及 Glacier)。

● 使用 Terraform 快速擴展 Cribl 與其他元件。

● 系統可隨組織需求成長。

法規遵循與安全性:

● 日誌安全地存放於 S3,並可在 OpenSearch 中輕鬆搜尋。

● 讓法規報告與安全監控更快速、更簡單且更可靠。


從這段歷程中學到的主要經驗:

優先處理正確的資料:

● 並非所有日誌都相同;應根據重要性分別處理。

● Zurich 透過優先處理關鍵日誌,將擷取成本降低了 50% 以上。

投資現代化工具:

● 使用針對當前挑戰而設計的工具(例如 Cribl、AWS OpenSearch、S3)。

● 這些工具可隨組織無縫擴展。

透過自動化確保一致性:

● 運用自動化(例如 Terraform)進行部署、升級和擴展。

● 減少人為錯誤,並讓團隊能投入策略性工作。

超越法規遵循的思維:

● 現代化日誌管理可提供更快速的搜尋、即時洞見與更完善的安全監控。

● 著重讓資料為組織創造效益,而不只是符合法規要求。

摘要:

● 更聰明的日誌管理方法能帶來徹底轉變。

● 優先處理重要事項、投資現代化工具、將流程自動化,並以超越法規遵循的角度思考。


日誌管理的未來計畫:

持續專注於節省成本:

● 改良 S3 分層策略,以最佳化儲存效率。

● 根據使用情況,在頻繁存取、低頻存取與 Glacier 儲存層之間移動日誌。

擴大自動化:

● 使用 Terraform 進一步簡化擴展與組態更新。

● 目標是打造幾乎能自行運作的基礎設施。

整合進階分析:

● 運用 OpenSearch 內建的機器學習功能,例如異常偵測。

● 在日誌資料中的異常模式惡化之前加以掌握。

匯入並最佳化 SIME 關聯搜尋與警示:

● 持續從舊式 SIME(安全資訊與事件管理)轉移,將這些項目匯入 OpenSearch 並加以最佳化。

● 在採用現代化平台的同時,維持高標準的監控。

強化資料治理:

● 使用 AWS Glue 等工具強化中繼資料管理。

● 維持日誌井然有序,並提前因應法規遵循要求。

探索結合 OpenSearch 的生成式 AI:

● 使用 OpenSearch 作為向量資料庫,為 AI 使用案例提供檢索增強生成(RAG)能力。

● 範例:使用日誌訓練 AI 模型,在系統問題發生前加以預測。