何となくわかった気になる週刊AWS - 2022/1/3週

## はじめに

あけましておめでとうございます、なじむです。
2021/12/10 に DBS も合格し、目標であった全冠（11冠）を達成できました。半年かけてスペシャリティの資格を毎月一個取得してきましたが、とてもいい勉強になりました。社会人になってこんなに勉強したのは久しぶりな気がします。とはいえ、言葉が分かるようになった、ある程度の使い方・注意点が分かるようになった、程度なので引き続き精進していきたいと思います。
というわけで今年も張り切ってやっていきましょう！AWS Japan さんがまとめている[週刊AWS](https://aws.amazon.com/jp/blogs/news/tag/%E9%80%B1%E5%88%8Aaws/)で確認した内容の自分用メモ。
今回は[1/3週](https://aws.amazon.com/jp/blogs/news/aws-weekly-20220103/)のアップデートです。

## 1/3(月)

### [AWS Glue ジョブでのオートスケーリングのご紹介 (プレビュー)](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/autoscaling-aws-glue-jobs-preview/)

Glue は ETL (Extract：抽出、Transform：変換、Load：格納) を実行するマネージドサービスです。
※例えば S3 からデータを抽出し、抽出したデータに何かしらの処理を加え変換し、変換後のデータを再度 S3 に格納したりします。
![product-page-diagram_Glue_Unified-View-of-Data-Across-Multiple-Data-Stores.0aa670c04b8b8f68f36fb2f6916cd0bf1b12f43a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/6c404fb1-aa9e-3871-dbf6-1c448da55346.png)
(出典) [AWS Glue](https://aws.amazon.com/jp/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)

これまで、Glue ジョブを実行する際の実行リソースは最初に決めた数のワーカーを使用していました。そのため、リソースを過剰にプロビジョニングし膨大なコストがかかってしまったり、コストダウンのためにリソースの最適化が必要になっていました。本アップデートにより、Glue ジョブのオートスケーリング機能が追加されました。これにより、最適な量のリソースで Glue ジョブを実行できるようになり、無駄なコストを抑えることが可能になります。

実際の画面は以下です。
ジョブの作成時にはオートスケーリングの設定はできません。ジョブの作成後、Glue Studio から対象ジョブを選択し、[Job details] タブから設定が可能です。

- 設定前：Requested number of workers を設定できる
  ![設定前.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/550c49ef-1f9d-aa29-104e-7e755ea711b1.jpeg)

- 設定後：Maximum number of workers を設定できるようになる
  ![設定後.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/3db14d00-431e-cfad-aa26-9b84019ab3e4.jpeg)

オートスケーリングの利用には以下のような注意事項があります。詳細は [Using Auto Scaling for AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/auto-scaling.html) を参照ください。

- Type        ：Spark または Spark Streaming を指定（Python shell は対象外）
- Glue Version：3.0 以上を指定
- worker types：G.1X または G.2X を指定（Standard DPUs はサポート外）

なお、本機能はプレビュー機能です。現時点では米国東部(オハイオ)のみで利用可能なためご注意ください。

- 日本リージョン対応状況
  - 東京：未対応
  - 大阪：未対応

## 1/4(火)

### [Amazon SageMaker JumpStart のタブデータに LightGBM と CatBoost モデルが追加](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/amazon-sagemaker-jumpstart-lightgbm-catboost-tabular/)

時間切れで確認できず…

- 日本リージョン対応状況
  - 東京：未確認…
  - 大阪：未確認…

### [Amazon ECS で ECS クラスターとタスク定義作成のための簡素化されたコンソールエクスペリエンスを開始](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/amazon-ecs-launches-console-ecs-clusters-task-definitions/)

ECS は Docker コンテナを実行および管理するマネージドサービスです。
![image-13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/601122b6-d4d8-5f86-117c-b0cb3c1b7b99.png)
(出典) [Amazon EFS を Amazon ECS と AWS Fargate で使用するための開発者ガイド – パート 1](https://aws.amazon.com/jp/blogs/news/developers-guide-to-using-amazon-efs-with-amazon-ecs-and-aws-fargate-part-1/)

本アップデートでは、ECS のマネジメントコンソールが新しくなりました。
新旧コンソールの切り替えは画面左上のトグルボタンで行います。
![20220117_122607.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/f3e83a9f-df7e-134b-aff7-58ce6ce51de7.jpeg)

新コンソールになり、以下の改善が加わっています。
※以前の画面と並べて比較しようと思ったんですが、結構変わっていて並べての比較が難しいなと思ったため、新コンソールのみ載せます。

1. ECS クラスターの作成時
  1. Auto Scaling グループの作成を簡易化（EC2 インスタンスを起動して新しい Amazon ECS クラスターに自動的に登録）
    ![20220116_155731.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/53f77234-a3c3-5590-fdd1-00766bfbcb6c.jpeg)
1. タスク定義作成時
  1. 複雑な設定の削除（柔軟性のあるデフォルトの提供、タスク実行に必要なロールの自動作成） ※画面から無くなっている項目のため割愛
  1. EC2 および Fargate の両方において、異なる OS/アーキテクチャ (Graviton、Windows、Linux) で実行するタスクを設定可能に
    ![20220116_160313.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/b8e2dff2-2014-1c4d-97f1-db656d7c6579.jpeg)
  1. メトリクスとトレースの収集を有効にするオプションを追加（X-Ray、CloudWatch、Amazon Managed Service for Prometheus へのエクスポートが可能）
    ![20220116_160416.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/58116127-35d1-72d8-1ba3-f08626a12135.jpeg)

一方で、コンソールが新しくなったことにより、一部作成時に設定できなくなった項目もあるようです。それらに関しては、旧コンソールで設定する必要があります（具体的に新コンソールで何が設定できないのかは未確認）

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：未対応 ※画面右上のトグルが無かったので未対応と思われます。

### [Amazon EMR on EKS がカスタム Docker コンテナイメージのテストを簡素化するカスタムイメージ検証ツールをリリース](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/amazon-emr-custom-image-validation-tool-images/)

EMR on EKS は EKS 上で EMR を動かせるサービスです。EMR on EKS を使用すると、同じ EKS クラスターで Spark アプリケーションを他のタイプのアプリケーションとともに実行し、リソース使用率を向上させ、インフラストラクチャ管理を簡素化することができます
![2020-emr-on-eks-diagram-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/4d832b17-7eb5-668b-b31d-f929aa8e085e.png)
(出典) [新発表 — Amazon EMR on Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/jp/blogs/news/new-amazon-emr-on-amazon-elastic-kubernetes-service-eks/)

EMR on EKS では、pod にカスタムイメージを使用することができます。本アップデートでは、カスタムイメージを検証するためのツールがオープンソースとして公開されました。検証ツールを使用することで、以下のチェックを行うことが可能です。

- Basic Test          ：カスタムイメージに以下パラメータが含まれていることを検証
  - UserName
  - WorkingDir
  - EntryPoint
- Environment Test    ：必要な環境変数が期待されるパスに設定されていることを検証
  - SPARK_HOME=/usr/lib/spark
  - JAVA_HOME=/etc/alternatives/jre
- File Structure Test ：必要なファイルが予想されるパスに存在することを検証
- Local Job Run Test  ：カスタムイメージが有効であり、基本的なジョブ実行に合格できることを検証

検証ツールは github からダウンロードできます。
(参考) [awslabs/amazon-emr-on-eks-custom-image-cli](https://github.com/awslabs/amazon-emr-on-eks-custom-image-cli)

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：未対応 ※EMR on EKS に未対応

### [Amazon Managed Blockchain (AMB) が Hyperledger Fabric v2.2 のサポートを発表](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/amazon-managed-blockchain-hyperledger-fabric-2-2/)

Managed Blockchain はブロックチェーンネットワークを構築できるマネージドサービスです。
![Building-a-serverless-blockchain-application-A.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/28f4730a-d50f-207b-64ab-7dc9f2c1bfd0.jpeg)
(出典) [Amazon Managed Blockchain を使用したサーバーレスブロックチェーンアプリケーションの構築](https://aws.amazon.com/jp/blogs/news/building-a-serverless-blockchain-application-with-amazon-managed-blockchain/)

Managed Blockchain では、ネットワークの構築にオープンソースのブロックチェーン・プラットフォームである Hyperledger Fabric 利用しています。本アップデートにより、Managed Blockchain で LTS 版である Hyperledger Fabric v2.2 がサポートされました。v2.2 では以下の特徴があります（なぞってみたけど全く分からない…）

- v 2.x リリースの初の LTS リリース
- チェーンコード (スマートコントラクト) の分散型ガバナンスを導入
- 複数の組織でチェーンコードのパラメータ (チェーンコード承認ポリシーなど) を使用する前に各組織が同意することが可能に
- 参加する可能性のあるチャンネルメンバーのすべての組み合わせのプライベートデータコレクションを作成する必要なく、プライベートデータを共有する高度なパターンを使用することが可能に

その他の Fabric v2.2 でのアップデート内容は以下に記載があります。
(参考) [New release: Hyperledger Fabric 2.2 LTS](https://www.hyperledger.org/blog/2020/07/20/new-release-hyperledger-fabric-2-2-lts)

実際の画面は以下です。
Hyperledger Fabric v2.2 が利用可能になっています。
![20220117_105016.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/5e4eccf0-501d-2a16-edc2-50f558840253.jpeg)

やってみた系の記事はクラメソさんのブログが参考になりました。
(参考) [Amazon Managed BlockchainでHyperledger Fabric v2.2が利用出来るようになったのでネットワーク作成してチェーンコードを実行してみた](https://dev.classmethod.jp/articles/amazon-managed-blockchain-hyperledger-fabric-v2-2/)

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：未対応 ※Managed Blockchain 自体に未対応

### [Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス) が OpenSearch バージョン 1.1 のサポートを開始](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/amazon-opensearch-supports-version-1-1/)

OpenSearch Service は OSS の全文検索エンジンのマネージドサービスです（ElasticSearch、Kibana の AWS フォーク版です）
![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f3339363531302f63333064306337652d306632302d393734302d323564342d6539303833326363306431352e6a706567.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/d130ce07-ccdf-c803-2ff4-d77d91863787.jpeg)

本アップデートでは、OpenSearch Service 1.1 が利用可能になり、以下機能が追加されました。

1. クラスター間レプリケーション (CCR) ：クラスター間でのデータレプリカ。Elasticsearch 7.10 でサポートしていた機能が追加。
1. 履歴データの異常検出               ：過去のデータを基にした異常値検出。これ便利そう。
1. バケットレベルのアラート           ：これよく分かりませんでした…

実際の画面は以下です。バージョン 1.1 が選択できるようになっています。
![20220116_161104.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/67634efd-d1e8-e67e-96de-125cfa72fb42.jpeg)

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：対応

### [AWS Glue Interactive SessionsとJob Notebooksの紹介（プレビュー）](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/aws-glue-interactive-sessions-job-notebooks/)

Glue Interactive Sessions と Job Notebooks がプレビュー利用可能になりました。
Glue ジョブの開発では Jupyter Notebook 使うと効率的に進められます。従来は SageMaker ノートブック + 開発エンドポイントで構築していましたが、その構成はコストが非常にかかります。本アップデートによりサーバレスで Jupyter Notebook が使えるようになったためコストが抑えることが可能になりました（使い方次第かも）

実際の画面は以下です。
Glue Studio から Jupyter Notebook が選択できるようになっています。
![20220117_121348.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/cbe99ab3-c56d-2c9c-b75d-d36efded4e6a.jpeg)

3 分くらいすると環境が構築されます。めっちゃ簡単でめっちゃ早い！（実際の開発はしていないため使い勝手は不明…）
![20220117_121828.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/42129d06-0446-b6a0-480d-cec113c93eef.jpeg)

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：未対応

## 1/5(水)

### [Amazon Redshift 向け AWS Data Exchange を発表](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/aws-data-exchange-amazon-redshift/)

※Data Exchange のサブスクライブが間に合わなかったため推測※

Data Exchange は AWS クラウド内のサードパーティのデータを簡単に検索、サブスクリプション、および利用できるサービスです。例えば、コロナ関連のデータ（世界の感染者数の情報等）が利用可能です。
![AWS-Data-Exchange-for-Amazon-Redshift-HIW.c20078c30014daedcd7a6a5e8c1c1d6002dbf812.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/c86704ec-7d43-dc99-f127-6a7259ddaac8.png)
(出典) [AWS Data Exchange for Amazon Redshift](https://aws.amazon.com/jp/redshift/features/aws-data-exchange-for-amazon-redshift/)

これまで、Redshift に Data Exchange のデータを取り込むためには、サブスクライブしたデータを S3 から Redshift に取り込む必要がありました。本アップデートにより、データをサブスクライブすると直接 Redshift 上に表示することが可能となり、Redshift に取り込む手間がなくなったものと思います（ここ確証無し）また、Data Exchange 上のデータは自動で更新されるため、「自分が今使っているのは最新のデータか？」という点を気にしなくてもよくなります。
なお、AWS Data Exchange for Amazon Redshift の利用開始には、当該リージョンで Redshift の RA3 インスタンスを利用する必要があるためご注意ください。
※2021/10/19 に発表された[プレビュー機能](https://aws.amazon.com/jp/about-aws/whats-new/2021/10/aws-data-exchange-amazon-redshift/)が GA になったというアップデートです

実際の画面は以下です。

1. 任意の Data を選択し、サブスクライブする（Redshift向けの製品で絞ります）
  ![20220116_210121.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/d022f928-fa63-8691-a522-844e111dabd0.jpeg)
1. Redshift 上からデータを閲覧（できるんじゃなかろうかと推測）

申請がサブスクライブされなかったので実動作が分からなかったのですが、こんな感じなんじゃないかなと思います。どこかでちゃんと検証します…

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：未対応 ※Data Exchange 自体に未対応

### [マネージド型の監査およびセキュリティレイクである AWS CloudTrail Lake を発表](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/aws-cloudtrail-lake-audit-security/)

CloudTrail ログをクエリできるサービスである CloudTrail Lake が新規利用可能になりました。

従来、CloudTrail のログは CloudTrail のコンソールから確認することが可能でしたが、保存期間が90日である、設定しているリージョンのみしか表示されない等、いくつか使いづらい点がありました。それらを解決するために S3 に保存した CloudTrail ログに対して Ahtena を使用してクエリをかける方法が一般的ですが、今回のアップデートでは、それと同様の環境をより簡単に構築できる CloudTrail Lake が利用可能になりました。

クエリまでの大きな流れは以下です。

1. イベントデータストアを作成する
  ![20220116_201723.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/1ab7a842-c4e8-b066-f6ab-0c6d0746a280.jpeg)
1. クエリを実行する
  ![20220116_202209.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/239ad488-aafe-5d6c-0ce5-132efe664de5.jpeg)

凄い簡単ですね！実際に構築してみて、以下が嬉しい点かなと思いました。

- 本当に簡単に環境が作成できる
- 最長7年ログが保存できる（料金は当然かかる）
- 全てのリージョン、全ての組織内のアカウントの CloudTrail ログをまとめてクエリできる

CloudTrail Lake クエリの文法は以下を参照ください。
(参考) [CloudTrail Lake SQL constraints](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/query-limitations.html)

また、やってみた系は公式ブログが参考になりましたので併せてご覧ください。
(参考) [Announcing AWS CloudTrail Lake – a managed audit and security Lake](https://aws.amazon.com/jp/blogs/mt/announcing-aws-cloudtrail-lake-a-managed-audit-and-security-lake/)

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：対応

### [Amazon RDS Proxy が 8 つの追加 AWS リージョンで利用可能に](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/amazon-rds-proxy-available-additional-aws-regions/)

RDS Proxy はデータベースプロキシのマネージドサービスです。
![20220116_195904.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/61f5324c-392f-08d2-b734-7fc0123a5119.jpeg)
(出典) [Amazon RDS Proxy のご紹介](https://pages.awscloud.com/rs/112-TZM-766/images/EV_amazon-rds-aws-lambda-update_Jul28-2020_RDS_Proxy.pdf)

Lambda や EC2、Fargate と RDS の間に RDS Proxy を使用することにより、以下のようなことが可能となります。

- 接続プーリングでオーバーヘッド削減 ：RDS Proxy が中継することで、RDS のリソース消費を抑えることができます（特にLambda からの接続時などに有効）
- フェイルオーバー時の復旧時間短縮   ：DNS に依存しないフェイルオーバーにより復旧時間短縮
- RDS への接続に IAM 認証が使用可能に：DB ユーザではなく、IAM ロール等を用いて RDS に接続可能になります（RDS IAM認証と同様の機能）

今回のアップデートにより、大阪リージョンでも RDS Proxy が使用可能になりました。

実際の画面は以下です。
大阪リージョンで RDS Proxy が作成できるようになっています。
![20220116_192512.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/de40ea6f-de7b-bc82-f203-dc2889c3310a.jpeg)

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：対応

## 1/6(木)

### [CloudFormation Registry に 37 の新しいリソースタイプを導入](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/cloudformation-registry-37-resource-types/)

CloudFormation は AWS リソースの IaC (Infrastructure as Code) のサービスです。JSON または YAML で AWS のリソースを記載することにより、AWS のリソースをテンプレートとして管理することができます。
本アップデートでは先月追加されたサービスを中心に、新たに 37 のサービスが CloudFormation で記述できるようになりました。

1. AWS::AmplifyUIBuilder::Component
2. AWS::AmplifyUIBuilder::Theme
3. AWS::AppStream::AppBlock
4. AWS::AppStream::Application
5. AWS::AppStream::ApplicationFleetAssociation
6. AWS::AppSync::DomainName
7. AWS::AppSync::DomainNameApiAssociation
8. AWS::Batch::SchedulingPolicy
9. AWS::Chatbot::SlackChannelConfiguration
10. AWS::CloudFront::ResponseHeadersPolicy
11. AWS::Connect::ContactFlow
12. AWS::Connect::ContactFlowModule
13. AWS::DataSync::LocationHDFS
14. AWS::EC2::IPAM
15. AWS::EC2::IPAMPool
16. AWS::EC2::IPAMScope
17. AWS::Evidently::Experiment
18. AWS::Evidently::Feature,
19. AWS::Evidently::Launch,
20. AWS::Evidently::Project
21. AWS::FSx::FileSystem
22. AWS::FSx::Snapshot
23. AWS::FSx::StorageVirtualMachine
24. AWS::FSx::Volume
25. AWS::Lex:Bot
26. AWS::Lex::BotAlias
27. AWS::Lex::BotVersion
28. AWS::Lex::ResourcePolicy
29. AWS::IoT::Logging
30. AWS::IoT::ResourceSpecificLogging
31. AWS::IoTWireless::FuotaTask
32. AWS::IoTWireless::MulticastGroup
33. AWS::Pinpoint::InAppTemplate
34. AWS::ResilienceHub::App
35. AWS::ResilienceHub::ResiliencyPolicy
36. AWS::RUM::AppMonitor
37. AWS::Timestream::ScheduledQuery

具体的な文法に関しては CloudFormation のリファレンスを参照ください。
(参考) [AWS resource and property types reference](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html)

- 日本リージョン対応状況 ※各サービスが東京、大阪に対応していれば CloudFormation で記述可能
  - 東京：対応
  - 大阪：対応

### [Amazon EKS が Internet Protocol version 6 (IPv6) をサポート](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/amazon-eks-ipv6/)

EKS は Kubernetes のコントロールプレーンのマネージドサービスです。
![networking-overview.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/5c3835b0-a840-999b-c1de-a1821cb37ca5.png)
(出典) [Amazon EKS ネットワーク](https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/eks-networking.html)

これまで、EKS では IPv4 しか選択できませんでした。EKS は Pod 毎に IP が割り振られるため、大規模なシステムでは IP が枯渇する場合があります。プラグインを用いることでその問題を回避することも可能ですが、ネットワーク構成が複雑になり、遅延が発生する場合もあります。IPv6 を使用することでそれらの課題を回避することができます。 

実際の画面は以下です。
IPv6 が選択できるようになっています。
![20220117_115352.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/c4a96e6f-d4c2-ea85-1f39-7017f30dd05a.jpeg)

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：対応

### [AWS Lambda が ES モジュールと Node.js 14 の Top-Level Await のサポートを開始](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/aws-lambda-es-modules-top-level-await-node-js-14/)

Lambda はサーバレスでコードを実行できるサービスです。Lambda で Node.js 14 を実行している場合、以下2つの機能が利用可能になりました。

- ECMAScript (ES) モジュール
- Top-Level Await

私はこの辺に疎いのですが、以下記事がとても参考になりました。こんなにまとめられるの凄い。
(参考) [top-level awaitがどのようにES Modulesに影響するのか完全に理解する](https://qiita.com/uhyo/items/0e2e9eaa30ec2ff05260)

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：対応

### [インスタンスタグが Amazon EC2 インスタンスメタデータサービスで利用可能に](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/instance-tags-amazon-ec2-instance-metadata-service/)

EC2 は仮想マシンのサービスです。EC2 にはインスタンスメタデータサービスと呼ばれるサービスがあります。EC2 上で ```curl http://169.254.169.254``` と実行することで、ホスト名やセキュリティグループなど、インスタンスに関する様々な情報を取得することができます。

これまで、タグ情報を取得したい場合は DescribeInstance または DescribeTag を実行することで取得していましたが、大量に実行するとスロットリングエラーや API の実行に時間がかかるといった課題がありました。本アップデートにより、インスタンスメタデータからインスタンスのタグ情報を取得できるようになりました。これにより、先の課題が解決されます。

実際の画面は以下です。
先ずはインスタンス作成時に設定を有効にする必要があります（既存のインスタンスでも、設定を有効にすることができます）
![20220116_171221.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/bd0251c1-769d-aa7b-febf-0fac5de978eb.jpeg)

有効にした後はインスタンスにログインし、メタデータにアクセスします。```curl http://169.254.169.254/latest/meta-data/tags/instance/Name``` を実行することで Name タグの値を取得することができました。
（見やすいように改行を修正しています）

```bash
$ curl http://169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
2016-06-30
2016-09-02
2018-03-28
2018-08-17
2018-09-24
2019-10-01
2020-10-27
2021-01-03
2021-03-23
2021-07-15
latest
$
$ curl http://169.254.169.254/latest/
dynamic
meta-data
$
$ curl http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hibernation/
hostname
iam/
identity-credentials/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
managed-ssh-keys/
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
$
$ curl http://169.254.169.254/latest/meta-data/tags/
instance/
$
$ curl http://169.254.169.254/latest/meta-data/tags/instance/
Name
Owner
$
$ curl http://169.254.169.254/latest/meta-data/tags/instance/Name
nagym-ec2
$
```

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：対応

## 1/7(金)

### [Amazon AppStream 2.0 が SAML 2.0 フェデレーティッドユーザー ID 向けにアプリケーションエンタイトルメントの提供を開始](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/amazon-appstream-2-0-application-entitlements-saml-2-0-federated-user-identities/)

Amazon AppStream 2.0 はアプリケーションストリーミングのマネージドサービスです。
![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f3339363531302f61316634303065652d323139322d386161392d343237372d3265393463353231356636392e706e67.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/8afdb1ba-c693-cfd1-43e2-b80d429ae6fb.png)
(出典) [Amazon AppStream 2.0でデスクトップアプリケーションのストリームをスケールする](https://aws.amazon.com/jp/blogs/news/scaling-your-desktop-application-streams-with-amazon-appstream-2-0/)

AppStream 2.0 で作成したアプリケーションにアクセスするためには認証（ユーザ情報）と認可（そのユーザがどのアプリケーションにアクセスできるか）の設定が必要になります。本アップデートでは、その設定をアプリケーションエンタイトルメントを用いて設定できるようになりました。例えば、AD に登録しているユーザで "nagym-dev" というグループに所属しているユーザには "VS Code" の実行を許可するという設定を、以下のようにアプリケーションエンタイトルメントで設定できるようになりました。
![20220116_182334.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/396510/5de9c6ef-d1a0-8a2b-4a8a-4ed156d81738.jpeg)

AD を構築しておらず検証ができなかったため、実機での検証はしていませんが、詳細な解説と実際のやってみた系は今年もクラメソさんのブログが参考になります。ぜひご覧ください。
(参考) [[アップデート] AppStream 2.0 で SAML 2.0 Federated User を利用する際にアプリケーションの選択ができる様になりました](https://dev.classmethod.jp/articles/try-appstream2-application-entitlements/)

- 日本リージョン対応状況
  - 東京：対応
  - 大阪：未対応 ※AppStream 2.0 に未対応

## 感想

新年早々、めっちゃアップデートあるなって思いました。そしてしばらくサボっていた分、全然分からなくなっていました…
今年は（忙しくなければ）継続してやっていきたいと思いますので、本年もよろしくお願いします。
間違いがあればご指摘ください。