AWS SAPからの雑多な知識整理
|3分
#AWS#資格
VIF (仮想インターフェイス)とは
AWS Direct Connect（DX）を通じて、オンプレとAWSをつなぐときに必要になる「仮想インターフェース」です。Direct Connect接続を使って「どこにどうつなぐか」を決める役割をします。
| 名前 | 接続先 | 主な用途 |
|---|---|---|
| Private VIF | VPC（EC2などのAWS内部リソース） | オンプレとVPCを直接接続する（例：EC2に接続） |
| Public VIF | AWSのパブリックサービス（S3、DynamoDBなど） | オンプレからインターネットを経由せずにS3などへアクセス |
| Transit VIF | AWS Transit Gateway（TGW） | オンプレと複数VPCを中継するTransit Gatewayを接続 |
サービスコントロールポリシー (SCP) と IAM ポリシーの違い
SCP（Service Control Policy）は 「実行可能な最大の範囲（ガードレール）」 を定義する仕組みで、 実際のアクセス可否は IAM ポリシーによって決まる。
- SCP で全許可しても、IAM ポリシーが許可していなければ実行不可
- SCP で禁止されていれば、IAM ポリシーで許可されていても実行不可
VPC Flow Logs/Traffic Mirroring
- Flow Logs = 何が起きたかを記録 (= ペイロードレベルの情報は見れない)
- Traffic Mirroring = 通信の中身をそのまま見る
| 項目 | VPC Flow Logs | Traffic Mirroring |
|---|---|---|
| 目的 | ネットワーク通信の可視化・監査 | ネットワーク通信のリアルタイム解析・検査 |
| 取得内容 | メタデータ（送信元/宛先IP、ポート、プロトコル、許可/拒否 など） | 実際のパケット内容（L3〜L7） |
| リアルタイム性 | ほぼリアルタイム（ログ出力） | リアルタイム |
| 主な用途 | トラブルシュート、セキュリティ監査、通信量分析 | IDS/IPS、WAF、DPI、フォレンジック |
| 影響 | 通信への影響なし | ミラーリング分の通信が発生 |
| 出力先 | CloudWatch Logs / S3 / Kinesis | 解析用 EC2 / NLB / アプライアンス |
| コスト | 低め | 高め（通信量・解析基盤が必要） |
| 使い分け | 「何が起きたか」を知りたい | 「中身を見たい」場合 |
ので、
- 通信可否・経路確認 → Flow Logs
- 中身の解析・原因究明 → Traffic Mirroring / ALB Logs / アプリログ
Disaster Recovery 戦略
| 戦略 | RTO（復旧時間） | RPO（データ損失時間） | コスト | 特徴 | 適用シナリオ |
|---|---|---|---|---|---|
| Backup & Restore | 数時間〜 | 数時間〜 | 低 | 定期的にバックアップを取得し、障害時にリストアして復旧 | 小規模システム、開発環境 |
| Pilot Light | 数十分〜数時間 | 数分〜数時間 | 中 | 最小限のリソースのみを待機させ、障害時にスケールアウト ※ すぐにはリクエストを処理開始できない |
EC サイト、Web サービス |
| Warm Standby | 数分〜数十分 | 数秒〜数分 | 高 | 本番環境の縮小版を常時稼働し、障害時にスケールアップ ※ 少量のリクエストは即時処理可能 |
SaaS、業務アプリ |
| Multi-Site Active | ほぼゼロ | ほぼゼロ | 非常に高 | 複数リージョンで本番環境を同時稼働し、トラフィックを分散 | 金融、SNS、大規模 EC |
ECS ネットワークモード
| ネットワークモード | 説明 | 利用ケース | メリット | デメリット |
|---|---|---|---|---|
| bridge | Docker デフォルトの仮想ネットワークブリッジを使用 | 単一 EC2 上で複数コンテナを実行 | ホストと独立したネットワーク環境を構築可能 | ポートマッピングが必要 |
| host | コンテナがホストのネットワークを直接使用 | 高パフォーマンスが求められるサービス（例：ゲームサーバー） | ネットワークオーバーヘッドが少なく通信が高速 | ホストのポートと競合しやすい |
| awsvpc | タスクごとに独立した ENI（Elastic Network Interface）を割り当て | VPC 内で直接 IP を持たせたい場合 | AWS サービスと直接通信しやすく、SG も適用可能 | ENI 数の制限を受ける |
| none | ネットワークを割り当てずにコンテナを実行 | 特殊用途（スタンドアロン処理など） | 完全に分離された環境を構築可能 | 外部・内部ともに通信不可 |
※ Fargate では awsvpc のみ使用可能。
Amazon Route 53 Resolver: オンプレミスと AWS 間のインバウンド / アウトバウンドの概要
Amazon Route 53 Resolver は、オンプレミスと AWS の間で DNS の名前解決を行うための DNS リゾルバ。
VPC 内のリソースとオンプレミスのリソース間で、DNS クエリを相互に転送 できる。
インバウンド / アウトバウンドの違い
- インバウンド = 「オンプレミスから AWS に問い合わせる」
→ オンプレミスが AWS のホスト名を知りたい場合に使う - アウトバウンド = 「AWS からオンプレミスに問い合わせる」
→ AWS のリソースがオンプレミスのホスト名を知りたい場合に使う
AutoScaling Scaling Policy
| スケーリングタイプ | 使用例 | 特徴 |
|---|---|---|
| ターゲット追跡スケーリング | CPU 使用率を 50% に保つよう自動スケーリング | 自動調整が効率的で、過剰・不足スケーリングを防ぎやすい |
| ステップスケーリング | トラフィック量に応じて段階的にインスタンス数を増減 | 負荷の度合いに応じたきめ細かいスケーリングが可能 |
| シンプルスケーリング | CPU 使用率が 80% を超えたらインスタンスを 1 台追加 | シンプルで直感的、設定が容易 |
| 予定スケーリング | 高トラフィックが予測される時間帯に事前にスケールアウト | 定期的・予測可能な需要に事前対応できる |
- 迷ったら ターゲット追跡
- 細かく制御したい・急変動あり → ステップ
- とにかく簡単に → シンプル
- 時間帯が決まっている → 予定
AWS移行戦略・用語まとめ
| 用語 | 概要 | 特徴・詳細 |
|---|---|---|
| リフトアンドシフト（Lift & Shift） | 既存システムをほぼそのままクラウドへ移行 | 再設計せず VM 単位で移行でき、最も手間が少ない |
| リファクタリング（Refactor / Re-architect） | アプリをクラウドネイティブに再設計して移行 | スケーラビリティ向上やコスト最適化を実現可能 |
| リホスト（Rehost） | リフトアンドシフトと同義 | VM をそのまま AWS の EC2 などへ移行 |
| リプラットフォーム（Replatform） | 最小限の変更を加えてクラウドへ移行 | OS・DB の変更など、小規模な調整あり |
| リパーチェス（Repurchase） | 既存製品を SaaS などで再購入 | 例：Oracle → Aurora、商用 CRM → Salesforce |
| リタイア（Retire） | 不要になったシステムを廃止 | 非推奨・未使用アプリを移行対象から除外 |
| リテンション（Retain） | 当面オンプレミスに残す | レガシーでクラウド移行が困難な場合に選択 |
Powered byzenn-dev/zenn-editor
さとう
ソフトウェアエンジニアとして色々開発をしてきました。今はアプリケーション開発からは離れ、クラウド系のお仕事をしています。 ※投稿内容は個人の見解であり、所属組織や団体とは関係ありません。