前言

这周 AWS 将更多去年提出的 Preview 版本的服务 GA 了！这次 GA 的服务类型十分多元，包含了 IoT 方面的 Fleet Provisioning，这项服务让用户注册流程能够自动化，节省了不少时间。无服务器方面则是 Amazon EventBridge Schema Registry 正式 GA了，这项服务让前后端应用程序能够彼此串联。

除了多项新服务正式推出外，还有许多服务也增加了新功能。在机器学习领域，Amazon Transcribe Medical 现在支持定制词汇，新增更多专业名词及发音。另外，Amazon Translate 多了墨西哥西班牙语，更道地的语言支持可以供给用户更好的体验。文内我们也将介绍资安相关的 WAF 更新、管理层面的 AWS Systems Manager Explorer 及 AWS Step Functions 还有多项不同领域的新服务及改善喔！

一、焦点新聞

Amazon Elasticsearch UltraWarm 正式 GA

假设今天想要快速读取及分析大量机器的 Log，并快速地排除运行安全问题，除了 Log 储存成本会造成很大的负担，分析的工具还需要相辅相成，并不是件容易的事。

UltraWarm 在 2019 AWS re：Invent 释出 Beta 版，这是一个在 Elasticsearch 里储存 Hot Data 的功能，最多可以储存 900 TB 的 Hot Data，满足以往想要快速存取资料的需求，成本与过往相比，降低了 90 %，在实用及价格上都占有优势。

UltraWarm 支持两种 Storage Tiers：
– Hot Tier: 主要用来创建索引、更新资料及访问资料。
– UltraWarm Tier: 可以存储不常访问的资料

也就是可以根据数据的访问频率进行分类，助于成本优化。但这样还是有疑虑，就是用户如何去决定要不要用，Amazon Elasticsearch Documentation 有提供计算的文件，可以根据自身的需求，计算可预估的成本为何，评估是否使用。

参考来源至：AWS announces Amazon Elasticsearch Service UltraWarm general availability

参考来源至：Announcing UltraWarm (Preview) for Amazon Elasticsearch Service

AWS IoT Core Fleet Provisioning 正式 GA

Fleet Provisioning 是 IoT Core 的一个新功能，能让用户快速注册硬件到 IoT Core 上，像大量制造设备的制造商（OEM），为了测试硬件常一个一个手动注册至 IoT Core 上，这是一件非常麻烦且耗时的事情，甚至可能会拖延硬件开发的周期，所以现在可以透过 Fleet Provisioning 来自动化这些注册流程，包括注册、新增凭证等步骤，替用户节省大量的时间。

参考来源至：Announcing the general availability of AWS IoT Core Fleet Provisioning, a new feature that makes it easy to onboard large numbers of manufactured devices to AWS IoT Core at scale

AWS SageMaker Notebooks 与 Amazon SageMaker Studio 正式 GA

Amazon SageMaker Notebooks 替用户省去以往要手动开一台机器（notebook instance）还要等待它 provision 完环境才可以使用的时间并整合于 SageMaker Studio 中，SageMaker Studio 则是一个整合式的机器学习开发环境，让用户可以在同一个环境中建置、训练、部署和分析模型。

目前这两个服务正式GA，目前可于 US East（N. Virginia）、US East（Ohio）、US Wes（Oregon）和 EU（Ireland）使用。

参考来源至：Announcing General Availability of Amazon SageMaker Notebooks and expansion of Amazon SageMaker Studio to additional AWS regions

AWS Transit Gateway Network Manager 添加 Route Analyzer 功能

AWS Transit Gateway Network 是一款监视、管理 Transit Gateway 的功能，降低了跨 AWS 区域和远程位置管理网络操作复杂性，此次更新后，新增 Route Analyzer 功能，助于分析路由，可以透过实时流量，去测试路由配置、排除流量中断的问题等，确保路由正常运作。

这个功能可以进行 2 个 Transit Gateway 在对等传输时的路由分析，以下图为例，可以看到 Transit Gateway 1 可以连接到 2 个 VPC ， Transit Gateway 2 可以利用 VPN 连接到地端网络。现在需要使用 Route Analyzer 确保 VPC 和地端网络能够相互路由：

• 首先你需要设置Source来源，指定 Transit Gateway 1，从 VPC A 当中的 CIDR Block 选择 IP 地址，例如：10.0.0.7。
• 设置 Destination 目标地，指定 Transit Gateway 2，在地端网络范围内指定IP地址，例如：172.31.0.8。
• 选择 Include return path in results。
• 开始路由分析，下方图片就是运行结果，你可以看到从 Transit Gateway 1 到 Transit Gateway 2 路径，可以看到要返回的时候，发生中断的状况，这样一来可以迅速发现问题，以便快速修正。

