「Bedrock AgentCore、ECS Fargate…AWS、次の一手は?」~【aws】人気記事TOP5(2025/09/28)
【2025/9/28】「Bedrock AgentCore、ECS Fargate…AWS、次の一手は?」人気記事TOP5(2025/09/28)
Spring Boot WebアプリをECS on Fargateにデプロイする際の注意点、およびecspressoいいよという話
Spring Boot WebアプリをECS on Fargateへデプロイする際の注意点とecspressoの活用について。ecspressoはECSのサービスとタスク定義をデプロイするツール。タスク定義では、コンテナのファイルシステム保護のためreadonlyRootFilesystem: trueを設定し、Tomcatの/tmp書き込み用にEphemeral Storageをマウント。Dockerfile作成時はベースイメージの脆弱性チェック、アプリ実行用ユーザーの作成、VOLUME設定と所有者変更を行う。Cloud Native Buildpacksでは同様の設定が難しいためDockerfileを使用。
AWSコスト見積もりエージェントを自作!Bedrock AgentCoreワークショップで学んだローカルからクラウドデプロイまで
Bedrock AgentCoreワークショップに参加し、AWSコスト見積もりエージェントを構築・デプロイした内容。AgentCoreはAIエージェントの本番運用に必要な機能(コンピューティング環境、デプロイ、認証、監視)をマネージドサービスとして提供し、開発者はビジネスロジックに集中できる。Strands Agents SDKを用いてエージェントを実装。Code Interpreterで安全なコード実行、Runtimeでクラウドデプロイ、Memoryで対話履歴の記憶・パーソナライズを実現。ローカル開発からクラウドデプロイへのスムーズな移行を体験し、AIエージェント開発のパラダイムシフトを実感した。
Bedrock AgentCore Runtime の CDK L1 Construct を試す
AWS CDK v2.217.0でBedrock AgentCore RuntimeのL1 Constructがリリースされたことを受け、CDKによるAgentのデプロイを試した記事。DockerImageAssetでコンテナイメージを構築し、必要なIAMロールを作成。CfnRuntimeでAgentCore Runtimeを定義し、CfnRuntimeEndpointで特定バージョンを指すエンドポイントを構築。これにより、IaCでのBedrock AgentCoreの管理が可能になった。L2 Constructの登場やAgentCore Gatewayのサポートにも期待が寄せられている。
CDKでaddToResourcePolicyを使ってDynamoDBにポリシー追加したのに反映されない!?
モリサワのデータ基盤移行検証で、CDKのaddToResourcePolicyによるDynamoDBへのリソースポリシー追加が反映されない問題が発生。原因はCDKのIssue。解決策として、addToResourcePolicyを使用せず、resourcePolicyプロパティに直接ポリシーを記述することで対応。ZeroETLに必要なDynamoDBのPITR設定とリソースポリシー設定を行う場合、CDKの挙動に注意が必要。
AWS Compute OptimizerがAurora I/O-Optimizedの推奨事項に対応したことで導入判断が容易になりました
AWS Compute OptimizerがAurora I/O-Optimizedの推奨に対応し、導入判断が容易になった。従来、手動でコスト計算が必要だったI/O-Optimizedの導入可否判断が、Compute Optimizerによって自動化された。実際に、Compute Optimizerの推奨によりI/O-Optimizedを導入した結果、I/Oコストが削減され、RDS全体のコストを大幅に削減できた事例が紹介されている。Auroraのコスト最適化を検討する際は、まずCompute Optimizerの推奨事項を確認することが推奨される。
【2025/9/21】「Lambda、Kubernetes、CloudFormation…AWS、使いこなせてる?」人気記事(2025/09/21)
「クラウドでIDEを動かしたかっただけなのに」AWSで22万円のクラウド破産した話
クラウドIDEを試した際、Jetbrains CodeCanvasでAWS上に構築されたKubernetes環境のEC2インスタンスを削除したと思い込んでいたが、Kubernetesの自動復旧機能によりインスタンスが再起動し続け、高額請求が発生。原因はCloudFormationのスタックを一括削除せず、個別にEC2インスタンスのみを削除したこと。対策として、CloudFormationスタックの個別削除と予算アラート設定が有効。AWSサポートへの連絡で請求額は減額された。結論:予算アラートは必ず設定すべき。
大してアクセスないサイトにECSはオーバースペック
低アクセスサイトではECSがオーバースペックであるとし、Lambdaとの料金比較を行っている。計算リソースのみの比較では、月間50万アクセスが損益分岐点。API Gatewayなどの付随コストを考慮すると70万アクセスとなる。キャッシュヒット率が高いほどLambdaの優位性は増す。ただし、Lambdaでのシステム構築は未知数な点も多く、モジュール分割やRDB利用などの課題がある。個人サービスでの検証が今後の課題。
うちの Step Functions、こうやって育ててます (実践 Tips 集)
ナレッジワークでのAWS Step Functionsの実践的な運用ノウハウを紹介。
- CDKによるインフラ定義、
- アプリコードとの同一リポジトリ管理、
- 多用途Lambda関数による関数数削減、
- Lambda関数バージョン固定によるデプロイ時のエラー回避、
- VariablesとJSONataによるワークフロー簡略化、
- State Machine Fragmentによる共通処理の再利用、
- 1要素Parallelによるコンソール表示の改善をTipsとして解説。
Step Functionsの保守性とスケーラビリティ向上に役立つ設計方針や、大規模AIワークフローでの活用例を紹介。
Kubernetes 1.33でStableになったサイドカーコンテナとは?
Kubernetes 1.33でサイドカーコンテナがStableになり、サイドカーパターンの実装が容易になりました。従来のPodにおける複数コンテナ実行では、起動・終了順序の制御やコンテナ生存期間の管理に課題がありましたが、サイドカーコンテナはinitコンテナの拡張としてrestartPolicy: Alwaysで実現し、StartupProbeで起動順序を制御します。これにより、メインコンテナとサイドカーコンテナの連携がスムーズになり、Pod削除時の挙動も改善されます。ただし、StartupProbeの設定やタイムアウトには注意が必要です。
CloudFront + Lambda Function URL + LWAでFlaskのレスポンスをストリーミング
CloudFront、Lambda Function URL、Lambda Web Adapterを活用し、FlaskでJSONレスポンスをストリーミング配信する構成を紹介。Lambdaの6MB上限を回避し、長時間処理の進捗や部分結果を逐次返却する。
CloudFront Functionでリクエスト元のドメインを付与、Lambda@EdgeでリクエストボディのSHA-256を計算。Lambda側はレスポンスストリーミングを有効化。
デプロイは、Lambda@EdgeとCloudFront + Function URLをそれぞれ行う。FlaskアプリはJSONを逐次yieldで返す。
【2025/9/14】「Bedrock活用、進んでる?サーバーレスでどこまでできる?」今週の人気記事TOP5(2025/09/14)
人間に優しくないjson形式の通知をBedrockで可読化する
AWSの監視サービス通知がJSON形式で読みにくいため、Bedrockで可読化する仕組みを構築。EventBridgeからSNS経由で送られるJSON通知を、Step FunctionsでBedrockを呼び出し、人が読みやすいHTML形式に変換してメール送信。Lambda関数は仲介役で、ロジックはStep Functionsに集約。JSONata式でプレースホルダーを利用し、プロンプトで出力形式を制御。結果、通知の読みやすさ、重要度の把握、サマリー生成が向上し、保守性も向上した。生成AIによる業務効率化の好例。
AWSによるマイクロサービスの基本アーキテクチャ
AWSのサーバーレス環境でBtoB向け課題管理アプリケーションのマイクロサービスアーキテクチャを設計。認証、ユーザー管理、課題管理、通知の各サービスを構築し、EventBridgeでサービス間連携。認証サービスはOIDCトークンを発行し、各BFFと連携。EventBridgeのカスタムイベントバスでイベントを公開・購読し、障害時の影響範囲を限定。バックエンドはAPI Gatewayを介し、サーバーレスサービスとDBを柔軟に選択。高負荷やセキュリティ要件に応じて構成変更を検討。
minimoでのLLMを使った掲載審査の裏側
MIXIのサロン予約サービス「minimo」で、掲載審査にLLMを活用した「かんたんAIチェック」を導入。AWS Bedrock上のClaude 3.5 Sonnetを使用し、審査時間を短縮、CSのコスト削減に成功。プロンプトには思考出力や多数決の要素を取り入れ精度向上。エンジニア以外もプロンプト開発に貢献。導入後、審査時間が6%短縮、CSを介さない審査取り下げが9%発生。課題はBedrockのリクエスト数制限。
Vercelデプロイの内部構造
Vercelのデプロイは、GitHubへのpushをトリガーに、AWSのS3、Lambda、SQS、Fargateなどを活用した分散システムで実現されています。
ソースコードはS3に一時保管され、Lambdaで認証や設定ファイルの検証、リソース制限の確認が行われた後、SQSでビルドがスケジューリングされます。
Fargate上のビルドコンテナでビルドされ、成果物はLambda(サーバーレス関数)、Vercel Edge Network(Edge Functions)、S3(静的ファイル)にプロビジョニングされます。
Vercelの中核技術は、ビルド成果物を適切な実行環境へ自動配置するプロビジョニング機能です。
【アップデート】CloudFrontの署名付きURLでECDSA鍵を利用可能に!──実測で91%高速化、55%のURL短縮効果
CloudFrontの署名付きURLでECDSAがサポートされ、RSAと比較して平均91%の高速化と55%のURL短縮を実現。
検証では、ECDSAキーペアを生成し、CloudFrontへ登録・設定。AWS CLIの制限を回避するためPythonで署名付きURL生成プログラムを実装。性能測定の結果、ECDSAはRSAより高速でURLも短く、高頻度なURL生成やリソース制約のある環境で特に有効。
【2025/9/7】「コスト削減、Lambda、AI…AWS、次の一手は?」今週の人気記事TOP5(2025/09/07)
Terraform で AWS Lambda をデプロイしようとする際にぶつかる現実
TerraformでLambda関数をデプロイする際、terraform applyだけでは完結せず、ビルドとZIP化を別途行う必要がある。local-execは一時的な回避策であり、HCP Terraformとの相性も良くない。解決策として、TerraformでLambdaの設定を管理し、CI/CD環境でビルド・ZIP化・デプロイを行う方法が推奨される。aws-actions/aws-lambda-deploy等のツールも利用可能。この構成により、設定変更とコード変更のライフサイクルを分離できる。
Amazon S3 の月額コストを約30%削減したアプローチ
ナウキャストでは、AWS S3の月額コストが課題でしたが、Cost ExplorerとStorage Lensで現状を把握し、以下の3つのアプローチで約30%の削減に成功しました。
- 不要データの削除: S3 Lifecycle PolicyでNoncurrent version bytesやIncomplete multipart upload bytesを削除。
- 利用状況の分析: S3 Access LogsとAthenaを活用し、アクセスされていないデータを特定・削除またはGlacierへ移行。
- アーキテクチャの見直し: 顧客ごとにS3バケットを作成する構成から、共通バケットを利用する構成に変更し、データの重複を解消。
AWSの月額通信量が2倍以上!? —— AWS Batchの隠れたコストの正体とは
RemitAidでAWS Batchを利用した際、月額通信量が想定の2倍以上になる事象が発生。原因は、Batchジョブ起動時のECRからのコンテナイメージ(35-40MB)ダウンロードによるNAT Gateway経由の通信だった。対策として、セキュリティ上問題ないバッチをpublic subnetへ移設し、FargateにPublic IPを割り当てることで解決。AWS Batch利用時は、特にprivate subnet環境において、コンテナイメージのダウンロードコストに注意が必要。
【初心者向け】Amazon Q Developer 入門!完全ガイド
Amazon Q Developerは、AWS環境における開発・運用を支援するAIアシスタントです。チャット、コード補完、変換、テスト生成、レビュー、ドキュメント生成などの機能を提供し、VS CodeやAWS CLIから利用可能です。料金体系は無料枠とPro版があり、Pro版では制限が解除されます。
日本語対応も開始され、Microsoft Teams、Slack、GitHub、GitLabとの連携も可能です。
カスタムエージェントの作成機能も追加され、特定のユースケースに合わせたAIアシスタントを構築できます。安全に利用するためのオプトアウト設定も重要です。
AWS Lambda×DuckDB×PyIcebergで実現する動的ルーティング軽量ETLの実装
AWS Lambda、DuckDB、PyIcebergを用いた動的ルーティングETLの実装を紹介。S3にPUTされたファイルをトリガーにLambdaが起動し、S3パスからDynamoDBを参照してIcebergテーブルへの書き込み先とSQLを動的に決定。DuckDBでデータ処理後、PyIcebergでIcebergテーブルに追記する。バケット名またはフォルダ名をベースにしたルーティングが可能。これにより、ソース追加時のコード変更が不要になり、保守性が向上。ただし、DynamoDBがボトルネックになる可能性や、処理の複雑さに制限がある点に注意。
Discussion