どうも、セクションナインの吉田真吾（@yoshidashingo）です。

だいぶ間が開いてしまい恐縮ですが、5/12(木)から6/1(水)まで3週間分のアップデートをふりかえってみましょう。

AWS公式

AWS公式

1. EC2 Run Commandアップデート – コマンドの管理と共有など

WindowsおよびLinuxのインスタンスに外部からコマンド実行を指示できるEC2 Run Commandがアップデートされた
- Windows用の事前定義コマンド（インベントリ情報収集、未適用のWindows Updateのリスト化、KB単位でインストール実行）が追加され、メインテナンスを支援してくれる
- 共有されているドキュメントや実行可能なパラメータを選択して自分用のカスタムコマンドが作成可能になった。これはPublicに公開することも、特定のアカウント間でのみ共有することも可能
- インスタンス用Simple Systems Manager (SSM)エージェントのLinux版がGitHubで公開された

リンク：EC2 Run Commandアップデート – コマンドの管理と共有など | Amazon Web Services ブログ

github.com

2. [新サービス]AWS Application Discovery Service – クラウド移行計画

クラウド移行計画(現在のIT資産を評価→調査と計画策定→構築→稼働)を推進するための新しいサービスを発表した
「The Discovery Agent」と呼ばれるエージェントをオンプレのサーバーに入れてシステム情報を収集する仕組み
- エージェントは収集した情報をオンラインであればポート443でやりとり、オフラインであればローカルに保存される
- エージェントが対応してるOSはUbuntu 14、Red Hat 6-7、CentOS 6-7、そしてWindows (Server 2008 R2、Server 2012、Server 2012 R2)
Application Discovery ServiceのCLIやSDKからも操作が可能

リンク：New – AWS Application Discovery Service – クラウド移行計画 | Amazon Web Services ブログ

3. AWS Config – タグの変更検知の高速化、新しいマネージドルール追加、およびユーザビリティの向上

AWS Config Rulesが改良され、タグの変更後、数分以内にタグ変更の通知を受け取りrequired-tagsが素早くチェックされるように
マネージドルール(AWSが提供するルール、他に自分でカスタムして作成も可能)にIAMユーザにMFAが有効になってるかチェックも追加された → https://github.com/awslabs/aws-config-rules
その他：
- Config Rulesコンソールから準拠/非準拠の注釈を確認することができるようになった(UIの改善)
- Config Rulesの詳細ページからルールの呼び出しができるようになった(機能追加)
- 評価の際のタイムスタンプ等、より細かい粒度のステータスを受け取ることができるようになった(機能追加)

リンク：AWS Config – タグの変更検知の高速化、新しいマネージドルール追加、およびユーザビリティの向上 | Amazon Web Services ブログ

4. EC2のX1インスタンス – メモリー重視のワークロードに対応可能

昨年秋、AWS re:Inventで発表されていたX1インスタンス( x1.32xlarge )がローンチされた
スペック
- 2.3GHzの4 x Intel™ Xeon E7 8880 v3 (Haswell) – 64コア / 128 vCPUs → ターボブースト2.0で最大3.1GHzまでクロックアップ
- メモリー： Single Device Data Correction (SDDC+1)を実現した1,952 GiB → ほぼ2TB！
- インスタンスストレージ： 2 x 1,920 GB SSD → 揮発性のストレージなのでスワップや一時領域に使う想定
- ネットワーク帯域幅： 10 Gbps
- 専用のEBS帯域幅： 10 Gbps (デフォルトでEBS最適化、追加料金不要)
現状では利用申請が必要
SAPなどに利用する想定
料金：東京リージョンにおいて、オンデマンドで1時間あたり $19.341、1年すべて前払い($97438：約1000万)で$11.123、3年すべて前払い($142204：約1500万)で$5.411

リンク：EC2のX1インスタンス – メモリー重視のワークロードに対応可能 | Amazon Web Services ブログ

5. I Love My Amazon WorkSpaces!

