勉強で作ったxlsxファイルの抜粋。「内容」の列が自分で書いた箇所でマークダウンで見たらグチャグチャになっとる。

時間と共に劣化してくから、真実を書いてないこともアリ。

リンク先は「リンク」「blackbelt」とか短く表記したり、 カテゴリ 分割をgemini先生に３段階でお願いした。

それにしても長いページやな。

1
2

添付のマークダウンを変換して。
変換は、テーブルにあるURLリンク箇所を「リンク」と表示させてURLを埋め込んだ記法にしてダウンロードできるようにして。

1
2
3
4

添付ファイルのマークダウンで書かれたテーブルを以下のように更新してコードをコピペできるようにして。
1. 「サービス名」の列を１０文字程度で改行して<br>入れて
2. 「内容」の列を25文字程度で改行して<br>入れて
3. １つ目のテーブル２２４件、２つ目のテーブル５１件全部処理して

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

添付のマークダウンを変換してコードをコピペできるようにして。
1. １つ目のテーブル２２４件だけが対象で２つ目のテーブルは何もしない。
2. 「サービス名」の列を以下の分類に分割したテーブルにして
コンピューティング/コンテナ/ストレージ/データベース/デベロッパーツール/
ネットワークとコンテンツ配信/エンドユーザーコンピューティング/
フロントエンドウェブおよびモバイル/移行と転送/アプリケーション統合/
機械学習とAI/IoT/分析/メディア/セキュリティとアイデンティティ/
マネジメントとガバナンス/ブロックチェーン/ビジネスアプリケーション/
クラウド財務管理/その他

3. テーブルの中の「No」の列はテーブルそれぞれ１からリナンバして

やってたらgemini先生の使用制限がパンパンになっとった。

aws-limit

たまに更新しとこ。

awsサービス

コンピューティング

LightsailとOutpostsは使う場面ない。IMDSは今でもようわからん。

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS Lambda サーバーの管理なしにコードを実行できる
「サーバーレスコンピューティングサービス」
・CPUを明示的に指定できない。メモリに応じて
自動割り当て。
・同時実行＝１秒あたりの呼び出し数x平均実行時間。
・同時実行は１つのアカウントの同一リージョン
で１０００に制限（上限突破申請は可能）。
・上限に達するとスロットリング（サービス
制限がかかること）され実行されない
（４２９：TooManyRequestsException）。
・スロットリングエラーがあるかはlabmda
throttesメトリクスに対応するデータポイント
がないか確認する。
・予約済同時実行数制限の設定がある。
・予約実行可能数を超過したイベントは
スロットリング（イベントの処理停止）を
行い、キューに入る。
・キューに入ったイベントは、Lambdaの同時
実行数が予約実行可能数以下になると順次処理される。
・キューに入ったイベントの順番保証はされない。
・予約コンカレンシーを設定すると、関数ごとの
最大同時実行数を制限でき、他の関数がシステム
全体の同時実行上限を圧迫されてしまうのを防げる。
・GPUはサポートしていない。
・短時間・小規模のタスクには適しているが、
継続的な映像処理などには向かない。		 リンク
2 Lambda@
Edge		 cloudfrontのエッジロケーションから
コードを実行するLambda関数のことで、
ユーザに近い場所でコードが実行されるので
高速なコンテンツ配信が可能になる仕組み。
・Lambda関数はバージニアリージョンで
作成する必要がある。
・ログが保管されるリージョンは、ユーザーから
最も近いエッジロケーションとなる。
・CloudFront に送信されるクエリパラメータ
を正規化（小文字変換・アルファベット順
にソート）できる。これにより、同一の意味
を持つリクエストが常に同じキャッシュキーに
マッピングされ、CloudFront のキャッシュ
ヒット率を大幅に向上させることができる。
・エッジロケーション（地域）に応じて表示
させるコンテンツを変えられる。
・User-Agentなどに応じて取得する
コンテンツを変えられる。
・アクセス元のIPアドレスによって表示
させるコンテンツを変えられる。
・実際に叩かれるURLと、S3などから実際
に取得する資源のURIを変更できる。
・Lambda @Edge は CloudFront
のキャッシュの操作はできるが、データ
キャッシュを提供しない。さらに、Lambda
@Edge は Node.js と Python のみ
をサポートする。Javaなどはサポートしない。		 リンク リンク
3 Amazon
Lightsail		 コスト最優先の軽量サーバ。
・一度作成したインスタンスの変更はできない。
・SnapshotをEC2にエクスポートする
機能により、後からEC2に移行することが可能。		 リンク リンク リンク
4 AWS Elastic
Beanstalk		 ・コードをアップロードするだけでフルスタック
のアプリケーションをデプロイできる。
・抽象化が強く、リソース最適化が難しい。
・ステージング環境で新バージョンを事前検証
し、CNAME のスワップにより本番環境へ即時
切り替えが可能。これにより、1日複数回の更新
にも対応でき、かつ不具合発生時には旧バージョン
へ即時ロールバックが可能。
・動的コンテンツには向いているが静的ホスティングには不向き。
・EC2 ベースのアプリケーションに適したサービス
であり、サーバーレスアーキテクチャには適していない。
・Immutable デプロイポリシーは、新しい
インスタンスグループを作成し、既存のインスタンス
に影響を与えずにデプロイを行うため、失敗時
にロールバックが速い。
・All at Once デプロイポリシーは、
すべてのインスタンスを同時に更新するため、デプロイ
中にサービスの中断が発生する可能性がある。
・Rolling デプロイポリシーは、インスタンス
を順次更新することでサービスの継続性を保ち、
デプロイ中に一部のインスタンスが古いバージョンの
ままであるため、一貫性のある環境を提供する
“Immutable” デプロイポリシーほどの信頼性はない。
・ローリングと追加バッチによるローリングの違い
は更新中にEC2インスタンスの台数が減少するか
維持されるかで、コストとパフォーマンスのどちら
を取るかで選ぶことになる。
・トラフィック分割デプロイポリシーは、新しく
AutoScalingGroupを作りトラフィック切り替え
を行い更新する。		 リンク リンク リンク
5 AWS Elastic
Beanstalk		 ・イミュータブルとトラフィック分割の違い
は新旧のバージョンに流れるトラフィックを厳密
に管理できるか出来ないか。イミュータブル
の場合、一時的にランダムで新旧どちらかの
インスタンスにトラフィックが流れる。一方、
トラフィック分割の場合、新旧それぞれに流す
トラフィックの割合を制御することができる。
そのため、Canaryリリースではトラフィック分割
を利用する。
・Elastic Beanstalkのデプロイメント
オプションにはないBlue/Greenを実現したい
場合にはRoute53を用いたURLのスワップが必要。		 リンク リンク
6 AWS App
Runner		 ウェブアプリケーションを自動的にデプロイし、
暗号化・負荷分散・スケールするサービス
・WAFへの対応
・Secrets ManagerとSystem
Managerからのシークレットと設定の取得
・Bitbucketソースコードリポジトリをサポート
・GPU非対応
・簡易デプロイに適するが、複雑なパイプライン
や細かいデプロイ制御には不向き
・cloudfrontとの統合は非標準		 リンク リンク blackbelt
7 AWS Batch 大量のコンピューティングバッチワークロードを
実行するためのフルマネージドサービス。小規模
なLambdaワークロードには過剰。サービス
単体での課金はない。
・リージョン内の複数のAZ間で実行中のバッチ
ジョブを簡略化する
・VPC内に環境を作成できジョブキューに関連
付けられた後でジョブを実行する。
・Dockerコンテナイメージを指定するジョブ
定義を指定できる。
・コンテナベースの実行環境を提供し。必要なとき
だけリソースを確保し、処理後には自動でスケール
ダウンするため、コスト効率が非常に高く、
スケジューリングもEventBridgeと連携できる。
・複数のazを指定することで耐障害性が上がり、
vcpu=0にしておくと使用しないときには
インスタンスが起動しない設定となる。
・インスタンス起動には配分戦略がある(Fargate
リソースで実⾏されるジョブには適用されない)。
1)BEST_FIT (デフォルト)
最もコストの低いインスタンスタイプを優先して、
ジョブのニーズに最も適したインスタンスタイプを
選択。選択したインスタンスタイプの追加インスタンス
が利湧できない場合、AWS Batch は追加
インスタンスが利湧可能になるまで待機する。
2)BEST_FIT_PROGRESSIVE
キュー内のジョブの要件を満たすのに⼗分な
⼤きさのインスタンスタイプを追加で選択。単位
vCPUあたりのコストが低いインスタンスタイプが優先される。
3)SPOT_CAPACITY_OPTIMIZED
(スポットインスタンス向け)
キュー内のジョブの要件を満たすのに⼗分な
⼤きさのインスタンスタイプを 1 つ以上選択。
中断する可能性が低いインスタンスタイプが優先される。
4)SPOT_PRICE_CAPACITY_OPTIMIZED
(スポットインスタンス向け)
価格とキャパシティの両⽅を考慮して、中断される
可能性が最も低く、価格ができるだけ低いスポット
インスタンスプールを選択。この配分戦略は、
スポットインスタンスのコンピューティングリソース
でのみ使湧できる。		 リンク リンク blackbelt
8 AWS Outposts ローカル環境でのデータ処理や移行、低レイテンシー
を維持したいという目的で専用のハードウェア
一式をオンプレの環境に設置して、オンプレ
にAZが増えたイメージで扱うサービス。
・専用ラックを置いてAWSから管理してもらえる。
エンタープライズサポートプランに入る必要がある。
・EC2, S3, EKS などの AWS
サービスが実行可能。		 リンク リンク
9 EC2 仮想マシン。RDSやFargate、ECS/
EKSのバックエンドで動くノードもコレ。
・スポットインスタンスは中断リスクがある。
・EC2 インスタンスの認証情報ストアの
アクセスキーはプレーンテキストであり永続的。
・AMIを別リージョンから参照させることは
できない。コピーする必要がある。
・ウェブサーバーやアプリケーションサーバー
など、CPUをフル活用しないワークロード向け
にコスト最適化されたAmazon EC2インスタンス。
通常のインスタンス（M7i, C7iなど）
と比較して、低価格で同等の高い価格性能
（最大19%向上）を提供し、ベースライン
CPU性能が保証されつつ、必要に応じてフル
パフォーマンスにスケールアップできるのが特徴。
・tシリーズのインスタンスではバーストが
可能で、standardモードではなく、unlimited
モードが選択できる。unlimitedモードで
バーストが発生すると、追加料金を支払う必要
があるが性能を維持できる。代わりに請求が青天井。
・ハイパースレッディングは、ハイパー
スレッドごとに 1 つのプロセス (コア
ごとに 2 つのプロセス) を許可すること
により、一部のアプリケーションのパフォーマンス
を向上させるが、ほとんどの HPC アプリ
ケーションは、ハイパースレッディングを無効
にすることでメリットを得る。		 リンク リンク リンク blackbelt
10 EC2 Image
Builder		 Amazon マシンイメージ (AMI) と
コンテナイメージのカスタマイズ、テスト、配布、
ライフサイクル管理を簡素化するフルマネージド型
のサービス。		 リンク リンク
11 ゴールデンAMI 事前に構成された環境をマシンイメージ化し、
テンプレートとして使えるようにしたもの。この
イメージは、新しいハードウェアや仮想マシンに
迅速にデプロイするための使用される。EC2
を普通に起動するときに使うもののことらしい。
自前のカスタムイメージやバックアップイメージとは別。
・awsが所有者になっているamiに、
windows2025日本語版で直近のwindows
updateが適用されたものがある。これを
そのまま使うと日本語化やwindows update
の実施が省ける。		 リンク
12 Amazon EC2
Spot Fleet		 予め最高価格と復数のインスタンスタイプと
Availability Zoneを設定しておくことで
その中で一番安いスポットインスタンスをn個
用意するということを自動で出来るようになる。
・Auto Scaling と連携させることで、
トラフィックの急増にも動的に対応でき、障害
時の復旧もスピーディに行える。特に短期間のピークに最適。		 リンク リンク
13 EC2 Auto
Scaling		 アプリケーションの負荷を処理するために適切な
数の Amazon EC2 インスタンスを利用
できるようにする。
・動的ポリシーとして、シンプルスケーリング、
ターゲット追跡、ステップスケーリングが利用
可能。マニュアルのスケーリングもある。
・「Terminate」プロセスを一時的に停止
することで、ALB によって非ヘルシーと判定
されたインスタンスがすぐに終了せずに残る。		 リンク リンク blackbelt
14 プレイスメント
グループ		 複数のインスタンスを論理的にグループ化して、
パフォーマンスの向上・耐障害性を高める機能。
・クラスタープレイスメントグループ
->単一AZ内のインスタンスを論理的にグループ
化したインスタンスのプレイスメントグループ。
ハイパフォーマンスコンピューティング (HPC)
アプリケーションで典型的な緊密に組み合わされた
ノード間通信に必要な低レイテンシーネットワーク
パフォーマンスを実現できる。
・パーティションプレイスメントグループ
->障害に対応するためのプレイスメントグループ
で、グループをパーティションと呼ばれる論理的
なセグメントに分割する。
・スプレッドプレイスメントグループ
->それぞれ独自のネットワーク、電源がある
異なるラックに1つ1つのインスタンスを分割する。
・プレイスメントグループは利用できる
インスタンスタイプが制限されていることもある。
・Tシリーズは対応していない。		 リンク リンク
15 Amazon
Elastic
VMware
Service
(Amazon EVS
)		 VMware Cloud Foundation
(VCF) を Amazon Virtual
Private Cloud (Amazon VPC)
内で直接実行できる。
・大阪リージョンは使えず、シングルazでの
提供のみ。I4i.metalインスタンスを使う。
VCFは5.2.1。
・ビジネスサポートまたはエンタープライズ
サポートが必要で、最初に「環境あたりのホスト
数のアカウントレベルが４以上」のサービス
クオータの緩和が必要。
・vmotionさせることで、オンプレから
awsへシームレス移行が可能。		 リンク リンク blackbelt
16 amazon Linux awsが提供するlinux。最新は2023
でカーネルサポートが4年ある。マイナー
バージョンは四半期ごとにリリース、隔週
でセキュリティリリースがある。
・Fedoraのepel9から派生したspal
(security package for amazon
linux)というのがあり、amazon linux2
から2023への移行が便利になっている
(cveトラッキング対象外、セキュリティ
アップデートはepel9から行う必要あり)。
・amazon linux2から2023への自動
アップグレードや差分確認、移行のツールは存在しない。		 リンク
17 IMDS
(インスタンス
メタデータ
サービス)		 インスタンスメタデータはインスタンスに関する
データで、実行中のインスタンスを設定または
管理するために使用する。
・インスタンスメタデータサービスバージョン
2 (IMDSv2) – セッション指向メソッド
・インスタンスメタデータサービスバージョン
1 (IMDSv1) – リクエスト/レスポンスメソッド
・インスタンスメタデータV1はアクセスが簡単
だがセキュリティが弱く、インスタンスメタデータ
V2はアクセスが少し複雑だがセキュリティが強化されている。
・IMDSv2を使用しなければならないように
指定すると、IMDSv1はもう機能しなくなる。		 リンク リンク
18 Elastic
Fabric
Adapter
(EFA)		 高性能コンピューティング（HPC）や機械学習
などの低レイテンシ・高スループット通信を
必要とするワークロード向けのネットワークインターフェース。
・OSバイパスして超低レイテンシの通信が可能。
TCP/UDPではなくRDMAでの通信を行う。
・EFA対応のインスタンスを選択し、AMIも
対応しているものを選ぶ(amazonlinuxやubuntu)。		 リンク リンク
19 Instance
Connect		 AWSマネジメントコンソール上(ブラウザ上)
からSSHを利用してサーバにアクセスができるサービス。
・秘密鍵/公開鍵の設定を行わずとも、安全
にサーバへSSH接続を実施することができるが
amazon linux/ubuntu限定。
・接続時にsshのキーペアが作成され、ec2
インスタンスへのパブリックキー登録、プライベート
キーによる認証と接続が行われるためsshキー
を管理する必要がなくなる。
・ec2インスタンスはssh接続ができ、
パブリックIPが付与されている必要がある。
・aws systems session manager
を使う方がベター。		 リンク リンク

コンテナ

docker大好きでmicrok8sも普段使うけど、EKS Distroって使ったことないな。使い始めるきっかけがないと使わん。App2Containerってどうなんやろ。

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS Fargate サーバーレスで従量制料金のコンピューティング
エンジンであり、サーバーを管理することなく
(パッチ適用不要)アプリケーションの構築
に集中することができる。
・CPUとメモリの最大値、ネットワーク、
コンテナの制御、並びに同時実行数に制限がある。
・Fargate spotは割安。全てのアカウント
のクラスターでいつでも利用可能だが、これ
だけで構成するのはリスクあり。
・Compute Savings Plans 対象
にはなっている。
・EKSではなくECSのみだが、Fargate
Spot と Fargate Graviton による
コスト削減が可能。
・コンテナを特権モードで起動できず、
sshによるホストアクセスも不可能。
・ネットワークモードはawsvpcモード
のみが選択可能。
・Fargateバインドマウント/エフェ
メラルストレージが利用できるが、揮発性
のストレージでコンテナ停止時には削除される。
20GiBまで無料。		 リンク リンク リンク リンク
2 Amazon EKS kubernetesクラスタ。Fargateあり
での運用も可能。
・EKS マネージド型ノードグループを
利用するとEKSがノードを管理してくれる。
・マネージド型ノードグループ/セルフ
マネージドノード/Fargateは併用できる。
・Compute Savings Plansを活用して
EKSのベースをカバーし、ピーク時には
Spot Instancesでスケーリングする構成
にすると安価に対応できる。
・Dedicated Hostsは専有ホスト
なのでコストが高め。
・Fargate Spotには対応制限があり
全体の基盤を移行するのはリスクがある。
ECS専用の機能でEKSでは利用できない。
・FargateのサポートはAWSリージョン
内、またはAWS Outpostsなどの特定
のAWS環境に限定されているので、オンプレ
ミスのインフラストラクチャ上で動作する
EKS AnywhereではFargateを利用できない。
・クラスタスケーラーにはcluster
autoscalerとkarpenterがある。		 リンク リンク blackbelt
3 Amazon EKS
Distro		 EKSで提供されるKubernetesの
ディストリビューションをオンプレミスや
他のクラウド環境でも利用できるようにした
オープンソースのソフトウェア。		 リンク リンク
4 Amazon ECS dockerの豪華版、なんちゃして
kubernetesだができることは多い。管理
方法はkubernetesとは違って固有。クラスタ
作成し、ノード指定はEC2/Fargate/
オンプレコンテナ環境が使える。AWS上で
Dockerコンテナを簡単にデプロイ、管理、
スケーリングできる、フルマネージド型の
コンテナオーケストレーションサービス。
・hostモード
全タスクがホストと同じネットワーク空間
を共有する。個別制御はできない。
・bridgeモード
タスク単位でENIが作成されず、細かい制御は不可。
・awsvpcモード
各タスクに個別のENI（Elastic
Network Interface）を割り当てられ、
セキュリティグループとIAMロールをタスク単位
で分離できる。・リザーブドインスタンス
は柔軟性が乏しく、変動トラフィックには不向き。
・スポットインスタンスはコスト削減に効果的
であり、ドレイニングを有効にすることで、
インスタンス停止前にタスクを他のインスタンス
へ安全に移行でき、サービス中断のリスクを抑えられる。
・docker execのようなaws ecs
execute-commandがある。		 リンク リンク
5 Amazon ECS
Anywhere		 オンプレミスインフラストラクチャでコンテナを実行。
・実行環境となるサーバー、仮想マシンには
Docker がインストールされている必要がある。
・実行環境となるサーバー、仮想マシンに
AWS Systems Manager の SSM Agent
をインストールし、ハイブリットアクティベート
によりマネージドインスタンスとして登録する必要がある。
・ELB をサポートしておらず、Service
Load Balancing を利用できない。
・他クラウドの VM を External
インスタンスとして登録してコンテナ実行することは可能。		 リンク リンク
6 Amazon ECS
EC2 スポットインスタンス		 「未使用のEC2キャパシティ」を最大
90%OFFの格安料金で利用できる購入
オプション。ECS Cluster Autoscaling
のcapacity providerで管理される。
・格安の料金: オンデマンドインスタンス
と比べて最大90%のコスト削減が可能。
・突然の中断: AWSの容量が必要になると、
インスタンスが強制終了（または停止）される。
終了の2分前に警告が通知される。
・変動する価格: 市場価格（スポット価格）
に基づいて価格が変動する。
・柔軟なユースケース: データ解析、CI/
CD、テスト環境、バッチ処理など、中断
されても問題ない（ステートレス）処理に向いている。
・スポットフリート / Auto Scaling:
スポットインスタンスを自動で管理し、中断
されたら別のインスタンスを自動的に立ち上げる
機能と組み合わせる。
・中断通知の活用: 中断の2分前通知
を受け取り、作業中のデータ保存（チェック
ポイント）を行う。
・ステートレスな設計: インスタンスが突然
消えてもシステム全体に影響が出ないようにする。		 blackbelt リンク
7 Amazon
Elastic
Container
Registry
(ECR)		 Dockerのコンテナイメージを保存しておく
ためのレジストリ。
・利用にはインターネットアクセスが必要で、
プライベートサブネットではNATゲートウェイ
を作成しておく必要がある。またはPrivateLink
でエンドポイントを用意する。		 リンク リンク リンク
8 AWS
App2Container
(A2C)		 既存の.NET および Java アプリケーション
をコンテナ化するためのツール。		 リンク
9 Amazon
Lightsail
Container
Service		 スケーラブルコンピューティングとネットワーク
リソースで、コンテナをデプロイ、実行、
管理することができる。
・armはNGでx86のみ。		 リンク リンク

ストレージ

AWS Backupは裏側でs3みたいな感じで普段めっちゃお世話になってる。

ボールトロックしてコンプライアンスモードにもした。

Lifecycle Manager使う場面が運用では一回もない。

