See here:

(My question remains. I'm interested in seed configuration practice/recipe when deploying on AWS. In the scenario, assume Cassandra sits behind some other part of the service -- say, web container -- that are then exposed publicly. Cassandra nodes themselves are not.)

- m.

On Sun, Apr 4, 2010 at 6:48 PM, Dan Di Spaltro <> wrote:
A little off-topic, but is an availability zone in a separate physical

On Sat, Apr 3, 2010 at 5:08 PM, Benjamin Black <> wrote:
> Right, you determine AZ by looking at the metadata.  us-east-1a is a
> different AZ from us-east-1b.  You can't infer anything beyond that,
> either with the AWS API or guesses about IP addressing.  My EC2 snitch
> recipe builds a config file for the property snitch that treats AZs
> like racks (just breaking apart the AZ name, nothing magical), and the
> rest is the normal rack aware placement strategy.  I am sure folks
> _could_ do interesting things on EC2 with extra code, but I don't see
> extra code as required for these basic features.
> b
> On Sat, Apr 3, 2010 at 3:04 PM, Joe Stump <> wrote:
>> On Apr 3, 2010, at 2:54 PM, Benjamin Black wrote:
>>> I'm pretty familiar with EC2, hence the question.  I don't believe any
>>> patches are required to do these things.  Regardless, as I noted in
>>> that ticket, you definitely do NOT need AWS credentials to determine
>>> your availability zone.  It is available through the metadata web
>>> server for each instance as 'placement_availability_zone', avoiding
>>> the need to speak the EC2 API or store credentials in the configs.
>> Good point on the metadata web server. Though I'm unsure how Cassandra would know anything about those AZ's without using code that's aware of such things, such as the rack-aware strategy we made.
>> Am I missing something further? I asked a friend on the EC2 networking team if you could determine AZ by IP address and he said, "No."
>> --Joe

Dan Di Spaltro