WorkSpaces、クライアント・アプリケーションから使うのもいいが、最も体験が良いのは「Zero Client」
ラップトップが死んでも大丈夫

リンク：I Love My Amazon WorkSpaces! | Amazon Web Services ブログ

6. Amazon Auroraでアカウント間でスナップショットを共有できるようになった

スナップショットをアカウント間で共有可能になった

リンク：Amazon Auroraでアカウント間でスナップショットを共有頂けるようになりました | Amazon Web Services ブログ

7. Amazon ECSでAuto Scaling

これまでECSでAuto Scalingするためには、Auto Scalingと、増加したインスタンスでCloud Initの実行を行うという方法が提案されていたが、今回はCloudWatchのアラームがECSサービスに対応したのでこれを用いて「ECSクラスタのスケールイン/アウト」と「ECSサービスのスケールイン/アウト」を組み合わせてAuto Scalingできるようになったので、その構成方法を紹介している
構成上、ECSクラスタの増減のほうが時間がかかり（EC2をプロビジョニングするため）、ECSサービスの増減と実際の運用ではうまくバランスを調整する必要がある
特にAuto ScalingでSpot fleetなどさらに組合せを考慮するとクラスタとサービスのリードタイムの乖離が大きくなりがちだと想定されるので、つねにクラスタ>サービスとなるような構成とすることと、スケールのスピードをバランスする設定での運用が必要になると思われる
現在はまだバージニア/オレゴン/アイルランドのみ

リンク：Amazon ECSでAuto Scaling | Amazon Web Services ブログ

8. Amazon Elastic TranscoderでMPEG-DASHをサポートしました

通常、アダプティブストリーミング（ネットワークの状況に応じて、高ビットレートの映像の映像片を返すか低ビットレートにするか調整してストリーミングをスムーズにする）のためには、高ビットレート〜低ビットレートまで何種類かの映像片に変換して準備しておく必要があった。これをMPEG-DASHではコンテンツの変換時にさまざまなビットレートのセグメントを用意する規格なため、これに対応したTranscoderを利用すれば、ユーザー側で複数のビットレートのファイルに変換をかける必要がなく、1プロセスでコンテンツの準備ができるというもの。
また、セグメントの秒数が指定できるので、細かくすればするほど回線状況の変化にすばやくセグメント変更が対応できるようになる

リンク：Amazon Elastic TranscoderでMPEG-DASHをサポートしました | Amazon Web Services ブログ

9. EC2インスタンスのコンソールスクリーンショット

インスタンスの標準出力の状況をSSHやRDPでつないで確認する手間を省けるように、マネジメントコンソールから画面スナップショットを取得して表示することができるようになった
ちょっとした確認がすばやくできて便利

リンク：EC2インスタンスのコンソールスクリーンショット | Amazon Web Services ブログ

10. Amazon RDS for Oracleで拡張モニタリングが利用できるようになった

唯一対応していなかったOracleでも拡張モニタリングが可能になった
56種類のメトリクスを1秒単位で取得可能【PGA/SGAなどの値とメモリのメトリクスの対応関係は別途まとめるつもり】

リンク：Amazon RDS for Oracleで拡張モニタリングがご利用頂けるようになりました | Amazon Web Services ブログ

11. Amazon ElastiCache アップデート – RedisのSnapshotをAmazon S3へエクスポートする事が可能になりました

ElastiCache for Redis、今までS3からRDBファイルをインポートすることはできたが、エクスポートはできなかった。今回はエクスポートに対応。しかもRDBファイルなのでクラスタ再構築（スケール変更のためなど）や共有に使うことができる
バックアップはスナップショットで定期的にやっておいて、移行や共有はRDBファイルで行うという使い分けができそう

リンク：Amazon ElastiCache アップデート – RedisのSnapshotをAmazon S3へエクスポートする事が可能になりました | Amazon Web Services ブログ

12. Amazon AuroraでCross-Region Read Replicaが利用できるようになった

