AWS(5)セキュリティのベストプラクティス

概要

偶発的もしくは意図的な盗難漏洩不整合削除からミッションクリティカルな情報を保護するために、Information Security Management System (ISMS)を作成するためのガイドライン。

責任共有モデル

AWSでは、AWS が安全なインフラストラクチャとサービスを提供する一方で、ユーザは安全なオペレーティングシステム、プラットフォーム、データを用意する責任を持つ責任分担モデルを採用している。例えばEC2の場合は、設備やハードウェアの物理的セキュリティ、ネットワークインフラ、仮装化インフラはAWSが管理する一方で、AMI、OS、アプリケーション、データ、認証情報等は、ユーザ自らが管理しなければならない。

インフラストラクチャサービスの責任共有モデル

Trusted Advisorの利用

Trusted Advisorを利用してサービスの状況を確認し、セキュリティの設定ミスシステムパフォーマンスの向上に関する提案使用率の低いリソースの確認などを行うことができる。例えば、管理ポートへのアクセスが限定的なものであるかや、IAMが設定されているか、MFAが有効化されているかなどが確認できる。

アセット

ISMSを設計する前に情報アセットを特定し、これらを保護するために必要なソリューションを技術面とコスト面から検討する必要がある。アセットは、業務の情報やプロセスなどを含む本質的な要素と、ハードウェアやソフトウェア、人員などを含む本質的な要素をサポートする要素の2つに大別される。

アセットの例

アセット名 アセットの所有者 アセットカテゴリ 依存関係 コスト
顧客向けアプリケーション eコマースチーム 必須 EC2, RDS…
AWS Direct Connect 最高情報責任者(CIO) ネットワーク ネットワーク運用, Direct Connect

これらのアセットを保護するために、情報セキュリティマネージメントシステム(ISMS) の実装、運用、モニタリング、確認、保守、改良に関する基準を定める必要がある。このとき、ビジネスニーズや目標、プロセス、組織の規模や構造などを考慮して基準を定める。ISMSの設計には、ISO27001 などの標準的なフレームワークを参考にすると良い。

段階 内容 詳細
1 スコープと境界の定義 スコープに含めるリージョン、AZ、リソース等を定義する。除外するリソースがある場合はその除外理由を明記する。
2 ISMSポリシーの定義 情報セキュリティの方向性と指針、法律や契約の要件、リスクの評価方法や承認方法
3 リスクの評価方法の選択 ビジネスニーズ、セキュリティ要件、IT機能と要件、法規制
4 リスクの特定 アセットとアセットに対する脅威を記した登録簿の作成、脆弱性とその結果
5 リスクの分析と評価
6 リスクへの対処 リスクを受け入れる、回避する、リスクレベルの査定
7 セキュリティコントロールフレームワークの選択 ISO 27002、NIST SP 800など
8 マネジメントによる承認の取得 残留リスクの報告と承認
9 適用宣言書の作成 選択したフレームワーク、導入済/予定のフレームワーク、除外したフレームワークとその理由

AWSアカウント

AWSアカウントは非常に強力な権限を有するので日常的な使用はせず、極力IAMユーザを使用する。またIAMユーザは、(特定のグループに所属するIAMユーザが1名だけであった場合でも)IAMグループを利用し、またきめ細やかに権限を付与し、タスクに必要な最小限のアクセス権限を付与する。また、AWSのアカウントは、セキュリティの観点から単一アカウントで処理する、開発ステージごとにアカウントを分割する、などビジネスやガバナンスの要件を満たすように設計することが必要である。AWSアカウントを複数有する場合は、一括請求アカウントを利用することで、管理の複雑さを低減し、スケールメリットを享受することができる。

アクセスキーを利用する場合は、定期的に更新を行う。また、IAMユーザの認証にはMFAの併用が望ましい。複数のAWSアカウントを横断的に利用する場合には、クロスアカウントアクセスの利用も検討する。社内に既にディレクトリサービスを有する場合には、IDフェデレーションの利用も可能である。EC2から他のAWSリソースを利用する場合はIAMロールを使用する。

データの保護

リソースへのアクセス保護

