Amazon Web Services ブログ

AWS カナダ (中部) リージョンが利用可能に

当社は AWS の拡大を再開しました。新しい Canada (Central) リージョンが利用可能になり、今すぐ使い始めることができます。カナダおよび米国北部で AWS をご利用のお客様は、AWS インフラストラクチャサービスのスイートに低レイテンシーで迅速にアクセスできるようになります。

詳細
新しい Canada (Central) リージョンは、Amazon Elastic Compute Cloud (EC2) に加えて Amazon Elastic Block Store (EBS)Amazon Virtual Private CloudAuto ScalingElastic Load BalancingNAT ゲートウェイスポットインスタンスDedicated Host などの関連サービスをサポートします。また、Amazon AuroraAWS Certificate Manager (ACM)AWS CloudFormationAmazon CloudFrontAWS CloudHSMAWS CloudTrailAmazon CloudWatchAWS CodeDeployAWS ConfigAWS Database Migration ServiceAWS Direct ConnectAmazon DynamoDBAmazon ECSAmazon EC2 Container RegistryAWS Elastic BeanstalkAmazon EMRAmazon ElastiCacheAmazon GlacierAWS Identity and Access Management (IAM)AWS Import/Export SnowballAWS Key Management Service (KMS)Amazon KinesisAWS MarketplaceAmazon RedshiftAmazon Relational Database Service (RDS)Amazon Route 53AWS Shield Standard、Amazon Simple Storage Service (S3)Amazon Simple Notification Service (SNS)Amazon Simple Queue Service (SQS)Amazon Simple Workflow Service (SWF)AWS Storage GatewayAWS Trusted AdvisorVM Import/ExportAWS WAF もサポートします。カナダリージョンは、C4D2M4T2、および X1 のインスタンスをすべてのサイズでサポートします。環境に優しい方法でクラウドコンピューティングをお客様に対して利用可能にする当社の継続的な取り組みの一環として、カナダの AWS データセンターは、電気の 99% を水力発電で賄う送電網から電力の供給を受けています (詳細については、「AWS と持続可能性」を参照してください)。

すぐれた接続
オハイオで AWS リージョンを開始したときに私がお知らせした、ネットワークレイテンシーのメトリクスに関して多くの好意的なご意見ご感想をいただきました。そこで、本日の発表の一部として、新しいメトリクスのセットを用意しました (これらの時間はレイテンシーの下限を表しており、時間とともに変化する可能性があります)。最初のメトリクスのセットは、カナダのその他の各都市に対するものです。

  • トロントに対して 9 ms。
  • オタワに対して 14 ms。
  • カルガリーに対して 47 ms。
  • エドモントンに対して 49 ms。
  • バンクーバーに対して 60 ms。

2 番目のセットは米国の各都市に対するメトリクスです。

  • ニューヨークに対して 9 ms。
  • シカゴに対して 19 ms。
  • US East (Northern Virginia) に対して 16 ms。
  • US East (Ohio) に対して 27 ms。
  • US West (Oregon) に対して 75 ms。

カナダは、オンタリオ州トロントおよびケベック州モントリオールの CloudFront エッジロケーションの本拠でもあります。

カナダで 15 番目
本日の発表により、当社は世界各地の 15 のリージョンと 40 のアベイラビリティーゾーンに拡大し、さらに 7 つのアベイラビリティーゾーンと 3 つのリージョンが、来年中にオンラインになる予定です。繰り返しになりますが、各リージョンは、複数のアベイラビリティーゾーン (AZ) で構成される物理的な場所を指します。各アベイラビリティーゾーンは、1 つ以上のデータセンターで構成されます。各データセンターは、冗長性のある電源、ネットワーキング、および接続を備えており、それぞれが別々の設備に収容されます。各リージョンに複数の AZ を設けることで、AZ が 1 つだけの場合よりも、実行するアプリケーションの可用性、耐障害性、耐久性を強化できます。

現在および将来の AWS リージョンの詳細については、AWS グローバルインフラストラクチャのページを参照してください。

Jeff;

IoTコンピテンシーの紹介

IoTコンピテンシーの紹介

あなたはお客様に革新的なIntenet of Things(IoT)を提供、手助けができるAPNパートナーでしょうか?
あなたの会社は、AWSでIoTアプリケーションを構築しようとしている企業顧客にサービスを提供することに重点を置いていますか?

IoTにおけるAPNパートナーの機会は莫大です。 IDCは、Internet of Things(IoT)の世界市場は、2015年の6,926億ドルから2020年には1兆4600億ドルに成長し、年間成長率(CAGR)は16.1%になると予測しています。
インストール済みIoT基盤は、2015年の121億人から2020年には300億人以上に増加することが予測され。[1]
AWS上で革新的なIoTアプリケーションを構築しようとする世界中のお客様がますます増えています。私たちの目標は、ビジネス目標を達成するのに役立つ顧客とのつながりを支援することです。

AWSコンピテンシープログラムは、お客様が特定のビジネスのニーズにミートした正しいAPNパートナーを探し出すのに役立ちます。re:Invent内で開催されているAWS グローバルパートナーサミットにおいて、2つの新しいAWSコンピテンシーの1つAWS IoTコンピテンシーについて 発表致します。

AWS IoTコンピテンシーの発表
AWS IoTコンピテンシーは、コンサルティング/テクノロジーパートナーが スマートファクトリー、スマートシティ、エネルギー、自動運転、ヘルスケア(これらに限らず)を含む様々なユースケースに技術の提供 かつ/もしくは 開発の能力があることを示します。

