Category: Amazon EC2

EC2 シニアプロダクトマネージャーの Taylor Anderson が自動化を利用して AMI メンテナンスとパッチ適用を合理化する方法についてご説明します。-Ana 去年 12 月の re:Invent でリリースした Amazon EC2 Systems Manager では、ソフトウェアインベントリの収集や OS パッチの適用、システムイメージの作成そして Windows や Linux のオペレーティングシステム設定などのプロセスを自動化することができます。こうした機能は自動設定や継続的に行う大規模なシステム管理を自動化し、Amazon EC2 やオンプレミスで実行しているインスタンスのソフトウェアコンプライアンスを維持することができます。Systems Manager には自動化の機能が含まれています。パッチの適用やエージェントの更新、Amazon Machine Image (AMI) にアプリケーションを組み込む場合に、この機能を使用することができます。自動化を使用することで、イメージの更新を手動で行うための時間や労力を省くことができます。代わりに、合理化し繰り返し可能で監査可能なプロセスを通じて AMI を構築することができます。先日、AWS は自動化に関する公開ドキュメントを初めてリリースしました。詳しくは AWS-UpdateLinuxAmi をご覧ください。 このドキュメントは Ubuntu、CentOS、RHEL、Amazon Linux AMI のパッチ適用を自動化できるようしたり、その他のサイト固有のパッケージと設定のインストールも自動化します。さらに、自動化ドキュメントを最初に書く必要を排除することで自動化を取り入れやすくしています。 AWS-UpdateLinuxAmi は、ご自分の自動化ワークフローを構築する場合にテンプレートとして使用することもできます。Windows ユーザーを対象にした、今後公開予定の AWS-UpdateWindowsAmi ドキュメントはこれと同等の内容を提供します。AWS-UpdateLinuxAmi は次のワークフローを自動化します。 ソース Linux AMI から一時 EC2 インスタンスを起動 インスタンスのアップデート インスタンスでユーザー提供の更新前のフックを起動 […]

リザーブドインスタンスは AWS のお客様がご利用されている EC2 の使用量に対し、大幅な割引を提供します (オンデマンドの料金に比べ最大 75% の割引)。また、特定のアベイラビリティーゾーン (AZ) で使用する RI を購入される際のキャパシティー予約においても同様です。去年後半には、リージョン内の AZ すべてを対象に割引を適用するリージョン RI をリリースし、今まで以上にリザーブドインスタンスの柔軟性を高めました。また、リザーブドインスタンスに関連付けられたインスタンスファミリーやその他のパラメーターを変更できるようにするコンバーティブル RI も提供しました。どちらのタイプの RI も管理に掛かるコストを削減し、追加オプションを提供します。リージョン RI を使用すると、RI 割引の対象になる AZ で起動することを心配せずにインスタンスをスタートできます。コンバーティブル RI を使用する場合、時間が経過するに連れて選択するインスタンスタイプやサイズが変わっても、RI が使用量に適しているか確認することができます。 インスタンスサイズの柔軟性 3 月 1 日より、すでにご利用されているリージョン RI の柔軟性が今まで以上に高まります。一括請求により、複数のアカウントで使用している場合でも、共有テナンシーを持つすべての Linux/UNIX RI をインスタンスファミリーと AWS リージョン内のあらゆるサイズのインスタンスに適用できるようになりました。これにより、RI の管理時間を節約したり、コンピューティングリソースをよりクリエイティブで革新的に使用できるようになります。新しい RI や既存の RI のサイズはインスタンスサイズに基づいた正規化係数により決定されています。 インスタンスサイズ 正規化係数 nano 0.25 micro 0.5 small 1 medium 2 […]

の初日に、私は EC2 インスタンスの更新に関する投稿で、入手次第、皆様に追加情報をお知らせすることを約束しました。本日は、15 か所の AWS リージョンで 6 つのサイズの新しい I3 インスタンスの提供を開始したことをお知らせします。このインスタンスは入出力量が多いワークロード用に設計されており、きわめて効率が高い NVMe SSD ストレージを備えています。4 KB ブロックで最大 330 万の IOPS を配信し、最大 16 GB/秒のシーケンシャルディスクスループットを実現します。このため、リレーショナルデータベース、NoSQL データベース、検索エンジン、データウェアハウス、リアルタイム分析、ディスクベースのキャッシュなど、高スループットと低レイテンシーを必要とするあらゆるワークロードに最適です。I3 インスタンスは、I2 インスタンスと比較すると、低コストで高密度のストレージを提供し、CPU コアあたりの IOPS とネットワーク帯域幅も大幅に増えます。 仕様 インスタンスサイズと関連仕様は次のとおりです。 インスタンス名 vCPU カウント メモリ インスタンスストレージ (NVMe SSD) 料金/時間 i3.large 2 15.25 GiB 0.475 TB 0.15 USD i3.xlarge 4 30.5 GiB 0.950 TB 0.31 USD i3.2xlarge 8 […]

