見出し画像

オンプレからAWS環境へActiveDirectoryサーバ移行時の検討事項

以前携わったオンプレからAWS環境へActiveDirectoryサーバを移行する案件にて、要件定義の段階で悩んだ2つの検討事項を記事にしました。Simple ADや AD Connectorについては本記事では触れません。

【ライターの紹介】
横浜事業部のSOYAです
クラウド環境を主にインフラエンジニアをしております。


1.前提条件

以前携わった案件を参考に移行前の稼働状況を上図に示し、本記事で記載する移行作業の前提条件を下記に示します。

- プロジェクト開始時点でオンプレとAWS環境はDirectConnectで接続されています。
- 移行前は、オンプレで稼働するADサーバに対して、オンプレのサーバや作業端末がドメイン参加している状態です。
- 上図にある2台のADサーバのみAWS環境へ移行します。
- 移行前後でADサーバの稼働は24時間/365日です。
- ドメイン参加する端末やユーザの総数は500以下です。
- 移行後は本番/開発環境の2つを用意します。
- 移行後はオンプレのサーバ及び作業端末だけでなく、将来的にAWS環境で構築するサーバもドメイン参加する方針です。
以上から、AWS内で完結するSimple ADやオンプレで稼働するADへの接続を前提としたAD Connectorは移行後の利用サービスから除外しました。

2.移行後の構成例

検討した移行後の構成2パターンを下記に記載します。

<構成例1:AWS Managed Microsoft ADを使用する場合>

AWS Managed Microsoft AD利用時の前提条件としてドメインコントローラーは最低2つ起動し、異なるAZにある必要があります(注1)。

GPOなどを管理するために管理用EC2が必要ですが、本案件では同時期に別案件で移行したWebサーバを兼用で使用しました。オンプレ環境からのドメイン参加はルーティングやファイアウォール(あるいはセキュリティグループ)が適切に設定してあれば、通常のドメイン参加の方法で設定可能です。

AWS Managed Microsoft ADを利用するメリットは高可用性と耐障害性がありますが、DCのパッチ適用やバージョンアップをダウンタイム無し、またコンソールから簡単に実行できる点も運用を考慮すると大きいです(注2)。

本記事ではAWS Managed Microsoft ADのメリット/デメリットの詳細はこれ以上記載しません。

(参考リンク)
(注1)AWS マネージド Microsoft AD の使用を開始する
(注2)AWS Managed Microsoft AD の主要なコンセプト

<構成例2:AD on EC2を利用する場合>

単一リージョンのマルチAZ構成で、2つのAZに1台ずつDCを配置することで冗長化します。AWS Managed Microsoft AD利用時とは違い、管理用サーバは不要です。
AWS Managed Microsoft ADと同様、オンプレ環境 – AWS環境双方のドメイン参加はルーティングやファイアウォール(あるいはセキュリティグループ)が適切に設定してあれば、通常のドメイン参加の方法で設定可能です。

3.検討事項1- ランニングコスト

まず本案件で大きなポイントとなったのは、開発環境にかかるコストです。
本案件では、開発環境のサーバは運用開始以降パッチ当てなどの検証時以外は停止する要件がありました。しかし、AWS Managed Microsoft ADは停止するという機能はなく、本番/開発ともに常時起動することになるため不要なコストがかかります。

下記に各パターンの年間ランニングコストの試算例を記載します。
(2024/5月時点の公式情報を参考に試算)

【AWS Managed Microsoft ADを利用する場合】
本案件では、管理するオブジェクトは500以下であるためAWS Managed Microsoft AD Standard Editionを使用しています(注3)。
1.前提条件で記載の通り、24時間365日稼働で年間コストを試算します。

◯本番環境利用料金(開発環境も同額)
年間コスト:$0.146/h×24h×365d = $1278.96
※$0.146/h・・・Standard Edition でのDC二台の時間当たり料金(注4)

【AD on EC2を利用する場合】
本案件では下記のスペックで利用を検討しました。
EC2:t3.large(2vCPU/8GiB)
EBS:容量40GiB、ボリュームタイプgp3(3,000 IOPS/125 MB/秒 スループット)、Cドライブのみ
オンデマンド利用及び24時間365日稼働で年間コストを試算します。