IoT_banner_493x260

AWS IoTコンピテンシーを取得するには、公開事例の提供や第三者の監査を完了させるなど幾つもの要求を満たす必要があります。我々はAWS上でのIoTソリューション/成熟度を示し、お客様がIoTパートナーを特定しコンタクするためにIoTコンピテンシー取得に際して高いバーを設定しました。
要求事項についてはこちらをクリック

AWS IoTコンピテンシーパートナーは、次のようなビジネス、技術、およびマーケティングのさまざまなメリットを得る資格を得ます。

・IoTコンピテンシーのロゴをマーケティング資料に使用できる
・AWS IoTコンピテンシーパートナーとしてのAWS Webサイトで公認
・AWS partner solution finderでAWS IoTコンピテンシーパートナーとしての指定
・マーケット開拓のためのファンド提供
・AWSコンピテンシーとAWSに関するIoTに関する将来のAWS発表に含める際の優位性
・APNパートナーのスポットライト(引用、お客様の声、ビデオなど)に含める際の優位性
・ウェブセミナー、ロードショー、イベントのAWSコンピテンシーに関する情報開示の優位性

IoTカテゴリとローンチパートナー
以下にカテゴリ毎にIoTパートナーをご紹介します。おめでとうございます。

エッヂ(Edge):IoTデバイスを構築するために使用されるハードウェアおよびソフトウェア、またはIoTソリューションまたはアプリケーションで使用される完成品を提供するパートナー。
例として、センサー、マイクロプロセッサ、マイクロコントローラ、オペレーションシステム、セキュア通信モジュールや評価/デモキットなどとなります。
・Intel
・Microchip Technology

ゲートウェイ(Gateway):クラウドにエッジデバイスを接続するデータアグリゲーションハードウェアおよび/またはソフトウェアを提供し、エンタープライズITシステムに接続するだけでなく、前段でインテリジェンスを提供するパートナー。
例として、ハードウェアゲートウェイ、プロトコルを変換するソフトウェアコンポーネント、ローカルでの意思決定をサポートするためにオンプレミスプラットフォームなどとなります。
・MachineShop

プラットフォームプロバイダ(Platform Provider):ISVが開発したクラウドベース 収集/解析/行動/IoTデータの活用 のプラットフォーム
例として、デバイス管理システム、可視化ツール、メンテナンス予測、データ解析、機械学習などとなります
・Bsquare Corporation
・C3 IoT
・Splunk
・PTC
・Thinglogix

接続性(Connectivity):エッヂとgatewayを接続するための広域接続
例として、デバイスや登録の管理プラットフォーム、課金システム、デバイスプロビジョニングシステム、モバイルネットワーク(MNOs)や仮想モバイルネットワーク(MVNOs)提供者などとなります
・Amdocs, Inc.
・Asavie
・Eseye
・SORACOM(ソラコム)

コンサルティング AWS IoTコンピテンシーは以下となります。おめでとうございます。
・Accenture
・Aricent
・Cloud Technology Partners
・Luxoft
・Mobiquity, Inc.
・Solstice
・Sturdy
・Trek10

もっと知るには
2つのIoTコンピテンシーローンチパートナーの声をお聞き下さい。C3 IoTとMachineShopがなぜAWSと一緒にやることにしたのか、そしてお客様にとってのIoTコンピテンシーの価値について

C3 IoT

MachineShop

その他IoTソリューションについてはこちら

[1] “Worldwide Internet of Things Forecast Update, 2016-2020”, IDC Market Forecast, May 2016. https://www.idc.com/getdoc.jsp?containerId=US40755516

