COLUMN

オンプレミスのADサーバーをAWSに移行する時の課題と注意点 セミナーレポート

【無料】ADサーバーのクラウド移行をご検討の方、お悩みの方はこちらからお問い合わせください。

2021年7月20日に開催されました「オンプレミスのADサーバーをAWSに移行する時の課題と注意点」のセミナーの模様をレポートさせて頂きます。

当日にお聞きいただけなかった方のご参考となれば幸いです。また、レポートをご覧になっての疑問点や質問事項などございましたら、お問い合わせを頂ければと思います。

1.オンプレミスActive Directoryサーバーの課題点と移行計画

とあるオフィス環境を例として、オンプレミスでActive Directoryサーバーが運用されている環境で課題となっているポイントをまとめ、その内容について解説しました。

オンプレミスActive Directoryサーバーの課題点とは

  • 保守・運用の課題

Active Directory自体のハードウェアをどのように保守・運用するか

  • BCP対策についての課題

データセンターやサーバー室が被災した時にどうやって事業を継続していくか

  • 冗長構成についての課題

支店や事務所と拠点との間に引かれたWANの回線が逼迫した際に備え、どう構成するか

以上がActive Directoryの課題点と考えられます。これらを解決していくためのクラウドの構成について解説していきました。

移行方針の検討

「移行方針の検討」というところで、一般的なAWSへの移行から着目していく。

AWSの移行は、まず「何をしたいのか?」というような目的を必ず明らかにして、「どのような戦略で行くか」という理解から始める。

これにより移行で取るべき戦略が変わる。

【移行の目的例】

  • 運用稼働を削減したい
  • トータルコストを削減したい
  • ハードウェアのサポート切れに対応したい
  • そもそものビジネスモデルを新しくしたい

Active Directoryの場合の移行戦略

Active Directoryの場合、「Replatform」と「Rehost」というような形での移行となるため、核となるビジネスのプロセスに余り変わりはない。

そのため主な戦略は以下の2つとなる。

  • マネージドサービスを検討する
  • 今あるオンプレミスサーバーをAmazon EC2に置き換える

Active Directoryの移行優先度

AWSの移行は緊急度の高いもの、移行難度の低いものと、順に検討していくのがおすすめ。

【緊急度の高いもの】

  • データ消失がビジネスリスクになる
  • ハードウェアのサポート切れ、OSのサポート切れが迫っている

 ⇒身近に迫っているものは緊急度高い

【移行難易度が低いもの】

  • 並行運用が可能
  • 夜間の利用が少なく一時的に停止が可能
  • データ移行手段が複数ある
  • 業務プロセスに影響の少ないもの

移行優先順位は優先緊急度の高いもの、移行難易度の低いものから検討

ファイルサーバーやActive Directoryサーバー、アプリケーションサーバーというような順番で決められていくパターンが多い。

これらは少しずつ移行してクラウドのノウハウを蓄積していくという方法がおすすめ。

Active Directoryの移行

緊急度の高いもの、移行難度の低いものと言う観点から、以下のようにActive Directoryは、優先的に移行できるものとなっている。

緊急度の観点:中

  • 冗長化することが一般的のため、データ消失リスクは低め
  • 一般的に冗長化されていることが多いので、1台ずつ移行できるため、リスクが低い

 移行難易度の観点:中

  • 並行運用が可能

既存 Active Directory サーバーと並行運用

  • 夜間一時的に止めることが可能
  • データ移行手段が複数ある

移行ツール例

CloudEndure Migration

Active Directory Migration Tool (ADMT)

マスタ移行・昇格

  • 業務プロセスの影響は少ないが、一方でクライアントのDNS等設定変更が必要なケースがある

これはオンプレミスの移行の場合と同じくAWSの移行でもあり得るパターンとなっている

Active DirectoryはIaaSまたはPaaSでの構築がおすすめ

