5時間で請求額95万円！？失敗から学ぶファイル転送基盤構築

5時間で請求額95万円!? 失敗から学ぶファイル転送基盤構築 2025年11月27日 株式会社エヌアイデイ ICTデザイン事業部ANA部第2課 S.N. (2年目※検証当時) ※「AWS」、「Amazon Web Services」および関連サービス名は、Amazon.com, Inc.またはその関連会社の商標です。 Copyright(c)2025 NID All Rights Reserved 1 1

参加メンバー&検証年月 ※いずれも検証当時 ICTデザイン事業部ANA部第2課 S.N. ICTデザイン事業部ANA部第2課 A.I. (2年目) (1年目) ※2024年8月～2025年2月検証実施 2 Copyright(c)2025 NID All Rights Reserved

目次 1.検証目的・内容 1-1.検証目的 1-2.検証結果 1-3.検証内容 2.デモンストレーション 3.発生した課題 3-1.ループ処理の発生 4.AWSサポートの活用 5.総括・学び 6.商標に関する注記 3 Copyright(c)2025 NID All Rights Reserved

1. 検証目的・内容 4 Copyright(c)2025 NID All Rights Reserved

1-1.検証目的 NIDの提案力向上 ・昨今、データ利活用と多様なシステム・サービス間連携が加速度的に進んでおり、ファイル転送中継環境の需要 が拡大している。 →アジリティおよびマルウェア感染などセキュリティ対策レベル向上、ならびに従量課金モデルの導入・マネージドサービ ス利用によるEOS対応費用削減に伴う投資コスト最適化の観点から、クラウドをHUBとするファイル転送中継環 境がマッチするユースケースが増えることが見込まれる。 →ファイル転送基盤という仕組みの特性から、いずれはエンタープライズ環境内で共用インフラ化する可能性があり、 類似のソリューションのニーズがあると想定される。 5 Copyright(c)2025 NID All Rights Reserved

1-2.検証結果 AWSマネージドサービスのみを使用したSFTP中継環境は、当初検討したアーキテクチャとは一部異なる結果となった ものの、EventBridgeやStepFunctions、Lambda等を連携することでNIDとして十分ソリューション提供可能か つ商用ベースに乗るサービスへ発展させることができる結果となった。 6 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるマルウェア対策、アクセス制御、アカウント制御の方式を確立する。 (a).GuardDutyのファイルチェックが、受信や振分け、コピー前などの時点で可能かを確認する。GuardDutyで チェック完了したファイルについてタグ付けできるかを確認する。 (b).EventBridgeでファイルのputを検知できるか確認する。その際、GuardDutyチェック完了後に付与されるタグ を処理起動トリガーとできるか確認する。 (c).ファイル転送ごとに作成するS3ディレクトリごとにEventBridgeで処理を振り分けることができるか確認する。 (不可の場合はLambdaを使用する) (d). EventBridgeでのファイル転送処理後、コピー元のファイルを次の転送に備えアーカイブできるか確認する。 ②EventBridgeで共有用S3から自社サーバに時刻指定してファイル転送できるかを確認する。 ③ AWS Transfer Familyがクライアントとしても使用可能か確認する。 (a).SFTP connectorsを使用してSFTPによるファイル転送が可能かを検証する。 (b).課金単位(ファイル転送の本数ごとの課金となるか、従量課金となるかなど)も確認する。 ④S3のコピーにより、他システムでのファイル読み取りができることを確認する。 (a).S3間のファイルコピーの際はS3 copyがよいか、S3 syncがよいか確認する。 (b).S3間のファイルコピー後、コピー元のファイルを次の転送に備えアーカイブできるか確認する。 7 Copyright(c)2025 NID All Rights Reserved

