」となったんですが、幸いDynamoDBのテーブルをまったく作ったことのないAWSアカウント上だったので大事にいたりませんでした。めでたしめでたし👏となるはずはもちろんないので、原因を探りました。Keyを設定したSDKでテーブルの作成を実行していたことが原因でした。]}と書かれています。Lambdaと、Lambda経由でいろんなサービスを実行するための諸々の権限が含まれている...という感じですかね。最初にこのポリシーをアタッチするときにポリシーの名前だけ見ていて、これをアタッチすればLambdaを見たり編集できるぜと勘違いをして設定していたかと思います。原因ではあったのですが、他のポリシーでも同様の現象を引き起こす可能性があります。そこでいくつか対策を考えてみました。権限を適切に付与するまずは権限を適切に付与できているのか確認し、できていなければ修正を行おうと思います。適切に権限が付与されているか確認するのには、IAMで各ユーザーに付与されているアクセスアドバイザーが便利です。アクセスアドバイザーではアクセスできるサービスアクセスできるサービスの権限がどのポリシーで付与されているか最後に使用したのはいつかがわかります。そのユーザーに対して余計な権限が付与されているようであれば、アタッチされているポリシーやロールの見直しを行いましょう。そもそもIAMユーザーを無闇矢鱈に発行しないそもそもそのユーザーアカウントは必要なのか考えたほうがよいかもしれません。不要なアカウントは発行しないような設計を行うべきです。スイッチロールを使う何かあったらクリティカルなAWSアカウントに不用意にユーザーを作りたくない。要所要所で作業はできるようにしておきたい。そんな場合はスイッチロールできるように設定しておくといいかもしれません。本番用と開発用とでAWSアカウント2つ用意しておき、普段は開発用のAWSアカウントのみを使用するようにし、本番のAWSアカウントでは必要最低限のユーザー、ロールだけにしておく。必要に応じてロールをスイッチするようにすれば事故の可能性は減らせるかなと思います。Roleで複数のAWSアカウント間を切替えるに詳しく書かれています。本番と開発とでAWSアカウントが別れていない場合は、組織の大小やサービスの状態などにもよるでしょうが、アカウントを分ける検討をするとよいかと思います。既存のポリシーをアタッチするときはちゃんと確認する当前ですが、何するかわからないポリシーをアタッチしてはいけないということですね。終わりに今回のように、DynamoDBなどは1つのAWSアカウントに対して同じ名前のテーブルは一つしか作成できないので、万が一テーブルの破棄などを誤って行ったらサービスが死んでしまう可能性があります。これはだいぶ怖いですね。IAMは本当難しいなぁと最近感じるところですが、ちゃんと管理できてれば安心感がグッと変わってきます。安心感は開発のしやすさにダイレクトに影響してきますので、しっかり管理していきたいところです。sasaki@ryosukesFollow株式会社クラシコム「北欧、暮らしの道具店」を運営するクラシコムのエンジニアチーム。upLoginユーザーは見つかりませんでした。