リソースへのアクセスは、各リソースを作成したユーザが他のユーザに対してアクセスを許可するリソースポリシーと、IAMユーザやIAMグループを使用して付与される機能ポリシーのいずれかを単独でもしくは組み合わせて使用する。

保管時のデータ保護

以下の課題を考慮して、データの保護を行う手法を検討する

  • 偶発的な情報開示や漏洩
  • データの不整合や不正な書き換え
  • 過失による削除
  • システム障害や災害に備えたシステムの可用性

S3におけるデータ保護

  • アクセス権限の付与
  • バージョニング
  • レプリケーション
  • バックアップ
  • サーバサイド暗号化
  • クライアントサイド暗号化

EBSにおけるデータ保護

  • レプリケーション
  • バックアップ(スナップショット)
  • 暗号化

RDSにおけるデータ保護

  • 暗号化関数の使用
  • アプリケーションレベルの暗号化

Glacierにおけるデータ保護

  • サーバサイド暗号化
  • クライアントサイド暗号化

DynamoDBにおけるデータ保護

  • Base64エンコード

EMRにおけるデータ保護

  • S3のサーバサイド暗号化
  • S3のクライアントサイド暗号化
  • アプリケーションレベルの暗号化

伝送中のデータ保護

以下の課題を考慮して、データの保護を行う手法を検討する

  • 偶発的な情報開示や漏洩
  • データの不整合や不正な書き換え
  • なりすましや中間者攻撃

伝送中のデータを保護するために、AWSではIPSecSSL/TSLをサポートしている。また、Remote Desktop Protocol(RDP)の使用やSSHの使用も有効である。

S3へ伝送中のデータ保護

  • SSL/TSLを用いた通信

RDSへ伝送中のデータ保護

  • SSL/TSLを用いた通信
  • X.509証明書

DynamoDBへ伝送中のデータ保護

  • HTTPSの利用

OSとアプリケーションのセキュリティ保護

OSとアプリケーションのセキュリティを保護するためには以下が奨励される。

  • ルートアクセスキーとシークレットキーの無効化
  • IPアドレスを限定したインスタンスへのアクセス
  • pemファイルのパスワード保護
  • ユーザの管理
  • 認証情報の更新
  • IAMユーザのアクセス権を定期的に管理

AMIを公開する場合は、認証情報をOS上から消去しておくなど、セキュリティ面には十分注意する。

万が一、OS等への侵入が確認された場合に、根本的な原因追求を行うためにフォレンジックを行う。

ブートストラッピング

PuppetやChefなどを利用してセキュリティプログラムの更新や、パッチの適用、ステージに合わせた環境設定の実行、リモートモニタリング等を実施する。

マルウェアからの保護

信頼できないAMIやコードは実行しない。また、信頼できないソフトウェアリポジトリも使用しない。ユーザに付与する権限は必要最小限とし、ウイルスおよびスパム対策ソリューションを必ず利用する。

その他の対策

  • ベンダー指定のデフォルト値を削除する
  • 不要なユーザを無効化する
  • EC2に複数の機能を持たせない
  • 必要なサービスやデーモンのみ有効化する
  • 不要な機能やWebサーバは無効化する

インフラの保護

インフラを保護するためには以下を行う。

VPCの利用

VPCを利用することで、AWSのパブリッククラウド内にプライベートクラウドを作成できる。他のAWSユーザからリソースを隔離できるということだけでなく、インターネットから隔離することもできる。また、IPSecやDirect Connectを利用することでオンプレミス拠点とAWS間をセキュアに接続することも可能である。

セキュリティグループやNACLを使用することで、セキュリティゾーニングを実現することができる。この際に、セキュリティゾーン間の通信を制御するかゾーン間の通信をモニタリングするかゾーンごとにアクセス権限を付与するか、などを検討する必要がある。

セキュリティのテスト

セキュリティコントロールとポリシーの有効性を定期的にレビューする。新しい脅威や脆弱性に対処するためには、外部脆弱性評価外部侵入テストアプリケーションとプラットフォームの内部グレー/ホワイトボックスレビューを行う。なお、侵入テストを行う場合には、AWSにリクエストが必要な場合がある。

メトリクスの管理と向上

