AD

※Active Directory
Windowsのサーバーに搭載されている(GUI)機能で、ネットワークにつないでいるクライアント端末やサーバー、プリンター、アプリケーションなどの情報を収集し、一元管理できるディレクトリサービス。

※Windows2000から導入されておりWindows Server標準機能であるため、特別なソフトのインストールは不要。

ADサーバをもとに、ユーザー認証・アクセス管理・ソフトウェア管理・接続機器の管理・操作ログの管理など可能。

●LDAP

ADのプロトコル。ネットワーク機器やユーザーID、パスワードを管理する「ディレクトリサービス」の維持やアクセスを行うプロトコル。

Simple AD

社内のActive DirectoryとIAMを連携するのではなく、AWS上に別のADサービスを構成する。
・ユーザーアカウントやグループメンバーシップの管理
・グループポリシーの作成および適用
・EC2 インスタンスへの安全な接続を提供
・Kerberos ベースのシングルサインオン (SSO) を使用できる

AD Connecter

・AWSとオンプレミス Microsoft AD の間で信頼関係を設定する方式を利用していない。
・クラウドの情報をキャッシュしない

[仕組み]
既存オンプレミスの Microsoft Active Directory のユーザーやグループにロールを割り当てる。ロールに割り当てられた IAM ポリシーに基づいてユーザーの AWS サービスへのアクセスを制御する。

[多要素認証]
オンプレミスまたは Amazon EC2 インスタンスで Active Directory を実行している場合は、AD Connector の多要素認証を有効にすることができる。
[引用元サイト]

Managed Microsoft AD

・高可用性構成のドメインコントローラーが、自動で複数のアベイラビリティーゾーンにまたがって作成される。
・モニタリング、復旧、データのレプリケーション、スナップショット、ソフトウェア更新などはすべてAWSが自動管理。
・オンプレミス Microsoft AD とAWS との間で信頼関係(ルート)を設定。AWS SSOと連携したシングルサインオンが可能。
・VPCと統合可能で、既存のAWSリソースとの連携がスムーズ。

DNS

※Domain Name System

IPアドレスとドメイン名（インターネットやメールなどで使われる住所）を紐づけて管理する。

※DNSの伝播とは… DNSレコードの変更がインターネット上のすべてのDNSサーバーに反映されるまでの時間を指す。たとえば、ドメインのIPアドレスを変更した場合、その情報が世界中のDNSサーバーに行き渡るまでに時間がかかる。

DNSの仕組み

①再起問い合わせ：クライアント から DNSキャッシュサーバ に送られる問い合わせ
②非再起問い合わせ：DNSサーバ から 権威サーバ に送る問い合わせ
③反復問い合わせ：非再帰問い合わせ を上位の権威サーバから下位の権威サーバまで繰り返して問い合わせを行う

権威DNS サーバ	【調査】DNSコンテンツサーバ。フルサービスリゾルバからの問い合わせに「ゾーンファイル」を参照して対応する。 [ゾーンファイルの記載内容] ●NSレコード 管理を委託しているDNSサーバの名前が書いてある行。どこに行けばドメインのIPアドレスを見つけられるかをインターネットに知らせる。 ※下記ドメイン名に関する情報を格納 ・ドメイン名 ・ターゲットIPアドレス ・TTL（Time To Live）……など [引用元サイト]
フルサービスリゾルバ	【受付/回答】DNSキャッシュサーバ。パソコンからの問い合わせを受け付ける。権威DNSサーバに問い合わせ、ドメインの名前解決をおこなうDNSサーバー。解決したドメインの情報を一時的に保存する、DNSキャッシュサーバーを兼ねているのが一般的。 ※DNSリゾルバ―とは リゾルバは自分の知っているDNSサーバへ問い合わせを行い、IPアドレスの割り出し（名前解決）を行う機能。ドメイン名の対応付けを確認してくれる。
再帰的なDNS リゾルバー	ドメインに変更がないか再度問い合わせること。情報をキャッシュに保持することで、毎回リゾルバが名前解決しなくてもドメインの情報を把握することが可能であり、呼び出し数を減らせる。 ※DNSフォワーダとは フルサービスリゾルバが問い合わせを受けたけど答えが分からないときに、その問い合わせを別のDNSサーバ（フルサービスリゾルバ）に丸投げ（中継）する機能。

その他機能

●ROA(Route Origin Authorization)

【経路の電子証明書】利用している RIR を介して作成。
経路広告に関する電子署名付き証明書。IPアドレスの組み合わせが正しい組み合わせであることを示す電子署名が施されたデータ。

・アドレス範囲、そのアドレス範囲を公開することを許可された自律システム番号 (ASN)、および有効期限が含まれる。

※RIR（Regional Internet Registry）
特定地域内のIPアドレスの割り当て業務を行うレジストリ。
インターネットリソース（IPv4、IPv6の両IPアドレスとAS番号）の配分と登録を管理する組織。

●Zone APEX

【サブドメインなし】example.jp や example.co.jp など サブドメイン(wwwなど)を含まないドメイン名のこと。
APEXは頂点を意味し、ゾーンの頂点として意味するサブドメインを含まないドメインを意味する。

Route53

・異常と判断した対象のIPアドレスをクエリ結果として返さない。すべて異常の場合はIPアドレスを返す仕様。

・S3と接続するときはリソースレコード名とバケット名が一致している必要がある。
※Route53はS3に直接ルーティングすることはできない。

・Route53のプライベートDNSレコードはオンプレミスの使用には拡張できず、発信元のリクエストがVPC内から行われた場合のみ機能する。

※ドメイン管理機能/DNS権威機能とは
WebコンソールやAPIから簡単にドメイン情報やゾーン情報を設定・管理。

●DNSルックアップ

DNS を用いて、ドメイン名やホスト名からIPアドレスを、あるいはその逆を調べること。
※通常はリゾルバと呼ばれるソフトウェアを用いる

[エンドポイントを利用した名前解決]

「プライベートDNSオプション」を有効にすることで実現可能

Evaluate Target Health

【ターゲットの正常性の評価】 一般に、ツリー内のすべてのエイリアスレコードに設定する。 [No (なし)]の場合：Route 53 はレコードのヘルスチェックが失敗した場合でも、エイリアスレコードが参照するレコードにトラフィックをルーティングし続ける。 [Yes (あり)]の場合：正常にヘルスチェックの結果を応答として返す。

Route53

●Route53 インバウンドリゾルバーエンドポイント

外部ドメイン（VPCの外部）から、Route53リゾルバ―を利用して、VPC内で作成されるインスタンスの名前解決ができる。

●Route53 リゾルバーアウトバウンドエンドポイント

外部ドメインに対する転送ルールを設定することで、VPCから外部ネットワークへDNSクエリを転送し、目的のホストと通信ができる。このエンドポイントにはVPC内のプライベートIPアドレスが使われ。同一リージョン内で複数のVPCが1つのエンドポイントを共有したり、複数作成したりすることも可能。

[ハイブリッドネットワークにおける統合 DNS 解決]
下記構成により、ハイブリッドクラウド環境においても 柔軟かつ効率的な名前解決戦略が可能になる。

①Route 53 Resolver 転送ルールを使用して、ドメイン名ベースで DNS クエリの送信先を制御。
②AWS から発信される DNS クエリは、転送ルールに基づいて適切なリゾルバーへルーティングされる。
⇒オンプレミス向けのクエリ：オンプレミスの DNS リゾルバーへ転送。
⇒AWS 内／インターネット向け：Route 53 Resolver が直接解決。

●Route53 ARC

※Route53 Application Recovery Controller
マルチAZやマルチリージョンを利用している環境において障害や不具合が発生した際の高速復旧に利用される。具体的には、障害や不具合の起きているAZやリージョンを使用しないよう分離して、サービスを継続するための仕組みである。

• 安全対策の必要性
  誤ってすべてのルーティングコントロールをオフにすると、フェイルオープン（意図しない切り替え）になる可能性がある。
• マスターオン／オフスイッチの導入
  一連のルーティングコントロールを一括で無効化する仕組みを設けることで、自動化による誤動作を防止。

[安全ルール]
ルールを組み合わせることで、意図しないフェイルオーバーや自動化による誤動作を防ぎ、より堅牢なトラフィック制御が可能になる。

ルール種別	主な用途	制御方法
アサーションルール	最低限の可用性を保証（常に1つはOn）	状態変更時に基準を満たす必要あり
ゲートルール	一括制御のスイッチとして機能（On/Off）	ゲートの状態に応じて変更を許可/拒否

ホストゾーン

ルート設定機能。ホストゾーンはレコードのコンテナであり、レコードにはドメイン名やサブドメインの特定のドメインのトラフィックをどのようにルーティングするか情報を保持。ホストゾーンの名前と対応するドメインの名前は同じ。

・ヘルスチェックで利用するプロトコルは、HTTP、HTTPS、TCP。
・Zone ApexレコードをELBに関連付けるには、Aレコードを使用。

パブリックホストゾーン	トラフィックをインターネットでどのようにルーティングするかを指定するレコードが含まれている。インターネット上に公開されたDNSドメインのレコードを管理するコンテナ。
プライベートホストゾーン	トラフィックをVPCでどのようにルーティングするかを指定するレコードが含まれている。 VPCに閉じたプライベートネットワーク内のDNSドメインのレコードを管理するコンテナ。

ルーティング

[ルーティング方法]

ホストベース	HTTPヘッダーのHostフィールドに基づいてクライアント要求をルーティングでき、同じロードバランサーから複数のドメインにルーティングする。
パスベース	HTTPヘッダーのURLパスに基づいてクライアント要求をルーティングできる。
HTTPヘッダーベース	標準またはカスタムのHTTPヘッダーの値に基づいてクライアント要求をルーティングできる。
HTTPメソッドベース	標準またはカスタムのHTTPメソッドに基づいてクライアントリクエストをルーティングできる。
クエリ文字列パラメータベース	クエリ文字列またはクエリパラメータに基づいてクライアントリクエストをルーティングできる。
送信元IPアドレスCIDRベース	リクエストの発信元の送信元IPアドレスCIDRに基づいてクライアントリクエストをルーティングできる。

[ルーティングポリシー]

シンプル	設定されたレコード情報に沿ってルーティングする、標準的な1対1のルーティング。
フェイルオーバー	ヘルスチェックを行い、無事なところにルーティングする（アクティブ / アクティブ , アクティブ / スタンバイ） ※本番システム障害時にSorryサーバのIPアドレスをセカンダリコードとして登録すると自動的に表示できる
位置情報	地理的に近いところへルーティングする。（待ち時間の削減には適さない）
地理的近接性	リソースの場所に基づいてトラフィックをルーティングし、必要に別の場所のリソースに移動する。
レイテンシーベース	トラフィックを最もレイテンシーが低いリソース（リージョンなど）へルーティングする（静的ウェブサイトのみ）
加重	複数のリソースへ指定した加重比率でルーティング分散する
マルチバリュー (複数値回答)	別々のレコードにIPアドレスを設定、IPアドレス単位でヘルスチェックを実施してルーティングする。1つのレコードを異なるIPアドレスを複数登録して、ランダムに返却されたIPアドレスに接続する。

レコードタイプ

※CNAMEの振る舞い：yyy.sample.com → AWSリソースのドメイン名 → IPアドレス
※ALIASの振る舞い：yyy.sample.com → IPアドレス

A	ドメイン名を（静的な）IPアドレスにマッピングする。（例：example.com -> 192.168.0.1） IPv4アドレスとドメイン名を1対1で紐づける。ウェブサーバーなどのリソースにトラフィックをルーティング。
AAAA	IPv6アドレスとドメイン名を1対1で紐づける。ウェブサーバーなどのリソースにトラフィックをルーティング。
CAA	間違った CA（認証機関） がドメインの証明書を発行することを防止できる。
CNAME	CNAMEレコードは正規ホスト名に対する別名を定義するレコード。特定のホスト名を別のドメイン名に転送する時などに利用する。 【例】ドメイン名：abc.comの場合【設定可能】 ホスト名：www VALUE：www.onamae.com　と入力⇒http://www.abc.com/にアクセスするとhttp://www.onamae.com/に転送される。
DS	委任署名者 (DS) レコードは、委任サブドメインゾーンのゾーンキーを参照します。DNSSEC 署名を設定するときに、信頼チェーンを確立するときに DS レコードを作成できます。
MX	メールサーバーの名前を指定。複数のメールサーバーがある場合は、優先順位を指定。
NAPTR	名前付け権限ポインタ (NAPTR) は、動的委任発見システム (DDDS) アプリケーションで、1 つの値を別の値に変換または置き換えるために使用されるレコードのタイプです。
NS	ホストゾーンのネームサーバーを識別
PTR	IP アドレスを対応するドメイン名にマッピング
SOA	ドメインおよび対応する Amazon Route 53 のホストゾーンに関する情報を提供。
SPF	メールの送信者の身元を確認するために SPF レコードが使用されていた(非推奨)
SRV	E メールや通信のサービスなどのサービスにアクセスするために使用。
TXT	ホスト名に関連付けるテキスト情報（文字列）を定義するレコード。送信+C8ドメイン認証の認証情報などを記述。 [参考]

●Aliasレコード

【高処理CNAME】
Route 53の内部で扱う特殊なタイプ。外から見たら単なるAレコードに見える。一言で言ってしまえば「各AWSプロダクトで利用するDNS名専用の、CNAMEレコード風の挙動を実現するレコード」。

・CNAME レコードと同様に、エイリアスレコードを使用すると、選択した AWS リソース (CloudFront ディストリビューションやAmazon S3 バケットなど) にトラフィックをルーティングできる。

※CNAMEはDNSクエリが2回発生するのに対して、1回で処理できる