◯本番環境利用料金
年間コスト(EC2):$0.0418×24h×365日 ×2台= $1462.92
年間コスト(EBS):$0.096/月×40GB×12ヶ月 ×2台= $92.12
年間コスト(合計):$1555.04
※$0.0418・・・EC2一台の時間当たり料金(注5)
$0.096・・・EBS一つの1ヶ月当たり料金(注6)

【2パターンの比較】

※$1,647.16・・・本番環境の年間コスト+EBS単体の年間コスト
 α・・・運用開始以降の起動時間あたりのEC2利用料金

上記の試算より本番環境だけ見れば、AWS Managed Microsoft ADの方がコストを抑えられますが、本番/開発環境を用意した場合、停止中に料金が発生しないEC2の方がある程度コストを抑えられることがわかります。

また、開発環境のスペックを縮小あるいは、本番環境でリザーブドインスタンスなどの割引サービスを利用するといった対応を行うことで、EC2の方はさらにコストを低く抑えられます。

AWS Managed Microsoft ADを利用するとしても年間コストの差額は大きくとも$1,000程度であり、可用性やメンテナンス性を図る上で必要なコストとは思われますが、オンプレ運用と同等レベルの運用が可能であれば、固定費削減を優先して自己管理型の手段(AD on EC2)を選択する顧客も少なくないと思われます。

(参考リンク)
(注3)What is AWS Directory Service?
(注4)AWS Directory Service の料金
(注5)Amazon EC2 T3 インスタンス
(注6)Amazon EBS の料金

4.検討事項2- 移行コスト

もう1つの大きなポイントは既存のドメインの利用と、データの移行手段です。
既存ドメインの利用に関して、AWS Managed Microsoft ADは自己管理型のADサーバのドメインに参加することはできません。
そのため、自己管理型のADサーバからAWS Managed Microsoft AD への移行に関してはAWS公式で案内されている通り、新規ドメインでサービスを起動し、Active Directory 移行ツールキット(ADMT)やパスワードエクスポートサービス(PES)をインストールしてユーザやパスワードの移行を実施しなければなりません。(注6) (注7)

AWS公式では案内されていませんが、Microsoft公式が案内している”Copy a Group Policy Object”を参考にすれば、グループポリシーも自己管理型のADサーバからコピーすることが可能です。

ただし、これらのツールを用いても移行不可のオブジェクトはいくつかあります(注8)ので、要件定義の段階で移行対象の精査が必要になります。

一方、AD on EC2を利用しての移行であれば、新規ADサーバを既存ドメインに参加しDC昇格するといったAD移行の一連の作業(注8)を行うことでオンプレDCと同期ができ、移行にかかる工数は管理するオブジェクトの数によっては大きく減らすことができます。

また、ユーザ端末でのドメインの切り替え作業も不要であるため、切り替えに関わる手順書の作成や問い合わせ対応といった作業コストも削減できます。

以上から、AWS Managed Microsoft ADはその高い可用性やメンテンナンス性により運用負荷を抑えられるメリットはありますが、サーバ構築〜ドメイン切り替えまでの初期コストは自己管理型サーバ同士の移行(AD on EC2利用)より高く、また管理するオブジェクトが複雑であるほどそのコストは大きくなる可能性があります。

(参考リンク)
(注7)How to migrate your on-premises domain to AWS Managed Microsoft AD using ADMT
(注8)Active Directory の移行
(注9) Windows Server 2012/2012 R2 Active Directory 移行の手引き

5.まとめ

ADサーバ移行の検討事項として、開発環境のランニングコストと移行にかかる初期コストの2点を挙げさせていただきました。

本案件では最終的に、AD on EC2を選択しましたがもちろんこれが最適というわけではありません。要件定義の段階で調達コストや可用性、メンテナンス性、移行期間などの項目の優先順位を協議しその結果次第でどちらを利用すべきかは変わってきます。

また、今回は構築/運用コストという比較的検討されやすい項目を中心に記載しましたが、AWS Managed Microsoft ADはマネージドサービスの特性上機能的制約もいくつかあります。要件定義あるいは基本設計の段階でそういった懸念点やリスクも念頭に入れて、どちらを利用するか検討してください。

ALHについて知る



↓ ↓ ↓ 採用サイトはこちら ↓ ↓ ↓


↓ ↓ ↓ コーポレートサイトはこちら ↓ ↓ ↓


↓ ↓ ↓ もっとALHについて知りたい? ↓ ↓ ↓




みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!