1．VPC作成 サブネット作成 インターネットゲートウェイ作成 ルートテーブル作成
①VPC作成
②サブネット作成
アベイラビリティゾーンに気をけて
③インターネットゲートウェイ作成（作成後に、VPCのアタッチ忘れないように）
④ルートテーブル作成
VPCを選択する必要があり
参考URL
重要なこと
すべての設定が完了したら
VPCのリソースマップくらい見ておくとOK？
AWSの考えるパブリックネットワークとプライベートネットワークの違い
EC2の場合
パブリックネットワークの場合
グローバルIPアドレスありでサーバ構築
プライベートネットワーク
グローバルIPアドレスなしでサーバ構築
※当たり前なことかもしれないが、AWSの考え方。うーん。
5. EC2作成
6. S3作成
6-1 バケット設計
どのログをどのバケットに置きますかをまずは設計
基盤のログ
アプリのログ
ネットワークのログ
アプリのコード
基盤のスクリプト
Inspectorのログ
DBのバックアップなど
それぞれ何日保管したいですか
CloudTailで追っかける必要ありますか？
それによって、暗号化方式を検討する
6-2 バケットの詳細設定
設定考慮点
１．バケットのバージョニング
２．暗号化タイプ（通常SSE-S3)でいいと思う。
３．Inspector等のログならSSE-KMSのほうがいいと思う。
４．バケットキーは無効でいいと思う。SSE-KMS選択の場合は有効？
※たくさん呼び出すなら。そもそもそんなにInspector実行するかなぁ
6-3 レプリケーション設定
※事前作業
１．東京側にバケットを作成
２．東京側に必要なディレクトリ作成
３．東京側に必要なライフサイクルポリシー設定
４．大阪側にバケット作成
５．大阪側に必要なライフサイクルポリシー設定
※大阪側にはディレクトリは作成しない
※大阪側のファイル削除は、大阪側で実施する必要あり。レプリケーションでは削除されない（はず）
レプリケーション設定
１．ルールのスコープの選択：基本的にすべてのオブジェクト
※個別に実施したい場合は別途検討
２．送信先のバケット（大阪向け）
３．IAMロールは新しいロールの作成を選択
その他はチェックなしで作成
6-4 ライフサイクル設定
1.複数ルールを作成する場合は
ルールスコープは
1つ以上のフィルターを使用してこのルールのスコープを制限する
2.プレフィックス
ディレクトリ名が「zzzz」の場合は
「zzzz/」な感じで。最後に「/」をつけ忘れないように
以下は要件次第だけど、S3でもっとも重要な部分はここだと思われる。
3.オブジェクトの現行バージョンを有効期限切れにするにチェックを入れる
4.オブジェクトの非現行バージョンを完全に削除にするにチェックを入れる
結局
3.でオブジェクトの有効期限を設定する。
※ここがややこしいのは、s3へどうやってアップロードする部分を含め検討しないといけないからここだけで検討することはできない
※アップロード方法は、aws s3 cp syncで実施していたので、その部分を考慮して設計しました。
4.オブジェクト削除マーカーをつけるまでの日数とだけどどんなけ残したいの？だから
基盤のログ等は、日付付きでアップされるから削除されることはないだろうが
アプリのソースコードみたいに同じファイルでアップされる場合はどういったほうがいいのだろう。。。（そんな昔のソースコードいるって話だけど(笑)）
7. VPCエンドポイント
7-1 S3ゲートウェイ作成
7-2 ssm用エンドポイント
前提：エンドポイント用サブネットを作成していること（AZ毎に）
プライベートでSSM接続するために必要な設定まとめ
・EC2側にロールの付与
・エンドポイント側のセキュリティグループにHTTPSの「443」を明示的に許可
※TCPとかでの全許可ではNG。イミフ
・エンドポイントを3つ作成する必要あり
※amazon-ssm-agentが新しい場合は2つでいいみたい。この項目のしたにURL載せておきます。
SSM用エンドポイント作成手順は以下のサイトを引用させていただきました。
自分がはまったこと
どうもHTTPSの443でセキュリティグループのインバウンドルールを許可しないといけないみたい。
※TCPですべてOKではだめだった。。。うーーんよくわかんないけど
マスト必要なのは
「com.amazonaws.region.ssm」
「com.amazonaws.region.ssmmessages」
ssm agentのバージョンが古い場合は以下も必要みたい
「com.amazonaws.region.ec2messages」
※
セッションマネージャーを使用してのスナップショット等に使用する場合必要みたい
「com.amazonaws.region.ec2」
ちなみに現在の環境は、上記4つともエンドポイント設定あり。
※1つのエンドポイント月額おおよそ10ドル（時間料金: USD 0.014 / 時間）
※2つ不要であっても2000円かぁ。。。
※az毎で環境が本番・開発で4つで月額4000円。まぁあってもいいかな(笑)
セキュリティグループにセキュリティグループを紐づける
EventBridge
AWS backup
AWS Config
IAMユーザ作成・IAMグループ作成
マネコンの接続IPを限定する
パターン①
A.ソースのIPアドレスだけで許可する
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"10.0.1.xx/24",
"xx.xx.xx.0/24"
]
}
}
}
}
パターン②
A.ソースIPアドレス
B.AWSのサービス経由
C.Cloudshellも追加する（AWSサービス経由に含まれない・・・・そんな馬鹿な・・・）
さすがクラスメソッドさん・・すごいスキル
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"10.xx.xx.xx/32",
"10.0.113.xx/32"
]
},
"Bool": {"aws:ViaAWSService": "false"},
"StringNotLike": {
"aws:userAgent": "*exec-env/CloudShell*"
}
}
}
}
パターン③
VPCエンドポイントからマネコンへ接続する場合も考慮すると
最終系
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"10.xx.xx.xx/32",
"10.0.113.xx/32"
]
},
"Bool": {"aws:ViaAWSService": "false"
},
"StringNotLike": {
"aws:userAgent": "*exec-env/CloudShell*"
},
"StringNotEquals": {
"aws:SourceVpce":[
"vpce-0123456543yutqwzx",
"vpce-xxxxccda334xx2345"
]
}
}
}
}