

# Managing servers
<a name="configuring-servers"></a>

In this section, you can find information on how to view a list of your servers, how to view your server details, how to edit your server details, and how to change the host key for your SFTP-enabled server.

**Topics**
+ [

## View a list of servers
](#configuring-servers-view-server-list)
+ [

## Delete a server
](#delete-server)
+ [

# View SFTP, FTPS, and FTP server details
](configuring-servers-view-info.md)
+ [

# View AS2 server details
](view-as2-server-details.md)
+ [

# IPv6 support for Transfer Family servers
](ipv6-support.md)
+ [

# Edit server details
](edit-server-config.md)
+ [

# Edit identity provider configuration
](configuring-servers-edit-custom-idp.md)
+ [

# Manage host keys for your SFTP-enabled server
](configuring-servers-change-host-key.md)
+ [

# Monitoring usage in the console
](monitor-usage-transfer-console.md)

## View a list of servers
<a name="configuring-servers-view-server-list"></a>

On the AWS Transfer Family console, you can find a list of all your servers that are located in the AWS Region that you chose.

**To find a list of your servers that exist in an AWS Region**
+ Open the AWS Transfer Family console at [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

  If you have one or more servers in the current AWS Region, the console opens to show a list of your servers. If you don't see a list of servers, make sure that you are in the correct Region. You can also choose **Servers** from the navigation pane.

  For more information about viewing your server details, see [View SFTP, FTPS, and FTP server details](configuring-servers-view-info.md).

## Delete a server
<a name="delete-server"></a>

This procedure explains how to delete a Transfer Family server by using the AWS Transfer Family console or AWS CLI.

**Important**  
You are billed, for each of the protocols enabled to access your endpoint, until you delete the server.

**Warning**  
Deleting a server results in all its users being deleted. Data in the bucket that was accessed by using the server is not deleted, and remains accessible to AWS users that have privileges to those Amazon S3 buckets.

------
#### [ Console ]

**To delete a server by using the console**

1. Open the AWS Transfer Family console at [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. In the left navigation pane, choose **Servers**.

1. Select the check box of the server that you want to delete.

1. For **Actions**, choose **Delete**.

1. In the confirmation dialog box that appears, enter the word **delete**, and then choose **Delete** to confirm that you want to delete the server.

 The server is deleted from the **Servers** page and you are no longer billed for it.

------
#### [ AWS CLI ]

**To delete a server by using the CLI**

1. (Optional) Run the following command to view the details for the server that you want to delete permanently.

   ```
   aws transfer describe-server --server-id your-server-id
   ```

   This `describe-server` command returns all of the details for your server.

1. Run the following command to delete the server.

   ```
   aws transfer delete-server --server-id your-server-id
   ```

If successful, the command deletes the server and does not return any information.

------

# View SFTP, FTPS, and FTP server details
<a name="configuring-servers-view-info"></a>

You can find a list of details and properties for an individual AWS Transfer Family server. Server properties include protocols, identity provider, status, endpoint type, custom hostname, endpoint, users, logging role, server host key, and tags.

**To view server details**

1. Open the AWS Transfer Family console at [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. In the navigation pane, choose **Servers**. 

1. Choose the identifier in the **Server ID** column to see the **Server details** page, shown following.

   You can change the server's properties on this page by choosing **Edit**. For more information about editing server details, see [Edit server details](edit-server-config.md). The details page for AS2 servers differs slightly. For AS2 servers, see [View AS2 server details](view-as2-server-details.md).  
![\[The server details console page for the server, showing the Endpoint details parameter.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-top.png)![\[The server details console page for a server, showing the list of service-managed users.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-endpoints.png)![\[The server details console page for a server, showing the Agreements details.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-users.png)![\[The server details console page, showing the Server host keys for a server.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-agreements.png)![\[The server details console page, showing the Server host keys for a server.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-hostkeys.png)
**Note**  
The server host key **Description** and **Date imported** values are new as of September 2022. These values were introduced to support the multiple host keys feature. This feature required migration of any single host keys that were in use before the introduction of multiple host keys.   
The **Date imported** value for a migrated server host key is set to the last modified date for the server. That is, the date that you see for your migrated host key corresponds to the date that you last modified the server in any way, before the server host key migration.  
The only key that was migrated is your oldest or only server host key. Any additional keys have their actual date from when you imported them. Additionally, the migrated key has a description that makes it easy to identify it as having been migrated.  
The migration occurred between September 2 and September 13. The actual migration date within this range depends on the Region of your server.  
![\[Server details screen showing the Monitoring section..\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-additional.png)![\[Server details screen showing the Tags section.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-monitoring.png)![\[Server details screen showing the Tags section.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-tags.png)

# View AS2 server details
<a name="view-as2-server-details"></a>

You can find a list of details and properties for an individual AWS Transfer Family server. Server properties include protocols, status, and more. For AS2 servers, you can also view the AS2 asynchronous MDN egress IP addresses.

![\[The server details console page for an AS2 server showing protocol and identity provider section.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/as2-server-details-top.png)![\[The server details console page for an AS2 server showing the endpoint details section.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/as2-server-details-endpoints.png)![\[The server details console page for an AS2 server showing the users and agreements sections (AS2 servers do not have any listed users).\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/as2-server-details-users-agreements.png)![\[The server details console page for an AS2 server showing the server host keys and additional details sections.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/as2-server-details-keys-additional.png)


Each AS2 server is assigned three static IP addresses. Use these IP addresses for sending asynchronous MDNs to your trading partners over AS2.

![\[Panel from an AS2 server details page, showing the list of service-managed static IP addresses.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/as2-server-details-static-ips.png)


The bottom portion of the AS2 server details page contains details for any attached workflow and monitoring and tagging information.

![\[The server details console page for an AS2 server, showing tag details.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/as2-server-details-workflows-monitoring.png)![\[The server details console page for an AS2 server, showing tag details.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-tags.png)


# IPv6 support for Transfer Family servers
<a name="ipv6-support"></a>

AWS Transfer Family supports dual-stack (IPv4 and IPv6) endpoints for the following resources:
+ SFTP public endpoints
+ VPC internal endpoints for all protocols (SFTP/FTPS/FTP and AS2)
+ Public endpoints for AS2-enabled Transfer Family servers, by using the steps provided in [Using an Application Load Balancer for dual-stack AS2 server connectivity](#ipv6-alb-as2) 
+ API endpoints

With dual-stack support, your Transfer Family endpoints can communicate with both IPv4 and IPv6 enabled clients. This enables you to gradually transition from IPv4 to IPv6 based systems without needing to switch all at once, meet IPv6 compliance requirements, and remove the need for expensive networking equipment to handle address translation between IPv4 and IPv6. For details, see [DNS and Endpoints](https://docs.aws.amazon.com/transfer/latest/APIReference/Welcome.html#dns-endpoints) in the *AWS Transfer Family API Reference*. For a complete list of available endpoints, see [AWS Transfer Family endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/transfer-service.html) in the *AWS General Reference*.

## IPv6 limitations
<a name="ipv6-limitations"></a>

The following Transfer Family resources do not currently support IPv6:
+ VPC-Internet endpoints
+ VPC\$1ENDPOINT endpoint type (deprecated)

The FTPS protocol supports the PASV and EPSV commands for requesting an open data port for file listing, getting, and putting operations. However, PASV doesn't work with IPv6 because it requires an IPv4-specific response. EPSV continues to work because it returns only port information.

To use FTPS, we recommend one of the following:
+ Configure your FTPS client to use EPSV
+ Use IPv4 instead of IPv6

SFTP supports both IPv4 and IPv6. We recommend using SFTP instead of FTPS when working with dual-stack endpoints.

## Configuring IPv6 for servers
<a name="ipv6-server-config"></a>

When creating a new server or updating an existing server, you can choose the IP address type:
+ **IPv4** (default): For backwards compatibility, the server will only accept IPv4 connections.
+ **Dual-stack**: The server will accept both IPv4 and IPv6 connections.

To update an existing server's IP address type:

1. Stop the server.

1. Edit the endpoint details.

1. Change the IP address type to **Dual-stack**.

1. Start the server.

**Note**  
For VPC-Internet endpoints, dual-stack mode is not currently supported.

## Using an Application Load Balancer for dual-stack AS2 server connectivity
<a name="ipv6-alb-as2"></a>

You can enable dual-stack (IPv4 and IPv6) connectivity to your AS2 server by using an Application Load Balancer that has a public-facing endpoint. This allows trading partners to connect to your AS2 server using either IPv4 or IPv6.

To set up a dual-stack Application Load Balancer for your AS2 server

1. Create a VPC with the following settings:
   + VPC only
   + Manual IPv4 CIDR input
   + Amazon-provided IPv6 CIDR block

1. Create at least two subnets in different Availability Zones:
   + Add IPv6 CIDRs to the subnets
   + When creating subnets, allocate only a subset of the VPC's IPv4/IPv6 addresses to leave addresses available for additional subnets

1. Create an internet gateway for the VPC.

1. Edit the route table and add two routes:
   + One route with *Destination* `0.0.0.0/0`
   + One route with *Destination* `::/0`
   + Set both route targets to the internet gateway you created

1. Create an AS2-enabled server in the VPC that you created in step 1. Make sure to specify the `IpAddressType` as `DUALSTACK`.

   For details on how to create a Transfer Family server that uses the AS2 protocol, see [Create an AS2 server](create-as2-transfer-server.md).

1. Create a target group:
   + For *Specify group details*, configure:
     + Target type: IP addresses
     + Name: Enter a name
     + Protocol: HTTP
     + Port: 5080
     + VPC: Select the VPC you created
     + Protocol version: HTTP1
     + Health checks: Use defaults
   + For *Register targets*:
     + Enter your AS2 server's private IPv4 address
     + Choose *Include as pending below*

1. Create an Application Load Balancer:
   + Enter a name
   + For *Scheme*, choose *Internet-facing*
   + For *IP address type*, choose *Dualstack*
   + For *Network mapping*:
     + Select the VPC you created
     + Select the Availability Zones where you created subnets
   + For *Security groups*, select a security group that allows inbound IPv4 and IPv6 traffic from any IP address on port 80
   + For *Listeners and routing*:
     + Protocol: HTTP
     + Port: 80
     + Default action: Forward to the target group you created
   + Choose *Create load balancer*

After you create the Application Load Balancer, trading partners can use its DNS name to send traffic to your AS2 server. This configuration enables your AS2 server to accept connections from both IPv4 and IPv6 clients through the dual-stack Application Load Balancer.

# Edit server details
<a name="edit-server-config"></a>

After you create an AWS Transfer Family server, you can edit the server configuration.

**Topics**
+ [

## Edit the file transfer protocols
](#edit-protocols)
+ [

## Edit the server endpoint
](#edit-endpoint-configuration)
+ [

## Edit your logging configuration
](#edit-CloudWatch-logging)
+ [

## Edit the security policy
](#edit-cryptographic-algorithm)
+ [

## Change the managed workflow for your server
](#configuring-servers-change-workflow)
+ [

## Change the display banners for your server
](#configuring-servers-change-banner)
+ [

## Put your server online or offline
](#edit-online-offline)

**To edit a server's configuration**

1. Open the AWS Transfer Family console at [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. In the left navigation pane, choose **Servers**.

1. Choose the identifier in the **Server ID** column to see the **Server details** page, shown following.

   You can change the server's properties on this page by choosing **Edit**:
   + To change the protocols, see [Edit the file transfer protocols](#edit-protocols).
   + For the identity provider, you can now change between any identity provider types (service-managed, AWS Directory Service, or custom identity provider). For details about changing identity provider types and the required information for each transition, see [Edit identity provider configuration](configuring-servers-edit-custom-idp.md).
   + To change the endpoint type or custom hostname, see [Edit the server endpoint](#edit-endpoint-configuration).
   + To add an agreement, you need to first add AS2 as a protocol to your server. For details, see [Edit the file transfer protocols](#edit-protocols).
   + To manage host keys for your server, see [Manage host keys for your SFTP-enabled server](configuring-servers-change-host-key.md).
   + Under **Additional details**, you can edit the following information:
     + To change the logging role, see [Edit your logging configuration](#edit-CloudWatch-logging).
     + To change the security policy, see [Edit the security policy](#edit-cryptographic-algorithm).
     + To change the server host key, see [Manage host keys for your SFTP-enabled server](configuring-servers-change-host-key.md).
     + To change the managed workflow for your server, see [Change the managed workflow for your server](#configuring-servers-change-workflow).
     + To edit the display banners for your server, see [Change the display banners for your server](#configuring-servers-change-banner).
   + Under Additional configuration, you can edit the following information:
     + **SetStat option**: enable this option to ignore the error that is generated when a client attempts to use `SETSTAT` on a file you are uploading to an Amazon S3 bucket. For additional details, see the `SetStatOption` documentation in the [ProtocolDetails](https://docs.aws.amazon.com/transfer/latest/APIReference/API_ProtocolDetails.html) topic.
     + **TLS session resumption**: provides a mechanism to resume or share a negotiated secret key between the control and data connection for an FTPS session. For additional details, see the `TlsSessionResumptionMode` documentation in the [ProtocolDetails](https://docs.aws.amazon.com/transfer/latest/APIReference/API_ProtocolDetails.html) topic.
     + **Passive IP**: indicates passive mode, for FTP and FTPS protocols. Enter a single IPv4 address, such as the public IP address of a firewall, router, or load balancer. For additional details, see the `PassiveIp` documentation in the [ProtocolDetails](https://docs.aws.amazon.com/transfer/latest/APIReference/API_ProtocolDetails.html) topic.
**Note**  
Avoid placing Network Load Balancers (NLBs) or NAT gateways in front of AWS Transfer Family servers. This configuration increases costs and can cause performance issues. For more details, see [Avoid placing NLBs and NATs in front of AWS Transfer Family servers](infrastructure-security.md#nlb-considerations)
   + To start or stop your server, see [Put your server online or offline](#edit-online-offline).
   + To delete a server, see [Delete a server](configuring-servers.md#delete-server).
   + To edit a user's properties, see [Managing access controls](users-policies.md).  
![\[The server details console page for the server, showing the Endpoint details parameter.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-top.png)![\[The server details console page for a server, showing the list of service-managed users.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-endpoints.png)![\[The server details console page for a server, showing the Agreements details.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-users.png)![\[The server details console page, showing the Server host keys for a server.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-agreements.png)![\[The server details console page, showing the Server host keys for a server.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-hostkeys.png)
**Note**  
The server host key **Description** and **Date imported** values are new as of September 2022. These values were introduced to support the multiple host keys feature. This feature required migration of any single host keys that were in use before the introduction of multiple host keys.   
The **Date imported** value for a migrated server host key is set to the last modified date for the server. That is, the date that you see for your migrated host key corresponds to the date that you last modified the server in any way, before the server host key migration.  
The only key that was migrated is your oldest or only server host key. Any additional keys have their actual date from when you imported them. Additionally, the migrated key has a description that makes it easy to identify it as having been migrated.  
The migration occurred between September 2 and September 13. The actual migration date within this range depends on the Region of your server.  
![\[Server details screen showing the Monitoring section..\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-additional.png)![\[Server details screen showing the Tags section.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-monitoring.png)![\[Server details screen showing the Tags section.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-details-tags.png)

## Edit the file transfer protocols
<a name="edit-protocols"></a>

On the AWS Transfer Family console, you can edit the file transfer protocol. The file transfer protocol connects the client to your server's endpoint.

**To edit the protocols**

1. On the **Server details** page, choose **Edit** next to **Protocols**.

1. On the **Edit protocols** page, select or clear the protocol check box or check boxes to add or remove the following file transfer protocols:
   + Secure Shell (SSH) File Transfer Protocol (SFTP) – file transfer over SSH

     For more information about SFTP, see [Create an SFTP-enabled server](create-server-sftp.md).
   + File Transfer Protocol Secure (FTPS) – file transfer with TLS encryption

     For more information about FTP, see [Create an FTPS-enabled server](create-server-ftps.md).
   + File Transfer Protocol (FTP) – unencrypted file transfer

     For more information about FTPS, see [Create an FTP-enabled server](create-server-ftp.md).
**Note**  
If you have an existing server enabled only for SFTP, and you want to add FTPS and FTP, you must ensure that you have the right identity provider and endpoint type settings that are compatible with FTPS and FTP.  
![\[\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-protocols.png)

   If you select **FTPS**, you must choose a certificate stored in AWS Certificate Manager (ACM) which will be used to identify your server when clients connect to it over FTPS.

   To request a new public certificate, see [Request a public certificate](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) in the *AWS Certificate Manager User Guide*.

   To import an existing certificate into ACM, see [Importing certificates into ACM](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) in the *AWS Certificate Manager User Guide*.

   To request a private certificate to use FTPS through private IP addresses, see [Requesting a private certificate](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html) in the *AWS Certificate Manager User Guide*.

   Certificates with the following cryptographic algorithms and key sizes are supported:
   + 2048-bit RSA (RSA\$12048)
   + 4096-bit RSA (RSA\$14096)
   + Elliptic Prime Curve 256 bit (EC\$1prime256v1)
   + Elliptic Prime Curve 384 bit (EC\$1secp384r1)
   + Elliptic Prime Curve 521 bit (EC\$1secp521r1)
**Note**  
The certificate must be a valid SSL/TLS X.509 version 3 certificate with FQDN or IP address specified and contain information about the issuer.

1. Choose **Save**. You are returned to the **Server details** page.

## Edit the server endpoint
<a name="edit-endpoint-configuration"></a>

On the AWS Transfer Family console, you can modify the server endpoint type and custom hostname. Additionally, for VPC endpoints, you can edit the availability zone information.

**To edit the server endpoint details**

1. On the **Server details** page, choose **Edit** next to **Endpoint details**.

1. Before you can edit the **Endpoint type**, you must first stop the server. Then, on the **Edit endpoint configuration** page, for **Endpoint type**, you can choose either of the following values:
   + **Public** – This option makes your server accessible over the internet.
   + **VPC ** – This option makes your server accessible in your virtual private cloud (VPC). For information about VPC, see [Create a server in a virtual private cloud](create-server-in-vpc.md).

1. For **Custom hostname**, choose one of the following:
   + **None** – If you don't want to use a custom domain, choose **None**.

     You get a server hostname provided by AWS Transfer Family. The server hostname takes the form `serverId.server.transfer.regionId.amazonaws.com`.
   + **Amazon Route 53 DNS alias** – To use a DNS alias automatically created for you in Route 53, choose this option.
   + **Other DNS** – To use a hostname that you already own in an external DNS service choose **Other DNS**.

   Choosing **Amazon Route 53 DNS alias** or **Other DNS** specifies the name resolution method to associate with your server's endpoint.

   For example, your custom domain might be `sftp.inbox.example.com`. A custom hostname uses a DNS name that you provide and that a DNS service can resolve. You can use Route 53 as your DNS resolver, or use your own DNS service provider. To learn how AWS Transfer Family uses Route 53 to route traffic from your custom domain to the server endpoint, see [Working with custom hostnames](requirements-dns.md).  
![\[The Edit endpoint configuration console page.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-endpoint-configuration.png)

1. For VPC endpoints, you can change the information in the **Availability Zones** pane.

1. Choose **Save**. You are returned to the **Server details** page.

## Edit your logging configuration
<a name="edit-CloudWatch-logging"></a>

On the AWS Transfer Family console, you can change your logging configuration.

**Note**  
If Transfer Family created a CloudWatch logging IAM role for you when you created a server, the IAM role is called `AWSTransferLoggingAccess`. You can use it for all your Transfer Family servers.

**To edit your logging configuration**

1. On the **Server details** page, choose **Edit** next to **Additional details**.

1. Based on your configuration, choose between a logging role, structured JSON logging, or both. For more information, see [Updating logging for a server](log-server-manage.md#log-server-update).

## Edit the security policy
<a name="edit-cryptographic-algorithm"></a>

This procedure explains how to change a Transfer Family server's security policy by using the AWS Transfer Family console or AWS CLI.

**Note**  
If your endpoint is FIPS-enabled, you can't change the FIPS security policy to a non-FIPS security policy.

------
#### [ Console ]

**To edit the security policy by using the console**

1. On the **Server details** page, choose **Edit** next to **Additional details**.

1. In the **Cryptographic algorithm options** section, choose a security policy that contains the cryptographic algorithms enabled for use by your server.

   For more information about security policies, see [Security policies for AWS Transfer Family servers](security-policies.md).

1. Choose **Save**.

    You are returned to the **Server details** page where you can see the updated security policy.

------
#### [ AWS CLI ]

**To edit the security policy by using the CLI**

1. Run the following command to view the current security policy that is attached to your server.

   ```
   aws transfer describe-server --server-id your-server-id
   ```

   This `describe-server` command returns all of the details for your server, including the following line:

   ```
   "SecurityPolicyName": "TransferSecurityPolicy-2018-11"
   ```

   In this case, the security policy for the server is `TransferSecurityPolicy-2018-11`.

1. Make sure to provide the exact name of the security policy to the command. For example, run the following command to update the server to `TransferSecurityPolicy-2023-05`.

   ```
   aws transfer update-server --server-id your-server-id --security-policy-name "TransferSecurityPolicy-2023-05"
   ```
**Note**  
The names of the available security policies are listed in [Security policies for AWS Transfer Family servers](security-policies.md).

If successful, the command returns the following code, and updates your server's security policy.

```
{
    "ServerId": "your-server-id"
}
```

------

## Change the managed workflow for your server
<a name="configuring-servers-change-workflow"></a>

On the AWS Transfer Family console, you can change the managed workflow associated with the server.

**To change the managed workflow**

1. On the **Server details** page, choose **Edit** next to **Additional details**.

1. On the **Edit additional details** page, in the **Managed workflows** section, select a workflow to be run on all uploads.
**Note**  
If you do not already have a workflow, choose **Create a new workflow** to create one.

   1. Select the workflow ID to use. 

   1. Choose an execution role. This is the role that Transfer Family assumes when executing the workflow's steps. For more information, see [IAM policies for workflows](workflow-execution-role.md). Choose **Save**.  
![\[The Managed workflows console section.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/workflows-addtoserver.png)

1. Choose **Save**. You are returned to the **Server details** page.

## Change the display banners for your server
<a name="configuring-servers-change-banner"></a>

On the AWS Transfer Family console, you can change the display banners associated with the server.

**To change the display banners**

1. On the **Server details** page, choose **Edit** next to **Additional details**.

1. On the **Edit additional details** page, in the **Display banners** section, enter text for the available display banners.

1. Choose **Save**. You are returned to the **Server details** page.

## Put your server online or offline
<a name="edit-online-offline"></a>

On the AWS Transfer Family console, you can bring your server online or take it offline.

**To bring your server online**

1. Open the AWS Transfer Family console at [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. In the navigation pane, choose **Servers**.

1. Select the check box of the server that is offline.

1. For **Actions**, choose **Start**.

It can take a couple of minutes for a server to switch from offline to online.

**Note**  
When you stop a server to take it offline, currently you are still accruing service charges for that server. To eliminate additional server-based charges, delete that server.

**To take your server offline**

1. Open the AWS Transfer Family console at [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. In the navigation pane, choose **Servers**.

1. Select the check box of the server that is online.

1. For **Actions**, choose **Stop**.

While a server is starting up or shutting down, servers aren't available for file operations. The console doesn't show the starting and stopping states.

If you find the error condition `START_FAILED` or `STOP_FAILED`, contact AWS Support to help resolve your issues.

# Edit identity provider configuration
<a name="configuring-servers-edit-custom-idp"></a>

You can change your server's identity provider type from any type to any other type. The available identity provider types are:
+ **Service managed** – Store user credentials within the service
+ **AWS Directory Service** – Use AWS Managed Microsoft AD or AWS Directory Service for Entra ID Domain Services
+ **Custom** – Use Lambda function or Amazon API Gateway to integrate with your existing identity provider

When changing identity provider types, you need to provide specific information depending on the transition you're making. The following sections describe the required information for each type of change.

**Important**  
Considerations when changing identity providers:  
**User migration** – When changing identity provider types, existing user configurations are not automatically migrated. You'll need to set up users in the new identity provider system.
**Testing** – Test the new identity provider configuration thoroughly before making the change in production environments.
**Permissions** – Ensure that the new identity provider has the necessary IAM permissions and roles configured before making the change.

## Changing to service-managed identity provider
<a name="change-to-service-managed"></a>

When changing from any other identity provider type to service-managed, you need to:
+ Select **Service managed** as the identity provider type
+ Create new users directly in AWS Transfer Family after the change is complete, as existing user configurations from other identity providers won't be transferred

Example: If you're changing from a custom identity provider to service-managed, you'll need to recreate all user accounts and their associated permissions within the AWS Transfer Family service.

## Changing to AWS Directory Service
<a name="change-to-directory-service"></a>

When changing from any other identity provider type to AWS Directory Service, you need to provide:
+ **Directory** – Select an existing AWS Managed Microsoft AD or AWS Directory Service for Entra ID Domain Services directory
+ **Access** – Choose whether to restrict access to a specific group or allow access to all users in the directory
+ **Access role** – An IAM role that allows AWS Transfer Family to access your directory

Example: If you're changing from service-managed to AWS Directory Service, you would select your existing `d-1234567890` directory, choose to restrict access to the `TransferUsers` group, and specify the `TransferDirectoryAccessRole` IAM role.

## Changing to custom identity provider
<a name="change-to-custom-idp"></a>

When changing from any other identity provider type to a custom identity provider, you need to choose between Lambda function or Amazon API Gateway and provide the required configuration:

### Using Lambda function
<a name="change-to-lambda-idp"></a>

For Lambda function integration, provide:
+ **Function** – Select an existing Lambda function that handles authentication
+ **Authentication method** (for SFTP protocol) – Choose password, public key, or both

Example: If you're changing from AWS Directory Service to a custom Lambda identity provider, you would select your `TransferCustomAuth` function and choose **Password** as the authentication method.

![\[For a Lambda identity provider, you can change the underlying Lambda function.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-idp-lambda.png)


### Using Amazon API Gateway
<a name="change-to-api-gateway-idp"></a>

For Amazon API Gateway integration, provide:
+ **API Gateway URL** – The invoke URL of your API Gateway endpoint
+ **Invocation role** – An IAM role that allows AWS Transfer Family to invoke your API Gateway
+ **Authentication method** (for SFTP protocol) – Choose password, public key, or both

Example: If you're changing from service-managed to API Gateway, you would provide the URL `https://abcdef123.execute-api.us-east-1.amazonaws.com/prod`, specify the `TransferApiGatewayInvocationRole` IAM role, and choose **Public key** as the authentication method.

![\[For an API Gateway identity provider, you can update the Gateway URL or the invocation role, or both.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-server-idp-apigateway.png)


### Changing from Amazon API Gateway to Lambda function
<a name="change-api-gateway-to-lambda"></a>

A common transition is changing from Amazon API Gateway to Lambda function for custom identity provider integration. This change allows you to simplify your architecture while maintaining the same authentication logic.

Key considerations for this transition:
+ **Same function, different permissions** – You can use the same Lambda function for both API Gateway and direct Lambda integration, but the resource policy must be updated.
+ **Resource policy requirements** – When changing to direct Lambda integration, the function's resource policy must grant `transfer.amazonaws.com` permission to invoke the function, in addition to `apigateway.amazonaws.com`.

**To make this change**

1. Update your Lambda function's resource policy to allow `transfer.amazonaws.com` to invoke the function.

1. In the AWS Transfer Family console, change the identity provider from API Gateway to Lambda function.

1. Select your existing Lambda function.

1. Test the configuration to ensure authentication works correctly.

Example resource policy for direct Lambda integration:

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement": [{
      "Effect": "Allow",
      "Principal": {
         "Service": [
            "transfer.amazonaws.com",
            "apigateway.amazonaws.com"
         ]
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:function-name"
   }]
}
```

## User preservation during identity provider transitions
<a name="user-preservation-during-transitions"></a>

When changing between identity provider types, existing user configurations are preserved in specific scenarios to enable efficient rollback in case of issues:
+ **Service-managed to custom identity provider and back** – If you change from service-managed to a custom identity provider and then back to service-managed, all users are preserved in their last known configuration.
+ **AWS Directory Service to custom identity provider and back** – If you change from AWS Directory Service to a custom identity provider and then back to AWS Directory Service, all definitions for Delegated Access groups are retained in their last known configuration.

This preservation behavior allows you to safely test custom identity provider configurations and roll back to your previous setup without losing user access configurations.

## Important considerations when changing identity providers
<a name="identity-provider-considerations"></a>
+ **User migration** – When changing identity provider types, existing user configurations are not automatically migrated. You'll need to set up users in the new identity provider system.
+ **Testing** – Test the new identity provider configuration thoroughly before making the change in production environments.
+ **Permissions** – Ensure that the new identity provider has the necessary IAM permissions and roles configured before making the change.

# Manage host keys for your SFTP-enabled server
<a name="configuring-servers-change-host-key"></a>

Server host keys are private keys used by the Transfer Family server to provide a unique identity to the caller, and to guarantee that it is the correct server. That guarantee is enforced by the presence of the correct public key in the caller's `known_hosts` file. (The `known_hosts` file is a standard feature used by most SSH clients to store the public keys for the servers that you've connected to.) You can retrieve the public key that corresponds to your server host key by running `ssh-keyscan` for your server.

**Important**  
Accidentally changing a server's host key can be disruptive. Depending on how your SFTP client is configured, it can fail immediately, with the message that no trusted host key exists, or present threatening prompts. If there are scripts for automating connections, they most likely would fail as well.

By default, AWS Transfer Family generates host keys for your SFTP-enabled server. You can import server host keys to preserve host identity and avoid updating client trust stores. [When to import host keys](#host-key-import-use-cases) lists a few reasons you might want to do this. If you do not provide host keys, new ones will be generated for you.

AWS Transfer Family supports multiple host keys of different types (RSA, ECDSA, and ED25519) to provide compatibility with a broader range of client host signature algorithms. Different key types enable specific algorithms: RSA keys enable **rsa-\$1** algorithms, ECDSA keys enable **ecdsa-\$1** algorithms, and ED25519 keys enable **ed25519** algorithms. Plan your key types at server creation time, as introducing additional key types after clients have started interacting with the server can be disruptive for some clients and may be as problematic as replacing existing host keys.

To prevent your users from being prompted to verify the authenticity of your SFTP-enabled server again, import the host key for your on-premises server to the SFTP-enabled server. Doing this also prevents your users from getting a warning about a potential man-in-the-middle attack.

You can also rotate host keys periodically, as an additional security measure. For details, see [Rotate the server host keys](server-host-key-rotate.md).

**Note**  
Server host keys are used by servers that support the SFTP protocol.

## When to import host keys
<a name="host-key-import-use-cases"></a>

While AWS Transfer Family can generate host keys automatically, there are several scenarios where importing your own host keys provides operational benefits:
+ *Server migration* - You're migrating from an existing server to AWS Transfer Family and want to avoid updating client trust stores (`known_hosts` files) for existing clients.
+ *Disaster recovery and failover* - You have multiple AWS Transfer Family servers (for example, one in US East (Ohio) and one in US West (Oregon)) that share the same public DNS name. Using the same host keys on both servers ensures seamless failover without client authentication failures.
+ *Operational continuity* - You want the host key material available for use with other servers (AWS Transfer Family or otherwise) in the future to maintain consistent server identity across your infrastructure.
+ *Algorithm control* - You want greater client compatibility by providing more Host Key Algorithms, or you want to control which algorithms clients can use by only offering keys compatible with specific algorithms.

The following topics provide detailed procedures for managing server host keys:
+ [Add an additional server host key](server-host-key-add.md) - Add additional host keys to your server
+ [Delete a server host key](server-host-key-delete.md) - Remove host keys from your server
+ [Rotate the server host keys](server-host-key-rotate.md) - Rotate host keys for enhanced security
+ [Additional server host key information](server-host-key-other.md) - View and manage host key details

# Add an additional server host key
<a name="server-host-key-add"></a>

On the AWS Transfer Family console, you can add additional server host keys. Adding additional host keys of differing formats can be useful for identifying a server when clients connect to it, as well as improving your security profile. For example, if your original key is an RSA key, you could add an additional ECDSA key.

**Note**  
The SFTP client will connect using the oldest key in the configuration that matches the key's algorithm. The oldest key for each key type (RSA, ECDSA, or ED25519) is the active key for the server for that type.

**Security note when a Transfer Family server has multiple types of host keys**  
If a server has multiple types of host keys, the SFTP client can assign a preference by type. So, when there exist RSA, ECDSA, and ED25519 host keys for the server, the choice is driven by the preference by type.

Modern SFTP clients prefer ECDSA and ED25519 host keys when they exist. This becomes important if you want to add an ECDSA or ED25519 key when the server previously only had RSA keys. The addition of the new ECDSA or ED25519 key would potentially manifest as a security warning for a client.

To the client, the key will appear as having changed, when in fact it was not changed: the new key was added in addition to the existing RSA key. Keep this in mind if you decide to add new types of server host keys.

**To add an additional server host key**

1. Open the AWS Transfer Family console at [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. In the left navigation pane, choose **Servers**, and then choose a server that uses the SFTP protocol.

1. On the server details page, scroll down to the **Server host keys** section.  
![\[The Server host keys console section.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/server-host-keys.png)

1. Choose **Add host key**.

   The **Add server host key** page displays.

1. In the **Server Host Key** section, enter an RSA, ECDSA, or ED25519 private key that is used to identify your server when clients connect to it over the SFTP-enabled server.
**Note**  
When you create a server host key, make sure to specify `-N ""` (no passphrase). See [Creating SSH keys on macOS, Linux, or Unix](macOS-linux-unix-ssh.md) for details on how to generate key pairs.

1. (Optional) Add a description to differentiate among multiple server host keys. You can also add tags for your key.

1. Choose **Add key**. You are returned to the **Server details** page.

To add a host key by using the AWS Command Line Interface (AWS CLI), use the [ImportHostKey](https://docs.aws.amazon.com/transfer/latest/APIReference/API_ImportHostKey) API operation and provide the new host key. If you create a new SFTP-enabled server, you provide your host key as a parameter in the [CreateServer](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateServer) API operation. You can also use the AWS CLI to update the description for an existing host key.

The following example `import-host-key` AWS CLI command imports a host key for the specified SFTP-enabled server.

```
aws transfer import-host-key --description key-description --server-id your-server-id --host-key-body file://my-host-key 
```

# Delete a server host key
<a name="server-host-key-delete"></a>

On the AWS Transfer Family console, you can delete a server host key.

**To delete a server host key**

1. Open the AWS Transfer Family console at [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. In the left navigation pane, choose **Servers**, and then choose a server that uses the SFTP protocol.

1. On the server details page, scroll down to the **Server host keys** section.  
![\[The Server host keys console section.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/server-host-keys.png)

1. In the **Server Host Keys** section, select a key, and then under **Actions**, choose **Delete**.

1. In the confirmation dialog box that appears, enter the word **delete**, and then choose **Delete** to confirm that you want to delete the host key.

The host key is deleted from the **Servers** page.

To delete the host key by using the AWS CLI, use the [https://docs.aws.amazon.com/transfer/latest/APIReference/API_DeleteHostKey](https://docs.aws.amazon.com/transfer/latest/APIReference/API_DeleteHostKey) API operation and provide the server ID and host key ID.

The following example `delete-host-key` AWS CLI command deletes a host key for the specified SFTP-enabled server.

```
aws transfer delete-host-key --server-id your-server-id --host-key-id your-host-key-id
```

# Rotate the server host keys
<a name="server-host-key-rotate"></a>

Periodically, you can rotate your server host key. This topic describes how the server chooses which key to apply, and the procedure for rotating these keys.

## How the client chooses a server host key
<a name="server-key-behavior"></a>

The way that Transfer Family chooses which server key to apply depends on conditions for the SFTP client, as explained here. The assumption is that there is one older key and one newer key.
+ An SFTP client has no prior public host key for the server. The first time the client connects to the server, either of the following occurs:
  + The client fails the connection, if it is configured to do so.
  + Or, the client chooses the first key that matches the possible available algorithms and asks the user if that key can be trusted. If so, the client auto-updates the `known_hosts` file (or whatever local configuration file or resource the client uses to record trust decisions) and enters that key.
+ An SFTP client has an older key in its `known_hosts` file. The client prefers to use this key, even if a newer key exists, either for this key's algorithm or another algorithm. This is because the client has a higher level of trust for the key that is in its `known_hosts` file.
+ An SFTP client has the new key (in any of the available algorithms) in its `known_hosts` keys file. The client ignores older keys because they are not trusted and uses the new key.
+ An SFTP client has both keys in its `known_hosts` file. The client chooses the first key by index that matches the list of available keys offered by the server.

Transfer Family prefers that the SFTP client has all of the keys in its `known_hosts` file, since this allows the most flexibility when connecting to a Transfer Family server. Key rotation is based on the fact that multiple entries can exist in the `known_hosts` file for the same Transfer Family server.

## Rotate the server host key procedure
<a name="server-key-rotate-procedure"></a>

As an example, assume that you have added the following set of server host keys to your Transfer Family server.


**Server host keys**  

| Host key type | Date added to the server | 
| --- | --- | 
| RSA | April 1, 2020 | 
| ECDSA | February 1, 2020 | 
| ED25519 | December 1, 2019 | 
| RSA | October 1, 2019 | 
| ECDSA | June 1, 2019 | 
| ED25519 | March 1, 2019 | 

**To rotate the server host key**

1. Add a new server host key. This procedure is described in [Add an additional server host key](server-host-key-add.md).

1. Delete one or more of the host keys of the same type that you had added previously. This procedure is described in [Delete a server host key](server-host-key-delete.md).

1. All keys are visible, and can be active, subject to the behavior described previously in [How the client chooses a server host key](#server-key-behavior).

# Additional server host key information
<a name="server-host-key-other"></a>

You can select a host key to display details for that key.

![\[The hostkey details console screen.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/server-host-keys-details.png)


You can delete a host key, or edit its description from the **Actions** menu on the Server details screen. Select the host key, then choose the appropriate action from the menu.

![\[The server hostkey Actions menu.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/server-host-keys-actions.png)


# Monitoring usage in the console
<a name="monitor-usage-transfer-console"></a>

 You can get information about your server's metrics on its **Server details** page. This provides you with a single place to monitor your file-transfers workloads. You can track how many files you have exchanged with your partners and closely track their usage using a centralized dashboard. For details, see [View SFTP, FTPS, and FTP server details](configuring-servers-view-info.md). The following table describes the metrics available for Transfer Family. 

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/transfer/latest/userguide/monitor-usage-transfer-console.html)

 The **Monitoring** section contains four, individual graphs. These graphs show the bytes in, bytes out, files in, and files out. 

![\[The Monitoring console section showing the BytesIn, BytesOut, FilesIn, and FilesOut graphs.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/metrics.png)


For servers that have the AS2 protocol enabled, there is an **AS2 Monitoring** section below the **Monitoring** information. This section contains details for the number of inbound messages, both successful and failed.

![\[The AS2 Monitoring console section showing the InboundMessages, and InboundMessagesFailed details.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/as2-metrics-inbound.png)


 To open the selected graph in its own window, choose the expand icon (![\[Expand icon\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/expand.png)). You can also click a graph's vertical ellipsis icon (![\[Vertical ellipsis icon\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/vertical-ellipsis.png)) to open a dropdown menu with the following items: 
+ **Enlarge** – Opens the selected graph in its own window.
+ **Refresh** – Reloads the graph with the most recent data.
+ **View in metrics** – Opens the corresponding metrics details in Amazon CloudWatch.
+ **View logs** – Opens the corresponding log group in CloudWatch.