For those that may not be familiar with what Amazon ELB (Elastic Load Balancer), this is an auto-scale load balancer that sits in front of EC2 instances and distributes traffics in a round robin manner between associated devices.
A publicly available address for this ELB will look something similar to my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com. Now this can cause some issues when you are trying to assign your top-level domain too. For more information on this, have a read of 'Pointing Domain to AWS Elastic Load Balancing'. This is an excellent resource which outlines some possible methods of approach with multiple types of setups.
Here is a link for more information from Amazon regarding how AWS ELB works and can be associated: http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/using-domain-names-with-elb.html
Something to note with AWS and Akamai integration is to make sure is that the origin configuration matches the AWS ELB configuration after the migration. For instance, the vary header behavior and the PCONN configuration is very important to double-check.
The Vary header instructs Akamai Servers that content may differ based on some characteristic and hence, it is uncacheable. This is a valid behavior per RFC HTTP/1.1. Specifically, Akamai will not cache content if the Origin Server response includes a Vary header with a value other than ‘Vary: Accept-Encoding’. Akamai will cache responses with ‘Vary: Accept-Encoding’ only if they are accompanied by ‘Content-Encoding: gzip’.
As something to check, if content is not being cached because of a Vary header, either remove this header from the origin server response, or modify the associated configuration, using the Configuration Manager on Luna Control Center, to instruct Akamai to ignore the Vary header.
This option can be found in:
Configuration Manager under Optional Features, ‘Header Handling: Remove Vary Header’
Property Manager, in the Default Rule, toggle the ‘Remove Vary Header’ On
With the integration with Akamai it is ideal to keep in mind that there could be a conflict with persistent connections as the default for Akamai is 300secs and for AWS it is 120secs. This can be fixed by doing the following:
· Either Akamai lowers its PCONN time
· Increase PCONN at the origin (recommended)
Here is a KB article on more details on the PCONN## or persistent connections if you require further information. https://control.akamai.com/core/search/kb_article.search?articleId=5236