亚马逊AWS官方博客

awschina

Author: awschina

为游戏业务团队构建只读代码问答 Agent:架构、性能与安全实践

游戏规则、数值和活动配置最终由代码与项目配置决定。策划、测试、运营和客服在核对规则或处理玩家反馈时,往往需要研发协助定位实现,零散问题因此反复打断研发工作。为缩短这条确认链路,我们构建了一套只读代码问答 Agent:代码副本和索引集中保存在常驻服务中,会话环境只通过 HTTP 上的只读 MCP 工具查询代码和配置。本文分别从业务体验和技术实施角度,介绍方案功能、准确性机制、安全边界、性能、管理方式与成本,并结合合成样本测试和游戏客户的试用结果说明实际表现。

地理空间 AI 智能体(Code Agent)中国区部署实践

在农业遥感监测、自然资源调查、城市规划、碳汇核算、保险定损等领域,企业客户日益需要对卫星影像进行快速分析。传统工作流要求GIS专业人员编写Python代码处理遥感数据,门槛高、周期长、成本大。亚马逊云科技开源项目 sample-geospatial-code-agent(https://github.com/aws-samples/sample-geospatial-code-agent)提供了一套AI智能体方案,让非技术用户也能通过自然语言完成专业级遥感分析。该方案采用Code Agent架构——LLM直接生成Python脚本执行,中间数据留在内存不回传上下文,相比传统Tool Agent在遥感分析场景中速度更快、成本更低。但原项目基于海外区服务生态构建,其底图方案(Google/CARTO瓦片)和部分托管服务无法在中国区直接运行,需要针对中国区进行适配。

混合云架构下秒级多维网络监控方案

本文介绍一种面向混合云、跨可用区及本地数据中心网络链路的秒级主动拨测方案。方案通过部署轻量探针 Agent,在探测端使用 fping 与 nping 分别覆盖 ICMP 与 TCP SYN 场景,并结合 EC2 实例元数据、Prometheus、Grafana 与通知渠道,实现按源实例、私网 IP、可用区、目标端点和探测方式维度聚合的网络质量可观测能力。

使用开源身份提供商 Keycloak 实现 Amazon Quick 多端 SSO——从部署到SAML + OIDC 双协议集成与验证

在智能建筑和物业管理领域,IoT 设备的稳定运行对业务连续性至关重要。物业公司通常通过 IoT 平台管理大楼的设施设备,实时采集并记录设备报送的各类指标数据(如温度、湿度、压力等)。然而,设备离线、网络故障、平台问题等异常情况时有发生,传统的监控方式往往只能提供统计图表,关联分析比较困难,难以快速定位问题根源,影响了问题发现和处理的效率。本文以某客户智能建筑管理场景为例,介绍如何利用亚马逊云科技的无服务器(Serverless)来构建一套近实时(分钟级)的 IoT 设备异常检测系统,实现从数据采集、实时分析到告警的全流程自动化,面对大量 IoT 设备数据能够在数分钟内识别出设备的异常,为物业企业提供可靠的设备监控能力。

基于 Auto Scaling 实现油气智慧基地 AI 视频日报系统的优雅扩缩容

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

基于Direct Connect和Transit Gateway实现全球视频会议双中心组网方案—中国出海企业全球视频会议网络架构设计与落地实践

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

ECS + CodePipeline 企业轻量级容器化 CI/CD 实战—基于 GitHub + CodePipeline + CodeBuild + ECS Fargate 的全托管容器化部署方案

在企业应用现代化过程中,容器化部署已成为主流选择。然而,很多企业在评估容器编排方案时,往往默认考虑 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 即自动构建镜像并滚动更新线上服务——全程零停机。

从大模型训练与推理出发:亚马逊云科技容器环境 IP 消耗、规划与 VPC CNI 优化

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