当初の構成案 Google Cloudに構 築 Region ① Virtual private cloud (VPC) Amazon Amazon GuardDuty CloudWatch Virtual private cloud (VPC) ① AWS Identity and Access Management (IAM) 同一リージョン内でVPCを分け てサーバを構築 Private subnet ③ ※トリガー： ファイル格納 マルウェア検知 Private subnet 他社SFTP クライアント Internet AWS Transfer Family (SFTP Server) Amazon EventBridge Amazon Simple Storage Service (Amazon S3) ※トリガー： ファイル格納 Amazon Simple Storage Service (Amazon S3) ② AWS Transfer Family(SFTP Client) ※トリガー： 指定時刻 ① Amazon Amazon Simple Amazon EventBridge Storage Service EventBridge (Amazon S3) ユーザごとにディレクトリを分けて転送 制御を行う ※番号は検証内容に該当する場所 自社サーバ ・ファイル転送ごとに転送制御を行う ・課金単位がユーザごとかインスタン スごとかを確認する 他AWSアカウント ④ S3バケット 共有用(他シス) 自社システム (AWSサービス) 別リージョンでサーバ構築 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する。 (a).GuardDutyのファイルチェックが、受信や振分け、コピー前などの時点で可能かを確認する。 GuardDutyで チェック完了したファイルについてタグ付けできるかを確認する。 ※番号は検証内容に該当する場所 9 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する。 (a).GuardDutyのファイルチェックが、受信や振分け、コピー前などの時点で可能かを確認する。 GuardDutyで チェック完了したファイルについてタグ付けできるかを確認する。 ⇒GuardDutyのファイルチェックはS3格納時にされることが分かった。また、チェック完了ファイルにタグを付与することが できた。 GuardDutyのマルウェアスキャン有効前に格納されていたファイルはスキャンされないこともわかった。 新規格納オブジェクト 既存オブジェクト 10 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する。 (b).EventBridgeでファイルのputを検知できるか確認する。その際、GuardDutyチェック後のタグを処理起動トリ ガーとできるか確認する。 ※番号は検証内容に該当する場所 11 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する。 (b).EventBridgeでファイルのputを検知できるか確認する。その際、GuardDutyチェック完了後に付与されるタグを 処理起動トリガーとできるか確認する。 ⇒S3のイベント通知機能を有効にすることで、EventBridgeでのファイルputが検知可能であった。 また、ファイルputだけでなく削除やタグの付与・削除も検知・トリガー対象とすることが可能であり、自由度の高さが 確認できた。 S3イベント通知設定画面 S3イベント通知設定画面 12 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する。 (b).EventBridgeでファイルのputを検知できるか確認する。その際、GuardDutyチェック完了後に付与されるタグを 処理起動トリガーとできるか確認する。 ⇒EventBridgeで検知するタグの値を指定することはできないため、GuardDutyのマルウェアスキャンで付与されたタグ をEventBridgeの処理トリガーとすることはできなかった。しかし、EventBridgeから通知を受け取り転送処理を行う レプリケーションルールにて転送対象とするタグの値を任意で指定できるため、EventBridgeでタグの値を指定できな くても問題ない。 レプリケーションルール概要 13 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する。 (c).ファイル転送ごとに作成するS3ディレクトリごとにEventBridgeで処理を振り分けることができるか確認する。 (不可の場合はLambdaを使用する) ※番号は検証内容に該当する場所 14 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する。 (c).ファイル転送ごとに作成するS3ディレクトリごとにEventBridgeで処理を振り分けることができるか確認する。 (不可の場合はLambdaを使用する) ⇒EventBridgeではファイル転送をすることができなかった。 指定できるターゲット(情報の送信先)にS3が指定できないため。 EventBridgeのターゲット指定画面 15 Copyright(c)2025 NID All Rights Reserved

補足:EventBridgeで設定できるターゲット ・API 送信先 ・API Gateway ・AWS AppSync ・バッチジョブのキュー ・CloudWatch ロググループ ・CodeBuild プロジェクト ・CodePipeline ・Amazon EBS CreateSnapshot API コール ・EC2 Image Builder ・EC2 RebootInstances API コール ・EC2 StopInstances API コール ・EC2 TerminateInstances API コール ・ECS タスク 別のアカウントまたはリージョンの イベントバス ・同じアカウントとリージョンのイベントバス ・Firehose 配信ストリーム ・Glue ワークフロー ・Incident Manager レスポンスプラン ・Inspector 評価テンプレート ・Kinesis ストリーミング ・Lambda 関数 (ASYNC) ・Amazon Redshift クラスターデータ API クエリ ・Amazon Redshift Serverless ワークグループデータ API クエリ ・SageMaker パイプライン ・Amazon SNS トピック(FIFO (先入れ先出し) トピックは 指定不可) ・Amazon SQS キュー ・Step Functions ステートマシン (ASYNC) ・Systems Manager Automation ・Systems Manager OpsItem ・Systems Manager Run Command 参考 https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-targets.html 16 Copyright(c)2025 NID All Rights Reserved

