第14回JAWS-UG札幌勉強会で発表しました。~Windows Server + VPNのAWS移行事例
2月26日(木)、第14回JAWS-UG札幌 勉強会で発表しました。
内容は「Windows Server + VPNのAWS移行事例」で資料はこちらです。
「古いWindows Server 2012 R2 AMIの不具合」の件は知らない方もいらっしゃったようで、「マジか。。。」のような声もちらほら聞かれました。
いつも以上に緊張して持ち時間15分のところ22分ぐらい?しゃべってしまいました。
次回は5分ぐらい余裕を持って準備するようにしたいと思います。
(2019.8.20追記)
「発覚した問題(1) – RDSの名前解決」について補足します。
「VPN接続したお客様営業所のPCでRDSエンドポイントのDNS名前解決ができない」という問題で、当時は、AWS VPC内にEC2インスタンスを作成し、DNSキャッシュサーバーを用意することで解決しました。
今なら、AWS VPC側でRoute 53 ResolverのInbound Endpointを作成することで解決しますね。
(参考)
Route53 Resolverを試した – Qiita
https://qiita.com/rotekxyz/items/585635a5ccd806b651e7
(2019.8.20追記ここまで)
ほかの方の発表について。
Amazonエクマンさん
JAWS札幌 re:Invent 2014レポート ― サーバレスの時代へ
昨年のre:Inventに参加したエクマンさんが感じたAWSの方向性についての発表でした。
確かに、最近のAWSのリリースは、ビッグデータ解析関連、モバイル関連、Lambdaなど、サーバーレスに向かっています。
サーバー管理が不要になるし素晴らしいのだけれど、開発側がそれに追いつくのはなかなか大変で、(仮想)サーバーでの運用はやっぱり残っていくのでしょう。
よく言われていることですが、AWSを使うなら、サーバーレスやプログラマブルな部分を活用しないと料金面でもったいないです。
シンプルなサーバー構成でよければ、国産クラウドサービスのほうがコストパフォーマンスがよくて使いやすいと思います。
(RDSのようなDBサービスがあるとよりよいですね。)
Auroraは早く使ってみたいけど、Limited Previewに申し込んでも全然順番が回ってきません(笑)
サーバーワークス羽柴さん
安心と安全のお話。
自動化で安全を強化、人手で安心を提供。
「すべてを自動化できるわけではなく、人が仕事をしている限り、人が関わることが必要。」というのは、そのとおりだと改めて気づかされるよい言葉でした。
アグレックス松井さん
落ちないFTPサーバー+VPNの構築過程を詳しく説明した発表でした。
懇親会で他の方とも話していたのですが、ちゃんと考えると難しいですね。
最終的に「EC2 x 2台、Floating IPパターン、ENI付け替え、ストレージはGlusterFS」で落ち着いたところで、VPNを使用せずに「インターネット公開+SFTP」となり、ELBで実現したとのこと。
そこまで行ったのならもう一歩進めてS3でいいんじゃないか、という気もするけど、サーバーがほかのユーザーと分離していないと怖いとか、クライアントソフトの操作感が少し違うとかで難しいのでしょうね。
イー・カムトゥルー佐藤さん
佐藤さんも、偶然僕と同じくWindows Serverのお話でした。
冒頭の「AMIでシステム環境を納品」というのは面白いですね。
ライセンス、CALのお話はあまりよくわかっていなかったので、参考になりました。
後で調べたのですが、AWS Windows ServerのSPLAライセンスについては、Developers.IOの以下の記事もわかりやすいです。
・Windows Server on AWSにCALは必要か確認した
http://dev.classmethod.jp/cloud/windows-server-on-aws-cal/
次は3月22日(日)の「JAWS DAYS 2015」に参加する予定です。
(関連記事)
・AWS VPC+RDS~クローズドネットワーク環境からVPN経由でRDSに接続できない?
https://inaba-serverdesign.jp/blog/20140911/aws_vpc_vpn_rds.html
・AWS Windows Serverのバックアップ自動化とリカバリー
https://inaba-serverdesign.jp/blog/20140326/aws_windows_server_backup.html