Amazon Web Services ブログ

Category: Networking & Content Delivery

東京に5番目のエッジロケーションを開設。アトランタ(A)からチューリッヒ(Z)までAmazon CloudFrontの接続拠点数が100箇所に

アマゾン ウェブ サービス(AWS)が、グローバルなコンテンツデリバリーネットワーク(CDN)のAmazon CloudFrontのリリースしたのは、約9年前の出来事になります。14の接続拠点からなる高性能なエッジネットワークとして始まったこの新しいサービスは、現在、世界中からの数百万ビューアーの接続に対応するまで成長しました。本日、Amazon CloudFrontの成長が最も著しい地域の一つである日本で100番目の接続拠点(89のエッジロケーションと11のリージョナルエッジキャッシュ)を発表できることを嬉しく思います。100番目の接続拠点(POP)は、東京で5番目そして、日本で6番目のエッジロケーションとなります。 「Amazon CloudFrontのグローバル展開におけるこの節目は、お客様のアプリケーションをよりセキュアで高速、かつ信頼性の高いものにしたいと言う私達のこだわりの成果です。」とAWS Edge Services VPのPrasad Kalyanaramanは、語っています。「東京を100番目の接続拠点のロケーションとして発表できることを特に嬉しく思います。新たなロケーションへの展開やLambda@Edge、AWS Shieldなどの革新的な技術の導入などを通して今後も私達のグローバルのお客様にサービスを提供して行くことを楽しみにしています。」 100番目の接続拠点が東京で展開されることについて日本でも特にご利用が大きい数社のお客様から激励のコメントを頂いています: ソニー・インタラクティブエンタテインメント(SIE)は、PlayStation®のハードウェア及びソフトウェアの製造販売と、PlayStation™Network(PSNSM)などのサービスを手がけている会社です。 SIE、システム/ネットワークエンジニアリング オペレーション部門、課長の田中博規氏は次のように語っています。「このたびはCloudFront100番目のエッジロケーション開設おめでとうございます。CloudFrontは、PlayStation™Networkの安定的な配信と高いパフォーマンスを支える重要なサービスのひとつとなっています。同時に、ゲームコンテンツの高精細化・多機能化・大容量化に伴い、CloudFrontは、弊社のグローバルの利用帯域増に対応できる数少ないCDNサービスの一つです。ユニークで付加価値の高いCDNサービスとしてCloudFrontのさらなる発展を心より期待しています。」 キヤノン株式会社は、カメラ、ビデオカメラなどの精密機器を製造するメーカーです。キヤノン株式会社、映像事務機DS開発センター、主席の八木田 隆氏は次のように語っています。「CloudFrontの100番目のエッジロケーションがTokyoということを感慨深く感じると同時にエッジロケーションが増えていくことはとても喜ばしいことです。Amazon CloudFrontとCloudFrontのAWSサービスとの連携は、キヤノンのクラウドサービスのDynamic ContentsとStatic Contentsの両方の高速な配信に欠かせないものとなっています。ワールドワイドに展開されているCloudFront DistributionをAPIで簡単に制御できるため、我々のサービスの継続的統合と継続的デリバリー(CI/CD)及び自動化に寄与しています。」 三菱電機株式会社は、一般消費者から産業向けまで幅広い製品の製造とサービスを提供している会社です。三菱電機株式会社、インフォメーションシステム統括事業部、部長の岩城新一氏は次のように語っています。  「この度の100番目のエッジロケーション開設大変おめでとうございます。当社では3年前からCloudFrontを活用した大規模動画配信システムによるコンテンツ提供サービスを開始しております。開発当時を振り返りますと、システム設計段階からの手厚いご支援はもとより、システムのカットオーバー前の当社からの突然の負荷テストの依頼など無理なお願いも快く引き受けていただき、人的なサポート面でも大変お世話になったことを思い出します。また、御社の日米のチームがうまく連携していることもとても印象的でした。CloudFrontは立ち上げ初期のチューニング以降は一切問題がなく現在大変安定した配信をしています。Amazon CloudFrontの機能とエッジロケーションも継続して増えているので、日々急激に進化していることを肌で感じています。今後もCloudFrontがどのような進化を遂げていくのか期待をもって見守っていきたいと思っています。」 ディライトワークス株式会社は、ゲームの企画・開発・運営を行っており、その中でも『Fate/Grand Order』は現在、1,000万ダウンロードを突破しています。ディライトワークス株式会社、テクニカル・ディレクターの田村祐樹氏は次のように語っています。「ディライトワークスは、”ただ純粋に、面白いゲームを創ろう。”という開発理念のもとに、ゲームの創作をおこなっております。そこで重要な要素となるのが、より多くのユーザーにより高品質なコンテンツを届けることです。多くのCDNサービスがある中、高い品質、低いコスト、安定した配信と速いインバリデーションからAmazon CloudFrontの利用を決断しました。また、Amazon Route 53、AWS WAFやSSL証明書の自動更新が可能なAWS Certificate Manager(ACM)などの他のAWSサービスとの親和性も高いことにメリットを感じています。今後もCloudFrontとAWSから革新的なサービスに出会えることを期待しています。」 株式会社サイバーエージェントは、メディア事業、広告事業、ゲーム事業とインターネットを軸に様々な事業を展開しています。株式会社サイバーエージェント、メディア統括本部 最高技術責任者の福田一郎氏は、次のように語っています。「CloudFrontの100番目のエッジロケーションという節目が東京で迎えられるということを大変喜ばしく思います。CloudFrontが私達のサービスにとって、より安定・高速にサービス提供をするための一翼を担っていることは間違いありません。これからも、CloudFrontおよびAWSがより一層成長・発展していくことを願っております。」 Amazon CloudFrontの100の接続拠点は、23カ国、50都市と全世界に配置されています。この1年間で37のエッジロケーションを追加しネットワーク帯域を50%以上増設しています。追加された拠点には、新しく4カ国*と9都市が含まれまています: ドイツ、ベルリン;米国、ミネアポリス;チェコ共和国*、プラハ;米国、ボストン;ドイツ、ミュンヘン;オーストリア*、ウィーン;マレーシア*クアラルンプール;米国、フィラデルフィア;スイス*、チューリッヒ。 アマゾンウェブサービスは、ネットワークの拡大に積極的に取り組んでおり、 中東の新しいAWSリージョン開設の予定を発表できたことも嬉しく思います。その取組みに先立って2018年の第1四半期にアラブ首長国連邦に最初のエッジロケーションを解説します。 私達は、常に世界中のお客様により良いサービスを提供する方法を考えています。2016年のre:Inventカンファレンスでは、リージョナルエッジキャッシュという新しいキャッシュ階層の発表で11の接続拠点をネットワークに追加しました。これらの接続拠点は従来のエッジロケーションと比べ大きいキャッシュ容量がありエッジロケーションとお客様のオリジンサーバの間に配置されます。この配置によりビューアーにより近いところでお客様のコンテンツをより長い間キャッシュに残すことができるため、お客様のオリジンサーバの負荷を下げ、ファイルの取得を早くします。 私達は、CDNの評価は、世界にあるロケーションの数だけで決まらないないことも理解しています。Amazon CloudFrontの広大なネットワークに加え、ビジネス要件を満たすために必要な機能やパフォーマンスを満たせるように常にお客様の声に耳を傾けています。セキュリティは、私達にとって最大の優先事項であり、つい最近ではセキュリティポリシー機能のリリースとHIPAA対応を発表できたことを嬉しく思います。また数ヶ月前には、お客様がエンドユーザにより近い所でLambda関数が実行できるLambda@Edgeの一般提供をはじめました。また、開発者の利便性と使い勝手を良くするために、グローバルのキャッシュのインバリデーションと設定変更の伝搬にかかる時間を改善しました。CDNサービスによって、 インバリデーションや設定変更のパフォーマンスの定義が異なる場合があります。CloudFrontの場合、数ミリ秒でインバリデーションのリクエストを受け付け、殆どの場合60秒以内に「全世界のすべてのサーバーでキャッシュをクリア」したことを確認します。   話題性の高いロケーションでの拠点や新機能の追加以上に、私達は、世界中の様々な規模のお客様と共に協力できることを光栄に感じています。個人のブロガーや中小企業のオーナーから世界有数の大企業まで、私達にとって全てのお客様が重要であることお伝えすると同時に私達のグローバルなネットワークに加わっていただいていることを深く御礼申し上げます。 ·         Amazon CloudFrontチームより Amazon CloudFrontのご利用についてより詳しい情報をご希望の場合、こちらのWebページから最新のウェビナーの開催情報や資料を入手いただけます。

