shift-mentor-study.connpass.com 13時間前

第56回_AWS Certified Cloud Practitioner (CLF) 勉強会

AWS未経験者向けにCLF(Cloud Practitioner)対策問題を一緒に解くオンライン無料勉強会。株式会社Shift Mentor主催で、2026年9月5日14時から開催、事前準備不要で途中参加・退出も可能。

AWS未経験者向けにCLF(Cloud Practitioner)対策問題を一緒に解くオンライン無料勉強会。株式会社Shift Mentor主催で、2026年9月5日14時から開催、事前準備不要で途中参加・退出も可能。
↗ 元記事を開く
dev.classmethod.jp 昨日 23:39

CloudWatch エージェントが journald に対応したので Amazon Linux 2023 で試してみた

CloudWatch エージェントが journald からのログ収集に対応し、Amazon Linux 2023 でsystemdユニット・カーネル・監査・Dockerの4種類のログをファイル退避なしで直接収集できることを検証した記事。journald対応版のRPMはS3から取得が必要で、構造化JSONとして届くログはLogs Insightsでそのまま集計・検索可能。監査ログは既定priorityでは収集対象外になる点や、ユニット指定は識別子ではなくユニット名で効く点などの実践的な注意点も報告している。

CloudWatch エージェントが journald からのログ収集に対応し、Amazon Linux 2023 でsystemdユニット・カーネル・監査・Dockerの4種類のログをファイル退避なしで直接収集できることを検証した記事。journald対応版のRPMはS3から取得が必要で、構造化JSONとして届くログはLogs Insightsでそのまま集計・検索可能。監査ログは既定priorityでは収集対象外になる点や、ユニット指定は識別子ではなくユニット名で効く点などの実践的な注意点も報告している。
↗ 元記事を開く
dev.classmethod.jp 昨日 21:33

2026年8月 Flociアップデートまとめ、CloudFrontの配信とAppSyncのGraphQLエンドポイントが動くようになった

オープンソースAWSエミュレータFlociの2026年8月アップデートまとめ。1.6.0/1.7.0で227コミットが入り、CloudFrontがS3/カスタムオリジンからの配信と署名付きURL検証に対応、AppSyncはGraphQLエンドポイントが動くようになったがリゾルバーは未実装(Phase 8待ち)。IAMはAWSマネージドポリシー1566件の名前解決に対応したが中身は全てAllow *で権限評価には使えない、アカウント間のDynamoDB/S3ストレージ分離バグが修正された等、実機検証を交えて報告している。

オープンソースAWSエミュレータFlociの2026年8月アップデートまとめ。1.6.0/1.7.0で227コミットが入り、CloudFrontがS3/カスタムオリジンからの配信と署名付きURL検証に対応、AppSyncはGraphQLエンドポイントが動くようになったがリゾルバーは未実装(Phase 8待ち)。IAMはAWSマネージドポリシー1566件の名前解決に対応したが中身は全てAllow *で権限評価には使えない、アカウント間のDynamoDB/S3ストレージ分離バグが修正された等、実機検証を交えて報告している。
↗ 元記事を開く
dev.classmethod.jp 昨日 18:20

Amazon SageMaker HyperPod のディープヘルスチェックをオンデマンドで実行してみた

Amazon SageMaker HyperPod のオンデマンドディープヘルスチェックを稼働中のSlurmクラスターで検証した記事。接続チェックは約2〜3分で完了する一方、ストレスチェックは約75分かかり、その9割以上(約69分)がDCGM診断time。チェック中はSlurm上にhyperpod-deep-health-check予約とHARDWARE_CHECKジョブが作成され、結果はCloudWatch LogsのDeepHealthCheckResultsストリームで確認できることを実機検証で示した。

Amazon SageMaker HyperPod のオンデマンドディープヘルスチェックを稼働中のSlurmクラスターで検証した記事。接続チェックは約2〜3分で完了する一方、ストレスチェックは約75分かかり、その9割以上(約69分)がDCGM診断time。チェック中はSlurm上にhyperpod-deep-health-check予約とHARDWARE_CHECKジョブが作成され、結果はCloudWatch LogsのDeepHealthCheckResultsストリームで確認できることを実機検証で示した。
↗ 元記事を開く
dev.classmethod.jp 昨日 18:17

Amazon Aurora MySQL 3.13 が GA になったので Data API でバージョンを確認してみた

Amazon Aurora MySQL 3.13.0(MySQL 8.0.45互換)がGAになったことを受け、Aurora Serverless v2の最小構成でRDS Data APIを有効化したクラスターを作成し、MySQLクライアント不要でバージョン情報を取得する検証を実施。あわせてリリースカレンダーを整理し、サポート期間重視ならLTSの3.10系、最新修正重視なら3.13を選ぶ指針を示している。

Amazon Aurora MySQL 3.13.0(MySQL 8.0.45互換)がGAになったことを受け、Aurora Serverless v2の最小構成でRDS Data APIを有効化したクラスターを作成し、MySQLクライアント不要でバージョン情報を取得する検証を実施。あわせてリリースカレンダーを整理し、サポート期間重視ならLTSの3.10系、最新修正重視なら3.13を選ぶ指針を示している。
↗ 元記事を開く
dev.classmethod.jp 昨日 18:08

M5StickS3 を AWS IoT Core につないで MQTT で双方向通信してみる

M5StickS3をAWS IoT CoreにMQTTS接続し、テレメトリ送信とコマンド受信による双方向通信を実装した記事。Wi-Fi設定をNVSに、証明書類をLittleFSに分離配置する構成、Arduino IDEでの開発環境構築、IoTポリシー・証明書の関連付け手順、MQTTテストクライアントでの動作確認方法を解説している。

M5StickS3をAWS IoT CoreにMQTTS接続し、テレメトリ送信とコマンド受信による双方向通信を実装した記事。Wi-Fi設定をNVSに、証明書類をLittleFSに分離配置する構成、Arduino IDEでの開発環境構築、IoTポリシー・証明書の関連付け手順、MQTTテストクライアントでの動作確認方法を解説している。
↗ 元記事を開く
dev.classmethod.jp 昨日 18:04

[Amazon SageMaker AI] 教師 gpt-oss-20b → 生徒 Llama 3.2 1B の応答蒸留(レスポンス蒸留)を試してみました

OpenAIのgpt-oss-20bを教師、Meta Llama 3.2 1Bを生徒とし、SageMaker Training Jobで応答蒸留(クロスファミリー)を検証。全フィールド一致率は2%から63%、サービス名正規化は34%から96%に向上し、生徒が教師(90%)を上回る結果も得られた。一方few-shotは形式のみ整い内容は悪化し、JSON抽出処理や教師データ生成・検品での実装上の注意点も多数報告している。

OpenAIのgpt-oss-20bを教師、Meta Llama 3.2 1Bを生徒とし、SageMaker Training Jobで応答蒸留(クロスファミリー)を検証。全フィールド一致率は2%から63%、サービス名正規化は34%から96%に向上し、生徒が教師(90%)を上回る結果も得られた。一方few-shotは形式のみ整い内容は悪化し、JSON抽出処理や教師データ生成・検品での実装上の注意点も多数報告している。
↗ 元記事を開く
dev.classmethod.jp 昨日 17:34

