【日本初導入】 AWS Outposts ラックを徹底解説 第1回 〜導入・利用方法の概要〜

はじめに

こんにちは、イノベーションセンターの福田・鈴ヶ嶺です。 普段はクラウドサービスをオンプレ環境でも同様のUI/UXで使用を可能とするハイブリッドクラウド製品の技術検証をしています。

本記事は、今回日本で初めて導入した AWS Outposts ラックの仕様、導入方法、利用方法について徹底解説します。次の画像は、実際に導入した AWS Outposts ラックの画像です。

f:id:NTTCom:20220315105105p:plain

NTT Com では「Node-AI on AWS Outposts」に関するニュースリリースを2022年3月14日に発表いたしました。 今後は「Node-AI on AWS Outposts」を軸に、自社の多様なサービスやソリューションと組み合わせることで、AWSをご利用されるお客さまのデジタルトランスフォーメーションを支援していきます。

国内初、「AWS Outposts」に自社データ分析ツールを組み込んだソリューションを開発

f:id:NTTCom:20220314133107p:plain

AWS Outposts ラックとは

AWS Outposts ラックは AWS が出しているハイブリッドクラウド AWS Outposts ファミリーの一部であり、42Uの専用ラックをデータセンターなどのオンプレ環境に設置して使用します。 以降は簡易に Outposts と記述します。

Outposts は、 AWS のサービスを

  • オンプレミス上で
  • Public AWS と同じ体験で

実現してくれるものです。 実際、各種 API も展開先の Outposts ARN を指定したりするプロパティが追加される等、 Outposts で利用したいリソースと Public 上の AWS で利用したいリソースとの間で API が分離されているということは(一部を除いて)ありません1。 つまり、慣れた AWS API の中でデプロイ先 Outpost 筐体を指定すれば Outpost 筐体上でリソースが展開されるようになっています。

ただし、AWS Outposts 上で展開されるサービスは AWS のフルセットではなく、サブセットになります。 具体的には、 EC2, S3, EKS などの AWS サービスが実行可能です2

Outposts は提供されるハードウェアも含めて AWS によるフルマネージドな管理がなされます。 これによって従来のオンプレシステムに比べて管理稼働の削減が期待されます。 例えば、Outposts 筐体のハードウェアが故障した際には AWS がハードウェア故障の調査をしてくれます。

ユースケース

Outposts の主なユースケースは次の通りです。

  • Public 上の AWS だとネットワークのレイテンシーが大きくなって要件に合わないような環境で、近接環境に AWS Outposts をデプロイすることで、レイテンシーを低減しながら AWS サービスを利用する
  • データレジリエンシーの観点からクラウドにデータを流せないような地域でも AWS Outposts をデプロイすることでデータを特定の地域に留めつつ AWS サービスを利用する
  • 外出しできないようなデータがあるような場所に AWS Outposts をデプロイすることでデータを中に留めつつ AWS サービスを利用する
  • オンプレ環境に Outposts をデプロイし、一部サービスをそちらに移行することで段階的にクラウド化を実施する

Outposts を使えばこれらの要件を満たしつつ、クラウドサービスの恩恵を受けることができます。 例えば、次のような環境の場合、 Public 上の AWS を利用するには Public なインターネットを通したり、 AWS の提供する網内を通るためにクラウドサービスを利用できませんでした。

  1. セキュリティ保護要件上データはオンプレ上に保管
  2. オンプレ環境からのみデータへのアクセスを可能にしなければならない

AWS Outposts を利用すれば、このような環境でもオンプレ内にデータを留めたまま EC2 インスタンスでそのデータを処理するといったことを実現できます。

f:id:NTTCom:20220304170142p:plain

AWS Outposts の立ち位置

運用面ではデプロイ先リージョン内の AZ へ紐付く形になります。 例えば ap-northeast-1 リージョンにデプロイし、 ap-northeast-1a に紐付けるという形で運用します。 形としてはある AZ が AWS Outposts によって拡張されるようなイメージです。

f:id:NTTCom:20220304170150p:plain