Read More

Application Load BalancerがSNIを利用した複数のTLS証明書のスマートセレクションをサポートしました

本日、我々はApplication Load Balancer (ALB)でServer Name Indication (SNI)を使った複数のTLS/SSL証明書のサポートをリリースしました。これによって、単一のロードバランサの背後に、それぞれ別の証明書を持ったTLSで保護されたセキュアなアプリケーションを複数配置することが可能になります。SNIを利用するためには、複数の証明書をロードバランサの同じセキュアリスナーに紐付ける必要があります。ALBは各クライアントに最適なTLS証明書を自動的に選択します。これらの新機能は追加料金無しでご利用可能です。 もし新しい機能をどうやって使えばいいかを手っ取り早く知りたければ、こちらをクリックして下さい。この機能に興味があり、Transport Layer Security (TLS)について復習したい場合は続きをお読み下さい。 TLS? SSL? SNI? SSLとTLSは技術的には異なるものですが、これらを入れ替え可能な用語として使いがちです。SSLはTLSプロトコルの技術的な祖先にあたります。以下では簡潔さのために、TLSという用語を使っていきます。 TLSはパスワード、クッキー、クレジットカード番号といったデータを安全に伝送するためのプロトコルです。これによって、送信されるデータのプライバシー、認証、完全性が実現されます。TLSは、ウェブサイトのIDカードに相当する証明書を基礎とした認証技術を利用します。もし、その証明書を署名し発行した人、すなわちCertificate Authority (CA)を信用するなら、あなたはその証明書の中のデータは正しいと信用します。あるブラウザがTLSが有効化されたあなたのALBに接続するとき、ALBはあなたのサイトの公開鍵を表示しますが、それはCAによって暗号的に証明されたものになります。この方法によって、クライアントは”本物のあなた”からデータを得ていることと、あなたのサイトの公開鍵を利用して安全な接続を確立可能なことを確実にすることができます。 SNIのサポートによって、同一のALBで1つ以上の証明書をもっと簡単に利用できるようになりました。複数の証明書を使いたい最も一般的な理由は、同一のロードバランサで異なるドメインを捌きたいときです。これは、ワイルドカードやsubject-alternate-name (SAN)署名書をALBで利用することで元々実現可能ですが、いくつかの制約があります。ワイルドカード証明書は単純なパターンに合致する関連するサブドメインでしか使えません。SAN証明書は複数の異なるドメインをサポートできますが、単一の認証局でそれぞれを認証する必要があります。つまり、新しいドメインを追加するときには毎回証明書を再認証して再配布する必要があることを意味しています。 フォーラムやReddit、そして私のメールボックスで最も頻繁に頂いていた要望の1つが、TLSのServer Name Indication (SNI)拡張を利用してクライアント毎に証明書を選択するようにしてほしいというものでした。TLSはHTTPの下のトランスポートレイヤを担当するため、クライアントがリクエストしたホスト名を見ることができません。SNIはクライアントがサーバに”私が欲しい証明書はこのドメインです”というのを初回接続時に伝えることで動作します。これによってサーバはクライアントに返答するための適切な証明書を選択することができます。全てのモダンなウェブブラウザとその他のクライアントの大多数はSNIをサポートしています。実際、CloudFrontに接続しているクライアントの99.5%以上がSNIサポートしていることを今現在確認しています。 ALBの証明書スマートセレクション ALBの証明書スマートセレクションはSNIを越えていきます。正しいドメイン名の配列だけでなく、証明書にはサーバがサポートしている鍵交換方式と暗号、さらに証明書を署名する時に使った署名アルゴリズム (SHA2, SHA1, MD5)が含まれています。TLS接続を確立する時に、クライアントは”ClientHello”メッセージを送ることでTLSのハンドシェイクを開始しますが、そのメッセージにはクライアントが利用可能なプロトコルバージョン、拡張、暗号アルゴリズムの組、そして圧縮方式の概要が含まれています。各クライアントが何をサポートしているかを元に、ALBのスマートセレクションアルゴリズムがその接続のための証明書を選択し、クライアントに送ります。ALBは古典的なRSAアルゴリズムも、より新しくて人気で高速な楕円曲線ベースのECDSAアルゴリズムも両方サポートしています。クライアントのECDSAサポートはSNI程は広まっていませんが、全てのモダンなウェブブラウザではサポートされています。より高速でCPUの利用も少ないので、超低レイテンシなアプリケーションや、モバイルアプリのバッテリ残量の節約には特に有効です。ALBはTLSのハンドシェイクから各クライアントが何をサポートしているかが分かるので、同一ドメインのRSAとECDSA証明書の両方をALBにアップロードすることでALBが各クライアントに最適なものを自動的に選択させることができます。 ALBでSNIを利用する ここではウェブサイトの例として、VimIsBetterThanEmacs.comとVimIsTheBest.comを使います。Amazon Route 53でこれらのドメインを購入しホストしておいて、2つの別々の証明書をAWS Certificate Manager (ACM)で発行しています。もし1つのALBでこれらのサイトを両方とも安全に配信したいと思ったら、コンソールから両方の証明書を追加することができます。 最初に、コンソールから私のロードバランサを選択し、listenerタブに行き、”view/edit cerfiticates”を選択します。 次に、左上の角にある”+”ボタンを使って証明書を幾つか選択して、”Add”ボタンをクリックします。 これ以上の手順はありません。GUI好きな方ではなかった場合も、AWS Command Line Interface (CLI) (またはSDK)経由でももちろん新しい証明書を追加することはできますのでご安心下さい。 aws elbv2 add-listener-certificates –listener-arn <listener-arn> –certificates CertificateArn=<cert-arn> 知っておくべきこと ALBのアクセスログには、クライアントがリクエストしたホスト名と使われた証明書のARNが含まれるようになります。もし”hostname”のフィールドが空 (“-“で表現されます)だったときには、そのクライアントではリクエストにSNI拡張が使われていません。 […]