Aurora DSQL が外部キー制約をサポートしたので競合時の挙動を確認してみた

Aurora DSQLが外部キー制約に対応し、psqlとPythonから並行トランザクションの競合挙動を検証した記事。既存テーブルへの制約追加はNOT VALID必須でASYNC VALIDATEによる非同期検証が必要、また子行なし親行の削除と子行挿入が競合した場合はロック待ちではなくSQLSTATE 40001のシリアライゼーションエラーで後発コミットが失敗する点をpsycopgでの実装例とともに確認している。

Aurora DSQLが外部キー制約に対応し、psqlとPythonから並行トランザクションの競合挙動を検証した記事。既存テーブルへの制約追加はNOT VALID必須でASYNC VALIDATEによる非同期検証が必要、また子行なし親行の削除と子行挿入が競合した場合はロック待ちではなくSQLSTATE 40001のシリアライゼーションエラーで後発コミットが失敗する点をpsycopgでの実装例とともに確認している。
↗ 元記事を開く
dev.classmethod.jp 昨日 17:05

AWS IAMロールのマネージドポリシーの上限拡張(20個)を確認してみた

AWSはIAMロールにアタッチできるマネージドポリシーのデフォルトクォータを10個から20個に引き上げた。既存ロールにも自動適用される。記事ではaws iam get-account-summaryやService Quotasでクォータ値20を確認し、実際に21個のポリシーを順にアタッチする検証で20個目まで成功、21個目でLimitExceededエラーになることを確認している。

AWSはIAMロールにアタッチできるマネージドポリシーのデフォルトクォータを10個から20個に引き上げた。既存ロールにも自動適用される。記事ではaws iam get-account-summaryやService Quotasでクォータ値20を確認し、実際に21個のポリシーを順にアタッチする検証で20個目まで成功、21個目でLimitExceededエラーになることを確認している。
↗ 元記事を開く
techmokmok.connpass.com 昨日 13:02

もくもく会@恵比寿

恵比寿の貸会議室で毎週土曜開催されるもくもく会。AWS認定クラウドプラクティショナー取得を目標に、参加者同士で勉強を進めるイベント。教材配布あり、電源・Wi-Fi無料、参加費500円。

恵比寿の貸会議室で毎週土曜開催されるもくもく会。AWS認定クラウドプラクティショナー取得を目標に、参加者同士で勉強を進めるイベント。教材配布あり、電源・Wi-Fi無料、参加費500円。
↗ 元記事を開く
s-jaws.connpass.com 昨日 11:56

mini Security-JAWS[第52回]アップデートチェック会 2026年9月19日(土)

AWSとセキュリティ初心者向けのオンライン勉強会「mini Security-JAWS」第52回の告知。2026年9月19日10時から開催され、5-7月頃のAWS最新アップデートをチェックする内容。

AWSとセキュリティ初心者向けのオンライン勉強会「mini Security-JAWS」第52回の告知。2026年9月19日10時から開催され、5-7月頃のAWS最新アップデートをチェックする内容。
↗ 元記事を開く
dev.classmethod.jp 昨日 09:08

[アップデート] キャパシティ予約リソースグループが Amazon EC2 Capacity Blocks for ML と中断可能なキャパシティ予約に対応しました

AWSのキャパシティ予約リソースグループが2026年8月25日のアップデートでEC2 Capacity Blocks for MLと中断可能なキャパシティ予約に対応し、オンデマンド予約と合わせて3種類の予約を1つのグループに混在できるようになった。同一グループARNのまま起動時の購入オプションを変えるだけで消費される予約タイプを切り替えられることを検証している。

AWSのキャパシティ予約リソースグループが2026年8月25日のアップデートでEC2 Capacity Blocks for MLと中断可能なキャパシティ予約に対応し、オンデマンド予約と合わせて3種類の予約を1つのグループに混在できるようになった。同一グループARNのまま起動時の購入オプションを変えるだけで消費される予約タイプを切り替えられることを検証している。
↗ 元記事を開く
dev.classmethod.jp 昨日 03:57

[アップデート] Aurora DSQL が外部キー制約をサポートしたので確認してみた

Aurora DSQLが外部キー制約に対応した。REFERENCES句での新規作成やON DELETE CASCADE/SET NULLはPostgreSQLと同様に動作するが、既存テーブルへの追加はNOT VALID前提でVALIDATE CONSTRAINTは未サポート、CASCADE削除は1トランザクション3,000行制限の対象になるなど、DSQL特有の制約がある。

Aurora DSQLが外部キー制約に対応した。REFERENCES句での新規作成やON DELETE CASCADE/SET NULLはPostgreSQLと同様に動作するが、既存テーブルへの追加はNOT VALID前提でVALIDATE CONSTRAINTは未サポート、CASCADE削除は1トランザクション3,000行制限の対象になるなど、DSQL特有の制約がある。
↗ 元記事を開く
aws.amazon.com 昨日 01:00

Amazon CloudWatch Logs で Application Load Balancer のログを分析する

Amazon CloudWatch LogsがApplication Load Balancer(ALB)のログをVended Logsとしてサポートし、アクセスログ・接続ログ・ヘルスチェックログを構造化JSONで直接配信できるようになった。テレメトリ有効化ルールで取り込みを設定し、CloudFormationテンプレートでダッシュボードをデプロイすれば、S3管理やAthenaテーブル保守なしでLog Analyticsによる5xxエラーの原因切り分け、遅延ルート特定、ターゲット信頼性分析が可能。ログアラームでのヘルスチェック失敗通知、パイプラインでのエンリッチ(GeoIP等)、複数アカウントの集約、Contributor Insightsによる上位クライアント/ターゲットのランキングにも対応する。

Amazon CloudWatch LogsがApplication Load Balancer(ALB)のログをVended Logsとしてサポートし、アクセスログ・接続ログ・ヘルスチェックログを構造化JSONで直接配信できるようになった。テレメトリ有効化ルールで取り込みを設定し、CloudFormationテンプレートでダッシュボードをデプロイすれば、S3管理やAthenaテーブル保守なしでLog Analyticsによる5xxエラーの原因切り分け、遅延ルート特定、ターゲット信頼性分析が可能。ログアラームでのヘルスチェック失敗通知、パイプラインでのエンリッチ(GeoIP等)、複数アカウントの集約、Contributor Insightsによる上位クライアント/ターゲットのランキングにも対応する。
↗ 元記事を開く
dev.classmethod.jp 2日前

AWS IoT RuleでMQTTメッセージをCloudWatch Logsへ保存してみた

AWS IoT RuleとTerraformを使い、ローカルコンテナからPublishしたMQTTメッセージをCloudWatch Logsへ保存する最小構成を検証した記事。IoT Rule・IAM Role/Policy・Log groupの3要素で経路を構成し、IoT SQLでpayloadとtopic階層からThing名を抽出してログイベントとして保存する手順とTerraformコードを紹介している。

