2026 年 8 月 24 日週に私が最も興味を持ったニュースは、DuckLabs の買収でした。 AWS は、Parquet、CSV、JSON などのファイルに対してインプロセスで実行され、SQL を直接実行する人気のオープンソース分析データベースである DuckDB の背後にあるアムステルダムを拠点とする企業である DuckLabs を買収する最終契約を締結しました 。DuckDB は、独立した基盤と MIT ライセンスの下でオープンソースを維持しており、時間の経過とともに、AWS は日常のクエリの速度と、Amazon S3、Amazon Redshift、Amazon Athena などのエンタープライズ規模のサービスを組み合わせる予定です。 ハネス・ミューライゼンとマーク・ラースベルトが共同設立した DuckDB は、ローカルまたは Amazon S3 上で稼働しています。そのため、現実世界の分析の大部分を占める日常のクエリ (1 テラバイト以下) の処理速度が非常に速くなります。また、AI エージェントとの相性も抜群です。AI エージェントは、人間と同じようにデータを「調べて」実験します。AWS が DuckDB のスピードと Amazon EMR、AWS Glue、Amazon SageMaker などの分析サービスを組み合わせている間、共同創設者は引き続き技術的な方向性をリードしていきます。なぜこれが重要なのかをより大局的に説明するために、バイスプレジデント兼著名なエンジニアであるアンディ・ウォーフィールドが、 ポスト DuckDB と All Things Distributed で変化する分析 の物理現象についての考えを共有しました。 それでは、8 月 31 日週の AWS ニュースを見ていきましょう… 8 月 24 日週のローンチ 8 月 24 日週のローンチのうち、私が注目したリリースをいくつかご紹介します: Amazon ECS は、エージェントとの接続を失ったコンテナインスタンスを自動的に検出して回復するようになりました。Amazon ECS は、エージェントのコントロールプレーンへの接続を継続的に監視し、新しい AGENT_CONNECTIVITY ヘルスイベントを AWS Fargate、Amazon ECS マネージドインスタンス、および EC2 上の Amazon ECS 全体にわたって検出するようになりました。Fargate とマネージドインスタンスでは、ECS が自動的にリカバリ、タスクの排出、代替インスタンスの起動、障害のあるインスタンスの登録解除を行います。EC2 では、イベントを独自のワークフローに接続できます。すべての AWS コマーシャルおよび AWS GovCloud (米国) リージョンで追加料金なしで利用できます。 AWS Lambda では、Node.js 26 と Python 3.15 からパブリックプレビューランタイムが導入されました。今後の Lambda ランタイムが一般公開される前にテストできるようになりました。プレビューランタイムは最終的な GA バージョンと同じ識別子を使用するため、関数はアクションなしで自動的に段階的に終了します。サードパーティのツールやデプロイメントフレームワークでも、GA に先立って互換性を検証できます。まだ本番環境向けではありませんが（重大な変更が可能です）、次のアップグレードに先んじるには最適な方法です。すべての AWS コマーシャル、AWS GovCloud (米国)、および中国リージョンでご利用いただけます。 AWS IoT Core にネイティブ InfluxDB ルールアクションが追加されました — カスタムコードを記述したり、中間サービスをセットアップしたりしなくても、IoT デバイスから InfluxDB (Amazon TimeStream マネージドまたはセルフホスト) に時系列データを直接ルーティングできるようになりました。IoT Core はデータを InfluxDB のラインプロトコルにフォーマットし、デバイス側とサーバー側のバッチ処理をサポートします。Amazon Timestream for InfluxDB が提供されているすべての AWS リージョンで利用できます。 Amazon GameLift Servers に DDoS 保護機能が強化されました — ゲームサーバーは、ネットワークとトランスポートレイヤー (レイヤー 3 と 4) の DDoS 攻撃 (UDP リフレクション、SYN フラッド、および同様のベクトル) から自動的に保護されるようになりました。有効にしたりオプトインしたりする必要はありません。ゲーム用に最適化されたトラフィックシェーピング機能を備えた AWS Shield Standard 上に構築されているため、追加費用なしでサーバーの稼働を開始した瞬間 (Server SDK 5) に起動します。中国 (北京) と中国 (寧夏) を除き、サポートされているすべてのGameLift Serversリージョンで利用できます。 Amazon SageMaker HyperPod が Ray のサポートを拡大する — 組み込みのオブザーバビリティ、レジリエントなトレーニング、高速推論により、SageMaker HyperPod で Ray ワークロードを実行できるようになりました。Amazon SageMaker Studio から Ray クラスターを作成および管理し、JupyterLab またはローカル IDE をアタッチしてマルチノードクラスターがローカル開発環境のように動作するようにし、Grafana ダッシュボードを自動プロビジョニングします。ノードの自動リカバリ、ハングジョブの検出、階層化されたチェックポイントにより、大規模なトレーニングを正常に実行できる一方、Ray Serve は推論用に階層化された KV キャッシュを追加します。既存のオープンソース Ray コードは変更されずに動作します。Amazon EKS によってオーケストレーションされたハイパーポッドクラスターで使用できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: 20 歳の誕生日おめでとう、Amazon EC2! — アマゾン EC2 が 20 周年を迎えます。Channy Yun は、EC2 が 1 つのリージョンの単一の m1.small インスタンスタイプから 39 のリージョンにわたって 1,200 を超えるインスタンスタイプに成長した経緯と、最初の Graviton から Graviton5 と Trainium3 へのカスタムシリコンの移行について振り返ります。Amazon ECS、Amazon EKS、AWS Lambda、Amazon SageMaker、Amazon Bedrockなど、今でも AWS の多くを支えているこのサービスについて、楽しくて読む価値があります。 エージェントリソースディスカバリー (ARD): エージェントディスカバリーのオープン仕様 — 組織がエージェント 、ツール、MCP サーバーをスケールアップするにつれて、これらのリソースはクラウド、オンプレミスインフラストラクチャ、SaaS プラットフォームに分散し、それぞれが独自のレジストリとメタデータを持つことになります。ARD は新しいオープン仕様（Apache 2.0）で、エージェントのリソースを記述して発見する一般的な方法を定義しています。そのため、パブリッシャーは「一度説明すると」、コンシューマーは「あらゆる場所で発見する」ことができます。DNS はエージェント向けです。AWS はフィードバックを提供しましたが、この仕様は独自のものではありません。また、移行せずに複数のカタログを統合できるため、AWS Agent Registry が補完されます。 AWS CLI で Agent Toolkit for AWS を使い始めましょう – 単一の AWS CLI コマンド ( aws configure agent-toolkit ) で、Kiro、Claude Code、Codex、Cursor などの AI コーディングエージェントに、厳選された最新の AWS 知識と AWS MCP サーバーを介した何千もの AWS API への安全な接続が可能になりました。AI コーディングアシスタントを使用してビルドすると、適切なサービスを選択し、最新の API を使用し、セキュリティのベストプラクティスに従うのに役立ちます。そのため、初めてでも AWS コードを正しく理解できることが多くなります。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 開発者が集まってクラウドと AI の最新情報を学び、交流し、探求する無料の対面イベント。開催予定: チューリッヒ (9 月 2 日)、 サンパウロ (9 月 3 日)、 テルアビブ (9 月 10 日)、 ドバイ (9 月 30 日)。直接参加できない場合 セッションは、 グローバルライブストリームとオンデマンドハブ からストリーミングできます。サンパウロサミットでは、生成 AI と Amazon Bedrock に関する2つのセッションを発表します。参加されたら、ぜひご挨拶ください。 AWS Community Days – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。今後のイベントとして、 東京（9月5日）および ポーランドのワルシャワ （9月8日）での「JAWS SONIC 2026」が予定されています。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 8 月 31 日週のニュースは以上です。9 月 7 日週の次回 Weekly Roundup もお楽しみに! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

