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ページから最新のウェビナーの開催情報や資料を入手いただけます。

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.comVimIsTheBest.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拡張が使われていません。
  • ACMかIAMにある全ての証明書を利用することができます。
  • 同一ドメイン向けの複数の証明書を1つのsecure listenerに紐付けることができます。ALBはクライアントのサポート範囲を含む複数の因子を元に適切な証明書を選択します。
  • もしクライアントがSNIをサポートしていない時には、ALBは(listener作成時に1つ指定する)デフォルト証明書を使います。
  • 3つの新しいELB API呼び出しが追加されます: AddListenerCertificates, RemoveListenerCertificates, そしてDescribeListenerCertificatesです。
  • (デフォルト証明書を除いて) ロードバランサ毎に最大25個の証明書を紐付け可能です。
  • リリース時点でこれらの新しい機能はAWS CloudFormationでサポートされています。

私の同僚のJon Zobristが作ったウェブサイトでこれらの新しい機能が稼働している例を見ることができます: https://www.exampleloadbalancer.com/.

全体を通して、私は個人的にこの機能を使っていきますし、多くのAWS利用者もこのメリットを受けることができると確信しています。Elastic Load Balancingチームには、これを我々のユーザに届けるためのハードワークをしてくれたことに感謝したいと思います。

Randall

原文: Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI (翻訳: SA岩永)

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

Elastic Load Balancing(ELB)は、Auto ScalingAmazon 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 Load Balancerの作成

EC2コンソールの画面を開き、Network Load Balancerを作成することができます。Load Balancers を選択し、Create Load Balancerをクリックします。

Network Load Balancerを選び、Createをクリックし、詳細を入力します。ターゲットVPCの各サブネットに対してElasticIPを選択することがで、Network Load Balancerにタグづけができます。

次にConfigure Routingをクリックし、新しいターゲットグループを作成します。名前を入力し、プロトコルとポートを選択します。トラフィックポートまたは代替に選んだポートに対するヘルスチェックも設定することができます。

Register Targetsとトラフィックを受けるEC2インスタンスをクリックし、 Add to registeredをクリックします。

全ての項目が問題無い事を確認し、Createをクリックします。

新しいLoad Balancerの状態はprovisioningで、1分程度の間にactiveに代わります。

テスト目的のために、コンソールからLoad BalancerのDNS名前を確認します。(通常はAmazon Route 53を使い、もっとわかりやすい名前を使用します。)

それから大量のトラフィックを送りました。(1秒か、2秒の間実行する事を意図していましたが、気をとられ、膨大な数のプロセスを生成してしまいました。これはうれしいアクシデントでした。)

$ while true;
> do
>   wget http://nlb-1-6386cc6bf24701af.elb.us-west-2.amazonaws.com/phpinfo2.php &
> done

もちろん、より規律あるテストではBees with Machine Gunsの様なツールを使用します!

トラフィックを流す様にするため少し休憩したのち、私のLoad BalancerのCloudWatchメトリックスを確認し、簡単に、突然のトラフィックの猛攻撃を処理することができたことを確認しました。

どの様な負荷をかけているか確認するために、EC2インスタンスをみました。(本当にうまくいったことがわかりました)

私の同僚達が私が実施したよりもより規律的なテストを実施しています。彼らはNetwork Load Blancerをセットアップし、それにはEC2インスタンスのオートスケールフリートを利用しました。彼らは数百台のEC2インスタンスにより構成される2番目のfleetをセットアップし、それぞれBees with Machine Gunsを実行し、非常に多数のリクエストとレスポンスサイズを生成する様に設定しました。秒間150万リクエストからはじめ、素早くダイアルを全部あげ、テストリソースの最大に達する前に、秒間300万以上のリクエスト、総帯域幅が30Gbpsに達しました。

Load Balancerの選択

いつものように、Load Balanerを選ぶ場合、アプリケーションの要求を考える必要があります。以下はいくつかのガイドラインです。

Network Load Balancer(NLB) – TCPトラフィックの負荷分散に理想的で、NLBは超低遅延を維持しながら秒間数百万のリクエストを取り扱う能力があります。NLBはAvailability Zone毎に1つの固定IPを使いながら、突発的で変動しやすいトラフィックパターンを取り扱う事に最適化されています。

Application Load Balancer(ALB) – HTTPおよびHTTPSトラフィックの高度なロードバランシングに理想的で、ALBはマイクロサービスやコンテナベースのアプリケーションを含むモダンなアプリケーションアーキテクチャをサポートする高度なリクエストルーティングを提供します。