AWS IoT RuleとTerraformを使い、ローカルコンテナからPublishしたMQTTメッセージをCloudWatch Logsへ保存する最小構成を検証した記事。IoT Rule・IAM Role/Policy・Log groupの3要素で経路を構成し、IoT SQLでpayloadとtopic階層からThing名を抽出してログイベントとして保存する手順とTerraformコードを紹介している。
↗ 元記事を開く
dev.classmethod.jp 2日前

多観点で比較する Lambdalith vs 単一目的 Lambda

AWS Lambda構成をエンドポイントごとに分ける「単一目的Lambda」と、Honoで1つのLambdaにルーティングをまとめる「Lambdalith」を、コールドスタート・認可のタイミング・IAM権限・保守性・ルーティング表現力・CDKの書き方・CloudFormationリソース数の7観点で比較。前者はインフラ層での制御(起動前の認可・最小権限)に強く、後者は開発体験・保守性・リソース数の面で優位。結論は優劣ではなく「インフラ層で効かせたい要件があるか」で選ぶべきというもの。

AWS Lambda構成をエンドポイントごとに分ける「単一目的Lambda」と、Honoで1つのLambdaにルーティングをまとめる「Lambdalith」を、コールドスタート・認可のタイミング・IAM権限・保守性・ルーティング表現力・CDKの書き方・CloudFormationリソース数の7観点で比較。前者はインフラ層での制御(起動前の認可・最小権限)に強く、後者は開発体験・保守性・リソース数の面で優位。結論は優劣ではなく「インフラ層で効かせたい要件があるか」で選ぶべきというもの。
↗ 元記事を開く
dev.classmethod.jp 2日前

DevOps Agentのリソース変更操作(エージェントアクション)で緩和計画を実行してみた

AWS DevOps AgentのDirected Actions(エージェントアクション)機能を検証した記事。アクションロール登録とエージェントアクション有効化の2ステップで設定し、ロール権限は「天井」に過ぎず実行時はセッションポリシーとオペレーター承認により操作範囲が絞られる仕組みを解説。サポート対象外の`authorize_security_group_ingress`はブロックされたが、NAT Gatewayのルート修正シナリオでは承認フローを経て緩和計画の実行完了まで確認できた。

AWS DevOps AgentのDirected Actions(エージェントアクション)機能を検証した記事。アクションロール登録とエージェントアクション有効化の2ステップで設定し、ロール権限は「天井」に過ぎず実行時はセッションポリシーとオペレーター承認により操作範囲が絞られる仕組みを解説。サポート対象外の`authorize_security_group_ingress`はブロックされたが、NAT Gatewayのルート修正シナリオでは承認フローを経て緩和計画の実行完了まで確認できた。
↗ 元記事を開く
dev.classmethod.jp 2日前

AWS Batch が Amazon ECS Managed Instances をサポートしたので GPU と CPU インスタンスそれぞれ試してみた

AWS Batch が Amazon ECS Managed Instances に対応した。EC2のパッチ適用やAMI管理をAWS側に任せつつGPUや大きめのvCPU/メモリを使えるのが特徴で、FargateとEC2の中間を埋める選択肢となる。著者はCPU(スポット)とGPU(オンデマンド)の2種類のコンピューティング環境を実際にCLIで構築し検証した。インスタンスゼロの状態からジョブ投入して実行開始までCPUは約30〜44秒、GPUは約36秒と高速だった。ホストOSはBottlerocket、GPUインスタンスにはNVIDIAドライバとCUDA Toolkitがプリインストール済みで追加設定なしにnvidia-smiが実行できた。一方でminvCpusによる常時起動指定不可、スポットをオンデマンドより前段に置けない、最大稼働14日、カスタムAMI不可などの制約があり、Terraform AWS Providerは未対応(2026年8月時点)。料金はEC2料金に加えインスタンス単位の管理手数料が発生する。

AWS Batch が Amazon ECS Managed Instances に対応した。EC2のパッチ適用やAMI管理をAWS側に任せつつGPUや大きめのvCPU/メモリを使えるのが特徴で、FargateとEC2の中間を埋める選択肢となる。著者はCPU(スポット)とGPU(オンデマンド)の2種類のコンピューティング環境を実際にCLIで構築し検証した。インスタンスゼロの状態からジョブ投入して実行開始までCPUは約30〜44秒、GPUは約36秒と高速だった。ホストOSはBottlerocket、GPUインスタンスにはNVIDIAドライバとCUDA Toolkitがプリインストール済みで追加設定なしにnvidia-smiが実行できた。一方でminvCpusによる常時起動指定不可、スポットをオンデマンドより前段に置けない、最大稼働14日、カスタムAMI不可などの制約があり、Terraform AWS Providerは未対応(2026年8月時点)。料金はEC2料金に加えインスタンス単位の管理手数料が発生する。
↗ 元記事を開く
dev.classmethod.jp 2日前

Account Access Managerで割り当てるIAMロールの配置先と運用構成を検証してみた

IAM Identity CenterのAccount Access Managerを使い、委任管理アカウントから別メンバーアカウントの既存IAMロールを割り当てる運用を検証した記事。信頼ポリシーに必要なActionはAssumeRole/SetContext/SetSourceIdentityの3つで、SetSourceIdentityが無いとValidationExceptionになる。信頼ポリシーへのaws:SourceIp条件によるIP制限はAssumeRoleの呼び出し元がサービスプリンシパルになるため機能せず、CloudTrailで実証している。ロール自体は許可セットのように自動展開されず各アカウントで個別管理が必要という運用上のトレードオフも整理している。

IAM Identity CenterのAccount Access Managerを使い、委任管理アカウントから別メンバーアカウントの既存IAMロールを割り当てる運用を検証した記事。信頼ポリシーに必要なActionはAssumeRole/SetContext/SetSourceIdentityの3つで、SetSourceIdentityが無いとValidationExceptionになる。信頼ポリシーへのaws:SourceIp条件によるIP制限はAssumeRoleの呼び出し元がサービスプリンシパルになるため機能せず、CloudTrailで実証している。ロール自体は許可セットのように自動展開されず各アカウントで個別管理が必要という運用上のトレードオフも整理している。
↗ 元記事を開く
kakakakakku.hatenablog.com 2日前

Terraform で default DB サブネットグループをインポートしようとすると "Default" is not allowed as "name" というエラーが出る

AWSのdefault DBサブネットグループをTerraformのimportブロックで取り込もうとするとname="default"が原因で"Default" is not allowed as "name"エラーが発生する。原因はTerraform AWS Provider(およびRDS API仕様)がname値としてdefaultを禁止しているためで、nameを省略してimportすると成功しdescription更新等の管理も可能になるが、意図しない挙動のため推奨はできず、defaultサブネットグループに依存しない構成が望ましいとまとめている。

AWSのdefault DBサブネットグループをTerraformのimportブロックで取り込もうとするとname="default"が原因で"Default" is not allowed as "name"エラーが発生する。原因はTerraform AWS Provider(およびRDS API仕様)がname値としてdefaultを禁止しているためで、nameを省略してimportすると成功しdescription更新等の管理も可能になるが、意図しない挙動のため推奨はできず、defaultサブネットグループに依存しない構成が望ましいとまとめている。
↗ 元記事を開く
dev.classmethod.jp 2日前