No サービス名 内容 URL1 URL2 URL3 URL4
1 Amazon FSx
for
Windows		 WindowsServerのストレージを
利用できるマネージドサービス。
・CloudwatchでFreeStorage
Capacity メトリクスを監視し、
アクション用にAWS Lambda 関数を
作成して呼び出すと、Amazon FSx
の容量を自動拡張 するように設定できる。		 リンク リンク リンク
2 Amazon FSx
for Lustre		 高性能コンピューティング(HPC)で
求められるような高性能な分散ファイル
システム。Luster（ラスター）はスパコン
で利用されるようなファイルシステム。
・普段利用しないデータをs3に退避して
おき、遅延ロード(最初にアクセスしたとき
にS3から取ってくる)して利用し、処理終了
後にFSxボリュームを削除することでコスト
を抑えられる。
・linuxホストのみ利用可能。		 リンク リンク リンク
3 Amazon S3 ファイル設置のためのバケット利用。「フォルダ」
という考え方はないらしいが、擬似的に実現できる。
・S3 Transfer Accelerationは高速
アップロードには有効、ストリーミングデータ
のリアルタイム配信には不向き。
・MFA deleteを使うとオブジェクトの
誤削除防止、バージョニング維持ができる。
・Object Lock機能を使用すると、
WORM（Write Once Read Many）
方式でログを保管でき、改ざん防止が可能。
・大陸間で定期的にGBからTBのデータを
転送する場合、Transfer Accelaration
を有効にすると速くなる。1GBアップロード
あたり、$0.04 が上乗せされる。アップロード
に失敗したときのため、「不完全なアップロード
を削除」のポリシーを有効化しておくと不要データ
での課金が防げる。
・VPCエンドポイントのエンドポイントポリシー
で(aws:SourceVpce)、対象S3バケット
に限定し、EC2にIAMロールを付与する
ことで、アクセス制御をIAMポリシーとバケット
ポリシーで二重に適用可能。
・サブネットIDをバケットポリシーで制御する
ことは未サポート。
・aws:SourceIp はインターネット経由
のIPアドレスにしか対応していない。プライベート
IP制御には適さない。
・aws:PrincipalArn による制御は IAM
レベルの制限を行う。
・バケットのBlockPublicAclsが有効
になっていると、オブジェクト単位でACLを用いた
パブリック設定はすべて拒否される。
・電子証明書を保存するのはセキュリティ
リスクあるのでアカン行為。
・S3アクセスログにはIPアドレスが含まれ、
Athenaを使って分析可能。		 リンク リンク リンク
4 Amazon S3
Pre-signed
URL		 権限のあるIAMユーザか、ロール付与がなければ
S3利用できないが、Pre-signedURL
を利用することで一時的にアクセスが可能。
・URL有効性のチェックはリクエストを受け付けた
タイミングで行われる。大きなファイルをダウンロード
中に有効期限を過ぎてしまっても、ダウンロード
中に通信が切断されることはない。
・Pre-signed URLによるリクエスト＝
当該のIAM Entity(User/Role)による
リクエストなので、IAMユーザやロールが削除
されると、アクセスは拒否される。
・EC2 インスタンスから利用する時、
~/.aws/credentials 設定ファイル
に必要な AWS 認証情報が適切に設定されて
いないと、アクセスに失敗する。		 リンク
5 Amazon S3
File Gateway		 s3へのファイルインターフェイスをサポート
し、サービスと仮想ソフトウェアアプライアンス
を組み合わせる。この組み合わせを使用すると、
NFSやSMBなどを使用して、Amazon
S3 でオブジェクトを保存および取得可能。		 リンク リンク
6 S3 storage
lens		 オブジェクトストレージの使用状況や
アクティビティの傾向についての組織レベル
の可視性を提供し、コストの最適化、アプリ
ケーションパフォーマンスの改善、データ保護の
強化のための実用的なレコメンデーションを提示する。
・監視対象オブジェクト数に応じて料金が発生する。		 リンク リンク
7 SSE-S3 追加料金なし。Amazon S3 が各オブジェクト
を個別のデータキーで暗号化し、そのキーを
さらにローテーションされるマスターキー（内部
的に管理される）で暗号化することで、多層的
なセキュリティを提供している(自動ローテーション)。
すべては Amazon S3 により自動で処理され、
AES-256 が使用される。		 リンク
8 SSE-KMS 従量課金あり。キーはユーザ管理。手動または
自動でキーのローテーション可能。Cloudtrail
のログで使用状況を監査可能。		 リンク
9 SSE-C 追加料金なし。キーはユーザ管理。独自の暗号化
キーでデータを暗号化でき、ローテーションも
ユーザ管理。あまり使われず非推奨っぽい。		 リンク
10 Amazon S3
Intelligent-Tiering		 パフォーマンスへの影響、取り出し費用、運用上の
オーバーヘッドなしに、アクセス頻度に基づいてデータ
を最も費用対効果の高いアクセス階層に自動的
に移動することにより、きめ細かいオブジェクト
レベルでストレージコストを自動的に削減できる
ストレージクラスの一種。		 リンク リンク
11 Amazon S3
Storage
Lens		 オブジェクトストレージおよびアクティビティ
を組織全体で可視化するために使用できる
クラウドストレージ分析機能。		 リンク リンク
12 AWS Backup EC2やRDSをバックアップできる。
・バックアッププランの定義で、タイミング
(cron式指定で複数指定可能)や保管期間を指定する。
・AMI作成されるので、EC2はそこから復元できる。
・バックアッププランでグループを作り、
グループ単位でのバックアップができる。
・PITRは、対象のリソース（s3、RDS、
Aurora、SAP HANA）に適用でき、「ポイント
インタイムリカバリ（PITR）の継続的な
バックアップを有効にする」オプションを選択する
だけで、一元的に管理・設定できる。
1)s3はバージョニング必要、dbはバックアップ
ウィンドウの手動設定ができなくなる。
2)rds oracle/sqlserverはPITR
サポート外。(スナップショットが取得されるのみ)
3)実際にバックアップ取得すると「continuous」
として１つのジョブ結果が表示される。
4)リストアは、s3:直近１５分、rds:
直近５分に戻せる。
5)１つのリソースには１つのバックアップのみ。
複数のバックアップは取れない。		 リンク リンク リンク
13 Amazon Data
Lifecycle
Manager
(DLM)		 EBSの定期スナップショットと EBS-backed
AMI の作成、保持、削除を自動化できる。
・他の方法で作成されたスナップショットまたは
AMI を管理することはできない。
・EBS Direct API で S3 にデータをエクスポートできる。		 リンク リンク
14 Amazon
Elastic
Block Store
(EBS)		 EC2につけて使うブロックストレージ。ドライブとして利用。
・AZをまたいで共有できないので、複数AZでの同時運用は
できない。
・st1はスループット最適化型であり、ランダムIOPS
を要求する処理には不適。sc1はコールドhddで
さらに低コスト。
・io2は高耐久・高性能だがコストが高い。dbms向き。
・gp2 ストレージはストレージ容量に応じた
IOPS（3 IOPS/GB）を提供し、クレジット
を消費してバースト性能を実現する。ピーク時間帯
にクレジットが枯渇すると、ベースライン性能に
戻り、I/O 処理が著しく遅延する。gp3へオンラインで
変更可能。
・Gp3はプロビジョンドIOPSとスループット
の設定が柔軟で、コストを大幅に削減しつつ
必要な性能を確保できる。
・NVMe/HDDインスタンスストアは揮発性。
・暗号化すると1年に１回自動でキーが
ローテーションされる。		 リンク リンク
15 Amazon EFS フルマネージドのNFS(NFSv4.1 および
NFSv4.0) 。800万TBの容量がある。
S3はオブジェクトストレージ、EFSはファイル
ストレージで耐障害性はどちらも99.9999999%
（イレブンナイン）。
・S3よりも価格は高い。EC2+EBSでNFS
を構築するよりも安い。
・Provisioned Throughput モードを
使用すると、必要なスループットを確保でき、
EBS よりもコストを抑えながら高性能を維持できる。
・データ保管サイズによって最大２倍のバーストがある。
・AZそれぞれにマウントターゲットを作成しSG
を設定して接続できる。ネットワークACLによる設定も
可能。
・クライアントはnfs-utilsでも利用可能
だが推奨はamazon-efs-utils。TLS通信ができる。
・cp/rsyncよりも５倍高性能なefs file
syncが利用可能。
・パフォーマンスモード(汎用/最大I/O)
を変更するにはファイルシステムを再作成必要。
汎用モードでメトリクスPercentIOLimit
が限界に近い場合は最大I/Oモードでの利用を
検討するといい。		 リンク リンク blackbelt
16 AWS Storage
Gateway		 オンプレミスのソフトウェアアプライアンスを
クラウドベースのストレージと接続し、お客様の
オンプレミスの IT 環境と AWS のストレージ
インフラストラクチャとの間にデータセキュリティ
機能を備えたシームレスな統合を実現するサービス。
・標準プロトコル (Internet Small
Computer System Interface (iSCSI)、
SMB、NFS) を使用して接続を実行。
・StorageGatewayアプライアンスと
AWS間の通信はTLS暗号化。
・プライベート接続にはVPCエンドポイントを
構成する(S3はゲートウェイ型ではなくインターフェース型)
・iscsiでCHAP を使用して接続元イニシエータ
を明示的に認証可能であり、企業向けハイブリッド
構成ではベストプラクティス。
・ゲートウェイストアドボリュームは、Amazon
EBS スナップショットとしてバックアップ可能。
・３種類のゲートウェイが存在する。
ファイルゲートウェイ：S3ファイルゲートウェイ(smb/
nfs)またはFSxファイルゲートウェイ(smb)を使用して保存。
テープゲートウェイ：仮想テープライブラリ(VTL)
設定と既存のバックアップソフトウェアを統合して利用
(iSCSI)。テープををS3で置き換え、S3Glacier
およびS3 GlacierDeepArchiveで長期アーカイブが行える。
ボリュームゲートウェイ：S3とEBSスナップ
ショットを利用する(iSCSI)。ブロックボリューム
をローカルに保存またはキャッシュし、
必要に応じてクラウドで復元。		 リンク リンク blackbelt

データベース

普段はRDSしか使わん。NoSQL系の使ってみたいけどリクエストがないと想像の中にしかない。

No サービス名 内容 URL1 URL2 URL3 URL4
1 Amazon
DynamoDB		 NoSQLデータベースサービス。グローバル
テーブル設定可(書き込みを他の AWSリー
ジョンのレプリカテーブルに自動的に伝播)。
・コールドスタート、バージョンアップ
グレード、メンテナンスウィンドウがない。
・サーバレス、複数リージョンでの構成ができ
ファイブナイン(99.999%)の可用性、
１桁ミリ秒のパフォーマンス、サーバレス
(稼働状況把握できない)、PartiQLという
SQL互換のクエリ利用可能
・Provisioned Throughputで「どの
ぐらい読み書きするか」を設定。プロビジョニング
されたスループットに対して課金され、実際の
読み書きは関係ない。その他、データ転送料
と保存料が課金される。
・Provisioned Throughputの容量を
超えるとリクエストが失敗する。
・I/Oのリクエストは常に「失敗するかもしれない」
という考慮が必要で、SQSでキューイングする
などしてリトライし現象回避させる。
・DynamoDBグローバルテーブルは、マルチ
リージョン間でリアルタイムかつ双方向にデータ
を同期でき、トランザクションシステムのような
更新頻度の高いアプリに最適。
・接続はVPCエンドポイントを用いるか、
NAT Gateway経由でインターネット経由
の接続を行う。
・キー・バリュー型の高速なトランザクション
処理に向いているが、全文検索や大量の非構造化
データ検索には適していない。
・定期スケジュールにより、ピーク時間帯に先回り
して書き込みキャパシティ(wcu:write
capacity unit)を増強できる
・Amplifyとの統合もスムーズ。
・Amazon DynamoDB Accelerator
(DAX) を導入して、読み取りキャッシュの
レイヤーを構築すると読み取り性能が上がる。
・継続的で大量なストリーミング処理には向かない。
バイナリデータ保管に向かない。		 リンク リンク リンク blackbelt
2 DynamoDB
ストリーム		 NoSQL（キー/バリュー）データベース。
DynamoDB のテーブルのデータに変更があった
時にその変更情報を暗号化してログに保存しておく。
・DynamoDB のテーブルのデータに変更があった
時に、その変更情報を暗号化してログに保存
・変更をトリガーにリアルタイム処理が可能
・テーブルへのアクセスとストリームへの
アクセスのエンドポイントは別々
・テーブル作成時だけでなく作成後でも有効・
無効を設定でき、パフォーマンスに影響しない
・ストリームレコードは 1 つの変更に関するデータ
・ストリームレコードが集まるとシャード
・ストリームレコードとシャードを含む全体がストリーム
・変更データは 24 時間を超えるとすぐに削除
される可能性がある
・無効にすると 24 時間は保持され、手動削除は不可		 リンク
3 Amazon
Keyspaces		 フルマネージド型のNoSQL（カラム指向）
データベースサービス。Apache Cassandra
と互換性があり、スケーラブルで高可用性のある
分散データベースを提供。オンプレミスや既存の
Cassandraベースのアプリケーションを
AWSに移行する際に最適。
・Cassandra Query Language
(CQL) に完全対応。
・既存のCassandraツールやアプリケー
ションをAWSに移行可能。
・手動でのクラスタ構築やメンテナンスが不要。
自動スケーリングにより、大量のトラフィックや高スループットに対応。
・使用したスループット（読み取り/書き込み）
とストレージに基づいた課金。
・特にIoT、時系列データ、セッション管理、
レコメンデーションに適している。		 リンク リンク
4 AWS Advanced
JDBC
Wrapper
Driver		 ネイティブの PostgreSQL 、MySQL、
MariaDB の JDBC ドライバーを”ラップ”
し、ドライバー機能を拡張したもの。
・TCPキープアライブとJavaDNS
キャッシュの有効期限を短く設定し、RDS
proxyと併用することで、DBクラスタの
切り替えがスムーズになるらしい。
・アプリケーションコードに認証情報を埋め込ま
ない事によるセキュリティ向上を実現(Secrets
Manager 利湧時は Jackson Databind
のライブラリが必要)。
・HikariCPなどコネクションプーリングと互換性がある。		 リンク
5 Aurora
PostgreSQL/
MySQL/DSQL		 PostgreSQL、MySQL、DSQLを提供。
高性能だがコストが高く、中規模システムには
過剰なのでRDSのクロスリージョンリードレプリカ
と必要時の自動昇格を使うほうが安く済む。
・クラスター構成を採用している。自動的
に６箇所に複製される。
・RDSと比較して利用できるバージョンに差異がある。
・エラーログはデフォルトで有効。
・オンプレとの直接的なレプリケーションには対応していない。
・書き込みはプライマリリージョンに限定
されるため、即時双方向同期には適さない
(->Dynamo)。
・Auto Scaling はレプリカに対して
動的なスケーリングを提供することで、読み取り
性能の最適化を実現。
・DSQLは北米のみマルチリージョンクラ
スターを提供。アジアやヨーロッパはシングル
リージョンクラスターのみ提供。
・Amazon Aurora レプリカは、1つ
の共有ストレージボリュームを複数の読み取り
専用インスタンス（最大15個）で共有する、
高可用性・高性能なAWSの機能。
・クラスターエンドポイントはプライマリDB
に接続、読み取りエンドポイントはリード
レプリカに接続、カスタムエンドポイントは
プライマリと読み取りエンドポイントの両方
を接続対象に指定できる。		 リンク リンク リンク リンク
6 Aurora Global
Database		 リージョンを跨いでDBを同期してくれる機能。
リージョン間のDB同期をAWSがマネージドで機能提供。
・３つのAZに渡って６重化されてデータが保持される。
・Oracle/db2のバックアップをそのまま
インポートする機能は持たない。Amazon DMS
を使う。Postgresqlやmysqlはバイナリ
ダンプではないのでインポート可能。
・数秒以内にデータを複数リージョンに複製
できる設計であり、高速なフェイルオーバー
により厳格なRTO/RPO要件を満たす。
・1つのプライマリリージョンで書き込み、
セカンダリリージョン(最大１０)で読み取り
専用のレプリカを運用できる。リージョン
ごとにオプションを変えられる。
・ブルー／グリーンデプロイメントはサポートされない。
・セカンダリクラスタでAutoscalingは使えない。
・DB同期はストレージレイヤのaurora
volume単位でエージェントによって実施。
・書き込み転送機能があり、セカンダリクラ
スターへの読み取り整合性レベルがある
1)eventual
同一セッションでコミットされた書き込みでも、
転送後にレプリケーションされる前は後続のクエリ
では書き込み前のデータが取得される。
2)session
同一セッションでコミットされた書き込みが、
後続のクエリで取得される。転送された書き込み
がレプリケート完了するまで待つ。
3)global
他リージョンを含めた全セッションでコミット
された結果が取得される。クエリ開始時点の、
プライマリクラスターでコミットされた全データ
がレプリケーションされるまで待機する。		 リンク リンク blackbelt
7 Amazon
Aurora
Serverless		 オンデマンドの自動スケーリング設定。
アプリケーションニーズに応じて、自動的に起動、
シャットダウン、および容量をスケールアップ
またはスケールダウンする。
・秒単位課金。RDSに比べると数倍になる
こともある。ElastiCache入れるほうが安く
なることもある。
・Aurora Serverless v2 インスタンス
を、既存または新規のデータベースクラスターで
プロビジョニングされたインスタンスとともに使用
することもできる。
・Aurora Serverless v2 の単位は
Aurora 容量単位 (ACU)で、各 ACU
では、約 2 ギビバイト (GiB) の
メモリと、対応する CPU、ネットワークが組み合わせられている。
・頻繁なトランザクションがあるとコネクション
レイテンシが発生する可能性がある。		 リンク リンク
8 RDS Oracle/
MsSQL/
MariaDB/
PostgreSQL/
MySQL		 マネージド型のリレーショナルデータベース
サービス。
・クロスリージョンリードレプリカを設定し、
フェイルオーバー時に昇格させられる。
・マルチAZはリージョン内障害に有効だが、
リージョン障害の復旧を保証できない。その
ときはAurora Global Databaseで複数
リージョンを使う。
・マルチマスターレプリケーションは、整合性
の維持が難しく、グローバルなデプロイメント
には適さない。-> Aurora Global Databaseを利用
・AWS Backup のポイントインタイムリカバリ
（PITR）機能により、最大で数秒単位の任意
時点までデータベースを復元可能。
・リードレプリカは災害復旧には使えない
ケースがあり、レプリカ自体が破損する可能性がある。
・マルチマスター構成は通常のRDS
PostgreSQLでは非対応。
・追加のリーダー DB インスタンスを含む
マルチ AZ DB クラスターを提供しているが、
MySQL と PostgreSQL データベースエンジン
でのみサポート。		 リンク リンク リンク
9 RDS Proxy 接続元と接続先のRDSの間に設置し、アクセス
を中継するサービス。
・例えば、lambda + RDSだと同時接続数
を超えてしまいアクセスできない状態になること
がある。このときに lambda + RDS proxy
+ RDS構成でコネクションのプーリングなどを
行う。
・RDS proxyは複数のAZにデプロイでき、
フェイルオーバーの際は新しいデータベース
インスタンスに直接ルーティングすることで、
アプリケーションの再接続は不要で、ダウンタイム
を短縮することができる。
・データベースがユーザ名/パスワードしか対応
していない場合でもRDS proxyの接続はiam
認証が可能。Secrets Managerによる認証
情報の一元管理も行える。		 リンク リンク blackbelt
10 Amazon
ElastiCache		 インメモリ型のデータベース。
・ElastiCacheの導入にはアプリケーション
の変更が必要になる場合がある。
・Memcachedはマルチスレッドに対応、
文字列のみ、単純なデータ向け。高可用性
または自動クラスターフェイルオーバーをサポート
していない。
・Redisはシングルスレッド、さまざまなデータ
タイプに対応、定期スナップショットによりバック
アップをサポート、マルチAZ対応。高可用性
または自動クラスターフェイルオーバーをサポート。
・ValkeyはRedisのフォークで、Redis
OSS の API とデータフォーマットに互換性
があり、コードを書き換えたり、アーキテクチャ
を変更することなくアプリケーションを移行可能。
・トラフィック集中やヒット率低下が発生して
いる場合、クラスターモードを有効化し、シャー
ディングを導入するのが効果的。
・キャッシュに保存されたデータは、元のデータ
がすでに変更されている可能性があるため、頻繁
に変化するデータには効果的ではない。		 リンク リンク リンク
11 Amazon
MemoryDB		 Valkey OSS と Redis OSS 互換性
と耐久性を備えたインメモリデータベースサービス。
・ElastiCacheよりも耐久性が高いという点
が大きな特徴。ElastiCacheは、高速な
処理を重視する一方、データの永続的な保存
を保証していない場合がある。
・従量課金制で最低料金はない。
・オンデマンドノードは、インスタンスを時間
単位で使用する購入オプション。
・リザーブドノードは、1年または3年単位
で契約し、予約したノードの時間単位の使用
レートが割り引かれる。
・読み取りにはコスト発生しないが、書き込み
データ量(GB単位)が月に10TBを超えるとコスト発生する。		 リンク リンク リンク
12 Amazon
Neptune		 グラフ型データベースサービス。
・頂点(Node, Vertex)と辺(Edge)
からなる構造をもつデータベース。
・マルチリージョン構成不可。
・大量のオブジェクトとそれらの関係性を保持
するのに適したデータベース。
・人間関係, 通信ネットワーク, SNS,
レコメンデーションエンジン, 経路案内,
物流最適化, 自動診断, 侵入検知やゲノム
配列決定などネットワーク構造を持つものを表現
するのに適している。
・インターネット経由のアクセス不可。VPC
エンドポイントが存在しない。VPC内部から
のみ接続可能。プライベートサブネット経由
でなければならない。Lambdaから処理させる
には、lambdaをVPC内に配置する必要あり。
・ユーザー情報の管理や認証基盤、トラン
ザクション処理中心のアプリケーションには不適。
・位置検索には不向き。		 リンク リンク
13 Amazon
Timestream		 フルマネージド型の専用時系列データベース
エンジン。Amazon Timestream for
LiveAnalytics を利用すると、1 分
あたり数十 GB を超える時系列データを取り
込み、TB 規模の時系列データに対して SQL
クエリを数秒で実行できるほか、最大 99.99%
の可用性を実現できる。
・データは常時暗号化。通信時は、TLS。
・保管時は、KMSを利用して暗号化。
・アクセス管理は、IAMユーザによる認証。
・Table/Time-Series/Record
で構成される。
・例えば気象アプリケーションは、時系列データ
ベースにより適した時系列データを使用する。		 リンク リンク
14 Amazon
DocumentDB
(MongoDB
互換)		 MongoDB との互換性を持つドキュメント
指向データベース。
・ドキュメント指向データベースはドキュメント
ごとに構造が違っていても格納できるので、
RDB と比べてスキーマの変更が容易。
・インスタンスベースのDocumentDB
クラスターは、 VPC のサブネット内に作成
し、クラスターはプライマリインスタンス・
レプリカインスタンス(autoscale可)と、
1 つのクラスターストレージボリュームで構成
される。プライマリインスタンスは 1 台、
読み込みのみサポートするレプリカは最大
15 台まで配置可能。クラスターの中で
インスタンスを含むコンピュートレイヤーと、
ボリュームを含むストレージレイヤーに分かれて
いるのが特徴。
・Elastic クラスターはペタバイト規模の
ストレージ容量を使用して、1 秒あたり数百万
の読み書きにデータベースをスケールできる。
インスタンスを選択、管理、アップグレードする必要がない。
・Elastic クラスターは MongoDB 互換
のシャーディング API をサポート。シャー
ディングを使用すると、単一のサーバーの容量
を超えるデータを扱うことができる。
・復旧させたい時点を秒単位で指定することができる。
・DocumentDB 管理 API の認証・認可は
IAM ユーザー、IAM ロール、IAM ポリシー
によって提供される。
・変更データキャプチャ（CDC）を行うには、
AWS Database Migration Service
(DMS) を使用する。AWS DMSは、
DocumentDBをソースまたはターゲットとして、
他のデータベースからDocumentDBへのデータ
移行、またはDocumentDBから他のデータベース
への変更をリアルタイムでキャプチャする。		 リンク リンク