Kate Miller (翻訳はパートナーSA小梁川が担当しました。本文はこちら

AWS LambdaのC#サポートの発表

本日、AWS Lambdaのサポート言語としてC#を発表しました。新しいオープンソースの.NET Core 1.0ランタイムを使用すると、さまざまな一般的な.NETツールからC#コードをAWS Lambdaに簡単に公開できます。 .NET開発者は、C#言語と使い慣れた.NETツールを使用して、Lambda関数とサーバーレス アプリケーションを作成できます。 Visual Studio、Yeoman、およびdotnet CLIにおけるツール サポートによって、C#で記述された個々のLambda関数またはサーバーレスアプリケーション全体をLambdaおよび Amazon API Gatewayに簡単に展開できます。

LambdaAWSサーバーレスプラットフォームの中核です。もともと2015年に発売されたLambdaでは、インフラストラクチャやスケーリングを心配することなく、Node.jsPython、およびJavaコードをAWSに展開することができます。これにより、開発者はアプリケーションのビジネスロジックに集中でき、インフラストラクチャの維持と拡張に時間を費やす必要がありません。今日まで、.NET開発者はこのモデルを利用することができませんでした。サポートされている言語のリストにC#を追加し、サーバーレスアプリケーションを作成すためにLambdaAPIゲートウェイを利用する新しいカテゴリの開発者ができたことを嬉しく思っています。

 

C#でのLambda

単純なC#ラムダ関数を見てください。 既にNode.js、Python、JavaでLambdaを使っていたなら、これはよく分かるはずです:

using System;
using System.IO;
using System.Text;

using Amazon.Lambda.Core;
using Amazon.Lambda.DynamoDBEvents;
using Amazon.Lambda.Serialization.Json;

namespace DynamoDBStreams
{
    public class DdbSample
    {
        private static readonly JsonSerializer _jsonSerializer = new JsonSerializer();

        [LambdaSerializer(typeof(JsonSerializer))]
        public void ProcessDynamoEvent(DynamoDBEvent dynamoEvent)
        {
            Console.WriteLine($"Beginning to process {dynamoEvent.Records.Count} records...");

            foreach (var record in dynamoEvent.Records)
            {
                Console.WriteLine($"Event ID: {record.EventID}");
                Console.WriteLine($"Event Name: {record.EventName}");

                string streamRecordJson = SerializeObject(record.Dynamodb);
                Console.WriteLine($"DynamoDB Record:");
                Console.WriteLine(streamRecordJson);
            }

            Console.WriteLine("Stream processing complete.");
        }


        private string SerializeObject(object streamRecord)
        {
            using (var ms = new MemoryStream())
            {
                _jsonSerializer.Serialize(streamRecord, ms);
                return Encoding.UTF8.GetString(ms.ToArray());
            }
        }
    }
}

Lambdaでサポートされている他の言語と同様に、関数の入力と戻り値の型を扱うための選択肢がいくつかあります。最も基本的な選択は、System.IO.Streamの低レベルストリームインタフェースを使用することです。また、アプリケーションのアセンブリレベルまたはメソッドレベルでデフォルトのシリアライザを適用することも、Amazon.Lambda.Coreライブラリによって提供されるILambdaSerializerインターフェイスを実装することによって独自のシリアライゼーションロジックを定義することもできます。

ProcessDynamoEvent関数の関数シグネチャを見て、シグネチャ内のDynamoDBEventに注意してください。これは、Lambdaが提供するAmazon.Lambda.Coreライブラリと、他のAWSイベントタイプのためのさらに多くのクラスから来ています。このNuGetパッケージにプロジェクトの依存関係を追加すると、staticLambdaロガー、シリアライゼーション インターフェイス、およびLambdaコンテキストオブジェクトのC#実装にアクセスできます。

ロギングでは、C#Consoleクラス、Amazon.Lambda.Core.LambdaLoggerクラスのLogメソッド、またはコンテキストオブジェクトのLoggerプロパティによって提供される静的なWriteメソッドまたはWriteLineメソッドを使用できます。 C#プログラミングモデルの詳細については、「AWS Lambda開発者ガイド」を参照してください。

 

AWS Toolkit for Visual Studio

AWS Toolki for Visual Studio は、.NET Core Lambda関数とサーバーレスアプリケーションの開発、テスト、および展開をサポートします。 このツールキットには、容易に開発を始めるために、次の2つの新しいプロジェクトテンプレートが用意されています: AWS Lambda Projectテンプレートは、単一のCLambda関数を持つ単純なプロジェクトを作成します。 AWS Serverlessアプリケーションテンプレートは、AWS Serverless Application ModelAWS SAM)に従って、小さなAWSサーバーレスアプリケーションを作成します。 このテンプレートは、API GatewayRESTエンドポイントを介して公開された複数のラムダ関数で構成された完全なサーバーレスアプリケーションを開発する方法を示しています。 また、AWS SAMでは、アプリケーションがプロジェクトのテンプレートの一部として使用するAWSリソースをモデル化できます。

コードが準備できたら、プロジェクトを右クリックし、ソリューションエクスプローラで[Publish to AWS Lambda…]を選択してVisual Studioから直接展開できます。 そこから、デプロイメント・ウィザードがデプロイメント・プロセスをガイドします。

 

.NET Core CLIを使用したクロスプラットフォーム開発

.NET Coreの優れた機能の1つは、クロスプラットフォームのサポートです。 従来の.NETフレームワークでは、開発者はWindows上でアプリケーションを構築して実行する必要があります。 ただし、.NET Coreを使用すると、任意のプラットフォームでC#コードを開発し、任意のプラットフォームに展開することができます。Windowsで開発しておらず、AWS Toolkit for Visual Studioにアクセスできない場合でも、.NETツールを使用してCLambda関数とサーバーレスアプリケーションをAWSに簡単に公開できます。 AWS Toolkit for Visual Studioを使用していても、dotnet CLIの使い方を知ることは、ビルドとデプロイメントプロセスの自動化に役立ちます。.NET Coreプロジェクトを作成したら、Yeomanのようなツールを使用してdotnet CLILambdaツールを有効にします。 Amazon.Lambda.ToolsNuGetパッケージに依存するツールを新しいプロジェクトに追加するだけです。

Amazon.Lambda.Tools NuGetパッケージは、新しいdotnet CLIにコマンドを追加します。これにより、使用しているプラットフォームに関係なく、Lambda関数とサーバレスアプリケーションをAWSにデプロイできます。 Windows上のVisual Studioで開発している場合でも、dotnet CLIAWS Lambdaツールは、アプリケーションのCI / CDパイプラインを設定するのに役立ちます。dotnet CLIの新しいラムダコマンドの詳細については、プロジェクトディレクトリに「dotnet lambda help」と入力してください。

 

まとめ

我々は、.NET Core ランタイムを通してC#アプリケーションに対してAWS Lambdaを利用可能にすることに興奮しています。 C#Lambda関数の作成に関する詳細は、「AWS Lambda開発者ガイド」を参照してください。 AWS Toolkit for Visual Studioをダウンロードして開始するか、dotnet CLIのLambda拡張を確認してください。

 

原文: Announcing C# Support for AWS Lambda (翻訳: SA福井)

Amazon AppStream 2.0 – AWSからデスクトップアプリをストリーミング

