AWS Recent Announcements(6/1～6/12)
はじめに（定型文）
AWSのUpdate情報の中で、個人的に気になったものをピックアップします。
（Update以外でも新しく知った情報や、たまにAWS以外の情報も記載するかもしれません）
※日本語は反映が遅いので基本英語版で見ています
AWS Step Functions launches an interactive workshop for building and deploying application workflows
Step Functionsの学習用ワークショップ資料が公開されました。
（What's Newの中にワークショップ資料の追加までアナウンスされるイメージはあまりなかったですが）
Step Functionsは去年あたりから大幅に更新が入ってかなり使いやすくなっており、様々なAWSサービスと統合されてLambdaを書く必要性も少なくなっているので、勉強しておいて損はないサービスだと思います。
Amazon EMR Serverless is now generally available
EMR Serverlessがリリースされました。
EMRはSparkやPrestoといった分散フレームワークを容易に構築できるサービスです。
複数のEC2、もしくはEKSクラスターなどのインフラを必要とするので、提案の際にコストがネックになりがちでしたが（Redshiftなども同様）、Serverlessが使えることにより小規模なシステムでも利用しやすくなると思います。
（東京リージョンでも使えます）
AWS Elastic Disaster Recovery now supports multiple staging and target accounts
AWS Elastic Disaster Recovery（DRS）が複数のステージング・ターゲットアカウントに対応しました。
（以前はCloudEndureのDisaster Recovery機能として提供されていたものと記憶）
今回、ステージアカウントとターゲットアカウント（※）を複数（最大300→3000と謳っているのでおそらく10個まで）選択できるようになりました。
（下記のようなイメージです（ドキュメントより抜粋））
Announcing AWS Cost Allocation Tag API
コスト割り当てタグの設定がAPIで実施できるようになりました。（以前はコンソールのみ）
これにより、アカウントの初期構築作業などの中で自動化できそうと思いましたが、現状Cloudformationには対応していないようです。
AWS Mainframe Modernization is now generally available
メインフレームのアプリケーション移行用のサービスがリリースされました。
AWS Health Dashboard streamlines service transparency via Connector for ServiceNow
AWS Service Management ConnectorでServiceNowと連携できるようになりました。
（おそらく連携自体は個別実装すればできたかと思いますが、それがConnectorで簡単にできるようになった）
上記リンクはHealth Dashboardと連携できるようになった旨のアップデートですが、同様にServiceNowと連携できるようになった系のアップデートがいくつか出ていました。
ServiceNowはITILで言うところのITサービスマネージメント（ざっくり言うと運用）に位置付けられるプロダクトで、大きめ且つハイブリッド環境のところだとよく使われるので、できることを覚えておくと業務の幅が広がるかもしれません。
（ちなみにJIRAも対応）
Amazon Aurora PostgreSQL-compatible edition now supports zero-downtime patching
Aurora PostgreSQLでゼロダウンタイムパッチ（ZDP）がサポートされるようになりました（元々はMySQL版でのみサポートされていた機能）。
これにより、マイナーバージョンとパッチバージョンの更新時はダウンタイムが発生しないため、実働環境で無停止でのバージョンアップが可能となります。
（元々マイナーバージョンアップであればダウンタイムは30秒～1分ぐらいの短期間ではありましたが）
※どうでもいいですがこの機能、サービス利用者にはすごく重要だと思うのですが、ドキュメントで明確に記載されている箇所が無い（見つけられていないだけもしれませんが）のはかなり謎です
Amazon Aurora PostgreSQL supports LO module
Aurora PostgreSQLでラージオブジェクト（LO。もしくはBLOB）が拡張機能でサポートされるようになりました。
ラージオブジェクトはテーブルにサイズの大きなデータ（動画や画像など）を大容量オブジェクトとして格納する際に利用する機能で、これによりDBのトランザクション機能を利用しつつ大きなサイズのデータを扱えるようになるメリットがあります。
（DynamoDBではサイズの大きなデータをS3に配置し、テーブルにはその配置先を格納するユースケースがあるので、その別解だと想像）
全然関係無いですが、ずっと前から東京リージョンにも欲しいと思っていたAuroraのバックトラックの機能、MySQL版限定ですがいつの間にか日本上陸を果たしていたようです（6/12時点で英語ドキュメントのみ記載）
AWS Recent Announcements(4/30～5/31)
はじめに（定型文）
AWSのUpdate情報の中で、個人的に気になったものをピックアップします。
（Update以外でも新しく知った情報や、たまにAWS以外の情報も記載するかもしれません）
※日本語は反映が遅いので基本英語版で見ています
Amazon RDS now supports Internet Protocol Version 6 (IPv6)
AWS adds new management features for EC2 key pairs
キーペアの管理機能が更新され、作成日と公開鍵が取得可能になりました。
また、Cloudformationでキーペアの作成・削除も可能になったので、今後はEC2を立てる前に事前にキーペアを作っておく必要がなくなりました。
（コンソールだとこんな感じ）
AWS Network Firewall now supports AWS Managed Threat Signatures
Network FirewallのマネージドルールにTheat Signatureのマネージドルールが追加されました。
元々Network Firewallは（TrendMicroやPaloAltoなどの製品と比較して）ルールの維持が難しく、Suricataのルールなどを使っていても手動更新になるので運用負荷がかなり高かったのですが、マネージドルールはAWS側で自動更新されるため、そうした運用が軽くなることが期待されます。
※ちなみに「Theat Signature」はセキュリティ界隈の一般用語で、「Signature」は（攻撃の）「特徴的なパターン」をという意味らしいです
Amazon EKS console now supports all standard Kubernetes resources to simplify cluster management
EKSのコンソールから全ての標準kubernetesリソースが確認できるようになりました。
以前はPodやNodeといった一部のリソースしか確認できませんでしたが、UIも一新されて見やすくなりました。
（カスタムリソースは引き続きkubectlで確認）
Amazon RDS Performance Insights now allows you to more easily see metrics for any time interval
RDSのPerformance Insightsのメトリクス表示がカスタム時間に対応しました。
以前は過去1日や1週間といった大雑把な期間でしか指定できませんでしたが、細かい時間指定が可能になりました。
（元々保持期間が2週間とかなので大した問題ではありませんでしたが、選択肢が増えるのはありがたい）
Amazon EBS Snapshots Archive is now available in additional regions
EBSスナップショットを別リージョンにアーカイブする機能が大阪リージョン（他）でサポートされるようになりました。
大阪リージョンで利用可能になったことで、リージョン障害時の選択肢として使いやすくなると思います（海外リージョンだと法律の壁がある場合があるので）
注意点としては、EBSスナップショットは通常増分バックアップですが、アーカイブするとフルバックアップを保持する仕様になるため、あまり何世代も保持するようになっていると余計にコストがかかる場合があります。
（詳しくは↓のサービスアップデートで説明されています）
サービスアップデート Storage 編：Part1 (S3, EBS, EFS, Snow Family)
AWS Serverless Application Model CLI now supports enabling AWS X-Ray tracing
元々SAMのテンプレートでLambdaのX-Ray有効化はできましたが、sam initに"--tracing"オプションを追加することでテンプレート生成時に自動でX-Ray有効化の設定を追加してくれるものです。
X-Rayアクティブトレースはコード修正無しで設定可能ですが、トレース可能なのはLambda関数での処理であり、接続先（DBなど）の処理は参照不可になります。
（逆に言うと、その制約を許容できるのであれば割と使える機能かと思いました）
【SAMテンプレートでのX-Rayアクティブトレース設定例】
（アップデート自体は「ふーん」という感じでしたが、LambdaのX-Rayアクティブトレースについてちゃんと知らなかったので確認ついでにピックアップ）
Amazon RDS for PostgreSQL supports cascaded read replicas for up to 30X more read capacity
RDS for PostgreSQLのv14.1以降でカスケードリードレプリカが利用可能になりました。
カスケードリードレプリカはリードレプリカのソースにリードレプリカを追加して階層構造にする方式で、これによるメリットは主にソースDBインスタンスへの負荷軽減です。
PostgreSQLではWALプロセスがDBの更新内容をキャッチしてリードレプリカインスタンスに送信していますが、読み取りスケールのためにリードレプリカを複数（最大5つ）構築しているとその分WALプロセスの処理負荷が上がり、ソースDBインスタンスの負荷が上がるという問題があります。
カスケードリードレプリカを利用するとリードレプリカのソースをリードレプリカに設定できるため、その更新処理をリードレプリカに外出しすることが可能となり、結果ソースDBインスタンスの負荷が軽減されるというものです。
（ちなみにAnnounceではカスケード込みで最大155まで作成可能とありましたが、この計算方法がいまいちよくわかってないです）
※参考
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.html
RDSも色々と進化しており、マルチAZとリードレプリカのメリデメは資格試験だと定番だったりするのですが、今では「マルチAZ且つリードレプリカ」が作成可能となっており、知識の陳腐化が起こっていたりします。
あとは自分は知らなかったですが、（Auroraではない）RDSでもリージョン間のリードレプリカが作成できるようになっていました。
（普段Auroraしか使わないので見落としていた可能性もありますが）
The New Amazon ElastiCache console is now available
Elasticacheのコンソール画面が更新されました。
以前の画面は一部の設定値を表示させる際に無限にリロードが発生するなど（個人的に）かなり使いにくかったですが、他サービスと同じようなUIになりかなり使いやすくなりました。
AWS Service Catalog Provisioning constructs for the AWS Cloud Development Kit (AWS CDK) are now available
最近Service CatalogでCDKが利用可能になったアップデートがありましたが、CDKのコンストラクトを既存のService Catalog製品から生成してくれるツール（ビルダー）が提供されました。
コンストラクトとは、CDKにおけるリソースの構成単位のことで、ある程度のリソースをセット且つ細かいパラメータはwell-architectedに従ってよろしく決めてくれるもの（抽象度の高いもの）から、Cloudformationと同じ単位で細かくパラメータを設定できるもの（抽象度の低いもの）などがあります。
CDKは基本的に記述コストが重いのですが（抽象度の高い方が使えるなら別ですが、実案件では細かいカスタマイズが必要になることが多い）、既存からのインポートができることでその負担軽減が期待されます。
（元々はCloudformationのリソース定義をコンストラクトとして引っ張ってくるツールで、それにService Catalogのインポート機能が追加されたものと思われる）
※ちなみにService Catalog with CDKのWorkshopもあるようです。
Amazon Braket Hybrid Jobs now supports embedded circuit simulations, improving the performance of certain hybrid quantum-classical algorithms by over 10X
Amazon BracketのHybrid Jobsが組み込み回路シミュレーターをサポートするようになり、パフォーマンスが向上したようです。
この場合の「Hybrid」とは、量子コンピューティングと古典（所謂従来型）のコンピューティングを組み合わせるという意味です。
（量子コンピュータは特定の計算には強いものの、それ以外の一般的な用途では古典コンピュータの方で十分な性能が出せるということで、それを組み合わせて実用性のある結果を出そうというアプローチ）
※量子コンピュータは個人的に関心があるものの、中身はよくわかっていないので紹介まで
はじめに（定型文）
AWSのUpdate情報の中で、個人的に気になったものをピックアップします。
（Update以外でも新しく知った情報や、たまにAWS以外の情報も記載するかもしれません）
※日本語は反映が遅いので基本英語版で見ています
Amazon EC2 adds CloudWatch Events support for Amazon Machine Images
AMIの状態変化（イメージ作成・登録・登録解除など）のイベントをEventbrigeに送信可能になりました。
AMI作成であればパイプラインツール（Codepipelineなど）か、もしくはImageBuilderを利用するかと思いますが、EventBridgeを利用するとアーキテクチャーを疎結合にできるメリットがあります。
※疎結合のメリットは、呼び出し元（ソース）と呼び出し先（ターゲット）の機能を分離することで、ユーザーに応答を早く返せるのでレスポンス速度が上がる、機能や宛先の追加時には呼び出し先（ターゲット）の追加だけで済むので拡張性が高まるといったあたりです
（参考）
Announcing new workflow observability features for AWS Step Functions
StepFunctionsの実行結果確認画面が拡張されました。
従来の表示（グラフビュー）に加え、Table view、Event viewが追加され、アクション単位での処理結果やステートマシン実行の事前処理などの所要時間といった詳細情報が見やすくなりました。
（「新しい実行ページ」をオンにすると見れます）
※下記はEvent viewの画面例
AWS Secrets Manager now publishes secrets usage metrics to Amazon CloudWatch
Secrets Managerのシークレット数（count）のメトリクスがCloudwatchで取得可能になりました。
単純に取れる情報が増えたのは嬉しいことですが、「an unexpected increase or decrease in number of secrets.（予期せぬシークレット数の増減）」というのがどんな状況なのかわかっていないので、具体的な用途は思いつかないですが（監視目的？）。
Amazon Athena now supports views in Apache Hive metastores
Athenaが外部のHiveメタストアのビューに対してクエリを実行できるようになりました。
Hiveメタストアとの接続は以前から（AthenaからLambdaを呼び出して）できたものの、Hiveビューを参照するためのクエリがAthenaでサポートされていなかったため利用できなかったものが今回解消した、というアップデートのようです。
（Athenaがクエリを自動解釈可能になった）
※Hiveメタストアの利用方法
AWS PrivateLink announces support for IPv6
※以前の構成
Amazon VPC Traffic Mirroring now supports sending mirrored traffic to Gateway Load Balancer backed monitoring appliances
VPC Traffic Mirroringのターゲット（送信先）にGateway LoadBalancer（正確にはGateway LoadBalancerのエンドポイント）を指定できるようになりました。
（以前はENIとNLBのみ）
VPC Traffic MirroringはVPC上を経由するパケットの情報を指定したターゲットにコピーして送信する機能で、VPC FlowLog（L4レイヤー）では確認できないパケットフィルタリングやパケットの監査を行う時などに利用する機能です。
※AWSブログ記事
※構成図
Amazon VPC now supports multiple IPv6 CIDR blocks
CIDR追加が可能になったメリットの例は、Amazon管理のCIDRに追加して顧客管理のIPv6 CIDRの利用（BYOIP）が可能となり、ネットワーク上の境界を設けることができるようになった点です。
（現状IPv6を利用する案件はまだ無いですが、諸々の制約が徐々に解消されているので、そろそろ使わない利用は無くなってきているのかなと個人的には思い始めています）
AWS Control Tower can now use customer provided core accounts
Control Towerのコアアカウントで既存のアカウントを指定できるようになりました。
コアアカウントはControl Towerの中でも特別な機能を持つアカウントで、管理アカウント、監査アカウント、ログアーカイブアカウントの3種類があり、今回のアップデートでランディングゾーン設定時に既存アカウントが指定できるようになったとのことです。
（Control Towerにあまり明るくないので何のことかわかりませんでしたが、設定時の画面で「既存のアカウントの使用」というのができるようになったということみたいです）
Amazon CloudWatch announces improved console experience
CloudwatchのUIが更新され、ダッシュボードやロググループのお気に入り設定が一覧表示できるようになりました。
最初ロググループのお気に入り設定のやり方がわかりませんでしたが、ロググループを参照すると下記画面の「最近のアクセス」のところに追加されるので、そこで星マークを押すと登録できるようです（直感的ではないのでそのうち修正されそうですが）
AWS Resilience Hub adds support for Terraform, Amazon ECS, and additional services
Resilience HubでECSやRoute53などのサービス追加の他、Terraformのコードがサポートされるようになりました。
Resilience Hubはアプリケーションのコードをアップロードすると復旧時間などをレジリエンススコアとして評価してくれる機能で、ProtonのようにTerraformと連携できるサービスは今後も増えていくかもしれません。
（Resilience Hub自体は使ったことないのであまりピンと来ていませんが）
Announcing general availability of 1-click public embedding available with Amazon QuickSight
Quicksightは元々お値段控えめの読み取り専用ユーザー（閲覧者）のライセンスも提供していましたが、こちらはライセンス不要なので、社内のポータルサイトにダッシュボードを表示させる、といった用途に利用できます。
（Quicksightのダッシュボードだけ見せたい、というケースは多そう）
Announcing Multi-Account Support for AWS Transit Gateway Network Manager
Transit Gateway Network ManagerがOraganization内のマルチアカウント管理に対応しました。
Network Managerはリージョン間やVPCなどのネットワークトポロジー間の通信経路を可視化できる機能で、従来は単一アカウントのみでしたが、これがマルチアカウントに対応できるようになりました。
Network Managerという機能自体は遠い昔の記憶で何となく覚えがありますが、実際に使ったことはなかったので、マルチアカウントで大規模なネットワーク管理を行っている場合は使えそうな機能だと思いました。
（また、Network Managerで管理しているとRoute Analyzerでルーティングの検証も可能なので、Reachavility Analyzerと合わせてできることは色々ありそうです）
Two new storage locations available for AWS DataSync
DatasyncのLocationとしてAzure Storageと（GCの）Cloud Storageがサポートされるようになりました。
DataSyncはオンプレミスやAWSストレージ間でデータ同期を行うサービスで、主に移行やバックアップの用途で使うことが多いですが、AzureやGCのデータをS3に転送（同期）できるようになったことで、クラウド移行やマルチクラウドの運用に選択肢ができたと思います。
（直近、Azure→AWSの移行案件をやっているので、可能なら試してみたいと思います）
Amazon EC2 enables customers to protect instances from unintentional stop actions
EC2インスタンスで停止保護が設定できるようになりました。
インスタンス終了（削除）保護は前からありましたが、停止保護を設定することでステートフルワークロード用途やインスタンスストア（一時）ボリュームを使っている場合に意図しない停止から保護することができます。
（停止保護が入っていると終了保護も入るようです）
AWS Systems Manager announces support for port forwarding to remote hosts using Session Manager
従来はSSHを利用する必要がありましたが、SSMの機能（ドキュメント）で実施できるようになりました。
（SSH経由だとSCPも使えて便利なので、完全上位互換というわけではないとは思いますが）
アップデート記事にリンクされているドキュメントからはやり方などがよくわからなかったので、自分でも試してみました。詳細は下記に記載しています。
Amazon ECS simplifies Capacity Provider integration with Auto Scaling groups
ECSのキャパシティプロバイダーとEC2 AutoScaling Groupの統合が簡素化されました。
普段はFargateしか使わないので詳細は雰囲気程度にしかわかっていませんが、これまではターゲット追跡ポリシーでECS（on EC2）のAutoScalingを設定する場合、ECSタスクを増やすポリシーと実行するEC2インスタンスを増やすポリシーを設定していたものが、ターゲット追跡ポリシーの中で両方書けるようになって簡素化した、という内容のようです。
（間違っていたらすみません）
SSMでリモートホストにPortForwardingする
はじめに
下記アップデートにて、SSMのドキュメントでPortForwardingができるようになりました。
リンク先のドキュメントは何も書いてないに等しかったので、調査がてら試してみることにしました。 （尚、コンソールのセッションマネージャーやRunCommandからできたら楽だったのですが、現状はできない模様です）
やりたいこと 今回はローカルPCからプライベートサブネット上のDocumentDBにログインしてみます。
【接続経路】 ローカルPC(WSL2)→EC2(AmazonLinux2)→DocumentDB(Port:27017)
※接続先がDocumentDBなのは今案件で使っていて試しやすかっただけで他意はないです（EC2やRDSでも可能です） ※そのせいでMongo-shellの実行環境を作る必要があって地味にめんどくさかったのは秘密
事前準備
PortForwarding用のEC2インスタンスを作成します。 基本デフォルト（キーペアもSGのインバウンドルールも不要）で問題ないですが、セッションマネージャーで接続ができることが前提なので「AmazonSSMManagedInstanceCore」権限のあるインスタンスプロファイル（IAMロール）をアタッチしてあれば良いです。
また、PortForwardingはSSMエージェントのバージョンが「3.1.1374.0以降」である必要があります。 尚、検証時点（※5/28）のAmazonLinux2のAMIにデフォルトで入っているエージェントは地味にバージョンが足りないので、利用する場合は手動アップデートが必要になります。 （昨日今日に追加された機能なので、そのうち更新されると思います）
※検証時点（※5/28）で起動したインスタンスのSSMエージェントバージョン
# rpm -qa | grep -i ssm amazon-ssm-agent-3.1.1188.0-1.amzn2.x86_64
※バージョンアップ手順はこちら
https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-al2.html
※更新後のバージョン
# rpm -qa | grep -i ssm amazon-ssm-agent-3.1.1446.0-1.x86_64
接続コマンド
SSMドキュメント名は「AWS-StartPortForwardingSessionToRemoteHost」です。 詳細はドキュメントの説明（SSMのコンソールから見れます）に譲りますが、パラメータにローカル/リモートのポートと転送先のホスト（今回はDocumentDBのエンドポイント）を設定すれば接続できます。
$ aws ssm start-session --target i-xxxxxxxxxxxx --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters 'portNumber=27017,localPortNumber=27017,host=docdb.cluster-abcdefghij.ap-northeast-1.docdb.amazonaws.com' Starting session with SessionId: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Port 27017 opened for sessionId xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Waiting for connections...
実行後、別画面でlocalhost宛てに接続すれば転送先にログインできます。
$ mongo --host localhost:27017 --username mongo
MongoDB shell version v4.4.14
Enter password:
connecting to: mongodb://localhost:27017/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("c5988ed1-5497-4e17-9138-16ae18b0b71e") }
MongoDB server version: 4.0.0
(※中略)
rs0:PRIMARY>
参考
WSL2でMongo-shellを使いたい場合、単にaptではインストールできないようです。 自分は下記サイトを参考にしました。 （DBが必要なわけではないのでmongodb-org-shellのみインストールしました）
