Workloads

The entry point of a website is the configuration that answers its hostnames, the names such as www.example.com that clients ask for. A DNS lookup sends the client to it, and the entry point terminates the Transport Layer Security (TLS) connection, the encrypted channel in which the server proves with a certificate that it holds the hostname. With mutual TLS (mTLS), the client proves its identity with a certificate too. The entry point then decides which code answers the request, so the hostnames and certificates change without any change to that code.

Workloads is the Platform Resource that runs that entry point on Azion’s distributed infrastructure. A workload holds a workload domain that Azion generates, the domains you add, the TLS and mTLS settings, the ports and HTTP versions it accepts, and the infrastructure it runs on. Its deployment names the application that answers, and optionally the firewall that inspects requests first and the custom page set that replaces error responses. Use Workloads to put an application on your own domain, serve it over HTTPS with your certificate or one Azion requests for you, require client certificates, or try a configuration on staging before production.

Workload structure

A workload is one JSON object. azion describe workload --workload-id <workload-id> --format json returns a new workload, created with a name and every default, as the API stores it:

• workload_domain is the read-only hostname Azion generates at creation. domains holds your own hostnames, and workload_domain_allow_access decides whether clients still reach the workload domain.
• infrastructure is 1 for production and 2 for staging, and it sets the suffix of the workload domain.
• protocols.http lists the HTTP versions and the ports the workload accepts. tls names the certificate, where null selects the Azion SAN certificate, along with the cipher suite and the minimum TLS version.
• mtls is off in a new workload. Turned on, it names the Trusted CA certificate that client certificates are checked against, and a verification mode.

The workload holds no application. Its deployment, a sub-object at /v4/workspace/workloads/{workload_id}/deployments, names the application, the firewall, and the custom page set in the strategy.attributes keys application, firewall, and custom_page. If you know a property from another platform, the workload and its deployment together play that role.

Request path

Creating a workload serves nothing until its deployment names an application. Until the deployment propagates, the workload domain answers 404 with Azion’s HTML error page.

1. The client looks up the hostname. A custom domain points at the workload domain with a CNAME record, so DNS returns an address of Azion’s distributed infrastructure.
2. The workload that lists the hostname takes the request.
3. The workload completes the TLS handshake with its certificate, its minimum TLS version, and its cipher suite. With mTLS on, it also checks the client certificate.
4. When the deployment names a firewall, the firewall runs its rules on the request before the application does.
5. The application in the deployment handles the request and fetches content through its connector.
6. When the connector answers with an error status code that the deployment’s custom page set covers, the client receives the custom page in place of that response.

A workload holds one deployment, so every hostname of the workload reaches the same application, firewall, and custom page set. For each step of the path and what it costs, refer to How Workloads works. For a domain that answers 404 or a handshake that fails, refer to Troubleshoot Workloads.

Resources

Certificate Manager and Custom Pages act on a workload once you bind a certificate to it or assign a custom page set in its deployment. DDoS Protection acts on every workload with nothing to bind.

Certificate Manager

Certificate Manager stores the certificates a workload uses for TLS: server certificates you upload with their private key, and Trusted CA certificates that verify client certificates for mTLS. It also requests Let’s Encrypt certificates for the workload’s domains and renews them for you, stores certificate revocation lists (CRLs), and creates certificate signing requests (CSRs). Turn to it when a domain of your own must serve HTTPS, since the Azion SAN certificate covers only the workload domain and the Azion Custom Domain.

For the certificate types, their fields, and their statuses, refer to Certificates, for how Azion issues and renews a Let’s Encrypt certificate, refer to Issuance and renewal, and to bind your first certificate to a workload, refer to the Certificate Manager quickstart.

Custom Pages

Custom Pages replaces the error response a connector returns with a page of your own, one page per 4xx or 5xx status code. A custom page set groups those pages, and each page fetches its content from a connector, keeps it in cache for its own time, and answers with the status code you set. The client receives the page in place, with no redirect. Turn it on when visitors must see your own page instead of the origin’s error page, and assign the set in the workload’s deployment.

For the fields of a set and its pages, and the status codes a page can replace, refer to Custom page settings, and to replace your first 404, refer to the Custom Pages quickstart.

DDoS Protection

