- About the web interface controls
- Always-on DDoS mitigation
- Browser recommendations when using the Fastly web interface
- Content and its delivery
- Fastly POP locations
- Getting started with Fastly
- How caching and CDNs work
- How Fastly's CDN Service works
- HTTP status codes cached by default
- Self-provisioned Fastly services
- Sign up and create your first service
- Working with services
Domains & Origins
Domains & Origins
- Changing origins based on user location
- Connecting to origins
- Enabling global POPs
- Failover configuration
- IPv6 support
- Maintaining separate HTTP and HTTPS requests to origin servers
- Routing assets to different origins
- Setting up redundant origin servers
- Specifying an override host
- Using Fastly with apex domains
- Accept-Language header VCL features
- Authenticating before returning a request
- Basic authentication
- Creating location-based tagging
- Custom responses that don't hit origin servers
- Delivering different content to different devices
- Enabling URL token validation
- Guide to VCL
- Isolating header values without regular expressions
- Manipulating the cache key
- IP geolocation variables: Migrating to the new dataset
- Overriding which IP address the geolocation features use
- Response Cookie handling
- Support for the Edge-Control header
- Understanding the different PASS action behaviors
- Using edge side includes (ESI)
- VCL regular expression cheat sheet
Access Control Lists
Monitoring and testing
- Domain validation for TLS certificates
- Enabling HSTS through Fastly
- Forcing a TLS redirect
- Managing domains on TLS certificates
- Serving HTTPS traffic using certificates you manage
- Serving HTTPS traffic using Fastly-managed certificates
- Setting up free TLS
- TLS key and certificate replacement
- TLS termination
Web Application Firewall
- Log streaming: Amazon S3
- Log streaming: Microsoft Azure Blob Storage
- Log streaming: Cloud Files
- Log streaming: Datadog
- Log streaming: DigitalOcean Spaces
- Log streaming: Elasticsearch
- Log streaming: FTP
- Log streaming: Google BigQuery
- Log streaming: Google Cloud Storage
- Log streaming: Honeycomb
- Log streaming: Kafka
- Log streaming: Log Shuttle
- Log streaming: LogDNA
- Log streaming: Logentries
- Log streaming: Loggly
- Log streaming: Heroku's Logplex
- Log streaming: OpenStack
- Log streaming: Papertrail
- Log streaming: Scalyr
- Log streaming: SFTP
- Log streaming: Splunk
- Log streaming: Sumo Logic
- Log streaming: Syslog
User access and control
About Dynamic Servers
Last updated July 27, 2018
Fastly's Load Balancer allows you to create pools of origin servers that you dynamically manage using Fastly's Dynamic Servers feature to distribute and direct incoming requests. The benefits include:
- support for any infrastructure deployments including any type of server instances and one or more datacenters, regions, or cloud providers
- high availability of web applications when using health checks
- compatibility with TLS termination, HTTP/2, and IPv6
- server stickiness without requiring a cookie-based approach
- implement any number of request routing rules/conditions to select a pool of origin servers
To set up Dynamic Servers, you attach a pool to a service, then add versionless origin servers that are stored separately from your VCL configuration. You can use the Fastly API to programmatically add, remove, and update pools and origin servers.
IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.
How Dynamic Servers work
Like Edge Dictionaries and ACLs, Dynamic Servers have two major components: the pool and origin servers within it. Pools act as containers for origin servers that store the hostnames or IP addresses of servers to which incoming requests can be directed. Each pool is attached to a version of a service, but origin servers are versionless and any changes will become effective immediately.
When Dynamic Servers might be useful
Dynamic Servers might be useful for organizations that need to load balance requests among origin servers. They can be used to:
- evaluate new server instance types and new software deployments.
- independently scale individual microservices.
More specifically, they can be used as:
- a Local Server Load Balancer (LSLB) where they are used to balance requests among origin servers within in a single region, such as AWS EC2 instances in the US East region, or within a single datacenter or on-premises location.
- a Global Server Load Balancer (GSLB) where they are used to load balance requests among origin servers across any geographically distributed infrastructure deployments such as:
- within multiple regions of an Infrastructure as a Service (IaaS) provider (e.g., AWS, GCP, Microsoft Azure).
- between multiple IaaS providers (e.g., AWS, GCP, Microsoft Azure).
- as part of hybrid infrastructure deployments that include a combination of on-premises origin servers or datacenters and IaaS providers.
You'll need to follow these steps:
- Create a pool in a working version of a service that's unlocked and not yet activated.
- Add at least one origin server to the newly created pool, keeping in mind the limitations.
- Activate the version of the service you associated with the pool.
Once the pool is created, properly associated, and filled with origin servers, it can be called in your service.
Keep the following limitations in mind as you use Dynamic Servers:
- Each Fastly service can be configured with up to five origin servers. Origin servers count as origins for the purposes of these limits. Contact firstname.lastname@example.org to enable more than five origin servers per service in your account.
- Pools cannot be created with custom VCL. If you create a pool using the API, you can use the API to make changes to it and use custom VCL to interact with it.
- Pools need at least one enabled server entry. Origin servers cannot be deleted when a pool only has one enabled entry left.
- Origin server deletions are permanent. If you delete an origin server, it is permanently removed from all service versions and cannot be recovered.
- When you delete a pool, you'll only delete it from the service version you're editing. Pools are tied to versions and can be cloned and reverted. When using pools, we want you to be able to do things like delete a pool from a current version of your service in order to roll back your configuration to a previous version using as few steps as possible.
- Event logs don't exist for origin server changes. If you use the API to add, update, or remove an origin server, there will be no record of it. The only record of a change will exist when you compare service versions to view the point at which the pool was associated with the service version in the first place.