Author: AWS Japan

EC2スポットインスタンスは、AWSクラウドの余剰コンピューティングキャパシティへのアクセスを提供します。 我々のお客様は、オンデマンドインスタンスと比較して大幅な節約をもたらす価格で、CI/CD環境とトラフィックジェネレータ、Webサーバとマイクロサービスのホスト、動画のレンダリング、さまざまなタイプの解析ジョブを実行するためにスポットインスタンスを使用しています 。 新しい合理化されたアクセス 11/28、我々はスポットインスタンスのための新しい、合理化されたアクセスモデルを導入します。 スポットインスタンスを起動したい時、RunInstances関数やrun-instancesコマンド、またはAWSマネージメントコンソールを使用して希望内容をシンプルにサブミットするだけで、条件が満たされている限りそのリクエストを実行することができます。 余分な労力を費やすことなく、インスタンスタイプのオンデマンド価格を最大90％削減できるため、同じ予算でアプリケーションスループットを最大10倍向上できます。 この方法で起動するインスタンスは、終了するまで、またはEC2がオンデマンドリクエストのためにEC2スポットインスタンスをターミネートする必要がある場合まで実行されます。 その時点で、スポットインスタンスには通常2分前の警告が与えられる為、その後再生できるフォールトトレラントなアプリケーションに最適です。 スポットマーケット、入札、およびスタンドアロンの非同期APIへの呼び出しを理解する必要があった旧モデルとは異なり、新しいモデルは同期的でオンデマンドとして使いやすいものです。 あなたのコードまたはスクリプトは即座にインスタンスIDを受け取り、リクエストが処理され受け入れられたかどうかを確認する必要はありません。 私たちは可能な限りクリーンでシンプルにしました。現在の多くのスクリプトやアプリケーションを修正して、スポットリクエストで使用することが容易になると予想しています。 スポットインスタンスの予算をさらに管理したい場合は、スポットリクエスト時に最大価格を指定するオプションがあります。 スポットを使用してAmazon EMR、Amazon ECS、AWS Batchクラスタにパワーを注いでいる場合、またはAWS CloudFormationテンプレートまたはAuto Scaling Groupを使用してスポットインスタンスを起動した場合、変更を加えることなくこの新しいモデルのメリットが得られます 。 RequestSpotInstancesまたは RequestSpotFleetの周辺に構築されたアプリケーションは、変更なしでうまく動作できます。 しかしながらSpotPriceパラメータを含まない要求を行うことができます。 スムーズな価格変更 11/28発表の一環として、スポット価格の変化の仕様を変えて、需給の長期的なトレンドに基づいて価格がより緩やかに調整されるモデルに移行しています。 先ほどお話したように、On-Demand価格の平均70-90％を引き続き保持し、インスタンスの稼働中の期間に有効なスポット価格を引き続き支払えます。 スポットフリート機能をベースに構築されたアプリケーションは、フリートの作成時に指定した設定に基づいて、最も費用対効果の高いプールにスポットインスタンスの配置を自動的に多様化します。 スポット イン アクション コマンドラインからスポットインスタンスを起動する際、 単にスポット市場を指定してください： $ aws ec2 run-instances –instance-market-options ‘{“MarketType”:”Spot”}’ \ –image-id ami-1a2b3c4d –count 1 –instance-type c3.large インスタンスハイバネーション メモリに多くの状態を保持するワークロードを実行する場合、この新しい機能が好ましいです！ インスタンスが再利用されたときにメモリ内の状態を保存するように手配し、ラップトップを閉じてから開くときと同じように、キャパシティが再び利用可能になったときに中断した場所とインスタンス上のアプリケーションを選択できます。 この機能は、Amazon Linux、Ubuntu、またはWindows Serverを実行しているC3、C4、および特定のサイズのR3、R4、およびM4インスタンスで動作し、EC2ハイバネーションエージェントでサポートされています。 メモリ内の状態は、インスタンスの起動時に設定された領域を使用してインスタンスのルートEBSボリュームに書き込まれます。 プライベートIPアドレスとElastic IPアドレスは、停止/開始サイクル全体にわたって保存されます。 […]