A denial-of-service (DoS) attack floods a service with traffic until legitimate requests cannot get through, and a distributed (DDoS) attack sends that traffic from many machines at once. DDoS Protection is a Platform feature, always on: the Platform mitigates DDoS attacks on every workload, at the network, transport, presentation, and application layers, with nothing to create and nothing to configure. For detection and mitigation targeted at a specific attack, you write custom rules on the firewall the deployment names.

For the attack types and the mitigation techniques, refer to Attack mitigation, and for its bounds, refer to Workloads limits.

Scope and limits

• Domains: a workload answers on its workload domain, <id>.map.azionedge.net on production and <id>.preview.azionedge.net on staging, as soon as its deployment propagates, before you own any domain. You add domains of your own, each a full hostname with no wildcard, and point each one at the workload domain with a CNAME record. A production workload can also answer on one free azion.app hostname, which Azion Console calls Azion Custom Domain, at no additional cost. The Workload Domain Allow Access switch closes the workload domain once your own domains serve traffic. For every rule a hostname follows, refer to Workload settings, and for the DNS records, refer to Point a domain to a workload.
• DNS: a workload holds no DNS records. A domain’s zone stays at your DNS provider, or in Edge DNS, and the workload answers the hostnames it lists wherever their zone is hosted.
• Infrastructure: the Infrastructure control runs a workload on the Production Network, for global availability, or on the Staging Network, for testing with limited propagation. The choice is fixed at creation, and a staging workload takes no custom domain. For how to try a change on staging first, refer to Workloads best practices.
• Protocols: a workload accepts HTTP/1.1, HTTP/2, and HTTP/3 over QUIC, which needs HTTPS on and both earlier versions listed. HTTP runs on up to four ports, from 80, 8008, 8080, and 8880, with 80 by default, and HTTPS on up to twelve listed ports, with 443 by default. For the ports, refer to Workload settings.
• TLS: the minimum TLS version ranges from TLS 1.0 to TLS 1.3, the default, and TLS 1.0 and 1.1 are deprecated. Eight cipher suites are available, with suite 7 by default. The Azion SAN certificate covers the workload domain and the azion.app hostname, and a domain of your own needs a server certificate from Certificate Manager. Azion blocks TLS renegotiation and TLS resumption by default. These settings secure the connection from the client to Azion, while the connection to your origin is set on the connector. For the fields and the ciphers of each suite, refer to Workload settings.
• mTLS: a workload checks client certificates against a Trusted CA certificate, with up to 100 CRLs, in enforce or permissive mode, on HTTPS connections only. Azion activates mTLS per account, so contact the Sales team to turn it on. For both modes and every requirement, refer to mTLS.
• Deployment: a workload holds one deployment, which names the application, required, and a firewall and a custom page set, both optional. Azion CLI creates a deployment but cannot update or delete one, so change it in Azion Console or with the API. For its fields, refer to Workload settings.
• Propagation: a saved change to a workload or its deployment takes several minutes to reach all of Azion’s distributed infrastructure, with no guaranteed duration. Meanwhile, requests can receive the old or the new configuration. For more information, refer to Propagation.
• Interfaces: you create and manage workloads on the Workloads page of Azion Console, through the Azion API at /v4/workspace/workloads, with Azion CLI commands such as azion create workload and azion create workload-deployment, and with the azion_workload and azion_workload_deployment resources of Terraform.
• API v4: on API v3, one Domains object carried the role of a workload, and an application’s Main Settings held the protocol and TLS settings. On API v4, the workload and its deployment replace them. For the mapping between the two models, refer to API v4 Migration, and for an account that still runs API v3, refer to Domains.
• Observability: Azion’s error page carries an x-azion-request-id header that identifies the request. Data Stream collects the events of the workloads you associate with a stream, as Associate workloads with a stream shows.
• Limits: a workload name takes up to 100 characters, and a workload covers up to 50 domains. An account holds 100 workloads on the Developer, Business, and Enterprise support plans, and 1,000 on Mission-Critical. For every bound and the answer past it, refer to Workloads limits.
• Billing: Workloads is billed on workloads, data transfer, and requests. Each plan includes an amount of each, such as 10 workloads on Hobby and 20 on Pro. For the rates, refer to Pricing.
• Terms: the Workloads glossary defines the words the Workloads pages give a specific meaning, such as workload domain, deployment, Azion custom domain, and Trusted CA certificate.

Next steps