Amazon Web Services ブログ

SAP on AWSにおけるVPCサブネットのゾーニングパターン 第3回：内部および外部接続

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。

VPCサブネットのゾーニングパターンに関するシリーズ記事の第1回目では、SAPアプリケーションへのいくつかの接続方法を紹介し、内部専用接続のためのAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンについて詳細を説明しました。第2回目では、従来のアプリケーションにおけるネットワークのゾーニングをAWS上でどのように実装できるか説明しました。このシリーズの最後の記事として、内部接続と外部接続の両方を必要とするSAPアプリケーションの接続パターンを説明します。外部ソースからの接続は管理されていてもよく(つまり、既知の外部の関係者を含む)、管理されていない(つまり、公開されていてもよい)場合もあります。両方のシナリオについて説明します。

内部および管理された外部接続

外部向けインターフェースに対する信頼された外部の関係者からの接続と、内部向けインターフェースに対するSAPと非SAPシステム間またはどちらかの間の接続が必要となる、SAP Process Orchestration(PO)とSAP Process Integration(PI)がこのシナリオの典型的な例です。内部向けインターフェースは簡単に管理できます。基本的には、ルートテーブル、ネットワークアクセスコントロールリスト(ACL)、およびセキュリティグループに適切なトラフィックを定義します。しかしながら、外部接続を安全に提供することには課題があります。そこで、信頼できる外部の関係者からのトラフィックの入口と出口に着目しましょう。典型的な選択肢が4つあります。

  • 入口と出口の両方のための仮想プライベートネットワーク(VPN)接続
  • 入口用のElastic Load Balancing、および出口用のネットワークアドレス変換(NAT)ゲートウェイ
  • NATデバイス(NATインスタンスまたはNATゲートウェイ)
  • リバースプロキシ

VPN接続 (入口と出口)

信頼できる外部の関係者と専用の仮想接続を作成する場合は、VPCでVirtual Private Gateway(VGW)を使用するか、パブリックサブネット内にAWS Marketplaceで公開されているような独自のソフトウェアVPNサーバを使用することで、サイト間IPsec VPN接続を確立できます。

注釈   この記事のアーキテクチャ図では、簡単にするために単一のアベイラビリティゾーンで示しています。実際には、高可用性を実現するために、少なくとも2つのアベイラビリティゾーンにわたってソリューションを構成することをお勧めします。

図 1: 管理された外部接続のためのVPNコネクション

Elastic Load Balancing (入口) / NATゲートウェイ (出口)

Elastic Load Balancingには、次の3つのタイプがあります。

  • Classic Load Balancer
  • Network Load Balancer
  • Application Load Balancer

Classic Load Balancerは、 EC2-Classicプラットフォーム上で構築されたアプリケーションに向いています。VPCをお使いであれば、Network Load BalancerあるいはApplication Load Balancerをお勧めします。Network Load Balancerは、Open Systems Interconnection(OSI)モデルの接続レベル(レイヤー4)で動作し、TCPトラフィックの負荷分散に最適です。Application Load Balancerは、接続レベル(レイヤー7)で動作し、HTTPまたはHTTPSの負荷分散に最適です。

Secure File Transfer Protocol(SFTP)とHTTPSの2つの例を考えてみましょう。

  • SFTP: プライベートサブネットにSFTPサーバがあり、信頼できる外部の関係者から接続できる必要があるとします。このシナリオでは、パブリックサブネット内にインターネットに面するNetwork Load Balancerを配置し、プライベートサブネット内のSFTPサーバに関連付けられているセキュリティグループによって、信頼できる外部の関係者からの接続を管理できます(Network Load Balancerに関連付けられたセキュリティグループはありません)。SAP PI / POから信頼できる外部の関係者が持つSFTPサーバへのアウトバウンド(出口)トラフィックの場合には、NATゲートウェイが必要です。Amazon Route 53を使用して、組織の外部ドメイン名を登録し、ロードバランサーを完全修飾ドメイン名(FQDN)で名前解決できます。

    図 2: 外部接続のためのNetwork Load Balancer

  • HTTPS: この2つ目の例では、外部から利用可能なSAP PI / POへのWebサービスベースのインターフェイスがあるとします。このシナリオでは、接続はSSL(HTTPS)に基づいて行われるため、Application Load Balancerが入口トラフィックに最適です。既知のIPからの接続は、ロードバランサーに関連付けられたセキュリティグループによって管理されます。一方、SAP PI / POが信頼できる外部の関係者によって公開されたWebサービスを利用する必要がある場合は、NATゲートウェイが必要です。Amazon Route 53は、ドメイン名の登録とFQDN解決にも使用できます。

    図 3: 外部接続のためのApplication Load Balancer

その他の選択肢