私の同僚であるGene FarrellがオリジナルバージョンのAmazon AppStreamがお客様のフィードバックをもとにしていかに進化したかについてゲスト投稿を書きました。

Jeff;


AWSでは、お客様の問題を解決することを手助けしテクノロジーによってお客様にサービスを提供するのが私たちのミッションです。それが私たちに考えることをうながし、私たちがイノベーションを実現する方法の中心となっています。私たちのお客様はAWSのサービスを使用して次世代のモバイルアプリを構築し、快適なWebエクスペリエンスを作成し、そしてコアのITワークロードをグローバルスケールで実行しています。

モバイル、Web、そしてコアITにおけるイノベーションとトランスフォーメーションにはめざましいものがありますが、デスクトップとデスクトップアプリケーションについてはほとんど変化がありませんでした。エンドユーザーはどこでどのように仕事をするのかの自由をまだ享受できていません。ITは、デスクトップ、アプリケーション、そして無数のデバイスを管理するための堅牢で高価なシステムに悩まされています。そして企業情報をセキュアにすることはますますむずかしくなっています。おおくのやり方でクラウドはITのこの側面を迂回しているようです。

私たちのお客様はそれを変えたいと思っています。 モバイル、Web、およびコアITで見られるように、デスクトップとアプリケーションの柔軟性、スケール、セキュリティ、パフォーマンス、そしてコストのメリットが求められます。 たった2年以上前に、私たちはフルマネージドのセキュアなクラウドデスクトップサービスであるAmazon WorkSpacesを発表し、AWS上で永続的なデスクトップを提供しています。 本日、私はデスクトップアプリケーションをWebブラウザに配信するためのフルマネージドでセキュアなアプリケーションストリーミングサービスであるAmazon AppStream 2.0を紹介することにワクワクしています。

お客様は、さまざまなプラットフォームで動作することを必要としている従来のデスクトップアプリケーションがたくさんあると言っていました。 これらのアプリケーションの保守は複雑で高価であり、お客様はよりよいソリューションを求めています。 AppStream 2.0によって、任意のデバイス上のWebブラウザを使用することで、AWSからのストリーミングによってデスクトップアプリケーションへのインスタンスアクセスを提供することができます。 クラウドのためにアプリケーションを書き直す必要はなく、ひとつのバージョンをメンテナンスするだけですみます。 アプリケーションとデータはAWS上でセキュアにたもたれ、アプリケーションストリームはエンドツーエンドで暗号化されます。

オリジナルのAppStreamをふりかえって
AppStream 2.0の詳細について説明する前に、オリジナルのAmazon AppStreamサービスの歴史についてみる価値があります。 2013年に私たちはAppStreamをSDKベースのサービスとしてローンチし、お客様はデスクトップアプリケーションのストリーミング体験を構築してこれらのアプリケーションをクラウドに移行することができるようになりました。 私たちはSDKによるアプローチがお客様がアプリケーションストリーミングを自分たちの製品に統合できるようにすると考えていました。 私たちは、ゲーム開発者やグラフィックスISVがこの開発モデルを採用するだろうと考えていましたが、予想していたより多くの作業が必要であり、つかいはじめるためには重要なエンジニアリングへの投資が要求されることがわかりました。それを試した人たちはその機能セットが自分たちのニーズを満たしていないことに気づきました。 たとえば、AppStreamはg2.2xlarge EC2インスタンスをベースとしたひとつインスタンスタイプだけを提供していました。 これによって、パフォーマンスがコストを正当化できるハイエンドなアプリケーションへのサービスのみに限定されました。 しかし、経済性は多くのアプリケーションにとって割に合わないものでした。

AppStreamで、お客様の重要な問題を解決するために取り組んでいましたが、解決策を正しく得ることに失敗しました。 これは、アマゾンではあえて受け入れるリスクです。 われわれは迅速に動き、お客様を手助けすることができる分野を探求していますが、失敗の準備をします。 私たちは失敗するときに学習し、すばやく反復します。 この場合、お客様からデスクトップアプリケーションのためのよりよいソリューションが必要であることを継続的にヒアリングし、そしてふりだしに戻りました。 その結果がAppStream 2.0です。

