AWS Direct Connectとは？～概要と実装の方法を解説～

AWSの活用を進めていくためには、既存のオンプレミス環境との連携が必要になります。その際、多くの場合、AWSとオンプレミス間の通信をセキュアに保つことが求められます。

そこで必要になるのが、プライベートな通信を行うための接続を確立するサービスです。AWS Direct Connectは、そのうちの一つです。AWS Direct Connectを利用することで、セキュアで安定した品質のプライベート通信を確立できます。

しかしAWS Direct Connectは、適切な設定を行うためにAWSとネットワークの知識の両方が必要になる、やや利用ハードルの高いサービスです。本記事では、初学者がそのハードルを越えられるよう、AWS Direct Connectの概要から設定の例まで解説します。

　アシストの「AWS環境構築支援」とは？

AWS Direct Connectは、ユーザー側のデータセンターから、AWSのデータセンターに配置されているVPCへ専用線接続を確立するためのネットワーキングサービスです。

AWS Direct Connectによる接続を確立することで、オンプレミスネットワーク内のサーバーと、VPC内のリソース間でプライベートIPアドレスを使った通信が行えるようになります。

AWSのVPCやEC2を展開するデータセンターの具体的な所在地は明かされておらず、AWSのユーザーや弊社のようなAWSパートナー企業も立ち入ることはできません。

そのような環境に、どうやって専用線接続を確立するのかについて、以下の図で解説します。

AWS Direct Connectのエンドポイントは、データセンター事業者管理の(※AWSのデータセンターではない)データセンターに展開されています。この、AWS Direct Connectのエンドポイントが存在するデータセンターは「Direct Connectロケーション」と呼ばれます。Direct Connectロケーションを提供する事業者(*)としては、日本ではアット東京やエクイニクス等が挙げられます。

図中のオレンジ枠の範囲は、AWSのユーザーがコンソールで設定する範囲です。そして、青枠の範囲は顧客あるいはDirect Connectパートナーとして認定されているネットワーク事業者が設定する範囲です。これらのルーター間を相互に接続(クロスコネクト)することで、オンプレミスとVPC間で閉域接続が行えるようになります。

(*)Direct Connectロケーションの一覧(参考)
https://aws.amazon.com/jp/directconnect/locations/

AWS Direct Connectを利用するメリットとして以下があります。

AWS Direct Connectを用いることで、通信のセキュリティを強化できます。

AWS Direct Connectの通信においては、ネットワークインフラはAWSが厳重に管理しています。また、利用ユーザーが限定されているため、インターネット回線を用いたネットワークに比べセキュリティ攻撃や盗聴のリスクが低いです。

ただし、AWS Direct Connectによる通信はデフォルトでは暗号化されない点にご認識ください。

AWS Direct Connectでは、通信品質の安定性が期待できます。

インターネット回線でよく利用されるベストエフォート型の契約では、帯域を多数のユーザーで共有利用するため、混雑時は通信品質が低下する可能性があります。

一方、AWS Direct Connectでは、プランごとに設定された帯域を確保することができるため、安定した通信品質が期待できます。

AWS Direct Connectでは、通信容量あたりに発生するコストが比較的低いです。
そのため、通信量が多くなればなるほどAWS Direct Connectを利用することによるコストメリットが高まります。

なお、AWS Direct Connectには固定料金も発生します(詳細は後述します)。固定料金に関しては、AWS Site-to-Site VPNの方が低く設定されている(*)ため、通信量が少なく、かつ高い通信品質が必要ない場合には、費用対効果としてAWS Site-to-Site VPNに分があります。

(*)参考：AWS Site-to-Site VPNの料金
https://www.ashisuto.co.jp/db_blog/article/aws-vpn.html#Index-6

オンプレミスとVPC間のプライベート通信を可能にするソリューションとして、AWS Site-to-Site VPNもよく話題にあがります。これらのソリューションは、比較観点によって一長一短です。

要件ごとに、適切に使い分ける必要があるため、各ソリューションのメリットデメリットを押さえておきましょう。以下の表をご確認ください。

なお、この2つのソリューションは併用(AWS Direct Connectの通信を、AWS Site-to-Site VPNで暗号化する)することも可能です。併用することで、両者の不足部分を補う構成とすることも可能です。

AWS Direct Connectを構成するリソースとして「接続」と「仮想インターフェイス」があります。「接続」は、イーサネットの物理ポートを確保するリソースです。その「接続」のポート帯域を割り当てて「仮想インターフェイス」を作成します。この仮想インターフェイスを利用して、AWS Direct Connectによる通信を確立することができるようになります。