AWS DMS で MySQL の TIME 型を Redshift の TIME 型にマッピングできないのはなぜですか

AWS DMSでMySQLのTIME型をRedshiftのTIME型にマッピングしようとすると、型不一致エラーが発生する。DMSはMySQLのTIME型をいったんSTRING型に変換し、Redshiftではそれが VARCHAR として書き込まれるため、TIME型で事前定義したカラムとは型が一致しない。MySQLのTIME型が24時間を超える値域を持つのに対しRedshiftのTIME型は00:00:00〜24:00:00までしか扱えないという値域の違いも背景にある。対応策として、移行先カラムをVARCHARとして定義することが推奨されている。

AWS DMSでMySQLのTIME型をRedshiftのTIME型にマッピングしようとすると、型不一致エラーが発生する。DMSはMySQLのTIME型をいったんSTRING型に変換し、Redshiftではそれが VARCHAR として書き込まれるため、TIME型で事前定義したカラムとは型が一致しない。MySQLのTIME型が24時間を超える値域を持つのに対しRedshiftのTIME型は00:00:00〜24:00:00までしか扱えないという値域の違いも背景にある。対応策として、移行先カラムをVARCHARとして定義することが推奨されている。
↗ 元記事を開く
dev.classmethod.jp 2日前

Savings Plans購入時に「オーバーコミットしている可能性があります」と表示されたときの確認手順

AWS Savings Plans購入時に表示される「オーバーコミットしている可能性があります」という警告は、購入操作を行うアカウント単体の直近30日間のオンデマンド料金のみを基に判定される。一括請求環境やSP更新時には実態と異なる警告が出やすく、正しく判断するにはBilling and Cost Managementの使用状況レポート(使用率)とカバレッジレポート(カバレッジ)を確認する必要がある。使用率100%かつカバレッジ100%未満であれば、オーバーコミットには該当しない。

AWS Savings Plans購入時に表示される「オーバーコミットしている可能性があります」という警告は、購入操作を行うアカウント単体の直近30日間のオンデマンド料金のみを基に判定される。一括請求環境やSP更新時には実態と異なる警告が出やすく、正しく判断するにはBilling and Cost Managementの使用状況レポート(使用率)とカバレッジレポート(カバレッジ)を確認する必要がある。使用率100%かつカバレッジ100%未満であれば、オーバーコミットには該当しない。
↗ 元記事を開く
aws.amazon.com 2日前

Amazon Bedrock のきめ細かなコスト配分の導入

Amazon Bedrock がAPI呼び出しを実行したIAMプリンシパル(ユーザー/ロール/フェデレーテッドID)ごとにコストを自動紐付けする機能を発表。CUR 2.0でユーザー・アプリケーション・チーム別の支出が確認でき、コスト配分タグを使えばチームやプロジェクト単位で集計可能。IAMユーザー、IAMロール、フェデレーテッド認証、LLMゲートウェイ経由の4シナリオ別に設定方法を解説している。

Amazon Bedrock がAPI呼び出しを実行したIAMプリンシパル(ユーザー/ロール/フェデレーテッドID)ごとにコストを自動紐付けする機能を発表。CUR 2.0でユーザー・アプリケーション・チーム別の支出が確認でき、コスト配分タグを使えばチームやプロジェクト単位で集計可能。IAMユーザー、IAMロール、フェデレーテッド認証、LLMゲートウェイ経由の4シナリオ別に設定方法を解説している。
↗ 元記事を開く
aws.amazon.com 2日前

パート2: Amazon AthenaとCUDOSを使用したAmazon Bedrockのコスト配分

Amazon BedrockのコストをIAMプリンシパル単位で配分・分析する方法の解説記事(Part2)。CUR 2.0のデータエクスポートでIAMプリンシパル情報を有効化し、Amazon Athenaでのクエリパターン(利用者別、タグ別、UNNESTによる動的タグ検出)を紹介するほか、CUDOSダッシュボード5.8で追加されたBedrock向けAI/MLタブ(100万トークンあたりコストのトレンドやインタラクティブなドリルダウン)についても説明している。

Amazon BedrockのコストをIAMプリンシパル単位で配分・分析する方法の解説記事(Part2)。CUR 2.0のデータエクスポートでIAMプリンシパル情報を有効化し、Amazon Athenaでのクエリパターン(利用者別、タグ別、UNNESTによる動的タグ検出)を紹介するほか、CUDOSダッシュボード5.8で追加されたBedrock向けAI/MLタブ(100万トークンあたりコストのトレンドやインタラクティブなドリルダウン)についても説明している。
↗ 元記事を開く
dev.classmethod.jp 2日前

[アップデート] Mountpoint for Amazon S3 v1.24.0 でメモリ使用量を制御できるようになったので確認してみた

Mountpoint for Amazon S3 v1.24.0 でメモリ使用量の目標値を指定する `--memory-target` オプションが追加された。指定がない場合は物理メモリの95%が自動設定され、このターゲット値から書き込み時の同時オープンファイル数の上限が計算式(メモリターゲット − オーバーヘッド − read part size)/ write part size で決まる。上限に達すると新規の open() が ENOMEM で失敗する仕様で、これは破壊的変更としてリリースノートにも記載されている。検証では東京リージョンの EC2 上で実際にオプション指定値ごとの上限値と計算式の一致、最小値バリデーション、上限超過時の ENOMEM 発生を確認している。

Mountpoint for Amazon S3 v1.24.0 でメモリ使用量の目標値を指定する `--memory-target` オプションが追加された。指定がない場合は物理メモリの95%が自動設定され、このターゲット値から書き込み時の同時オープンファイル数の上限が計算式(メモリターゲット − オーバーヘッド − read part size)/ write part size で決まる。上限に達すると新規の open() が ENOMEM で失敗する仕様で、これは破壊的変更としてリリースノートにも記載されている。検証では東京リージョンの EC2 上で実際にオプション指定値ごとの上限値と計算式の一致、最小値バリデーション、上限超過時の ENOMEM 発生を確認している。
↗ 元記事を開く
dev.classmethod.jp 2日前

AWS DevOps Agentがリソースを更新できるようになったので試してみた

AWS DevOps AgentにDirected actions(エージェントアクション)機能が追加され、読み取り専用だったエージェントがリソース変更を実行できるようになった。有効化にはエージェントスペースでのトグルON、アカウントごとのIAMアクションロール登録、操作ごとの承認という3層のオプトインが必要。IAMロールで許可されていても、リソース削除・パーミッションバウンダリー変更・iam:PassRoleを伴う操作はエージェント側のガードレールで拒否される仕組み。筆者は実際にLambda関数へのタグ付けを依頼し、承認パネルで実際のAPI呼び出し内容やリスク評価(影響範囲・可逆性)を確認した上でApproveし、正常に実行されることを確認した。

