投稿日：2020-07-09T23:42:33+09:00

AWS WAF+CloudFront+S3でIPアドレス制限するときはIPv6 Enabledを確認しよう

発生した事象

VPNからのみアクセスしたいS3をhttps付きで用意したいと思い、AWS WAF+CloudFront+S3の構成を用意
WAFのWeb ACLのRulesでIPアドレス制限のルールを設定した
が、何故かそのルールに引っかからずIPアドレス制限ができなかった

起こっていた理由

CloudFrontがIPv6 Enabled:true

PCや家のネットワークがIPv6を利用するようになっている

IPアドレス制限をIPv4でやる

VPNはIPv4アドレスのみ払い出されていた

という設定・環境だった

→IPv6でリクエストが飛んでIPv4のIPアドレス制限にひっかからない、という状態になっていた

対策

CloudFrontのIPv6 Enabledを無効化する

以上です
*VPNのIPv6アドレスがあるならそれを設定するべきな気もします

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T23:32:24+09:00

IAMで副作用なくリージョン縛りをする方法

やりたいこと

IAMでリージョン縛りをする（特定のリージョンから来たリクエスト以外は弾く）ポリシーを書く方法。
素でやるとCloudFrontやIAM自身のようなグローバルサービスも「東京以外」扱いで弾かれてしまうので、それを回避する必要がある。

NGパターン

以下のようなポリシーを書きたくなるが、これは失敗する（正確には、縛りは利くのだがIAM、CloudFront、Route53といったグローバルサービスも共倒れになる）。グローバルサービスのエンドポイントが北バージニア（us-east-1）に存在することが原因。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllActionsNotFromTokyo",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "ap-norhteast-1"
                    ]
                }
            }
        },
        {
            "Sid": "AllowAllActios",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}
OKパターン

以下のように改修すればOK。

ここではS3、CloudFront、IAM、Route53、サポートの5つのサービスを"東京縛り"の除外対象としている。

NotActionがポイント。「以下のアクションはコンディション句を経た結果としての明示的なDenyから除外する」という意味となり、これによって後続の明示的なAllowで許可される余地が生まれる（明示的なDenyはそれ以外の全てに優先するので、これをしてしまうと、どう頑張ってもAllowはできなくなる点に注意）。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllActionsNotFromTokyo",
            "Effect": "Deny",
            "NotAction": [
                "s3:*",
                "cloudfront:*",
                "iam:*",
                "route53:*",
                "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "ap-northeast-1"
                    ]
                }
            }
        },
        {
            "Sid": "AllowAllActios",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}
裏技パターン

グローバルサービスのエンドポイントが北バージニア（us-east-1）にあることを逆手に取ると、最初のポリシーでも動くようになる。

グローバルサービス触るときは北バージニア用のIAMユーザーないしIAMロールでやる、というルール決めができるなら、多分これでも運用に乗る。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllActionsNotFromTokyo",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "us-east-1"
                    ]
                }
            }
        },
        {
            "Sid": "AllowAllActios",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}
おまけ

S3はグローバルサービスだと思っていたが、バケットごとにエンドポイントが分かれる（言われてみれば・・・）ので、最初のポリシーで試すと以下のような状態になる（北米のバケットが「エラー」として表示される。バケットの中身も勿論閲覧不可）。

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T23:25:43+09:00

【AWS】 CircleCI/CD 自動デプロイでハマったエラーの解消【Capistrano 】

Railsで作成したポートフォリオをAWS EC2にデプロイし、最終段階でCicleCIによるCD(自動デプロイ)を導入していて、大きくハマった点があった為、備忘録かつ誰かの一助になればと思い、記します(理解が誤っている場合がありますので、修正があれば都度修正します)。

自動デプロイの記事について、先人の記事を見ながら実装を進めていたのですが、ssh keysのインストールはできており、最終段階の「Capistrano deploy」で以下のようなエラーがおき、長らくハマっていました。

Net::SSH::AuthenticationFailed: Authentication failed for user エラー

文面からSSH key関連のエラーであることはわかります。しかし、前タスクでInstalling additional ssh keysはSuccessしているしなぜ？と思っていました。ググっているとここでハマる方が多いようでした。

結論としては、

CircleCIに登録したKeyが間違っていた

その結果、Fingerprintとしてconfig.ymlに記載していた値が違う為、デプロイできなかった
config.yml
   - add_ssh_keys:
          fingerprints:
            - "XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX" # こちらの値
ということです。

最初にCircleCIに登録していた鍵は、AWS EC2を構築しているときにダウンロードした、「hoge.pem」でした。

先人の記事を参考に進めていて、書いてあるとおり何も疑わずにEC2からダウンロードしていたhoge.pemをcatしてコピーし、CircleCIに登録していました。

最終的に、自分のケースでは「pem形式の鍵をCircleCIに登録する」という点はあっていたのですが、catする鍵が違っていたようです。

CircleCIに登録すべき鍵は、ssh-keygenして作成した「~rsa」(公開鍵ではない)で、ローカルからEC2にログインする際に使用する秘密鍵でした。

EC2にSSH接続する際、初期の方で、EC2にログイン→.sshに移動→authorized_keys(中身はssh-keygenして作成した~rsa.pub)に対応する秘密鍵を、ローカルの.sshに置いて~rsaでログインしていると思うのですが、CircleCIに登録すべきSSH keyはそちらでした。

しかし、ssh-keygenして生成した~rsaは、OPENSSH形式であり、そのままではCircleCIに登録できません。実際に登録しようとすると怒られて登録できませんでした。
※CircleCIはOPENSSH形式の鍵に現時点では対応していないとメンターさんから伺いました。

登録できない？じゃあ結局どの鍵を登録すればいいんじゃ！とそこでもハマっていたのですが、
結果的にどうするのかというと、

rsa鍵（OPENSSH形式）をpem形式(catするとBEGIN RSA PRIVATE KEY---で始まる)の鍵に変換する」というシンプルな解決方法でした。

こちらの記事を参考に、
SSH KeyをOpenSSH形式化からPEM形式に変換
local
ssh-keygen -p -m PEM -f hoge_key_rsa
こちらのコマンドで、rsaをpem形式に変換できると思います。
OPENSSH形式ではなくなっていますが、今までのように
local
$ ssh hoge_key_rsa
Last login: ------- 2020 from ec2-xx-xx-xx-xx.compute-1.amazonaws.com

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
EC2にSSH接続は可能です。

pem形式に変換されたhoge_key_rsaをcatすると、
hoge_key_rsa
-----BEGIN RSA PRIVATE KEY-----
省略
==
-----END RSA PRIVATE KEY-----
と出てくると思います。こうなっていればOKで、ハイフンを含めてBEGINからENDまで全てをコピーし、CircleCIに追加します。

ちなみにOPENSSH形式のままの鍵(rsa)を開くと、
local
-----BEGIN OPENSSH PRIVATE KEY-----
...
と出てきますが、このままではCIrcleCIに登録できないとういう訳です。

先ほどのcatしてコピーしたコードを、CircleCIに登録します。
そして生成されたFingerprintを、localのCircleCIの設定ファイルであるconfig.ymlに記載することで、エラーが解消し、無事デプロイが完了しました。

随時加筆・修正していきたいと思います！

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T23:01:06+09:00

AWS 無料アカウントの作成方法

目次

概要

AWS 無料対象のサービス

AWSアカウント作成

1. 概要

AWSには無料利用枠があり、AWS のプラットフォーム、製品、サービスを無料で実際に体験できます。
ここでは、AWSの無料アカウント作成方法を記載します。

2. AWS 無料対象のサービス

無料対象には3つの種類があります。

項目無期間無料 12ヶ月無料トライアル

有効期限なし 12ヶ月サービス毎に異なる

有効期限開始なし AWSアカウント作成日トライアルサービス開始日

代表サービス AWS Lambda (1,000,000 件/月) EC2 (t2.micro インスタ) Redshift

