---
tags: AWS, WORKSHOP, MEMO
---

# AWS Professional

補足資料：https://resatotmp0001.s3-ap-northeast-1.amazonaws.com/course/advarch/html/advarch.html

- ELBはリバースプロキシとしてつかえるか→NATゲートウェイでできるわ→NATってリバプロと一緒？

- VPCエンドポイント→タイプが二つあり、GatewayとInterface、Gatewayタイプはs3とDynamoだけ。Gatewayはインターネットゲートウェイを利用するように、ルートテーブルからVPCエンドポイントに接続できるように設定する。InterfaceはENIを利用する、ルートテーブルをいじることはない。

- ENI　ネットワークインターフェース

- 疎結合アーキテクチャって別にサービス間の通信をなくすことじゃなくないか？マイクロサービスはサービス間の通信はあるよな、じゃあマイクロサービスは疎結合じゃないの？。。。なるほど、ELBを置くだけでも直接通信をすることじゃないという意味で言ってる。

- SOAは一つのアプリケーションを提供するイメージ、マイクロサービスはもっと小さい。

- アカウントを分けるのは、VPCの外で動いているマネージドサービスの利用を分けたい場合や利用コストを分けたい、利用可能リソースの上限を分けたい場合、開発者が本番環境を利用できないようにしたいなどがある。

- VPCピアリングは推移的な接続はできない。→ピアtoピアで接続設定をしないといけない。

- transitゲートウェイ、ネットワークが複雑になる場合はまとめることができる、その場合はピアリングは利用しない。

- インスタンスタイプに最近Nが追加された。ネットワークパフォーマンスが高いもの。

- 拡張ネットワーク→AmazonLinuxではデフォで有効化されてるがそれ以外だと対応されていない。API叩くと有効化できる。オートスケールする場合はユーザーデータを設定しておく。

- プレイスメントクラスター
→タイプ２つ、
クラスター→一つの物理ホストに配置される可能性が高い→通信速度が速い
スプレッド→別のホスト→耐障害性高い

- ジャンボフレーム？を設定→VPC間の通信速度改善が見込める

- Lustre FSx →black belt動画あり

- aws training → 試験のトレーニングがEラーニングである。
- 研修でやったサービスのFAQとベストプラクティスを読んでおく。（試験対策）
- 静的VPN→IPを指定
- 動的VPN→BGP（ルーターのプロトコル）をサポート　（ネットワークの説明：https://www.nic.ad.jp/ja/newsletter/No35/0800.html）
- VGW：VPN通信をするためのゲートウェイ
- transit gateway TGW　
- Direct Connect (DX) 実は通信料はVPNより安い。
- Route53　
- インバウンド
- オンプレからの通信をAWSのRoute53に向ける
- アウトバウンド
- AWSからオンプレのDNSに向ける

- それぞれの役割
- サポートチームはとりあえず、顧客サポート
- 顧客は広告代理店とそのクライアント
- 管理者はリソース管理やIAMユーザー管理、デプロイ許可など
- ADは、顧客の管理アプリで利用するユーザー管理用
- ADはAWSに移行しても良いか
- ログストレージもAWSに移行していいか
- ログはhadoop、オンプレ
- マルチAZ
- できればコンテナ化。しかし以降コストがかかるため、それは開発者次第
- 開発環境はAWSアカウントをわける→本番環境を使えないようにするため
- DBはRDS、Mysql。プライマリとセカンダリ。デフォルトの自動バックアップを利用する。Readはリードレプリカを作成。

## Day2

- SANはマウントしないと使えないから、クラウドからアクセスは厳しい
- スイッチロールはするときはグループという概念はない？
- 自動化する際の条件にタグをつけることができる。ちゃんとタグをつけているか→タグポリシー→指定したタグがついていか確認することができる。タグを必須にすることができる。
- AWS Config 設定の変更履歴をチェックするもの→タグをないことは確認できるが防ぐことはできない。
- AWS Organizations は企業の規模は関係ない
- アカウントにポリシーを付与することができる。
- Organisations ログの管理はログ記録用のアカウントを作成し、S3バケットに集約することができる。
- パブリッシングアカウント構造
- AMIやIaCをIT部門が作成管理し、配布する。
- Service Catalog
- Cloud Formationのテンプレの共有をすることができる。
- AWS Active Directory
- Simple AD
- Samba4 (Active Directory互換サーバー)
- ADの機能をすべてサポートされているわけではない
- 利用者数5000人以下
- Microsoft Active Directory
- ほとんどADと一緒
- 利用者数5000 - 50000人
- AD Connector
- WorkSpacesなどを利用するにオンプレのADに連携することができる。
- マネージドサービスを利用し、かつオンプレADに連携したい場合のみ利用。

