Category: AWS PrivateLink

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、シニアエバンジェリストの亀田です。 大阪リージョンが3つのAZを伴うフルリージョンとしてラウンチしてから3週間が過ぎました。利用を開始したり、検討されている方も多いのではないでしょうか。3月2日のラウンチ後も機能拡張は続いておりますが、今日2つの機能がリリースされましたのでご報告いたします。 1.Amazon VPC Endpoints For Amazon EC2 2.Amazon Redshift Spectrum Amazon VPC Endpoints For Amazon EC2 AWS PrivateLinkは、サービス間のプライベート接続がVPCエンドポイント経由で可能となるサービスです。今回のアップデートにより、大阪リージョンにおいて、インターネットを経由せずにAmazon Virtual Private Cloud（Amazon VPC）内からAmazon EC2にアクセスできるようになりました。これにより、 インターネットゲートウェイやNATゲートウェイを必要とせずに、EC2 APIによりセキュアな接続方法が提供されます。PrivateLinkはAWS IAMをベースとした ロールベースのアクセス制御ポリシーを設定することが可能で、従来のIPアドレスやプロトコル、ポート番号ベースの制御より、より細かい権限設定が可能となります。オンプレミスからのアクセスは、AWS DirectConnect、別のVPCからのアクセスはVPC Peeringを使用してVPCエンドポイントにアクセスすることもできます。 詳しくはこちらをご覧下さい。 Amazon Redshift Spectrum Amazon Redshiftは最も高速で最も広く使用されているクラウドデータウェアハウスです。データウェアハウス、運用データベース、およびデータレイクにあるペタバイト規模の構造化データと半構造化データを、標準的な SQL を使用してクエリを実行することも可能です。さらに、Apache Parquet のようなオープンフォーマットでクエリの実行結果を Amazon S3に保存することも簡単です。 今回の大阪リージョンのアップデートでは、S3のデータに対して直接クエリを実行可能なRedshift Spectrumがサポートされ、AWSの各サービスに対して透過的なデータ処理を実現することが可能となりました。Parquet、ORC、JSON、CSVなどのオープンデータ形式をサポートし、構造体、配列、マップなどの複雑なデータ型を使用したネストされたデータのクエリもサポートしています。 詳しくはこちらをご覧ください。 さて、機能拡張が続く大阪リージョンですが、西日本のお客様だけではなく、地理的に離れた場所にシステムの災害対策拠点、バックアップ拠点を作りたいという要件をお持ちのお客様が東京リージョンに対するDR拠点などとして検討されているケースも増えてきています。 このセミナーでは、私の方より、1）社内システム、2) フロントエンドシステム、そして 3) DR拠点の3シナリオに分けて大阪リージョンと東京リージョンの使い分け検討指標についてご紹介を予定しています。もしよろしければご参加ください。 – シニアエバンジェリスト […]

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、シニアエバンジェリストの亀田です。 AWS Gateway Load Balancerが東京リージョンに対応しましたのでお知らせいたします。 Virtual Private Cloud (VPC)では、インターネットゲートウェイ (IGW) または Virtual Private Gateway (VGW)  において、すべての発着信トラフィックを、特定の Amazon Elastic Compute Cloud (EC2) インスタンスの Elastic Network Interface にルーティングさせる機能を用いることで、トラフィックをターゲットの EC2 インスタンスに中継する前に、バーチャルアプライアンスなどをインストールした別のEC2インスタンスを用いて、疑わしいネットワークトラフィックを検査またはブロックすることができます。 さらにこの機能を活用することでセキュリティ系ツールを提供しているパートナーは、検査を行うソフトウェアが起動しているEC2を動作させる専用VPCを起動し、AWS PrivateLink 経由で検査対象のEC2が存在しているVPCと連携させることで、VAaaS (Virtual Appliance as a Service) ビジネスを展開することが可能になりました。 このような構成をとる場合、仮想アプライアンスが動作しているEC2の高可用性、スケーラビリティは非常に重要となります。時として、ピーク時の負荷と高可用性を処理するために仮想アプライアンスのためにEC2を過剰にプロビジョニングするか、トラフィックに基づいてアプライアンスを手動でスケールアップ/ダウンするか、等の対応を行う必要がありましたが、Gateway Load Balancer を用いることで、簡単かつ費用効果の高い方法で、デプロイ、スケーリング、管理が可能となります。 AWS Gateway Load Balancer (GWLB)の仕組み こちらのBlog記事にその詳細がありますので、合わせて読んでみてください。以下はその抜粋です。 VPC のルートテーブルで簡単な設定更新を行うことで、トラフィックを GWLB に送信することができるようになります。GWLB を使用すると、仮想アプライアンスのフリート間でトラフィックの負荷分散を行うことで、仮想アプライアンスを自在にスケーリングできます。GWLB […]

