PuppyIP Resource Center
Cloud Operations 6 min read Published 2026-10-15

Transfer Family SFTP Host Keys: Console and CLI Defaults Differ

AWS Transfer Family can now store SFTP server host keys in Secrets Manager in your account, letting you retrieve and reuse them across servers and Regions to preserve server identity during migration or failover. New console-created servers default to this storage, while CLI and API creation still defaults to service-managed storage. Existing keys cannot all be converted directly.

AWS Transfer Family SFTP Secrets Manager Host keys AWS KMS

Service eligibility and regional restrictions

PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.

Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.

Key Takeaways

  • New console-created servers default to SECRETS_MANAGER. CLI/API creation defaults to SERVICE_MANAGED when HostKeyStorageType is omitted.
  • Direct conversion of an existing service-managed host key requires it to have been imported on or after October 14, 2026. Older keys need an AWS Support exception.
  • UpdateHostKey with SECRETS_MANAGER requires transfer:ExportHostKey even when the key already uses that storage. Customer-managed KMS also needs a service-linked role decryption grant.
  • Transfer Family controls the secret lifecycle. Do not manually delete or overwrite it; Secrets Manager automatic rotation is not used. Host-key operations are eventually consistent.

Separate server identity from user login credentials

In its October 14, 2026 announcement, AWS added storage of SFTP server host keys in Secrets Manager in the customer’s account. Previously, service-held keys did not let customers retrieve the associated private key material. The new option helps preserve server identity during migration or failover and is available in all AWS Regions where Transfer Family is available.

A host key lets the client identify the server; known_hosts holds the corresponding public key. It is not a user’s login private key and does not replace user authentication or file-access authorization. Accidentally changing it can trigger trust warnings or break automated connection scripts.

Creation and updates use different fields and defaults

Before creating a server, decide whether you need to retrieve and reuse its host key. The console defaults to SECRETS_MANAGER, while CLI/API creation defaults to SERVICE_MANAGED if HostKeyStorageType is omitted. With CreateServer, use HostKeyStorageType to choose explicitly. Transfer Family generates a host key if you do not provide one.

For an import or update, the relevant field is StorageType in ImportHostKey or UpdateHostKey, with the same SERVICE_MANAGED and SECRETS_MANAGER values. Do not reuse the server-creation field name in a host-key update or assume that new-server defaults automatically migrate existing servers.

Check the import date, then the caller’s permissions

Before converting an existing SERVICE_MANAGED host key, check when it was imported. Direct conversion to SECRETS_MANAGER is allowed only for keys imported on or after October 14, 2026. For an older key, contact AWS Support for an exception and include the AWS account ID. This is an import-date rule, not a server-creation-date rule, and it does not establish direct eligibility for every older generated key.

Next, check the update caller’s permissions. UpdateHostKey with StorageType set to SECRETS_MANAGER requires transfer:ExportHostKey, even if the host key already uses Secrets Manager storage. ExportHostKey is a permission-only action; it is not a callable export API.

For first use of this storage, also confirm that the caller has iam:CreateServiceLinkedRole. Transfer Family creates the AWSServiceRoleForTransfer service-linked role in the account and uses it to read the secret and serve the host key to new connections. This creation permission and ExportHostKey serve different purposes.

Customer-managed KMS needs a key-policy decryption grant

When importing or updating a host key, the optional KmsKey parameter selects a customer-managed KMS key ARN. If omitted, Transfer Family uses the AWS managed key for Secrets Manager. To change the encryption key for an existing Secrets Manager-backed host key, provide a new KmsKey through UpdateHostKey; Transfer Family re-encrypts the secret.

Before using a customer-managed key, check that its key policy allows AWSServiceRoleForTransfer to call kms:Decrypt. The role’s managed policy does not provide that grant. The official example uses kms:ViaService and kms:EncryptionContext:SecretARN to restrict access to the regional Secrets Manager service and transfer!-prefixed secrets. Check its account, Region and partition placeholders against the actual environment.

Reusing identity is only one part of cross-Region failover

Consider a hypothetical setup with a primary SFTP server in Region A and a standby in Region B, both using the same public DNS name. Reusing the same host key can preserve the server identity clients already trust, avoiding a new host-key trust decision solely because traffic moves to the standby.

That addresses only host identity. The announcement does not promise automatic secret replication, DNS switching, file synchronization, user authorization or zero downtime. Plan those parts separately. Verify the existing host identity and client trust requirements rather than changing keys simply to silence a warning.

Manage the host key through Transfer Family, not manual secret edits

After an approved change, inspect StorageType with DescribeHostKey or ListHostKeys. Secrets Manager-backed keys also return SecretId. Transfer Family names the managed secret with a transfer! prefix and controls its lifecycle; it is not an arbitrary configuration item to maintain manually.

You cannot overwrite the existing host-key value through the Transfer Family API or Secrets Manager console, and Transfer Family does not use automatic rotation for these secrets. To rotate a host key, the documentation specifies importing a new host key and deleting the old one. DeleteHostKey, or deletion of the server, causes Transfer Family to schedule the corresponding secret for deletion. Do not bypass that lifecycle by deleting the secret manually.

Deleting the secret, or removing the service-linked role’s access to it or its KMS key, prevents host-key retrieval and makes new connections fail. Host-key operations are eventually consistent. Observe the actual state and client connection results after a change; one successful response does not establish that every connection has switched.

Sources

Frequently Asked Questions

Can I add my own tags to the Transfer Family-managed secret?

Yes. The documentation allows custom tags. Service tags include aws:transfer:owningServerArn, aws:transfer:owningHostKeyArn and aws:secretsmanager:owningService=transfer, which help identify ownership or scope access. Permission to add tags does not mean the key value or secret lifecycle should be managed manually.

Is adding another host-key type always harmless for older clients?

No. Transfer Family supports types including RSA, ECDSA and ED25519, but its guide warns that adding a type after clients start using the server can cause compatibility or trust problems, potentially as disruptive as replacing an existing key. Include algorithm choice and client compatibility in the change review.

Does this feature include free Secrets Manager and KMS usage?

The reviewed announcement and two documents provide no Secrets Manager or KMS price table or free allowance, so they do not establish free usage. Cross-Region host-key reuse is not a promise of free replication, calls or recovery infrastructure. Check the services used in the actual deployment separately.