参考来源至：Announcing Route Analyzer in AWS Transit Gateway Network Manager

参考来源至：Route Analyzer official document

Amazon EventBridge Schema Registry 正式 GA

Amazon EventBridge 是一个无服务器的服务，可以帮助用户串连不同 AWS Account 或是在相同 AWS Organization 的 AWS Account 中的应用程序。不同账户的用户可以将应用程序执行完所产生的 Event 存放在一个共享的 Registry，且在 EventBridge Schema Registry 的 Event，会使用可以直接引用在代码之中的格式来记录，方便前后端应用程序彼此串接。

举例来说，企业或组织在开发系统时，经常将系统功能的前后端逻辑交由不同的开发团队执行，以提高效率。当前端程序执行完后（例如：接收到前端使用者的请求），会把接收到的信息传送到后端程序做判断、处理（例如：数据的完整性、真实性），最后才呈现结果。

如果两个开发团队使用不同的 AWS Account 开发，AWS resource 是分割而无法互通，需要一个媒介来让应用程序可以彼此沟通。使用 Amazon EventBridge Schema Registry 便可以作为情境中的媒介，顺利的把 Event 的内容传递到另一个 Account 的程序中。

• 情境如下图：CreatAccount 的前端程序收到创立帐户的请求后，触发 Lambda 判断请求的内容，最后生成 ACCOUNT_CREATED 的 Event。此Event 会放在 EventBridge Schema Registry 里，提供给 FraudCheck 做后续 FAKE_ACCOUNT 的查验。
• CreatAccount 的前端程序及 FraudCheck 后端程序在不同的 AWS Account 开发。

情境參考自：AWS Blog: New – Amazon EventBridge Schema Registry is Now Generally Available

• 建立 Event bus 时，可选用共享的目标用户。可直接指定 Account ID，也可以选择 AWS Organization。

• 创建好之后，启用 discovery 来发布 Event，之后后端程序就可以搜索 Registry 里的 Event。

而组织要如何管控谁可以推送/ 访问在同一个 Registry 的资料呢？EventBridge Schema Registry 支持 resource policies。在创建EventBridge Schema Registry 后，管理者可以指定 IAM Policy 来控制使用的权限，确保只有项目内的人员才可以取用 Registry 內的 Event。

例如：运用 Principal 参数限制可使用的 AWS Account。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GiveSchemaAccess",
      "Effect": "Allow",
      "Action": [
        "schemas:ListSchemas",
        "schemas:SearchSchemas", 
        "schemas:DescribeSchema",
        "schemas:DescribeCodeBinding",
        "schemas:GetCodeBindingSource",
        "schemas:PutCodeBinding"
      ],
      "Principal": {
        "AWS": "123412341234"
      },
      "Resource": [
        "arn:aws:schemas:us-east-1:432143214321:schema/discovered-schemas",
        "arn:aws:schemas:us-east-1:432143214321:schema/discovered-schemas*"
      ]
    }
  ]
}

参考来源至：Amazon EventBridge schema registry is now generally available

二、其他服务更新

AWS RoboMaker 针对模拟任务添加账户级别的 CloudWatch 指针

RoboMaker 让用户可以通过模拟环境来测试与部署机器人相关的应用程序，以往用户可以从每个模拟任务的指标中监控此次模拟所消耗的资源与结果等。

此次新增了账号层级的指标，会汇总所有个别仿真任务的指标数值，如此一来用户便可以透过 CloudWatch Alarm 设置警报，例如：用户希望某资源只要超出一定用量就通知用户。

参考来源至：AWS RoboMaker now supports account-level metrics for simulation resources

快速搬迁 WAF Classic 规则至 AWS WAF

AWS WAF 为新版的 Web 应用防火墙，作为 WAF Classic 的替代品，在规则（rule）中新增支持「巢状规则（nested rules）」、「布林逻辑表达式（Boolean combinations）」、「完整的 CIDR 表示法」等新设定，让用户能够更细致的定义防火墙的规则。

但 WAF Classic 中的规则是没有办法与新版 WAF 共享的，导致许多先前使用 WAF Classic 的用户得自己在新版 WAF 重新建立规则，而此次更新后，可以通过搬迁精灵（migration wizard）功能快速的将 WAF Classic 的规则转换成 Cloudformation template，让用户可以利用此 template 迅速部署新版WAF的规则。