デベロッパーツール

コンテナでgitlab/jenkins動かして、ローカルでvscodeしか普段は使わん。

JDKで corretto ってのにお世話になってるけど、そういえばテストには出てこんかったな。

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS CDK コードでクラウドインフラストラクチャを定義
し、 AWS CloudFormation を通じて
プロビジョニングするためのオープンソースの
ソフトウェア開発フレームワーク。
・typescriptが使われること多い、pythonも可。
・cloudformationテンプレートに変換できる。
・CodeBuildやCodePipelineと組み合わせ
てCI/CDの一貫した運用も可能。		 リンク リンク
2 AWS CodeCommit gitリポジトリのサービス。
・2024 年 7 月 25 日に、新規アクセスを終了。
・トリガー機能によってlambdaを起動し、シークレット
情報の有無をスキャンして影響があればキーを無効化して
通知できる。		 リンク リンク
3 AWS CodeBuild フルマネージドのCIサービス。ビルドキュー
も含めてサーバーの管理やプロビジョニングが不要。
・実態はコンテナサービスでDockerイメージ
を利用して起動。
・ソースとしてはCodeCommit以外にもS3、
Bitbucket、GitHub、GitLabをサポート。
・自前構築したGitLabはサポート外。自分で
構築したGitLabをソースにしたい場合にはCode
Commitへのミラーリングを間にかませて疑似
的にソースとして扱うことになる。
・出力するアーティファクトをKMSを用いて
暗号化することが可能。
・AWSのリソースにアクセスできるように認可する
ためにはCodeBuildにサービスロールを割り当てる
必要がある。
・VPC内リソースにアクセスする必要がある
場合にはVPC内でCodeBuildを起動する必要があり、
このときIPアドレスを消費するため(実行完了して
IPアドレス解放は５分程度かかる)、IPアドレス
数に余裕があるネットワーク設計が必要。
・CodeBuildの環境変数にはAWSから提供
されているデフォルトの環境変数とカスタムして扱う
環境変数の2つが存在する。
・AWSから提供されている環境変数にはリージョン
名やビルドIDなど。CodeBuildが実行されて
いるリージョンを読み取り、処理の分岐をさせる
といった使い方をする。
・カスタムの環境変数は自由に定義して使える
環境変数で、静的と動的がある。Paramater
StoreあるいはSecrets Manager(rds
の接続情報とか)にパラメータを保存し、それを
読みだすという処理の流れで利用。
・ビルドプロジェクトでは、Amazon S3 と
ローカルの 2 種類のキャッシュのうち、
いずれかを使用できる。
・LOCAL_SOURCE_CACHE は一時的な
ローカルキャッシュで、再利用性が限定される。		 リンク リンク リンク リンク
4 AWS CodePipeline CI/CDをオーケストレーションするための
ビジュアルワークフローツール。
・起動契機は、eventbridgeでのイベント駆動、
webhook、ポーリング
・ソース->ビルドとテスト->開発デプロイ->
承認(必ず手動)->本番デプロイ
・アーティファクトはs3に保存されるが、複数
リージョンにデプロイするときそれぞれに置き場が必要
・高速にサイクルを回すため、人間がマネジメント
コンソールに張り付くのはアンチパターン。ステータス
が変更されたら自動で通知が飛んでくるようにする
ことで、パイプラインを起動した後は通知が来る
までほかのやるべきことをやれるようにする、
というのがベストプラクティス。
・1つのAWS CodePipelineに1つのAWS
CodeDeploy。並行でデプロイしたいとして
複数のCodepipelineを構築するのはアンチ
パターン。実行時にアカウントのAPIスロット
リングに引っかかりやすくなり、管理不全などの
問題を引き起こすため、 Codedeployの
デプロイメントグループで対応する。
・ビルドとテストを2種類並行したい場合は、
それぞれの実行ステージのRunOrderパラメータ
を２以上の値に設定してパイプラインを構築する。
・パイプラインタイプにはV1とV2が存在し、
V2のみに以下の機能がある。
CodeStarSourceConnection アクションのフィルターに
基づいたトリガー QUEUED、PARALLEL 実⾏モード
ソースリビジョンのオーバーライド
ステージ条件・ステージのロールバック・ステージ失敗時の⾃動再試⾏
V2 パイプライン専湧のアクション
※V2パイプラインではV1の機能が全て実行可能。		 リンク リンク
5 AWS CodeDeploy アプリケーションのデプロイメントを自動化する
ためのデプロイサービス。
・オンプレとEC2はagentが必要、ecsとlambdaは不要
・デプロイメントのパターンは、EC2でBlue/
Greenかin-place(既存のインスタンスを
使う：ダウンタイムあり)、ecsとlambdaは
Blue/Green(新規にインスタンスを作成：
ダウンタイムほぼなし)のみ
・デプロイメントフックについて
BeforeInstall
ファイルの暗号化解除や現在のバージョンのバックアップ
作成など、インストール前のタスクに使用。
AfterInstall
アプリケーションの設定やファイルパーミッションの
変更などのタスクに使用。
ApplicationStart
ApplicationStop 中に停止したサービスを開始するために
使用。
ValidateService
デプロイが正常に完了したことを確認するために使用。
BeforeAllowTraffic
ロードバランサーに登録する前に、EC2インスタンスでタスクを実行。
・デプロイメントタイプについて
「リニア」「Canary」が出てくるのはデプロイ
先がlambda/ECSの場合のみ。リニアは徐々に
新バージョン環境へトラフィックを流し、最終的
にすべてのトラフィックを新バージョン環境へ流すが
リカバリ性が低い。Canaryは最初に少しだけ
トラフィックを流し、問題ないと判断したところ
で即時に全てのトラフィックを流す。
「All-at-Once」は「Canary」「リニア」
と異なり「最初少しだけ」という部分がなく、
ある時点で全てのトラフィックを既存バージョン
から新バージョンに流すデプロイ方式。		 リンク リンク リンク
6 CodeGuru 機械学習 (ML) と自動推論を組み合わせた
静的アプリケーションセキュリティ検査 (SAST)
ツール。コードの脆弱性を特定し、特定された
脆弱性を修正する方法に関する推奨事項を提示できる。
・分析の対象はAWSに連携されたリポジトリ
サービスであり、CodeCommitやGitHubの
リポジトリを連携することによって利用可能。
・CodeGuru Reviewerはソースコードの
レビュアーをしてくれるサービス。
・CodeGuru Profilerはアプリケーションの
パフォーマンスを分析するサービス。
・CodePipeline＋CodeBuildを利用して
CodeGuruによるレビューをCI/CDパイプライン
に組み込める。		 リンク リンク リンク
7 AWS CodeArtifact パッケージマネージャツール(Maven、Gradle、
npm、Yarn、Twine、pip、NuGet
など)でダウンロードするパッケージを管理するサービス。
・開発元と再配布者、実際にパッケージを利用
する人 (エンドユーザー)の３者について、
3人のうち開発元と再配布者に成り立つ関係を
アップストリーム再配布者とエンドユーザーに
成り立つ関係をダウンストリームと呼ぶ。		 リンク リンク
8 AWS SAM Infrastructure as Code (IaC) を
使用してサーバーレスアプリケーションを構築
するためのオープンソースフレームワーク。
・aws sam cliをローカル環境にインストール
し、cloudformationを通じてaws sam
テンプレート定義を利用して開発とテストを行える。		 リンク リンク リンク
9 AWS .NET
Core		 クロスプラットフォーム開発フレームワークであり、
AWS上で.NET Coreアプリケーションを構築・
デプロイして実行するための仕組み。		 リンク リンク
10 AWS Fault
Injection
Service		 障害シナリオを実行できるサービス。元はFault
Injection Simulatorという名前だった。		 リンク リンク blackbelt

ネットワークとコンテンツ配信

めっちゃ苦手。Route53のところに出てくるポリシーがどうしても覚えられん。

普段はNATゲートウェイ使うことはあっても、NATインスタンスなんか見たことない。

No サービス名 内容 URL1 URL2 URL3 URL4
1 Amazon
Cloudfront		 AWSが提供する世界的なコンテンツ配信
ネットワーク（CDN）サービスで、ウェブサイト
のコンテンツ（HTML、画像、動画など）を
高速・安全・確実に配信。
・AWS Shield Standardを標準搭載
・オリジンとして複数のリソース指定が可能で、
例えばALBだけでなくs3を指定可能。
・/static/のようなパスベースの振り分け
ができる。ビヘイビアにはワイルドカード
指定できるが正規表現は使えない。
・UDPはサポートしていない。NLBの前段
に配置することはできない。
・s3にIP制限よりもcloudfrontのOAI
(Origin Access Identity)設定の
ほうが安全で公式手法
・User-agentではCloudFront経由
かは判別できない
・DDoS攻撃のような突発的な大量トラ
フィックも、グローバルに分散されたエッジが
吸収するため耐障害性が向上する
・クエリ文字列毎のキャッシュが可能だが、
パラメータの順序、大文字小文字の違いによって、
別のキャッシュと判断されるためLambda@Edge
でクエリ文字列を標準化するとキャッシュ
ヒット率が上がる。
・署名付きURLが使用でき静的ファイルの
限定公開には有効だが、動的なアクセス権管理
に不適切でセッション管理もできない。
・ジオ制限(GeoRestriction)機能を
使うと、特定の国からのアクセスをブロック
することができ、IPベースではなく国コード
ベースで制御が可能。ただし完全に判別できる
わけではないため、判別結果が不明でも拒否
する場合はWAFのジオ制限を使うとブロックできる。
・アップロード処理には対応していない。
・S3 に直接アクセスすることを禁止するには、
Origin Access Control（OAC）を作成
し、CloudFront ディストリビューション
に関連付ける。		 リンク リンク リンク リンク
2 Amazon
Cloudfront		 ・CloudFront からのアクセスを識別する
カスタムヘッダーを用いて ALB 側で WAF
による制限を行い、S3 には OAI を適用
して直接アクセスを防止できる。
・独自のドメイン名を使用し、エンドツー
エンドで HTTPS 接続を確保するには、信頼
できるサードパーティ証明機関が発行した
証明書を ACM にインポートし（自己証明
は利用不可）、ALB にアタッチする。
CloudFront のビューアープロトコル
ポリシーを「HTTPS のみ」に設定し、
CloudFront には ACM または IAM
証明書ストアにインポートした SSL/TLS
証明書を使用する。ACM を使用する場合、
証明書は US East (N. Virginia)
リージョン（us-east-1）に存在する必要あり。
・CloudFront のビューアープロトコル
ポリシーを「Match Viewer」に設定
すると、ビューアーが HTTP を使用した
場合、CloudFront から ALB への通信
も HTTP になる。
・S3 に保存した証明書を ALB や
CloudFront に直接使用することはできない。
・S3へのオリジンポリシーが誤っていると、
４０４などのエラーが戻るが４０３は戻らない。
・価格クラスには All、200、100
の 3 つがあり、それぞれの価格クラスで
使用される地理的リージョンに違いがある。
・TTL を0 に設定すると、CloudFront
がコンテンツをキャッシュするのを防ぎ、ユーザー
が最新バージョンを確実に受け取れるようにできる
(キャッシュしなくなる)。		 リンク blackbelt
3 CloudFront
Functions		 JavaScript で軽量な関数を記述し、
レイテンシーの影響を受けやすい CDN
カスタマイズを大規模に実行できる。
・以下のイベントが発生したら、CloudFront
Functions を呼び出すことができる。
1)CloudFront がビューワーからリクエストを受信
したとき (ビューワーリクエスト)
2)CloudFront がビューワーにレスポンスを返す前
(ビューワーレスポンス)
・Lamda@Edgeに似ているが、
CloudFront Functions の方が処理
が高速で、利用費が安くなっている(制約はある)。
・データキャッシュを提供しない。		 リンク リンク
4 Route53 ドメインネームシステム (DNS) ウェブサービス。
・シンプルルーティングポリシー
すべてのクライアントが同じレスポンスを受信する。
・フェイルオーバールーティングポリシー
アクティブ/パッシブフェイルオーバーを構成
する場合に使用。ヘルスチェック結果により自動切り替え。
・位置情報ルーティングポリシー
ユーザーの場所に基づいてインターネット
トラフィックをリソースにルーティングする場合
に使用、最寄りのアプリケーションに誘導できる。
デフォルトのレコードの作成を選択しなかった
場合、Route 53 は、それらのロケーション
からのクエリに対して “no answer” のレスポンスを返す。
・地理的近接性ルーティングポリシー
リソースの場所に基づいてトラフィックを
ルーティングし、必要に応じてトラフィックを
ある場所のリソースから別の場所のリソース
へ移動する場合に使用
・レイテンシールーティングポリシー
複数の場所にリソースがあり、レイテンシーが
最も小さいリソースにトラフィックをルーティング
する場合に使用
・IP ベースのルーティングポリシー
CIDR表記でIPアドレス範囲の場所に
トラフィックをルーティングするために使用
・複数値回答ルーティングポリシー
ランダムに選ばれた最大 8 つの正常な
レコードを使用して Route 53 が DNS
クエリに応答する場合に使用
・加重ルーティングポリシー
指定した比率で複数のリソースにトラフィック
をルーティングする場合に使用		 リンク リンク
5 Route53 ・EvaluateTargetHealth
Yes：AWS管理のFQDNのヘルスチェック
と連携する(alias先がcloud front
の場合は選択不可)、
No：ヘルスチェックを考慮しない
・ヘルスチェックの種類
エンドポイントをモニタリング、算出した
ヘルスチェックを監視、Cloudwatch
アラームをモニタリング、Amazon
Application Recovery Controller
(ARC) ルーティングコントローラー
・複数のVPCから、route53のプライ
ベートホストゾーン利用名前解決と、オンプレ
のDNSの両方で名前解決を可能な環境を作る場合、
1)各VPCにroute53のプライベートホストゾーンを
関連づける。
2)インバウンドリゾルバエンドポイントを
中継用VPCに配置。
3)オンプレDNSから転送設定を行う。
・route53resolverのフォワーダー
はオンプレミス連携用
・異なるAWSアカウント間でプライベート
ホストゾーンを共有する場合、
1)所有アカウントAで承認を作成
2)他アカウントBでVPCを関連づけ
3)セキュリティ向上のため承認を削除
・AWS Resource Access Manager
（RAM）を使って中央アカウントに共有VPC
を作成し、他のアカウントのVPCとピア
リングしておくとRoute 53のプライベート
ホストゾーンを中央アカウントで管理できる。
6 Amazon
Route53
Resolver		 以前は、「.2 resolver」「Amazon
provided DNS」と呼ばれた。
・転送ルールタイプには「システム」
「転送」「再期的」がある。
・AWS resource access manager
により転送ルールは他のawsアカウントと共有できる。		 リンク blackbelt
7 Amazon
Route53
Application
Recovery
Controller		 大規模な障害（リージョン全体の障害など）
が発生した際に、アプリケーションを迅速かつ
確実に復旧させるためのマネージドサービス。
通常のRoute 53が「名前解決（DNS）」
を主目的としているのに対し、ARCは「災害
復旧（ディザスタリカバリ：DR）の自動化
とオーケストレーション」に特化している。
① 準備状況チェック (Readiness Check)
アプリケーションが別のリージョンで正常に起動
できる状態にあるかを継続的に監視する。
役割: AWSリソース（EC2、ASG、RDS、
DynamoDBなど）のキャパシティやクォータ
（制限）が、フェイルオーバー先で不足して
いないかを確認する。
メリット: 「いざ切り替えようとしたら、
移行先のスペックが足りなくて動かなかった」
という事態を未然に防げる。
② ルーティングコントロール (Routing Control)
トラフィックの切り替えを制御する「究極
のオン/オフスイッチ」。
役割: Route 53のヘルスチェックと
連動し、管理者が手動または自動でトラ
フィックの流れを別リージョンへ瞬時に切り替える。
信頼性: このスイッチ自体が極めて高い
可用性を持つように設計されており（5つの
エンドポイントに冗長化）、AWSのコントロール
プレーン（管理機能）自体が障害に陥っている
状況でも操作が可能。		 リンク リンク
8 AWS Cloud
Map		 クラウドリソース検出サービス。クラウド
リソースに任意の名前をつけて、簡単かつ迅速
にみつけるための仕組み。DNSクエリやAPI
呼び出しで参照する。
• すべてのクラウドリソースのためのレジストリ
• 高速かつセキュアな名前解決
• 属性を指定したサービスディスカバリ
• Amazon Route 53 ヘルスチェック
を利用した対向システムの状態異常への対応
• AWS クラウドやオープンソース
ソリューションとの統合
・DNS クエリ対応の名前空間作成時には、
AWS Cloud Map が⾃動的に Route
53 Hosted Zone を作成する。		 リンク リンク リンク
9 ELB
（ロードバランサ）		 ELBにはALB/NLB/GLBがある
・ALB - カスタムヘッダの追加はできない
(2024年11月頃できるようになった）。
やるならCloudfront。
・ALBのroud_robinアルゴリズムは
バックエンドへのリクエストを均等に分配する
・ALBに割り当てたセキュリティグループで、
CloudFront用のAWS管理プレフィックス
リストだけを許可し、それ以外のトラフィック
を拒否するように構成すると、クライアントから
直接ALBにアクセスするのを防ぎ、継続的
なIPアドレスの変更が可能になる。
・ALBはL7（HTTP/HTTPS/gRPC）
専用であり、UDPトラフィックを扱うことはできない。
・ALBはリージョンを跨いでターゲットを登録できない。
・ALBはSNIによりサーバ名ごとにSSL/TLS
証明書を設定できるようになり、リクエストから
証明書を適用するサーバ名が判断して適用するようになる。
・ALBがクライアントのHTTPSリクエスト
を受け取り、バックエンドへ転送する際、
例えば以下のネットワークACLの設定が必要。
1)プライベートサブネットのインバウンドに、
ポート443・送信元10.1.0.0/24を許可
2)プライベートサブネットのアウトバウンドに、
ポート1024〜65535・送信先10.1.0.0/24を許可
※ネットワークACLはステートレスなため、
レスポンス返送のためのアウトバウンドルール
（動的ポート）を明示的に許可する必要がある
・NLBはL4負荷分散で、UDP取扱可能。
(その他にもTCP/TLSを取り扱える)
・セッション管理をしているシステムはセッション
の途中でサーバが変わってしまうとややこしく
なってしまうため、スティッキーセッション設定
を行うことで、同一セッションについては同じ
サーバで処理するようにする。awsではelb
ではなくターゲットグループに設定がある。		 リンク リンク リンク リンク
10 ELB
（ロードバランサ）		 ・GLBを使うとインターネット通信を一元的に
中央の VPC に集約し、検査・制御が可能。
・GLBでエンドポイントを作成するには、
Amazon VPC とサブネットを選ぶ。エンド
ポイントネットワークインターフェイスには、
サブネットの IP アドレスの範囲から
プライベート IP アドレスが割り当てられる。
作成後、サービスプロバイダーから承認されると
使用できるようになる。
11 Amazon
global
accelerator
(AGA)		 世界中のユーザー向けにアプリケーションの可用性
とパフォーマンスを向上させるネットワークサービス。
ALB、NLB、EC2の前段に置いてアプリ
ケーションの可用性とパフォーマンスを改善する。
・cloudfront
プロトコル : http/httpsのみ対応
キャッシュ : 使う
クライアント証明書 : 利用しない
オンプレ : オリジンに指定可能
・global accelerator
プロトコル : TCP/UDPのトラフィック・ルーティングに対応
キャッシュ : 使わない
クライアント証明書 : 利用する
オンプレ : オリジンに指定不可
固定のAnycast IP(一つのIPアドレスがインターネット
上の複数の機器に同時に割り当てられ共有される)が2つ
提供され、最もパフォーマンスの良いリージョンに自動的
にルーティングされる。
・TCP/UDP レベルでの最適化は可能だが、
アプリケーションレベルでのキャッシュによる
改善効果の方が大きい。		 リンク リンク リンク blackbelt
12 Amazon
Virtual
Private
Cloud
(VPC)		 awsの中でのネットワークの単位。
・ピアリングを使用することで、複数の
VPC を AWS 内でセキュアかつ直接的
に接続できる。インターネットを介さない。
・VPC フローログを有効化すれば、拒否
されたトラフィックや送信元 IP を含む詳細
なログ情報を CloudWatch Logs に出力できる。
・lambdaやamazon data firehose
を使わなくても、VPCフローログはs3に直接出力できる。
・Local Zones を使用すると、コンピュー
ティングやストレージなどのリソースをエンド
ユーザーに近い複数の場所に配置できる。
・Wavelength Zones を使用すると、
デベロッパーは 5G デバイスやエンドユーザー
に非常に低いレイテンシーを提供するアプリケー
ションを構築できる。標準の AWS コンピュー
ティングおよびストレージサービスを通信事業者
の 5G ネットワークのエッジにデプロイする。
・カスタムネットワーク ACL を更新すると、
欠落している送信ルールが含まれるようになる。
ネットワーク ACL はステートレスで、受信
ルールと送信ルールが必要。		 リンク リンク リンク リンク
13 AWSの
ゲートウェイ		 ５種類ある。
・インターネットゲートウェイ
サブネットを外部環境と双方向にインターネット
接続したい時にVPCにアタッチして使う （イン
ターネットゲートウェイに接続できる状態のサブ
ネットを「パブリックサブネット」という）
・NATゲートウェイ
サブネット内のリソースを外部環境とアウト
バウンドに限ってインターネット接続したい時に
サブネットにアタッチして使う
・仮想プライベートゲートウェイ
単一VPC内のリソースとオンプレミス環境
をVPNで接続したい時にVPCにアタッチして使う
・トランジットゲートウェイ
複数のVPC ⇔ オンプレミス環境の接続と、
複数のVPCを接続するときに使う
・カスタマーゲートウェイ
オンプレミス環境とVPCをVPNで接続したい
時にAWS環境内に作成して使う		 リンク リンク
14 NAT
Gateway		 プライベートサブネット内のインスタンスは
VPC 外のサービスに接続できるが、外部
サービスはそれらのインスタンスとの接続を
開始できない。
・インターネット接続ができ、他のVPCや
オンプレのネットワークに接続できる。
・外部サービスからは接続開始できない。
・アウトバウンドトラフィック用途であり
インバウンド制御には不適。
・デフォルトタイプはパブリック。
・パブリック
-> 作成時にElasticIPアドレスをNAT
ゲートウェイに関連づけ必要。
・プライベート
-> ElasticIPアドレスを関連づけできない。
・IPv6がサポートされていないため、プライ
ベートサブネットに配置されたインスタンスが外部
と通信するには、着信をブロックしつつ送信専用
のEgress-Onlyインターネットゲートウェイ
を使用する。VPCピアリング経由でNATを
利用する構成も、IPv6では成立しない。		 リンク リンク
15 Egress-Only
インターネット
ゲートウェイ		 IPv6 で使用されるNATゲートウェイ。 リンク リンク
16 Transit
Gateway		 Amazon VPC同士はもちろんオンプレミス
を相互接続できるネットワークのハブ。通信の
暗号化はできない。		 リンク リンク
17 GREトンネル 総称ルーティングカプセル化トンネル=GRE
トンネルはTransit Gateway Connect
ピアとも呼ばれる。
・１つのルーティングプロトコルを使用する
データパケットを別のプロトコルのパケット内
でカプセル化するためのプロトコルのこと。
「カプセル化」は、箱の内にもうひとつ別の
箱を入れるように、あるデータパケットが別の
データパケットを内包することを意味する。		 リンク リンク
18 Direct
Connect		 AWSと自社の拠点や自社のシステムが稼働
するデータセンターとのプライベート接続（専用
接続）を実現できるクラウドサービス。
・単一の物理接続で複数リージョンに拡張
可能。冗長構成とBGPによるフェイルオーバー
も可能で、可用性とパフォーマンスを両立できる。
・50 Mbps から 400 Gbps まで速度に対応。
・異なるキャリアを使った接続を追加することで、
物理障害やキャリア障害に対する耐性が強化される。(費用が増える)
・VIF（仮想インターフェース）はPublic
/Private/Transitの種類があり混在可能。
・PublicVIFは専用線を介してawsサービス
に接続(中国では使えない)、TransitVIF
は２０を超えるVPCとの接続やSD-WAN
利用で選択する。
・DirectConnectSiteLinkを利用すると、
オンプレ間の接続が可能になる。
・PublicVIFではなくPrivateVIF推奨。
PrivateVIFでは暗号化はできない。
・暗号化を行う場合、PublicVIF上で
Site-to-site VPNを構成するのが標準的な方法。
・PrivateVIFでは暗号化されないため、
PublicVIFと、IPSec VPNトンネル
またはSite-to-Site VPNをその上に
構成することで暗号化できる。
・BGPセッションの保護には MD5認証を
使用するのが標準的。
・Direct Connect のバックアップとして
VPN接続を追加する構成は、コスト効率と冗長性
を両立する最も現実的な方法。BGPによる
ルート交換により、Direct Connect が
ダウンした際にも自動でVPNにフェイルオーバーできる。
・複数リージョン間でも、それぞれのVPCに
VGWを作成してDirectConnectGateway
を介して接続可能。
・リンク集約グループ (LAG) は、リンク
集約制御プロトコル (LACP) を使用して
単一の Direct Connect エンドポイント
で複数の接続を集約する論理インターフェイス。
1 Gbps、10 Gbps、100 Gbps、
または 400 Gbpsで同じ帯域幅の回線が必要。		 リンク リンク リンク リンク
19 AWS
Site-to-Site
VPN		 オンプレミス機器と VPC 間の安全な接続
を実現する。各 VPN 接続には、高可用性
のために同時に使用できる 2 つの VPN
トンネルが含まれている(メンテでときどきダウンすることがある)。
・VPCに関連付けられたトランジットゲート
ウェイ、または、仮想プライベートゲートウェイ
（VGW）を経由し、リモートネットワークへの
安全なアクセス環境を利用できる。
・Direct connectのバックアップ回線として利用可能。
• 用途によって、接続先を使い分け。
1) VGW：特定のVPCのみと通信
2) TGW：多くのVPCと通信（VPN料金
の他にTGWの料金も発生する）
※複数のVPN接続を束ね、Equal Cost
Multi Path(ECMP)を利用し帯域を増せる。
1つのIPsecトンネル当たり、最大1.25
Gbps、VPN接続を増やすことで、最大50
Gbpsまでのバースト可。
※Accelerated VPNオプションを有効化
し、AWSバックボーンを利用することで、海外
拠点からのVPN接続時などにインターネットの
不安定要素を軽減。
• IPsec対応ルーターと固定Public IP
があれば、容易に環境構築可能（事前共有キー
による認証方式）。
• プライベート証明書による認証の場合、
非固定Public IPに対応。
• 不要になったらすぐに停止できる（時間課金
＋転送量に課金）。
・同一のVGW/TGWに接続された動的
AWS VPN間でASNをユニークにすることで、
折り返し通信が可能（AWS VPN CloudHub）。
・オンプレミスCIDRとVPC CIDRが
重複しているとき、オンプレのルーターで
Source NATとDestination NATを併用
し、重複を回避可能。		 リンク リンク リンク
20 AWS
PrivateLink		 データをインターネットに公開することなく、
VPC と AWS のサービス間の接続を確立する。
・VPC間のcidrが重複しても接続確立が許容される。
・Interfaceエンドポイントはさまざまなaws
サービスに接続でき(有料)、Gateway
エンドポイントは、s3/DynamoDBに接続できる(無料)。
・エンドポイントへの接続はサブネットに
ルーティング設定を付与し、セキュリティグループ
で通信許可設定も必要。
・Interfaceエンドポイントはeniの集合。		 リンク リンク blackbelt
21 Amazon VPC
Lattice		 ・基本的には「ALBの集合体＋それらを
まとめるハブ」みたいなもの。
・コンピュート系リソース同士をアプリ
ケーション層で相互通信＆ルーティング＆
アクセス制御できる。
・複数のAWSアカウントやVPCから相互乗り入れできる。		 リンク リンク
22 VPC Traffic
Mirroring		 特定のENIを通るトラフィックをミラーリング
してコピーを送信する。
・送信先でwireshark使えばパケット
をキャプチャして確認・調査ができる。		 リンク リンク
23 NAT インスタンス ネットワークアドレス変換 (NAT) を提供
する。NAT インスタンスを使用すると、
プライベートサブネット内のリソースが、インター
ネットやオンプレミスネットワークなどの仮想
プライベートクラウド (VPC) 外部の宛先
と通信できる。実態はEC2インスタンスで
NATゲートウェイを使うほうがベター。		 リンク リンク
24 AWS
Wavelength		 モバイルネットワークを利用したときに、従来の
リージョンと比べてより低遅延でアクセスが
出来る用になるサービス。
・従来、5G や 4G ネットワークを使って
AWS リージョンにアクセスすると、いわゆる
「the internet」を経由していた。Wavelength
で提供される Zone を利用することで、
キャリアネットワークに閉じたアクセス経路に
なるため、より低遅延にアクセスが出来るようになる。
・Wavelength のユースケースは、スマート
ファクトリー、コネクテッドカー、リアルタイム
ゲームなどが挙げられる。
・Wavelength Zone は、ネットワーク
キャリア網に参加している端末からアクセス可能。
・5G でも 4G でも接続可能
・the internet からはアクセスできない (ICMP のみ可能)
・Wavelength Zone の東京と大阪は、Tokyo Region の VPC に所属する
・Tokyo Region の AZ と、Wavelength Zone 間は問題なく通信可能
・Wavelength Zone の東京と大阪間は通信できない		 リンク リンク リンク