詳細は、AWS公式ページを参照
AWS 無料利用枠

3. AWSアカウント作成

すでに、AWSアカウントを持っている人は、この工程Skipしてください

3-1. 登録画面にAccess

AWS アカウント作成の流れ
上記のリンクをクリック

「AWS アカウントを今すぐ無料で作成」をクリック

こんなページが開く

英語だと分かりにくいので日本語に変更する

日本語表示になる

3-2. アカウント情報を入力

・Eメールアドレス
一つしか登録できないため、複数人で同一のAWSアカウントを使用する場合には、
メーリングリストでの登録を推奨

・AWSアカウント名
AWSを利用する際の管理ユーザ名、あとで変更できるため、そこまで悩まなくてもOKです

こんな画面に遷移する

・アカウントの種類
会社などの組織での利用の際には、プロフェッショナルを選択してください。
個人利用の場合には、パーソナルを選択する。

ほとんどの人は、個人利用だと思うので、「パーソナル」を選択
「会社名」の項目を記入しなくてよくなります

・アドレス
・市町村
・都道府県または地域
上記は、なぜか日本語での入力ができず、数字＋アルファベットの入力しかできないので、頑張ってください

英語での住所表記がよく分からない人は、下記のサイトで日本語の住所を変換させてみてください
JuDress | 住所→Adress変換

こんな画面に遷移する

3-3. 支払い情報の入力

必要なカード情報を入力

本人確認の画面に遷移する

電話番号を入れる

登録した電話番号にAMAZONから検証コード（数字４桁）が飛んでくるので、それを入力

登録成功

3-4. AWSサポートプランの選択

基本的には、無料の「ベーシックプラン」でOK
会社での利用や、商用利用の場合には、必要なサポートレベルに応じて有料プランを選ぶことを推奨します

最後にアンケートみたいなのが出てくるのでテキトーに選ぶ

3-5. AWS Consoleにログイン

こんな画面に遷移します

まだ、IAMユーザは作成していないので、ルートユーザーでLogin
ルートユーザーのメールアドレスは、AWSアカウント作成時に登録したメールアドレスです

パスワードを入力してクリック

AWS Consoleに無事Loginできました

なぜか、英語表記なので、画面一番下までスクロールして、日本語に変更します

まとめ

ここまで来れば、OKです
AWSをもっと安全に使いたい人は、下記のQiitaのPageを参照して、設定してみてください。

AWSアカウントを作成したら最初にやるべきこと -セキュリティ編-

また、EC2インスタンス上にAWS Cloud9を使って簡単に開発環境が作成できる方法を紹介しています。
是非、見て試してみてください

Amazon EC2 インスタンスにAWS Cloud9開発環境を作成する

項目	無期間無料	12ヶ月無料	トライアル
有効期限	なし	12ヶ月	サービス毎に異なる
有効期限開始	なし	AWSアカウント作成日	トライアルサービス開始日
代表サービス	AWS Lambda (1,000,000 件/月)	EC2 (t2.micro インスタ)	Redshift

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T22:46:56+09:00

AWSをゼロから勉強する。vol.0

7/9
これから1日10分でも毎日勉強して
AWSについての理解を深めていく様をメモとして残していきます。
同じ境遇の人は、気軽に声かけてもらえると嬉しいです。
お互いに情報共有しあえたら最高です。

勉強に使う参考書
「Amazon Web Service クラウドサーバ構築ガイド ~コストを削減する導入・実装・運用ノウハウ~」

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T21:44:35+09:00

AWSコンソールにログインするためのMFA（多要素認証）をAWS CLIで無効化する

MFAデバイスを失ってAWSコンソールにログインできなくなってしまった！そんなとき、AWS CLIが使えて権限さえついていれば自分自身でMFAを無効化できる。
aws iam list-mfa-devices --user-name {ユーザー名}
ここで表示されるSerialNumber（arn:aws:iam::***:mfa/***）を控えておいて、
aws iam deactivate-mfa-device --user-name {ユーザー名} --serial-number {シリアルナンバー}
以上でもうログインできるようになっている。

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T20:59:40+09:00

AMIとsnapshotによるバックアップと復元

初心者向けの内容です。
AWS初学者の方の一助になれば幸いです。

AMI(Amazon Machine Image)とsnapshotを利用して、
インスタンスのバックアップと復元をする方法をまとめさせていただきます。

AMIとsnapshotの違い

AMI(あみ)はストレージ部分も含んだバックアップ、snapshotはストレージ部分のみのバックアップ、という差があります。

snapshotは、既に存在しているインスタンスに対しアタッチしすることで使用可能な状態になります。
しかし、AMIは取得したAMIをそのまま起動することでインスタンスとして使用可能な状態へと復元ができます。

そのあたりの違いを確認していければ良いなと思います。

また、AMIもsnapshotも静止点確保が推奨要件のため、可能であればインスタンスを停止したいですね。
どうしてもインスタンスの停止が難しい場合は、データ処理の少ない時間帯を選び、双方のデータ齟齬が少なくなるようにすると良いとのことです。

AMIでのバックアップと復元

AMIを利用してバックアップを取得し、インスタンスとして使用可能な状態へと復元します。

「EC2ダッシュボード」より、AMIを作成したいインスタンスをチェックし、「アクション」、「イメージ」、「イメージの作成」と順に選択していきます。

イメージの作成画面が表示されたら、「イメージ名」を入力して、他項目を任意で入力していきます。
(今回は「イメージの説明」も入力しています)

「イメージの作成」を選択すると作成処理が開始されるため、左ペインより「AMI」を選択します。

ステータスが「available」に変わったら、AMIの作成が完了しているので、「アクション」より、「起動」を選択します。

すると、インスタンスを新規作成する画面が表示されるため、順に設定を行うことでインスタンスとして利用可能な状態となります。

snapshotでの復元

以下の流れにて、snapshotでのバックアップと復元を実施したいと思います。

インスタンス「Webserver」のsnapshot作成

インスタンス「Webserver」のEBSをデタッチ(擬似障害)

作成したsnapshotからボリュームの再作成

作成したボリュームをインスタンス「Webserver」にアタッチし復旧

snapshot作成

左ペインの「Elastic Block Storage」の「ボリューム」を選択し、snapshotを取得したいボリュームを選択します。
この際、アタッチされている場所(本環境では"/dev/xvda")は後で使用するので覚えておきます。

続いて、「アクション」、「スナップショットの作成」を選択し、スナップショットの説明やタグを入力します。
Nameタグを設定しておくと識別が楽です。

「スナップショットの作成」を選択することで作成が開始されます。
左ペインの「スナップショット」を選択して状況を確認します。

もちろん現時点ではインスタンスへの接続が可能です。

インスタンスのEBSをデタッチしてみる

インスタンス「Webserver」のEBSをデタッチしていきます。
(インスタンスが稼働している場合は、停止しておきます)

左ペインの「ボリューム」を選択して、該当するインスタンスにチェックを入れ、「アクション」から「デタッチ」を選択します。

デタッチが終わると、ボリュームの状態が「in-use」から「availvable」に変化します。

この状態でインスタンスを起動すると、インスタンスは起動できません。

"/dev/xvda"にrootボリュームがないということですので、復旧をしていきます。

作成したsnapshotからボリューム作成、復旧の確認

左ペインの「スナップショット」より、先ほど作成したsnapshotを選択します。
「アクション」より「ボリュームの作成」を選択します。

入力項目があるので適宜入力して、「ボリュームの作成」を選択します。
Nameタグを設定しておくとやはり便利です。

注意事項は、インスタンスと同じAZに作成することです。
インスタンスからは別のAZのEBSに接続することはできない、という特性上からです。

しばらくするとボリュームが出来上がるので、左ペインの「ボリューム」を選択し、出来栄え(availableとなっていること)を確認します。

作成したボリュームを選択して、「アクション」、「ボリュームのアタッチ」を順に選択します。

アタッチするインスタンスと、デバイスを選択します。

この時、インスタンスと異なるAZにボリュームを作成してしいるとインスタンスが選択できません。
また、デバイスはのアタッチ先は、確認した"/dev/xvda"を選択します。別の場所だとインスタンスは起動しません。

アタッチが完了すると状態がin-useに変更になります。これでsnapshotを使用したインスタンスの復旧は完了です。

参考資料

参考資料1：これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版

参考資料2:AWS認定資格試験テキスト AWS認定ソリューションアーキテクト-アソシエイト

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T19:42:17+09:00

AWS SNSが重複してメッセージを配信してしまう

よくAWSに触れるものです。

AWS SNSでちょっとハマりました。

問題

AWS SNSからlambda経由で何故かメッセージの送信に成功しているのに重複してメッセージが送られてきます。

そもそもSNSからlaｍbdaに対して重複して配信しているようでした。

配信再試行ポリシーのnumRetriesを0にしても解決しません。

解決

lambdaで処理を終える際にresponseメッセージで成功ステータスを送る必要がありました。
(以下はpythonですが、他の言語も同様)
##lambda関数内

def main()

    ...

    return {
        'statusCode': 200
    }
以上で重複配信がなくなります。

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T18:18:51+09:00

AWSのCentOS8公式イメージ

公式イメージ

CentOS 8でEC2インスタンスを作成しようと、AWS MarketplaceからCentOS 8で検索すると、ずらずらっといくつかAMIが表示されるものの、公式イメージが出てきませんでした。

まだ、公式イメージは提供されてへんのかいな…と途方に暮れかけていたところ以下のページを発見。

https://wiki.centos.org/Cloud/AWS

AMIの画面からインスタンスを作成したいリージョンのAMI IDを入力して検索すると出てきます。

例えば東京リージョンであれば、ap-northeast1なので、「ami-089a156ea4f52a0a3」で検索

出てきた。

ここから起動して、とりあえず使ってみよっと。

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T18:09:08+09:00

Redash で google login を有効にする方法。権限変更でmanage.py が動かない時の代替案

これは何

自分でAWSで提供されているAMIを使ってインストールした場合、google loginはデフォルトで無効になっていた。
最初はRedash独自の認証機構を使っていたが以下の問題があった。

社内のRedashユーザが退職したケースに対応が面倒。毎回忘れずにユーザ削除をしないといけない

多要素認証がない

Redash は google login を使えるので、導入して上記問題を解決したい。

Redash とは？というのは、他にもたくさん情報があるので割愛します。https://redash.io/
よくRe:dashと表記されているのでそれが正式名称なのかな？と思いましたが、公式サイトだとRedashの表記になっていたのでこの記事ではその表記に合わせます。

google login を入れた時に考えられる問題点

社内ドメインのアドレスのユーザだったら誰でもログインできる？

google login を有効にして、許可するドメインをかくと、そのドメインをもつメールアドレスのユーザが誰でもログインしてRedashを使ってQueryを書くことができる。センシティブなデータを扱っている場合、誰でも入れるというのは避けたい

新規ユーザには default の group がデフォルトでつくようになっているが、その権限を制限できるか？

解決策？

ここら辺を確認して権限をつけたり外したりできそう　http://next4us-ti.hatenablog.com/entry/2019/03/20/180311

manage.py がどんなサブコマンでも全く応答しないので使えない

真：解決策

default グループから権限を剥奪する

member グループとでも命名したものにデフォルト同様の権限をつける（新規作成でデフォルトの権限）。新たにRedashを使うユーザにはこのグループをGUIから操作して手動で割り当てる

私の環境はでmanage.pyは全く応答しなかったので、データベースを直接いじることにした。これについてはハマりどころの章で説明します。

google login有効化まではこの通りにやればできる手順書

token 作成はこれに沿ってやる => https://redash.io/help/open-source/admin-guide/google-developer-account-setup

token をサーバに設定するのはこの手順でやる => https://redash.io/help/open-source/setup#Google-OAuth-Setup

ハマりどころ（この記事のメインコンテンツ）

特にAWSのAMIを使った場合は内部的にdockerで動いているので、ちょっとだけハマったのでそれについてだけ補足説明を書いておきます。

docker-compose.yml と env のありか

サーバにsshログインすると以下のディレクトリに置かれているのがわかります。
envにpostgresのパスワードなどが書かれているので、中身見ておきましょう。
# pwd
/opt/redash
# ls
docker-compose.yml  env  postgres-data
サーバログインしてsudo su - で root になってディレクトリ移動し、dockerコンテナ全部再起動すると env 読み込みできる。うまくいかなければサーバ再起動でもOK。
dockerコンテナ再起動方法は以下のもの
$ docker-compose down
$ docker-compose up -d
group権限の書き換え

権限やクエリを保存している postgres に繋いで、 groups テーブルの default グループの permissions のところを書き換えて権限0にする。
AWS AMIから作ったインスタンスはデフォルトでローカルにpostgresコンテナが立っているようなので、ここに接続する。
# docker exec -it --user root redash_postgres_1 bash
// docker コンテナの中で以下のコマンド
// password はenv ファイルに書かれているものを使用
# psql -h localhost -U postgres -d postgres --password
postgres に入った後はMySQLとの対応コマンドリストを参照してみていく。神ドキュメント => 　https://qiita.com/aosho235/items/c657e2fcd15fa0647471

コンソールでグループを作った上で以下の作業を行う。グループ作成の時に空白を入れないこと。DBにそのまま保存されてしまう、whereで絞る時に苦労する。
postgres=# select * from groups;
 id | org_id |  type   |    name    |                                                                              permissions                                                                               |          created_at
----+--------+---------+------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------
  1 |      1 | builtin | admin      | {admin,super_admin}                                                                                                                                                    | 2020-06-30 05:12:08.756199+00
  2 |      1 | builtin | default    | {create_dashboard,create_query,edit_dashboard,edit_query,view_query,view_source,execute_query,list_users,schedule_query,list_dashboards,list_alerts,list_data_sources} | 2020-06-30 05:12:08.756199+00
  3 |      1 | regular | member     | {create_dashboard,create_query,edit_dashboard,edit_query,view_query,view_source,execute_query,list_users,schedule_query,list_dashboards,list_alerts,list_data_sources} | 2020-07-01 09:44:08.588092+00
(3 rows)
# UPDATE groups SET permissions = '{}' WHERE name = 'default';
postgres=# select name, permissions from groups;
            name             |                                                                              permissions
-----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 admin                       | {admin,super_admin}
 default                     | {}
 member                      | {create_dashboard,create_query,edit_dashboard,edit_query,view_query,view_source,execute_query,list_users,schedule_query,list_dashboards,list_alerts,list_data_sources}
これで、このグループをつけたユーザがどうなるか？というところだが、自分のプロフィール以外実質何もできなくなったのでOK。一応ログインはできる。

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T18:09:08+09:00

Redash で google login を有効にする方法。権限変更のためのmanage.pyが動かない時の代替案

これは何

自分でAWSで提供されているAMIを使ってインストールした場合、google loginはデフォルトで無効になっていた。
最初はRedash独自の認証機構を使っていたが以下の問題があった。

社内のRedashユーザが退職したケースに対応が面倒。毎回忘れずにユーザ削除をしないといけない

多要素認証がない

Redash は google login を使えるので、導入して上記問題を解決したい。

Redash とは？というのは、他にもたくさん情報があるので割愛します。https://redash.io/
よくRe:dashと表記されているのでそれが正式名称なのかな？と思いましたが、公式サイトだとRedashの表記になっていたのでこの記事ではその表記に合わせます。

google login を入れた時に考えられる問題点

社内ドメインのアドレスのユーザだったら誰でもログインできる？

google login を有効にして、許可するドメインをかくと、そのドメインをもつメールアドレスのユーザが誰でもログインしてRedashを使ってQueryを書くことができる。センシティブなデータを扱っている場合、誰でも入れるというのは避けたい

新規ユーザには default の group がデフォルトでつくようになっているが、その権限を制限できるか？

解決策？

ここら辺を確認して権限をつけたり外したりできそう　http://next4us-ti.hatenablog.com/entry/2019/03/20/180311

manage.py がどんなサブコマンでも全く応答しないので使えない

真：解決策

default グループから権限を剥奪する

member グループとでも命名したものにデフォルト同様の権限をつける（新規作成でデフォルトの権限）。新たにRedashを使うユーザにはこのグループをGUIから操作して手動で割り当てる

私の環境はでmanage.pyは全く応答しなかったので、データベースを直接いじることにした。これについてはハマりどころの章で説明します。

google login有効化まではこの通りにやればできる手順書

token 作成はこれに沿ってやる => https://redash.io/help/open-source/admin-guide/google-developer-account-setup

token をサーバに設定するのはこの手順でやる => https://redash.io/help/open-source/setup#Google-OAuth-Setup

ハマりどころ（この記事のメインコンテンツ）

特にAWSのAMIを使った場合は内部的にdockerで動いているので、ちょっとだけハマったのでそれについてだけ補足説明を書いておきます。

docker-compose.yml と env のありか

サーバにsshログインすると以下のディレクトリに置かれているのがわかります。
envにpostgresのパスワードなどが書かれているので、中身見ておきましょう。
# pwd
/opt/redash
# ls
docker-compose.yml  env  postgres-data
サーバログインしてsudo su - で root になってディレクトリ移動し、dockerコンテナ全部再起動すると env 読み込みできる。うまくいかなければサーバ再起動でもOK。
dockerコンテナ再起動方法は以下のもの
$ docker-compose down
$ docker-compose up -d
group権限の書き換え

権限やクエリを保存している postgres に繋いで、 groups テーブルの default グループの permissions のところを書き換えて権限0にする。
AWS AMIから作ったインスタンスはデフォルトでローカルにpostgresコンテナが立っているようなので、ここに接続する。
# docker exec -it --user root redash_postgres_1 bash
// docker コンテナの中で以下のコマンド
// password はenv ファイルに書かれているものを使用
# psql -h localhost -U postgres -d postgres --password
postgres に入った後はMySQLとの対応コマンドリストを参照してみていく。神ドキュメント => 　https://qiita.com/aosho235/items/c657e2fcd15fa0647471

コンソールでグループを作った上で以下の作業を行う。グループ作成の時に空白を入れないこと。DBにそのまま保存されてしまう、whereで絞る時に苦労する。
postgres=# select * from groups;
 id | org_id |  type   |    name    |                                                                              permissions                                                                               |          created_at
----+--------+---------+------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------
  1 |      1 | builtin | admin      | {admin,super_admin}                                                                                                                                                    | 2020-06-30 05:12:08.756199+00
  2 |      1 | builtin | default    | {create_dashboard,create_query,edit_dashboard,edit_query,view_query,view_source,execute_query,list_users,schedule_query,list_dashboards,list_alerts,list_data_sources} | 2020-06-30 05:12:08.756199+00
  3 |      1 | regular | member     | {create_dashboard,create_query,edit_dashboard,edit_query,view_query,view_source,execute_query,list_users,schedule_query,list_dashboards,list_alerts,list_data_sources} | 2020-07-01 09:44:08.588092+00
(3 rows)
# UPDATE groups SET permissions = '{}' WHERE name = 'default';
postgres=# select name, permissions from groups;
            name             |                                                                              permissions
-----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 admin                       | {admin,super_admin}
 default                     | {}
 member                      | {create_dashboard,create_query,edit_dashboard,edit_query,view_query,view_source,execute_query,list_users,schedule_query,list_dashboards,list_alerts,list_data_sources}
これで、このグループをつけたユーザがどうなるか？というところだが、自分のプロフィール以外実質何もできなくなったのでOK。一応ログインはできる。

インスタンスサイズが小さいと動かない

Redashに割り当てるインスタンスサイズは t2.micro だとnginxがエラー（確か internal server error？）を吐いてしまいました。おそらくメモリサイズが足りないのだろうと思って t3.small を割り当てると動きました。

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T12:47:36+09:00

【AWS】Wordpress「返答が正しいJSONレスポンスではありません」の対処法

現象

Amazon LinuxインスタンスでWordpressをたてた。その際パーマリンクを基本→投稿名に変更して記事を投稿しようとするも、「返答が正しいJSONレスポンスではありません」とエラーが出て投稿できない＆トップページ以外が表示できなくなってしまった。

wordpress返答が正しいJSONレスポンスではありません
上記記事でapache設定が原因とわかった。
sudo vi /etc/apache2/apache2.conf
記事の通り上記コマンドで設定ファイルに入ろうとするも、Amazon Linuxではそのようなファイルがなかった。

対処法

AWSドキュメントに方法が書いてあった。
WordPress がパーマリンクを使用できるようにするには

1.該当のインスタンスに接続した上で、下記コマンドでファイルに入る。
sudo vim /etc/httpd/conf/httpd.conf
2.<Directory "/var/www/html">で始まるセクションを見つける。（※複数の AllowOverride行があるため、間違えないように。必ず <Directory "/var/www/html">セクションの行を探す。vimで/htmlと検索すると、すぐ見つかる。)
<Directory "/var/www/html">
    #
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.4/mod/core.html#options
    # for more information.
    #
    Options Indexes FollowSymLinks

    #
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   Options FileInfo AuthConfig Limit
    #
    AllowOverride None

    #
    # Controls who can get stuff from this server.
    #
    Require all granted
</Directory>
3.上のセクションをAllowOverride None行をAllowOverride Allに変更。(None→All)

4.ファイルを:wqで保存する。

5.上記設定を反映させるため、sudo systemctl restart httpd.serviceで再起動させる。sudo systemctl status httpd.serviceで念のためアクティブになっているか確認。

上記設定をするとパーマリンクを基本以外にしても、記事の投稿ができたりトップページ以外も参照できるようになる。

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T11:57:22+09:00

【AmazonConnect】キューとルーティングプロファイル作成

概要

AmazonConnectでは外線からの通話をキューに振り分けることで、ユーザーに着信させることが出来ます。
また、ルーティングプロファイルをユーザに割り当てることでユーザーがどのキューから着信を受けるかを決めることが出来ます。

ここでは、キューとルーティングプロファイルの関係と作成方法に加え、任意のエージェントに着信させる方法ついてまとめたいと思います。

キューの作成

AmazonConnectインスタンスには、デフォルトで"Basic Queue"というキューが存在します。

画像の通りに進むとキューの管理画面に進むことが出来ます。
右上の「新しいキューの追加」からキューを作成できます。

今回はキューとユーザーの関係を一対一にしたいので、ユーザー分の数のキューを作成します。

画像の通り、6つのキューを作成しました。

ルーティングプロファイルの作成

こちらもデフォルトで"Basic Routing Profile"というプロファイルが存在します。

画像通りに進むとルーティングプロファイルの管理画面に進むことができ、右上の「新しいプロファイルを追加」から新しいルーティングプロファイルを作成できます。

ルーティングプロファイルの作成時に着信を受けるキューを設定します。複数設定できますが、キューとユーザーの関係を一対一にするため、一つのみ設定します。

また、作成には「デフォルトのアウトバウンドキュー」を設定する必要があります。
発信通話の際に使用するキューなので、着信と同じキューを設定しても大丈夫ですし、発信用のキューを作成しても構いません。

画像のようにキューの数だけルーティングプロファイルを作成しました。

まとめ

この設定で問い合わせフローを適切に設定すれば、ユーザーが複数いる場合（今回は6人想定）に明示的にユーザーに優先順位をつけて着信させることが出来ます。

問い合わせフローに関する記事は以下のURLから⇓

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T11:51:29+09:00

AWS SESでテストメールを送信すると「Email address is not verified」になる

AWS SESを使い、Domainの登録を済ませいざテストメールを自分のgmailアドレスにでも送ろうかと思ったらタイトルのエラーが出た。

原因

SESは最初の時点ではSandboxモードになっており、送信先が制限されていることが原因だった！

Sandboxモードの時点では「送信元(From)」と「送信先(To)」は同じである必要がある、あるいは「EmailAdress」タブにて登録済みであるアドレスにしか送れない。

上のとおり、FromとToを揃えたらエラーなく送信できた。

解決策

それは良いとしてSandboxを解除して、普通に使用したい場合。

左側のメニューより、「Sending Statistics」の画面に行くと「Reaquest a Sending License Limit Increase」というボタンがあるのでそれを押し手続きを踏むと制限が解除される。

以上！

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T10:33:18+09:00

[AWSメモ] 公式リンク

自分用メモです。
構築時に役立った公式のリンク集です

AWS アカウントIDの確認方法
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/console_account-alias.html#FindingYourAWSId

タスクのライフサイクルの見方
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-lifecycle.html

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T08:47:43+09:00

【AWS SAA-C02】新しいサービスのまとめ

はじめに

AWS SAAがC01からC02と新しいバージョンに移行された。新しいバージョンではSAA-C01では出題されなかった比較的新しいサービスについて出題されるとのことで、ネット上で試験に出題された・覚えた方が良いとよく言われているサービスをまとめていきたい。
（私は試験を受けてないので、あくまでネット上で出題されたとされる・覚えておくべきサービスを中心にまとめいきたいと思います。ご参考程度にご覧ください。）

サービス

FSx for Windows

用途

Windows Server上で、下記の管理機能をおこなう。
・エンドユーザーファイルの復元
・ユーザークォータ
・アクセスコントロールリスト（ACL）

説明

FSx for WindowsはWindows Server 上に構築された完全マネージド型のファイルストレージ。2019年3月から東京リージョンで利用可能になった。

今までLinuxベースの共有ファイルシステムであるEFSは存在したが、Windowsベースの共有ファイルシステムは存在しなかった。

Microsoft Windowsで構築したものとほぼ同じ仕様で運用でき、Active Directory(AD)統合やSMBプロトコル※を介してアクセスできる。

※SMBプロトコル：主にWindowsを中心としたネットワーク環境でファイル共有やプリンタ共有などに使用される通信プロトコル

EFSとFXsの違いを問われる問題が出題される可能性あり。

FXs for Lustre

用途

・機械学習、高性能コンピューティング (HPC)、ビデオ処理、財務モデリングなど、速度が重要なワークロード

説明

Amazon S3と統合された、フルマネージド型高性能ファイルシステム。
高速ストレージを必要とするアプリケーション向けのストレージシステム。

Windows FileserverとLustreの違い

Amazon FSx for Windows File Server：ビジネスアプリケーション（Windows Server）向け
Amazon FSx for Lustre：高性能ワークロード向け

Aurora Serverless

用途

・データベースの容量を手動ではなく、自動で管理

説明

Amazon Aurora(MySQL互換エディションおよび PostgreSQL互換エディション)のオンデマンド自動スケーリング設定。
データベースの容量を自動的に起動、シャットダウン、スケールアップまたはスケールダウンしてくれる。

Transit Gateway

用途

・グローバル展開（AWSグローバルネットワークを使用して AWS Transit Gateway は相互にリージョン間ピア接続できる。）
・ネットワークを簡素化

説明

AmazonVPC、AWSアカウント、オンプレミスネットワークを単一のゲートウェイに簡単に接続してくれる。中央ハブを介してVPCとオンプレミスネットワークを接続し、複雑なピア接続関係がなくなる

Snowmobile

用途

・膨大な規模のデータを短時間で転送
説明

超大容量データをAWSに移動できるエクサバイト規模のデータ転送サービス。すでにAWS Snowball・Snowball Edgeでデータ転送はできるが、それでも保存しきれない超大容量のデータや、データセンターを丸ごとAWSへ移行する際に使用できる。（Snowballl　80TB、Snowball Edge　100TB、Snowmobile　100PBまで転送可能※例外あり）

Snow系サービスの違いも出題される可能性あり。

Global Accelerator

用途

・アプリケーションパフォーマンスの高速化

説明

アプリケーションの固定エントリポイントを提供し、静的IPアドレスが提供されることで、様々なAWSリージョンおよびアベイラビリティーゾーンの専用IPアドレスを管理しなくて済む。

上記のような比較的新しいサービスも覚えると、SAA C-02の合格に近づくだろう。
参考
https://aws.koiwaclub.com/exam/passrecord/
・FSx for Windows
https://aws.amazon.com/jp/fsx/windows/
https://www.cloudsolution.tokai-com.co.jp/white-paper/2020/000268.html
・FXs for Lustre
https://aws.amazon.com/jp/fsx/lustre/
https://www.acrovision.jp/service/aws/?p=1129
・Aurora Serverless<
https://aws.amazon.com/jp/rds/aurora/serverless/
・AWS Sowmobile
https://aws.amazon.com/jp/snowmobile/
https://dev.classmethod.jp/articles/amazon-snowmobile-released/
・Global Accelerator
https://aws.amazon.com/jp/global-accelerator/faqs/

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T08:47:43+09:00

【AWS SAA-C02】新しく登場したサービスのまとめ

はじめに

AWS SAAがC01からC02と新しいバージョンに移行された。新しいバージョンではSAA-C01では出題されなかったサービスについて新しく出題されたとのことで、ネット上で試験に出題された・覚えた方が良いとよく言われているサービスをまとめていきたい。
（私は試験を受けてないので、あくまでネット上で出題されたとされる・覚えておくべきサービスを中心にまとめいきたいと思います。ご参考程度にご覧ください。）

サービス

FSx for Windows

用途

Windows Server上で、下記の管理機能をおこなう。
・エンドユーザーファイルの復元
・ユーザークォータ
・アクセスコントロールリスト（ACL）

説明

FSx for WindowsはWindows Server 上に構築された完全マネージド型のファイルストレージ。2019年3月から東京リージョンで利用可能になった。

今までLinuxベースの共有ファイルシステムであるEFSは存在したが、Windowsベースの共有ファイルシステムは存在しなかった。

Microsoft Windowsで構築したものとほぼ同じ仕様で運用でき、Active Directory(AD)統合やSMBプロトコル※を介してアクセスできる。

※SMBプロトコル：主にWindowsを中心としたネットワーク環境でファイル共有やプリンタ共有などに使用される通信プロトコル

EFSとFXsの違いを問われる問題が出題される可能性あり。

FXs for Lustre

用途

・機械学習、高性能コンピューティング (HPC)、ビデオ処理、財務モデリングなど、速度が重要なワークロード

説明

Amazon S3と統合された、フルマネージド型高性能ファイルシステム。
高速ストレージを必要とするアプリケーション向けのストレージシステム。

Windows FileserverとLustreの違い

Amazon FSx for Windows File Server：ビジネスアプリケーション（Windows Server）向け
Amazon FSx for Lustre：高性能ワークロード向け

Aurora Serverless

用途

・データベースの容量を手動ではなく、自動で管理

説明

Amazon Aurora(MySQL互換エディションおよび PostgreSQL互換エディション)のオンデマンド自動スケーリング設定。
データベースの容量を自動的に起動、シャットダウン、スケールアップまたはスケールダウンしてくれる。

Transit Gateway

用途

・グローバル展開（AWSグローバルネットワークを使用して AWS Transit Gateway は相互にリージョン間ピア接続できる。）
・ネットワークを簡素化

説明

AmazonVPC、AWSアカウント、オンプレミスネットワークを単一のゲートウェイに簡単に接続してくれる。中央ハブを介してVPCとオンプレミスネットワークを接続し、複雑なピア接続関係がなくなる

Snowmobile

用途

・膨大な規模のデータを短時間で転送
説明

超大容量データをAWSに移動できるエクサバイト規模のデータ転送サービス。すでにAWS Snowball・Snowball Edgeでデータ転送はできるが、それでも保存しきれない超大容量のデータや、データセンターを丸ごとAWSへ移行する際に使用できる。（Snowballl　80TB、Snowball Edge　100TB、Snowmobile　100PBまで転送可能※例外あり）

Snow系サービスの違いも出題される可能性あり。

Global Accelerator

用途

・アプリケーションパフォーマンスの高速化

説明

アプリケーションの固定エントリポイントを提供し、静的IPアドレスが提供されることで、様々なAWSリージョンおよびアベイラビリティーゾーンの専用IPアドレスを管理しなくて済む。

上記のような新しく出題されたサービスも覚えると、SAA C-02の合格に近づくだろう。
参考
https://aws.koiwaclub.com/exam/passrecord/
・FSx for Windows
https://aws.amazon.com/jp/fsx/windows/
https://www.cloudsolution.tokai-com.co.jp/white-paper/2020/000268.html
・FXs for Lustre
https://aws.amazon.com/jp/fsx/lustre/
https://www.acrovision.jp/service/aws/?p=1129
・Aurora Serverless<
https://aws.amazon.com/jp/rds/aurora/serverless/
・AWS Sowmobile
https://aws.amazon.com/jp/snowmobile/
https://dev.classmethod.jp/articles/amazon-snowmobile-released/
・Global Accelerator
https://aws.amazon.com/jp/global-accelerator/faqs/

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T08:47:43+09:00

【AWS SAA-C02】新しく登場したサービスの概要

はじめに

AWS SAAがC01からC02と新しいバージョンに移行された。新しいバージョンではSAA-C01では出題されなかったサービスについて新しく出題されたとのことで、ネット上で試験に出題された・覚えた方が良いと言われているサービスをまとめていきたい。
（私は試験を受けてないので、あくまでネット上で出題されたとされる・覚えておくべきサービスを中心にまとめいきたいと思います。ご参考程度にご覧ください。）

サービス

FSx for Windows

用途

Windows Server上で、下記の管理機能をおこなう。
・エンドユーザーファイルの復元
・ユーザークォータ
・アクセスコントロールリスト（ACL）

説明

FSx for WindowsはWindows Server 上に構築された完全マネージド型のファイルストレージ。2019年3月から東京リージョンで利用可能になった。

今までLinuxベースの共有ファイルシステムであるEFSは存在したが、Windowsベースの共有ファイルシステムは存在しなかった。

Microsoft Windowsで構築したものとほぼ同じ仕様で運用でき、Active Directory(AD)統合やSMBプロトコル※を介してアクセスできる。

※SMBプロトコル：主にWindowsを中心としたネットワーク環境でファイル共有やプリンタ共有などに使用される通信プロトコル

EFSとFXsの違いを問われる問題が出題される可能性あり。

FXs for Lustre

用途

・機械学習、高性能コンピューティング (HPC)、ビデオ処理、財務モデリングなど、速度が重要なワークロード

説明

Amazon S3と統合された、フルマネージド型高性能ファイルシステム。
高速ストレージを必要とするアプリケーション向けのストレージシステム。

Windows FileserverとLustreの違い

Amazon FSx for Windows File Server：ビジネスアプリケーション（Windows Server）向け
Amazon FSx for Lustre：高性能ワークロード向け

Aurora Serverless

用途

・データベースの容量を手動ではなく、自動で管理

説明

Amazon Aurora(MySQL互換エディションおよび PostgreSQL互換エディション)のオンデマンド自動スケーリング設定。
データベースの容量を自動的に起動、シャットダウン、スケールアップまたはスケールダウンしてくれる。

Transit Gateway

用途

・グローバル展開（AWSグローバルネットワークを使用して AWS Transit Gateway は相互にリージョン間ピア接続できる。）
・ネットワークを簡素化

説明

AmazonVPC、AWSアカウント、オンプレミスネットワークを単一のゲートウェイに簡単に接続してくれる。中央ハブを介してVPCとオンプレミスネットワークを接続し、複雑なピア接続関係がなくなる

Snowmobile

用途

・膨大な規模のデータを短時間で転送
説明

超大容量データをAWSに移動できるエクサバイト規模のデータ転送サービス。すでにAWS Snowball・Snowball Edgeでデータ転送はできるが、それでも保存しきれない超大容量のデータや、データセンターを丸ごとAWSへ移行する際に使用できる。（Snowballl　80TB、Snowball Edge　100TB、Snowmobile　100PBまで転送可能※例外あり）

Snow系サービスの違いも出題される可能性あり。

Global Accelerator

用途

・アプリケーションパフォーマンスの高速化

説明

アプリケーションの固定エントリポイントを提供し、静的IPアドレスが提供されることで、様々なAWSリージョンおよびアベイラビリティーゾーンの専用IPアドレスを管理しなくて済む。

上記のような新しく出題されたサービスも覚えると、SAA C-02の合格に近づくだろう。
参考
https://aws.koiwaclub.com/exam/passrecord/
・FSx for Windows
https://aws.amazon.com/jp/fsx/windows/
https://www.cloudsolution.tokai-com.co.jp/white-paper/2020/000268.html
・FXs for Lustre
https://aws.amazon.com/jp/fsx/lustre/
https://www.acrovision.jp/service/aws/?p=1129
・Aurora Serverless<
https://aws.amazon.com/jp/rds/aurora/serverless/
・AWS Sowmobile
https://aws.amazon.com/jp/snowmobile/
https://dev.classmethod.jp/articles/amazon-snowmobile-released/
・Global Accelerator
https://aws.amazon.com/jp/global-accelerator/faqs/

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T00:59:12+09:00

KMSで暗号化したSNS Topicに投入したメッセージをKMSで暗号化したSQS Queueに投入する

はじめに

*　こちらの手順に則って作業します。
*　（けど、上記の手順は昔のコンソール用の手順）
*　構築が終わったら、Resource Policyをガチャガチャいじる予定

Custom CMKを作る

KMS のコンソールにアクセス
Create Keyをクリック
Key typeはSymmetricを選択し、Key Material OriginはKMSを選択する
AliasにMyCustomCMKを入力する
Key AdministratorにIAM_ROLE_DEFAULT（自分で作ったIAM ROLEかIAM USER）を選択する
Key Usage PermissionにIAM_ROLE_DEFAULT（キーの使用者に該当。検証用なので、Administratorと同一）を選択する
Reviewで、SNSをPrincipal指定したStatementを追加する


{
    "Id": "key-consolepolicy-3",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::xxxxxxxxxxxx:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam:: xxxxxxxxxxxx:role/IAM_ROLE_DEFAULT"
            },
            "Action": [
                "kms:Create*",
                "kms:Describe*",
                "kms:Enable*",
                "kms:List*",
                "kms:Put*",
                "kms:Update*",
                "kms:Revoke*",
                "kms:Disable*",
                "kms:Get*",
                "kms:Delete*",
                "kms:TagResource",
                "kms:UntagResource",
                "kms:ScheduleKeyDeletion",
                "kms:CancelKeyDeletion"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam:: xxxxxxxxxxxx:role/IAM_ROLE_DEFAULT"
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow attachment of persistent resources",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam:: xxxxxxxxxxxx:role/IAM_ROLE_DEFAULT"
            },
            "Action": [
                "kms:CreateGrant",
                "kms:ListGrants",
                "kms:RevokeGrant"
            ],
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "kms:GrantIsForAWSResource": "true"
                }
            }
        },
        {
            "Sid": "Allow Amazon SNS to use this key",
            "Effect": "Allow",
            "Principal": {
                "Service": "sns.amazonaws.com"
            },
            "Action": [
                "kms:Decrypt",
                "kms:GenerateDataKey*"
            ],
            "Resource": "*"
        }
    ]
}

SSEが有効なSNS Topicを作る

SNSのコンソールにアクセス
Create Topicをクリックする
Topic NameにMyEncryptedTopicを入力する
EncryptionでEnable encryptionを選択し、フォームにalias/MyCustomCMK（さっき作ったCMKのalias）を入力する
Create Topicをクリックする

SSEが有効なSQS Queueを作る

SQSのコンソールにアクセス
Create New Queueをクリックする
Queue NameにMyEncryptedQueueを入力し、Configure Queueをクリックする
SSE SettingsでUse SSEをチェックし、AWS KMS CMKでMyCustomCMK（さっき作ったCMKの名前）を選択する
Create Queueをクリックする

SNS Topicへのサブスクライブ

SQSのコンソールにアクセスする
MyEncryptedQueueを選択、Queue ActionからSubscribe Queue to SNS Topicをクリックする
Choose a TopicからMyEncryptedを選択する
Subscribeをクリックする

SSEが有効なSNS Topicにメッセージをパブリッシュする

SNSのコンソールにアクセスする
TopicsからMyEncryptedTopicを選択し、Publish Messageをクリックする
SubjectにTest Message Subject、Message BodyにTest Message Bodyを入力し、Publish Messageをクリックする

SSEが有効なSQS Queueにキューイングされていることを確認する

SQSのコンソールにアクセスする
MyEncryptedQueueを選択し、Queue ActionからView/Delete Messagesをクリックする
Start Polling for Messagesをクリックし、Test Message Subjectがキューイングされていることを確認できる

（参考）各オブジェクトのJSON

sqs get-queue-attributes


{
    "Attributes": {
        "ApproximateNumberOfMessagesNotVisible": "0", 
        "Policy": "{\"Version\":\"2012-10-17\",\"Id\":\"arn:aws:sqs:ap-northeast-1: xxxxxxxxxxxx:MyEncryptedQueue/SQSDefaultPolicy\",\"Statement\":[{\"Sid\":\"Sid1594222624729\",\"Effect\":\"Allow\",\"Principal\":{\"AWS\":\"*\"},\"Action\":\"SQS:SendMessage\",\"Resource\":\"arn:aws:sqs:ap-northeast-1: xxxxxxxxxxxx:MyEncryptedQueue\",\"Condition\":{\"ArnEquals\":{\"aws:SourceArn\":\"arn:aws:sns:ap-northeast-1: xxxxxxxxxxxx:MyEncryptedTopic\"}}}]}", 
        "KmsMasterKeyId": "arn:aws:kms:ap-northeast-1: xxxxxxxxxxxx:key/73f9e34b-a538-4049-91e0-yyyyyyyyyyyy", 
        "MessageRetentionPeriod": "345600", 
        "ApproximateNumberOfMessagesDelayed": "0", 
        "KmsDataKeyReusePeriodSeconds": "300", 
        "MaximumMessageSize": "262144", 
        "CreatedTimestamp": "1594222364", 
        "ApproximateNumberOfMessages": "1", 
        "ReceiveMessageWaitTimeSeconds": "0", 
        "DelaySeconds": "0", 
        "VisibilityTimeout": "30", 
        "LastModifiedTimestamp": "1594222626", 
        "QueueArn": "arn:aws:sqs:ap-northeast-1:xxxxxxxxxxxx:MyEncryptedQueue"
    }
}

sns get-topic-attributes


{
    "Attributes": {
        "KmsMasterKeyId": "arn:aws:kms:ap-northeast-1: xxxxxxxxxxxx:key/73f9e34b-a538-4049-91e0-yyyyyyyyyyyy", 
        "DisplayName": "", 
        "SubscriptionsDeleted": "0", 
        "EffectiveDeliveryPolicy": "{\"http\":{\"defaultHealthyRetryPolicy\":{\"minDelayTarget\":20,\"maxDelayTarget\":20,\"numRetries\":3,\"numMaxDelayRetries\":0,\"numNoDelayRetries\":0,\"numMinDelayRetries\":0,\"backoffFunction\":\"linear\"},\"disableSubscriptionOverrides\":false}}", 
        "Owner": "xxxxxxxxxxxx", 
        "SubscriptionsConfirmed": "1", 
        "Policy": "{\"Version\":\"2008-10-17\",\"Id\":\"__default_policy_ID\",\"Statement\":[{\"Sid\":\"__default_statement_ID\",\"Effect\":\"Allow\",\"Principal\":{\"AWS\":\"*\"},\"Action\":[\"SNS:GetTopicAttributes\",\"SNS:SetTopicAttributes\",\"SNS:AddPermission\",\"SNS:RemovePermission\",\"SNS:DeleteTopic\",\"SNS:Subscribe\",\"SNS:ListSubscriptionsByTopic\",\"SNS:Publish\",\"SNS:Receive\"],\"Resource\":\"arn:aws:sns:ap-northeast-1: xxxxxxxxxxxx:MyEncryptedTopic\",\"Condition\":{\"StringEquals\":{\"AWS:SourceOwner\":\"xxxxxxxxxxxx\"}}}]}", 
        "TopicArn": "arn:aws:sns:ap-northeast-1:xxxxxxxxxxxx:MyEncryptedTopic", 
        "SubscriptionsPending": "0"
    }
}

おしまい。

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T00:12:42+09:00

AWS認定ソリューションアーキテクトアソシエイト（AWS SAA）合格記

はじめに

AWSソリューションアーキテクトアソシエイトに無事合格できましたので、記録を残しておきます。

学習のきっかけ

新規アプリのセキュリティ対策を任せていただいて、
CloudFront、AWS WAFあたりを触り始めたことがきっかけです。

そこから、

・システム全体の動きをなんとなく把握しておきたい
・業務中のAWSの話についていけるように、浅くともインデックスを張っておきたい
・1年目としてはやや難しめな資格を手にして自信をつけたい

あたりを目的に、学習し始めました。

前提知識

強いて言えば、
「Web技術の基本」という技術書を数周読んだ程度です。

AWS関連では、
・Cloud9
・CodeCommit
・CloudFront
・AWS WAF
・CloudWatch
・Trusted Advisor
・GuardDuty
あたりを業務で軽く触った程度です。

当時は慣れていなさすぎて、
AWSの画面を観るのにかなり抵抗がありましたw

学習期間 & 結果

学習期間

2020/1月〜7月頭の半年です。
結構長かったです。

ただ、
業務の繁忙期と重なったり、モチベーション低下で途中で断念したりで、
実際は3〜4ヶ月程度かと思います。

一度止めると堕落してしまうので、一気にやるのがオススメです（自戒）。

結果

1回目 6月半ば

680/1000

2回目 7月頭

725/1000

（実は一度落ちています！）
（720/1000以上で合格！超ギリギリ！！）

学習方法

使用した教材は4種類です。

教材

１）
これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）（udemy）
https://www.udemy.com/course/aws-associate/
こちらで試験範囲はおおかたカバーできます。
分野ごとにハンズオンを交えながら丁寧に解説して頂けます。
udemyの動画教材は、安いときに買うのがオススメです。

２）
Amazon Web Services 基礎からのネットワーク&サーバー構築改訂版（書籍）
https://www.amazon.co.jp/Amazon-Web-Services-%E5%9F%BA%E7%A4%8E%E3%81%8B%E3%82%89%E3%81%AE%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E6%A7%8B%E7%AF%89/dp/4822237443
主にEC2周りの、基礎的な流れについて丁寧にわかりやすく説明されています。
知識皆無でもスムーズに理解できると思います。
いろんな方がAWS学習で初めに読む本として薦める名著です。

３)
【SAA-C02版】AWS 認定ソリューションアーキテクトアソシエイト模擬試験問題集（6回分390問）（udemy）
https://www.udemy.com/course/aws-knan/
上記1)にある模擬試験よりだいぶ難易度高いです。
細かい内容や、1)で出てこないような知識も結構問われます。
こちらも答えられるようにしておくと、かなり自信を持って試験に臨めると思います。

4）
Qiita記事　2つ
AWS 認定ソリューションアーキテクト – アソシエイト資格試験に合格した時の勉強法とノウハウ　第二回（前半）
AWSソリューションアーキテクトアソシエイトでよく出た(と思う)内容まとめ
試験範囲内の各サービスの特徴と、
よく問われる点について丁寧にまとめて頂いてる上記の記事も、
とても参考にさせて頂きました。
出題範囲が広い&細かいので、
どこまで理解できているのかを把握することができます。

学習の流れ

基本的に上の順でやりました。

１)（レクチャー動画）
全体的にとても分かりやすかったです。
ただ、24.5h+模擬試験3題とかなりボリュームがあり、
途中から視聴に疲れて、モチベーションの維持が難しかったです。
ハンズオン、小テスト、細かい箇所の理解などは飛ばして、
先にどんどん進めていくのが良いかなと思います。

↓

２）
1）のEC2の学習で理解に詰まったとき、ざっと読みました。
VPC周りがメインの内容なので試験と比べると範囲は狭いですが、
だいぶ理解がしやすかったので初めはこちらから入れば良かったです。
試験ではVPC,EC2の問題も頻出なので、しっかりとした理解に繋がります。

↓

１)（小テスト・模擬試験）
1)動画・2)をそれぞれ2周したあと、一気に問題を解き始めました。
初めは3割すら答えられずボロボロでしたが、何度も繰り返して答えられるようにしました。
ここで一気に知識が定着していったと思います。

↓

３）
続けて3)です。
ここで新たに理解の浅いところや適当に覚えてしまっていた箇所が新たに判明して、
こまめに基礎理解へ戻ったり、解答を読んでも不明だった点をググったりして、
自分でサービスごとの重要ポイントや注意点をまとめたりしてました。
　※ 試験直前で時間もなかったので、4,5あたりはやってないですw

4)
最終週には理解度を確認するために、
上記のQiita記事を丁寧に読み込みました。
ElastiCacheのRedis/memcashedの違いなど、
模擬問題で出てこなくて忘れてた箇所もあったりして、最終的な確認ができました。

感想

学習前

Qiitaで合格記なる記事を色々見ましたが、
みなさん1〜2ヶ月とか40時間とかで合格されていて優秀すぎたので、
学習教材だけ決めてあとは見ないようにしていましたw

学習後

1アプリの中だけに囚われていたので、
学習前と比べるとだいぶ視野が広がったと感じます。

・通信を制限する方法
・キャッシュの仕組み
・負荷が増えたらどう対応するか
・〇〇を実現するために最適な構成は
などなど、大まかに理解ができました。

試験のコツ？

同じような内容の問題で、
模擬試験では答えられても、本番の問題では答えられない、みたいなことが多々ありました。
それは知識というより、文章の構成に違いを感じました。

違う角度からみた説明に戸惑ったり、
答えが2択まで絞れてどちらを取っても考えられそうだったり、
学習してた時となんか違う違和感を感じると思います。
自分は一度落ちてしまいましたが、
二度目も同じく、なんだか読むのが苦手な文章だと感じました
（もちろん知識の不足もあったと思いますが）。

・いろんな教材の問題を解いて慣れる
・公式の模擬試験を受けてみる（難易度は本番と比べてだいぶ低いけど…）
・基礎固めを徹底して不明な箇所を無くす
などで対策していけば、突破できるかなと思います。

今後

知識だけで、頭でっかちになっている感があります。
問題は解けてもいざ実際に構築できるかと言われると自信がないですw

業務で触る機会を作って、どんどんと慣れていきます。

参考記事

AWS 認定ソリューションアーキテクト – アソシエイト資格試験に合格した時の勉強法とノウハウ　第二回（前半）
AWSソリューションアーキテクトアソシエイトでよく出た(と思う)内容まとめ

　 Tweet
Qiitaで続きを読む

投稿日：2020-07-09T00:04:48+09:00

memo AWSデプロイエラー時のコマンド

背景

AWSデプロイに詰まったとき、エラーログを見るために頻繁に使用したのでコードをメモしておく

tailコマンドを使う

ファイルの最後の部分を表示する

サーバーログ

アプリのリポジトリ上にて
tail -n 30 log/production.log
オプションの意味

-n　数字 : ファイルの最終行からその数字行だけ表示できる

nginxログ

アプリのリポジトリ上にて
sudo tail -f /var/log/nginx/error.log
オプションの意味

-f: リアルタイムで更新されるログファイルを確認しながらプロセスの挙動を確認できる

unicornログ

アプリのリポジトリ上にて
sudo tail -f log/unicorn.log
また、再起動コマンドもよく使ったのでメモしておく

nginx 再起動
sudo service nginx reload
unicorn 再起動
ps -ef | grep unicorn | grep -v grep
PID：プロセス番号を確認した後
kill プロセス番号
再起動コマンド
unicorn_rails -c /var/www/rails/アプリ名/config/unicorn.conf.rb -D -E production

　 Tweet
Qiitaで続きを読む

20200709のAWSに関する記事は21件です。

AWS WAF+CloudFront+S3でIPアドレス制限するときはIPv6 Enabledを確認しよう

発生した事象

起こっていた理由

対策

IAMで副作用なくリージョン縛りをする方法

やりたいこと

NGパターン

OKパターン

裏技パターン

おまけ

【AWS】 CircleCI/CD 自動デプロイでハマったエラーの解消【Capistrano 】

Net::SSH::AuthenticationFailed: Authentication failed for user エラー

CircleCIに登録すべき鍵は、ssh-keygenして作成した「~rsa」(公開鍵ではない)で、ローカルからEC2にログインする際に使用する秘密鍵でした。

rsa鍵（OPENSSH形式）をpem形式(catするとBEGIN RSA PRIVATE KEY---で始まる)の鍵に変換する」というシンプルな解決方法でした。

AWS 無料アカウントの作成方法

目次

1. 概要

2. AWS 無料対象のサービス

3. AWSアカウント作成

3-1. 登録画面にAccess

3-2. アカウント情報を入力

3-3. 支払い情報の入力

3-4. AWSサポートプランの選択

3-5. AWS Consoleにログイン

まとめ

AWSをゼロから勉強する。vol.0

AWSコンソールにログインするためのMFA（多要素認証）をAWS CLIで無効化する

AMIとsnapshotによるバックアップと復元

AMIとsnapshotの違い

AMIでのバックアップと復元

snapshotでの復元

snapshot作成

インスタンスのEBSをデタッチしてみる

作成したsnapshotからボリューム作成、復旧の確認

参考資料

AWS SNSが重複してメッセージを配信してしまう

問題

解決

AWSのCentOS8公式イメージ

公式イメージ

Redash で google login を有効にする方法。権限変更でmanage.py が動かない時の代替案

これは何

google login を入れた時に考えられる問題点

google login有効化まではこの通りにやればできる手順書

ハマりどころ（この記事のメインコンテンツ）

docker-compose.yml と env のありか

group権限の書き換え

Redash で google login を有効にする方法。権限変更のためのmanage.pyが動かない時の代替案

これは何

google login を入れた時に考えられる問題点

google login有効化まではこの通りにやればできる手順書

ハマりどころ（この記事のメインコンテンツ）

docker-compose.yml と env のありか

group権限の書き換え

インスタンスサイズが小さいと動かない

【AWS】Wordpress「返答が正しいJSONレスポンスではありません」の対処法

現象

対処法

【AmazonConnect】キューとルーティングプロファイル作成

概要

キューの作成

ルーティングプロファイルの作成

まとめ

AWS SESでテストメールを送信すると「Email address is not verified」になる

原因

解決策

[AWSメモ] 公式リンク

【AWS SAA-C02】新しいサービスのまとめ

はじめに

サービス

FSx for Windows

用途

説明

FXs for Lustre

用途

説明

Windows FileserverとLustreの違い

Aurora Serverless

用途