【aws トピック】今週の人気記事TOP5！（2025/3/16 更新）

この記事はZennからawsのLike数が多い記事のリストを自動的取得し、AIを利用して要約し、自動更新されています。

【2025/3/16】集計 新着週間Like数 ランキング Top5

AWS設計プロンプト

AIプロンプトを用いたAWSアーキテクチャ設計の効率化に関する記事です。 AIプロンプトは、構造化された出力フォーマット、具体的なパラメータ要求、選定理由の明確化、代替案との比較、Well-Architected Frameworkの原則適用を重視します。これにより、実装可能な詳細なAWS設計書（各セクション500-800単語）を効率的に生成し、設計者の専門知識と時間を最大限に活用できます。出力はエグゼクティブサマリー、アーキテクチャ概要、AWSサービス選定詳細（コンピューティング、ネットワーク、ストレージ、データベース、アプリケーションサービス、開発者ツール）、セキュリティ、高可用性・DR、スケーラビリティ、パフォーマンス最適化、コスト最適化、運用、デプロイメント戦略、移行計画、IaCコード例、ベストプラクティス適用、リスクと対策から構成されます。

Amazon Q for command lineのAIエージェント機能が便利

Amazon Q for command lineにAIエージェント機能が追加された。 Claude 3.7を用いた日本語対応も可能で、S3にアップロードされたWAVファイルをMediaConvertでMP3に変換するLambda関数のコードを生成、ファイルへの書き込みまで自動で行うことを実証。 Homebrewでインストール後、AWS Builder IDを取得し、q chatコマンドで対話可能。 zshのファジー補完機能なども備え、非常に便利である。

アプリケーションの認可をシンプルに

複雑化するアプリケーション認可ルールを解決する手段として、AWSのAmazon Verified Permissionsを紹介。RBAC、ABAC、ReBACを組み合わせたきめ細やかなアクセス制御とポリシーの一元管理を実現し、保守性を向上、スケーラビリティにも優れる。Cedarポリシー言語を採用し、記述・テストが容易。ただし、AWS依存、従量課金、Cedar学習コストといった課題も存在する。マイクロサービスやマルチテナント環境で有効だが、導入前にコストとAWS依存度を考慮すべき。

AWS Community Builderに選出されました🎉

ココナラHead of Informationのyuta_k0911氏がAWS Community Builderに選出された。DevOpsDays Tokyo 2024やCloud Security Day 2024への登壇経験が評価された。今後はAWS関連の技術広報活動を継続し、3月には3回のイベント登壇を予定している。 選出は技術貢献への大きな励みとなり、更なるアウトプット強化につながる。

データ連携システム「連携くん」のアーキテクチャについて解説

「連携くん」は、歯科医院のレセコンデータと歯科技工システム「技工くん」のデータ連携を実現するシステム。Windowsデスクトップアプリ（C#/.NET）でレセコンデータを取得し、API Gateway、AWS Lambda、RDS Proxyなどを用いたサーバーレスアーキテクチャで「技工くん」に送信する。3省2ガイドライン準拠のためmTLSを採用し、AWS Private CAとAWS CMで証明書管理を行う。AWS WorkSpacesを用いた開発環境構築によりコスト削減を実現した。

【2025/3/9】集計 新着週間Like数 ランキング Top5

SOC2 Type2取得のためのAWS設計・運用

スマートラウンド社はAWS上で稼働するプロダクト「smartround」でSOC2 Type2認証を取得。Security Hub基準準拠、GuardDutyによる脅威検知と対応、Inspectorによる脆弱性管理、IAMの厳格な管理、承認プロセス導入、定期レビュー、AWSをサードパーティとしてリスク管理、可用性監視、バックアップリストアテスト、インシデント対応・災害対策・事業継続計画の策定と訓練を実施した。これらの取り組みを通じて、インフラ面におけるSOC2 Type2要件への準拠を達成した。ただし、SOC2認証はAWSのみならず、組織全体のセキュリティ体制が重要である点に留意すべき。

40代後半のおじさんが AWS Community Builders になってみた

40代後半でAWS未経験から1年半でAWS Community Buildersに選出された事例。2022年7月からAWS学習開始、資格取得、案件対応を経て、JAWS-UG等で積極的に登壇(11回)・ブログ投稿(9本)を実施。データ利活用に焦点を当て、Dataカテゴリーで応募し選出された。 遅く始めることへの不安を払拭し、熱意と継続的な活動が成功要因と結論づけている。