エンドユーザーコンピューティング

xrdpコンテナとlibreofficeあったらええんとちゃうか。

個人利用では絶対使わん。

運用ではworkspacesってoffice365も使えるんやけど値段高めやで。

No サービス名 内容 URL1 URL2 URL3 URL4
1 Amazon
WorkDocs
(旧 Amazon
Zocalo)		 コンテンツの作成、ストレージ、コラボレーション
用の安全なフルマネージド型サービス。
・2025年4月25日をもって終了。
・バージョニングができ、WorkDocs Content
Manager APIを利用してロールバックなどが可能。		 リンク リンク
2 Amazon
AppStream
2.0		 デスクトップ環境を提供するフルマネージド
サービス。非永続的なストリーミングインスタンス
で、windows serverでの提供。		 リンク リンク
3 Amazon
workspaces		 デスクトップ環境を提供するフルマネージド
サービス。永続的なデスクトップインスタンス
を提供でき、windowsクライアントOSや
linuxでの提供。		 リンク
4 amazon DCV リモートサーバーでホストされる、グラフィック
を多用する 3D アプリケーションに安全に接続
するために使用できる、リモート可視化技術。
以前はNICE DCVという名前。
・利用ポートは8443でselinuxに許可設定
を入れ、dcv serverを稼働させておき、
クライアントサイドからhttps://<EC2の
IPアドレス>:8443としてアクセス。		 リンク リンク

フロントエンドウェブおよびモバイル

アカン、まったく使ったことない。

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS Amplify AWSがOSSで公開する開発プラットフォーム。
・React, Vue, Angularなどでの
SPAや、Gatsby, Hugoなどの静的サイト
ジェネレーターを用いたWebアプリケーションを
最速で開発するためのプラットフォーム。
・アプリケーション開発者はフロントエンドの
開発に集中でき、バックエンドとインフラはAWS
にサーバーレスで任せる。
・CI/CD環境の構築も自動で構築してくれる。		 リンク リンク blackbelt
2 AWS Device
Farm		 アマゾン ウェブ サービス (AWS) により
ホストされている実際の物理的な電話やタブレット
で、Android や iOS、およびウェブ
アプリケーションをテストしてやり取りできる
アプリケーションテストサービス。
・us-west-2 (オレゴン) リージョン
でのみ使用可能。
・ローカルコンピュータからリモートでデバイス
にアクセス。ウェブブラウザでインタラクティブ
にアクセスするか、ローカルクライアントから
Appium を使用して自動的にテスト。		 リンク リンク リンク

移行と転送

たまたまやけどdatasyncを使ってて、複数タスクを並列実行できんから扱いにくい。

タスクの代わりにfastcopyで バッチ処理 したほうが楽。

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS
datasync		 AWS DataSync は、AWSストレージ
サービスとの間で大量のデータのコピーを
簡素化、自動化、高速化するために
設計されたオンラインデータ転送サービス。
・大量ファイルの転送向き。即時処理には不向き。
・Network File System (NFS)、
SMB、Amazon S3 API などの標準的
なプロトコルに接続できる。
・仮想アプライアンスのエージェント経由で
データの同期を行う。ec2でイメージから
作成して稼働させることもできるが、
オンプレ側のvsphere/hyper-v
などで稼働させるのがベストプラクティス。
・ロケーションにオンプレのsmbやnfs
などを転送元として指定し、転送先に
s3/efs/fsxなどを指定する。fsx
ではロケーションの中の共有名に日本語使えない。
・ロケーションを作成する際のsmb接続情報
を入力すると、自動的にacm(AWS
Certificate Manager )に登録される。
・cron式を指定したタスクを作成して定期
処理を行い、結果をs3/cloudwatchlogs
に出力させて実行管理する。タスクは
エージェント単位でキューイングされ１つずつ
しか動かせない。
・リージョン間やクロスアカウントでの利用も可能。		 リンク リンク リンク blackbelt
2 AWS Snowball
Edge		 オンボードストレージとコンピューティング
能力を備えた物理デバイスで、ネットワーク
帯域幅が制限された環境でも大量のデータ
をクラウドに高速かつ安全に転送したり、
エッジコンピューティングを実行したり
するために使用される。数十TBでのデータ取扱い。
・大容量ストレージ、コンピューティング機能
・最大100Gbpsの転送速度
・暗号化強制
・インターネットを使用せずにデータを物理的に転送する
・データ転送プロトコル
・NFSv3
・NFSv4
・NFSv4.1
・HTTP/HTTPS経由のS3
・転送中にファイルを自動的に暗号化
するため、小さなファイルを大量にコピーする
場合は暗号化処理によるオーバーヘッドが
スループットの低下を引き起こすことがある。
この課題には、複数の並列コピーセッション
を用いて転送を同時に実行することで、
暗号化処理の負荷を分散し、全体のコピー
速度を改善できる。
・移行データの転送目安(1KB=1024
bytes, 転送時間を25%プラスしたとき)
1TB->100Mbps(30h), 1Gbps(3h), 10Gbps(18min)
10TB->100Mbps(12d), 1Gbps(30h), 10Gbps(3h)
100TB->100Mbps(121d), 1Gbps(12d), 10Gbps(30h)
1PB->100Mbps(3y), 1Gbps(121d), 10Gbps(12d)
10PB->100Mbps(33y), 1Gbps(3y), 10Gbps(121d)		 リンク リンク リンク
3 AWS Snow ・AWS Snowcone
小型のデバイスでオフラインデータ転送
およびエッジデバイスのどちらとしても使う
事ができるもの。2024年11月12日
をもって新規提供が停止
・AWS Snowmobile
すでにサービス終了。
最大 100 PB のデータを長さ 14
m の丈夫な輸送コンテナで移動するため、
マルチペタバイトまたはエクサバイト規模
のデジタルメディアの移行やデータセンター
のシャットダウンに最適。		 リンク リンク
4 AWS
Mainframe
Modernization		 オンプレミスのメインフレームアプリ
ケーションを AWS 上のクラウドネイティブ
かつフルマネージド型のランタイム環境に
移行して、モダナイズできる独自の
プラットフォーム。		 リンク リンク
5 AWS MGN Application Migration
Service(MGN)は、アプリケーション
を AWS に移行するために推奨される
サービス。
・オンプレVMの継続的なリアルタイム
レプリケーションを提供できる。
・エージェントレススナップショットベース
のレプリケーションは、VMware vCenter
環境でのみサポートされる。		 リンク リンク リンク
6 AWS SCT 「AWS Schema Conversion
Tool」の略称で、データベース間で
データ移行を効率的に行ってくれるツール。
オンプレミス環境で運用していたデータベース
をAWSに円滑に移行させることができる。
・スキーマ、ビュー、プロシージャ、
ファンクションの⼤部分を⾃動的に変換。
【OLTP変換】
DB2 -> Aurora MySQL/Aurora PostgreSQL/
MySQL/PostgreSQL/MariaDB
AzureSQL ->
Aurora MySQL/Aurora PostgreSQL/MySQL/
PostgreSQL
MsSQL ->
Aurora MySQL/Aurora PostgreSQL/MySQL/
PostgreSQL/MariaDB/MsSQL
MySQL -> Aurora PostgreSQL/MySQL/
PostgreSQL
Oracle -> Aurora MySQL/Aurora PostgreSQL/
MySQL/PostgreSQL/MariaDB
PostgreSQL ->
Aurora MySQL/Aurora PostgreSQL/
MySQL/PostgreSQL
SAP ASE ->
Aurora MySQL/Aurora PostgreSQL/
MySQL/PostgreSQL/MariaDB
【DWH変換 - to Amazon Redshift】
Azure Synapse Analytics/BigQuery/Greenplum/
MsSQL/Netezza/Oracle/Snowflake/Teradata/
Vertica
【NoSQL】
Apach Cassandra -> Amazon DynamoDB		 リンク リンク リンク
7 AWS Data
Migration
Service
(DMS)		 DataMigrationService。AWS
SCTとペアで使う。スキーマ移行ツール。
・例えば数TBのデータをSnowballEdge
利用して一括で物理的に転送した後、SCT
利用してスキーマ変換しDMSで日時の小規模
更新を同期しつつデータの鮮度を保つ
・AWS DMS CDC（Change Data
Capture：変更データキャプチャ）は、
データベースの移行やレプリケーションにおいて、
ソースDBで発生した挿入・更新・削除などの
差分データをリアルタイムで検出し、ターゲット
DBに自動反映する機能。
・Limited LOB mode は⼀般的に
最も⾼速な LOB の移⾏⽅法であり、
まずはこの LOB mode の利湧が可能か
を検討する。ただし LobMaxSize
（上限100MB）を超過したLOB は、
移⾏時に値が切り捨てられてしまう点に注意。
・Inline LOB mode は Limited
LOB mode と Full LOB mode
を組み合わせた動作であり、Limited LOB
mode で移⾏できない LOB 列データが
存在する場合は、次点として InlineLob
MaxSize を超えたデータを切り捨てることなく
移⾏可能な、 Inline LOB mode の利湧
を検討。
・CDCLatencySourceは、DMS
がソースから読み取った最後のデータ変更
イベントの時刻 (ソースで記録された時刻)と、
レプリケーションインスタンスの現在の時刻との差
・CDCLatencyTargetは、ターゲット
へのコミットを待機している最初のデータ変更
イベントの時刻(ソースでコミットされた時刻)と、
レプリケーションインスタンスの現在の時刻との差。		 リンク リンク リンク blackbelt
8 AWS Data
Migration
Service
(DMS)		 ・CDCLatencySource の値が
⾼く CDCLatencyTarget も同程度
の場合は、⼀般的にソース上のデータ変更
の読み取りが遅れていると考えられる。
1) Oracle の場合、ひとつの⽬安
として REDO ログが 1 時間あたり
10 GB を超える場合には、REDO
ログの読み取り⽅法をデフォルトの
LogMiner から Binary Reader
へ変更し改善することがある。エンドポイント
の接続属性にて「useLogMinerReader
=N;useBfile=Y; 」を指定することで
Binary Reader を利湧できる
2)PostgreSQLの場合、test_
decording を⽤いると ⼈間が読める
形式で WAL の内容を取得する⼀⽅で、
pglogical を⽤いるとWAL を圧縮
したバイナリ形式で取得するため、
ネットワーク帯域幅の使湧量の削減などを期待できる。
・CDCLatencySource の値が
⾼くなく CDCLatencyTarget
の値が⾼い場合は、⼀般的にターゲットへの
データ変更の適湧が遅れていると考えられる。
1)個別のDMLの性能が完全に最適
であるにも関わらず適湧が遅い場合は、
通常のトランザクション適湧(BatchApply
Enabled = false)での性能限界に
直面しており、バッチ適湧(BatchApply
Enabled = true)が必要である可能性がある。
2)ターゲットでの DML の実⾏性能
の影響を受けている場合、BatchApply
TimeoutMin や BatchApplyTimeout
Max、BatchApplyMemoryLimit
の値を増やすことで、⼀度にバッチで
適湧するデータ変更を増やし、ターゲット
へのデータ変更の適湧の頻度を下げ、
ターゲットにて実⾏される DML による
負荷の低減を期待できる。
9 AWS Transfer
Family		 AWS ストレージサービスとの間でファイルを転送
できる安全な転送サービス。S3やefsを
バックエンドに選べる。
・FTP/FTPS/SFTP/AS2が利用でき
バックエンドはS3/EFS。
・Amazon S3 へは AWS IAM 認証
情報を利湧し、Amazon EFS は POSIX
認証情報を利湧する。
・ユーザの利用フォルダはホームディレクトリ以外
に、複数の任意の論理フォルダを指定できる。
・ファイルコピーはリソースを跨げない。
ex.)S3⇒S3のコピーは可能、S3⇒EFSのコピーは不可
・SSHキー
⇒ユーザー認証（SA、ECDSA、ED25519 キーを受け入れ）。
・PGPキーペアアルゴリズム
⇒ワークフロー複合用（RSA または ECC (NIST)）
・PGP 対称暗号化アルゴリズム（直接選択しない）
⇒格納ファイルの暗号化（AES-128, AES-192,
AES-256, 3DESなど ）		 リンク リンク リンク blackbelt
10 CloudEndure
Disaster
Recovery		 障害発生やシステムの破損などが起こった際に
被害を最小限に抑えることができるとともに、
早期に復旧が可能。
・ec2のみ保護できる。Auroraやrdsには適用不可。
・既にサービス終了がアナウンスされており、
一部のリージョンを除いて2024/3/31に廃止。
現時点で、新規のデプロイもできない。		 リンク リンク
11 AWS Elastic
Disaster
Recovery		 サーバーとブロックストレージをソースロケーション
から AWS のリカバリリージョンへ継続的に
レプリケーションするサービス。CloudEndureの後継。
・パブリックサブネットとインターネットゲートウェイが必要。		 リンク リンク リンク
12 AWS
Application
Migration
Service		 オンプレミスおよびクラウドベースのアプリ
ケーションの移行に利用する。オンプレ側には
AWS Replication Agentをインストール
する必要がある。
・CloudEndure Migrationは物理・
仮想サーバーをAWSに移行するためのサービスで、
2022年12月30日をもってほとんどの
商用リージョンでサービスを終了し、後継サービス
であるAWS Application Migration
Service (AWS MGN)に移行。
・vSphereの場合、MGNのvCenter
Clientを利用することでエージェントレスで
のレプリケーションが可能。
・エージェントレス構成の場合、CBT
(Changed Block Tracking)による
差分データのみをレプリケーションする機能
によって、大量の仮想マシン移行を実行可能。		 リンク リンク
13 AWS
Application
Discovery
Service		 オンプレミスのサーバーのインベントリと動作
を検出して、クラウド移行を計画するのに利用。
サーバー構成情報やリソース使用状況、アプリ
ケーションの依存関係など、TCO 見積もり
に必要な詳細データを効率的に取得できる。これら
のデータは AWS Migration Hub で
集約して分析され、クラウドへの最適な移行戦略
を立てる上で不可欠。
・エージェントまたはエージェントレスを使って
自動で情報をキャプチャする。
・エージェントは公開 S3 バケット上に
配置されている専用のインストーラを使用して、
情報収集対象である移行元サーバにインストール。
・エージェントはシステム設定、使用率、
パフォーマンス情報、プロセスデータ、および
ネットワーク接続情報を収集。
・収集には前提条件があり、移行元サーバから
TCP ポート 443 を介した arsenal
エンドポイントへのインターネットアクセスと、
必要なポリシーが設定された IAM ユーザーの
アクセスキーが使用できる必要がある。
・エージェントレスは、VMware vCenter
Server 環境に仮想マシン(amazon
linux2)としてインストールし情報収集する。
・利用料無料。		 リンク リンク
14 AWS
Migration
Hub		 AWS Application Discovery
Serviceで収集した情報の参照・分析を行う。
• 推奨 EC2 インスタンスの取得
• 情報収集の停止・再開
• 収集した情報のエクスポート		 リンク リンク
15 Migration
Evaluator		 AWSクラウドへの移行計画をサポートする評価
サービス。現在のオンプレミス環境の詳細な現状
分析を提供し、それに基づいて将来のAWSクラウド
でのコストを予測できる。		 リンク リンク
16 AWS Cloud
Adoption
Readiness
Tool (CART
)		 組織のクラウド移行準備状況を多面的（ビジネス
、セキュリティ、オペレーション、スキルなど）
に評価し、移行計画立案の基盤を提供する診断
ツール。棚卸情報が不足しているような初期段階
で特に有効。		 リンク リンク

