#最初に
株式会社ピー・アール・オーのアドベントカレンダー１３日目です！
ここ3年ぐらいはマネージメント中心でしたが、技術者っぽいことをする機会に恵まれたので、Qiitaに投稿することにしました

AWS移行する人にとって、少しでも「あったらいいな」になれれば幸いです

#内容は2つ

5年振りにAWSで環境構築してみたので、その辺りを思い出す
どのようにAWS移行を進めたのか？を簡単にまとめる

#利用したAWSサービスの比較

2014年	2019年
-	AWS Backup
Certificate Manager	Certificate Manager
-	CloudFormation
-	CloudTrail
CloudWatch	CloudWatch
-	CodeBuild
-	CodeCommit
-	CodeDeploy
-	CodePipeline
EC2(Auto Scaling含む)	EC2
-	EFS
ElastiCache	ElastiCache
IAM	IAM
-	Lambda
RDS	RDS(Aurora含む)
Route 53	Route 53
S3	S3
Simple Notification Service	Simple Notification Service
-	Trusted Advisor(全項目)
VPC	VPC
-	WAF & Shield(WAFv2)
-	サポート

#2014年と2019年の主な変化(感動含め、個人的主観が含まれております)
すでに5年前に利用できたものが含まれている可能性もございます
また、5年間の全てのAWSサービスの変化をまとめたものではなく、個人の経験に基づくものです

AWSでドメイン取得できる！(以前は外部で取得したドメインをRoute53へ登録していた)
ELBが3種類もある！(CLB、ALB、NLBの3種類が存在し、以前は種類はなかった)
NAT Gatewayがある！(以前はEC2で作成していて止む無く単一障害点にしていたが、マネージドサービスになり、回避可能になった)
S3以外の共有ストレージがある！(以前はSDKを利用してHTTPSでやり取りしていたが、EFSでマウントすることでアプリ改修が少なく済む)
AuroraというAmazon独自のRDBがすごい！(何やらすごい)
AWSにWAFがある！(5年前は存在しなかった)
CloudWatchLogsがすごい！(自前でS3にログ転送していたが、EC2のステートレスな状態を保つのが楽に)
デプロイ機構が容易にできる！(以前はGlodenAMI方式という名前もなかったような気がするのと、デプロイ処理も自前だった)

#AWS移行の進め方
###2019年は既存システムをAWS移行する機会に恵まれました

AWSアカウント設計
IAM設計
インフラ設計＆ランニングコスト算出
ネットワーク設計
運用設計
移行設計
スケジュールは間に合うのか

##1. AWSアカウント設計

AWSコンソールを触る際、本番環境とSTG環境が混ざった状態では環境を触るハードルが高い
AWSアカウントを組織単位でまとめるサービスもあるが、今回は触れていない
AWSサポートは必要になったタイミングで変更が可能
- 性能試験実施の際、ELB暖気運転が必要になるのでサポートを変更する予定
AWSアカウントのルートユーザーでやることを忘れずに
- 請求アラート、2段階認証(MFA)、パスワードポリシー設定、等

参考ページ
https://qiita.com/takuya_tsurumi/items/cbeeeaa1e3a87c679f81
https://qiita.com/yu-yama-sra-airline-erp/items/c300c65d6a1a24492631

##2. IAM設計

IAMはAWSコンソールではなく、コードで履歴管理、一括適用したい
どのようにグループ、ユーザー、ポリシー、ロールを割り当てるか

プロジェクトに関係する会社が多ければ多いほど、説明に時間がかかる可能性あり

参考ページ
https://qiita.com/tonishy/items/9eb772b4a5a338ac6ee6

##3. インフラ設計＆ランニングコスト算出
####インフラ設計(大枠)

調査用のAWSアカウントを用意し、そこで仮環境構築のトライ＆エラー(このサービスを使ってみよう、ダメ。こっちはどうだ。)
既存システムで利用しているドメイン、SSL証明書は継続か、変更か
- ドメインとSSL証明書のコストを比較する
- ドメイン登録から何日経過しているか？
どのAWSサービスを使うと既存システムの要件が満たせるか
既存システムで環境起因の課題となっている点は解消するには(個人やチームで改善したいことが多くなる傾向になるが、必要最低限以上はやらない勇気のほうが必要だったりする)
既存システムのアプリへの影響を少なくするには
非機能要件を加味したインフラ設計
外部連携(外部連携アプリへの影響、外部サービスとの連携)
OSユーザーの整理及び検討
ミドルウェアの設定値の整理及び検討
インフラ構成図は何を利用して、どこに書くか(外部サービスを使わず自前で資料を作成する場合、最新のAWSアイコンを利用しているか)
本番、STGと環境の差異はどこまで許容するか？(コスト見合い、AWSサービス差、スペック差、冗長化差)
コスト節約ができる点はないか？

参考ページ
https://aws.amazon.com/jp/architecture/icons/
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/domain-transfer-to-route-53.html

####インフラ設計(各AWSサービス単位の検討ポイント)

