[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for Valkey™](../index.md) > [Concepts](index.md) > Networking in Yandex Managed Service for Valkey™

# Yandex Managed Service for Valkey™ network and DB clusters


When creating a cluster, you can:

* Specify a network for the entire cluster.
* Specify subnets for each host in the cluster.
* Enable TLS support to connect to the cluster from outside Yandex Cloud.


## Host name and FQDN {#hostname}

Yandex Managed Service for Valkey™ generates a name for each cluster host when it is created. This name will be the host's fully qualified domain name (FQDN). You cannot change the host name and, consequently, FQDN.

To learn how to get a host FQDN, see [this guide](../operations/connect/fqdn.md).


You can use the FQDN to connect to the host from the cloud network or over the internet.

## Public access to {#public-access-to-host} cluster hosts

If you create a Yandex Managed Service for Valkey™ cluster with TLS support, you can connect to it both from a Yandex Cloud VM and from the internet.

If you created a cluster without TLS support, you can only connect to it from a Yandex Cloud VM on the same cloud network. You cannot enable public access to a host in this type of cluster.

Any host in a cluster with TLS support enabled can be accessible from outside Yandex Cloud if you requested public access when [creating](../operations/hosts.md#add) or [modifying](../operations/hosts.md#update) the host.

You cannot update a public IP address after creating a host; however, you can replace an existing host with a new one that has a public IP address.

When deleting a publicly accessible host, the assigned IP address is revoked.

## Using FQDNs instead of IP addresses {#fqdn-ip-setting}

Valkey™ uses host IP addresses, not their [FQDNs](#hostname). If a Yandex Managed Service for Valkey™ cluster supports TLS, this prevents connection to Valkey™ hosts in the following situations:

* The [Valkey™](supported-clients.md) client connects to a host via SSL and requests to verify the host's FQDN against the certificate.

    The certificate contains the host's FQDN, not its IP address, so this verification will fail.

* Public access is enabled for the host.

    Valkey™ returns the host's internal IP address, even if public access is enabled for that host. Such an IP address is not accessible from the internet.

Enable the setting that allows FQDNs to replace IP addresses. You can do this when [creating](../operations/cluster-create.md) or [updating](../operations/update.md#configure-fqdn-ip-behavior) any Yandex Managed Service for Valkey™ cluster; however, this setting is typically used in clusters with TLS support to bypass the above limitations.

{% note info %}

Some clients do not support this setting and will fail to connect to the cluster hosts. They expect an IP address and will produce errors if you provide an FQDN instead.

{% endnote %}

> **Example of how this works**
>
> In non-sharded Yandex Managed Service for Valkey™ clusters, Sentinel is often used to get the address of the Valkey™ master host. Since Sentinel gets the address from Valkey™ itself, the result will vary depending on whether the **Use FQDN instead of IP addresses** option is enabled.
>
> Let's assume a cluster has a Valkey™ master host with `rc1a-goh2a9tr********.mdb.yandexcloud.net` for FQDN and `10.0.0.222` for internal IP address. The host address returned by Sentinel will look like this:
>
> * Option disabled: `10.0.0.222:6379`
> * Option enabled: `rc1a-goh2a9tr********.mdb.yandexcloud.net:6379`

## Security groups {#security-groups}

[Security groups](../../vpc/concepts/security-groups.md) follow the rule that all traffic is denied unless you explicitly allow it. To connect to a cluster, configure security group rules. These rules allow traffic from certain ports, IP addresses, or other security groups. For example, a VM will not be able to connect to a cluster in the following cases:

* The VM is in the `10.128.0.0/16` subnet, whereas the inbound rules only allow `10.133.0.0/24`.
* The VM is in the `10.133.0.0/24` subnet but attempts to access a port not exposed in the security group rules.

For information on how to configure security groups, see [Configuring security groups](../operations/connect/index.md#configure-security-groups).

{% note tip %}

When connecting to a cluster from its cloud network, configure security groups both for the cluster and the connecting host.

{% endnote %}

Features of using security groups:

- Even if the cluster and host share the same security group, you still need rules allowing traffic between them to be able to connect to the cluster from the host. By default, such rules are included in the security group created along with the cloud network. These are the `Self` rules that allow unlimited traffic within the security group.

- Security group settings only determine whether connecting to the cluster is possible. They do not affect cluster features, such as replication, sharding, and backups.

For more information, see [this Virtual Private Cloud article](../../vpc/concepts/security-groups.md).


## Use cases {#examples}

* [Using a Yandex Managed Service for Valkey™ cluster as a PHP session storage](../tutorials/valkey-as-php-sessions-storage.md)
* [Migrating a database from a third-party Valkey™ cluster](../tutorials/data-migration.md)