diff --git a/menu/navigation.json b/menu/navigation.json index d8e0fdf192..ccd50f2c3a 100644 --- a/menu/navigation.json +++ b/menu/navigation.json @@ -2712,6 +2712,10 @@ { "label": "Understanding routing", "slug": "understanding-routing" + }, + { + "label": "Getting the most from Private Networks", + "slug": "getting-most-private-networks" } ], "label": "Additional Content", @@ -2788,7 +2792,17 @@ ], "label": "API/CLI", "slug": "api-cli" - } + }, + { + "items": [ + { + "label": "Public connectivity: best practices", + "slug": "public-connectivity-best-practices" + } + ], + "label": "Additional Content", + "slug": "reference-content" + } ], "label": "IPAM", "slug": "ipam" diff --git a/network/ipam/reference-content/index.mdx b/network/ipam/reference-content/index.mdx new file mode 100644 index 0000000000..55c52f78b1 --- /dev/null +++ b/network/ipam/reference-content/index.mdx @@ -0,0 +1,8 @@ +--- +meta: + title: IPAM - Additional content + description: IPAM additional content +content: + h1: IPAM - Additional content + paragraph: IPAM additional content +--- diff --git a/network/ipam/reference-content/public-connectivity-best-practices.mdx b/network/ipam/reference-content/public-connectivity-best-practices.mdx new file mode 100644 index 0000000000..85f2430346 --- /dev/null +++ b/network/ipam/reference-content/public-connectivity-best-practices.mdx @@ -0,0 +1,117 @@ +--- +meta: + title: Public connectivity - best practices + description: Discover essential best practices for securing and optimizing public connectivity in your Scaleway cloud environment. Learn how to enhance performance and ensure robust protection. +content: + h1: Public connectivity - best practices + paragraph: Discover essential best practices for securing and optimizing public connectivity in your Scaleway cloud environment. Learn how to enhance performance and ensure robust protection. +tags: flexible-ip public-ip private-network connectivity best-practice +dates: + validation: 2024-09-30 + posted: 2024-09-30 +categories: + - network +--- + +This document sets out best practices for securing and optimizing public connectivity for your Scaleway resources. + +## Public vs private connectivity + +Public vs private connectivity defines how resources are accessed and exposed over networks. + +- **Public connectivity**: Your resource has a [public IP address](/network/ipam/concepts/#public-flexible-ip-address) and is reachable over the public internet. Anyone with the right credentials can access the resource via its public IP address, e.g. over an [SSH connection](/compute/instances/how-to/connect-to-instance/) or simply by directly accessing its IP address in a browser to retrieve and display any content it is serving, e.g. over HTTP. +- **Private connectivity**: Your resources is reachable over an attached [Private Network](/network/vpc/concepts/#private-networks). The resource has a [private IP address](/network/vpc/concepts/#private-ip-address), but it can only be accessed via this address from within the VPC of the Private Network. Such a resource may or may not also have a public IP address. + +## Effectively managing IP addresses + +### Flexible IP addresses: definition + +Public connectivity for **Instances**, **Elastic Metal**, **Load Balancers** and **Public Gateways** is facilitated by a [flexible IP address](/network/ipam/concepts/#public-flexible-ip-address). + +- A flexible IP address is a public IP address that you can attach and detach from the resource at will. +- If you detach it, it returns to the pool of flexible IP addresses kept in your account for that product, and you can attach it to a different resource (or reattach it to the same one as before). +- Flexible IP addresses are scoped to a single product and a single Availability Zone (AZ). If you create a flexible IP address for an Instance in PAR-2, you can move it to a different Instance in PAR-2, but not to an Instance in PAR-1, nor to an Elastic Metal server in any AZ. + +Other resource types generally facilitate public connectivity in other ways, e.g. via public endpoints that cannot be modified by the user. Public connectivity may be mandatory with no option to deactivate (e.g. for Apple Silicon), or optional (e.g. for Managed Database). See the specific documentation for the product in question to find out more. + +### Exploiting the benefits of flexible IPs + +As flexible IP addresses can be moved between resources, they provide the following advantages: + +- **Seamless failover and disaster recovery**: If your Instance, for example, goes down, you can move its public IP to a different Instance in the same AZ to ensure the service remains available. +- **Zero downtime during maintenance and migration**: When you need to carry out updates, migrations or maintenance on a resource, you can temporarily move its public IP to a backup resource to avoid disruption for users. +- **IP retention and consistent endpoints**: Maintaining the same IP avoids the need for frequent DNS or firewall rule updates, and makes it easier to manage your dynamic cloud environments. + +In the future, look out for even more improvements to our flexible IP offering, such as the ability to move flexible IPs between different types of products, and to manage all your public flexible IPs from your [IPAM](/network/ipam/) dashboard. + +### Limiting public connectivity, prioritizing Private Networks + +We strongly recommend that you disable public connectivity on all of your Scaleway resources, unless it is absolutely required. Attaching resources to Private Networks, and limiting their communication to these networks brings the following advantages: + +- **Minimized attack surface**: Without a public IP address, the resource is not exposed directly to the internet, decreasing the risk of DDoS or brute force attacks, or unauthorized access. +- **Reduced cost**: Public (flexible) IP addresses are [billed](https://www.scaleway.com/en/pricing/), whereas Private Networks and the private IP addresses that attach resources to Private Networks are free of charge (except for Elastic Metal servers). +- **Improved latency**: Communication between resources over a Private Network is generally faster, as it does not need to be routed through the public internet. + +Depending on the resource type, public connectivity can be disabled by: +- Toggling off **Public connectivity** when creating the resource +- Detaching an existing flexible IP address (after resource creation) +- Deactivating public connectivity (after resource creation) + + +For some products, e.g. Apple Silicon, public connectivity cannot be disabled at any stage, and for other resources, eg Managed Databases for Redis, public connectivity options cannot be modified after resource creation. Check the documentation for your specific product to learn more. + + +Favor resources such as Public Gateways and Load Balancers to provide access to the public internet over the Private Network. This allows Instances and other attached resources to send and receive packets to the internet through a single, secure point of access. You can use the Public Gateway's SSH bastion feature to [connect to your resource via its private IP address](/network/public-gateways/how-to/use-ssh-bastion/#how-to-connect-to-a-resource-behind-your-ssh-bastion). + +Find out more about how to get the most from Private Network in our [dedicated documentation](/network/vpc/reference-content/getting-most-private-networks/) + +## Implementing security controls + +Different products offer different security features and controls to help place limits and restrictions on the traffic arriving over your resource's public interface. We strongly recommend that you implement all available measures to minimize security risk and optimize the security of your resource. Some of the available security controls are listed below. + +### Instances: Security groups + +[Security groups](/compute/instances/concepts/#security-group) act as firewalls, filtering public internet traffic on your Instances. They can be stateful or stateless, and allow you to create rules to drop or allow public traffic to and from your Instance. [Find out how to create and configure security groups](/compute/instances/how-to/use-security-groups/). + +### Load Balancers: ACLs + + + +Learn how to use the ACL feature in our [dedicated how-to](/network/load-balancer/how-to/create-manage-acls/) and go deeper with our [reference documentation](/network/load-balancer/reference-content/acls/). + +### Other controls + +For resources such as Instances and Elastic Metal servers, you may wish to implement third-party manual solutions in front of your public services to enhance security, for example: + +- Deploying a reverse proxy, e.g. Nginx (/tutorials/nginx-reverse-proxy/), and configuring it to enforce rate limits and to throttle traffic. This helps to prevent abuse and DDOS attacks on your public-facing services. +- Installing a **W**eb **A**pplication **F**irewall that can filter out malicious traffic such as requests containing attack patterns, or requests from blacklisted IPs. + +## Handling traffic surges + +Exposing your resource to the public internet can present risks of unexpected traffic surges. These may be malicious DDoS attacks, or legitimate surges that are simply the result of high demand. If correct mechanisms are not put in place to deal with high load, you risk facing downtime, service unavailability and performance degradation. A number of possibilities exist to help you handle this scenario: + +### Autoscaling + +Scaleway currently offers Autoscaling in Public Beta. Autoscaling allows you to dynamically adjust the number of Instances within a given Instance group based on defined scaling policies. Scaling actions (scale up or down) are triggered when the monitored metric exceeds the configured thresholds from your policies. Check out the [API documentation](https://www.scaleway.com/en/developers/api/autoscaling/). + +### Load Balancer + +Placing a Scaleway Load Balancer in front of your backend servers allows you to expose multiple Instances through a single public IP. The Load Balancer distributes workload across the servers in the backend pool, ensurable scalable and continuously available applications, even during heavy traffic. You can manually add and remove servers from the backend pool as necessary, and configure the best balancing method for your particular needs. Find out more in the [Load Balancer documentation](/network/load-balancer/). + +### Edge Services + +Available for Load Balancers and Object Storage buckets, Scaleway Edge Services provides a caching service to reduce load on your origin. This means that content can be served directly to users from Edge Services' servers, instead of from your Load Balancer or Object Storage bucket. [Learn more about Edge Services](/network/edge-services/). + +### Kubernetes Kapsule + +Hosting your containerized application in a managed Kubernetes cluster brings many benefits in terms of scaling and managing fluctuating demand. Kubernetes can automatically adjust the number of running resources within defined limits, based on current demand. It also offers self-healing capabilities in the case of node failure. Find out more in the [Scaleway Kubernetes](/containers/kubernetes/) documentation. + +## Monitoring and alerting via Scaleway Cockpit + +We recommend that you use [Scaleway Cockpit](/observability/cockpit/) to monitor your resources. Cockpit stores metrics, logs and traces and provides a dedicated dashboarding system on Grafana for easy visualisation. Different metrics are available for different resource types, with metrics for network traffic being available for many, enabling you to monitor connections over the public interface. You can also configure managed and pre-configured alerts for your resources, to receive warnings for potentially abnormal behavior or unusual network activity. + +Read more about [Scaleway Cockpit](/observability/cockpit/). + + + + diff --git a/network/vpc/reference-content/assets/scaleway-vpc-osi.webp b/network/vpc/reference-content/assets/scaleway-vpc-osi.webp new file mode 100644 index 0000000000..911e0a8c57 Binary files /dev/null and b/network/vpc/reference-content/assets/scaleway-vpc-osi.webp differ diff --git a/network/vpc/reference-content/assets/scaleway-vpc-schema.webp b/network/vpc/reference-content/assets/scaleway-vpc-schema.webp new file mode 100644 index 0000000000..25adf4f1af Binary files /dev/null and b/network/vpc/reference-content/assets/scaleway-vpc-schema.webp differ diff --git a/network/vpc/reference-content/getting-most-private-networks.mdx b/network/vpc/reference-content/getting-most-private-networks.mdx new file mode 100644 index 0000000000..2872bf7e65 --- /dev/null +++ b/network/vpc/reference-content/getting-most-private-networks.mdx @@ -0,0 +1,124 @@ +--- +meta: + title: Getting the most from Private Networks + description: Optimize your Scaleway VPCs, Private Networks and resource connectivity with this guide which details tips and best practices. +content: + h1: Getting the most from Private Networks + paragraph: Optimize your Scaleway VPCs, Private Networks and resource connectivity with this guide which details tips and best practices. +tags: vpc private-network connectivity best-practice +dates: + validation: 2024-08-28 + posted: 2024-08-28 +categories: + - network +--- + +This document sets out guidance, advice and best practices for building and optimizing your Scaleway VPCs and Private Networks. + +## Private Networks and VPC definitions + +VPC allows you to build your own **V**irtual **P**rivate **C**loud on top of Scaleway's shared public cloud. Within each VPC, you can create **Private Networks**. Resources attached to Private Networks can communicate securely between themselves, away from the public internet, reducing security risks by ensuring traffic is isolated from public routes. + +The VPC operates at the network layer (layer 3) of the OSI model, while Private Networks are a layer 2 resource. As such, a VPC is responsible for routing packets between its different Private Networks. Private Networks provide network isolation within a VPC and enable you to segment your resources and traffic across different subnets. + +VPCs and Private Networks are both **regional** resources. When you create a Private Network in a VPC, it is necessarily scoped to the same region as the VPC. Some Scaleway resources are also regional, others are zonal and scoped to a single Availability Zone (AZ). When attaching resources to a Private Network, you can attach resources from any AZ within the Private Network's region, allowing for example an Elastic Metal server in PAR-2 to communicate securely, away from the public internet, with an Instance in PAR-1 and a Managed Database in PAR-3. + + + +| Region | Availability Zones | +|-------------------------|---------------------------| +| France - Paris | PAR1, PAR2, PAR3 | +| Netherlands - Amsterdam | AMS1, AMS2, AMS3 | +| Poland - Warsaw | WAW1, WAW2, WAW3 | + +One default VPC for each region is automatically created in each Scaleway [Project](/identity-and-access-management/organizations-and-projects/concepts/#project). The [**VPC routing**](/network/vpc/concepts/#routing) feature allows for managed and custom routes between the Private Networks of a VPC, so resources on different Private Networks can communicate. + + + +## Designing your network topology + +When you start creating resources and building your infrastructure with Scaleway, take some time to consider and plan your network topology. We recommend that you build your VPC infrastructure with **separation of concerns** in mind. Separation of concerns is a fundamental design principle aimed at breaking down large complex systems into smaller, distinct components each with clear responsibilities and interfaces. This kind of design will future-proof your VPC and come into its own when Scaleway introduces further features such as ACLs for VPC. + + Separating resources into different Private Networks according to function and usage can: +- **Improve network performance** by reducing broadcast traffic and congestion +- **Enhance manageability** via a logical organization of resources +- **Enable easier troubleshooting, monitoring and maintenance** +- **Allow for easier scalability** + +For example, you may use one Private Network for frontend resources and another for backend resources, limiting public access only via Load Balancers and/or Public Gateways, stripping other resources of public IP addresses. You may want to create different VPCs for production and test environments, allowing you to isolate potential errors in testing from the production environment. + +When [creating a Private Network](/network/vpc/how-to/create-private-network/), you can let Scaleway automatically generate a CIDR block for it that is guaranteed to be unique in this VPC. All resources attached to the Private Network get a private IP address from this block. However, you also have the option to define your own CIDR block for the network. Ensure you choose a prefix and network size that is appropriate for your needs, does not overlap with that of any other Private Network in the VPC, and contains enough IP addresses for all resources that will be attached to the Private Network. + +## Attaching resources to Private Networks + +When you attach a resource (e.g. an Instance, an Elastic Metal server) to a Private Network, you can either: +- Let Scaleway automatically assign any IP address from the Private Network's CIDR block to use for the attachment, or +- Define a specific, reserved IP address from the CIDR block to use for the attachment. + +### Auto-assigning an IP address + +This solution is best for simplicity, dynamic environments, and short-lived resources. It can be especially useful in large-scale deployments where manual IP management could be cumbersome. When you let Scaleway automatically assign IP addresses, we ensure there are no IP conflicts within your VPC, reducing any risk of human error. + +Note that when you select this option, the IP address randomly assigned to the resource will be stable, and does not risk changing until you detach the resource from the Private Network. At this point, the private IP address is released back into the pool of generally available addresses from the network's CIDR block, and may be auto-assigned to another resource requesting attachment. + +### Using reserved IP addresses + +You can reserve private IP addresses from your Private Networks' CIDR blocks thanks to Scaleway's [**IP A**ddress **M**anagement solution](/network/ipam/), which helps you plan, track and manage the IP address space of your VPCs and their Private Networks. From the [IPAM space](https://console.scaleway.com/ipam/) in the Scaleway console, simply use the **Reserve private IP** feature to select the Private Network you want to reserve an IP address on, and choose to either reserve any available address, or a specific address not currently attached to any resource. The reserved address will then not risk being auto-assigned by Scaleway to other resources during network attachment, and can be kept until you are ready to use it to attach a specific resource. + +Further, when you attach a resource to a Private Network and specify a reserved IP to use, the IP will remain reserved even after you detach the resource from the network. You can choose to either release the IP back into the pool, or keep it reserved until you use it to attach another resource. + +Using reserved IP addresses is ideal to ensure that certain IP addresses are never released into the general pool and kept for certain critical resources with fixed IP requirements, even when that resource is detached from the Private Network, or when migrating between resources. Reserved IP addresses may also be useful where your Private Network is extending or integrating with external networks, or to assign addresses to virtual machines hosted on Elastic Metal servers via Proxmox. + +## Removing public IPs from resources + +We strongly recommend that you disable public connectivity on all of your Scaleway resources, unless it is absolutely required. It is preferable to attach resources to Private Networks wherever possible, and direct all traffic to the resource's private IP address on that network. This ensures optimal security, reduced cost and enhanced latency. Find out more in our documentation about [public connectivity best practices](/network/ipam/reference-content/public-connectivity-best-practices). + +## Public connectivity over Private Networks + +### Public Gateways + +You can use Scaleway [Public Gateways](/network/public-gateways/) to provide resources on a Private Network with a secure point of access to and from the public internet. + +- Set the Public Gateway to advertize a default route to the internet, allowing attached resources to send packets to the internet via the gateway, without needing their own public IP address. +- Activate the [SSH bastion](/network/public-gateways/how-to/use-ssh-bastion/) so that you can establish SSH connections to resources on the Private Network via the gateway's bastion. +- Use static NAT to map ingress traffic from the public internet towards resources on the Private Network, using private IP addresses and ports. + +### Load Balancers + +Another option is to attach a Scaleway [Load Balancer](/network/load-balancer/) to the Private Network. By giving the Load Balancer a public IP address, and configuring Instances on the Private Network as backend servers for the Load Balancer via their private IP addresses, the Load Balancer can securely and efficiently distribute traffic to the Instances. This solution is suitable when you have multiple Instances serving the same application, although you can also use multiple frontends/backends and [routes](/network/load-balancer/how-to/create-manage-routes/) to direct traffic to specific server pools. + +You can also disable public connectivity on the Load Balancer itself. This may be relevant if the Load Balancer is configured to receive and distribute traffic from resources on a different Private Network within the same VPC, for example. + +## Connecting a VPC to external infrastructure + +Watch this space for Scaleway's upcoming solution to provide private, secure connectivity between resources in a Scaleway VPC and your external or on-premises architecture. In the meantime, you may consider installing a manual VPN on a Scaleway Instance to connect to other non-Scaleway infrastructure, and create a [custom route](/network/vpc/how-to/manage-routing/#how-to-create-a-custom-route) towards this VPN so traffic on your Private Network can securely communicate with resources at the other end of your VPN tunnel. + +## Resource-specific information + +Different types of Scaleway resources may have different requirements and possibilities in terms of Private Networks. See the comparative table below for more information, and to jump to the resource-specific documentation on Private Networks for each product. + +* **Max attached PNs**: The maximum number of Private Networks that a resource can be attached to +* **Mandatory PN**: Whether or not a Private Network must necessarily be attached to this resource +* **Compatible with private IPv6**: Whether or not the resource is compatible with private IPv6 addressing. Compatible resources generally acquire both an IPv4 and an IPv6 address when attached to a Private Network. +* **Compatible with reserved IPs**: Whether or not you can use a [reserved IP](/network/ipam/how-to/reserve-ip/#how-to-attach-a-resource-to-a-private-network-using-a-reserved-ip-address/) to attach the resource to a Private Network + +| | Instance | Elastic Metal | Kubernetes | Managed Inference | +|------------------------------|----------|---------------|------------|-------------------| +| Max attached PNs | 8 | 8 | 1 | 1 | +| Mandatory PN | No | No | Yes | No | +| Compatible with private IPv6 | Yes | Yes | Yes | No | +| Compatible with reserved IPs | Yes | Yes | No | No | +| Additional information | -- | [Paid-for
feature](https://www.scaleway.com/en/pricing/elastic-metal/#network) | PN cannot be changed
after cluster creation | Must have at least one of
private and/or public endpoint | +| Documentation | [Go](/compute/instances/how-to/use-private-networks/) | [Go](/bare-metal/elastic-metal/how-to/use-private-networks/) | [Go](/containers/kubernetes/reference-content/secure-cluster-with-private-network/#why-have-a-private-network-for-your-kubernetes-kapsule-cluster) | [Go](/ai-data/managed-inference/how-to/managed-inference-with-private-network/) | + + +| | Managed Database | Managed Database for Redis™ | Public Gateways | Load Balancer | +|------------------------------|------------------|-----------------------------|-----------------|---------------| +| Max attached PNs | 1 | 1 | 8 | 8 | +| Mandatory PN | No | No | No | No | +| Compatible with private IPv6 | No | No | No | No | +| Compatible with reserved IPs | No | No | Yes | Yes | +| Additional information | Must have at least one of
private and/or public endpoint | Must have at least one of
private and/or public endpoint | -- | Private LBs must have a PN | +| Documentation | [Go](/managed-databases/postgresql-and-mysql/how-to/connect-database-private-network/) | [Go](/faq/databases-for-redis/#what-is-the-private-networks-feature-for-redistm-database-instances) | [Go](/network/public-gateways/how-to/configure-a-public-gateway/#how-to-attach-a-public-gateway-to-a-private-network) | [Go](/network/load-balancer/how-to/use-with-private-network/) + +