Elastic Load Balancingを使用する代わりに、NATインスタンスとリバースプロキシを使用できます。ただし、NATインスタンスとリバースプロキシを管理する負担を取り除くため、インターネットに面する構成ではNetwork Load BalancerあるいはApplication Load Balancerを使用することをお勧めします。

  • NATデバイス: AWSでは、2種類のNATデバイス、つまりNATゲートウェイとNATインスタンスを提供しています。NATインスタンスはAmazon Machine Image(AMI)に基づいていますが、NATゲートウェイはAWSサービスとして管理されています。これらのデバイスはいずれも、プライベートサブネット内のEC2インスタンスにインターネット接続を提供します。ポート転送のNATインスタンスを有効にすることで、外部の関係者がプライベートサブネット内のEC2インスタンス上で実行されているアプリケーションに接続することもできます。前述のSFTPの例をもう一度見てみましょう。プライベートサブネット内のSFTPサーバには、既知の外部の関係者からはSAP PI / POの持つファイルベースのインターフェイスを経由して接続される必要があります。NATインスタンス(ポート転送を有効にした後)は、SFTPサーバ(プライベートサブネット内に存在)を外部からの直接接続から保護しながら、外部の関係者が接続できるようにします。NATインスタンスに関連付けられたセキュリティグループを設定すると、管理された接続として既知の外部IPからのトラフィックだけを許可できます。すべてのインターフェイスがSAP PI / POからのアウトバウンド接続に基づいている場合、NATゲートウェイが最適です。

    図 4: ポート転送のためのNATインスタンス

  • リバースプロキシ (入口) / NATゲートウェイ (出口): HTTP / HTTPSトラフィックの入口にはリバースプロキシが使用されます。パブリックサブネットのリバースプロキシは、外部の関係者からプライベートサブネット内のSAP PO / PIサーバにHTTP / HTTPS接続を確立できるようにします。入口トラフィックのリバースプロキシとしてSAP Web Dispatcherを使用することも、F5 BIG-IPのようなサードパーティ製品を使用することもできます。SAP Web Dispatcherを使用している場合は、Reverse invokeによる接続を構成することをお奨めします。前述のシナリオのように、出口トラフィックに対してはNATゲートウェイを使用できます。

    図 5: 外部接続のためのリバースプロキシ

これらの両方のシナリオ(NATおよびリバースプロキシ)では、静的パブリックIPアドレスを保持するために、Elastic IPアドレスを使用する必要があります。さらに、Amazon Route 53を使用して、ドメイン名の登録とFQDN解決を行います。

SAP Cloud Connectorなど、他のアプリケーション固有の選択肢も利用することができます。クラウドコネクタは、HTTPS経由でSAP Cloud Platformとの接続を確立します。接続は常にクラウドコネクタによって呼び出されますが、セッションが確立された後、データは双方向に(逆引き接続を介して)送信されます。クラウドコネクタはエクストラネットゾーンに配置し、NATゲートウェイ経由でインターネットに接続することをお勧めします。

図 6: SAP Cloud Platformとの連携

内部および管理されていない外部接続

この領域のアプリケーションへの内部接続は、前述のシナリオ(内部および管理された外部接続)と同様の方法で、つまり適切なルートテーブル、ネットワークACL、およびセキュリティグループを定義することによって管理する必要があります。したがって、このセクションでは、管理されていない外部接続に焦点を当てます。

SAP Fioriは、VPN接続および内部接続なしで外部接続が必要なSAPアプリケーションの一般的な例です。その他の例としては、SAP Hybrisプラットフォーム、外部から接続可能なSAP Enterprise Portal(EP)、あるいはSAP Supplier Relationship Management(SRM)などがあります。ただし、ほとんどの場合、SAPシステムへの管理されていない外部接続はHTTP / HTTPSに制限されています。SAP NetWeaver Gateway上で実行されるセントラルハブ構成のSAP Fioriフロントエンドサーバの例を考えてみましょう。

図 7: 外部接続のためのApplication Load Balancer

外部ゾーンのApplication Load Balancerは、HTTP / HTTPS要求のエントリーポイントとして機能します。ロードバランサーはSAP Web Dispatcherに要求を送信します。AWS Shieldは、特にロードバランサーとAWS WAFを組み合わせて使用​​する場合、一般的なWebエクスプロイトからSAP NetWeaver Gatewayを保護します。AWS Shieldは、AWS上で動作するWebアプリケーションを保護する、マネージド型の分散サービス妨害(DDoS)の保護サービスです。AWS Shieldには、StandardとAdvancedの2つの階層があります。AWS Shield Standardには追加料金はかかりません。

今後について
この記事では、SAPアプリケーションに内部および外部から接続するためのシナリオについて説明しました。特定のシナリオについて議論したい場合、またはこのブログの内容についてご質問やご提案がありましたら、お気軽にお問い合わせください。

翻訳はPartner SA 河原が担当しました。原文はこちらです。