【AWSアプデ 06/17】AWS KMS で Multi-Region Keys をサポート他6件【#毎日AWS #220】

はじめに
アップデート内容
最後に

はじめに

今回は、 06/17のアップデートについて紹介していきます。
こちらの内容については、YoutubeやPodcastでもアップロードしているので、気になる方はぜひチェックしてください。

■ Youtube での配信

youtu.be

Apple Podcast や Spotifyなど、各種配信サービスにて「サーバーワークス」で検索！

では、さっそく最新1日のアップデートを見ていきましょう。
今回は 06/17、7件のアップデートがありました。

アップデート内容

AWS KMS で Multi-Region Keys をサポート

暗号化キーの作成・管理を行う AWS KMS が Multi-Region　Keys のサポートをしました。

どんな機能か?と申しますと、ある AWS リージョンから別のAWS リージョンにキーを複製できる機能となります。
仕様として、コピーした KMS キーは同じキーマテリアルとキーIDを持っているため、完全に同じキー扱いとなるそうです。

■メリット

①開発者は、暗号化されたデータの移行プロセスを非常に簡単におこなえます。

今まで、リージョンごとに異なるキーを使う必要があり、暗号化されたデータの移行が非常に複雑でした。
例えば、東京リージョンで暗号化されたデータをシンガポールリージョンに移行したい場合、暗号化データを東京リージョンのKMSキーで一度復号化したあと、シンガポールリージョンのKMSキーで暗号化して保存するといった感じですね。

今回の登場した機能を利用すれば、暗号化データとKMS キーをそのまま別リージョンに複製するだけで OK という非常に短いプロセスで暗号化データの移行を行えます。

②開発者は、全リージョンに対して、単一の KMS キーで暗号化プロセスを実行できるので、マルチリージョンアプリケーションの設計・運用が楽になります。

アプリケーション内で暗号化・復号化に必要なキーの指定をリージョンごとに変える必要がなくなったり、IAM ポリシーでの権限許可で複数KMSキーのARN を指定しなくてOK になりますね。

■ リージョン

全てのAWS パブリックリージョンでサポートされます。

■ 注意点

CMK のみ対応しています。AWS マネージドキーでは対応していません。

KMS のマルチリージョンコピーは、多くの人に刺さるアップデートなのではないかと思います。
これによって DR 対策が非常にやりやすくなると思うので、ぜひ検証してみてください!

AWS EC2 F1 インスタンスが新しいシェル F1.S.1.0 を発表

アップデート本題に入る前に、使ったことある人も少ないと思うので、AWS EC2 F1 インスタンスに捕捉しますと、

■ AWS EC2 F1 インスタンスとは

FPGA リソースを搭載したインスタンスタイプ。
FPGA とは、「Field-Programmable Gate Array」の略。プログラミングにより、開発者がカスタマイズできる集積回路。CPU が汎用性特化なのに比べて、こちらはカスタマイズに特化しています。したがって、特定のタスク向けに使われることが多いです。
具体例としては、ゲノム処理、データ分析、画像/ビデオ分析、機械学習などの特定ワークロードです。

参考「FPGA」をわかりやすく解説、CPUやASICとどう違うのか https://www.sbbit.jp/article/cont1/37659
Amazon EC2F1インスタンス
https://aws.amazon.com/ec2/instance-types/f1/

今回のアップデートでは F1 インスタンスに新しいシェル F1.S.1.0 が登場しました。

■ FPGA リソースにおけるシェルとは

シェルについて補足しますと、そもそもFPGA の構成要素は固定機能部とユーザロジック部に大きく分かれます。
そのうち固定機能部の方を「シェル」と呼びます。
この固定機能部は、ハードウェアモジュールの集まりでして、ユーザが変更できないスタティックな領域となります。

参考: https://japan.xilinx.com/html_docs/xilinx2019_1/sdaccel_doc/frj1535666552301.html

これまで F1 インスタンスでは、F1.X.1.4シェルが使用されていたのですが、新しいシェルになったことで、性能がアップしました。具体的には、

FPGA リソースの使用量を 30% 削減できる
FPGA とホスト間の転送速度を最大 20 % 向上できる

■ メリット

新しいシェルを使うことで、開発者はより効率よくコンピューティングリソースを扱い、アプリケーション処理を高速化することができます。

■ リージョン

F1 インスタンスが使用できるすべてのリージョンで使用可能です ※ F1 インスタンスは東京リージョンにはまだ対応していないようですが...