有効性の測定を行う上では、メトリクスの利用が有効的である。

  • 手順のモニタリング
    • 処理結果からエラーを迅速に検出する
    • セキュリティ侵害やインシデントに迅速に対応する
    • セキュリティアクティビティが想定通りに実行されているか判断する
    • セキュリティイベントを検知してインシデントを防止する
    • 対処が効果的であったか判断する
  • ISMSの有効性のレビュー
    • セキュリティ監査、インシデント、有効性測定
    • 関係者からの提案およびフィードバック
    • ポリシーが目的に合っているかの確認
  • 有効性の測定
    • セキュリティ要件を満たしているかどうか
  • 定期的なリスク評価レビュー
    • 残留リスクの許容可能なリスクのレビュー
    • 法改定など外部イベントに適しているか
  • 内部監査
  • 定期的な管理レビュー
    • スコープが適切か
  • セキュリティ計画の更新

DoSおよびDDoS攻撃の緩和と保護

DoSおよびDDoSについて懸念がある場合には、AWSのサポートの契約が望ましい。サポートに契約することで、AWSがDoSおよびDDoS攻撃の事前および事後にサポートを提供できる。AWSは、トラフィックが攻撃によるものかは判断できないために、アクティブに対処することはしない。これらの攻撃に対処するためには、以下の手法を検討する。

  • セキュリティグループやNACLの使用
  • WAFの使用
  • レート制限
  • ハーフオープンセッションの制限

モニタリングと監査、インシデント対応

ログファイルを蓄積することで、適切なモニタリングとて監査、インシデント対応を行うことができる。

エリア 考慮事項
ログ収集 収集方法に注意する
ログ転送 ログファイルを安全、確実、タイムリーに転送する
ログストレージ 一元管理し分析を行う
ログ分類 分析に適した形式
ログ分析 ログファイル内のイベントを相互に関連付ける
ログの保護 改ざん等を防ぐ

AWS ElastiCache(1)ElastiCacheの概要

Elasticacheとは

完全マネージドなRedis および Memcached。インメモリデータストアのため非常に高速で、大量のデータを処理したり既存のシステムを効率化することができる。

インメモリデータストアの目的は、データのコピーに超高速で低コストなアクセスを提供することである。キャッシュするデータを決定するためには、データ自体とそのアクセスパターンを把握する必要がある。また、これらのキャッシュされたデータは最新データではないという認識が必要で、使用するアプリケーションの特性上、古いデータでも許容されるのかどうかについて考察が必要である。

Elasticacheは、RedisとMemcachedをサポートしているが、できるだけシンプルな構成が必要であったり、大きなノードを実行する場合は、Memcachedを選択すべきである。

キャッシュできるデータは、S3RDS, DynamoDB streamsなど。

クラスタとレプリケーション

ElastiCacheは、メモリの断片であるノードという単位から構成され、これらを1〜6台まとめたグループをシャードと呼ぶ。クラスタモードを有効化したRedisでは、1〜15のシャードで構成される。無効化されている場合は常に1シャードのみである。

Redisクラスタ

クラスタ構成を有効化する場合には、ノード数を2以上とし、マルチAZ構成とすることが望ましい。クラスタ構成とするとデータは、シャードごとに分散されて保存され、クラスタの一部に異常が発生した場合には、正常なノード(サービス)にマスターが自動で移動する。また、異常が発生したノード(サービス)は再構成される。

Redisレプリケーション

リードレプリカを使用することで、耐障害性が向上するとともに読み込み能力がスケールアウトする。Redisに異常が発生した場合は、DNSが切り替わり、新しいノードにマスターが移動する。

キャッシング戦略

Redisにおけるキャッシュ方法は以下が用意されている。

方法 内容 利点 欠点
遅延書き込み データがキャッシュにない、もしくは古い場合に追加 容量, 障害の影響 遅延, データの古さ
書き込みスルー データがデータベースに書き込まれると常にデータを追加 データが新しい ノード拡張時にデータが存在しない, 不要なキャッシュ
TTLの追加 有効期限を指定し、期限切れはデータがないものとして扱う

AWS DynamoDB(3)使用する上で注意すること

適切なスキーマ設定