Read More

新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング

Elastic Load Balancing(ELB)は、Auto ScalingとAmazon CloudWatchを含む3つの組みの一部としてローンチした2009年以来、AWSの重要な要素になっています。それから、私たちは多数の機能を追加し、そしてApplication Load Balancerをリリースしました。コンテナで稼働するアプリケーションに対するアプリケーションレベルでのコンテンツベースルーティングをサポートする様に設計されており、Application Load Balancer はマイクロサービス、ストリーミング、リアルタイムワークロードと相性が良いです。 長年にわたって、私達のお客様はあらゆる規模のwebサイトや、アプリケーションをサポートする為にELBを利用しています。1, 2台のT2インスタンス上で動くシンプルなサイトや、ハイエンドインスタンスで構成される大きなフリート上で動き大量のトラフィックを捌く複雑なアプリケーションにまで利用されています。ELBはバックグラウンドでトラフィックを監視し、需要に応じる様に自動的にスケールしています。このプロセスには、余裕をもったバッファが含まれていて、長年にわたってより迅速になりより反応性があがってきたことで、生放送やフラッシュセール、ホリデーシーズンををサポートするためにELBを利用しているお客様にとっても、よく動作します。しかしながら、リージョン間の瞬時のフェイルオーバーや急激なワークロードの変動(スパイク)などの状況では予想されるトラフィックの急増に対してELBをプリプロビジョニングをするようお客様と協力して対応してきました。 新しい Network Load Balancer 今日、新しいNetwork Load Balancer(NLB)を発表します。NLBは超低遅延で高いスループットを維持しながら利用者の努力なしに、秒間何百万リクエストを捌く様に設計されています。Network Load Balancerはターゲットグループやターゲットの完全なプログラム制御を含めて、Application Load BalancerとAPI互換性があります。最も重要な機能のいくつかは以下の通りです。 固定IPアドレス – 各Network Load Balancerは 各VPCサブネットの範囲に対して1つの固定IPアドレスを提供します。us-west-2aにあるサブネットにターゲットがあり、他のターゲットがus-west-2cのサブネットにあった場合、NLBは2つのIPアドレス(サブネットあたり1つ)を作成し管理します。そのIPアドレスに対する接続は そのサブネット内のインスタンス全体に分散します。さらに制御をするために、各サブネットに対して既存のElasticIPを割り当てることも可能です。IPアドレスを完全に制御することで、Network Load BalancerはIPアドレスを、DNSレコードやファイアウォールルールなどにハードコードされる必要がある場合でも利用可能です。 ゾーナリティ(Zonality) – サブネット単位のIP機能はパフォーマンスの向上により遅延を減少させ、アイソレーションとフォールトトレランスを通じて可用性を向上させ、Network Load Balancerの利用をクライアントアプリケーションから透過的にします。Network Load Balancerは、自動フェイルオーバーを可能にしながら、特定の送信元からの一連のリクエストを1つのサブネットのターゲットにルーティングします。 送信元アドレスの保持 – Network Load Balancerでは、到達コネクションのオリジナルの送信元IPアドレスと送信元ポートを維持するので、アプリケーションソフトウェアはX-Forwarded-Forやプロキシプロトコルや他のワークアラウンドをサポートする必要がありません。これは、VPC Security Groupsを含む一般的なファイアウォールルールをターゲット上で利用可能であることを意味しています。 長時間の接続 – NLBは組み込まれたフォールトトレランスによりコネクションを扱うため、NLBは何ヶ月も何年にもわたってオープンなコネクションを処理できるため、IoTやゲーム、メッセージングアプリケーションに最適です。 フェイルオーバー – Route53による ヘルスチェックによって、NLBはリージョン内およびリージョン間のIPアドレス間のフェイルオーバーをサポートします。(訳注: NLB単体では複数AZをサポートします) Network […]

