【学習メモ】AWS SAP問題集解いてるときのメモ

※自分用のメモです。随時更新中。

■Data Lifecycle Manager
EBSスナップショットとEBS-backed AMIの作成、保持、削除を自動化できる。
CloudWatch Eventsと組み合わせて、EC2とそれぞれのEBSを完全にバックアップできる。しかも追加料金なし。

可用性に影響を与えないデプロイはブルグリ。
ローリング更新も似てるけど、エラーに弱い。

■AWS Resource Access Manager
アカウント同士、組織同士（AWS Organizations）でリソースの共有ができる。RDSの許可をしたら、許可されたアカウントのRDSの画面にリソース出てくる。
組織で許可すれば未来のアカウントも許可できて楽。

FSxの以降はDataSyncがおすすめ。ダウンタイム短い。

スロットリングは皆に平等。
エクスポネンシャルバックオフ

エ、クス、、ポネン、、、シャル、、、、バック、、、、、オフ！

■CloudWatch Logsには、埋め込みメトリクス (Embedded Metric)
CloudWatch Logsに含まれる情報を、自動でCloudWatch Metricsへ転送してくれます。

DNSルックアップとは、DNSを用いてIPを調べつこと。又はその逆。

Route 53 ResolverはVPCへのインバウンド。VPCからのアウトバウンド。

Amazon Transcribe
自動文字おこしサービス。

Snowball Edgeのスループットを上げたいなら、S3アダプター。

■EFA（Elastic Fabric Adapter）
ハイパフォーマンスコンピューティングを求めるEC2のためのインターフェース
C5以降のタイプに対応し、数千のGPUにスケールアップ可能。

RDSはIPSecVPN接続を作れば、オンプレにもリードレプリカを作れる。

■カスタムAMI
フレームワーク等がインストールされたAMIを作ることで、デプロイを効率化できる。

■AWS Shield以外のDDoS攻撃対策
・CloudFrontの地理的ブロックで特定地域のアクセスを回避
・Auto Scalingを利用。スケーリングは対策に有効。
・CloudWatchでCPU率モニタリング。異常を検知してすぐに対応。

SCPの検証をするには少しずつ。

■Amazon Elasticsearch Service
大規模かつ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する完全マネージド型サービス。
アプリケーションのモニタリングもできるし、インフラのモニタリングもできる。
ログ分析もできるし他にもいろいろできる。
超高機能な監視ツール、、か？
開始するにはまずはドメインを作るよ。

WindowsPatchBaselineなんて無い。DefaltPatchBaselineです。
まとめて行うパッチ適用は、タグでグループ分けしてね。

1000k IOPS以上はインスタンスストアね。忘れないで。

EFSだって負荷に応じてスケーリングできる。

Amazon ConnectとLexの組み合わせで電話の自動応答が自然なやりとりになる！
他サービスとも連携するならLambdaだ。

「１．リホスト」は リフト・アンド・シフト と同義で、単純にクラウドに移し替えます。
「２．リプラットフォーム」はDBサーバをマネージドなDBサービスへ移行する等を意味します。
「３．再購入」はアプリケーションを置き換えるクラウドサービスを購入する等を意味します。
「４．リファクタリング/再設計」はクラウドネイティブな機能を使ってシステムを再設計することを意味します。
「５．廃止」と「６．保持」はそれぞれ、不要なシステムを廃止したり、クラウド化の意義が小さいシステムをオンプレのまま保持する事を意味します。

■CloudFormer
既存のAWS環境のリソース情報からCloudFormationテンプレートを自動で作成してくれるツール。

NATはIPv6に対応していない。エグレスです！

CloudWatch Logsはログファイル無期限で保存できるぜ。
リージョンで上長したけりゃS3に転送しな。

■AWS Service Catalog
AWS Service Catalogは、CloudFormationの機能に加えて、[制約][起動制約][アクセス制御][製品のバージョン管理]を利用できます。
AWS での使用が承認されたリソースなどを一元的に管理。
企業標準へのコンプライアンスを確保できる。

ルール違反の検出はConfigマネージドルールとEventBridgeでできる。

静的アセット：画像とかスクリプトとかの静的資産。

RTMP：ビデオとオーディオ、その他のデータを運ぶためのプロトコル（Real-Time Messaging Protocol）

■Glacierの取り出し！
・Standard：3〜5 時間
・迅速：1〜5分以内
・大容量：5〜12時間

S3バケットポリシーは暗黙の拒否、IAMポリシーは明示的許可。

署名付きURLには書き込み権限が付与されている。アップロードできないときには有効期限を疑う。