DynamoDBは限られた範囲のクエリを効率よく処理できるがそれ以外はコストが掛かる。重要なクエリを安価に効率よく実行できるようなスキーマ設計が需要である。アプリケーションのユースケースを注意深く解析して、単一のテーブルで処理可能な構造とする。

スキーマを構成する上で確認すべき点は、データサイズデータ形式クエリ負荷である。

  • 関連するデータをまとめる
  • ソート順を決定する
  • クエリを分散する
  • グローバルセカンダリインデックスを使用する

パーティションキー

効率的なパーティションキーの設計とし、クエリを分散させる。ただし、一部のパーティションに負荷が偏った場合でも、アダプティブキャパシティが自動的に適用され、ある程度は影響を緩和することができる。

アダプティブキャパシティ

負荷を分散させるために、格納された値を元にパーティションキーにサフィックスを付加する手法も存在する。

キャパシティを上げた状態でOnDemand課金に切り替える

OnDemandを使用する場合は、バーストトラフィックに耐えれるように、まずキャパシティを上げた状態にしておき、それからOnDemand課金に変更する。ただし、課金体系への変更には制限があることから頻繁な変更はできないことに留意が必要。

大きな項目データは、圧縮するかS3に保存する

圧縮したバイナリデータを保存したり、S3に保存してこのオブジェクト識別子をDynamoDBに保存することができる。

時系列データは複数テーブルによる構成も検討する

時系列データの場合、当日データに書き込みや読み込みが偏り、ホットスポットが発生する。これを回避するために期間ごとにテーブルを分割して、バッチ処理で新しいテーブルの作成と新しいテーブルへの切り替えを行う。

クエリの最適化

Scanクエリはなるべく使わない

Scanは非常に低速でデータ数が大きくなると非効率となるので避ける。

条件付き書き込みやアトミックカウンターを使用する

複数が同時に更新する場合は、条件付き書き込みを使用する。

AWS Lambda(3)使用する上で注意すること

エントリポイントをコアロジックから分離

トリガを受ける関数と処理を行う関数を分離することで、単体テストが実施しやすくなり、また依存関係が完結となり関数のパフォーマンスも向上する。

再帰的な処理を記述しない

意図しない処理が発生する可能性があるため。

メモリ使用量を計測し適切なサイズに設定する

AWS CloudWatch LogsのMax Memory Usedを参照して最適なメモリサイズを設定する。

実行時間を計測し適切なタイムアウト値を設定する

同時実行数にも関連するので、実際の値を正確に把握する。

AWS SQS(1)Amazon Simple Queue Serviceの概要

Amazon SQSについて

Amazon SQSは、マネージド型のメッセージキューイングサービス。SQSを使用することであらゆる量のソフトウェアコンポーネント間で、メッセージの送信や保存、受信が可能となる。