お客様からビジネスのダイナミックさと、それを実現するためのアプリケーションがブロックストレージに求めるものについてご意見をうかがうことは、いつも興味深いものです。ビジネス状況の変化に伴ってブロックストレージへの要求も変化し、容量を追加したり、性能特性の異なるボリュームが必要になったりすることもあるはずです。今日では、24時間運用され続けるシステムも珍しくはありません。結果として、ダウンタイムやシステム運用への影響なく変更作業を行えることがお客様にとって重要な要素となってきます。 我々は長年にわたり、お客様の様々なユースケースをカバーするために、EBSに新機能を追加し続けてきました。例えば、2016年にはスループット最適化HDD(st1)とコールドHDD(sc1)という2種類のボリュームタイプをリリースしました。これらのボリュームをシステム運用への影響なく、パフォーマンス特性の変更やコスト削減を行うことで、階層化ストレージのように利用したいと考えるお客様がいらっしゃいます。言い換えると、お客様はEBSがより柔軟になることを望んでいるのです！ エラスティックボリューム 本日、EBSの新機能としてエラスティックボリュームをリリースいたしました。これは現行世代のEC2インスタンスにアタッチされた、全ての現行世代のEBSボリュームで利用可能です。お客様はボリュームサイズの拡張、パフォーマンスの調整、ボリュームタイプの変更を利用中に行うことができます。変更処理はオンラインで行われますので、お客様のアプリケーションは引き続き利用可能でダウンタイムはありません。 この新機能はリソース計画やチューニング、空き容量の管理といった作業を劇的にシンプル化してくれます。あるいは作業自体が不必要になるかもしれません。従来のやり方はダウンタイムを伴うため、変更の完了までプランニングやシステム停止の調整を含めると数週間から数ヶ月にわたる時間が必要でした。しかしこれからは、利用しているストレージインフラストラクチャをシンプルなAPIコールで簡単に変更することが可能になります。 ワークロードの変化 – インフラ構築を急ぐ必要があり、汎用SSDボリュームを採用することにしました。システムをリリースし、運用を行っていくにつれて、スループット最適化HDDボリュームが最適であることに気づいたとしましょう。エラスティックボリュームの機能により、単純にボリュームタイプを変更するだけで対応が完了します。 突発的な需要への対応 – プロビジョンドIOPSボリューム上に構築したリレーショナルデータベースで、1ヶ月のほとんどの期間にわたり問題なく処理を行えるシステムがあります。ただし月末処理の関係で各月終わりの3日間は10倍のトラフィックを処理する必要があったとします。この場合は、エラスティックボリュームを利用して月末の3日間だけIOPSを高く設定し、処理が終わったら元に戻すという運用が可能です。 ストレージの増加 – 100GBのボリュームで運用してきたシステムで、ディスク使用率が90%を超過したというアラームが発報しました。あらかじめ設定を行っておけば、ボリュームとファイルシステムの拡大を自動的にダウンタイム無しで行うこともできます。 エラスティックボリュームの利用 お客様はこれら全ての操作をAWSマネジメントコンソールやAPIコール、AWSコマンドラインインタフェース(CLI)で実行できます。これに加えて、AWS CloudFormationのスタック更新機能を利用することも可能で、対象のボリュームに必要な変更を行ってくれます。コンソールを利用する場合は、対象のボリュームを選択してアクションメニューから「Modify Volume」を選択するだけです: ポップアップするウィンドウの中で、ボリュームタイプやサイズ、IOPS値(プロビジョンドIOPSボリュームの場合)を変更してください。これは75GBの汎用SSDボリュームを、20,000IOPSで400GBのプロビジョンドIOPSボリュームに変更する例です: 変更ボタンをクリックしたら、確認ウィンドウが表示されるので問題が無ければ「YES」をクリックします: ボリュームの「状態」に変更処理の進捗状況(modifying、optimizing、completed)が表示されます: 次のステップは追加されたストレージ領域を利用できるようにするために、ファイルシステムを拡張することです。作業の詳細についてはLinuxでEBSボリュームのストレージ領域を拡張するかWindowsでEBSボリュームのストレージ領域を拡張するを参照してください。ボリュームの状態が最適化中に変わったら(通常数秒で変わります)、ファイルシステムの拡張作業を行うことができます。新しいボリュームの容量やタイプはすぐに利用可能になりますが、最適化の処理は最大で24時間を要する場合があります。コストについて補足すると、ボリュームの状態がoptimizingになったタイミングで新構成を基準に計算されることになります(変更自体のコストはかかりません)。 エラスティックボリュームの自動オペレーション 手動オペレーションでの変更も充分に魅力的ですが、自動化を行うたくさんのチャンスがあります。いくつかのアイデアをお見せしてみましょう: 正しいサイジング – IOPS上限か、それに近いレベルに到達しているかをCloudWatchで監視しアラームを上げるよう設定します。アラームが上がったらIOPS値の増加や、ボリュームタイプの変更を行うための承認プロセスを開始し、変更作業の準備を進めます。同様にCloudWatchのカスタムメトリクスを利用して空き容量をモニタリングして、拡張のための承認プロセスを開始することもできます。 コストの削減 – CloudWatchメトリクスや予め設定したスケジュールに従ってIOPSの削減やボリュームタイプの変更を行います。（背景：先週、大学のセキュリティ管理者と会話する機会がありました。彼は学内の全てのサーバから1日に10GBのログを収集し、60日間に渡って保持するという仕事をしています。ほとんどのファイルは参照されることはなく、参照が必要になったときでもアクセス速度はそれほど求められません。この場合、1日分のログを書き込むための汎用SSDボリュームを作成し高速な書き込みを実施し、完了したらスループット最適化HDDに変更することでコストを最適化することができます。） 先にお伝えしたように、新たに追加された領域を利用できるようにするためにはファイルシステムをリサイズする必要があります。この手順をお見せするために、私の同僚がCloudWatch Events、AWS Lambda、EC2 Systems Managerを利用したPythonとPowerShellのサンプルスクリプトを提供してくれました。このルールはEBSから送信される情報に基づきmodifyVolumeというイベントにマッチし、logEventsというLambdaファンクションを起動します: このファンクションは対象となるボリュームを特定し、これがEC2 Systems Managerで管理されるインスタンスにアタッチされていることを確認したうえでメンテナンス用のタグ情報を付与します: def lambda_handler(event, context): volume =(event[‘resources’][0].split(‘/’)[1]) attach=ec2.describe_volumes(VolumeIds=[volume])[‘Volumes’][0][‘Attachments’] if len(attach)>0: instance = attach[0][‘InstanceId’] filter={‘key’: ‘InstanceIds’, ‘valueSet’: [instance]} info = […]

