Per-Entity Metadata Working Group

[Patrick Radtke <>]

On Tue, Sep 6, 2016 at 4:24 PM, Tom Scavo 
<>
 wrote:
> On Tue, Sep 6, 2016 at 7:19 PM, Cantor, Scott 
> <>
>  wrote:
>> On 9/6/16 7:16 PM, Paul Caskey wrote:
>>>
>>> To the extent that's true, then I would question the need for a CDN,
>>> as opposed to a normal highly-available infrastructure (which would be
>>> less expensive to operate).
>>
>> I think the point of the CDN was not performance but in fact
>> availability. I thought the issue was that InCommon wasn't comfortable
>> providing that HA infrastructure, at least enough that it was thought to
>> be worth investigating what a CDN would offer and cost.
>
> Well, our initial thought was to enable AWS Elastic Load Balancer for
> automatic failover. It has not been tried, however, so I don't know if
> it works as advertised.

I believe a CDN will be cheaper than running a pair of EC2 instances
and the ELB.
Cloud front is a penny per 10K HTTPS connections and ~9 cents for 10TB
of data transfer. There would probably be a dollar or two in S3
charges for storing the signed metadata. Going with servers, an ELB
and figuring out cross region HA will cost more than that.

To me the real advantage to the CDN is resilience to targeted attacks
against the MDQ servers. To me the largest downside is that failure
modes are now location specific, which can make it hard to provide an
accurate federation wide status of the service. If the cloudfront edge
in Toronto is having issues, who would it affect? how would they be
affected? would Ops be able to determine there was partial outage?,
etc, etc.

-Patrick