AWS代付、代实名
阿里云国际 | 腾讯云国际

Amazon DynamoDB now supports more granular throttle error exceptions

AWS账单代付阅读(30)

Amazon DynamoDB now supports more granular throttle error exceptions

DynamoDB now supports more granular throttling exceptions along with their corresponding Amazon CloudWatch metrics. The additional fields in the new throttling exceptions identify the specific resources and reasons for throttling events, making it easier to understand and diagnose throttling-related issues.

You can see the new Amazon CloudWatch metrics immediately, and upon upgrading your SDK to the newest version, you will also see the new granular throttling exceptions. Every throttling exception now contains a list of reasons why the request was throttled, as well as the Amazon Resource Name (ARN) of the table or index that was throttled. These new throttle exception reasons help you understand why you were throttled and enable you to take corrective actions like adjusting your configured throughput, switching your table to on-demand capacity mode, or optimizing data access patterns.

The more granular throttling exceptions and their respective metrics are available in all commercial AWS Regions, the AWS GovCloud (US) Regions, and the China Regions.

To get started see the following list of resources:

  • Diagnosing throttling issues in the DynamoDB developer guide
  • Enhanced throttling observability in Amazon DynamoDB blog post
  • Troubleshooting throttling in the DynamoDB developer guide

Amazon EC2 R8g instances now available in AWS Asia Pacific (Jakarta)

AWS账单代付阅读(29)

Amazon EC2 R8g instances now available in AWS Asia Pacific (Jakarta)

Starting today, Amazon Elastic Compute Cloud (Amazon EC2) R8g instances are available in AWS Asia Pacific (Jakarta)region. These instances are powered by AWS Graviton4 processors and deliver up to 30% better performance compared to AWS Graviton3-based instances. Amazon EC2 R8g instances are ideal for memory-intensive workloads such as databases, in-memory caches, and real-time big data analytics. These instances are built on the AWS Nitro System, which offloads CPU virtualization, storage, and networking functions to dedicated hardware and software to enhance the performance and security of your workloads.

AWS Graviton4-based Amazon EC2 instances deliver the best performance and energy efficiency for a broad range of workloads running on Amazon EC2. AWS Graviton4-based R8g instances offer larger instance sizes with up to 3x more vCPU (up to 48xlarge) and memory (up to 1.5TB) than Graviton3-based R7g instances. These instances are up to 30% faster for web applications, 40% faster for databases, and 45% faster for large Java applications compared to AWS Graviton3-based R7g instances. R8g instances are available in 12 different instance sizes, including two bare metal sizes. They offer up to 50 Gbps enhanced networking bandwidth and up to 40 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS).

To learn more, see Amazon EC2 R8g Instances. To explore how to migrate your workloads to Graviton-based instances, see AWS Graviton Fast Start program and Porting Advisor for Graviton. To get started, see the AWS Management Console.


Amazon Athena now supports CREATE TABLE AS SELECT with Amazon S3 Tables

AWS账单代付阅读(35)

Amazon Athena now supports CREATE TABLE AS SELECT with Amazon S3 Tables

Amazon Athena now supports CREATE TABLE AS SELECT (CTAS) statements with Amazon S3 Tables. Using CTAS statements makes it simple to create a new table and populate it with data using the results of a SELECT query. You can now use CTAS statements in Athena to query existing datasets and create a new table in S3 Tables with the query results, all in a single SQL statement.

S3 Tables deliver the first cloud object store with built-in Apache Iceberg support and streamline storing tabular data at scale. With today’s launch, you can quickly and efficiently convert existing datasets stored in Parquet, CSV, JSON, and other formats, including Apache Iceberg, Hudi, and Delta Lake, into fully-managed tables that are continually optimized for performance and cost. Once created, use Athena to analyze your data, JOIN it with other datasets, and evolve it over time using INSERT and UPDATE operations. Using CTAS, you can partition the data on the fly, giving you flexibility to optimize query performance for different use cases.

You can use CTAS to create S3 Tables in all AWS Regions where both Athena and S3 Tables are supported. To learn more, see the Amazon Athena User Guide.


Celebrating 10 years of Amazon Aurora innovation

AWS账单代付阅读(32)

AWS News Blog

Celebrating 10 years of Amazon Aurora innovation

|

Ten years ago, we announced the general availability of Amazon Aurora, a database that combined the speed and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases.

As Jeff described it in its launch blog post: “With storage replicated both within and across three Availability Zones, along with an update model driven by quorum writes, Amazon Aurora is designed to deliver high performance and 99.99% availability while easily and efficiently scaling to up to 64 TiB of storage.”

When we started developing Aurora over a decade ago, we made a fundamental architectural decision that would change the database landscape forever: we decoupled storage from compute. This novel approach enabled Aurora to deliver the performance and availability of commercial databases at one-tenth the cost.

This is one of the reasons why hundreds of thousands of AWS customers choose Aurora as their relational database.

Today, I’m excited to invite you to join us for a livestream event on August 21, 2025, to celebrate a decade of Aurora database innovation.

A brief look back at the past

Throughout the evolution of Aurora, we’ve focused on four core innovation themes: security as our top priority, scalability to meet growing workloads, predictable pricing for better cost management, and multi-Region capabilities for global applications. Let me walk you through some key milestones in the Aurora journey.

We previewed Aurora at re:Invent 2014, and made it generally available in July 2015. At launch, we presented Aurora as “a new cost-effective MySQL-compatible database engine.”

In June 2016, we introduced reader endpoints and cross-Region read replicas, followed by AWS Lambda integration and the ability to load tables directly from Amazon S3 in October. We added database cloning and export to Amazon S3 capabilities in June 2017 and full compatibility with PostgreSQL in October that year.

The journey continued with the serverless preview in November 2017, which became generally available in August 2018. Global Database launched in November 2018 for cross-Region disaster recovery. We introduced blue/green deployments to simplify database updates, and optimized read instances to improve query performance.

In 2023, we added vector capabilities with pgvector for similarity search for Aurora PostgreSQL, and Aurora I/O-Optimized to provide predictable pricing with up to 40 percent cost savings for I/O-intensive applications. We launched Aurora zero-ETL integration with Amazon Redshift which enables near real-time analytics and ML using Amazon Redshift on petabytes of transactional data from Aurora by removing the need for you to build and maintain complex data pipelines that perform extract, transform, and load (ETL) operations. This year we added Aurora MySQL zero-ETL integration with Amazon Sagemaker, enabling near real-time access of your data in the lakehouse architecture of SageMaker to run a broad range of analytics.

In 2024, we made it as effortless as just one click to select Aurora PostgreSQL as a vector store for Amazon Bedrock Knowledge Bases and launched Aurora PostgreSQL Limitless Database, a serverless horizontal scaling (sharding) capability.

To simplify scaling for customers, we also increased the maximum storage to 128 TiB in September 2020, allowing many applications to operate within a single instance. Last month, we’ve further simplified scaling by doubling the maximum storage to 256 TiB, with no upfront provisioning required and pay-as-you-go pricing based on actual storage used. This enables even more customers to run their growing workloads without the complexity of managing multiple instances while maintaining cost efficiency.

Most recently, at re:Invent 2024, we announced Amazon Aurora DSQL, which became generally available in May 2025. Aurora DSQL represents our latest innovation in distributed SQL databases, offering active-active high availability and multi-Region strong consistency. It’s the fastest serverless distributed SQL database for always available applications, effortlessly scaling to meet any workload demand with zero infrastructure management.

Aurora DSQL builds on our original architectural principles of separation of storage and compute, taking them further with independent scaling of reads, writes, compute, and storage. It provides 99.99% single-Region and 99.999% multi-Region availability, with strong consistency across all Regional endpoints.

And in June, we launched Model Context Protocol (MCP) servers for Aurora, so you can integrate your AI agents with your data sources and services.

Let’s celebrate 10 years of innovation

By attending the August 21 livestream event, you’ll hear from Aurora technical leaders and founders, including Swami Sivasubramanian, Ganapathy (G2) Krishnamoorthy, Yan Leshinsky, Grant McAlister, and Raman Mittal. You’ll learn directly from the architects who pioneered the separation of compute and storage in cloud databases, with technical insights into Aurora architecture and scaling capabilities. You’ll also get a glimpse into the future of database technology as Aurora engineers share their vision and discuss the complex challenges they’re working to solve on behalf of customers.

The event also offers practical demonstrations that show you how to implement key features. You’ll see how to build AI-powered applications using pgvector, understand cost optimization with the new Aurora DSQL pricing model, and learn how to achieve multi-Region strong consistency for global applications.

The interactive format includes Q&A opportunities with Aurora experts, so you’ll be able to get your specific technical questions answered. You can also receive AWS credits to test new Aurora capabilities.

If you’re interested in agentic AI, you’ll particularly benefit from the sessions on MCP servers, Strands Agents, and how to integrate Strands Agents with Aurora DSQL, which demonstrate how to safely integrate AI capabilities with your Aurora databases while maintaining control over database access.