Bedrock EngineerでAWS構成図生成してみた

AWS Bedrockを利用したソフトウェア開発エージェントアプリ「Bedrock Engineer」を用いてAWS構成図の自動生成を試行した結果、ALB、ECS、Aurora Postgres等で構成される比較的複雑なアプリケーションの構成図もテキスト指示から高い精度で生成できることを確認。 CLIによるリソース情報収集・描画機能も開発中であり、AWS構成図作成支援ツールとして有効と結論づけた。 Claude 3.5 Sonnet LLMを使用。

AWS Community Buildersに選ばれるまでにやったことと、これからやりたいこと

AWS Community Builder（データカテゴリ）に選出された筆者は、ZennでのAWS関連技術記事執筆（特にデータエンジニアリング関連7件）、Redditへの投稿、ローカル勉強会開催、SNS発信を主な活動としていた。登壇経験はなく、選出は継続的な発信によるものと考察。今後は技術記事執筆継続、登壇挑戦、AWS関連表彰への応募を予定している。 選出への鍵は「AWSへの興味」と「自身の考えの発信」だと結論づけている。

AWS WAF最適化: ルールグループ全体への例外処理をルールグループ内の特定ルールに絞り込んだ例外処理に移行する話

AWS WAFで、特定パスへの例外処理をマネージドルールグループ全体への適用から、特定ルールへの適用に移行する際に課題が発生。全体適用では、例外パスがどのルールにヒットするかログに記録されず、移行が困難になる。解決策として、一時的に全てのルールに例外処理を適用し、ログを記録することで、どのルールが該当パスを検知するかを特定。その結果に基づき、安全に移行完了。 最初から特定ルールへの例外処理を適用すべきだが、既存システムは全てルールへの例外処理を適用することでログを確保し移行を実現した。

【2025/3/2】集計 新着週間Like数 ランキング Top5

Amplify Hostingの中身が気になってS3+Cloudfront+CodeBuildで静的ホスティングをした

本記事は、Amplify Hostingに代わるNext.jsアプリの静的ホスティングをS3+Cloudfront+CodeBuildで構築した過程を記述。S3はストレージ、CloudfrontはCDNとして利用し、CodeBuildで自動デプロイを実現。 ACL無効化、パブリックアクセスブロック、OAC設定などセキュリティ面にも配慮。 環境変数はSSM Parameter Storeで管理。Amplify Hosting利用の方が容易だが、AWSインフラ構築の学習には有効な例となっている。 コストは月数百円程度と推定。

ECS Fargate上のアプリケーションへのDatadog APM導入

この記事は、AWS ECS Fargate上で動作するJava/KotlinアプリケーションにDatadog APMを導入する手順を解説しています。Datadog Agentコンテナをサイドカーとして追加し、Java AgentとしてDatadog Java Tracerを起動することで、アプリケーションのパフォーマンス監視を実現します。Kotlin Coroutineのトレース設定や、GitHub連携によるソースコード表示、Nginxメトリクス取得などの方法も紹介。 DD_で始まる環境変数による設定や、Agentコンテナの自動再起動、ECRプルスルーキャッシュの活用によるコスト削減策も示されています。FargateでのAPM費用は、EC2と比べて大幅に安価であると結論づけています。

DEF CON 29 で発表された「Alexandre Sieira - Attack Vectors for APIs w AWS API