はじめに こんにちは。バックエンドエンジニアの山口です。 私が所属しているチームでは、日頃からClaude Codeを利用して開発をしています。 コードを書く・レビューする・調査するといった作業はかなり任せられるようになってきた一方で、課題に感じている部分があります。 「情報とナレッジの同期」です。 設計・コーディングといった開発業務であれば、ハーネスとGitと組み合わせて、かなり効率化されます。一方で、コーディング自体をAIに任せられるようになるほど、ボトルネックはより上流——企画や要件定義、部門をまたいだ合意形成に移ってきている実感があります。ただ、ビジネス活動のライフサイクルに

こんにちは、OSSよろず相談室のSKです。 OSS に関するお問い合わせが日々寄せられる中で、今回は Linux における pam_faillock によるアカウント一時ロック に関連して寄せられたお問い合わせをご紹介します。 以下のような問い合わせがありました。 Red Hat Server 環境にて、一時的にログインができなくなる事象が発生しました。 一般ユーザがリモートからログインしたところ、認証エラーとなりログインできませんでした。 管理者（root）ユーザに切り替えて passwd -S コマンドで確認したところ PS （パスワード設定済み・有効）と表示されており、アカウントロック（ LK ）にはなっていません。 また、特に解除操作を行わなくても一定時間経過すると正常にログインできるようになります。何が原因なのでしょうか？ passwd -S コマンドは /etc/shadow ファイルを参照しますが、 pam_faillock による一時ロック情報は /etc/shadow ではなく専用のディレクトリ（ /var/run/faillock/ ）で管理されているため、 passwd -S では確認できません。 今回は、このやり取りに関連して、「 pam_faillock とは何か」「 passwd -S で確認できない理由」「 faillock コマンドでの確認方法」「Linux（Red Hat系）での動作検証手順」について解説します。 pam_faillock とは？ pam_faillock は、Linuxの認証システム（PAM）で提供されているセキュリティモジュールです。 短時間に指定された回数以上の認証失敗（パスワード間違いなど）が発生した際に、ブルートフォース攻撃（総当たり攻撃）などの不正アクセスを防ぐ目的で、該当アカウントを一時的に自動ロックします。 なぜ passwd -S で確認できないのか？ passwd -S コマンドは /etc/shadow ファイルを参照 してアカウントのステータス（ PS : パスワード有効、 LK : ロック等）を判定します。 passwd -S コマンド出力例 testuser PS 2026-09-01 0 99999 7 -1 (Password set, SHA512 crypt.) 一方、 pam_faillock による一時ロック情報は /etc/shadow を書き換えるのではなく、専用のディレクトリ（デフォルト: /var/run/faillock/ ）に失敗履歴として記録・管理 されます。 そのため、 /etc/shadow 上は正常（ PS ）に見えても、 pam_faillock の失敗カウンタが上限に達していることで認証が拒否される現象が発生します。 システムログと設定パラメータ システムログ（/var/log/secure）の出力例 pam_faillock により一時ロックが発生すると、 /var/log/secure に以下のようなログが出力されます。 Sep 01 13:32:06 server sshd:pam_unix(sshd:auth): authentication failure; ... user=<対象ユーザ名> Sep 01 13:32:40 server sshd:pam_unix(sshd:auth): authentication failure; ... user=<対象ユーザ名> Sep 01 13:36:01 server sshd:pam_unix(sshd:auth): authentication failure; ... user=<対象ユーザ名> Sep 01 13:36:01 server sshd:pam_faillock(sshd:auth): Consecutive login failures for user <対象ユーザ名> account temporarily locked 設定パラメータ例（/etc/security/faillock.conf） /etc/security/faillock.conf の代表的な設定項目は以下の通りです。 deny = 3 fail_interval = 900 unlock_time = 1800 deny = 3 : 3回連続で認証失敗するとロックされます。 fail_interval = 900 : 15分間（900秒）の中で発生した失敗回数をカウントします。 unlock_time = 1800 : ロック発生後、30分間（1800秒）経過すると自動的にロックが解除されます。 注意点 パスワード変更では解除されない ：ロック中にパスワード変更を行っても pam_faillock のロック状態は解除されません（ passwd と pam_faillock の管理領域が独立しているため）。 失敗試行の繰り返しによる延長 ：ロック中にログイン試行を繰り返すと新たな失敗履歴が追加され、ロック期間（ unlock_time ）がさらに延長されることがあります。 faillock コマンドによるロック状態の確認方法 pam_faillock による認証失敗履歴およびロック状態を確認するには、 faillock コマンド を使用します。 faillock --user <対象ユーザ名> 実行結果の例： When Type Source Valid 2026-09-01 15:25:51 TTY pts/1 V 2026-09-01 15:25:59 TTY pts/1 V 2026-09-01 15:26:06 TTY pts/1 V Valid 列に V が表示されている試行が有効な失敗記録としてカウントされており、これが指定回数（ deny の値）に達するとロック状態となります。 Linux での動作検証手順 実際に Linux（今回は Red Hat Enterprise Linux 8）環境で pam_faillock の動作を確認する手順例です。 1. テスト用ユーザの作成 # useradd testuser # passwd testuser 2. SSSDの最小構成設定と起動 # cat << 'EOF' > /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = files [domain/files] id_provider = files EOF # chown root:root /etc/sssd/sssd.conf # chmod 600 /etc/sssd/sssd.conf # systemctl enable --now sssd 3. authselect による faillock の有効化 # authselect enable-feature with-faillock # authselect apply-changes # authselect current 4. faillock.conf の設定 # cp -p /etc/security/faillock.conf /etc/security/faillock.conf.org # cat << 'EOF' >> /etc/security/faillock.conf deny = 3 fail_interval = 900 unlock_time = 60 EOF 5. 意図的な認証失敗とロック確認 一般ユーザへ切り替えた上で、わざとパスワードを間違えてログインを試みます。 # su - testuser # パスワードを3回以上間違える その後、root ユーザで失敗履歴を確認します。 # faillock --user testuser まとめ Linux で「パスワード設定は正常（ PS ）なのにログインできない」場合は、 pam_faillock による一時ロック を疑い、 /var/log/secure や faillock --user <ユーザ名> コマンドで状態を確認することが有効です。 ご覧いただきありがとうございました！ 参考ドキュメント 　pam_faillock(8) — Linux manual page 　 https://man7.org/linux/man-pages/man8/pam_faillock.8.html 　faillock(8) — Linux manual page 　 https://man7.org/linux/man-pages/man8/faillock.8.html ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OSSサポートの現場から！一時的なアカウントロックの原因とは first appeared on SIOS Tech Lab .