はじめに
こんにちは、なじむです。
先週は SCS の試験があって疲れきってしまいお休みしました。今週は張り切ってやっていきましょう!AWS Japan さんがまとめている週刊AWSで確認した内容の自分用メモ。ギリギリ三週間坊主にならなかった第四回目です。
今回は8/16週のアップデートです。
8/16(月)
AWS Lambda が Python 3.9 のサポートを追加
サーバレスでコードを実行できる Lambda で Python 3.9 が使用可能になりました。
Python 3.9 では、3.8 から大きく以下の変更点が加えられています。詳細は Python 3.9の新機能 を参照ください。
- TLS 1.3 のサポート
- 新しい文字列および辞書のオペレーション
- 辞書のマージ演算子
- 文字列のremoveprefix()メソッドとremovesuffix()メソッド
- 組み込みGeneric型
- 改善されたタイムゾーン(zoneinfo モジュール)のサポート
実際の画面は以下です。
Python 3.9 で Lambda を作成できるようになっています。
- 日本リージョン対応状況
- 東京:対応
- 大阪:対応
Amazon EC2 M6i インスタンスのご紹介
仮想マシンのサービスである EC2 で、Intelの「Intel Xeon Scalable Processor」を搭載した新しいインスタンスタイプの M6i が使用可能になりました。
M6i インスタンスは以下のような特徴があります。
- M5 インスタンスよりも、15% 高いコストパフォーマンス
- インテルの Total Memory Encryption (TME) を使用した常時オンのメモリ暗号化
- vCPU あたり最大 20% 高いメモリ帯域幅
- M5 インスタンスの最大 2 倍のネットワークパフォーマンス
コストを比較してみましたが、料金(東京リージョン)に差はなかったので、おそらくパフォーマンスが 15% 上がっているのかと思います。ベンチマークを取れば分かるのかな…?
インスタンスサイズ | M5 | M6i |
---|---|---|
large | 0.124 | 0.124 |
xlarge | 0.248 | 0.248 |
2xlarge | 0.496 | 0.496 |
4xlarge | 0.992 | 0.992 |
8xlarge | 1.984 | 1.984 |
12xlarge | 2.976 | 2.976 |
16xlarge | 3.968 | 3.968 |
24xlarge | 5.952 | 5.952 |
32xlarge | - | 7.936 |
ネットワークパフォーマンスは M5 の 25GB から、32xlarge では 50 GB になっています。また、各インスタンスサイズでもパフォーマンスが上がっています。
インスタンスサイズ | M5 | M6i |
---|---|---|
large | 最大 10 ギガビット | 最大 12500 メガビット |
xlarge | 最大 10 ギガビット | 最大 12500 メガビット |
2xlarge | 最大 10 ギガビット | 最大 12500 メガビット |
4xlarge | 最大 10 ギガビット | 最大 12500 メガビット |
8xlarge | 10 ギガビット | 12500 Megabit |
12xlarge | 10 ギガビット | 18750 Megabit |
16xlarge | 20 ギガビット | 25000 Megabit |
24xlarge | 25 ギガビット | 37500 Megabit |
32xlarge | - | 50000 Megabit |
実際の画面は以下です。
M5 にはなかった、32xlarge(128 core, 512 GiB)が利用可能になっています。でかい…
東京リージョンは発表時は M6i がローンチされていなかった記憶ですが、8/24(火)に使用できるようになったようです。
ただ、大阪リージョンは未対応でした。はまだ起動できるインスタンスタイプが少ないですね。
- 日本リージョン対応状況
- 東京:対応
- 大阪:未対応
AWS Transfer Family が、FTPS/FTP クライアントの互換性を拡張し、サーバー数の制限を引き上げ
S3 と EFS に対して FTP や SFTP、FTPS を行うことができるマネージドサービスの Transfer Family で、以下のアップデートがありました。
- ファイアウォールまたはルーターの IP アドレスを FTPS/FTP サーバーに柔軟にアタッチできるようになりました。
- 作成可能台数の上限が 10→50 台になりました
1つ目の方は Configuring your FTPS server behind a firewall or NAT with AWS Transfer Family を読んだのですがイメージがつきませんでした。
おそらく、以下のような構成を取った際、FTP の PASV 応答をよ正常に受け付けられるように aws transfer update-server --server-id --protocol-details PassiveIp= コマンドを利用できるようにしたという意味だと思うのですが、どの辺が新機能なのか以前の状態を知らないためにパッと分からず…
- 日本リージョン対応状況
- 東京:対応
- 大阪:未対応 ※Transfer Family 自体が未対応
8/17(火)
Amazon EC2 のお客様は、インスタンス接続操作中の認証で ED25519 キーを使用できるようになりました
EC2 に接続する際に使用する、公開鍵/秘密鍵のペアであるキーペアで、新しく ED25519 アルゴリズムを用いたキーペアが使用可能になりました。
従来の RSA アルゴリズムを用いて作成したキーペアよりも、セキュリティ面、性能面で優位なようです。ED25519 アルゴリズムの詳細は専門的なことが多く、頭が理解することを放棄しました。
実際の画面は以下です。
RSA キーが非推奨になることに伴う対応ですね。今後は ED25519 キーを使用していくのが良いのかなと思います。
- 日本リージョン対応状況
- 東京:対応
- 大阪:対応
8/18(水)
AWS Security Hub がクラウドセキュリティ体制のモニタリング強化のため、18 の新しいコントロールを Foundational Security ベストプラクティス標準に追加し、8 の新しいパートナーを強化されたクラウドセキュリティポスチャーモニタリングに追加
CIS Benchmark や AWS のベストプラクティスに沿っているか包括的に確認できるサービスである Security Hub で、以下 18 個の AWS 基礎セキュリティのベストプラクティスのルールが使用可能になりました。
RDS 系のルールの追加が目立ちますね。詳細はそれぞれのリンク先を参照ください。
- [APIGateway.5] API Gateway REST API キャッシュデータは暗号化されて保存されている必要があります
- [EC2.19] セキュリティグループはリスクの高いポートへの無制限のアクセスを許可しません
- [ECS.2] Amazon ECS サービスには、自動的にパブリック IP アドレス を割り当ててはいけません
- [ELB.7] Classic Load Balancers は、Connection Draining を有効にしている必要があります
- [ES.5] Elasticsearch ドメインは監査ロギングを有効にしている必要があります
- [ES.6] Elasticsearch ドメインには少なくとも 3 つのデータノードが必要ですshould have
- [ES.7] Elasticsearch ドメインには少なくとも 3 つの専用マスターノードが必要です
- [ES.8] Connections to Elasticsearch ドメインへの接続は TLS 1.2で暗号化する必要があります
- [RDS.16] RDS DB クラスターはタグをスナップショットにコピーして構成する必要があります
- [RDS.17] RDS DB インスタンスはタグをスナップショットにコピーして構成する必要があります
- [RDS.18] RDS インスタンスは VPC にデプロイする必要があります
- [RDS.19] RDS イベント通知サブスクリプションは重大なクラスターイベントのために構成される必要があります
- [RDS.20] RDS イベント通知サブスクリプションは重大なデータベースインスタンスイベントのために構成される必要があります
- [RDS.21] RDS イベント通知サブスクリプションは重大なデータベースパラメータグループイベントのために構成される必要があります
- [RDS.22] RDS イベント通知サブスクリプションは重大なデータベースセキュリティグループイベントのために構成される必要があります
- [RDS.23] RDS データベースとクラスターはデータベースエンジンのデフォルトポートを使用してはいけません
- [Redshift.4] Amazon Redshift クラスターは監査ロギングを有効にしている必要があります
- [SQS.1] Amazon SQS キューは暗号化して保存する必要があります
- 日本リージョン対応状況
- 東京:対応
- 大阪:対応
8/19(木)
Announcing Amazon MemoryDB for Redis
Amazon MemoryDB for Redis という新しいサービスがリリースされました。
インメモリデータベースのサービスというと Elasticache がありますが、こちらはインメモリデータベースの特徴通りメモリにデータを格納しているため、例えば障害発生時等にはデータが失われるという課題がありました。MemoryDB for Redis では、同じくメモリにデータを格納するものの、トランザクションログを複数の AZ に格納することによりログを永続的に保存し、ノードの再起動やフェイルオーバー、データベースリカバリを可能にし、インメモリデータベースの課題を解決したようです。
日本リージョン未対応だったため詳細は見ていません。
- 日本リージョン対応状況
- 東京:未対応
- 大阪:未対応
Introducing optimized Spark 3.1 runtime for data integration with AWS Glue 3.0
ETL (Extract, Transform, Load) ジョブを実行する Glue が新しくバージョン 3.0 になりました。
以下のアップデートがされています。
- Spark 3.1.1 への対応と、それに伴う依存関係のアップグレード
- パフォーマンスと信頼性の向上
詳細は AWS Glue Release Notes を参照ください。
実際の画面は以下です。Glue ジョブを作成する際に、バージョンを指定できるようになっています。
- 日本リージョン対応状況
- 東京:対応
- 大阪:対応
Redshift の空間パフォーマンスの強化と新しい空間関数
DWH のマネージドサービスである Redshift には、二次元の地理的データ(座標、海抜、住所、都市名、郵便番号など)に関する取り込み、保存、クエリを行うための GEOMETRY データ型があります。その GEOMETRY データ型で、以下のアップデートがありました。
- 空間クエリパフォーマンスが最大 100 倍に強化
- 空間クエリでの 3D/4D ジオメトリのサポート
- 新しい空間関数として 8 つの関数を追加(されたようですが、何が追加になったのか分からない…)
- ST_MakeLine は追加になっていそう
空間関数を使っての実機の動作は Redshift の空間データを試してみるよ が参考になるかと思います。
力尽きたので実機での動作検証はしませんでした。。
- 日本リージョン対応状況
- 東京:対応
- 大阪:対応
Amazon EC2 Hibernation adds support for C5d, M5d, and R5d Instances
仮想マシンのサービスである EC2 の C5d, M5d, R5d インスタンスで、ハイバネーションができるようになりました。
ハイバネーションは EC2 を一時停止する機能で、メモリの情報をルート EBS に保持し、次回起動時にその情報をメモリに読み込み、シャットダウン前と同じ状態で起動することができます。
大阪リージョンは EC2 作成時の設定項目がなく、未対応のようでした。
- 日本リージョン対応状況
- 東京:対応
- 大阪:未対応
AWS Cost Categories introduces Split Charge rules for allocation of shared costs
カテゴリルールを定義して、AWS アカウントやタグ情報ごとにコストを確認できる Cost Categories で、データ転送量やエンタープライズサポート費用等の共有コストを配分できる Split Charge ルールが使用可能になりました。
おそらく以下の画面で半分できるようになったということだと思うのですが、実際に設定できていないので詳しいことは分かりませんでした。
(料金が発生しなさ過ぎて、案分できる料金がない…)
- 日本リージョン対応状況 ※Cost Categories はグローバルのサービスのため対応としています。
- 東京:対応
- 大阪:対応
8/20(金)
Amazon ElastiCache for Redis が オートスケーリングをサポートするようになりました
インメモリキャッシュのマネージドサービスである Elasticache for Redis で、オートスケーリング機能が使用できるようになりました。
オートスケーリング機能により、
Redis やインメモリキャッシュについては RedisとElastiCacheを分かりやすくまとめてみた が非常に参考になるのではないかなと思います。
対応しているリージョンでは、Elasticache を作成した後に [アクション] > [Auto Scaling ポリシーの管理] から設定できました。バージニアリージョンの設定画面を見ましたが、シャードの数をスケーリングする感じなんでしょうか。
日本リージョンも近日中に対応するものと思います。
- 日本リージョン対応状況
- 東京:未対応
- 大阪:未対応
アジアパシフィック向け Amazon Forecast Weather Index を発表
Forecast は過去のデータから、正確な時系列予測を算出するマネージドサービスです。Forecast には、予測に気象条件を含めることができる Weather Index という機能があります。本アップデートで、Forecast にアジアパシフィック地域のデータを使用できるようになりました。
これで、日本でも Forecast を使った商品販売の需要予測等で気象条件を含めることができるようになりました。
気象条件を含めるためには、インポートするデータに緯度/経度でロケーションの情報を追加する必要があります。今回は AWS ブログとクラスメソッドさんのブログを参考に、35.39_139.44 を追加しました(北緯 35.39 度、東経 139.44 度)
(参考) Amazon Forecast Weather Index – automatically include local weather to increase your forecasting model accuracy
(参考) Amazon Forecastでお手軽に時系列予測
天気情報を含めるかどうかは Train a predictor をする際に設定します。
実際に予想を作成してみましたが、エラーで失敗しました。Conditions and Restrictions にあるように、アジアパシフィックの天気予報を使用するためには、2020年5月以降のデータが必要のようです。ForecastHorizon cannot exceed one-third of the length of the truncated target time series. Set ForecastHorizon to a value between 1 and -46752. とも怒られていますが、これもおそらく対象のデータが指定の期間内に無いことが問題かなと思います。
これ、ちゃんとデータを用意すればブログ一本書けるぞって思いました。予想を作成するのに数時間かかるっぽかったので、時間と気力がある時に…
なお、大阪は未対応でした。
- 日本リージョン対応状況
- 東京:対応
- 大阪:未対応 ※forecast 自体に未対応
Amazon Aurora で PostgreSQL 9.6.22、10.17、11.12、および 12.7 をサポート
Oracle や SQL Server 等、RDBMS のマネージドサービスである RDS の Aurora で、以下の PostgreSQL の互換バージョンが使用可能になりました。アップデートの詳細はそれぞれのリリースノートを参照ください。
なお、PostgreSQL 9.6 は 2022/1/31 で EOSL を迎えますのでご注意ください。また、大阪リージョンでは 9.6 系は対応していないのでご注意ください。
- 日本リージョン対応状況
- 東京:対応
- 大阪:対応 ※PostgreSQL 9.6.22 だけ未対応
Amazon Aurora PostgreSQL が oracle_fdw の拡張機能のサポートを開始
同じく Aurora の PostgreSQL で Oracle データベースを操作するための外部ラッパーである oracle_fdw の拡張機能が使用できるようになりました。
具体的な使い方や解説は富士通さんのページが参考になるかと思いますので、気になる方はご覧ください。
(参考) Oracleデータベースにアクセスする ~oracle_fdwの基本的な使い方~
2021/7/9 に Amazon RDS for PostgreSQL が Oracle データベースに含まれるデータにアクセスするための oracle_fdw 拡張機能をサポート のアップデートが発表されましたが、その Aurora 版かと思います。
実機での検証はしていませんが、おそらく東京も大阪も対応していると思います。
- 日本リージョン対応状況
- 東京:対応
- 大阪:対応