釣りです。すみません。

「AWS DBエンジニア向け体験ハンズオン」に参加してきました。
（↑これが３時間・リソース４ドル分）
https://pages.awscloud.com/DMSSCTHandson.html

このハンズオンは、
AWS Database Migration Service (DMS)　と、
AWS Schema Conversion Tool (SCT)　を使って、
既存のデータベースから新しいデータベースにデータを移行する内容です。
流れは、以下です。
１．実行環境自動作成（約３０分）
２．データベースコードオブジェクトの変換（約４５分）
３．レプリケーション（約４５分）
４．後片付け（約１５分）

１．実行環境自動作成：

CloudFormation（AWSリソースのサービスを設定ファイルを元に自動化できるサービス）で、事前に作成いただいているテンプレートを読み込んで、実行環境を作成します。
今回は、Oracleから、PostgreSQLへの移行を行います。

２．データベースコードオブジェクトの変換：

AWS SCTで、Oracleインスタンスのスキーマ、ビュー、ストアドプロシージャ、関数などのデータベースコードオブジェクトをpostgreSQLへ、変換＆登録します。
ツールで自動変換できない箇所は、評価レポート、または、自動変換できない個所が黄色くハイライトがあるので、これらを手動で変換します。
尚、ソース→ターゲットの変換可能データベースは、以下となっています。
ソースデータベースは、オンプレでも可能です。

(https://aws.amazon.com/jp/dms/　より)

３．レプリケーション：

サービスから、AWS DMSを選択し、レプリケーションインスタンスを作成します。
レプリケーションなので、タイトルはデータ移行と謳いましたが、継続的レプリケーションもできました。

４．後片付け：

CloudFormationから、読み込んだ実行環境スタックを削除すれば、すべてのリソースもろとも消えるので、ラクチン。
ハンズオンは、ココで終わりです。

ところで、AWSは、移行支援サービスが、とても手厚いです。
システムの焼き直しなら、AWSが向いていると思います。
（新しいビジネスを、迅速に展開するなら、GCPでしょうか。フルマネージドのサービスが充実しています。）

（https://www.slideshare.net/KamedaHarunobu/migration-to-aws-as-of-20170920　より）
また、今年は、三菱UFJがパブリッククラウド採用を採用したこともあり、パブリッククラウドへのシステム移行を検討する企業が多くなったと思います。
しかし、日本企業の多くは、パブリッククラウドを導入しきれないのは、
「コスト」
「セキュリティ」
「用途」
の懸念があるからと思います。

●パブリッククラウドを導入しきれない懸念①「コスト」

オンプレミス環境である場合、大体、下記を維持します。
データセンター費用
ハード
電気代
物理ファシリティ
セキュリティ
仮想基盤運用保守
センター運用保守
そのため、クラウドの利用料だけにフォーカスをあてると、高い／低いは額面の大きさだけで議論することになりますが、実は、相当なコストカットが見込めます。
それらは、AWSだと、以下のURLで試算できます。

https://awstcocalculator.com/

試算してみたら、「９８％」減とかになりました。
但し、資産価値があるものは、差し引く必要はあるので、ご注意ください。
下記のスライドを参考にすると、伝わりやすいでしょうか。

（https://www.slideshare.net/KamedaHarunobu/migration-to-aws-as-of-20170920　より）

●パブリッククラウドを導入しきれない懸念②「セキュリティ」

失礼ながら、、、、
御社のセキュリティは、クラウドベンダーのそれより強固なのでしょうか？
・・・・・
・・・・
・・・
・・
・
すみません。取り乱しました。
AWSだと、セキュリティに関して、年間数百億円かけているといわれています（←ソース忘れました）。
その上、その道のスペシャリストが担当します。
「餅は、餅屋」です。
優秀なセキュリティ環境を得られます。
ただし、AWSは、責任共有モデルによって、AWSとユーザで責任部分を分けています。
たとえば、↓の図のとおり、「データベース（サービス）」はAWSの責任のため、ユーザは中身（＝データ）だけ気にすればいいです。
（GCPのセキュリティモデルは、「エンドツーエンド」ですよ！）
ユーザが利用しているクラウド部分（データや設定）は、ユーザの責任、AWSが提供している仕掛け（サービス）は、AWSの責任です。

(https://aws.amazon.com/jp/compliance/shared-responsibility-model/　より)
つまるところ、オンプレ環境から、ユーザのセキュリティポリシーが変わることはないと思います。
セキュリティに使っていたソフトやツールが、変わるだけです。

●パブリッククラウドを導入しきれない懸念③「用途」

責任共有モデルだと、データはユーザ責任なので、ミッションクリティカルなシステム（基幹系、お金を扱うとか）の導入は二の足を踏みます。
クラウドサービスの利点は、オンタイムでリソース確保して、いらなかったらすぐに壊して、または、リソースのバージョン管理を行って（＝スナップショットをとっておいて）、システムの展開／廃棄が即時可能なところと思います。
自社サーバを構築してみたものの、利用されなくなり、使われないリソースの再利用に悩むこともありません。
そのため、アグレッシブに、新しいビジネス・サービス・システムにチャレンジするのは、作って、壊せるクラウドが安価です。
まずは、新規ビジネスのためのサービスのように、気軽に作って、壊せるものから試す。
使ううちに、機能を把握して、基幹系などミッションクリティカルな機能へ、しかも、昨日分解してゆき、影響の小さいところから、展開するほうがスムーズです。
ちなみに、「AWS Application Discovery Service」は、「オンプレミスサーバーのインベントリと動作を確認できる」そうで、アプリケーション移行計画に必要な情報を把握できます。

もう、至れり尽くせりです。

AWSだか、GCPだか、どちらのセールスなんだか、わからない内容になりましたが、最近は、IBMも無料枠を設けていますので、どしどし、クラウドサービスを試して、いろいろなサービスを作ってみましょう。

ホームページ　http://www.ois-yokohama.co.jp
facebook　　　https://www.facebook.com/orientalinformationservice/