[Route 53にALBのDNS名を設定]
・エイリアスターゲットの IP アドレスを伴う A レコード (IPv4 アドレス）
・エイリアスターゲットの IP アドレスをAAAA レコード (IPv6 アドレス)

エラー事例

[Route53 APIリクエスト]
AWSアカウントごとに1秒あたり5件を超えるリクエストを送信すると、Route53は「HTTP 400エラー(Bad request)」を返す。レスポンスヘッダーには、Throttllingの値をCode要素と、Rate exceededの値を持つMessage要素も含まれている。

[ChangeResourceRecordSets]
Route53で次のリクエストが到着するまでにリクエストを処理できない場合、同じホストゾーンの後続のリクエストが却下され、HTTP400エラー（Bad Request）が返される。

基礎知識

●プレフィックスリスト

AWSのVPCの機能で、IP アドレス範囲一式を指す。1つ以上のCIDRブロックを一元管理できる。セキュリティグループで複数プロトコルを利用して接続元を絞る場合、それぞれのリソースに同じルールを記載する手間があった。各リソースをリスト化のように扱うことで、重複したIPの設定を省略できるようになった。

• マネージド
  AWSが管理するIPアドレスレンジのリスト。最新のIPアドレスレンジを手動で更新する必要が無くなる。
  
• カスタマーマネージド
  その名の通り、ユーザー自身が管理することのできるIPアドレスレンジのリスト。これらのプレフィックスリストは AWS が管理しており、さまざまな AWS サービスで使用される IP アドレスを参照する手段を提供する。
  
  ・S3 や DynamoDB、その他数多くの AWS サービスに対応している。
  
  [セキュリティ面]
  AWS が提供する信頼のおける IP アドレス情報に依存することで、設定ミスや予期せぬ接続問題によるリスクを最小限に抑えることができる。
  [参考サイト]

●VIF（Virtual Interface）

仮想インターフェイス。AWSリソースにアクセスするための論理インターフェイス。　※DX：専用接続

パブリックVIF	オンプレ環境とAWS側をパブリックIPアドレスでつなぐ。接続対象はVPCの中ではなく、VPCの外のパブリックIPアドレスで提供される。
プライベートVIF	オンプレ環境とAWS側をプライベートIPアドレスでつなぐ。VPCの中にインターネットと通信する出入口のない部屋（プライベートサブネット）を作成する。
トランジットVIF	Direct Connect Gateway 経由でTransit Gateway につなぐときに利用する。

[一時ポート]

多くの Linux カーネル (Amazon Linux カーネルを含む)	ポート 32768～61000 を使用
Elastic Load Balancing からのリクエスト	ポート 1024-65535 を使用
Windows Server 2003 を介する Windows オペレーティングシステム	ポート 1025～5000 を使用
Windows Server 2008 以降のバージョン	ポート 49152～65535 を使用
NAT ゲートウェイ	ポート 1024～65535 を使用
AWS Lambda 関数	ポート 1024-65535 を使用

[参考公式サイト]

• VPN 接続
  高可用性のために同時に使用できる 2 つの VPN トンネルが含まれている。

• VPN トンネル
  お客様のネットワークと AWS の間でデータを送受信できる暗号化されたリンク。

[オンプレミスからのプライベートな接続]

通信元がオンプレミス環境の場合、ゲートウェイ型エンドポイントは利用できない。
専用線やVPNを経由し、インターフェイス型エンドポイントを選択することで実現できる。

●MACsec暗号化

（Media Access Control Security）
イーサネット通信を暗号化する技術で、レイヤ2（データリンク層）で動作する。つまり、LANやWANなどの物理的な接続部分でデータを守る仕組み。MACsecは、IPsecやTLSのような上位層の暗号化とは違い、物理的な接続そのものを保護するのが特徴。

[主な特徴]

・通信内容の暗号化：盗聴や改ざんを防止
・データの整合性チェック：改ざんされていないかを確認
・認証機能：正当なデバイス同士の通信かを検証
・リプレイ攻撃防止：古いパケットの再送信による攻撃を防ぐ

[MACsec接続関連付けキー]

MACsecで暗号化通信を行うには、通信相手と共通の鍵情報（CKN/CAK）を持っている必要がある。

• CKN（Connectivity Association Key Name）：鍵の識別名
• CAK（Connectivity Association Key）：実際の暗号化に使う鍵

このペアを「MACsec接続関連付けキー」と呼び、例えばAWS Direct Connectなどでは、ユーザーがこのCKN/CAKを設定して、MACsec通信を確立する。

[注意点]
AWSではこのキーをSecrets Managerで安全に管理することも可能です。一度接続に関連付けたキーは変更できないため、変更したい場合は一度解除して再設定が必要。

ルーティング機能

ルーティングテーブル	ルータに記録される経路情報。ルーティング処理を行う際に参照する。 ※デフォルトルートは１つ
サブネット (サブネットワーク)	ネットワークトラフィックは不要な ルーターを通過せずとも、短い距離を移動して宛先に到達させる効率的なネットワーク。 （デフォルトのサブネットマスクは常に/20になる） ・同じサブネット内のインスタンスは互いに通信ができる （セキュリティグループの設定による）

[サブネットの考え方]
以下、重複しない構成。
〇VPC：10.0.0.0/24：10.0.0.0～10.0.0.255

• パブリックサブネット：10.0.0.0/25：10.0.0.0～10.0.0.127
• プライベートサブネット：10.0.0.128/25～10.0.0.255
  
  ※CIDR 10.0.54.0/24（重複）、CIDR10.1.0.0/24（範囲外）

NAT機能

NATゲートウェイ、NATインスタンスともにプライベートIPをグローバルIPへ変換するという機能は同じ。アウトバウンドの受け入れのみ、対象とする。

●NATインスタンス

プライベートサブネットに配置されたサーバーから外部サイトへアクセスするときの踏み台サーバー。コストが高い(¥7,000)が、運用管理をユーザーが行わなくて良い。

・性能、冗長性を適切な調整やセキュリティアップデート等のメンテナンスが必要。
・EC2インスタンスであるため、一時停止が可能。
・NATインスタンスには送信元/送信先チェック(SrcDestCheck 属性)を無効にする必要がある。

●NATゲートウェイ

コストが安く(¥1,000～¥3,000)で、カスタマイズが自由にできる。
※IPv6トラフィックは処理できない

運用管理はユーザー側が行う。ただしAWSマネージドサービスであるためメンテナンス不要で、トラフィックに応じた十分な性能およびMultiAZ冗長性も確保されている。ただし、一時的な停止はできない。

・ネットワークアドレスを変換する
・セキュリティグループは不要

[接続タイプ]

[引用元サイト]

パブリック	プライベートサブネットのインスタンスは、パブリック NAT ゲートウェイを介してインターネットに接続できる。しかし、インターネットから未承諾のインバウンド接続を受信することはできない。パブリックサブネット内にパブリック NAT ゲートウェイを作成し、Elastic IP アドレスを NAT ゲートウェイに関連付ける必要がある。 ※お客様が所有するパブリックIPアドレスを（パブリック）NATゲートウェイに割り当てることにより、サードパーティはこの単一のIPアドレスをホワイトリストに登録できる。承諾済みのインバウンドとして、受信できる。
プライベート	プライベートサブネットのインスタンスはプライベート NAT ゲートウェイを介して他の VPC またはオンプレミスのネットワークに接続できる。この場合、NAT ゲートウェイからのトラフィックを Transit Gateway または仮想プライベートゲートウェイ経由でルーティングできる。Elastic IP アドレスをプライベート NAT ゲートウェイに関連付けることはできない。

Elastic Network Interface

アカウントで独自のネットワークインターフェイスを作成して設定し、VPC内のインスタンスにアタッチできる。

• VPC の IPv4 アドレス範囲からのプライマリプライベート IPv4 アドレス
• VPC の IPv4 アドレス範囲からの 1 つ以上のセカンダリプライベート IPv4 アドレス
• プライベート IPv4 アドレスごとに 1 つの Elastic IP アドレス (IPv4)
• 1 つのパブリック IPv4 アドレス
• 1 つ以上の IPv6 アドレス
• 1 つ以上のセキュリティグループ
• MAC アドレス
• 送信元/送信先チェックフラグ
• 説明

●トラフィックミラーリング

インスタンスに接続されているネットワークインターフェースからのインバウンドトラフィックとアウトバンドトラフィックをコピーする。

[EC2へのアタッチ]

ホットアタッチ	【実行中のアタッチ】 ENI をインスタンスの実行中にアタッチすること。
ウォームアタッチ	【停止中のアタッチ】 ENI をインスタンスの停止中にアタッチすること。
コールドアタッチ	【インスタンス起動中にアタッチ】 ENI をインスタンスの起動中にアタッチすること。

[IPについて]

IPフローティング	【トラフィック切り替え】 ENIのプロパティの一つ。Elastic IPアドレスをフローティングすることで即時に別のEC2インスタンスへとトラフィックを切り替えることができる。
Ipsec	【ネットワーク層暗号化】 OSI参照モデルにおける「ネットワーク層（第３層）」において暗号化を行っている。 そのため、上位層である「トランスポート層」や「アプリケーション層」が暗号化に対応なくても、下位層である「ネットワーク層」が暗号化しているため、より安全に通信を行える。
Elastic IP(EIP)	固定のグローバルアドレスを提供。EC2のデフォルト設定では、インスタンスが停止するとアタッチしたパブリックIPアドレスは解放(削除)してしまう。 ※NLBには直接IPを割り当てることができるが、ALBには実施できない 以下条件時、料金が発生する。 ・アドレスが実行中のインスタンスに関連付けられていないとき ・関連付けたインスタンスが停止しているとき ・ネットワークインターフェイスに関連付けられているとき ※インスタンスに直接付与するのではなく、ENIのプロパティのひとつである。

[インスタンスに複数のIPアドレス付与]
インスタンスに複数のENIを接続することで、複数のプライベート IPv4 および IPv6 アドレスを指定できる。

[参考公式サイト]

接続サービス

VPN(Client VPN)

[VPN エンドポイントの分割トンネル]

VPN接続を利用しているクライアントは、VPC内のリソースのトラフィックのみをVPNトンネルを通して送信し、それ以外のトラフィックはVPNトンネルを使用せずに直接送信する。
これにより、VPCあてのトラフィックのみがVPNトンネルを通過するというコンプライアンス要件を満たせる。

[参考公式サイト]

[VPNのプロトコルの種類]

OpenVPN 【オープンソース】	比較的新しく、利用ユーザーの多いオープンソースのプロトコル。セキュリティが強固で、速度が速い。ファイヤーウォールを通過できる。
IKEv2 【取り扱い：少】	Ciscoとマイクロソフトによって開発された安定性の高いVPNプロトコル。セキュリティが強固で、速度が速い。通信を自動的に再接続してくれる。ただし、サポートされている端末が少ない。
L2TP 【取り扱い：多】	通信速度が遅いが、IPSecと併用することで、PPTPより安全性を高めることができる。セキュリティが強固であり、対応端末が多い。しかし、ファイヤーウォールにブロックされることがある。
SSTP 【Windows向け】	Windows向けのVPNプロトコル。セキュリティが強固であるが、Windows向け。
PPTP 【古い】	多くの端末に対応しており、速度が速いが、プロトコルが古い。

VPCピアリング接続

★ピアアクセプタ（Peer Acceptor）… VPCピアリング接続において、リクエストを受け入れる側のVPCを指す。

[図解]

Private Link

※VPC間の接続は、同じリージョン内でないと利用できない

・PrivateLink を利用したインターフェース VPC エンドポイントは、AWS パートナーがホストするサービスと AWS Marketplace で利用可能なサポートするソリューションへの接続を可能にする。
※サービスを利用する側のVPCエンドポイントと、サービス提供側のVPCエンドポイントサービスの2つのセットでプライベート接続できる形式

・インターネットやパブリックIPアドレスを使用しないため、ブルートフォース攻撃やDDoS攻撃の恐怖にさらされない。

Private Link for Amazon S3

【オンプレとS3間の接続】
Virtual Private Cloud (VPC) でインターフェイス VPC エンドポイント (インターフェイスエンドポイント) をプロビジョニングできる。これにより作成されたENIにプライベートIPが割り当てられオンプレミス環境から S3 へ直接プライベート接続することができる。

これらのエンドポイントは、VPN および AWS Direct Connect 経由でオンプレミスにあるアプリケーション、または VPC ピアリング経由で別の AWS リージョン にあるアプリケーションから直接アクセスできる。

Site-to-Site VPN

※帯域幅：Direct Connect ＞ Site-to-Site VPN
※インターネットプロトコルセキュリティ (IPsec) VPN 接続をサポート

[フェイルオーバー用の冗長設定]

カスタマーゲートウェイデバイスが使用できなくなった場合に接続が失われるのを防ぐために、2 番目のカスタマーゲートウェイデバイスを追加して、VPC および仮想プライベートゲートウェイへの 2 番目の Site-to-Site VPN 接続を設定できる。

[参考サイト]

Direct Connect

▲注意点
物理的にAWS側と専用線接続の設定が必要であるため、AWSへの申請と設定などが必要不可欠となり、準備が間に合わない可能性がある。

[Direct Connect仮想インターフェイス]

接続を使用するには下記のインターフェースから選択が必要。

パブリック仮想インターフェイス	パブリック IP アドレスを使用してすべての AWS のパブリック(パブリックにアクセス可能な)サービスにアクセスできる。
プライベート仮想インターフェイス	プライベートIPアドレスを使ってVPCにアクセスするために使用。
トランジット仮想インターフェイス	Direct Connectゲートウェイに関連付けられた一つまたは複数のAmazon VPCトランジットゲートウェイにアクセスできる。

連携サービス

IPsecVPN	バックエンドAPIへの安全な接続を提供する。DirectConnect接続上にVPNを設定すると、転送中のデータが保護される。VPCにVGWを追加し、パブリック仮想インターフェイスを設定し、パブリック仮想インターフェースを介してデータセンターとVGWの間にIPSecトンネルを作成する。 [参考]
MACsec	10 Gbps , 100 Gbps , 400 Gbps の専用 Direct Connect 接続のみでサポートされている。 ※MACsec イーサネットの通信を暗号化する技術のこと。IEEE 標準の 1 つ。データの機密性、データの整合性、およびデータオリジンの信頼性を定義。

ゲートウェイ（Gateway）

Internet Gateway

Customer Gateway

●カスタマーゲートウェイデバイス

【カスタマー側のエンドポイント】
オンプレミスネットワーク (Site-to-Site VPN 接続のユーザー側) で所有または管理している物理アプライアンスまたはソフトウェアアプライアンス。ユーザーまたはネットワーク管理者は、Site-to-Site VPN 接続で動作するようにデバイスを設定する必要がある。

Virtual Private Gateway

※VPC上で仮想プライベートゲートウェイはひとつしか利用できない

Egress-OnlyインターネットGateway

インターネットからのトラフィックを防ぎつつ、IPv6の発信トラフィックをサポートする。
(アウトバウンドのみ)水平的に拡張でき、冗長で高度な高可用性を持つVPCコンポーネントで、IPv6経由でVPCからインターネット接続出来る。

Transit Gateway

Transit Gateway を他のアカウントと共有することで、複数のアカウントが Transit Gateway を利用することができる。

機能性

Transit Gateway ルートテーブル	VPCアタッチメントごとに作成することで、各VPCのトラフィックを効率的に制御できる。
(ルート)プロパゲート機能	特定の接続（VPC、VPN、Direct Connect）のルート情報をTransit Gatewayのルートテーブルに伝播（プロパゲート）する設定。本設定を有効にすることで、対象ネットワークのルート情報が自動的にルートテーブルに反映させることができる。
Transit Gateway Resolver	VPC間のルーティングを効率化するためのDNSリゾルバのことです。これにより、異なるVPCに存在するリソース間で名前解決を可能にし、ネットワーク構成の複雑さを軽減する。

連携サービス

Route53	Route53 プライベートホストゾーンを複数のVPCおよびAWSアカウントで解決する場合、ホストゾーンをアカウント間で共有し、それを必要な各VPCに関連付けることで、DNSの一元管理が可能になる。

Direct Connect Gateway

Storage Gateway

タイプ

●（S3）ファイルゲートウェイ

ネットワークファイルシステムなどのファイルプロトコルを使用して、既存のファイルをS3でオブジェクトとして保存と取得を実行できる。書き込まれたオブジェクトにS3で直接アクセスできる。

・オンプレミスサーバーやEC2上で、S3バケットへのファイルアクセスをローカルのファイルシステム操作として実行できる。
・S3とのデータ転送を最適化し、ローカルキャッシュを利用するために、アプリケーションに対して高速なデータアクセスを提供。

●ボリュームゲートウェイ

オンプレミス内のデータをスナップショットしたものを保存する。iSCSI プロトコルを使用してアプリケーションにブロックストレージを提供する。AWSでiSCSI ボリュームにアクセスする場合は、EBSボリュームの作成に使用できるEBSスナップショットを作成する。

キャッシュ型	プライマリデータを S3 に保存。プライマリデータはS3に書き込まれ、頻繁にアクセスするデータはキャッシュでローカルに保持され、低レイテンシーアクセスを実現する。 [スナップショット切り替え] スナップショットから新しいボリュームを作成する時、ゲートウェイは S3 にあるスナップショットデータを保持する。そこでスナップショットデータが新しいボリュームのプライマリデータに切り替わる。
保管型	プライマリデータはローカルに保管される。保管されたデータセットは低レイテンシーアクセスできる。データセット全体が低レイテンシーのアクセスのために、使用可能となり、非同期にAWSにバックアップする。 [スナップショット切り替え] スナップショットから新しいボリュームを作成する時、ゲートウェイはスナップショット内に含まれているデータをローカルハードウェアにダウンロードする。 そこで、データが新しいボリュームのプライマリデータになる。

●テープゲートウェイ

物理のテープライブラリの代替として、仮想テープライブラリを使用。仮想テープのデータはS3内に保存される。または、S3 Glacier へのアーカイブが可能。テープベースのアーカイブをクラウドに移行するために設計されている。
そのため、頻繁な読み書きなどの複雑な処理には適していない。

暗号化

SSL / TLSを使用してゲートウェイアプライアンスとAWSストレージ間で転送されるデータを暗号化。デフォルトで S3管理暗号化キー（SSE-S3）を使用して、S3に格納されているデータをサーバー側で暗号化する。

CHAP認証	不正なクライアントのなりすまし防止。
データ暗号化	KMSを使用して暗号化可能。
通信の暗号化	HTTPSの暗号化

[参考公式サイト]

API Gateway

[クライアント→リクエスト受信⇒バックエンド⇒クライアント]に返す, プロキシのような働きする。
※スケールも自動化

・ソフトウェアやアプリケーションなどの一部を外部に向けて公開することで、第三者が開発したソフトウェアと機能を共有できる
・AWS SDK、CLIは頻繁にローテーションされる一時的なセキュリティ認証情報は自動的に生成できる。
・料金は、受け取ったAPI呼び出し、送出したデータの量の分
・HTMLに直接書き込んでコードを呼び出すことも可能

●Lambda オーソライザー

Lambda関数を使用してAPIへのアクセスを制御できる。クライアントがAPIのメソッドの1つにリクエストを送信すると、API Gateway は Lambda オーソライザーを呼び出す。

・発信者IDを入力として受け取り、IAMポリシーを出力として返す。
※OAuth や SAML などのベアラートークン認可戦略を使用する、または発信者 ID を判断するためにリクエストパラメータを使用するカスタム認証スキームをする場合に有効。

トークンベース （TOKENオーソライザー）	JSON ウェブトークン(JWT)やOAuth トークンなどのベアラートークンで発信者IDを受け取る。
リクエストパラメータベース （REQUESTオーソライザー）	ヘッダー、クエリ文字列パラメータ、stageVariables、および$context 変数の組み合わせで発信者IDを受け取る。WebSocket API では、REQUESTオーソライザーのみサポートする。

機能性

機能	説明
スロットリング	API またはメソッドレベルで秒間リクエスト数などの制限を設ける。リクエストが多すぎるために バックエンドサービスが処理しきれなくなることを防ぐ。
クォータ	一定期間（例：1日、1週間）内の最大リクエスト数を設定。個別のAPIメソッドを使用料プランの設定に基づいてAPIキー認証を要求するように設定できる。
ステージの指定	使用量プランごとに対象となる API ステージを定義可能
APIキーの関連付け	クライアントを識別してアクセス制御を適用

使用量プラン	API キーと使用量プランを組み合わせることで、特定の顧客やアプリケーションに対してアクセス可能な API ステージやメソッドを限定し、識別・制限することができる。これにより、他社アプリに対しても適切なアクセス制御（スロットリングやクォータ）が可能となる仕組み。
API キャッシュ	エンドポイントのレスポンスがキャッシュされるようにする。エンドポイントへの呼び出し回数が削減できる。秒単位で指定した有効期限(TTL)が切れるまで有効。※TTL値の最大値は3600秒

API Gateway の処理

[リクエスト]

メソッドリクエスト 【検証】	「受付可能なクエリパラメータ」「必須のパラメータ」「認可の有無」「API Keyの有無」などと実際に受付けるリクエストを絞り込む、いわばリクエストの受付。必須のパラメータを含んでいるかを確認することで、バックエンドのリソースを無駄に呼び出さずレスポンスを返すことが可能になる。 ※誤ったリクエストでバックエンドを無駄に起動すると、レスポンスに遅れが生じる
統合リクエスト 【HTTPリクエストをカプセル化】	API Gateway がバックエンドに送る HTTP リクエスト。バックエンドが受け取ったHTTPリクエストをカプセル化。どのバックエンドにどのようにデータを渡すかを決定する。 [データの整形] バックエンドにリクエストを投げる前にデータの整形が必要な場合、XML形式で受け取ったリクエストをJSON形式にしたいなど、バックエンドでは不要なフィールドを削除したいといったケースに対応できるマッピングテンプレートがある。 ※バックエンド：Lambda関数やAWSサービスなど実際にリクエストを処理するコンポーネント

[レスポンス]

統合レスポンス	バックエンドの出力をカプセル化。バックエンドから返ってきたレスポンスに関する設定を行う。例えばHTTPステータスコードをマッピングしたり, レスポンスの内容の変換を行ったりする。
メソッドレスポンス	【受信の定義】 クライアントから受け取るリクエストに対するAPI Gatewayの最終的なレスポンスを定義。 ステータスコードやHTTPヘッダなどといった部分。

エンドポイント

●リージョン API エンドポイント

同じリージョンのクライアントを対象とする。
下記の場合、リージョン別 API は接続のオーバーヘッドを減らすことが可能。
・EC2 インスタンスで実行されているクライアントが同じリージョンの API を呼び出す場合
・ API が要求の高い少数のクライアントへのサービスを目的としている場合

• カスタムドメイン
  複数のリージョンでリージョン別 API をデプロイする場合、すべてのリージョンで同じカスタムドメイン名を使用できる。
  
  ・ユーザーが使用するカスタムドメイン名は API がデプロイされているリージョンに固有となる。
  ・リージョン別 API エンドポイントは、すべてのヘッダー名をそのまま渡す。
  ・カスタムドメインをRoute 53 と組み合わせて使用すると、レイテンシーベースのルーティングなどのタスクを実行できる。

●エッジ最適化 API エンドポイント

地理的に分散されたクライアントに最適。API リクエストは、最寄りの CloudFront POP (Point Of Presence) にルーティングされる。エッジ最適化された API に使用するカスタムドメイン名はすべてのリージョンに適用される。
※これは、API Gateway REST API のデフォルトのエンドポイントタイプ。

[CloudFrontと比較]
リクエストをオリジンに転送前に、Cookie 名の自然な順序で HTTP Cookie を並べ替える。

[API gatewayのキャッシュ有効]
指定された存続時間（TTL）期間（秒単位）にエンドポイントからの応答をキャッシュする。エンドポイントにリクエストを送信する代わりに、キャッシュからエンドポイントレスポンスを検索することでリクエストに応答する。
※存続可能時間（TTL）を設定することで、キャッシュの制御を実施。

⇒「エンドポイントへの呼び出しの数」、「API へのリクエストのレイテンシー」を減らせる。
※APIキャッシングのデフォルトのTTL値は300秒。最大TTL値は3600秒。
※TTL = 0は、キャッシュが無効になっていることを意味する

メトリクス

[Integration Latency]メトリクス	バックエンドの応答性を測定。
[Latency]メトリクス	API コールの全体的な応答性を測定。
[Cache Hit Count / Cache Miss Count]メトリクス	目的のパフォーマンスの実現に向けてキャッシュ容量を最適化する。

エラー

502	Lambdaプロキシ統合バックエンドから互換性のない出力が返答されている。
504	エンドポイントのリクエストのタイムアウト。

ペイロードサイズの上限

APIタイプ	最大ペイロードサイズ	備考
REST API	10MB（10,485,760バイト）	リクエスト・レスポンスともに対象。超えると413 Request Too Largeエラー
HTTP API	10MB	REST APIと同様の制限が適用されます
WebSocket API	128KB	メッセージ単位の制限。32KBを超えるとフレーム分割が必要

プライベートAPI

API Gateway を使って構築される、VPC（Virtual Private Cloud）内からのみアクセス可能な REST API 。インターネット経由ではアクセスできず、AWS 内部ネットワーク（PrivateLink）を通じてのみ呼び出せるのが特徴。

[概要]

• エンドポイントタイプに「Private」を指定して作成
• VPC エンドポイント（Interface型） を経由してアクセス
• AWS PrivateLink によってセキュアな通信を実現
• パブリックインターネットを経由しないため、セキュリティが高い

[構成要素]

コンポーネント	説明
API Gateway（Private）	プライベートAPIのホスト
VPC エンドポイント	API Gateway へのプライベートな接続口
リソースポリシー	アクセス元の VPC や VPC エンドポイントを制限
Route 53（任意）	プライベートDNSでの名前解決に使用可能

S3 File Gateway

特徴

プロトコル	標準的なファイルプロトコル（NFS や SMB）を使って、S3 にオブジェクトを保存・取得できる。
マウントポイントの提供	S3 オブジェクトを、ローカルファイルのようにアクセスできる
VM環境に対応	オンプレミスに設置される仮想マシン（VM）として実行される。 ※VMware ESXi、Microsoft Hyper-V、Linux KVM に対応。

APP Sync

• GraphQL API の開発を容易にする完全マネージド型サービス。
• キャッシュやサブスクリプションを活用してパフォーマンスを向上。
• クライアント側のデータストアによるオフライン同期を実現。
• API 実行エンジンは自動的にスケールアップ／ダウン。
• 数百万のクライアントに WebSockets を通じてリアルタイムでデータをプッシュ。
• モバイル／ウェブアプリで、オフライン時のローカルアクセスや競合解決も可能。

★GraphQLとは… AWS AppSyncで開発できるGraphQLとは、API用のクエリ言語とスキーマ言語のこと。

AWSには、AppSyncと似たサービスでAPI Gatewayがある。どちらも、APIを開発できるフルマネージドサービスだが、AWS AppSyncはGraphQLの開発ができるのに対し、Amazon API GatewayはRESTful APIとWEBSOCKET APIを作成できる点で異なる。

[※引用サイト]

[サブスクリプション機能]
リアルタイムに同期処理を実現できる。
[※引用公式サイト]

帯域強化サービス

拡張ネットワーキング

シングルルート I/O 仮想化 (SR-IOV) を使用して、サポートされるインスタンスタイプにおける高性能ネットワーキング機能が提供される。(SR-IOVは、従来のものと比較し、I/O パフォーマンスが高く、CPU 利用率が低いデバイス仮想化の手法）

・高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス（低レイテンシー）

・拡張ネットワーキングは追加料金なしで使用できる。

Global Accelerator

・S3のデータのアップロードには利用できない。

[仕組み]
ユーザ変更は不要で、バックエンドでALB、NLB、EC2、Elastic IPなどのアプリケーションに対して固定エントリポイントとして機能する2つのグローバルな静的IPアドレスを提供することでグローバルアプリケーションの管理を容易にする。

・パフォーマンスに基づいて最適なエンドポイントにユーザートラフィックを自動的にルーティングし、アプリケーションの状態、ユーザーの位置、設定するポリシーの変更に瞬時に反応する。

・障害が発生した際、アプリケーションの正常なインスタンスが存在するリージョンに自動的にリクエストをルーティングする。

・速度比較ツールを使用することで、お客様のロケーションからどのようなパフォーマンスの利点があるかをテストできる。

機能性

●エンドポイント

NLB / ALB / EC2 / EIP を指定できる。
エンドポイントグループは1つ以上のエンドポイントが含まれるエンドポイントの集合体を指す。
各リスナーに対してそれぞれ１つ以上のエンドポイントグループを指定する。

• リスナー
  エンドポイントの正常性やトラフィックダイヤルによって設定されたトラフィック量に基づいてそれぞれのエンドポイント（グループ）にトラフィックをルーティングする。リージョンが異なるエンドポイントグループをひとつのリスナーに関連付けることができる。

●アクセラレータ

• 標準アクセラレータ
  世界中のユーザのインターネットアプリケーションの可用性を向上。AWSグローバルネットワーク経由でクライアントに最も近いリージョンのエンドポイントにトラフィックを転送する。

• カスタムルーティングアクセラレータ
  アプリケーションまたはサービスへのトラフィックのルーティングは細かく制御できる
  ※NLBをエンドポイントしてサポートしていない

Wavelength

※5G や 4G ネットワークを使って AWS リージョンにアクセスすると、従来使用されていたネットワークを経由しなくなり、早い回線を利用できるようになる

基礎知識

●可用性

システムが継続して稼働できる能力のこと。
サービスの提供が不可能になる状態に陥ることが少なく、安定して利用できる性質。

目標復旧時間（RTO）	いつまでに事業を復旧するかという目標時間を表す指標。
目標復旧時点（RPO）	データ損失の最大許容量。24時間であれば24時間分のデータの損失は許容される。

• スケールイン：撤去すること
• スケールアウト：増設すること

●TTL（Time TO Live）機能

あるデータが破棄されるまで時間や、処理の繰り返し回数の上限。DynamoDB コンソールまたは AWS CLI、存続期間を有効にできる。(キャパシティユニットを消費しない)

●SSLネゴシエーション

SSL通信の工程を意味する。

ELB

●リスナ

[接続チェック]
設定したプロトコルとポートを使用して接続リクエストをチェックするプロセス。

• リスナをセキュリティグループに設定できない。
• 優先順位により、登録済みのターゲットにリクエストをルーティングする方法が決まる。

※リスナによって想定されていないプロトコルおよびポートを使用した場合、「接続確立時エラー」発生する可能性がある。

機能性

ヘルスチェック	高可用性のある通信トラフィックの負荷分散。 ヘルスチェックを30秒ごとに行う。
モニタリング	【アクセスログ有効】 ロードバランサーに送信されるリクエストについて、詳細情報を収集するアクセスログを S3 に格納。 トラフィックパターンの分析や、問題のトラブルシューティングを行うことができる。 【ログ内の情報】 ・リクエストの受信時刻 ・クライアントの IP アドレス ・レイテンシー ・リクエストパス ・サーバーレスポンス……など
スケーリング	負荷に応じて、自動的にクラウドサーバーの台数を増減させる機能。 ただし、緩やかにスケーリングするため、突発的な増加には対応できない。
クロスゾーン 負荷分散	【AZ跨ぎ分散】 複数のAZを跨いで、起動するインスタンスの台数に偏りがある場合でも、均等にトラフィックを分散して振り分ける機能。
スティッキー セッション	【セッション記憶】※NLB未対応！ ユーザーのセッション情報をELBが把握できるようになり、セッション中に同じユーザから来たリクエストを全て、同じEC2インスタンスに送信する機能。ELBがサーバにリクエストを振り分ける際、Cookieを確認して特定のクライアントからのリクエストを特定のサーバに連続的に紐付ける。セッションアフィニティとも呼ぶ。
Connection Draining	【異常なインスタンスを判別】 既存の接続を開いたまま、登録解除または異常なインスタンスへのCLBのリクエスト送信を停止する。 （タイムアウト値：１時間）
暖気申請	(Pre-Warming)【事前にスケール】 急激なアクセス増が予想される場合、暖気申請を行い事前にELBをスケールする。ELBは負荷に合わせてスケールする機能があるが、ある程度の時間がかかりリクエストが瞬間的に増えたときはスケールが間に合わず、HTTP 503を返す。

メトリクス

レイテンシー	ロードバランサーが配下のインスタンスへリクエストを送信〜対象インスタンスがレスポンスヘッダを送信し始めた合計経過時間(秒)。アベレージ、Maxが有用。
RequestCount	指定された間隔に完了したリクエストの数。合計が有用。
Healthy Host Count	ロードバランサー配下の正常なインスタンス数。統計は平均とMaxが有用。
Un Healthy Host Count	ロードバランサー配下の異常なインスタンス数。統計は平均とMinが有用。
HTTPCode_Backend_2XX (3XX,4XX,5XX)	ELB配下のインスタンスからのレスポンスのステータスコードの数。ロードバランサーのレスポンスのステータスコードは含まれない。なお、統計はSumで見ないと1固定になってしまうので注意。 ➡ELB配下のインスタンスでリクエストが裁けなくなってる
HTTPCode_ELB_5XX	ロードバランサーのレスポンスのステータスコード5XXの数。ELB配下のインスタンスからのレスポンスのステータスコードの数は含まれない。ELBに配下のインスタンスで正常なインスタンスがひとつもない場合や、リクエストレートがインスタンスやロードバランサーの容量を超える場合に発生。なお、統計はSumで見ないと1固定になるため注意。➡ELB配下のインスタンスに負荷がかかりると危険。 とうとうインスタンスのヘルスチェックOKのインスタンスが0になったのでインスタンスにリクエストすら送れなくなり、ELBがユーザーにインスタンス死んでるから無理と5XXエラー返しだす。

ヘッダー

●Proxy Protocolヘッダー

【接続元指定】
接続元のクライアントのIP アドレスが必要な場合は、Proxy Protocol を有効にする。Proxy Protocol ヘッダーからクライアント IP アドレスを取得できる。

• Proxy Protocol
  ELBで事前に設定していたプロトコル以外の接続に対して、接続元のIPアドレスやポート番号が確認できる。
  Proxy ProtocolはAWSによってサポートされている。
  （HTTPで設定していたが、他のプロトコルで接続があったなど）

エラー

[HTTP503エラー]

一時的にサーバーにアクセスできない状態。原因の一つとして、サーバーへのアクセス過多があげられる。
対応として、インスタンスを停止し再起動すると、認識までに時間がかかり、瞬間的なリクエストの増加に対応が間に合わないことがある。そのため、暖気申請を実施するのが良い。

[ロードバランサーの種類]

機能	Application Load Balancer	Network Load Balancer	Gateway Load Balancer	Classic Load Balancer
ロードバランサーの種類	レイヤー 7	レイヤー 4	レイヤー 3 Gateway + レイヤー 4	レイヤー 4/7
ターゲットの種類	IP、インスタンス、Lambda	IP、インスタンス、ALB	IP、インスタンス	IP、インスタンス
フロー/プロキシの動作終了	有	有	いいえ	有
プロトコルリスナー	HTTP、HTTPS、gRPC	TCP、UDP、TLS	IP	TCP、SSL/TLS、HTTP、HTTPS
到達方法	VIP	VIP	ルートテーブルのエントリ	VIP

[引用元サイト]

CLB

SpilloverCount	【拒否リクエスト数】 サージキューがいっぱいなため、拒否されたリクエストの総数。
SurgeQueueLength	【リクエスト合計数】 正常なインスタンスへのルーティングを保留中のリクエスト（HTTPリスナー）または接続（TCPリスナー）の合計数。キューの最大サイズは1,024。追加のリクエストまたは接続は、キューがいっぱいになると拒否される。

[参考：公式サイト]

ALB

・CLBと比較して費用対効果が高い
・WebSocket プロトコルに対応している
・動的ポートマッピングを支援
・CNAME レコードは対応していない
・静的IPアドレスを割り当てることはできない
・SQSキューをターゲットに設定できない

ALBアクセスログ	下記、詳細を含むアプリケーションアクセス情報を提供する。 ・クライアントIPアドレス ・接続タイプ ・ユーザーエージェント……など ※出力先は S3 固定
URLベースのルーティング	URLパスに基づいてリクエストを転送するルールを持つリスナーを作成できる。 マイクロサービスを実行している場合、複数のバックエンドサービスにトラフィックをルーティングできる。 [静的IPアドレスが必要な場合] ALBをNLBの背後に登録すること。 [参考公式サイト]

ヘルスチェック

[参考公式サイト]

●HealthCheckIntervalSeconds

個々のターゲットのヘルスチェックの概算間隔 (秒単位)。範囲は 5 ～ 300 秒。
ターゲットタイプが instance または ip の場合のデフォルトは 30 秒で、ターゲットタイプが lambda の場合のデフォルトは 35 秒。

●HealthyThresholdCount

非正常なインスタンスが正常であると見なすまでに必要なヘルスチェックの連続成功回数。
範囲は 2 ～ 10 。デフォルトは 5 。

NLB

・静的IPアドレスを持たせることができる
・ホワイトリストに静的IPアドレスを登録して、アクセス制限できる。
・「受け取ったプロトコルをそのまま」バランシングするため、「HTTP/HTTPS プロトコル」は非対応。
・「Lambdaターゲットタイプ」は非対応である。
・「スティッキーセッション」や「加重ラウンドロビン」は対応できない

[NLBの暗号化]

NLBで終端される TLS (Transport Layer Security) 接続を利用することで、ロードバランサーと SSL あるいは TLS セッションを開始したクライアント間のトラフィックを暗号化できる。

Gateway Load Balancer

・Gateway Load Balancer は仮想アプライアンスと同じ VPCに配置される
・透過的なネットワークゲートウェイとして機能し、アプリケーションの構成を変更せずにセキュリティ機能を追加できる。

●GWLBエンドポイント

「サービスプロバイダーVPC内の仮想アプライアンス」と「サービスコンシューマVPC内のアプリケーションサーバ間」のプライベート接続を提供するVPCe。2つのVPCをGWLBとGWLBエンドポイントでつなぎ、VPCを超えてトラフィックを安全に交換する。

• GWLBは仮想アプライアンスと同じVPCにデプロイする。
• 仮想アプライアンスは、GWLBターゲットグループに登録する。

[例：通信の流れ]

①アプリケーションサーバーへの外部からの通信（受信）は：
インターネットゲートウェイ ➜ GWLB エンドポイント ➜ 宛先サブネット

②サーバーから外部への通信（送信）は：
宛先サブネット ➜ GWLB エンドポイント ➜ インターネット

Auto Scalling

・グループのサイズは手動でいつでも変更が可能
・グループポリシーで終了させるインスタンスの調整ができる
・メモリ利用率をトリガーとした設定がデフォルトで設定できないようになっている

スケーリング機能

スケーリングは異常なインスタンスを修了させた後、新しいインスタンスを追加する。
※スケジューリングされたアクションが重複する場合、エラーが通知される

スケールイン保護	スケールイン時にインスタンスの停止を伴わない。
スケーリングプラン	【タイミング指定】 いつどのような条件でAuto Scalingを実行するか指定する。
クールダウン	【待機期間】 スケーリングを連続して行わないようにする待機時間を指定する。アプリケーションが必要以上の起動や終了を実施しないようにすることができる。インスタンスがスケールアウトすると一定のクールダウンに入る。なおユーザーアクション中はスケールアウトは中止される。 ・デフォルトではAuto Scalingグループ全体へ適用している。 ・クールダウンを用いて、Cloud Watchとの重複起動を避けられる ・スポットインスタンスの入札が決定すると、Auto Scallingグループはクールダウンが有効になる
ウォームプール	起動時間が長いインスタンスも事前に起動しておくことで、急なトラフィック増加に対応できる。Auto Scaling グループに接続された初期化済みの EC2 インスタンスのプール。EC2インスタンスが起動する際のデータのディスクへの書き込みや起動時間の長さによって発生するアプリケーションのレイテンシー（遅延）を削減する。（レイテンシーの問題に有効）インスタンスは、ウォームプールから離れたときに、グループの希望する容量にカウントされる。これはウォームスタートとされる。

[スケーリンググループの削除方法]

• AutoScalingグループの最小サイズと希望する容量を０にする。
• CLIから「delete – auto – scaling – group」コマンドを実行。

[SQSに基づくスケーリング]

設定は 3 つの主要な部分で構成される。

• SQS キューからのメッセージを処理するために EC2 インスタンスを管理する Auto Scaling グループ。
• CloudWatch に送信するカスタムメトリクス。Auto Scaling グループの EC2 インスタンスごとにキュー内のメッセージの数を測定する。
• ターゲット追跡ポリシー。カスタムメトリクスと一連のターゲット値に基づいて Auto Scaling グループをスケールするように設定。CloudWatch アラームでスケーリングポリシーを呼び出す。

インスタンスの種類

ステートレスなインスタンス 【手動連携】	ユーザーが途中まで操作した段階でスケールインしサーバー数が減った場合でも、常にユーザーが全データを送信する。これにより、スケールイン・スケールアウトが発生してもスムーズなシステム運用が可能。
ステートフルなインスタンス 【自動連携】	ユーザーがどこまでの操作を行ったかをシステムが保持する。スケールアウトやスケールインでサーバーが増減した場合でも続きの処理を別のサーバーでもできるようにする。そうしないと、新しく起動されたインスタンスにリクエストしたときにデータが存在しないエラーが発生することがある。
属性ベースのインスタンス	属性ベースのインスタンスタイプの選択では、特定のインスタンスタイプのリストの代わりに、以下のようなインスタンスに必要な属性のリストが提供される。 ・vCPU 数 ・メモリ ・ローカルストレージ ・バースト可能なパフォーマンス

[インスタンスの状態]
「Stopped（停止中）」「Running（実行中）」「Hibernated（休止中）」のいずれかの状態で保持される。コストを最小限に抑えるには、インスタンスを停止状態で保持するのが効果的。この場合、使用したボリュームとElastic IPアドレスに対してのみ料金が発生する。

起動設定

【設定テンプレート】※既存の起動設定は変更できない
Auto Scaling グループがインスタンスを起動するために使用するインスタンス設定テンプレート。

• AWS::AutoScaling::LaunchConfiguration
  起動設定の指定。AutoScalingグループがインスタンスを設定するために使用できるEC2 AutoScaling起動設定を指定する。

●起動テンプレート

【複数起動】起動設定の代わりに起動テンプレートを定義すると、複数のバージョンの起動テンプレートを使用できる。AMI の ID、インスタンスタイプ、キーペア、セキュリティグループ、その他 EC2 インスタンスを起動するために使用するパラメータが含まれている。
※インスタンス設定情報を指定する起動設定と似ている。

機能性

ライフサイクルフック	インスタンスの起動・停止を一時的に待機させ、指定のアクションを実行。異常なインスタンスの分析などのシチュエーションなどで有効。
ヘルスチェック	[EC2のヘルスチェック]：pingを定期的にインスタンスに送る。 ・正常：InService　・不健全：OutOfService [ELBのヘルスチェック] ・正常：running ・異常：stopping、stopped、terminating、terminatedの場合、またはシステムステータスがimpairedである場合。 [カスタムチェック] デフォルトのヘルスチェックは、EC2のステータスチェックのみ。ELBのヘルスチェックを設定すると、EC2のステータスチェックとELBのヘルスチェックいずれかに合格しない場合に異常となる。（つまり両方合格して、正常となる）
グループ別集計機能	【EC2統計機能】 ・Auto Scaling グループ内で EC2 の統計を集計することができる。 ・CloudWatch のメトリクス数式を使用して、複数リージョンのメトリクスを集計・変換できる。 ・クロスアカウントダッシュボードを使用すると、複数の異なるアカウントのメトリクスに対してメトリック数式を実行できる。

プロセス

[参考公式サイト]

Launch 【追加】	グループがスケールアウトするとき、またはEC2 Auto Scaling がその他の理由 (インスタンスをウォームプールに追加する場合など) でインスタンスの起動を選択するときに、インスタンスを Auto Scaling グループに追加する。
Terminate 【削除】	グループがスケールインするとき、または EC2 Auto Scaling がその他の理由 (最大有効期間を超過した、もしくはヘルスチェックに合格しなかったためにインスタンスが終了される場合など) でインスタンスの終了を選択する場合に、インスタンスを Auto Scaling グループから削除する。
AddToLoadBalancer	インスタンスが起動されたときに、アタッチされたロードバランサーターゲットグループまたは Classic Load Balancer にインスタンスを追加する。
AlarmNotification	動的スケーリングポリシーに関連付けられているアラームからの CloudWatch通知を受け入れる。

ポリシー

[スケーリングポリシー]

手動スケーリング	Auto Scalingグループのサイズの希望する容量を手動で変更しスケーリングする。
動的スケーリング	トラフィックの変化に応じてスケーリングする。
簡易	～％の閾値を超過次第
ステップ	warning , errorと段階を踏ませる
ターゲット追跡	設定値を自動的に維持する仕組み。容量が増加すると減少し、容量が減少すると増加するなど、比例的なスケーリングを実現可能。
スケジュール	特定の時間に容量を増減するスケジュールアクションを作成することで予測可能な負荷の変化に合わせてアプリケーションを事前対応的にスケーリングする。
予測	通常のトラフィックの日次や週次のパターンに基づいて Auto Scaling グループ内の EC2 インスタンス数を事前に増加させる。

[終了ポリシー]

・Oldest Instance
・Newest Instance
・Oldest Launch Configuration
・Coldest To Next Instance Hour
・Default
・Oldest Launch Template
・Allocation Strategy

・Termination Policy

スケールイン時に終了させるインスタンスの順番を定義する。デフォルトは古いインスタンスから実行。

メトリクス

• Group TotalInstance
  AutoScalingグループに含まれるインスタンス（稼働中、保留中、終了処理中）の合計数を特定。
• GroupInServiceInstances
  Auto Scaling グループの一部として実行するインスタンスの数。
  このメトリクスには保留中もしくは終了処理中のインスタンスは含まれない。

[高可用性：インスタンス最小数1、インスタンスの最大数1]

特性	説明
ヘルスチェックによる自動置き換え	EC2 インスタンスが異常と判定された場合、Auto Scaling グループはそのインスタンスを終了し、新しいインスタンスを自動で起動します。
希望キャパシティの維持	最小数・最大数が1でも、Auto Scaling グループは「常に1台稼働している状態」を維持しようとします。
Launch Template による迅速な復旧	起動テンプレートに基づいて、同一構成のインスタンスを即座に再起動できるため、復旧時間（RTO）を短縮できます。
CloudWatch アラームとの連携	異常検知を CloudWatch アラームで補強すれば、より早期に障害を検知・対応できます。

Application Auto Scaling

EC2 Auto Scaling 以外の個々の AWS サービスに対してスケーラブルなリソースを自動的にスケーリングするソリューションを必要とするデベロッパーやシステム管理者向けのウェブサービス。

●Service Auto Scaling

【拡張スケーリング機能】
複数のAWSサービスに対して、スケーリング（リソースの増減）を自動で制御。用途に応じてスケーリングポリシーを柔軟に定義することができる。

DRS

特徴

コスト効率が高い	復旧サイトのリソースはアイドル状態で維持され、必要なときだけフル稼働するため、無駄なコストを削減できる。
簡単なセットアップと運用	AWSマネジメントコンソールから操作でき、特別なスキルがなくても導入可能。エージェント方式で既存インフラへの変更も最小限。
自動化された復旧プロセス	起動テンプレートやモニタリングツールの有効化など、復旧に必要なアクションを自動化できる。レプリケーションで取得したサーバーイメージはEC2インスタンスとして復元できる。
柔軟なユースケース対応	オンプレミスからAWS、他クラウドからAWS、AWSリージョン間など、さまざまな構成に対応可能。
テストフェイルオーバー機能	実際の障害を起こさずに復旧テストができるため、BCPの信頼性を定期的に検証できる。
切り戻し機能	元のサイトに切戻し(フェールバック)もできる。（オンプレミスのサーバーにも対応可能）

連携サービス

Global Accelerator	Global Acceleratorを活用して、フェイルオーバー後も低レイテンシを実現。全体として、アプリケーション層・データベース層のそれぞれに明確なRPO/RTO目標を持ち、短時間かつコスト効率の高い災害復旧を実現する設計。

事前知識

●IPS (Intrusion Prevention System)

トラフィック保護。不正侵入防止（防御）システム。

●IDS（Intrusion Detection System）

ネットワークやサーバーを監視し、不正なアクセスを検知して管理者に通知する役割を担うシステム。
インスタンスまたはリバースプロキシ層に IDS/IPS エージェントを実装することで解決できる。

ネットワークACL

※最も低いルール番号から順番に評価されていく

セキュリティグループ

【ステートフル】1つ以上のインスタンスのトラフィックを制御する仮想ファイアウォールとして機能する。
どのトラフィックEC2インスタンスへ、またはインスタンスから許可されるかを指定する。

・インスタンス間のトラフィックを制御するためには、セキュリティグループを利用することが適切。
・セキュリティグループは EC2 等のインスタンスのトラフィックを制御する。

★ステートフルの解釈 応答トラフィック。インバウンドを定義したらアウトバウンドも定義されるという認識。

[デフォルト（初期設定）]

• インバウンド：同じセキュリティグループからの全トラフィックを許可する。
• アウトバンド：全アドレスからのすべてのトラフィックを許可する。

WAF

【WAFで保護できるリソースタイプ】
以下に転送されるHTTPおよびHTTPSリクエストのみをモニタリング可能。また、コンテンツへのアクセスを制御可能にする。
・CloudFrontディストリビューション
・API Gateway REST API
・ALB
・APP Sync
・Cognito　ユーザープール

※CloudFront、ALBと緊密に統合されている。

構成要素

Web ACL 【保護対象選択】	リクエストの処理方法（許可・ブロック）を制御し、ルールの集合体として構成される。 Web Aclに関連付けされたAWSサービスが保護対象となり、Web Aclの配下に作成したルールやルールグループが保護対象リソースのアクセス制御の評価基準となる。保護されたリソースが応答するすべての HTTP(S) ウェブリクエストをきめ細かく制御できる。	【下記リソースを保護】 ・CloudFront ・API Gateway ・ALB ・AppSync ・Cognito ・App Runner ・Verified Access
レートベースルール 【DDoS対策】	送信元IPアドレスごとにリクエストの数を追跡し、リクエストの数が制限を超えた時、条件に合致するトラフィックをブロックする。 ●Referer制限 直前に開いていたサイトに応じてアクセスを制限する。
ルールグループ	複数のルールをまとめて再利用する構成。AWSマネージドルールや独自ルールのグループ化が可能。

Firewall Manager

●オートメーションソリューション

Organizations の全てのアカウントとリソースで　ファイアウォールルールを一元的に設定、管理、監査できる。

●AWS Network Firewall

【VPC】VPC 全体に Network Firewall セキュリティをデプロイ。インターネットやVPC間とのネットワークトラフィックをきめ細かく制御するファイアウォールルールを定義。（Internet Gatewayの手前に設置されているイメージ）
・Network Firewall ルールに基づいてポリシーを構築し、それらのポリシーを仮想プライベートクラウド (VPC) とアカウント全体に一元的に適用できる。

[一元的自動デプロイ]
一元的に設定したルールのセットへの変更が、アカウントと VPC に自動的にデプロイされる。これにより、セキュリティ管理者は組織内に新しいアカウントと VPC が作成された場合でも、組織全体で一元的に義務付けられたファイアウォールルールを一貫して適用できる。

Shield

Standard	【無料DDos対策】 すべてのAWSユーザーが自動的に利用できるサービス。インフラストラクチャ（L3、4）を標的とするDDoS攻撃から保護する。受信するトラフィックをモニタリングし、異常を検出する。
Advanced	【高度なDDos対策】 アプリケーションレイヤー（L7層）に対するDDoS攻撃から保護する。

Guard Duty

※AWS上で有効化するだけで使用可能。

●Lambda Protection 機能

Lambda 関数のコード自体をスキャンする機能だけでなく、ランタイム中の不正なアクティビティや脅威を監視。

仕組み

GuardDutyは以下のログデータを継続的に分析する。
・VPCフローログ: ネットワークトラフィックの情報を監視。
・CloudTrailログ: AWSアカウント内のAPIアクティビティを監視。
・DNSログ: DNSクエリの情報を監視。

上記ログを基に、脅威インテリジェンス（既知の悪意のあるIPアドレスやドメインのリスト）と機械学習を組み合わせて、以下のような脅威を検出する。

未知の脅威	通常とは異なる場所からのAPI呼び出し、異常なトラフィックパターン、不審なユーザー行動など
既知の脅威	暗号通貨マイニング、既知のマルウェア感染、不正なポートスキャンなど

[メンバー設定]
※メンバーアカウントごとに本サービスを有効にする必要がある

(管理・メンバー) アカウントの指定	・管理者アカウントとメンバーアカウントを同時に持つことはできない。 ・アカウントが管理者ではない場合、他の管理者からの招待を受けてメンバーになることが可能。 ・メンバーとなったアカウントは管理者として指定されることはない。
招待によるメンバー 設定手順	①招待の受諾 → ②アカウントの追加 → ③招待の送信

IPリスト

信頼できるIPリスト	役割: 安全だと分かっているIPアドレスを登録しておくリスト。 効果: このリストに入っているIPからの通信は、GuardDutyが「安全だ」と判断し、警告を出さない。これにより、誤った警告が減り、本当に重要な警告に集中できる。
脅威IPリスト	役割: 危険だと分かっているIPアドレスを登録しておくリスト。 効果: このリストに入っているIPからの通信があると、GuardDutyが「危険な通信だ」として警告を出す。

連携サービス

●Organizations

AWS Organizations を使用している場合、管理アカウントから GuardDuty を一括で有効化・管理できる。管理アカウントが GuardDuty を有効化すると、組織内の他のアカウント（メンバー）に対しても自動的に GuardDuty が有効化される。

[GuardDuty の自動有効化とメンバー管理]

• 組織の管理アカウントが GuardDuty を有効化すると、組織内の新規アカウントにも自動的に GuardDuty が有効化される。
• 既存のメンバーアカウントに対しては、GuardDuty の招待と承認プロセスが必要になる場合がある。

[メンバーアカウントの追加方法]

方法	説明
自動追加（Type: Organization）	管理アカウントが GuardDuty を有効化すると、組織内のアカウントが自動的にメンバーとして追加される
招待による追加（Type: By Invitation）	管理アカウントが GuardDuty に手動で招待し、メンバーが承認することで追加される

Security Hub

複数のサービスにまたがって届く膨大な数のアラートをひとつひとつ確認して処理する手間を減らすことが期待できる。 （GuardDuty、Inspector、Macieなど画面にそれぞれ遷移しなくてよい）
AWS サービスのイベントは、ほぼリアルタイムで、保証に基づいて EventBridge に配信される。

・CIS Benchmarksをサポートしている

★CIS Benchmarksとは セキュリティ担当者がサイバーセキュリティ防御を実装および管理するのに役立つ。世界的に認められたコンセンサス主導の一連のベストプラクティス。 [参考]

[結果をグループ化]
フィルターを変更することに加えて、選択した属性の値に基づいて結果をグループ化できる

Inspector

・EC2インスタンス/ECRのコンテナイメージ/Lambda関数の脆弱性を行うサービス。
・AWSのEC2インスタンスにおいて脆弱性診断を自動で行ってくれるサービス。
・スキャンには AWS Systems Manager (SSM) と SSM Agent を利用。
・SSM が収集した ソフトウェアインベントリ情報 をもとに、Inspector が脆弱性を検出。
・対象は、Systems Manager がサポートする OS のソフトウェア のみ。

●評価テンプレート

【評価定義】評価の実行を定義するために作成するもの。評価ターゲットを評価するためのルールパッケージ、評価実行期間、評価の実行状態と結果に関する通知の送信先である、SNSトピック、評価の実行によって生成された結果を割り当てることができる。

[Lambda関数スキャン]

Lambda関数に対して、自動的にCVEスキャンを実行する。

Inspector Lambda 標準スキャン 【依存パッケージの脆弱性】	デフォルトのスキャン方式。Lambda 関数およびレイヤー内のアプリケーション依存関係を対象にスキャンを実施。パッケージに脆弱性が含まれていないかを調べる。
Inspector Lambda コードスキャン 【自分で書いたコードの脆弱性】	Lambda 関数およびレイヤー内のカスタムアプリケーションコードをスキャンし、コードそのものに脆弱性がないかをチェックする。このスキャンを有効化する際には、Lambda 標準スキャンもあわせて有効化される。

[ECRコンテナイメージのスキャン]

ECR に保存されたコンテナイメージをスキャンして ソフトウェアの脆弱性（CVE） を検出する。

スキャンのタイミング	・新しいイメージがプッシュされたとき ・Inspector の CVE データベースに新しい脆弱性が追加されたとき（継続的スキャンの場合）
初回スキャンの対象	・機能を有効化すると、過去30日間にプッシュされたイメージが対象
スキャンの継続性	・デフォルトでは、イメージは生涯にわたって継続的にスキャンされる

Systems Manager との関係性

項目	内容
目的	セキュリティ脆弱性の検出と修正
Inspector の役割	EC2 やコンテナに対して脆弱性スキャンを実施
Systems Manager の役割	パッチ適用や設定変更などの修復アクションを実行
連携のポイント	Inspector が検出した脆弱性に対して、Systems Manager を使って自動修復やパッチ適用が可能
前提条件	EC2 インスタンスに Systems Manager Agent がインストールされており、適切な IAM ロールが設定されていること

Code Guru

AWS が提供する機械学習ベースのコード分析サービスで、以下の2つの主要機能を備えている。

CodeGuru Reviewer	ソースコードを自動レビューし、バグ、非効率な処理、セキュリティ脆弱性を検出。Java、Python、JavaScript、C# などに対応。プログラム分析と機械学習を使用して、開発者が見つけるのが難しい潜在的な欠陥を検出し、JavaおよびPythonコードを改善するための提案を提供する。
CodeGuru Profiler	本番環境のアプリケーションをプロファイリングし、CPU使用率やメモリ消費のボトルネックを特定。パフォーマンス改善の提案を行う。

[特徴と利点]

• 数百万件のコードレビューとオープンソースの知見を活用。
• GitHub、Bitbucket、AWS CodeCommit などと統合可能。
• IDE（Visual Studio Code、IntelliJ など）との連携も可能。
• セキュリティ機能では、誤検出を減らし、バグの自動追跡も可能。

Code Guru Security

※以前は「CodeGuru Reviewer」の一部として扱われていたが、現在は独立したセキュリティ機能として明確に位置づけられている。

アプリケーションコードの脆弱性スキャンに特化したセキュリティサービスであり、Pythonアプリケーションを含むコードの脆弱性を静的解析し、問題を検知する。また、Code Build で実行するプロジェクトを設定する際に、CodeGuru Security で脆弱性が検出された場合にエラーを発生させることで、CodePipelineのデプロイステージに進むことを明示的に止められる。

DevOps Guru

Macie

※S3に保存されている個人データの検出と保護のみ

通知や発見したデータセキュリティリスクに対する自動保護を可能にする。

[コスト最適化方法]

• 「最終変更」基準を使用してオブジェクトを含める
  分類可能な S3 でホストされているオブジェクトが変更される頻度を認識していて、特定の時点で変更されたリソースをスキャンしたい場合は、スコープに「最終変更」基準を使用して特定の日付または時刻に変更されたオブジェクト。
  
• CloudTrail ログをスキャンしない
  CloudTrail ログを含む S3 バケット プレフィックスを特定し、スキャンから除外する。

Detective

主な機能

アラート分析 (グラフ理論と機械学習で相関分析)	GuardDutyなどで検出されたアラートを視覚的に調査。関連するIP、IAMユーザー、リソースの履歴を確認。
インシデント調査 (セキュリティインシデントの根本原因を特定)	不審な操作や通信の履歴を時系列で追跡し、影響範囲を特定
スレットハンティング	明確なアラートがなくても、異常な挙動をもとに潜在的な脅威を探索
検出結果グループ	複数の関連アクティビティをまとめて分析し、攻撃の流れを把握
ログデータを自動収集 （最大1年間の履歴データにアクセス可能）	CloudTrail、VPC Flow Logs、GuardDutyの検出結果など

・事前に構築されたデータの集計、要約、コンテキストによって、起こりうるセキュリティ問題の性質と範囲を迅速に分析および判断するのに役立つ。

導入の流れ

①GuardDutyを有効化（48時間以上）
②Detectiveをコンソールから有効化
③IAMポリシーを設定
④メンバーアカウントを招待
⑤データ抽出とグラフ生成を確認

Policy Generator

【ポリシー作成簡素化】

SQS,S3,SNS,IAMのポリシードキュメントを作成するプロセスを簡素化するサービス。

監査対応に向けたサービス

【AWSアカウントのアーキテクチャとアーティファクトを調査】

一般的に読み取り専用アクセスを必要とする。そのため、読み取り専用アクセスをもつIAMユーザーを作成する。

Artifact

・監査を行う際に、AWS Artifactから該当のレポートをダウンロードして監査人に提供できる。

・Payment Card Industry Data Security Standard (PCI DSS) 準拠に関する情報が含まれている。

Service Organization Control

【第三者報告書】※略称：SOC
オペレーションとコンプライアンスをサポートするよう確立された AWS 統制を、ユーザーおよびユーザーの監査人が容易に把握できるようにする目的がある。

独立した第三者（ユーザーおよびユーザー監査人）がAWS社に対して、「重要な準拠統制および目標をAWSがどのように達成したか」を評価する審査報告書。

[４種類のSOCレポート]

・AWS SOC 1 レポート
・AWS SOC 2: セキュリティおよび可用性レポート
・AWS SOC 2: 機密性レポート
・AWS SOC 3: セキュリティおよび可用性レポート

[監査に備えてのベストプラクティス]

・IT運用管理の証拠収集
・第三者（サードパーティー）の監査済みAWSコンプライアンスレポート（報告書と証明書）
・侵入テスト実行

基礎知識

●エッジロケーション

リージョン、AZとは異なるデータセンター。
キャッシュデータなどを利用する際の更に小さなエンドポイントとなる拠点。
・DDoS攻撃からアプリケーションインフラストラクチャを保護する。
・Route 53、CloudFront、AWS WAF、Lambdaエッジ などが配置されている。

●責任共有モデル

提供されるサービスの管理責任を線引きした考え方。
詳細は「本公式ページ」にて。

●Docker

オープンプラットフォーム。コンテナサービスのこと。サーバごとに「必要なコンテナを用意して」「実行する」動きをする。

●リポジトリ

ECRのイメージリポジトリには、Dockerイメージ、OCIイメージなどが含まれる。

リポジトリポリシー	（コンテナ）イメージへのアクセス権を制御できる。
(コンテナ)イメージ	ECSやEKSで使用することが出来るコンテナイメージをpush、pullする。 利用可能な Docker イメージを実行する場合、docker pull コマンドを使用してローカル環境にプルする。
認証トークン	イメージをpush、pullするにはECRレジストリに対して認証が必要。

インフラ一括管理ツール

Service Catalog

環境カタログ集。IT管理者が利用者向けの製品やAWSリソースなどをカタログ(ポートフォリオ)として集中管理。
・ 製品の追加や制約の追加を行うことができる。
・製品や環境を準備しておくだけで、実際に起動するタイミングなどは利用者側に一任できる。
・ユーザーは必要な承認済みのITサービスのみをすばやくデプロイできる。
・作成したポートフォリオに対して利用者のアクセス権限を設定できる。

※AWSで使用が許可されたサービスのみ対象

●起動制約

利用者が自由にAWSリソースを作成するのではなく、管理者が定めたルールの中で安全に利用できるようにするのを目的とする。製品の利用方法にルールを設けて、ガバナンスやセキュリティを強化するための仕組み。簡単に言うと、「誰が・どのように・どんな設定で」製品を使えるかを制御できる。

[制約の種類]

起動制約 (Launch Constraint)	指定したIAMロールを使って製品を起動させることで、ユーザーに直接の権限がなくても安全にリソースを作成。
テンプレート制約 (Template Constraint)	CloudFormationテンプレートのパラメータに制限をかける。 たとえば、EC2のインスタンスタイプを「t2.micro」だけに制限するなど。
通知制約 (Notification Constraint)	製品の起動や更新時にSNS通知を送る設定ができる。
タグ更新制約 (Tag Update Constraint)	製品に付与されたタグの変更を許可するかどうかを制御する。
スタックセット制約 (Stack Set Constraint)	AWS Organizationsと連携して、複数アカウントにまたがるデプロイを制御できる。

Market Place

外部製品購入。厳選されたデジタルカタログ。
ユーザーはサードパーティーのソフトウェア、データ、サービスを検索、購入、デプロイ、管理してソリューションを構築し、ビジネスを運営できる。企業側は手軽に出品することができる。また、ユーザーに発生する料金はAWS内で一元管理される。

●Hyperwallet

Paypal が提供する海外口座レンタルサービス。資金をサポートされている他の銀行口座に送金することができる。AWSが標準サービスとしてサービスに組み込んでおり、Hyperwallt の登録が完了するとAWSアカウントに紐づけができるようになる。

VPC

●ENI(Elastic Network Interface)

VPC内のNWインターフェース。

プレフィックスリスト

複数のCDIRブロックを一元管理することができる。

AWSマネージド	※AWS管理 AWSサービスのIPアドレスの範囲のセットで、元々から用意されているもの。 所有者IDがAWSであるため変更・削除等はできない。
カスタマー管理	※ユーザー管理 自分で作成するIPアドレスの範囲で、他のAWSアカウントと共有できる。

エンドポイント

[各エンドポイントの比較]

項目	VPCエンドポイント	エンドポイントサービス	サービスエンドポイント
役割	AWSサービスや他VPCに接続するための入り口	自分のサービスを他VPCに公開する出口	AWSサービスへのセキュアな内部接続を提供
利用者	サービスを使いたい側（コンシューマー）	サービスを提供する側（プロバイダー）	AWSサービスを利用したいVPC内部のユーザー
対象	他者のエンドポイントサービスまたはAWSサービス	他アカウント／VPCに自サービス（EC2等）を公開	S3やDynamoDBなどのAWS公式サービス
構成要素	ENI（インターフェース型）	NLB（Network Load Balancer）＋PrivateLink	ゲートウェイ型／インターフェース型のいずれか
接続方式	PrivateLink	PrivateLink	AWS内部ネットワーク（PrivateLink含む）
承諾制	なし（自分で作成して利用）	あり（接続元からのリクエストを承諾）	なし（AWSサービスに直接接続）
課金体系	インターフェース型は時間＋処理量課金	PrivateLink利用料＋NLB費用	インターフェース型は課金あり／ゲートウェイ型は無料
主なユースケース	S3, SNS, SQSなどへのプライベートアクセス	SaaS提供やクロスアカウントのサービス共有	S3/DynamoDBなどへのセキュア接続（Private Subnetから）

・VPCエンドポイント：サービスを「利用する側（コンシューマー）」の入り口
・エンドポイントサービス：サービスを「提供する側（プロバイダー）」の出口

●サービスエンドポイント

【VPC→AWSサービス】※接続元
AWSの特定サービス（例：S3やDynamoDB）に対して、インターネットを経由せずにVPC内から直接プライベートにアクセスできるようにする仕組み。

ゲートウェイ型	・ S3 / DynamoDBのみ対象 ・コスト無料 ・接続方式：ルートテーブル（Private Linkは使用しない） ・セキュリティー：VPCエンドポリシー ・VPC内でのアクセスしか使えない。アプリケーションはインターネットを経由せずにAmazonネットワーク経由でDynamoDBにアクセスできる
インターフェイス型	・S3とDynamoDB を含む幅広いサービスを対象(不要なコストと設定負荷を伴う) ・データの転送とサービス利用時間に応じて課金。 ・接続方式：エントリポイントとなるプライベート IP アドレスを持つENI。 ・セキュリティ：セキュリティグループ(細かい制御可能) ・VPC外からのアクセスも対応

属性

●enable DNS Hostnames 属性

有効化しないと、サブネットで起動されたインスタンスはDNS名を取得できない。

●enable DNS Support 属性

VPCがAmazon提供のDNSサーバーを介したDNS解決策をサポートするか決定する設定値。デフォルトでは有効化。

その他機能

●Traffic Mirroring

EC2 インスタンスのENIからネットワークトラフィックをコピーする機能。

●DHCPオプション

(Dynamic Host Configuration Protocol)
TCP/IPネットワークのホストに設定情報を渡すための規格。サブネット内のアプリケーションは、必要に応じてDHCP サーバーと通信して、IPアドレス、または他のネットワーク構成情報 (DNS サーバーの IP アドレスや VPC 内のルーターの IP アドレスなど) を取得できる。

※TCP/IP ネットワーク上のすべてのデバイスには、ネットワークを介して通信するための IP アドレスが必要。
※DHCPは変更できないため、新しく作成して割り当てる必要がある
※以前は、ネットワーク内の各デバイスに IP アドレスを手動で割り当てる必要があった

仮想サーバー

AMI

・AMIはリージョンに依存する。AMI IDはリージョン固有であり、同じIDを異なるリージョンのAMIに割り当てることはできない。
（別リージョンで使用するときはコピーする）

●ゴールデンイメージ

【最適なEC2のAMI】
下記のような特定のAWSリソースタイプにおいて、最適なEC2インスタンスの構成をAMIとしたもの。
※EC2インスタンス、RDS DBインスタンス、EBSボリューム……など

オプション

No Reboot	AMI作成時の再起動を設定できる。再起動しないオプションが true（有効） に設定されている場合、EC2 はイメージの作成前にインスタンスをシャットダウンしない。 稼働中のEC2からAMIを取得したいときなど利用する。有効にしないでAMIを取得すると、稼働中のEC2が再起動してしまう（サービスの停止）。 ※デフォルトでは、EC2はインスタンスをシャットダウンして再起動してからイメージを作成する。

EC2(Elastic Compute Cloud)

・垂直スケール時、インスタンスを停止する必要がある
・コストを最小化するためには、インスタンスを可能な限り多くのゾーンに分散する。
・Linux2はデフォルトでSystemManagerエージェントがプリインストールされている

[インスタンスの再起動について]

一般的に「停止」→「起動」が的確な再起動となる。意図しない再起動が発生した場合、データは残るが、終了（削除と同意）するとデータは消える。
※システムの可用性を高める場合、基本的には EC2 を複数構築してスペックは低めにすることが良い。
（高スペック 1 台よりメリットが得られる。全ダウンしにくい、料金が安い）

[問題のあるインスタンスの調査方法]
ナビゲーションペイン→インスタンス:詳細ペイン→ Status Checks→System Status Checks と Instance Status Checks

メトリクス	モニタリングできるメトリクスについて記載。 [参考公式サイト]
IPアドレス	パブリックIPアドレスはインスタンスの作成時、「EC2のバブリックIPの自動割り当て」を有効にしないと割り当てられない。そのため、Elastic IPで後から指定する。

機能性

●SSH(セキュアシェル)キー(公開鍵/秘密鍵)

EC2にログイン(アクセス)するときに必要。インスタンスにアクセスキーを保存することはNG。インスタンスで動作するアプリケーションはAWSの他のサービスにアクセスするために認証情報が必要。

●EC2 Instance Connect

EC2インスタンスへのSSHアクセスを簡素化し、セキュリティを強化する。接続ごとに一時的なSSHキーが生成され、インスタンスに自動的に送信される。(SSHポートをひらく必要がある)また本サービスの利用は、CloudTrailに記録される。

●インスタンスメタデータ

インスタンスに関するデータで、実行中のインスタンスを設定または管理するために使用する。ホスト名、イベント、およびセキュリティグループなどのカテゴリに分けられる。インスタンスメタデータは実行中のインスタンスから取得できる。EC2 コンソールまたは AWS CLI を使用する必要はない。

●ブロックデバイスマッピング

属性

SrcDestCheck	送信元/送信先チェックをデフォルトで実行する。
DisableAptermination	偶発的な削除を防ぐことができる。インスタンスがコンソール、CLI、またはAPIを使用して終了できるか制御してくれる。
テナンシー（テナント属性）	EC2 インスタンスが物理ハードウェアに分散される方法を定義する。 ・default：インスタンスは共有するハードウェアで実行される。 ・dedicated：インスタンスはシングルテナントのハードウェアで実行される。 ・host：インスタンスはDedicated Hostで実行される。

[ルートデバイスボリューム]
インスタンス起動時に EBS ボリューム、またはインスタンスストアボリュームのどちらかルートデバイスボリュームを関連付ける。

※ルートボリューム：OS領域に割り当てるもの。システムストレージを使用する。

EBS-backed インスタンス	インスタンスを起動する際に、EBSが割り当てられる。
Instance store-Backed インスタンス (インスタンスストア)	EC2インスタンスに内蔵されている無料の簡易ローカルストレージ。 （※エフェメラルディスク） ・EC2の一時的なデータが保持され、EC2の停止・終了と共にクリアされる。 ・スナップショット作成できない。 ・物理ドライブに直接接続されているため、読み書き速度が早い。 ※/dev/sda1はルートボリューム（ルート用に予約されたボリューム）

[ストレージの変換について]
Instance Store-Backed Linux AMI を EBS-backed Linux AMI に変換はできる。
Instance Store-Backed Windows AMI を EBS-backed Windows AMIへの変換、および所有していないAMIの変換はできない。

品質改善

停止保護	インスタンスの停止および手動削除を防ぐ機能。
unlimited モード	【バーストパフォーマンス】 24 時間ごとのインスタンスの平均 CPU 使用率またはインスタンスの存続期間のいずれか短い方の時間で、インスタンスの平均 CPU 使用率がベースライン以下になった場合、1 時間ごとのインスタンス価格は自動的にすべての CPU 使用率スパイクをカバー。ピーク時以外のリソース使用率を抑えることができるため、ケースによってコスト最適化につながる。
送信元/送信先 チェック	※デフォルトで有効化 受信するすべてのトラフィックに関して、そのインスタンスが送信元なのか、あるいたは送信先であるのかを確認できる。ネットワークアドレス変換、ルーティング、ファイアウォールなどのサービスを実行するインスタンスでは本機能を無効にする必要がある。
ハイバネーション	【停止しても継続できる】 インスタンスが停止する前にメインメモリが保持する内容をハードディスクドライブに待避させ、次にコンピュータを起動させた際、作業途中から再開できるようにする機能。インスタンスがインターネットにアクセスするには、パブリックIPアドレスが必要となる。 ※セキュリティグループを指定しないままインスタンスを起動するとデフォルトセキュリティグループが指定される
自動復旧機能	インスタンスをモニタリングするCloud Watch アラームによって、基盤ハードウェアの障害や、AWSによる修復を必要とする問題によりインスタンスが正常に機能しなくなった場合、自動的に対象のインスタンスを復旧させることができる。復旧されたインスタンスは「インスタンスID」「プライベートIPアドレス」「ElasticIPアドレス」、すべてのメタデータを含めて、元のインスタンスと同じである。 ※自動復旧
Elastic Fabric Adapter (EFA)	【インスタンスの高速NWデバイス】 HPC（ハイパフォーマンスコンピューティング）と機械学習アプリケーションを高速化するために、EC2 インスタンスにアタッチできるネットワークデバイス。AWSで大規模な高レベルのノード間通信を必要とするアプリケーションを実行（数千のCPUまたはGPUに拡張）できる。既存の AWS ネットワークインフラストラクチャで動作するように最適化されており、アプリケーション要件に応じてスケーリングできる。 ※AWS Batchと連携して、バッチコンピューティングワークロードを実行 【以下をサポート】 ・メッセージパッシングインターフェイス（MPI）を使用するHPCアプリケーション ・NVIDIA Collective Communications Library（NCCL）を使用する機械学習アプリケーション

インスタンスの起動設定

EC2 フリート	【起動するインスタンスグループ】 起動するインスタンスの（オンデマンドやスポットなどの）種類、組み合わせを設定したグループ。設定次第でコスト最適化ができる。 ※起動設定の代わりに起動テンプレートを利用してAuto Scalingを構成できる
起動テンプレート	【設定の処理】 インスタンスを起動するための設定情報を含む起動テンプレートを作成。AMIのID、インスタンスタイプ、キーペア、セキュリティグループなどEC2の起動に必要なパラメーターが含まれている。 ※起動テンプレートにより起動パラメータを格納でき、インスタンスを起動するたびに指定する必要がなくなる。
EC2Configサービス	【タスク処理】 EC2Config は設定ファイル群を使って操作を制御する。インスタンスの初回起動時に複数の初期起動タスクを実行し、その後、それらを無効にする。これらのタスクを再実行するには、ユーザーが明示的に有効化した後でインスタンスをシャットダウンするか、手動でSysprep を実行する必要がある。
ユーザーデータ	【パッケージの処理】 インスタンス起動時に自動実行されるスクリプトのこと。起動時しか実行されない。アプリケーションのデプロイを自動化、インスタンス起動時に必要なソフトウェアをインストールしたり、アプリケーションをダウンロードして設定したり、サービスを起動したりする処理を記述できる。パッケージのアップデートやソフトウェアのインストールの際に有効。インスタンス起動時の一般的なタスクやプログラムはインスタンスにユーザーデータを渡すことで可能。EC2インスタンスの起動設定の一番下の方で記述し、ApacheをインストールしてWebサーバーにする、などの使い方をする。
EC2 Image Builder	[依存関係]アプリケーションとその依存関係のインストールを自動化し、定期更新を取り込むことが可能。 [ディストリビューション設定] 作成したイメージの配布方法を定義。新しいAMIがビルドされるたびに Autoscaling グループの起動テンプレートが自動的に最新のAMIを使用するように更新できる。 [カスタムレシピ] 特定の構成とインストール手順を定義し、それを元にEC2のAMIを作成できる。加え、本機能の一部として、AMI 作成プロセス中に自動的に脆弱性スキャンを実行できる。 ※アプリケーションの依存関係：対象のアプリケーションが正しく動作するために必要なその他アプリケーションのリスト。 【例】内部オブジェクトの内部アプリケーション詳細の表示方法 > アプリケーション > アプリケーション詳細ウィンドウ

インスタンスの種類

●コンピューティング最適化インスタンス

高いコンピューティングパフォーマンスが必要なワークロードに適しているが、コスト効果に優れているとは限らない。

●メモリ最適化インスタンス

メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスを実現するように設計されている。

●リザーブドインスタンス

(スタンダード / コンバーティブル)（数年間契約「１年間」「３年間」）

スタンダード	別のインスタンスファミリーに変更することができない。オンデマンドインスタンスと比較して、最大72％の割引を適用することができる。
コンバーティブル	作成時の価格と同等以上のインスタンスであれば、以下の設定を途中で変更できる。その代わりスタンダードRIよりも少し高い。 ・インスタンスファミリー ・OS,テナンシー (HWが共有か専有か) ・支払オプション (前払い、一部前払い、前払いなし)

[RI割引について]
割引を受けられるのは、RIを購入したアカウントのみ適用される。RIの割引共有を無効にするには、管理アカウントから実行できる。※RIの更新は有効期限満了日に更新可能
[参照元サイト]

●オンデマンドインスタンス

【時間単位、秒単位】
コンピューティング性能の料金を、長期契約なしで、時間または秒単位 (最低 60 秒) で支払うことができる。

[オンデマンドキャパシティ予約]

属性が一致する個別のインスタンスに対して、任意のタイミングや指定した時刻に終了するキャパシティが予約される。
特定のAZで任意の所要時間だけ、利用したい指定インスタンスのコンピューティング能力を予約もできる。
その際に、下記情報を選択すること。
・キャパシティーが予約されているアベイラビリティーゾーン
・キャパシティーを予約するインスタンスの数
・インスタンスタイプ、テナンシー、プラットフォーム/OS を含むインスタンスの属性

●スポットインスタンス

AWSサーバ上に存在し、使われてないEC2インスタンスに値段をつけて入札価格が現在のスポット価格(長期でなく、1回ごとの取引で決定した市場価格)を上回っている限り、そのインスタンスを利用できる。処理途中で中断可能な計算処理を大規模かつ並列で実行する場合に使用できる。※単独で実行されるかつ、停止した場合でも再実行で整合性を保証する

①スポットブロック

【スポットインスタンス継続利用】
スポットブロックが定義されたスポットインスタンスを中断することなく、選択した期間にわたって継続して利用できる。

・継続期間として 1 時間、2 時間、3 時間、4 時間、5 時間、または 6 時間を使用できる。
　※支払い額はこの指定した継続期間によって決まる。
・バッチ処理、エンコードとレンダリング、モデリングと解析、継続的な統合など、完了までに一定の時間のかかるジョブに最適。

②スポットフリート

【スポットインスタンスのセット】
スポットインスタンスの集合体。リクエストで指定した容量ターゲットを満たすような「スポットインスタンス」と「オンデマンドインスタンス」数を起動する購入方式。ニーズに合うスポットキャパシティープールを選択して、フリートのターゲット容量を満たすまでスポットインスタンスを起動する。

[起動の仕組み]
スポットフリートは、ニーズに合ったスポットキャパシティ（空き容量）プールを選んで、フリートのターゲットキャパシティ（目標容量）を満たすまでスポットインスタンスを起動する。フリートのスポットインスタンスが削除された後に代替インスタンスを作成することによってターゲット容量が維持されるように設定されている。

[リクエスト方法]
インスタンスの終了後も保持されない「ワンタイムリクエスト」として送信できます。オンデマンドインスタンスのリクエストもスポットフリートのリクエストに含めることができる。

[配分戦略]

起動設定によって、スポットフリートがスポットインスタンスを起動できるすべてのスポットキャパシティプール (インスタンスタイプおよびアベイラビリティーゾーン) を決定する。インスタンスを起動する際、スポットフリートは指定された配分戦略を使用して、使用可能なすべてのプールから特定のプールを選択する。

capacityOptimized	スポットインスタンスのリクエストを行う際、最も余裕のあるインスタンスタイプに対してリクエストする。
lowestPrice	最も低い価格のインスタンスタイプに対してリクエストを行う。しかし、価格の低いインスタンスは需要が高いため、供給が追い付かない可能性がある。
diversified	さまざまなインスタンスタイプや可用性ゾーン間でスポットインスタンスのリクエストを分散させる。

③スポットインスタンスアドバイザ

[中断軽減]
中断する可能性が最も少ないプールを判断して、オンデマンド料金を削減できる。スポットインスタンスを選択する前に、ユーザーはアプリケーションの中断をどの程度許容できるか、およびコスト削減の目標を比較検討する必要がある。中断の頻度が低いほど、スポットインスタンスを利用できる時間は長くなる。

[EC2インスタンス静止状態割引]
アプリケーション中断できる場合に、費用効率を非常に高く抑えることができる。\\

[リクエストのタイプ]

リクエストとは、スポットインスタンスを使用するために、希望するインスタンス数、インスタンスタイプ、アベイラビリティーゾーンを決める必要がある。

ワンタイムスポットインスタンスリクエスト	下記の状態にならない限り、アクティブ状態を維持する。 ・EC2 がスポットインスタンスを起動する ・リクエストの有効期限が切れる ・ユーザーがリクエストをキャンセルする 利用できるキャパシティがない場合、スポットインスタンスは終了し、スポットインスタンスのリクエストは終了する。
永続スポットインスタンスリクエスト	リクエストが受理された後も、リクエストの有効期限が切れるかユーザーによりキャンセルされるまで、アクティブ状態を維持する。キャパシティを利用できない場合は、スポットインスタンスは中断。中断後に、キャパシティが再び利用可能になると、スポットインスタンスが開始 (停止している場合)、あるいは再開 (休止状態の場合) される。

[ステータス]

●ステータスチェック

EC2におけるステータスのモニタリングを実行する。OSまたはミドルウェアからアプリケーション、AWS基盤側の問題などが検出されたか確認。（アプリケーションレベルの障害は検知できない）

[１分ごとに実行し、成功・失敗のステータスを更新]
・成功の場合：「OK」
・失敗の場合：「impaired」
※失敗の場合、インスタンスの[停止→起動]の実行で解消することがある。

pending： 実行前	stopped：インスタンスは停止状態、起動は可能
running： 実行中	shutting-down：削除準備中
stopping： 停止中	terminated：削除

[インスタンスファミリー]

【M~】汎用
【C~】 コンピューティング最適化	バッチ処理、高性能/高負荷なWebサーバ、動画エンコード、ゲームサーバなど
【R~シリーズ】 メモリ最適化	高性能/高負荷なデータベース、キャッシュサーバ、ビッグデータ分析など
【I,HS~シリーズ】 ストレージ最適化	NoSQL データベース、インメモリデータベース、データウェアハウスなど
【P,Inf,g,f】 高速コンピューティング
【T~シリーズ】 マイクロインスタンス
【G~シリーズ】 GPUインスタンス

[参考]

[トラブル・エラー]

・Insufficient Instance Capacity（インスタンスの容量不足）
[対策]
・数分間待ってから再リクエスト
・インスタンス数を減らして新しいリクエストを送信
・AZを指定しないでリクエストを送信
…etc

・Instance Limit Exceeded
インスタンス数の上限緩和リクエストが必要。

・インスタンス起動後、すぐに終了してしまう
インスタンスがすぐに終了する理由を次のいくつか。
・EBS ボリュームの制限を超えた。
・EBS スナップショットが破損している。
・ルート EBS ボリュームは暗号化されていて、復号用の KMS キー にアクセスする権限がない。
・インスタンスを起動するために使用した Instance Store-Backed AMI で、必要な部分 (image.part.xx ファイル)。
[引用元サイト]

クラスター構成

単一AZ内のEC2インスタンス間の通信を広帯域幅・低レイテンシーに実行できる。

クラスタープレイスメントグループ	【単一AZ】 単一のアベイラリティゾーン内のインスタンスを論理的にグループ化したもの。低いネットワークレイテンシー、高いネットワークスループット。インスタンス間のネットワーク遅延を最小限に抑える。
パーティションプレイスメントグループ	【単一AZ内】 アプリケーションに関連するハードウェア障害の頻度を軽減させるために役に立つ。(障害が広がらない)パーティションという論理的なセグメントに分割する。
スプレッドプレイスメントグループ	それぞれの異なるハードウェアに配置されるインスタンスのグループ。少数の重要なインスタンスが互いに分離して保持される必要のアプリケーションに推奨。インスタンスが基本ハードウェアを共有するときに発生する可能性のある、同時障害のリスクを軽減できる。

サーバー占有率

ベアメタル型 インスタンス	【物理へアクセス可能】 サーバーのプロセッサーと(CPUや)メモリーに直接アクセス可能なインスタンス。 通常のクラウドサーバーでは不可能な、ホストコンピューターのOSなど直接下層のハードウェアにアクセスが可能。また、仮想環境ではサポートされないレガシーのワークロード、そしてライセンス制限のあるティア1のビジネスクリティカルなアプリケーションを動かせる。
Dedicated Instance	【ハードウェア専有インスタンス】 他のAWSアカウントから分離された物理サーバにインスタンスを起動することができる。別アカウントのEC2インスタンスが同じサーバ上で起動しないことを保証する。（同じアカウントでのインスタンス共有はある）下記の場合に最適。 ・ソフトウェアのライセンス等で物理サーバを専有したい場合 ・コンプライアンスを重視する場合 ※一般的にEC2インスタンスはAWS側で任意の物理サーバの上で起動されるため、物理サーバ上のインスタンスには別アカウントのインスタンスが存在する。
EC2 Dedicated Host	【完全個室】(Dedicated Instance 上位版) インスタンス容量を完全にお客様専用として占有利用できる物理サーバ。別アカウントだけでなく、同アカウントのEC2インスタンスが同じサーバ上で起動できない。 ・サーバーにバインドされた既存のソフトウェアライセンスを利用できるため、コンプライアンス要件を満たし、コストを削減。 ※ライセンス条項の範囲で、ソケット単位、コア単位、または VM ソフトウェア単位の既存のライセンスを利用できる

AWSコンテナオーケストレーションサービス

●Pod

一つ以上のコンテナをグループ化（集合体）し、共有の実行環境を提供するKubernetesの最小単位。

Topology Spread Constraints	Podを複数のアベイラリティゾーンに均等に分散させる。これにより単一障害をなくす。Podの均等な分散はリソースの最適利用を可能にし、スケーラビリティとワークロードのバランスを保つ。
Kubernetes Cluster Autoscaler	予測不可能な数のステートレスPodに対応するためのスケーリングを提供。Kubernetesクラスタ内のノード数を自動で増減させるコンポーネント。

• レプリカセット（ReplicaSet）
  Kubernetes（クラスター）内でアプリケーションのPod（コンテナを含むアプリケーションの最小デプロイ単位）を一定数維持する機能。
  
• Kubernetes Horizontal Pod Autoscaler（HPA）
  Podの数を自動で増減させる仕組み。
  ・「Horizontal」：Podの数（横方向）を増減する。CPUやメモリの使用率などに基づいてスケーリング。
  ・目的：負荷に応じてPodの数を自動調整し、アプリケーションのパフォーマンスとリソース効率を最適化する。

デプロイ設定

Canary (割合分割)	すでにデプロイされているバージョンと新しいバージョンの間でトラフィックを分割。移行する割合 (%) を分単位で指定できる。 一部ユーザーに新環境を提供し、問題がある場合はフィードバックを得て修正を重ねる。
Linear (等分分割)	基本的にCanaryと同じであるが、新環境へのデプロイ割合が等分である。トラフィックは等しい増分で分割する。増分ごとに移行するトラフィックの割合 (%) と、増分間の間隔 (分) を指定できる。
All-at-once	新しいバージョンを全てのインスタンスに同時にデプロイする。
Blue / Green	新しいバージョンを完全に別の環境にデプロイし、すべてのユーザーを新環境に切り替える。 新環境のテストは行わず提供するが、問題があれば即時に旧環境に切り戻せる。

起動タイプ

Amazon ECSまたはEKSを利用する際は、EC2起動タイプかFargate起動タイプ(エンジン)を選択する。
[画像引用元]

EC2起動タイプ【通常のEC2利用】	Fargate【ECS / EKS】
通常のEC２インスタンスを利用するための設定が必要。管理しているEC2 インスタンスのクラスターで、コンテナ化されたアプリケーションを実行できる。使用されたEC2とEBSボリュームに基づいて課金される。インスタンスの選択やオペレーティングシステムの管理などが必要。故に自身で制御することが可能。	EC2を使わずにコンテナを実行する環境運用を自動化する。コンテナを実行するために仮想マシンのクラスターをプロビジョニング、設定、スケールを実施する。 (サーバーのプロビジョンとCluster管理は不要)。 ※ECSはコンテナ化されたアプリケーションが要求するvCPUとメモリリソースに基づいて課金。

EKS

★Kubernetesとは… コンテナ管理を自動化するための「コンテナオーケストレーションツール」。（オープンソース） より細かく、高度な運用ができることが特長。（その分、運用が難しい） たとえば、 ・どのコンテナイメージを何台実行するかを指定すると自動で配置してくれる ・リソース不足などの際に自動でスケールする……など

仕組み(構造)

コントロールプレーン (マスターノード)	※AWSによって管理されているため、ユーザー側の操作は不要 クラスタ内のワーカーノードやコンテナ情報を管理、Kubernetesオブジェクトの状態を保持する。クライアントからのコマンドや設定ファイルを受け取り、APIアクションを呼び出してコンテナのデプロイや更新を行う。また、スケジューラがコントロールプレーン側で動作すると、ワーカーノード上のKubelet(エージェント)が動作する。Kubeletはコントロールプレーンからの指示を受けてコンテナを起動する。
ワーカーノード	コントロールプレーンからの指示を受けてノード上にコンテナを起動する。起動タイプとして、EC2またはFargateを選択できる。コンテナイメージを事前に取得することで、Podの起動時間を短縮できる。 ※ノード：VMや物理マシン
データプレーン	伸縮自在であり、Kubernetes はアプリケーションを自動的にスケーリングして修復できる。回復力のあるデータプレーンは、2 つ以上のワーカーノードで構成され、ワークロードに合わせて増減し、障害から自動的に回復できる。

その他機能

kubeconfig ファイル	kubernetes を扱うための kubectl コマンドの接続先クラスターを管理する設定ファイル。 このファイルがないとEKSクラスターに接続できない。
EKS Anywhere （EKS-A）	AWS が提供する オンプレミスやエッジ環境で Kubernetes クラスターを構築・運用できるソリューション 。クラウドに依存せず、自社インフラ上で EKS のような体験を実現したい場合に最適。 ・EKS Distro（EKS-D） をベースにした Kubernetes ディストリビューション ・オンプレミスやエッジ環境 に Kubernetes クラスターを構築可能 ・セルフマネージド型：ユーザーがクラスターのライフサイクル（作成・アップグレード・スケーリングなど）を管理 ・AWS サポートあり：EKS Anywhere のコンポーネントは AWS によるサポート対象
Pod Identity	Kubernetes 上の Pod に対して IAM ロールを直接割り当てる方法。従来の IRSA（IAM Roles for Service Accounts）に代わる、よりシンプルでスケーラブルな仕組み。 ●EKS Pod Identity エージェント：Pod Identityの利用を夕刻するために本エージェントのインストールが必要。

[EKSをOutposts にデプロイ]

●拡張クラスター

Outpost の AWS リージョンとノードで Kubernetes コントロールプレーンを実行する。

●ローカルクラスター

Outpost で Kubernetes コントロールプレーンとノードを実行する。

ECS

●Task：コンテナ
●Cluster：EC2インスタンス
●Task Definication：Cluster上のタスクを定義する

[一例]
「6つのEC2インスタンスに対して、コンテナを実行する。コンテナは3つのAZに分散させて、同時に10個実行して、ロードバランサ―につなぐ」という指示

●awslogsログドライバー

タスクのコンテナを設定してCloudWatch Logsにログ情報を送信できる。タスクでFargate起動タイプを使用すると、コンテナからログを表示できる。EC2起動タイプを使用すると、コンテナからの異なるログを1か所に便利に表示できる。また、コンテナインスタンスのディスク容量をコンテナログが占有してしまうことも防止できる。

[公式引用サイト]

[代表的なコマンド]

・Pull コマンド
【イメージをローカルに】
Amazon ECR で利用可能な Docker イメージを実行する場合、docker pull コマンドを使用してローカル環境にプルする。
これはデフォルトのレジストリまたは他の AWS アカウントに関連付けられたレジストリから行うことができる。

ECR

・AWS CLIでECRにログインする時はget-loginではなくget-login-passwordを使うこと

●プルスルーキャッシュ

パブリックな一メージを一度キャッシュした後、後続の取得をVPC内部から可能にする。クラスターインスタンスの直接的なインターネット接続を廃止した状態でも、最新のイメージを取得できる。なお、事前に各イメージを最低一回取得することでキャッシュの初期かが行われるため、VPCのインターネット接続削除前にイメージの取得を行うことが必須である。

コンテナイメージ

ECSを利用する際はコンテナイメージを ECRに配置することが必要。
コンテナイメージはHTTPS経由で転送され、保管時には自動的に暗号化される。

パブリックレジストリ	高可用性でスケーラブルなアーキテクチャ。コンテナイメージをホストし、アプリケーションにコンテナを確実にデプロイする。Docker イメージと Open Container Initiative (OCI) イメージで構成されるパブリック イメージ リポジトリを管理できる。
プライベートレジストリ	高可用性でスケーラブルなアーキテクチャでコンテナイメージをホストする。Docker イメージ、Open Container Initiative (OCI) イメージ、アーティファクトで構成されるプライベートイメージリポジトリを管理。

ポリシー

リポジトリポリシー	個別の Amazon ECR リポジトリへのアクセスを制御することを目的として特に使用される IAM ポリシーのサブセット。
ライフサイクルポリシー	プライベートリポジトリごとに設定が可能。適用されたリポジトリ内で、指定した有効期限の基準を満たしたイメージを自動的に削除する。

スキャンタイプ

ECR（Elastic Container Registry）に保存されたコンテナイメージに対して実行できる

[スキャン対象と検出内容]

• OSレイヤーの脆弱性（基本スキャン・拡張スキャン）
• アプリケーションレイヤーの脆弱性（拡張スキャンのみ）

[スキャンのタイミング]

• イメージの登録時（基本スキャン）
• イメージのプッシュ時（拡張スキャン）
• 任意のタイミング（手動スキャン）

[スキャンタイプ]

スキャンタイプ	特徴	使用ツール・サービス
基本スキャン	イメージの登録時に自動実行。OSパッケージの脆弱性を検出。	Amazon Inspector
拡張スキャン	OSパッケージに加え、アプリケーションの脆弱性も検出。イベント駆動型で柔軟なスキャンが可能。	Amazon Inspector + EventBridge
手動スキャン	任意のタイミングでスキャンを実行可能。	AWS CLI または API

Transfer Family

・AD連携やカスタム認証にも対応しており、セキュリティ面も柔軟
・エンドユーザーのクライアントと設定をそのまま維持しながら、ファイル転送ベースのワークフローを AWS に移行できる。

基本構成

サーバーエンドポイントの作成	SFTP/FTP/FTPS/AS2 のいずれかのプロトコルを選択 パブリック or VPC 内のエンドポイントを選べる
ユーザー管理の設定	サービスマネージド（Transfer Family内で管理） AWS Directory Service（AD連携） カスタムIDプロバイダー（Lambda/API Gateway）
ストレージの指定	Amazon S3 または Amazon EFS を転送先として設定
認証方式の選択	SSHキー認証（SFTP） パスワード認証（FTP/FTPS） SAML連携（Okta, Azure AD など）

[設定方法]
最初にホスト名をサーバーエンドポイントに関連付けてから、ユーザーを追加。
適切なアクセスレベルをプロビジョニングする。
これにより、ユーザーの転送リクエストが Transfer Family サーバーエンドポイントから直接提供される。

●マネージドワークフロー

ファイル処理用のマネージドワークフローをサポートする。管理されたワークフローを使用すれば、SFTP、FTPS、またはFTPでファイルが転送された後に、ワークフローを開始することができる。ファイル処理タスクをオーケストレーションすることで、ダウンストリームのアプリケーションで消費される前にデータを前処理するのに役立つ。

[静的IPとしての機能]
インターネット経由でアクセス可能な仮想プライベートクラウド（VPC）エンドポイントとして機能する。このため、既存のElastic IP アドレスをエンドポイントとして利用できる。

[サポートされている転送プロトコル]

• Secure Shell (SSH) File Transfer Protocol (SFTP): バージョン 3
• File Transfer Protocol Secure (FTPS)
• File Transfer Protocol (FTP)
• 適用性ステートメント 2 (AS2)

Cloud Front

・コンテンツを保持するためのバックエンドサーバ(ELB , EC2 , S3の静的ホスティングを利用できる)。
・ディストリビューションはドメインを指定する(IP不可)。静的なIPアドレスを持たない。
・ディストリビューションを使用する方法はDNS名の提供を前提とする。

ストリーミング	RTMP(Real Time Messaging Protocol)を使って動画のストリーミング配信をする。動画のストリーミングはプログレッシブオプションに設定されたダウンロードオプションを利用。
プリンシパル	AWS リソースに対するアクションをリクエストできる、 IAM ユーザ、ロール、フェデレーションユーザ、またはアプリケーション。
ビューワーリクエスト	CloudFrontを参照するリクエスト。
キャッシュミス	リクエストされたオブジェクトがエッジロケーションでキャッシュされないこと。

[キャッシュについて]
同じコンテンツファイルが更新された場合、キャッシュの有効期限が切れない限り最新のファイルを提供しない。エッジキャッシュからファイルを無効にすることで最新ファイルの入手ができる。

※キャッシュ保持期間制御
・Cache-Control：max-age
オリジンのオブジェクトに追加することで、キャッシュに保持される期間を制御できる。これによって個々のページに対するTTLを設定できる。

[ダウンロード方法]
HTTP,HTTPSを使ってHTMLやCSS、画像などのデータを配信する。

ディストリビューション

(1つのオリジンに対して）コンテンツデリバリーの設定や構成などの配布形態を意味する。CloudFrontディストリビューションではフェールオーバーオプションが提供される。プライベートIPアドレスはもっていない。
※セキュリティソフトウェアのパッチは静的ファイルであるため、本機能を利用してキャッシュできる

●地理的ディストリビューション

【制限 機能】
ある国(地域)からのアクセスに対して 403 (アクセス拒否) のレスポンスを返すことが可能。

オリジン

●オリジンサーバ

コンテンツを配信する元となるサーバー。エッジロケーションに保存。
ターゲットグループを指定することはできない。

オリジンリクエスト	CloudFrontがオブジェクトを取得するためのリクエストをオリジンに送信する。
オリジンフェイルオーバー	【ディストリビューションの冗長化】 プライマリオリジンが使用できない場合、または障害を示す特定の HTTP レスポンスステータスコードを返す場合、CloudFront は自動的にセカンダリオリジンに切り替わる。 ・開始するには、プライマリとセカンダリの 2 つのオリジンを持つオリジングループを作成する。 ・少なくとも 2 つのオリジンを持つディストリビューションが必要。

ヘッダー

●カスタムヘッダー

オリジンに送信するリクエストにカスタムヘッダーを追加できる。
CloudFront がカスタムオリジンからファイルを取得するには、標準の HTTP (または HTTPS) リクエストを使用してCloudFront からファイルにアクセスできる必要がある。しかし、カスタムヘッダーを使用することで、コンテンツへのアクセスをさらに制限して、CloudFront を経由しないアクセスを防げる。

以下設定を変更する。

●ビューワープロトコルポリシー

【HTTP】
(CloudFront経由で)CloudFront エッジロケーションのコンテンツへのアクセスに使用するビューワーのプロトコルポリシー。ビューワーから CloudFront へのアクセス時に HTTPS の使用が求められるようにディストリビューションを設定。

HTTP and HTTPS	HTTPとHTTPS。ビューワーは両方のプロトコルを使用可能。
Redirect HTTP to HTTPS	HTTP を HTTPS にリダイレクト。ビューワーは両方のプロトコルを使用できるが、HTTP リクエストは自動的に HTTPS リクエストにリダイレクトされる。
HTTPS Only	HTTPSのみ。ビューワーは HTTPS を使用している場合にのみコンテンツにアクセス可能。

●オリジンプロトコルポリシー

【プロトコル】
CloudFront がリクエストをオリジンに転送する際にビューワーと同じプロトコルの使用が求められるように、ディストリビューションを設定。

HTTPS Only	HTTPSのみ。CloudFront は HTTPS のみを使ってカスタムオリジンと通信する。
Match Viewer	ビューワーに合わせる。ビューワーのリクエストのプロトコルに応じて HTTP または HTTPS を使用し、カスタムオリジンと通信する。

[参考]

[その他ヘッダー]

ホワイトリストヘッダー 【認証】	リクエストをオリジンに転送するときに、認証ヘッダーを含む一部のヘッダーを削除する。特定のキャッシュ動作のために常に認証ヘッダーを転送する場合は、必ずそのキャッシュ動作のヘッダーをホワイトリストに登録する。
User-Agent ヘッダー	クライアント側のOS・ハードウェア・ブラウザ情報などが含まれたHTTPヘッダー。Webサーバ側は受け取ったUser-Agent ヘッダーの情報をもとに最適なレスポンスを返す。
Cache-Controlヘッダー	HTTPヘッダーの一つ。ブラウザがオブジェクトをキャッシュするかどうか、またどのようにキャッシュするか制御する。「max-age=0」を指定するとブラウザは常に最新のオブジェクトを取得する。
Hostヘッダー	リクエストが送信される先のサーバーのホスト名とポート番号を指定するためのヘッダ情報。
Authorizationヘッダー	認証部分。

トリガー

オリジン応答イベント	オリジンからのレスポンスを CloudFront に返す前にトリガーされるイベント。
ビューワー応答イベント	Cloud Front がキャッシュされたコンテンツをユーザーに返す目にトリガーされるイベント。

取得設定

（Allowed HTTP Methods）
CloudFront経由でコンテンツを操作する際にHTTP メソッドを指定。許可するHTTPメソッド多くの場合は[GET,HEAD]を設定。WEBDAVなどデータをアップする際などは[GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE]CloudFront が処理してオリジンに転送する HTTP メソッドを指定する。

[GET, HEAD]	CloudFront を使用して、オリジンからのオブジェクトの取得またはオブジェクトヘッダーの取得のみを行うことができます。
[GET, HEAD, OPTIONS]	CloudFront を使用して、オリジンからのオブジェクトの取得、オブジェクトヘッダーの取得、またはオリジンサーバーがサポートするオプションのリスト取得のみを行うことができます。
[GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE]	CloudFront を使用して、オブジェクトの取得、追加、更新、削除、およびオブジェクトヘッダーの取得を行うことができる。また、ウェブフォームからのデータの送信など、その他の POST 操作も実行できる。

暗号化設定

（Field Level Encryption）
フィールドレベル暗号化を使用した機密データの保護を実施したい場合に設定。
Allow HTTP Methodsを「GET,HEAD,OPTIONS,PUT,POST,PATCH,DELETE」を選択した場合に設定可能。

●フィールドレベルの暗号化

【特定のデータ保護】
セキュリティのレイヤーが追加され、システムの処理中に特定のデータに特定のアプリケーションのみがアクセスできるように、そのデータを保護できる。ユーザーは機密情報をWebサーバーに安全にアップロードできる。

その他機能

署名付きURL	一定時間だけアクセスを許可 （※オブジェクトのアップロードに利用できる）
OAI	【オブジェクトのアクセス権】(オリジンアクセスアイデンティティ) オブジェクトのアクセス権の許可を付与する。S3で機能する。
OAC	(オリジンアクセスコントロール) OAIより詳細にアクセス権を制御できる。特定のオリジン（EC2,ELB,S3バケットなど）へのアクセスを制限する。
CloudFront Functions	簡単なリクエストの操作やレスポンスのヘッダー操作に最適。 ※複雑な寄りは不得意 【比較点】 ・CloudFront Functions リクエストの前処理に特化した軽量な関数であり、認証トークンの検証のような単純なロジックを実行する場合に最適。 ・Lambda@Edge より複雑な処理を実行できるが、リージョンの冗長性、コールドスタートの影響、およびデプロイの管理負荷が発生する。
Lambda@Edge	【CloudFrontでLambda】 CloudFrontの機能の1つ。Lambdaの拡張機能（CloudFrontのエッジロケーション上でLambdaを実行するサービス） CloudFrontのエッジサーバでCroudFrontが配信するコンテンツをカスタマイズする関数を（Lambdaで定義した）コード実行できる。 主にリクエストやレスポンスに対するカスタムロジックを実行するために使用される。アプリケーションのユーザーに近いロケーションでコードを実行する。 ・CloudFrontのイベントをトリガーとしてコードを実行する。 ・リクエストに対して自動的にスケーリングできる。 ・関数を使用してクエリパラメータの正規化や順序付けを行える。 ・ユーザーに近い場所でコードが実行されることで処理の待ち時間が短縮される。（キャッシュ機能ではない）
アクセスログ （標準ログ）	ウェブサイトのコンテンツに流れるトラフィックに対してログファイルを作成できる。格納先をS3に指定することができる。

連携サービス

WAF	WAF はウェブACL でディストリビューションに対して、ウェブリクエストの検査と管理ができる。これによりセキュリティ性の高さを確保できる。 [参考サイト]

貸し出しサービス

Outposts

・オンプレミスのインフラストラクチャの調達、管理、アップグレードのために必要な、差別化につながらない面倒な作業を取り除く。

[以下環境を提供]

• フルマネージド型AWS インフラストラクチャ
• ネイティブな AWS サービス
• API、ツール
• オンプレミス施設

●Outpostsラック

42U(42段分)のAWSラックを自社データセンターなどのオンプレミス環境に設置して利用するサービス。
利用開始時には、完全に組み立てられたOutpostsラックが配送され、設置作業はAWS側で行うため、ユーザーは電源とネットワークに接続するだけで使用できる。通常のクラウドのAWSと全く同じスペックのラックであり、AWSサービス、APIなどAWS リージョンで利用可能な幅広いサービスに接続できる。Outpostsサーバーよりも電力を多く消費する。
※ラックのサイズ：高さ80インチ（203.2cm）・幅24インチ（60.96cm）・奥行き48インチ（121.92cm）

●Outpostsサーバー

1台のAWSサーバーをオンプレミス環境に設置して利用するサービス。1Uサーバーか2Uサーバー、どちらかを選んで利用できる。Outpostsサーバーが直接配送され、自社データセンターの現場担当者か、設置委託会社のいずれかの設置が必要になる。ネットワークに接続した時点で、AWSがコンピューティングリソースとストレージリソースが構築される。Outpostsラックよりも必要とする電力は小さい分、利用できるAWSサービスにも限りがある。

※1Uサーバー：幅19インチ（48.26cm）・奥行き24インチ（60.96cm）・高さ1U
　2Uサーバー：幅19インチ（48.26cm）・奥行き30インチ（76.2cm）・高さ2U

Local Zones

・提供形態：ユーザーが使うのは仮想リソース（EC2、EBSなど）
・物理機器の管理：AWSが全て管理・運用
・利用者視点：通常のリージョンと同じように使える

[特徴とメリット]

特徴	説明
低レイテンシー	地理的に近いため、1桁ミリ秒の応答が可能
データレジデンシー対応	規制や契約上、データを特定地域に保持したい場合に有効
簡単な導入	AWSマネジメントコンソールから有効化・利用可能
親リージョンと連携	管理プレーンは親リージョンに依存し、操作は一貫性あり

WorkSpaces Family

あらゆるユースケースに対応して、セキュリティ性、柔軟、そして費用対効果の高い仮想デスクトップサービス。

WorkSpaces

【KVM提供】
ユーザー向けの仮想クラウドベースのMicrosoft Windows、Amazon Linux、Ubuntu Linuxデスクトップを提供。

・ハードウェアの調達とデプロイ、または複雑なソフトウェアのインストールの必要性を排除。
・必要に応じてユーザーを素早く追加または削除できる。
・リージョン単位で「ディレクトリ」を管理している。

・複数デバイスやWebブラウザから仮想デスクトップにアクセスでき、セキュリティ管理が容易。
・OSやソフトウェアの自動更新機能があり、常に最新の状態で仮想デスクトップ環境を維持。

●IPアクセスコントロールグループ

特定のIPアドレス範囲からのアクセスを許可または拒否する。

●WorkSpaces Personal

デベロッパーやナレッジワーカー、それにアプリケーションをインストールしたり、ファイルやデータを保存したり、デスクトップに設定を保存したりする必要のあるその他のユーザー向けに、永続的な仮想デスクトップを提供して、パーソナライズされたデスクトップエクスペリエンスをもたらす。 ユーザーはサインインするたびに同じ仮想デスクトップにアクセスする。

●WorkSpaces Pools

デスクトップにファイル、データ、設定を保存する必要のないタスクワーカーやコンタクトセンターの従業員などのユーザー向けに、非永続的な仮想デスクトップを提供。ユーザーはサインインのたびに新しい仮想デスクトップにアクセスできる。
管理者は、一部のユーザー設定、ブックマーク、ファイルを S3 や FSx などの中央ストレージリポジトリに保存して、ユーザーが新しいセッションを開始したときにアクセスできるようにすることができる。

●クロスリージョンリダイレクト機能

完全修飾ドメイン名（FQDN）をWorkSpaces の登録コードとして使用できる。DNS ルーティングポリシーと連携して、プライマリ WorkSpaces が利用できない場合に WorkSpaces ユーザーを別の WorkSpaces にリダイレクトする。
使用するにあたり、
・複数のAWSリージョンでユーザーのWorkSpacesを設定する
・接続エイリアスと呼ばれる特別なFQDNベースの登録コードを作成する

WorkSpaces Core

サードパーティのVDIソフトウェア向けの仮想デスクトップインフラAPI。

WorkSpaces Secure Browser

社内WebサイトやSaaSアプリにアクセスするための安全で低コストのブラウザサービス。
※旧名：WorkSpaces Web

通常のWorkSpacesとは異なり、自分で仮想マシンイメージを作ることはせず、AWSが用意したWEBブラウザ(Chrome)入りのイメージを利用する。そして利用者のクライアント環境のWEBブラウザからイメージ内部のWEBブラウザを使いユーザー企業内イントラサイトなどのリソースへアクセスする仕組み。また、ユーザー認証にAcitive Direcotryを使わず外部のIdP(AWS SSO,Azure AD,Okta 等)でSAML認証が必須となっています。

App Stream(2.0)

・ユーザーはサポートされているデバイスから、いつでもどこでも、必要なデータ、アプリケーション、およびデスクトップ・リソースに安全にアクセスできる。

・デスクトップアプリケーションを集中管理し、任意のコンピュータのブラウザへ安全に配信できる。
・各ストリーミングセッションはネットワーク状態に合わせて自動で調整される。

※ユーザープールでユーザーを作成および管理できる

●Image Builder

EC2 インスタンスをベースに構成されており、ストリーミングしたいアプリケーションと必要な設定を含むカスタムイメージを独自に作成できる。オリジナルアプリケーションの移行にも利用できる。

付帯コンテンツ機能

CloudSearch

【検索機能付与】

AWSクラウドにおけるマネージド型サービス。ウェブサイトまたはアプリケーション向けの検索ソリューションを容易かつコスト効率よく設定、管理、スケールできる。

・34言語をサポートし、ハイライト表示、自動入力、地理空間検索などの検索機能を備えている。

Elastic Transcoder

▲2025 年 11 月 13 日にサービス終了。以降は AWS Elemental MediaConvert

【ソース形式変更】クラウドのメディア変換サービス。

・高度なスケーラビリティ、使いやすさ、高い費用効率性を実現する設計。
・メディアファイルをその元のソース形式からスマートフォン、タブレット、PC などのデバイスで再生可能できるバージョンに変換 (または「トランスコード」) できる。

Amazon Connect

【カスタマーサービス】セルフサービスのクラウド型コンタクトセンター。
あらゆるビジネスが簡単に低コストでより良いカスタマーサービスを提供できるようにする。
（※カスタマーエクスペリエンスの向上を図るため、AWS AIサービスを利用できる）
エージェント端末を使用して利用することができる。

・グラフィカルインターフェイスで、対応フローの設計、スタッフの管理、業務指標の追跡が簡単にできる。
・インテリジェントな会話ボット Lexを対応フローに組み入れることで、自動応答が自然な会話に変化する。

※世界中のスタッフが日々百万件ものお問い合わせに対応するアマゾンのコンタクトセンターと同じ技術が使われている。

エージェント	エージェントはブラウザとヘッドセットがあれば電話対応可能。 Amazon Connect 問い合わせコントロールパネル (CCP) を使用して問い合わせと通信する。ただし、エージェントが CCP にアクセスし、問い合わせを処理できるようになる前に、行わなければならない操作がいくつかある。
フラグ	フラグコールボタンを追加することで使用できる。トリガーのような役割をもつ。
Contact Control Panel (CCP)	インストール不要のエージェントインターフェイス（ブラウザからURLアクセス）

[引用元サイト：Blackbelt]

IVS(Interactive Video Service)

【ライブストリーミング】
世界中の視聴者が低レイテンシーまたはリアルタイムの動画を利用できるようにするマネージド型ライブストリーミングソリューション。これにより、魅力的なライブ体験を実現できる。

・Twitchを支えるネットワークとインフラ
・累計一年間1.35兆分ものライブ動画再生
・低遅延（2～5秒）のHLSストリーミング
・超低遅延（300ms）のWebRTCのストリーミング
・ストリームチャット（WebSocket）

開発基礎知識

まず、開発の一般的な流れは、「Commit → Build → Test → Deploy」

Commit	・変更をCommitする ・複数の変更を統合する ・変更の履歴を統合する
Build	・成果物をBuildする ・複数の成果物の依存関係を解決する ・(Docker)イメージを作る
Test	・成果物の単体テスト実行 ・成果物の結合テスト実行 ・テスト結果を出力
Deploy	・成果物を開発環境に反映 ・成果物を本番環境に反映

●Web Hook

「イベント駆動型のHTTP通知機能」。あるサービスで特定のイベントが発生したとき、事前に指定されたURLへ自動的にHTTPリクエスト（通常はPOST）を送信する。この機能によってイベントを起点としたプログラムをHTTP通信で実行できるため、ポーリングやメッセージングシステムの利用は不要。

CLI

※AWS操作は主にAWSマネジメントコンソールとAWS CLIを利用

コマンド

start-build	使用してビルド仕様(buildspec)をオーバーライドできる。
aws configure	AWS CLI のインストールをセットアップするための最も簡単な方法。このコマンドを入力すると、AWS CLI によって 4 つの情報の入力が求められる。 ・アクセスキー ID ・シークレットアクセスキー ・AWS リージョン ・出力形式

SDK

※特定のプラットフォーム、オペレーティングシステム、またはプログラミング言語で実行されるコードを作成するには、デバッガー、コンパイラー、ライブラリなどのコンポーネントが必要。

・「AWS SDK」と「AWS CLI」はIAMロールから一時的なセキュリティ認証情報を自動取得できる。

特定のソフトウェア、プラットフォーム、ハードウェア、またはオペレーティングシステム向けのアプリケーションを構築するために必要な、ツールやライブラリ、ドキュメントなどをまとめたパッケージです。

ウェブアプリケーションがAPI Gatewayと連携するために必要なコード（JavaScript SDK）が含まれていれば、SDKを使うことで、開発者はAPIへの接続やデータのやり取りといった複雑な処理をゼロから書く必要がなくなり、効率的に開発を進めることができる。

例えるなら、組み立て式の家具を買ったときに付いてくる、ネジや六角レンチ、そして説明書がすべて入ったセットのようなもの。SDKがなければ、必要なツールや部品をすべて自分で見つけ出して揃えなければならないため、開発が非常に困難になる。

Data Pipeline

・データの取り出し・変換・保存など順次処理が可能。
（※オンプレミス環境からのデータ転送にはDataSyncを利用）

[スケジュールされたパイプライン]

パイプラインコンポーネント	【 データ管理のルールを定義】 ・パイプラインのビジネスロジックを表し、パイプライン定義のさまざまなセクションによって表される。 ・ワークフローのデータソース、アクティビティ、スケジュール、および前提条件を指定する。 ・これらは親コンポーネントからプロパティを継承でき、コンポーネント間の関係は参照によって定義される。
インスタンス	各インスタンスには、特定のタスクを実行するためのすべての情報が含まれている。 ・パイプラインを実行するときに、パイプラインコンポーネントをコンパイルして、一連のアクション可能なインスタンスを作成する。 ・完全なインスタンスのセットは、パイプラインの To-Do リスト。Task Runner に処理するインスタンスを渡す。
試行	堅牢なデータ管理を提供するために、失敗したオペレーションを再試行する。 (※この処理は、タスクが最大許容再試行回数に到達するまで続行される) ・試行オブジェクトは、さまざまな試行、結果、および失敗の理由（該当する場合）を追跡する。 ・基本的に、試行はカウンター付きのインスタンス。Amazon EMR クラスターや EC2 インスタンスなど、以前の試行と同じリソースを使用して再試行を行う。

Code Star

事前設定された継続的デリバリーツールチェーンを提供することでアプリケーションの提供を迅速化。

機能性

継続的デリバリー	ソフトウェア開発手法の一つ。コード変更が発生すると、自動的に実稼働環境へのリリース準備が実行される。アプリケーションのアップデートを素早く反映できる。
ツールチェーン	ある目的を達成するために組み合わせて使用する一連のツール(道具)のセット。
継続的デプロイメント 【開発アクティビティ管理】	CI/CD パイプラインでのコードのコミット、ビルド、テスト、デプロイなどのアクティビティを一元的に管理し、表示。 ・アプリケーションのビルドが正常に完了すると全て成功と表示 デプロイの進行状況やコミットの履歴なども同時に確認が可能。 ※ステージの追加、編集を行いたい場合には「Code Pipelineの詳細」を選択する。
チームwiki	内容をカスタマイズしてチームノートに保存したり、プロジェクトにリンクさせる、コードサンプル、チームメモなどのチーム情報の提供が容易。
アプリケーションアクティビティの監視と JIRA の問題管理	アプリケーション監視サービスであるCloudWatchやプロジェクト管理ツールであるAtlassian JIRA Softwareなどと統合することで、アプリケーションやJIRAの問題の監視、追跡、管理が可能。
アプリケーションエンドポイント	エンドポイントのリンクが表示。アプリケーションまたはサービスを表示するにはリンクを選択。
コミット履歴	リポジトリの最近のコミット履歴が表示。 コミットやリポジトリに関する全てのコミットや詳細を表示したい場合は… →コードがCodeCommitに保存されている　⇒　CodeCommitの詳細 →コードがGitHubに保存されている　⇒　GitHubで開く
アプリケーションアクティビティ	プロジェクトのAmazon CloudWatchメトリクスが表示。例えば、Code DeployリソースによってデプロイされたAmazon EC2のCPU使用率や、AWS Lambdaを使用すればLambda関数の呼び出しとエラーのメトリクスが表示され、情報は時間単位で表示される。

作成要素

プロジェクトテンプレート	・EC2、Lambda、Elastic Beanstalk にデプロイするアプリケーションの開発をすばやく開始する助けになり、複数用意されている。 ・Java、JavaScript、Python、Ruby、PHP などの多くのプログラミング言語をサポート
自動化された継続的デリバリーパイプライン	CodePipelineと連携して、コードのビルド、テスト、デプロイが自動化された事前設定済みのパイプラインがプロジェクトごとに設定（継続的デリバリー）されている。
自動化されたデプロイ	CodeDeployやCloudFormationと統合することで、アプリケーションコードを簡単に更新し、EC2やLambdaにデプロイすることができる。

管理要素

チームのアクセス管理	・IAM によって開発者のアイデンティティ管理を実施。 ・アクセス管理は、「所有者 / コントリビューター/ ビューワー」などのさまざまなロールに対応する、簡単な組み込みのセキュリティポリシーにより、プロジェクトへのアクセスを簡単に保護する。
ホスト型の Git リポジトリ (Code Commitで安全管理)	・CodeStarでのアプリケーションコードはCodeCommit に保存。 ※独自の GitHub リポジトリにプロジェクトのソースコードを保存できる。 ・Git リポジトリをホストするために独自のインフラストラクチャを管理する必要がなくなる。
一元化されたプロジェクトダッシュボード	一元的にアプリケーションアクティビティの監視と、最近のコードのコミット、ビルド、デプロイなどの日常的な開発タスク全体の管理を容易に行える。
完全マネージド型ビルドサービス	CodeBuild を使用することで、コードのビルド、テスト、統合をより頻繁に実行できるよう になり、ソースコードのコンパイルとパッケージ化を行える。

Code Pipeline

●アーティファクトストア

パイプライン内で生成・受け渡しされる成果物（アーティファクト）を保存するための Amazon S3 バケットのこと。

[役割]
・アーティファクトとは？
ソースコード、ビルド成果物、テストレポート、デプロイパッケージなど、各ステージで生成されるファイル群。
・保存場所
CodePipeline は、これらのアーティファクトを S3 バケットに保存し、次のステージに受け渡す。
・一元管理と履歴保持：
アーティファクトストアに保存することで、成果物の履歴を追跡でき、トラブルシューティングや再デプロイに役立ちます。

[CI/CD]
実装 > テスト > デプロイ・リリース のフローを可能な限り自動化する（Code＞Build＞Test＞Deploy）

性能特徴

パイプライン 【一連の処理の流れ】	ソフトウェアの変更がリリースプロセスをどのように通過するかを記述するワークフロー構造。各パイプラインは一連のステージで構成。 (※CloudFormationテンプレートのデプロイ、テストに利用できる。） (※パイプライン内の処理を定義するにはUIから手動で行うか、CloudformationでStackを定義して行う形になる)
ステージ 【処理を実行する環境の単位】	各ステージのアプリケーションアーティファクトに対して実行される複数アクションが含まれる。 (※各ステージ毎にコンテナを立ち上げて処理するイメージ) 各ステージは、連続または並列のアクションで構成されている。環境を分離し、その環境での同時変更の数を制限するために使用できる論理ユニット。
アクション 【実際に行われる処理の単位】	ソースコードを取ってきたり、テストしたり、デプロイしたりする。 アクションには[source / build / test / deploy / approval] というタイプがある。 パイプラインのステージに承認アクションを追加した箇所でパイプラインを停止することで、このアクションを主導で承認または拒否できる。

[※参考サイト]

[承認アクション]

[承認アクションの概要]

• 承認アクションを使うことで、パイプラインの特定ステージにおいて手動承認を要求できる。
• 承認アクションは、CodePipeline のステージに承認アクションを追加した箇所でパイプラインを停止することで、このアクションを手動で承認または拒否できる。アクションが追加されると、承認が完了するまで次のステージに進まない。
• IAM（AWS Identity and Access Management）アクセス許可が必要。

[承認が必要になるタイミング]
・パイプラインの進行を一時停止し、指定されたユーザーの承認を待つ。
・承認が拒否された場合、パイプラインは失敗として扱われる。

[有効なユースケース]

ユースケース	説明
コードレビュー	ステージ進行前にコードの内容を確認・承認する必要がある場合
リリース承認	本番環境へのデプロイ前にリリース責任者の承認が必要な場合
テスト結果の確認	自動テスト後に結果を人が確認してから次のステージへ進めたい場合

カスタムアクション

企業独自のリリースフローや検証ステップをCodePipelineへ柔軟に統合可能にできる。

・CodePipelineは標準でビルド・テスト・デプロイなどの複数のアクションを提供する。
・標準アクションに含まれていない独自のビルドプロセスやテストスイートを統合する場合に、カスタムアクションが有効。

[実装方法]
①AWS CLIを使用して、パイプラインにカスタムアクションを作成・追加。
②作成されたカスタムアクションは、AWSアカウントに関連づけられたパイプラインに組み込まれる。

属性

属性名	説明
パイプライン名	パイプラインの一意な識別名。
ステージ	ソース、ビルド、テスト、デプロイなどの処理単位。最低2つ必要（ソース＋ビルドまたはデプロイ）。
アクション	各ステージ内で実行される具体的な処理（例：CodeBuild、CodeDeploy、承認など）。
アーティファクト	ステージ間で受け渡される成果物（ZIPファイルやイメージなど）。S3に保存される。
トリガー	パイプラインの起動契機。EventBridge、Webhook、ポーリングなどが利用可能。
IAMロール	CodePipeline が他の AWS サービスにアクセスするための権限。
暗号化キー	アーティファクトの暗号化に使用される AWS KMS キー。
アーティファクトストア	アーティファクトを保存する S3 バケットの場所。
RunOrder	同一ステージ内でのアクションの実行順序。並列実行も可能。 ・デフォルト値は 1。 1以上の自然数のみ使用可能（0、負の数、分数などは無効）。 〇シリアル実行：アクションを順に実行するには、順番に大きい数値を割り当てる。 例：アクションA＝1、アクションB＝2、アクションC＝3。 〇並列実行：同じ runOrder 値を使うことで、同じステージ内の複数アクションを同時に実行可能。 例：アクションA＝1、アクションB＆C＝2 → BとCは同時に開始。
変数	パイプラインレベルで定義できるカスタム変数。V2 パイプラインで利用可能。

Code Artifact

構造

（ドメイン＞リポジトリ＞アセット）

ドメイン	CodeArtifact の最上位のエンティティ。ドメイン配下に複数のリポジトリを持つことが出来る。
リポジトリ	各アセットのバージョンセットが保存される。1 つのリポジトリにはサポートされる全てのタイプのパッケージのエンドポイントを提供。
アセット	ドメイン内のアセット (パッケージ) は KMS の暗号化キーで暗号化される。すべてのアセットとメタデータはドメインに保存される為、複数のリポジトリに同じアセットが存在する場合、アセットはドメインに 1 つだけ保存される。

機能性

パッケージ化したものを配布	PyPI（Python Package Index）, pip, npm, mavenなど
パッケージ管理	※ソフトウェア＝ソフトウェアパッケージ ・更新やサーバーの管理は不要。 ・ソフトウェアと依存関係をパブリックなアーティファクトリポジトリから自動的にフェッチできるため、デベロッパーに最新バージョンを提供できる。 ・管理者はソフトウェアを承認し、組織全体への配布を制御できる。 ・数回クリックするだけで、中央リポジトリをセットアップできる。 ・IAM をサポートしており、IT リーダーは AWS アカウント全体のさまざまなチームに適切なレベルのアクセス権を付与できる。

[オペレーションのオーバーヘッドを削減する]

・アーティファクトリポジトリの管理に、必要なインフラストラクチャをセットアップして運用する必要がない。

・一般的に使用されるパッケージマネージャーや各種のビルドツール (Maven、Gradle、npm、yarn、twine、pip、NuGet) で動作するため、既存の開発ワークフローに簡単に統合できる。

Code Commit

・AWS特有の完全マネージド型サービスなため、Gitをホスティングするサーバの構築は不要。
・CodeCommit リポジトリのトリガーを作成して、リポジトリのイベントから Lambda 関数を呼び出すことができる。

リポジトリ	ソースコードや構成ファイルなどのバージョン管理を行う中心的な場所。
機能ブランチ	別のパイプラインを作成し、テストされたコードを本番環境にマージする機能を支援する。
Git	ソースコードや設計書等のドキュメントの変更履歴を記録して管理する、オープンソースの分散型バージョン管理システム（対象ユーザは、主にソフトウェア開発者）
feature ブランチ	主要な機能を実装するためのブランチ。機能の実装やバグフィックスなど、タスクごとにfeature ブランチを作成し、作業を行う。

[仕様]
・共同でのソフトウェア開発向けに設計されている。
・複数のファイルにわたる変更を一括管理でき、並行分岐化、（S3のみ）バージョン比較（diffing）を利用できる。
・コードのアップロード、履歴の確認,ソースのプレビュー、ブラウザ上での編集、プルリクエスト、ブラウザ上でレビューコメント、承認ルールの設定が可能。

[セキュア性]
・CodeCommitにアクセスする際にAWSのユーザーIDとPWが求められる。
・CodeCommit リポジトリ内のデータは、転送中と不使用時のいずれも暗号化される。
・クラウド内のアセット（ドキュメント、ソースコード、バイナリファイルなど）を非公開で保存及び管理できる。

管理ポリシー

[ポリシーの目的]
特定のブランチ（例：master）に対して変更を拒否するためのDenyポリシーの設定方法を紹介。

[操作手順の概要]
・MyDemoRepoという名前のリポジトリを例に、masterブランチへのPushを拒否するポリシーを作成。
・AWS CodeCommitのコンソール画面から設定を行う流れが示されている。

[ポリシーの効果]
指定ブランチに対する意図しない変更やPushを防止でき、リポジトリの安定性・セキュリティを維持可能。

Code Build

[順序]
①ソースコードの編集とアップロード（CodeCommitにプッシュ）
②buildspec.ymlファイルの作成とアップ（CodeCommitにプッシュ）
③ビルドプロジェクトを作成（CodeBuild上で作成）
④ビルドを開始する（CodeBuild）

[CodeBuild へアクセスする際は認証情報が必要]
・Amazon S3：ビルドアーティファクトの保存と取得
・Amazon CloudWatch Logs：ビルドのログ表示

●BuildSpecファイル

yaml形式で記述されたAWS CodeBuildの設定ファイル。ここで記述された設定がAWS CodeBuildによってビルドされる。この設定ファイルの問題を確認するには、AWS CodeBuildビルドをローカルで実行する。ローカルで実行することで、BuildSpecファイルで記述した設定がどのようにビルドされるかローカル環境でテストすることができる。これにより、BuildSpecファイルにおける問題をローカル環境で確認することができる。

●ビルドバッジ

プロジェクトの最新のビルドのステータスを表示する。このイメージにアクセスするには、CodeBuild プロジェクトに対して生成されるパブリックアクセス可能な URL を使用する。そのため、誰でも CodeBuild プロジェクトのステータスを確認できる。ビルドバッジにはセキュリティ情報が含まれないため、認証は不要です。

プロパティ

on-failure	フェーズ中に障害が発生した場合に実行するアクションを指定する。 ・ABORT：ビルドを中止する ・CONTINUE：次のステップに進む

テストレポート

buildspec.yml によるテストレポート生成が可能。
・ビルド仕様ファイル（buildspec.yml）内でテスト実行後にサポート内の形式で結果を出力
・出力されたレポートを CodeBuild が自動的に読み取り、テストレポートグループを生成できる
・生成されたレポートは CodePipeline 上でビルドアーティファクトとともに簡単に確認可能

●レポートグループ

テスト結果の詳細な分析や、プロジェクトにおけるテストカバレッジの追跡に特化しており、開発チームがテスト結果をより効果的に評価し、アプリケーションの品質を改善するための洞察を提供する。

[サポートされるテストレポート形式]

• Cucumber JSON (.json)
• JUnit XML (.xml)
• NUnit XML (.xml)
• NUnit3 XML (.xml)
• TestNG XML (.xml)
• Visual Studio TRX (.trx)

キャッシュ機能

プロジェクトのビルド時間を節約できる。キャッシュには、ビルド環境の再利用可能な部分を保存し、複数のビルドで使用できる。AmazonS3またはローカルの2種類のキャッシュがある。

項目	Amazon S3 キャッシュ	ローカルキャッシュ
キャッシュ更新	Amazon S3(リモートストレージ)	CodeBuildのローカル環境（ビルドコンテナ付き）
データ取得方法	ネットワーク経由で取得	ローカルストレージから直接取得
転送速度	ネットワークの状態に依存	高速で安定している
依存関係取得時間への影響	転送時間がかかるため改善効果は限定的	取得時間を大幅に削減し、ビルドのパフォーマンスが向上
適用場面	低頻度のビルドやネットワークコストを重視する場合	頻繁なビルドや依存関係が多い場合に最適

Code Deploy

アプリケーションを構成している「ファイル群」をステージング環境や本番環境といった「グルーピングされたサーバー群」に定められた手順で自動配置するサービス。

[デプロイイベントのシーケンス]
[デプロイ] -> [テスト] -> (成功した場合) -> [手動の承認通知]

※CloudFormation のデプロイとテストのオプションを提供しない

●CodeDeploy エージェント

インスタンスにインストールして設定すると、そのインスタンスを CodeDeploy デプロイで使用できるようにするソフトウェアパッケージ。

App Spec

Lambdaのバージョンを管理することができる。

AppSpec file (Application Specification File)	CodeDeployがEC2インスタンスに対して、 S3 または GitHub にあるアプリケーションのリビジョンをどのようにインストールするか決定する、YAML フォーマットのファイル。 ※appspec.yml として、ルートディレクトリに配置される。 また同様に、デプロイの様々なライフサイクルイベントをフックして処理を実行するか決定する。 ・この要件を満たしていない場合、デプロイは失敗する。 ・AppSpec ファイルが既に存在する場合は、これを含めたデプロイ用のコンテンツを .zip (Windows Server 以外は .tar および .tar.gz も可能) 形式の圧縮ファイルにできる。
hooks (ライフサイクルフック) ※Lambda デプロイ向け	それぞれのフックは AppSpec ファイルで定義され、デプロイの特定タイミングで 1 回だけ実行される。 ・Before Allow Traffic デプロイされた Lambda のバージョンにトラフィックを流す「前」に呼び出される。 ・After Allow Traffic トラフィックをデプロイ済みバージョンに流した「後」に呼び出される。

デプロイ方法

●デプロイグループ

デプロイ中に使用される設定と構成が含まれる。ほとんどのデプロイグループ設定は、アプリケーションで使用されるコンピューティングプラットフォームによって異なる。ロールバック、トリガー、アラームなどの一部の設定は、どのコンピューティングプラットフォームのデプロイグループでも設定できる。

[インプレースデプロイ]
既存インスタンス上でアプリを停止して、直接デプロイ。追加リソース不要。ダウンタイムが抑え、コストは低いが、可用性に注意。

デプロイ方式	概要	適用対象
OneAtATime （ローリング）	1台ずつ順番にデプロイ。最も安全、障害の影響を最小化。 ダウンタイムを抑えつつ徐々に更新。本番環境での慎重な更新に向いている。	EC2 / オンプレミス
HalfAtATime	インスタンスの半分ずつデプロイ。バランス型、安全性と速度の中間。 中規模な本番環境に向いている
All-at-once （一斉デプロイ）	全インスタンスに一度に新バージョンを展開。 シンプル・高速だが、失敗時の影響が大きい。（テスト環境や緊急修正）	EC2 / Lambda / ECS

[その他デプロイ方式]

デプロイ方式	概要	適用対象
Blue/Green (ブルーグリーン)	新環境（Green）を構築し、旧環境（Blue）から切り替える。本番稼働用トラフィックを送信する前にサービスの新しいデプロイをテストする。ダウンタイムなし、ロールバックが容易。	ECS / Lambda（疑似的）
Canary （カナリア）	一部ユーザーに新バージョンを提供し、検証後、段階的に拡大する。 影響を最小限に抑えつつ安全にリリース。	Lambda / ECS / ECS(Blue/Green)
Linear （線形）	トラフィックは毎回同じ間隔(分)の等しい増分で段階的に移行する。 安定したリリースが可能、時間はかかる。（例：10%ずつ5分ごとに移行） 増分ごとに移行するトラフィックの割合(％)と、増分間の間隔(分)を指定可能。	Lambda / ECS / ECS(Blue/Green)

[引用サイト]

ライフサイクルイベント

フックして差し込む1つ以上のスクリプトを指定する。hooks セクションは、何らかの処理を追加したい場合のみ指定する。

ApplicationStop	前回のリビジョンのシャットダウンが開始したとき(フック可能)。
DownloadBundle	AWS CodeDeploy Agent がリビジョンをCドライブの[Archiive]階層にコピーしたあと(フック不可能)。
BeforeInstall	AWS CodeDeploy が files セクションで指定された場所にファイルをコピーする前(フック可能)。ファイルの復号や現在のバージョンのバックアップの作成などの事前インストールタスクに使用。
Install	CodeDeploy が files セクションで指定された場所にファイルをコピーするとき(フック不可能)。
AfterInstall	CodeDeploy が files セクションで指定された場所にファイルをコピーした後(フック可能)。 アプリケーションの設定やファイルのアクセス権限の変更などのタスクに、このデプロイライフサイクルイベントを使用。
ApplicationStart	アプリケーションのリビジョンが開始する直前(フック可能)。
ValidateService	サービスの検証が終わった後(フック可能)。

環境変数

環境変数名	説明
DEPLOYMENT_ID	現在のデプロイメントの一意なID
DEPLOYMENT_GROUP_NAME	実行中のデプロイメントグループ名（例：prod-group）
APPLICATION_NAME	デプロイ対象のアプリケーション名
LIFECYCLE_EVENT	実行中のライフサイクルイベント（例：BeforeInstall）
SCRIPT_NAME	実行中のスクリプト名
REVISION_DIR	アプリケーションのリビジョンが展開されたディレクトリ
DEPLOYMENT_TYPE	デプロイの種類（IN_PLACE または BLUE_GREEN）

GitHub関係

GitHub Actions	GitHubが提供するワークフロー自動化サービス。コードをビルド、テスト、デプロイするCI/CDパイプラインを自動化できる。
Webhook	GitHub上のイベント（例：push、pull request）を外部サービスに通知する仕組み。リポジトリで特定のイベントが発生したときに、指定した外部URLにHTTP POSTリクエストを自動送信する仕組み。CI/CDやSlack通知、外部API連携などに非常に便利。
WebSocket	クライアントとサーバー間で双方向・常時接続の通信を可能にするプロトコル。

Device Farm

主な機能

・自動テストの実行：Appium、Calabash、Espresso などのフレームワークに対応。
・手動テスト（リモートアクセス）：ブラウザ上で実機を操作可能（スワイプ、ジェスチャーなど）。
・テスト結果の取得：動画、ログ、スクリーンショットなどを自動生成。
・CIツールとの統合：Jenkins や Android Studio などと連携可能。
・プライベートデバイスラボ：専用デバイスを予約して使用することも可能。

利点

利点	説明
実機での検証	顧客と同じ端末での動作確認が可能。OSやファームウェアの違いも考慮できる。
不具合の再現と修正	手動操作でバグを再現し、自動テストで修正サイクルを高速化。
ユーザー環境の再現	ネットワーク、位置情報、言語などを細かく設定して実環境をシミュレート。
テストの柔軟性	組み込みテストスイートまたはオープンソースフレームワークを選択可能。
スケーラブルな実行	複数のブラウザやデバイスで並列テストが可能。従量課金制でコスト最適化。

Signer

・対象：Lambda関数、IoTデバイス（Amazon FreeRTOS）、コンテナイメージなど。
・仕組み：署名プロファイルを作成し、コードに署名。署名されたコードのみが実行可能になるよう制御できる。

[メリット]
・セキュリティ強化：改ざんされたコードの実行を防止。
・コンプライアンス対応：署名履歴の監査が可能。
・職務分離：管理者と開発者の権限を明確に分離。

主な機能

機能	説明
コード署名	LambdaやIoTデバイス向けのコードに署名を付与。
署名プロファイル	署名のルールや有効期限を定義。IAMロールで署名権限を制御。
CloudTrail連携	署名操作の監査ログを取得可能。
検証ポリシー	署名されていないコードの扱いを「警告（Warn）」または「拒否（Enforce）」で設定可能。

責任共有モデル(SaaS提供責任管理)

ユーザーとAWS側、各リソースの管轄を下記画像にて明示している。

[参考公式サイト]

Tag Editer

【タグ検索フィルター】
複数のリソースにタグを一度に追加・編集、置換、削除、検索することができる。タグ付けするリソースを検索し、検索結果からそのリソースのタグを管理できる。

System Manager（SSM）

・ユーザーポリシーを制御しない。ユーザーにアクセス許可を付与するには、IAMポリシーをアタッチすること。

managed node (マネージドノード)	【SSMのリソース】 Systems Manager のために設定されたハイブリッド環境の EC2インスタンス、エッジデバイス、またはオンプレミスのサーバーや仮想マシン (VM) のこと。
SSM パラメータタイプ	Systems Manager パラメータストア内の既存のパラメータに対応。Systems Manager パラメータキーは SSM パラメータの値として指定。CloudFormation は、スタックに使用するパラメータストアから最新の値を取得。
SSMエージェント	【コンポーネントへの指示】 SystemsManagerで管理したいサーバ（EC2、オンプレサーバ、他の仮想マシン）にインストールするエージェント。EC2に対して、エージェントのインストールや「パラメータストア」内に保存した設定ファイルを選択してのエージェントの起動ができる。例えば、CloudWatchエージェントをSSHログインして直接作業せずとも、SSMコンソール経由でインストール、起動することもできる。
SSMドキュメント	【コンポーネント指示セット】 マネージドインスタンスに対するSystem Managerの振る舞いの設定をするためのリソース。JSONやYAMLの形式で、ステートマネージャーやRun Commandで、いつ何を行うか、管理しているEC2インスタンスに対して実行するアクション（インスタンスにパッチを適用するなど）を定義、管理できる。 ※マネージドインスタンスが最新のセキュリティアップデートでパッチが適用された状態に維持できるように公開されている（合計７つ）

[オンプレミスにも対応]
オンプレミスとAWSそれぞれにITシステムが存在している場合、Systems Managerはオンプレミスのサーバを対象にした機能があるため、AWSにてオンプレミス側の運用を巻き取ることができ、運用負荷を大幅に減らすことができる。このように、AWSとオンプレミス双方でリソースや運用の自動化や効率化を実現できることが大きな特徴。

[ハイブリッド環境での設定]
・オンプレミスのサーバーやVMを設定すると、AWSマネジメントコンソール上で「マネージドインスタンス」として表示される。
・これらのインスタンスはIDの接頭辞で区別され、ハイブリッド環境のものは「mi-」、Amazon EC2のものは「i-」で始まる。

[推奨されている3種類のドキュメント]
・AWS-ConfigureWindowsUpdate
・AWS-InstallWindowsUpdates
・AWS-RunPatchBaseline

[ドキュメント名：AWS-RunPatchBaseline]

• 目的：EC2インスタンスにセキュリティ更新とその他のパッチを適用する。
• ベースライン：現在「デフォルト」として指定されている patch baseline が使用される。
• 対応範囲
  ・OS パッチ適用が可能（Linux/Windows）
  ・アプリケーションのパッチ適用も可能（ただし Windows では Microsoft アプリケーションに限られる）

主要プラグイン一覧

プラグイン名	説明
aws:applications	Windows EC2 インスタンスにアプリケーション（MSI形式）をインストール・修復・アンインストールします。
aws:cloudWatch	Windows Server から CloudWatch Logs にログやメトリクスを送信します（※現在は CloudWatch Agent の使用が推奨）。
aws:configureDocker	Docker をインストール・設定します。Linux インスタンスでのコンテナ環境構築に便利です。
aws:configurePackage	SSM Distributor や SSM Documents を使って、パッケージのインストール・更新・アンインストールを行います。
aws:domainJoin	Windows インスタンスを Active Directory ドメインに参加させます。
aws:downloadContent	指定された URL からファイルをダウンロードして、インスタンス上に保存します。
aws:psModule	PowerShell モジュールをインストール・更新・削除します（Windows専用）。
aws:refreshAssociation	State Manager の関連付けを即時再評価・再実行します。
aws:runDockerAction	Docker コンテナの起動・停止・削除などの操作を実行します。
aws:runDocument	他の SSM ドキュメントを呼び出して実行します（ネスト構造の実現に便利）。
aws:runPowerShellScript	Windows インスタンス上で PowerShell スクリプトを実行します。
aws:runShellScript	Linux/macOS インスタンス上でシェルスクリプトを実行します。
aws:softwareInventory	インスタンス上のソフトウェア情報を収集し、Inventory に登録します。
aws:updateAgent	SSM Agent を更新します（非推奨、代わりに aws:updateSsmAgent を使用）。
aws:updateSsmAgent	SSM Agent を最新バージョンに更新します（推奨）。

[引用元サイト]

主要なコンポーネントの一覧

[運用管理]

Explorer	運用アイテム情報などを表示するカスタマイズ可能なダッシュボード。利用しているAWSリソースすべてに関して、情報を統合した、カスタマイズ可能なダッシュボードを提供。情報のグルーピングやフィルタリングが可能。
OpsCenter	運用上の問題の確認、調査、解決を一元的に管理。AWSのリソースに関する問題の確認、調査、解決を一元的に実施できる環境を提供。
CloudWatch ダッシュボード	CloudWatch コンソールで作成したカスタマイズ可能なダッシュボードを表示。CloudWatchのコンソールにあるダッシュボードをSystems Managerの画面からもアクセスできる。わざわざCloudWatchのサービス画面を開く必要がないため、運用の効率性が向上する。
Incident Manager	事前に準備した対応計画に基づくインシデント管理。

[アプリケーション管理]

Application Manager	アプリケーション単位でのAWSリソースデータの表示、アクション実行。CloudFormationやECS、EKSの状態を確認することが可能で、AWSリソースに関する問題を調査および修正するのに役立つ。
App Config	アプリケーション設定の管理。EC2インスタンス、AWS Lambda、コンテナなどにデプロイするアプリ、環境変数などの設定を事前に決定しておくことで、アプリケーションデプロイ時のエラーを防止するのに役立つ。
Parameter Store	設定データを一元的に管理するストア。パスワード、データベース文字列といった設定データや機密情報を保存しておき、外部のアプリケーションなどから参照できる。こちらを利用することで、アプリケーションに認証情報等を直接書いてしまう、といったことを回避できる。

[ノード管理]

Fleet Manager	AWSおよびオンプレミスサーバの管理。
コンプライアンス	ログやパッチの適用状況などコンプライアンスの管理に必要なデータを表示。
インベントリ	サーバのシステム設定とインストールされたアプリケーションの把握。
ハイブリッドアクティベーション	ハイブリッド環境でサーバー、エッジデバイス、仮想マシン (VM) をマネージドノードとして設定する。
セッションマネージャー	サーバへのブラウザベースのリモートアクセス。
Run Command	サーバ群の上でリモートコマンド実行。
ステートマネージャー	サーバ設定の一貫性の維持。
パッチマネージャー	指定ルールに基づいたサーバ群へのパッチ適用。Patch Manager を使うことで、手動の作業を減らしながら、セキュリティとコンプライアンスを維持できる。
ディストリビュータ	サーバへのパッケージの配信およびインストール。

[変更管理]

オートメーション	AWS環境全体に対する自動化処理の実行。
Change Manager	構成変更ワークフローの簡素化。アプリケーションの設定やインフラストラクチャに対する運用上の変更について、確認や承認を行うワークフローのような機能を提供。
Change Calendar	指定したアクションが AWS アカウント で実行できるまたはできない日付と時刻の範囲を設定。
メンテナンスウィンドウ	タスクのスケジュール管理。

[参照元サイト]

【運用管理】

OpsCenter

⇒AWSリソースに影響する問題の解決までの平均時間を短縮できる

・EventBridgeやCloudWatchと統合されている

【アプリケーション管理】

Parameter Store

・パスワード、データベース文字列、Amazon Machine Image (AMI) ID、ライセンスコードなどのデータをパラメータ値として保存できる。

・お客様が管理するキーの機能を備えたAPIキーの安全なストレージを提供できる。
・認証情報のハードコーディングを防ぐためにIAMロールを使用する必要がある。

[保存形式]

・パラメータ値はプレーンテキストまたは暗号化された形式で保存可能。
・暗号化には AWS KMS（Key Management Service） を使用。

※保存可能な情報の例
・パスワードやライセンスキー
・DB接続文字列や AMI ID など

Secure String
【値の暗号化】データを Secure String として保存することで、値が暗号化され管理が容易になる。アプリケーション起動時にパラメータストアからこれらの値を取得し、環境変数として利用する。

[設定管理の自動化と整合性]

データベースサーバーのIPアドレスなどを一元的に管理し、必要に応じて自動的にアプリケーションサーバーの設定ファイルに挿入することができる。

【ノード管理】

Fleet Manager

EC2 の一括管理を主目的としたサービス。サーバーフリート全体の正常性やパフォーマンスステータスを表示する。
・個々のノードからデータを収集してトラブルシューティングや管理タスクを実行。
・インスタンスのパフォーマンス状況やファイルシステム、イベントログなどの情報をコンソールから確認。
・仮想マシンにリモート接続しなくても、個々のサーバーにドリルダウンして、ディスクとファイルの探索、ログ管理、Windows レジストリ操作、ユーザー管理などを行う。

Inventory

[機能]
・マネージドインスタンスからメタデータを収集。
・メタデータはAmazon S3バケットに保存。
・組み込みツールでデータにクエリを実行可能。
・インスタンスで実行されているソフトウェアや、更新やポリシー適用の必要性を特定できる。

[設定]
・ワンクリック手順で全インスタンスにインベントリを設定可能。
・複数リージョン・アカウントに対応した統合管理が可能。

[収集できるメタデータタイプ]

アプリケーション	アプリケーション名、発行元、バージョンなど
AWS コンポーネント	EC2 ドライバ、エージェント、バージョンなど
ファイル	名前、サイズ、バージョン、インストール日、変更および最新アクセス時間など
ネットワーク設定の詳細	IP アドレス、MAC アドレス、DNS、ゲートウェイ、サブネットマスクなど
Windows 更新	Hotfix ID、インストール者、インストール日など
インスタンスの詳細	システム名、オペレーティングシステム (OS) 名、OS バージョン、最終起動、DNS、ドメイン、ワークグループ、OS アーキテクチャなど
サービス	名前、表示名、ステータス、依存サービス、サービスのタイプ、起動タイプなど
タグ	インスタンスに割り当てられるタグ
Windows レジストリ	レジストリキーのパス、値の名前、値タイプおよび値
Windows ロール	名前、表示名、パス、機能タイプ、インストール日など
カスタムインベントリ	カスタムインベントリの操作 に説明されるようにマネージドインスタンスに割り当てられたメタデータ

Hybrid Activation

AWSの外にあるサーバー（オンプレミスや他社クラウド）を、AWS Systems Managerで管理できるようにする機能。これにより、AWS EC2インスタンスと同じように、一元的にサーバーのパッチ適用、インベントリ収集、自動化などの運用管理が可能になる。

Session Manager

AWS CLI を使用してマネージドノードとの Session Manager セッションを開始するには、ローカルマシンに Session Manager プラグインをインストールする必要がある。Microsoft Windows Server、macOS、Linux、および Ubuntu Server のサポート対象のバージョンにプラグインをインストールできる。

※インバウンドポートを開いたり、踏み台ホストを維持したり、SSHキーを管理が不要

・ポートに依存しない非SSHのセッションを確立できる。また、セッション中に実行されたコマンドをCloudWatch Logs に保存できる。
・アカウント内のインスタンスとのセッションを開始できる。セッションの開始後、他の接続タイプと同様、Powershellコマンドを実行できる。

●ポートフォワーディング

【パケットの転送指定】
インターネットから特定のポート番号宛てに届いたパケットを、あらかじめ設定しておいたLAN側の機器に転送する機能。SSHセッション中に実行したコマンドのログを保持し、ポートフォワーディング機能を維持する。

[セキュアなアクセス]

下記、要件を保証する。

●プラットフォーム

EC2インスタンスへの簡単なワンクリックのクロスプラットフォームアクセスの提供。

●堅牢なアクセス要件

インスタンスへの制御されたアクセス、厳格なセキュリティプラクティス、インスタンスアクセスの詳細を含む、完全に監査可能なログ環境を提供。
・インバウンドポートを開かずに、セキュアなインスタンスへのアクセスを提供できる。
・エンジニアが実行するコマンドの監査を提供し、エンジニアのアクションが完全に監査可能になる。

Run Command

・AWSマネジメントコンソールからWindows サーバーのPowerShellスクリプトを実行できる。
・CLIを介してEC2インスタンスマネージドノードの設定を安全にリモートで管理ができる。

スケジュールに従ってマネージドノードをスキャンしてコンプライアンスをレポートしたり、利用可能なパッチをインストールしたり、必要に応じてターゲット オンデマンドへのパッチの適用やスキャンを行ったりするオプションがある。

State Manager

【一例】

・起動時に特定のソフトウェアを使用してインスタンスをブートストラップする
・ライフサイクルを通じてソフトウェアの更新でインスタンスをパッチする。
・ライフサイクルを通じて Linux および Windows マネージドインスタンスでスクリプトを実行。
・インスタンスを Windowsドメインに結合する (Windows Server インスタンスのみ)。
・定義済みのスケジュールに従ってエージェント(SSMエージェントなど) をダウンロードして更新。

[State Manager の前提条件]

利用するにあたり、EC2には以下のような条件が必要。

・適切なRole（ProfileがEC2へ割り当たっている事）の準備。
・インターネットへの接続、もしくはSSM Endpointsへの接続が可能なこと。
・ステートマネージャーでログを出力するため、ログ用のバケットへの書き込み権限があること。

Patch Manager

・インスタンスをスキャンして、不足しているパッチのみをレポート。
・必要に応じて、不足パッチを自動インストールも可能。
・System Managerエージェントによって、リソースの更新、管理、設定を実施できる。
・パッチ承認ルール（例：リリース後数日で自動承認）や承認/拒否パッチのリストを設定可能。

[タグによる管理]
EC2タグを使って、個別インスタンスやグループ単位でパッチ適用の対象を指定。タグはパッチベースラインにも追加可能。

[メンテナンスのスケジューリング]
Systems Managerのメンテナンスウィンドウ機能で、パッチ適用を定期的にスケジュール可能。オペレーションシステムのパッチ適用、ドライバー更新、ソフトウェアやパッチのインストールなど、インスタンスに対して中断の可能性があるアクションを実行するスケジュールを定義できる。

[自動承認の遅延]
パッチがリリースまたは最後に更新されてから自動承認されて適用されるまでの待機日数。
【例】
CriticalUpdates 分類を使用してルールを作成し、自動承認の遅延として 7 日間を設定した場合、7 月 7 日にリリースされた新しい重要なパッチは 7 月 14 日に自動的に承認される。

Distributor

・アカウントにソフトウェアパッケージを安全に保存、配布するために使用。
・ソフトウェアをパッケージ化して Systems Managerマネージドノードへの公開に役立つ。
・管理対象となっている複数のマネージドインスタンスに対してAWSで公開されたパッケージ化された（既存含む）ソフトウェアを新規作成またはデプロイ、配布することができる。

[パッケージ作成]

Distributor でパッケージを作成すると、システムに SSM ドキュメントが作成。このドキュメントに .zip ファイルを添付できる。
Distributor を実行すると、システムは SSM ドキュメントにある指示を処理し、指定されたターゲットに .zip ファイルのソフトウェアパッケージをインストールする。

[パッケージ展開]

独自のソフトウェアをパッケージ化して公開したり、Distributor を使用して、CloudWatchAgent などの AWS から提供されるエージェントソフトウェアパッケージ、または Trend Micro などのサードパーティーパッケージを検索して公開することができる。

パッケージの公開により、ノード ID、AWS アカウント ID、タグ、または AWS リージョン を使用して特定のマネージドノードに、パッケージのドキュメントの特定のバージョンを公開できる。

【変更管理】

Automation

特徴

・Runbook（ランブック）を使用して作業手順を定義。
・AWSが提供するテンプレートを利用。または自分でカスタムRunbookを作成可能。
・Amazon EventBridgeと連携して通知を受信可能。
・Systems Managerコンソールから進行状況をモニタリング可能。
・Document：自動化したい一連の処理を定義。事前定義されたものを選択することもできれば、自前で作成することもできる。

機能性

機能カテゴリ	実装例・説明
同時実行制限	maxConcurrency パラメータで、同時に処理するターゲット数を制限可能。過負荷や予期せぬ影響を防止する。
エラーしきい値	maxErrors パラメータで、許容可能なエラー数を指定し、それを超えると自動化を停止する。
承認ステップ	aws:approve アクションを使って、特定のステップで、指定ユーザーの承認を求めることが可能。
入力バリデーション	allowedValues や allowedPattern を使って、パラメータの不正入力を防止。
ログと監査	CloudWatch Logs や CloudTrail に記録し、実行履歴やトラブルシュートに活用。

オートメーションランブック	[実行アクション定義] Systems ManagerがマネージドインスタンスとAWSのリソースに実行するアクションの定義を行う。 Automationには事前にランブックが用意されており、EC2の再起動など一般的なタスクも使用するできる。 [自動アクション] Automationにはステップというものがあり、各ステップごとにAutomationを関連付ける。
オートメーションクォーター	AWSアカウントはAutomationを同時に100個実行できる。100以上の実行は保留中のステータスになる。
オートメーションキューのクォータ	100個の同時Automationの数より多くのAutomationを実行しようとすると、後続にAutomationが追加。 追加制限として、最大1000個までキューに保存できる。
レート制御のオートメーションクォータ	AWSアカウントは最大25個のレート制御のオートメーションを同時実行できる。 25個より多くの実行すると保留中のステータスになる。
レート制御のオートメーションキューのクォータ	最大25個のレート制御のAutomationより多くのAutomationを実行すると、後続にAutomationが追加。 最大1000個のレート制御のAutomationをキューに追加できる。

Maintenance Windows

・タグを作成または更新するときに、タグをメンテナンスウインドウに追加できる。
・各メンテナンスウインドウには、スケジュール、最長期間、登録されたターゲットのセット（実行されるインスタンス）、登録されたタスクのセットがある。

ノードに対して破壊的になり得るアクションを実行する下記のようなスケジュールを定義できる。

・オペレーティングシステムのパッチ適用
・ソフトウェアやパッチのインストール
・ドライバーの更新など

※Amazon S3バケット、Amazon SQS キュー、AWS KMS キーなど、他の AWS リソースタイプでアクションをスケジュールできる。

Well-Architected Tool

[大まかな流れ]

①Well Architected Framework Toolを利用してレビューを実施する。
②レビューの結果をもとに課題に対して改善活動を行う。
③Well Architected Framework Toolからレポートが作成される。
④レビュー時の議論、レポートの内容から改善施策を立案する。
⑤課題の改善を実施する。

フレームワーク

Well Architected Framework	AWSがこれまで蓄積してきた経験から生まれたシステム設計・運用における「ベストプラクティス集」。
Well Architected Framework Tool	ユーザのワークロードがベストプラクティスにどれほど沿っているかレビュー項目に対して、関係者で議論して進めていく。理想像と現行の環境とのギャップを理解できる。結果をレポートとして出力。

Well Architected Framework
以下の６つの観点をもとに実施する。

運用上の優秀性	変更の自動化、イベントへの対応、日常業務を管理するための標準化。
セキュリティ	データの機密性と整合性、ユーザー許可の管理、セキュリティイベントを検出するための制御。
信頼性	分散システムの設計、復旧計画、および変化する要件への処理方法。
パフォーマンス効果	最適化されたリソースの選択、パフォーマンスのモニタリング、ニーズ増大に応じて効率を維持。
コスト最適化	時間の経過による支出把握と資金分配の制御、適切なリソースの種類と量の選択など。
持続可能性	持続可能性の責任共有モデル、影響についての把握、および必要なリソースを最小化してダウンストリームの影響を減らすための使用率を最大化。

[AWSパートナーとレビューを行う場合]

[メリット]
・熟練のAWSエンジニアが設問を正しく質問・解説するためレビューがより意味のあるものになる。
・レビュー後、出力されるレポートを整理されたオリジナルのフォーマットに変換してもらえる。
・改善施策の立案・並走まで対応してくれる

[一例]

例①）
「セキュリティサービスの標準化・一元管理」「各アカウントのホスト管理の一元化」ができていない
➡AWSを利用する上でガイドラインを作成する。セキュリティ、コストなどの項目についてガイドラインを作成し標準化を狙う。

例②）
定期的な不要リソース削除の仕組みがなく、スナップショットだけで利用料全体の20%を占めていた。
➡不要なスナップショットを削除すべく、効率

基礎知識

●クレデンシャル

IDやパスワードをはじめとする、ネットワーク上でユーザ等の認証に用いられるセキュリティ情報の総称。

●SCIM

(System for Cross-domain Identity Management)
様々なドメイン間でユーザID情報のやりとりを自動化する。
複数のクラウドサービスやシステム間でユーザーIDの整合性を取るように管理するプロトコル。

●認証(AUTH)トークン

アクセス制御に用いられるデジタルトークン。一般的に、ユーザーがアプリケーションやサービスにアクセスする際に、ユーザー名とパスワードを入力することで認証が行われる。

●SSL/TLS

(Secure Sockets Layer/Transport Layer Security)
インターネットで情報を送受信する際の仕組み（プロトコル）の一種で、サーバ〜PC間の通信を暗号化して安全を担保する。

[利用方法]
クライアントに説明して、CSR（Certificate Signing Request）ファイルと呼ばれる証明書の発行申請書を作成。認証局にお金を支払い証明書を発行してもらい、サーバへインストールするなどの手続きが必要になる。
※証明書接続エラーは基本的にSSLエラーとして確認されることが多い。

[SSL証明書の種類]

ドメイン認証型SSLサーバ証明書 （DV: Domain Validation）	(レベル:低)ドメイン認証
組織認証型SSLサーバ証明書 （OV: Organization Validation）	(レベル:中)ドメイン認証・会社実在認証
EV SSL証明書 （Extended Validation）	(レベル：高)ドメイン認証・会社実在認証・電話実在認証

◇フェデレーション

一度の認証で複数のシステムを使ったり、複数のサービス（クラウドなど）、リソースやアプリケーションへのアクセスを受けられるようにするための仕組み。

[フェデレーションの方法]
シングルサインオン(SSO)を実現させるために方式が４つあり、「フェデレーション方式」はその一つである。
[参考サイト]

Web ID フェデレーション	【パブリックなトークン】 AmazonやSNS、Google(IdP:IDプロバイダー)がユーザーのトークンを発行することでサインインできる。その時に外部サービスのユーザー情報とIAMロールを紐づけて一時的にアクセス権限を付与する。
その他外部 ID フェデレーション	【内部組織のトークン】 IAM ロールを使用して、ID が組織または第三者のプロバイダー (IdP) からフェデレーションされたユーザーのアクセス許可を指定できる。社内のディレクトリなど、AWS 以外の ID をユーザーに有効。

●IAMフェデレーション

組織内の既存のIDシステム (IDプロバイダー) を利用して、AWSやその他のクラウドサービスへのアクセスを許可する仕組み。IDプロバイダーとフェデレーションを使用して、各リソースへのアクセスをユーザーに求める。

フェデレーションタイプ	アカウントの種類	アクセス管理対象	サポートされている IDソース（プロトコル）
IAM	単一のスタンドアロンアカウント	・短期間の小規模デプロイにおける人間ユーザー,マシンユーザー	・SAML 2.0 ・OIDC
IAM Identity Center	Organizations によって管理される複数のアカウント	ワークフォースの人間ユーザー	・SAML 2.0 ・マネージド Active Directory ・Identity Center ディレクトリ
Cognito	いずれか	リソースへのアクセスに IAM 認可を必要とするアプリのユーザー	・SAML 2.0 ・OIDC ・OAuth 2.0 ソーシャル ID プロバイダーの選択

◇ID プロバイダー(IdP)

★プロバイダーとは… 回線をインターネットと繋げる役割を担う接続事業者のこと。外部の人向けにトークンを発行してくれる事業者

・外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を与えることができる。
　※外部ユーザー＝よく知られた IdP[事業者] (例: Login with Amazon、Facebook、Google)
・会社に既に企業ユーザーディレクトリなどの独自の ID システムがある場合に便利
・AWS リソースへアクセスが必要なモバイルアプリやウェブアプリケーションを作成する場合に便利

[大まかな付与プロセス]

既にユーザーIDをAWSの外で管理している（外部ユーザー）は、、、

1 : IAM ID プロバイダーエンティティを作成して、AWS アカウント と IdP の間に信頼関係を確立。
2 : AWS アカウント に IAM ユーザーを作成する代わりにトークンを作成（得る）。
3 : 外部 IdP は、OpenID Connect または SAML 2.0 のいずれかを使用して ID 情報を AWS に提供する。
4 : 以降から外部idPを使用してサインインする。
[参考公式サイト]

[ID プロバイダー×フェデレーション]

AWS のアカウント管理の仕組みである（IAM ユーザー）でユーザー認証をして AWS を利用できるようにするのではなく、外部の ID プロバイダー（IdP）で管理されている ID を使って認証して AWS を利用できるようにする仕組み(AWS が認証をするのではなく、AWS は認証後に渡されるもの(ID トークンなど)をみて AWS にアクセスする事を許可する)
[引用元サイト]

[IdP を直接 IAM にリンクする]

ID プロバイダーエンティティを作成して、AWS アカウントと IdP の間に信頼関係を確立する。IAMは、OpenID Connect (OIDC) または SAML 2.0 (Security Assertion Markup Language 2.0) と互換性のある IdP をサポートする。

※IAM Identity Centerを有効にせず、AWS アカウントを 1 つだけ使用するには、、、
OIDC または SAML 2.0 を使用して ID 情報を AWS に提供する外部 IdP で IAM を使用できる。

●OIDC

GitHub Actions など、AWS 上で実行しないアプリケーションを AWS リソースに接続できる。

●OIDC プロバイダー

AWSアカウントとOIDCをサポートする外部IdPとの信頼関係を確立するためのIAMエンティティ。OIDC 互換 IdP と AWS アカウント の間で信頼性を確立するときに IAM OIDC ID プロバイダーを使用する。
[引用元サイト]

◇プロトコル

[フェデレーションを実現させる技術]
フェデレーションを実現させるためのプロトコルの種類。フェデレーション認証の業界標準。

OpenID Connect	【トークン発行処理の標準仕様】　※ベース：OAuth 2.0プロトコル サービス間で利用者の同意に基づきID情報を流通するための標準仕様。 利用者がOpenID提供サイトに登録したID情報を使って、ほかのOpenID対応サイトにログインすることが可能になる。 [参考サイト]
SAML 2.0	【異なるプロトコルの通信方法】 外部のアプリケーションおよびサービスにユーザーが本人であることを伝える標準化された方法のこと。 （※異なるインターネットドメインの通信を実現するための通信プロトコル） ユーザーを一度認証してから認証を複数のアプリケーションに伝える方法を提供し、シングルサインオン（SSO）技術を可能にする。誰が誰かを示すための標準化された方法。身元特定しなくても、身分証を見るだけで済む。 [参考サイト] ※SAML：Security Assertion Markup Language ※ベース：XML SAMLフォーマット ・SAMLアサーション 認証に成功したときにIDプロバイダーが発行するメッセージ。 ユーザーに関する認証・認可の情報がXML形式で出力され、サービスプロバイダーが受信し、内容を確認する。

[引用元サイト：プロトコルの違いについて]

[解釈]
idPがトークン発行 ⇒ フェデレーション機能（SSO）だけでサインインできるけど、ロールと紐づけることで安全性が確保される。これが基本（？）

IAM

権限レベル

[強] ルートアカウント	[中] 管理者権限 （IAMユーザー）	[弱] パワーユーザー (IAMユーザー)
・AWSルートアカウントのメールアドレスやパスワードの変更 ・IAMユーザーの課⾦情報へのアクセスに関するactivate/deactivate ・他のAWSアカウントへのRoute53のドメイン登録の移⾏ ・AWSサービス（サポート等）のキャンセル ・AWSアカウントの停⽌ ・コンソリデイテッドビリングの設定 ・脆弱性診断フォームの提出 ・逆引きDNS申請	ルートアカウントと同等の権限はない	IAMの操作権限なし

●アクセス許可の境界
IAMの高度な機能。管理ポリシー（AWS管理ポリシー / カスタマー管理ポリシー）を使って、アイデンティティベースのポリシーをIAMエンティティ（ユーザーやロール）に付与することで、IAM ユーザーやロールに対して「最大限許可できる操作の範囲」を制限するための仕組み。

・エンティティはアイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できる。
（実際のアクセス許可は、IAM ポリシーとアクセス許可の境界の両方で許可されている操作のみが有効になる（AND条件））

IAMポリシー

AWS管理ポリシー (マネージド)	予めAWSによって用意されている管理ポリシー。「ポリシー」単体として存在できて、複数のプリンシパルエンティティにアタッチして利用可能。ポリシーを変更するとアタッチされている全てのプリンシパルエンティティが変更適用。バージョニング、ロールバック可能。
カスタマー管理ポリシー	ユーザー（お客様）自身が管理できる管理ポリシー。
インラインポリシー	特定のIAMユーザやIAMロール専用に作成されるポリシー。（使いまわしができない） 「ポリシー」単体では存在できず、プリンシパルエンティティ(1つのIAMユーザ)など、1対1でのアタッチしかできない。

AWSサービスやAWSリソース(リソース間の連携)に対する操作権限を定義して、IAMユーザやIAMグループにアタッチ。

	特徴
JSON形式で 定義	Action(どのサービスの)、Resource(どういう機能や範囲を)、Effect(許可/拒否)
Condition要素	IAMポリシーのCondition要素内で、特定のタグと値を持つリソースへのアクセス制御できる。
APIアクセスの設定	ユーザーが呼び出すことができる API オペレーションを指定できる。
MFA認証の 固定化	場合によっては、ユーザーが特に重要なアクションを実行することを許可する前に、このユーザーに AWS 多要素認証 (MFA) で認証することを求める追加のセキュリティが必要となることもある。 ・「Get-Session-Token」を呼び出す方法。 ・「Assumelore」を使用する方法。 [参考サイト]

JSONポリシー要素

要素	説明
Effect	許可（Allow）または拒否（Deny）
Action	許可・拒否する操作（例: s3:PutObject）
Resource	操作対象リソース（例: arn:aws:s3:::example-bucket）
Principal / NotPrincipal	操作者（誰が行うか）／それ以外を除外 ※NotPrincipalは、特定のプリンシパル（IAMユーザーやロールなど）以外のアクセスを拒否するために使われる。 "Effect": "Deny"と組み合わせて使用することで、「指定されたプリンシパル以外すべて拒否」というホワイトリスト的な制御が可能になる。
Condition	特定の条件（IP、時間、VPCなど）で制御

リソースポリシー vs アイデンティティポリシー 比較表

項目	リソースポリシー	アイデンティティポリシー
説明	特定の AWS リソースに適用される	特定の IAM ユーザー、グループ、またはロールに適用される
ポリシー の場所	リソース（S3 バケット、SNS トピック、SQS キュー）に直接アタッチされる	IAM エンティティ（ユーザー、グループ、ロール）にアタッチされる
ポリシー の目的	リソースへのアクセスを制御する	IAM エンティティの操作を制御する
誰に適用 されるか	特定のエンティティ（他の AWS アカウント、IAM ユーザー、ロール）	特定の IAM エンティティ（ユーザー、グループ、ロール）
ポリシー の形式	JSON 形式で記述される	JSON 形式で記述される
クロスアカウントアクセス	リソースに対して他の AWS アカウントからのアクセスを許可できる	グローバルに適用。ポリシーはエンティティに直接アタッチされる
例	S3 バケットポリシー、SNS トピックポリシー、SQS キューポリシー	IAM ユーザーポリシー、IAM ロールポリシー
適用対象 サービス	S3、SNS、SQS などのリソースを提供する AWS サービス	AWS Organizations など、アイデンティティを管理する AWS サービス

ポリシーの検証・テスト

Policy Validator	文法に基づいていないポリシーを検出し、修正を求める。
IAMPolicy Simulator	IAMのポリシー設定をテストできる。アイデンティティベースのポリシー、IAMアクセス許可の境界、組織のサービスコントロールポリシー、リソースベースのポリシーをテストおよびトラブルシューティングできる。
DryRun (プール値)	実際に要求を行うことなく、アクションに必要な権限があるかどうかを確認し、エラー応答を提供する。必要な権限がある場合、エラー応答はDryRunOperationとなる。

認証方式

AWSアクセスキー	アクセスキーID/シークレットアクセスキーのセット。 IAMユーザまたはAWSアカウントの長期的認証情報を指す。 S3やEC2といったAWSの各サービスに対してプログラムにおけるアクセスを認証するために作成される認証キー。
X509 Certificate	[参考：AWS公式]
MFA	Multi-Factor Authentication 多要素認証。ユーザーのスマートフォンからのコード、秘密の質問の答え、指紋、顔認識などを要求する。

●認証情報レポート（Credential Report）
監査向け情報。特定のIAMアイデンティティ（ユーザー、グループ、ロール）のIAM認証情報のレポートファイル。
※AWS Management Console、AWS SDK、コマンドラインツール、または IAM API から取得できる

[取得できる情報]

認証情報	パスワード、アクセスキー、MFA デバイスなど認証情報のローテーション。
認証情報ステータス	MFA、最終ログイン時間、パスワード利用有無など。 【監査向け対応】 監査やコンプライアンスの作業支援。また、外部の監査人にレポートとして提供できる。 ・監査人はレポートをダウンロードできる。4 時間ごとに 1 回生成できる。 ・レポートをリクエストすると、IAM はまず AWS アカウント について過去 4 時間以内にレポートが生成されたかどうかを確認する。

●IAMデータベース認証
DB接続用。IAMのデータベース接続に認証機能を付与する。

対象データベース	MySQL および PostgreSQL
仕組み	DBユーザーのパスワードなど資格情報の保存は不要。パスワードの代わりに IAM 認証トークン(署名付きの一時的な文字列)を使用して DB に接続。(IAM ユーザーまたはロール認証情報と認証トークンを使用してRDS DB インスタンスまたはクラスターに接続) ※RDSが立ち上げたMySQLなどにアクセスする際(通常はユーザー名とパスワードを利用してアクセス） ・アプリケーションがインスタンスで実行されている場合、インスタンスプロファイル認証情報を使用してデータベースにアクセス。 ・SSL 接続が必要で、DB インスタンスとの間で送受信されるデータは暗号化される。
トークンの有効期限	有効期間は 15 分。AWS アクセスキーを使用して生成。
署名方式	AWS Signature Version 4 を利用

[主なメリット]

• 認証情報の一元管理: IAM によって DB ユーザーの管理が可能（DBにユーザー情報を保存しなくてもよい）
• ネットワークセキュリティ: SSL/TLS による暗号化通信を使用
• EC2 連携: EC2 インスタンスに割り当てられた IAM ロールを使えば、パスワードなしで DB にアクセス可能

グローバル条件キー

すべての AWS サービスで共通して使用できるポリシー条件キー。これらは IAM ポリシーの Condition 要素で利用され、リクエストのコンテキストに基づいて、アクセス許可の条件を指定する。アクセス制御をより細かく設定するために使われる。

条件キー	説明
aws:SourceIp	リクエスト元の IP アドレスに基づいてアクセス制御
aws:UserAgent	リクエストの User-Agent に基づいて制御
aws:MultiFactorAuthPresent	MFA（多要素認証）が有効かどうか
aws:PrincipalArn	リクエストを行ったプリンシパルの ARN
aws:RequestTag/tag-key	リクエストに含まれるタグに基づく制御
aws:ResourceTag/tag-key	リソースに設定されたタグに基づく制御
aws:SecureTransport	HTTPS 経由のリクエストかどうか
aws:SourceAccount	リクエスト元の AWS アカウント ID
aws:SourceArn	リクエスト元のリソース ARN

作業ロール

●サービスロール

信頼ポリシーが設定されており、必要なアクセス権のみを持つため、不要な権限を削減できる。
AWSサービスが他のサービスへのアクセスに使用するための信頼性が確保された一意の資格情報が使用される。

項目	IAMロール	サービスロール
用途	AWS リソースへのアクセス権を付与するためのロール	AWS サービス（EC2、Lambda など）が他のサービスにアクセスするためのロール
主体	ユーザーアカウント、他のロール、AWS サービス	AWS サービス自体
割り当て先	ユーザーまたはグループ	サービス
アクセス許可ポリシー	一般的なアクセス許可ポリシー、カスタムポリシーなど	サービスによって事前に定義されたポリシーを使用
外部から信頼されるエンティティ	他の AWS アカウントや外部 ID を信頼することができる	信頼されるエンティティは AWS サービスのみ
セッションの期間	一時的なセッションが可能	固定された期間または無期限
フェデレーション	クロスアカウントへのアクセス、一時的なセッションに使用可能	サービスが他のサービスへのアクセスに使用

[参照先サイト]

IAMロール

★(ロール)信頼ポリシー…. JSON ポリシードキュメントで、他のアカウントやサービスが特定のIAMロールを引き受けることを許可する(IAMロールに必須の)ポリシー。信頼ポリシーで指定できるプリンシパルには、ユーザー、ロール、アカウント、およびサービスが含まれる。

[仕組み]

1. STSに「一時的セキュリティ認証情報」の発行を依頼
2. 発行された「一時的セキュリティ認証情報」を使って、AWSリソースにアクセスを行う。
   ※「一時的セキュリティ認証情報」をユーザーは管理する必要がな
   
   ユーザーがアクセスキーを管理する必要がなくなる
   ※[一時的セキュリティ認証情報 とは]
   セッショントークン、シークレットアクセスキー、有効期限、アクセスキー

[使用例]
EC2インスタンス上で稼働するアプリケーションに一時的にAWSのリソースへのアクセス権を与えたい
⇒ EC2インスタンス作成時にロールを付与することで可能

インスタンス プロファイル	IAM ロールのコンテナ。EC2インスタンスのためのIAMロールが作成される。インスタンスの起動時に EC2 インスタンスにロール情報を渡すために使用できる。
Assume Role (共有IAMロール)	別アカウントのリソースにアクセスしたい時、使用するロール。（ロールの代行） 「アカウントAがアカウントBのS3バケットにアクセスしたい」などのシチュエーションで役に立つ。 ※実行権限を持つロールは作成元リソースが存在するアカウントに存在する必要があるため ●外部ID（専用）【ロールの使用ID】 第三者がIAMロールを引き受ける際、信頼ポリシー内で外部IDを使うとロールを安全に委任できる。 指定することで、ロールの使用権限が第三者に漏れたとしても、外部IDが一致しないと使用できない。 ①IAMロールの信頼ポリシーに外部IDを設定。 ②第三者はAWS CLIまたはAPIを使ってそのロールを引き受ける際、外部IDを指定。
IAM Roles Anywhere	オンプレミスなどAWS外部のサーバーに、IAMロールを使って一時的な認証情報（クレデンシャル）を取得し、AWSサービスにアクセスできる。 ・AWS環境からアクセスキーやシークレットアクセスキーを払い出す必要がなくなり、 ・長期間有効な証明書ベースの認証を必要とするユースケースに適している

[SAML フェデレーションアクセスを許可するロール]

IAMで作成するロールは、組織のどのフェデレーションユーザーの操作を許可されるかを定義する。
ロールの信頼ポリシーを作成するときは、前に Principal として作成した SAML プロバイダーを指定する。さらに、特定の SAML 属性に一致するユーザーにのみロールへのアクセスを許可するように、Condition 付きの信頼ポリシーのスコープを設定できる。
[引用元サイト]

STS

・セキュリティ認証情報セットとして、「アクセスキー」、「シークレットキー」、「セッショントークン」を発行。
・リクエストに応じてその都度動的に作成される（AWSIDを発行しない）ため、一時的でユーザーに紐づかない。
（IDフェデレーション）

Organization

グループを作成し、そのグループに対して、アクセス制御OU(組織単位) や SCP(サービスコントロールポリシー)を適応することでサービスへの使用を制限する。ただし、OU単位でのポリシー作成は管理が複雑になるため、非効率。

・複数のアカウントでの料金を追跡し、コストと使用状況の統合データをダウンロードできる。

・APIから新規アカウントを作成・グループに追加を行い、すぐに使用管理できる。
(※従来はAWSのアカウントを作る際、カード番号の入力や電話認証などの対応が必要だった)

[一括請求にメンバーアカウントを追加する]
管理アカウントの所有者が、追加するアカウントへリクエストを送信する。

[リソース共有]
アカウントがOrganizationsによって管理されている場合、それを活用すればリソースを共有しやすくなる。組織の有無にかかわらず、ユーザーは個々のアカウントとリソースを共有できる。
[遷移先ページ]

[Organizations で管理できる内容]

項目	説明
アカウントの一元管理	複数の AWS アカウントを「組織」としてまとめ、グループ化（OU）できる
ポリシーの適用	サービスコントロールポリシー（SCP）で、アカウントやOU単位に操作制限を設定可能
請求とコスト管理	組織全体の利用料金をまとめて請求し、コストを可視化・最適化できる
リソースの共有	AWS RAM を使って、VPCやライセンスなどをアカウント間で共有可能
新規アカウントの作成	管理アカウントからメンバーアカウントを簡単に作成・招待できる
セキュリティと監査	CloudTrail や Config を使って、全アカウントの操作履歴や設定を監視できる
アクセス制御の統合	IAM Identity Center で、ユーザーやグループのアクセス権を一括管理できる

●OU

SCPの制御をさらに細かくグループ分けして制御できる。
※管理アカウントは組織のルートアカウントであり、OUに含めることはできない
※OUにはデフォルトでFullAWSAccess SCP がアタッチされている
※異なる組織ユニット（OU）間でのアカウントの移動のみをサポートしている

●タグポリシー

組織のアカウント内のリソース間でタグを標準化できる。リソースのタグ付けの際に適用されるタグ付けルールを指定。Organizations で管理されるアカウント群に対し、タグのキーや値のルールを定義・適用できるポリシー。

IAM Identity Center

（※AWS SSOの後継サービス）
SSOが組織版に対応した感じ。すべての AWS アカウント とクラウドアプリケーションのためのシングルサインオンサービスを提供する。複数アカウントを運用している環境で各ユーザを集約管理し、各アカウントへの一元的なアクセスとユーザーアクセス許可を簡単に行えるようにするためのサービス。

※SSO：Single Sign ON

●アクセス権限(許可)セット
ポリシーの集合体。管理者定義のポリシーの集合であり、ユーザーおよびグループが持つアクセスレベルを定義する。
・権限セットは IAM Identity Center に保存され、1 つ以上にプロビジョニングできる。
・AWS アカウント複数のアクセス権限セットを 1 人のユーザーに割り当てることができる。
・特定のAWSアカウントに対するユーザーのアクセス許可が有効か判断するためにSSOで使用される。

[仕組み]

1. AWS Directory Service を通じて Microsoft Active Directory に接続される。
2. そのディレクトリのユーザーは、既存の Active Directory のユーザー名とパスワードを使用して、パーソナライズされた AWS ポータルにサインインできる。
3. AWS アクセスポータルから、ユーザーは権限を持つすべての AWS アカウント およびクラウド アプリケーションにアクセスできる。

[参考]

[IdPとの関係性]
SSOとIdPは分離されているが、SSOプロバイダーがユーザーのログイン時にIdPでユーザーIDを確認するSSOのプロセスがある。

★旧SSOサービス：AWS SSO 【IdPを使った認証】 SSOトークンを発行して、1組の「ID・パスワード」による認証を1度行うだけで複数のサービスにログインできるようにする仕組み。

SCP

※サービスコントロールポリシー
組織のIAMユーザーとIAMロールで使用可能な最大アクセス許可を一元的に制御できる。しかし権限を付与するのではなく、OU（組織単位）内のIAMユーザーやIAMロールが実行できるアクションに対してアクセス許可ガードレールを定義、制限するものである。
※許可ではなく明示的な拒否を指定することで効果的に制限をかける仕組み。

上記より、アクセス許可を付与するにはIAMユーザーとIAMロールにアタッチされたアイデンティティベースのポリシーやアカウントリソースにアタッチされたリソースベースのポリシーなどのアクセスを制御するポリシーをアタッチすること。
[参考サイト]

[利用条件]
・機能セットの「すべての機能」が有効になっている組織でのみ使用できる。

[戦略]

拒否リスト （戦略）	アクションはデフォルトで許可され、禁止するサービスとアクションを指定できる。 ※戦略⇒許可しないアクセスを明示すること
許可リスト （戦略）	アクションはデフォルトで禁止され、許可するサービスとアクションを指定できる。 ※戦略⇒許可するアクセスを明示すること

※「FullAWSAccess」アカウントに対し、拒否形式（ブラックリスト形式）を設定する場合
「FullAWSAccess」にブラックリスト形式で特定の操作を拒否すると、対象リソースの操作が拒否されるものの、その他のリソースについては「FullAWSAccess」が維持された状態となる。

[アカウントの別組織への移動方法]

1. 新しい開発組織の管理アカウントから Oranizations API の InviteAccountToOrganization オペレーションを呼びだして開発者アカウントに招待状を送信。
2. 管理アカウントからOrganizations API の RemoveAccountFromOrganization オペレーションを使用して、古い組織から各開発者アカウントを削除。
3. 各開発者に自分のアカウントにサインインして、新しい開発組織への参加確認をしてもらう。

機能セット

Organization には利用可能な2つの機能セットがある。

・すべての機能（おすすめ）
一括請求機能が含まれている。(デフォルト)サポートされているAWSサービスとの統合、組織管理ポリシーなど高度なアカウント管理機能が可能。

・一括請求機能
※Consolidated Billing
複数アカウントを親アカウントと子アカウントの関係性にして親アカウントが子アカウントの分もまとめて一括支払い（一本化）できるサービス。

・複数アカウントで無料枠を使用していても１アカウント分しか無料枠は適用されない。
・一括請求機能のレポートは指定されたS3バケットに受信するように設定する必要がある。
・対象のバケットは管理アカウントによって所有されるため、メンバーアカウントが所有するS3バケットに受信されることはない。
・一括請求は追加コストなしで提供される。

[割引の共有]
全アカウントの利用料にボリューム割引が適用される。料金のボリューム割引、リザーブドインスタンスの割引、 Savings Plans を共有できる。（会社、部門、またはプロジェクトでの料金が個々のスタンドアロンアカウントと比較して低くなる）

アクセス周り

・aws:PrincipalOrgID
グローバル条件キー。指定する組織に属するアカウントのみアクセスできるように設定できる。組織内のすべてのAWSアカウントのアカウントリストIDリストのように扱える。

効率よく組織内のAWSアカウントに関連付けられたIAM プリンシパル (ユーザーとロール) のみにリソースのアクセス制限を実行できる。

認証・認可サービス

[認証・認可の違い]

• 認証：その人が誰であるかを判別すること。
• 認可：その人が何を許可されているかを判別すること。

Cognito

・「認証」、「許可」、「ユーザ管理」をサポートしており、ユーザー名とパスワードを使用して直接サインインする方法もある
・ユーザーは Google、Facebook、Amazon、Apple などのIdp、および SAML ベースの ID プロバイダー経由でユーザープールに認証、サインインすることもできる
・開発者が更新された同期されたデータとしてイベントを受信できるようにKinesisストリームを設定できる

●Decode Authorization Message
エンコードされたエラーメッセージのデコードに役立つ。

ユーザープール

認証機能。アクセスできる認証トークン発行窓口。サインアップおよびサインインサービス。
ユーザーディレクトリとユーザープロファイルを管理する。

1. ユーザープールにユーザーが作成されると、Cognitoが一意のIDを割り振る。
2. IDトークン(JSON Web トークン (JWT) を発行し、IDプールへつなげる。

●ユーザーディレクトリ
認証情報保存。アプリ内部の領域でありIDやパスワードの認証情報を保存し、その情報を利用してアプリの「認証（アイデンティティの検証）」を行う。

IDプール

認可機能。認証トークンに対して一時的な権限(Credetials＝認可トークン)を発行する。
外部のIDプロバイダーによって認証されたIDに対して、STSと連携し、AWSへのアクセス権限（認可トークン）を払い出す。

※事前にIAMロールとSTSの紐づけが必要になる

・Webアプリケーションなどを想定し、認証されていないゲストユーザーにも一部のアクセス権を付与できる機能を持つ。
・フロントエンドからの各種 AWS サービスへのリクエストに、認可を提供することが可能。

[Credentials の実体]
IDプール に事前に設定された IAM ロール を、AWS STS がユーザーのリクエスト毎に発行するIAMロールと同等の権限を持った一時的な認証情報を指す。

[ID プールがサポートする ID プロバイダー]

パブリックプロバイダー：Login with Amazon(ID プール)、Facebook(ID プール)、Google(ID プール)、Apple でサインイン(ID プール)

Cognito ユーザープール

Open ID Connect プロバイダー (ID プール)

SAML ID プロバイダー (ID プール)

デベロッパーが認証したアイデンティティ (ID プール)

[Cognito ワークフロー]

1. ユーザーにパスワード、Emailを入力させてCognitoへリクエスト。
2. ユーザープールトークン(認証トークン)を取得。
3. ユーザープールトークンをIDプールトークン(認可トークン)と交換。
4. 認証もしくは認可トークンをヘッダーに設定しAWSの各サービスへリクエスト。

★SSOとCognitoの違い ●SSO：一度ユーザーを識別すると、その後アクセスできるようになる ●Cognito：アクセス要求を検証し、検証済みのユーザーのみを許可する ➡安全性の違いとして、Cognitoの方が良い　　　[参考サイト]

その他 Cognito機能

プッシュ 機能通知	自動的にIDとデバイス間の関連付けを追跡する。 IDデータが変更された時、特定のIDのすべてのインスタンスにプッシュ通知をする。 また、特定のIDの同期ストアデータが変更されるたびに、そのIDに関連付けられているすべてのデバイスが通知を受け取る
Cognito ストリーム	すべてのSyncデータをKinesisに移動して、分析するためにDWHにストリーミング処理ができる
Cognito Sync	認証したデータを共有することができるようになる。ログインしたユーザーデータやアプリケーションデータを複数のデバイス間で共有することができる機能を提供
Cognito イベント	Cognitoにおける重要なイベントに応じてLambda関数を実行できる
Cognito コールバック	データセットの同期に関するアクティビティのコールバックイベントを処理する

ACM

・無料
・有効期限は13か月で自動更新される
・SHA-256のSSL/TLSサーバ証明書の作成・管理を行う
・SSL/TLS 証明書の購入、アップロード、更新プロセスを手動で行う必要がなくなる

[認証・証明情報の格納場所]
以下2つはどちらもSSL/TLS通信で使われるが、役割が異なる。

トラストストア (信頼ストア)	信頼できる証明書（主にサーバー証明書）を格納され、証明書の検証に使用される。信頼できる認証局(CA)の証明書を格納したデータベース。　※これらの証明書は CA ルート証明書、つまり自己署名付き証明書を指す
キーストア	自身の公開鍵と秘密鍵を格納し、サーバー認証やクライアント認証に使用される。非公開鍵と関連する証明書、または非公開鍵と関連する証明書チェーンを含むデータベースから成る。証明書チェーンは、クライアント証明書と、1 つ以上の証明書発行局 (CA) の証明書から成る。

DNS検証

このデータベースに追加する必要がある 1 つ以上の CNAME レコードが ACM から提供される。
これらのレコードには、ドメインを制御する証拠となる一意のキーと値のペアが含まれている。

項目	パブリック証明書	プライベート証明書
発行元	公に認められた認証局	企業や組織が独自に構築した認証局
信頼性	ウェブブラウザやOSがデフォルトで信頼	信頼されるルート証明書
利用範囲	インターネット	企業内や組織内など限定された範囲
費用	有料	費用は低く抑えられている場合が多いが高め
本人確認	厳格な審査基準	厳格な審査基準は設けられていない
補足事項	・ACMはエクスポートできない	・ブラウザにルート証明書をインストールする必要がある

インターネットからアクセスするようなサービスの場合は、パブリック証明書で、組織内などのプライベートネットワークの場合は、プライベート証明書という使い分け。
[引用サイト]

リソースの共有

クロスアカウントアクセス

単発共有機能。複数のAWSアカウント間のリソースを一つのIAMユーザーで操作したい時に利用する。
設定にはIAMロールを使用する。

[設定の流れ]
アクセスを許可したいアカウントがIAMロールを作成する。
アクセスさせたいIAMユーザーにロールのアクセス許可をする。

Resource Access Manager

Transit Gateway、サブネット、AWS License Manager の設定、Amazon Route 53 リゾルバーのルールのリソースを RAM で共有できる。

・複数組織では管理や請求の分離を行い、エラーの影響を制限するために複数のアカウントを使用。

連携サービス

Transit Gateway	ネットワークやリソースの管理を一元化し、拡張性と管理の効率性を向上させる。
Organizations	複数のアカウントがOrganizationsで管理されている場合、以下よりユーザーは個々のアカウントにリソースを共有できる。 ①RAMコンソールまたはAWS CLIよりOrganizationsのリソース共有を有効にする ②上記、組織内でリソース共有を有効にすると、RAMが以下ロールを作成する。 　→AWSServiceRoleForResourceAccessManager ③上記ロールはRAMのみが引き受けることができる。

基礎知識

[ディメンションとメトリクスの違い]
・ディメンション
データの分析軸・データ項目のこと
・メトリクス
データの数値的な指標のこと取得、監視する項目

●タグ

リソースを整理するためのメタデータとして機能するキーと値のペア。リソース作成時にタグを追加できる。

Billing and Cost Management

AWSの各コスト管理サービスを一元化して管理するプラットフォームみたいなもの。各コスト管理サービスを呼び出す。コンソールへのIAMアクセスを有効にすることで特定のユーザーやチームに対してコンソールへのアクセスを許可できる。

[異常検出の要件]

項目	AWSサービスのコストモニタータイプ	Linked Accountのコストモニタータイプ
対象範囲	各AWSサービスごとのコストと使用量を詳細に監視	複数のLinked Account全体のコスト動向を監視
監視対象	個別のAWSサービスやリソース （リソース単位のコスト異常）	アカウント全体のコスト （統合的なコストトレンド）
異常検出の粒度	リソース単位の詳細なコスト異常を検出	アカウントレベルの大まかな異常を検出
通知のタイミング	サービスやリソースごとのコスト異常が検出された場合	アカウント全体でコストが一定のしきい値を超えた場合
適用シナリオ	特定のサービスやリソースの異常なコスト増加を迅速に特定したい場合	複数のアカウント間で全体的なコストの傾向を把握したい場合
運用チームへの通知の精度	詳細なリソース単位でのコスト異常を通知	総合的なコスト増加の通知 （詳細なリソースは不明瞭）
推奨される 使用ケース	特定のリソースやサービスのコスト最適化と、不要なリソースを早期に検出したい場合	コストの全体的なトレンドを把握し、全体の予算管理を行う場合

●(請求)ダッシュボード

毎月の使用量の概要と内訳を表示。

●コストカテゴリ

詳細なレポートや分析が可能になる。コストの分類と分析を実現。タグやアカウントに基づいてコストデータをグループ化するルール(コストカテゴリ)を定義できる。（例:カテゴリーTeam1）

Cost Explorer

※[請求とコスト管理] メニューから Cost Explorer → 有効化することで利用できる。

大まかにデータを分析。コストと使用量のデータを詳細に分析して「傾向、コスト要因、異常」を特定できる。

コストの最適化	適切なサイズ設定に関する推奨事項により実現可能。 (例: すべてのアカウントの合計コストと使用量)
コスト異常検出 (Cost Anomaly Detection)	機械学習モデルを利用して、AWSコストに異常が発生すると検出できる。想定外のコストが発生することを減らすことができ、アラートを受信することができる。

グラフ（ビュー）機能

当月データは約24時間後に反映される。以降、24時間以内に一回更新される。（※過去分：最大13ヶ月分まで）

フィルタリング / グループ化	コストと使用量のデータを深く掘り下げることができる。
カスタムレポート	作成、保存、共有することで、さまざまなデータセットを調査できる。 利用状況から今後３か月分の、時間範囲のコストと使用量の予測したレポートを作成できる。
ビジネスインサイトの 取得	コストと使用状況に関する情報、および設定済みのビューから確認できる。

Cost & Usage Report（CUR）

●使用状況レポート

「Cost Explorer」から設定した情報をもとにAWS上で使用しているサービス、料金、リザーブドインスタンス、SavingsPlansなど各種リソースの使用状況に関して、詳細な情報をCSV形式でS3に出力する。
（１日に最大３回レポートを出力可能）

・使用状況の種類や運用ごとに分類でき、レポートは1時間、1日、1ヵ月と単位を設定が可能。
・AWS アカウントで使用する AWS 製品、使用タイプ、オペレーションの固有の組み合わせごとに明細項目が表示される。
[※明細項目一覧]

●コスト配分タグ

コスト配分レポートでリソースコストを整理し、AWSコストの分類と詳細レベルの追跡を容易にする。既存タグはコスト配分タグにできない。配分タグをアクティブ化することで利用できる。なお、管理者のみ実行可能。

ユーザー定義型	コスト配分タグとしてアクティブ化することで独自のタグによりコストの分類、利用料金を把握することが可能となる。
AWS 生成型(createdBy)	誰がリソースを作成したか追跡できるAWSタグ。AWS生成タグを使用するには、管理アカウントの所有者がBilling and Cost Managementコンソールでそれを有効にする必要がある。

[ 例 ]
EC2 Instanceを複数台構築されている場合でも、1台ごとにNameタグを付与しておけば、Nameタグ別に利用料を出力することができる。

連携サービス

Redshift	S3に保存したファイルをRedShiftにアップロードすることで使用可能。
QuickSight	CURをS3に保存し、QuickSightダッシュボードからデータソースとして指定することで可視化することができる。
Athena	S3に出力されているレポートファイルにクエリを発行して条件別にデータ抽出が可能。

Budgets

●Saving Plans

使用状況を追跡し、特定の閾値に達した時、通知することができる。
※通知を行うサービスとして、Amazon SNS が推奨される。

●RI(リザーブドインスタンス)

• RI 使用率
  リザーブドインスタンス契約で設定した使用率未満だった場合にアラートを上げる。
  
• RI Coverage【カバー率 , 網羅立】
  RI で「カバーされている時間数」、「オンデマンドインスタンスに費やした金額」、および「追加の予約を購入した場合に節約できた可能性」がある金額が表示される。これにより、RI の購入が不足しているかどうかを確認できる。

[通知手段]

• メール
• SNS
• Lambda → 他チャットやSNSと連携

Saving Plans

・EC2、Fargate for ECSの利用料を最大72%削減。
・Fargate for EKSを最大52%削減。
・Lambdaを最大17%削減。SageMakerを最大64%削減。

Saving Plans 通知アラート	有効期限と予約期限に対するアラート機能。
EC2 Instance Savings Plans	同じリージョン内のインスタンスファミリーに適用される（最大72%の）割引プラン。サイズ、AZ、OS、テナンシーには影響されず、同じリージョンであれば選ばれたインスタンスファミリーの料金を削減できる。長期間にわたり継続的かつ安定した計算能力を提供する。 ・インスタンスのOS（Windows→Linux）に変更しても、割引は自動的に反映される。 ・特定のインスタンスタイプに適用され、他のインスタンスタイプは変更できない。
Compute Savings Plans	EC2インスタンスを使った量に対して自動的に割引される。インスタンスファミリー、サイズ、AZ、リージョン、OS、テナンシーすべてに対応している（最大66％割引）のプラン。そのほか、Fargateおよび Lambdaにも適用される。メモリやストレージよりも、計算処理能力（コンピュート）を重視。一貫したコンピューティング使用料を契約することでコストの最適化を図れる。
SageMaker Savings Plans	SageMakerを対象とする。 契約期間は1年または3年。 【料金体系】 ・利用者は「1時間あたりの使用量（$/hour）」を事前にコミット ・コミットした使用量までの利用には割引価格が適用される ・割引率：オンデマンド料金と比較して最大64%のコスト削減が可能

[Saving Plans と RI の比較]

	Compute Savings Plans	EC2 Instance Savings Plans	コンバーチブル RI*	スタンダード RI
オンデマンドに比べ節約	最大 66%	最大 72%	最大 66%	最大 72%
金銭的コミットメントと引き換えに価格を下げる	✅	✅	—	—
すべてのインスタンスファミリーに自動的に価格を適用	✅	—	—	—
すべてのテナンシーまたはOSに自動的に価格を適用	✅	✅	—	—
Fargate に自動的に適用	—	✅	—	—
Lambda に自動的に適用	—	✅	—	—
AWS 地域全体に価格を自動的に適用	✅	✅	—	—
1年または3年の期間オプション	✅	✅	✅	✅

適切なサイジング

可能な限り低いコストで、インスタンスの「タイプ」と「サイズ」、ストレージの「クラス」を、ワークロードのパフォーマンスとキャパシティ要件にマッチングさせるプロセス。
また、デプロイされたインスタンスを調べ、キャパシティや他の要件を犠牲にすることなく、それらのインスタンスを取り除いたり、ダウンサイジングしたりする機会を特定するプロセスでもあり、更なるコスト削減が狙える。

※組織が AWS クラウドに初めて移行する際に考慮されないことがよくある。

[ 例 ]
インスタンスのパフォーマンスおよび使用の必要性とパターンを継続的に分析し、アイドル状態のインスタンスをオフにする。オーバープロビジョニングされているインスタンスやワークロードとのマッチングが不十分なインスタンスを適切なサイズにする。