利用目的別ＡＷＳ適用前の考慮事項

Transcript

1. 1 © NEC Corporation 2018 利用目的別ＡＷＳ適用前の考慮事項 2018年07月20日 NECソリューションイノベータ（株）
3. 目次 1. 自己紹介 2. 会社紹介 3. 本日のテーマ 4. AWS利用の目的１：開発環境として使いたい 5. AWS利用の目的２：保守切れに機にクラウドへ移行したい 6. AWS利用の目的３：負荷変動に耐えられるシステムを作りたい 7. AWS利用の目的４：BCP対策として利用したい 8. AWS導入の進め方 9. まとめ
4. 4 © NEC Corporation 2018 １．自己紹介 ▌名前 石崎 健太郎 ▌所属 NECソリューションイノベータ（株） クラウドNWソリューション事業部 クラウドビジネスSIグループ 中四国地域の企業様へのAWS導入支援を担当 ▌趣味 LEGO、ミニ四駆、ベイブレード （＝息子の趣味）
5. 5 © NEC Corporation 2018 ２．会社紹介 ２－１．NECとAWSのパートナー関係 「SIインテグレーション部門」と「ソフトウェア部門」の 両部門のパートナーとなっているのが特徴 APNテクノロジーパートナー • （ソフトウェア部門） APNコンサルティングパートナー • (SIインテグレーション部門) AWSが東京リージョンを開設した次の年(2012年)には上記2つのパートナーと なっています。 2012年 CLUSTERPRO,InfoCage SiteShellの AWS対応製品提供開始 2014年 AWSシステム構築サービス提供開始
6. 6 © NEC Corporation 2018 ２．会社紹介 ２－２．APNプレミアコンサルティングパートナーに2年連続で選出 高度な技術者 豊富な構築・運用実績 プロフェッショナル認定者を 含む、延べ300名以上の AWS認定技術者保有 様々な業種でAWS上での システム移行・構築実績あり ※ APNプレミアコンサルティングパートナーは全世界で67社、国内では8社のみ となっています。
7. 7 © NEC Corporation 2018 ３．本日のテーマ 過去のAWS利用のための相談事例から、利用目的別 に事前に考慮しておかなければならないポイントを 紹介いたします。 対象者 AWS利用を検討しているけど、どう進めていけばいいのか悩まれてい る情報システム部門の方 本日のゴール AWS利用にあたり、これからやらなくてはならないことの具体的なイ メージをつかんでもらい、準備が始められるようになる。
8. 8 © NEC Corporation 2018 ４．AWS導入の目的１：開発環境として使いたい AWSを開発環境として使いたいんだけど・・・ 開発対象が AWSで動かすシステムか 既存オンプレ環境で動かすシステムか により適用できる範囲が異なります
9. 9 © NEC Corporation 2018 ４．AWS導入の目的１：開発環境として使いたい ４－１．用途ごとの適用可能範囲 一言で開発環境といっても用途に応じて必要なものが異なり、AWS上で実 現可能な範囲も異なります。 用途 コーディング環境 検証環境 ステージング環境 必要なもの • IDE実行環境 • ソースリポジトリ • 機能検証用の小規 模環境 • 非機能検証用の本 番と同等の環境 • テストデータ • 本番と同じ環境 • 本番と同じデータ システム 実行場所 オンプレ 既存環境 ◦ AWS上で実現可能 ▲ AWS上でアプリケー ションの機能検証環 境までなら可能。 × 環境差異から利用は 推奨しない。 AWS上 ◦ 環境の分割方法の検討が必要。
10. 10 © NEC Corporation 2018 ４．AWS導入の目的１：開発環境として使いたい ４－２．コーディング環境として利用する場合 AWSをコーディング環境として利用することで、リソース調整の手間を省 け、環境提供のリードタイム短縮、リポジトリの高可用化が期待できます。 virtual private cloud corporate data center AWS cloud AWS CodeCommit AWSとの接続は Internet経由かVPN接続 RDPやSSH EC2 instances Internet gateway VPN gateway VPN connection Internet customer gateway gitリポジトリにAWSのサー ビスを利用することで、高可 用かつ運用コストを削減。 VPC subnet 開発者が使いたいIDEを導入 Amazon CloudWatch event (time- based) 開発環境は夜間自動停止させ ることで、利用料金を抑制
11. 11 © NEC Corporation 2018 ４．AWS導入の目的１：開発環境として使いたい ４－３．検証環境として利用する場合 本番環境がオンプレミスの既存環境の場合、プラットフォームの差異もあ り非機能性を合わせることができないため、利用は推奨できません。 ▌機能性検証であればAWS環境でも行えます。ただし、利用するソフト ウェアによってはライセンス費用が高くなるものもあり考慮が必要です。 virtual private cloud corporate data center AWS cloud 本番環境 検証／ステージング環境 仮想化基盤 AP サーバー DB サーバー ストレージ AP サーバー LB APサーバー DBサーバー Elastic Load Balancing 現用系 待機系 EC2 instance EC2 DB on instance 環境差異 が大きい
12. 12 © NEC Corporation 2018 ４．AWS導入の目的１：開発環境として使いたい ４－４．AWSで動かすシステムの開発環境として利用する場合 AWSで動かすシステムを開発する場合は、環境分割方法の検討が必要です。 品質、コスト、セキュリティの要件に応じていくつかのやり方があります。 本番環境 検証環境 開発環境 corporate data center ※本例はNWを分割した例ですが、AWSアカウントを環境ごとに分割する場合もあります。 専用線接続 AWS Direct Connect Gateway AWS Direct Connect customer gateway VPN gateway AWS CodeCommit AWS CodePipeline AWS CodeDeploy AWS CodeBuild CI/CDを実現 ステージング 環境
13. 13 © NEC Corporation 2018 ５．AWS導入の目的２：保守切れに機にクラウドへ移行したい 保守切れ対応を機にAWSへ移行したいけど、 移行できるのかわからない・・・ システム毎に移行方針の見極めが必要です。
14. 14 © NEC Corporation 2018 ５．AWS導入の目的２：保守切れに機にクラウドへ移行したい ５－１．クラウド移行の７R システム毎に７つの移行方針からいずれかに決定する必要があります。 移行方針 説明 AP 仕様変更 選択基準 AWS化方法 Retire： システム廃止 パッケージやハードウェアサポー ト終了を契機にシステムを廃止 不可 移行しない方針のため、対象外。 Retain： システム維持 現行システムのまま変更は行わず 利用しつづける。 Revise： 一部改修 既存アーキテクチャは維持しつつ、 アプリケーションの変更のみでク ラウドへ対応させる。 可 • 可用性、拡張性などクラウド のメリットを享受したい アプリをステートレ ス化するよう改修し、 AutoScaling対応する。 Rebuild： 再構築 最新OS、最新プラットフォーム に対応できるように既存アプリ ケーションを変更する。 • 物理サーバーで動作している。 • OSやミドルウェアが古い。 OS、ミドルウェアの 最新版を使った形で アプリを改修。 Replace： 新サービスへ移行 クラウドに対応したパッケージや SaaSへ乗り換える。 • 利用製品がAWS上での動作 保証をしておらずサポートが 受けられない。 AWSに対応したパッ ケージ製品に置換。 Rehost： インフラ刷新 クラウドベンダーが提供するツー ルなどを利用して移行 不可 • 仮想化基盤やOS、ソフト ウェアも新しく、そのままク ラウド上で動かすことができ る。 AWS SMSやVM Importを使い、仮想 サーバーをV2Vする。 Refactor： ソースコード改善 インフラ構成についてクラウドベ ンダーが提供するサービスを活用 するために一部修正する • 冗長化方式の見直しが必要。 • DBのライセンスも従量課金 にしたい。 クラスタ方式の見直 しや、DBをAmazon RDSを利用できるよ うにアプリケーショ ンを改修。
15. 15 © NEC Corporation 2018 ５．AWS導入の目的２：保守切れに機にクラウドへ移行したい ５－１．クラウド移行の７R システム毎に７つの移行方針からいずれかに決定する必要があります。 移行方針 説明 AP 仕様変更 選択基準 AWS化方法 Retire： システム廃止 パッケージやハードウェアサポー ト終了を契機にシステムを廃止 不可 移行しない方針のため、対象外。 Retain： システム維持 現行システムのまま変更は行わず 利用しつづける。 Revise： 一部改修 既存アーキテクチャは維持しつつ、 アプリケーションの変更のみでク ラウドへ対応させる。 可 • 可用性、拡張性などクラウド のメリットを享受したい アプリをステートレ ス化するよう改修し、 AutoScaling対応する。 Rebuild： 再構築 最新OS、最新プラットフォーム に対応できるように既存アプリ ケーションを変更する。 • 物理サーバーで動作している。 • OSやミドルウェアが古い。 OS、ミドルウェアの 最新版を使った形で アプリを改修。 Replace： 新サービスへ移行 クラウドに対応したパッケージや SaaSへ乗り換える。 • 利用製品がAWS上での動作 保証をしておらずサポートが 受けられない。 AWSに対応したパッ ケージ製品に置換。 Rehost： インフラ刷新 クラウドベンダーが提供するツー ルなどを利用して移行 不可 • 仮想化基盤やOS、ソフト ウェアも新しく、そのままク ラウド上で動かすことができ る。 AWS SMSやVM Importを使い、仮想 サーバーをV2Vする。 Refactor： ソースコード改善 インフラ構成についてクラウドベ ンダーが提供するサービスを活用 するために一部修正する • 冗長化方式の見直しが必要。 • DBのライセンスも従量課金 にしたい。 クラスタ方式の見直 しや、DBをAmazon RDSを利用できるよ うにアプリケーショ ンを改修。
16. 16 © NEC Corporation 2017 ５．AWS導入の目的２：保守切れに機にクラウドへ移行したい ５－２．AWS上で可用性を確保する SLAを考慮したシステム設計が必要になります。 可用性99.99%を謳う。しかしこれは、ユーザ自身がサーバーを冗長化して初 めて約束される数字である。 冗長化されていないシステムに対する可用性はSLAに定義されていない。 AWSはサービスメンテナンスを不定期かつ時間帯の配慮もなく行う。 AmazonEC2のSLA システムの安定稼働を実現するためには、 Multi-AZ構成でのサーバー冗長化が必要
17. 17 © NEC Corporation 2017 ５．AWS導入の目的２：保守切れに機にクラウドへ移行したい ５－３．アベイラビリティゾーンとは アベイラビリティゾーン(AZ)とは、互いに影響を受けないデータセンター 群を指します。 ▌AWSのインフラの構成 リージョン(数値はAvaliablity Zoneの数) 2018年3月13日時点 アカウント • １つのアカウントで、全てのリージョン が利用可能（特殊地域を除く) リージョン • 地理的に離れた領域 • リージョン毎にインフラは完全に独立 • リージョン間はパブリックインターネッ ト接続 • リージョンは２つ以上のAZから構成 アベイラビリティゾーン(AZ) • 各AZは、互いに影響をうけないように、 地理的・電源的・ネットワーク的に独立 • AZ間は低遅延の高速専用線で接続 • １つのAZは、最低１ヶ所以上のデータセ ンターで構成 データセンター データセンター データセンター データセンター データセンター データセンター データセンター データセンター データセンター データセンター データセンター データセンター データセンター データセンター データセンター データセンター リージョン AZ AZ AZ AZ
18. 18 © NEC Corporation 2017 ５．AWS導入の目的２：保守切れに機にクラウドへ移行したい ５－４．AWS上での冗長化方式 仮想サーバ(EC2)を複数のAZに配置する(Multi-AZ)冗長化方式を採用する 必要があります。 ▌負荷分散クラスタ方式 ロードバランサで負荷分散することで、 １台のサーバー障害においても、業務シ ステムを継続可能にする。 ▌フェイルオーバクラスタ方式 クラスタリングソフトを利用すること で、１台のサーバー障害において、待機 系のサーバに切り替えて、業務システム を継続可能にする。 Availability Zone #A Availability Zone #B ELB VPC subnet VPC subnet Availability Zone B Availability Zone A 業務 データ ミラーリング クラスタ ノード (待機系) 業務 データ クラスタ ノード (現用系) フェイルオーバ クラスタ ノード (現用系) クラスタ ノード (現用系) VPC subnet VPC subnet 東京 region 東京 region
19. 19 © NEC Corporation 2018 ５．AWS導入の目的２：保守切れに機にクラウドへ移行したい ５－５．既存システムの冗長化方式との比較 既存システムの冗長化方式 移行方針 AWS移行後 仮想化基盤の HA機能 Refactor 物理サーバー障害時のEC2の再起動はAWSでも 可能なためHAと同等の仕組みは実現可能。 本番稼働するシステムは負荷分散クラスタか、 フェイルオーバークラスタへの見直しを推奨。 負荷分散 クラスタ Rehost AWS上でも負荷分散クラスタで実現。 LBはAWSのサービス(ELB)を利用するため、仕 様差分の把握が必要。 ・分散アルゴリズム方式 ・セッション維持方式 ・ヘルスチェック方式 など フェイル オーバー クラスタ Refactor (Rebuild) AWSでは共有ファイルサービスがない。(Linux はAmazon EFSが利用可能） ディスクミラーリングが可能なクラスタソフト を採用する。 DBサーバーの場合は、AWS RDSを利用する形 にアプリケーションを改修する。 ※DBサーバーのもつ機能によっては仕様変更を 伴う改修が必要な場合もある。(Rebuild)
20. 20 © NEC Corporation 2018 ５．AWS導入の目的２：保守切れに機にクラウドへ移行したい ５－６．Rehost方式 AWS Server Migration Service(SMS)を利用することで、仮想化基盤から AWSへ移行が容易にできます。 ▌AWS SMSとは EC2にデプロイ可能なAMI(Amazon Machine Image)として、VM をレプリケートします。ま た最大90日間、VMの変更を増分レプリケーショ ンとして自動的に反映します。これにより本番切 り替えの停止時間を最小化できます。 ▌対応仮想化基盤 VMware vCenter 5.1以降 Hyper-V:Windows Server 2012 R2以降 ※そのほか、利用には前提条件があります。 ▌注意事項 AWSでは物理サーバからの移行をサポートしてい ません。一度仮想化基盤上にP2Vで移行を行った うえで、AWS SMSを利用する必要があります。 V M V M V M Server Migration Connector ①Download & Deploy AWS SMSが対応していないバージョンも、VM Import機能を用いることで移行す ることが可能です。 AMI 仮想化基盤 ③インスタンス化 AWS SMS ②移行ジョブ設定 ＆ 実行 オンプレミス環境
21. 21 © NEC Corporation 2018 ６．AWS導入の目的３：負荷変動に耐えられるシステムを作りたい 繁忙期対応でリソース調整や構成変更の手間を 省ける負荷変動に強いシステムを作りたい AWSのサービスを活用して サーバーをステートレスにすることで 拡張性のあるシステムが実現できます。
22. 22 © NEC Corporation 2018 ６．AWS導入の目的３：負荷変動に耐えられるシステムを作りたい ６－１．スケーリング手法一覧 負荷変動の種類によりスケーリングの手法は異なります。 手法 負荷の種類 AWSでの実現方法 手動スケーリング 発生時期や程度が明確 • キャンペーン期間 管理コンソールを使用して Auto Scaling グループのサイズ の変更 計画スケーリング 負荷の発生が定期的 • 定期バッチ Auto Scaling グループに スケジュールされたアクション を作成 動的スケーリング (Auto Scaling) 負荷の発生予測が難しい。 緩やかな負荷の増加 • 利用者増 スケーリングポリシーを定義。 • CPU負荷がxx%でサーバ2台 追加 ※Auto Scalingではスパイク的 な負荷への対応は難しい。 t t t
23. 23 © NEC Corporation 2018 ６．AWS導入の目的３：負荷変動に耐えられるシステムを作りたい ６－２．サーバーのステートレス化 AWSのAuto Scalingサービスを利用するにはサーバーのステートレス化が 必要です。 ▌サーバーの外部で保持すべき情報 セッション情報、ログ情報、システムで利用するデータ virtual private cloud Auto Scaling group Amazon DynamoDB Amazon ElastiCache Amazon RDS Amazon S3 Amazon CloudWatch セッション情報 データ ログ AMI 生成 Elastic Load Balancing 増設されるサーバーはイメージから 生成される。初期設定は起動時のス クリプトで行う等の工夫が必要。 WindowsサーバーのADへのドメイ ン参加・離脱には複雑な仕組みがつ い可で必要。 拡張性におけるボトルネックになり やすい箇所。リードレプリカ対応や RDS Auroraの採用等の検討が必要。 S3へのログ保管は、S3へのログ転 送に対応したソフトウェアの導入が 必要。Fluentdなど。
24. 24 © NEC Corporation 2018 ７．AWS利用の目的４：BCP対策として利用したい 自社ビルが老朽化しており、 BCPのためにクラウドを利用したい 復旧にむけての目標時間に応じて いくつかの手段があります。
25. 25 © NEC Corporation 2018 ７．AWS利用の目的４：BCP対策として利用したい ７－１．Disaster Recovery方式 復旧目標に応じてDR方式を選択する必要があるため、業務システム毎に求 められる復旧目標(RTO, RPO)を明確にしてください。 DR方式 目的 復旧レベル コスト 概要 遠隔地バックアップ データ保護 RTO≒数週間 RPO≒1日 オンプレミス環境のバックアップ をネットワーク経由でAWSにコ ピー。復旧は、新オンプレミス環 境 遠隔地コールドスタンバイ① システム復旧 RTO≒数時間 RPO≒1日 オンプレミス環境のバックアップ をネットワーク経由でAWSにコ ピー。復旧はAWS上でシステム構 築 遠隔地コールドスタンバイ② システム復旧 RTO≒数時間 RPO≒1日 AWS環境のバックアップを別リー ジョンにコピー。復旧は別リー ジョンにてシステム構築。 遠隔地クラスター システム継続 RTO≒数分 RPO≒数秒 メインサイトと災対サイトでDB を非同期レプリケーション。 二重化システム システム継続 RTO≒数秒 RPO≒数秒 2つの環境を両方現用系として利 用し、データは同期型でレプリ ケーション。 低 高
26. 26 © NEC Corporation 2018 ７．AWS利用の目的４：BCP対策として利用したい ７－２．AWSへ遠隔地バックアップ方式 場所やハードウェアの手配も含め再構築が必要となり、復旧は長期化する が、最小限のコストで実現が可能。 AWS cloud 東京 region 環境の再構築が完了後にシステムのデー タをリストア。 Web/AP Web/AP LoadBalancer DB (現用) DB (待機) Web/AP Web/AP LoadBalancer DB (現用) DB (待機) 復旧後 現行環境 Amazon S3に対応した バックアップソフトを利用 Amazon S3
27. 27 © NEC Corporation 2018 ７．AWS利用の目的４：BCP対策として利用したい ７－２．AWS上にコールドスタンバイサイト方式 AWS上で災対環境を用意するには、現行システムがAWS上で変更なく実行 可能な場合に限ります。 AWS cloud 東京 region 災対環境 事前にサーバはAWS上で一度構 築しイメージ化しておく。 災対発動時にイン スタンスを生成す る。 ※本構成図は一例であり、システム毎に方式は異なります。 DNSサービス DNSの設定変更により 環境を切り替える。 Web/AP Web/AP LoadBalancer DB (現用) DB (待機) システムが利用する データをAmazon S3に バックアップ DB on instance Web/AP DB DBは非同期レプリケー ションも可。 現行環境
28. 28 © NEC Corporation 2018 ７．AWS利用の目的４：BCP対策として利用したい ７－２．AWS上のみでコールドスタンバイ方式 システムをクラウド上に移行できればBCP対策が完了ではありません。 ▌大規模障害を想定し、本番システムの稼働環境とは別の地域で、災対環境 を用意しておく必要があります。 AWS cloud 東京 region シンガポール region 本番環境 災対環境 利用料金のかから ないインフラのみ 構築しておく。 Amazon Route 53 イメージを別 regionへコピー 災対発動時にイン スタンスを生成す る。 DNSの設定変更により 環境を切り替える。 スナップショットを 別 regionへコピー ※本構成図は一例であり、システム毎に方式は異なります。
29. 29 © NEC Corporation 2018 ８．AWS利用の進め方 ８－１．移行計画の全体像 AWS利用の可否を判断するために、PoCから始めることを推奨します。あ わせてクラウド化推進のための体制(CoE)整備を行う必要があります。 STEP3. 展開・高度化 STEP2. 1stプロジェクト STEP1. PoC PoC実施 価値 1st プロジェクト 適用判断 効果測定 ⑦移行PJ実施 ⑦移行PJ実施 マネージドサービス 化ＰＪ実施 ③クラウドネイティブPJ実施 ③クラウドネイティブPJ実施 クラウドネイティブPJ実施 移行展開 ⑦移行PJ実施 ⑦移行PJ実施 移行PJ実施 CoE体制整備 Refactor/Rebuild/Rehost Revise 調査 今ここ
30. 30 © NEC Corporation 2017 ８．AWS利用の進め方 ８－２．PoCの必要性 AWSの利用目的を達成できるか、クラウド移行が実現できるか、PoCを実 施し確認しておくことをお勧めします。 ▌PoC実施時の検証観点 ①可用性の確保 ②NW仕様への対応 ③マネージドサービスの利用 ④監視サービスの利用 ⑤V2Vでの移行 • マルチAZ構成にできるかどうか。 • クラスタソフトとの組み合わせ検証 • オートスケール可能なアプリケーション実装確認。 • オンプレミス環境と接続時のＮＷ性能（帯域、応答時間）は十 分か。 • データベースをＲＤＳに置き換え可能か • ロードバランサはＥＬＢで置き換え可能か • ステートレス化に必要なサービスを組み込み可能か • 現行の監視項目はAWS上でも実現可能か • アラーム設定は、現行運用にマッチしたものか • 現行仮想化基盤からV2Vが可能か
31. 31 © NEC Corporation 2018 ８．AWS利用の進め方 ８－３．クラウドCoEの必要性 社内のクラウド利用を推進するとともに、クラウドを安全かつ効果的に利 用するための統制を測る組織として、情報システム部門が担う役割。 ハイブリッドアーキテクチャ オンプレとクラウドの使い分け方針を策定し、各プロジェクトへ展開する。 リファレンスアーキテクチャ クラウド上で実現するシステムの実現方式について、標準化を行い各プロジェクト へ展開する。 アイデンティティ管理 クラウドサービスを利用する（運用する）ユーザのID管理を行う。適切なロール 設計と割り当てを行い、セキュリティを担保する。 コスト・アカウント管理 利用料金の確認とコスト最適化にむけた検討。複数のクラウドアカウントを利用す る場合は、利用ルール、払い出しワークフローの策定。 アセット管理 クラウド上に構築されたシステムの資産管理および、各プロジェクトにより蓄積さ れたクラウド活用におけるナレッジの集約および展開。 トレーニング 上記内容や、最新のクラウドサービスや技術を習得した内容を、組織に展開（プロ ジェクトメンバーの育成）し、組織を強化していく。 CoEの役割
32. 32 © NEC Corporation 2018 ８．AWS利用の進め方 ８－４．クラウドCoEとベンダーとの関係 CoEの役割を全て自社で対応するのではなく、ベンダーと連携することで、 効率化／負荷軽減が図れます。 ▌CoEの役割を全て自社で対応するのではなく、AWSパートナーベンダー と連携することで、効率化／負荷軽減が可能です。 CoEの役割 ベンダーに頼れる部分 ハイブリッドアーキテクチャ ・アーキテクチャレビュー支援 ・アセスメントによるクラウド移行可否判定支援 リファレンスアーキテクチャ ・アーキテクチャレビュー支援 ・ガイドライン作成支援 アイデンティティ管理 ・運用オペレーション ・ガイドライン作成支援（ユーザ管理方針） コストとアカウント管理 ・コスト最適化にむけた検討支援 アセット管理 ・ナレッジのレビュー トレーニング ・ベンダー教育の利用 システム移行・新規システム開発等の個別プロジェクトは、CoEと独立させた体制
33. 33 © NEC Corporation 2018 ８．AWS利用の進め方 ８－5．クラウドCoE体制案 企画チーム 技術取り纏め チーム 運用管理 チーム 新技術に対するチャレンジ精神をもち、クラウドに興味のある方で構成する • クラウド戦略（ロードマップ、事業企画） • 人材育成 • 最新サービスの追従 • 設計方針・ガイドラインの作成 • コスト最適化にむけた検討 • クラウド環境のユーザ、ロール管理 システム開発 支援チーム • DB設計方針検討 • データ連携方式設計支援 • アーキテクチャレビュー ＮＷ 支援チーム • NW設計方針検討 • アーキテクチャレビュー 開発 ＰＪ 設計方針のインプット レビュー の実施 コスト最適化にむけた アドバイスの提供
34. 34 © NEC Corporation 2018 ９．まとめ AWSの利用について • オンプレミスとAWSのプラットフォームの違い を理解して利用すること • クラウド化のメリットを享受するためには、最大 限AWSのサービスを利用すること クラウド化の進め方について • 期待したことができるか、まずはPoCを実施して 確かめること • クラウド化は、クラウドに興味がある人を中心に、 ベンダーと協力しながら進めること