LASSIC Media らしくメディア
Step Functions/SQS/SNSのコスト最適化を外注で進める方法
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Step Functionsはワークフロー種別（Standard/Express）の選択がコスト削減の起点になります
- SQS/SNSはロングポーリングとバッチ処理でAPIリクエスト数を大幅に抑えられます
- 最適化の検討・実装を外注する際に確認すべき委託先の要件と進め方を整理します
目次
Step Functions/SQS/SNSのコスト課題とは
Step Functions/SQS/SNSのコスト最適化とは、AWS上のワークフロー管理（Step Functions）・メッセージキュー（Amazon SQS）・Pub-Sub通知（Amazon SNS）固有の課金構造を把握し、不要なリクエスト・状態遷移・メッセージ配信を削減して支出を合理化する取り組みを指します。
クラウド利用費が月を追うごとに増加するなか、Step Functions・SQS・SNSは「使えば使うほど課金が積み上がる」構造をそれぞれ持っています。
Step Functionsは状態遷移ごとに費用が発生するため、リトライ処理やループを含むワークフローは遷移数が想定を超えやすい特徴があります。SQSとSNSはAPIリクエスト数に応じた課金で、ポーリング頻度やメッセージ送受信の設計次第でリクエスト数が大きく変わります。
これらのサービス固有のコスト構造は、EC2やLambdaのコスト削減とは異なる専門知識を要します。Lambda単独のサーバーレス最適化（）とは切り分けて、本記事ではStep Functions・SQS・SNSのワークフロー・キュー・Pub-Subに特化した削減手法を解説します。
Step Functionsの課金構造とStandard/Express選択
Standardワークフローの課金：状態遷移数に注意
Standardワークフロー（標準ワークフロー）は、状態遷移1回につき$0.000025（米国東部リージョン）で課金されます*1。毎月4,000回の状態遷移が無料枠として利用できます。
注意すべきは、リトライ処理もループも、1回の遷移として積み上がる点です。たとえば外部APIへの3回リトライが含まれるワークフローを1,000回実行すると、成功時の遷移に加えてリトライ分の遷移がそのまま課金対象になります。
実行時間は1年間まで保持でき、長時間の人間承認フロー（Human in the loop）や非同期バッチ処理に向いています。処理の信頼性が高く、実行履歴を90日間参照できるため、ビジネスクリティカルなワークフローでよく選択されます。
Expressワークフローの課金：短時間・大量実行に有利
Expressワークフローは、リクエスト数（100万回あたり$1.00）と実行時間×メモリ（GB-秒あたり$0.00001667）の組み合わせで課金されます*1。実行時間が5分以内という制限がありますが、高スループットかつ短時間のワークフローではStandardより費用を抑えられます。
IoTデータ取り込みやストリーミングイベント処理のように、1日に数十万回以上実行されるワークフローでは、遷移数課金のStandardより実行時間課金のExpressの方が費用効率が高くなります。どちらが有利かはワークフローの遷移数・実行時間・実行頻度の3変数から見積もることが大切です。
ペイロードをS3に退避してサイズ制限を回避する
Step Functionsは入力・出力・状態データに256KiBの上限があります*2。このサイズを超えるとエラーになるため、大きなデータをワークフロー内で直接受け渡しすることはできません。
対処法として、大きなデータはS3に格納してS3オブジェクトのARN（リソース識別子）をワークフローに渡すパターンが広く使われています。ワークフロー内ではARNのみを扱うため、状態遷移のペイロードサイズを最小化でき、コストと信頼性を両立できます。このパターンはS3の標準的な利用コストが発生しますが、Step Functions側のエラーと再実行コストを避けられます。
| 比較項目 | Standard（標準）ワークフロー | Express（高速）ワークフロー |
|---|---|---|
| 課金単位 | 状態遷移1回あたり$0.000025 | リクエスト数＋実行時間×メモリ |
| 無料枠 | 月4,000状態遷移 | なし（リクエスト・期間ともに発生） |
| 実行時間上限 | 1年 | 5分 |
| 向いているユースケース | 長時間・人間承認フロー・ビジネスクリティカル | 高スループット・イベント処理・IoTデータ取り込み |
| 実行履歴 | Step Functions コンソールで参照可 | CloudWatch Logsで参照（別途ログ費用） |
| コスト削減のポイント | リトライ設計の最適化・不要遷移の削減 | 実行時間の短縮・ペイロードのS3退避 |
SQS/SNSのコスト削減手法
ロングポーリングで空リクエストを削減する
Amazon SQS（Simple Queue Service）はAPIリクエスト数で課金され、64KBのチャンクごとに1リクエストとして計算されます。ショートポーリング（デフォルト設定）は、メッセージがなくても即座にレスポンスを返すため、空のレスポンスに対してもリクエスト費用が発生します。
ロングポーリングを有効にすると、接続を20秒まで保持してメッセージを待ちます。空のポーリングが減るため、APIリクエスト数を削減できます*3。設定は受信待機時間（WaitTimeSeconds）を1〜20秒の範囲で指定するだけで適用できます。
SendMessageBatchでリクエスト数を集約する
SQSにはバッチ送受信APIが用意されています。SendMessageBatch APIを使うと、1回のAPIリクエストで10件のメッセージをまとめて送信できます。個別送信と比較してリクエスト数を10分の1程度に抑えられます。
受信側もReceiveMessage APIのMaxNumberOfMessagesパラメータを10に設定することで、1回の受信で複数メッセージを取得できます。送受信を個別処理から一括処理に切り替えるだけで、アーキテクチャを大きく変えずにリクエスト費用を削減できます。
不要なトピック・サブスクリプションを整理する
Amazon SNS（Simple Notification Service）は、メッセージ発行のAPIリクエスト数と配信先へのメッセージ数に応じて課金されます。使われていないトピックやサブスクリプションが残っていると、誤送信による不要な配信コストが発生します。
定期的にSNSコンソールやAWS CLIでトピック一覧とサブスクリプション一覧を確認し、未使用のものを削除することがコスト管理の基本です。特にテスト用トピックが本番環境に残ったままになっているケースは見落とされやすい盲点です。
メッセージ集約でリクエスト数を減らす
細粒度のイベントを1件ずつSNSに発行しているシステムでは、メッセージを集約してから発行する設計変更が有効です。たとえば100件の個別変更イベントを1つのサマリーメッセージにまとめると、発行リクエスト数を削減できます。
この設計変更は、受信側のコンシューマー処理も影響するため、SQS/SNSだけでなくシステム全体のアーキテクチャ見直しを伴います。外注で対応する場合は、現行の処理フローを正確に把握した上で変更範囲を設計することが重要です。
内製で最適化を進める際のリスクと工数
必要な専門知識と内製のリスク
Step Functions・SQS・SNSのコスト最適化を内製で進めるには、AWS料金モデルの把握だけでなく、CloudWatch メトリクスによる現状分析・ステートマシン定義の見直し・アプリケーションコードのSQS API呼び出し変更・SNSトピック設計の見直しまで、複数の専門領域の知識が必要です。
特にStandard→Expressの移行は、実行時間・エラーハンドリング・ログ取得方式がすべて変わるため、移行後の動作検証が不十分だと本番障害に直結します。ワークフロータイプの変更を誤ると、5分を超える処理がタイムアウトで失敗し続けるリスクがあります。
内製対応に必要な工数の目安
現状分析からパラメータ変更・動作確認までを内製で行う場合、エンジニア2〜3名が数週間規模の稼働を要するケースが一般的です（自社の規模・構成により異なります）。コスト分析スキルを持つAWSエンジニアが不在の場合、分析フェーズだけで時間を消費する可能性があります。
また、既存の運用・開発タスクを抱えながら並行して最適化を進めると、本来業務への影響が出やすい点も考慮が必要です。「最適化で削減できる費用」と「内製作業の人件費」のバランスを事前に試算することが大切です。
外注で最適化を進める手順とチェックポイント
ステップ1：現状コストの可視化と目標設定
外注を開始する前に、現行のStep Functions・SQS・SNS費用をAWS Cost Explorer（クラウド費用の可視化・分析ツール）とCloudWatchメトリクスで整理します。サービスごとの月次費用・状態遷移数・リクエスト数・メッセージ数の実績データを委託先に提供することで、診断の精度が上がります。
削減目標は「費用を◯%削減」という数値で設定するより、「Expressワークフロー移行可否の診断」「ロングポーリング適用後のリクエスト数試算」など作業単位で定義する方が成果の検証がしやすくなります。
ステップ2：現状診断と最適化計画の立案
委託先が現状診断を行い、Standard/Expressの適合性・ペイロードサイズの実態・SQSポーリング設定・SNSトピック構成を確認します。診断結果をもとに、変更内容・実装工数・想定削減効果を記載した最適化計画書を作成してもらいましょう。
計画書には「変更するパラメータ」「変更後の動作検証方法」「ロールバック手順」を含めるよう要件として伝えることが大切です。計画段階で変更範囲を明確にすることで、実装フェーズでの手戻りを防げます。
ステップ3：実装・動作確認・モニタリング設定
計画に基づいて実装を進めます。ワークフロータイプ変更のように影響範囲が広い作業は、ステージング環境での動作確認を必須とする旨を契約に含めることが重要です。
実装完了後は、CloudWatchアラームやAWS Budgetsを使ったコスト監視設定まで委託先に依頼すると、最適化効果の継続的なモニタリングが可能になります。最適化後に利用パターンが変化してコストが再び増加するケースもあるため、定期的なレビュー体制を組み込むことをおすすめします。
外注先の選び方と評価軸
AWS Step Functions/SQS/SNS固有の実績確認
クラウドコスト最適化の委託先を選ぶ際は、AWSコスト削減の実績（）に加えて、Step Functions・SQS・SNSを対象とした作業経験を持つかどうかを確認します。Lambda・EC2のコスト削減とは異なる知識が必要なため、実績の内容を具体的に聞くことが大切です。
「どのサービスのコスト削減を実施したか」「Standard/Expressの移行経験があるか」「SQSのロングポーリング適用事例があるか」という質問で、実務経験の深さを確認できます。
契約形態と作業範囲の明確化
コスト最適化の外注は、診断フェーズと実装フェーズを分けて発注する方法が一般的です。診断だけを固定費用で委託し、実装の要否を判断した上で追加発注するステップが、発注側のリスクを抑えやすい進め方です。
作業範囲には「診断対象のサービス・リージョン・アカウント」「変更実施の可否決定者（承認フロー）」「実装後の動作確認基準」を明記します。曖昧な範囲設定は、実装中に追加作業が発生する原因になります。
元請（プライムベンダー）への委託で窓口を一本化する
Step Functions・SQS・SNSのコスト最適化は、アプリケーションレイヤーの変更を伴うことが多く、インフラとアプリ両側の知識を持つ委託先に依頼することが望ましいです。元請（プライムベンダー）として受託する会社に一本化すると、インフラ変更とアプリ改修の調整コストを削減できます。
複数の専門会社に分散して委託すると、変更による影響範囲の調整や動作確認の責任所在が不明確になりやすい点に注意が必要です。
まとめ：3つの最適化起点と外注判断基準
本稿では、Step Functions・SQS・SNSのコスト構造と最適化手法、外注で進める際の手順を整理しました。要点を3つにまとめると次の通りです。
第一に、Step FunctionsはStandard/Expressのワークフロー種別選択がコスト削減の出発点です。遷移数・実行時間・スループットの3変数で比較し、適切なタイプを選ぶことが肝心です。第二に、SQS/SNSはロングポーリングの有効化・バッチAPIの活用・不要トピック削除といった設定変更で、コードを大きく変えずにリクエスト費用を抑えられます。第三に、外注で進める際は診断と実装を分けた発注と、元請（プライムベンダー）への一本化が作業品質とリスク管理の両立につながります。
よくある質問
Step FunctionsのStandardとExpressはどちらが費用を抑えられますか。
どちらが有利かはワークフローの性質によって異なります。実行時間が5分以内で1日に数万回以上実行される高頻度・短時間のワークフローはExpressが有利なケースが多く、長時間実行や遷移数が少ないワークフローはStandardが費用を抑えやすいです。AWS公式の料金計算ツールで実際の遷移数・実行時間・頻度を入力して試算することをおすすめします*1。
SQSのロングポーリングはどのように設定しますか。
SQSキューの「受信待機時間（WaitTimeSeconds）」を1〜20秒に設定することで有効になります。AWSマネジメントコンソールのSQSキュー設定画面から変更できます。ReceiveMessage APIをコード内で直接呼び出している場合は、WaitTimeSecondsパラメータをリクエストに追加してください*3。設定変更だけで完了するため、アーキテクチャの変更は不要です。
Step Functionsの256KiB制限を超えるデータはどう扱えばよいですか。
256KiBを超えるデータはS3バケットに格納し、そのオブジェクトのS3 ARN（リソース識別子）をワークフローの入出力に渡す設計にします*2。ワークフロー内ではARNのみを受け渡すため、ペイロードサイズを最小化でき、制限超過によるエラーを避けられます。タスク内でS3からデータを取得・加工・書き戻す処理をLambdaに実装するパターンが広く使われています。
SNSのコスト削減で最初に着手すべき箇所はどこですか。
まず使われていないトピックとサブスクリプションの棚卸しから始めることをおすすめします。不要なトピックが残っているとテストや誤操作による発行費用が発生します。次に、細粒度のイベントを個別発行している箇所をメッセージ集約に変更することで、発行リクエスト数を削減できます。変更前にCloudWatch Logs Insightsで発行頻度の高いトピックを特定すると優先順位をつけやすくなります。
コスト最適化の外注にかかる費用の目安はどのくらいですか。
費用はシステムの規模・対象サービス数・変更の複雑さによって大きく異なります。診断フェーズ単独であれば数十万円台から対応している委託先もありますが、実装・動作確認・モニタリング設定まで含めると規模によって費用が変わります。具体的な金額は委託先に要件を提示した上で見積もりを依頼することが確実です。診断と実装を分けて発注することで、初期投資を抑えながら着手できます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：AWS「AWS Step Functions 料金」（2025年）
- *2 出典：AWS「AWS Step Functions のクォータ」（2025年）
- *3 出典：AWS「Amazon SQS 料金」（2025年）
