AWSウォッチャー吉田真吾のブログ転載スタート！

5月中旬から3週間のAWSのアップデートを振り返る

2016年06月08日 07時00分更新

文● 吉田真吾（Section-9）

今週から始まった「Section-9吉田真吾のAWS関連ブログまとめ」は、AWS関連の最新情報をまとめているSection-9 吉田真吾さんのブログ転載になります。今週は5月中旬から6月1日までのアップデートの振り返りです。

　どうも、セクションナインの吉田真吾（@yoshidashingo）です。だいぶ間が開いてしまい恐縮ですが、5/12(木)から6/1(水)まで3週間分のアップデートをふりかえってみましょう。

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 ブログ

【新サービス】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 ブログ

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 ブログ

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×1,920 GB SSD →揮発性のストレージなのでスワップや一時領域に使う想定
ネットワーク帯域幅：10Gbps
専用のEBS帯域幅：10Gbps (デフォルトでEBS最適化、追加料金不要)

現状では利用申請が必要。SAPなどに利用する想定している。料金は東京リージョンにおいて、オンデマンドで1時間あたり $19.341、1年すべて前払い($97438：約1000万)で$11.123、3年すべて前払い($142204：約1500万)で$5.411となっている。

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

I Love My Amazon WorkSpaces！

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

I Love My Amazon WorkSpaces! | Amazon Web Services ブログ

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

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

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

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 ブログ

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

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

また、セグメントの秒数が指定できるので、細かくすればするほど回線状況の変化にすばやくセグメント変更が対応できるようになる。

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

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

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

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

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

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

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

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

ElastiCache for Redis、今までS3からRDBファイルをインポートすることはできたが、エクスポートはできなかった。今回はエクスポートに対応。しかもRDBファイルなのでクラスタ再構築（スケール変更のためなど）や共有に使うことができる。

バックアップはスナップショットで定期的にやっておいて、移行や共有はRDBファイルで行うという使い分けができそう。

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

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

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

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

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 ブログ

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

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

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

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

ECSがDocker 1.11をサポート

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

Amazon EC2 Container Service Supports Docker 1.11

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

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

AWS Certificate Managerが東京リージョンを含む多数のリージョン（ノーカル／オレゴン／アイルランド／フランクフルト／ソウル／シンガポール／シドニー／サンパウロ）に対応した

Elastic BeanstalkからACMの設定が可能になった

AWS Elastic Beanstalk Supports AWS Certificate Manager

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

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

Amazon Elasticsearch Service Increases Domain Limits

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

Amazon WorkSpacesがタグをサポート

Amazon WorkSpaces now supports tagging

NIST 800-53クイックスタートガイドをアップデート