亚马逊AWS官方博客

EKS 上的 GPU 工作负载:节点、网络与高性能存储的架构实践

本文是《企业级 EKS 集群生产环境配置最佳实践》系列第二篇,承接第一篇搭建的生产级 EKS 基础,聚焦 GPU 工作负载链路的深度架构实践。文章围绕 GPU 工作负载的三层架构 —— 计算节点、网络邻近性、高性能存储 —— 展开,覆盖 P5 / P5e / P5en / P6(B200 / B300) / G6e / G7e / G7 等 GPU 实例系列的 EFA 多网卡精确摆位(含 p6-b300 非对称拓扑)、四种定价模式的 Launch Template 设计、基于 topology.k8s.aws/network-node-layer-N 的 AWS 原生拓扑感知调度,以及 FSx for Lustre(PERSISTENT_2)与 S3 Express One Zone + Mountpoint CSI Driver 这两类高性能存储按访问模式的选型,并以一套声明式 Terraform 模块完整实现。

大规模数据库迁移中的 CDC 吞吐优化实践

当 AWS Database Migration Service (DMS) 单任务无法追平高写入量源库的 CDC 延迟时,如何在不增加源库压力的前提下提升同步吞吐?本文介绍基于 Amazon MSK Connect + Debezium 的读写解耦方案:单连接读取 binlog,多 Task 并行写入 Aurora MySQL,实现 N 倍吞吐提升。

用数据选型:StarRocks 跨架构(arm64 vs x86)基准测试记录

许多团队在 Amazon EC2 上自建 StarRocks 做实时分析,但选型时往往缺乏同口径的跨架构对比数据。本文基于 TPC-H / TPC-DS SF1000 基准,在 StarRocks 存算分离架构下,横评 Graviton(arm64)与 x86 同规格实例的查询性能与价格性能,给出可复现的量化结论——帮助你用数据而非直觉做出选型决策。

在企业环境中为 AI 编程工具构建内容审查层

本文探讨在企业环境中为 AI 编程工具(如 AWS Kiro)构建内容审查层(DLP)的完整技术方案。文章将问题拆分为两条互斥路径:能改模型端点的自研应用(通过 LiteLLM 统一网关)和不能改端点的闭源工具(通过透明 MITM 拦截)。核心论点是:内容审查只能发生在能拿到明文的点,而内容型 DLP 本质上是 best-effort 检知而非硬预防。后半篇深入架构设计,部署语义审查小模型在自有 VPC 内(避免二次外发),并提出用 RAG 相似度检索补上”新写代码无签名、系统性漏检”的缺口。

将 Dify 工作流迁移至 Amazon Bedrock AgentCore 的实践与验证

新版 Dify 把工作流执行引擎从平台中解耦为一个独立的 Python 库 graphon。迁移一条 workflow 因此只需安装这个库并适配少数几类节点,不必搬整个平台。我们用一个 PoC 验证了这条路径。一条 20 步的 KYB(商户准入尽调)workflow,覆盖调模型、调代码、调知识库和多路判断,业务逻辑一行不改,通过自定义 node factory 部署并运行在 AgentCore Runtime 上,云端 5 条分支路径全部验证通过。同一份 DSL 还能导回 Dify 画布渲染。本文给出这条路径的做法、部署证据,以及版本风险和生产化前需要补齐的边界。

当知识可以被”编译” —— LLM Wiki 企业级实践的三道坎

传统 RAG 在每次查询时重新检索、重新拼装答案——源文档像被反复”解释执行”的脚本。LLM Wiki 换了一条路:在文档入库时预先”编译”为结构化知识页,此后持续维护、增量更新。经过四个月的实践,我们逐渐遇到了企业级落地中三个绕不开的”坎”。本文拆解这些挑战的根因,介绍基于 Amazon Bedrock、AWS Step Functions 与 Amazon S3 的解法,并给出生产环境中的量化验证。

从分钟到秒级 —— Amazon Advanced JDBC Wrapper 插件最佳实践

数据库的计划内变更(版本升级、打补丁、规格调整)和计划外故障(实例 Failover),都会让应用经历一段连接中断。多数团队会把优化目光投向数据库实例本身,却忽略了一个事实:客户端的连接行为往往是中断被放大的主因。Amazon Web Services Advanced JDBC Wrapper(下称 JDBC Wrapper)正是从这个角度切入——它包裹在现有 JDBC 驱动之外,让 Java 应用主动感知数据库拓扑变化、提前调度连接,把切换中断压到秒级。本文从原理到实测,拆解它是怎么做到的。