Whether you’re running mission-critical workloads or building new applications, these sessions will help you understand how to use the latest Aurora features.

Register today to secure your spot and be part of this celebration of database innovation.

To the next decade of Aurora innovation!— seb


AWS named as a Leader in 2025 Gartner Magic Quadrant for Strategic Cloud Platform Services for 15 years in a row

AWS账单代付阅读(30)

AWS News Blog

AWS named as a Leader in 2025 Gartner Magic Quadrant for Strategic Cloud Platform Services for 15 years in a row

|

On August 4, 2025, Gartner published its Gartner Magic Quadrant for Strategic Cloud Platform Services (SCPS). Amazon Web Services (AWS) is the longest-running Magic Quadrant Leader, with Gartner naming AWS a Leader for the fifteenth consecutive year.

In the report, Gartner once again placed AWS highest on the “Ability to Execute” axis. We believe this reflects our ongoing commitment to giving customers the broadest and deepest set of capabilities to accelerate innovation as well as unparalleled security, reliability, and performance they can trust for their most critical applications.

Here is the graphical representation of the 2025 Magic Quadrant for Strategic Cloud Platform Services.

Gartner recognized AWS strengths as:

Largest cloud community– AWS has built a strong global community of cloud professionals, providing significant opportunities for learning and engagement. Cloud-inspired silicon– AWS has used its cloud computing experience to develop custom silicon designs, including AWS Graviton, AWS Inferentia, and AWS Trainium, which enable tighter integration between hardware and software, improved power efficiency, and greater control over supply chains. Global scale and operational execution– AWS’s significant share of global cloud market revenue has enabled it to build a larger and more robust network of integration partners than some other providers in this analysis, which in turn helps organizations successfully adopt cloud.

The most common feedback I hear from customers is that AWS has the largest and most dynamic cloud community, making it easy to ask questions and learn from millions of active customers and tens of thousands of partners globally. We recently launched our community hub, AWS Builder Center to connect directly with AWS Heroes and AWS Community Builders. You can also explore and join AWS User Groups and AWS Cloud Clubs in a city near you.

We have also focused on facilitating the digital transformation of enterprise customers through a number of enterprise programs, such as the AWS Migration Acceleration Program. Using generative AI on migration and modernization, we introduced AWS Transform, the first agentic AI service developed to accelerate enterprise modernization of mission-critical business workloads such as .NET, mainframe, and VMware.

Access the complete full Gartner report to learn more. It outlines the methodology and evaluation criteria used to develop their assessments of each cloud service provider included in the report. This report can serve as a guide when choosing a cloud provider that helps you innovate on behalf of your customers.

— Channy

*Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.* *GARTNER is a registered trademark and service mark of Gartner and Magic Quadrant is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.*


AWS 一周综述:SQS 公平队列、CloudWatch 生成式人工智能可观测性等(2025 年 7 月 28 日)

AWS账单代付阅读(33)

亚马逊AWS官方博客

AWS 一周综述:SQS 公平队列、CloudWatch 生成式人工智能可观测性等(2025 年 7 月 28 日)

说实话,我还没从纽约 AWS Summit 中缓过劲儿来,正在努力了解 Amazon Bedrock AgentCore(预览版)和 Amazon Simple Storage Service(S3)Vectors 等发布内容。有很多新东西要学习!

同时,对于专注于可靠性和可观测性的 AWS 构建者来说,这是激动人心的一周。最引人注目的公告一定是 Amazon SQS 公平队列,该功能解决了多租户架构中最持久的挑战之一:“噪声邻居”问题。如果您曾经遇到过一个租户的消息处理使共享基础设施不堪重负并影响其他租户的情况,那么您一定会喜欢此功能,因为它在应用程序之间实现了更均衡的消息分发。

在人工智能方面,我们还看到,AWS 通过推出 Amazon CloudWatch 生成式人工智能可观测性的预览版,继续增强我们的可观测性能力。这将人工智能驱动的洞察直接带入您的监控工作流,帮助您以新的方式了解基础设施和应用程序性能模式。对于那些管理 Amazon Connect 环境的人来说,为消息模板附件添加 AWS CloudFormation 可以更轻松地在不同的环境中以编程方式部署并管理电子邮件活动资产。

上周发布的内容

  • Amazon SQS 公平队列 – AWS 推出了 Amazon SQS 公平队列,旨在帮助缓解多租户系统中的“噪声邻居”问题,实现更均衡的消息处理并提高共享基础设施中的应用程序韧性。
  • Amazon CloudWatch 生成式人工智能可观测性(预览版)– AWS 推出了 Amazon CloudWatch 生成式人工智能可观测性的预览版,使用户能够通过高级监控和分析功能获得由人工智能驱动的对云基础设施和应用程序性能的洞察。
  • Amazon Connect CloudFormation 对消息模板附件的支持 – AWS 推出了对出站活动消息模板附件的 AWS CloudFormation 支持,从而扩展了 Amazon Connect 的功能,使客户能够以编程方式管理并部署不同环境中的电子邮件活动附件。
  • Amazon Connect 预测编辑 – Amazon Connect 推出了新的预测编辑用户界面,使联络中心规划人员能够根据特定日期范围、队列和渠道的百分比或精确值快速调整预测,以实现更快的员工队伍规划。
  • 适用于 Amazon ElastiCache 的 Bloom 筛选条件 – Amazon ElastiCache 现在支持 Valkey 版本 8.1 中的 Bloom 筛选条件,与传统集合相比,可以提供一种节省空间的方式,快速检查项目是否位于内存效率超过 98% 的集合中。
  • Amazon EC2 跳过操作系统关闭选项 – AWS 为 Amazon EC2 推出了一个新选项,允许客户在停止或终止实例时跳过操作系统的正常关闭,从而加快应用程序恢复和实例状态转换。
  • AWS HealthOmics Git 存储库集成 – AWS HealthOmics 现在支持直接集成 Git 存储库用于工作流创建,使研究人员能够无缝地从 GitHub、GitLab 和 Bitbucket 存储库中拉取工作流定义,同时实现版本控制和可重复性。
  • AWS Organizations 标签策略通配符支持 – AWS Organizations 现在在标签策略中支持通配符语句(ALL_SUPPORTED),允许用户在一行中将标记规则应用于给定 AWS 服务的所有支持的资源类型,从而简化策略创建并降低复杂性。
  • 值得注意的博客

超越 IAM 访问密钥:现代身份验证方法 – AWS 建议将传统的 IAM 访问密钥转向更安全的身份验证方法,通过利用现代、更强大的身份管理方法来降低凭证泄露和未经授权访问的风险。

即将举行的 AWS 活动

AWS re:Invent 2025(2025 年 12 月 1 日至 5 日,拉斯维加斯)– AWS 的旗舰年度会议,通过点对点学习、专家主导的讨论和宝贵的交流机会提供协作创新。

AWS Summit – 加入一系列旨在汇聚云计算社区,以相互交流、协作和了解 AWS 的免费线上和线下活动。在离您最近的城市注册:墨西哥城(8 月 6 日)和雅加达(8 月 7 日)。

AWS Community Day – 参加由社区主导的会议,这些会议以技术讨论、讲习会和动手实验室为特色,由来自世界各地的 AWS 专家用户和行业领袖主持:新加坡(8 月 2 日)、澳大利亚(8 月 15 日)、亚德里亚地区(9 月 5 日)、波罗的海地区(9 月 10 日)和奥特亚罗瓦(9 月 18 日)。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。


基于 AWS MediaConvert 与 CMAF 的多语言视频分发优化实践

AWS账单代付阅读(40)

亚马逊AWS官方博客

基于 AWS MediaConvert 与 CMAF 的多语言视频分发优化实践

随着全球化数字内容市场的发展,视频分发领域正经历深刻变革,大语言模型与生成式 AI 技术正逐步消除语言障碍,为内容创作者提供革命性工具,使视频作品能高效触达全球受众。尽管技术进步显著,传统多语言视频分发模式仍存在明显短板:为每种语言创建独立视频版本不仅消耗大量计算资源,还占用过多存储空间,增加 CDN 负担并降低分发效率;同时,用户切换语言或字幕时需重新加载视频,打断了流畅观看体验。这种技术与用户体验的矛盾,凸显了当前视频分发系统亟需优化的方向,以适应日益多元化的全球内容消费需求。

CMAF(Common Media Application Format)是一种基于 ISO-BMFF 标准的现代化媒体容器格式,可以被广泛的设备和播放器所支持,包括 Web 浏览器、移动设备、智能电视在内的几乎所有的现代视频播放器。CMAF 继承了 MP4 的基础架构,能够在单一文件中封装多达 128 条独立音轨,以支持不同语言、解说及评论音轨的并存管理。此外,它灵活兼容文本型(WebVTT、TTML) 和位图字幕,为全球化内容提供了完整的多语言支持解决方案。同时,它还支持分片存储和传输,并与 HLS 和 DASH 等流媒体传输协议完全兼容,实现了真正的“一次编码,多处交付”。客户端在播放多语言的 CMAF 视频时,用户客户在直接无缝切换不同语言的音频和字幕,而不需要页面刷新和对视频资源重新加载,从而提升用户的视频观看体验。