CloudFormation。
DeletionPolicyもあれば、UpdatePolicyもある。

署名付きURLはアップロードもダウンロードもできるよ。

クエリは分析ではない。

URLで絞ったリソースへの接続制限はない、Webプロキシサーバーを用意する。

BGP：縄張りをまたいで通信する接続方法

マイクロサービス同時通信したいけどパブリックにさらしたくないならPrivateLink。

ボリュームゲートウェイのタイプは目的も若干変わる。
キャッシュ型：コスト削減、低レイテンシー
保管型：高耐久性、バックアップが目的。

Dynamoのコスト削減には、データの削除とSQSキューを使用した書き込みが有効。
頻繁に行われる処理が書き込みなのか、読み込みなのかでも変わる。
そう、場合による！！！

AWS生成タグは管理アカウントでのみ編集可能。

Auroraサーバレスは、オンプレと相性悪い。MariaDBの代わりにもならない。

EFSのデータ暗号化のタイミング
・保管時の暗号化：ファイル作成時に有効化
・伝送中の暗号化：EC2にマウントする時に有効化

IBMアプリケーションのAWS移行はEC2に置き換えるしかない。

オンプレのJava/TomcatのAWS移行ならBeanstalkで充分

Elastic Beanstalk環境のブルグリは、Swap enviroment URLsという機能ですぐにリダイレクトできる。

Power Userは名前のわりに制限かかってる。開発者への権限管理に良い。

S3使ってよさそうな時は積極的にS3使う。

aws application discovery serviceではエージェントの有無を選べる。
物理の通信状況など詳しく調べたい場合はエージェントベース。
エージェントを入れたくないなら、エージェントレスベース。

API GatewayはFagateよりもコスト効率が良い。
認証にはIAM、Lambdaオーソライザー、Cognitoオーソライザーが使える。

スロットリングってなんかエンジンブレーキっぽいよな。

問題文中の目的を見逃しがち。

Kinesis Data Firehoseから直接Dynamoへ出力はできない。
OK：S3、Redshift、Elasticserch、Splunk

別リージョンでAPI Gatewayを使いたいならエッジ最適化せよ。

DynamoDB Streams
⇒Dynamoのテーブルのデータに変更があったときに、その変更情報を暗号化してログに保存できる機能。

Route53のAPIリクエストは1アカウントごとに1秒あたり5件まで。
超えると400エラー返すよ。（Bad Request）

ENIを増やしてもパフォーマンス向上にはならない。

KMSキーはEXTERNALオリジンで作成できる（オンプレのHSMから材料を持ってこれる）。
普通材料はKMSから持ってくる。

Kinesis Producer Library(KPL)：Kinesisのデータを送る側やつら
Kinesis Consumer Library：受け取る側のやつら

共有するスタックセットは管理アカウントにあればいい。

CloudFrontは複数のオリジンから別々のコンテンツを受け取ることができる。
※ディストリビューションで複数のビヘイビアを設定する。

■Lambda関数の同時実行数
沢山のリクエストを適切に処理するためにコントロール方法が2種類ある。

・予約済み同時実行（リザーブド同時実行）
1つのLambda関数が同時に実行できる数を確保しておくことができる。
例えば上限を5にすると、絶対5個は処理できるけど、上限も5。
ちなみに実行数の合計はリージョンで決まっている。だから関数人るの上限を上げれば他の実行数が減る。
だから案外、上限を下げることで多い種類の関数を実行することができるので、大量の処理が適切に行える。無料。

・プロビジョニングされた同時実行
コールドスタートを防ぐ機能。リクエストに対し即座に応答できるように準備させておける。
お金かかります。

■パブリックとプライベートのACM証明書が使えるAWSサービス
・ELB
・CloudFront
・API Gateway
・Elastic Beanstalk
・CloudFoamation

AutoScalingでローンチされた全部のログをCloudWatchで見たい。
⇒Systems Managerを使ってエージェントをインストールする。（Run Commnadターゲットを使う。）

カスタムオリジンを使ったCloudFrontのアクセス制限
静的、動的コンテンツのFrontへの直接アクセス制限をする。
⇒・OAI作成し、ディストリビューションに追加。
・S3のバゲットポリシーにポリシー追加
・Frontにカスタムヘッダー設定
・WAFにはWeb ACLを作成し、検証。
こんな感じ。

シングルサインオンを利用してAWSサービスにアクセスしたいときは、IDプロバイダー、STS、IAMロールを使うと便利。

結局動画の保存先はS3。AWS上でOracl RACを使いたいならEC2。

