y2blog

AWSのマネージドメールサービス”WorkMail” を導入してみる

AWSのサービスは余りにも膨大で、日々増え続けているので一体どのサービスを使えば良いのか途方に暮れてしまいそうだが、AWSが組織向けのマネージド型の “WorkMail” というメールサービスを展開している．同じようなサービスとして、Office365のExchange Mailサービスが有るが、AWS版のExchangeライクなメール、カレンダーサービスと考えて良いだろう．

現時点では日本のリージョンでは展開されていないので、このサービスを日本の企業や官公庁などで導入するのは難しいだろうが、とりあえずどのような使い勝手か確かめるためテスト的に導入してみることにした．

私はプライベート用のメールに関してはプライベートドメインでVPSサーバ上にPostfixやDovecot、Cyrus SASLライブラリを導入してメールサーバを運用している．使用しているVPSサーバ環境も、さくらVPSからConoHaVPSへと移設し、この正月休みで VultrのVPSサーバへと数回の移行を経ている．

日本のVPSサービスでは、SMTP(TCP/25) の外向け(outbound) 通信は野放し（特に制限していない）の場合が多いが、AWS EC2やVultrなどの海外ベースのサービスでは、SMTPのoutbound通信をデフォルトでブロックしていることが多いようだ．

VultrのVPSサービスでも、SMTPのoutbound通信がデフォルトでブロックされていて、今回 VultrのVPSサービス上にメールサーバを移設するにあたり、何度も”Vultr”の担当者とやりとりを行ってようやくSMTPのoutbound通信を許可して貰った．日本との時差の関係で、メールでの数回のやりとりのために4日も費やしてしまった．

メール環境を自前で構築するのは結構大変な作業で、それなりのサーバ構築スキルとネットワークスキルがなければ難しい事に加え、日々安定して運用するには相当な手間を掛けなければならない．最近はOffice365 Exchange Mailなどのクラウドサービス型のメールサービスが企業メールの中心になっている．

私も個人的にビジネス版のOffice365サービスを契約してExchange Mailサービスを利用してはいるが、Office365のデフォルトドメイン “xxxx.onmicrosoft.com” ではなく、自ドメインで運用しようとすると、組織内のADサーバやAzure AD サービスなどとの認証連携作業やDNSの設定など、面倒な作業を行わなければならない．専門のIT部門を有さない小さな組織では自ドメインのExchange メールサービスを導入することは難しいだろう．

今回、AWSのWorkMailサービスを試して見ることにしたのは、”WorkMail” のドキュメントを見て比較的簡単に自ドメインメールを構築できそうだったので、とりあえず実際に自ドメインの”WorkMail”環境を立ち上げて使い勝手等を探ってみることにした．

WorkMail 環境を自ドメインで立ち上げてみる

“WorkMail” は現時点では、”US East(N. Virginia) us-east-1″、”US West(Oregon) us-west-2″ それに “Europe(Ireland) eu-west-1” の3つのリージョンだけなので、今回は一番近そうな”US West(Oregon) us-west-2″リーションを選択する．

まず最初に、”WorkMail”で使用するドメインを決めなければならないが、既存のRoute53上のホスティングドメインや新規にRoute53上にドメインを作成することも可能だ．勿論、Route53以外でホスティングされている外部のドメインでも構わないが、Route53を利用する方が圧倒的に楽に環境を構築可能だ．

今回は、Route53上でホスティングしているドメインの中から、メールサーバとして使用していない休眠ドメインを使うことにした．”Advanced Setting”の項目を展開すると、自組織のADなどのディレクトリサーバと認証連携させる設定も可能な用だが、今回は一番簡単な”WorkMail”のビルトインディレクトリサービスとキーサービスを使うことにする．

自ドメインのメール関連レコードの設定

自分のドメインとは別にWorkMailのデフォルトドメインが作成されるが、こちらのドメインはAWS側で管理されているので、ユーザは自分のドメインだけを管理すれば良い．設定でデフォルトドメインを自ドメインに切り替えることも可能だ．WorkMail側でRoute53上の自ドメインに自動的にMXレコードやCNAMEレコード、DKIM関連のCNAMEレコードを設定してくれるが、SPFとDMARC関連のTXTレコードは後で自分で設定しなければならないようだ．

メール関連の細かな追加設定

ここまでの設定で、一応自ドメインのメールサーバとしての基本的な機能は備わったことになるが、これ以外に、 “Enabling AutoDiscover to configure endpoints” や、自ドメインでのバウンスメール等の基本ポリシーの設定 “Editing domain identity policies”、“Configuring a custom MAIL FROM domain in Amazon WorkMail” などの設定を行って、メールサーバとしての身だしなみを整える必要がある．今回は、時間の都合でこれらの設定は省くが、仕事で使うメールサーバであればこれらの項目に関してもきちんと設定しておく必要がある．

WorkMailでは外部へのメールの配信は Amazon Simple Email Service(SES) を利用しており、WorkMailの環境を整える際に、SESの管理コンソールにアクセスして設定を追加する必要がある．

上記のWorkMailの管理コンソール画面の項目で、 “Cutom MAIL FROM Domain” という項目の設定が未設定のままなので、この項目も設定しておく．この項目の設定に関しては、“Setting up a custom MAIL FROM domain” を参照しながら作業を進めて行くと良いだろう．この設定を行うことで、Amazon SES がメールを送る際に MAIL FROM domain を .amazonses.com ではなく、自ドメインを使うようになる．

メールサーバとしての基本機能は整ったので、実際にこのメールサービスを利用するユーザを登録する作業を行う．WorkMailの管理コンソールから簡単にメールユーザを登録することが可能なので、コンソールに表示に従ってアカウントを登録していけば良い．ユーザ毎にモバイルデバイスの利用の制限やメールスプール容量の設定などが可能な用だが、今回はこの機能を試していないので、また別な機会に検証してみようと思う．

WorkMailでメールを送受信してみる

WorkMailへのユーザ登録が済めば、WorkMailを通じて外部とメールのやり取りが可能となる．一般的なメール専用クライアントだけではなく、WorkMailのWebMail機能を使用することも可能なので、余程レガシーなメールクライアントシステムで無い限りクライアント側での問題は発生しないだろう．

代表的なメールクライアントの設定方法についてのドキュメントリンクや WebMailアクセスポイントなどの情報が “Organization settings” の “General” タブに有るので、それらを参考にメールクライアントを設定すれば良い．

Web Mailシステムを自分で一から構築するのは大変だが、AWS “WorkMail” サービスでは Web Mail 機能が最初から備わっているのがとても有り難い．

AWSのWorkMailサービスを使えば、いとも簡単に自分専用のメールシステムを構築することが可能であることを理解して貰えることと思う．実際に、AWSの管理コンソールだけの情報を元にWorkMailサービスの構築を行ってみたが、マニュアル等を深読みすることなく、ほんの僅かな手間と時間を掛けるだけでこれだけのメール環境を整えられることはある意味画期的なサービスだと思う．

残念ながら現時点では、日本のリージョンでは展開されていないので、WorkMail導入の敷居は高いかもしれないが、そのうち日本でも展開される筈なので、自前のメールシステムの運用に疲れた人達は是非とも代替ソリューションとして検討してみてはいかがだろうか．費用も 1ユーザあたり 4$/月で、ドメインのホスティングの費用など多少の費用は発生するが、自分でVPSサーバを建てて運用する場合のコストを考えると圧倒的にコストパフォーマンスが良いだろう．