したがって、 Outpost 筐体を利用する場合はリージョンだけでなく AZ のレベルを意識しておく必要があります。

データの暗号化

Nitro システムを搭載しているため、 Outpost 筐体内のデータは全て暗号化されています。 Public AWS との接続にも Service Link を介して接続 されており、転送時にもしっかり暗号化されます。

AWS Outposts には Nitro Security Key という機器が設置されており、その機器がデータの暗号化を担当しています。 復元もこの機器が担当しているため、この機器を破壊すると内部のデータの復元は困難となります3

Outposts 導入要件

Outposts はここまで述べたように、従来 Public クラウドで利用が難しかった局面でもクラウドサービスを利用できるようにしてくれるサービスです。 そんな夢のようなサービスですが、 Outposts 導入には幾つかの要件が存在します。

  1. AWS Direct Connect を用いた AWS リージョンの接続
    • 専用線を用意するには準備に多くの稼働や時間が必要となります
    • 接続するネットワークの帯域も AWS から指定されています
  2. ラック、ネットワークに関する責任
    • Outposts ラックの物理的なセキュリティの責任を負います
    • Outposts へのネットワーク接続の一貫性の責任を負います

今回、私達が実際の構築にあたった際には社内で提供しているサービスを利用して構築しました。 これによって要件を満たしつつ、迅速に AWS Outposts を利用することが可能となりました。

NTT ComによるOutpost導入方法

AWS Direct Connect を用いた AWS リージョンの接続

Outposts は AWS リソースとの連携を可能とするために AWS リージョンとの接続が必須となります。 この接続は、 Service Link と呼ばれ AWS Direct Connect を利用した専用接続が必要になります。 データ伝送速度は 1Gbps 以上が推奨されています。 通常 AWS Direct Connect などの専用線を用意するには多くの稼働や NW 機器などのハードウェアの準備が必要となりますが、 NTT Com の次世代インターコネクトサービス Flexible InterConnect(FIC)FIC-Connection AWS を用いることで迅速に安定した接続を可能とします。 また、 FIC は最大 10Gbps の広帯域接続にも対応しているため高品質なネットワークを提供できます。

次の画像はFICのポータルです。このように専用の物理的な拠点とAWSの閉域接続をポータルで設定・管理することを可能とします。 f:id:NTTCom:20220303174256p:plain

ラック、ネットワークに関する責任

Outposts の物理的なラックの安全性は利用者側で責任を負います。 導入には重量・電力制限などの様々な設備に対応する必要があります。 これらの課題に対して NTT Com のデータセンターサービス Nexcenter を利用することで対応できました。 Nextcenter では、グローバル統一の「設備基準」や「サービス運用基準」に準拠することで高品質なサービスを提供できます。 また、ネットワークに関してはデータセンター内接続、 FIC による AWS リージョン接続などのそれぞれの接続を冗長設計することにより安定した運用が実現可能です。

オンプレミスネットワークとの統合

オンプレミスネットワークとは Local Gateway を通して接続されます。 この Local Gateway へ与えられたルートテーブルに VPC を関連付けることで、その VPC 内のリソースとオンプレミスネットワークが通信可能な状態になります4

ただし、これだけでは各種 Outposts 内の AWS リソースへ通信はきません。 こちら側から IP アドレスプールを提供し、 Outposts 内の各種 AWS リソースに適切にその IP アドレスプール内にある IP アドレス5を付与する必要があります6。 例えば、 EC2 インスタンスであれば ENI にその IP アドレスプールから IP アドレスを付与し、その ENI をアタッチしなければオンプレミスネットワークと接続はできません。

もし VPC と Local Gateway の関連付けを行わなかった場合、例え与えた IP アドレスプールから ENI ヘ IP アドレスを払出していてもオンプレミスネットワークと通信できません。 これは Local Gateway のルートテーブルのみがオンプレミスネットワークの内容を知っていて、 AWS の提供する VPC 側は AWS Outposts の存在を知らないからです。 接続したければ、こちらから接続先を明示してあげる必要があるというわけです。