• https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-targets.html

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する。 (c).ファイル転送ごとに作成するS3ディレクトリごとにEventBridgeで処理を振り分けることができるか確認する。 (不可の場合はLambdaを使用する) ⇒StepFunctionsをEventBridgeのターゲットに指定可能だったため、S3のイベント通知をEventBridgeから StepFunctionsへ転送し、ステートマシン(ファイル転送処理であるバッチレプリケーションジョブを実行するワークフ ロー)を起動する方針に変更した。Lambdaのみを使用したファイル転送に比べ結合度が上がり、EventBridgeを 経由して他のマネージドサービスの同時実行などが可能となる(例：Amazon SNSを使用したメール送信)。 Amazon SNSを使用したメール送信 EventBridgeのターゲット指定画面 Amazon Simple Notification Service (Amazon SNS) Amazon Simple Storage Service (Amazon S3) Amazon Simple Storage Service (Amazon S3) Amazon EventBridge AWS Step Functions Amazon Simple Storage Service (Amazon S3) 17 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する。 (c).ファイル転送ごとに作成するS3ディレクトリごとにEventBridgeで処理を振り分けることができるか確認する。 (不可の場合はLambdaを使用する) ⇒レプリケーションルールを複数設定しておけば、 S3ディレクトリごとにファイル転送処理を分けることができた。 レプリケーションルール画面 18 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する。 (c).ファイル転送ごとに作成するS3ディレクトリごとにEventBridgeで処理を振り分けることができるか確認する。 (不可の場合はLambdaを使用する) ⇒S3の機能であるレプリケーションルールのみでもファイル転送は可能だが、詳細なログが残らないためファイルのput 処理と転送処理を明確に分けることは難しい。EventBridgeを経由すればログが残るため、処理が明確に分かれて いることを確認できる。 EventBridgeモニタリング画面 StepFunctionsのモニタリング画面 19 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する (d). EventBridgeでのファイル転送処理後、コピー元のファイルを次の転送に備えアーカイブできるか確認する。 ※番号は検証内容に該当する場所 20 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ①SFTPでの受信におけるアクセス制御、アカウント制御の方式を確立する (d). EventBridgeでのファイル転送処理後、コピー元のファイルを次の転送に備えアーカイブできるか確認する。 ⇒S3のレプリケーションルールを使用すれば、転送元のS3にもファイルが残ることが分かった。レプリケーションの処理とし ては、単純な転送ではなく複製したものを転送している(ファイルの同期)状態である。 転送元 転送先 21 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ②EventBridgeで共有用S3から自社サーバに時刻指定してファイル転送できるかを確認する ※番号は検証内容に該当する場所 22 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ②EventBridgeで共有用S3から自社サーバに時刻指定してファイル転送できるかを確認する ⇒EventBridge自体はファイル転送をすることができなかったが、スケジュール機能を使用すれば指定された時刻に 他のAWSマネージドサービスへ通知を実施することは可能であった。 EventBridgeでの時刻通知設定 時刻通知先の設定 23 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ②EventBridgeで共有用S3から自社サーバに時刻指定してファイル転送できるかを確認する ⇒上記を踏まえ、指定された時刻になったことをEventBridgeからLambdaへ通知し、Lambdaにてファイル転送を 実施する方式とした。 Lambda実行ログ 転送元バケットと転送先サーバの状態比較 24 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ③ AWS Transfer Familyがクライアントとしても使用可能か確認する。 (a).SFTP connectorsを使用してSFTPによるファイル転送が可能かを検証する。 ※番号は検証内容に該当する場所 25 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ③ AWS Transfer Familyがクライアントとしても使用可能か確認する。 (a).SFTP connectorsを使用してSFTPによるファイル転送が可能かを検証する。 ⇒現時点で SFTP コネクタを使用できるのは接続先の SFTP サーバーがインターネットからアクセス可能な場合のみと なっている。そのため、接続先の SFTP サーバーがプライベートサブネット上にあり、インターネットからアクセス不可の場 合はファイル転送できないとAWSサポートより回答あり。 AWSサポート回答 26 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ③ AWS Transfer Familyがクライアントとしても使用可能か確認する。 (a).SFTP connectorsを使用してSFTPによるファイル転送が可能かを検証する。 ⇒S3へのPutをトリガーとし、Lambdaで転送する方針に変更。 Lambda設定 転送成功 27 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ③ AWS Transfer Familyがクライアントとしても使用可能か確認する。 (a).SFTP connectorsを使用してSFTPによるファイル転送が可能かを検証する。 ⇒サポートに問い合わせたことで、機能要望として担当部署へフィードバックいただけた。 将来的に実装される可能性あり。 AWSサポート回答 28 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ③ AWS Transfer Familyがクライアントとしても使用可能か確認する。 (b).課金単位(ファイル転送の本数ごとの課金となるか、従量課金となるかなど)も確認する。 ※番号は検証内容に該当する場所 29 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ③ AWS Transfer Familyがクライアントとしても使用可能か確認する。 (b).課金単位(ファイル転送の本数ごとの課金となるか、従量課金となるかなど)も確認する。 ⇒サーバーエンドポイントで有効にされたプロトコル、SFTP、FTPSまたはFTPでアップロードおよびダウンロードされたデータ 量 (ギガバイト)、AS2経由で送受信されたメッセージ数、またはTransfer Familyワークフローを使用して処理された データの量に対し課金される。 ⇒SFTP コネクタを使用してリモート SFTP サーバーに接続する場合、コネクタ呼び出しの回数と送受信されたデータの量 に対し課金される。 ⇒Transfer Family ウェブアプリケーションを使用する場合は、ウェブアプリケーション単位に対し課金される。 参考 https://aws.amazon.com/jp/aws-transfer-family/pricing/ 30 Copyright(c)2025 NID All Rights Reserved