アプリケーション統合

大昔にAIXで動くシステムでMQが動いてたのを見たことあるけど、AWS SQS/MQは一回もないなぁ。

No サービス名 内容 URL1 URL2 URL3 URL4
1 Amazon SES Amazon Simple Email Service
はクラウドベースの E メールサービスプロバイダー。		 リンク リンク
2 Amazon SNS Amazon Simple Notification
Serviceはフルマネージド型のPub/Sub
（Publisher/Subscriber）メッセージングサービス。
・サポートされているプロトコル (Amazon
SQS、HTTP/S、E メール、SMS、
Lambda) の 1 つを使用。		 リンク リンク
3 Amazon SQS アプリケーション間のメッセージを非同期で
送受信するための、フルマネージド型メッセージ
キューサービス。
・AmazonMQと違い、使った分だけ課金される。
・インスタンスの管理が不要。
・標準キューでは順序保証がない。FIFO
キューを使うと順序保証される。
・標準キュー
スループットは無制限
配信順序はベストエフォートで保証されない
(順番が前後する可能性がある)
メッセージは最低1回配信する
(複数回配信される可能性がある)
複数回同じメッセージが受け取っても悪影響出ないような
構成にする必要がある
FIFOキューに比べて安価
・FIFOキュー
スループットは1秒あたり300件のメッセージ処理
配信順序は保証される(順番が前後しない)
メッセージは必ず1回のみ配信(複数回配信されない)
このキューは、配信順序や処理回数が重要な場合に
使用される
・可視性タイムアウトは、コンシューマが
キューからメッセージを受信したとき、他の
コンシューマに当該メッセージを一時的に見え
なくする機能。このときメッセージはキューに残る。
作業中のメッセージを他のコンシューマが処理
できないようにするために使用される。
・maxReceiveCountはデッドレター
キューに移動する前にコンシューマがメッセージ
を受信できる最大回数。１に設定すると、
コンシューマが１度メッセージを読み取って
処理完了が失敗の場合、メッセージはデッド
レターキューに移動される。		 リンク リンク リンク リンク
4 Amazon MQ Apache ActiveMQ向けのマネージド型
メッセージブローカーサービス。
・SQSよりも高価。IBM MQなど既存
サービスでMQを使っており、そこからAWSへ
そのまま乗せ替えたい場合に使う。
・リージョン内の複数のAZにメッセージを
冗長的に保存しているので、障害が発生した場合
でも利用することが可能。
・ActiveMQ/RabbitMQいずれかの
ブローカーを選択してインスタンスを立ち上げる。
そのため、キューを使っていない時間帯でもずっと
インスタンス料金が課金される。		 リンク リンク
5 Amazon
AppFlow		 SaaS アプリケーションと AWS サービス
間でコードなしにデータを安全に転送できるように
する統合サービス。サードパーティのSaaS
とAWSのマネージドサービスの間でデータを
安全に送信 (連携) できる。
・SaaSが持っているデータをS3に持って
くることができれば、その後Athena、Glue、
QuickSight等を使って、分析・可視化が可能。
・ソースとしてAmazon S3および13
SaaSアプリケーションをサポートし、宛先として
Amazon S3、Amazon Redshift、
Salesforce、およびSnowflakeをサポート。
・S3に出力する際のファイルのフォーマット
をJSON、CSV、Parquetから選択できる。
・使用するための前払い料金はなく、実行する
フローの数と処理されるデータの量に対してのみ支払う。		 リンク リンク
6 AWS API
Gateway		 AWSが提供する「APIの作成および管理を
簡単に行える」フルマネージドサービス。
・スロットル設定にレート制限とバースト制限
があり、これを超えたリクエストは拒否される。
・HTTP API は REST API に比べて
軽量かつ安価で、Lambda を統合することで
DynamoDB へのアクセスが可能。
・HTTP API は直接 DynamoDB に統合
できないため、Lambda を使用する構成が必要。
・IAMユーザーによるアクセス制御が可能で、
認可タイプをAWS_IAMにすることでポリシー
に基づいた認可を実現できる。権限を
execute-api:Invokeと付与することで制御できる。
・エッジ最適化 API エンドポイントは通常、
リクエストを最寄りの CloudFront POP
(Point of Presence) にルーティング
する。これは、クライアントが地理的に分散されて
いる場合に役立つ。API Gateway REST
API のデフォルトのエンドポイントタイプ。
・リージョン API エンドポイントは、同じ
リージョン内のクライアントを対象としている。
ユーザーが使用するカスタムドメイン名は API
がデプロイされているリージョンに固有。複数の
リージョンでリージョン別 API をデプロイする
場合、すべてのリージョンで同じカスタムドメイン名
を使用可能。カスタムドメインを Amazon Route
53 と組み合わせて使用すると、レイテンシー
ベースのルーティングなどのタスクを実行できる。
・プライベート API エンドポイントは、
Amazon Virtual Private Cloud (VPC)
からしかアクセスできない API エンドポイント。
インターフェイス VPC エンドポイントは、
VPC 内に作成するエンドポイントネットワーク
インターフェイス (ENI)。		 リンク リンク blackbelt
7 AWS API
Gateway		 ・APIは ステージ に“デプロイ”する
ことでクライアントから呼び出し可能。prod/
stag/devといったステージングが可能。
カナリアリリースも可能。
・API作成は「既存APIのクローン」または
「Swagger(OpenAPI)ファイルのインポート」
による作成が可能。
・ステートレスなREST APIはhttpメソッド
(GET/PUT/POST/DELETE)で操作
して利用。キャッシュが利用可能。
・ステートフルなwebsocket APIは「wss://」
で利用し双方向通信を行える。
・認証には、３つの方法がある。
1)IAMアクセス制限：アクセスキーを利用
2)lambdaオーソライザー(旧カスタムオーソライザー)：
ベアラートークンやパラメータを利用し独自認証やOAuth
もこれで利用可能
3)cognitoオーソライザー：事前にAmazon
Cognitoユーザープールで認証を⾏い、取得した
トークンをHTTPヘッダーに指定してAPIに渡す
・ハードリミット
※REST API：統合タイムアウト … 最⻑
29秒、HTTPヘッダー値のサイズ … 最⼤
10,240Bytes、ペイロードサイズ … 最⼤10MB
※WebSocket API：フレームサイズ … 最⼤
32KB、接続時間 … 最⼤2時間、アイドル接続
タイムアウト … 最⼤10分、ペイロードサイズ
… 最⼤128KB
8 AWS AppSync GraphQLのマネージドサービス。
・GraphQL は、REST API の限界を
補完する形で登場し、必要なデータだけを効率
よく取得できるのが特徴。ドキュメントが自動
生成され、クライアントからのレスポンス形式
指定ができ、サブスクリプションを利用したリアル
タイム処理が可能。
・マルチデータソース対応: DynamoDB/
Lambda/AuroraServerless/Elastic
Search/HTTP Endpoint(既存のAPIや
API gateway) など、複数のデータソース
に対応しているため、さまざまなデータを統合しやすい。
・リアルタイム更新:GraphQL のサブスク
リプション機能を活用し、リアルタイムでデータ
更新が可能。これにより、チャットアプリやライブ
データ表示のようなリアルタイム機能が必要なアプリに最適。
・セキュリティと RBAC:Amazon Cognito
と連携して、ユーザー認証やロールベースのアクセス
制御（RBAC）を簡単に実現可能。これにより、
特定のユーザーグループのみが特定のデータにアクセス
できるように設定できる。
・双方向ストリーミングや低レイテンシなデータ配信には
適さない。		 リンク リンク blackbelt
9 AWS Step
Functions		 分散アプリケーションのための視覚的なワークフロー
で、ステートマシンと呼ばれる仕組みを作っておき、
分散アプリケーションの構築、プロセスの自動化、
マイクロサービスのオーケストレーション、データ
と機械学習パイプラインの作成を行うことができる。
・ジョブの実行状態・成功/失敗・分岐処理・
並列処理などを視覚的に管理でき、失敗時の自動
リトライや個別ステップの再実行も可能で、
一般的な業務バッチ処理の制御が可能。
・高頻度書き込みの処理には不向き。
・非同期実行では、API Gateway が必要
とする即時の応答は提供されない。
・スタンダードワークフローステートマシンは、
同じ名前の複数の同時実行をサポートしておらず、
そのときはエクスプレスワークフローステートマシンを使う。
・ASL(Amazon states language)
を書いてステートマシンを定義する。		 リンク リンク リンク blackbelt
10 AWS App Mesh マイクロサービス間通信の信頼性担保やシステム
全体を観測できるサービス。タイムアウト/
スロットリングなどアプリケーションレベルの通信
をインフラ側で制御できる。
2026年9月30日でサービス終了予定。		 リンク リンク

機械学習とAI

一覧には出てこんけど、 bedrock ってのがある。

生成AIにデータから学習されんっていうサービスあるらしい。

東京リージョンよりusリージョンのほうが使えるAIのラインナップも広いし、料金青天井なんかもなぁ。

中華AIもあるらしいけどデータ大丈夫か？

No サービス名 内容 URL1 URL2 URL3 URL4
1 Amazon
SageMaker
AI (旧名
Amazon
SageMaker)		 データ、分析、AI の統合基盤
・機械学習向けであり、通常のシミュレーション処理には
不向き。
・Unified studioはデータとAIの統合
開発環境を提供する(無料だが、間接利用する
サービスはそれぞれ課金)
発見: データと AI 資産を探索
構築: 包括的な分析と AI のツールセット
協働: プロジェクトでのコラボレーション
統制: アクセスを安全に管理
 リンク blackbelt
2 Amazon
SageMaker
ノートブック		 jupyterlab利用環境。 リンク リンク
3 Amazon
Kendra		 様々なデータソースを横断的に検索できる
エンタープライズ検索サービス。Kendra から
各種データソースに簡単に接続できるコネクタ
が提供されていて、Amazon S3, Microsoft
SharePoint, Salesforce, ServiceNow,
Google ドライブ, Confluence など連携できる。		 リンク リンク
4 Amazon
Fraud
Detector		 機械学習でオンライン不正をより早く検出する
ためのマネージドサービス。機械学習に今まで
触れてきてなくても、データを用意するだけで
不正検出を始められる。
・2025 年 11 月 7 日以降、AWS
は Amazon Fraud Detector (AFD)
の新規顧客の受け入れを停止。
・Fraud Detector では、トレーニングに
渡したデータのうち、15 % のデータは
トレーニングに使われない。85 % のデータ
でモデルを学習したあとに、使っていない
15 % のデータをつかって学習モデルの評価を行う。		 リンク リンク
5 Amazon Polly 文書の読み上げ（音声合成）を行う。 リンク リンク
6 Amazon
Transcribe		 音声の文字起こし（音声認識）を行う。 リンク リンク
7 Amazon
Textract		 印刷されたテキスト、手書きの文字、レイアウト
要素、データを、あらゆるドキュメントから自動的
に抽出。AI モデルによって画像からテキストを
読み取るOCR（Optical Character
Recognition) のようなサービス。		 リンク リンク
8 Amazon
Lookout
for Vision		 画像の異常を発見する機械学習 (ML) サービス
で、製造業の企業が大規模に欠陥を検出できる。
・最低限、正常な画像が 20 枚、異常な画像
が 10 枚で使い始められる。画像のアップロード
(S3バケットに格納)や、正常・異常のラベル
付けなど、AWS の GUI から操作が出来る
ため、難しい機械学習の知識が不要で始められる。		 リンク リンク
9 Amazon
Rekognition		 ML を使用して画像認識と動画分析を自動化。
・機械学習のモデルやインフラをゼロから構築
することなく、トレーニング済みまたはカスタマイズ
可能な画像処理APIをアプリケーションに素早く
追加することが可能。
・画像認識（物体認識）、顔画像の検索、
モデレーション(有害検出)など機能が多岐
に渡っているサービス。		 リンク リンク
10 Amazon Lex 音声からテキストデータへの変換に自動音声認識
（ASR）、テキストの認識には自然言語理解
（NLU）と呼ばれるディープラーニング技術が
活用されており、Amazon Alexaに使われて
いるものと同じ技術を使用できる。		 リンク リンク
11 Amazon
Comprehend		 機械学習のサービスの一つで、直感的な自然
言語処理ができる。
・固有名詞抽出 - 日付やイベント、特定の
場所、企業や人、量やタイトル及びその他を抽出可能。
・キーワード抽出 - 重要なフレーズとなる特徴
的な名詞を抽出可能。
・感情分析 - ４種類で表した感情の分析
ができる。肯定的、否定的、中立的(感情の振れ幅
が一定)、または混在。		 リンク リンク
12 Amazon
Translate		 AI モデルによって文章を多言語へ翻訳する。 リンク リンク
13 Amazon
Personalize		 機械学習の知識がなくても、個々のユーザー
向けにリコメンデーションをリアルタイムで
提供できるサービス。
・以下のようなレコメンド方式が提供可能。
1)商品購入履歴に応じたおすすめ：アイテムベース
「この商品を購入した人におすすめの商品です」
2)ユーザーの属性に応じたおすすめ：ユーザーベース
「あなたにおすすめの商品です」
3)パーソナライズされたランキングの表示
おすすめ商品が10個あった場合、それらを表示する順序をユーザーごとに変えるイメージ
 リンク リンク
14 AWS
Panorama		 オンプレミスのカメラネットワークにコンピュータ
ビジョンを提供するサービス。・Panorama アプ
ライアンスまたは他の互換性のあるデバイスをデータ
センターにインストールし、 AWS Panorama
に登録してAWS Panorama works から
既存のリアルタイムストリーミングプロトコル
(RTSP) ネットワークカメラでコンピュータ
ビジョンアプリケーションをデプロイできる。
・例えば、SageMaker AI を使用して、
カメラまたはセンサーからトレーニングデータを収集
し、機械学習モデルを構築し、コンピュータビジョン
用にトレーニングできる。		 リンク リンク

IoT

やったことない内容ばっかり。

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS IoT
Core		 複数のIoTデバイスを一元管理して制御できる
サービス。データ収集と遠隔制御を行う。
・MQTTをネイティブサポート。
・Data-ATS エンドポイントを使用すること
で、安全な TLS 通信経路が確保される。
・AWS IoT ルールを用いて DynamoDB
に直接書き込む構成は、高可用性・低レイテンシ・
メンテナンス不要という利点を持ち、EC2を
ブローカにするよりも運用負荷と障害リスクを低減できる。		 リンク リンク blackbelt
2 AWS IoT
SiteWise		 産業機器データの収集、整理、分析を簡素化
するマネージドサービス。
・設備機器が扱える産業用の通信プロトコル
（Modbus TCP や OPC UA など）を
AWS 側がサポートしているプロトコル
（MQTT や HTTP など）に変換する必要
があるが、SiteWise ゲートウェイを使う
と産業機器側のプロトコルをユーザー側で変換
することなく、AWS へデータを送ることができる。
・SiteWise API を使う方法は、デバイス側
に AWSが提供する SDK をインストールして
直接 SiteWise にデータを送れる。Site
Wise ゲートウェイを使っていないので設備機器
からのデータ収集についてはデバイス側で別途自前
で実装する必要あり。
・MQTT プロトコルを使って AWS IoT
Core 経由で送る方法もある。
・Grafana向けのプラグインがあり、
可視化をGrafanaで利用可能。		 リンク リンク blackbelt
3 AWS IoT
Device
Management		 接続デバイスを登録、編成、監視、リモート
管理するサービス。IoT Coreの一部。		 リンク リンク blackbelt
4 AWS IoT
Greengrass		 AWS の「IoT プラットフォーム」(AWS
IoT) の機能をエッジ(現場)にオフロード
する仕組み。データをクラウドを介さずに
現場で処理する「エッジコンピューティング
環境」を構築できるようになる。
・オンプレミスのサーバーに SageMaker
モデルをデプロイし、ローカルでの機械学習
推論を実行できる。
・IoT SiteWise EdgeはGreengrass
のコンポーネントとして提供される。
・コンテナを稼働させられる。
・Greengrass Lambdaが実行できる。
言語：node.js/python/java/c/c++
イベントソース：MQTT、他のlambdaからの実行
タイムアウト設定：デフォルト３秒、制限なしで実行する
ことも可能
メモリ設定：デフォルト16MB、デバイス依存
課金：Greengrassの費用のみ		 リンク リンク blackbelt
5 AWS IoT
Device
Defender		 AWS IoT デバイスのフリートで一貫性
のあるセキュリティポリシーを適用し、デバイス
が侵害された場合にはすばやく応答することができる。
・クラウド側のセキュリティ設定の監査(証明書
の有効期限・過剰な権限チェック)、デバイス
側の不正な以上動作の検出(不要なポートの
listenや想定外のトラフィックが出ていないか
など)を行い、問題のある設定を自動的に変更
してリスクを軽減できる(Mitigation actions)。
・監査の実行を定期化(今すぐ/毎日/毎週/
隔週/毎月)することができる。
・デバイスからメトリクスを取得するには、AWS
IoT Device Defender Agent SDK/
FreeRTOSライブラリ/AWS IoT
Device Clientを使う。
・異常検出はルール検出とML検出があり、
後者はデバイス履歴データに基づいてモデルを
自動的に生成する。
・ML検出では学習に最低14日分、２５0００
ポイントのデータが必要。		 リンク リンク blackbelt
6 AWS IoT
Analytics		 IoT デバイスからのデータの分析に必要な
ステップを自動化する。
・2025 年 12 月 15 日 AWS IoT
Analyticsをもってサポートを終了		 リンク
7 FreeRTOS
(RealtimeOS)
(ふりーあるとす)		 組み込みシステム向けに設計された軽量・高品質
なオープンソースのリアルタイムオペレーティング
システム（RTOS）。
・MITライセンスで提供され、多数のマイクロ
コントローラに対応しており、IoTデバイスのデファクト
スタンダードとして広く利用されている。
・AWSが開発・メンテナンスを行い、ネットワーク
接続やセキュリティ機能も提供。
・高い移植性とサポート: 多数のCPU
アーキテクチャに対応。
・軽量・コンパクト: メモリフットプリントが
非常に小さく、小規模なマイコンでも動作可能。
・プリエンプティブ/協調型スケジューラ:
タスクの優先度に基づく柔軟なスケジューリング。
・IoT機能の充実: MQTT、HTTP、AWS
IoTへの接続機能、OTA（Over the Air
:無線アップデート）用ライブラリ。
・無償・商用利用可: MITライセンスのため、
制約なく商用製品に組み込める。
・IoTデバイス、産業用オートメーション、
センサノード、ウェアラブル機器など、リアル
タイム性が求められる小〜中規模の組み込みシステムに最適。		 リンク リンク blackbelt
8 AWS IoT
Twinmaker		 AWS IoT 物理システムとデジタルシステム
の運用可能なデジタルツインを構築するために使用
できるサービス。 AWS IoT TwinMaker
現実世界のさまざまなセンサー、カメラ、エンター
プライズアプリケーションからの測定と分析を使用して
デジタルビジュアライゼーションを作成し、実際の
工場、建物、または産業プラントの追跡に役立つ。
この実際のデータを使用して、オペレーションの
モニタリング、エラーの診断と修正、および
オペレーションの最適化を行うことができる。		 リンク リンク

分析