私はいつも新規のEC2ユーザの方には、他のインスタンスタイプを見る前に、まずは汎用インスタンスから使い始め、負荷テストをしてみて、自分のアプリケーションのコンピュート・メモリ・ネットワーキングの利用具合をよく把握することをアドバイスしています。コンピュート、メモリ、ストレージ等に最適化した幅広いインスタンスの選択肢によって、我々のお客様は要件にフィットする最適なインスタンスタイプを選ぶ柔軟さを得ることができます。 私のEC2インスタンスの歴史の記事にあるように、汎用 (M) インスタンスは我々がm1.smallをローンチした2006年まで遡ります。我々はこの家系図の枝にそって進化を続け、M2 (2009年)、M3 (2012年)、そしてM4 (2015年) インスタンスをローンチしてきました。我々のお客様は、汎用インスタンスを使って、WEB & APPサーバを動かしたり、エンタープライズアプリケーションをホストしたり、オンラインゲームを支援したり、キャッシュのクラスタを構築しています。 新しいM5インスタンス 2017年11月29日、我々は新しいM5インスタンスをローンチすることで、次のステップに進みます。我々の継続的なイノベーションへのコミットによる成果を持ち、旧世代よりも良い費用対パフォーマンスまでも得られるインスタンスです。カスタムの2.5 GHz Intel® Xeon® Platinum 8175Mシリーズのプロセッサをベースに、M5インスタンスは過酷なワークロードのために設計されておりM4インスタンスよりもコア単価で14%の費用対パフォーマンスの向上が得られます。AVX-512命令を使っているアプリケーションでは、コア毎にさらに2倍のFLOPSを生み出します。我々はさらに新しいハイエンドなサイズを追加することで、更に多くの選択肢を提供しています。 こちらがM5インスタンス達です(全てVPCのみ、HVMのみで、EBS最適化です): インスタンス名 vCPUs RAM ネットワーク帯域 EBS最適化帯域 m5.large 2 8 GiB 最大 10 Gbps 最大 2120 Mbps m5.xlarge 4 16 GiB 最大 10 Gbps 最大 2120 Mbps m5.2xlarge 8 32 GiB 最大 10 Gbps 最大 2120 Mbps m5.4xlarge 16 64 GiB […]

AWSの規模と顧客基盤の多様性により、様々なタイプのワークロードに特化したEC2インスタンスタイプを作成する機会を得られました。例えば、多くの一般的な新ビッグデータの利用ケースは、数テラバイトのデータへの高速でシーケンシャルなアクセスに依存しています。お客様は巨大なMapReduceクラスタを構築して動かし、分散ファイルシステムをホストし、Apache Kafkaを利用して大量のログを処理したいと考えています。 新しいH1インスタンス 新しいH1インスタンスは、この利用ケースに特化して設計されています。既存のD2（高密度ストレージ）インスタンスに比べ、H1インスタンスはローカル磁気ストレージ1テラバイトあたり、より多くのvCPUとメモリを搭載し、ネットワーク帯域幅を拡張しています。リソースのバランスのとれた組み合わせによって、より複雑な課題に対処する能力を提供します。 H1インスタンスは Intel Xeon E5-2686 v4プロセッサ(2.3GHz)で動作し、以下の4つのインスタンスサイズを用意しました（全てVPCのみ、HVMのみ) インスタンス名 vCPUs RAM ローカルストレージ ネットワーク帯域幅 h1.2xlarge 8 32 GiB 2TB 最大 10 Gbps h1.4xlarge 16 64 GiB 4TB 最大 10 Gbps h1.8xlarge 32 128 GiB 8TB 10Gbps h1.16xlarge 64 256 GiB 16TB 25Gps 大きい2つのサイズでは、全コアのTurboで2.7GHz、シングルコアのTurboで3.0GHzのIntel TurboとCPUパワーマネージメントをサポートします。 ローカルストレージはシーケンシャルI/Oで高いスループットを出せるよう最適化されており、2MBのブロックサイズで最大1.15GB/s の転送が期待できます。ストレージは256ビットのXTS-AESとワンタイムキーにより暗号化されます。2つの最大サイズのインスタンスはIntel TurboおよびCPUパワーマネージメントをサポートし、all-core Turboは2.7GHz、single-core Turboは3.0GHzで動作します。 インスタンス間での大容量データの送受信は、拡張ネットワークを使うことで容易に行うことができ、プレースメントグループ内で最大25Gbpsのネットワーク帯域幅が得られます。 今すぐ起動してみましょう H1インスタンスは米国東部（バージニア北部）、米国西部（オレゴン）、米国東部（オハイオ）、欧州（アイルランド）の各リージョンで本日（日本時間2017年11月30日）からオンデマンド型及びスポットでの利用が可能です。その他のリージョンでも準備中です。専用ホスト型、専用インスタンス、リザーブドインスタンス（1年および3年）も同じく利用可能です。 — Jeff; 原文: H1 […]