参考来源至：AWS WAF now supports migration wizard for converting WAF rules from AWS WAF Classic

Amazon Transcribe Medical 支持定制词汇

Amazon Transcribe Medical 是一款将语音转换成文字的服务，适合用在医学、专业领域上，假设今天医生在看诊时，需要纪录病患的症状、用药注记，利用 Amazon Transcribe Medical 可以加快纪录速度，也让病患的体验更好，但是在医学上面有许多专业名词是较少见的，导致在记录上可能有错误，此次更新后，新增客制化词汇功能，新增专业名词的发音及文字，提升转换文字的准确度。

参考来源至：Amazon Transcribe Medical now supports custom vocabulary

AWS Storage Gateway – File Gateway 现在支持 S3 Intelligent-Tiering 作为保存地点

运用 S3 Intelligent-Tiering 可帮助用户自动将不常存取的文件转换至收费比较便宜的储存空间，而当文件被频繁访问时，在转移到一般的储存空间，以恢复原先支持的存取速度。

在此更新之前，当用户利用 File Gateway 作为地端环境的 Shared File System，并把文件存放在 AWS 上时，用户如果想运用 S3 IA （S3 Infrequent access） 来做部分成本优化，需要自行评估文件未来被存取的频率，再通过 S3 Lifecycle policy 来转移文件的位置。过程不仅好时也费力，且容易产生错误评估的结果，导致资源无法做出最适合的配置。

现在，用户可以设定 S3 Intelligent-Tiering 作为 File Gateway 的目的地，让 S3 自动判断文件的访问频率，并转移储存的地点。不仅帮助用户节省成本，也不会影响到现行系统的运行状况。

参考来源至：AWS Storage Gateway adds Amazon S3 Intelligent-Tiering for File Gateway

Amazon Translate 现在支持墨西哥西班牙语 (Mexican Spanish)

此次更新后，用户可以运用 Amazon Translate 转译墨西哥西班牙语，获得更良好的用户体验，而 Amazon Translate 现在支持的语言也来到了 55 个。

参考来源至：Amazon Translate now adds support for Mexican Spanish

Amazon VPC flow logs 添加更多 metadata 可供记录

云端安全性一直是许多用户在运用云端布建资源时的考量点，因为透过网络连接云端资源，容易增加系统受到网络攻击的可能性，例如：接收到未知来源的请求时，应该拒绝存取还是允许进入？因此有些用户会利用 VPC flow logs 来监控网络环境中流量的状态。透过 VPC flow log 的纪录，可知道 VPC 里流量的起始点与终点的 Endpoint 及 Port，甚至是每个请求做了什么动作。

VPC flow logs 的纪录是以 Elastic Network Interface 为基准，VPC 里具有 ENI 的机器都会被记录到。

此次更新后，用户可以在 VPC flow logs 得知 ENI 所在的位置，像是 Region、Availability Zone、Local Zone 等等，取得更多可供分析及追踪的信息。此外，现在所有的 VPC flow logs 都可以推送到 CloudWatch Log Group 或是 S3 存放。

参考来源至：Add enriched metadata to Amazon VPC flow logs published to CloudWatch Logs and S3

Amazon EC2 现在支持为 Amazon Machine Images （AMIs） 添加别名

Amazon Machine Images (AMIs) 是启用一台 EC2 时，必须指定的一项元素。AMIs将提供 EC2 启用时所需的信息，用户选用不同的 AMIs 就可以启用不同的 EC2。而用户也经常针对自己特殊的需求（例如：希望 EC2 在创立过程中可以安装好 Apache Web Server），可通过定制 AMIs，以原先的 AMIs 为基底，产生符合自身需求的 AMIs。往后只要用自制的 AMIs 启用 EC2，就可以省去每次启用都要让 EC2 执行安装、设定脚本的时间。

而每次定制 AMIs，都会产生一组独有的 AMIs ID，以区别内容的不同。当用户对 AMIs 更新（reversion）时，新版的 AMIs 会有新的 AMIs ID。 如果用户原先是利用预先写好的脚本自动化创立 EC2，会导致用户每一次更新 AMIs 都要去修改脚本内的 AMIs ID，才可以让自动化脚本创立新版的 EC2。

此次更新后，用户不需要再持续修改脚本内的 AMIsID，透过设立别名（aliases），在创立新版 AMIs 时，指定别名，下次自动化脚本在创 EC2 时直接认别名来选用 AMIs 就可以创立新版 EC2，省去了修改脚本的过程。