この「接続」と「仮想インターフェイス」は、用途の異なる複数の種類があります。AWS Direct Connectを適切に活用するためには、この種類に関する理解が必要なため、本章で解説します。

専用接続

単一のユーザーが、物理イーサネットポート単位での接続を保有する方式です。一般的に、ネットワーク事業者がこの接続を保有(*)し、その中で作成したホスト接続をエンドユーザーに提供します。提供されている帯域は1 Gbps、10 Gbps、100 Gbpsです。なお、利用できる帯域はDirect Connectロケーションによって異なります。

(*)「専用接続」を保持し、そこから分割して作成した「ホスト接続(後述)」をエンドユーザーに提供する事業者を「Direct Connectパートナー」と呼びます。

イメージは以下のとおりです。

ホスト接続

専用接続を論理的に分割した接続です。一般的に、Direct Connectパートナーに所属する事業者が、自身が保持する専用接続を分割して、エンドユーザーに提供します。

提供されている帯域は50 Mbps、100 Mbps、200 Mbps、300 Mbps、400 Mbps、500 Mbps、1 Gbps、2 Gbps、5 Gbps、10 Gbps、25 Gbpsです。

イメージは以下のとおりです。

AWS Direct Connectによる通信を確立するには、単に「接続」を用意しただけでは不十分です。「仮想インターフェイス」の作成が必要になります。仮想インターフェイスは、専用接続またはホスト接続を指定して作成するリソースで、これを仮想インターフェイスをVPC側のゲートウェイリソースに関連付けることにより、オンプレミスとVPC間の通信を確立できます。

仮想インターフェイスは、用途に応じて、3つの種類があります。それぞれについて解説します。

Private VIF

VPCに対するプライベート通信を確立するために利用します。

関連付けるゲートウェイはDirect Connectゲートウェイか、仮想プライベートゲートウェイのいずれかです。

Public VIF

デフォルトでVPCに属さないAWSサービスのAPIに専用線を用いた通信を行うために利用します。

ゲートウェイの関連付けは必要ありません。

Transit VIF

Transit Gatewayに接続を確立するために利用します。関連付けるゲートウェイはDirect Connectゲートウェイです。

AWS Direct Connectは、オンプレミスとクラウドのシステム間通信によく用いられます。その際、システムの稼働に影響を与えないよう、どのような冗長構成を取るかを検討することが重要です。

以下にAWS Direct Connectを用いる際の高可用性構成パターンをいくつかご紹介します。

複数のDirect Connectロケーションで接続を確立する構成です。

複数のDirect Connectロケーションで接続を確立し、かつ同一Direct Connectロケーション内で複数接続確立する構成です。最も高価ですが、最も高い信頼性を実現できます。

AWS Direct Connectによる接続を1つ確立しつつ、バックアップ回線としてAWS Site-to-Site VPNを用いる構成です。

通常時の通信にはAWS Direct Connectを利用し、障害発生時にはAWS Site-to-Site VPNに切り替える構成を取ることで、AWS利用コストを抑えつつシステムの信頼性を高めます。

この構成を取る場合、AWS Direct Connectの障害発生時には通信品質が劣化することは許容する必要があります。

　アシストの「AWS環境構築支援」とは？

本章にて、設定の例をご案内します。

※「Megaport」というクラウド接続サービスを用います。Megaportは、Direct ConnectロケーションにおいてDirect Connect接続の専用接続を契約しており、ユーザーにホスト型接続(VIF)を提供するネットワークサービスです。

まずは、今回の手順における構成の全体像と、AWS Direct Connectの主要な構成要素について解説します。

構成の全体像は以下のとおりです。

AWS Direct Connectに関する主要な構成要素について解説します。

今回使用するのは、プライベート仮想インターフェイスです。ホスト型の契約にあたり、専用型の接続はMegaport社が契約しているイメージです。

Direct Connect接続時のゲートウェイです。Direct Connectゲートウェイを間に挟むことで、単一の仮想インターフェイスによって複数のVPCとAWS Direct Connect接続を確立することができます。

(Direct Connectゲートウェイと仮想プライベートゲートウェイは1対多関係)

VPC側の接続ゲートウェイです。VPCが外部のネットワークと通信する際の出入口になるコンポーネントです。仮想プライベートゲートウェイは、VPCに対し1つだけ関連付けることができます。

仮想プライベートゲートウェイを仮想インターフェイスと直接関連付けることもできますが、その場合、AWS Direct Connectでオンプレミスと接続を確立できるVPCは1つだけになってしまいます(仮想インターフェイスと仮想プライベートゲートウェイは1対1関係のため)。そのため、AWS Direct Connectは、Direct Connectゲートウェイを用いる構成が推奨です。なお、Direct Connectゲートウェイは無料で利用できます。