AWS Identity and Access Management(IAM) のロール を利用することで、Amazon EC2上で実行するアプリケーションは、AWSが自動的に作成、配布、およびローテーションする一時的なセキュリティ資格情報を利用することができます。一時的な資格情報を使用することは、IAMのベストプラクティスとなっており、インスタンスで長期間の鍵の管理する必要がなくなります。IAM Roles for EC2 (EC2のIAMロール)を使用することで、長期的なAWSアクセスキーを手動またはプログラムで管理する必要もなくなります。そして本日、既存のEC2インスタンスにIAMロールをアタッチすることが可能になり、アプリケーションはAWSによって提供される一時的なセキュリティ資格情報を使用できるようにするよう設定できるようになりました。 また、既存のEC2インスタンスに添付されているIAMロールを変更することも可能になります。 このブログ記事では、AWS CLIを使用して既存のEC2インスタンスにIAMロールをアタッチする方法をご紹介します。 ソリューションの概要 このブログ記事のソリューションでは、 1. IAMロールの作成 2. IAMロールなしで起動された既存のEC2インスタンスにIAMロールをアタッチ 3. アタッチされているIAMロールの付け替え この記事では、新しく作成されたIAMロールを”YourNewRole“とします。このロールに関連付けられたインスタンス・プロファイルを”YourNewRole-Instance-Profile“、 既存のインスタンスを”YourInstanceId“とすることにます。 これら(赤字)はアカウントのリソース名に置き換えてください。 ここでは、AWSコマンドラインインターフェイス（CLI）の設定が完了しており、IAMロールを作成する権限、EC2 APIを呼び出す権限を持っていることを前提としています。 IAMロールの作成 注：既存のIAMロールをアタッチする場合は、このポストの「IAMロールなしで最初に起動された既存のEC2インスタンスにIAMロールをアタッチ」に進んでください。 またAWSマネージメントコンソールを使用してIAMロールを作成してから、同じセクションに進むこともできます。 AWS CLIからIAMロールを作成する前に、信頼ポリシーを作成する必要があります。 信頼ポリシーは、EC2などのAWSサービスがアプリケーションに代わってIAMロールを引き受けることを許可します。 信頼ポリシーを作成するには、下記のポリシーをコピーし、YourNewRole-Trust-Policy.jsonという名前で保存したテキストファイルに貼り付けます。 { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Principal”: { “Service”: “ec2.amazonaws.com” }, “Action”: “sts:AssumeRole” } ] } 信頼ポリシーを作成すると、既存のEC2インスタンスにアタッチできるIAMロールを作成する準備が整いました。 AWS CLIからIAMロールを作成 1. AWS […]