SQSでは、標準キューと呼ばれる配信順序がベストエフォート型のキューと、FIFOキューと呼ばれる送信順に配信されるキューの2つが用意されている。FIFOキューは、米国東部(バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、および 欧州 (アイルランド) リージョンのみで使用可能。

内容 標準キュー FIFOキュー
イメージ 標準キュー FIFOキュー
特徴 無限のスループット, 1回以上の配信, ベストエフォート 300件/秒, 1回のみ処理, 厳密な順序

キュー内のメッセージ数の上限は、12万件。メッセージ属性は、単一メッセージ内に10個まで。バッチ処理は、10メッセージまで同時に可能である。

AWSサービスとの連携

Amazon SQSは、他のAWSサービスと連携して使用することができる。

  • Amazon SNSでトピックが発行された際に、指定したSQS(標準キューのみ)対してキューメッセージを送信することができる。
  • キュー(標準キューのみ)にメッセージが着信した際に、これをトリガにLambda関数を事項させることができる。

キューの設定

キューを作成する際には、以下の項目を設定する。

設定項目 内容 デフォルト値 最大
可視性タイムアウト 受信したメッセージが他のキューから見えない時間 30秒 12時間
保持期間 メッセージの保持期間 4日 14日
最大メッセージサイズ 最大メッセージサイズ 256KB 256KB
配信遅延 初回配信時の遅延時間 0秒 15分
メッセージ受信待機時間 ロングポーリング時の待機時間。0秒に設定するとショートポーリングとなる。 0秒 20秒
コンテンツに基づく重複排除 (FIFOのみ) 本文のハッシュ値から重複排除IDを自動生成する 無効
デッドレターキュー 最大受信数を超えた場合の処理 無効 1000
サーバ側暗号化 CMKを用いたサーバ側暗号化の設定 無効

ロングポーリングとショートポーリング

ロングポーリングの場合、問い合わせの結果が空であった場合に、指定したメッセージ受信待機時間、SQSが待機してから応答を返す。これによって、空のレスポンス数を削減し、効率的なメッセージ取得が可能となる。

ショートポーリング

ショートポーリングは、問い合わせの結果に関わらず、常に応答を返す。

メッセージの送信

SQSのメッセージには本文に加えて、メッセージ属性を含むことができる。メッセージ属性は、キータイプ(String, Number, Binary)、から成る。

標準キー

1メッセージ単位で、配信遅延時間を設定することができる。

FIFOキー

メッセージグループIDメッセージ重複排除IDが入力必須。メッセージグループIDが同一のメッセージは、順序が保障される。キューの設定で、コンテンツに基づく重複排除を有効化していない場合は、メッセージ重複排除IDも入力する必要がある。

重複排除間隔は、5分

メッセージの受信

可視性タイムアウトの値は、受信ソフトウェアがメッセージを処理する時間を計測して決定する。具体的には、受信ソフトウェアが処理時間よりも長く、かつリトライまで待つ時間が必要以上に長くならない値に設定すべきである。

また、ロングポーリングを設定することで空の応答を減らしたり、バッチ処理によって複数のメッセージを処理することで、SQSの使用コストを削減することができる。

メッセージのエラー処理

デッドレターキューを設定することで、処理できない問題のあるメッセージをキャプチャすることが可能である。なお、デッドレターキューにメッセージが送信されても、元のメッセージのタイムスタンプは変更されないことに留意が必要

利用シーン

SQSは、以下のような用途で使用できる。

用途 内容
ワークキュー 同時に処理できないデータを処理から切り離す
バッファリング システムにスケーラビリティと信頼性を追加
リクエストのオフロード インタラクティブな処理から遅い処理を切り離す
ファンアウト SNSと組み合わせて1つの処理を複数のキューに配信
優先順位 優先順位ごとのキューを用意

AWS Identity and Access Management(4)STS

AWS Security Token Serviceとは

STSとは、AWSリソースへアクセスできる一時的なセキュリティ情報を持つユーザを作成できるサービスで、一般的なアクセス認証情報と異なり、リクエストに応じて、事前に定めた数分〜数時間の短い使用期限の認証情報が発行される。STSを利用することで作成したアプリケーションに長期の認証情報を埋め込む必要がない。STSはグローバルサービスで、全リージョンで単一のエンドポイントを持つ。

認証フェデレーション

外部システムでユーザーIDを管理し、それらのシステムからサインインするユーザーに一時的な認証情報を付与することができる。外部システムは、Microsoft Active DirectoryをはじめとしたSAML対応のサービスや、 Amazon、Facebook、Google、OpenID ConnectなどのウェブIDに対応している。

EC2におけるSTSの利用

EC2のロールもSTSを利用しており、ロールで許可したサービスを利用するために、一時的な認証情報がインスタンスに対して付与される。

セキュリティ認証情報のリクエスト

認証フェデレーションによって、アクセスキーおよびセッショントークンで構成された一時的セキュリティ認証情報を得ることができる。認証情報のリクエストには以下のAPIが利用できる。認証期間はデフォルトで1時間

API名 対象 呼び出し元 有効期間(デフォルト) 有効期間(最大)
AssumeRole クロスアカウント, カスタムIdB IAMユーザ 1時間 ロールの指定値
AssumeRoleWithWebIdentity Web IdP 任意のユーザ 1時間 ロールの指定値
AssumeRoleWithSAML SAML IdP 任意のユーザ 1時間 ロールの指定値
GetFederationToken カスタムIdB root/IAMユーザ 12時間 36時間
GetSessionToken 信頼されていない環境のユーザ root/IAMユーザ 12時間 36時間

認証情報の取り消し

必要がある場合、特定の時点より前に発行したロールの認証情報の、すべてのアクセス許可をすぐに取り消しできる。すべてのユーザーは、新しい認証情報を再認証して、リクエストする必要が生じる。

AWS Elastic Beanstalk(1)Elastic Beanstalkの概要

Elastic Beanstalkとは

Elastic Beanstalkは、Java、.NET、PHP、Node.js、Python、Ruby、Go などを使用して開発されたプログラムをApache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするためのサービス。インフラストラクチャの準備、運営から、アプリケーションスタック (プラットフォーム) の管理までをElastic Beanstalkが担当するため、ネットワーク設定や保守などの作業が不要

All at Onceローリング追加バッチとローリングイミュータブルブルー/グリーンなどの複数のポリシーからデプロイ方法を選択可能である。

Elastic Beanstalkを使用するにあたっての利用料金は不要で、デプロイしたAWSリソースに対する通常の使用料金のみ課金される。

使用するAWSリソースとその機能について、十分な知識を有する場合は、CloudFormationテンプレートを作成して運用することが望ましい。

Elastic Beanstalkのワークフロー

Elastic Beanstalkは、複数のアプリケーションを作成することが可能で、各アプリケーションは、Application VersionEnvironment(デプロイ済みのアプリケーション)やEnvironment TierEnvironmentの種別)、Environment Configuration(Environmentの設定)を有する。

