我創建上飛AWS短命用戶和調試時爲什麼這些新創建的登錄往往會失敗，一個InvalidAccessKeyId意識到，只是增加一個小sleep解決了這個問題。等到IAM策略已應用於
外部參照How long should I wait after applying an AWS IAM policy before it is valid?重：時間一致性整個AWS
我的跟進問題上面：是有辦法同步創建一致的IAM策略？或至少有一種方法知道他們準備好使用？
Amazon IAM不是爲提供短期憑證而設計的。您應該爲長期需求創建IAM用戶，例如登錄人員並登錄持久應用程序。
IAM用戶不應該用於應用程序登錄目的。例如，如果您要創建類似Instagram的應用程序，則應該維護自己的用戶數據庫，或者使用Amazon Cognito進行用戶驗證。
那麼，您如何授予用戶訪問AWS資源的權限？例如，如果你有一個Instagram的類似應用程序，您希望授予應用程序用戶上傳/下載他們的照片在Amazon S3中的能力，但要限制訪問某個桶和目錄？...
答案是使用AWS Security Token Service (STS)創建臨時憑證。可以使用給定策略在特定時間段內創建憑證。這些憑據立即工作。例如，如果類Instragram用戶登錄到應用程序，則後端應用程序可以生成臨時憑證，以允許用戶在特定的Amazon S3存儲桶內訪問特定的目錄一段時間（例如15分鐘）。然後將這些憑據傳遞到移動應用程序/ Web瀏覽器以直接訪問AWS服務。
謝謝，我會研究STS。我們使用Hashicorps Vault來管理證書，而對於其他類似db等等，這是一個非常簡單的模式，只需要首先生成具有特定TTL的新用戶 – salient
如果您的工作流程是「創建一個IAM資源，然後嘗試使用它」，而不是「更新那麼IAM資源使用它」，那麼也許你可以簡單地改變你的客戶端代碼來實現指數退避/重試達到一定數目的重試。這樣，您可以無縫地重試某些失敗響應，例如找不到無效的密鑰或資源。 – jarmod
這些事情都不可能，但爲什麼你要創建短命的IAM用戶？有一種處理短期憑證的機制，稱爲[安全令牌服務（STS）]（http://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html），它不應該要求傳播/複製時間，因爲令牌似乎是獨立的。 –