低コストでバースタブルな新しい Amazon EC2 インスタンス T8i の一般提供開始をお知らせします。Amazon EC2 T8i は AWS 専用にカスタマイズされた第 6 世代インテル Xeon スケーラブルプロセッサ (Granite Rapids) を搭載しています。T8i インスタンスは最も低価格な EC2 インスタンスのひとつとなり、前世代の T3 インスタンス と比較して最大 30% 優れた料金パフォーマンスを提供します。T8i インスタンスは、CPU 使用率が低から中程度のさまざまなワークロード (フリーミアムサービス、トレーニングおよびデモ環境、ステージングと開発、データ処理、マイクロサービス、低トラフィックの Web サイト、ログインゲートウェイなど) を実行するように設計されています。 T8i インスタンス T3 インスタンスは、小規模かつ費用対効果の高いコンピューティング構成が求められる軽量ワークロードの実行において、非常に多くのお客様から利用されています。これには、マイクロサービスアーキテクチャ、低トラフィックの Web サイト、開発およびテスト環境、小規模データベース、データ処理ジョブ、短時間のコンピューティングタスクなどが含まれます。こうしたお客様の多くからは、T ファミリーのバースタブル性能モデルが好まれています。このモデルでは、ベースラインレベルの CPU パフォーマンスが提供され、必要に応じて CPU クレジットを使用してベースラインを超えるバーストが可能です。 インフラストラクチャのモダナイズや、オンプレミス環境からの移行、イベント駆動型およびマイクロサービスアーキテクチャの採用、さらには AI 推論ワークロードの実験を進める中で、お客様から次の 3 点が求められています。それは、1. コスト最適化された新世代の小規模インスタンス、2. 総所有コストを削減できる優れた価格パフォーマンス、3. 既存の知識とツールを活用できるシームレスな移行パスです。 T8i インスタンスはこうした要望にお応えします。 最大 30% 優れた料金パフォーマンス。 T8i インスタンスは、 AWS Nitro System を基盤とし、カスタムの第 6 世代インテル Xeon スケーラブルプロセッサー (Granite Rapids) を搭載。最大 30% 優れた料金パフォーマンスにより、総所有コストの削減を実現します。 最大 70% 向上したコンピューティング性能。 T8i インスタンスは、T3 インスタンスと比較してコンピューティング性能が最大 70%、ネットワーク帯域幅は最大 1.25 倍、EBS 帯域幅は最大 2.4 倍に向上しています。 T3 からのシームレスなアップグレード。 すでに T3 をお使いのお客様は、T8i へのアップグレードが簡単です。T8i では、お客様がすでに使い慣れた CPU クレジットシステムと軽量コンピューティングオプションをそのままご利用いただけます。T3 から T8i に変更するだけで、より高いコストパフォーマンスが得られます。 高いコスト効果で新規に始めやすく。 AWS を初めて利用するお客様やオンプレミスから移行されるお客様にとって、T8i インスタンスは、低～中程度の CPU 使用率が必要なワークロードの実行のほか、バッチ処理、イベント駆動型関数、CI/CD パイプラインなどの短期間のコンピューティングタスクの実行において、最もコスト効果の高いエントリーポイントの一つとなります。 インスタンスの仕様 T8i インスタンスには 4 つのサイズがあり、いずれも 2 つの vCPU をシングルコアで提供します。次の表は、仕様をまとめたものです。 インスタンスサイズ vCPU メモリ (GiB) ベースラインパフォーマンス/vCPU (%) 1 時間あたりの CPU クレジット獲得数 ネットワーク バースト 帯域幅 (Gbps) t8i.nano 2 0.5 5 3 最大 6.25 t8i.micro 2 1 10 6 最大 6.25 t8i.small 2 2 20 12 最大 6.25 t8i.medium 2 4 20 12 最大 6.25 T3 と同様、T8i インスタンスは 1:0.25、1:0.5、1:1 といった、他の EC2 インスタンスにはない、独自の vCPU 対メモリ比率を提供します。また T3 と同様、CPU クレジットシステムを採用しており、 Standard モードおよび Unlimited モードの 2 つのクレジット設定モードを利用できます。T8i ではデフォルトで Unlimited モードが有効です。 T8i で提供されるサイズ ( nano 、 micro 、 small 、 medium ) よりも大きなインスタンスが必要なワークロードには、 M8i Flex インスタンス をお勧めします。これは、同等の前世代の T3 インスタンスと比較して最大 30% 優れた価格パフォーマンスを提供するとともに、 16xlarge までスケールアップできる柔軟性を備えます。 今すぐご利用いただけます Amazon EC2 T8i インスタンス は現在、以下の AWS リージョンでご利用いただけます: 米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン、北カリフォルニア)、アジアパシフィック (ハイデラバード、マレーシア、ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、パリ)。リージョンごとの提供状況と今後のリージョン拡張については、 AWS Capabilities by Region の CloudFormation リソースタブでインスタンスタイプを検索してください。 T8i インスタンスは、 オンデマンドインスタンス および スポットインスタンス で購入でき、Savings Plan オプションは近日提供予定です。T8i インスタンスは共有テナンシーのみをサポートしており、Dedicated テナンシーや専有ホストはサポートしていません。 t8i.micro インスタンス および t8i.small インスタンス は、 AWS 無料利用枠 でもご利用いただけます。詳細については、 Amazon EC2 の料金ページ をご覧ください。 T8i インスタンスを Amazon EC2 コンソール でお試しいただき、 AWS re:Post for EC2 または通常の AWS サポート窓口までフィードバックをお寄せください。 — Channy 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの 大前 です。9 月に入り一段と涼しくなってきましたが、いかがお過ごしでしょうか。今月は「エージェントに現場を任せるとき、境界線をどこに引くか」をピックアップトピックとしてお届けしつつ、8 月に公開された製造業向けのブログとサービスアップデートをご紹介します。なお、リンク先には英語の記事も含まれていますが、日本語の解説を添えていますのでぜひご覧ください。 ピックアップトピック: エージェントに現場を任せるとき、境界線をどこに引くか PoC では動いたのに本番に載せられない理由の多くは、モデルの精度ではなく「どこまで AI に判断させるか」が決まっていないことにあります。今回ご紹介している記事のいくつかでは、同じ問いに別の角度から答えていました。 AI に判断を任せ、実行は別の層で制御する コニカミノルタ様の「未来の実験室」 では、材料開発の実験を「緑色を作ってください」と自然言語で指示できます。ただしモデルは座標や動作列を生成しません。担当は目標色・操作候補・停止条件へ分解した JSON の中間表現までで、座標制御は人が設計した決定論的な制御層が担います。役割を絞ったので、軽量な Claude Haiku 系でも成立します。 SUMCO 様の SynchroFabAI も同じ構図で、AI に任せるのは「異常状態の推測」と「因果関係の推測」までであり、操作は人間が実施します。 AWS Summit での Physical AI デモ構築 においても、エージェントの権限を「変更できる／人の承認が要る／外で強制される」の 3 段に切ることで安全性を保ちながらロボットが動くデモを構築しました。これらに共通するのは、AI の判断と現実世界への操作を直結させず、その間に人の確認や決定論的な制御、外部から強制される権限制御を置いている点です。 では、どこまでをAIに任せ、どこからを人や制御層に渡すべきでしょうか。その境界は、モデルの性能だけでは決められません。8 月に公表された Amazon Science の論文で提案されている SOP-Bench では、標準作業手順書（SOP）を AI エージェントに実行させて成功率を測定しています。11 のモデルで試した結果、新しいモデルが必ず高い成功率を示すわけではありませんでした。また、ツール構成を比較した実験では、必要なツールだけを与えた場合に比べ、不要なツールを追加すると成功率がほぼ半減しました。自社の手順と実際のツール構成で性能を測り、安定して実行できる範囲だけをAIに委ねることが、AI と人間の境界を決める現実的な方法です。ただし、境界を決めるだけでは十分ではありません。実運用では、その境界を技術的な制約として強制する必要があります。 決めた境界をインフラ側で強制する 8 月は Amazon Bedrock AgentCore にこの方向の機能が 2 つ加わりました。 時間的ポリシー は、それまでの操作履歴を踏まえて各リクエストを評価する認可ルールで、作業順序の強制や特権操作前の人間承認を設定できます。 AgentCore Payments では支払い上限をインフラ層で強制できます。 「危険な操作をしないでください」とプロンプトに書くのと、そもそもその操作が許可されない状態を作るのは、まったく別のことです。後者は OT のインターロックに近い考え方です。エージェントを現場に出すために必要なのは、モデルを賢くすることだけでなく、任せない範囲を先に決め、その境界を外部から強制することなのかもしれません。 直近で開催予定のイベント 9/14 – 9/19 IMTS 2026 北米最大級の工作機械展示会がシカゴで開催されます。AWS もブースを出展予定で、量子コンピューティングと製造業をテーマにした AWS 主催のレセプションもあります。 10/13 – 10/16 CEATEC 2026 JEITA 主催のデジタルイノベーションの総合展示会が幕張メッセで開催されます。テーマは「Transformation -企業が、産業が、そして社会が変わる-」です。 AWS も Hall 4 で、安川電機様とご一緒に展示を予定しています。 10/26 – 10/31 JIMTOF2026 世界最大級の工作機械見本市が東京ビッグサイトで開催されます。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントがラスベガスで開催されます。2,200 を超えるセッションが予定されています。 製造関連ブログのご紹介 8/3 Engineering Development Hub : A unified workbench to accelerate product development 製品開発チームは、 分断されたツール・データサイロ・計算リソース制約 という課題に日々直面しています。 Engineering Development Hub (EDH) は、複雑なシステムの設計・テスト・検証に必要なアプリケーション・計算・データを1つのオープンソース環境に統合した、クラウドベースのエンジニアリングワークベンチです。 Amazon Lab126 や Rivian などの顧客が既にEDHを活用しており、NVIDIA Isaac Sim でのフィジカルAI模倣学習や車載インフォテインメント開発などの実例を紹介しています。 大規模ハードウェア開発を高速化したい設計・開発部門の方におすすめです。 8/6 Run HPC Simulations faster with Siemens Teamcenter and AWS ParallelCluster 「解析の順番待ちで設計が止まる」という課題を、Teamcenter Simulation と AWS ParallelCluster の連携で解いた記事です。設計を選んでジョブを投げれば入力は自動で置かれ、計算ノードは終われば消えます。数日の設計スタディが数時間に。 解析のリードタイム短縮を検討している CAE・解析部門の方におすすめです。 8/7 Leading FMEG Player Builds Manufacturing Control Tower on AWS 工場ごとにデータが閉じていると、異常に気づくのは手遅れになってからとなります。本記事ではインドの大手電設機器メーカーが約 15 工場を 4 層構成でつなぎ、障害後の意思決定を 24 時間超から 2 時間未満に、拠点追加の工数を 1 工場あたり 20% 未満（従来は 80〜100%）に縮めた事例をご紹介しています。 複数拠点の OT データ統合をこれから広げる方におすすめです。 8/18 SUMCO が挑む、Amazon Redshift × 生成 AI による半導体ウェーハ製造 DX 株式会社 SUMCO 様との共著です。ネットワーク分離と権限分離によるセキュアな AWS 基盤上に、データ分析パイプラインの RedPulse と自然言語でのデータ分析を実現する SynchroFabAI を積み上げた道筋が語られます。 セキュリティを担保しつつ、機械学習による品質予測や、品質に強く寄与するパラメータの要因分析などによるデータ分析の力を組織全体に広げていく過程をご覧いただけます。 8/19 Agentic AI でつなぐモノ・サービスの改善サイクル リリース後に溜まる運用データが、次の開発に一度も戻ってこない。その原因を「データのサイロ」と「人材のサイロ」に切り分け、Amazon Quick で埋める方法です。AI 自身が仮説を立てて検証まで進みます。 製品の改善サイクルを回したい開発・品質部門の方におすすめです。 8/20 Amazon Bedrock とロボティクスで目指す「未来の実験室」 コニカミノルタ株式会社様との共著です。材料開発の実験を自然言語で指示すると、ロボットアームが実際に手を動かし、結果が電子実験ノートに戻るという閉ループを約 2 か月で実装されています。開発には Kiro CLI を活用されており、 生成 AI をチャットの外の実機制御へ広げたい研究開発部門の方におすすめです。 8/21 Accelerating Chip Tape-out with AWS Unified Operations 半導体企業がAWS上でEDA（電子設計自動化）ワークロードを実行する際、インフラの可用性・性能がチップ納期に直結します。 AWS Unified Operations はAWSの最上位サポート層にあたり、専任チームが、アーキテクチャ支援・迅速なインシデント対応・財務最適化・セキュリティ監視を提供します。本記事では、12 か月のテープアウト工程に沿って Unified Operations がどのように支援を行うのかを紹介します。 高可用性が求められる HPC ワークロードを抱える方におすすめです。 8/21 SOP-Bench: A new benchmark for evaluating AI agents on real business procedures Amazon Science が発表した、標準作業手順書（SOP）を AI エージェントに実行させる公開ベンチマークです。倉庫点検や危険物分類を含む、12 業務領域・2,000 超のタスクを実際に動くツールと正解付きで用意し、エージェントの。自社の手順を足して評価することもできます。 エージェントを本番に載せる前の物差しが欲しい方におすすめです。 8/24 ソフトウェア開発を AI エージェントで加速する ── TOPPAN が体験した SDLC 主要フェーズの手応え TOPPAN 株式会社様との共著です。20 名が Kiro CLI を活用し、SDLC の Research・Plan・Release をAI と協調しながら回す体験を行いました。レガシーコードから設計書を復元する手応えや、AWS MCP Server を頼りに CI/CD を組む感触が率直に語られます。 AI を活用した開発の効率化に興味のある方におすすめです。 9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで 6 月の Summit で展示した「AI エージェントが街の障害物を自律的に見つけて片付ける」デモを、どう作ったかの記録です。10 名全員が兼務で、実機を使った統合に充てられたのは本番前の約 1 か月という過酷な条件の中で、企画の可視化から 3D モデリング、実装、説明員資料などの全工程を生成 AI と伴走する過程を紹介しています。 AI を使った開発プロセスの型づくりに関心のある方は、ここから読むと全体像がつかめます。 9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 2: ロボット開発編 上記デモのロボット側です。FANUC 社製協働ロボット 2 台をクラウドの AI エージェントと連携させるデモ開発の裏側をご紹介しております。画像から動作指令までを 1 つのモデルで出す方式を採らなかった理由、コーディングエージェントの権限を「変更できる／人の承認が要る／エージェントの外で強制される」の 3 つに切った線引き、そして手先の向きを保つ拘束を AI が誤って無効化した経験から「禁止と代替手順はセットで書く」に至った経緯まで、任せる範囲の決め方が具体的に語られます。 今号のピックアップトピックの実例編として、あわせてお読みください。 製造関連の主要なサービスアップデート 8/3 Amazon SageMaker AI がフルファインチューニングに対応 25 以上のオープンソースモデルで全パラメーターを更新できます。設備の型式ごとの符牒や検査基準といった組織固有の語彙を、モデルに深く覚え込ませたいときにご利用いただけます。 8/4 AWS Security Hub Extended がソフトウェアサプライチェーンのセキュリティに対応 外部から取り込むオープンソース部品に悪意あるコードが混ざっていないかを、アプリに組み込む前に検出・遮断できます。 8/6 AgentCore に時系列ポリシーとレート制限を追加 ピックアップトピックでご紹介した機能です。宛先ごとのリクエスト数・トークン数の上限も併せて設定できます。 8/7 AWS Parallel Computing Service が FedRAMP・SOC・ISO・PCI の対象に マネージド HPC サービスである、Parallel Computing Service がSOC、ISO などの主要な第三者認証の対象になりました。統制・監査要件が壁になっていた技術計算部門の導入判断を後押しします。 8/11 AWS Glue から SageMaker Unified Studio へワンクリックでアクセス AWS Glue と同じ権限のままクエリ・品質チェック・パイプライン構築へ移れます。データカタログの整備から分析・AI 活用までを、ツールを行き来せずに進められます。 8/18 AgentCore payments が一般提供開始 エージェントが有料の API を自ら見つけて使い、決済まで行えます。支払い上限はインフラ側で強制されるので、外部データを都度買う調達系エージェントも統制下で運用できます。 8/19 Amazon SageMaker のノートブックが Trusted Identity Propagation に対応 共有ロールではなく利用者本人の ID でデータ参照を制御でき、誰が何を見たかが AWS CloudTrail に残ります。品質データや設計情報の閲覧範囲を部門・拠点で分けたい分析基盤にご利用いただけます。 最後まで読んでいただきありがとうございました。 今月は、AI に任せる範囲の決め方と、その境界を仕組みで守る方法をご紹介しました。来月も、製造業における AI 活用のヒントをお届けします。それでは、また来月お会いしましょう！ 著者について 大前 遼（Ryo Omae） ソリューションアーキテクト 大前 遼（Ryo Omae）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。製造業のお客様を中心に、クラウド活用の技術支援を行っています。好きな領域は機械学習や生成 AI ・ロボティクスで、最近は Physical AI デモの構築に注力しています。

