【AWS SAPのお勉強】継続的な改善

AWS Solution Architect Professionalのお勉強メモ

運用の優秀性

AWS Systems Manager
EC2(Windows, Linux)やオンプレサーバーにSSM Agentをインストールし、Systems Managerの管理対象(マネージドインスタンス)にできる。
SSM Agentには、AWS管理ポリシーAmazonSSMManagedInstanceCoreの権限とSystems Managerサービスへのネットワークが必要。

Session Manager
ブラウザのSession Managerからsudo可能なssm-userを使って対話式コマンドを実行可能。
コマンド実行履歴は、 CloudWatch LogsとS3に出力可能。基本的に無料。

Runコマンド(実行コマンド)
EC2、オンプレサーバーの管理対象(マネージドインスタンス)に、コマンドドキュメントに事前定義されたコマンド実行が可能。基本無料。
コマンド実行対象のマネージドインスタンスは、インスタンスID、タグ、リソースグループから指定可能。Systems Manager メンテナスウィンドウで実行時間を指定することも可能。

パッチマネージャー
OSとソフトウェアのパッチを自動的に選択し、マネージドインスタンスの大規模グループに自動的にデプロイ可能。パッチベースラインによって、OSシステムパッチや重要度高パッチなど自動承認のルールを設定可能。メンテナンスウィンドウをスケジュールして、指定の時間帯に適用されるように設定可能。再起動も選択可能。

Automation
複数アカウント、リージョンにわたるAWSリソースの管理のために、事前定義されたプレイブックを使用し、python or powershellのスクリプトをプレイブックの一部として実行できる。 CloudWatch Events(EventBridge)をトリガーさせることも、スケジュール設定も、手動実行も可能。

OpsCenter
運用で発生した問題の確認やステータスを一元管理。

Amazon Inspectorの結果からSystems Managerによって脆弱性修復を自動化
マネージドインスタンスにInspectorエージェントをインストールし、SNSトピックポリシーでinspector.amazonaws.comからのSNS:Publishを許可。Inspector評価テンプレートで、SNSトピックへの通知を設定。SNSトピックではサブスクに、Run Commandを実行するLambdaを指定。これで、Inspectorが脆弱性を検出したら、自動でLambda関数が実行され、Systems MangerのRun Commandで EC2の脆弱性を修復できる。

S3バッチオペレーション
S3のオブジェクト管理機能にバッチオペレーションがある。数十億のオブジェクトを大規模管理。IAMロールには、batchoperations.s3.amazonaws.comからの信頼ポリシーが必要。インベントリファイルが必要。インベントリファイルはCSVで作成してもいいし、日次・週次で自動作成されるものを使っても良い。
可能なバッチオペレーション
・リージョン内、リージョン間のオブジェクトコピー
・Lambda関数の呼び出し
・オブジェクトタグの置換、削除
・アクセスコントロールリストの置換え
・オブジェクトのGlacier系からの復元
・オブジェクトロックの保持
・オブジェクトロックのリーガルホールド有効化、解除

異常検知

Amazon GuardDuty
CloudTrail, S3データログ、VPC FLow logs, DNSクエリログを分析して、脅威を抽出。
リージョンサービス。

Amazon Macie
S 3バケットに保存された機密データを機械学習とパターンマッチングで検出・監視。
ジョブの検出結果は、指定のS 3バケットにKMS CMKで暗号化保存。

Amazon CloudWatch Anomaly Detection
CloudWatchメトリクスで異常検出を設定可能。統計アルゴリズムと機械学習アルゴリズムで、正常ベースラインが計算される。異常値に対して、CloudWatchアラームを設定可能。

信頼性の改善