AppStream 2.0の特長
AppStream 2.0では、オリジナルのAppStreamサービスを試していだいたお客様から聞いた課題の多くに対応しています。 こちらがにいくつかの特長です:

  • デスクトップアプリケーションをセキュアにWindowsおよびLinux PC、Mac、Chromebook上のHTML5ウェブブラウザでどのデバイスでも実行できます。
  • ユーザーがどこからでもデスクトップアプリケーションに即座にアクセスできます。遅延はなく、大きなファイルをダウンロードすることもなく、時間のかかるインストールもありません。ユーザーは、ネイティブにインストールされたアプリを実行するのと同じように、敏感で流動的なエクスペリエンスを得ることができます。
  • シンプルなエンドユーザーインターフェイスで、ユーザーはフルスクリーンモードで実行し、ブラウザタブ内で複数のアプリケーションを開き、簡単にスイッチして操作することができます。ファイルをセッションにアップロードし、アクセスして編集し、完了したらダウンロードすることができます。また、印刷や、音声の再生、そしてネットワークの状態に最適化するために帯域幅を調整することもできます。
  • アプリケーションとデータをセキュアにAWS上に保持 – 暗号化されたピクセルのみがエンドユーザーにストリーミングされます。アプリケーションストリームとユーザー入力は、HTTPS経由でAWS上のセキュアなストリーミングゲートウェイを通過するため、ファイアウォールと親和性が高いものになります。自身のVirual Private Cloud(VPC)内でアプリケーションを実行でき、Amazon VPCのセキュリティ機能を使用してアクセスを制御できます。 AppStream 2.0は、ユーザーが自社の認証情報を使用してアプリケーションにアクセスできるようにするIDフェデレーションをサポートしています。
  • フルマネージドなサービスのため、アプリケーションストリーミングインフラストラクチャを計画、デプロイ、管理、およびアップグレードする必要はありません。 AppStream 2.0は、アプリケーションのホストおよび実行に必要なAWSリソースを管理し、自動的にスケールし、必要に応じてエンドユーザへのアクセスを提供します。
  • 一貫したスケーラブルなパフォーマンスをAWSで、一般的にローカルデバイスでは利用できないコンピューティング能力にアクセスすることができます。ローカルおよびグローバルに即座にスケールし、ユーザーが低レイテンシーのエクスペリエンスをつねに得られることを保証します。
  • さまざまなストリーミングインスタンスタイプでアプリケーションを実行します。 General Purpose、Compute Optimized、およびMemory Optimizedインスタンスファミリーのインスタンスタイプを使用して、アプリケーションのパフォーマンスを最適化し、全体のコストを削減することができます。
  • ハイパフォーマンスなストリーミングのためのNICE DCVは、アプリケーションにセキュアでハイパフォーマンスなアクセスを提供します。 NICE DCVは流動的でインタラクティブな体験を提供し、ネットワークの状態に自動的に適応します。

価格と利用可能なリージョン
AppStream 2.0では、使用するストリーミングインスタンスに対してのみ料金を支払います。 ストリーミングインスタンスの料金は、選択したインスタンスの種類、およびアプリケーションにアクセスする同時ユーザーの最大数によります。

特定の月にリージョン内のアプリケーションにアクセスするユニークな認可されたユーザーごとにユーザーフィーが課金されます。 ユーザーフィーはMicrosoft RDS SALライセンスをカバーしており、MicrosoftのライセンスモビリティプログラムによってRDS CALライセンスを持ち込むする場合は免除されます。 AppStream 2.0には、つかいはじめるための管理者体験を提供する無料利用枠があります。 無料利用枠には、最長2ヶ月間、月40時間が含まれます。 詳細については、こちらのページを参照してください。

AppStream 2.0は、米国東部(北バージニア)、米国西部(オレゴン)、ヨーロッパ(アイルランド)、および東京リージョンで利用可能です。 AppStream 2.0に既にインストールされているサンプルアプリケーションにアクセスすることで、今すぐに無料でAppStream 2.0のエンドユーザエクスペリエンスを試すことができます。Try It Nowにアクセスするには、AWSアカウントでログインし、Get Startedを選択してください。

AppStream 2.0,についてもっとよく知るには、AppStream pageにアクセスしてください。

Gene Farrell, Vice President, AWS Enterprise Applications & EC2 Windows