2017年11月30日、個別のAWS Lambdaファンクションに対して同時実行数の上限を設定することができるようになりました。実行数上限数の設定は、アカウントレベルの同時実行上限の一部を特定のファンクションに対して予約する事になります。この機能によって、特定のファンクションを事前に設定した最大同時実行数に到達した場合にスロットルさせることが出来ます。この機能は、Lambdaによって呼び出されるダウンストリームリソース（例えばデータベースのような）に対するトラフィックレートを制限したい場合や、プライベートVPCにアクセスするファンクションでのElastic Network Interface(ENI)とIPアドレスの消費を制御したい場合に役に立ちます。 あるファンクションの同時実行上限を数値で指定できます。こちらは、そのアカウント全体の同時実行上限($ACCOUNTで定義）から割り当てられます。1アカウントに対して、リージョンあたりの全てのファンクションのデフォルトの同時実行数は1000となっています。デフォルトでは、全てのファンクションの同時実行数が、このアカウントレベルの上限(つまり$ACCOUNT)に対してカウントされます。特定のファンクションに対して上限を設定すれば、同時実行上限の割当は、共有プールから取りされ、その特定のファンクションに割り当てられます。そのファンクションのその後全ての呼び出しは、ファンクションレベルの上限に対してのみカウントされます。個々のファンクションの同時実行数と、アカウントレベルの同時実行数は、この機能と同時に利用可能となった新しいAmazon CloudWatchメトリクスで追跡することが出来ます。 この機能についてより詳しく知りたい方はドキュメントをご参照ください。また、プロダクトページを訪れてさらなる情報を取得ください。 この機能は、 US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), AWS GovCloud (US), Canada (Central), South America (São Paulo), EU (Frankfurt), EU (Ireland), EU (London), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), China (Beijing)のリージョンでご利用可能です。   翻訳はSA布目が担当しました。原文はこちら

私が想像していた以上に早くサーバレスアプリケーションはメインストリームになりました。毎日毎秒、数え切れないほどの AWS Lambda ファンクションが起動され、ビジネスクリティカルな処理を実行しています。ユーザの皆さんは その柔軟性、安定性、コスト効率の良さを好きだと言ってくれます。 私たちはすべてのAWSのお客様がサーバレスな未来へ向かえるようにしたいと考えています。AWS Lambdaのサービス提供開始後、サーバレスアプリケーションのデプロイおよび管理プロセスを簡素化するため Serverless Application Model (SAM) を提供しました。さらにサーバレスのリファレンスアーキテクチャを公開しました。現在、Web アプリケーション、モバイルバックエンド、画像認識&処理、リアルタイムファイル処理、IoTバックエンド、MapReduce、リアルタイムストリーミング処理、そしてチャットボット向けの画像加工 を公開しています。 2017年11月30日、私たちは次のステップをお伝えします。AWS コンソールからサーバレスアプリケーションを可能な限り容易に探し、見つけ、デプロイできるようにします。加えて Lambda、SAM、サーバレスアプリケーションに関するオープンソースコミュニティをサポートするため、誰もが共有し、参加し、メリットを得られる場を提供します。

プログラミングを始める時に最初に学ぶことは、どんな職人でも同様ですが、道具についてです。メモ帳は役に立たないでしょう。強力なエディタとテスティング パイプラインがあなたの生産性に大きく貢献します。私はまだ最初にVimの使い方を学んだ時のことを覚えています。それを使ってシステムと複雑なプログラムをZip化しました。すべてのコンパイラと依存関係を新しいマシンにセットアップすることが、どれほど大変だったか覚えていますか？新しいデベロッパーをプロジェクトに参加させるためにバージョンをマッチさせ、構成ファイルを取り繕い、ドキュメントを書くのに、どれほどのサイクルを浪費したことか。 本日（11/30）コーディング、実行、デバッグを可能にする統合開発環境（IDE）をWebブラウザ上で実現するのAWS Cloud9をローンチしました。Cloud9は多くの人気のある開発言語（Javascript、Python、PHP、その他）のための主要なツールをパッケージ化しているので、様々なコンパイラやツールなどをインストールする必要はありません。Cloud9はまたサーバーレスアプリケーションとのシームレスなエクスペリエンスを提供しておりローカルとリモートの間でテストやデバッグを素早くスイッチできます。ポピュラーなオープンソースのAce Editorとc9.io IDE（昨年買収しました）をベースに、AWS Cloud9は非常にパワフルなペアプログラミング機能と共にクラウド開発におけるコラボレーションが容易になるように設計されています。Cloud9は、このBlog記事でカバーしているものよりも多くの機能を提供していますが、ここではクイックにエディタ機能、AWSとのインテグレーション、コラボレーション機能の3つのコンポーネントに分解して掘り下げていきます。

スプレッドプレイスメントグループは、クラスタやインスタンスのグループが障害になる可能性を低減する手助けを行います。Amazon EC2は、多くのHPCアプリケーションに典型的な、密なノード間コミュニケーションのために低レイテンシーなネットワークパフォーマンスが必要なアプリケーション向けに、クラスタプレイスメントグループを持っていました。今回リリースされた、スプレッドプレイスメントグループを利用することにより、メンバーのインスタンスが別個のハードウェアに配置され、アプリケーションに対してハードウェア障害による影響を低減することが可能になりました。スプレッドプレイスメントグループは全てのAWSリージョンでご利用可能です。スプレッドプレイスメントグループは、AWS Management Console, AWS Command Line Interface (CLI), AWS SDKからご利用可能です。   翻訳はSA布目が担当しました。原文はこちら