オンプレミスはサービスレベルを自身で決められる反面、設計をはじめ、検討項目が多く、構築のリードタイムが長くなりやすい。

IaaS/PaaS は設計の自由度と料金面で柔軟性が確保でき、構築のリードタイムも短くできる。

  オンプレミス構築 IaaS/PaaS
データの所有権 自身 自身(AWSの場合)
可用性 自身で設計 自身で設計
セキュリティ 自身で設計 責任共有モデルに準ずる
容量・性能 自身で設計 自身で設計
伸縮性 リードタイムあり 即時対応可
保守対応 全て自身で設計 責任共有モデルに準ずる
料金

初期費 サーバー・ネットワーク物品費・設定費

Active Directory 設定費

Active Directory設定費
料金

運用費 サーバー保守料金(固定費用)

データセンタ・サーバー室利用料(固定費用)

Active Directory運用費

Active Directory運用費

クラウド利用料(従量課金)

Active Directoryと Azure AD の違い

Active Directoryには他にAzure ADというものがある。

Azure ADとは

  • Azure AD は SaaS の ID 管理ユーザ管理やシングルサインオンを目的としており、利用目的が異なる
  • 既存の置き換えではなく、既存のActive DirectoryとAzure ADを組み合わせて使用されることが多い

【無料】ADサーバーのクラウド移行をご検討の方、お悩みの方はこちらからお問い合わせください。

2.AWSで Active Directory を利用する構成と移行方法

次にAWSでActive Directoryを利用する際に構築可能な3つのパターンについて構成例を交えて紹介しました。

IaaS、PaaSで構築するということから、多くは以下の3つのパターンとなる。

  Active Directory サーバー on EC2 AWS Directory Service (Simple AD) AWS Directory Service (Managed Microsoft AD)
おススメケース オンプレミスWindows Server での運用とあまり変えたくない人向け 小規模なディレクトリやAWS 内で完結する方向け 高い可用性と耐久性が必要なActive Directory を新たに構築したい方向け
OSの保守・運用 自身で設計 AWS側で管理 (Samba4 ベース) AWS側で管理 (Windows Server 2012 R2 ベース)
セキュリティ 自身で設計

CloudTrailを利用した監査ログの取得が可能

自動アップデート

CloudTrailを利用した監査ログの取得が可能

自動アップデート

バックアップ 自身で設計

AWS側で設計

手動でスナップショット取得も可

AWS側で設計

手動でスナップショット取得も可

可用性と耐久性 自身で設計 AWS側で設計 AWS側で設計
ユースケース
  • Active Directory 最新版の機能を使いたい
  • ハイブリッド構成かつシングルドメイン
  • 小規模なユーザ管理、高度なグループポリシーを使用しない
  • AWS 内で完結する
  • 高い可用性と耐久性が必要
  • オンプレとは信頼関係でよい

①Active Directory サーバー on EC2

オンプレミスWindows ServerをAmazon EC2で立てるため、殆ど変えることなく使うことが出来る。

オンプレミスWindows Server での運用とあまり変えたくない方におすすめ。

Amazon EC2(以下、EC2)

安全でサイズ変更が可能なコンピューティング環境

  • vCPU やメモリに加えて、ネットワーク帯域や GPU の有無など環境に合わせて選択可能
  • WindowsやLinux など複数の OS から選択可能

メリット

  • Windows Server の標準機能が利用可能
    ⇒他の Windows 対応アプリケーション ファイルサーバー等 と重畳させることも可能
  • 操作手順はオンプレミスとあまり変わらない
    (OS を変えた場合はGUIが変わるので、操作手順は変わる)
  • Windows Server 2019 を利用した場合 Active Directory の最新版の機能を利用可

デメリット

  • OS 以上のレイヤは運用保守の検討が必要 (Windows Update など)
  • 冗長化も可能だが、 EC2 を複数台立てた上で冗長化設計が必要
  • 大規模な環境などで高性能なEC2や冗長化対応などでEC2を3台以上で利用すると、高額な料金になる場合がある

