【要約】AWS 認定 SAP（Solutions Architect - Professional）試験範囲サービス概要
【１ このページは】
AWS認定 ソリューションアーキテクト プロフェッショナルの試験範囲のサービス概要をまとめたものです。
長いですが、1か月くらいかかる参考書でのインプットを1時間もかからず済ませられるはずです。
筆者の解釈も含まれます。情報の不足は自分で調べてください！
【２ 複雑な組織への対応】
■クロスアカウントアクセス
ロール切り替えのやつ。代表アカウントでアカウントをまたいたユーザのアクセス管理ができる。
マネコン、CLI、SDK（ソフトウェア開発キット）からも設定できるし、オンプレからの認証も可能。
サードパーティー製品との連携もできるけど、万が一IDとARNが漏れたら不正利用につながる。
そんな時は、外部IDという認証を追加して不正利用を防ぐ。
■Directory Service（３種類）
既存のオンプレにあるADと組み合わせて使いたい ⇒ AD Connector
AWSへActive Directoryを移行したい↓
⇒ 5000ユーザ以下 ⇒ Simple AD
⇒ 5000を超えるユーザ ⇒ Managed Microsoft AD（MFAいける、他ドメインと信頼）
SSO シングルサインオンは、ActiveDirectoryを使ったものとAWS SSOを使ったものと二つを合わせたものがある。
■VPCエンドポイント
・ゲートウェイエンドポイント
S3、DynamoDB用。利用料金はかからない。
けど例えばオンプレから利用するときはAWS上のEC2から接続する手間がある。
・インターフェースエンドポイント
S3も行ける、CloudWatch、SystemManagerとか用。利用料金がかかる。
オンプレからも直接利用できて、EC2の料金がかからない分こっちの方がオトクな場合もある。
■クライアントVPN
VPCとPC（クライアント）との接続をクライアントVPNを噛ますことで直接アクセスを許可することができる。
特徴：CloudWatchlogsでアクセスの履歴を残せる。Lambdaを使ってアクセスの許可/拒否をさせることもできる（接続ハンドラ、ハンドル？）
■Site to Site
オンプレミスと仮想プライベートサブネットとをつなげる方法。
冗長したりできるけどIPv4限定。
ちな接続口
オンプレ側：カスタマーゲートウェイ
プライベートサブネット側：仮想ゲートウェイ
■Direct Connect
接続2種類
・専用接続
物理イーサネットに接続！72時間以内に承認されるよ
・ホスト接続
別アカでDirect Connect使ってる人にお願いして繋げさせてもらうやり方。持ち主の承認が必要。
お金、接続タイプと時間によってかかる。データ転送にも金かかる。
●接続ウィザード
接続方法を決めて、お手軽に冗長化できる。
最大回復性:最強、4本2ロケ
高い回復性：2本2ロケ
開発とテスト:2本1ロケ接続するためにVIF(仮装インターフェイス)必要。
・出入口
プライベートVIF：EC2とかプライベートな所に繋ぎたい
パブリックVIF：S3、DynamoDBとか公な所に繋ぎたい
トランジット：Transit Gatewayに繋ぎたいLAG(Link Aggregation Group)
複数の専用線をまとめる論理IF
■VPCピア接続
VPC同士のお願いと承認が必要。
■Transit Gateway
最大5000のVPC、オンプレ接続を簡素化。
VPCアタッチメントを使うことでAZごとに接続を持てる。NICがそれぞれに必要。VPNでオンプレとも、Direct ConnectトランジットでDXとも繋げられる。
Transit Gatewayピアリング接続：Transit Gatewayの2個使いで複数リージョンと接続！
Network Managerは地図にして見れるだけ。
Transit Gateway作成時Acceleratorを有効にしとくと、エッジロケーションを、利用して高速化できる。
■Routo53
2タイプある。
パブリックホストゾーン：インターネットを介するルーティング
プライベートホストゾーン：VPC内のルーティング
・Routo 53 Resolver
オンプレ接続を解決する方法。イン／アウトバウンドのエンドポイントを作らないといけない
■AWS Organizations
組織管理、毎度クレカ、メアド登録しなくて済む。CLI、SDKからもできる。
請求書を一括管理できるし、まとめ買いの割引もあるかも。
■SCP（サービスコントロールポリシー）
新アカに付けるルールのテンプレート。
組織、チーム、ユーザ毎に付けられて、上の階層のSCPが優先される。
組織で許可されてないなら、ユーザで許可しても意味ない。みたいな
■Cloud Formation StackSets
アカウントで使い回すリソースのセット。
IAMロールとか何度も作らなくて済む。
■Cloud Trail
マスターアカウントで組織内のTrailを一括で有効化できる
■Service Cataglog
ポートフォリオと製品作成して、組織内で共有できる。
■Control Tower
アカウント自体の自動作成ツール。
Landing Zoneの自動構築ができる。
SCPや、CloudFormation StackSetsでアカウントの中身もほぼ自動で作ってくれる。
【３ 様々なソリューション設計】
セキュリティ
■AWS KMS
キー2種
カスタマー管理：ユーザーが完全に制御するキー。使う時とストレージに課金される。
AWS管理：AWSが作ってくれたキー、ストレージ料金がかからない。
・エンベロープ（覆う）暗号化
同じキーで暗号化、複合化をする方法と、別々なキーで行う方法がある。
別々の時は、データを暗号化する時に暗号化されたキーも作る。
・CMKは自動ローテーション機能がある。古いキーもKMSの中に残る。
・キーはオンプレから調達することもできる。
■S3の暗号化色々
クライアントサイド：先に暗号化してからS3にアップする。
サーバーサイド：S3にアップしたデータを暗号化。
サーバーサイドの暗号キー3つ
SSE-S3：S3が管理するキー。要件を選択するだけ。
SSE-KMS：KMSが管理するキー。Trail追跡可能、自動ローテーション可能。
SSE-C：カスタマー管理、オンプレのキーも使える。
■Cloud HSM
キー自体を超安全（FIPS 140-2レベル3に準拠）に管理するための、キーボックス的なもの。
AZにNICが作られて、28個までクラスタ作れる。
バックアップも暗号化してくれる。RDSはTDE（暗号化の方法）に対応してるけど、Cloud HSMを使ったTDEは無理。EC2でガンバレ。
■Certifilate Manager
証明書の保存、更新が無料でできる。
CloudFront、ELB、API Gatewayでドメインの証明書が設定できる。
・プライベートCA
自分で証明書機関（CA）作れちゃう。
■Cognito
ログインを安全に。大きく2種類
・ユーザープール
ログインを簡単にできる。他SNSとの連携も可能にする。
追加機能あり。
パスワードポリシー、メアド番号での認証、MFA、アドバンスドセキュリティ（漏えいしてた情報でのログインを検知、ブロック。）
ログイン時にLambda走らせて、記録をS3に残すこともできる。
・IDプール
SNSでログインした人の操作で、AWSリソースに処理を加えられる。
IDプールにロールをアタッチできるから。
■Auto Scaling
スケーリング方法５つ（SAAでやった）
・スケジュールに基づくスケーリング：時間決めてスケーリング
・シンプルスケーリングポリシー：CloudWatchアラームを指定してスケーリング。あまり使わない。
・ステップスケーリングポリシー：同じくCloudWatchアラームを使い、段階的にスケーリングできる。ウォームアップ機能ありで、無駄な起動を抑える。
・ターゲット追跡スケーリングポリシー：CPU使用率等に応じてスケーリングできる。
・予測スケーリング：（最短でも）過去24時間のスケーリングの傾向を機械学習分析により、以降48時間のスケーリングの予定を決められる。
■Auto Scaling同期処理、非同期処理。
同期処理：ユーザからのリクエストからスケーリングまでをEC2等のリソースで連携させる方法。スピードは速いけど、障害が起きたら一気に潰れる。
非同期処理：リクエストからスケーリングまでの間にLambdaを噛ませて、非同期にする方法。冗長的だし、リソースが落ちてもキューが残っていれば復旧後に処理は続けられる。AWSは非同期処理推し。
■SQSを利用してもスケーリングできる。
Lambdaを中心にキューのメッセージ数、ASグループ内のInServiceのホスト数、CloudWachメトリクスをチェックしてステップスケーリングができる。
SQSを利用して動くEC2（コンシューマ）のスケーリングに便利。
・ファンアウト（扇形に広がるスケーリング）
フロント側からのリクエストをSNSトピックに変えて、複数のSQSキューを送る。
それぞれのキューの先にAutoScalingグループがあって、それぞれスケーリングする。まるで扇形。
同時動画アップロードのような、複数の重い処理ができる。
どこかで処理が失敗しても、ほかのグループが生きてるからリトライする規模も小さくてよい。
SQSのメッセージには優先度が設定できる。それはスケーリングにも応用できる。
・ライフサイクルフック
スケールイン/アウト時に指定した処理を終わらせてからスケーリングできるようにする機能。
例：ソフトウェアがデプロイしたことを確認してからホストをInServiceにしたり、データのコピーが完了してからスケールインできたりする。
↑
多分マネコンから設定解除できない。CLI、SDK、APIからCompleteLifecycleActionを編集。
■Routo53
パブリック、プライベートに対応したDNSサービス。ドメインの購入、管理もできる。
エッジロケーションを使っているからレイテンシー低いし、ALBを噛ませば複数AZでのヘルスチェック機能も持たせられる。
しかも！固定IPをつけておけば、障害時にAMIから自動で復活させてシステム影響も少ない。すごい。
加重ルーティングもお好みで。
■Kinesis（4種類 SAAでもやった）
・Kinesis Data Streams
レイテンシー1秒未満の高機能ストリーミニグサービス。データの保存期間はデフォルトで24時間、課金すれば最長1年間。
加工、重複判定、サーバサイドで暗号化もできるし、課金でシャード単位のCloudWachモニタリングもできる。
・Kinesis Data Firehose
Data Streamsよりも設定が簡単で管理も楽。さすがにレイテンシーは負ける。
データの保存先をS3、Redshift、サードパーティサービスなど、設定時に選択するだけで使える。
・Kinesis Data Analytics
上二つのKinesisで採ってきたデータを主にSQLクエリを使って分析できる。
分析結果をまたKinesisにも送れるし、Lambdaで処理もできる。
例：TwitterのツイートをData Streamsで採ってきて、Data AnalyticsしてData Firehoseに流して、分析結果をS3に保存したりできる。どれだけ炎上したかの分析とかできるのか？知らんけど。
・Kinesis Video Streams
防犯カメラとかからのデータをリアルタイムで分析したり、確か動画の編集もできる。
■RPOとRTO（障害時のリカバリ）
RPO：このポイントまで戻してね
PTO：このタイム（時間）までには元に戻してね
バックアップをS3に保存する場合、許容できるこれらのRPOとRTOによって、低頻度とかGrecirに保存するかを判断できる。
■Storage Gateway
オンプレミスからのバックアップをAWS上に置く場合、Storage Gatewayが超便利。
置きたいデータの形によって4種類に分かれるよ。
・S3ファイルゲートウェイ
ファイル形式で保存するときに便利。要件に応じてS3スタンダード、Intelligent-Tiering（どれだけ引き出すかわからん時）、スタンダードAI（取り出す頻度が低いとき）、1ゾーンAII（取り出す頻度が低くてデータが重要でないとき）を選んでね。
・ボリュームゲートウェイ
ボリュームを使いたいとき。保管型とキャッシュ型の2種類。
保管型：オンプレミスに保管型。レイテンシー低いけど、AWSには非同期的にデータを保存。
キャッシュ型：すべてのデータをAWSに。キャッシュ型。よく使うものだけオンプレにキャッシュして使う。システムへのパフォーマンス影響が低い。
・テープゲートウェイ
テープ型のデータを保存したいとき。テープの保持規約が2種類。
コンプライアンスモード：期間中は神でも削除できない。
ガバナンスモード：権限がないと削除できない。（ガバナンスの方が少しガバガバ。）
・FSxファイルゲートウェイ
Windowsネイティブな通信が可能。
別リージョンにバックアップを取りたいときは。
AMI、スナップショットを別リージョンに定期的にコピーすることで、障害時に環境の復元が可能。
自分でもできるし、タグを使ってそうゆうバックアップを一元管理できるのがAWS Backup。リージョン間コピーもこれでできる。
障害時に早く復旧させたい！3選
■パイロットランプ
障害からの復旧を早くする方法。
AMI、リードレプリカなど復旧のための準備を沢山しといて、RTOを短くする。
バックアップの頻度を高くすることによりRPOを短縮する。
■ウォームスタンバイ
パイロットランプに加え、最小限のリソースを稼働させておく。
ちゃんと動くかのテストの時間が無くなり早い。
■マルチサイトアクティブ／アクティブ！
丸まんま同じ環境を常時稼働させておく。そりゃ早いわ。
使ってるインスタンスより高いパフォーマンスが欲しい！3選
■バーストパフォーマンス
T2.T3.T3a.T4gで使える。
一定のCPU率を超えるとバースト消費して処理する。
超えない間にバーストを貯める。
■ジャンボフレーム
1パケットでジャンボな量のデータを送れるフレーム。
■プレイスメントグループ
EC2同士の通信のレイテンシーを下げる方法。（3種）
クラスタプレイスメントグループ：同じAZにある。
パーティションプレイスメントグループ：同じAZをパーティションで分けて、その中にグループを作る。冗長的。
スプレッドプレイスメントグループ：EC2ごとにグループを分ける。7つまで。かなり冗長的。
■デプロイの自動化CodePipeline
ソース、ビルド（テスト）、デプロイまでのパイプを自動化。総称かな。
・CodeCommit：ソース管理サービス。Gitの機能を提供。
・Cloud9：ブラウザだけで開発環境を実行できる。
・CodeGuru：ソースコードのバグ、問題抽出。最適化の自動化をする。
・CodeBuild：ビルド、テスト環境を提供するフルマネージドサービス。開発用インスタンスの用意不用。
・CodeStar：loy等Pipeline、Commit、Build、Depのパイプラインをテンプレから簡単構築できる。
・CoteArtifact：パッケージ管理ツール。チーム内で安全に共有できる。
・OpsWorks：Chef、Puppetが使える。
・CloudWatch：主にAWSリソースのログ、メトリクス収集。
・X-Ray：↑よりも細かいAPIリクエスト時間などの記録をみる。バグ、ボトルネック抽出に便利。
■CodeDeploy
作ったアプリをEC2、コンテナ、Lambda等でのデプロイを自動化する。
アプリはS3とかGitHubから持ってくる。
・デプロイ設定
・EC2 3種
一気にデプロイAllAtOnece。
半分ずつデプロイHalfAtTime
1個ずつOneAtTime。そのままやん。
ECS、Lambdaデプロイ方法
・AllAtOnece：一気にデプロイ
・Canary（カナリア）：まず一定の割合をデプロイ後、期間を決めて残り全部をデプロイする。（例：まずは10％５分後にの残り全部）
・Linear（リニア）：まず一定の割合をデプロイ後（ここまで同じ）、残りを一定間隔でデプロイ。（例：まずは10％残りは10分おきに10％ずつ。）
■CloudFormation
テンプレートを元にスタックを作成して、AWS環境を簡単構築。
用語
・テンプレート：YAMLかJSONで書かれた設計図
・スタック：↑を元に作られたリソースのセット
・カスタムリソース：リソースにLambda関数を実行させて、お好みの状態にしておける。
・cfn-init：PythonがCloudFormationをお助けしてくれる設定。（CloudFormation::init、、、と記述して設定する。cfnはCloudFormationのことかな）
・スタックポリシー：テンプレートでリソースの更新をしても、スタックごとにポリシーをお好みで決められる。
DeletionPolicy：決めておくことでスタックごと削除したときに、特定のリソースを保護できる。
■Elastic Beanstalk
開発者がすぐにAWSサービスを使えるようにするサービス。
EB CLIを開けばすぐに開発環境で作業ができる。
・デプロイパターン
ローリング更新：片方ずつELBから切り離して順番にデプロイ
ブルーグリーンデプロイ：同じ環境のクローンを作って、クローン上でデプロイ。問題があれば元の環境に戻せばいい。
↑にCodeDeploy、ECR、ECSを連携させた方法もある。
Kinesis 1シャード1M1000レコ2MB/s
【４移行計画】
■Cloud Adaption Readiness Tool（CART）
クラウド導入の準備ツール。
いくつかの質問に答えるだけで、どれだけクラウド以降の準備ができているか診断してくれる。
AWSアカウントは不要。
■Application Discovery Service
オンプレのアプリ、ネットワーク情報を収集して、クラウド移行計画をサポート。
Windows、Linuxに入れる「エージェント型」とVMware用の「エージェントレスコネクタ型」がある。
Kinesisに繋げてS3にデータ保存もできるし、それをAthenaで分析もできる。
■Snow Family
・Snowcone：８TBのHDDストレージ。最小デバイスだから外への持ち出しや、Datasyncを使用したエッジロケーション経由のデータ伝送が可能。
・Snowball Edge Strage Optimizwd（ストレージ最適化）：80TBのHDD、32GBのメモリ、24vCPU。データ加工不要で大きいストレージが要るときに良い。
・Snowball Edge Compute Optimizwd（コンピューティング最適化）：39.5TBのHDD、7.68TBのブロックストレージ、208のメモリ、52vCPU。データ加工可能。
・Snowball Edge Compute Optimizwd with GPU：↑のスペックにGPUがついたデバイス。デバイス側で推論処理とかできる。
・Snowmobil：100PB（ペタバイト）まで運べるトラック。Snow Familyの転送状況はSNSトピックを作成すれば、Amazonの配送状況みたいに追跡できる。
■Server Migration Service(SMS)
オンプレのVMware、Microsoft Hyper-v、AzureのVMをEC2のAMIに移行できる。
ほとんどAWSにコピーしておいて、切り替え時に増分だけ移行する「増分レプリケーション」だと切り替え本番の作業は早くなる。
■Database Migration Service(DMS)
オンプレからのデータベース移行サービス。対象DBの種類は多すぎるから書かない。
移行状況のモニタリングも可能。
■Schema Conversion Tool（SCT）
↑のDMSはスキーマの変換はしない。ので、SCTを使ってスキーマを変換してDBを作れる。
変換するにはWindows、Mac等のクライアントにSTCをインストールしなきゃいけない。Snowballとも連携可能。
■AWS Glue
フルマネージドのETLサービス（抽出、変換、格納サービス）。
Glueのクローラーが、元のデータソースを読み取って来て、Data Catalogにテーブルを作る。その内容をS3、RDSなどに保存できる。
ちなみにPythonを使って抽出、変換してて、スケジュールも決められるし、イベント起因でも実行できる。
■Athena
S3内のデータをSQLを使って、簡単に分析できる。S3に入れたCSV、JSON、ParaquetをSQL分析するとくればAthena。
クエリ結果もS3に保存する。Quick Sightで可視化もできるし、サポートされていればサードパーティツールも使える。
Athenaで作ったテーブル情報はGlue Data Catalogにしまわれる。
■AWS SES
Eメール送受信できる。いろんなAWSサービスと連携可能。
あんまり書くことないな。
■Transfer Family
使うとS3、EFSへのデータ保存にSFTP、FTPS、FTPプロトコルが使えるようになる。
読み書きの権限はTransferサービスにIAMロールを付与することで解決。パブリックエンドポイント、Elastic IPで指定されたIPアドレスに向けても転送可能。
内部でもインターネット向けでも使えるよ。
■IPアドレスだよりの設計
・NLBは、AZごとにIPアドレスを固定できる。
・NEIにIPアドレス、SGを付与してEC２等にアタッチすることも便利。
・Egress‐Onlyインターネットゲートウェイ：IPv6利用時に使う、NATゲートウェイ的存在。
■低レイテンシーのためのサービス
・AWS Outposts：自分のデータセンターに物理のデカいサーバーラックを置く。自社にAZが1つ増える感覚。
・AWS Local Zone：リージョンの拡張。EC2作成時に有効にしておくことでユーザにより近いデータセンターを使えるのかな。
・AWS Wavelength：５Gを使いたい人のための超低レイテンシー接続帯域。
【５ コスト管理】
■EC2のコスト（大まかに４種）
・リザーブドインスタンス
1年、3年の期間で契約することでの割引。インスタンスタイプ、リージョンOSで値段は変わる。
ちなみにインスタンスタイプはt2.midiumの1年分を購入すれば、t2.smallの2年分、t2.largeの半年分としても使える。
リザーブドインスタンスにも2種類ある。
スタンダード：変更できるが交換不可。安い。（同じインスタンスファミリー内のサイズ変更は可能等）
コンバーティブル：変更も交換も可能。↑よりは高い。（インスタンスファミリーもOSも変えられる。ただグレードダウンはできない。）
・スポットインスタンス
使う料金を決めて起動させるインスタンス。予算を超えたりすると中断する。
CloudWatchと連携することで中断の2分前に通知することもできる。スポットインスタンスを使っておきながら中断されると困る場合は、代わりに起動させる用のAMIを取っておいりたり、S3にバックアップを取ったり、SQSにキューをためて処理だけは守ったりする。
・DedicatedHost（専有ホスト）
指定した特別な物理サーバー上にEC2を起動する。1分1秒課金されます。
DedicatedInstance（専有インスタンス）との違いは？？
→同じように専有物理サーバーにEC2を立てるけど、ソケット、コア、ホストIDは専有インスタンスだと見れない。インスタンスの配置もAWSが決めるので、こちらの方がやや専有度が低い。多分安いのかな。
（専有インスタグラマーより、専有ホストの方が格上）
・Savings Plans
時間当たりの料金を契約することでの割引。毎日の何時から何時まで使う、みたいな契約ができる。
■S3のコスト
引用！（これが一番わかりやすい https://sayjoyblog.com/s3_storage_classes/ ）
＝＝＝
S3 Standard ：汎用的なストレージクラスとしての利用
S3 Standard-IA ：S3 Standard と同等の性能を求めるがアクセス頻度が低い場合に利用（最小保存期間30日）
S3 Intelligent-Tiering ：アクセスパターンが予測不能な場合に利用
S3 One Zone-IA ：アクセス頻度が低く、可用性よりもコストを優先させたい場合に利用
S3 Glacier ：(すばやい取り出しが必要な) 長期アーカイブに利用
S3 GlacierDeep Archive ：(すばやい取り出しが不要な) 長期アーカイブに利用
＝＝＝
・リクエスタ支払い（先払い）
S3の料金をリクエストした側に請求するもの。有効にするとAWSアカウント以外からのアクセスができなくなる。
■DynamoDBのコスト（2種類）
・オンデマンドモード
書き込み、読み込みの回数ごとに料金が発生するモード。
・プロビジョンドキャパシティモード
１秒間に可能なWCU、読み込み回数、RCUを決める方法。
※WCU：テーブルにデータを書き込むための各 API コールの書き込みリクエスト（RCUは読み込み。）
↑どちらの方がお得かは頻度による。
オンデマンドは少し高いけど、読み書きが頻繁でない場合は無駄がないし、急なスパイクリクエストにも対応可能。
プロビジョンドキャパシティは設定の単位が1秒ごとと決まっているので、急なスパイクには対応できない。けど使用頻度の変化が緩やかな場合はこちらがお得。
・DAX（DynamoDB Accelerator）
料金追加で使用できるDynamoDBで使えるキャッシュの機能。通信早いし元テーブルへの負荷軽減（キャッシュ自体の説明してる...）AZごとに配置ができて、ノードの時間ごとに料金発生。
■ほかにも！
RDS、ElastiCache、Redshift、OpenSerch Serviceにもリザーブドオプションがあります～。
■コストのモニタリング
・コスト分配タグ：リソースに適切なタグ付けをすることで、タグごとに料金分析が行える。
・Cost Explorer：時系列でのコスト可視化ツール。タグでの絞り込みや、税金を除外なの見方もできる
日付を未来にすればコスト予測もできる。
・Cost Anomaly Detection（普通じゃないコスト検出）：削除し忘れとか異常なコストの検出。
最大10個までモニター設定可能。
・AWS Budget：予算管理ツール。８～12時間ごとに料金をチェックして予算を超えた時、超えそうなときに通知してくれる。10個までならメアド登録できるし、SNSトピックにパブリッシュも可能。
・請求アラーム：例えば料金が＄100超えるごとにアラームが欲しい場合などに使える。けどアラームにもお金がかかる。請求のメトリクスはバージニア北部リージョンにのみ保存できる。
・Compute Optimizer：EC2、AutoScalingグループ、EBS、Lambdaを分析して、本当に今のサイズが適切かをチェックしてくれる。最低14日間30時間以上のメトリクス必要。
【6 設計の改善】
■Amazon InspectorとSystem Managerの連携
EC2に入れておいたInspectorエージェントで異常を検出して、
Inspector→SNS→System ManagerでRunCommnad という流れで異常検出から復旧を自動で行うことができる。
ちなみにInspectorエージェントもRun Commnadで一斉にインストールすることができる。
■S3バッジオペレーション
たくさんのS3の管理を一気にできる。
例えば、
オブジェクトのコピー、Glacirからの復元、
タグの置き換え/削除、オブジェクトロックの保持、リーガルホールドの有効無効化、
Lambdaの呼び出し、ACLの置き換え。ができる。
異常検出３つ
■Guard Duty
リージョンごとに脅威の検出ができる。Trail、S3のログ、Flow Logsなどを分析。
DOS攻撃、悪いIPアドレス、マイニングなどを検出して、レポートも出せる。
■Amazon Macie
S3の保存された機密情報を検出できる。大事な情報をクラウドに入れたくない時とかにつかうのか？
■CloudWach Anomly Detection
CloudWachにもAnomly Detectionはある。統計とAIで異常なリソース情報（CPU使用率とか）の検出ができる。アラーム設定も可能。
■信頼設計のポイント
・ステートレス（使い捨て）
・疎結合
・急なスパイクへの対応
・DBへの接続確保
→RDS プロキシが便利。元RDSへの世俗を確立しつつ、障害時に接続させない調整もできる。
ちなみに、Auroraサーバレスにはプロキシは使えない。Data APIを使ってください。
パフォーマンス改善
■CloudFront
世界中のエッジロケーションを利用して、コンテンツ配信ができる。超早いしオリジンのS３、ALB、EC2等の負荷軽減。
CloudFlontに設定されたリソースや情報を、ディストリビューションと呼ぶ。
オリジンへのアクセス3種類
・OAI（オリジンアクセスアイデンティティ）：CloudFlontで作成できるユーザを作って、オリジンと紐づけてGetObjectだけ許可する。
・カスタムヘッダー：ALBがオリジンの時に便利。ディストリビューションとオリジン間でキーと値を設定、リクエストに指定したHTTPヘッダーが含まれていたら正しいページへご案内。含まれでいなければ403コードで追い返す。
・IPアドレス制限：オリジン側のIPアドレスでリクエストを判定したいときに使う。（？）IPアドレスはよく変更が加わるので、Lambdaなどで自動更新するのがおすすめ。
そのほかのCloudFlontの機能
・オンデマンドビデオ、ライブストリーミング配信
AWS Elemantal Media Convertというサービスで元のファイルを配信向けの形に変換してS3に保存。そのデータをCloudFlontで配信できる。
・フィールドレベルの暗号化
公開鍵と秘密鍵で特定の場所だけ暗号化できる。
例えば、ユーザが入力した電話番号を暗号化して、通信の間も暗号化したまま処理ができる。
・署名付きURL、署名付きcookie
ディストリビューションで設定した特別なパスパターンへのアクセスはこれでできる。
アクセスする側は、たぶんAWSアカウントも必要ないはず。
・エッジ関数
CloudFlontのHTTPリクエストのカスタマイズ２個
・Lambda＠Edge：Lambdaの拡張機能で、Node.js、Pythonがサポートされてる。CloudFlontだけではできない処理（他サービスへの連携とか）をする。
・CloudFlont Functions：CloudFlontの機能でJavascriptで実装できる。↑よりも軽い処理（メモリ最大２MB）が得意で、ヘッダー追加、トークン検証等ができる。
■Global Accelerator
AWSのネットワークをつかってリージョンへの通信を最適化できる。遠い所でも早い通信ができる。
接続先はEC2、ALB、NLB、ElasticIPを設定できて、通信の重みづけも可能。クライアント
クライアントアフィニティを有効にすると、同じIPへの通信をしばらく保持することもできる。
■ElastiCache
外付け？のインメモリデータストアとして使える。EC2の負荷軽減、インスタンスタイプを小さいものに留めておきたい要望があればこれが使える。
エンジン２種類
・Memcached：マルチスレッド、水平スケーリングが可能で、堅牢な感じ。
・Redis：ハイパフォーマンスで永続性がある。構造化データ対応だし、リードレプリカ/フェイルオーバーもできる。ゲームのリアルタイムランキングを出すのはコレ。
■API Gateway（のパフォーマンスについて）
・API Gatewayキャッシュ：実はキャッシュの機能がある。容量が0.5GBから237GBまでの８段階で設定できて、TTLの秒数も決められる。
・エッジ最適化API：APIエンドポイントには３種類ある。
全世界のユーザが使うなら「最適化APIエンドポイント」
特定の地域の人が使うなら「リージョンAPIエンドポイント」
VPCのみからのAPI通信なら「プライベートAPIエンドポイント」
・使用料プラン：APIキーごとに使用料を設定して、余計な通信を制限できる。
・APIの認証：IAM認証、Cognitoオーソライザー、Lambdaオーソライザーの有効化で不要なリクエスト
を排除できる。
セキュリティの改善
■Secrets Manager
DBなどの認証情報を保持してくれるシークレットに強いサービス。
シークレットの取得にはAPIリクエストを使用、Lambdaを使って認証情報の更新も可能だけど、ダウンタイムを作らないために認証ユーザーは２つ作るのがおすすめ。
（順番に更新すれば片方が生きててダウンタイムが発生しないから）
■AWS WAF
アプリ用ファイアーウォール。CloudFlont、API Gateway、ALB、AppSyncへのリクエストを許可、拒否、カウントすることができる。
アプリへの変更を加えずにアクセスセキュリティを上げられて便利。
みんなが使えそうなマネージドルール（一般的な脆弱性、ボットからの通信の管理、保護など）と、
独自に設定できるカスタムルールがある（送信元IP、送信元の国、リクエストに含まれる文字、正規表現とか）。
WASのフルログが欲しいならKinesis Data Firehoseに送れる。
■AWS Shield
DDoS攻撃から保護するサービス。２種類
Standard：無料、AWSサービスへの悪いアクセスからの保護。勝手に有効なはず。
Advanced：有料でより良いサービス。例えば↓
・EC2、IP、Routo53などリソースを指定しての保護。
・数テラバイトの処理が可能。
・24/365でDDos対策チームからの対応が受けられる。などなど、、、
Shield→CloudWatch→SNS→Lambda と連携させて、検知から自動処理を走らせて通知、サポートケース起票などもできる。
■AWS Network Firewall
VPC向けのマネージドファイアウォール。VPC内のルートテーブルのセキュリティを向上ができる。
■AWS Firewall Manager
複数アカウントでWAF、Shield Advanced、Network Firewall、Routo53 Resolverなどのファイアウォールサービスたちを一元管理できる。
コンテナ
■AWS CDK（Cloud Development Kit）
Java、Python等の使い慣れた言語を使ってCloudFormationのテンプレートを作れる。
デプロイの実行などができるCDK独自のコマンドも用意されてる。cdk hogehogeコンテナ
■ECS（ Elastic Contena Service）
コンテナを実行する場所、クラスタ、タスク、サービスの設定をする。
タスクのENIにSG設定したり、タスクにIAMロール付けたりセキュリティも色々。
■クラスタ2種類
・EC2タイプ：コンテナ起動時にEC2を立てる。何かと運用の手間はかかるけど、スポットインスタンス利用したり、重み付け設定もできる。
・Fargate：新しい方。サーバレスでEC2のような管理不要。コンテナ全体の管理に集中できる。
fargate_spotという割引のプランもある。■ECR
コンテナのイメージ置き場。■EKB
Kubernetesのコンテナを使いたい時に選択。
EKSでもEC2タイプとFargateが選べる。
以上！
この記事が気に入ったらサポートをしてみませんか？