Matt Wood の投稿 当社は Alexa から Amazon Go まで Amazon のすべての領域でディープラーニングを広範に使用し、これまで多くのディープラーニングエンジンを試してきました。そして 1 つのエンジンがディープラーニングを実行するための最もスケーラブルで効率的な方法として出現しました。その理由により、Amazon のエンジンとして MXNet が選択されました。MXNet はオープンソースの最新鋭のディープラーニングエンジンであり、これにより開発者は高度なカスタム人工知能システムを構築することができます。 このようなシステムのトレーニングは、そのスケールとパフォーマンスにより、MXNet では著しく高速です。たとえば、よく使用される画像認識ネットワークの Resnet では、MXNet は他のエンジンと比較して 2 倍のスループットを実現し、同等のモデルを半分の時間でトレーニングできます。また、MXNet は数百の GPU にわたって線形に近いスケーリングを示しますが、他のエンジンのパフォーマンスでは、規模に見合った増加は見られません。 Amazon には重要なチームがあり、MXNet コミュニティと連携して、この進化に継続的に取り組んでいます。チームは MXNet に対して Apache Incubator に参加し、Apache Software Foundation のプロセス、財産管理、支援活動、およびコミュニティイベントを活用することを提案しました。幸い、この提案は受け入れられました。Apache MXNet への投資は開始点にあり、当社はコミュニティと連携して既に重要になっているユーティリティを拡大していくことを楽しみにしています。MXNet の使用開始を希望される場合は、AWS Re:Invent で私が行った基調講演をご覧になり、AWS ディープラーニング AMI のインスタンス (またはクラスター全体) を起動してください。これには MXNet と、プリコンパイルされ、すぐに使用できるサンプルコードが含まれています。また、推奨モデリングに関する Leo のプレゼンテーションとチュートリアルもご覧ください。 Twitter で @apachemxnet […]

2016年末最後の数秒をカウントダウンする場合は、最後に1秒を追加するのを忘れないようにしてください！ 次回のうるう秒（通算27回目）が、UTC（世界標準時）の2016年12月31日 23:59:60として挿入されます（訳注：日本標準時では2017年1月1日 8:59:60になります）。これは地球上での時刻（協定世界時）と太陽時（天文時）とのずれを小さくするために行われ、この結果、UTCでは今年最後の1分は61秒あることになります。 参考）「うるう秒」挿入のお知らせ（総務省） 前回のうるう秒の際に出した情報（事前にご確認ください – AWSでのうるう秒対応）は引き続き有効で、今回も同様に処理されますが、少しの違いと進展があります: AWS調整時刻（AWS Adjusted Time） –うるう秒挿入前後の24時間の期間にわたって、うるう秒の1秒を少しずつ分散します（UTCで12月31日の11:59:59から、2017年1月1日12:00:00まで）。AWS調整時刻と協定世界時はこの期間が終了後に同期します。（訳注：この期間の１秒をごくわずかに遅くすることで、追加される１秒を長い時間のなかに分散する方法であり、これは前回うるう秒挿入時と同じ挙動です。詳しくは前回の情報をご確認ください。） Microsoft Windows – Amazonによって提供されたMicrosoft WindowsのAMIを利用しているインスタンスは、AWS調整時刻に従います。 Amazon RDS – 大多数のAmazon RDS インスタンスは （UTCで設定されている場合）“23:59:59” を2回記録します。しかし、Oracle 11.2.0.2、11.2.0.3、12.1.0.1 はAWS調整時刻に従います。Oracle 11.2.0.4と12.1.0.2について詳細な情報が必要な場合はAWSサポートにお問い合わせください。 サポートが必要ですか？ このうるう秒挿入についてご質問がある場合は、AWSサポートにコンタクトいただくか、EC2フォーラムにポストしてください。 — Jeff; 翻訳：下佐粉　昭（@simosako） 原文：https://aws.amazon.com/blogs/aws/look-before-you-leap-december-31-2016-leap-second-on-aws/