AWS DevOps AgentにDirected actions(エージェントアクション)機能が追加され、読み取り専用だったエージェントがリソース変更を実行できるようになった。有効化にはエージェントスペースでのトグルON、アカウントごとのIAMアクションロール登録、操作ごとの承認という3層のオプトインが必要。IAMロールで許可されていても、リソース削除・パーミッションバウンダリー変更・iam:PassRoleを伴う操作はエージェント側のガードレールで拒否される仕組み。筆者は実際にLambda関数へのタグ付けを依頼し、承認パネルで実際のAPI呼び出し内容やリスク評価(影響範囲・可逆性)を確認した上でApproveし、正常に実行されることを確認した。
↗ 元記事を開く
dev.classmethod.jp 2日前

AWS IoT Fleet Provisioningでローカルコンテナを自動登録してみた

AWS IoT Fleet ProvisioningのProvisioning by claimを使い、共通のclaim証明書を持つローカルLinuxコンテナ(Podman)から初回起動時にThingとデバイス固有証明書を自動生成する検証記事。claim用とruntime用のIoT Policyを分離し、証明書のライフサイクル管理や再起動時のprovisioningスキップ処理まで実装・動作確認している。

AWS IoT Fleet ProvisioningのProvisioning by claimを使い、共通のclaim証明書を持つローカルLinuxコンテナ(Podman)から初回起動時にThingとデバイス固有証明書を自動生成する検証記事。claim用とruntime用のIoT Policyを分離し、証明書のライフサイクル管理や再起動時のprovisioningスキップ処理まで実装・動作確認している。
↗ 元記事を開く
aws.amazon.com 2日前

Amazon EC2、20 回目の誕生日おめでとう

Amazon EC2が2026年8月25日で20周年を迎えた。2006年のm1.smallインスタンス1種類から始まり、現在は1,200種類以上のインスタンスタイプ・39リージョンへ拡大。EBS、ELB、VPC、Nitro System、Gravitonなど基盤技術を振り返りつつ、直近5年の注目リリース(Inferentia/Trainium等のAI専用チップ、Macインスタンス、ML向けCapacity Blocks、Graviton5、数学的分離を保証するNitro Isolation Engine)を紹介。ECS/EKS/Lambda/SageMaker/Bedrockなど多くのAWSサービスが最終的にEC2上で動作しており、今後もクラウドコンピューティングの基盤であり続けるとしている。

Amazon EC2が2026年8月25日で20周年を迎えた。2006年のm1.smallインスタンス1種類から始まり、現在は1,200種類以上のインスタンスタイプ・39リージョンへ拡大。EBS、ELB、VPC、Nitro System、Gravitonなど基盤技術を振り返りつつ、直近5年の注目リリース(Inferentia/Trainium等のAI専用チップ、Macインスタンス、ML向けCapacity Blocks、Graviton5、数学的分離を保証するNitro Isolation Engine)を紹介。ECS/EKS/Lambda/SageMaker/Bedrockなど多くのAWSサービスが最終的にEC2上で動作しており、今後もクラウドコンピューティングの基盤であり続けるとしている。
↗ 元記事を開く
qiita.com 2日前

ローカル環境でAWSを使ってみる(FlociをつかってTerraformで構築) - Qiita

LocalStackのライセンス変更を受け、MITライセンスのFlociを使ってローカル環境でAWSを模擬し、Terraform・AWS CLIをDockerで構築する方法を紹介する記事。

LocalStackのライセンス変更を受け、MITライセンスのFlociを使ってローカル環境でAWSを模擬し、Terraform・AWS CLIをDockerで構築する方法を紹介する記事。
↗ 元記事を開く
aws.amazon.com 2日前

AI・ガバナンス・マルチプロダクト──注目スタートアップ 3 社の事例セッション【AWS Summit Japan 2026】

AWS Summit Japan 2026のスタートアップ3社事例セッションのダイジェスト。LayerXはAIエージェント基盤にn8n・MCP・LiteLLM・Fargate/Lambda・Temporal Workflowを組み合わせ、統制を最小限にしつつAI Native化を推進。JPYCはステーブルコイン事業の金融統制と開発スピードを両立するため、AWS ArtifactによるFISC対応の効率化やネットワーク多層防御、ゼロトラストのアクセス制御を構築。ログラスはマルチプロダクト化に備え早期にAmazon EKS(シングルクラスタ・マルチアカウント)を導入し、Platform EngineeringとHelmによる開発者体験向上で開発速度を大幅改善した。

AWS Summit Japan 2026のスタートアップ3社事例セッションのダイジェスト。LayerXはAIエージェント基盤にn8n・MCP・LiteLLM・Fargate/Lambda・Temporal Workflowを組み合わせ、統制を最小限にしつつAI Native化を推進。JPYCはステーブルコイン事業の金融統制と開発スピードを両立するため、AWS ArtifactによるFISC対応の効率化やネットワーク多層防御、ゼロトラストのアクセス制御を構築。ログラスはマルチプロダクト化に備え早期にAmazon EKS(シングルクラスタ・マルチアカウント)を導入し、Platform EngineeringとHelmによる開発者体験向上で開発速度を大幅改善した。
↗ 元記事を開く
aws.amazon.com 2日前

最新技術の“その先”と出会う場所|Startup Zone & Physical AI エリア【AWS Summit Japan 2026】

AWS Summit Japan 2026のレポート記事。Startup Zoneでは、AWSを活用するVOISING、DubGuild、インフィニマインド、Jitera、Direavaなど各社の事例ブースやセッションを紹介。Physical AIエリアでは、フツパーの外観検査AI、FastLabelの人型ロボット、Highlandersの四足歩行ロボット、コニカミノルタの自然言語駆動ロボットアーム、リコーの多能工ヒューマノイド、AWS自身の自律連携デモなど、実世界で動くAIの展示が紹介された。

AWS Summit Japan 2026のレポート記事。Startup Zoneでは、AWSを活用するVOISING、DubGuild、インフィニマインド、Jitera、Direavaなど各社の事例ブースやセッションを紹介。Physical AIエリアでは、フツパーの外観検査AI、FastLabelの人型ロボット、Highlandersの四足歩行ロボット、コニカミノルタの自然言語駆動ロボットアーム、リコーの多能工ヒューマノイド、AWS自身の自律連携デモなど、実世界で動くAIの展示が紹介された。
↗ 元記事を開く
dev.classmethod.jp 2日前

Amazon SES Mail Manager SMTPでVPCエンドポイント集約構成を維持できるか整理してみた

Amazon SES Mail Manager SMTPのガイド付きセットアップ登場を受け、マルチアカウントでSMTP用VPCエンドポイントを集約する既存構成を維持したままMail Manager SMTPへ移行できるか整理した記事。従来のSES SMTPはSMTP認証情報に対応するIAMユーザーの権限で送信するが、Mail Manager SMTPは認証とメール送信の主体が分離し、ルールセットに設定したIAMロールが送信を担う。VPCエンドポイントとイングレスエンドポイントは同一アカウント所有必須、IAMロールもMail Managerと同一アカウント必須という制約から、VPCエンドポイント集約とアカウント単位の送信クォータ/評価メトリクス分離を両立できず、両立させたい場合は従来のSES SMTP継続が現実解と結論づけている。

