AWS認定プログラム ソリューションアーキテクト – プロフェッショナルに合格しました
AWS認定プログラム ソリューションアーキテクト – プロフェッショナルに合格しました。
合格に必要な情報をまとめておきます。
AWS認定プログラムについて
こちらにまとめています。模擬試験が2160円、本試験が32400円。
yamano3201.hatenablog.jp
AWS活用資料集
一番まとまってるしわかりやすいので、ここから入るとわかりやすいです。
AWS クラウドサービス活用資料集 | AWS
無料問題集
ある程度勉強したら問題集に取り組みます。
yamano3201.hatenablog.jp
模擬試験
模擬試験は悪問が多いそうです。受けなくても良いかもしれません。
【AWS認定】ソリューションアーキテクト プロフェッショナル(AWS CSA-Pro)に合格してきた【英語重要】
公式リンク
自分用のメモになりますが、受験前に一読するとヒントになると思います。
yamano3201.hatenablog.jp
有料サービス
個人的にはUdemyのPractice Testがおすすめです。
https://www.udemy.com/aws-certified-solutions-architect-professionalpractice-test/learn/v4/overview
80問×3で240問が買い切りです。
日本語に対応していないですが、解説もあり充実していました。
私の場合、試験の2週間前から1日20-30問くらいを解きながら勉強しました。
結果
結果はすぐに画面で確認することができます。
私の場合は80%でした。
総合評点: 80% トピックレベルスコアリング: 1.0 High Availability and Business Continuity: 83% 2.0 Costing: 100% 3.0 Deployment Management: 87% 4.0 Network Design: 75% 5.0 Data Storage: 66% 6.0 Security: 75% 7.0 Scalability & Elasticity: 76% 8.0 Cloud Migration & Hybrid Architecture: 100%
所感
どんなに勉強しても受かるか心配だったのですが、
UdemyのPracticeTestで3回とも70%を超えたのが自信になりました。
有料ですが、一度は問題を解いてみるのがおすすめです。
AWS認定試験を受ける前に確認すべき公式リンク一覧 (ソリューションアーキテクト – プロフェッショナル)
AWS 認定ソリューションアーキテクト – プロフェッショナルを受ける前に確認すべき公式リンク一覧をまとめました。
aws.amazon.com
既にAWSについて詳しく知っている人向けの確認用のメモです。
EC2
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html
- タグ
- 環境ごとのEC2の保護にタグが使える
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html
- シングルルート I/O 仮想化 (SR-IOV)
- 高性能ネットワーキング機能
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html
- HVM AMI
- ハードウェアへの高速なアクセスを可能にするハードウェア拡張を利用できる
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html
- EBS暗号化
- 以下の暗号化を行う
- ボリューム内の保存データ
- ボリュームとインスタンスの間で移動されるすべてのデータ
- ボリュームから作成されたすべてのスナップショット
- それらのスナップショットから作成されたすべてのボリューム
- 以下の暗号化を行う
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html
- AMIリージョン間コピー
- DR用
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html
- 複数ENI、複数EIP
- 管理用ネットワーク作成
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-capacity.html
- InsufficientInstanceCapacityエラー
- リスタートか再作成
AutoScaling
http://docs.aws.amazon.com/autoscaling/latest/userguide/as-suspend-resume-processes.html
- スケーリングプロセスの中断
- ウェブアプリケーションの設定などの問題を調査し、アプリケーションに変更を加えたいときに使う
CloudWatch
ELB
CLBの問題が多い。今ならALB, NLBを使うのが普通。
http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-az.html
- AZ追加
- 複数AZに追加できる
VPC
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html
- NACL
- CIDR の範囲を指定してインバウンド、アウトバウンドのACLを設定
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html
- DHCP オプションセット
- 作成後に変更できないので、新しいセットを作成して新しく関連付けする
Route53
S3
http://docs.aws.amazon.com/AmazonS3/latest/dev/cors.html
- Cross-Origin Resource Sharing (CORS)
- クロスオリジンリクエストを明示的に有効にする
http://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html
- 署名付き URL
- 署名付き URL の作成者がそのオブジェクトをアップロードする権限が必要
CloudFront
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
- S3 コンテンツへのアクセスを制限
- Origin Access Identityを使って制限する
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/what-is-lambda-at-edge.html
- Lambda@Edge
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-overview.html
- ウェブディストリビューション
- Apple HTTP Live Streaming (HLS) を使用したオンデマンドマルチメディアコンテンツに対応
RDS
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html
- マルチ AZ
- 異なるアベイラビリティーゾーンに同期スタンバイレプリカが自動的にプロビジョニングされる
DynamoDB
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html
- グローバルセカンダリインデックス
- 1 つ以上の グローバルセカンダリインデックス を作成して、そのインデックスに対して Query リクエストを発行できる
RedShift
http://docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html
- スナップショット
- 自動と手動の 2 つのタイプがある
http://docs.aws.amazon.com/redshift/latest/dg/c_workload_mngmt_classification.html
- ワークロード管理 (WLM)
- デフォルトで、同時実行レベルが 5の 1 つのキューと、同時実行レベルが 1 のスーパーユーザーキューを設定する
http://docs.aws.amazon.com/redshift/latest/mgmt/purchase-reserved-node-instance.html
- リザーブドノード
- プロジェクトの評価フェーズ、または概念実証を開発する場合はオンデマンドを使う
Kinesis
http://docs.aws.amazon.com/streams/latest/dev/introduction.html
- Kinesis Data Streams
- データレコードの大量のストリームをリアルタイムで収集し、処理する
IAM
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html
- ウェブ ID フェデレーション
- IdPを使用してサインインし、認証トークンを受け取って、DynamoDBにアクセスする
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html
- IAMロール
- パスワードやアクセスキーが不要
http://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
- クロスアカウントアクセス
- 特定のアカウントにあるリソースを別のアカウントのユーザーと共有できる
OpsWorks
http://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-custom-ami.html
- カスタム AMIとchefレシピ
http://docs.aws.amazon.com/opsworks/latest/userguide/common-issues-troubleshoot.html
- UnrecognizedClientExceptionエラーの原因
- IAM ユーザーまたはロール削除
- ボリュームまたはストレージの設定編集
- 手動でEIP追加
http://docs.aws.amazon.com/opsworks/latest/userguide/best-practices-updates.html
- AWS OpsWorks スタック
- 通常、アプリケーションサーバー、データベースサーバー、ロードバランサー、その他のスタックが必要
http://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-events.html
- ライフサイクルイベント
- Setup, Configure, Deploy, Undeploy, Shutdown
CloudFormation
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-findinmap.html
- Fn::FindInMap
- マッピングのキーに対応する値を返す
- 例、regionごとのAMIを定義
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html
- IAMロール
- InstanceProfile リソースは、IAM ロールの外側で指定
- Roles プロパティで対応するロール名を指定することによってそのロールを参照
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-deletionpolicy.html
- DeletionPolicy
- Retain
- スナップショット
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-waitcondition.html
- WaitCondition
- スタックの作成の外部での設定アクションを使ったスタックリソース作成を調整するため
- 設定プロセスのステータスを追跡するため
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/conditions-section-structure.html
- Conditions
- 例、本稼働用のスタックの場合に動作を変える
CloudHSM
http://docs.aws.amazon.com/cloudhsm/latest/userguide/generate_ssh_key.html
- CloudHSM
- 暗号化オペレーションを処理し、暗号化キーの安全なストレージを提供するコンピューティングデバイス
StorageGateway
DicrectConnect
AWS Fargateを触ってみた
Fargateとは、コンテナを扱う上で、サーバーやクラスタの管理が不要になるサービスです。
こちらを参考にチュートリアルを起動してみました。
www.ketancho.net
起動させたいコンテナイメージさえあれば簡単に動かせそうで、非常に興味深いサービスです。
メモ
- VPCについて
- ALBについて
- CloudFormationについて
- 参考 → AWS CloudFormationを使ってAWS Fargateの環境を作成してみる - Qiita
- 既存VPCを指定して作成可能
- Service設定でLaunchTypeをFARGATEに設定する
- AwsvpcConfiguration: Subnets: で既存のサブネットを設定する
Amazon API Gateway のリソースポリシーでアクセスコントロール
Amazon API Gateway のリソースポリシーでアクセスコントロールできるようになりました。
Amazon API Gateway が、API のリソースポリシーをサポート
公式サンプルではAWSアカウントのホワイトリスト、IP範囲のブラックリストがあります。
他にも時間やユーザーエージェント(UA)やユーザーIDなどのキーが用意されていて、各種設定を組み合わせたアクセスコントロールが簡単に設定できます。
AWS Conditions that can be used in API Gateway Resource Policies - Amazon API Gateway
以下、UAとIP範囲のアクセスコントロールを例にメモしておきます。
UAとIP範囲のAND条件によるアクセスコントロール
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "arn:aws:execute-api:ap-northeast-1:XXXXXXXXXXXX:yyyyyyyyyy/*/GET/", "Condition": { "StringLike": { "aws:UserAgent": "test" }, "IpAddress": { "aws:SourceIp": "ZZ.ZZ.ZZ.ZZ/ZZ" } } } ] }
UAとIP範囲のOR条件によるアクセスコントロール
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "arn:aws:execute-api:ap-northeast-1:XXXXXXXXXXXX:yyyyyyyyyy/*/GET/", "Condition": { "IpAddress": { "aws:SourceIp": "ZZ.ZZ.ZZ.ZZ/ZZ" } } }, { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "arn:aws:execute-api:ap-northeast-1:XXXXXXXXXXXX:yyyyyyyyyy/*/GET/", "Condition": { "StringLike": { "aws:UserAgent": "test" } } } ] }
AWS Well-Architected Lens – Serverless Applications まとめ コスト編
アーキテクチャを検討する上で、とても役に立つフレームワークであるAWS Well Archtected Framework。
サーバーレス版が公開されたのでベストプラクティスについてまとめておきます。
https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf
運用編、セキュリティ編、信頼性編、パフォーマンス編、コスト編の5回に分けてメモしていきます。
解釈が間違っているかもしれないので、ご注意ください。
SERVCOST 1:最適なラムダメモリ割り当てを決定するための戦略は何ですか?
SERVCOST 2:ラムダ関数のコードロギングの戦略は何ですか?
SERVCOST 3:複雑さを軽減するために必要なLambda関数を実行するコード・アーキテクチャーはありますか?
SERVCOST 4:できるだけ短い時間で実行するようにコードをどのように最適化していますか?
- 長時間Lambdaを実行する必要がある場合は、Lambda関数で実装する代わりにStep Functionsを使用して待機状態を実装する。
- データストアやその他のサービス/リソースへの接続を維持するためにグローバル変数を使用してコードを最適化すると、パフォーマンスが向上し、実行時間が短縮され、コストも削減される。
AWS Well-Architected Lens – Serverless Applications まとめ パフォーマンス編
アーキテクチャを検討する上で、とても役に立つフレームワークであるAWS Well Archtected Framework。
サーバーレス版が公開されたのでベストプラクティスについてまとめておきます。
https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf
運用編、セキュリティ編、信頼性編、パフォーマンス編、コスト編の5回に分けてメモしていきます。
解釈が間違っているかもしれないので、ご注意ください。
SERVPER 1:サーバレスアプリケーションで最適な容量単位(メモリ、シャード、1秒あたりの読み書き)をどのように選択しますか?
- Lambdaのデフォルトのメモリ設定とタイムアウト設定は、パフォーマンス、コストに望ましくない影響を及ぼす可能性がある。
- タイムアウトを平均実行時間よりもはるかに高く設定すると、コードが誤動作したときに長く実行される可能性があり、その結果、コストが高くなり同時実行数の限界に達する可能性がある。
- 一時的なネットワーキングの問題またはダウンストリームサービスの異常が発生した場合、サーバレスアプリケーションが実行を突然停止させる可能性がある。
- さらに重要なのはアップストリームサービスを考慮せずに、負荷テストを行わずにタイムアウトを設定し、いずれかのパーツがタイムアウトになるとエラーが発生する可能性がある。
SERVPER 2:サーバーレスアプリケーションのパフォーマンスをどのように最適化しましたか?
- サーバーレスのアーキテクチャーが成長するにつれ、さまざまなワークロード・プロファイルで共通に使用される特定のメカニズムが存在する。
- パフォーマンスを向上させるために、API Gatewayのキャッシュを有効にすることができる。
- 同様に、DAXを有効にすることで、読み取り応答を大幅に向上させ、グローバルおよびローカルセカンダリインデックスを改善して、DynamoDBフルスキャン操作を防止する。
- Lambda関数コード内のグローバルスコープを利用して、Lambdaコンテナを再利用することで、データベース接続とAWSサービスの初期接続と設定の処理に再利用される。
- Lambda関数は必ずしもVPCにデプロイする必要はない。
- CPUとネットワークの帯域幅は、Lambda機能用に設定されたメモリ設定に基づいて比例して割り当てられる。
- 必要に応じてVPCへのアクセスを設定する必要がある。VPCに関数をデプロイするとENIを作成する必要があるため起動時間が増える。
- Lamba機能がVPCとインターネットにアクセスする必要がある場合は、Lambdaからインターネット上で公開されているすべてのリソースへのトラフィックを許可するために、NATゲートウェイが必要です。
- 高い可用性とパフォーマンスを実現するために、複数のAZにNATゲートウェイを配置することをお勧めする。
SERVPER 4:パフォーマンスのためにラムダコードをどのように最適化していますか?
- Lambda関数は単一の目的で、可能な限り高速に実行されます。
- AWSでは、コンテナの再利用、ランタイムの展開パッケージサイズの最小化、依存関係の複雑さの最小化など、Lambda関数を使用する際のベストプラクティスに従います。
- この決定を下す際には、トレードオフが重要です。
- AWS Lambda 関数を使用する際のベストプラクティス - AWS Lambda
- VPCのLambda機能では、VPCのパブリックホスト名のDNS解決に数秒かかることがあるので避ける。リクエストに数秒の請求時間が追加される。
- たとえば、Lambda関数がVPC内のAmazon RDS DBインスタンスにアクセスする場合、nopublicly-accessibleオプションでインスタンスを起動します。
- VPC 内の Amazon RDS DB インスタンスの使用 - Amazon Relational Database Service
SERVPER 5:どのようにデータベース接続を初期化していますか?
- Lambda関数が実行された後、別のLambda関数呼び出しを予期してしばらくの間、ランタイムコンテナを維持します。
- グローバルスコープを活用する。
- たとえば、Lambda関数がデータベース接続を確立した場合、接続を再確立する代わりに、元の接続が後続の呼び出しで使用される。
- Lambda関数ハンドラコードの外側でデータベース接続やその他のオブジェクト/変数を宣言することで、関数が再度呼び出されたときに最適化される。
- コードにロジックを追加して、接続を作成する前に接続がすでに存在するかどうかを確認できる。
AWS Well-Architected Lens – Serverless Applications まとめ 信頼性編
アーキテクチャを検討する上で、とても役に立つフレームワークであるAWS Well Archtected Framework。
サーバーレス版が公開されたのでベストプラクティスについてまとめておきます。
https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf
運用編、セキュリティ編、信頼性編、パフォーマンス編、コスト編の5回に分けてメモしていきます。
解釈が間違っているかもしれないので、ご注意ください。
SERVREL 1:ピークワークロードのサーバレス制限を考慮しましたか?
- サービスの不正使用から守るために、デフォルトのサービス制限がある。
- 適切に制限を監視しないと、サービスの劣化または抑制をもたらす可能性がある。
- 多くの制限はソフトリミットであり、それを超える場合は上限緩和申請することができる。
- AWS Trusted Advisorを使用して、サービスが制限の80%を超えているかどうかを検出できる。
- また、ワークロードの超過が予測される場合は、事前に制限を引き上げることもできる。
- 制限を引き上げる場合は、スケール対応したりサービス不能攻撃を吸収するために、サービス制限と最大使用量との間に十分なギャップがあることを確認する。
- 関連するすべてのアカウントとリージョンでこれらの制限を考慮する必要がある。
- さらに、Lambdaの同時実行制限機能を使用して、ビジネスクリティカルなパスを分離し、予期しないイベントの負荷が他のリソースに影響しないようにする必要がある。
- プロファイル、脅威モデル、および組織構造によって、異なるアカウントのワークロードを分離することも推奨される。
- 同時実行数の管理 - AWS Lambda
- サーバレスアプリケーションがスパイクするかどうかに関わらず、非同期パターンに従って、サーバレスアプリケーションをより弾力性のあるアプリケーションに設計する。
SERVREL 2:サーバーレスアプリケーションへのアクセスレートをどのように規制していますか?
- リクエストの数が、バックエンドで処理できる処理数を超えると、サービスAPIが影響を受ける可能性がある。
- 契約プランによってアクセスパターンをコントロールするには、APIレベルでスロットリングを有効にする必要がある。
- API内の適切なHTTPステータスコード(スロットル用の429など)を返すことで、それに応じてリトライを行いスロットリングされたアクセスを処理するのに役立つ。
- より細かい制御は使用量プランとAPIキー発行で可能となる。疑わしいリクエストをしている場合、管理者が簡単にアクセスを切断することもできる。
- APIキーを取得する一般的な方法は、開発者ポータルを用意する方法です。これにより、サービスプロバイダとして、コンシューマとリクエストに関連付けられた追加のメタデータが提供される。
- アプリケーション、連絡先情報、ビジネスエリア/目的をキャプチャし、DynamoDBのようなデータストアに格納します。
- これにより、コンシューマーの追加検証とIDによるロギングのトレーサビリティが提供され、コンシューマーに変更のアップグレード/問題を連絡することができる。
SERVREL 3:サーバーレスのアーキテクチャー内での非同期呼び出しとイベントに関する戦略は何ですか?
- 非同期呼び出しは、HTTPレスポンスの待ち時間を短縮する。イベントドリブンアーキテクチャにより、非同期でコードを実行できるため、待ち時間が制限される。
- フロントエンドシステムは、全体の実行が完了するまでブロックするのではなく、最初のリクエストでジョブIDを受け取り、そのステータスをポーリングする。
- イベントループ、並行処理技術を使用してアプリケーションの一部を遅延ロードすることによって、フロントエンドをより効率的にすることができる。
- また、フロントエンドは、カスタムリトライとキャッシングによってより堅牢になるため、非同期呼び出しでは重要な要素になる。
- また、同期呼び出しが必要な場合は、実行全体がAPI Gatewayの最大タイムアウトを超えないようにし、その調整が外部サービス(AWSステップ関数など)によって行われていることを確認することをお勧めする。
- リクエストライフサイクルに沿って発生する可能性があります。
SERVREL 4:サーバーレスアプリケーションのテスト戦略は何ですか?
- テストは、通常、ユニットテスト、統合テスト、受入れテストによって行われる。堅牢なテスト戦略を開発することで、さまざまな負荷や状況下でサーバレスアプリケーションをエミュレートできる。
- 単体テストはサーバーレスではないアプリケーションと異なるものであってはならず、必要な変更を加えずにローカルで実行できる。
- 統合テストは、制御できないサービスを模倣すべきではありません。実稼働環境とまったく同じ環境を提供できるため、実際のサービスを使用する。
- 受け入れまたはエンドツーエンドテストは固有の推奨事項はありません。
- 一般に、AWS Marketplaceで利用可能なLAmbdaおよびサードパーティのツールは、パフォーマンステストのコンテキストでテストハーネスとして使用できる。
- パフォーマンステスト中の注意点を次に示す。
- 呼び出された最大メモリなどのメトリクスは、CloudWatchログで確認できる。メトリクスは、最適なメモリーと適切なタイムアウト値を示す場合がある。
- Lambda機能がVPC内で実行されている場合は、サブネット内の使用可能なIPアドレス空間に注意する。
- モジュール化されたコードをハンドラの外部にある別々の関数に作成することにより、より多くのユニットテスト可能な関数が可能になる。
- Lambda関数の静的コンストラクタ/初期化コード(つまり、グローバルスコープ、ハンドラの外側)で参照される外部化された接続(リレーショナルデータベースへの接続プールなど)を確立すると、Lambda実行の場合に外部接続のしきい値に到達しない環境が再利用される。
- それに応じてDynamoDBの読み書きテーブルのスループットを調整し、パフォーマンステストサイクル全体のスループットの変化に対応するように自動スケーリングを設定する。
SERVREL 5:サーバレスアプリケーションにどのように弾力性を持たせていますか?
- 変更が失敗した場合に以前のバージョンに戻すことができると、サービスの可用性が保証される。
- まず、監視メトリクスを配置する必要がある。環境負荷の「正常」状態を判断し、CloudWatchで適切なメトリクスとしきい値パラメータを定義して、「正常でない」状態を過去のデータに基づいて判断する。
- また、デプロイを監視し、自動化されたアクションを実装する。Lambda機能のバージョニングやAPIバージョンなどの機能を使用すると、デプロイが失敗した場合に以前の状態に戻すことができる。
- サーバーレスアプリケーションの特定の部分は、pub / subなどのパターンを使用して、イベント駆動型のさまざまなコンポーネントへの非同期呼び出しによって指定される。
- 非同期呼び出しに失敗した場合は、できるだけキャプチャしてリトライする必要がある。そうしないとデータが失われる可能性があり、ユーザーエクスペリエンスが低下する可能性がある。
- Lambda関数については、Lambdaクエリにリトライロジックを組み込んで、スパイキーなワークロードがバックエンドを圧倒しないようにする。
- また、Lambdaロギングライブラリを活用して、CloudWatchログにエラーを追加しカスタムメトリクスとして取得する。
- AWS SDKは、ほとんどの場合に、デフォルトでバックオフとリトライのメカニズムを提供している。しかし、ニーズに合わせて調整するべきです。
- AWS X-RayおよびサードパーティのAPM(Application Performance Monitoring)ソリューションを使用すると、分散トレースでスロットリングを識別したり、待ち時間にどのような影響が生じるのかを把握できる。
- 失敗する可能性のある非同期呼び出しの場合、個々のLambda関数に対してデッドレターキュー(DLQ)を有効にし、専用のDLQリソース(Amazon SNSとAmazon Simple Queue Service(Amazon SQS)を使用)を作成することをお勧めする。
- 可能な限り、Step Functionsを使用して、サーバーレス・アプリケーション内のカスタム試行/キャッチ、バックオフ、およびリトライの量を最小限に抑える必要がある。
- さらに、PutRecords(Kinesis)やBatchWriteItem(DynamoDB)などの操作では、部分的な障害が発生した場合でも正常に返されるので、常に応答を検査し、プログラムで対処する必要がある。
- トランザクションベースの同期処理の場合、Sagaパターンで説明されているように、アプリケーションのロジックを分離し単純化したStep Functionsを使用することによってロールバックを達成できる。