Classic Load Balancer(CLB) – EC2 Classicネットワーク上に作成されたアプリケーションに最適です。

横並びでの比較には、Elastic Load Balancing Details の表を確認してください。

現在Classic Load Balancer を利用していて、Network Load Balancerに移行しようとしている場合には新しい Load Balancer Copy Utilityを確認してください。このPythonツールは既存のClassic Load Balancerと同じ設定でNetwork Load Balancerを作成する手伝いをします。また既存のEC2インスタンスを新しいload balancerに登録することもできます。

価格と利用状況

Application Load Balancerと同様に、価格はLoad Balancer Capacity Units、LCUに基づきます。費用はLCUあたり$0.006で、以下のディメンジョンの内、最も高い値に基づきます。

  • Bandwidth -LCUあたり1 GB
  • New Connections – LCUあたり800
  • Active Connections – LCUあたり100,000

ほとんどのアプリケーションは帯域幅バウンドで、Application またはClassic Load Balancerと比較すると
約25%のコスト削減(負荷分散について)になります。

Network Load BalancerはChina(Beijing)以外の商用リージョンの全てで利用可能で、AWS CloudFormation, Auto Scaling, Amazon ECSでもサポートされています。

Jeff;

原文: New Network Load Balancer – Effortless Scaling to Millions of Requests per Second (翻訳: SA浅野・岩永)

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

昨年、Lambda@Edgeプレビューをアナウンスし、お客様に近いロケーションでHTTPリクエストを”賢く”処理する方法を説明しました。プレビューに応募しアクセスを許可された開発者は Lambda@Edge を有効に活用し、非常に有用な多くのフィードバックをいただきました。プレビュー中に HTTP レスポンスの生成、CloudWatch Logs のサポートを追加し、フィードバックに基いてロードマップを更新しました。

一般提供の開始

本日、 Lambda@Edge の一般提供を開始できることを嬉しく思います。次のように利用できます:

  • A/B テストを行うために cookie を検査し、 URL を書き換える
  • ユーザーエージェントヘッダに基づいて、特別なオブジェクトを返す
  • オリジンにリクエストを許可する前に、特定のヘッダを検索することでアクセスコントロールを実装する
  • ヘッダを追加、削除または変更して様々なキャッシュ済オブジェクトに誘導する
  • HTTP レスポンスを生成する
  • 古い URL 形式のサポート
  • ヘッダや URL を変更または簡略化して、キャッシュ使用率を改善する
  • 他のインターネットリソースへ HTTP リクエストを行い、その結果を使用してレスポンスをカスタマイズする

(more…)

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

AWS Direct Connect は、大規模な顧客に対してオフィス、データセンターやコロケーション設備におけるプライベートでハードウェア専有のネットワーク接続の設立を支援します。1 Gbps と 10 Gbps の接続を設立することで、顧客にとってはネットワークコストの削減、データ転送スループットの向上、そしてインターネット基盤で可能な接続よりもさらに安定したネットワーク接続を確立することができます。本日は、Direct Connect の新しい Link Aggregation 機能についてご紹介します。また、新しい Direct Connect バンドルについて、そして Direct Connect をどのように活用して AWS re:Invent 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 側で同じデバイスとして接続されます。デバイスに空き容量がある限り、既存のグループにポートを追加することもできます (空き容量情報は Direct Connect Console から入手できるようになりました)。既存のグループの拡張を希望していても、デバイスに開放ポートがない場合には、新しいグループを注文して接続を移動するだけ十分です。コンソールから Link Aggregation を作成する方法を次に示します。まず、新しい LAG をゼロから作成します。

次に、既存の接続から LAG を作成します。


Link Aggregation グループは、 US East (Northern Virginia)US West (Northern California)US East (Ohio)US West (Oregon)Canada (Central)South America (Brazil)Asia Pacific (Mumbai)Asia Pacific (Seoul) リージョンで現在提供されており、今すぐ作成できます。 今月末には、そのほかのリージョンでもサービスの提供が可能になる予定です。