使ってみたい内容多いけど、試験勉強で想像しかしたことない。

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS Glue データ分析、機械学習、アプリケーション開発
に使うデータの検出・準備・結合を、サーバー
レスでスケーラブルに行えるデータ統合サービス
・バッチ処理向けでリアルタイム処理には不向き。
・リレーショナルDB移行やロジック変換には
対応していない。
・一般的な業務バッチ処理の制御には適さない。
・RDSからS3にデータをエクスポートし、
Athenaを使って分析すると大容量データを一括で
クエリできる。
・Lambda をトリガーとして動作させることで
S3 にアップロードされたデータの変換処理を
自動化できる。クローラーを使えばスキーマの
自動検出も可能。
・ジョブの実行はワーカーノードが割り当てられ、
DPU(DataProcessingUnit:4コア
16GBメモリ)単位を指定でき、Flex実行
オプションを使うとautoscaleされる(Flex
はバージョン3以上のsparkジョブのみ)。
・処理の規模に応じて、lambda(15分以内
の処理) < glue python shell(時間
制限なし、メモリはlambdaより多め) <
glue ray(python並列) < glue
apache spark(大規模)を使い分ける。
・Glue studioを使うとローコードでジョブ
作成でき、Glue Stuido notebookを
使うとJupyter notebookでのジョブ作成が可能。
・個人識別情報(PII)を判別する機能がある
(人名やmacアドレス、口座情報など)。
・ジョブの実行管理でstep functions/
MWAA(apache airflow)/Glue
workflowなどと連携したり、eventbridge
のcron式による時間起動が可能。		 リンク リンク blackbelt
2 ETL 抽出、変換、ロード (ETL:Extract/
Transfer/Load) は、複数のソースから
のデータを、データウェアハウスと呼ばれる中心的な
大規模リポジトリにまとめるプロセス。
AWS Glueがそれにあたる。
3 Amazon EMR Elastic MapReduce の略で、Apache
SparkやApache Hadoopなどのオープン
ソースツールを使って、ペタバイト規模の
ビッグデータを効率的に処理・分析するための
マネージド型クラウドプラットフォームサービス。
・クラスター
EMR におけるクラスターは、EC2インスタンス
の集合体。EMR on EC2 のセットアップ
はクラスターがメイン。1 つのアベイラビリティ
ゾーンまたはサブネットにのみ存在する事できる。
Private Subnetに配置する事も可能。
・マスターノード(プライマリーノード)
クラスター内のまとめ役で、ノード間のデータ
や分散したタスクを管理するノード。最小構成
では、マスターノードだけでも可能。spot
インスタンスを使うと処理の安定性が失われる
ため、オンデマンドインスタンスを利用する。
・コアノード
タスクを実行するHDFS（Hadoop
Distributed File System）にデータ
を保存するノード。マスターノードとともに
オンデマンドインスタンスを使うことで安定
する。スポットインスタンスで実行するのは、
HDFSでの一部のデータ損失を許容できる場合のみ。
・タスクノード
タスクを実行するだけでデータの保存する機能
はないノード。オプションのためセットアップ
時は省略が可能。spotインスタンスを使うと
コストが安く済む。
・ブートストラップアクション
クラスターが Hadoopを起動する前に
スクリプトを実行するために使用される。
これにより、追加のソフトウェアを
インストールし、アプリケーションを
カスタマイズ出来る。
・プライマリノードとコアノードに関する
コストを削減するためには、savings
plansの対象となるec2インスタンスを利用する。		 リンク リンク リンク
4 Amazon EMR ・ノートブック
クエリやコードを実行する用途、jupyter
notebookの環境から開く事が可能。コマンド
は EMR クラスター上のカーネルを使用して実行される。
・HDFS
クラスターを管理する Hadoop クラスター
ノード、個別のステップを管理する Hadoop
クラスターノードの間でのデータ連携を行う
ため、マスターノードまたは、コアノード
によって使用される。高速だがクラスターが
終了すると消失するのでキャッシュ置き場に
使う。データの冗長度は基本で３。ストレージ
コストはデータ量の３倍かかる。
・EMRFS
Amazon EMRからS3に通常のファイルを
直接読み書きするために使用するもので、
S3 をHDFSのように扱える。プライベート
サブネット環境だとS3エンドポイントが必要。
・インスタンスグループは、同じノードタイプ
を指定して構成。
・インスタンスフリート（Instance
Fleets）とは、クラスタ内の各ノード
タイプ（マスター、コア、タスク）に対して、
「複数のインスタンスタイプ」と「複数の購入
オプション（オンデマンド/スポット）」を
柔軟に組み合わせて指定できる構成方法のこと。
awsでは、需給バランスによって特定の
インスタンスタイプが利用できなくなることがある。
インスタンスフリートを使えば、1つのタイプが
使えなくても他のタイプを自動的にプロビジョ
ニングしてくれるため、データ処理のパイプ
ラインが止まるリスクを大幅に軽減できる。
5 AWS Lake
Formation		 Amazon S3上のデータレイク構築、
セキュリティ確保、管理を数日で簡素化
するマネージドサービス。
・AWS Glue の拡張機能。周辺サービス
での課金のみで、Lake Formation ⾃体
の費湧は無償。
・クロスリージョン/クロスアカウント共有
は Lake Formation を使わなくても実現
可能だが、Lake Formation を使うことで
⼀元的に設定が可能なため、運湧負荷が減る。
・実体は、ほぼAWSの各種サービスをラップ
したもの(Glue, IAM, S3, etc..)。
・データレイク専用にアクセス制御を行う
ために、IAMとは別に独自の権限管理機構を持つ。
・Lake Formation によるアクセスの制御
は IAM による制御の後に⾏われる。そのため
Lake Formation による細かな制御を
⾏うには、まず IAM による制御を荒く
する必要がある。
・行と列、またはその組み合わせをアクセス
制御できるが、GlueやAthenaなどサービス
によって使えるセキュリティ制御(LFタグ方式
/リソース方式)が異なる。
・ブループリントはデータレイクにデータ
を取り込むためのワークフローを⼿軽に
実装できる機能。
・ブループリントは AWS Glue workflow
でトリガ、ジョブ、クローラーを⾃動的
に設定するため、実装の難易度が低い。		 リンク リンク
6 Amazon
QuickSight		 BIツール。
・管理者（Admin）、作成者（Author）、
閲覧者（Reader）の3つの権限がある。
・s3などの入力をインメモリデータベース
として展開するspiceが使える。
・Amazon Qが使える。		 リンク リンク リンク
7 Amazon
OpenSearch
Service		 AWS上に保存されたデータのナレッジ検索に
特化したサービス。
・AWS上にアップロードした文書などの
ドキュメントデータを検索できる。
・オープンソースの高速全文検索エンジンで、
OpenSearchをAWS上で管理するためのサービス。
・単なるテキストの検索だけではなく、半構造化、
非構造化データの検索にも対応している。
・読み取り専用のデータを格納する場合、
コスト最適化のために標準ノードではなく、
UltraWarmノード/ストレージ(s3利用)
を使用することでコストパフォーマンスが向上する。		 リンク リンク リンク
8 AWS kibana
（現OpenSearch
Dashboards）		 AWSの管理するElasticsearchサービス
（現在はAmazon OpenSearch Service）
のデータを可視化・分析するツール。
・2021年9月までは Amazon
Elasticsearch Service というサービス名だった。		 リンク リンク
9 Amazon
Athena		 サーバーレスのクエリ実行サービスで、S3上
のデータに対してSQLクエリを直接実行することができる。
・クエリ対象のデータ量に応じて課金が発生する。
そのため、GZIPやSnappyなどの圧縮アルゴ
リズムを使用してデータを圧縮することで、クエリ
に対する課金を圧縮すると同時に、パフォーマンス
についても向上させることが可能。
・実行したクエリの結果をS3に自動的に保存。
同じクエリを再実行する際には、前回の結果を再利用できる。
・S3上のデータをパーティション分けすることができる。
これにより、クエリの実行範囲を制限し、
コスト削減につなげることができる。
・Hive 形式のパーティションと Parquet
などの列指向フォーマットを活用することで、スキャン
量を削減しパフォーマンスとコストを最適化できる。
・構造化クエリ向けのサービスであり、S3 上の
全文検索には適さない。
・ODBCによるBIツールとの連携が可能		 リンク リンク
10 Amazon
OpenSearch
Service		 全文検索に最適なマネージドサービス。
・ストレージには、ホットストレージ、Ultra
Warm、コールドストレージ、S3 Glacier
Deep Archiveが利用可能。
・UltraWarmは 巨大なサイズのログ解析を
低コストで可能とする、新しいタイプのデータノード。
・いわゆるウォームストレージと呼ばれるもので
S3にデータを保管する。これにより90%程度
のコスト削減を図ることが出来る。		 リンク リンク
11 Amazon
Redshift		 クラウド内でのフルマネージド型、ペタバイト
規模のデータウェアハウスサービス。
・マルチAZ非対応
・フルマネージド型
・大量データを高速に扱うことのできるデータウェアハウス。
・分析用途に利用できる。
・列指向データベースのためクエリ速度の最適化
とストレージコストの削減が可能。
・SQLを使用する。
・クラスタ{ リーダノード、コンピューティング
ノードp{ノードスライスn1,ノードスライスn2}、
コンピューティングノードq}、ストレージ}
・自動的な増分スナップショットを定期的に取得可能。
・手動でのスナップショット取得可能。
・クラスターのスナップショットを別の AWS
リージョンにコピー可能。
・バッチ処理や外部ファイルとの柔軟な連携には不向き。
・全文検索には不向き。
・DR対応するなら、自動スナップショットを
有効化し、クロスリージョンのスナップショット
コピーを設定して、DR (Disaster Recovery)
リージョンへレプリケーションする。障害発生時には
そのスナップショットからセカンダリリージョン
で素早く Redshift クラスタを復元する
ことができ、RTO 1時間を満たす対策が可能。
・KMS暗号化されているスナップショットは
コピーグラントを設定も必要。		 リンク リンク
12 Amazon
Redshift
Spectrum		 S3 のファイルから構造化および半構造化
されたデータを取得。クエリでは超並列処理を
採用しており、大きなデータセットに対する処理が
非常に高速で実行される。処理の多くは Redshift
Spectrum レイヤーで生じ、データの大部分が
Amazon S3 に保持される。		 リンク リンク
13 AWS
DataExchange		 様々なデータを簡単に共有できるサービス。
・対象データは、S3、API Gateway、
Redshiftデータウェアハウス、AWS Lake
Formation経由のGlueテーブル。
・Reuters、Foursquare、Change
Healthcare、Vortexa、IMDbなどの
サードパーティが提供するデータセットを
Amazon Simple Storage Service
（Amazon S3）を介して購読・利用できる。		 リンク リンク リンク
14 OpenData 行政データ、科学研究、ライフサイエンス、
気候、衛星画像、地理空間情報、ゲノムデータ
など、さまざまなオープンデータセットが登録されている。		 リンク リンク
15 Kinesis
DataStreams
(KDS)/
DataFirehose
/Managed
Service
for Apache
Flink/
VideoStreams		 動画、音声、アプリケーションログ、IoTデバイス
のセンサーデータといったストリーミングデータ
をリアルタイムで収集・処理・分析できる完全
マネージド型サービス。
・Firehose - DynamoDBへの直接
書き込みはできない、Amazon Redshift
を送信先としてネイティブにサポート。
・例えば、ストリーミングデータを日付と
イベントタイプごとにパーティション分割しつつ
S3 に保存できる。
・順序を保証できる
・ファイル単位の長時間処理には不向き
・例えば、スマホの操作データ（タップ、
スクロール、表示時間など）のように大量発生
するデータを、kinesisワーカーで分析させることができる。
・Apache Flink は、無制限の (ストリーム)
データセットと制限付き (バッチ) データセット
をステートフルに処理するためのオープンソース
の分散エンジン。		 リンク リンク
16 Amazon
Kinesis
Client
Library
(KCL)		 Amazon Kinesis Data Streams
からのデータの消費と処理のプロセスを簡素化
するために設計されたスタンドアロンの Java
ソフトウェアライブラリ。
・バージョン 1.x および 2.x は古く最新は3。		 リンク リンク

メディア

Chime SDKってどういう業務の場面で使うんやろ？？？

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS
Elemental
MediaLive		 リアルタイムで映像をエンコードし、ライブ
ソースを高画質なストリームに圧縮するサービス。		 リンク リンク blackbelt
2 AWS
Elemental
MediaStore		 メディア向けに最適化されたストレージサービス
で、ライブストリーミングビデオコンテンツの
配信に必要なパフォーマンス、一貫性、低レイ
テンシーを提供。		 リンク リンク
3 AWS
Elemental
MediaPackage		 さまざまなデバイスに向けたインターネット配信
向けの動画の作成とコンテンツの保護を行うサービス。
・DVR時にユーザーが使用する、再生、一時
停止、巻き戻しなどの機能を簡単につけることが可能。
・デジタル著作権管理 (DRM)に対応でき、コンテンツを保護。
・Amazon CloudFrontと連携することで、
動画をグローバル配信することが可能。
・AWS Elemental MediaLiveと連携
することで、リアルタイムのライブ動画を簡単に作成することが可能。
・Amazon CloudWatchと連携することで、
リアルタイムでのモニタリングや、通知設定を実施することが可能。		 リンク リンク
4 Amazon Chime
SDK		 ビデオ通話や画面共有などを自前アプリに組み込む
ことができるサービス。		 リンク リンク

セキュリティとアイデンティティ

監査で年に１回ぐらいしか見ることないけど、「Artifact」って名前だけ初めて聞いたとき「なんでビルド結果入れる仕組みがこのカテゴリにあるんや」と思ったな。

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS WAF ボットトラフィックを制御するセキュリティ
ルールを作成し、SQL インジェクションや
クロスサイトスクリプティング (XSS)
などの一般的なアプリケーション層(L7)への
攻撃パターンを定義ルールに基づいてブロック
することができる。
・署名ベースのルールセットやIP制御、
リクエストサイズ制限なども可能で、アプリ
ケーションのセキュリティを強化できる。
・動的コンテンツ（Fargate/ALB）
保護：CloudFront に カスタムヘッダー
を付加し、ALB 側に連携された AWS
WAF によって、このヘッダーが存在しない
リクエストを拒否する。これにより CloudFront
以外の経路からの直接アクセスを防ぐ。		 リンク リンク
2 AWS Shield WebアプリケーションをDDoS攻撃から守る
マネージド型セキュリティサービス。全ユーザー
向けの無料版「Standard」と、高度な
保護とサポートを提供する有料版「Advanced」
の2プランがあり、ネットワーク層(L3/L4)
およびアプリケーション層(L7)への攻撃を緩和。
・Advancedは年契約で月額USD3000かかる。		 リンク リンク
3 Amazon
GuardDuty		 AWS アカウントとワークロードを継続的
にモニタリングして悪意のあるアクティビティ
がないかを確認し、可視化と修復のための
詳細なセキュリティ調査結果を提供する
脅威検出サービス。		 リンク リンク
4 AWS
Identity
and Access
Management
（IAM）		 AWS内ユーザの認証と権限管理の仕組み
・ポリシーを作成し、ロールにアタッチ
してグループに許可する
・Permissions Boundaryは「アクセス
許可の境界」として、IAMユーザやIAM
ロールに対して、IAMポリシーに加えて付与
することができるポリシー。IAMグループには
アタッチできない。
・オンプレミスの LDAP サーバーと
API 経由で接続はできない。
・IAM グループやユーザーの統合はアカウント
間ではサポートされておらず、IAM エンティティ
はアカウント単位で分離管理される。		 リンク リンク リンク
5 IAMロール ・conditionに「“sts:ExternalId”:
“xxxxxxxxxxxx”」とすると特定のAWS
アカウントからAssumeRoleによるstsセッション
で許可することができる。
・クロスアカウントアクセスで、ポリシーの
共有やホワイトリスト化ではAssumeRole
の信頼関係を適切に構成できない。
・信頼ポリシーに SAML プロバイダーを
プリンシパルとして明示的に記載していない場合、
SAML アサーションが正しくても STS による
ロール引き受け（AssumeRole）が拒否される。
・ルートユーザは制御できない。Organization
とSCPで制限する。
・AWSアカウントにSAML IdPを統合し、
信頼ポリシーを使ってクロスアカウントアクセス
を実現できる。
・AssumeRoleWithSAMLはすべての
リージョンでサポート。
・Savings Plans は特定のIAMロール
に対してスコープを指定することはできない。
・LDAP資格情報を直接割り当てることはできない。
・AWS アカウント間で管理権限を委譲するには、
クロスアカウント IAM ロールの構成が推奨される。
1)マスターアカウントに管理者用 IAM
ユーザーを作成し、Dev / Test アカウント
側に 信頼されたマスターアカウントの IAM
エンティティに限定して引き受けを許可する
IAM ロール を作成
2)この IAM ロールに対して必要最小限
の操作権限（例：ec2:StopInstances,
rds:DeleteDBInstance など）を付与
すれば、マスターアカウントから Dev /
Test 環境の操作が安全に実行可能		 リンク リンク
6 IAMポリシー IAMロールにバインドして使う。
・SCMで許可されてないものを許可できない
・EC2操作と組織構成の確認を許可する
最小限のアクセスを提供するには、IAMユーザー
にPowerUserAccessマネージドポリシーをアタッチする。
・IAM ポリシーは AWS アカウントを越えて
直接他アカウントのリソースへのアクセスを許可
できない。クロスアカウントロールが必要。
7 AWS IAM
Identity
Center
（旧AWS
SSO）		 IDアクセス管理サービス。
・例えば組織にユーザを所属させておいて、
組織にredshiftやs3利用できるようにアクセス
許可すると１度の認証で利用できる。MFA
と組み合わせるとセキュリティ強化にもなる。		 リンク リンク
8 IAM Access
Analyzer		 リソースのポリシーを確認して、意図せぬ
公開設定などがされていないか検出し、可視化
する機能。
・例えばCloudtrailを使ってlambda
関数が実行するAPIコールを収集し、Access
Analyzerでログを分析することで必要な
アクションだけを含む最小限のIAMポリシーを
自動生成できる。		 リンク リンク
9 AWS
Directory
Service
for
Microsoft
AD		 WindowsServer 2019 を搭載した
マネージドサービス Microsoft Active
Directoryとして実行される。
・MFAを利用したい場合、RADIUSサーバー
（またはMFAプロキシ）の用意が必要。
・EC2のWindows Serverへのログイン自体
にMFAを強要したい場合は、AWS Managed
Microsoft ADの機能ではなく、Windows側に
DuoやOktaなどの独自の「Windows用MFA
エージェント」をインストールする必要がある。
・ADのユーザーを使って、AWSマネジメント
コンソールやAWS CLIへのログインを安全に
MFA化する場合は、RADIUSサーバーを立てる
よりも、AWS IAM Identity Center
（旧AWS SSO）を利用する方が簡単に実装できる。		 リンク リンク
10 Simple
active
directory		 Samba4 actrive directory互換
サーバが管理するスタンドアロンのマネージドディレクトリ。
・MFAはサポートしない。
11 AWS IAM
Identity
Center
(AWS SSO)		 AWS アカウントとアプリケーション全体で
一元的にアクセスを管理できるようにする
クラウド認証ソリューション。
・組織内の認証に使う
・IDプールには、AWS SSOがデフォルト
で利用され、それ以外にMicrosoft Active
Directoryや、外部IDプロバイダーなど指定ができる
・SSOアプリケーションには、AWSサービスの
他に、クラウドアプリケーションを指定し
管理することができる。		 リンク リンク
12 Amazon
Cognito		 ウェブおよびモバイルアプリケーション向けの
ユーザー認証、認可、およびユーザー管理サービス。
GoogleやFacebook・Amazonなどの
ソーシャルIDを使った認証も提供している。
・不特定多数の利用による認証に使う
・ユーザープールは、独自のディレクトリ持って
おり、ユーザー名やパスワードが補完できる機能。
ユーザーディレクトリを用いて、アプリユーザーの
サインアップとサインインを提供する。
・IDプールはアイデンティティプールとも呼ばれ、
AWSのほかのサービスに対するアクセスを許可する機能。
・IAMロールを用いたクロスアカウントアクセスには適さない
・恒久的な認証情報はモバイルアプリへの保存
に適さず、セキュリティリスクが高まる。		 リンク リンク
13 AWS STS
(Security
Token Service
)		 AWS リソースへのアクセスをコントロールできる
一時的セキュリティ認証情報を持つ、信頼された
ユーザーを作成および提供。
・AssumeRoleWithWebIdentity API
を使用し、ソーシャル ID プロバイダー（Google
、Facebook など）と連携できる。IAM
ロールを作成し、S3やDynamoDBなどへの
アクセスを許可できる。アクセスキーの埋め込み
が不要で、セキュアかつスケーラブルになる。
・IAMロールを作成しておいて、Active
Directory を ID プロバイダー（IdP）
として統合し、STSを使って一時的な認証情報
が発行されるようにしておくと、ロールには、その
ユーザー専用の S3 フォルダ（例: s3://
bucket-name/users/${user_name}/
）にだけアクセスできるようポリシーが設定される。		 リンク リンク
14 AWS security
hub		 重大なセキュリティ問題に優先順位を付け、
環境を保護するための大規模な対応を支援する。
・Cloud Security Posture Management
（CSPM）に相当するサービスで、「AWSリソース
のセキュリティ設定がベストプラクティスから
逸脱していないか」を自動でチェックする。
・AWS configを同一リージョンで有効化し、
必要なセキュリティ標準を選択、適用して利用する。
・チェック結果はスコア化して表示され、
オートメーション機能により条件指定した
アクションを利用して通知などが行える。
・IAM Access Analyzer と Macie
の調査結果は両方とも Security Hub
で報告できる。
・複数のリージョン、アカウントにまたがる、
クロスリージョン集約とマルチアカウント集約が可能。
・コントロールのパラメータ変更（ログの保持期間
を1年ではなく2年にする、検証環境のRDSは
バックアップ不要等）が可能。		 リンク リンク blackbelt
15 AWS Secrets
Manger		 データベースの認証情報や、パスワードなどの
任意のシークレット情報をAPIコールで取得できる
ためのAWSサービスの一つ。
・サーバからこのAPIを叩くことでシークレット
情報を取得でき、認証やサーバセットアップに利用できる
・ECS タスク定義に Secrets Manager
のシークレット ARN を指定し、タスク実行
ロールを用いることで、環境変数経由で認証情報
を安全に取り出せる。
・定期的なパスワードローテーションが可能。		 リンク リンク リンク
16 AWS
Certificate
Manager
(ACM)		 SSL/TLS証明書の発行、管理、および
自動化を行うフルマネージドサービス。
・Amazon Elastic Load Balancer
（ELB）、Amazon CloudFront、Amazon
API Gateway、AWS Elastic Beanstalk
などのAWSサービスと統合されている。
・2016年より以前はこのサービスがなく、それ
まではIAMに証明書をアップロードしていた。		 リンク リンク リンク
17 AWS
CloudHSM		 ハードウェアセキュリティモジュール (HSM)
の管理。シングルテナント HSM インスタンス
を用いて保護された、FIPS 検証済みのハード
ウェアでキーを管理し、アクセスすることができる。
・KMSより高価		 リンク リンク
18 AWS Network
Firewall		 VPC 全体に高度な Network Firewall
セキュリティをデプロイできる。
・すべての外部通信をTransit Gateway
経由で1つのVPCに集中させることで、
AWS Network Firewallで一元的に
フィルタリングでき、個別にファイアウォールや
プロキシを設置する必要がなくなり、運用効率
とセキュリティの一貫性が確保される。
・ステートフルインスペクション、侵入防止・
検知、Webフィルタリングを簡単に導入・管理できる。
・Lambda に対するトラフィック制御を直接
行う用途には適さない。		 リンク リンク
19 Firewall
Manager		 アカウント全体のファイアウォールルールを一元的に
構成および管理するサービス。
・セキュリティグループやWAFなどのファイア
ウォールルールを一元的に管理できる。
・管理者アカウントとメンバーアカウントの2種類
のアカウントを使用。
・セキュリティポリシーの適用状況や違反状況を監視し、
レポートすることができる。		 リンク リンク
20 Amazon
Macie
(メイシー)		 ML利用して機密データを発見し、データ
セキュリティのリスクを可視化して、そのリスク
に対する自動的な防御を行う。
・例えばS3バケットにdocx、xlsx、
txt、pdf、csvなど色々なオブジェクトが
あり、その中から機密データが含まれる
オブジェクトを検出してくれる。
・課題としてキーワードが日本語対応してない。
例えば「生年月日」は「birthday」などの
英語のキーワードが必要であり、「生年月日」
といった日本語のキーワードでは検出されない。
・日本の制度や日本語に依存しない識別子
については利用可。正規表現で全角文字の指定も可。
・CodeCommit(git)のスキャンには対応していない。		 リンク リンク
21 Amazon
Detective		 セキュリティインシデントの分析と調査を支援
するサービス。
・VPCフローログ、AWS CloudTrail、
Amazon GuardDutyのデータを自動的
に収集。
・収集したデータを加工し、グラフモデルと
呼ばれる関連性の高いデータセットに変換。
・グラフモデルに対して機械学習や統計分析
を適用し、異常なアクティビティやパターンを検出。		 リンク リンク
22 Amazon
Inspector		 EC2インスタンス、コンテナイメージ、
AWS Lambda 関数などのワークロードや
コードリポジトリを自動的に検出し、ソフト
ウェアの脆弱性や意図しないネットワークへの
露出がないかスキャン。
・パッケージの脆弱性については、AWS
Systems Managerの機能を使用。
・テンプレートを設定すれば、起動された
インスタンスが自動的に評価対象となるため、
頻繁な AMI 展開にも対応可能。		 リンク リンク
23 AWS Artifact ISO、PCI、SOCなどのセキュリティ・
コンプライアンスレポートや、HIPAAのBAA
契約書などをオンデマンドで取得・管理できる
無料のセルフサービスポータル。AWSの安全性
に関する証跡を一元管理し、監査対応や規制遵守
（コンプライアンス）の負担を軽減する。利用は無償。		 リンク リンク
24 AWS Audit
Manager		 AWS アカウント内のリソースがコンプライ
アンス違反していないかを継続的にチェックする
リソース。
・AWSの使用状況を継続的に監査し、従来手動
で行われていた証跡収集を自動化し作業コスト
を削減できる。
・リソース評価は、証拠を収集、保存、および
管理するプロセスであり、医療保険の相互運用性
と説明責任に関する法令 (HIPAA) や
PCI データセキュリティスタンダード (PCI
DSS) などの業界標準や規制へのリスクと
コンプライアンスを評価する際に使用できる。
・リソース評価 1,000 件ごとで単価が決められている。		 リンク リンク リンク