(日本語訳はSA渡邉が担当しました。原文はAmazon AppStream 2.0 – Stream Desktop Apps from AWS

新機能 – Virtual Private Cloud での EC2 インスタンスの IPv6 サポート

インターネットは、特にモバイルアプリケーション、コネクテッドデバイス、そしてIoTの分野で引き続き成長しており、それが業界全体のIPv6への移行に拍車をかけています。米国政府機関は2010年に定められた指令に従って、パブリックに公開されたサーバーとサービスをできるだけすみやかにIPv6に移行するように取り組んでいます。128ビットのアドレス空間を持つIPv6では十分な拡張の余地があり、新しいアプリケーションやユースケースへの道が開かれます。

EC2のIPv6

今年の初めに、S3 (Transfer Accelerationを含む)、CloudFrontWAF、および Route 53のIPv6サポートを開始しました。本日、新しい大きなステップとして、Virtual Private Cloud (VPC) およびEC2インスタンスのIPv6サポートを開始しました。米国東部 (オハイオ) リージョンを皮切りに、他のリージョンも対応を進めていきます。

IPv6サポートは、新規および既存のVPCで利用できます。マネジメントコンソール上でチェックボックスにチェックを入れるだけで、VPCごとにオプトインすることができます (APIとCLIもサポートされます)。

(more…)

AWS Shield – DDoS攻撃からアプリケーションを保護

オンラインの世界は時として不愉快な場所です!あなたがウェブサイトを公開するや否や、問題を起こしたり、サイトを停止させようとする多くの種類の攻撃の標的にされます。DDoS (分散型サービス妨害) 攻撃は非常に一般的な問題の一つです。攻撃者はウェブ上のあらゆる侵害されたリソースを利用し、活動を特定の標的に集中させます。

DDoS攻撃には一般的に3つの種類があります。

アプリケーション層攻撃 はアプリケーションのリソースを消費するように設計された、整形式かつ悪意のあるリクエスト(HTTP GETやDNSクエリが一般的)からなります。たとえば複数のHTTP接続を開き、数秒または数分かけてレスポンスを読むことで、過剰にメモリが消費され、正当なリクエストが処理されなくなります。

State-Exhaustion 攻撃 はステートフルなプロトコルを悪用し、一接続当たりに多くのリソースを消費させることでファイヤーウォールや負荷分散装置に負荷を与えます。

ボリューム攻撃 は対処しきれないほどの大量なトラフィックを送りつけたり、無防備な被害者に驚くほど大量の低レベル”surprise”応答を送りつける偽クエリを発行(別名:リフレクション攻撃)させて、ネットワークを不通にします。

新サービス – AWS Shield

AWS Shieldは新しいマネージドサービスで、ウェブアプリケーションをDDoS (分散型サービス妨害) 攻撃から保護します。Elastic Load BalancingAmazon CloudFrontAmazon Route 53と連携して動作し、様々なタイプ、形状、サイズの攻撃からお客様を保護します。このサービスには二つのTierがあります。

AWS Shield Standard は追加費用なしで、すべてのAWS顧客が利用できます。 SYN/ACK フラッド、リフレクション攻撃、HTTPスローリードなど、今日最も一般的な攻撃の96%からお客様を守ります。 この保護は、Elastic Load Balancer、CloudFrontディストリビューション、Route 53リソースに自動的かつ透過的に適用されます。

AWS Shield Advanced は、ボリューム攻撃に対する追加のDDoS軽減機能、インテリジェントな攻撃検出、アプリケーションおよびネットワーク層での攻撃に対する軽減を提供します。 攻撃の軽減のカスタマイズ、高度なリアルタイムメトリクスとレポート、DDoS攻撃の影響で請求金額が跳ね上がるのを防ぐDDoSコスト保護のために、私たちのDDoSレスポンスチーム(DRT)に24時間365日アクセスできます。

詳しくは、AWS Shield もしくは Get Started with AWS Shield Advanced をご参照ください。

原文:AWS Shield – Protect your Applications from DDoS Attacks (翻訳:Security Solutions Architect 桐山 隼人)

AWS Step Functions – ビジュアルワークフローを使ったアプリケーションのビルドと配布

私たちは、ビルドの複雑性や配布されたアプリケーションを、多数のWebアプリやマイクロサービスの連携によってより簡易にしたいと考えています。あなたが複雑なビジネスプロセスを構築しているか写真のアップロードのプロセスをセットアップしているかに関わらず、あなたはコーディネーションではなくコードにフォーカスしてほしいと、私たちは思っています。また、あなたがツールやライブラリに既に明るくなっていてそれらを使うことで、可用性の高いアプリケーション、つまり強固であり、スケーラブルであり、コスト優位性があり、を構築できるようになってほしいと思っています。

 

AWS Step Functionsの概要

まさに上記に述べたことを実現していただくために、本日私たちはAWS Step Functionをリリースしました。これにより、あなたは、ビジュアルなワークフローにて、アプリケーションのコンポーネントを一連のステップとしてコーディネートすることが出来ます。あなたは、アプリケーション実行のスケール時にステップの特定や実行をするために”Step Function Console”により、”state machine”(マシン状態)を生成します。どのstate machineも”tate”のセットとそれらのトランザクションを定義します。”state”は直列や並列でアクティベートされることが可能です。並列のときは、Step Functionは、次に進む前に、全てのパラレルstateが完了に向けて実行されます。その結果、Statsは実行し、判断し、state machineを通してプロセスの進捗をコントロールします。

この図はstate machineの概要です。

 

 

複数のそれらのstate machineのコピーは、同時に独立して実行させることが可能です。そのとき、どのコピーも1つの実行と呼ばれます。このようにして、Step Functionsにより数千の同時実行もさせるこが出来るため、どのような要求レベルであってもスケールさせることが可能です。

stateが実行されたときに何を起こさせるかを指定するために2つの方法があります。1つは、stateが実行されたときに同期的に呼び出されるLambda関数を使う方法です。もう1つは、Activityと呼ばれるものを使う方法です。これは、長時間実行ワーカー関数の参照実装です。この参照実装では、APIを使ってworkの完了をポーリングします。どちらの方法でも、コードはインプットとしてJSON形式で、またアウトプット形式は別の型のJSON形式が期待されます。

state machineの機能として、エラーハンドリング時の挙動やリトライロジックを組み込むことが出来ます。これにより、あなたのコードの一部の問題により一時的な問題発生が起こったとしてもスムーズに実行できる、強固なアプリケーションをビルドできることになります。

 

クイックツアー

それでは、AWS Management Consoleを使ってstate machineをセットアップしてみましょう。本番のアプリケーションでは、ほとんどの場合、実行やstate machine生成にAWS Step FunctionのAPIを使うことにご留意ください。

まずシンプルなLambda関数を生成して保存します。

 

その間に、functionのARNを記録しておきます。

 

そしてAWS Step Functions Consoleに行き、「 Create a State Machine」ボタンを押します。マシン名(ここでは「MyStateMachine」) を入力し、実行開始のためにblueprintsから1つを選んでクリックします。

 

ここでは、MyStateMachineにこのJSONモデルを生成するためのParallelエレメントとHello Worldを使って開始します。

{
  "Comment": "A simple example of the Steps language using an AWS Lambda Function",
  "StartAt": "Hello",

  "States": {
    "Hello": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:eu-west-1:99999999999:function:HelloWord_Step",
      "Next": "Parallel"
    },

    "Parallel": {
      "Type": "Parallel",
      "Next": "Goodbye",
      "Branches": [
        {
          "StartAt": "p1",
          "States": {
            "p1": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:eu-west-1:9999999999:function:HelloWord_Step",
              "End": true
            }
          }
        },

        {
          "StartAt": "p2",
          "States": {
            "p2": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:eu-west-1:99999999999:function:HelloWord_Step",
              "End": true
            }
          }
        }
      ]
    },

    "Goodbye": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:eu-west-1:99999999999:function:HelloWord_Step",
      "End": true
    }
  }
}

 

グラフィカルに確認するために”Preview”ボタンを押します。

 