Application Version

デプロイ可能なコードを指し、S3上でバージョン管理される。

Environment Tier

HTTP リクエストを処理し、ウェブアプリケーションを実行可能なWebサーバ環境と、Amazon SQSキューからタスクを引き出し、バッチ処理などをスケーラブルに実行可能なワーカー環境の2つから選択することが可能である。

Webサーバ環境

Webサーバ環境で構築されるEC2のソフトウェアスタックは、選択したコンテナタイプ(テンプレート)によって異なる。また、ホストマネージャー(HM)と呼ばれるソフトウェアコンポーネントも実行され、アプリケーションのデプロイの実行や、アプリケーションの監視等も行なっている。

Webサーバ環境

ワーカー環境

完了するまでに長い時間がかかる処理は、SQSを用いたワーカー環境で実行することが望ましい。ワーカー環境では、Amazon SQS キューを管理しタスクを実行するSQSデーモンが実行される。また、cron.yamlにタスクを記述することで、タスクの定期実行を行うことも可能である。

ワーカー環境

設計上の注意事項

スケーラビリティを確保する方法として、スケールアップ(垂直スケーリング)とスケールアウト(水平スケーリング)が存在が、スケールアップは過剰なリソースの準備となるなど問題点が存在するため、Elastic Beanstalkアプリケーションは、必要に応じてスケールアウトできる耐障害性に優れた疎結合コンポーネントを使用して、できるだけステートレスにする必要がある。

また、耐障害性を有するように、必ず故障から自動回復できるように設計、実装、およびデプロイする必要がある。

アプリケーションの管理

ソースコードをアップロードするたびに、新たなバージョンラベルを付与し、アプリケーションバージョンを作成する。古いアプリケーションバージョンは削除することも可能で、削除してもデプロイ済みのEnvironmentには影響を与えない

アプリケーションバージョンライフサイクルポリシーを設定することで、過去のバージョンを自動的に削除することが可能である。保有するバージョンの数、もしくは期間を設定でき、これを超えるとサービスが自動でアプリケーションバージョンを削除する。

アプリケーションは、ソースバンドルと呼ばれる処理プログラムを含む必要があり、ソースバンドルは、単一のZIPファイルまたはWARファイルで構成される必要がある。AWS Toolkit for Eclipse等を使用して開発を行なっている場合は、ツールが正しく構造化した上でZIP化してくれる。

Environmentの管理

1つのアプリケーションは、開発環境、統合環境、本番環境など複数のEnvironmentをデプロイすることができる。新たなEnvironmentを作成する場合は、

  • プラットフォーム
  • Application Version もしくは 新たなソースバンドル
  • Environment Tier(ウェブ環境/ワーカー環境)

等を指定する。作成したEnvironmentを終了すると、デプロイしたリソースの全てが削除される。

デプロイ

Environmentをデプロイする際には、複数のデプロイ方法の中から1つを選択することが可能である。

