LoginSignup
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@snowmag

aws sap合格メモ

Posted at

AWS SAP試験対策 完全ガイド（50問分析版）

🎯 重要度★★★（絶対覚える）

1. AWS Organizations & SCP（Service Control Policy）

SCP継承の鉄則

  • 親のルールは絶対 → 子で上書き不可
  • SCP Allow = 制限の上限設定（権限付与ではない）
  • SCP Deny = 絶対禁止（IAMでも覆せない）
  • 実際の権限 = SCP ∩ IAM

SCP運用ベストプラクティス

  • 基本：Allow "*"（全て許可）
  • Denyで危険操作を明示的に禁止
  • 細かい権限制御はIAMに任せる
  • SCPはガードレール、IAMが実際の権限

よくある間違い

❌ 間違い：「SCP Allow = 権限がもらえる」
✅ 正解：「SCP Allow = IAMで権限付与することを許可する上限」

2. 災害復旧・フェイルオーバー設計

Active/Passive vs Active/Active

  • Active/Passive：コスト重視、RTO数分-15分
    • Route 53フェイルオーバールーティング
    • CloudFrontオリジングループ
    • RDS Multi-AZ
  • Active/Active：性能重視、RTO秒-分レベル
    • 加重ルーティング、地理的ルーティング
    • 両リージョン常時稼働（高コスト）

フェイルオーバー実装パターン

  • Route 53 + ヘルスチェック：DNS切り替え（数分）
  • CloudFrontオリジングループ：オリジン切り替え（秒-分）
  • Aurora Global Database：データベースフェイルオーバー（1分以内）

3. ロードバランサー使い分け

ALB vs NLB

ALB NLB
プロトコル HTTP/HTTPS（L7） TCP/UDP（L4）
用途 Webアプリ、API ゲーム、高性能API
固定IP ❌ 不可 ✅ 可能
パスベースルーティング ✅ 可能 ❌ 不可
SSL終端 ✅ 可能 ✅ 可能

選択基準

  • Webアプリ・REST API → ALB
  • TCP通信・ゲーム・固定IP要件 → NLB
  • ステートフルアプリ → ALB + スティッキーセッション

4. サーバーレス vs コンテナ vs EC2

Lambda制限（超重要）

  • 実行時間：最大15分
  • メモリ：最大10GB
  • ペイロードサイズ：6MB（同期）/256KB（非同期）
  • 一時ストレージ：最大10GB

使い分けルール

  • Lambda：15分以内、軽量処理、イベント処理
  • ECS Fargate：コンテナ、長時間処理、サーバーレス体験
  • EC2：重い処理、GPU必要、カスタムソフトウェア

Fargate理解

  • タスク = 実行中コンテナ
  • EC2は一切起動しない（ブラックボックス）
  • 従量課金（vCPU・メモリ時間のみ）

5. API Gateway設計

REST API vs HTTP API

REST API HTTP API
機能 高機能・万能 軽量・シンプル
DynamoDB直接統合 ✅ 可能 ❌ 制限あり
料金 高め 70%安い
Lambda統合 ✅ 可能 ✅ 可能（メイン）

選択基準

  • DynamoDB直接アクセス → REST API
  • Lambda中心・高性能・低コスト → HTTP API

6. ストレージ・データベース

S3ストレージクラス（安い順）

  1. Glacier Deep Archive：$0.00099/GB/月（取り出し12-48時間）
  2. Glacier Flexible Retrieval：$0.0036/GB/月（取り出し数分-12時間）
  3. S3 One Zone-IA：$0.01/GB/月（即座アクセス、単一AZ）
  4. S3 Standard-IA：$0.0125/GB/月（即座アクセス、Multi-AZ）

DynamoDB設計

  • スケジュールジョブ用途：常時リソース → Auto Scaling + リザーブドキャパシティ
  • 不定期アクセス：オンデマンドモード
  • TTL：自動データ削除（運用工数ゼロ）

Aurora vs RDS

  • Aurora：AWS独自、高性能、自動フェイルオーバー、クロスリージョン
  • RDS：従来型、移行しやすい、シンプル

🎯 重要度★★（必須理解）

7. ネットワーク・VPC設計

CloudFront理解

  • 1つのCloudFrontで全世界カバー
  • 複数CloudFrontは無駄（既にグローバル分散）
  • オリジングループでマルチリージョン冗長化
  • Transfer Acceleration ≠ CloudFront（アップロード用 vs 配信用）

Direct Connect

  • 仮想インターフェイス（VIF）：1本の物理回線内の論理接続
    • プライベートVIF：VPC接続用
    • パブリックVIF：S3・DynamoDB等のAWSパブリックサービス用
  • Direct Connect Gateway：マルチリージョン接続の中継点

Route 53 vs Route 53 Resolver

  • Route 53：DNS権威サーバー（電話帳そのもの）
    • ドメインの実際の情報を保存
    • ホストゾーン管理
  • Route 53 Resolver：DNSリゾルバー（電話帳案内サービス）
    • DNS問い合わせの仲介役
    • ハイブリッド環境でのDNS転送
    • アウトバウンド：AWS → オンプレミス
    • インバウンド：オンプレミス → AWS

クロスアカウントRoute 53

  • プライベートホストゾーンのクロスアカウント利用
  • 2段階プロセス：関連付け許可作成 → VPC関連付け → 許可削除