次に、自分のために適切に生成された、Step FunctionのIAMロールを選択します。

 

これで全てです!これで、コンソールから生成したstate machineを実行できます。つまり、最初のLambda関数をパスするJSONブロックで実行させることが出来ます。

 

Start Exctionボタンを押すとすぐに、定義したstate machineは実行するために開始します。state間を遷移する実行フローを確認することが出来ます。

 

また、Lamdaコンソールに行き、自分の関数の実行が期待どおり4回であることを確認できます。(事前に4回のクリックと、別々の4つのLambda関数の生成は苦に思わないとして)

 

AWS Step Functionsは、どのステップに関する全ての情報を記録しており、Step Consoleを使って確認することが出来ます。

 

AWS Step Functions API

前述のとおり、ほとんどのAWS Step Functions操作はAPIを通じて行われると思いますので、ここに、基本的な関数の概要を記載します。

  • CreateStateMachine – JSON定義による新規state machineの生成
  • ListStateMachines – state machineの一覧表示
  • StartExecution – (非同期な)state machineの実行
  • DescribeExecution – 実行に関する情報取得
  • GetActivityTask – 実行のための、新taskのポーリング(長時間実行ワーカーによる)

また、S3バケットにファイルがアップロードされるたびにLambda関数が実行されるようにすることもできました。

この関数は、StartExecutionを使ってstate machineをキックでき可能です。たとえばこのstate machineはイメージファイルの検査をしたり、複数のサイズ生成を並列的に実行したり、特定のタイプをチェックしたり、Databaseをアップデートさせたりすることが可能です。

同様の機能は、AWS Command Line Interface(CLI)によっても可能です。

 

開発ツール

手書きもしくは自動生成のJSON、それは共通エラーチェックやをチェックするために、新しい、statelint gemを使うことが出来ます。