• https://aws.amazon.com/jp/aws-transfer-family/pricing/

参考:具体的な金額 SFTP、FTPS、または FTP エンドポイント サーバーエンドポイントで各プロトコルが有効になっている時間 データアップロード データダウンロード ・・・プロトコルあたり USD 0.30/時間 ・・・転送されたギガバイト (GB) あたり USD 0.04 ・・・USD 0.04/転送されたギガバイト (GB) AWS Transfer SFTP コネクタ コネクタコールあたりのコスト データ転送の GB あたりのコスト ・・・ USD 0.001 ・・・ USD 0.40/送受信したGB ウェブアプリケーション ウェブアプリケーションが有効になっている時間 ・・・ USD 0.50/時間/ユニット ※東京リージョンでの計算 参考 https://aws.amazon.com/jp/aws-transfer-family/pricing/ 31 Copyright(c)2025 NID All Rights Reserved

• https://aws.amazon.com/jp/aws-transfer-family/pricing/

1-3.検証内容 ④S3のコピーにより、他システムでのファイル読み取りができることを確認する。 (a).S3間のファイルコピーの際はS3 copyがよいか、S3 syncがよいか確認する。 ※番号は検証内容に該当する場所 32 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ④S3のコピーにより、他システムでのファイル読み取りができることを確認する。 (a).S3間のファイルコピーの際はS3 copyがよいか、S3 syncがよいか確認する。 ⇒結論としては、S3 copyを使用する方が適していると考える。 ⇒ copyはファイルをコピーするコマンド、syncはディレクトリの更新差分をコピーする(同期する)コマ ンドであるため、一括でファイルすべてをコピーするcopyの方が漏れが発生するリスクがないため。 ⇒コマンドのオプションは大半が同じだが、一部特有のオプションが存在するためケースによってcopyとsyncを使い分ける 必要はある。 33 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ④S3のコピーにより、他システムでのファイル読み取りができることを確認する。 (b).S3間のファイルコピー後、コピー元のファイルを次の転送に備えアーカイブできるか確認する。 ※番号は検証内容に該当する場所 34 Copyright(c)2025 NID All Rights Reserved

