共感で繋がるSNS
📓
引きこもりでも勉強したい
小さな積み重ねから大きな成長へ
目標
AWS Certified Developer Associate 進行中
応用情報技術者
TOEIC 750点
勉強
海外
早寝早起き
📓
70
📓
AWS が提供するオブジェクトストレージサービス。
ストレージは バケット と呼ばれ、各ファイルは オブジェクト として保存され、作成時に一意の ID が付与される。
高い拡張性：容量は実質無制限
高い可用性：複数 AZ に自動的に複製され、AZ 障害時もデータは維持される
高い安全性：IAM ポリシー と バケットポリシー によるアクセス制御が可能
高いパフォーマンス：プレフィックス単位でスループットを拡張
例）
bucket/1/file → プレフィックス /1/
bucket/2/file → /2/
bucket/3/4/file → /3/4/
ストレージクラス
Standard：頻繁に利用されるデータ向け（性能・コスト最高）
Standard-IA：使用頻度は低いが、必要時は即時アクセス
One Zone-IA：単一 AZ 保存、紛失しても問題ないデータ向け
Glacier Instant Retrieval：アーカイブ用途・高速取得
Glacier Flexible Retrieval：アーカイブ用途・取得速度は問わない
Glacier Deep Archive：最安、取得は最も遅い
アクセス制御
IAM ポリシー：ユーザー／ロール／グループ単位のアクセス制御
バケットポリシー：バケット単位でのアクセス制御
バージョン管理・複製・ライフサイクル
Versioning：オブジェクトのバージョン管理。削除時には Delete Marker が付与される。
Replication：バケット A → バケット B の非同期コピー。連鎖コピーは不可（A→B しても B→C はされない）。
Lifecycle
Transition：ストレージクラスの自動変更
Expiration：オブジェクトの自動削除
Notification Event：アップロードや更新をトリガーに他サービスへ通知可能（例：Lambda）
データ転送 / 取得
Multi-Part Upload：5GB 以上のオブジェクトアップロードに必須（分割並列アップロード）
Byte-Range Fetch：オブジェクトを部分的にダウンロード（マルチスレッドに類似）
Transfer Acceleration：エッジネットワークを利用してアップロードを高速化
メタデータ / タグ
User-Defined Object Metadata：x-amz-meta-xxx 形式でアプリケーションレベルの情報を付与
S3 Object Tag：分類とポリシー制御（検索やソートは S3 単体では不可 → DB と連携）
セキュリティ（暗号化）
SSE-S3：AWS が鍵を管理。AES-256 によるサーバーサイド暗号化。
ヘッダ：x-amz-server-side-encryption: AES256
SSE-KMS：鍵は KMS で管理。CloudTrail に鍵使用履歴が記録。
ヘッダ：x-amz-server-side-encryption: aws:kms
暗号化・復号のたびに KMS API を使用するため、使用回数制限がある。
SSE-C：ユーザーが鍵を提供。鍵は AWS に保存されない。
Client-Side Encryption：クライアント側で暗号化してからアップロード。
CORS
ブラウザが外部ドメイン間リソースへのアクセスをブロックするため、
別オリジンからのアクセスを許可する場合は CORS 設定が必要。
45📓
Public Subnet は Internet Gateway と接続することで、インターネットとの双方向通信ができます。つまり、パブリックサブネット内のリソースは外部へアクセスでき、外部からもアクセスできます。一方、Private Subnet はインターネットへの直接接続ができません。インターネットへ出る必要がある場合は NAT Gateway を経由します。また、外部から Private Subnet のリソースに直接アクセスされることはありません。両者の本質的な違いは、接続しているゲートウェイが異なることです。
一般的な企業構成では、アプリケーションサーバやデータベースは Private Subnet に配置します。そして、Private Subnet のリソースがインターネットに接続できるように、Public Subnet に NAT Gateway を設置します。さらに Public Subnet は Internet Gateway に接続されます。
ネットワークのアクセス制御には NACL と Security Group を使用します。NACL はサブネット単位に適用されるファイアウォールで、ルールは許可と拒否が設定できます。ただしステートレスのため、受信と送信の両方を明示的に設定する必要があります。Security Group はインスタンス単位のファイアウォールで、許可ルールのみ設定します。ステートフルであり、受信を許可すれば送信は自動的に許可されます。
VPC Peering は複数の VPC をプライベートネットワークで直接接続する仕組みです。ただし転送はできず、A–B、B–C を接続しても A は B を経由して C にアクセスできません。VPC Endpoint を使うと、VPC 内のリソースがインターネットを介さずに AWS のサービスへアクセスできます。つまり NAT やパブリックサブネットを使用せずに通信できます。
オンプレミスと AWS を接続する場合は二つの方法があります。Site-to-Site VPN はインターネット上に暗号化された仮想回線を作る方式で、コストが低く構築が簡単ですが、安定性はそこまで高くありません。Direct Connect は専用の物理回線で接続する方式で、コストは高いですが、安定性が高く、帯域幅が大きく、遅延も少なくなります。
23📓
ユーザーが www.example.com にアクセス
↓
ローカルキャッシュ参照
↓（なければ）
ルート DNS サーバへ問い合わせ
↓
ルート DNS：example.com の NS は Route53 と返す
↓
クライアント → Route53 の NS に問い合わせ
↓
Route53 が Hosted Zone の A / AAAA / CNAME を参照し IP を返す
↓
クライアントはサーバーに接続し、IPをローカルにキャッシュ
8📓
DNS（Domain Name System）ドメイン名をIPアドレスに変換する仕組み
Aレコード：ドメイン名 → IPv4
AAAAレコード：ドメイン名 → IPv6
CNAMEレコード：ドメイン名 → 別のドメイン名へ紐付け
※ ルートドメインには使用不可、サブドメインのみ可（例：www.example.com）
※ 参照時は2回名前解決が発生する
NSレコード：そのドメインの名前解決に使用するDNSサーバーを示す
Hosted Zone
Public Hosted Zone：インターネットからアクセス可能
Private Hosted Zone：同じVPC内からのみアクセス可能
TTL：ローカルキャッシュが保持される時間
Alias レコード：CNAME と似ているがルートドメインに使用可能、ただしAWSリソースに対してのみ使用可。AWS内で解決されるためCNAMEより高速
Routing Policies（ルーティングポリシー）
Simple 複数IPの中からランダムで1つを返す
Weighted 割合（重み）に応じてトラフィックを分散
Latency-based 遅延が最も小さいリージョンへ誘導
Failover マスター障害時にサブへ切り替え（ヘルスチェック必須）
Geolocation クライアントの地理位置に基づいて接続先を決定
GeoProximity オフセット係数で地域ごとのトラフィック量を調整（有料機能）
IP-based 特定のCIDRに基づいてルート指定
Multi-Value 複数IPを返し、クライアント側でランダム選択
Health Check
サービスやリソースの有効/無効を判断する仕組み
Route53は複数（最大15）のヘルスチェッカーでチェックし、少なくとも18%以上成功した場合に正常と判定 → ネットワークの揺れによる誤判定を防ぐ仕組み
Private リソースには直接使用できないが、CloudWatch 経由で間接監視が可能
10📓
Aurora 暗号化
DBデータの暗号化はDB作成時にのみ設定可能
既存のDBを後から暗号化に変更することはできない
リードレプリカの暗号化状態はマスターに従う
マスターが暗号化なし → レプリカも暗号化できない
暗号化されていないDBを暗号化したい場合は、スナップショットから復元（Restore）して、復元時に暗号化設定を有効化する
RDS Proxy
役割：
コネクションプール ＋ 接続再利用 ＋ IAM / Secrets Managerによる認証統一 ＋ 自動フェイルオーバー
RDSへ直接接続せず、Proxy を経由することで：
接続切断のリスク軽減、高負荷トラフィック時の効率向上、可用性向上
ElastiCache
よく使うデータをキャッシュに保存し、DBへのクエリ回数を減らして負荷を軽減する。
Redis/Valkey：永続化可能/Pub-Sub対応/パッチ・障害対策サポートあり
Memcached：分散キャッシュ/サーバーレス/永続化なし/レプリケーションなし（データ喪失の可能性あり）
キャッシュ戦略
1. Lazy Loading
まずキャッシュを参照し、データがない場合のみDBに問い合わせる方式
DBから取得したデータはキャッシュに保存し、次回はキャッシュから取得
メリット：検索が速い、必要なデータだけキャッシュに入る
デメリット：初回は必ずDBにアクセス、キャッシュ同時失効時に「キャッシュアバランチ」の可能性
2. Write Through
DB更新時に同時にキャッシュも更新する方式
メリット：キャッシュと DB の整合性が強い
デメリット：使わないデータもキャッシュされるため容量負担が増える、書き込みが重くなる
キャッシュ削除ポリシー（Eviction Policies）
TTL 設定した時間が過ぎたら削除
LRU 最近最も使われていないデータを削除
LFU 使用頻度が最も低いデータを削除
Random ランダムに削除
29📓
RDSはAWSが提供するマネージド型のリレーショナルデータベースサービスで、従來のようにEC2 インスタンスにデータベースをインストールする必要がありません。
PostgreSQL、MySQL、Oracle、MariaDB、Aurora など一般的なデータベースをサポートしています。
RDSには、モニタリング、自動バックアップ、使用狀況に応じたストレージの自動拡張、障害対策、データ復元などの運用機能が標準で備わっています。
特にマルチAZ配置を有効にすると、本番環境用と待機用のデータベースが別のアベイラビリティゾーンに配置され、マスター側に障害が発生した場合、自動的に待機側へ切り替わるため、可用性が向上します。
また、Read Replicaを利用すると、マスターから読み取り専用のデータベースへデータを自動的に複製できます。
これにより、読み取り負荷を複数のインスタンスへ分散でき、パフォーマンスが向上します。
データの流れは以下の通りです：
書き込みはマスターに行い → マスターからレプリカへ同期 → 読み取りはレプリカから行う。
6📓
難しいところは特にありませんが、いくつかのスケーリングポリシーがあることを理解しました。
Target Tracking Scaling
あらかじめ目標の指標値（例：CPU 使用率 50%）を設定し、
ASG がその値に近づくように自動的にインスタンス数を増減します。
設定が簡単で、もっともよく使われる方式です。
例：
CPU 使用率が 50% を超える → インスタンスを追加
CPU 使用率が下がる → インスタンスを削除
Step Scaling
指標の増加・減少量に応じて段階的にインスタンス数を調整します。
例：
CPU 50% 超 → +2 台
CPU 70% 超 → +3 台
段階的にスケールさせたいときに使います。
Simple Scaling
しきい値を超えたら設定された数だけスケールし、その後は Cooldown（待機時間） に入ります。
Cooldown 中に再スケールができないので、反応が遅くなりやすく、現在ではほとんど使われません。
Schedule Scaling
時間指定でインスタンス数を増減する方式です。
トラフィックの増加が時間帯で予測できる場合に便利です。
例：
毎日 9:00 に +2 台、18:00 に -2 台
Predictive Scaling
過去の使用データを機械学習で分析し、将来の負荷を予測して自動的にスケールさせる方式です。
予測可能なトラフィック変動があるシステムに向いています。
6📓
Gateway Load Balancer（GWLB）
OSI 参照モデルの 第3層（ネットワーク層） に位置するロードバランサで、すべてのリクエストを検査・検証することができます。独自のルールを設定することで、リクエストの正当性を確認できます。
Sticky Session（スティッキーセッション）
ロードバランサを経由する際、同じユーザーのリクエストを常に特定のインスタンスへ転送する仕組みです。この機能は Cookie を利用して実現されています。ユーザーごとにセッションが維持されるため、ログイン状態を保持するようなアプリケーションに便利です。
Cross-Zone Load Balancing（クロスゾーンロードバランシング）
複数のアベイラビリティゾーンにまたがっている場合でも、リクエストを各ゾーンのインスタンスに均等に分散できます。この機能は ALB ではデフォルトで有効かつ無料、NLB と GWLB ではデフォルトで無効かつ有料 となっています。
SSL Certificates（SSL 証明書）
HTTPS 通信を利用するためには、ロードバランサに SSL 証明書 を設定する必要があります。これにより、クライアントとロードバランサ間の通信が暗号化され、セキュリティが向上します。
Deregistration Delay（登録解除ディレイ）
インスタンスを シャットダウン（終了）する際、設定した時間だけ待機して、処理中のリクエストをすべて完了させてから削除する機能です。サービス停止時のリクエスト損失を防ぎます。
Auto Scaling Group（ASG）
特定の条件（CPU 使用率など）をトリガーとして、インスタンスを自動的に増減させる仕組みです。ロードバランサと連携させることで、高可用性とコスト効率の両立が可能になります。
8📓
この機能の目的は、具体的なサーバーを隠し、単一の入り口（エンドポイント）を提供することです。
すべてのリクエストはこの入り口を通じて、適切なサーバーへ転送されます。
これにより、安全性と可用性の両方が向上します。
AWS のロードバランサには、主に4種類あります。
① Classic Load Balancer（CLB）
古いタイプのロードバランサで、もう廃棄しています
② Application Load Balancer（ALB）
OSI 第7層（アプリケーション層）で動作します。
HTTP / HTTPS のリクエストを受け取り、特定のサーバーやパスに転送（フォワード）できます。
例：
同じセキュリティグループ内に2台の EC2 インスタンスを用意し、
ALB を作成する際にこの2台のインスタンスをターゲットとして登録します。
ロードバランサ自体にも専用のセキュリティグループを設定して、
トラフィックを安全にコントロールします。
③ Network Load Balancer（NLB）
OSI 第4層（トランスポート層）で動作します。
非常に高いパフォーマンスを持ち、TCP・UDP トラフィックを処理できます。
また、各アベイラビリティゾーンに固定（静的）IPアドレスを持ちます。
④ Gateway Load Balancer（GLB）
まだ勉強中です
8📓
EFSとは複数のアビリティゾーン(AZ)からアクセス可能なネットワークファイルシステム
EBS ボリュームと違い、インスタンスのアベイラビリティーゾーンが異なっていても、EFS を通して同じストレージ上にファイルを保存できます。
つまり、ゾーン A のインスタンス A で保存したデータを、ゾーン B のインスタンス B からも EFS を介してアクセスすることができます。
使いやすい一方で、コストは EBS よりも高めです。
昨日の内容の補足として、EBS にはいくつかのボリュームタイプがあります。
• 汎用型（gp2 / gp3）：最大 IOPS は 3,000。パフォーマンスとコストのバランスが良い。
• パフォーマンス特化型（io1 / io2）：高い IOPS を必要とするシステム向けで、性能を最大化できる。
• HDD 型（st1 / sc1）：大容量だが、読み書き速度は遅め。
• インスタンスストア（Instance Store）：高速だが一時的なストレージ。インスタンスに障害が発生するとデータが失われる可能性がある。
8📓
Volume は自由にインスタンスにアタッチできるが、作成時に選択したアベイラビリティーゾーンでしかアクセスできない。
そのため、スナップショット（snapshot）機能を使えば、ボリューム内のすべてのデータをバックアップできる。
スナップショットをベースに新しいボリュームを作成することも可能で、
その際には再度ゾーンを選択することができる。
また、個人の Recycle Rule（リサイクルルール） を設定しておくと、
スナップショットを削除したときにまず Recycle Bin（リサイクルビン） に移動し、
ルールで指定した期間が経過すると自動的に削除される。
これにより、誤ってスナップショットを削除してしまうことを防ぐことができる。
19📓
On-Demand: No discount; pay only for what you use. Suitable for temporary or unpredictable workloads.
Reserved Instances: Up to 72% discount, but requires a 1- or 3-year commitment. Best for steady workloads.
Savings Plans: Up to 66% discount; you pay a fixed amount per hour, offering flexibility across instance types and regions.
Spot Instances: The cheapest option, but unstable — instances can be terminated at any time when capacity is needed.
Dedicated Hosts: Provides an entire physical server for your exclusive use.
Capacity Reservations: Guarantees reserved capacity in a specific Availability Zone, ensuring resources are available when needed.
7📓
4