概要 前回の記事「 SSL/TLS証明書の有効期限短縮に備えて脱・手動更新② 」では、DNS-01チャレンジと、そのDNS認証を自動化するために利用するacme-dnsについて説明しました。 また、Certbotとacme-dnsを同じサーバーに導入し、acme-dnsがDNS-01チャレンジ用のDNSサーバーおよびWeb APIサーバーとして動作するところまで構築しました。 ここまでで、 Certbot acme-dns の2つが利用できる状態になっています。 しかし、この2つを導入しただけでは、CertbotがDNS-01チャレンジで使用する値をacme-dnsへ自動的に登録することはできません。 そこで今回は、Certbotとacme-dnsを連携させるための 認証スクリプト を用意します。 あわせて、認証スクリプトを利用するための前準備として、 acme-dnsへの利用登録 認証情報の保存 メインDNSへのCNAME登録 CNAMEのDNS反映確認 認証スクリプトが参照する認証情報ファイルの作成 まで行います。 なぜ認証スクリプトが必要なのか CertbotはACMEプロトコルを利用して、認証局（CA）が提供するACMEサーバーへ証明書の発行を要求します。 本記事では、以降、認証局（CA）が提供するACMEサーバーを簡略化して「認証局」と表記します。 DNS-01チャレンジを利用する場合、認証局は、証明書を取得しようとしているドメインを本当に管理していることをDNSを使って確認します。 Certbotは認証局から受け取ったチャレンジ情報をもとに、DNS-01で使用する検証値を用意します。 この検証値をDNSのTXTレコードとして公開し、認証局がDNSを問い合わせて正しい値を確認できれば、DNS-01チャレンジは成功します。 前回構築したacme-dnsには、DNS-01チャレンジ用のTXTレコードを更新するためのWeb APIがあります。 一方、Certbotは今回構築したacme-dnsのAPI認証情報をそのままでは知りません。 そのため、 Certbotから認証対象のFQDNとDNS-01の検証値を受け取り、acme-dnsの認証情報を使用してTXTレコードを更新する処理 が必要になります。 この処理を担当するのが、今回用意する 認証スクリプト です。 今回使用するacme-dns-auth.py 今回は、 acme-dns-auth.py を認証スクリプトとして利用します。 acme-dns-auth.py は、acme-dnsの開発者である joohoi氏がGitHubで公開している 、Certbotとacme-dnsを連携させるための認証Hookスクリプトです。 acme-dns本体もjoohoi氏が開発したプロジェクトで、このスクリプトはacme-dnsのWeb APIをCertbotから利用するためのサンプル実装として公開されています。公開元でも「Certbot client hook for acme-dns」と説明されています。 このスクリプトは、Certbotから認証対象のFQDNとDNS-01の検証値を受け取り、acme-dnsの /update APIを利用してTXTレコードを更新します。 それぞれの役割を整理すると、次のようになります。 要素 役割 Certbot ACMEプロトコルを利用して認証局と通信し、証明書の取得・更新を行う 認証局 DNS-01チャレンジによってドメインの管理権限を確認し、証明書を発行する acme-dns DNS-01チャレンジ用のTXTレコードを管理し、DNS問い合わせに回答する acme-dns-auth.py CertbotからFQDNと検証値を受け取り、acme-dnsのAPIを利用してTXTレコードを更新する 前回の記事では全体像を分かりやすくするため、「Certbotがacme-dnsのAPIを利用する」と簡略化して説明しました。 実際には、 Certbotから呼び出された acme-dns-auth.py がacme-dnsのAPIへアクセスします。 今回はacme-dnsへの登録を事前に行う 公開されている acme-dns-auth.py には、対象FQDNの認証情報が保存されていない場合、自動的にacme-dnsへ登録する機能があります。 一方、今回の構成では、 Certbotによる証明書取得を実行する前に、acme-dnsへの登録とCNAME設定を済ませておく 方式とします。 事前準備は次の流れになります。 acme-dnsの/register APIを実行 ↓ 認証情報と専用FQDNを保存 ↓ メインDNSへCNAMEを登録 ↓ CNAMEがDNSへ反映されたことを確認 ↓ 認証情報をacmedns.jsonへ登録 ↓ acme-dns-auth.pyを配置・設定 ↓ Certbotを実行 これにより、Certbotを実行する時点で、DNS-01チャレンジに必要なacme-dns側の初期設定を完了させておきます。 acme-dnsへ登録して認証情報を保存する acme-dnsには、利用登録を行うための /register APIがあります。 /register を実行すると、TXTレコードの更新に使用する認証情報と、その登録専用のサブドメインが払い出されます。 今回は、証明書を取得するFQDNを次のようにします。 www.example.org まず、認証情報を保存するディレクトリを作成します。 sudo install -d -m 700 -o root -g root /etc/letsencrypt/acme-dns 続いて、acme-dnsの /register APIを実行します。 返されたJSONは、そのままファイルへ保存します。 curl -sS -X POST http://127.0.0.1:8080/register \ -H 'Content-Type: application/json' \ -d '{"allowfrom":["127.0.0.1/32"]}' \ | sudo tee /etc/letsencrypt/acme-dns/www.example.org.json >/dev/null 認証情報が含まれるため、アクセス権を制限します。 sudo chmod 600 /etc/letsencrypt/acme-dns/www.example.org.json ここで重要なのは、 同じ登録のために /register を複数回実行しないこと です。 /register を実行すると、その都度、新しいacme-dnsアカウントと専用サブドメインが発行されます。 そのため、今回の手順では /register を1回だけ実行し、そのレスポンスをその場で保存します。 acme-dnsは、専用サブドメインと限定されたAPI資格情報を利用してDNS-01用TXTレコードのみを更新できるようにする仕組みです。 保存される認証情報 /register のレスポンスには、主に次の情報が含まれます。 項目 内容 username /update APIの認証に使用するユーザー情報 password /update APIの認証に使用する認証情報 subdomain 今回の登録に割り当てられたacme-dns内のサブドメイン fulldomain メインDNSのCNAME参照先として使用するFQDN allowfrom /update APIの利用を許可する送信元ネットワーク このうち username 、 password 、 subdomain は、後ほど acme-dns-auth.py がTXTレコードを更新するときに使用します。 fulldomain は、メインDNSへ設定するCNAMEの参照先として使用します。 CNAMEの参照先を確認する 続いて、実際に保存したJSONから fulldomain を確認します。 jq がインストールされていない場合は、事前にインストールします。 sudo dnf install -y jq fulldomain を確認します。 sudo jq -r '.fulldomain' /etc/letsencrypt/acme-dns/www.example.org.json 例えば、次のように表示されます。 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.auth.example.org この値が、今回の /register によって実際に払い出されたacme-dns側のFQDNです。 メインDNSへCNAMEを登録する 証明書を取得するFQDNが、 www.example.org で、先ほど確認した fulldomain が、 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.auth.example.org の場合、メインDNSには次のCNAMEを登録します。 _acme-challenge.www.example.org. CNAME xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.auth.example.org. これによって、認証局が、 _acme-challenge.www.example.org を問い合わせた場合、CNAMEを経由してacme-dnsが管理するFQDNへ到達できるようになります。 認証局 ↓ _acme-challenge.www.example.org ↓ CNAME xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.auth.example.org ↓ TXT DNS-01の検証値 acme-dnsは、既存DNSの _acme-challenge を専用サブドメインへCNAMEで向け、その参照先のTXTレコードだけをAPIから更新する仕組みです。 このCNAMEは基本的に一度設定すれば、その後の証明書更新でも同じ設定を利用できます。 証明書更新のたびに変更されるのは、CNAMEの参照先でacme-dnsが回答するTXTレコードの値です。 CNAMEがDNSへ反映されたことを確認する メインDNSへCNAMEを登録したら、 Certbotを実行する前に、DNSへ反映されていることを確認します。 次のコマンドを実行します。 dig +short _acme-challenge.www.example.org CNAME 先ほどacme-dnsから払い出された fulldomain が表示されることを確認します。 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.auth.example.org. このように正しいCNAME参照先が取得できれば、メインDNSからacme-dns側のFQDNを参照できる状態になっています。 CNAMEがDNSへ反映される前にCertbotを実行すると、認証局がacme-dns側のTXTレコードまで到達できず、DNS-01チャレンジに失敗する可能性があります。 そのため、 CNAMEを登録するだけでなく、実際にDNSから参照できることを確認してから次の作業へ進みます。 acme-dns-auth.pyが利用するacmedns.jsonを作成する 先ほど作成した、 /etc/letsencrypt/acme-dns/www.example.org.json には、 /register APIから返された1アカウント分の情報がそのまま保存されています。 一方、今回使用する acme-dns-auth.py は、デフォルトでは次のファイルを認証情報の保存先として参照します。 /etc/letsencrypt/acmedns.json このファイルでは、 認証対象のFQDNをキーとして、そのFQDNに対応するacme-dnsの認証情報を保持します。 例えば www.example.org の場合は、次のような構造になります。 { "www.example.org": { "username": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "password": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "fulldomain": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.auth.example.org", "subdomain": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "allowfrom": [ "127.0.0.1/32" ] } } 先ほど保存したJSONから、次のように作成できます。 sudo jq -n \ --arg domain "www.example.org" \ --slurpfile account /etc/letsencrypt/acme-dns/www.example.org.json \ '{($domain): $account[0]}' \ | sudo tee /etc/letsencrypt/acmedns.json >/dev/null 続いてアクセス権を設定します。 sudo chown root:root /etc/letsencrypt/acmedns.json sudo chmod 600 /etc/letsencrypt/acmedns.json 複数のFQDNを管理する場合は、既存の acmedns.json を上書きせず、それぞれのFQDNをキーとして認証情報を追加します。 acmedns.jsonへの登録を確認する 今回の構成では、Certbotを実行する前に対象FQDNの認証情報を acmedns.json へ登録しておくことが重要です。 次のコマンドで確認します。 sudo jq -e 'has("www.example.org")' /etc/letsencrypt/acmedns.json 次のように表示されれば、対象FQDNのエントリが存在しています。 true 公開されている acme-dns-auth.py には、対象FQDNの情報が acmedns.json に存在しない場合、新しいacme-dnsアカウントを自動登録する機能があります。 今回の構成ではCNAMEを事前に登録しているため、意図しない別アカウントの作成を避けるためにも、Certbot実行前に対象FQDNが正しく登録されていることを確認します。 認証スクリプトを配置する 認証情報の準備ができたら、 acme-dns-auth.py を配置します。 このスクリプトはPythonで作成されており、acme-dns APIとの通信にPythonの requests ライブラリを使用します。公開元でもCertbotとPython requestsライブラリが必要とされています。 RHEL / Rocky Linux / AlmaLinux系では、次のようにインストールします。 sudo dnf install -y python3-requests 続いて、認証スクリプトを取得します。 sudo curl -o /etc/letsencrypt/acme-dns-auth.py \ https://raw.githubusercontent.com/joohoi/acme-dns-certbot-joohoi/master/acme-dns-auth.py 実行権限を設定します。 sudo chmod 0700 /etc/letsencrypt/acme-dns-auth.py 公開元でも、 /etc/letsencrypt/acme-dns-auth.py へ配置して実行権限を付与する方法が案内されています。 認証スクリプトを設定する acme-dns-auth.py の先頭付近には、次の設定があります。 ACMEDNS_URL = "https://auth.acme-dns.io" STORAGE_PATH = "/etc/letsencrypt/acmedns.json" ALLOW_FROM = [] FORCE_REGISTER = False 今回の構成に合わせて確認します。 ACMEDNS_URL ACMEDNS_URL は、認証スクリプトがアクセスするacme-dnsのWeb APIのURLです。 前回の記事では、Certbotとacme-dnsを同一サーバーに配置し、acme-dns APIを、 127.0.0.1:8080 で待ち受ける構成としました。 そのため、次のように変更します。 ACMEDNS_URL = "http://127.0.0.1:8080" これにより、 acme-dns-auth.py からacme-dns APIへの通信は同一サーバー内部で行われます。 STORAGE_PATH STORAGE_PATH = "/etc/letsencrypt/acmedns.json" 先ほど作成した、FQDNごとのacme-dns認証情報を保持するファイルです。 acme-dns-auth.py はCertbotから認証対象FQDNを受け取ると、このファイルから対応する認証情報を取得します。 ALLOW_FROM ALLOW_FROM = [] ALLOW_FROM は、 acme-dns-auth.py 自身がacme-dnsへ新しいアカウントを登録する場合に、TXTレコードの更新を許可する送信元ネットワークを指定するための設定です。公開スクリプトでも、この値は新規登録時に使用されます。 今回の構成では、事前に curl で /register APIを実行し、その際に、 "allowfrom":["127.0.0.1/32"] を指定しています。 通常のCertbot実行時には、すでに保存済みの認証情報を利用して /update APIを呼び出すため、今回の運用ではスクリプト内の ALLOW_FROM は使用しません。 そのため、今回はデフォルトの、 ALLOW_FROM = [] のままとします。 FORCE_REGISTER FORCE_REGISTER = False FORCE_REGISTER を True にすると、保存済みの認証情報が存在していても、新しいacme-dnsアカウントを登録する動作になります。 今回は事前に /register を実行して認証情報とCNAMEを準備しているため、再登録は行いません。 そのため、 FORCE_REGISTER = False のままとします。 Certbotから認証スクリプトへ渡される情報 Certbotは認証Hookを実行するとき、DNS-01チャレンジに必要な情報を環境変数として認証スクリプトへ渡します。 現在のCertbotでは、認証対象を CERTBOT_IDENTIFIER 、検証値を CERTBOT_VALIDATION として渡します。また、後方互換性のため CERTBOT_DOMAIN にも CERTBOT_IDENTIFIER と同じ値が設定されます。 今回利用する acme-dns-auth.py は、主に次の2つを使用します。 環境変数 内容 CERTBOT_DOMAIN 認証対象のFQDN CERTBOT_VALIDATION DNS-01でTXTレコードへ設定する検証値 例えば、 CERTBOT_DOMAIN ↓ www.example.org CERTBOT_VALIDATION ↓ 今回のDNS-01検証値 という情報がCertbotからスクリプトへ渡されます。 acme-dns-auth.pyによるTXTレコード更新 Certbotから acme-dns-auth.py が呼び出されると、スクリプトは、 /etc/letsencrypt/acmedns.json から CERTBOT_DOMAIN に対応するacme-dnsの認証情報を取得します。 例えば、 CERTBOT_DOMAIN = www.example.org の場合、 www.example.org に対応する、 username password subdomain を取得します。 その後、acme-dnsの /update APIを呼び出し、Certbotから渡された CERTBOT_VALIDATION をTXTレコードへ設定します。 これによって、acme-dns側では、 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.auth.example.org. TXT "今回のDNS-01検証値" というTXTレコードが設定されます。 acme-dnsは、限定されたAPI資格情報によって専用サブドメインのTXTレコードのみを更新できるように設計されています。 認証局が、 _acme-challenge.www.example.org を問い合わせると、事前に設定したCNAMEを経由して、このTXTレコードを確認できます。 Certbotから認証スクリプトを呼び出す 事前準備が完了したら、 acme-dns-auth.py をCertbotの**認証Hook（authentication hook）**として指定します。 例えば、次のように実行します。 sudo certbot certonly \ --manual \ --preferred-challenges dns \ --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py \ -d www.example.org 各オプションの役割は次のとおりです。 オプション 内容 certonly 証明書の取得のみを行う --manual Certbotのmanual pluginを使用する --preferred-challenges dns DNS-01チャレンジを使用する --manual-auth-hook DNS認証時に実行する認証スクリプトを指定する -d 証明書を取得するFQDNを指定する Certbotはmanual pluginの認証処理で --manual-auth-hook に指定されたスクリプトを実行し、認証に必要な環境変数を渡します。 今回の構成では、Certbotを実行する前に、 acme-dnsへの登録 認証情報の保存 CNAME登録 CNAMEのDNS反映確認 acmedns.json への認証情報登録 まで完了しています。 そのため、Certbotから acme-dns-auth.py が呼び出されると、保存済みの認証情報を利用してacme-dnsのTXTレコードを更新できます。 証明書取得・更新時の全体の流れ 今回の構成を、事前準備と証明書取得・更新時に分けて整理します。 事前準備 1. acme-dnsの/register APIを1回だけ実行 ↓ 2. 認証情報と専用FQDNをJSONへ保存 ↓ 3. 保存したJSONからfulldomainを確認 ↓ 4. メインDNSへCNAMEを登録 ↓ 5. CNAMEがDNSへ反映されたことを確認 ↓ 6. 認証情報をacmedns.jsonへ登録 ↓ 7. acme-dns-auth.pyを配置・設定 ↓ 8. acmedns.jsonに対象FQDNが存在することを確認 証明書取得・更新時 初期設定後は、次の処理が行われます。 1. Certbotが認証局へ証明書発行を要求 ↓ 2. 認証局からDNS-01チャレンジを要求 ↓ 3. Certbotがacme-dns-auth.pyを実行 ↓ 4. acme-dns-auth.pyがacmedns.jsonから認証情報を取得 ↓ 5. acme-dnsの/update APIを実行 ↓ 6. TXTレコードへ今回の検証値を設定 ↓ 7. 認証局がDNSを確認 ↓ 8. CNAMEを経由してacme-dns側のTXTレコードを確認 ↓ 9. DNS-01チャレンジ成功 ↓ 10. 証明書発行・更新 初期設定後は、証明書更新のたびにメインDNSのCNAMEを書き換える必要はありません。 acme-dns-auth.py がacme-dns側のTXTレコードを、その都度新しい検証値へ更新します。 今回まででできるようになったこと 今回までで、 Certbotのインストール acme-dnsのインストール・設定 acme-dnsへの利用登録 認証情報の保存 メインDNSへのCNAME登録と反映確認 acmedns.json の作成 認証スクリプトの配置・設定 まで完了しました。 これによって、 Certbot ↓ DNS-01チャレンジ ↓ acme-dns-auth.py ↓ acme-dnsの/update API ↓ TXTレコードを自動更新 ↓ 認証局がDNSを確認 ↓ DNS-01チャレンジ成功 ↓ 証明書取得・更新 という処理を自動化できます。 ただし、ここまでで自動化できたのは、 Certbotサーバー上へ新しい証明書を取得・更新するところまで です。 実際にWebサーバー、LDAPサーバー、メールサーバーなどで新しい証明書を使用するには、取得した証明書を対象サーバーへ配布し、サービスへ反映する必要があります。 Certbotには、証明書が正常に発行・更新された後に任意の処理を実行する deploy hook という仕組みがあります。 今回の構成では、このdeploy hookから証明書配布用のスクリプトを実行する想定です。 証明書配布スクリプトの内容や、取得した証明書を各サーバーへ配布してサービスへ反映する方法については、次回の記事で説明します。 次回は、 「4. 証明書配布スクリプトの用意」 について説明します。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post SSL/TLS証明書の有効期限短縮に備えて脱・手動更新③ first appeared on SIOS Tech Lab .