EC2をステートレスに
サーバーにデータを保存するアプリはステートフルで、リクエストの分散できない。フェールオーバーにはデータのレプリケーションも必要。 AZ障害だけでなくHW障害だけでシステムダウンにつながる。
上記構成を、 EC2をステートレスにする。 EC2にデータを保存しないようにする。アプリ動作に必要なデータはAMIに紐付くスナップショットに入れておく。起動後にユーザーやシステムによって追加されるデータは、 EC2に保管しないことでリクエストを分散できます。分散できるので、複数AZに冗長化可能。
データの保存先でS 3を使うケースでは、アプリをSDKを使ってカスタムすれば可能。ユーザーが直接アップロード、ダウンロードしてくるユースケースに最適。
アプリのカスタムができない場合はE FSを使う。
ログなどローカルに書き込まれる記録は、 EC2にCloudWatchエージェントをインストールして、 CloudWatchLogsに出力。
これで EC2が使い捨てになったので、ALBによる分散リクエストやAuto Scalingが使用可能になる。

疎結合化
ALB-Web EC2-ALB-App EC2-DB&外部APIの構成の場合、外部APIが同時に受け付ける数に制限があったり、外部APIが落ちたりすると、App EC2で処理を捌けずにサービスが止まってしまう。その構成を、SNSとSQS、Lambda、Dynamo DBを使ったファンアウトにより解消可能。SNSとSQSにはFIFOトピックとFIFOキューを設定し、順序を守る。LambdaからAPIにリクエストを投げる。APIが落ちてる場合はリクエスト内容はDynamoに書いておき、APIが復旧したらリクエスト順序を維持したまま、再度APIへリクエストを投げる。

データベースへのリクエスト改善
データベースへの接続数が多いユースケースでは、RDS Proxyを使う。Aurora、RDS Mysql、PostgreSQLに使える。Aurora Serverlessは対応していない。アプリからRDS Proxyのエンドポイントにリクエストを投げる。DBのユーザー名とパスワードはSecrets Managerが必要。

パフォーマンスの改善

パフォーマンスの改善にはCloudFront、ElastiCache、API Gatewayが重要。

Amazon CloudFront

