You should be familiar with these terms

Before you get started with Akamai Cloud Embed (ACE), you should be familiar the following concepts and terms.

ACE-specific concepts and terms

These terms and concepts are specific to Akamai Cloud Embed and its usage, and are called out throughout this documentation. Terms are ordered based on their importance.

Concept/Term Description
Cloud Partner These are Akamai resellers or partners who provide delivery services to their customers. As a user of ACE, you are a cloud partner. (This documentation is focused toward the cloud partner.)
subcustomer As a cloud partner, your customers are subcustomers. Akamai does not assign individual Content Provider (CP) codes to subcustomers even though their traffic is sent over the Akamai platform. A cloud partner has access to usage detail reports for each subcustomer, based on the subcustomer IDs you provide Akamai.
subcustomer ID This is a unique ID controlled by you, as our cloud partner, that you establish for each subcustomer within your own billing systems. All traffic for a particular subcustomer is rolled up by this ID for billing purposes.
Base Configuration This configuration includes all of the common rules used to process end-user requests via your subcustomers. You use the Property Manager in Control Center (or the Property Manager API) to set up this configuration. This is similar to an individual "Property Configuration" that you set up to use any of our other delivery products (AMD, DD or OD). However, with ACE, a base configuration serves as a single configuration that you apply for use with multiple subcustomers.
Note: The terms "base configuration," "property configuration," "configuration," and "configuration file" are used interchangeably to describe this component.
Subcustomer Enablement behavior In Property Manager, this is the specific behavior you use to control which individual ACE (and optionally ICA) features are available to handle your subcustomers' traffic. You can set up this behavior to provide access to all available features, or you can select a subset of features to define different classes of service.
Policy Policies determine how Akamai Edge servers handle a given subcustomer's requests. A single policy is bound to a specific property hostname, that has been defined in a specific base configuration. Your policy JSON is made up of rules, which contain both match criteria and behaviors. When an incoming request meets the match criteria in a rule, it triggers the behaviors listed in that rule. Within a policy, rules must be unique: they can't have identical sets of matches. A policy can also contain up to 100 behaviors.
Policy Rules These rules include both policy match criteria and policy behaviors. When an incoming request meets the match criteria in a rule, it triggers the behaviors listed in that rule. You can use each match type and each behavior once in a policy rule. Also, no one rule can contain both a whitelist and blacklist behavior of a given type. For example, you can add an IP whitelist and a referrer blacklist to a rule, but you can't have both an IP whitelist and IP blacklist in the same rule. Rules are applied from top to bottom and should be listed from least restrictive (top) to most restrictive (bottom). For example, you would list a match on url-wildcard value /* first, because it would apply to all requests, where /images/* would only apply to a subset of requests.
Policy Matches Within a policy rule, a policy match defines which subcustomer requests receive the policy behaviors within the rule. All match conditions for a rule must evaluate to "true" in order for the behaviors to apply. When constructing matches in a rule, the type of data you enter depends on the type of match. For example, if you use the query string match, you have to enter the exact string and keep case sensitivity in mind. If you use the url-scheme match, you enter either HTTP or HTTPS. Within a match, you cannot repeat entries in the value string.
Policy Behaviors Policy behaviors are used to encapsulate customizable settings. Behaviors are a part of a policy's rules. A rule can have many behaviors or only one. With ACE, you group rules into policies. You can have a maximum of 100 behaviors in a subcustomer policy. Policies exceeding 100 behaviors are rejected upon submission. Within a behavior, you cannot repeat entries in the value string.
Content Characteristics-Dynamic Web Content Behavior Include this behavior if you've included acceleration via ICA to your ACE instance, and you only want to enable specific ICA optimizations for your subcustomers. (Contact your Account Representative for more information on ICA.)
InstantConfig Behavior If your subcustomers only send HTTP traffic, you have to add this behavior to your base configuration. This behavior, also known as "Multi-Domain Configuration," lets you associate multiple web assets to a single property without adding each hostname separately. It applies property settings to all incoming hostnames based on a DNS lookup.

Generic Terms

These terms describe general components used throughout Akamai, and also apply to ACE.

Concept/Term Description
Content Provider (CP) Code This is an identifier for a particular subset of content on your Origin Server. Some features are applied individually to particular CP codes. CP codes are also used to provide additional granularity in reports and to track billing. You'll have at least one CP code per contract. Also, a CP code is associated with a single contract.
Property Configuration See Base Configuration.
Property Hostname This is an identifier that is used to determine which base configuration file to use when processing end-user HTTP/HTTPS requests for a subcustomer's resource. Often, the Property Hostname is the fully qualified domain name of the endpoint subcustomers use to access your cloud partner CDN. For instance, would be your endpoint domain name and your Property Hostname. A property hostname is sometimes referred to as a "digital property," too.
DNS Record This is a record that associates a Domain Name to an IP address.
Edge Hostname This describes your specific cloud partner subdomain on an Edge network domain. It maps incoming requests to our Edge servers. You generate a "property hostname to Edge hostname association" to determine an Edge hostname. For example, assume the endpoint that subcustomers access is This would serve as the property hostname in this association that results in the Edge hostname, An end-user request for a subcustomer's assets is ultimately directed to this Edge hostname. In turn, the Edge hostname resolves the request to individual servers on the Edge network, where the associated base configuration is read to determine how to process the request.
Edge Server This is a server in the Akamai Edge network that ultimately receives end-user requests from subcustomers. (End user requests to the subcustomer's hostname are redirected to an associated Edge hostname which resolves to the Edge Server.)
Forward HOST Header The name the Edge server forwards (often to the Origin Server) in the HTTP Host request header, sometimes also referred to as the expected host. Often, this is the same name as the Property Hostname.
Origin Server The server where subcustomer content is housed to be served to end users (where your site/application resides). Edge servers read first from the applicable subcustomer's policy for origin information, and second from the Origin Server settings applied in your base configuration.
Origin-server Hostname The Hostname that maps to your Origin Server from which Edge Servers retrieve your content. The usual syntax of the Origin-server Hostname is the Property Hostname preceded by “origin” and a hyphen.