Dog-fooding has been described as "The Golden Rule of Platforms"[1] and was apparently part of Jeff Bezos's mandate:<p>"<i>His Big Mandate went something along these lines:... There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.</i>"<p>1. <a href="https://plus.google.com/+RipRowan/posts/eVeouesvaVX" rel="nofollow">https://plus.google.com/+RipRowan/posts/eVeouesvaVX</a>
> It’s nice to see that AWS’ supporting services are ran pretty much the same way as how outside companies will run their workload within AWS.<p>Reminds me that Heroku does (or at least did) run their slug compiler Vulcan <i>as a Heroku app</i>—when you push your app to Heroku, you're simply relying on another Heroku dyno to do the work of building yours. They don't need to do anything special to those dynos, or give them any special privileges; they're already isolated enough to serve as build-task runners, and their only output is to push something from their filesystem to S3, which they can do completely obliviously to Heroku's architecture.<p>I believe the recently-rebuilt Heroku dashboard might <i>also</i> be a Heroku app, but I'm not as sure on that one.
This is pretty well-known. For a similar example, you have to magic-number the Elastic Load Balancing service IDs[1] in order to dump logs to an S3 bucket.<p>[1] - <a href="http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-access-logs.html#attach-bucket-policy" rel="nofollow">http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...</a>
It scared me initially that knowing this would open up a can of worms but conclusion came to dog fooding and not exploit.<p>Thanks I never gave it and these ids too much thought until this post.