去年、EC2 Run Command をご紹介して、最初に EC2 インスタンスで、次いでハイブリッドおよびクラウド間の環境で大規模なリモートのインスタンス管理をするための使い方をご説明しました。その過程で、Linux インスタンスのサポートを追加したため、EC2 Run Command は幅広く応用できる非常に便利な管理ツールになりました。 ファミリーへようこそ Werner が EC2 Systems Manager を で発表したので、ついにお話しできるようになりました。これは、同じように便利な 8 つの機能と共に EC2 Run Command の強化版を含む新しい管理サービスです。EC2 Run Command と同様に、Windows と Linux を実行するインスタンスとサービスで構成されたハイブリッドおよびクラウド間の環境をサポートします。 を開き、管理するインスタンスを選択して、実施するタスクを定義します (API および CLI のアクセスも可能)。機能拡張と新機能の概要を次に示します。 Run Command – コマンドの実行速度を制御し、エラー率が高くなりすぎたときにコマンドの発行を停止できるようになりました。 State Manager – 定期的に適用される、ポリシーで定義されたシステム設定を維持します。 パラメーターストア – ライセンスキー、パスワード、ユーザーリスト、その他の値の一元管理型 (オプションで暗号化された) ストレージを提供します。 メンテナンス時間 – 更新のインストール、その他のシステムメンテナンスの時間枠を指定します。 ソフトウェアインベントリ – 各インスタンスから、詳細なソフトウェアおよび設定のインベントリ (ユーザー定義の追加を含む) […]

インターネットは、特にモバイルアプリケーション、コネクテッドデバイス、そしてIoTの分野で引き続き成長しており、それが業界全体のIPv6への移行に拍車をかけています。米国政府機関は2010年に定められた指令に従って、パブリックに公開されたサーバーとサービスをできるだけすみやかにIPv6に移行するように取り組んでいます。128ビットのアドレス空間を持つIPv6では十分な拡張の余地があり、新しいアプリケーションやユースケースへの道が開かれます。 EC2のIPv6 今年の初めに、S3 (Transfer Accelerationを含む)、CloudFront、WAF、および Route 53のIPv6サポートを開始しました。本日、新しい大きなステップとして、Virtual Private Cloud (VPC) およびEC2インスタンスのIPv6サポートを開始しました。米国東部 (オハイオ) リージョンを皮切りに、他のリージョンも対応を進めていきます。 IPv6サポートは、新規および既存のVPCで利用できます。マネジメントコンソール上でチェックボックスにチェックを入れるだけで、VPCごとにオプトインすることができます (APIとCLIもサポートされます)。

AWSのお客様はT2インスタンスを使う時に得られるコスト効率のよい、バーストベースのモデルを好まれています。これらのお客様は webサーバや開発環境、継続的なインテグレーション用のサーバ、テスト環境、そして小さなデータベース等の一般的な用途でのワークロードを動作させるのにT2インスタンスを使います。これらのインスタンスは豊富なベースラインパフォーマンスと、必要に応じてフルコアのプロセッシングパワーにまで透過的にスケールアップを提供します。（もしこちらがあなたにとって新しいニュースであれば、バースト可能な性能を持つ新しい低コストEC2インスタンスをご参照ください） 本日２つの新しいより大きなT2インスタンスサイズを追加します。- 16GiB メモリの t2.xlargeと32GiB メモリのt2.2xlarge です。これらの新しいサイズにより、お客様はより大きなリソースの要件のアプリケーション向けに T2のバーストモデルの価格とパフォーマンスのメリットを享受頂けます。（t2インスタンスのレンジを拡大するのは、今回が3度目になります；昨年の6月にt2.largeを、昨年の12月にt2.nanoを追加しました。 こちらがT2インスタンスのすべてのサイズ向けのスペックになります。（価格は最近のEC2の値下げを反映しています。US Eastリージョンの料金になります。） 名前 vCPU ベースラインパフォーマンス プラットフォーム メモリ CPU クレジット / 時間 価格 / 時間 (Linux) t2.nano  1  5%  32bit または 64-bit  0.5  3  $0.0059 t2.micro 1 10%  32bit または 64-bit 1 6 $0.012 t2.small 1 20%  32bit または 64-bit 2 12 $0.023 t2.medium 2 40%  32bit […]