2つのサブネット、またはアベイラビリティゾーンを分けて構築をすることで冗長化を行ってロケーションの冗長化を実現

2つのサーバーをマスタとスタンバイに分けて構築することも可能

拠点とAWS間をVPNで接続し、拠点のクライアントとEC2のIPアドレスに分けて接続

②AWS Directory Service (Simple AD)

小規模なディレクトリやAWS 内で完結する場合におすすめ。

Simple AD

Samba4互換のマネージド AD サービス

  • スモール 最大 500 ユーザ 、ラージ 最大 5,000 ユーザ をサポート
  • 2つのアベイラビリティゾーンで冗長化、どの時点まで戻しますか?というポイントインタイムリカバリの実行可能
  • Samba4互換なので一般的なMicrosoft Active Directoryの機能を使用可

メリット

  • 手軽に可用性や対障害性を向上させることができる
  • ユーザの一括移行がデータのin/outで実現することが可能
  • 従量課金で利用可能(東京リージョンの場合、ドメインコントローラ1つあたりスモール 0.08USD/h ラージ 0.24USD/h)

デメリット

  • AWS 外のコンポーネントの管理ができない
  • 既存ドメインとの信頼関係の設定不可
  • ユーザ管理用に別途 EC2 インスタンスが必要

Amazon WorkSpacesという仮想デスクトップサービスが拠点のクライアントと繋がる形になる。

ドメイン参加できるのはAWSの中だけなので、WorkSpacesから接続してくる必要がある。

以上のような形で、少し構成に工夫が必要と言うのが、注意点となる。

③AWS Directory Service (Managed Microsoft AD)

高い可用性と耐久性が必要なActive Directory を新たに構築する際におすすめ。

Managed Microsoft AD

