DynamoDBのテーブルのAWS Beanstalkの.ebextensions設定

Question

は、私たちは、DynamoDBの持つJava春ブートアプリを開発しています。 .ebextensionsを使用してDynamoDBにテーブルを2つ作成しようとしています。これまでは、生成されたjarファイルを、eb cliからインクルードされた.ebextensionsフォルダとともに展開することができました。リスト（ユーザー）からいくつかの理由で

Resources: 
Book: 
    Type: AWS::DynamoDB::Table 
    Properties: 
    TableName: Book 
    KeySchema: 
     HashKeyElement: {AttributeName: id, AttributeType: S} 
    ProvisionedThroughput: {ReadCapacityUnits: 1, WriteCapacityUnits: 1} 

Subject: 
    Type: AWS::DynamoDB::Table 
    Properties: 
    TableName: Subject 
    KeySchema: 
     HashKeyElement: {AttributeName: id, AttributeType: S} 
    ProvisionedThroughput: {ReadCapacityUnits: 1, WriteCapacityUnits: 1} 

User: 
    Type: AWS::DynamoDB::Table 
    Properties: 
    TableName: User 
    KeySchema: 
     HashKeyElement: {AttributeName: id, AttributeType: S} 
    ProvisionedThroughput: {ReadCapacityUnits: 1, WriteCapacityUnits: 1} 

、唯一の最後のテーブルに作成されます。その中に私は、次の内容のdatabase.configファイルを持っています。なぜ他の2つが作成されていないのか？スクリプトの中の1つだけを保持すると、期待通りに作成されます。

誰もが新しい展開にDynamoDBのテーブルを作成し、更新するためのより良いアイデアを持っていますか？ .ebextensions設定ファイルは便利ですが、すべてのリリース前に正しい情報が含まれていることを確認する必要があります。

おかげで、 クリスティアン。

Answer 1

AWSの技術サポートからの回答：

私はあなたがトラブルCLIツールを通して展開しながら、弾性ビーンストークのebextension機能を使用してDynamoDBのテーブルを作成したことを理解しています。なぜこれが起こったのか理解するために、Elastic Bean StalkはCloudFormationを使用して適切なリソースと設定を行うことを理解することが重要です。私はテーブル[User、Book、Subject]が元のCloudFormationスタック（この場合は以前のBeanstalkスタック）から作成されていることに気付きました。テーブルは以前のスタックで作成されているため、新しい作成に失敗し、ロールバックしようとしました。このロールバックプロセスでは、以前のフォーミュレーションからの削除されたリソースは失敗し、テーブルは同じ名前を共有していました。このバグは社内のチームに報告されています。今後、AWSへのテストと移行の過程にあることを理解しています。これに関連するBeanstalkスタック[1]を再構築して、DynamoDBテーブルのリソース名を共有しないでデプロイを再開することをお勧めします。