- Workspaces
- 仮想デスクトップのサービス
- cloud formaiton
- 複数アカウントにテンプレを流すことができる。
- テンプレは役割ごとに分けるとよい。
- インフラ用
- ネットワーク定義用
- IAM用　etc...
- RDSは立てないほうが良い
- パスワードを記入しないといけないので
- パスワードはSystems Managerに入れておく
- アップデート内容
- インポート
- 実環境とテンプレの差異を修復することができる。
- テキストに載ってるコマンドは復習したほうがよい（試験対策）
- S3
- マルチパートアップロード
- 大きなファイルを送る場合、パートに分けて送信でき、送信エラーが起きた際、エラーが起きたパートのみ再送信できる。
- コードを書く場合
- マルチパートを利用したほうが良いデータサイズは100MB以上
- ダウンロードもバイト指定することで並列処理をすることができる
- 一覧情報を取得する際
- セカンダリインデックスを構築する
- 別DBを用意し、S3のEvent関数でDBにS3のメタ情報を保管。
- オブジェクトロック
- 一定期間書き換えられない機能
- クロスリージョンレプリケーション
- 今は同じリージョン内でもできるようになった
- https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/request-rate-perf-considerations.html
- Amazon Drive構築事例
https://www.slideshare.net/AmazonWebServices/stg406-using-s3-to-build-and-scale-an-unlimited-storage-service

- ElastiCache
- DBにもキャッシュ設定があるが、アクセスが集中した場合はつかえる
- Memcashed
- シンプルに使える
- Redis
- 高機能
- マスタースレーブ構成ができる
- アプリケーション開発を支援することができる
- ソート済みセットを残すことができる
- バックアップ可能

- snowball
- データを入れた筐体をオフラインで運びS3にアップロードする
- 一つの筐体に80テラまでいれる
- 時間がかかる（2週間ほど）
- Storage Gateway
- オンプレからクラウドにデータ移行する場合は、オンプレ側にサーバーを立てる必要あり。
- ファイルサーバー用に作られていない
- transfer XFTP
- データベース移行
- DMS
-　異なるエンジン間でダウンタイムを起こしたくない場合に利用
- データベースの数やデータサイズの制限など、移行元と移行先で設定が異なると移行できないので要チェック
- DynamoDBのモデリングをする際はアクセスパターンを把握しておく必要がある。

# Day3
試験対策
- cloud formation 基本的な動き、削除したくないリソースはどうすればよい
- Symtems Manager 機能が増えてるけど、一年くらい前までにあった機能を抑えとけばいい

- ビックデータ
- データウェアハウス
- 基本的にRDB
- BIツールがある前提で構築する
- 外部のDBでバラバラに保存しているものはデータウェアハウスに保存する際に統一する。
- データレイク
- データ変換をせず、生データを格納する。しかし、完全に生ではなく、どのようなアプリからも利用しやすいファイルフォーマットにしておくことが多い。（csv etc..）
- 分析ツール
- Athena
- SQL
- EMR
- Hadoopのマネージドサービス
- ETL処理にも使える
- 集計処理などに強い
- RedShift
- データウェアハウスサーバー
- SageMaker
- ML/DL、ディープラーニングの開発から運用までをトータルサポートツール
- QwickSight
- BIツール
- AthenaやRedShift（他多数）接続することができる
- IoTやモバイルデータの保存
- S3である一定の大きさまではスケールするが、秒間のアクセスが大きすぎると耐えられない可能性はある。
- そこでKinsis Stream
- データを一時的に受け止めることができる
- Kinsis Firehose
- kinsis streamsに入っているデータをS3等に書き込むことができる
- リアルタイムにデータを分析したい
- kinsis analytics
- kinsis streamsにあるデータに対してSQLを投げることができる
- EC2 t系はベースラインパフォーマンスが数十パーセントなので、アクセスが多くなった時にCPU使用率が高くならずオートスケーリングできない。そのため、t系はオートスケーリングに向いていない。
- しかし、平日のCPUスペックはt系で良くて、土日のバッチ処理だけ必要であればt系でもバーストするのでCPU使用率が高くなりオートスケーリングすることができる。
- EBSにもバーストの概念がある。→汎用SSD
- しかし、あまり危険性はない。
- ベースラインがボリュームサイズの3倍であるため。
- しかし、ボリュームサイズを小さく持ち、IOPSの高い場合は気を付ける必要がある。
- セッションデータはどこで持つのがいいのか
- Dynamo
- セッションデータは永続化したい場合
- ElastiCache
- セッションデータを永続化しなくてもいい場合

- 耐障害性
- WAF
- セキュリティーオートメーション
- サーキットブレーカー
- サーバービジーの状態でリトライすると余計悪影響なので、サーバービジーが終わったらリトライする方法。
- エクスポネンシャルバックオフ
- リトライ間隔を開けていく方法
- 本番環境でエラーに気づく場合
- クラウドでないと本番環境同等の環境が作れないことが原因で起こるエラーが多い。→クラウドを利用しましょう
- グローバルアクセラータ
- 静的データをエッジロケーションに置くことができる（？）
- リージョンのフェイルオーバーもできる
- 地理的近接性

演習

海外展開
ログデータは東京リージョンで一元管理
分析基盤　→　kinses →　データレイク　→　EMS →　Qwick Sight

フェイルオーバー　→　グローバルアクセラータ、Route53(pilot-light or warm standby)