CMAF 具有非常明显的成本与效率优势。以一部 2GB 的视频需要支持五种语言(英语、中文、法语、西班牙语、日语)为例,我们可以清晰地看到两种方案的本质差异。在传统 MP4 方案下,每个语言版本都需要生成独立的视频文件,这意味着存储系统需要容纳 5 个完整的 2GB 文件,总存储需求高达 10GB。当用户观看英语版本时,即便完全不需要其他语言的音轨,CDN 仍然必须传输完整的 2GB 文件,造成巨大的带宽浪费。CMAF 的智慧之处在于其分片化架构。它将视频内容与多语言音轨分离存储:2GB 的视频内容只需保存一份,五种语言的音轨各自独立存储(假设每条音轨约 0.1GB),总存储需求仅需 2.5GB,相比传统方案节省了 75% 的存储空间。这种设计不仅降低了存储成本,更重要的是优化了 CDN 的分发效率。当日本用户观看视频时,边缘节点只需缓存一份公共视频分片和日语音轨分片,其他语言的音轨可以按需加载,极大减轻了边缘节点的存储压力。

同样, CMAF 在多语言视频转码场景下也带来了令人瞩目的转码优势。传统方案需要为每种语言组合生成独立视频文件;假设需要为每种语言的视频配置不同语言的字幕时,5 种语言配上 5 种字幕就意味着 25 次完整的视频转码。而 CMAF 只需对视频内容进行一次转码,音轨和字幕可以独立处理,由此转码效率提高了 96%。这种提升在需要频繁更新多语言内容的生产环境中尤其珍贵。

与 HLS 和 DASH 等自适应流媒体协议相比,CMAF 展现出独特的兼容性优势。虽然 HLS 和 DASH 也支持分片化,但它们通常需要为不同协议生成独立的分片格式,导致存储需求翻倍。CMAF 的统一分片格式(.cmfv/.cmfa)可以同时服务于 HLS 和 DASH 协议,不仅节省了 50% 的存储空间,还避免了重复转码的工作量。

在 CDN 分发层面,CMAF 的优势更为明显。传统 MP4 方案要求每个边缘节点缓存所有语言版本的完整视频文件,而 CMAF 只需在边缘节点缓存一份视频分片。当用户切换语言时,系统只需传输新的音轨分片(约 0.1GB),而不必重新加载完整的 2GB 视频文件,这使得带宽消耗降低了 95%。这种分片复用机制也大幅减少了回源请求量。

AWS Elemental MediaConvert 是一项基于云的视频转码处理服务,能够将用户输入的视频按照需求进行转码操作,其支持 MP4、HLS、DASH、CMAF 等格式的视频封装。接下来,本文将会介绍如何使用 AWS Elemental MediaConvert 封装一部同时支持中英文双语音轨和字幕的 CMAF 的视频片段。

准备工作

确保当前登录 AWS Console 的 IAM 用户有访问 AWS Elemental MediaConvert 的权限。

根据文档 Setting up IAM permissions,为 MediaConvert 任务配置正确的 IAM Role,以使得 MediaConvert 在转码过程中能正确访问输入和输出文件所在的 S3 存储桶。

创建转码任务

导航到 AWS MediaConvert 控制台,在 Jobs 页面上通过点击 Create Jobs 按钮导航到 Create Job 控制台。

配置转码任务的输入

1. 在 Create Job 控制台中的 Inputs 中,添加本次转码任务的视频输入。

2. 在下方的 Audio Selectors 部分中添加两个

Audio Selector,用来为转码任务配置视频的多语言音频输入。本次转码任务中,将会为视频添加英文和中文两种语言的音频支持,并将配置英文为视频的默认语言;由于这两种语言的外置音频文件分别被存放在 S3 存储桶中,因此需要在 Audio Selector 中使用 External file 选项来配置其在 S3 中的位置。此时,需要明确的是在 Audio Selector 1 中配置了视频默认为英文音频,在 Audio Selector 2 中配置了中文音频。

3. 在下面的

Captions selectors 中添加两个 Captions Selector,用来为转码任务配置视频的多语言字幕输入。因此需要在视频添加中英文的字幕支持。同样需要明确的是,在 Captions Selector 1 中,配置了英文字幕的 S3 URI 地址;在 Captions Selector 2 中配置了中文字幕的 S3 URI 地址。

配置转码任务的输出

1. 在转码任务的

Output Groups 中,通过点击 Add 按钮,添加一个 CMAF 输出组。

2. 在

CMAF group settings 里面配置转码输出的 S3 地址。

3. 在 CMAF 的转码任务中,通常会同时输出 HLS 和 DASH 格式的视频;在本次的转码任务中,只希望输出 HLS 格式的视频;因此,需要在

CMAF group settings 里面通过 Write DASH manifest 来关闭 DASH 格式的输出。

4. 配置视频输出;默认情况下,MediaConvert 会输出 H.264 的视频;此时可以根据实际的需要配置对视频输出的转码需求。

5. 配置默认的英文的音频输出;在 CMAF 输出组中的 AAC 输出配置中,通过修改 HLS 配置中的 Audio track type 来控制客户端在播放视频是选择音轨的行为;因为当前配置的是默认的英文音轨,因此需要选择 Alternate audio, auto select, default;另外,可以通过 Name modifier 配置自定义了当前音轨输出文件的名称。

此外,需要通过编码配置中的 Audio source 配置来为当前的音频输入配置正确的输入。需要在此处选择 Audio Selector 1,原因是在输入中,英文的音频文件输入标识为 Audio Selector 1。

同时,需要在编码配置中的高级选项中,为当前的音轨配置正确的语言标识和名称,以使得客户端在播放时能正确显示和处理语言选项。

6. 配置中文音频输出;通过上文中的音频输出控制台的

Copy output 来添加一个音频输出。

7. 和上文中配置英文的音频输出一样,同样的需要通过

Name Modifier 来为音频输出设置自定义标识;由于中文音频输出不作为默认的音频输出,因此需要更新 Audio track type Alternate audio, auto select, not default

另外,由于在输入配置中中文的标识为 Audio Selector 2,因此需要在当前输出的编码配置中将 Audio source 配置为 Audio Selector 2;同样的,需要在编码配置的高级选项中,为音轨选择正确的语言标识和名称。

8. 增加字幕输出;在 CMAF 输出组的 Outputs 中,添加两个新的输出,并修改 Name modify 为这两个输出添加标识。

在输出配置中,通过 Add Captions 将输出定义为字幕输出,并在字幕的编码配置中,分别为不同的字幕输出定义输入源,并设置正确的语言和描述。

9. 最后,则可以点击

Create 创建转码任务。

检查转码任务输出

在转码任务成功后,可以在输出配置中的 S3 中看到转码后的输出文件。在输出的 HLS 的 manifest 中可以看到,视频流分别引用了两个不同的音频媒体和字幕;而在音频媒体和字幕中,按照不同的语言引用了不同的音频和字幕 manifest。以此,就可以实现在播放器中动态切换不同语言的音频和字幕。

结语

本文介绍了如何使用 AWS MediaConvert 和 CMAF 格式来提高多语言视频分发过程的效率。借助于 CMAF 的音视频解耦技术,内容提供商能够以更加高效、经济的方式构建本地化的视频内容,从而为全球用户提供一致的观看体验。


使用 AI 构建 AWS VPC Direct Connect 路由监控系统

AWS账单代付阅读(23)

AWS VPC Direct Connect 路由学习监控系统

在现代企业的数字化转型过程中,混合云架构已经成为连接本地数据中心与云端资源的主流选择。AWS Direct Connect 作为这一架构的核心纽带,为企业提供了稳定、高速的专线连接。随着业务规模的不断扩张和网络复杂度的增加,主动监控和管理各项技术限制变得至关重要。对于大部分 AWS 服务配额,我们可以通过 Service Quotas 控制台、CloudWatch 指标进行常规监控,相关方法可参考 Service Quotas 用户指南和 CloudWatch 配额监控文档。然而某些特定的指标技术限制(如 VPC 路由表通过 BGP 学习到的路由条目数)目前还没有直接可用的监控指标。

本文将为您介绍一个基于 AWS 原生服务构建的智能化路由监控解决方案,它不仅能够实时监控您的 VPC 路由状态,还能在潜在问题发生之前主动发出预警,让您始终掌控网络的健康状态。

设计理念

监控系统采用了 AWS 的无服务器架构,充分利用了云原生服务的优势,24 小时不间断地监控着您的 VPC 路由状态。