WAFサービスはAWS WAF(どのマネージドルールか)か、それとも他サービスか？
AWS WAFv2なのか？AWS WAF Classicなのか？
DBはRDSなのか？Auroraなのか？(MultiAZ含め検討)
DBは暗号化するか？
DBのパラメータはどこを変更するのか？
リードレプリカは使用するか？しないか？(アプリ改修のコスト見合い)
ストレージはS3なのか、EBSなのか、EFSなのか(アプリ改修がどの程度許容できるのか、EFSの低頻度アクセスでどの程度コストが許容できるか)
NATはEC2か？NATゲートウェイか？(冗長化とコスト見合い)
踏み台サーバは常時起動が必要なのか？(ステートレスの概念があればいらないかも？)
ElasticIPは5つで足りそうか？(足りなければAWSへ申請が必要)
CloudFormationで何をどこまで自動化するか？(コスト見合い)
自動デプロイは何を使用するか？(Code4兄弟？jenkins？Gitはどれ？)
環境の違いによる各サービスのネーミングルール(AWSのサービスによって「-」使えたり使えなかったり、「_」が使えたり使えなかったり)
RI(リザーブドインスタンス)か？それとも定期的な停止によるオンデマンドインスタンスにするか？(用途やコスト見合い)
AWS CloudTrailは無料期間中の90日保存で問題ないか？(S3への保存は不要か？)
運用のAWSサービスはどこまで導入するか？(Shiled、WAF、CloudTrail、GuardDuty、Inspector、Config)
バッチサーバはLamdbaで動かすのはどうか？
CloudFrontの導入は必要か？(性能、コスト見合い)
外部のアプリとファイル連携している場合、Transfer for SFTPを使うか？、EC2で自前SFTPサーバを作るか？
ELBはALBか？(またスティッキーセッションは設定するか？)

参考ページ
https://dev.classmethod.jp/cloud/aws/ri-2019march/

####スペック決め

既存システムのスペック調査、既存システムのリソース調査
非機能要件を加味して、スペック決め
判断が難しい場合、スペック弱めにしておき、性能試験でチューニングする(ランニングコスト変動はプロジェクト内に共有が必要)

####ランニングコスト算出

AWSアカウントごとに算出する
プロジェクト内に性能試験による変動や、毎月のデータ量による変動がある旨を共有する
AWSの見積もりサービスに見積れないサービスがある(WAF & Shield、ドメイン取得)
移行元のクラウドコストに移行先のAWSで一時的にランニングコストがのっかる形になる
ランニングコストは常に共有し続ける

####AWS簡易見積もりツール
https://calculator.s3.amazonaws.com/index.html?lng=ja_JP
https://dev.classmethod.jp/project-management/estimate/2018-aws-re-entering-mc/

##4. ネットワーク設計

セキュリティを意識したサブネット構造になっているか
インターネットから内部へのアクセス、内部からインターネットへのアクセスはセキュリティを意識した構成になっているか
AWSのマネージドサービスや、意図的に冗長化している部分でIPアドレスは枯渇しないか
ネットワークACL、セキュリティグループはセキュリティを意識した設定になっているか
ネットワークACL、セキュリティグループは運用を意識した設定になっているか
ネットワーク構成図はどこに書くか

##5. アプリ結合

アプリのAWSに適用する箇所を修正
改修した箇所のテストをどうやってやるか？
他案件との同時並行の開発で修正箇所は発生しないか？

##6. 運用設計

閉塞と閉塞解除はどうやってやるか？
デプロイやホットデプロイはどうやってやるか？
ステートレスを保つ(Auto Scalingがいつでも対応できるように。EC2が削除されてもいい状態になっているか。プライベートIPが変更されてもいい状態になっているか。)
監視項目は何か？(アプリ、インフラリソース、AWSサービス)
検知はどのようにして、どのように通知するか？
各AWSサービスやサーバが停止した場合のリカバリ策は考えているか？
各AWSサービスのバックアップはいつ保存し、いつまで保存しておくか？また、どうやって復元するか？
各AWSサービスのメンテナンスウィンドウはどのタイミングで実施するか？
移行完了後(運用中)に継続検討するタスクをまとめておき、運用で改善する意識も持っておく(全てを完璧にやろうとしない)

##7. 移行設計

何を移行する必要があるか？
どうやって移行するか？
- DBの場合、DMS？、S3経由？、手動？
- コンテンツの場合、DataSync？、手動？
性能試験向けのデータ移行、実際の本番移行と2回あるはず
DNS移行はどうやってやるか？
移行完了後の旧から新URLへのリダイレクト設定
ドメイン移行はぶっつけ本番？お試しで取得したドメイン移行を別AWSアカウント向けにやってみたら？
移行切り戻しの検討
移行元はいつまで残すか？

##8. 非機能試験

性能試験の際、AWSへ事前申請は必要か？
脆弱性試験の際、AWSへ事前申請は必要か？
性能試験の際、ELB暖気運転を忘れずに
性能試験が終わるまでRI(リザーブドインスタンス)にしないほうがいい

参考
https://qiita.com/Nacht/items/3fd3c98ff82be641f9ba
https://aws.amazon.com/jp/security/penetration-testing/

##9.外部結合

外部アプリとの結合(AWS側の準備)

#最後に
AWS移行するという機会に恵まれたことはいい経験になった(感謝)
ここまで色々やったのだから、AWS認定試験でも受けてみようかと思った