Amazon Aurora Multi-Master は、複数のアベイラビリティゾーンにわたって複数のRead/Writeマスターインスタンスを作成することができます。これによって、リードレプリカで現在できることと同様に、アプリケーションは1つのクラスター内の複数のデータベースインスタンスを読み書きできるようになります。 Multi-MasterクラスターはAuroraの高可用性を向上させます。複数インスタンス内の1つが落ちたとしても、クラスター内のその他のインスタンスに即座に引き継がれます。インスタンス障害やAZ全体障害が起きたとしても、アプリケーションのダウンタイムほぼゼロで、読み書きの可用性が維持されます。 現在のSingle-MasterのAuroraは、1つのクラスター内に1台の書き込みインスタンスと最大15台の昇格可能なリードレプリカをサポートし、書き込みインスタンスはr4.16xlargeで秒間200,000書き込みを実行できます。Aurora Multi-Master であれば、より高い書き込みスループットを必要とするワークロードであっても、マスターインスタンスを追加することで書き込みを水平方向にスケールアウトさせることができます。 このプレビューはMySQL互換のAuroraで使用でき、サインアップフォームに記入することで参加できます。 Aamazon Aurora はオープンソースデータベースのシンプルさとコスト効率、およびハイエンド商用データベースのパフォーマンスと可用性を両立した、完全マネージドなリレーショナルデータベースです。 Aurora Multi-Master プレビュー: サインアップ （翻訳はSA柴田が担当しました。原文はこちら）

Amazon EC2にて、他のAWSリージョンを跨いでVirtual Private Cloud (VPC)ピアリングの確立ができるようになりました。(※2018/02/21 追記、新たに9つのリージョンが追加されました　詳細はこちら) インターリージョンVPCピアリングでは、Gateway、VPNコネクション、ネットワークアプライアンスなどを使う事なく、別なリージョンで稼働しているEC2インスタンス、RDSデータベース、LambdaファンクションなどのVPCリソースに対してPrivate IPアドレスにて通信が可能です。 インターリージョンVPCピアリングは、リージョン間のリソース共有や地理的な冗長性を得るためのデータレプリケーションに関して、シンプルかつコスト効率の良い方法となります。インターリージョンVPCピアリングはVPCと同様な水平方向のスケール、冗長、高可用性テクノロジーにより構築されており、単一障害点や帯域のボトルネック無しに暗号化します。インターリージョンVPCピアリングのトラフィックは常にグローバルAWSバックボーンにとどまり、パブリックなインターネットを横断することは無く、一般的な悪用であったりDDoS攻撃のような脅威を減らすことができます。 インターリージョンVPCピアリングコネクションによって転送されたデータのコストは、インターリージョン間の通常のデータ転送費用となります。 インターリージョンVPCピアリングはAWSの米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、欧州（アイルランド）にて利用可能です。他のリージョンについても、まもなく予定しています。 さらなる情報については、Amazon VPC Peeringのドキュメントをご参照下さい。   翻訳はSA益子が担当しました。 原文：こちら

T2インスタンスについての最初の投稿は2014年の夏でした。そこでは、多くのワークロードは継続的なCPUパワーに対する需要は控えめであり、かなり多くのCPUパワーを必要とするのは時々であるとお話しました。このモデルはお客様と共鳴しました。T2インスタンスは非常に普及しており、マイクロサービス、低レイテンシーの対話型アプリケーション、仮想デスクトップ、ビルド＆ステージング環境、プロトタイプなどをホストするために利用されています。   新しいT2 Unlmitedインスタンス 本日（日本時間2017年11月30日）、AmazonはT２インスタンスで開拓したバーストモデルを拡張し、コストを可能な限り低く抑えながら、任意の時間枠で高いCPUパフォーマンスを維持する能力を提供します。インスタンスを起動する際に、この機能を有効にするだけです。すでに実行中のインスタンスに対しても、有効にすることができます。時間あたりのT2インスタンスの価格は、平均CPU使用率が24時間のウィンドウにおけるベースラインよりも低い場合には、すべての瞬間的なスパイクをカバーします。長期間に渡って高いCPU使用率でインスタンスが稼働する場合には、少額の時間課金が発生します。例えば、t2.microインスタンスを平均CPU使用率15%（ベースラインに比べ5%高い）で24時間動かすと、追加で6セントが課金されます（vCPU時間あたり5セント * 1 vCPU * 5% * 24時間）。