提供されるサービス

Outposts 上では様々なサービスを展開できますが、そのうち私達が試した Outposts 上で使用できるサービスについて解説します。

VPC と subnet

VPC は Local Gateway のルートテーブルを紐付ければ良いだけで他に設定は必要ありません。 一方、 subnet の方だけ Outposts 上で利用する設定が必要です。

subnet を作成する CreateSubnet API を見ればわかりますが、デプロイ時に Outpost ARN を指定することでその Outpost ARN を持つ Outpost 筐体上にデプロイされます。

注意点として、マネージドコンソール上から作成するには Outposts コンソールから行う必要があります。 現在の VPC コンソール上における subnet の作成画面には Outpost ARN を直接指定するインターフェースがないため、 VPC コンソールからは AWS Outposts 上に subnet を作成できません。 必ず AWS Outposts コンソール上から作成する必要があります。

使用感は Public 上の AWS へデプロイする普通の subnet と変わりません。 管理も AWS マネージドコンソール上からも可能です。 唯一、 subnet 上にのっているリソースだけ(設定していれば) Local Gateway を通してオンプレミスネットワークと疎通できるところが違います。

EC2 インスタンス

EC2 インスタンスを立ち上げる API を見ていただければわかるのですが、 EC2 インスタンスの操作自体は Outpost 上へデプロイする設定を持ちません。 代わりに、 Outpost 筐体上にデプロイしている subnet へ EC2 インスタンスをデプロイすることで自動的に Outpost 筐体上へインスタンスがデプロイされる仕組みになっています。

このインスタンスをオンプレミスネットワークと通信させるようにするには

  1. こちらが提供する IP アドレスプールから IP アドレスを割り当てられた ENI
  2. Local Gateway へのルーティング

がそれぞれ必要になります。

使用感は Outpost 上へデプロイしない他のインスタンスとまったく同じで、こちらも AWS のマネージドコンソールから管理が可能です。

Outposts 上で展開される EC2 で利用可能なインスタンスタイプについては Outpost 筐体注文時に指定します。 現在は m5, g4dn, c5, r5 などが指定可能です。

EBS Volume

CreateVolume API を見ると Outpost ARN を指定できるようになっていることが確認できます。

他の EBS Volume とは指定された Outpost 筐体上にデプロイされているところが違うだけで、 Public 上の AWS にあるインスタンスからもマウントでき、シームレスに連携できます。

S3 on Outposts

Outposts 上の S3 は S3 on Outposts と呼称されていますが、 S3 と S3 on Outposts は操作感が異なります。

  • オブジェクトを put する、などの操作にひと手間必要
  • 発行されるアクションが S3 と一部異なる
  • AWS CLI の high level な操作 (copy 等) は使えない
  • AWS マネージドコンソールからバケット内のオブジェクトが確認できない

などの違いがあります。

f:id:NTTCom:20220304170156p:plain

バケットへの接続

S3 on Outposts では以下のものを VPC に設置しなければバケットへ接続できません。

これらリソースを設置した上で、それらリソースが設置された VPC からのみアクセスが許可されています7

このように現在の S3 on Outposts を利用するには Public 上の S3 とは違ってひと手間必要になります。 こちらでも使用感がより良くなるよう気になるところは適宜フィードバックした上で改善を待っています。 皆さんも使用した上で気になる部分があれば AWS へフィードバックをお願いします。

API

さて、肝心の S3 on Outposts のデプロイについてですが、 S3 とは API がです。 Public AWS 上の S3 にバケットをつくるには Amazon S3 の CreateBucket API です。 一方、 S3 on Outposts にバケットをつくるには Amazon S3 Control の CreateBucket API です。 そもそもからして API が異なります。 他のサービスは同じ API 内にデプロイ先 Outpost 筐体を指定すればよかったのですが、これだけ例外で他のものと API レベルから分離されています8

EKS

Outposts 上で Amazon EKS ノードを実行しオンプレ環境でマネージド k8s サービスの利用を可能とします。 マネージド形ノードはサポートされておらず、自らEC2を作成してクラスターにノードとして登録するセルフマネージド型ノードのみがサポートされています。