AWS API GatewayとLambda AuthorizerにおけるIAMポリシーの設定ミス、特にワイルドカード(*)の誤用が、意図しないAPIへのアクセス許可につながる脆弱性を解説。ワイルドカードはパス区切り(/)を超えてマッチングするため、*/product/* のような記述は、/admin/product/*にもマッチする。対策として、ワイルドカードの使用をパス末尾に限定、明示的なDenyポリシーの導入、多層防御による認可チェック強化が提示されている。 IAMポリシーの設計には細心の注意が必要。

CloudWatchメトリクスで31日分のデータを"ちゃんと"取得したい

CloudWatchメトリクスで31日分の正確なデータを取得するには、デフォルトの30日間集計ではなく、「統計:合計」「期間:1日」でCSVをエクスポートし、合計値を算出する必要がある。これは、Aurora IO最適化オプション検討など、月単位の正確なコスト計算に必須となる。 簡略化のため、誤差許容範囲内であれば「データテーブル」表示で概算値を確認できる。ただし、正確な値が必要な場合はCSV出力による集計が推奨される。

[Node.js, Typescript] 初学者のためのエラーハンドリング

Node.jsとTypeScriptにおけるエラーハンドリングを解説した記事。try-catch-finally構文の基本と、TypeScriptでのunknown型を用いた型安全なエラー処理を説明。Errorクラスの拡張によるカスタムエラークラスの作成方法と、エラー再スロー時のスタックトレース保持の重要性を指摘。 AWS SDK v3のエラーオブジェクトの列挙可能性に触れ、JSONシリアライズの容易さを示している。 結論として、unknown型とカスタムエラー、causeプロパティを用いた適切なエラーハンドリングが、堅牢なアプリケーション構築に不可欠と述べている。

【2025/2/23】集計 新着週間Like数 ランキング Top5

Amazon Aurora から Google Cloud BigQuery へのデータ移行を自動化してみた

AWS AuroraからGoogle Cloud BigQueryへの日次データ移行を自動化。AWS LambdaとEventBridge(AWS SAM利用)でAuroraのスナップショットをS3にエクスポートし、BigQuery Data Transfer ServiceでBigQueryへロードする。スケジュールはAuroraスナップショット取得(1時頃)、Lambda実行(4時頃)、BigQueryロード(6時頃)。WRITE_TRUNCATEオプションでデータ更新に対応。本番・ステージング環境両方に対応。導入時の課題はKMSのID指定とdata_pathの設定、データ重複の解消。現在トライアル運用中で順調。

Amazon Aurora PostgreSQLのパフォーマンスを引き出すためのCloudWatch Database Insights活用

Amazon CloudWatch Database Insightsは、Aurora PostgreSQLのパフォーマンス監視・最適化ツールとして有用です。SQLレベルのクエリパフォーマンス分析、リソースボトルネック特定、自動アラート設定、実行計画確認などを提供。 Top SQL分析によるクエリ最適化、メトリクス監視によるリソース状況把握、スロークエリ分析による効率改善を可能にし、レスポンスタイム改善やボトルネック特定に貢献します。実行計画確認機能の追加により、クエリチューニングの効率化も実現。無料の7日間履歴に加え、設定変更で30日間履歴の保持も可能です。

TROCCOのSelf-Hosted RunnerをAmazon ECS（Fargate）で動かしてプライベートネット間の転送をしてみた

TROCCOのSelf-Hosted RunnerをAmazon ECS Fargateで運用し、プライベートネットワーク間でのデータ転送を実現した。Self-Hosted Runnerは、ユーザー環境でデータ転送処理を実行するコンテナイメージを提供することで、インターネットアクセス制限のあるリソースへのアクセスを可能にする。AWS Parameter Storeでトークンを安全に管理し、ECSタスク定義、IAMロール、セキュリティグループなどを設定。結果、VPCピアリングされたプライベートサブネット上のRDS間データ転送に成功。vCPU数の増加による処理速度向上と、複数タスク同時実行による並列処理も確認された。

マルチアカウント×ハイブリッドクラウド構成におけるRoute53

本記事は、AWSとオンプレミス環境のハイブリッドクラウド、マルチアカウント構成におけるRoute53の活用方法を解説している。 オンプレミスからAWS、AWSからオンプレミスへの名前解決には、それぞれOutbound/Inbound Endpointと転送ルール、Private Hosted Zoneを用いる。マルチアカウント構成では、Private Hosted Zoneの一元管理とEndpointのNWアカウントへの集約を推奨。Private Hosted Zoneの共有はAWS CLI等を用い、転送ルールの共有にはRAMを利用できる。結果、複雑な環境でも効率的なDNS管理を実現できることを示している。

【AWS】全く知らないシステムのエラー対応をした話

AWS上で稼働するシステムの403 Forbiddenエラー発生を受け、原因調査を実施。EC2、nginx、Gunicorn等のログを確認するもエラー原因特定に至らず。アクセスログのクライアントIPアドレスがプライベートIP帯であったことからELBの存在を推測、さらに調査を進めるとAWS WAFが設定されていることを発見。CloudWatch Logsを確認した結果、WAFのルール設定ミスにより正常なアクセスがブロックされていたことが判明。WAFルールの修正によりエラーは解消された。 本事例は、AWS環境下でのエラー対応において、多様なログの確認と固定観念にとらわれない調査が重要であることを示している。