Amazon SES Mail Manager SMTPのガイド付きセットアップ登場を受け、マルチアカウントでSMTP用VPCエンドポイントを集約する既存構成を維持したままMail Manager SMTPへ移行できるか整理した記事。従来のSES SMTPはSMTP認証情報に対応するIAMユーザーの権限で送信するが、Mail Manager SMTPは認証とメール送信の主体が分離し、ルールセットに設定したIAMロールが送信を担う。VPCエンドポイントとイングレスエンドポイントは同一アカウント所有必須、IAMロールもMail Managerと同一アカウント必須という制約から、VPCエンドポイント集約とアカウント単位の送信クォータ/評価メトリクス分離を両立できず、両立させたい場合は従来のSES SMTP継続が現実解と結論づけている。
↗ 元記事を開く
www.publickey1.jp 2日前

DuckDBの開発元であるDuckLabsがAWS子会社になると発表。DuckDBはオープンソースのMITライセンスを維持

DuckDBの開発元DuckLabsが2026年9月初旬にAWSの子会社になると発表。DuckDBおよびDuckLakeはMITライセンスのオープンソースとして維持され、ライセンス・開発体制・ガバナンス・ロードマップも継続される。AWSにとっては、S3上の大規模データを高速分析できるDuckDBを自社のデータ戦略(S3、Redshift、S3 Tables等)を補完する要素として取り込み、SnowflakeやDatabricks、Google Cloudなど競合への接近を防ぐ狙いがあると見られる。

DuckDBの開発元DuckLabsが2026年9月初旬にAWSの子会社になると発表。DuckDBおよびDuckLakeはMITライセンスのオープンソースとして維持され、ライセンス・開発体制・ガバナンス・ロードマップも継続される。AWSにとっては、S3上の大規模データを高速分析できるDuckDBを自社のデータ戦略(S3、Redshift、S3 Tables等)を補完する要素として取り込み、SnowflakeやDatabricks、Google Cloudなど競合への接近を防ぐ狙いがあると見られる。
↗ 元記事を開く
dev.classmethod.jp 3日前

GitHub Actionsのセルフホステッド ランナーをLambda MicroVMs上で実行してみた

Lambda MicroVMs上にGitHub Actionsのセルフホステッドランナーを構築するCDK構成(cdk-github-microvm-runners)を検証した記事。GitHub App連携からワークフロー実行までの手順を紹介し、ジョブ実行までの待ち時間が約25秒、Docker利用も可能なことを確認。料金面ではGitHub-hosted runnersの方が単純比較で安いが秒単位課金がメリットで、MicroVMの一時停止・再開機能を活用すればステート保持による処理時間短縮も見込めると考察している。

Lambda MicroVMs上にGitHub Actionsのセルフホステッドランナーを構築するCDK構成(cdk-github-microvm-runners)を検証した記事。GitHub App連携からワークフロー実行までの手順を紹介し、ジョブ実行までの待ち時間が約25秒、Docker利用も可能なことを確認。料金面ではGitHub-hosted runnersの方が単純比較で安いが秒単位課金がメリットで、MicroVMの一時停止・再開機能を活用すればステート保持による処理時間短縮も見込めると考察している。
↗ 元記事を開く
dev.classmethod.jp 3日前

新規IAMユーザーの初回パスワード変更とMFA有効化を同時に強制することはできますか?

AWS IAMで新規ユーザーの初回パスワード変更とMFA有効化を同時に強制する方法を解説。iam:ChangePasswordをMFA例外アクションに含めないとログイン自体に失敗するため、既存の強制MFAポリシーにこのアクションを追加する必要がある点を実例のスクリーンショット付きで説明している。

AWS IAMで新規ユーザーの初回パスワード変更とMFA有効化を同時に強制する方法を解説。iam:ChangePasswordをMFA例外アクションに含めないとログイン自体に失敗するため、既存の強制MFAポリシーにこのアクションを追加する必要がある点を実例のスクリーンショット付きで説明している。
↗ 元記事を開く
dev.classmethod.jp 3日前

Amazon Data Firehose の Direct PUT 送信元を後から特定できないのはなぜですか

Amazon Data FirehoseのDirect PUTは送信元のIAMプリンシパルを記録しないため、CloudTrailの管理イベントだけでは送信元を特定できない。PutRecord/PutRecordBatch呼び出しはデータイベントに分類され、デフォルトでは無効化されているため、送信元IPやIAMプリンシパルを追跡するには事前にデータイベントを有効化しておく必要がある。有効化前の呼び出しは遡って確認できない点に注意が必要。

Amazon Data FirehoseのDirect PUTは送信元のIAMプリンシパルを記録しないため、CloudTrailの管理イベントだけでは送信元を特定できない。PutRecord/PutRecordBatch呼び出しはデータイベントに分類され、デフォルトでは無効化されているため、送信元IPやIAMプリンシパルを追跡するには事前にデータイベントを有効化しておく必要がある。有効化前の呼び出しは遡って確認できない点に注意が必要。
↗ 元記事を開く
aws.amazon.com 3日前

Adtech Meetup ~変わる広告、変わらない価値~ 開催レポート

AWSジャパンが2026年7月にアドテク・マーケティングテクノロジー企業19社を招き「Adtech Meetup」を開催。シグナルロスとAIの台頭という2大変化への対応、RTB通信に特化した低遅延・低コストのネットワークサービス「AWS RTB Fabric」の紹介、同サービスで国内初の商用接続を実現したfluct・UNICORN両社によるパネルディスカッションなど、AI時代の広告ビジネス戦略と事業者間連携をテーマにしたイベントレポート。

AWSジャパンが2026年7月にアドテク・マーケティングテクノロジー企業19社を招き「Adtech Meetup」を開催。シグナルロスとAIの台頭という2大変化への対応、RTB通信に特化した低遅延・低コストのネットワークサービス「AWS RTB Fabric」の紹介、同サービスで国内初の商用接続を実現したfluct・UNICORN両社によるパネルディスカッションなど、AI時代の広告ビジネス戦略と事業者間連携をテーマにしたイベントレポート。
↗ 元記事を開く
aws.amazon.com 3日前

AWS Weekly Roundup: AWS Builder Center での学生リワード、ラスベガスのローカルゾーンなど (2026 年 8 月 24 日)

AWS Weekly Roundupの記事。AWS Builder Centerで学生向けリワードプログラムが開始され、認定を受けた高等教育学生はSkill Builderの12か月無料アクセスやクレジット・認定バウチャーを獲得できる。その他、ラスベガスの新ローカルゾーン、ロンドンリージョンの第4アベイラビリティーゾーン、EC2 Auto Scalingのバッチ終了サポート、CloudShellのビジュアルエディタ、Bedrockでのgrok-4.6とOpenAIモデルのクロスリージョン推論対応、AgentCore Payments一般提供、Glue 6.0の値下げとIceberg v3対応など、8月24日週の複数のAWSアップデートをまとめている。