マネジメントとガバナンス

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS Cloud
Formation		 JSONやYAML形式の「テンプレート」
と呼ばれる定義ファイルに基づいて、AWS
リソース（EC2、ELBなど）の構築や
管理をコードで行うことで自動化する
Infrastructure as Code (IaC) サービス。
・Stackとは CloudFormation
テンプレートで管理されているリソースのかたまり。
1つのテンプレートにつき1つのStackが必ず
生成される。 そして、StackSetsはこの
Stackをマルチアカウントあるいはマルチ
リージョンで展開する仕組みを指す。
・CloudFormation StackSetsを
使うことで、1つのテンプレートから複数の
AWSアカウント、リージョンに対しStackを
作成することが可能。
・スタックの更新は時間がかかる。
・cloudformationを通じてec2やrds
などの構築をするときは、その実行許可を
IAMロール・ポリシーで許可しておく必要がある
・リソースの削除時の挙動を制御するために
DeletionPolicyを指定できる。RDSには
“Snapshot"オプションがあり(retain
にすると削除されず残る)、削除時に自動
でスナップショットを作成できる。これにより、
インスタンス自体は削除されコストを抑え
つつ、後から復元が可能。一方、S3バケット
は"Retain"を指定することでStack削除時
にもバケットが保持される。
・AWS::AutoScaling::Auto
ScalingGroup に UpdatePolicy
属性を追加し、AutoScalingRolling
Update を指定すると、CloudFormation
はローリングアップデート戦略を用いて Auto
Scaling グループ内のインスタンスを順次
新しい AMI に置き換える。
・Resource Tags プロパティを使えば、
テンプレート内で定義されたリソースに対して
自動的にタグを適用できる。
・スタックを削除する前にs3バケットが
空でない場合は削除できない。		 リンク リンク リンク リンク
2 AWS Service
Catalog		 AWSで起動するサービス群をカタログとして
管理できるサービス。
・例えば、EC2とRDSを使ったWebアプリ
ケーションに関するCloudFormationだけ
を許可したい場合に利用でき、AWS
CloudFormation テンプレートを各aws
アカウントにOrganizationを通じて共有する。
・開発チーム向けのCloudFormationで
のアプリ展開テンプレートの範囲内でリソース
を展開できるよう、テスト担当者が操作可能
になるように制限されたアクセスを提供できる。
・CloudFormationとIAMをAWS
Service Catalogという形でくるみ、
管理できるようにしているので管理者側で作成
できる環境の定義、利用者側で起動可能な
サービスをカタログから選択、という使い方ができる。
・ポートフォリオ、製品、ユーザーごとの
一意の識別子を使用してタグを付与できる。
・標準構成で展開できるので、コスト統制が可能になる。		 リンク リンク リンク
3 launch
constraint		 AWS Service Catalogで定義。
管理者が定義すると、利用者はその制約を受ける。		 リンク
4 AWS Control
Tower		 マルチアカウント環境を自動でセットアップ
するサービス。コンフィグジェネレーター
の役割を持つ。
・セキュアなマルチアカウント環境を実現
するには、所属するアカウントへの統制、
適切なポリシーの設定などが必要。
・ガードレールは、AWS利用者がセキュリティ上
問題のある操作をしないよう検知・防止する考え方。
コントロールと同義。４０0を超える
プリセットのコントロールがある。
・コントロールには予防コントロール(リソース
操作を防止)、検出コントロール、プロアクティブ
コントロール(ポリシー違反を検出したらリソース
変更を拒否)の３種類があり、例えば、暗号化
されていないEBSボリュームを自動検知する
検出コントロールが提供されている。
・ランディングゾーン、スケーラブルで安全な
マルチアカウント環境のこと。
・ダッシュボード、ランディングゾーンを監視。
・管理アカウント(権限管理用でSCP適用
されない)、監査アカウント(セキュリティチーム
やコンプライアンスチームが利用)、ログ
アーカイブアカウント(ログをs3やcloudtrail
に保管)、メンバーアカウント(一般アカウント)を利用する。
・管理アカウントには管理者権限
(AdministratorAccess)を持たせる。
・rootにはリソース作成を妨げるscpを
アタッチせず、FullAWSAccessポリシー
のみアタッチするのが推奨。メンバーアカウント
はいずれかの組織に属するので、OUにSCP
をアタッチしてコントロールする。
・ホームリージョンは一度設定すると変更できない。
IAM identity centerと同じリージョン
にする必要がある。管理対象リージョンは設定後に
変更できる。
・１つのOUにはメンバ３０0まで登録可能。
SCPのアタッチは５つまで(階層構造にすればいい)。		 リンク リンク blackbelt
5 Amazon
Managed
Grafana		 Grafana Labs社が開発したデータの
可視化ツール。
・事前にAWS SSOの設定を完了させておく必要あり。
・CPUやメモリなどのメトリクスをグラフ表示してくれる。		 リンク リンク リンク
6 Amazon
Managed
Service
for
Prometheus		 kubernetesのpod/コンテナのメトリクス
をモニタリングする Prometheus 互換の
サーバーレスサービス。eks/ecsからメトリクス
をadot collectorというエージェント経由
(ecsのタスク内でサイドカーとして定義)
で収集して大規模なコンテナ環境を安全にモニタリング。
・ecsでサイドカーとして定義するadot
collectorの設定を作る場合、ssmの
パラメータストアを利用して参照させる。
・eksでeksアドオンを利用するとadot
operatorを利用可能。他にもAWS
observability Acceleratorの
terraformモジュールを利用してamp/adot/
grafanaなどのツールをデプロイ可能。
・cloudwatch container insight
は変換費用が高くなることもあり、prometheus
のほうがカバー範囲が広い。
・オンプレのメトリクスを集める場合、
アクセスキーではなくssmエージェントを利用して集める。		 リンク リンク リンク blackbelt
7 AWS
Cloudwatch		 サービスやアプリケーションの監視、ログの
収集・分析、アラーム通知、自動アクションを
実行する統合モニタリングサービス。
・ec2やrdsのcpuメトリクスが得られる。
・ec2ホストにエージェントをインストール
し、メトリクス取得情報をjson定義しておくと、
ディスク利用率やメモリ利用率のメトリクスも得られる。
・batch_countを１に設定するとログが
即時にcloudwatchLogsへ送信され、auto
scale構成のスポットインスタンスが終了しても
ログが失われない。
・CloudWatch LogsはS3アクセスログ
の対象ではない。		 リンク リンク リンク
8 CloudWatch
Synthetics		 WebページやAPIエンドポイントに対する
Synthetic Monitoringを設定、自動実行
できるマネージドサービス。
・Canaryというリソースを作成して監視を
行う。CanaryはNode.jsまたはPython
ランタイムのLambda関数を作成してスクリプトを実行する。
・CanaryはNode.jsではPuppeteer、
PythonではSeleniumを使用して
Chromium（ヘッドレスブラウザ）を操作
し、指定されたエンドポイントURLにアクセス
して監視を行う。
・Webサイトをブラウザで開いた際のHAR
（HTTP Archive）ファイルも確認できる。
各通信ごとのステータスやレイテンシーを確認できる。
・スクリーンショット、ログ、HARファイル
はアーティファクトとしてCanary作成時に
指定したS3バケットにアップロードされる。
（既定で30日間保管）
・稼働状況モニターはターゲットにのみ
アクセスし、サービスが内部エラーメッセージ
で応答するかどうかを判断できない。
・API カナリア設計図を利用し、GET
メソッドで API カナリアを作成して、
サードパーティーサービスが期待どおりに
応答しているかどうかを判断できる。		 リンク
9 AWS X-Ray アプリケーションやマイクロサービスにおける
リクエストの実行状況を追跡・可視化し
(observability)、パフォーマンスの問題や
ボトルネックを特定するためのマネージドサービス。
・autoscale構成ではローカルログが消えて
しまうので使うべき。
・AWS X-Ray へトレースデータを送信
する方法はいくつかある。
-> X-Ray SDKのライブラリ(java/
node.js/python/.net/ruby/go)を利用
-> AWS SDKのAPIであるPutTrace
Segments(java/.net/ruby/go/php
/python)を利用してjsonで送る
-> AWS CLIのput-trace-segments
やput-telemetry-recordsを利用
・lambda/sqsなどのサービスをX-ray
を有効化することが可能。
・ec2にもX-rayデーモンを導入でき、
オンプレ環境にも導入可能。
・ecsの場合はタスク内でサイドカーとして
dokcerコンテナで稼働させる。		 リンク リンク リンク blackbelt
10 AWS
Cloudtrail		 AWSアカウントで実行されるすべてのAPI呼び出し
とその履歴を記録するサービス。2015年
12月からマルチリージョン構成が選べるようになった。
・直近90日間のイベントが保存可能。90日間
を超えて保存するためには、Amazon S3
などを利用する必要がある。
・AWS CloudTrail Lakeは、イベントに対して
SQLベースのクエリを実行できるサービスで、
AWS CloudTrail標準のダッシュボードよりも、
複雑な条件でイベントを検索することができる。
・プレビュー段階のサービス、まだ一般公開
(GA) されていないサービス、また、公開
API がないサービスは、サポート対象外。
AWS Import/Exportもサポート外。		 リンク リンク blackbelt
11 AWS
Organizations		 複数のAWSアカウントを一元的に管理・統制
するためのサービス。
・管理アカウントになるAWSアカウントは変更
できないため、管理アカウントは慎重に選択する必要あり
・ServiceControlPolicy(SCP)を書いて
ポリシー運用し、OU単位でサービスの制御が可能。
・ReservedInstance(RI)の割引適用に
使う(IAMポリシーでは制御できない)。
・Savings Plans の共有設定は、AWS
Organizations の管理アカウントから各メンバー
アカウントごとに有効/無効を設定可能。共有を
無効化すれば、該当アカウントで購入された割引
は他のアカウントに影響しない。
・OrganizationAccountAccessRole
を通じてマスターアカウントから各アカウントへの
アクセスも統合的に制御できる。
・管理アカウントから、管理対象アカウントへ
Organizationsへの招待を行い、「すべての機能」
を有効にすることで統合請求と一元管理の両方
を実現可能で管理対象アカウントごとのコスト
を可視化・分析できる。
・管理アカウントでCost and Usage Report
(CUR)を生成してS3にcsv出力し、
AthenaやQuickSightを使って管理対象
アカウントごとのダッシュボードを作成できる
・複数のOrganizations間でのSCP管理はできない。
・Organizationsを利用しない１アカウント
管理では、リソースタグに対応していないサービス
やトラフィックなどはコストを分離できない。
また、タグ付けや集計に手間がかかる。リザーブド
インスタンスを個別に適用などはできない。		 リンク リンク リンク
12 SCP Organizationsで使う１つの機能。サービス
コントロールポリシー。組織のセキュリティ統制、
特に予防的ガードレールとして役立つ機能で、実態はIAMポリシー。
・管理アカウント以外のすべてのアカウントに適用可能。
・組織単位での許可アクションの上限を定義する
ため、記載されていないアクションはすべて暗黙的に
拒否される。
・OUにアタッチすると配下のアカウントすべて
に即時反映される。個々のアカウントに SCP
をアタッチすると、多数のアカウントのうちそれぞれ
に追加設定が必要になってしまう。
・AWSが自動で作成・管理するサービスリンク
ロール（Service-Linked Role）には適用されない。
・例えば、API 呼び出し（例: Associate
Address）を事前にブロックできる。これにより、
例えばEC2へのパブリック IP の付与などを構成
レベルで防止可能。
・サービス利用を制限しているときに、別アカウント
を招待したてのときはサービス利用できないことがある。
IAMで許可してもサービスが制限されているため、
このときは新規OUを作成して、そのOUにサービス
利用許可を行い、別アカウントをそのOUに属させる。
・AWS Organizations配下のアカウント全体
に対して「指定されたタグキーが含まれない限り
リソースを作成できない」という条件を適用できる。
例えば、“aws:TagKeys” を使って部門コード
などの存在を必須とすることで、タグなしリソース
の作成を技術的にブロックできる。		 リンク リンク
13 AWS Trusted
Advisor		 コストの最適化、パフォーマンスの向上、
セキュリティと耐障害性の改善、クラウドで
の大規模な運用を支援する。
・レポートは定期的な確認はできるが、
リアルタイムでは不可。		 リンク リンク
14 AWS License
Manager		 ソフトウェアのライセンスの過剰使用や期限切れ
などの問題を解消して、ライセンス管理をスムーズ
に行うためのサービス。
・追加料金なしで利用できる。ただし、AWS
License Managerを利用する際は、EC2
インスタンスなどの計算リソースを使用して、
ワークロードを実行するのが一般的。		 リンク リンク
15 AWS Resource
Access
Manager（RAM）		 AWS でリソース共有を有効にするには、AWS
Resource Access Manager（RAM）
コンソールに移動し、組織内での共有を有効にする
設定をオンにするか、AWS CLIコマンド aws
ram enable-sharing-with-aws-
organization を実行。
・lambdaは別awsアカウントへ共有不可。コード
をエクスポートして再作成が必要。
・別awsアカウントへRDSの高速なクローン作成
が可能でダウンタイムをほぼゼロに抑えられる。		 リンク リンク
16 AWS Config AWSアカウント内に存在する各種AWSリソース
（EC2、EBS、セキュリティグループ、VPC
など）の構成情報を取得し、管理するサービス。
・監査には有効、アカウント統合・権限委譲・
ログを提供するわけではない。
・リソース変更（ユーザー追加含む）を検出する
監視機能を利用して、SNSやEventBridge
と組み合わせてリアルタイム通知が可能。
・例えば、S3バケットポリシーの変更検出と
自動修復アクション(リメディエーション)を設定できる。
・EC2 インスタンスがどの AMI から起動
されたかを評価し、承認されたAMI以外から
起動されている場合に自動通知・アクションを行える。		 リンク リンク リンク
17 AWS Config
Conformance
Pack		 適合パックを使用すると、コンプライアンス
ルールのパッケージを作成することができる。この
パッケージは AWS Config ルールと修復
アクションの両方を単一のエンティティにまとめ
たもので、大規模な展開を容易にする。		 リンク リンク
18 AWS OpsWorks Puppet または Chef. OpsWorks
Stacks を使用してクラウドエンタープライズ
でアプリケーションを設定および運用するのに
役立つ設定管理サービス。
・2024年5月でサービス終了
・EC2に自前でchefサーバーを作るか、
Chef SaaSを利用する必要がある。		 リンク
19 AWS Systems
Manager
Patch
Manager		 Windows ノードにサービスパックをインストール
したり、Linux ノードでマイナーバージョン
のアップグレードを実行したりすることができる。
Ec2インスタンスだけでなく、オンプレの仮想
サーバに対してもパッチを管理できる。
・Patch Groupごとに異なるMaintenance
Windowを設定することで、インスタンス群に対して
時間をずらしてパッチを適用することが可能。
により、すべてのインスタンスが同時に再起動
することを防ぎつつ、最新のパッチを自動で適用可能。		 リンク リンク
20 AWS Systems
Manager
Session
Manager		 EC2インスタンス、エッジデバイス、オンプレミス
サーバ、VMを管理できる。
・SSM agentをインストールしておく
(amazon linuxはプリインストール)。
・IAMでSSM用の許可設定(Amazon
SSMManagedInstanceCore)を付与する
ことで、ポートを閉じたままアクセスできる。
・インバウンドポートを開いたり、踏み台
ホストや SSH キーを管理したりする必要がなく
bastion利用よりもベター。		 リンク リンク
21 AWS Systems
Manager
Automation		 AWS リソースを大規模にデプロイ、設定、
管理のための、自動化されたソリューション
を構築するのに役立つ。
・AWSSupport-ExecuteEC2
Rescue ドキュメントを活用し、課題を
自動診断・修復する。この方法により、RDP
や SSH の設定ミス、ネットワーク構成の
課題などが原因でアクセス不能になった EC2
インスタンスを自動的に診断・修復できる。		 リンク
22 AWS Systems
Manager
Parameter
store		 AWS Systems Manager の機能。
・単純に設定値や秘密情報を保存して、
アプリケーションから簡単にアクセスしたい時に利用。
・シークレットやパスワードだけでなく、URL、
データベースホスト名、カスタム設定、プロダクト
キーを保管でき、デフォルトは平文だが暗号化も可能。
・SecretManagerと違って、自動ローテーション機能がない。		 リンク
23 SSM Agent EC2インスタンスに導入して使うと、Systems
Manager でリソースを更新、管理、設定
できるようになる。SSHやRDPポートを開放
する必要がない。IAMによるアクセス制御ができ、
Cloudtrailによる操作ログ取得も可能。
・ECS構成のバックエンドで動くEC2
に対してRun Command を使用すると、
1 回の操作ですべての EC2 インスタンス
を変更が可能。		 リンク リンク
24 AWS
AppConfig		 AWS Systems Manager の機能。
・アプリケーションの設定を逐次更新して、
リアルタイムでアプリケーションに適用可能。
・アプリケーション設定を作成、管理し、迅速
にデプロイする。設定は、アプリケーションの
動作に影響する設定のコレクション。		 リンク リンク

ブロックチェーン

なんやそれ。まったく扱ったことない。

No サービス名 内容 URL1 URL2 URL3 URL4
1 Amazon
Managed
Blockchain
(AMB)		 フルマネージド型のサービスで、オープン
ソースフレームワークのHyperledger
Fabricや Ethereumを使用し、スケー
ラブルなブロックチェーンネットワークを簡単
に作成し管理できるサービス。
・ブロックチェーンとは分散型ネットワークが
組み込まれた複数のコンピューターで、暗号技術
を使うことでデータの改ざんや不正利用をされ
にくいデータを記録する方法。台帳(ledgers
)/非中央集権(Decentralization)/
コンセンサスアルゴリズム(Consensus
algorithm)で構成される。		 リンク リンク
2 Amazon
Quantum
Ledger
Database
(QLDB)		 Amazon QLDBは、データが不変で分散
化する必要ない中央集権的であることに対し、
Amazon Managed Blockchainは、
データを複数で検証する必要がある中央機関
なしのサービス。		 リンク

ビジネスアプリケーション

コールセンター作るれるって、イメージ湧かんがな。でもテストには出てたで。

No サービス名 内容 URL1 URL2 URL3 URL4
1 Amazon
Pinpoint		 メッセージの一斉送信、顧客管理、レスポンス
分析のできるサービス。
・2026年10月30日をもって
サポートを終了予定
・例えばメッセージの開封率から、
どんなメッセージ<がどの時間に
どんな人だと読んでもらいやすいか
などを可視化できる。		 リンク リンク
2 Amazon
Connect		 コールセンターを開設できるサービス。 リンク リンク リンク

クラウド財務管理

RIとかSaving Plansは「もうすぐ契約終わるで」とか言うてくれへんかったはず。

期限切れるの忘れててそのまま使ってたら割引適用終わって、ビックリ課金来たら悲惨。