FPGA Image generation and EC2 F1 instances are supported in the us-east-1 (N. Virginia), us-west-2 (Oregon), eu-west-1 (Ireland) and us-gov-west-1 (GovCloud US) regions.
引用元 https://github.com/aws/aws-fpga/tree/small_shell#getting-familiar-with-aws

Github 上でシェルの移行ドキュメントが公開されているので、移行を検討する方はそちらも合わせてご確認ください

スモールシェル移行ドキュメント https://github.com/aws/aws-fpga/blob/small_shell/hdk/docs/AWS_Small_Shell_Migration_Guidelines.md

Amazon RDS for PostgreSQL が Extension Allowlists 機能をサポート

RDS for PostgreSQL が Extension Allowlists 機能をサポートし、インストールできる拡張機能を細かく制限できるようになりました

こちらの機能は、PosgerSQL に新しく追加された rds.allowed_extensionsパラメータを psqlコマンドを使って設定することで実装できます。

■ メリット

運用者は、自社のルールやコンプライアンスに従った拡張機能のみを PosgerSQL に対して強制することができるようになります。

■ 注意点

以下バージョンのみ対応しています。

PostgreSQL13.2以降のマイナーバージョン
PostgreSQL12.6以降のマイナーバージョン

参考: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction

こういったガードレール的な機能があると、セキュリティリスクを防ぐのに役立つのでありがたいですよね。

AWS Amplify CLI で permissions boundaries を付与できるように

フロントエンド開発者向けに、バックエンド構築をサポートするサービス AWS Amplify に関するアップデートです。

AWS Amplify の操作を行う Amplify CLI が、生成した IAM Role に対して、 permissions boundaries を付与できるようになりました。

■ permissions boundaries とは

ある IAM ユーザ/ロールが、別のIAMユーザ/ロールを発行する際に許可できる権限を制限する機能です。一言でいえば IAM におけるガードレールでしょうか。
この機能がないと、開発者が自分の権限を越えた IAM ユーザ/ロールを作れるようになってしまいます。

参考: https://www.atmarkit.co.jp/ait/articles/2103/30/news018.html

今までは、Amplify CLI で作成した IAM Role に対して、 permissions boundaries を付与したい場合は、別途、AWSCLI やマネコンでアタッチしてあげる必要があったのですが、
今回のアップデートで Amplify CLI のみで IAM Role の作成から permissions boundaries の付与まで, 完結できるようになりました。

■ メリット

Amplify CLI だけで完結する操作が増えたことで、地味に Amplify CLI を使った構築の手間が減りますね。

■ 注意点

permissions boundaries を設定する上で必要な IAM Policy は自前で用意する必要がございます。

The IAM Policy, to be used as a Permissions Boundary, must be configured outside of Amplify CLI.
引用元: https://docs.amplify.aws/cli/usage/permissions-boundary

そもそも Amplify で構築したときに、IAM Role の permissions boundaries を考慮したことなかったという人もいらっしゃるかなと思うので、自身の環境を今一度ご確認ください。

AWS Copilot v1.8 が登場

AWS におけるコンテナ web アプリケーションの構築・管理を簡単に行える CLI ツール AWS Copilot に関するアップデートです。

AWS Copilot の v1.8 が新しく登場しました。

ポイント3点に絞ってお伝えすると、

ECS 上にデプロイされた、負荷分散された Web サービスのパブリックエンドポイントに対して、マニフェストファイルで、エイリアスを付与できるようになりました。
現状、このエイリアスは、Copilot での初回作成時に指定したドメインのサブドメインとならなければいけません。
実行すると裏側で Copilot がホストゾーンをいい感じで作成してくれます。
参考: https://aws.github.io/copilot-cli/docs/developing/domain/
プライベートサブネットしか存在しない VPC にECS アプリケーションをインポートできるようになりました。
Copilotを使用して完全に分離された環境でアプリケーションを実行できます。
アプリケーションのヘルスステータスの可視性が向上しました。
今までは、copilot svc status コマンドを実行すると、コンテナヘルスチェックのみが行えましたが、今後は、最近停止したECS タスクと負荷分散されたWebサービスエンドポイントに対するのターゲットヘルスチェックを行えるようになります。
リリースノートに copilot svc status を実行したときのサンプルが掲載されていたので、イメージ湧かない方はこちらを見ていただくといいと思います。
参考
■ リリースノート
https://github.com/aws/copilot-cli/releases/tag/v1.8.0