亚马逊AWS官方博客
AWS 一周综述:欢迎 DuckLabs 加入 AWS 团队,代理资源发现(ARD)等(2026 年 8 月 31 日)
上周最让我感兴趣的新闻是收购 DuckLabs。AWS 已签署收购 DuckLabs 的最终协议,DuckLabs 是一家总部位于阿姆斯特丹的公司,也是热门开源分析数据库 DuckDB 的开发商,DuckDB 可在进程内运行,并直接针对 Parquet、CSV 和 JSON 等文件执行 SQL。DuckDB 将继续保持开源,由其独立基金会和 MIT 许可证管理。AWS 计划逐步将 DuckDB 在日常查询方面的速度优势与 Amazon S3、Amazon Redshift 和 Amazon Athena 等企业级服务的规模优势相结合。
构建云原生 AI 图像&视频素材设计平台:从零到生产的架构实践
我们为客户从零搭建了一个面向设计师的 AI 图像与视频素材生成平台——Open Gallery,一个统一的工作台,能调用不同的 AI 模型,在同一个画布上完成从创意到成品的全流程,这个过程中的技术决策,思考过程,遇到了哪些问题,以及最终如何解决
Story2Video 技术实践:从故事文本到可发布短视频的 AIGC Pipeline
内容创作团队常常面临一个问题:把一段故事线快速转成可发布的短视频,涉及脚本、分镜、配音、口型同步和字幕,链路长且难以维持一致性。在这篇文章中,我们向面向视频生成的架构师、AI 工程师和内容平台团队展示如何使用 Amazon Bedrock、ComfyUI 和 Fish-Speech 组合出一条端到端的 AIGC pipeline
企业级 EKS 集群生产环境配置最佳实践
从私有 cluster endpoint、VPC Endpoints、Pod Identity 替代 IRSA,到双 EBS + LVM 隔离容器运行时与四种 CSI Driver 接入,本文把企业级 EKS 的生产配置决策逐项讲透,并沉淀为一套开源 Terraform 模块:一次 apply 约 30 分钟建成集群,配 9 项健康检查验收。
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 模块完整实现。
用 Amazon DynamoDB 构建无需双写的 Agent Memory 与语义检索
本文用一个可运行的 Agent 长期记忆场景,说明如何把业务属性和 embedding 放进同一条 item,用一次 PutItem 完成写入,用 SearchVectors 完成语义召回;同时给出这套设计在真实项目里需要提前验证的几个点,以及它明确不适合的场景。
大规模数据库迁移中的 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 相似度检索补上”新写代码无签名、系统性漏检”的缺口。
把 RDS MySQL 数据入仓 Amazon Redshift 的三种方式 · 首推 Zero-ETL
从”手工搬 CSV”到”零代码近实时同步”,围绕同一个 RDS for MySQL → Redshift Serverless 场景,本文完整走通三条主流路径,对比它们的架构、成本、运维与延迟,并给出选型建议。