AWS GitHub repoからダウンロードしインストールしてみてください。(Rubyの場合は、RubyGems

$ sudo gem install j2119-0.1.0.gem statelint-0.1.0.gem

以下は、もし問題があった場合の表示です。

$ statelint my_state.json
2 errors:
State Machine.States.Goodbye does not have required field "Next"
No terminal state found in machine at State Machine.States

問題ない場合は、以下のようになります。

$ statelint my_state.json
$

 

利用可能です

AWS Step Functionsは利用可能です。現在、US East (Northern Virginia)、US East (Ohio)、US West (Oregon)、EU (Ireland)、Asia Pacific (Tokyo) のリージョンで利用可能です。

AWS Free Tierの一部として、月間4,000までのstate transitionは無料です。それ以降は1,000state transtionにつき0.025USD課金されます。

 

Jeff;

原文:New – AWS Step Functions – Build Distributed Applications Using Visual Workflows(翻訳:市崎 洋平)

Lambda@Edge – プレビュー

ちょうど先週、私が Hacker News上で書いたコメントがきっかけでAWSのお客様から興味深いメールを頂きました。

彼はS3上でホストしているシングルページのアプリケーションを動作させていて(こちらについてはAmazon S3で静的なWebサイトの運用が可能に をご覧下さい。)、Amazon CloudFrontを経由して少ないレイテンシーで提供していると教えてくれました。そのページは、AWS Elastic Beanstalk上でホストしているAPIを使って、それぞれのユーザー向けにカスタマイズして表示するいくつかの動的な要素を含みます。

彼が説明してくれた彼の課題はこちらです。

適切に検索エンジンのインデックスを取得するために、またFacebookやTwitterないで正しく表示するためのコンテンツのプレビューをするためには、それぞれのページが事前に表示されたバージョンを提供する必要があります。こちらを実現するには、一般ユーザーがヒットするたびに、私たちのサイトはノーマルのフロントエンドをCloudFrontから提供する必要があります。しかし、もしユーザーエージェントがGoogle / Facebook / Twitter等にマッチする場合は、その代りに私たちは事前に表示されたバージョンへリダイレクトさせる必要があります。

私たちはこのユースケースについてよく分かっており、興味深いソリューションを準備中であることを彼に秘密を漏らすことなく伝えました。他のお客様もまた、エッジにおいてクイックな判定によりカスタマイズしたいと伝えてくれてました。

お客様に近いロケーションでHTTPリクエストを”賢く”処理しなければならないユースケースがあることがわかりました。これらには、HTTPヘッダの検査および変更、アクセスコントロール(特定のcookieを必要とする)、デバイス検出、A/Bテスト、クローラーまたはbotsのための処理または特別な対応、レガシーシステムに適応させるためにユーザーフレンドリーなURLを書き換えるユースケースを含みます。多くのこれらのユースケースは、シンプルなパターンマッチングやルールによって表現可能なユースケースよりも多くの処理や判定を必要とします。

Lambda@Edge
これらのユースケースのサポートを提供するために、私はLambda@Edgeのプレビューをラウンチしています。この新しいLambdaベースの処理モデルにより、ますます増加するAWSエッジロケーションのネットワーク内で動作するJavaScriptコードを書くことが出来ます。

CloudFrontのディストリビューションを通して流れるリクエストやレスポンスを処理する軽量なロジックを書くことができます。4つの異なるイベントに対するレスポンスの中でコードを実行できます。

Viewer リクエスト – あなたのコードは、コンテンツがキャッシュされるか否かに関わらず、あらゆるリクエストにおいて動作します。こちらがシンプルなヘッダ処理用のコードです。

exports.viewer_request_handler = function(event, context) {
  var headers = event.Records[0].cf.request.headers;
  for (var header in headers) {
    headers["X-".concat(header)] = headers[header];
  }
  context.succeed(event.Records[0].cf.request);
}

Origin リクエスト – リクエストされたコンテンツがエッジでキャッシュされていない時に、Originに転送される前にコードを実行します。ヘッダを追加したり、既存のヘッダを編集したり、URLを編集したりすることが可能です。

Viewer レスポンス – キャッシュされているか否かに関わらず、すべてのレスポンスにおいてコードを実行します。Viewerに戻す必要のないヘッダをクリーンアップするためにこちらを利用できます。

Origin レスポンス – キャッシュミスにより Originへコンテンツを取りに行き、エッジへレスポンスを戻した後でコードを実行します。

リクエストやレスポンスに含まれるURLやメソッド、HTTPバージョン、クライアントIPアドレス、ヘッダなどのさまざまな要素へコードからアクセスできます。まず最初にヘッダを追加、削除、そして編集することができるようになる予定です。すぐに、bodyを含むすべての値に対して読み込み/書き込みの完全なアクセスができるようになる予定です。

JavaScriptコードは、リクエスト/レスポンスパスの一部になるでしょう、そしてそれは効率的で、重要で、自己完結型のものでなければなりません。他のWebサービスをコールすることは出来ません、また他のAWSリソースへアクセスできません。128MBメモリ内で動作しなければならず、また50ms以内で完了しなければなりません。

開始するには、新しいLambda function を作成して、あなたのディストリビューションをトリガーとして設定し、新しいエッジランタイムを選択します。

その後で通常通りコードを書きます。Lambdaはエッジロケーションでの舞台裏での処理をしてくれます。

興味深いですか?
このクールな新しい処理モデルはいくつかのとてもクールな新しいアプリケーションや開発ツールの作成を導いてくれると信じています。あなたがこちらを使って何をもたらしてくれるか待ちきれません。

私たちは本日Lambda@Edgeの制限付きのプレビューをラウンチします、そして利用者を募集しています。もしあなたが関連しそうなユースケースをお持ちで、こちらを試す準備が出来れいれば、ぜひこちらにご応募ください。

-Jeff

翻訳は舟崎が担当しました。原文はこちらです。

AWS Batch – AWSでバッチ処理ジョブを実行する

私は1978年秋に大学に入学しました。モンゴメリー・カレッジのコンピュータ・サイエンス部門は、強力な(当時の)IBM 370/168メインフレームを中心に構築されました。 Keypunchマシンを使用してカードデッキを準備する方法、実際のコードの前にジョブの名前と優先順位を設定し、FORTRAN、COBOL、またはPL / Iコンパイラを呼び出す暗黙のジョブ制御言語(JCL) 。デッキを提出ウィンドウに持ってきて、ジョブIDと引き換えにオペレーターに渡してから、数時間後に戻って印刷出力とカードデッキを回収します。私はその印刷物を慎重に研究しましたが、仕事に就いて数時間を待ってから、実際の稼動時間はほんの数秒であったことに気付いていました。仲間の学生と私がすぐに学んだように、学校のIT部門が開始した仕事は優先順位4で実行され、私たちは8で実行されました。彼らの仕事は私たちよりも優先されました。優先順位の高いメカニズムの目標は、高価なハードウェアを可能な限り完全に使用することでした。学生の生産性は、リソースの効率的な使用に引き続き二次的でした。

今日のバッチコンピューティング
今日、バッチ・コンピューティングは依然として重要です!より簡単にコンピューティングパワーにアクセスすることで、映画スタジオ、科学者、研究者、数値アナリストなどがこれまで以上に多くのコンピューティングサイクルを楽しめるようになりました。多くの組織では、オープンソースまたは商用ジョブスケジューラを搭載した社内の計算クラスタを構築することによって、これらのニーズに対応しようとしています。三度、優先順位が立ちはだかり、依然として、決して十分な計算能力がないようです。クラスタは、構築・運用するのに費用がかかり、同一の、ほぼ差異のないプロセッサの大きな配列で構成され、ビンテージとまったく同じ仕様に構築されることが多い。

クラウドコンピューティングは、さまざまな種類のEC2インスタンスへの迅速なアクセス、ニーズの変化に対応して拡大縮小する機能、および、必要なキャパシティに対して入札を行い、可能な限り経済的にそれを得られる価格モデルによって、バッチコンピューティングモデルをより良いものに変える可能性を秘めています。これまで、多くのAWSのお客様は、EC2インスタンス、コンテナ、通知、CloudWatchモニタリングなどを使用して独自のバッチ処理システムを構築してきました。これは非常に一般的なAWSユースケースであることが判明し、バッチ処理システムの構築を達成することをさらに容易にすることに決めました。

AWS Batchの紹介
今日、完全に管理されたバッチ機能の新しいセットについてお話したいと思います。 AWS Batchにより、バッチ管理者、開発者、およびユーザーは、クラスタのプロビジョニング、管理、監視、またはメンテナンスを行うことなく、クラウドのパワーにアクセスできます。購入するものはなく、インストールするソフトウェアはありません。 AWS Batchは、特に違いを生まない重い作業を処理し、EC2インスタンスの動的にスケーリングされたセットでコンテナイメージとアプリケーションを実行できるようにします。 Amazon EC2とEC2 Spotによって提供される弾力性と選択性を活かした並列ジョブを大量に実行することができ、効率的で使いやすく、クラウド向けに設計されており、他のAWSサービスAmazon S3、DynamoDB、およびSNSが含まれます。

(more…)