Você definitivamente não precisa de um intervalo para cada usuário. Não importa o fato de que parece improvável que o suporte da AWS aprove uma solicitação para aumentar o limite total de buckets padrão de sua conta de 100 para 300.000.000. Além disso, a criação inicial do intervalo não deve ser feita de forma agressiva ou em tempo real.
The high-availability engineering of Amazon S3 is focused on get, put, list, and delete operations. Because bucket operations work against a centralized, global resource space, it is not appropriate to create or delete buckets on the high-availability code path of your application. It is better to create or delete buckets in a separate initialization or setup routine that you run less often.
http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
Projete seu aplicativo para que não importe se você usa um ou vários buckets. Como? Para cada usuário, armazene o bucket_id onde os dados desse usuário são armazenados. Em seguida, comece com todos em bucket_id 1 e, mais tarde, você terá a flexibilidade de colocar novos usuários em novos grupos se isso for necessário ... ou se você decidir migrar alguns usuários para diferentes intervalos ... ou se decidir situar os usuários armazenamento em um bucket mais próximo do local típico do usuário.
O S3 dimensionará automaticamente sua capacidade para atender às demandas do seu tráfego. Você pode tornar esse processo mais fácil projetando os caminhos para seus objetos para que haja atribuição não-sequencial de chaves de objeto perto do lado esquerdo da chave.
O S3 dimensiona sua capacidade dividindo as partições de índice. Assim, por exemplo, dar a cada objeto um caminho que comece com a data do upload seria uma péssima ideia, porque seu índice de bucket desenvolve um ponto de acesso com uploads pesados em um pequena parte do espaço de chaves.
Veja link
Pela mesma razão, não dê a seus buckets nomes sequenciais lexicais em uma região.
O que o Dropbox pode estar fazendo provavelmente não é relevante.