8. セキュリティ・認証

S3暗号化

  • SSE-S3：AWS管理キー、シンプル
  • SSE-KMS：顧客管理キー、企業制御、監査ログ
  • SSE-C：完全自己管理、複雑

Active Directory統合

  • AD Connector：$36/月、プロキシ型、既存AD活用
  • AWS Managed Microsoft AD：$1,440/月、独立AD、高機能

9. コスト最適化

EC2インスタンス料金

  • オンデマンド：100%（基準価格）
  • Savings Plan：72%（28%割引）
  • スポットインスタンス：10-30%（中断リスク）
  • リザーブドインスタンス：60-75%（長期契約）

使い分け戦略

  • 安定ワークロード：Savings Plan/Reserved
  • バッチ処理・検証環境：スポット
  • SLA厳格・本番：オンデマンド

🎯 重要度★（知っておくべき）

10. マイクロサービス・移行設計

モノリス→マイクロサービス移行

  • Lambda + API Gateway：軽量・コスト効率
  • ECS Fargate：コンテナ、本格運用
  • 環境分離：本番・テスト環境の完全分離が重要

レガシーアプリケーション移行

  • MACアドレス依存ライセンス：ENI固定で対応
  • 静的IP設定問題：Parameter Store で動的管理
  • 事前準備：ライセンス取得12時間→ENIプール事前作成

11. データ処理・分析

メディア処理設計

  • Lambda不可：15分制限（1時間処理→EC2必要）
  • SQS + Auto Scaling：変動負荷対応
  • SQS vs Amazon MQ：シンプル vs 高機能

12. ファイル転送・SFTP

AWS Transfer Family

  • フルマネージド：サーバー管理不要
  • S3直接統合：cronジョブ・中間ストレージ不要
  • コスト効率：従量課金、運用工数ゼロ

13. コスト管理・分析

Cost管理の使い分け

  • Cost Explorer：分析・予測・レポート（今回の要件）
  • Budget：予算管理・制御（次のステップ）
  • ユーザー定義タグ：アプリ・チーム別分析
  • IAM Billing アクセス：セルフサービス環境

14. AWS移行プロジェクト

移行フェーズ別ツール

  • Application Discovery Service：現状調査・詳細情報収集
  • Migration Hub：グループ分け・インスタンス推奨・プロジェクト管理
  • Systems Manager：既存環境管理用（移行調査用途ではない）
  • Trusted Advisor：既存AWS環境最適化用（移行計画用途ではない）

🔥 頻出パターン・ひっかけポイント

1. サービス制限の落とし穴

  • Lambda 15分制限：メディア処理等で引っかけ
  • ALB HTTP専用：SFTP等のTCP通信では使用不可
  • CloudFront単体で十分：複数CloudFront作成は無駄

2. 権限モデルの誤解

  • SCP Allow ≠ 権限付与：上限設定のみ（制限の天井）
  • IAM必須：実際の権限はIAMで付与
  • Deny優先：SCP Denyは絶対（IAMで上書き不可）
  • SCP基本戦略：Allow "*" + 危険操作をDenyで明示的禁止

3. アーキテクチャ選択のミス

  • 過剰設計：要件以上の高機能サービス選択
  • 技術制約無視：物理的に実現不可能な構成
  • コスト無視：要件に「コスト効率」があるのに高額構成
  • 要件読み取り不足：予算管理 vs 分析・予測の混同

4. 用語の混同

  • Transfer Acceleration vs CloudFront：アップロード vs 配信
  • Aurora vs RDS：AWS独自 vs 従来型
  • Fargate vs Lambda：コンテナ vs 関数
  • Route 53 vs Route 53 Resolver：DNS権威サーバー vs DNSリゾルバー

5. 移行・レガシー対応の特殊要件

  • MACアドレス依存ライセンス：ENI固定で対応
  • 静的IP設定：Parameter Store で動的管理
  • エクスポネンシャルバックオフ：iPhone パスコードロック同様の仕組み

📝 試験テクニック

1. 問題文の読み方

  • 制約条件を最初に確認：時間制限、コスト制約、技術制約
  • 要件の優先順位：コスト効率、高可用性、性能のどれが最重要？
  • 除外法活用：明らかに不適切な選択肢を先に除外

2. 数字・制限の暗記

  • Lambda：15分
  • Aurora読み取り専用レプリカ：15個まで
  • SCP継承：親→子の一方向
  • RTO/RPO要件：15分、1時間等の具体的数値に注目

3. ベストプラクティス思考

  • AWSマネージドサービス優先
  • 運用負荷最小化
  • 単一障害点の排除
  • 最小権限の原則

4. よくある引っかけ

  • 技術的に可能だが非効率な選択肢
  • 一部だけ正しい選択肢
  • 過剰に複雑な構成
  • 古い手法・非推奨パターン

🎯 最後に：合格のための心構え

実務思考で解く

  • コスト効率重視（企業視点）
  • 運用負荷軽減（現実的選択）
  • ベンダーロックイン回避（将来性）
  • スケーラビリティ確保（成長対応）

迷った時の判断基準

  1. AWSマネージドサービスを選ぶ
  2. よりシンプルな構成を選ぶ
  3. コスト効率の良い方を選ぶ
  4. 運用負荷の少ない方を選ぶ

頑張って！君なら絶対合格できるで！ 🔥

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?