Windows Server 2012 R2のマネージド Active Directory サービス

  • Standard(最大30,000オブジェクト、Enterprise(最大 500,000)をサポート
  • 2つのアベイラビリティゾーンで冗長化、ポイントインタイムリカバリを実行可能
  • マルチリージョンでのレプリケーション可能なので、複数のリージョンで冗長化や復旧実行するような大規模な障害にも対応が可能

メリット

  • 手軽に可用性や対障害性を向上させることができ、大規模な運用が可能
  • 信頼関係を結ぶことができるため、既存のAD と簡単に統合可能
  • Amazon WorkDogsなどのAWS 各種サービスとのシングルサインオンが利用可能

デメリット

  • Windows Server 2016 以降に追加されたActive Directoryの機能は利用不可
  • シングルフォレスト・シングルドメイン構成が必須
  • WindowsのAdministrator 権限は利用不可。別途AdminがAWSから付与される
  • Simple ADと比較すると料金やや高め

(東京リージョンの場合、 Standard 0.146USD/h、Enterprise 0.445USD/h)

拠点側のADサーバーと信頼関係を結んでおけば、ハイブリッドで使うことも可能。

AD Connectorというサービスを使うことでAD同士の相互認証も実現可能。

ハイブリッド方式

ここまでがAWSだけを使ったサービスの話でしたが、もしも、AWSを使っているリージョンで障害が発生し、ADが利用不可となった場合、ユーザがクライアントを使えなくなる事態が考えられます。

そのような事態に対応するには、AWSだけではなくハイブリッドで使うという選択肢を取ることができます。

ここからは、拠点とAWSの双方を使用するハイブリット方式の解説をしました。

1つ目のタイプ

拠点のActive Directoryは残しておき、新たにAWS側のManaged Microsoft ADを使用する場合。

2つのドメインを作成することで、信頼関係を構築するというような形を取ることが出来る。

こうした形態では以下のような管理を行う

  • 拠点のコンピューターの管理はオンプレミスのActive Directoryで行う
  • AWSに移行したサーバーの管理はAWSのクラウドの方での管理を行う

2つ目のタイプ

Active Directoryはハイブリッドで使用するが、同じドメインとしたい場合。

この場合は、Active DirectoryにManaged Microsoft ADを使わずにActive Directoryサーバーon EC2を使用する。

この際、冗長化のため2台作成し、更に管理用のEC2を1台用意した3台で1つのドメインとして構築する。

これにより、万が一どちらかの拠点が使えなくなってしまった場合でも相互に保管が可能となる。

また、基本は例えばAWSを使い、もし何かあった時にオンプレミスの方を使うと言うようなことも可能になる。

AWSへの 経路のセキュリティ確保

AWSと拠点間の接続の経路の話を簡単に紹介いたしました。

拠点とAWS間は安全に繋ぐ経路が必要になってきます。こういったところの経路につきましては暗号化やVPN等の方式が使うことが出来ます。

インターネット接続を利用の場合

  • 経路でのセキュリティ確保は行わず、httpsによる暗号化通信でセキュリティを確保

最も手軽で安価

セキュリティレベルは最も低い

  • インターネットVPNを利用

一般のインターネット回線上にVPNトンネルを仮想的に構築

閉域ネットワークより安価で導入しやすい

インターネット接続環境としては高いセキュリティレベルを確保

閉域ネットワークを利用の場合

  • IP-VPNで閉域ネットワークを利用

通信事業者が独自に保有する閉域ネットワークを仮想的な専用ネットワークとして複数のユーザで共用し利用するサービス

NTT東日本のサービスを使って閉域ネットワークと一緒に繋ぐことも可能

インターネットVPNより高価

  • 専用線を利用

最も高価

セキュリティレベルは一番高い

Active Directoryのデータ移行

構成に応じて利用できる移行ツールは異なるため、状況に応じて利用する。

  Active Directory サーバー on EC2 AWS Directory Service (Simple AD) AWS Directory Service (Managed Microsoft AD)
Cloud Endure Migration

△データ同期

※切替時 DB 不整合に注意

× ×
ADMT+PES △(Windows 2012 以前) ×

データエクスポート

データインポート

マスタ移行・昇格 × ×

【参考】その他設計上の注意点

フォレスト/ドメイン/OU設計/サイトトポロジ

これまでのActive Directoryの設計方針と同じ。

アプリケーション側のActive Directoryの設計は、これまでの思想と同じなので従来と変わらずに考えていく必要がある。

VPC/ネットワーク関連

  • アベイラビリティゾーンを 1つの個別データセンターとしてみなし、複数のアベイラビリティゾーンに配置を推奨
  • オンプレミスとAWSの間のネットワーク間に冗長構成の検討を推奨
  • セキュリティグループの制御を行う
    (必要なポート:https://learn.microsoft.com/ja-jp/archive/blogs/jpntsblog/563 )
  • オンプレミスに対してAWSから名前解決が必要な場合は、DNSサーバーやフォワーダの設計を行う
  • FSMO(Flexible Single Master Operation:ドメインコントローラの操作マスタ)は冗長構成をとれないので、「スタンバイ操作マスタ」を用意する

バックアップリストア関連

  • EC2 の場合、Windows Server上のVolume Shadow Copyサービスを有効化するかActive Directory 互換のバックアップツールを使用する
  • バックアップデータが保管されているボリュームのスナップショット取得の自動化を行う
  • ドメインコントローラ全体のスナップショットは取得しない (DB 不整合を起こすため)

管理端末関連

インターネットから管理端末の操作が必要な場合、踏み台サーバーやリモートデスクトップ可能な端末を用意する

【無料】ADサーバーのクラウド移行をご検討の方、お悩みの方はこちらからお問い合わせください。

3.AWS移行後のActive Directoryの運用

運用について、考慮が必要な運用作業は各パターンによって異なる。

考慮が必要な運用作業

  Active Directory サーバー on EC2 AWS Directory Service (Simple AD) AWS Directory Service (Managed Microsoft AD)
ハードウェアの保守・運用 AWS側で管理 AWS側で管理 AWS側で管理
OSの保守・運用 必要 AWS側で管理 AWS側で管理
Windows Updateの適用 必要 AWS側で管理 AWS側で管理
バックアップ 必要 AWS側で管理 AWS側で管理
ユーザ追加等 必要 必要 必要

Active Directoryサーバー on EC2の場合

OS以上の機能を管理する必要がある

AWS Directory Service (Simple AD、Managed Microsoft AD)の場合

バックアップやWindows Updateといったような管理についてはAWS側で実施

どのサービスを使っても、ユーザ追加やグループポリシーといったようなActive Directoryの機能についてはユーザ自身で実装していく必要がある。

運用の効率化(アウトソース)

Windows Update 等、定常作業は自動化を検討する。

非定常作業だがユーザ追加をしたい、アクセス権を変えたい、グループポリシーをいじりたいなどの保守運用にかかわる作業についてはアウトソースも検討する。

NTT東日本の運用サービスの中でもActive Directoryのユーザ追加や削除を行っています。

また、AWSの設定変更や監視や障害の一時対応と言った様な事も行っています。

こちらも定常作業となってくるので、アウトソースが検討出来るようになっています。

例えばAWSの設定変更ですと、「EC2のスペックを変えたい」「EBSの容量を少し増やしたい」「セキュリティグループの追加の設定をして、セキュリティを高めたい」の他に「拠点が増えたのでVPNを増やしたい」と言うよう事も出来ます。

また、以下のようなケースでもアウトソースが検討できるようになっています。

  • システムの正常性の監視
  • AWSの基盤側なのか、それ以上のレイヤなのかを切り分け、もし万が一の場合、一時対応として再起動や停止起動の実施

【無料】ADサーバーのクラウド移行をご検討の方、お悩みの方はこちらからお問い合わせください。

4.NTT東日本によるパブリッククラウド関連サービス

NTT東日本では、パブリッククラウドに関連するさまざまなサービスをご提供しております。

  • AWSのアカウントの提供サービスなら、①アカウント提供
  • AWSのネットワークならば、②クラウドゲートウェイサービス(閉域接続)
    お客さま拠点からAWSに至るまでのネットワークについてのご相談が可能です
  • 今回のセミナーのテーマであるActive Directoryの構築や移行から移行後の運用についての相談なら、④クラウド導入・運用サービス

【無料】ADサーバーのクラウド移行をご検討の方、お悩みの方はこちらからお問い合わせください。

5.Q&A

 最後にQ&Aの時間を設けて、参加者からの質問に対し、回答しました。その質問と回答内容を紹介します。

Q1移行までの所要時間について

Answer

移行の方式や、接続されているクライアントの台数に左右されます。

ここではクライアントの設定変更は含まずに回答します。

単純にマスタ昇格や同期であれば、早いものなら数時間。クライアントの台数が多い場合は数日かかります。

また、データを新しく入れての切り替える場合、結局は新しい新規の構築になるため、数週間単位となります。

Q2Amazon EC2でWindows Server 2019を立ち上げたが、English版しか選択肢が無かったためEnglish版で利用している。
この場合、オンプレミスのWindows Server 2012日本語版とのAD同期時に気を付ける点などあったら教えて欲しい。

Answer

Windows Server 2019 Japanese版はコミュニティAMIで提供されています。ami-0e742307f99887019を選択することで利用が可能となります。

Active Directory自体は英語版と日本語版大きく変わることはありませんが、Windows Server 2012とWindows Server 2019などのバージョンの異なるActive Directoryの場合、注意すべき部分は機能レベルなります。

Windows Server 2012で使われている機能レベルをチェックし、それがWindows Server 2019で対応している機能レベルかどうかを確認することが一つポイントになります。

例えば、Windows Server 2012には「元々がWindows Server 2003で使われた機能だった」というケースもあり機能レベルがかなり低いものが中には存在します。

移行先のWindows Server 2019で対応していない場合は、一旦オンプレミスのWindowsのActive Directoryの機能レベルを上げてから対応するようにしましょう。

Q3移行期間を長く取り、オンプレミスとクラウドのADを両方並行運用した場合、どのような連携をオンプレとクラウドで設定しなければならないか。

Answer

どのようなケースを想定されているか不明ですが、一つ考えられるのはそのままEC2に移行されるパターンが多いと思います。

この場合、マスタのどちらかを昇格、降格して1つのドメインにして、データ同期をして頂ければと思います。

また、使われていない時間帯にマスタをオンプレミスとクラウドに切り替えると言う設定する必要があるかと思います。

Q4各拠点にある端末のドメイン参加はAWSのマネージドなADサービスだと出来ないのか?

Answer

Simple ADでは出来ません。

ただ、Managed Microsoft ADを使用している場合は、新しいドメインを作る際に各拠点にある端末をMicrosoft ADへ参加することが可能となっています。

Q5移行についてデータエクスポート・データインポート方式とした場合、SIDは既存ADから変更されてしまうのか?

Answer

その通りです。変更されてしまいます。

Q6ドメインコントローラ自体のスナップショットは取らないようにとあるが、これはEC2のスナップショットのことか?

Answer

その通りです。EC2のスナップショットのことです。

工夫点として、ユーザデータが入っているボリュームとOSやActive Directoryのボリューム(EBS)を分けるのが良いと思います。

Q7オンプレミスではドメインコントローラは複数台推奨だが、AWSも複数台構成は可能か?

Answer

AWSでも複数台の構成は推奨となっております。

AWSでは更に複数のドメインコントローラを別々のアベイラビリティゾーンに分けて頂くことを推奨しています。

これを行うことで複数のデータセンターで冗長しているのと同じような効果が得られます。

Q8AWS環境のみでのActive Directoryサーバー利用の場合、クライアントPCからインターネットに接続不能となった場合は具体的にどのような不具合が発生するか?
また、逆に不具合が発生しない部分はどこか?

Answer

インターネットに接続不能の場合は、既存のネットワークのWANの不調と同じく、ドメインに参加できないので、ローカルユーザでしかログインが出来ない状況になります。

不具合が発生しない部分は難しいところでありますが、クライアントPCに不具合が無いという事であれば、クライアントPCのローカルユーザであれば、そのまま使えるという回答となります。

Q9AWS上のActive DirectoryではRadius認証は可能か?

Answer

AWSのActive Directoryで例えば、EC2上であれば、Radiusサーバーを立てる事は可能です。

また、Managed Microsoft ADでもRadiusは利用可能となっています。

6.まとめ

今回のセミナーにて紹介しました、まとめは次の3点になります。

①移行について

Active Directoryの移行はファイルサーバーに続いて優先的に検討する。

Active Directory の構築はIaaSやPaaSを使って柔軟に設計をする。

②移行先の方式について

IaaSで使うもの、PaaSで使うもの、ハイブリッドで使うもなど3つの利用パターンがある。

以下のように、どのような要件で使いたいか?というところに合わせて検討していく。

  • IaaS

これまでの利用を余り変えない

  • PaaS

手軽に新規で可用性や対障害性の高いものを作りたい

  • ハイブリッド

IaaSとオンプレミスとIaaSーPaaSで良いところを合わせて使いたい

③オンプレミスからIaaS/PaaSへの移行について

IaaS/PaaSへ移行することでハードウェアの運用保守が軽減される。

しかし、IaaSの場合はOSの管理が必要になり、またIaaS、PaaSのどちらもユーザ管理やActive Directoryの部分は引き続き、保守運用の検討が必要となる。

これらの作業の一部はアウトソースが可能で、アウトソースについても検討可能です。

7.おわりに

本レポートではオンプレミスActive Directoryサーバーの課題点と移行計画を紹介しました。オンプレミスのActive Directoryからクラウドへの移行を検討中の方の参考になれば幸いです。

今後も随時ウェビナーを開催していきますのでNTT東日本のイベント・セミナーページを引き続きご確認ください。

また、今回Active Directoryに関しては、さまざまな条件があり、お客さまの要件に合わせて柔軟に検討していく必要があるかと思います。

クラウドでActive Directoryを使ってみたいけど、よく分からないので不安だというお客さまは、オンラインでの無料相談窓口も開設しております。お気軽にお問合せください。

フルスペックのActive DirectoryをAWS上で利用できる
マネージドなディレクトリサービスはこちらをご確認ください。

ページ上部へ戻る

無料ダウンロード

自社のクラウド導入に必要な知識、ポイントを
このに総まとめ!

あなたはクラウド化の
何の情報を知りたいですか?

  • そもそも自社は本当にクラウド化すべき?オンプレとクラウドの違いは?
  • 【AWS・Azure・Google Cloud】
    どれが自社に最もマッチするの?
  • 情シス担当者の負荷を減らしてコストを軽減するクラウド化のポイントは?
  • 自社のクラウド導入を実現するまでの具体的な流れ・検討する順番は?

初めての自社クラウド導入、
わからないことが多く困ってしまいますよね。

NTT東日本では
そんなあなたにクラウド導入に必要な情報を

1冊の冊子にまとめました!

クラウド化のポイントを知らずに導入を進めると、以下のような事になってしまうことも・・・

  • システムインフラの維持にかかるトータルコストがあまり変わらない。。
  • 情シス担当者の負担が減らない。。
  • セキュリティ性・速度など、クラウド期待する効果を十分に享受できない。。
理想的なクラウド環境を実現するためにも、
最低限の4つのポイントを
抑えておきたいところです。
  • そもそも”クラウド化”とは?
    その本質的なメリット・デメリット
  • 自社にとって
    最適なクラウド環境構築のポイント
  • コストを抑えるため
    具体的なコツ
  • 既存環境からスムーズにクラウド化
    実現するためのロードマップ

など、この1冊だけで自社のクラウド化のポイントが簡単に理解できます。
またNTT東日本でクラウド化を実現し
問題を解決した事例や、
導入サポートサービスも掲載しているので、
ぜひダウンロードして読んでみてください。

クラウドのわからない・
面倒でお困りのあなたへ

クラウドのご相談できます!
無料オンライン相談窓口

NTT東日本なら貴社のクラウド導入設計から
ネットワーク環境構築・セキュリティ・運用まで
”ワンストップ支援”が可能です!

NTT東日本が選ばれる5つの理由

  • クラウド導入を
    0からワンストップでサポート可能!
  • 全体最適におけるコスト効率・業務効率の改善
    中立的にご提案
  • クラウド環境に問題がないか、
    第3者目線でチェック
    してもらいたい
  • 安心の24時間・365日の対応・保守
  • NTT東日本が保有する豊富なサービスの組み合わせで
    ”課題解決”と”コスト軽減”を両立

特に以下に当てはまる方はお気軽に
ご相談ください。

  • さまざまな種類やクラウド提供事業者があってどれが自社に適切かわからない
  • オンプレミスのままがよいのか、クラウド移行すべきなのか、迷っている
  • オンプレミスとクラウド移行した際のコスト比較を行いたい
  • AWSとAzure、どちらのクラウドが自社に適切かわからない
  • クラウド環境に問題がないか、第3者目線でチェックしてもらいたい
  • クラウド利用中、ネットワークの速度が遅くて業務に支障がでている

クラウドを熟知するプロが、クラウド導入におけるお客さまのLAN 環境や接続ネットワーク、
クラウドサービスまでトータルにお客さまのお悩みや課題の解決をサポートします。

相談無料!プロが中立的にアドバイスいたします

クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。