まず、AWS側の基本リソースをCloudFormationを用いて作成します。

以下の赤枠内のリソースを展開します。

ここでは、VPCおよびEC2関連の以下リソースを展開します。
・VPC

・サブネット

・ルートテーブル ※「ルート伝播」を有効化

・仮想プライベートゲートウェイ

・EC2インスタンス

・セキュリティグループ ※ICMP通信を許可するルールを追加

1.1 以下を、ローカル環境に拡張子「.yaml」のテキストファイルとして保存します。

AWSTemplateFormatVersion: '2010-09-09'
Description: AWSリソースを作成するCloudFormationテンプレート
Parameters:
  InstanceAMI:
    Type: String
    Description: EC2インスタンスのAMI IDを指定してください。Windows OSのAMIを選択してください。
  InstanceType:
    Type: String
    Default: t2.micro
    AllowedValues:
      - t2.micro
      - t2.small
      - t2.medium
      - t3.micro
      - t3.small
      - t3.medium
    Description: EC2インスタンスのインスタンスタイプを選択してください。
  KeyName:
    Type: AWS::EC2::KeyPair::KeyName
    Description: EC2インスタンスのキーペアを指定してください。
  WindowsPassword:
    Type: String
    NoEcho: true
    Description: Windowsサーバのログインパスワードに設定する文字列を入力してください。
Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 172.35.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
  VirtualPrivateGateway:
    Type: AWS::EC2::VPNGateway
    Properties:
      Type: ipsec.1
      AmazonSideAsn: 64512
  AttachVPNGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref MyVPC
      VpnGatewayId: !Ref VirtualPrivateGateway
  MyRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref MyVPC
  MySubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: 172.35.1.0/24
      AvailabilityZone: !Select [0, !GetAZs '']
  SubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref MySubnet
      RouteTableId: !Ref MyRouteTable
  MySecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow ICMP
      VpcId: !Ref MyVPC
      SecurityGroupIngress:
        - IpProtocol: icmp
          FromPort: -1
          ToPort: -1
          CidrIp: 0.0.0.0/0
  MyEC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref InstanceAMI
      InstanceType: !Ref InstanceType
      KeyName: !Ref KeyName
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref MySubnet
          AssociatePublicIpAddress: false
          GroupSet:
            - !Ref MySecurityGroup
          PrivateIpAddresses:
            - Primary: true
              PrivateIpAddress: 172.35.1.10
      UserData:
        Fn::Base64: !Sub |
          
          net user Administrator ${WindowsPassword}
          netsh advfirewall set allprofiles state off
          

1.2 CloudFormationコンソールにアクセスします。
https://ap-northeast-1.console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/getting-started

1.3 「スタックの作成」をクリックします。

1.4 以下のとおり指定し、「次へ」をクリックします。

テンプレートの準備：既存のテンプレートを選択

テンプレートの指定：テンプレートファイルのアップロード

アップロードファイル：「1.1」で作成したファイル

1.5 以下の項目にそれぞれ入力し、「次へ」をクリックします。

スタック名：任意のスタック名(ここではstack-01を指定)
InstanceAMI：Windows OSのAMI名
インスタンスタイプ：任意のインスタンスタイプ(ここではt3.mediumを指定)

KeyPairName：任意のキーペア

WindowsPassword：任意のパスワード文字列

その他はデフォルト指定のまま進み、「送信」をクリックします。その後、リソース作成が開始します。

1.6 数分経過後、スタックのステータスが「CREATE_COMPLETE」となったことを確認します。

AWS側リソースの準備として、Direct Connect ゲートウェイを作成します。

2.1 Direct Connect Gatewayコンソールにアクセスします。

https://us-east-1.console.aws.amazon.com/directconnect/v2/home?region=ap-northeast-1#/dxgateways

2.2「Direct Connect ゲートウェイを作成する」をクリックします。

2.3 以下の項目に入力し、「Direct Connect ゲートウェイを作成する」をクリックします。

名前：MyDXGW

Amazon 側の ASN：64512

2.4 リソースが作成され、状態が「available」となっていることを確認します。その後、Direct Connect ゲートウェイのIDをクリックし、詳細画面にアクセスします。

2.5 Direct Connect ゲートウェイに仮想プライベートゲートウェイを関連付けます。「ゲートウェイの関連付け」タブ-「ゲートウェイを関連付ける」の順にクリックします。

2.6 以下項目に入力し、
ゲートウェイ：「1.6」で作成された仮想プライベートゲートウェイを選択し、「ゲートウェイを関連付ける」をクリックします。