Read More

Lambda@Edge – エッジで HTTP リクエストを”賢く”処理する

昨年、Lambda@Edge のプレビューをアナウンスし、お客様に近いロケーションでHTTPリクエストを”賢く”処理する方法を説明しました。プレビューに応募しアクセスを許可された開発者は Lambda@Edge を有効に活用し、非常に有用な多くのフィードバックをいただきました。プレビュー中に HTTP レスポンスの生成、CloudWatch Logs のサポートを追加し、フィードバックに基いてロードマップを更新しました。 一般提供の開始 本日、 Lambda@Edge の一般提供を開始できることを嬉しく思います。次のように利用できます: A/B テストを行うために cookie を検査し、 URL を書き換える ユーザーエージェントヘッダに基づいて、特別なオブジェクトを返す オリジンにリクエストを許可する前に、特定のヘッダを検索することでアクセスコントロールを実装する ヘッダを追加、削除または変更して様々なキャッシュ済オブジェクトに誘導する HTTP レスポンスを生成する 古い URL 形式のサポート ヘッダや URL を変更または簡略化して、キャッシュ使用率を改善する 他のインターネットリソースへ HTTP リクエストを行い、その結果を使用してレスポンスをカスタマイズする

Read More

AWS Direct Connect アップデート – Link Aggregation Groups, Bundles そして re:Inventの一部振り返り