模版中的 Lambda 函数,它定期执行路由检查任务。这个函数采用了去重算法,确保即使同一条路由出现在多个路由表中,也只会被计算一次。这种设计避免了重复计数可能导致的误报,确保监控数据的准确性。

系统采用了双阈值预警机制。当路由使用率达到第一个阈值(默认 60%)时,系统会发送中等级别的预警,提醒运维人员关注路由状态;当使用率达到第二个阈值(默认 80%)时,系统会发送高级别的预警,建议立即采取行动。这种渐进式的预警机制给了运维团队充足的时间来规划和执行优化措施。

注意:本文方案适合采用 ** **VGW ** **通过动态学习机制,利用 ** **DX ** **线路的 ** **BGP ** **协议学习的路由,并自动传播到 ** **VPC ** **子网路由表的环境。

技术架构

Amazon EventBridge 负责按照预设的时间间隔触发监控任务。您可以根据业务需求灵活配置监控频率,从每 5 分钟一次的高频监控到每天一次的日常检查(更多的设置可自行调整 CloudFromation 模版),系统都能完美支持。对于大多数企业来说,每小时或者半小时的监控频率既能及时发现问题,又不会产生过多的成本。

AWS Lambda 承担着最核心的监控逻辑,查询 VPC 路由信息,识别 Direct Connect 传播的路由,并进行准确的统计分析。

Amazon SNS 负责将监控结果和预警信息及时传达给相关人员。预警邮件不仅包含简洁的摘要信息,还提供了详细的路由列表和具体的优化建议,帮助运维人员快速理解当前状况并采取相应措施。

AWS IAM 严格遵循最小权限原则,确保整个监控过程的安全性,Lambda 函数只被授予查询路由表和发送 SNS 通知的必要权限,最大程度地降低了安全风险。

让我们来看一个实际的监控流程:每当 EventBridge 触发 Lambda 函数时,函数首先会调用 EC2 API 获取指定 VPC 的所有路由表信息。然后,它会遍历每个路由表中的路由条目,识别出那些 Origin 标为”EnableVgwRoutePropagation”的路由——这些就是通过 Direct Connect 传播的路由。

统计完成后,函数会计算当前的路由使用率,并与预设的阈值进行比较。如果使用率超过了任何一个阈值,系统就会生成详细的预警报告。这个报告不仅包含数字统计,还会列出具体的路由信息,包括目标网段、路由表 ID、目标类型等详细信息,帮助运维人员快速定位和分析问题。

实战部署

部署这个监控系统的过程被设计得尽可能简单和直观。整个系统通过一个 CloudFormation 模板进行定义,这意味着您可以通过几个简单的命令就完成整个系统的部署。

首先您需要准备一些基本信息:要监控的 VPC-ID、接收预警通知的邮箱地址、路由数量限制以及期望的监控频率。这些参数都可以在部署时进行配置,也可以在后续根据需要进行调整。

可以通过 WEB 界面直接部署:

1. 下载

CloudFormation 内容到本地,并保存为 yaml 格式

AWSTemplateFormatVersion: ‘2010-09-09’

Description: ‘VPC Direct Connect Route Monitor with AI-powered route aggregation analysis’

Parameters:

VpcId:

Type: AWS::EC2::VPC::Id

Description: Select the VPC to monitor for DX propagated routes

MaxRoutes:

Type: Number

Default: 100

MinValue: 1

MaxValue: 1000

Description: Maximum number of routes limit (default 100)

WarningThreshold1:

Type: Number

Default: 60

MinValue: 1

MaxValue: 100

Description: First warning threshold percentage (default 60%)

WarningThreshold2:

Type: Number

Default: 80

MinValue: 1

MaxValue: 100

Description: Second warning threshold percentage (default 80%)

MonitoringFrequency:

Type: String

Default: ‘1 hour’

AllowedValues:

  • ‘5 minutes’
  • ’10 minutes’
  • ’30 minutes’
  • ‘1 hour’
  • ‘1 day’

Description: How often to check the route count (default 1 hour)

NotificationEmail:

Type: String

Description: Email address to receive alert notifications

AllowedPattern: ‘^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$’

ConstraintDescription: Please enter a valid email address

EnableAIAnalysis:

Type: String

Default: ‘false’

AllowedValues:

  • ‘true’
  • ‘false’

Description: Enable AI-powered route aggregation analysis using Amazon Bedrock Nova Lite

BedrockRegion:

Type: String

Default: ‘us-east-1’

AllowedValues:

  • ‘us-east-1’
  • ‘us-west-2’
  • ‘eu-west-1’
  • ‘ap-southeast-1’
  • ‘ap-northeast-1’
  • ‘eu-north-1’

Description: AWS region where Bedrock is available (default us-east-1)

Conditions:

Is5Minutes: !Equals [!Ref MonitoringFrequency, ‘5 minutes’]

Is10Minutes: !Equals [!Ref MonitoringFrequency, ’10 minutes’]

Is30Minutes: !Equals [!Ref MonitoringFrequency, ’30 minutes’]

Is1Day: !Equals [!Ref MonitoringFrequency, ‘1 day’]

AIAnalysisEnabled: !Equals [!Ref EnableAIAnalysis, ‘true’]

Resources:

AlertTopic:

Type: AWS::SNS::Topic

Properties:

TopicName: !Sub ‘${AWS::StackName}-vpc-dx-route-alerts’

DisplayName: ‘VPC DX Route Monitor Alerts’

EmailSubscription:

Type: AWS::SNS::Subscription

Properties:

TopicArn: !Ref AlertTopic

Protocol: email

Endpoint: !Ref NotificationEmail

LambdaExecutionRole:

Type: AWS::IAM::Role

Properties:

AssumeRolePolicyDocument:

Version: ‘2012-10-17’

Statement:

  • Effect: Allow

Principal:

Service: lambda.amazonaws.com

Action: sts:AssumeRole

ManagedPolicyArns:

  • arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

Policies:

  • PolicyName: VPCRouteMonitoringPolicy

PolicyDocument:

Version: ‘2012-10-17’

Statement:

  • Effect: Allow

Action:

  • ec2:DescribeRouteTables
  • ec2:DescribeVpcs

Resource: ‘*’

  • Effect: Allow

Action:

  • sns:Publish

Resource: !Ref AlertTopic

  • !If
  • AIAnalysisEnabled
  • PolicyName: BedrockAccessPolicy

PolicyDocument:

Version: ‘2012-10-17’

Statement:

  • Effect: Allow

Action:

  • bedrock:InvokeModel

Resource: !Sub ‘arn:aws:bedrock:${BedrockRegion}::foundation-model/amazon.nova-lite-v1:0’

  • !Ref ‘AWS::NoValue’

RouteMonitorFunction:

Type: AWS::Lambda::Function

Properties:

FunctionName: !Sub ‘${AWS::StackName}-vpc-dx-route-monitor’

Runtime: python3.9

Handler: index.lambda_handler

Role: !GetAtt LambdaExecutionRole.Arn

Timeout: 600

MemorySize: 512

Description: ‘Monitor VPC DX propagated routes with optional AI analysis’

Environment:

Variables:

VPC_ID: !Ref VpcId

MAX_ROUTES: !Ref MaxRoutes

WARNING_THRESHOLD_1: !Ref WarningThreshold1

WARNING_THRESHOLD_2: !Ref WarningThreshold2

SNS_TOPIC_ARN: !Ref AlertTopic

ENABLE_AI_ANALYSIS: !Ref EnableAIAnalysis

BEDROCK_REGION: !Ref BedrockRegion

Code:

ZipFile: |

使用 AI 构建 AWS VPC Direct Connect 路由监控系统

“””

AWS VPC DX路由监控Lambda函数 – AI增强版本

支持通过Amazon Bedrock Nova Lite进行路由聚合分析

“””

import boto3

import json

import os

from datetime import datetime

from typing import Dict, List, Any, Set, Tuple, Optional

def lambda_handler(event, context):

“””Lambda主函数”””

try:

vpc_id = os.environ.get(‘VPC_ID’)

max_routes = int(os.environ.get(‘MAX_ROUTES’, ‘100’))

warning_threshold_1 = int(os.environ.get(‘WARNING_THRESHOLD_1′, ’60’))

warning_threshold_2 = int(os.environ.get(‘WARNING_THRESHOLD_2′, ’80’))

sns_topic_arn = os.environ.get(‘SNS_TOPIC_ARN’)

enable_ai_analysis = os.environ.get(‘ENABLE_AI_ANALYSIS’, ‘false’).lower() == ‘true’

bedrock_region = os.environ.get(‘BEDROCK_REGION’, ‘us-east-1’)

if not vpc_id or not sns_topic_arn:

raise ValueError(“缺少必要的环境变量”)

查询DX传播的路由

route_info = query_dx_propagated_routes(vpc_id)

if route_info is None:

send_error_notification(sns_topic_arn, vpc_id, “查询路由失败”)

return {‘statusCode’: 500, ‘body’: json.dumps({‘error’: ‘查询路由失败’})}

计算使用百分比

current_routes = route_info[‘unique_dx_routes’]

usage_percentage = (current_routes / max_routes) * 100

AI分析(如果启用)

ai_analysis = None

if enable_ai_analysis and current_routes > 0:

try:

ai_analysis = analyze_routes_with_ai(route_info[‘unique_routes’], bedrock_region)

print(“AI分析完成”)

except Exception as e:

print(f”AI分析失败: {e}”)

ai_analysis = {“error”: f”AI分析失败: {str(e)}”}

检查预警

should_alert = False

alert_level = None

if usage_percentage >= warning_threshold_2:

should_alert = True

alert_level = ‘HIGH’

elif usage_percentage >= warning_threshold_1:

should_alert = True

alert_level = ‘MEDIUM’

发送预警

if should_alert:

send_alert_notification(

sns_topic_arn, vpc_id, current_routes, max_routes,

usage_percentage, alert_level, route_info[‘unique_routes’], ai_analysis

)

result = {

‘vpc_id’: vpc_id,

‘unique_dx_routes’: current_routes,

‘max_routes’: max_routes,

‘usage_percentage’: round(usage_percentage, 2),

‘alert_sent’: should_alert,

‘alert_level’: alert_level,

‘ai_analysis_enabled’: enable_ai_analysis,

‘ai_analysis_status’: ‘completed’ if ai_analysis and ‘error’ not in ai_analysis else ‘failed’ if ai_analysis else ‘disabled’,

‘timestamp’: datetime.now().isoformat()

}

print(f”监控结果: {json.dumps(result, ensure_ascii=False)}”)

return {‘statusCode’: 200, ‘body’: json.dumps(result, ensure_ascii=False)}

except Exception as e:

error_msg = f”Lambda执行失败: {str(e)}”

print(error_msg)

try:

if ‘sns_topic_arn’ in locals():

send_error_notification(sns_topic_arn, vpc_id if ‘vpc_id’ in locals() else ‘Unknown’, str(e))

except:

pass

return {‘statusCode’: 500, ‘body’: json.dumps({‘error’: error_msg})}

def query_dx_propagated_routes(vpc_id: str) -> Dict[str, Any]:

“””查询VPC中通过DX传播的路由条目”””

try:

ec2_client = boto3.client(‘ec2’)

response = ec2_client.describe_route_tables(

Filters=[{‘Name’: ‘vpc-id’, ‘Values’: [vpc_id]}]

)

route_tables = response.get(‘RouteTables’, [])

if not route_tables:

print(f”未找到VPC {vpc_id} 的路由表”)

return None

if response.get(‘NextToken’):

print(“警告: 检测到分页,可能需要升级到完整版本”)

使用Set去重

unique_dx_routes: Set[Tuple[str, str, str]] = set()

unique_routes_list = []

for rt in route_tables:

rt_id = rt[‘RouteTableId’]

routes = rt.get(‘Routes’, [])

for route in routes:

if route.get(‘Origin’) == ‘EnableVgwRoutePropagation’:

destination = route.get(‘DestinationCidrBlock’) or route.get(‘DestinationIpv6CidrBlock’, ‘未知’)

target_type, target_value = get_route_target(route)

route_key = (destination, target_type, target_value)

if route_key not in unique_dx_routes:

unique_dx_routes.add(route_key)

unique_routes_list.append({

‘route_table_id’: rt_id,

‘destination’: destination,

‘target_type’: target_type,

‘target_value’: target_value,

‘state’: route.get(‘State’, ‘未知’)

})

return {

‘unique_dx_routes’: len(unique_dx_routes),

‘unique_routes’: unique_routes_list

}

except Exception as e:

print(f”查询DX路由失败: {e}”)

return None

def analyze_routes_with_ai(routes: List[Dict], bedrock_region: str) -> Optional[Dict]:

“””使用Amazon Bedrock Nova Lite分析路由聚合”””

try:

bedrock_client = boto3.client(‘bedrock-runtime’, region_name=bedrock_region)

准备路由数据

route_data = []

for route in routes:

route_data.append({

‘destination’: route[‘destination’],

‘target_type’: route[‘target_type’],

‘target_value’: route[‘target_value’],

‘state’: route[‘state’]

})

构建AI提示

prompt = f”””你是一个AWS网络专家,请分析以下Direct Connect传播的路由,并提供路由聚合建议。

当前路由列表(共{len(routes)}条):

{json.dumps(route_data, indent=2, ensure_ascii=False)}

请分析并提供以下内容:

1. 路由聚合机会分析

2. 具体的CIDR聚合建议

3. 预期的路由数量减少

4. 实施建议和注意事项

5. 风险评估

请用中文回答,格式要清晰易读。”””

调用Nova Lite

request_body = {

“messages”: [

{

“role”: “user”,

“content”: [

{

“text”: prompt

}

]

}

],

“inferenceConfig”: {

“max_new_tokens”: 4000,

“temperature”: 0.1

}

}

response = bedrock_client.invoke_model(

modelId=’amazon.nova-lite-v1:0′,

body=json.dumps(request_body)

)

response_body = json.loads(response[‘body’].read())

ai_analysis = response_body[‘output’][‘message’][‘content’][0][‘text’]

return {

‘analysis’: ai_analysis,

‘route_count’: len(routes),

‘analysis_timestamp’: datetime.now().isoformat(),

‘model_used’: ‘Amazon Nova Lite’

}

except Exception as e:

print(f”AI分析失败: {e}”)

return {“error”: str(e)}

def get_route_target(route: Dict) -> tuple:

“””获取路由目标类型和值”””

if ‘VirtualPrivateGatewayId’ in route:

return ‘vpn-gateway’, route[‘VirtualPrivateGatewayId’]

elif ‘TransitGatewayId’ in route:

return ‘transit-gateway’, route[‘TransitGatewayId’]

elif ‘DirectConnectGatewayId’ in route:

return ‘dx-gateway’, route[‘DirectConnectGatewayId’]

elif ‘GatewayId’ in route:

return ‘gateway’, route[‘GatewayId’]

elif ‘NatGatewayId’ in route:

return ‘nat-gateway’, route[‘NatGatewayId’]

elif ‘NetworkInterfaceId’ in route:

return ‘network-interface’, route[‘NetworkInterfaceId’]

elif ‘InstanceId’ in route:

return ‘instance’, route[‘InstanceId’]

else:

return ‘unknown’, ‘unknown’

def send_alert_notification(sns_topic_arn: str, vpc_id: str, current_routes: int,

max_routes: int, usage_percentage: float, alert_level: str,

routes: List[Dict], ai_analysis: Optional[Dict] = None):

“””发送预警通知(包含AI分析)”””

try:

sns_client = boto3.client(‘sns’)

subject = f”🚨 VPC DX路由预警 – {alert_level} 级别 ({usage_percentage:.1f}%)”

if ai_analysis and ‘error’ not in ai_analysis:

subject += ” [含AI分析]”

message_lines = [

f”VPC Direct Connect 路由监控预警”,

f””,

f”📊 监控摘要:”,

f” VPC ID: {vpc_id}”,

f” 当前DX传播路由数: {current_routes}”,

f” 最大路由限制: {max_routes}”,

f” 使用百分比: {usage_percentage:.2f}%”,

f” 预警级别: {alert_level}”,

f” 检查时间: {datetime.now().strftime(‘%Y-%m-%d %H:%M:%S UTC’)}”,

f””,

f”🔍 DX传播路由详情:”

]

if routes:

message_lines.append(f” {‘目标网段’:<18} {'目标类型':<15} {'目标值':<25}")

message_lines.append(f” {‘-‘*18} {‘-‘*15} {‘-‘*25}”)

for route in routes[:15]: # 限制显示数量,为AI分析留空间

message_lines.append(

f” {route[‘destination’]:<18} {route['target_type']:<15} {route['target_value']:<25}"

)

if len(routes) > 15:

message_lines.append(f” … 还有 {len(routes) – 15} 条路由未显示”)

添加AI分析结果

if ai_analysis:

message_lines.extend([

f””,

f”🤖 AI路由聚合分析 (Amazon Nova Lite):”,

f”{‘=’*60}”

])

if ‘error’ in ai_analysis:

message_lines.append(f”AI分析失败: {ai_analysis[‘error’]}”)

else:

将AI分析结果按行分割并添加适当的缩进

analysis_lines = ai_analysis[‘analysis’].split(‘\n’)

for line in analysis_lines:

if line.strip():

message_lines.append(f”{line}”)

else:

message_lines.append(“”)

message_lines.extend([

f””,

f”分析时间: {ai_analysis.get(‘analysis_timestamp’, ‘Unknown’)}”,

f”使用模型: {ai_analysis.get(‘model_used’, ‘Unknown’)}”

])

message_lines.extend([

f””,

f”⚠️ 建议操作:”,

f” – 检查是否有不必要的路由传播”,

f” – 考虑优化路由聚合”,

f” – 如需增加路由限制,请联系AWS支持”

])

if ai_analysis and ‘error’ not in ai_analysis:

message_lines.append(f” – 参考上述AI分析建议进行路由优化”)

message_lines.append(f”\n此消息由AWS Lambda自动生成”)

sns_client.publish(

TopicArn=sns_topic_arn,

Subject=subject,

Message=”\n”.join(message_lines)

)

print(“预警通知已发送”)

except Exception as e:

print(f”发送预警通知失败: {e}”)

def send_error_notification(sns_topic_arn: str, vpc_id: str, error_message: str):

“””发送错误通知”””

try:

sns_client = boto3.client(‘sns’)

subject = f”❌ VPC DX路由监控错误 – {vpc_id}”

message = f”””VPC Direct Connect 路由监控执行错误

错误信息:

VPC ID: {vpc_id}

错误消息: {error_message}

发生时间: {datetime.now().strftime(‘%Y-%m-%d %H:%M:%S UTC’)}

请检查Lambda函数配置和权限设置。”””

sns_client.publish(

TopicArn=sns_topic_arn,

Subject=subject,

Message=message

)

except Exception as e:

print(f”发送错误通知失败: {e}”)

ScheduleRule:

Type: AWS::Events::Rule

Properties:

Name: !Sub ‘${AWS::StackName}-vpc-dx-route-monitor-schedule’

Description: ‘Schedule trigger for VPC DX route monitoring’

ScheduleExpression: !If

  • Is5Minutes
  • ‘rate(5 minutes)’
  • !If
  • Is10Minutes
  • ‘rate(10 minutes)’
  • !If
  • Is30Minutes
  • ‘rate(30 minutes)’
  • !If
  • Is1Day
  • ‘rate(1 day)’
  • ‘rate(1 hour)’

State: ENABLED

Targets:

  • Arn: !GetAtt RouteMonitorFunction.Arn

Id: ‘RouteMonitorTarget’

LambdaInvokePermission:

Type: AWS::Lambda::Permission

Properties:

FunctionName: !Ref RouteMonitorFunction

Action: lambda:InvokeFunction

Principal: events.amazonaws.com

SourceArn: !GetAtt ScheduleRule.Arn

LambdaLogGroup:

Type: AWS::Logs::LogGroup

Properties:

LogGroupName: !Sub ‘/aws/lambda/${RouteMonitorFunction}’

RetentionInDays: 14

Outputs:

LambdaFunctionName:

Description: ‘Lambda function name for VPC DX route monitoring’

Value: !Ref RouteMonitorFunction

SNSTopicArn:

Description: ‘SNS topic ARN for alert notifications’

Value: !Ref AlertTopic

MonitoredVPC:

Description: ‘VPC ID being monitored’

Value: !Ref VpcId

AIAnalysisEnabled:

Description: ‘Whether AI analysis is enabled’

Value: !Ref EnableAIAnalysis

BedrockRegion:

Description: ‘Bedrock region for AI analysis’

Value: !Ref BedrockRegion

Condition: AIAnalysisEnabled

2. 去网站控制台

CloudFormation 功能,上传刚才创建的 CloudFormation.yaml 文件

3. 输入监控必须项目,填写预警所需邮箱(选择已经学习 DX 路由的 VPC),并点击下一步

4. 勾选我确认,同意系统所需最小授权,并点击下一步完成堆栈部署

部署完成后,系统会自动开始工作。您会收到一封来自 Amazon SNS 的订阅确认邮件,确认后就能开始接收监控通知了。整个过程通常在几分钟内就能完成。

在实际的生产环境中,我建议您根据业务的重要性和网络的复杂程度来调整监控参数。对于关键的生产环境,可以将监控频率设置为半小时或 1 小时,并将预警阈值设置得相对保守一些,比如 50% 和 70%。对于测试环境,可以适当放宽阈值并降低监控频率,以节省成本。

值得注意的是,系统的运营成本非常低廉。以每小时监控频次为例,每月的总成本通常不超过几美元,这对于大多数企业来说几乎可以忽略不计。这种成本效益使得即使是小型企业也能轻松承担这样的监控系统。

预警机制

设置了两个预警点,您可以通过较低点的预警,通过长期的监控数据,分析路由数量的变化趋势,识别出哪些时间段路由数量增长较快,哪些网络段的路由传播最为频繁。这些信息对于网络规划和容量管理具有重要价值。

因为使用了 Lambda 作为扫描工具,系统扩展较为轻松。您可以轻松地将监控范围扩展到多个 VPC,或者集成 Slack 等即时通讯工具来接收预警通知。对于有特殊需求的企业,还可以在 Lambda 函数中添加自定义的分析逻辑,比如按照网络段类型进行分类统计,或者与 CMDB 系统集成来获取更丰富的上下文信息。

在实际运维过程中,建议建立一套标准的响应流程。当收到中等级别预警时,可以安排在下一个维护窗口进行路由优化;当收到高级别预警时,应该立即评估是否需要采取紧急措施。定期回顾预警历史和处理记录,可以帮助团队不断改进网络架构和监控策略。

当系统检测到路由使用率超过预设阈值时,它会生成一份详细而实用的预警报告,不仅提供了必要的统计信息,还包含了具体的优化建议。

常规预警邮件示例:

🚨 VPC DX路由预警 – 级别 HIGH (85.0%)

📊 监控摘要:

VPC ID: vpc-[已去除电话]

当前DX传播路由数: 85

最大路由限制: 100

使用百分比: 85.00%

预警级别: HIGH

检查时间: 2024-07-04 06:00:00 UTC

🔍 DX传播路由详情:

目标网段 路由表ID 目标类型 目标值 状态

10.1.0.0/24 rtb-abc123 vgw vgw-xyz789 active

10.2.0.0/24 rtb-abc123 vgw vgw-xyz789 active

⚠️ 建议操作:

  • 检查是否有不必要的路由传播
  • 考虑优化路由聚合,将多个小网段合并为较大的网段
  • 评估是否可以移除一些不再使用的网络段
  • 如需增加路由限制,请联系AWS支持团队
  • 考虑使用Transit Gateway来优化网络架构
  • 通过大模型优化

    通过 Nova 大模型进行运维能力优化

Amazon Nova 是新一代基础模型,能够提供前沿情报和行业领先的性价比,可在 Amazon Bedrock 上使用。Amazon Nova 模型包含四种理解模型、两种创意内容生成模型和一种语音转语音模型。通过与 Amazon Bedrock 的无缝集成,开发人员可以使用 Amazon Nova 基础模型来构建和扩展生成式人工智能应用程序。要开始使用 Amazon Nova 进行构建,必须使用 Amazon Bedrock 通过 API 访问模型。

在模版创建的过程中,您可以勾选大模型分析功能,本文将采用成本较低的 Nova Lite 进行意见总结,详情见下图:

在模版创建的过程中,可以勾选 Nova 大模型进行路由聚合计算,精准进行路由层面的分析,检查路由信息提供聚合意见:

📊 监控摘要:

VPC ID: vpc-0fdb6792d7643d42e

当前DX传播路由数: 17

最大路由限制: 20

使用百分比: 85.00%

预警级别: HIGH

检查时间: 2025-07-25 09:17:02 UTC

🔍 DX传播路由详情:

目标网段 目标类型 目标值

—————— ————— ————————-

200.1.6.0/24 gateway vgw-0ccfb055a11d6827f

200.1.7.0/24 gateway vgw-0ccfb055a11d6827f

200.1.8.0/24 gateway vgw-0ccfb055a11d6827f

200.1.9.0/24 gateway vgw-0ccfb055a11d6827f

200.1.10.0/24 gateway vgw-0ccfb055a11d6827f

200.1.11.0/24 gateway vgw-0ccfb055a11d6827f

210.1.12.0/24 gateway vgw-0ccfb055a11d6827f

210.1.13.0/24 gateway vgw-0ccfb055a11d6827f

210.1.14.0/24 gateway vgw-0ccfb055a11d6827f

210.1.15.0/24 gateway vgw-0ccfb055a11d6827f

210.1.16.0/24 gateway vgw-0ccfb055a11d6827f

210.1.17.0/24 gateway vgw-0ccfb055a11d6827f

100.1.1.0/24 gateway vgw-0ccfb055a11d6827f

100.1.2.0/24 gateway vgw-0ccfb055a11d6827f

100.1.3.0/24 gateway vgw-0ccfb055a11d6827f

… 还有 2 条路由未显示

🤖 AI路由聚合分析 (Amazon Nova Lite):

============================================================

路由聚合分析与建议

1. 路由聚合机会分析

当前的路由列表中,所有的目的地网段都是 /24 的单独网段,且都通过同一个虚拟网关(vgw-0ccfb055a11d6827f)进行路由。这种情况下,存在显著的路由聚合机会。通过聚合这些 /24 网段,可以减少路由表的大小,提高路由效率。

2. 具体的CIDR聚合建议

根据当前的路由列表,可以将这些 /24 网段进行聚合。以下是具体的聚合建议:

  • **200.1.6.0/21**:包含 200.1.6.0/24 到 200.1.11.0/24
  • **210.1.12.0/21**:包含 210.1.12.0/24 到 210.1.17.0/24
  • **100.1.1.0/21**:包含 100.1.1.0/24 到 100.1.5.0/24
  • 3. 预期的路由数量减少

通过上述聚合,原来的 17 条 /24 路由可以减少为 3 条 /21 路由,从而显著减少路由表的大小。

成本分析

从成本效益的角度来看,这个监控解决方案体现了云计算”按需付费”的优势。整个系统的月度运营成本通常不超过几美元美元,但它能够预防的潜在损失却可能是这个成本的数千倍甚至数万倍。

考虑一个实际的场景:如果因为路由数量超限导致关键业务系统小时级中断,对于一个中型企业来说,直接的业务损失可能就达到数万元。更不用说由此可能引发的客户投诉、声誉损失的风险。相比之下每月几十元钱的监控成本简直微不足道。

更重要的是,这个系统能够帮助运维团队从被动响应转向主动预防,显著提升运维效率和服务质量。运维人员不再需要定期手动检查路由状态,也无需担心在关键时刻遗漏重要的网络问题。

总结

对于正在使用或计划使用 AWS Direct Connect 的企业来说,部署这样一个监控系统应该是网络架构规划中的必选项。它不仅能够保障网络的稳定运行,还能为未来的网络扩展和优化提供有价值的数据支持。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。

本篇作者


Amazon DocumentDB Serverless 现已推出

AWS账单代付阅读(27)

Amazon DocumentDB Serverless 现已推出

亚马逊AWS官方博客

Amazon DocumentDB Serverless 现已推出

今天,我们宣布 Amazon DocumentDB Serverless 正式推出,这是 Amazon DocumentDB(兼容 MongoDB)的一种新配置,可根据应用程序需求自动扩展计算和内存。Amazon DocumentDB Serverless 简化了数据库管理,无需预付承诺或额外费用,与为峰值容量进行预置相比,可节省多达 90% 的成本。

借助 Amazon DocumentDB Serverless,可以使用与 Amazon DocumentDB 相同的 MongoDB 兼容 API 和功能,包括只读副本、性能详情、I/O 优化以及与其他 Amazon Web Services(AWS)服务的集成。

Amazon DocumentDB Serverless 推出了一种以 DocumentDB 容量单位(DCU)衡量的新数据库配置,该配置由大约 2 吉字节(GiB)的内存、相应的 CPU 和网络组成。该功能持续跟踪 CPU、内存和网络等资源的利用率,这些资源来自应用程序执行的数据库操作。

Amazon DocumentDB Serverless 可自动扩展或缩减 DCU 以满足需求,而不会中断数据库可用性。在现有集群中从预置实例切换到无服务器实例就像添加或更改实例类型一样简单。这种过渡不需要任何数据迁移。要了解更多信息,请访问 Amazon DocumentDB Serverless 的工作原理。

Amazon DocumentDB Serverless 的一些关键使用案例和优势包括:

  • 可变的工作负载 – 借助 Amazon DocumentDB Serverless,可以应对突然的流量高峰,例如定期提升活动、开发和测试环境以及用量可能迅速增加的新应用程序。还可以构建代理式人工智能应用程序,这些应用程序受益于 Amazon DocumentDB 的内置向量搜索功能,以及处理动态调用的代理式人工智能工作流的无服务器适应性。
  • 多租户工作负载 – 可以使用 Amazon DocumentDB Serverless 来管理整个数据库实例集中的单个数据库容量。无需为企业应用程序或软件即服务(SaaS)供应商的多租户环境管理成百上千个数据库。
  • 混合用途工作负载 – 可以均衡定期出现查询流量峰值的工作负载的读写容量,例如在线事务处理(OLTP)应用程序。通过为集群中的 Amazon DocumentDB Serverless 实例指定提升层级,可以配置集群,使读取器实例可以独立于写入器实例进行扩展以处理额外的负载。

对于稳定的工作负载,Amazon DocumentDB 预置实例更适合。可以选择提供预定义内存量、CPU 功率和 I/O 带宽的实例类。如果在使用预置实例时工作负载发生变化,则应手动修改写入器和读取器的实例类。或者,可以随时向现有的预置 Amazon DocumentDB 集群添加无服务器实例。

Amazon DocumentDB Serverless 实际应用

要开始使用 Amazon DocumentDB Serverless,请转到 Amazon DocumentDB 控制台。在左侧导航窗格中,选择集群和创建。

在创建 Amazon DocumentDB 集群页面上,选择基于实例的集群类型,然后选择无服务器实例配置。可以选择最小和最大容量 DCU。从 Amazon DocumentDB 5.0.0 及更高版本开始,支持 Amazon DocumentDB Serverless,容量范围为 0.5-256 个 DCU。

如果使用审计和性能详情等特征,请考虑为每项特征添加 DCU。要了解更多信息,请访问 Amazon DocumentDB Serverless 扩展配置。

要向现有的预置集群添加无服务器实例,请在选择已预置的集群时在操作菜单上选择添加实例。如果使用的是早期版本(例如 3.6 或 4.0)的集群,则应首先将集群升级到支持的引擎版本(5.0)。

在添加实例页面上,在数据库实例类部分为要创建的每个新无服务器实例选择无服务器。要添加另一个实例,请选择添加实例并继续添加实例,直到达到所需的新实例数量。选择创建。

可以执行失效转移操作,将 DocumentDB Serverless 实例设置为集群写入器。此外,可以通过更改实例的类或通过删除 Amazon DocumentDB 实例将其从集群中移除,将任何剩余的预置 Amazon DocumentDB 实例转换为 DocumentDB Serverless 实例。

现在,可以使用 AWS CloudShell 连接到 Amazon DocumentDB 集群。选择连接到集群,即可看到 AWS CloudShell 运行命令屏幕。在新建环境名称中输入一个唯一名称,然后选择创建并运行。

出现提示时,输入 Amazon DocumentDB 集群的密码。已成功连接到 Amazon DocumentDB 集群,可以运行一些查询来熟悉使用文档数据库。

要了解更多信息,请访问 AWS 文档中的创建使用 Amazon DocumentDB Serverless 的集群和管理 Amazon DocumentDB Serverless。

现已推出

从 Amazon DocumentDB 5.0 开始,Amazon DocumentDB Serverless 现已可用于新集群和现有集群。只需按每秒 DCU 用量的固定费率付费。要了解有关定价详细信息和区域可用性的更多信息,请访问 Amazon DocumentDB 定价页面。

在 Amazon DocumentDB 控制台中试用这些新特征,如有反馈,请发送至 AWS re:Post for Amazon DocumentDB 或通过通常的 AWS Support [已去除[已去除推广语]语]发送反馈。

— Channy


推出 Amazon 应用程序恢复控制器区域切换功能:一种跨区域的应用程序恢复服务

AWS账单代付阅读(22)

推出 Amazon 应用程序恢复控制器区域切换功能:一种跨区域的应用程序恢复服务

亚马逊AWS官方博客

推出 Amazon 应用程序恢复控制器区域切换功能:一种跨区域的应用程序恢复服务

作为 AWS 的开发人员倡导者,我曾与众多跨多个 AWS 区域运营关键应用程序的企业组织合作过。他们常常共同担忧的一个关键问题是对其区域失效转移策略缺乏信心——即在需要时该策略是否奏效,是否已识别出所有依赖关系,以及其团队是否已充分练习相关流程。传统的处理方式往往使他们对是否具备进行区域切换的能力感到不确定。

今天,我非常高兴地宣布推出 Amazon 应用程序恢复控制器(ARC)区域切换功能,这是一项完全托管且高度可用的功能,能让各组织安心地计划、练习并编排区域切换操作,从而消除跨区域恢复操作中的不确定性。区域切换功能可帮助您对部署在 AWS 上的多区域应用程序进行恢复操作的编排。它为您提供了一个集中的解决方案,可在您需要将应用程序的运行环境从一个 AWS 区域切换到另一个区域时,协调并自动化执行跨 AWS 服务和账户的恢复任务。

许多客户会将业务关键型应用程序部署在多个 AWS 区域中,以满足其可用性需求。当一个操作事件影响到一个区域内的应用程序时,将操作切换到另一个区域则需要协调多个步骤,这些步骤涉及不同的 AWS 服务,如计算、数据库和 DNS 等。这种协调工作通常需要构建和维护复杂的脚本,而这些脚本需要随着应用程序的不断发展进行定期测试和更新。此外,编排并跟踪多个应用程序中区域切换的进展情况,并为合规目的提供成功恢复的证明,通常需要进行人工数据收集。

区域切换功能基于区域数据面板架构而构建,在该架构中,区域切换计划会从被激活的区域开始执行。这种设计在切换过程中消除了对受影响区域的依赖,从而提供一个更具韧性的恢复流程,因为其执行过程与您所切换的区域无关。

利用 ARC 区域切换功能制定恢复计划

利用 ARC 区域切换功能,您可以创建恢复计划,这些计划会明确说明在不同区域之间切换应用程序所需的特定步骤。每个计划都包含代表了在 AWS 资源上所进行的操作的执行块。启动时,区域切换功能支持九种执行块类型:

  • ARC 区域切换计划执行块 – 通过引用其他区域切换计划,您可以编排多个应用程序切换到您想要激活的区域的顺序。
  • Amazon EC2 Auto Scaling 执行区 – 通过匹配源区域容量的指定百分比,对您目标区域中的 Amazon EC2 计算资源进行扩展。
  • ARC 路由控制执行块 – 更改路由控制状态,通过 DNS 运行状况检查来重新引导流量。
  • Amazon Aurora 全局数据库执行块 – 为 Aurora Global Database 执行数据库失效转移(可能导致数据丢失)或切换(数据完全不会丢失)操作。
  • 手动批准执行块 – 在您的恢复工作流程中添加批准检查点,以便团队成员在继续操作前进行审查和批准。
  • 自定义操作 AWS Lambda 执行块 – 通过在激活或停用区域执行 Lambda 函数,添加自定义恢复步骤。
  • Amazon Route 53 运行状况检查执行块 – 允许您指定在失效转移期间您的应用程序流量将被重定向至哪些区域。执行区域切换计划时,Amazon Route 53 运行状况检查状态会进行更新,并且流量会根据您的 DNS 配置进行重新定向。
  • Amazon Elastic Kubernetes Service(Amazon EKS)资源扩展执行块 – 在恢复过程中,通过匹配源区域容量的指定百分比,对目标区域内的 Kubernetes 容器组(pod)进行扩展。
  • Amazon Elastic Container Service(Amazon ECS)资源扩展执行块 – 通过匹配源区域容量的指定百分比,对目标区域内的 ECS 任务进行扩展。

区域切换功能会每隔 30 分钟检查一次资源配置以及 AWS Identity and Access Management(IAM)权限,以持续验证您的计划。在执行过程中,区域切换功能会监控每个步骤的进展情况,并提供详细的日志。您可以通过“区域切换”控制面板以及执行详情页面的底部查看执行状态。

为了帮助您在成本与可靠性之间取得平衡,区域切换功能为您提供了灵活准备备用资源的方式。在恢复过程中,您可以通过使用“区域切换扩展执行块”来为目标区域配置所需的计算容量百分比。对于那些在恢复过程中预计会出现流量激增的关键应用程序,您可以选择将容量扩展到超出 100% 的水平,而设定较低的百分比则有助于实现更短的总体执行时间。但是,需要强调的是,使用其中任何一个扩展执行块并不能保证具备足够的容量,实际的资源可用性取决于恢复时目标区域的容量情况。为了确保取得最佳效果,我们建议您定期测试恢复计划,并在备用区域中维持适当的服务配额。

ARC 区域切换功能包含一个全局控制面板,您可以通过它来监控整个企业及各个区域的区域切换计划状态。此外,还有一个“区域执行情况”控制面板,它只会显示当前控制台区域内的执行情况。此控制面板设计为在每个区域内实现高可用性,以便在操作事件发生时能够正常使用。

通过区域切换功能,可以将资源托管在与包含区域切换计划的账户不同的账户中。如果该计划所使用的资源来自与托管该计划的账户不同的账户,则区域切换功能会使用

executionRole 代入

crossAccountRole,以访问这些资源。此外,可以使用 AWS Resource Access Manager(AWS RAM)在多个账户之间进行集中和共享区域切换计划,从而实现对整个组织的恢复计划的高效管理。

下面我们来看看它的工作原理

让我来向您演示如何创建并执行区域切换计划。此演示包含三个部分。首先,我创建了一个区域切换计划。然后,我定义一个工作流程。最后,我配置了触发器。

第 1 步:创建计划

我导航到 AWS 管理控制台的应用程序恢复控制器部分。我在左侧导航菜单中选择区域切换。然后,我选择创建区域切换计划。

在为我的计划命名之后,我指定了一种多区域恢复方法(主动/被动或主动/主动)。在“主动/被动”模式下,两个应用程序副本被部署到两个区域中,而流量只会被路由至主动区域。被动区域中的副本可以通过执行区域切换计划来激活。

然后,我选择主要区域和备用区域。我还可以选择输入所需的恢复时间目标(RTO)。该服务将利用此值来了解区域切换计划的执行所需时间与我所需要的 RTO 之间的关系。

我进入计划执行 IAM 角色。该角色能够使区域切换功能在执行期间调用 AWS 服务。我会确保我所选择的角色具备被服务调用的权限,并且包含的权限范围是能够使 ARC 正常运行的最小权限集。请参阅文档的 IAM 权限部分以获取详细信息。

当两条计划评估状态通知显示为绿色时,我将创建一个工作流程。我选择构建工作流程以开始操作。

这些计划能让您构建特定的工作流程,通过“区域切换执行块”来恢复您的应用程序。您可以使用执行块来构建工作流程,这些执行块可以按顺序或以并行方式运行,以编排多个应用程序或资源在激活区域中的恢复顺序。一个计划由这些工作流程组成,通过这些工作流程,您可以激活或停用特定的区域。

在本次演示中,我使用图形编辑器来创建工作流程。但您也可以用 JSON 格式来定义工作流程。这种格式更适合自动化操作,或者当您希望将工作流程定义存储在源代码管理系统(SCMS)和基础设施即代码(IaC)工具(例如 AWS CloudFormation)中时。

我可以通过选择工作流程构建器标题旁边的相应选项卡在设计与代码视图之间交替切换。JSON 视图是只读的。我使用图形编辑器设计了工作流程,并将对应的 JSON 格式文件复制下来,将其与我的 IaC 项目文件一同保存。

区域切换功能每隔 30 分钟启动一次评估,以验证您的恢复策略的有效性。它会定期检查您的工作流程中所定义的所有操作在执行时是否都能成功完成。这种主动式的验证会评测多种要素,包括各个账户和不同区域内的 IAM 权限以及资源状态。通过持续监控这些依赖关系,区域切换功能能够确保您的恢复计划保持有效,并能在实际切换操作受到影响之前发现潜在问题。

然而,正如未经测试的备份并非可靠的备份一样,未经测试的恢复计划也不能被视为真正经过验证的计划。虽然持续评估能提供坚实的基础,但我们强烈建议您在测试场景中定期执行计划,以验证其有效性、了解实际恢复时间,并确保您的团队熟悉恢复流程。这种实践的测试对于保持对您的灾难恢复策略的信心至关重要。

第 3 步:创建触发器

触发器用于定义激活刚刚创建的工作流程所需的条件。。它以一组 CloudWatch 警报的形式表示。基于警报的触发器是可选的。您也可以将区域切换功能与手动触发器结合使用。

在控制台的“区域切换”页面上,我选择触发器选项卡,然后选择添加触发器。

对于计划中定义的每个区域,我选择添加触发器来定义将激活该区域的触发器。最后,我选择了区域切换功能将用于触发区域激活的警报及其状态(正常或警报)。

我现在准备测试使用“区域切换”功能来执行区域转换计划的执行情况。重要的是要从我所激活的区域(即工作流程的目标区域)执行该计划,并使用该特定区域中的数据面板。

以下是使用 AWS 命令行界面(AWS CLI)执行计划的方法:

aws arc-region-switch start-plan-execution \

–plan-arn arn:aws:arc-region-switch::[已去除电话]:plan/resource-id \

–target-region us-west-2 \

–action activate

定价和可用性

在所有商业化的 AWS 区域中,均提供区域切换功能,每个计划每月收费 70 美元。每个计划最多可包含 100 个执行块,或者您也可以创建父计划来最多编排 25 个子计划。

亲眼目睹了构建和维护多区域恢复解决方案所涉及的大量工程工作之后,我非常高兴地看到区域切换功能将如何帮助我们的客户实现这一过程的自动化。要开始使用 ARC 区域切换功能,请访问 ARC 控制台并创建您的第一个区域切换计划。有关区域切换功能的更多信息,请访问 Amazon 应用程序恢复控制器(ARC)文档。您还可以联系您的 AWS 账户团队,咨询有关将区域切换功能应用于多区域应用程序的相关问题。

我期待听到您是如何利用区域切换功能来增强多区域应用程序的韧性的相关情况。


AWS代付、代充值免实名

联系我们阿里云国际免实名