2.7 Direct Connectゲートウェイに仮想プライベートゲートウェイが関連付けられたことを確認します。

　アシストの「AWS環境構築支援」とは？

以下の手順を実施することで、Megaportが保持するホスト型接続が、ユーザー側に提供されます。

※Megaportの管理画面へのログイン手順は割愛いたします。

3.1「Destination Type」として「Cloud」を選択します。

3.2 以下のとおり選択し、「Next」をクリックします。

Select Provider：Amazon Web Services
AWS Connection Type：Hosted VIF

Select Destination Port：Asia Pacific(Tokyo)(ap-northeast-1) Equinix TY2, Tokyo

3.3 以下のとおり入力し、「Next」をクリックします。

Connection Name：MyVXC

Rate Limit：100

VXC：State：Enabled

Preferred A-End VLAN：10

Minimum Term：No Minumum Term

3.4 以下のとおり入力し、「Next」をクリックします。

Type：Private

AWS Connection Name：MyVXC

AWS Account ID：プライベート仮想インターフェイスを作成したいAWSアカウントのID

Customer ASN：64500

BGP Auth Key：Test BgpKey

Customer IP Address：192.168.1.1/30

Amazon IP Address：192.168.1.2/30

3.5 入力内容を確認後、「Add VXC」をクリックします。

3.6 MyVXC(Design)が作成されたのを確認し、画面左側の「Configured Services」-「Order」をクリックします。

3.7 「No Minumum Term」と表示されていることを確認し、「Order Now」をクリックします。

3.8 MyVXC(Deployable)と表示されていることを確認します。

ここまでの手順で、Megaport社が保持しているDirect Connect接続の中のプライベートVIFが、ユーザー側のAWSアカウントに共有されます。その共有を承認し、自身のVPCと接続する設定を行います。

4.1 仮想インターフェイスコンソールにアクセスします。
https://us-east-1.console.aws.amazon.com/directconnect/v2/home?region=ap-northeast-1#/virtual-interfaces

4.2 「MyVXC」という名前の仮想インターフェイスが出現していることを確認します。この時点では状態は「Confirming」と表示されています。IDをクリックし、詳細画面にアクセスします。

4.3 詳細画面の右上の「承諾する」をクリックします。

4.4 以下のとおり入力し、「仮想インターフェイスを承諾する」をクリックします。

ゲートウェイタイプ：Direct Connect ゲートウェイ

Direct Connectゲートウェイ：MyDXGW

4.5 仮想インターフェイスの詳細画面にて、状態がpendingとなっていることを確認します。

4.6 Direct Connectゲートウェイの詳細画面にて、状態が「attaching」となっていることを確認します。

4.7 Megaportのコンソールを確認し、MyVXCのアイコンが緑色になっていることを確認します。

オンプレミスのルーターからコマンドを実行し、BGPを確立します。

本手順まで完了すれば、オンプレミスとVPC間でプライベート通信が可能になります。

なお、オンプレ側ルータ―にはYAMAHAのルーター RTX830を使用します。

5.1 ルーター管理用端末から、Teraterm等のエミュレータでルーター管理コンソールにアクセスします。

5.2 不要な設定が入るのを避けるため、設定を初期状態に戻しておきます。

> administrator
# cold start

5.3 ルータ設定コマンドを実行します。

# console columns 4096
# console lines infinity
# login timer clear
# ip lan1 address 192.168.200.254/24
# ip lan2 address 192.168.0.1/24
# vlan lan2/1 802.1q vid=10 name=VLAN10
# ip lan2/1 address 192.168.1.1/30
# vlan lan2/2 802.1q vid=3441 name=VLAN3441
# ip lan2/2 address 192.168.100.1/24
# bgp use on
# bgp autonomous-system 64500
# bgp neighbor 1 64512 192.168.1.2
# bgp neighbor pre-shared-key 1 text TestBgpKey
# bgp router id 192.168.1.1
# bgp import filter 1 include 192.168.200.0/24
# bgp import 64512 static filter 1
# bgp export filter 1 include 0.0.0.0/0
# bgp export 64512 filter 1
# telnetd service on
# telnetd host lan
# dhcp service server
# dhcp server rfc2131 compliant except remain-silent
# dhcp scope 1 192.168.200.1-192.168.200.10/24
# statistics traffic on
# bgp configure refresh

5.4 設定完了後、設定を保存しルーターを再起動します。

#save
#restart

5.5 再起動後、administrator権限でBGP確立状況を確認します。「BGP state = Established」となっていることを確認します。