CDN。
オリジンへのアクセス制限は、OAI(オリジンアクセスアイデンティティ)・カスタムヘッダー、IPアドレス制限がある。
OAI:S3をオリジンとしている場合は、OAIが使用可能。OAIというユーザーをCloudFrontで作成し、OAIからのリクエストのみを許可したS 3バケットポリシーを作成する。
カスタムヘッダー:オリジンがALBの場合に有効。CloudFront側では、ディストリビューションのオリジン設定に任意のキーと値でカスタムヘッダーを追加。ALB側のルーティング設定で、指定したHTTPヘッダーがリクエストに含まれる場合のみ、正常なターゲットへルーティングする。指定したヘッダーが含まれない場合は、403 Access Deniedを返す。
IPアドレス制限:ip-ranges.jsonにAWSサービスが使っているIPアドレス範囲が公開されている。ただし、エッジロケーションの拡張など、IP{アドレス範囲は定期的な見直しが必要。セキュリティグループを使用する場合、Lambda関数をAWS SDKで実装し、EventBridgeで定期実行し、セキュリティグループを更新するなどの自動メンテが良い。

オンデマンドビデオ、ライブストリーミングビデオの配信
アプリからS 3にアップされた動画ファイルを、AWS Elemental MediaConvertによってHLS(HTTPライブストリーミングプロトコル)に変換し、配信用のS 3に保存。CloudFrontディストリビューションから再生アプリやデバイスへ配信可能。
ライブストリーミング配信は、AWS Elemental MediaLiveでリアルタイムにエンコードしたコンテンツをAWS Elemental MediaStoreに保存して、CloudFront経由で配信。

フィールドレベルでの暗号化
CloudFrontはフィールドレベルの暗号化が可能。公開鍵、秘密鍵を使った非対称暗号化。
例えば、ユーザーがフォームで入力した電話番号を、CloudFrontディストリビューションで登録された公開鍵で暗号化して、オリジンのAPI GatewayにPOST。API Gatewayは暗号化された電話番号をDynamoDBにPutItem(暗号化されたまま)。秘密鍵はパラメータストアでSecure StringとしてKMSで暗号化して保存しておく。Lambdaは、GetParameterした秘密鍵を使用し、DynamoDBからGetItemした暗号化された電話番号を復号。Amazon Connectを使えば自動で電話発信も可能。

署名付きURLと署名付きCookieを使用したプライベートコンテンツの配信
CloudFrontディストリビューションでもリクエストに認証を必要とさせること可能。
公開鍵・秘密鍵のキーペアをローカルで作成し、ClouFrontへアップロードして、キーグループをディストリビューションビヘイビア設定に追加。
署名付きURL:リクエスト時における制限付きの権限と有効期限が設定された URL です。署名付き URL のクエリ文字列には認証情報が含まれているため、認証情報を持たないユーザーでもリソースに対して特定の操作を実行できます。
署名付きCookie :CloudFront 署名付き Cookie を使用すると、現在の URL を変更したくない場合や、複数の制限付きファイル (ウェブサイトの購読者の領域にあるすべてのファイルなど) へのアクセスを提供する場合に、誰がコンテンツにアクセスできるかを制御できます。

エッジ関数
CloudFrontディストリビューションへのHTTPリクエスト、レスポンスの処理をエッジ関数でカスタムできる。エッジ関数には、CloudFront FunctionsとLambda@Edgeがある。
CloudFront Functions:CloufFrontの機能。JSで実装。最大2MB MEM。オリジンへのリクエスト、レスポンスはサポート外。ユースケースは、Lambda@Edgeより軽い処理に使う。例として、リクエストURL変換しキャッシュヒット率向上、ヘッダー追加、リクエストトークンの検証など。
Lambda@Edge:Lambdaの拡張機能。Node.js、Pythonが使える。メモリサイズが必要な処理に使う。オリジンへのリクエスト、レスポンスも対象。

AWS Global Accelerator
AWSグローバルネットワークを利用することで、複数のAWSリージョンへのネットワーク経路を最適化します。静的エニーキャストIPアドレスが提供される。BYOIPも可能。
作成したアクセラレータには複数のエンドポイントを設定できる。エンドポイントにはALB、NLB, EC2、EIPを設定可能。トラフィックダイヤルを使えば、エンドポイントに重み付けができる。ヘルスチェック機能もあり、異常を検知するとすぐに別のエンドポイントにルーティングされる。IPアドレスが変わらないので、フェイルオーバーが早い。
リスナーでポート番号範囲とTCP/UDPを設定。リスナー設定でクライアントアフィニティを有効化すると、同じ送信元IPからのリクエストは、同じエンドポイントへ送信される。ステートフルアプリに有効。

AWS ElastiCache

インメモリのデータストアをMemcachedエンジンかRedisエンジンで提供。
使い所は、ユーザーセッションやAPIへの問い合わせ結果、DBのRead負荷など。
Memcached:マルチスレッド、水平スケーリング。
 フラットな文字列をキャッシュするように設計されている。
Redis:は構造化データ(ソート済みセット型、ハッシュ型など)、永続性、アトミック、Pub/Sub、リードレプリカ/フェールオーバー。

Amazon API Gateway

API Gatewayキャッシュ
API GatewayのAPIステージで、GETリクエストに対しキャッシュを有効にできる。時間単位の追加料金発生。キャッシュ容量は0.5~237GB、8段階設定。TTLを秒数で指定。

エッジ最適化API
・エッジ最適化APIエンドポイント:エッジロケーションPOPを経由してルーティング。全世界のユーザーが使用するようなAPIが向いている。
・リージョンAPIエンドポイント:使用ユーザーが特定地域に集中している場合。
・プライベートAPIエンドポイント:VPCのみから使用する場合。

使用量プラン
1秒、1日、1週間、1ヶ月のAPI利用量を設定可能。顧客に配布するAPIキーごとに設定して、異常な数のAPIリクエストが実行され、他の顧客に影響が出ることを防ぐ。

APIの認証
IAM認証:IAMユーザーにIAMポリシーを設定し、実行許可する。他アカウントのIAMユーザーに許可する場合は、API Gatewayのリソースベースポリシーで、他アカウントからの実行許可ポリシーを定義する必要がある。
Cognitoオーソライザー:Cognitoユーザープールでサインインして取得したJWTをAuthorizationヘッダーに含めて、API Gatewayにリクエスト実行。
Lambdaオーソライザー:カスタム認証を検証したり、サードパーティ製品の認証を検証可能。

セキュリティの改善

AWS Secrets Manager
DBなどの認証情報を保持し、取得にはAPIリクエストを使用。更新が必要となったら、Secrets ManagerがDBの認証情報を更新して保持。アプリからSecrets ManagerへGetSecretValueリクエストを実行して、最新の認証情報を取得。認証情報の更新はLambdaが行う、

AWS WAF(Web Application Firewall)
対象はCloudFront、API Gateway、ALB、AppSync GraphQL API
リクエストの条件に対して、許可・ブロック・カウントを設定できる。
それぞれのリソースにWebACLをアタッチするだけ。
よくある攻撃についてはマネージドルールがある。独自ルールの設定も可能。
5分間に指定した数を超えた場合ブロックというカウントできるレートベースルールも可能。
料金:WebACL 5USD/M、ルール 1USD/M、リクエスト 0.6USD/100万リクエスト
代表的なマネージドルール
・ベースラインルールグループ
 コアルールセット:OWASP記載の高リスク脆弱性
 管理者保護:sqlmanagerなど管理用のURIパスへの攻撃保護
 既知の不正な入力:localhost、web-infなどのパス、PROPFIND、御承諾JWTからの保護
 SQLデータベース:SQLインジェクションなど、SQL DBを使うアプリに対しての保護
 Linux、POSIX、Windows OS:各OS固有の脆弱性からの保護
 PHP、Wordpress:fsockopenや$_GETなどの関数、WordPressコマンドやxmlrpc.phpへのリクエストからの保護
・IP評価ルールグループ
 Amazon IP評価リスト:Amazonの内部脅威インテリジェンスによってボットと識別されたIPアドレスのリストからの保護
・匿名IPリスト
 TORノード、一時プロキシ、などのIPアドレスのリストからの保護
・AWS WAFボットコントロールルールグループ
 ボットからのリクエストを管理、保護
AWS WAFのカスタムルールのプロパティ
リクエスト送信元IPアドレス、リクセウト送信元の国、リクエストヘッダー、リクエストに含まれる文字列、リクエストの長さ、SQLインジェクションの有無、クロスサイトスクリプテイングの有無
AWS WAFのメトリクスとログ
ルールごとと、全てのAllowedRequests、BlockRequestsがメトリクス取得でき、モニタリング可能。サンプリングログはWebACLの概要から確認。フルログはKinesis Data Firehoseを「aws-waf-logs-」で始まる名前で送信。

AWS Shield
DDoS攻撃から保護。Standardは無料で有効。CloudFront、Route53への攻撃を自動で緩和。
より高いレベルの保護はAdvancedを使用。
Advancedで可能になること
– CloudFront、Route53、Global Accelerator、ELB、 EC2、EIPの各リソースを指定しの保護
– 24/365のDDoSレスポンスチームが対応
– WAF使用料金も含む
AWS Shield Engagement Lambda
DDoSを自動検知してエスカレーションアクションを自動化する設計パターン。Shield AdvancedからのDDoS検知メトリクスに CloudWatchアラームを設定して、SNSトピックへ送信して、サブスクEメールを送信。もう一方のサブスクでLambda実行し、Sheild Advanced APIへAttackDetailなどをリクエストして、エスカレーションアクションを実行。エスカレーションアクションは、AWSサポートケースの作成やサードパーティサービスでインシデントチケットを切るなど。

AWS Network Firewall
VPC向けステートフルなマネージドネットワークファイアウォールおよびIPSサービス。
Network Firewallはトラフィック量に応じて自動的にスケールし、複数のAZにエンドポイントをデプロイすれば高可用性も実現。ネットワークACL、セキュリティグループでは実現できない、カスタマイズルールを実装可能。不正なドメインへのアクセスを防いだり、既知の不正IPを防いだり、署名ベースの検出が可能。
VPCイングレスルーティングと組み合わせると、検査用VPCとしてNetwork Firewallを構築して、大規模ネットワークにおいて全てのインバウンド、アウトバウンドを検査するよう設定も可能。
ステートレスルールとステートフルルールを作成して、ファイアウォールポリシーでルールに対しての動作を定義します。作成したポリシーはNetwork Firewallに関連付けします。Network Firewallエンドポイントを配置するVPCとサブネットを指定、通るようにルートテーブルを設定。Suricata互換のルールセットをインポートして利用可能。
Suricata:Suricata is an open source-based intrusion detection system and intrusion prevention system. 

AWS Firewall Manager
複数アカウントでAWS WAF、AWS Shield Advanced、VPCセキュリティグループ、AWS Network Firewall、Amazon Route53 Resolver DNSファイアウォールを一元管理可能。
AWS Organizations、AWS Configと連携し、AWS Configで非準拠リソースを抽出することも可能。
複数アカウントのCloudFrontディストリビューションなども保護可能。特定のタグでまとめて適用もOK。AWS Organizations組織内の全てのアカウントをShield Advancedに自動登録可能。

デプロイメントの改善

AWS CDK
CDKを使うとソースコードからCloudFormationテンプレートを生成できる。
詳細なパラメータ設定なしで、ペストプラクティスに基づくデフォルト設定が適用。
オブジェクト指向、ループ、条件分岐で動的にインフラ構築可能。レイヤごとの共有コンポーネントを共有クラスや関数として組織内で再利用できる。
from aws_cdk.aws_ec2 import Vpc
vpc = Vpc(self, “TheVpc”, cidr=”10.0.0.0/16″)
上記コードで、パブリックサブネットとプライベートサブネットを複数AZにデプロイしたVPCを構築できる。

CDKコマンド
CDKで記述したコードを基にデプロイするにはCDKコマンドを使う。
cdk init: CDKプロジェクトのスケルトンを作成
cdk list: プロジェクトのスタック一覧
cdk deploy: プロジェクトのスタックをデプロイ、引数で単一スタック指定も可能
cdk synthesize: CDKコードをテンプレートにして表示
cdk diff: CDKコードとスタックで差異がないか表示
cdk destroy: スタック削除

Amazon ECS

クラスタ
クラスタのタイプはAWS FargateとAmazon EC2から選択。
EC2の場合はOS、可用性、エージェント更新など、運用が必要。
EC2インスタンスにECSエージェントが実行される。 EC2 Auto Scalingグループをキャパシティプロバイダーに紐付けて、重み付けを設定。
Fargateの場合、運用が必要なく、コンテナ管理に集中できる。キャパシティプロバイダーにはFARGATEとFARTATE_SPOTがあり、FARGATE_SPOTを選択すれば70%割引。

タスク定義
コンテナがAWSサービスを使用するためのIAMロール、ネットワークモード、タスクサイズ、コンテナイメージ、ポートマッピング、環境変数などを定義。記述はJSON。ボリューム追加でE FS指定も可能。Amazon EventBridgeでスケジュールを設定し、ターゲットにECSタスクのコンテナを指定し、定期的に実行することも可能。

サービスの設定
コンテナを配置するVPC、サブネット、セキュリティグループ、Auto Scaling、ALBのターゲットグループ、デプロイメントが設定可能。

ECSイベントストリーム
EventBridge
(
“source”: [
“aws.ecs”
],
“detail-type”: [
“ECS Task State Change”,
“ECS Container Instance State Change”
]
}
Amazon EventBridgeで上記ルールを設定。ECSがタスクを開始or停止した時と、コンテナインスタンス上のリソース利用や確保が変更された時にイベントが発生。このイベントをLambdaやSNS、OpenSearch Serviceに連携すれば、リアルタイム通知が可能。

ネットワークモード
Fargateはawsvpcモードのみで、タスクにENIが割り当てられて使用できる。
コンテナタスクにセキュリティグループが設定可能。ALBのターゲットとしているときは、インバウンドルールをヘルスチェックとアプリケーションリクエストを設定。
EC2タイプの場合、awsvpc, none, bridge, hostを使用可能。hostを使用すれば、 EC2のENIにコンテナポートを直でマッピングできる。

Amazon EKS
Kubernetes準拠のフルマネージドサービス。Fargate、 EC2両方使用可能。ELB, IAM, VPC, PrivateLink, CloudTrail, App Meshなどのサービスと統合されている。

Please share this page: