Hosted Skillはほぼ欠かせない存在であるS3。実は自前ホストの場合でもいろいろ工夫して使うとなかなか良い感じになります。

S3バケットをDBにするメリット

• DynamoDBと比較して安い
• 耐障害性が高い
• 古いデータを低冗長化ストレージに移すなどの操作が容易
• 全件検索がやりやすい

S3バケットをDBにするデメリット

• クエリ操作に弱い（AthenaやS3 Selectでやれないことはない）
• １スキル１バケットにするとすぐ上限に達する
• DBではないので、整合性が取りづらい

S3バケットの使い所

個人的には、「スキルの利用状況」や「設定」のような頻繁に変化しないデータはS3でよいと思っています。

また、DynamoDBでは全件取得がコスト的にあまり推奨できませんので、全ユーザーの利用データを参照したい時などにもS3バケットを使う方がよいでしょう。

S3バケットを１つにまとめる

S3へデータを保存するようにできるライブラリask-sdk-s3-persistence-adapterは保存する際にプレフィックスを設定できます。

ここにスキル名を設定すると、１つのバケット内にスキル別にディレクトリが作成されるようになります。

import * as Ask from 'ask-sdk-core';
import {S3PersistenceAdapter} from 'ask-sdk-s3-persistence-adapter'

export const handler = Ask.SkillBuilders.custom()
  .addRequestHandlers(
    MyHandler
  )
  .addErrorHandlers(
      ErrorHandler
  )
  .withPersistenceAdapter(
      new S3PersistenceAdapter({
          bucketName: 'YOUR_S3_BUKET_NAME',
          pathPrefix: 'YOUR_SKILL_NAME'
      })
  )
  .lambda()

1バケットにまとめるメリット

Hosted Skillでは正直このやり方は無意味です。スキル毎にバケットが使える様子なので、余計なパスを増やすこともないでしょう。

ですが自前でホストする場合、「リソース上限に引っかからないこと」以外にもう１つメリットがあります。それは「IAMロールを都度作る必要がなくなること」です。

参照するバケットを統一することで、そのバケットにアクセスする権限を付与した「Alexaスキルバックエンド用IAMロール」を作ることができます。そして開発する際は、このロールをLambdaに割り当てるようにすれば、毎回IAMロールを作ったり、CloudFormation / Serverless Frameworkなどで定義を書いたりする必要もなくなるでしょう。