Yes — you can call aws secretsmanager update-secret in a loop, but the guidance you quoted is about a different risk than the per-second API limit.

The “50 per second” limit is a service/API throughput quota.

The “avoid more than once every 10 minutes” guidance is about version churn per secret when you update the secret value (SecretString/SecretBinary), because each value update creates a new version and Secrets Manager will not remove unlabeled versions created within the last 24 hours. If you update the same secret value too frequently, you can hit the per-secret version quota.

Key points:

If your loop updates MANY DIFFERENT secrets once each (or infrequently), that’s fine.
The 10-minute guidance is mainly about repeatedly updating the SAME secret’s value at high frequency.

A new version is created only when you update the secret value (SecretString/SecretBinary).
If you update only metadata (e.g., Description, tags), you are not creating a new value version.

Why you only see AWSCURRENT and AWSPREVIOUS:

Secrets Manager versions are identified by VersionIds.
Only some versions have staging labels (AWSCURRENT, AWSPREVIOUS, etc.).
You can still have many unlabeled versions that are not “promoted” to those labels.

To see all versions (including unlabeled), use:

aws secretsmanager list-secret-version-ids
--secret-id <SECRET_ARN_OR_NAME>

Practical recommendation for automation:

If you need to update secret values in bulk, do it, but avoid updating the same secret more often than the guidance (≈ once per 10 minutes) unless you are sure you won’t hit the version quota.

If you need frequent updates (every seconds/minutes) to the same value, Secrets Manager is the wrong storage.
Consider a different store (e.g., SSM Parameter Store for non-rotating config, DynamoDB, etc.) depending on your use case.

If you’re looping at scale, also add retry/backoff for throttling, but the “version quota” issue is per secret, not per region-wide TPS.