リソースが発表されました。引き上げられ、また、リソースグループとタグエディタの導入により、タグはより役に立つものとなりました。ポリシーからのアクセスとリソースの管理などを行っています。タグ付けモデルでは、リソース作成とリソースのタグ付けという別個の機能を提供しています。これは柔軟性が高く、多くのユーザーに役立ってきましたが、リソースがタグ付けされていない状態で存在すると、時間枠が小さくなります。つの異なる機能を使用すると、リソースの作成だけは成功してもタグ付けが失敗し、リソースがタグ付けされていない状態になってしまいます。つの新たな機能により、タグ付けをより柔軟で役に立つ仕方で行えます。呼び出しの一部として指定できます。ポリシーを記述できます。リソースレベルのアクセス許可がサポートされるようになりました。ポリシーを記述できます。(呼び出しがインスタンスとボリュームの両方を作成する場合は、インスタンスと各ボリュームに異なるタグを指定できます)。成功するには、両方が成功する必要があります。インスタンスやボリュームを作成した後に実行するタグ付けのスクリプトを構築する必要はもうありません。買収の契約に署名したこと、そして両社が協力し合い高パフォーマンスと科学計算において今まで以上に優れたツールとサービスを開発していく予定であることをブログでお知らせしました。リリースするに至りました。パワー、スケール、柔軟性を活用する技術的および科学的なアプリケーションのセットアップと実行のプロセスをシンプルにするように設計されています。クラスターをセットアップし、シンプルなウェブベースのユーザーインターフェイスを介してアクセスすることができます。使用している場合は、引き続きオンプレミスで実行したりクラウドに移動することができます。サービスや機能を使用して構築されています。インスタンスなどです。このようなマネージド型サービスはワークロードや作業に集中しやすくすることができます。システムソフトウェアのアップグレード、パッチ、処理やストレージのスケーリング、そして自分でクラスターを構築した場合に伴うその他の責任などを心配する必要がありません。テンプレートから起動します。パラメーター化し自己完結型のテンプレートは、起動する各クラスターが同じ様に設定されることを確実にします。メンテナンスとパッチ適用を合理化する方法についてご説明します。オペレーティングシステム設定などのプロセスを自動化することができます。オンプレミスで実行しているインスタンスのソフトウェアコンプライアンスを維持することができます。自動化の機能が含まれています。アプリケーションを組み込む場合に、この機能を使用することができます。自動化を使用することで、イメージの更新を手動で行うための時間や労力を省くことができます。構築することができます。自動化に関する公開ドキュメントを初めてリリースしました。パッチ適用を自動化できるようしたり、その他のサイト固有のパッケージと設定のインストールも自動化します。自動化ドキュメントを最初に書く必要を排除することで自動化を取り入れやすくしています。ご自分の自動化ワークフローを構築する場合にテンプレートとして使用することもできます。ドキュメントはこれと同等の内容を提供します。次のワークフローを自動化します。購入される際のキャパシティー予約においても同様です。リリースし、今まで以上にリザーブドインスタンスの柔軟性を高めました。管理に掛かるコストを削減し、追加オプションを提供します。起動することを心配せずにインスタンスをスタートできます。使用量に適しているか確認することができます。柔軟性が今まで以上に高まります。リージョン内のあらゆるサイズのインスタンスに適用できるようになりました。管理時間を節約したり、コンピューティングリソースをよりクリエイティブで革新的に使用できるようになります。サイズはインスタンスサイズに基づいた正規化係数により決定されています。インスタンスの更新に関する投稿で、入手次第、皆様に追加情報をお知らせすることを約束しました。インスタンスの提供を開始したことをお知らせします。ストレージを備えています。GB/秒のシーケンシャルディスクスループットを実現します。データベース、検索エンジン、データウェアハウス、リアルタイム分析、ディスクベースのキャッシュなど、高スループットと低レイテンシーを必要とするあらゆるワークロードに最適です。ネットワーク帯域幅も大幅に増えます。インスタンスサイズと関連仕様は次のとおりです。Shareお客様からビジネスのダイナミックさと、それを実現するためのアプリケーションがブロックストレージに求めるものについてご意見をうかがうことは、いつも興味深いものです。ビジネス状況の変化に伴ってブロックストレージへの要求も変化し、容量を追加したり、性能特性の異なるボリュームが必要になったりすることもあるはずです。今日では、24時間運用され続けるシステムも珍しくはありません。結果として、ダウンタイムやシステム運用への影響なく変更作業を行えることがお客様にとって重要な要素となってきます。我々は長年にわたり、お客様の様々なユースケースをカバーするために、EBSに新機能を追加し続けてきました。2016年にはスループット最適化HDD(st1)とコールドHDD(sc1)という2種類のボリュームタイプをリリースしました。これらのボリュームをシステム運用への影響なく、パフォーマンス特性の変更やコスト削減を行うことで、階層化ストレージのように利用したいと考えるお客様がいらっしゃいます。本日、EBSの新機能としてエラスティックボリュームをリリースいたしました。これは現行世代のEC2インスタンスにアタッチされた、全ての現行世代のEBSボリュームで利用可能です。お客様はボリュームサイズの拡張、パフォーマンスの調整、ボリュームタイプの変更を利用中に行うことができます。変更処理はオンラインで行われますので、お客様のアプリケーションは引き続き利用可能でダウンタイムはありません。この新機能はリソース計画やチューニング、空き容量の管理といった作業を劇的にシンプル化してくれます。作業自体が不必要になるかもしれません。従来のやり方はダウンタイムを伴うため、変更の完了までプランニングやシステム停止の調整を含めると数週間から数ヶ月にわたる時間が必要でした。これからは、利用しているストレージインフラストラクチャをシンプルなAPIコールで簡単に変更することが可能になります。インフラ構築を急ぐ必要があり、汎用SSDボリュームを採用することにしました。システムをリリースし、運用を行っていくにつれて、スループット最適化HDDボリュームが最適であることに気づいたとしましょう。エラスティックボリュームの機能により、単純にボリュームタイプを変更するだけで対応が完了します。プロビジョンドIOPSボリューム上に構築したリレーショナルデータベースで、1ヶ月のほとんどの期間にわたり問題なく処理を行えるシステムがあります。月末処理の関係で各月終わりの3日間は10倍のトラフィックを処理する必要があったとします。この場合は、エラスティックボリュームを利用して月末の3日間だけIOPSを高く設定し、処理が終わったら元に戻すという運用が可能です。100GBのボリュームで運用してきたシステムで、ディスク使用率が90%を超過したというアラームが発報しました。設定を行っておけば、ボリュームとファイルシステムの拡大を自動的にダウンタイム無しで行うこともできます。お客様はこれら全ての操作をAWSマネジメントコンソールやAPIコール、AWSコマンドラインインタフェース(CLI)で実行できます。CloudFormationのスタック更新機能を利用することも可能で、対象のボリュームに必要な変更を行ってくれます。ポップアップするウィンドウの中で、ボリュームタイプやサイズ、IOPS値(プロビジョンドIOPSボリュームの場合)を変更してください。次のステップは追加されたストレージ領域を利用できるようにするために、ファイルシステムを拡張することです。作業の詳細についてはLinuxでEBSボリュームのストレージ領域を拡張するかWindowsでEBSボリュームのストレージ領域を拡張するを参照してください。ボリュームの状態が最適化中に変わったら(通常数秒で変わります)、ファイルシステムの拡張作業を行うことができます。新しいボリュームの容量やタイプはすぐに利用可能になりますが、最適化の処理は最大で24時間を要する場合があります。コストについて補足すると、ボリュームの状態がoptimizingになったタイミングで新構成を基準に計算されることになります(変更自体のコストはかかりません)。手動オペレーションでの変更も充分に魅力的ですが、自動化を行うたくさんのチャンスがあります。IOPS上限か、それに近いレベルに到達しているかをCloudWatchで監視しアラームを上げるよう設定します。アラームが上がったらIOPS値の増加や、ボリュームタイプの変更を行うための承認プロセスを開始し、変更作業の準備を進めます。同様にCloudWatchのカスタムメトリクスを利用して空き容量をモニタリングして、拡張のための承認プロセスを開始することもできます。CloudWatchメトリクスや予め設定したスケジュールに従ってIOPSの削減やボリュームタイプの変更を行います。(背景:先週、大学のセキュリティ管理者と会話する機会がありました。彼は学内の全てのサーバから1日に10GBのログを収集し、60日間に渡って保持するという仕事をしています。ほとんどのファイルは参照されることはなく、参照が必要になったときでもアクセス速度はそれほど求められません。この場合、1日分のログを書き込むための汎用SSDボリュームを作成し高速な書き込みを実施し、完了したらスループット最適化HDDに変更することでコストを最適化することができます。先にお伝えしたように、新たに追加された領域を利用できるようにするためにはファイルシステムをリサイズする必要があります。Managerを利用したPythonとPowerShellのサンプルスクリプトを提供してくれました。機会均等法を順守しています。平等に採用しています。