• 示例：使用 AWS CLI 运行 run instance 的命令来启用 EC2。

aws ec2 run-instances \
    --image-id resolve:ssm:MyGoldenAMI \
    --count 1 \
    --instance-type c3.large \
    --key-name MyKeyPair \
    --security-groups MySecurityGroup

示例中的 ssm:MyGoldenAMI 是用来识别 AMIs 的别名，只要是相同用途、不同版本的 AMIs 都会指定相同的别名。别名可存放在 AWS System Manager 里，并给予用户取用 System Manager 资源的权限，就可以成功执行示例中的指令。

参考来源至：Amazon EC2 now supports aliases for Amazon Machine Images (AMIs)

AWS Systems Manager Explorer 现在可以将不同帐号的 Trusted Advisor checks 统整在同一个 dashboard

Trusted Advisor 是一个可提供即时建议的服务，针对不同面向，例如：资安、成本、效能、容错力等等，建议用户按照 AWS 最佳实务来布建资源，以优化使用情景。

此次更新后，AWS Systems Manager Explorer 可以把不同帐号的 Trusted Advisor checks 统整在一起，帮助用户得到整体的营运报告，进而监控、调查系统的状态，最后可改善系统的效率、花费、可靠度及安全性。

参考来源至：AWS Systems Manager Explorer now provides a multi-account summary of Trusted Advisor checks

AWS Step Functions 工作流程添加 AWS CodeBuild 服务

AWS Step Functions 让用户在定义工作流程可以使用多种 AWS 服务（例如AWS Fargate、Amazon SNS，AWS Lambda），藉此直接调用并传递参数给这些服务的 API。工作流程主要由一系列步骤组成，如下图当我们要处理 ETL 流程时，就可利用 Step Functions 进行建构，规范每一步骤要使用的服务与传递的参数。Step Functions 也有支持在发生错误时重试、平行处理等相关功能，让使用者在开发时方便修改，并且可以追踪每个步骤的状态。

除了原先的服务，AWS Step Functions 现在支持使用 AWS CodeBuild 服务，这项更新用户将可直接在 AWS Step Functions 中呼叫 AWS CodeBuild 服务相关 API，如 StartBuild、StopBuild 等 API，利用这些 API 用户可以自定义 CI/CD 的流程，像是自动化测试系统 API 等，如下图。透过Step Functions，藉由参数决定是否进行测试，然后在触发 AWS CodeBuild 进行测试，当测试结果产生后再利用 SNS 寄送通知给用户们。这次的更新将可以节省用户在进行 CI/CD 所花费的时间并减少撰写重复的代码，同时利用发生错误时重试、平行处理等功能创建更弹性的工作流程。

参考来源至：AWS Step Functions now supports AWS CodeBuild service integration

参考来源至：Orchestrate multiple ETL jobs using AWS Step Functions and AWS Lambda

参考来源至：New – Building a Continuous Integration Workflow with Step Functions and AWS CodeBuild

Amazon CloudWatch 添加 Prometheus metrics

Prometheus 是一个第三方开源的项目，用于监控应用程序的状态。过去用户如果想观看 Container 里 Prometheus 监控的结果，需要连入个别的 Container 下指令查询，一旦 Container 的数量提高，查询就会成为一项耗时耗力的手续，最后导致管理上的不便。此次更新后，对于已习惯使用Prometheus 作为监控应用程序工具的用户，不再需要手动查找，而是通过安装于 Container 的 AWS CloudWatch Agent 来收集 Prometheus metrics，并推送到 CloudWatch metrics，作为一个集中管理、呈现的平台。

目前 Prometheus metrics 仅支持 Amazon Elastic Kubernetes Service （EKS） 和在 EC2 上的 Kubernetes clusters，预计未来也会支持 Amazon ECS 和 AWS Farget。

针对现有已运行在 Kubernetes 且支持 Prometheus 的 CloudWatch Agent，用户须先删除旧有的版本再安装新版，才能成功将 Prometheus metrics 推送到 CloudWatch metrics。此外，CloudWatch Agent 利用一个 YAML 文件来指定如何收集 Prometheus metrics，用户若有定制的需求，也可以更动此 YAML 文件成自己所需的。更多安装方式请参考 Amazon CloudWatch Doucmentation。

参考来源至：Amazon CloudWatch now monitors Prometheus metrics – Now in Beta