方法 デプロイメントポリシー 内容 制約 時間 ダウンタイム DNS変更
All at Once All at Once 現行のインスタンス全てに新たなコードを適用する
Rolling Rolling 現行のインスタンスに順に新たなコードを適用する 単一インスタンス環境では選択できない やや速
Rolling with additional batch Rolling with additional batch 新たなインスタンスと現行のインスタンスの一部に新たなコードを適用する 単一インスタンス環境では選択できない
Immutable Immutable 新たなインスタンスに新たなコードを適用する
Blue/Green Rolling with additional batch もしくは Immutable 新たなインスタンス(と現行のインスタンスの一部)に新たなコードを適用する 単一インスタンス環境では選択できない URL Swap もしくは DNS切り替え

Rollingを用いてデプロイする場合は、更新するバッチサイズを指定する。また、Route53の加重ラウンドロビンを利用することで、新バージョンを徐々に適用していくことも可能である。

プラットフォームの更新

アプリケーションを実行しているプラットフォームの更新を定期的に、もしくは手動で行うことが可能である。また、マイナーアップデートを含めるのか、パッチの適用だけなのかについても選択することができる。

AWS認定(2)デベロッパー(アソシエイト)に合格するまで

AWS認定デベロッパー試験合格に向けての資料集。以下の資料を何度も読み込んで、手を動かしながら実践を繰り返すことが合格の近道となる。

出題範囲と学習法

AWS認定デベロッパー試験の問題は、システムを構築する際に、可用性や拡張性コストなどを考慮した上で、実際どのような手法で実装するかについて問われることが多い。AWSが提供するサービスは100を超えるが、本試験を受講する上では、API Gateway, Cognito, DynamoDB, S3, SQS, IAM(STS), Elastic Beanstalk, Elastic Beanstalk, Lambdaなどのデプロイツールやサーバレスアーキテクチャの理解。また、CloudFormation, CodeBuild, CodeCommit, CodeDeploy, CodePipeline, CloudFront, CloudWatch, ElastiCache, Kinesis, RDS, X-Rayなども理解しておくことが必要である。

勉強法は、

  1. サンプル問題集に目を通してレベルを確認する
  2. 以下の資料を読みながら実際に各サービスに触れる
  3. 模擬試験を受講する

で十分合格ラインに行くかと。ちなみに学習時間は2週間ほど。なお、各サービスのドキュメントにベストプラクティスの項目が存在する場合は、該当部分を理解しておく

対策本

対策本はほとんど発売されていない。以下の本が唯一の試験対策本。この本には、各サービスの概要や特徴が簡潔に書かれており、AWSの各サービスの概要を学ぶためには非常に有効。一方で、章末問題と実際の試験問題は異なるので、実際の問題に慣れるためには、模擬試験の受講が必要である。

AWSの概要とセキュリティ

AWS(1)AWSの概要とメリット
AWS(4)Well-Architectedフレームワーク
AWS(5)セキュリティのベストプラクティス

AWS Identity and Access Management

AWS(2)セキュリティの概要
AWS Identity and Access Management(1)IAMの概要
AWS Identity and Access Management(4)STS

AWSの基本サービスの概要

Amazon S3

AWS S3(3)S3の概要
AWS S3(4)使用する上で注意すること

Amazon RDS

AWS RDS(1)Relational Database Serviceの概要

Amazon DynamoDB

AWS DynamoDB(1)DynamoDBの概要

Amazon ElastiCache

AWS ElastiCache(1)ElastiCacheの概要

AWS Lambda

AWS Lambda(1)Lambdaの概要
AWS Lambda(3)使用する上で注意すること

Amazon Kinesis Data Streams

AWS Kinesis(1)Kinesisの概要

Amazon SQS

AWS SQS(1)Amazon Simple Queue Serviceの概要

AWS Elastic Beanstalk

AWS Elastic Beanstalk(1)Elastic Beanstalkの概要

Amazon CloudWatch

AWS CloudWatch(1)CloudWatchの概要

Amazon SNS

AWS SNS(1)Simple Notification Serviceの概要
AWS SNS(2)モバイルプッシュ通知

Amazon Cognito

AWS Cognito(1)Cognitoの概要