同一個 GitHub Actions 標籤，現在也可能跑在 AWS 上
YAML 沒改，工作卻在外部服務登入時失敗，線索可能在執行基礎設施。GitHub 於10月28日宣布，Linux 算力從 Azure 擴展至 AWS。工作標籤相同，外部看到的來源位址卻可能改變。
熟悉的標籤背後有了更大的機器池
範圍涵蓋標準2核、4核 Linux runner，以及同等規模、無特殊設定的相容 larger runner。不包括 Windows 與私人網路等特殊設定。Free、Pro、Team 自動適用，Enterprise Cloud 可在 Actions > Hosted compute cloud providers 啟用 AWS。
GitHub 保留標籤與工作流程語法，在可用供應商間分配合適工作。目標是減少容量不足造成的排隊並提高韌性，並非保證每項工作加速，也沒有承諾在兩朵雲重複執行。
為什麼看起來像間歇性故障
假設部署 API 只接受 Azure 位址，相同工作流程從 Azure 可通過，換個出口就可能被拒。GitHub 也提醒留意 Microsoft Entra Conditional Access 的網路條件。這是解說用的假設，並非我們遭遇的事故。
更換權杖前，可比對失敗時間、目的地、來源 IP 與實際政策。啟動前等待機器和啟動後驗證遭拒是不同階段。算力擴充不會自動修好存取規則。
把 IP 當作範圍來讀
官方起點是 GET https://api.github.com/meta 的 actions 陣列。REST 文件要求查詢目前數值，不要複製範例。我們在本機執行 Python ipaddress，以文件專用網段192.0.2.0/24示範：.10及.200在範圍內，198.51.100.10不在。這些並非真實 runner 位址。
允許所有網段不適合每個系統。runner 文件不建議用數量眾多的標準網段作為內部資源允許清單，而列出靜態 IP 的 larger runner 或自架方案。來源網路也不能取代身分驗證與最小權限。
標籤不變，前提可能已變
先判斷失敗在啟動前或啟動後，再比對目前網段與實際限制。需要固定出口，就選擇符合要求的 runner。別把 runner 標籤默認為雲端供應商身分。