1-3.検証内容 ④S3のコピーにより、他システムでのファイル読み取りができることを確認する。 (b).S3間のファイルコピー後、コピー元のファイルを次の転送に備えアーカイブできるか確認する。 ⇒転送元のファイルをコピーするため、コマンド実施後もアーカイブ可能である。 35 Copyright(c)2025 NID All Rights Reserved

最終的な構成 EventBridgeだけでは細か い条件指定でのS3オブジェク トのレプリケーションを実現でき なかったため、 StepFunctionsを間に挟む アーキテクチャとした Region Google Cloudに構築 ① Amazon Amazon GuardDuty CloudWatch Virtual private cloud (VPC) マルウェア検知 Private subnet 他社SFTP クライアント Internet AWS Transfer Family (SFTP Server) ① ※トリガー： ファイル格納 AWS Identity and Access Management (IAM) ① Amazon Amazon AWS Simple EventBridge Step Storage Functions Service (Amazon S3) Private subnet ③ Amazon Simple Storage Service (Amazon S3) ② Amazon Amazon EventBridge Simple Storage Service (Amazon S3) ユーザごとにディレクトリを分けて転送 制御を行う ※番号は検証内容に該当する場所 Virtual private cloud (VPC) AWS Lambda ※トリガー： 指定時刻 AWS Lambda 同一リージョン内でVPCを分け てサーバを構築 自社サーバ AWS Transfer Family のSFTPクライアントである SFTP connectorsはプラ イベートIPアドレスを転送先 に設定できず、今回のアー 先に設定できず、今回の キテクチャでは採用できない アーキテクチャでは採用でき ことが判明したため、 ないことが判明したため、 Lambdaにて代替した 他AWSアカウント 別リージョンでサーバ構築 ④ S3バケット 共有用(他シス) 自社システム (AWSサービス) 36 Copyright(c)2025 NID All Rights Reserved

2. デモンストレーション 37 Copyright(c)2025 NID All Rights Reserved

最終的な構成 Google Cloudに構 築 Region Virtual private cloud (VPC) Amazon Amazon GuardDuty CloudWatch Virtual private cloud (VPC) AWS Identity and Access Management (IAM) Private subnet 同一リージョン内でVPCを分け てサーバを構築 マルウェア検知 Private subnet 他社SFTP クライアント Internet AWS Transfer Family (SFTP Server) ※トリガー： ファイル格納 Amazon Amazon AWS Simple EventBridge Step Storage Functions Service (Amazon S3) ユーザごとにディレクトリを分けて転送 制御を行う Amazon Simple Storage Service (Amazon S3) AWS Lambda Amazon Amazon EventBridge Simple Storage Service (Amazon S3) AWS Lambda 自社サーバ ※トリガー： 指定時刻 他AWSアカウント S3バケット 共有用(他シス) 別リージョンでサーバ構築 自社システム (AWSサービス) 38 Copyright(c)2025 NID All Rights Reserved

3. 発生した課題 39 Copyright(c)2025 NID All Rights Reserved

3-1.ループ処理の発生 ・概要 →2024年11月20日(水)14:00頃、ループ処理によりS3バッチオペレーションの ジョブが大量に作成される障害が発生 →品質問題としてNID品質管理部門へも報告！ ・原因 →設計ミス、および確認不足 →検証計画ミス、および内部連係ミス ・影響 →総作成ジョブ数:24,659件 →請求額：6,164.75(USD)≒約95万円 40 Copyright(c)2025 NID All Rights Reserved

