anchor.diff:      users: /myusers/**
   ----
   
  -This means that all calls such as "/myusers/101" will be forwarded to "/101" on the "users" service.
  -But calls including "/admin/" will not resolve.
  -
  -WARNING: If you need your routes to have their order preserved you need to use a YAML
  -file as the ordering will be lost using a properties file. For example:
  +The preceding example means that all calls (such as `/myusers/101`) are forwarded to `/101` on the `users` service.
  +However, calls including `/admin/` do not resolve.
  +
  +WARNING: If you need your routes to have their order preserved, you need to use a YAML file, as the ordering is lost when using a properties file.
  +The following example shows such a YAML file:
   
   .application.yml
   [source,yaml]
  
positive.code:   clusterNameExpression: metadata['cluster']
  ----
  
  In this case, the cluster name from 4 services is pulled from their metadata map, and is expected to have values that include "SYSTEM" and "USER".
  
  To use the "default" cluster for all apps you need a string literal expression (with single quotes, and escaped with double quotes if it is in YAML as well):
  
  ----
  turbine:
  
negative.code:     nonSecurePort: 80
  ----
  
  Depending on the way the security rules are set up in your Cloudfoundry instance, you might be able to register and use the IP address of the host VM for direct service-to-service calls.
  This feature is not yet available on Pivotal Web Services (https://run.pivotal.io[PWS]).
  
  ==== Using Eureka on AWS
  
  If the application is planned to be deployed to an AWS cloud, the Eureka instance must be configured to be AWS-aware. You can do so by customizing the {github-code}/spring-cloud-netflix-eureka-client/src/main/java/org/springframework/cloud/netflix/eureka/EurekaInstanceConfigBean.java[EurekaInstanceConfigBean] as follows:
  
  [source,java,indent=0]
  ----
  