AWS Weekly Roundupの記事。AWS Builder Centerで学生向けリワードプログラムが開始され、認定を受けた高等教育学生はSkill Builderの12か月無料アクセスやクレジット・認定バウチャーを獲得できる。その他、ラスベガスの新ローカルゾーン、ロンドンリージョンの第4アベイラビリティーゾーン、EC2 Auto Scalingのバッチ終了サポート、CloudShellのビジュアルエディタ、Bedrockでのgrok-4.6とOpenAIモデルのクロスリージョン推論対応、AgentCore Payments一般提供、Glue 6.0の値下げとIceberg v3対応など、8月24日週の複数のAWSアップデートをまとめている。
↗ 元記事を開く
dev.classmethod.jp 3日前

Amazon CognitoのAdminDeleteSoftwareTokenを直接呼び出してTOTP設定をリセットしてみた

Amazon Cognitoに追加されたAdminDeleteSoftwareTokenは、管理者がユーザーのTOTPソフトウェアトークンを削除できるAPI。AWS CLI・boto3は未対応のため、botocoreでSigV4署名を付与したHTTPリクエストとして直接呼び出し、削除前後で認証要素とMFAチャレンジの変化を検証している。デバイス紛失時にMFA必須を維持したままTOTPだけをリセットし、MFA_SETUPから再登録させる復旧フローが実装可能になった。

Amazon Cognitoに追加されたAdminDeleteSoftwareTokenは、管理者がユーザーのTOTPソフトウェアトークンを削除できるAPI。AWS CLI・boto3は未対応のため、botocoreでSigV4署名を付与したHTTPリクエストとして直接呼び出し、削除前後で認証要素とMFAチャレンジの変化を検証している。デバイス紛失時にMFA必須を維持したままTOTPだけをリセットし、MFA_SETUPから再登録させる復旧フローが実装可能になった。
↗ 元記事を開く
aws.amazon.com 3日前

AWS と DuckLabs: 分析の未来を共に築く

AWSがDuckDBの開発元DuckLabsを買収する最終契約を締結。DuckDBはインプロセスで動作する分析データベースで、1TB以下の日常的なSQLクエリを高速処理する点に強みがある。創業者のHannes MühleisenとMark RaasveldtはAWSに参画し、DuckDBオープンソースプロジェクトは独立したFoundationの下でMITライセンスのまま維持される。Amazon QuickやAllen Instituteでの活用事例も紹介され、AWSはS3やRedshiftなど既存分析サービスとDuckDBの統合を進める方針。

AWSがDuckDBの開発元DuckLabsを買収する最終契約を締結。DuckDBはインプロセスで動作する分析データベースで、1TB以下の日常的なSQLクエリを高速処理する点に強みがある。創業者のHannes MühleisenとMark RaasveldtはAWSに参画し、DuckDBオープンソースプロジェクトは独立したFoundationの下でMITライセンスのまま維持される。Amazon QuickやAllen Instituteでの活用事例も紹介され、AWSはS3やRedshiftなど既存分析サービスとDuckDBの統合を進める方針。
↗ 元記事を開く
kakakakakku.hatenablog.com 3日前

IAM Policy Autopilot 0.3.0 でサポートされた「Terraform の plan 結果からの IAM ポリシー生成」を試す

IAM Policy Autopilot 0.3.0 で追加された Terraform plan 結果から IAM ポリシーを生成する機能を検証した記事。SQS キューと Lambda 関数の作成・削除それぞれの plan/plan-destroy から最小権限ポリシーの「ベースライン」を生成できることを確認し、Lambda の例では不要な権限(iam:TagUser 等)や Resource が "*" になる箇所を Warnings 機能が指摘する挙動も紹介している。

IAM Policy Autopilot 0.3.0 で追加された Terraform plan 結果から IAM ポリシーを生成する機能を検証した記事。SQS キューと Lambda 関数の作成・削除それぞれの plan/plan-destroy から最小権限ポリシーの「ベースライン」を生成できることを確認し、Lambda の例では不要な権限(iam:TagUser 等)や Resource が "*" になる箇所を Warnings 機能が指摘する挙動も紹介している。
↗ 元記事を開く
zenn.dev 3日前

ローカル AWS エミュレータで Terraform を検証する

TerraformのAWSエミュレータFlociを使い、ECS+RDS構成で7種類のインフラ設定ミスがローカル検証できるか検証した記事。DBホスト名/ポート誤りや循環参照は検出できたが、セキュリティグループのingress不足、SSL必須設定、ルートテーブル誤り、IAMロール不足(ECS経由)、デッドロックは再現できなかった。エミュレータが再現するのはAPIレスポンス(コントロールプレーン)のみで、ネットワーク制御や料金等のデータプレーン・非機能面は再現されない。TrivyやCheckovなどの静的解析も既定ルールでは同様のケースを検出できず、terraform validateやカスタムポリシーの併用が有効と結論づけている。

TerraformのAWSエミュレータFlociを使い、ECS+RDS構成で7種類のインフラ設定ミスがローカル検証できるか検証した記事。DBホスト名/ポート誤りや循環参照は検出できたが、セキュリティグループのingress不足、SSL必須設定、ルートテーブル誤り、IAMロール不足(ECS経由)、デッドロックは再現できなかった。エミュレータが再現するのはAPIレスポンス(コントロールプレーン)のみで、ネットワーク制御や料金等のデータプレーン・非機能面は再現されない。TrivyやCheckovなどの静的解析も既定ルールでは同様のケースを検出できず、terraform validateやカスタムポリシーの併用が有効と結論づけている。
↗ 元記事を開く
www.infoq.com 4日前

AWS Introduces Specification-Driven Composition for Flexible Data Workflows

AWSがデータ変換ワークフローの仕様駆動コンポジションパターンを公開。ワークフローの意図(仕様)と処理ロジックを分離し、Lambda・Step Functions・S3・OpenSearchを用いてサーバーレスに実装。仕様がデータセットやフィールドマッピングを宣言的に記述し、コンポーザーが検証してパイプラインを動的に組み立てる。規制対応やマルチソース統合など、トレーサビリティと事前検証が重要なケースに適する一方、単純な変換には過剰な複雑さになりうるとしている。

AWSがデータ変換ワークフローの仕様駆動コンポジションパターンを公開。ワークフローの意図(仕様)と処理ロジックを分離し、Lambda・Step Functions・S3・OpenSearchを用いてサーバーレスに実装。仕様がデータセットやフィールドマッピングを宣言的に記述し、コンポーザーが検証してパイプラインを動的に組み立てる。規制対応やマルチソース統合など、トレーサビリティと事前検証が重要なケースに適する一方、単純な変換には過剰な複雑さになりうるとしている。
↗ 元記事を開く
qiita.com 4日前

アクセスキーこわい やめかたと漏らさない工夫 - Qiita

AWSアクセスキーは有効期限がなく漏洩時の被害が大きいため、開発者はaws login、AWSリソースはIAMロール、CI/CDはOIDC、外部サーバーはIAM Roles Anywhereといった一時クレデンシャルへの移行を提案。移行できない場合の対策として、gitleaksやPush Protectionによる予防、最小権限やローテーションによる防御、GuardDutyによる検知という3段構えの防御策と、漏洩時は即座に無効化すべきことを解説している。