AWS re:Invent で AWS PrivateLink for Amazon S3 のリリースに関する発表が行われましたが、この新機能の一般提供が開始されました。AWS PrivateLink は、仮想ネットワークからのプライベート IP を使用して、Amazon Simple Storage Service (S3) とオンプレミスリソース間のプライベート接続を提供します。 S3 は VPC エンドポイントを追加する最初のサービスとして 2015 年に提供が開始されましした。これらのエンドポイントは、ゲートウェイや NAT インスタンスを必要としない S3 への安全な接続を提供します。この柔軟性はお客様に歓迎されましたが、オンプレミスアプリケーションから AWS Direct Connect または AWS VPN によるセキュアな接続を介した S3 へのプライベートアクセスが必要という意見も聞かれました。 機知に富む私たちのお客様は、プライベート IP アドレスを持つプロキシサーバーを Amazon Virtual Private Cloud にセットアップし、S3 のゲートウェイエンドポイントを使用することで、この問題を解決しました。この解決法は機能しますが、一般的にプロキシサーバではパフォーマンスが抑制されるだけでなく、障害点が増えてオペレーションが複雑になります。 このような欠点を排除し、問題を解決する方法として PrivateLink for S3 が開発されました。 この機能を使用することによって、Virtual Private Cloud 内で新しいインターフェイス […]

AWS Transit Gateway (TGW)は徹底的に進化することにより、クラウドネットワーキングを簡素化しました。本記事では、複数Amazon Virtual Private Cloud(VPC)とオンプレミスの接続パターンを紹介します。 AWSでは、オンプレミスのネットワークとの接続にはAWS Direct Connect(DX)を使います。DX接続は様々な形態がありますが、日本のお客様に多い“共有型”DX接続ではTGWを直接使うことができません。TGWを使うことができることが“専有型”DX接続の優位点の一つですが、本記事では”共有型”DX接続でTGWを使った接続実現する方法を含めて、いくつかの接続パターンを解説します。 TGWのメリット TGWを使用すれば、一貫した信頼性の高いネットワークパフォーマンス を実現しながら、複数のVPCおよびDXを使ってオンプレミスネットワークを相互接続するのはお手の物です。TGWは各VPC、VPN、DXの間のすべてのトラッフィクを一箇所で制御することができます。 専有型が利用できる場合にはTGWとDXをつなぐと、AWSを経由してインターネット接続することもできます。 上の例では、TGWがAWS Direct Connect Gateway(DXGW)にアタッチされています。 DXの複数VPCでの利用は典型的なユースケースです。一方で、DXは1Gbps以上の接続につきTGWのためのトランジット仮想インターフェースは１つだけという制限があります。つまり、日本のお客様に多い、“共有型”DX接続ではTGWを直接使うことができません。 ここでは、複数VPCとオンプレミスの接続パターンを以下４つに整理してみます。1つ目だけが、“専有型または1Gbps以上のホスト型接続”のみ実現可能です。 TGWにDXをつける DX用のVPCにNetwork Load Balancer(NLB)を配置。VPC間はTGW DX用のVPCにNLBを配置。VPC間はAWS PrivateLink(Private Link) DXGWにVPCをつける 1. TGWにDXをつける この場合、すべてのトラフィックはTGWで管理できます。AWSを経由したインターネット接続もProxyなしで実現できます。また、全トラフィックを”監査用アプライアンス”に通すことで全トラフィックの記録 / 制限 / 監査も可能ですので、セキュリティ面でも有利です。 2. DX用のVPCにNLBを配置。VPC間はTGW DXにつながるVPCとして“DX用VPC”1つが現れました。このとき、DXからみれば1つの”DX用VPC”がつながるだけですので、”共有型”でも問題ありません。VPC間の通信はTGWで設定制御ができます。 オンプレミス↔VPC間で通信をしなければならない特定のサーバのフロントにはDX用VPCにNLBを設置することで通信できるようにします。サーバの数だけNLBを設定するため、サーバ数が増えるとNLBの時間あたり費用がかさむことに注意してください。 3. DX用のVPCにNLBを配置。VPC間はPrivateLink このパターンでは、PrivateLinkが重要です。マイクロサービスなど、VPCを自由にいくつも使っている場合には、IPアドレスブロックが重複することはよくあることです。2つ目のパターンでは、TGWをつかってVPC間の通信を制御していました。TGWではアドレス重複の答えにはなりません。PrivateLinkはその解決策です。 VPC間およびオンプレミスとの特定の通信はPrivateLinkで設定します。VPCからオンプレミス上のサーバにアクセスするためにも使うことができます。 4. DXGWにVPCをつけたとき VPCとオンプレミスの間の通信はあるけれども、VPC同士の通信が無いのであれば、TGWは実は必要なかったのかもしれません。なお、一つのDXGWに接続できるVPCは10までですので、スケーラビリティにもやや難があるかもしれません。VPCの数が10以上になった場合、2つめの共有型Private VIFを利用する事により、多くのVPCと接続することができます。ただし、共有型VIFを増やし続けると、”1.”でご紹介した専有型接続の方が結果的に安価となる分岐点に到達します。詳細な見積もりが必要な場合は、利用するパートナー様にご確認ください。 比較 比較の一覧を追加しておきます。料金試算は、東京リージョンで、3つのサービス用VPCと1つのオンプレミスのネットワークを接続し、サービスするVPCひとつあたり月間10TB通信があり、DXのIn/Outの比率が1:1の場合です。（詳細は最後に） 案1: TGWにDXをつけたとき 案2: DX用のVPCにNLBを配置。VPC間はTGW 案3: DX用のVPCにNLBを配置。VPC間はPrivateLink […]