RDSはまだ対応していない。2023EFSはリージョナルサービス。これだけでAZ障害対策になる。

Lambdaのデッドレターキューの目的はリクエストの分析のみ。

パブリックVIFはDirect Connentのためのもの。Routo53がヘルスチェックを合格とする基準2個。

1. エンドポイントがHTTP2xxか3xxコードを返しているか

2. 特殊テキストは最初の5120バイトを正しく出現させているか。

Routo53がRDSのリードレプリカへの通信を分散するときは、加重ルーティングを使う。
というか同じ加重でルーティングするしか方法がない。

Lambdaのパフォーマンスを上げる方法
・実行環境の再利用：実行コンテキストを再利用して実行時間を短縮できる。
・メモリの最適化：Lambdaのメモリを上げるとCPUも勝手にあがる。処理早くなる。

SQSとLambdaはあんまり相性よくない。案外API Gatewayのみのシンプル設計の方が効率がいい。

Application Discovery ServiceとVMware vCenterのAWS ApplocationDiscovery Serviceを使用することで、依存関係の調査や移行計画を支援ができる。

管理アカウントは組織（OU）に含めるべきではないし、そもそも含められない。

JupyterノートブックをAWSで使いたいなら、SageMakerノートブックとService Catalogで安全かつ簡単にできる。

LambdaやCLIは使わなくていい。

スポットフリートを使えば、費用対効果が高く常時稼働にも対応できるようになるらしい。（眉唾）

Global AcceleratorとALBでDR用の別リージョンのエンドポイントに同じ静的アドレスを保持できる。
Acceleratorは1つでいいよ。

System Managerはバゲットポリシーの自動修復もできちゃう。

Inspectorは脆弱性のスキャンをするものであって、攻撃のスキャンはしない。

削除権限はユーザ定義より、タグ管理の方が楽

Amazon Rekognitionの有名人検索コードは「Serch Celebrities」なにに使うんだろう。

IAMもCloudFormationテンプレートに含められる。

CloudFormationで唯一必須なセクションは「Resourcesセクション」
CLIからテンプレは作れない。
--regionsセクションじゃない--region!

RDSのリージョン間DRでは、勝手にプライマリには変わらないので、LambdaとSNS等で昇格させる仕組みが必要。

S3 Transfar Acceleratorはアップロード時に使うもんよ。

例えば150TBのデータセットを毎週S3にアップロードしたい。
→もしDirect Connentがあるなら、パブリック仮想インターフェース（PVI）を使えば32時間でコピー完了するで。

Direct Connectありのリージョンとなしの別リージョンの接続を安全かつ高速に保ちたければ、
アリのリージョンのパブリックエンドポイントにパブリック仮想
インターフェースを作成する。
元のリージョンにパブリックで来られるようにするイメージかな。

時間がかかっても平気なDRなら、S3のバックアップからの復元が安い。
めっちゃ時間かかるけど。

EC2、プレイスメントグループへは移動できるよ。削除しなくてもいいよ。

AWS Config
AWS内のリソースを監査したりできる。
トラシュー、社内コンプラの確保にも使える。
例えば、最近作成されたEC2か指定されたAMIから作られているかをスキャンして、違反していれば通知してくれる。

アカ毎に利用できるサービスを制限したり、請求を管理する場合はOUとSCPで管理するのがおすすめ。
IAMロールで制限するには、ポリシーの管理が面倒になることがある。

ネットワークトラフィックのモニタはやはりフローログ。
直接S3に吐き出せるから、余計なリソース使わずにコスト面も良い。

VPC同士でIPアドレスの競合を起さないためには、PrivateLinkでつなげる。
ENIがかまさるから平気になる。

■Step Functionsにも分類があった
・スタンダードワークフローステートマシン
　⇒安い。同名処理の同時実行はできない。
・エクスプレスワークフロー
　⇒高い。同名処理の同時実行が可能。

・同期実行
　⇒API Gateway、Lambda等に即時応答。
・非同期実行
　⇒即時応答には対応していない。依存性が低くてこれも良い。

■CloudWatch Synthetics
Synthetic「統合的な」「合成の」「人工的な」「模擬の」。
CloudWatch側がユーザのWebアクセスなどを模倣して分析することにより、実際に値を取るよりも早く異常を検出するためのマネージドサービス。

・クラスタープレイスメントグループは主にパフォーマンスを向上させるためのもの。
・パーティションプレイスメントグループとスプレッドプレイスメントグループが耐障害性を高めるもの。
・スプレッドプレイスメントグループは、パーティションと同様にセグメント分けする。