Direct Connect バンドル
re:Invent 2016 年にいくつかの新しい強力な Direct Connect バンドルが発表されました。それぞれのバンドルは、複雑性を低減してパフォーマンスを向上させた最先端のハイブリッドリファレンスアーキテクチャとなっています。新しいバンドルは次の通りです。Level 3 コミュニケーションパワー Amazon WorkSpaces – エンタープライズアプリケーションデータ接続、ユーザーワークスペース、そしてエンドポイントデバイスによって、信頼できるパフォーマンスとより向上したエンドユーザーエクスペリエンスを提供します: AT&T NetBond によって拡張された SaaS アーキテクチャ – AWS クラウドに移動したアプリケーション用に拡張された機能とユーザーエクスペリエンス: Megaport DX 搭載の Aviatrix ユーザーアクセス – AWS クラウドリージョン間、エンタープライズデータセンターと AWS 間、そして AWS への VPN アクセスにおける暗号化接続のサポート: Verizon の安全なクラウド相互接続 における Riverbed の Hybrid SDN/NFV アーキテクチャ – エンタープライズ顧客に安全で最適化された AWS サービスへのアクセスをハイブリッドネットワーク環境で提供します:

re:Invent 2016 年の Direct Connect
re:Invent の参加者とパートナーに最上のエクスペリエンスを提供するために、高度な利用性と完全な冗長化の通信を設立できる Level 3 を開発しました。このネットワークは、休憩セッション、認定試験、ハンズオンラボ、キーノート講演 (122 か国から 25000 人以上の閲覧者に向けたライブストリームを含む)、ハッカソン、ブートキャンプ、ワークショップをサポートするために利用されました。この re:Invent ネットワークは、10 Gbps 接続を使用し、各 2 接続が US West (Oregon)US East (Northern Virginia) です:

これは、すべての re:Invent イベントをサポートしました:

ここに、実現に至った方法とお客様ご自身で実現させる方法の詳細について役立つビデオ資料を紹介します。

Jeff;

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

先日のブログ「Amazon S3 で IPv6 をサポート」の続報として、今回は Amazon CloudFrontAmazon S3 Transfer AccelerationAWS WAF と 50 か所以上に渡るすべての CloudFront エッジロケーションでも IPv6 サポートが利用可能になったことをお知らせします。AWS では、すべての自律システムネットワーク (ASN) で IPv6 を有効にするための段階的な移行プロセスを本日より開始し、今後数週間に渡りすべてのネットワークで拡張する予定です。

CloudFront IPv6 のサポート
Amazon CloudFront ディストリビューションごとに IPv6 サポートを有効にすることができます。IPv6 を使用して CloudFront エッジロケーションに接続する閲覧者とネットワークは自動的に IPv6 でコンテンツを取得します。IPv4 を使用して接続する場合は以前のように機能します。オリジンサーバーへの接続には IPv4 を使用します。

新たに作成したディストリビューションでは自動的に IPv6 が有効になります。既存のディストリビューションを変更するには [Enable IPv6] を有効にします。これはコンソールまたは CloudFront API から設定できます。

この新機能の重要事項については次をご覧ください。

  • エイリアスレコード – ディストリビューションで IPv6 サポートを有効にすると、ディストリビューションの DNS エントリは AAAA レコードを含むものに更新されます。Amazon Route 53 とエイリアスレコードを使用してディストリビューションのドメインすべてまたは一部をマップしている場合、そのドメインに AAAA エイリアスを追加する必要があります。
  • ログファイルCloudFront アクセスログを有効にしている場合、IPv6 アドレスが c-ip フィールドで表示されるので、ログ処理システムがそれに対処できるようにしておいてください。
  • 信頼された署名者信頼された署名者と IP アドレスのホワイトリストを併せて使用している場合は、IP ホワイトリストと実際のコンテンツの IPv4/IPv6 ディストリビューションを備える、信頼された署名者 URL の IPv4 に限られたディストリビューションの使用を強くお勧めします。このモデルでは、IPv4 アドレスを使用して送信した署名リクエストにサインしたことで、コンテンツのリクエストがホワイトリストに載っていない別の IPv6 アドレスから届くといった問題を回避することができます。
  • CloudFormation – CloudFormation サポートを準備中今回のリリースでは、CloudFormation テンプレートから作成したディストリビューションで IPv6 は有効になりません。既存のスタックを更新する場合、スタックで参照したディストリビューションの設定に変更はありません。
  • AWS WAFAWS WAF と CloudFront を併せて使用している場合は、IPv6 アドレスのホワイトリストまたはブラックリストで適切となるように WebACL と IP ルールセットを必ず更新してください。
  • Forwarded ヘッダー – ディストリビューションで IPv6 を有効にする場合は、オリジンに渡した X-Forwarded-For ヘッダーに IPv6 アドレスが含まれているようにしてください。オリジンがこの形式のヘッダーを処理できるか確認してください。