3-1.ループ処理の発生 ・再発防止策 対策①-1：設計パラメータと設計意図をドキュメントにまとめ、会議など相互コミュニケーションがとれる環境にて 内部共有する。(設計時点)(担当・チームとしてのコミュニケーションスキル・意識観点) 対策①-2：内部共有された設計パラメータと設計意図に矛盾点がないかを確認する。(設計時点)(チームとし ての作業計画とチェック観点) 対策②-1：事前に検証作業開始・終了時間を決めておき、周知のため関係者を含めカレンダー登録を実施す る。(作業準備・開始時点)(担当・チームとしてのコミュニケーションスキル・意識観点) 対策②-2：作業計画を実施前に共有し、作業を実施しない者が問題点の有無を確認する。(作業準備・開 始時点)(チームとしての作業計画とチェック観点) 対策③-1：作業開始・終了の際にチャットやメールで周知を行う。作業終了後は30分以内に結果をまとめ、 作業関係者へ報告する。(作業実施・完了時点)(担当・チームとしてのコミュニケーションスキル・意 識観点) 対策③-2：作業終了30分以内に結果を確認する計画とする。想定通りでなかった場合は原因を分析・調査 し、作業の再計画を実施する。(作業実施・完了時点)(チームとしての作業計画とチェック観点) 41 Copyright(c)2025 NID All Rights Reserved

4.AWSサポートの活用 42 Copyright(c)2025 NID All Rights Reserved

4.AWSサポートの活用 ・活用の背景 →StepFunctionsでオブジェクトのレプリケーションを実装する際、基本的な設計では 新規オブジェクトしか転送できず、コードの作成が必要となった。 →公式ドキュメントを確認したところコード記載の凡例などが見つからなかったため、 AWSサポート(デベロッパープラン)を有効にし、問い合わせを行うこととした。 ・効果 →課題の早期解決を実現できた。 →現時点では実現不可能な部分も機能要望として担当部署へフィードバックされたため、 将来的にはAWSサービスとして改修される可能性がある。 43 Copyright(c)2025 NID All Rights Reserved

4.AWSサポートの活用 No. 問い合わせ内容 回答結果 解決方法 解決期 間 1 Step Functionsを使用したS3既存オブ ジェクトのレプリケーション方法 Step Functions のワークフローにて CreateJob APIを呼び出し、バッチレプリ ケーションジョブを作成する StepFunctionsのステートマシンに 2営業日 CreateJob APIを設定し、バッチオ ペレーションジョブを作成してS3に設 定したレプリケーションルールを起動 しレプリケーションする 2 Step FunctionsのCreateJob API に おいて、二回目以降に既存のジョブとは別 の新しいジョブを作成する方法 CreateJob API の ClientRequestToken パラメータに都度 異なる値を指定する ステートマシンのコードに 「ClientRequestToken.$」の値 に「$$.Execution.StartTime」と 記載する 2営業日 3 SFTPコネクタを使用した、インターネットを 経由しないEC2サーバへの接続方法 現時点で SFTP コネクタを使用できるのは Lambdaを使用した転送に方針転 接続先の SFTP サーバーがインターネットか 換 らアクセス可能な場合のみのため、不可。 1営業日 4 Step Functionsを使用したS3既存オブ ジェクトのレプリケーションができなくなった 設定されたクエリ言語がJSONataになって いるため、JSONPathに変更 1営業日 クエリ言語設定をJSONPathに変 更 44 Copyright(c)2025 NID All Rights Reserved

5. 総括・学び 6.商標に関する注記 45 Copyright(c)2025 NID All Rights Reserved

5. 総括・学び ・AWSでは様々なサービスを連携することで大きな価値を生み出せるため、お客様のニーズを正確に捉えた上で各 サービスの特徴を正しく理解しどう連携できるかを考えることができれば、お客様へよりよいソリューションを提案できる。 ・一つの構成が失敗したからといって要件が実現不可とあきらめるのではなく、他の代替手段を考案し、検証を繰り返し 実現しきることができて初めてエンジニアとしての提案力がつく。 ・技術・ソリューション検証の遂行においては検証・構築時の計画やステークホルダーとの調整、実施結果の周知と第 三者視点での確認が最も基本的だが重要である。 ・トラブル発生時は、速やかな報告や火消しのための協力要請が命運を分ける。 46 Copyright(c)2025 NID All Rights Reserved

6. 商標に関する注記 • 「AWS」、「Amazon Web Services」および関連サービス名は、Amazon.com, Inc.またはその関 連会社の商標です。 47 Copyright(c)2025 NID All Rights Reserved