亚马逊AWS官方博客

本文聚集某油气行业客户在油气智慧基地平台上的 AI 视频日报系统优雅扩缩容的需求，提出了针对计算密集型工作负载在对成本和时效性都有较高要求的场景下，基于 Auto Scaling 实现的优雅扩缩容的解决方案。该方案在对原系统最小修改的原则下，基于自定义监控指标、Auto Scaling的 Target Tracking 策略和 Lifecycle Hook 实现了系统的高峰期自动扩容、低谷期优雅缩容，避免了任务被中途强制终止，以达到成本和时效性的最优解。

随着中国企业加速全球化布局，越来越多的出海企业在海外设立分支机构和生产基地。我们在服务某大型出海企业的过程中发现，其海外机构分布在欧洲、南美、非洲等多个大洲，总部与海外分支之间的视频会议协同面临着独特的网络挑战：（1）中国总部为核心：所有重大决策和管理会议均以中国总部为中心，总部侧网络质量直接影响全球协同效率 （2）海外站点分散：海外分支机构分布在欧洲（法兰克福）、南美（圣保罗）、非洲（开普敦），彼此之间也有频繁的跨区域会议需求 （3）跨境网络复杂：中国到海外的互联网质量波动大，传统VPN方案难以保障视频会议的稳定性和低延迟 （4）合规与安全：企业对数据传输的安全性和合规性有严格要求，需要专线级别的网络保障。本文介绍如何利用亚马逊云科技的网络服务，为中国出海企业构建全球视频会议双中心高可用组网方案。

在企业应用现代化过程中，容器化部署已成为主流选择。然而，很多企业在评估容器编排方案时，往往默认考虑 Kubernetes（EKS），却忽视了其带来的巨大运维复杂性：Ingress Controller 配置、Helm Chart 管理、RBAC 策略、集群升级等问题让开发团队苦不堪言。对于大多数企业级 Web 应用、API 服务和微服务场景，Amazon ECS（Elastic Container Service）配合 Fargate 无服务器计算引擎，提供了一种更为轻量级、开箱即用的容器部署方案。结合 亚马逊云科技 CodePipeline 和 亚马逊云科技 CodeBuild，可以快速搭建一套完整的 CI/CD 流水线，实现代码提交即自动构建、测试、部署。本文介绍如何使用 GitHub + CodePipeline + CodeBuild + ECR + ECS Fargate 实现企业级容器化 CI/CD，实现 git push 即自动构建镜像并滚动更新线上服务——全程零停机。

今天，我们宣布计划在柏林、海得拉巴和圣保罗开设新的 Builder Loft。每个地点都将成为永久的社区空间，为想要走进大门的开发人员、学生或技术专业人员提供免费讲习会、社交活动、推介之夜、内容创作空间、协作/共享办公区以及举办活动。

EC2 应用程序状态检查、IAM 角色管理器、Bedrock 上的 OpenAI Daybreak 等

本文介绍如何将 NousResearch 开源的 Hermes Agent 部署到 Amazon Bedrock AgentCore 的托管运行时 AgentCore Runtime 上，并使用 AWS Cloud Development Kit (AWS CDK) 以基础设施即代码的方式实现全部资源，支持 Telegram、Slack、Discord、飞书和微信等渠道接入。

本文源于大模型训练与推理场景中的一个实际问题：大型GPU节点通常只运行少量Pod，但Amazon VPC CNI可能预留大量IP，从而造成子网地址浪费，并影响训练集群扩容和推理服务弹性。文档由此延伸到EKS、ECS和自建Kubernetes在EC2/VPC中的IP消耗、容量突增、升级与蓝绿并存风险，以及相应的规划和治理方案。本文面向负责或参与AI/ML平台、亚马逊云科技容器平台、网络和容量规划的读者

Amazon Quick 分 Web 与 Desktop 两个端，分别使用 SAML 2.0 与 OIDC + PKCE 两种认证协议，二者必须收敛到同一个身份提供方（IdP）才能实现单点登录（SSO）。本文面向自建 IdP 的开发方，给出用自建 IdP 打通 Amazon Quick 两端 SSO 的完整对接实战：Desktop 侧复用现有 OIDC 能力，Web 侧为 IdP 增补 SAML 2.0 直连。

Mantle 是 Amazon Bedrock 的新一代推理引擎，OpenAI 的 GPT-5.6（Sol / Terra / Luna）等模型由它提供服务，通过 OpenAI 兼容的 bedrock-mantle 端点对外暴露。它与承载 Claude 的经典 bedrock-runtime 端点在协议上并不一致：前者用 Chat Completions / Responses，后者用 Converse / InvokeModel。本文用一台 EC2 上的 LiteLLM 网关（测试形态，生产化建议见文中）把两个端点收敛到同一个入口，实测供出 9 个模型（GPT-5.6 三变体、GPT-5.5、GPT-5.4、gpt-oss 两款、Claude 两款），客户端只认一个地址、一个 key，网关侧完全用 EC2 实例角色做 SigV4 认证，不落盘任何 API key。文中还给出一个 92 行的 pre-call 钩子，解决 Codex 客户端与 Mantle 的请求体不兼容问题，让 Codex 和 opencode 共用同一套网关。

AWS Heroes Summit、Amazon Bedrock 上的 Web 搜索、Dogwood、Kiro Crew 等