は、大規模な顧客に対してオフィス、データセンターやコロケーション設備におけるプライベートでハードウェア専有のネットワーク接続の設立を支援します。1 Gbps と 10 Gbps の接続を設立することで、顧客にとってはネットワークコストの削減、データ転送スループットの向上、そしてインターネット基盤で可能な接続よりもさらに安定したネットワーク接続を確立することができます。本日は、Direct Connect の新しい Link Aggregation 機能についてご紹介します。また、新しい Direct Connect バンドルについて、そして Direct Connect をどのように活用して 2016 年の最先端の顧客エクスペリエンスを提供していることについてもさらに詳しくお話ししたいと思います。 Link Aggregation グループ 顧客なかには自身のロケーションと 46 の Direct Connect ロケーションのうちの 1 つに複数の接続 (一般的にはポートと呼ばれる) を設立することをお望みの方もいらっしゃると思います。このような顧客のなかには、AWS の外部におけるネットワーク問題に対しても復元力がある高度な利用可能性をもったリンクの設立が希望でしょう。また、さらなるデータ転送スループットのみを必要とする場合もあります。このような顧客にとって重要なユースケースをサポートするために、最大で 4 つまでのポートの購入とそのすべてを単一管理の接続として扱うことができるサービスの提供が始まりました。これは、Link Aggregation グループ、あるいは LAG と呼ばれます。このサービスを設立すると、トラフィックはポートを通して個別のパケット接続レベルで負荷分散されます。すべてのポートは同時にアクティブとなり、単一の BGP セッションとして提供されます。グループ間のトラフィックは、動的 LACP (Link Aggregation Control Protocol、または ISO/IEC/IEEE 8802-1AX:2016) を通して管理されます。グループの作成時には、接続が有効となる際にアクティブとなるべきポートの最低数も指定する必要があります。複数のポートを持った新しいグループを注文して、既存のポートをこの新しいグループに加えることもできます。どちらの場合でも、すべてのポートは同じスピード (1 Gbps あるいは 10 Gbps) であることが必要です。グループとしてのすべてのポートは、AWS […]