Auroraのリードレプリカを他のリージョンに作成することが可能になった
このレプリカをマスターに昇格できるのは暗号化されていない場合のみ
binlogも有効にしておくこと（binlog_format=MIXED）

リンク：Amazon AuroraでCross-Region Read Replicaがご利用頂けるようになりました | Amazon Web Services ブログ

13. Amazon RDSがMariaDB 10.1をサポートした

MariaDB 10.1をサポートしたことで、以下のような機能が利用できるようになった
- XtraDB/InnoDB page compression
- XtraDB/InnoDB data scrubbing
- XtraDB/InnoDB defragmentation
- Optimistic in-order parallel replication
- ORDER BY optimization
- WebScale SQL patches

リンク：Amazon RDSでMariaDB 10.1をサポートしました | Amazon Web Services ブログ

14. AWS KMSを使ってS3のオブジェクトを暗号化するためのREST APIの使用法

AWS Key Management Service(AWS KMS)を使ってS3のサーバーサイド暗号化とクライアントサイド暗号化を行う際のREST APIの利用方法
通常、SDKで暗号化することが多いが、クロスプラットフォームで利用できる（言語のロックインに悩まなくていい）のがメリット

aws.typepad.com

15. Amazon Route 53で登録可能なドメインが増えた

.name, .online, .uk, .org など300以上のTLDが追加された
ドメインについての詳細な操作履歴が取得可能になった

リンク：Amazon Route 53 Announces Domain Name Registration Enhancements: Expanded TLD Catalog, Detailed Billing History, and Amazon Registrar support for .ORG

16. ECSがDocker 1.11をサポート

ECS利用時にホストに指定する最新のAmazon ECS-optimized AMIでDocker 1.11をサポート
従来のホストであれば単純にアップグレードすれば同様に1.11を利用可能

リンク：Amazon EC2 Container Service Supports Docker 1.11

17. Amazon Redshiftの改良

バージョン1.0.1012以上で、SELECT INTO TEMP TABLEで一時テーブルを作成するスピードが2倍になった
バージョン1.0.1056以上で、クエリのスループット（一度に処理可能なワークロード）が2倍になった
バージョン1.0.1056以上で、VACUUMのパフォーマンスが10倍以上になった
バージョン1.0.1057以上で、UNION ALLのクエリの処理速度が10倍以上になった

リンク：Amazon Redshift improves throughput performance up to 2X リンク：Amazon Redshift UNION ALL queries and VACUUM commands now run up to 10x faster

18. AWS Certificate Managerが東京リージョンにも来て(ELBで利用可能に ※CFはすでにサポート済み)、Beanstalkでもサポートされた

AWS Certificate Managerが東京リージョンを含む多数のリージョン（ノーカル/オレゴン/アイルランド/フランクフルト/ソウル/シンガポール/シドニー/サンパウロ）に対応した
Elastic BeanstalkからACMの設定が可能になった

リンク：AWS Certificate Manager now available in more regions リンク：AWS Elastic Beanstalk Supports AWS Certificate Manager

19. Amazon Elasticsearch Serviceの制限が緩和された

データノード10台/マスターノード1台 → データノード20台/マスターノード5台
これによりi2.2xlの場合、今まで4TB〜8TBだった最大データ量を12TB〜24TBに拡張可能になった

リンク：Amazon Elasticsearch Service Increases Domain Limits

20. Amazon Kinesis FirehoseでRedshiftへのデータロードにリトライウィンドウを設定可能になった

RedshiftへのCOPYコマンドの実行が失敗しても7200秒以内の間隔を指定して再実行するように設定が可能になった
Kinesis Firehoseのスケーラビリティ(1000リクエスト/1シャード単位にスケール可能)に比べて容易にスケールしにくいRedshiftにおいて、再実行で同期処理の制約から解放されるため、より安心して使えるようになりそう

リンク：Amazon Kinesis Firehose Supports Configurable Retry Window for Loading Data into Amazon Redshift