セルフマネージド型ノードは AWS Outposts にデプロイできますが、マネージド型ノードや Fargate ノードにはデプロイできません。 https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/eks-on-outposts.html

また、コントロールプレーンである EKS クラスターは Public 上の AWS における subnet 上に作成する必要があります。

クラスターの作成時に、 Outposts サブネットを渡すことはできません。 https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/eks-on-outposts.html

Application Load Balancer

Outposts 上で Application Load Balncer(ALB) をデプロイするには c5/c5d, m5/m5d, r5/r5d インスタンスが必要となります。 また、オンプレミスネットワークから接続する場合はこちらが払出す IP アドレスプールから IP アドレスを割り当てる必要があります。

An Application Load Balancer can be deployed on c5/c5d, m5/m5d, or r5/r5d instances on an Outpost. The following table shows the size and EBS volume per instance type that the load balancer can use on an Outpost:

使用感としては普通の ALB と変わりません。 AWS 上のマネージドコンソールからも管理可能です。

容量

Outpost 筐体上に展開できる EBS や S3 ストレージのサイズ、 EC2 のインスタンス数の制限などは当然デプロイしている Outpost 筐体の物理的制約に依存します。 消費しているリソースや、空き容量といったものは Outposts コンソールからデプロイしている Outpost 筐体毎に確認できます。

使用できる空き容量がない場合、容量のないリソースのデプロイはできなくなります。 容量がない時にデプロイしようとするとデプロイは空きがでるまで待たされます。

ちなみに、 EC2 インスタンスの容量上限はインスタンスタイプ毎にあるので、 m5g4dn をそれぞれ利用できるようにした Outposts 筐体における EC2 インスタンスの上限は m5g4dn で別々です9

まとめ

本記事では

  • Outposts について
  • NTT ComによるAWS Outposts ラックの導入方法について
  • オンプレ環境との統合について
  • Outpostsで提供されるサービスについて

について記載しました。

Outposts はその使用感を Public 上の AWS と同じにしつつ、従来は難しかった場面でもクラウドサービスを利用できるようにしてくれる素敵なサービスであることが見ていただけたかと思います。 細かいところで注意すべき点があったりもしますが、それらを差し引いても AWS サービスをオンプレ内で、しかも外にデータを出さずに管理できるというところは魅力あるところです。 データ利用の壁があり、今まで Public クラウド上にあった AWS サービスを利用し辛かったところはこれを機に AWS Outposts の利用を検討してみてはいかかでしょうか?


  1. 例えば、サブネットを作る CreateSubnet API にデプロイ先 Outpost 筐体を示すための OutpostArn というプロパティが追加されていますが、 Outposts 専用に API は切られておらず、 Public のものと同一です(https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSubnet.html#API_CreateSubnet_RequestParameters)。

  2. 提供されるサービスについての詳細は 公式ページ へ譲ります。

  3. 「Q: データセンターに設置された Outposts ラックの物理的なセキュリティに対する責任を負うのは誰ですか?」 https://aws.amazon.com/jp/outposts/rack/faqs/

  4. デフォルトでは VPC と Local Gateway に与えられたルートテーブルは関連付けられていません。

  5. この IP アドレスプールのことを customer owned IP address または顧客所有の IP アドレス, CoIP と呼称します。

  6. customer owned IP address を持たせることは AWS API からはできるようになっていますが、一部 CloudFormation コンストラクターについては未対応です。そのため、 CDK 等を利用して IaC をやるのは現状では少し難しいです。これについては次回以降説明します。

  7. https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3OutpostsNetworking.html

  8. オブジェクトの操作 API 名はかわりませんが、 API に指定するバケット名は Public 上の S3 とは異なり、 S3 on Outposts 上のバケット名ではなく、バケットへの接続を確保している access point の ARN になります。

  9. ただし、 EBS 容量は全てのインスタンスタイプで共通してるので、そちらの上限にひっかかる可能性はあります。

© NTT Communications Corporation 2014