Read More

IPv6 サポートの更新 – CloudFront、WAF、S3 Transfer Acceleration

先日のブログ「Amazon S3 で IPv6 をサポート」の続報として、今回は 、Amazon S3 Transfer Acceleration、 と 50 か所以上に渡るすべての CloudFront エッジロケーションでも IPv6 サポートが利用可能になったことをお知らせします。AWS では、すべての自律システムネットワーク (ASN) で IPv6 を有効にするための段階的な移行プロセスを本日より開始し、今後数週間に渡りすべてのネットワークで拡張する予定です。 CloudFront IPv6 のサポート 各 ディストリビューションごとに IPv6 サポートを有効にすることができます。IPv6 を使用して CloudFront エッジロケーションに接続する閲覧者とネットワークは自動的に IPv6 でコンテンツを取得します。IPv4 を使用して接続する場合は以前のように機能します。オリジンサーバーへの接続には IPv4 を使用します。 新たに作成したディストリビューションでは自動的に IPv6 が有効になります。既存のディストリビューションを変更するには [Enable IPv6] を有効にします。これはコンソールまたは CloudFront API から設定できます。 この新機能の重要事項については次をご覧ください。 エイリアスレコード – ディストリビューションで IPv6 サポートを有効にすると、ディストリビューションの DNS エントリは AAAA レコードを含むものに更新されます。 […]

Read More

Amazon CloudFront をカナダで展開

主にお客様からのご要望に基づき実現した多数の機能を備える Amazon CloudFront は、世界中のお客様に静的、動的、そしてインタラクティブなコンテンツを高速かつ低レイテンシーで提供する場合に最適です。AWS 無料利用枠の一環として、HTTP や HTTPS のリクエスト 200 万件までを処理するほか、追加料金なしに毎月 50 GB までのデータを転送することができます。 そしてこの度、カナダのトロントおよびモントリオールにも CloudFront エッジロケーションを追加いたしました。同地域のお客様に今まで以上に優れたサポートをご提供、そして全世界に渡るロケーション数は 59 か所になりました (詳細は全リストをご覧ください)。これには先日オンラインになったブラジルで 2 番目のエッジロケーション、サンパウロも含まれています。トロントおよびモントリオールのロケーション価格は、米国のエッジロケーションと同様です (詳しくは CloudFront の料金表をご覧ください)。カナダのエッジロケーションは価格クラス 100 になります。 アプリケーションがすでに CloudFront を使用している場合は、新しいロケーションを活用するために特別な操作を行う必要はありません。ロケーションにかかわらず、ユーザーは静的、動的、ストリーミングしたコンテンツへのアクセスを高速かつ低レイテンシーでお楽しみいただけます。 また、開発者の方は CloudFront の使いやすさとコスト効率の良さを実感いただけるでしょう。柔軟性を備えているため、予測が困難なトラフィック負荷を処理する場合でも過剰にプロビジョニングする必要がありません。次の新しい 3 つのロケーションでも今後 Amazon Route 53 をサポートしていく予定です。新しいロケーションを活用するために特別な操作を行う必要はありません。 — Jeff  

Read More