> administrator
# show status bgp neighbor
BGP neighbor is 192.168.1.2, remote AS 64512, local AS 64500, external link
  BGP version 4, remote router ID 52.95.59.55
  BGP state = Established, up for 00:02:16
  Last read 00:00:19, hold time is 90, keepalive interval is 30 seconds
  Received 5 messages, 0 notifications, 0 in queue
  Sent 7 messages, 0 notifications, 0 in queue
  Connection established 1; dropped 0
  Last reset never
Local host: 192.168.1.1, Local port: 1047
Foreign host: 192.168.1.2, Foreign port: 179

5.6 ルート設定を確認し、種別=「BGP」となっている経路情報が表示されることを確認します。

BGPによって、VPC側から経路が伝播されてきていることを示します。

# show ip route
宛先ネットワーク    ゲートウェイ     インタフェース  種別  付加情報
172.35.0.0/16       192.168.1.2          LAN2/1       BGP  path=64512
192.168.0.0/24      192.168.0.1            LAN2  implicit
192.168.1.0/30      192.168.1.1          LAN2/1  implicit
192.168.100.0/24    192.168.100.1        LAN2/2  implicit
192.168.200.0/24    192.168.200.254        LAN1  implicit

5.7 . AWSの仮想インターフェイスのコンソール上でも、BGPステータスがUPになっていることを確認します。

ここまでの手順で、オンプレミスとVPC間のプライベート接続が確立できたことになります。

オンプレミス側の端末から、AWS側のEC2に疎通確認します。

6.1 コマンドプロンプトを開き、EC2のプライベートIPアドレスに対してpingを実行します。

C:\Users\xxxxx>ping 172.35.1.10
172.35.1.10 に ping を送信しています 32 バイトのデータ:
172.35.1.10 からの応答: バイト数 =32 時間 =4ms TTL=125
172.35.1.10 からの応答: バイト数 =32 時間 =5ms TTL=125
172.35.1.10 からの応答: バイト数 =32 時間 =5ms TTL=125
172.35.1.10 からの応答: バイト数 =32 時間 =4ms TTL=125
172.35.1.10 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 4ms、最大 = 5ms、平均 = 4ms

無事、EC2インスタンスと疎通確認ができました。

※BGPが確立できているにもかかわらず疎通に失敗する場合は、EC2側でセキュリティグループの通信許可設定が足りていない、あるいはルートテーブルの設定が不足している等の可能性が考えられます。

AWS Direct Connect設定の例は以上です。

AWS Direct Connectの課金要素は固定と従量の2つに分けられます。

AWS Direct Connectの有効な接続ポートごとに発生する料金です。専用接続とホスト型接続で料金体系が異なります。

※接続ポートに発生する費用は、日本以外の国では一律の価格設定です。そのため、以下の表では「ポート料金(日本以外)」と「ポート料金(日本)」の2つの情報をまとめます。
※専用接続で利用できる容量はDirect Connectロケーションによって異なります。最新情報は以下を参照ください。
　AWS Direct Connect Locations
　https://aws.amazon.com/directconnect/locations/

専用接続のポート料金

ホスト型接続のポート料金

従量課金は、データ転送量に応じて発生します。

まず、VPCから見た時のデータ転送イン(オンプレミスからDirect Connectロケーションに向かっていく通信)には費用がかかりません。

VPCから見た時のデータ転送アウト(Direct Connectロケーションに向かっていく通信)には、発信元リージョンと発信先のDirect Connectロケーションの所在地に応じて以下のとおり課金されます。

※行方向に列挙しているのが発信元、列方向に列挙しているのが発信先です。

※課金はGBあたり

料金の例を示します。

ポート料およびデータ転送料の前提は以下のとおりとします。

ポート料金

・2つのDirect Connectロケーション

・ホスト型接続

・ポート容量＝1 Gbps

・30日間使用(730時間)

データ転送料金

・転送元は東京リージョン(ap-northeast-1)

・転送先のDirect Connectロケーションの所在地は東京

・通信データ量は1,024 GB

参考：AWS Direct Connectの料金
https://aws.amazon.com/jp/directconnect/pricing/

ここまでで、AWS Direct Connectの概要、メリット、設定例、料金について解説しました。

本記事を通して、AWS Direct Connectの基本を理解いただき、より良いクラウドネットワーク構成の検討につなげていただければ幸いです。

なお、弊社でも、AWS Direct Connectを含むAWSネットワークの設計および実装のご支援が可能です。オンプレミスネットワークとAWSを組み合わせたハイブリッド構成を組みたいご要望がありましたら、ぜひ弊社にご相談ください。

　アシストの「AWS環境構築支援」とは？