AWS Lambda: [ERROR] ProfileNotFound: The config profile (xxxx) could not be found

Chaliceを使ってPythonコードをlamdaにデプロイしたら、Internal Errorのリターンがあり、表題のようなエラーがCloud Watchで確認できました。エラーの意味は、xxxxってプロファイルがないよってことなんですが。。。。

原因と解決策

原因は、ローカルで指定している Crediencialのプロファイルが、サーバー側にはないよってこと。

解決策は、デプロイするコードにはprofileを指定する記述をなくす。。ということにようです。sonnnet3.7の回答がそうだったので、実際そうすると動きました。でも何かスマートじゃないな。

AttributeError: 'Template' object has no attribute 'add_description'

Zappaを使ってAWS LambdaにFlaskのスクリプトをアップしようとしたら、表題のようなエラーが。。。どうやら、最近この現象が起き始めているようで、Githubのissuesにも取り上げられているようです。

解決策

当面の解決策は、

• pip3 install "troposphere==2.7.0"

を実行すること。。どうやら、AWS側の問題らしい。よくわからんけど、とりあえず動いているので良しとしよう。

DynamoDBに正式移行しました

おちラボでは、ようやく、、、、よーやく研究室の公式DBをSimpleDBからDynamoDBに移行しました。

なぜ今まで移行しなかったか？
DynamoDBについては、2012年に

• DynamoDBとは

という記事を書いたように、早くから注目していましたが、料金体系に問題があり（後述）、ゼミでの利用に不向きだったこともあり、SimpleDBを利用していました（AWS:SimpleDBをセットアップする）。しかし、SimpleDBはいつ死んでもおかしくないようなサービスなので（全くSDKがバージョンアップしていない）、このまま使う続けるのはまずいよな。。と流石に思い始め、かつ後述するように料金体系がいつの間にか変更されていて、使いやすくなっていたので、今年から切り替えることになりました。

DynamoDBの料金体系を確認する
現在、DynamoDBには２つの料金体系が存在します。

1. プロビジョニング
2. オンデマンド

１は昔からあるタイプで、いわゆる事前割当になります。これが問題だったのは、テーブル毎にプロビジョニング設定をしないといけないということ。つまりテーブルを増やせば増やすほど課金されます。これは使わなくてもです。一方、２は最近出てきた料金体系で（2018年に発表されたようです）、使ったぶんだけ、、ということになります。SimpleDBがまさにこの料金体系だったので、おそらくこの料金体系を用意することで、SimpleDBのユーザを移行させようとしているのではないでしょうか（私みたいに）？

実際安くなるのか？

ただし、オンデマンドの場合、青天井に増えていく可能性がありますので注意が必要です。真面目に運用をはじめると、プロビジョニングのほうが割安でしょう。ただ、ゼミでちょっと学生に使わせるとか、テーブルを気軽に増やしておけるというのは大変ありがたく（これが正しいDynamoDBの使い方なのかはおいといて）、現状だとDynamoDBについてコストはほぼ発生していない状況です。

というわけで、今後はDynamoDBについての記事も増えてくると思います。

Zappaを使ってLambdaにFlaskアプリを導入した際のURL問題の解決法

 Zappaを使うと、AWS Lambda上にてウェブアプリをお手軽にDeployさせることができます。おちラボで動かしているのはFlaskのアプリなんですが、１つだけ問題が。。。。

ディレクトリ階層に余分なprefixがつく問題

ZappaでアップロードしたURLには、/dev/みたいな余分なURL（Stageという概念ですね）が付いちゃいます。これはAPI Gatewayの仕様らしく、回避不能のようです。api的な使い方だったら別にそれを前提にしておけばいいんですが、アプリとしてDeployする場合、アプリ内で自身の別URLを呼ぶ場合に都合が悪くなります。例えば、

• (ローカル環境)/update
• (Lambda環境) /dev/update

というふうに、”/dev”みたいなstage表記がもれなく付いてきます。静的にURLを記述しちゃうとローカルで動くけどLambdaにデプロイするとURLがNot foundでエラーになったりするわけです。

解決策：動的にURLを定義する

まあ、当たり前の解決策なんですが、実行環境に合わせて動的に定義するしかないです。例えば以下のようにosの環境を調べておいてからstageを渡すという方法ですね。下記の場合は、ローカルがWindows環境を想定していますので、まあLambdaのOSがWindowsなわけがないので（Amazon Linuxのはず）、これでOKでしょう。

zappaのインストールメモ

zappaをanacondaで作成した仮想環境にインストールした際に、zappa init でちょっと手間取ったところがあるのでメモ書きです。

AWSの環境設定
ここは大前提なので書かれてないことが多いですが、awsを使うので当然、AWS周りの環境設定は必要です。
・aws-cliをインストール
・Lambdaを動かすアカウントを作成しておき、Access Key などをメモっておく
・aws configureでAccess Key ID、Secret Access Key、region name、output formatの4つを設定する

zappa用の仮想環境の構築
仮想環境作って、下記のようにインストールしましょう。

$ pip install flask
$ pip install zappa

ネットに出てくる情報は、virtualenv を使ってってのが多いですが、Anaconda（GUI）で仮想環境作ってもOKです。ただ、Anaconda（GUI）の場合、デフォルトではzappaのインストールができなかったので、pipコマンド使いました。

AWSで権限の設定をしておく
これについての情報が非常に少なく、もしかしたら私が勘違いしているのかもしれませんが、zappaを使うということは、当然LambdaとかAPIGatewayなどをアクセスする権限（ロール）の設定が必要なはずで、このあたりの設定が不十分だと、zappa でのデプロイ時に権限がらみのエラーが出ます。とりあえず下記のロールを追加しとくとエラーはでないでしょう。

•  AWSLambdaFullAccess
•  IAMFullAccess
•  AWSLambdaDynamoDBExecutionRole
•  AmazonAPIGatewayAdministrator
•  AWSCodeDeployRoleForLambda
•  AWSLambdaExecute
•  AWSCloudFormationFullAccess

なお、IAMのポリシー設定についてはGitHubで議論があります。

• Minimum AWS policies for example

Zappa init で初期設定ファイルを作る

$ zappa init

このコマンドを実行することで、zappa_settings.js というファイルができます。
ここで以下のようなエラー出たときの対処法を書いておきます。

エラー：zappa init error: "Zappa requires an active virtual environment

このメッセージが出たときは、環境変数でVIRTUAL_ENV を設定してください。

（Windowsの場合）
$ set VIRTUAL_ENV=c:\users\xxxx\appdata\local\continuum\anaconda3\envs\flaskenv

エラー：zappa Init error 'utf8' codec can't decode byte 0x**

このエラーは単にディレクトリの（権限の？）問題だけのようです。（自分がこれから作成しようとしている）Pythonのプロジェクトファイルのフォルダに移動してみてから initを再度実行してみてください。

zappa_settings.jsonファイルの修正
必要に応じてファイルを修正しましょう。ここの肝は、project_nameという変数を変えることで、別プロジェクトのような扱いになります。つまり異なるLambda関数となり、APIGatewayでのURLも変わることになります。

zappaコマンド（デプロイ、更新、削除）
インストールに成功したら、あとの操作は下記のようになります。

（はじめてプロジェクトをデプロイする場合）
$ zappa deploy dev
（更新する場合）
$ zappa update dev
（削除する場合）
$zappa undeploy dev

AWS Lambdaのメモリ設定とパフォーマンスについてのメモ書き

AWS Lambdaをもう少し本気で使ってみようかなということで、ラボで内部利用している非公開なAPIをGAE→Lambdaにしようと企んでいます。ちょっと試してみたんですが、その使用感などメモ書きです。

メモリとコンテナのスペックは連動する
Lambdaにはメモリ設定があります。これは最初悩みどころで、どれぐらいメモリが必要なんだろ？とか思ったりしますがこれは勘違いです。メモリ設定の正体は、Lambdaコンテナのスペックに比例します。つまり、

• メモリ量を増やすことで、実効速度が速くなる

ということです。逆に言うと、メモリをケチるとめちゃめちゃ遅いです。使い物にならないです。例えば、「amazon product advertising api」をLambdaでコールしてみたんですが、

• メモリ128MB:→実行速度：6000〜8000ms
• メモリ1024MB:→実行速度：600〜1000ms

となります。ウェブアプリのREST APIとして使いたいなら、6000〜8000msなんてありえない数値です。1000msでも遅いなぁって気がしますしね。

傾向として初回は起動が遅いですが、連続した2回目以降の処理は速くなります。ただ、メモリ128Mだと、何回やっても6000〜8000msをうろつきます。ちなみに、試したプログラムの最大メモリ使用量は51MBです。

コスト（料金）に注意

ただし、メモリを増やすとコストもかかってきます。これについては、下記の記事を御覧ください。

• AWS LambdaのPricingを読み解く（Qiita）

メモリ設定変更の方法に注意（Javaの場合）

管理画面でメモリを変更できるようになってますが、Javaの場合はメモリ設定だけを変更することはできないようです。jarのアップロード時にしか反映されない感じなので注意が必要です。

コストの点ではLambdaはGAEよりも若干高い気がしますが、制約もなくきちんとしたモノを作りたいのであれば選択肢として充分アリかなという印象ですね。

EclipseでAWS Lambda Functionプログラミング（Java）

Lambdaについて、意外とJava版の情報が少ないので書いてみました。なお、本記事は新サービスである「Amazon API Gataway」を視野に入れた書き方をしています。

Lambdaとは
簡単にいうと、AWS上で動かすことのできるスクリプトです。AWSで提供されているサービスのイベントに合わせてプログラムを実行できます。例えば、

• DynamoDBにデータが登録された際に〜な処理をする

みたいなこともできるわけです。以前までは、Javascript（node.js相当）で記述できましたが、先月、Javaも対応になりました。さらに、、、後日記事にするつもりですが、このたび、Amazon API Gatawayというサービスも登場し、Lambdaと連携できるようになったということもあり、今、ホットな話題と言えるでしょう。

Eclipseでの手順
ざっと書くと下記の通りです。

０．事前準備
Eclipse for AWS Pluginは入れておいて下さい。で、当然ですが、AWSのアカウントはもっており、Lambdaの実行権限のあるユーザアカウントを用意しておいて下さい。また、S3も使えるようにアカウント設定しておきましょう。

１．AWS Lambda Java Project でプロジェクトを生成
プロジェクトの作成でAWSのところに、AWS Lambda Java Projectがありますので、これをクリックして作成します。

２．InputTypeの設定に注意

Lambdaは基本的にAWSのイベントを扱いますから、どのようなイベントに対応するのかをInputTypeで設定します。今回はカスタムにしました。そして、Stringを授受するファンクションとしました。

３．サンプルコードを書き換えます

すでにサンプルはできていますので、出力がnullになっているので何か文字を返すように書き換えましょう。

４．アップロードと実行

プロジェクトを右クリックすることで、AWSへアップロードや実行をするメニューが出ます。

実行を選ぶとAWSへのアップもされるようです。

５．Deployするリージョンとファンクション名を指定

Lambdaにおいてどういうファンクション名にするのか指定します。既存のものに上書きすることもできます。なお、現段階では東京リージョンは使えない模様。

６．動作環境設定

最初は細かい設定が必要です。S3も使うようなのですが、何のためかは不明。コードの実体を保存する場所かと思いましたが、そういうわけではない模様。メモリとタイムアウトの設定については、どういう値がベターなのかは今後の要調査ですね。Roleについては、今回はAPIGatewayのを前提してます。

７．実行

実行時には、入力パラメータを求められるので必ず何かを書いて下さい。どうやらファンクションとのやりとりはJSON形式で行われているらしく、何もなしで実行するとJSON Parserエラーが出ます。今回はStringを受け取るファンクションを作ったわけですから、必ずStringを渡す必要があるのです。

実行結果は出力パネルに出ます。

ちなみに、、、、、この実行というのは、本番環境での実行になりますので注意して下さい。今回のサンプルでは、文字列を受け取るようになっているので、実行時の入力には必ず何か文字を渡して下さい。

以上、ざっと書いてみましたが、これとAmazon API Gatawayを組み合わせることで、面白いことができそうです。それについては後日。

DynamoDBにてHash+RangeのQuery設定方法（v2対応）

久しぶりにDynamoDB触ってみたら、Hash+RangeのQuery設定方法がv2で変更になっていて、古いコードがエラーになってしまったので。。。。

C#： Amazon S3を操作する（put,get,delete,list）

AmazonのストレージサービスであるAmazon S3に対するオブジェクト（ファイル）の基本操作についてです。いろいろオプション設定する項目はあるようです。

登録(put) 検索(get) 削除(delete) リスト（list）

AWS ExploreでSimpleDBを操作する

おちラボではSimpleDBをラボの研究用データベースの１つとして利用していますが、SimpleDBはAWS Management Consoleで操作ができないなど、後発のDynamoDBよりも冷遇されている感じで、管理がやりにくい雰囲気があります。しかし、SDKに付随しているAWS Exploreを利用するといろいろできます（Eclipse、Visual Studio等）。下記は、Eclipseの例です。

ドメインの作成、削除
AWS Exploerを開くとドメインの一覧が出てきます。ここで右クリックすれば、ドメインの作成・削除ができます。

アイテムの操作
ドメインをクリックするとドメインの中身が見れます。クエリーを入力することで検索することもできます。Excelみたいに直接値を修正することもできます。

OSimpleMapperCS リリースしました

AWSが提供するデータベースの１つであるSimpleDBのO/Rマッパーもどきのライブラリ（C#版）として

• OSimpleMapperCS

をGitHubにリリースしました。おちラボでは、Javaアプリケーション開発においてSimpleDBの利用を進めていましたが、本ライブラリを利用することでC#アプリケーションからのSimpleDB利用が容易になるかと思います。

AWS：org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager: method ()V not found

AWSのSimpleDBプログラムをGWT-RPCのサーバー側で呼びだそうとした時、下記のエラーに遭遇

Caused by: java.lang.NoSuchMethodError: org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager: method ()V not found

という意味不明なエラーが発生。これは、どうやら、
gwt-dev.jarにThreadSafeClientConnManagerが含まれてて、これとバッティングしている感じ。解決策としては、

•  httpclient.jarが含まれているライブラリ、つまりAWSのライブラリを GWTより前に持ってくる

ということで解決できます。

GAE/JからSimpleDBを利用する方法

GAEはDatastoreの有料化に伴いとても使いにくくなりました。かといって、他のクラウドサービスはJavaを動かすだけでちょっとお高く、、、という感じで、帯に短しタスキに長しという感じで、個人的にはGAEのプラットフォームはとても好きだけど使えない。。。と悶々としておりました。
 一方、データベースについてはDynamoDBとかSimpleDBなどAWSが魅力的なサービスを提供してますので、GAEとAWSをうまく組み合わせることができたら最高じゃないか？っていうのは誰もが気づくことです。しかし、GAEの制約により、AWSのSDKは使えないということになっています。困ったもんです。。。
ですが、SimpleDBやDynamoDBなどのサービスはRESTインタフェースを持っているわけで、SDKなんか使わなくても単純なRESTアクセスをすれば、GAEからアクセス可能なはずです。だれかそういうことをやっている猛者はいないのかといろいろ探していたのですが、ようやくいいソリューションを発見しました。

Alanwilliamson's Library

RESTを利用してSimpleDBにアクセスする試みってのは探せばあるもんでして、

• http://alan.blog-city.com/simpledb_sqs_java.htm

に、そのライブラリがありました。これを使います。マニュアル等はありませんが、これをつかうことでAWSのSDKなしで純粋なHTTPクラスのみでアクセスできます。ただし、これのみではGAEでは使えません。試したらみたらわかりますが、FileOutputStreamなどを使っているのでこれらがGAEで使えないというエラーが出ます。困りましたね。

Koherent-App-Engine-Library-for-Java

探せばあるもんで、

• https://github.com/koher/Koherent-App-Engine-Library-for-Java 

このライブラリは、

FileOutputStream、FileInputStreamをDatastoreOutputStream、DatastoreInputStreamに置き換える

ということができます。上記のAlanのコードを書き換えましょう。

Content-typeを修正する

上記２つを組み合わせることで、無事動く、、、と言いたいのですが、putAttributeを実行するとなぜか認証エラーがでます。DomainListsの入手では問題ないのに。。。。これは、SimpleDBのRESTの仕様のバグか何か？で

//urlc.setRequestProperty("Content-type", "application/x-www-form-urlencoded" );
urlc.setRequestProperty("Content-type", "application/x-www-form-urlencoded; charset=utf-8" );

のようにヘッダの記述部分を書き換えることで解決します。

おそらく、AWS+GAEの組み合わせを希望しつつ、断念していた人も多いのではないかと思います。しかし、この方法なら大丈夫なはずです。細かいコマンドの動作はまだ試してませんが、後日、ノウハウをまとめたいと思います。

AWS:RDSではなくSimple DBを選んだ理由

先日の記事のように、おちラボでは、

• DynamoDB
• SimpleDB

の２つをラボのクラウドデータベースの柱として活用することにしたわけですが、今回、RDSではなくSimple DBを選んだその理由についてちょっと書いてみます。

ネットワークセキュリティ

一番の理由はこれですね。ファイヤーウォールの関係で、RDSのように従来のRDBシステムをバックにしたシステムにアクセスするポートは塞がっています。よって、ラボ内からRDSにアクセスできない。。。この問題は、SQL Azureを利用するときにもぶちあたっていて、RDSも同様のシステムなんだから無理なわけで、、、もちろん、申請すればポートなどは開けてもらえますが、この手のクラウドのサービスでは、EndpointのIPも変わるような気がして（未確認）、とにかくセキュリティポリシー上無理だということに。一方、SimpleDBはDynamoDBと同様にRESTインタフェースをベースにしてますから、ふつうにアクセスできます。

シンプルにDBを扱いたい

教育的な視点を考えると、RDBのような一般的なDBを扱わせたいと思う反面、すばやくシステムを作ることを考えると、SimpleDBのような単機能のほうが良いかなと判断しました。

値段的に安い

私の勘違いでなければ

• RDS ・・・　DBのインスタンス生存時間
• SimpleDB 　・・・　実際のCPU処理時間

で、つまり、RDSは使ってなくてもインスタンスが動いていれば課金。SimpleDBは実際のリクエスト処理時間に応じて課金。ということ。ラボの利用みたいに、少人数でアクセス時間も限られている場合であれば、SimpleDBは格安ですむと思われます。

クラウドデータベース選定の一助になれば幸いです。

AWS:SimpleDBをセットアップする

AWSのSimpleDBを使ってみようかと思って、いきなりセットアップでハマったので、、、

SimpleDBってAWSの中では結構ウリのサービスでありながら、AWS Management Consoleにその名がないなどいまいちスタンスがよくわからないサービスです。そして、DynamoDBの登場によりなおさらその存在が微妙になりつつある感じがしますが、おそらくDynamoと並行して残っていくサービスだと思います（根拠なし）。

おちラボではとりあえず、DynamoDBとSimpleDBを併用して運用しようかと考えており、ではさっそくセットアップして使ってみようと思ったものの情報があまりない？。ネットでググッてみてもSDKのなかのコマンドラインツールを使って、、、というのもめんどくさいこと書いてるし、、、と試行錯誤してシンプルなセットアップを見つけましたので、以下に手順を書いていきます。

１．SimpleDBを有効にする
公式サイトにアクセスして、まずは有効にしましょう。

２．IAMでSimpleDBを使えるようにする
ここが一番ハマりました。User PolisiesでSimpleDBを使えるようにPolicyを追加しようとしましたが、Policy TempleteにSimpleDBの項目がない！？でもここで諦めてはいけません。Policy generatorではちゃんとSimple DBはリストにありますので。ここで SimpleDBを使えるようにしましょう。なお、Resouseのところは

