【AWS】AWSの監視と通知
CloudWatch
各種サービスを監視するサービス
AWSリソースから送られてくるデータを保存、可視化する
メトリックス=監視項目
デフォルトメトリックス
EC2インスタンスのCPU利用率
EBSのディスクI/O
S3の格納オブジェクト数
RDSインスタンスのCPU利用率
RDSインスタンスのメモリ空き容量
RDSインスタンスのストレージ空き容量
DynamoDBに書き込まれたユニット数
RDSのようなマネージドサービスはデフォルトで様々なデータを送ってくるので何もしなくてもメトリックスを取得できる
EC2のようなマネージドサービスでないものはハイパーバイザが収集できるデータのみになる
ハイパーバイザを通して取得できるメトリックス=標準メトリックス
OSにインストールしたエージェントが送信したデータから取得できるメトリックス=カスタムメトリックス
標準メトリックスは12種類(※割愛)
メモリ利用率などはカスタムメトリックスとして取得しなければならない
取得したモニタリングデータは2週間しか保持できないので、どこか別な場所に保存しておく必要がある
アラームとアクション
アラーム
CloudWatchが取得するモニタリングデータが一定の閾値を超えたらアラーム状態にする機能
例、あるEC2のCPU利用率が70%を超えた等
アラーム状態になった場合特定のアクションを呼び出す事が可能
メールを送信する
AutoScalingポリシー
EC2アクション
→アラームとアクションを使用することで伸縮自在の構造を設計できる
アラームで複数のアクションを起こせる
例、
CPUの使用率が70%を超えている状態が3分続いた場合、新しいEC2インスタンスを追加する
4台のEC2のCPU使用率の平均が30%を切ったらEC2インスタンスを2台停止するなど
上記2つのアラーム、アクションを設定する事でコンテンツが高負荷状態になった場合は自動でEC2インスタンスが立ち上がり負荷を軽減
必要なくなったら停止するというような構造を実装できる
SNS
Amazon Simple Notification Service
通知サービス、指定したユーザーやアプリケーションにメッセージを送信できる
使用にあたっての重要な単語
メッセージ=通知内容
サブスクライバ=受信者をさす
トピック=単一、もしくは複数のサブスクライバをまとめたもの
【AWS】データベース
マネージドサービス
利用者自身がOSやミドルウェア、ソフトウェアをインストールしなくても利用できるサービスの事
サービスの可用性、拡張性、バックアップ、メンテナンス等はすべてAWS側でやってもらえる
負荷分散を行うELB、キューサービス(SQS)などもマネージドサービス
マネージド型データベースサービス
リレーショナルデータベース
Amazon Relational Database Service(RDS)
AZサービスに該当する
利用可能なエンジンとして
Amazon Aurora
MySQL
MariaDB
PostgreSQL
Oracle
Mucrosoft SQL Server
が使用可能
Amazon AuroraはMySQL互換のAWS独自のデータベースエンジン
マルチAZ配置
RDSのマスターがあるAZと異なるAZにスレーブのRDSを設置し、レプリケーションする事
MySQL、MariaDB、PostgreSQL、Oracleは同期物理レプリケーション
Mucrosoft SQL Serverは同期論理レプリケーション
データの読み取り速度アップのためリードレプリカを設置する事も出来る
クラスターボリューム(Amazon Auroraのみ)
3つのAZにまたがるクラスターボリュームが作成され各AZにクラスターデータが格納される
1つのAZが読み書き可能なプライマリインスタンスとなり、残りのAZはリードレプリカとして機能する
→どこかのAZが停止しても残ったAZのうちどちらかがプライマリとなるため障害に強い
自動バックアップ
RDSの標準機能毎日1回自動でバックアップ(スナップショット)をとる
バックアップを作成する時間帯を指定できる
バックアップ中は多少の書き込み遅延が発生する
バックアップの保持期限を0~35日の間で設定できる→0日にするとバックアップを取らない。
トランザクションログも自動的に取得している
自動バックアップとトランザクションログを利用して、特定時点のインスタンスを復元できる
パッチの適用
自動パッチ適用機能があり、この機能を有効にしておくと設定された曜日・時間にパッチが適用される
緊急性の高いパッチは機能の有効・無効に関係なく、自動で適用されることがある
ストレージ
EC2同様にGeneral Purpose SSD、Provisioned IOPS SSD、Magneticの3タイプ
DBエンジンによって最低容量、最大容量が変わってくる
NoSQLデータベース
Amazon DynamoDB
リージョンサービスに該当する
リレーショナルDBよりも拡張性が高い
デーブルのデータを3か所のデータセンタに複製する
１つ１つの項目サイズは400kbまでなので、項目は多いがデータが少ないデータ格納向け
プライベートサブネットからDBのテーブルに新しい項目を追加したり、既存の項目を読み取ったりするのにNATインスタンスが必要
Dynamoへのアクセス制限はIAMポリシーやEC2に付与するIAMロールで制限する
インメモリキャッシュサービス
Amazon ElastiCacsh
AZサービスに該当
DBへのアクセス負荷を軽減する方法としてリードレプリカを用意する方法のほかこれを使ってキャッシュする方法がある
使用できるエンジンは
Memcached
Redis
ユースケース→RDSへのクエリ結果をキャッシュすることでRDSへの負荷を軽減する
データウェアハウスサービス
※フェイルオーバー
サーバやシステムの冗長化の1つ。
稼働中のシステムやサーバに障害が発生した場合、あらかじめ用意しておいた経路と同等の待機システムに切り替える機能のこと。
【AWS】S3についてまとめ
■S3
Amazon Simple Storage Service(s3)
オブジェクトストレージサービス
データ（オブジェクト）にキー（ユニークID）を付与してフラットに格納する
各オブジェクトにはURLが付与される
1オブジェクトが5TBまで
格納可能なオブジェクト数やデータ総数は無制限
特定のリージョンにバケットと呼ばれる格納先を作成する
バケット名はAWSの全アカウント（全世界）で一意とする必要がある
S3はオンラインで頻繁に更新されるようなデータ格納先としては不向きである
静的なデータを何度も読みだすような用途に使用する
S3にはストレージクラスがある
スタンダードクラス
アップロードされたオブジェクトをデフォルトでリージョン内の3か所のデータセンタに複製される
そのため、99.99999999%の耐久性を誇る
使用用途、失うことが許されないオリジナルデータなどを格納する
RRS(低冗長化ストレージ)
スタンダードよりも耐久性は低い（99.99%）
スタンダードよりもコストが抑えることができる
オリジナルからの加工データなど再生成可能なデータを格納する
※低頻度アクセスS3が2015年から稼働しているらしい→後で調べる
スタンダードの耐久性をもちつつ、アクセス頻度が少ないデータを格納するのに向いている
■S3の整合性
オブジェクトの新規格納（ＰＵＴ）
書き込み後、すぐに一覧表示しても表示されないことがある
大事=S3から「完了」が返された後に一覧表示するとオブジェクトは存在する
書き込み後の読み込み整合性があるので
既存オブジェクトの上書き（ＰＵＴ）
大事=S3から「完了」が返されても、データにアクセスすると古いデータが取得される事がある
時間がたてば書き換わる
オブジェクトの削除（ＤＥＬＥＴＥ）
大事=S3から「完了」が返されても、一覧に表示されやりデータにアクセスする事ができる
時間がたてば削除される
■S3のアクセス制限とセキュリティ
デフォルト
そのリソース（S3バケット、オブジェクト）を作成したアカウントにだけアクセス権限が付与されている
アクセス管理方法
アクセスコントロールリスト（ＡＣＬ）
バケット、オブジェクト両方
ほかのＡＷＳアカウントからの書き込み、読み取りの許可を設定できる
オブジェクトに付与されているURLについてもHTTPSアクセス許可を与えることができる
条件付きアクセス許可やアクセス拒否は設定できない
自アカウント内のIAMユーザー、グループのアクセス権制限もできない
バケットポリシー
バケットのみ
自アカウント内のIAMユーザーやグループにアクセス許可を与えることができる
他アカウントのユーザーに対しても許可を設定できる
条件付きアクセス許可、アクセス拒否も設定可能
IAMポリシー
S3へのアクセス許可を設定したIAMポリシーをIAMユーザーやグループ、ロールに割り当てることができる
条件付きアクセス許可、アクセス拒否も設定可能
他のアカウントを指定したアクセス設定はできない
著名付きURL
有効期限付きURLを作成することができる
例）10分間だけアクセス可能なURLを発行する
商品Aを購入したユーザーに特典映像として特典Bのオブジェクトに10分間だけアクセスできるURLを発行する
→得点BのURLを購入者以外に流れてしまっても10分経てばアクセスできなくなる
■オブジェクトの暗号化とアクセスログ
S3バケットに格納されているオブジェクトを「任意」で暗号化できる
AWSが管理する鍵やユーザが管理する鍵を使ってサーバサイドで暗号化することができる
クライアント側で事前に暗号化したデータをアップロードする事もできる
S3バケットへのアクセスログは任意で同じ/異なるS3バケットに取得する事ができる
アクセスログの取得はベストエフォードで記録されるため完全性は保証されていない
アクセスログの格納バケットへのログの書くのは実際のアクセスから時間をおいて行われる
■S3の静的webサイトホスティング機能
S3のwebサイトホスティング機能を使用することで静的なwebサイトをS3設置に設置できる
EC2を利用するよりも安価にwebサイトの運用ができる
PHPやJSPなど動的にページを生成するようなサイトはできない
この機能を利用した場合のアクセス先のエンドポイントは決まっており
そのエンドポイントを所有しているドメインでアクセスさせるためにはRoute53などのDNSサービスで名前解決が必要
■S3のバージョニング機能
オプション設定でバージョニング機能を設定できる
オブジェクトにキーのほかにバージョンIDが付与される
オブジェクトを上書き保存すると、別バージョンIDが付与され、前のオブジェクトとは別に格納される
オブジェクトを削除する場合も異なるバージョンIDと削除マーカーが付与されたオブジェクトが生成され削除前のオブジェクトが保持される
■S3のライフサイクルとGlacierへのアーカイブ
AmazonGlacier
削除したくない、できないが普段アクセスすることはほとんどないデータ向け
データのアーカイブや長期バックアップの格納先として利用
S3と同等の耐久性がある
S3よりもコストを抑えることができる
格納する方法は2種、S3のライフサイクル機能とSDKを使って直接格納する方法
S3のライフサイクル機能
S3に格納したオブジェクトを指定した日数経過後にGlacierに移動したり削除したりできる
→とあるログを1年後にGlacierに移動、5年後に削除ということをジョブで自動化できる
Glacierに格納したデータはそのままでは参照できず、取り出す必要がある
データを取り出す時間はデータの大小関係なく3~5時間かかる
データの取り出しはGlacierに保管しているデータ量（月平均）の5%までは無料だが、それ以上は取り出し料金が発生する
xR Teck Tokyo #9に参加してきました。
参加してきました。
※聞き間違っている部分あると思います。特に理解できてない部分は変な事言ってるかも
全体のまとめ
振り返るとVtuber関連のセッションばかりだったような気がします。
2016年以降、大きな話題もなく一般の目からは衰退しているように見えるVR業界ですが、Vtuberの登場で一気に盛り上がり、新しい場面に突入しているような気がします。
会場で感じたのは発表者、参加者、コンテンツ展示どこもVR界隈を盛り上げていこう！というパワーやる気にあふれており、元気を感じた。
実は私はVR teck Tokyo #3から参加しているのですが、にもかかわらずいまだにコンテンツ開発に踏み切れていないので今年こそはここに少しでも参加できるようになりたいです。
■xRでN足のわらじを履いてみた話
JackMasaki
VR関係の情報を集めているとよく見るJackMasakiさん。
実は、
学生
株式会社ホロラボのバイトリーダー
MoguraVRの記者
Mark-onの代表
と複数のわらじを履いている。
●メリット
相乗効果（じさくじえん）が乗る
ホロラボの記事をMoguraVRで記事にしたり
MoguraVRでViVEトラッカーの記事を書くため、Mark-onで作成したコンテンツを使ったり等
つながりが増える
複数コミュニティの橋渡し
考える方向が広がる(水平思考)
毎日が新鮮で楽しい
毎日新しいことをやると楽しい人向け（毎日同じことして楽しい人には向かないかも？）
●デメリット
忙しい
1日の睡眠時間が15分から20分
2か月に1回たまに倒れるように寝るらしい・・・
専門性の低下（いろんなことを浅く広くさわることになる）
時間がたりない
炎上案件が複数重なるとつらい（最大3案件重なったことも・・・）
連絡が錯綜する（誰に何を連絡しなければならないかわからなくなる等）
Mark-onで1週間でゲームを作った話
1月13日に行われた銀座VRというイベントでコンテンツを出すために1月4日から11日までの間（12日は設営テストのため）にコンテンツを作成する必要がある。
そのために開発合宿を行った。
●合宿のメリット
unity初心者に指南がすぐできる
リアルタイムのハードウェア対応
つまりポイントの見える化
いつでも実機デモでフィードバック共有
→主にコンテンツを効率的に作成できるというメリット
●合宿のデメリット
せまい→6畳に男4人が生活しているので環境劣悪
※特に寝る場所がない
生活リズムのずれ
食事ペースのずれ
→人間へのストレスがパナイ
●Mark-onについて
jack氏が洗脳して連れてきた人達（全員社会人）
宗教団体かもしれない・・・
●ゲームについて
ゲームにあまり興味のない若い人でもたのしめる
オタクをのけ者にしない
●VRZONEの民
VRZONEに集まってVR体験するような人の事
VRZONEに来る人はゲーム大好きなオタクユーザーではなく、キラキラしたリア充が集まる
（私も実際行ったことがありますが、外国人の団体やゲームセンターでは間違いなく見ないようなリア充やカップルが多いです）
特徴として、何かになりたいのではなく自身が体験したいという人の集まり
例）マリオカートでオタクはマリオになりたい！ピーチになりたい！と選ぶが、VRZONEの民は気にせず業務的に奥から詰めて座る
VRマリオカートは座る台によってキャラが固定されているため。マリオになりたい場合は１Pの台に座る必要があるが民たちは気にしない
●彼らを意識したコンテンツ
彼らには難しいストーリーは通用しないため、想像しやすい設定が必要
例えば、プレイヤーを無敵とする場合
実は痛覚がないとか、実は特殊な力で無敵であるというストーリーは理解できない
今回は巨人としたことによって巨人＝無敵（ガリバー旅行記など）と想像しやすく設定を受け入れやすくした
●オタクをのけ者にしない
オタクが好きなものをゲーム内に盛り込む
へんなこだわりを入れる
マップに存在する家。実は中をしっかり作りこんであり窓からのぞき込むことができる
スコアを入れる
スコア好きでしょ？
ほかに隠し要素やコンテンツ内にナビゲータを置くなど
●まとめ
ゲーム作りの話は非常に参考になった。
VRZONEはそもそもゲームセンターに通うようなタイプとは真逆のタイプがお金を払うコンテンツ、空間を目指しており
今後VRが盛り上がるにはこの辺の人たちを取り込む必要がある
こういう人たちに受けるコンテンツを作る考え方はゲーム大好きな人たちが考え付くのは難しいのでとても良い
■生放送におけるモーションキャプチャーの活用について
みゅみゅ
現在生放送で大人気のみゅみゅ氏
●生放送を始めた理由
つまらない人間が面白い生放送をするには？
↓
モーションキャプチャーで3Dキャラを使って放送したらおもしろい！
始めたのは2012年頃、kinect v1の開発機を入手できたのでやってみた。
当時MMDにkinect v1対応プラグインが登場したため。
生放送のフィードバックから表情が変わらないのが怖いという指摘
Wiiリモコンで表情を変える機能を実装して放送していた
kinect v2が登場、フェイスキャプチャが可能になる
フェイスキャプチャが違和感がすごくて特に左右の目が別々に瞬きするのが気持ち悪いと指摘される
フェイスキャプチャを頑張るため様々な技術を試す
●フェイスキャプチャまとめ
アニメキャラがリアルに動くとどんどん不気味に見える
ジト目とか恐ろしい子のようなアニメ的表現の表情ができない
表情筋が筋肉痛で痛い
●指の動きの取得
kinect v2はｸﾞｰﾊﾟｰのON/OFFしかないため中途半端でキモイ
特に親指の動きがおかしい
色々ためすが満足のいくものがなかった
kinectは
生放送するとカメラを常に向いてる必要があり、画面に変化が少なく面白くない
ということもわかった
現在、VR空間内で生放送をする事で大体の問題が解決された（最適解だとは思っていない）
●VR生放送の欠点
HMDをつけっぱなしなので疲れる
一人で配信しているため、放送開始ボタンを押したりするのが大変
放送でダンスしているがケーブルが良く絡まる
たまに壁にぶつかる
いつかケガをする・・・
※放送中にベットに横になったりしたが、実は椅子を2つ並べた上に寝ころんでおり、かなり危険だったり
ただし、想像力次第で無限にネタが作れる
結論
中の人が面白ければ静止画一枚で十分
こんなのいらない
●まとめ
自分はVtuberではないと終始おっしゃっていたが、Vtuberに興味のある人向けの内容だったと思う
一人生放送は大変というのもこれからやりたいと思っている人向けだし、生放送を簡略化するサービスの開発などにつながるわけで・・・
次のセッションがまさにそれなのだが・・・
■世界のxRコミュニティの話とちょこっとバーチャルキャラクター配信システム「AniCast」の話
Somelu
やっぱりツイッターでよくお見掛けする人
VR界隈では知らない人がいないくらい有名なGOROmanさんの会社に所属
GOROmanさん、本だすってよ→出たら買います
●海外のVR事情について
メモ抜けがあったのでさらっと書きますが
海外各国にVRコミュニティが多く存在している（SVVR、 FIVR、EEVR）
VRの未来についての質問をしたところ、国によって考え方はいろいろだが
安価なVRハードが登場した事はポジティブにとらえられている
（キラー）コンテンツ不足な状態でコンテンツの追加が最優先である
新しいメニューのインタラクト、移動方法などが必要でできればVRに新しい革命を起こせるかも？
●AniCastについて
一人でも簡単にVtuberになって配信できる機能の開発
もともとはgugenka社から同社の東雲めぐをVtuberデビューさせたいとのオファー
そのためにシステムを開発した
PCとOculus(+touch)で簡単に配信が行える
放送中のカメラ切換えなど放送者自身ができるため、一人での配信が可能
遅延のないリップシンク、イキイキとした表情がうり
技術的な話はuniteで発表したVR MAGICを見てくださいとの事
https://www.slideshare.net/Unite2017Tokyo/unite-2017-tokyovr-magic4
録画と編集は別ツールで画面キャプチャする必要があるが、配信はとても簡単にできる
表情の変更について、オートな部分とマニュアルな部分がある
実はCGワールドの取材を受けていて、詳細はそこに書かれるそうなのでCGワールドを買おう
まとめ
みゅみゅ氏講演で話していた現在の生放送の敷居の高さを一変する事ができそうな話だった
めぐちゃんかわいいからみんなでファンになろうよ・・・
ショートセッション
あんまりメモとってないので軽くさわる感じですが。
■VRから始めるVtuber世界の予算と未来
はるねずみ
現在のVtuver界隈のまとめ情報
すでに630人くらいのVtuberがいるらしい
配信方法が様々あり、敷居が下がっている
キャラの１枚絵があるだけのVtuber?という感じでも、
そもそも動画もなく一枚絵しかない状態でもファンが付くなどキャラクター商売ともいえる
■Facebook AR Studioについて
Junji Suzuki
facebookが開発しているARstudioを使う
SNOWみたいな機能
あまりにも開発中感が強く、何かに使える段階にはなさそうだが・・・これからに期待
顔だけVtuberみたいなことはすでにできるらしい
■xRを作る前に知りたい最適化基本のキ
野生の男
開発したコンテンツのフレームレート、パフォーマンスの向上
これ全然ついていけなかった・・・スライド公開してほしい・・・
今コンテンツを作ってないので、全然ついていけない。後で絶対必要になる知識・・・
■Vtuberによく似た何か
inuchin
ハウステンボスにある変なバーの話
バーチャルバーテンダーの中の人（バーチャルオペレーター）の話
日本のオジサンはいきなりセクハラしてくるので中の人のストレスがマッハ
なんとかしたい、Vオペレーターをある程度AIに任せるには？という話
そもそも現在のVtuberは属人性（本人でないとキャラクターを表現できない状態のことをさす）が高いと言える
属人性を下げることで中の人の採用窓口が広がる、AIに任せられる領域が広がるなどメリットがあるのでそれを開発していきたい・・・という感じ？？？
まとめを上に書いたので書くことありませんが、知り合いになんか配信したいとずっと言ってる人物がいるので、これで勉強させたいと思います。
【AWS】EC2について
EC2
Amazon Elastic Conmpute Cloud
仮想サーバのこと
以下は起動に必要な設定の順に追っていく
①AMIの選択
Amazon Machine Image
仮想サーバに設定するマシンイメージ
AWSから提供されるwinServerやlinaxといったマシンイメージを選択できる
利用者自身が利用しているEC2インスタンスをカスタムAMIとして保存することもできる
②インスタンスタイプの選択
マシンの性能のタイプの事、CPUのコア数やメモリなどのスペックがそれぞれ違う
インスタンスタイプはスペックのバランスによってインスタンスファミリーというグループにわけられる
③ネットワーク、IAM、ユーザーデータの設定
ユーザーデータ、OSの起動スクリプトのようなもの
EC2インスタンスの初回起動時に実行したい処理を設定する
ElasticIPを割り当てる場合、初回起動のEC2はインスタンスIDを持っていない
この問題を解決する方法としてメタデータが存在する
メタデータにはインスタンスIDやIアドレスなどEC2インスタンス自体に関連するデータ
④ストレージ
EC2に接続するストレージを選ぶ
ストレージは大きくわけで2種類設定できる
Amazon Elastic Block Store（EBS）
AZ内に作成されるネットワーク接続型ブロックストレージ
不揮発性
EC2を停止してもデータは消えない
IOPSがインスタンスストアに比べて遅い
利用料金がかかる
ディスクタイプが複数種類あり
磁気ディスク→IOPSが遅いが安いコスト重視マシン
generalSSD→一般的なマシン
Provisioned IOPS SSD→IOPSの最大が高く、高速な返答やDBなどに利用される
さらにEBSはネットワーク接続のため通常のネットワークとEBSのディスクI/Oが同じネットワークを流れていることにより、その部分がボトルネックになる
その場合はEBS最適化インスタンスとして立ち上げることで専用帯域を確保してくれる
EBSはスナップショットをとってデータのバックアップをとることができる
スナップショットはデータの整合性を保つため、一度ディスクIOを停止させるかEBSボリュームをアンマウントしてからスナップショットを実行すること
実行時は開始時のスナップショットを保存するので、保存が完了する前に戻しても実行後に書き加えられたデータは無視バックアップしてくれる
スナップショット元と同じAZ内に複製することも別AZに複製することも可能
スナップショットは別なAZやリージョンにコピーすることができるため複製可能
インスタンスストア
EC2インスタンスの物理ホスト内の内臓ストレージ
揮発性
EC2インスタンスを停止すると保存されているデータが削除される
※再起動はいける？？
IOPSが高速
利用料金がEC2に含まれるため無料
⑤ タグ付け
EC2にタグを設定できる
このタグを使ってEC2インスタンスを検索できる
⑥セキュリティーグループの設定
⑦キーペアの選択
EC2のステータスと料金
EC2は初回起動するとpending状態となり起動処理が終了するとrunning状態になる。
running状態になってからシステムのチェック、OSのチェックが走るのでrunning状態であってもアクセスできないタイミングが存在する
running状態になった時点から料金が発生する。
プレイスメングループ
同一AZ内のEC2同時の通信を高速したい場合に用いる
AZの中にプレイスメントグレープを作成にその中に複数のEC2インスタンスを設置するとそのEC2同士は高速で通信可能になる
その代わり冗長性が失われる
dedicatedインスタンス
EC2はデフォルトではどこかの物理ホスト上で起動するが、それは自身だけではなく他社も利用している可能性がある。EC2にインストールするソフトはツールにはそういう複数のEC2インスタンスが同一ホスト上で共存していることを許可しないものがあったりする。その場合にdedicatedインスタンスを使うことでハードを占有することができる
【AWS】AWSのネットワーク
■VPC
Amazon Virtual Private Cloud
AWS上にプライベートなネットワーク空間を構築でき、インターネットやオンプレミスのイントラネットなどの外部ネットワークと接続できる
特定のリージョンに対してVPCを作成する
VPCの中にサブネットを作成する
サブネット
サブネットは複数のAZにまたがって作成できない。AZの数だけ作成する必要がある。
サブネットはその中に配置するサーバの役割事に作成するのが一般的
複数のAZに同じ役割のサブネットを作成、サーバを設置することで、冗長化され、故障に備えた設計にできる
サブネットごとにインターネットとのアクセス制限をかけることができる
インターネットにアクセス許可をしているサブネットをパブリックサブネット
インターネットとのアクセスを許可してないサブネットをプライベートサブネットと呼ぶ
同じVPC内のサブネットであればサブネット間通信が可能
ゲートウェイの生成
外部ネットワークとつながるための出入り口ゲートウェイを作成する
インターネットにつながるGWをインターネットゲートウェイ（IGW）といい、
オンプレやVPNの専用回線につながるＧＷをバーチャルプライベートゲートウェイ（VGW）という
ルートテーブル
ルートテーブルにデフォルトゲートウェイのターゲットとしてIGWが設定されている→パブリックサブネット
デフォルトゲートウェイのターゲットがIGW以外ならばプライベートサブネット
ルートテーブル内の「10.100.0.0/16 local」はデフォルト設定のため、変更削除は行えない
NATインスタンス
プライベートサブネットのOS更新など一時的にインターネットにつなぎたい場合
NATインスタンスを使用して一時的にインターネットにアクセスできる
NATインスタンスを使用時、インターネット側からサブネット側にアクセスを受け付けない
サブネット側からインターネットやリージョンにアクセスできる
NATゲートウェイ→調べよう
■セキュリティグループとネットワークACL
VPCのファイアウォール機能
セキュリティグループ
EC2、ELB、RDBなどのインスタンス事に適用しアクセス制御を行う
各インスタンスに少なくとも1つのセキュリティグループを適用する必要がある
ステートフル→送信時にアウトバウンドで許可されて送信したトラフィックはインバウンドで許可してなくても受け付ける。その逆もまたしかり
受信→インバウンド
送信→アウトバウンド
インバウンドはデフォルトで許可されているルールがないためどこからのアクセスも受け付けない
アウトバウンドはデフォルトですべての宛先・ポート番号に対するアクセス許可をするルールが設定されている
ネットワークACL
サブネットごとのファイアウォール
デフォルトでは全ての送信受信が許可されている
指定したIPアドレスとポート番号の許可だけでなく、拒否もできる
ステートレス→インバウンド、アウトバウンドともに許可を出さないとトラフィックを受け付けることができない
■VPCピア接続
2つのVPCを接続する機能
本番環境と開発環境を異なるVPCで作成した場合に
２つの環境をVPCピア接続を利用することで通信可能になる
ピア接続が確立するとPCXというゲートウェイ相当のものが作成される
ルートテーブル設定でターゲットをPCXにすることで各VPC内のサブネット間でプライべートIPでの通信が可能になります
VPCピア接続は制約があり
接続するVPCは同じリージョンに存在する必要がある
VPCのプライベートネットワークアドレス空間は重複していない
1対1の接続であること
【AWS】責任分担セキュリティモデルとAWSの認証
●責任分担セキュリティモデルとは？
AWS上のシステムを不正アクセスから守るため利用者とAWSが協力してセキュリティを高める必要があります。
サービスの種類によって、利用者とAWSがそれぞれ責任を持つ範囲は変わります。
各サービス毎に利用者とAWSでそれぞれの責任範囲を明確にすることが目的です。
●IAM
AWSのアクセス制御を行うサービス
IAM（Identity And Access Management）
AWSアカウントを作成したときに作られるアカウントはルートアカウントと呼ばれる
ルートアカウントの権限はすべてのサービスを制御することができるが、ルートアカウントの権限は制御できないため情報漏洩を防ぐ意味でも普段は使用しない。
IAMでグループやユーザを作成します。作成されたばかりのグループやユーザにはIAMポリシーが設定されていないため何のサービスにもアクセスできない。
なので、用途によって必要最低限のアクセス権限を割り当てます。
アクセス許可と拒否のような相反するポリシーを付与された場合より厳しい権限が（この場合は拒否）が優先的に適用される。
各IAMユーザーはアクセスキーとシークレットキーのペアを作成、保持する
このアクセスキーとシークレットキーは各サービスに接続する認証情報として利用できるが、セキュリティの観点から各キーをEC2インスタンス上のプログラムに等に記述されることは推奨されない。
代わりにIAMロールを使用する
IAMロールはEC2インスタンスにIAMポリシーを付与するようなもの
IAMロールを割り当てられたEC2インスタンス上のプログラムはアクセスキーとシークレットキーがなくても各種サービスやリソースにアクセスすることが可能
IAMユーザーを全従業員１人１人に割り当てるのは非効率的
AWSには一時的に認証許可を行うSTS(Security Token Service)というものがあり、
STSと会社の従業員IDなどを紐づけて一時的にサービスへのアクセス許可を出すことができる。これをIDフェデレーションと呼ぶ
●まとめ
責任分担セキュリティモデルは利用者とAWSでそれぞれどこまでセキュリティについて責任を持つかを明確にすることである。
ルートアカウントは使用しない、IAMユーザ、IAMグループを作成する
IAMは厳しいIAMポリシーが優先される
セキュリティの観点からアクセスキー、シークレットキーをプログラムに記載するのは推奨されない、EC2インスタンスにはIAMロールを適用する
たくさんの従業員がいる会社などでは１人１人ユーザを作成するのは非効率的なのでIDフェデレーションを利用する