詳しくは「Amazon CloudFront で IPv6 をサポート」をご覧ください。

AWS WAF IPv6 サポート
AWS WAF はアプリケーションレイヤーで発生する攻撃からアプリケーションを保護します (詳しくは「新機能 – AWS WAF」をご覧ください)。

AWS WAF が IPv4 アドレスまたは IPv6 アドレス経由で届くリクエストを調べられるようになりました。IPv6 と一致するウェブ ACL を作成することができます。詳しくは「IP Match Conditions の使用」をご覧ください。

既存の WAF 機能はすべて IPv6 に対応、そのパフォーマンスで目に見える変化はありません。IPv6 は WAF が収集し表示したサンプルリクエストで表示されます。

S3 Transfer Acceleration IPv6 サポート
この重要で新しい S3 機能が IPv6 をサポートするようになりました (詳しくは「AWS ストレージの更新 – Amazon S3 Transfer Acceleration + より多くのリージョンでさらに大きくなった Snowballs」をご覧ください)。アップロードに使用できるデュアルスタックのエンドポイントに簡単に切り替えることができます。次のように変更するだけです。

https://BUCKET.s3-accelerate.amazonaws.com

https://BUCKET.s3-accelerate.dualstack.amazonaws.com

クライアントオブジェクトの作成とデュアルスタック転送の有効を可能にする AWS SDK for Java 使用コードは次の通りです。

AmazonS3Client s3 = new AmazonS3Client();
s3.setS3ClientOptions(S3ClientOptions.builder().enableDualstack().setAccelerateModeEnabled(true).build());

大半のアプリケーションとネットワークスタックは自動的に IPv6 の使用を好む傾向があるので、これ以上の設定は必要ありません。IPv6 アドレスと併せて使用する上で機能動作に問題がないことを確認するため、パケットの IAM ポリシーを見直すことをお勧めします。詳しくは「IPv6 を使用して Amazon S3 にリクエストを送信」をご覧ください。

テストを忘れずに
AWS リージョンへの IPv6 接続に制限があったり存在しない場合は、代わりに IPv4 が使用されます。以前公開したブログでも触れましたが、IPv6 をサポートするようにクライアントシステムを設定することができます。ただし、その場合は IPv6 パケットをインターネットにルートするように設定していないネットワークに接続する必要があります。こうした理由から、IPv6 に切り替える前に何らかのアプリケーションレベルで行うエンドツーエンド接続のテストを行うことをお勧めします。

Jeff;

Amazon CloudFront をカナダで展開

主にお客様からのご要望に基づき実現した多数の機能を備える Amazon CloudFront は、世界中のお客様に静的、動的、そしてインタラクティブなコンテンツを高速かつ低レイテンシーで提供する場合に最適です。AWS 無料利用枠の一環として、HTTP や HTTPS のリクエスト 200 万件までを処理するほか、追加料金なしに毎月 50 GB までのデータを転送することができます。

そしてこの度、カナダのトロントおよびモントリオールにも CloudFront エッジロケーションを追加いたしました。同地域のお客様に今まで以上に優れたサポートをご提供、そして全世界に渡るロケーション数は 59 か所になりました (詳細は全リストをご覧ください)。これには先日オンラインになったブラジルで 2 番目のエッジロケーション、サンパウロも含まれています。トロントおよびモントリオールのロケーション価格は、米国のエッジロケーションと同様です (詳しくは CloudFront の料金表をご覧ください)。カナダのエッジロケーションは価格クラス 100 になります。

アプリケーションがすでに CloudFront を使用している場合は、新しいロケーションを活用するために特別な操作を行う必要はありません。ロケーションにかかわらず、ユーザーは静的、動的、ストリーミングしたコンテンツへのアクセスを高速かつ低レイテンシーでお楽しみいただけます。

また、開発者の方は CloudFront の使いやすさとコスト効率の良さを実感いただけるでしょう。柔軟性を備えているため、予測が困難なトラフィック負荷を処理する場合でも過剰にプロビジョニングする必要がありません。次の新しい 3 つのロケーションでも今後 Amazon Route 53 をサポートしていく予定です。新しいロケーションを活用するために特別な操作を行う必要はありません。

Jeff