はじめに
知識整理のための個人的なメモです。
VPCとの接続
Direct Connect
- 閉域網での接続が要件として必須である場合に利用する。閉域網でなくても十分なセキュリティ強度が実現可能であるが、「それでもインターネットで重要な社内データを送受したくない」というニーズに応える。
- 帯域保証なので大量のデータの通信に向いている。(1GBps、10Gbps)
- 専用線ならではの高品質(高スループット・低遅延の接続性を安定的に確保)が期待できる。
- プロバイダ選択の幅が狭い。(APNパートナーのみ)
IPSec VPN
- セキュリティ強度はDirect Connectと同等コスト重視
- ただしベストエフォート
- 可用性(冗長構成)、レジエンシー(障害復旧力)
HTTPS/SSH
- 通信要件なしの場合に適用
- アプリケーションレベルでセキュリティを担保
VPCで独自DNSサーバを使用する
- DNSサーバの値を独自DNSサーバとした新しいDHCPオプションセットを作成し、VPCデフォルトのDHCPオプションセットを新しく作成したDHCPオプションセットに置き換える。
VPC → インターネット通信の帯域増束
- NATインスタンスのスケールアップ
-
CDP:High Availability NATパターンの「ELBを使った冗長化」を適用する。NATではなく、内部ELB + Autoscaling対応したProxyサーバの構成を採ることで帯域増束する。
サブネット構成
- パブリックアプリケーションとプライベートアプリケーションは別サブネットに配置する。(技術的には同一サブネットに配置することもできるが、現実的にも認定試験的にしないのがアーキテクチャとセキュリティルール)
Cloud Watchのカスタムメトリクスが必要な監視対象
- 課金とは関係がないもの(メモリ使用率やディスク使用率)
- ディスクはIOPSで課金するのでディスク使用アクティビティは標準メトリクス
アプリサーバのセキュリティ
- 開発者にはアプリサーバインスタンスにアクセスさせない。
- ログサーバやロガーサービスからS3へログをアーカイブする。
- 開発者にログが格納されたS3バケットへのアクセス権を付与
RDBMSのパフォーマンス向上
- リードレプリカを作成し、読み取りリクエストの半分をリードレプリカへリダイレクトする。
- DBMSのクエリ実行結果をElastiCacheにキャッシュする。
- シャーディングし、シャード間で負荷分散する。
- MySQLやMongoDBが対応している。
- 複数のノードに渡って異なるデータを保存することで、読み取りや書き込みのパフォーマンスを水平方向のスケーリングできる。
DynamoDBのコスト
- 最大4KBの項目に対して結果整合性のある読み込みが2回/秒で1RCUを消費
- 最大4KBの項目に対して強い整合性のある読み込みが1回/秒で1RCUを消費
- 最大1KBの項目に対して書き込みが1回/秒で1WCUを消費
- 計算例
- 2KBの項目に対して100回/秒の結果整合性のある読み込み: 50RCUが必要
- 2KBの項目に対して100回/秒の強い整合性のある読み込み: 100RCUが必要
- 2KBの項目に対して100回/秒の書き込み: 200WCUが必要
DynamoDBの「export to csv」
- マネージメントコンソールのDynamoDBタブにて、exportボタンをクリックするとCSVを取得できる。
- 最大100レコードまで
- ネストされたデータが含まれている場合、データがjson形式でエクスポートされる。
S3の暗号化
- サーバ側の暗号化(Server Side Encryption: SSE)
- S3に書き込む際にデータを暗号化
- 暗号化に使用するキー: S3で管理されたキー(SSE-S3)、KMS(SSE-KMS)、ユーザ独自(SSE-C)
- クライアント側の暗号化(Client Side Encryption: CSE)
- S3に格納する前にデータを暗号化
- 暗号化に使用するキー: KMS、ユーザ独自
Cloud Formationのテンプレートの要素
- AWSTemplateFormatVersion: 【必須】「2010−09−09」固定
- Description: テンプレートの概要
- Metadata: テンプレートに関するメタ情報(テンプレートの詳細を記述)
- Parameters: テンプレートに渡す変数
- Mappings: 条件毎のキーと値のマッピング
- Conditions: 条件の定義
- Transform: Serverless Application Modelのバージョン指定
- Resources: 【必須】対象となるリソースを指定
- Outputs: スタックのプロパティから返される値の表示
SQS
- メッセージの配信順序は決まっていない。(最近は違うらしい...)
- 同じメッセージが複数回送信されることがある。
- 配信遅延(DelaySeconds)
- 目的: 処理開始を遅らせる。(S3にオブジェクト配置完了まで待つなど)
- キューイングしたメッセージの初期非表示期間を指定する。
- DelaySecondsを1[s]にする。(デフォルト値は0[s])
- 可視性タイムアウト(Visibility timeout)
- 目的: 同一メッセージが複数回処理されることを抑制する。
- メッセージが受信された後、サブスクライバから当該メッセージを受信不可にする時間(デフォルトは30秒)
- 本設定で指定した時間よりも処理時間を要すると、同じメッセージが再度キューイング、受信されることになるので時間を要する処理の場合は余裕を持った設定する。
- メッセージ受信待機時間、ロングポーリング(ReceiveMessageWaitTimeSeconds)
- 目的: 空振り防止、コスト削減
- ReceiveMessageWaitTimeSecondsを1〜20[s]に設定する。(デフォルトは0 = ショートポーリング)
- メッセージが空の場合に、設定した秒数待機する。その間にメッセージが入ってくれば取得できる。
- SQSはリクエスト数に応じた従量課金なので、ロングポーリングにより空振りを抑制することでコスト削減できる。
- メッセージ保持期間(MessageRetentionPeriod)
- 目的: メッセージの滞留防止
- 一度キューイングしたメッセージは明示的に削除するか、MessageRetentionPeriod(デフォルト4日間)以上経過しないと削除されない。
- Dead Letter Queues(DLQ)
- 目的: 異常系メッセージを別途処理するために、正常に処理されなかったメッセージをDLQに保持する。
- 設定した回数以上メッセージが受信されてもキューに残っている場合、DLQにメッセージが移動される。
Route53でDNSフェールオーバ
- Evaluate Target HealthフラグをTrueとしたルーティングレコードセットを作成する。
S3アクセスコントロールリスト(ACL)
- バケットやオブジェクトへのアクセスを許可するAWSアカウントまたはグループを定義する。
- 外部からのHTTPSアクセスを許可できる。
- アクセス拒否を設定できない。
- IAMユーザ、グループ、ロールのアクセス権は設定できない。
S3バケットポリシ
- AWSアカウントまたはグループ、 他アカウントのものを含むIAMユーザ、グループ、ロールに付与するバケットやオブジェクトへのアクセス権を定義する。
- 条件付きのアクセス権設定ができる。
(S3を対象とした)IAMポリシ
- AWSアカウントまたはグループ、 自アカウントのIAMユーザ、グループ、ロールに付与するバケットやオブジェクトへのアクセス権を定義する。
- 条件付きのアクセス権設定ができる。
S3 MFA Delete
- バージョニング機能のオプション
- バージョンIDを指定する削除操作のみ、MFAデバイスによる認証を必須とする。
- バージョンIDを指定しない通常のファイル操作(作成、変更、削除)通常と同じ。
S3のパフォーマンス
- 大量リクエストが予想される場合は、事前にピーク使用時の1秒あたりのリクエスト総数を確認する必要がある。
- 1秒あたりのリクエスト率がPUT/LIST/DELETE)の場合300、GETの場合800を超える場合は、サポートケースを開いて一時的な制限を回避する必要がある。
Auto Scalingがスケールアウトとスケールインを繰り返して安定しない。伸縮自在性を維持しながら最適化
- cool-downタイマのチューニング
- スケーリングポリシをトリガするCloud Watchのアラーム間隔をチューニング
オンプレミスデータセンタと仮想プライベートゲートウェイ間のVPC接続
- 仮想プライベートゲートウェイ: AWS側のGW、複数のカスタマーゲートウェイからのVPN接続を受け付けることができる。
- カスタマーゲートウェイ: ユーザ側のGW、WAN側アドレスとして固定グローバルIPアドレスを設定する必要がある。
EMR(Amazon Elastic MapReduce)、つまりHadoopでJOBの実行時間を短縮
- MapReduceジョブ構成の入力分割サイズ: サイズが小さいファイルを複数用意するより大きいファイル（GB以上）を扱う方が効率的
- 同時実行可能なマッパータスク数: リソースを効率的に活用できる様調整する。
- I/Oパフォーマンスに優れたインスタンスを使用する。
セキュリティグループの反映タイミング
- セキュリティグループの設定変更はリアルタイムに反映される。
- ただし、既にセッションが張られているものには適用されない。
- ポリシー変更後にnetstatで状態を確認するか、インスタンス再起動でポリシーを適用できる。