No サービス名 内容 URL1 URL2 URL3 URL4
1 RI
(リザーブド
インスタンス
)		 EC2、Redshift、RDSとRIの料金
体型。オンデマンドと比べると３0〜６０%
ほど費用節減できる。事前に費用を支払う
ことで時間単価が低価格になり、キャパ
シティの確保ができる料金オプション。
・支払い方法
No Upfront - 前払いなしで、時間単価が低下。
Partial Upfront - 従来の重度使用と同じ。
All Upfront - 全ての料金を前払い。
・組み合わせ
１年 No Upfront (前払いなし)
１年 Partial Upfront (一部前払い)
１年 All Upfront (全前払い)
３年 Partial Upfront (一部前払い)
３年 All Upfront (全前払い)
・スタンダードRIでは、特定のインスタンス
ファミリー契約していると、EC2インスタンス
の使用量に応じて割引適用される。
・コンバーティブルRIでは、期間中に
インスタンスの構成を変更できるオプションが
提供され、EC2インスタンスの使用量に応じて
割引を受けることができる。
・FargateとLambdaのコスト最適化は
実現できない(サーバーレスのコンピューティング
エンジンであるため、インスタンスという概念を
意識せずに利用する仕組みになっているため)。		 リンク リンク blackbelt
2 Savings
Plans		 AWS の使用コストをオンデマンド料金
よりも 最大 72% 削減できる柔軟な料金
モデル。EC2についてリザーブドインスタンス
よりも柔軟に設定できる。
・Organizationsを利用している場合、
管理アカウントまたは何もリソースを持たない購入
専用アカウントを作成し他のアカウントへ共有
するのがベストプラクティス。
・Compute Savings Plans、EC2
Instance Savings Plans は、
Amazon EMR、 Amazon EKS や
Amazon ECS で利湧している EC2
インスタンスにも適用。
・SageMaker Savings Plansは、
SageMaker Studio Notebook,
SageMaker Processing, Sage
MakerData Wrangler など各機能で
利湧するインスタンスの使湧に⾃動的に適用。
・EC2、Fargate for ECSの利用料
を最大で72%削減。
・Fargate for EKSの利用料を最大
で52%削減。
・Lambdaの利用料を最大で17%削減。
・SageMakerの利用料を最大で64%削減。
・1年間または3年間、一定の利用料をコミット
するだけで、その利用料に対して割引が適用。
例えば、10 USD / 時間 をコミット
すると、その利用料に対して割引が適用される。
・既にRIを購入している状態でSavings
Plansを買うと、RIの方が優先的に適用され、
RIが適用されていないAWS利用料に対し、
Savings Plansが適用される。
・EC2 Instance Savings Plans
は Compute Savings Plans よりも
優先して適用される。		 リンク リンク blackbelt
3 AWS Budgets 使用状況をモニタリングし、事前に設定した
予算を超過しそうな場合や実際に超過した場合
に、Eメールなどで通知を行うコスト管理サービス。
・予算アクションの設定や予算レポート機能
を利用する場合には、料金が発生。
・通知は可能でも、アカウント停止や強制的
制御はできない。		 リンク リンク blackbelt
4 AWS Cost
Explorer		 AWSサービスの使用状況やコストを棒グラフ
などで視覚的に分かりやすく表示してくれる
コスト管理サービス。
・1時間ごとの詳細な使用状況を確認する場合
は、1日の使用レコードにつき0.00000033
ドル（USD）の料金が発生。また、APIを利用
する際には、1リクエストごとに0.01ドル
（USD）が必要。		 リンク リンク

その他

AWS Well-Architectedフレームワークはどうしても頭に入らん。

他にも大事なことがあるような気がするんやけど、なんで柱が６つでこの内容なんやろな。

No サービス名 内容 URL1 URL2 URL3 URL4
1 AWS Well-
Architected
フレームワーク		 AWSが提唱するAWSクラウドの設計や運用
のベストプラクティスにおける指針。
・AWS認定試験では、「最適なものを選べ」
という問題が出る。試験は選択形式で、出題
される要件を満たす選択肢を選ぶが、要件を
満たす選択肢が複数存在する場合がある。
その際に選択肢を比べる指針となるのがWell
-Architected フレームワーク。
・運用上の優秀性・セキュリティ・信頼性・
パフォーマンス効率・コスト最適化・持続
可能性 が6つの柱		 リンク リンク リンク
2 AWS Black
Belt		 Amazon Web Services Japan
が主催する、AWSの各種サービスに関する体系的
な知識を学べる無料のオンラインセミナーシリーズ
のこと。Qiitaにはaws-trainingの
カテゴリ記事があって、そっちのほうが頭に入りやすい。		 リンク リンク リンク

用語

試験に出てくる単語でわけわからんものを撲滅するためにメモを作ってるんやけど、時間経ったら絶対忘れる。

RPO/RTOはどっちがどっちやとか、スケールアップ・ダウン・イン・アウトもどれがどれやって絶対こんがらがる。

DNSのレコードの種類がどうしても覚えられへんから、たまに読み返す。

No サービス名 内容 URL1 URL2 URL3
1 半構造化、
非構造化		 ・構造化データは、あらかじめデータを
管理する構造を決めて、その構造に合わせて
データを格納していく「Schema-on-
Write」の方式を取る。RDBMSで実装される。
・非構造化データは、XMLやJSONの
ように、あらかじめ定義されたスキーマや
モデルに従って整理されていないデータのこと。
・半構造化データは、構造化データと非構造化
データの中間に位置する。グラフ型・キー
バリュー型・ドキュメント型・カラム型の４つ
に分類され、いずれもデータ＋名前（タグ）の
組み合わせでデータを管理。
2 スケールアップ
(垂直スケール
)		 CPU、メモリ、ディスクなどの性能を上げる。 リンク
3 スケールダウン
(垂直スケール
)		 CPU、メモリ、ディスクなどの性能を下げる。
4 スケールイン
(水平スケール
)		 ２台のホストを１台に減らして運用。
5 スケールアウト
(水平スケール
)		 １台のホストを２台に増やして運用。
6 OWASP OWASP (Open Worldwide
Application Security Project)
。
・OWASP Top10
1. アクセス制御の不備
2. 暗号化の失敗
3. インジェクション
4. 安全でない設計
5. セキュリティの設定ミス
6. 脆弱で古くなったコンポーネント
7. 識別と認証の失敗
8. ソフトウェアとデータの整合性の不具合
9. セキュリティログとモニタリングの失敗
10. サーバーサイドリクエストフォージェリ（SSRF)		 リンク リンク
7 セキュリティ
ポスチャー		 組織のセキュリティ体制を評価し、
改善し続ける取り組み。		 リンク
8 シャーディング 大規模なデータベースの負荷分散とスケーラ
ビリティ向上を目的に、データを複数の物理
サーバーに分散して格納する技術。
Aurora DSQL のように各性能が「実質
無制限」にスケールするデータベースでは、
そもそもシャーディングを行う必要がない。		 リンク リンク
9 KMS Key Management Service
（キー管理サービス）		 リンク
10 CMK Customer Master Key
（カスタマ管理のキー）
11 クレデンシャル IAMユーザのクレデンシャルをアプリに埋め込む
のはセキュリティ的にリスクがあるので
やってはいけない。
12 Let’s
Encrypt		 非営利の Internet Security
Research Group のプロジェクトで、無料
の TLS 証明書を提供する認証局。		 リンク
13 モノリシック
アーキテクチャ		 アプリケーションの全ての機能が単一のコード
ベースや大きなモジュールに統合され、一枚岩
のように動作するソフトウェア設計手法。
・シンプルで処理の高速化がメリット、肥大化
しやすく機能追加しづらいのがデメリット。		 リンク
14 マイクロサービス
アーキテクチャ		 独立してデプロイ可能な小規模なサービスの集合体。 リンク
15 ステートレス・
ステートフル		 ステートフルとは、システムが過去のやり取り
や現在の状態（ステート）を記憶・保持し、
その状態に基づいて処理を行う仕組み。オンライン
ショップのショッピングカート機能はステートフル
なシステム。
ステートレスとは、「状態を持たない」ので、
サーバーがクライアントの過去のやり取り
（状態）を記憶せず、リクエストごとに独立
して処理を行う方式。Http通信だと、サイト
管理者がそのコンテンツを削除したり変更したり
しない限りは、何度やっても、誰がどのマシン
でやっても、表示されるのは同じWebサイト。		 リンク
16 旧AZ(apne
1-az3)
でできないこと		 古い時期に作成されたAWSアカウントにはAZ
が4つあることがある。
apne1-az3(2025/2/28に廃止
された)は、AWSの新しい機能が提供され
ない可能性が高いAZなので使うのは
避けたほうがベター。
・Transit Gatewayが使えない
・NAT Gatewayが作れない
・IOPS SSD(io1)が使えない
・VPCエンドポイントが作れない		 リンク
17 スパイク 何かが急激に増加すること。CPUやメモリ
の利用率が急激に上がったり、ネットワーク
トラフィックが増えたり。		 リンク
18 RPO 目標復旧時点（Recovery Point
Objective）のこと。障害発生時、過去の
「どの時点まで」のデータを復旧させるか
の目標値である。例えば更新頻度の少ないシステム
では、障害発生の24時間前までのデータ（RPO
＝1日）で復旧できれば支障ないこともある。
逆に24時間365日連続的にサービスを提供
する通販サイトでは、復旧時に停止直前まで
のデータ（RPO ＝0秒）が求められる。		 リンク
19 RTO RTO（Recovery Time
Objective）とは、障害発生時「どのくらい
の時間で（いつまでに）」 復旧させるかを定めた
目標値である。言い換えると、RTO は「システム
停止やサービス中断が許される時間」とも言える。
20 ブルーグリーン
デプロイ		 新旧2つの本番環境（ブルーとグリーン）を
並行稼働させ、新バージョン（グリーン）への
トラフィックを徐々に移行し、デプロイを安全
に行う手法。問題発生時には素早く旧バージョン
（ブルー）へ切り戻せるためダウンタイムを
最小限に抑えられ、デプロイ後の事後テスト
も本番環境と同等の環境で行えるのが利点。
一方で、一時的に環境が2つ必要になるため
サーバーリソースが増加し、環境管理が複雑化
する可能性があるデメリットがある。
21 オリジン間
リソース共有
(CORS)		 オリジン間リソース共有 (Cross-Origin
Resource Sharing, CORS) は、
HTTP ヘッダーベースの仕組みを使用して、
あるオリジンで動作しているウェブアプリケーション
に、異なるオリジンにある選択されたリソース
へのアクセス権を与えるようブラウザーに指示する
ための仕組み。		 リンク リンク
22 Apache
Kafka		 LinkedInで開発され現在はApache
Software Foundationが管理する
オープンソースの分散イベントストリーミング
プラットフォームで、リアルタイムで発生する膨大
な量のストリームデータを低遅延かつ高スループット
で処理し、信頼性の高いデータパイプラインや
イベント駆動型アプリケーションの構築に利用される。
・オンプレやec2でkafkaを利用している
ときの移行先として選択すればいいが、kinesis
data streamsのほうがサーバレスでもあり優れている。
・スケーラビリティに優れた分散メッセージキューを
扱える。
・後からクラスタにマシンを追加することで、
処理性能とデータ保持容量を
スケールアウトすることもできる。
・aws msk(Amazon Managed
Streaming for Apache Kafka)
ではバージョンアップはblue/green方式
を使える。フルバックアップ機能はないがクラスタ
のミラー機能で複製が可能。		 リンク リンク blackbelt
23 GraphQL REST API の課題を解決するために
Facebook が開発した API のクエリ
言語。GraphQL では、単一のエンドポイント
（URL）から、複数の種類のデータを一度に取得できるようになる。		 リンク
24 署名付きCookie
を用いてプライベート
コンテンツを
配信		 ・ 署名のための秘密鍵と公開鍵のキーペアを作成する
・ CloudFront側に公開鍵を設定する
・ アプリケーション側で秘密鍵を用いて署名した
Cookieを作成し、ブラウザにセットする
・ ブラウザは署名付きCookieがセットされた状態で
CloudFrontにアクセス
・CloudFront側で署名付きCookieを検証し、
問題がなければコンテンツへのアクセスを許可する
（署名付きCookieがない、不適切な場合はアクセスを拒否する）		 リンク
25 MQTT IoT（モノのインターネット）デバイス間など
の軽量な通信に使われる、パブリッシュ/
サブスクライブ型のメッセージングプロトコル。
・メッセージキューの機能は持たない。
・メッセージ通信電文が軽量に設計されている。		 リンク
26 Data Guard
レプリケーション		 プライマリ データベースとスタンバイ データベース
のレプリケーション構成におけるエンタープライズ
データ的高可用性、データ保護、および災害復旧
を保証する。
・初期ロード後のVPNレプリケーション（Data
GuardまたはDMS）は、変更分のみ同期
でき、最小限のダウンタイムでの移行に適している。		 リンク リンク
27 フェデレーション
認証		 複数の異なるサービス間で認証情報を
連携させる仕組み。		 リンク
28 スキーマ
レプリケーション		 ActiveDirectoryでのレプリケーション。
AWSでは一般的に推奨されない。		 リンク
29 4つの災害対策
(DR)		 ・パイロットライト
ガス駆動ヒーターなどのデバイスで常に点灯し、
必要に応じて素早くデバイスを起動できる小さな炎
を指す。システムの重要データのみ保持する低
スペックのDBを起動しておいてデータ同期する。
復旧時はスケールアップ。
・バックアップ＆リストア
必要なときにバックアップからリストアする。
費用下がるが時間かかる。
・ウォームスタンバイ
DRリージョンで低スペック構成を常時起動。
切り替え時はスケールアップ。
・Active-Active(マルチサイト)
DRリージョンで完全構成を常時起動。
切り替え速いが費用上がる。		 リンク リンク
30 スティッキー
セッション		 ロードバランサ（負荷分散装置）の機能の一つで、
セッションが続いている間は同じクライアントを
同じサーバへ誘導する機能。		 リンク
31 ラウティング ルーティング。Routing。
32 OU ・LDAPやADでのDN/DC/OU
ツリーの中でDN (Distinguish Name)
を定義していく。
DC (Domain Component)
L OU (Organization Unit) ：
L OU (Organization Unit)
L CN (Common Name)
・AWS OrganizationsのOU
アカウントをまとめてグループ化するのに利用。		 リンク リンク
33 クラウド移行
戦略		 ▪️AWSへの移行戦略。
1.準備フェーズ (アセスフェーズ)：
現状を分析し、移行目標や方法を検討
2.移行フェーズ (モライフェーズ)：
移行計画を立て、AWS環境を構築
3.最適化フェーズ (マグレアモダナイズ
フェーズ)：移行後のシステムを検証し、最適化
▪️AWSが提唱する7つの移行パス(7R)。
1. リロケート (Relocate)：既存の
アーキテクチャーをそのままAWSに移行します。
移行が早く、クラウドの基本的なメリットを
得られます。
Amazon EVS(elastic vmware
service、旧VMware on AWS) など
を使ってインフラ単位で移行する方法のこと。
dockerコンテナをecs/eksへ移行するなど。
2. リホスト (Rehost - lift &
shift)：オンプレミスのサーバーをAWSの
EC2へ移行します。リロケートと同様に、
移行が早く、クラウドの基本的なメリットを
得られます。
3. リプラットフォーム (Replatform
)：アーキテクチャーを一部最適化して移行
します。OSやミドルウェアのバージョンアップ、
データベースサーバーをRDSに変更するなどが
該当します。移行には時間がかかりますが、
より多くのメリットを得られます。
4. リファクター (Refactor)：
アーキテクチャーをクラウドに最適化して
再設計します。モノリスなアプリケーションを
マイクロサービス化したり、データベースのエンジン
を変更したりすることが該当します。移行には
多くの時間とコストがかかりますが、クラウドの
メリットを最大限に引き出せます。
5. リパッケー ジ (Repackage
- reparchase)： 既存のシステム
をパッケージ製品に置き換えます。
6. リテイン (Retain)：AWSに移行
せず、既存環境で引き続き利用します。
7. リタイア (Retire)：システムを統合
したり、廃止したりします。		 リンク
34 単一障害点 単一障害点（SPOF：Single Point
of Failure）とは、その部分に障害が
発生すると、システム全体が停止してしまうような、
システムを構成する要素のこと。
・SPOFをなくすには、システムの構成要素
を冗長化（予備を複数用意）し、障害時に
自動的に代替する仕組みを導入することが一般的。		 リンク
35 rest api ウェブサービスがデータをやり取りするための
設計原則に従った、アプリケーション・
プログラミング・インターフェース（API）。		 リンク
36 redis メモリ上で動作する高速なインメモリ
データベース（NoSQLの一種）。データが
ディスクではなくメモリに保存されるため、
データの読み書きが非常に高速で、キャッシュや
リアルタイム性の高いアプリケーションに
適している。		 リンク
37 3層アーキテク
チャ		 大規模なWebアプリケーションなどで、
システムをプレゼンテーション層、アプリケー
ション層（ビジネスロジック層）、データ層
の3つに分割して設計する手法。		 リンク
38 gRPC gRPCはオープンソースのRPCフレーム
ワーク(後述)で、Googleによって開発
された。2015年にオープンソースとして公開
され、一般的にマイクロサービス間での通信や、
モバイルアプリとバックエンドサーバー間の
通信で用いられる。		 リンク
39 SNI 「Server Name Indication」の略で、
1つのサーバーで複数のドメインを運用する際に、
ドメインごとに適切なSSL/TLS証明書を使い分けるための技術。
・ブラウザが SNI をサポートしていない場合、
専用の IP 独自 SSL を使用する。
・サイトを遮断する目的でSNI技術が利用
されることがある。これは、暗号化通信の前
に接続先ドメイン名をサーバー側で把握できるため。		 リンク
40 gTLD gTLD（Generic Top Level
Domain：分野別トップレベルドメイン）は、
.comや.netのように、国や地域に関係
なく世界中から登録・利用できるドメインの
末尾（トップレベルドメイン）。
国別のものはccTLD(Country Code
Top Level Domain)と呼ばれる。
41 IP anycast 世界中にある複数のサーバーで「共通のIP
アドレス」を共有し、ユーザーからネットワーク
的に最も近いサーバーへ自動的に接続させる
ルーティング技術。高速な応答、負荷分散、
障害への対障害性、DDoS攻撃の軽減などが
実現され、主にDNSサーバーやCDNサービスで
活用されている。
42 DNSレコード
のリソース
レコード		 ・SOA
ゾーンの管理主体であること、権威であることを宣⾔
（Start Of Authority）。
———————————————————–
example.com. 3600 IN SOA ns.icann.org. noc.dns.icann.org.
2019101513 7200 3600 1209600 3600
———————————————————–
・NS
ゾーンを管理するネームサーバーの FQDN を指し⽰す。SOAとともに必須レコード。
———————————————————–
com. 518400 IN NS a.gtld-servers.net.
example.com. 518400 IN NS ns1.example.com.
———————————————————–
・A/AAAA
FQDN に対応する IP アドレスを応答する。
———————————————————–
www.example.com . 3600 IN A 192.0.2.3
www.example.com . 3600 IN AAAA 2001:0DB8::1
———————————————————–
・CNAME
名前解決を CNAME が指定する名前に置き換えて
継続することを要求する。
———————————————————–
info.example.com. 3600 IN CNAME www.example.com .
www.example.com . 3600 IN A 192.0.2.3
———————————————————–
43 DNSレコード
のリソース
レコード		 ・PTR
IP アドレスから FQDN を逆引きする。
———————————————————–
3.2.0.192.in-addr.arpa. 3600 IN PTR www.example.com .
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
———————————————————–
・MX
メールをメールサーバーに送信するためのもの。
———————————————————–
example.jp. 3600 IN MX 10 mx01.baremail.jp.
example.jp. 3600 IN MX 20 mx02.baremail.jp.
———————————————————–
・TXT
ドメイン情報に任意のテキスト文字列を関連付けて
DNS上に登録できるレコード。
・SRV
特定のサービスのためにサーバー内のポートを
指定する。
44 概念実証(PoC
:Proof
of Concept
)アーキテク
チャ		 新しい技術やアイデアの「実現可能性」を
検証するための小規模なシステム構成のこと。
本格的な開発に入る前に、技術的な課題の
特定やリスクの洗い出し、必要なリソースの
把握などを目的としている。
45 ワークロード
（workload
）		 「仕事量」「作業負荷」を意味し、IT
分野ではコンピュータやシステムが処理する
タスクの量や種類、またはその処理負荷の
大きさを指す。具体的には、CPU使用率
やメモリ使用率などのリソース利用状況、
または仮想マシン（VM）上で実行される
アプリケーション群、クラウド上で動くサービス
全体などを指すこともある。
46 スプリット
ブレイン		 複数のコンピュータを相互接続して1台の
サーバのように動作させるシステムにおいて、
ハードウェアやインターコネクトの障害により
システムが分断され、1つのサービスがクラスタ
内の複数のノード群で同時に起動してしまい、
サービス供給が停止してしまう状況のこと。
47 ACIDトラン
ザクション		 データベース操作において高い信頼性と整合性
を保証する4つの特性（原子性、一貫性、
独立性、永続性）の頭文字をとった概念です。
銀行の送金処理のように、複数の処理を
「すべて成功」か「すべて無し」の単位
で管理し、システム障害や同時アクセス時でも
データの不整合を防ぐ。
・Atomicity（原子性）：
トランザクション内の全操作が「完全に実行
される」か「一つも実行されない（ロール
バック）」のいずれかであること。
・Consistency（一貫性）：
トランザクションの前後で、データベースの
ルールや整合性制約が守られ、矛盾のない
状態が保たれること。
・Isolation（独立性/分離性）：
同時に実行される複数のトランザクションが互い
に影響を与えず、独立して動作すること。
・Durability（永続性/耐久性）：
完了したトランザクションの結果は、システム
障害が発生しても失われず、記録され続けること。
48 AWSサービス
のローカル
実行		 例えばローカルPCでdocker稼働環境を
作っておくと、docker composeも利用
してサービスをコンテナとして動かせる。
テストや練習に使える。
・例えばlocalstackではS3/SQS
/lambda/DynamoDB/SNSが使える。		 リンク リンク
49 データ民主化
（Data
Democrat
ization）		 企業・組織内の誰もが、専門家でなくても
必要なデータに即座にアクセス・分析し、日々の
業務改善や意思決定に活用できる環境を整える
取り組み。		 リンク
50 デジタルツイン デジタルツインは、現実世界の物理的な設備、
建物、都市などのデータをIoTセンサー等
で収集し、サイバー空間（仮想空間）にそっくり
な「双子（ツイン）」を再現する技術。リアル
タイムのデータ連動により、シミュレーション
や未来予測を行い、その結果を物理世界へ
フィードバックすることで、製造、都市計画、
医療などの分野で効率化や最適化を実現する。		 リンク
51 デバイスシャ
ドウ		 デバイスシャドウ（Device Shadow）
は、AWS IoT Coreでラズパイなどの
エッジ端末の最新状態（オン/オフ、温度
など）をJSONドキュメントとしてクラウド
上に保持・管理する機能。IoTデバイスが
オフライン時でもアプリケーションが状態を
把握・変更（desired）でき、再接続時に
自動で実際の状態（reported）と同期
させ、データの不整合や欠損を防止する。
・状態の保持: desired（アプリが望む
状態）とreported（デバイスが報告した
実際の状態）の2つの要素で管理。
・通信の非同期化: デバイスがインター
ネットに接続されていない間も、アプリは
シャドウを介して状態を確認・変更可能。
・用途: スマートライトの操作、IoT機器
の設定変更、オンライン/オフラインが切り替わる
環境での状態管理など。
・別名: 「デバイスツイン」や「MQTT
シャドウ」とも呼ばれる場合がある。		 リンク リンク