AWSアクセスキーは有効期限がなく漏洩時の被害が大きいため、開発者はaws login、AWSリソースはIAMロール、CI/CDはOIDC、外部サーバーはIAM Roles Anywhereといった一時クレデンシャルへの移行を提案。移行できない場合の対策として、gitleaksやPush Protectionによる予防、最小権限やローテーションによる防御、GuardDutyによる検知という3段構えの防御策と、漏洩時は即座に無効化すべきことを解説している。
↗ 元記事を開く
zenn.dev 4日前

Secrets Managerのシークレットはどんな粒度で分けるべき?

AWS Secrets Managerのシークレットをどんな粒度で分けるべきかを調査した記事。公式ドキュメントには明示的な粒度の指針はないが、最小権限の原則とローテーション推奨から「用途とライフサイクルが異なる秘密情報は1シークレットにまとめるべきではない」と結論づけている。粒度を誤った場合の弊害として、過剰な権限付与(不要な情報まで読み取り可能になる)と、IaCでの差分確認のしづらさ(CloudFormationは変更セットで行単位の差分が見えるがTerraformはsensitive値としてマスクされ内訳が分からない)を、CloudFormationとTerraformでの実検証を交えて解説している。

AWS Secrets Managerのシークレットをどんな粒度で分けるべきかを調査した記事。公式ドキュメントには明示的な粒度の指針はないが、最小権限の原則とローテーション推奨から「用途とライフサイクルが異なる秘密情報は1シークレットにまとめるべきではない」と結論づけている。粒度を誤った場合の弊害として、過剰な権限付与(不要な情報まで読み取り可能になる)と、IaCでの差分確認のしづらさ(CloudFormationは変更セットで行単位の差分が見えるがTerraformはsensitive値としてマスクされ内訳が分からない)を、CloudFormationとTerraformでの実検証を交えて解説している。
↗ 元記事を開く
duckdb.org 4日前

DuckLabs to Join AWS, Projects to Remain Open Source

DuckDBの開発元DuckLabsがAWSの子会社として参画することを発表。DuckDB・DuckLake等のプロジェクトはMITライセンスのオープンソースのまま、非営利のDuckDB Foundationが管理を継続し、ロードマップやガバナンスに変更はない。

DuckDBの開発元DuckLabsがAWSの子会社として参画することを発表。DuckDB・DuckLake等のプロジェクトはMITライセンスのオープンソースのまま、非営利のDuckDB Foundationが管理を継続し、ロードマップやガバナンスに変更はない。
↗ 元記事を開く
www.percona.com 4日前

Replication Lag on AWS FSx: The Hidden EC2 Single-Flow Bandwidth Limit

PostgreSQLのレプリケーション遅延の原因調査で、AWS FSx(NFS)の使用率は50%程度で正常に見えたが、実際にはEC2の単一TCPフロー(single-flow)に課される約5Gbpsの帯域上限がボトルネックだった事例。vmstatのbカラムやnfsiostatのキュー時間から異常を検知し、スループット分布を分析することで単一フロー上限を特定。NFSのnconnectオプションで複数TCPコネクションに分散させることで解消したが、闇雲に大きな値を設定するより適切なベンチマークで必要十分な接続数を決めるべきと指摘している。

PostgreSQLのレプリケーション遅延の原因調査で、AWS FSx(NFS)の使用率は50%程度で正常に見えたが、実際にはEC2の単一TCPフロー(single-flow)に課される約5Gbpsの帯域上限がボトルネックだった事例。vmstatのbカラムやnfsiostatのキュー時間から異常を検知し、スループット分布を分析することで単一フロー上限を特定。NFSのnconnectオプションで複数TCPコネクションに分散させることで解消したが、闇雲に大きな値を設定するより適切なベンチマークで必要十分な接続数を決めるべきと指摘している。
↗ 元記事を開く
kakakakakku.hatenablog.com 6日前

Amazon EC2 の新機能「アプリケーションステータスチェック」でアプリケーションのヘルスチェックを実行する

Amazon EC2の新機能「アプリケーションステータスチェック」を検証した記事。nginxを動かすEC2インスタンスにHTTP/HTTPSレベルのヘルスチェックを設定し、AWS CLIでの登録手順(create-application-status-check→associate-application-status-check→CloudWatchアラーム作成)とnginx停止/起動時のステータス変化、Slack通知までの動作確認を行っている。ALB不要でEIP運用やプライベートサブネットの内部アプリも監視可能になる点、ENIごとに時間課金が発生する点、Terraform AWS Providerは未対応な点にも言及。

Amazon EC2の新機能「アプリケーションステータスチェック」を検証した記事。nginxを動かすEC2インスタンスにHTTP/HTTPSレベルのヘルスチェックを設定し、AWS CLIでの登録手順(create-application-status-check→associate-application-status-check→CloudWatchアラーム作成)とnginx停止/起動時のステータス変化、Slack通知までの動作確認を行っている。ALB不要でEIP運用やプライベートサブネットの内部アプリも監視可能になる点、ENIごとに時間課金が発生する点、Terraform AWS Providerは未対応な点にも言及。
↗ 元記事を開く
tech.dentsusoken.com 6日前

Amazon Bedrock Managed Knowledge Base が日本語 PDF を扱えない件

Amazon Bedrock Managed Knowledge Base に電通総研の有価証券報告書PDFを投入したところ、営業利益の質問に対して全年度誤った数値が返された。原因を調査したところ、検索対象のチャンクから日本語が完全に欠落しており、PDF自体には問題がないことも確認済み。AWSサポートに問い合わせた結果、Managed KBは現時点で日本語PDFに対応していないとの回答を得た(メタデータの言語コードも"en"になっていた)。ワークアラウンドとして従来型のCustomer-managed KBを使えば正常に動作することを検証している。

Amazon Bedrock Managed Knowledge Base に電通総研の有価証券報告書PDFを投入したところ、営業利益の質問に対して全年度誤った数値が返された。原因を調査したところ、検索対象のチャンクから日本語が完全に欠落しており、PDF自体には問題がないことも確認済み。AWSサポートに問い合わせた結果、Managed KBは現時点で日本語PDFに対応していないとの回答を得た(メタデータの言語コードも"en"になっていた)。ワークアラウンドとして従来型のCustomer-managed KBを使えば正常に動作することを検証している。
↗ 元記事を開く
qiita.com 6日前

【cdkd(CDK Direct)】CloudFormationを経由しないCDKデプロイ!? cdkdによる高速デプロイを試してみた! - Qiita

AWS CDKのデプロイ手法「cdkd(CDK Direct)」を試した記事。CloudFormationを経由せずにデプロイすることで、従来のcdk deployと比較してデプロイ時間・全体時間を短縮できるかを実測比較している。

AWS CDKのデプロイ手法「cdkd(CDK Direct)」を試した記事。CloudFormationを経由せずにデプロイすることで、従来のcdk deployと比較してデプロイ時間・全体時間を短縮できるかを実測比較している。
↗ 元記事を開く