arn:aws:sdb:us-east-1:XXXXXXXXX:domain/*

と書けばいいと思いますが、XXXXXXXのところは適切な値にしてください。

３．Eclipse　Pluginからアクセスする

ここもポイントです。コマンドラインツールなんか使わなくても、Eclipseの AWS PluginにありAWS xploreを利用すればGUIで操作できます。Domainの作成はボタンクリックでできます。

というわけで、これからSimpleDBも利用していこうと思ってます。ノウハウが見つかればまた書いていきますね。

低コストなのはやはりGAEなのか 〜Elastic Beanstalkを触ってみて〜

先日からAmazonのJavaのPaasであるElastic Beanstalkを使っているのだが、思ったより金銭的コスト高い気がしてきた。Beanstalkはそれ自体の料金は無料で、バックで動いているEC2などの利用料金が取られる仕組みになっている。このバックで動いているサービスが厄介な感じだ。 

インスタンス課金の問題 
例えば、EC2はインスタンス単位の従量制課金になっている。GAEもインスタンス課金に変わったが、ちょっとこれとは意味が違う。まず、バックで動くEC2インスタンスは、ウェブアプリにアクセスに関わらず常時動いているということになる。先日でお試しでEnvironmentを作ってちょっとアプリを置いて、数回試しただけなのだが、Account Activityを確認してみたら、

Amazon EC2 running Linux/UNIX　186 Hrs 

となっている。186Hrsってどういうこと？アカウント作成したのはほんと数日前で、ほとんどアクセスしてないのに。。。なぜ186時間なのかといえば、

• アクセスがなくてもインスタンスは起動し続けている
• 1Environmentごとに1インスタンスが起動

という仕組みで、お試して2つぐらいEnvironmentを作ったままにしていたからそうなった感じ。まあこれは世間的にはあたり前のことかもしれないけど、今までGAEしか使ってなかったものからするとちょっと意外なんですよね。

もれなくサービスがついてくることの問題

Elastic Beanstalkってとても高機能なJavaサーブレットコンテナですが、それはつまり単体のサービスではなく、いろいろなサービスを組み合わせたものであると。。。しかも有料のね。おさらいするとElastic Beanstalkとは、

• Amazon EC2
• Amazon EC2 EBS
• Elastic Load Balancing
• Amazon CloudWatch
• Amazon Simple Notification Service

がバックで動いていることで、スケーラビリティの高いPaaSを実現しているわけですが、これらは使うと当然課金されます。で、やっかいなことにBeanstalkではこれらのサービスがもれなくついてきます。ロードバランサーなんかいらないんだけど、、、といっても外せません。だから、ロードバランサーについても今現在で、

Elastic Load Balancing　199 Hrs

という課金になっています。これは1Environmentを構築するたびに、Load Balancingも立ち上がっているということが原因です。

文句があるならEC2で環境構築しろや

まあ、そういうことでしょうね。EC2単体でLinuxを用意してそこで環境整備すればそれで解決するのだとは思います。ですけどね、、、環境整備が面倒だからこういったPaaSに感心があるわけでー。逆に言うと、そういう手間暇かからないんだから金は取られて当然ってことになるんですかね。

やっぱりGAEって安いのかな

そう考えると、GAEってやっぱり安い気がします。インスタンスは、アクセスが有るときのみ動いているようですし無料枠もあります。GAEが正式版になって、「1日28インスタンスだけ？！高すぎ」とか思ったりしましたが、使わなければ課金されないという手軽さがあるんですよね。

AWSにも無料枠はありますので、実際今のところ課金は発生していません。ただ無料枠適用は最初の1年だけのようですし、今後、永続的に利用する環境となるとちょっと心配です。まあ、毎月数千円でインフラが整うっているのは、一般的にみると安いんでしょうね。大学はいちおう回線ありますし、マシンもありますから別にEC2とか使わなくてもいいのでは？と思われるかもしれませんが、やはりメンテナンスが。。。研究室レベルのちょっとしたインフラとしてはちょっとBeanstalkやEC2は割りに合わないのかなぁ。

DynamoDB:IAMでのUserPolicyによるアクセス制限

諸事情で、ちょっといまAWSのDynamoDBについて調査中のメモ書き。
DynamoDBをラボで利用しようかと検討しているのだが、問題となるのはゼミ内で共有する時に問題となるのがテーブルへのアクセス制御。EclipseのPluginを使うとテーブルが全て見えてしまうのでこれは正直都合が悪い。そこで、要求仕様として

• ユーザごとにテーブルへのアクセス制限をする。具体的にはテーブルを見えないようにする。

というのを設定したわけだが、ここでちょっとハマった。。。

DynamoDBではIAMを用いてポリシーを記述することができるらしく、DynamoDBのテーブル参照のActionはおそらく、

• dynamodb:ListTables

なんだろうと推測。これをユーザとテーブルに対応したARNでDenyさせとけばいいと思ったわけだが、どうやらListTablesのアクションはARNでは制御できないとか。。。。
具体的にいうと

"Resource": "arn:aws:dynamodb:*:xxxxxxxxxxxxx:table/table1"

という記述で、table1に対してDenyするということはできない。ここは、
"Resource": "*" とするしかないわけだ。つまり、

• テーブルリストは全て見せるか全て見せないかの2択。
• アイテムの参照のレベルでテーブル毎にアクセス制限をつける

という戦略をとるしかないようだ。具体的には、

• 全てのリソース（テーブル）に対する"dynamodb:ListTables"をAllowとするステートメントを用意
• 特定のテーブルに対してアイテムのScanやCRUD操作ができるActionをAllowとするステートメントを用意

とすれば良いようだ。

なお、テーブル毎にステートメントを書いていくのは面倒な気がするがちょっとしたコツがある。AWSのARNの書き方では、*を利用した前方一致の指定ができる。そこで、プロジェクト毎にテーブル名の名前の付け方を決めておけば、*で一発で検索できる。例えばtest用のテーブルにtestという接頭語をつけるようにしておけば、test*の指定でOKとなる。