こちらの記事はRDS ProxyがGAされる前に執筆した記事です。現在はLambdaからRDSを利用する場合、間にRDS Proxyを挟むという選択肢が増えているので、まずはRDS Proxyを使う/使わないの検討をお願いします。以後で紹介しているトピックの一部はRDS Proxy利用時は考え方が変わってきます。 CX事業本部@大阪の岩田です。私が現在関わっているプロジェクトではLambda × RDSというアーキテクチャを採用して開発を進めています。開発を進める中でLambda × RDS(RDB)という構成についてある程度ノウハウが貯まってきたので、注意したいポイントやオススメの設定をTIPS的に紹介していきます。 環境 以後の説明では以下の環境の一部もしくは組み合わせを利用しています。具体的なコードやSQLの例はプログラミング言語やDBエンジンに依存しますが、根底の考え方はどの言語、

よく訓練されたアップル信者、都元です。 Amazon Route 53は、AWSが提供するDNSサービスです。通常、ドメインを取得すると、ドメインレジストラからDNSがサービスで提供されることが多いと思います。費用は大抵ドメイン代に含まれていて、追加費用は無いことが多いです。しかしAWSで利用するドメインは、下記のような理由から、ドメインのオマケで付いてくるDNSではなく、Route 53を利用するメリットが大いにあります。 無料じゃないとは言え、とにかく安い。Route 53のコストが月10ドル超えるような人気サービスを作れたら勝ち組です。 プログラマブルである。レコードの定義と書き換えをスクリプトで実行できる。デプロイの自動化に寄与。 CloudFormationからレコードの定義と書き換えができる。まぁ↑とほぼ同じことを言ってますが。 SLAは100%（！？） ELB, CloudF

コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR

もう、コンテナ調査のためにEC2に乗り込む必要は無い！ もう、Fargateだからコンテナの状況が見れないと悩むこともない！ ECS開発者待望の機能がリリースされました！ みなさん、こんにちは！ AWS事業本部の青柳＠福岡オフィスです。 Amazon Elastic Container Service (ECS) において、実行中のコンテナに乗り込んでコマンドを実行できる機能「ECS Exec」が公開されました。 Amazon ECS now allows you to execute commands in a container running on Amazon EC2 or AWS Fargate どんなものなのか、早速使ってみたいと思います。 これまでの方法 デバッグやトラブルシューティングを行うために、実行中のコンテナに乗り込んでコマンドを実行したいという時があると思います。

はじめに こんにちは、中山です。 Terraformを使用していく中で、どのようなディレクトリ構造(tfファイルの配置方式)がベストなのかと考えたことはありませんか。私自身いろいろと試している最中なのですが、現時点で私が考えるベストプラクティスをご紹介します。 ディレクトリ構造 いきなりですが、以下のとおりです。 ├── Makefile ├── README.md ├── app.tf ├── bastion.tf ├── cloudfront.tf ├── db.tf ├── elasticache.tf ├── elb.tf ├── envs │   ├── dev │   │   ├── main.tf │   │   └── variables.tf │   ├── prd │   │   ├── main.tf │   │   └── variables.tf │   └──

ソースIPは、多くのケースでNLBのPrivate IPになることがわかりますね。ターゲットからの戻りトラフィックのルーティング設計としては、NLBのPrivate IPへの疎通性を確保すればよいだけなので、こちらの方が設計はシンプルに済ませられそうです。 また、IPタイプはPrivate IPの直指定なのでEC2インスタンスとの組み合わせはあまり実用的ではありませんが、最近リリースされたAWS FargateといったENIに紐付くサービスでIPタイプが採用されています。今後もENIを利用するサービスでIPタイプが利用されるケースが増えるのでは、と予想します。 ちなみに、PrivateLinkはNLBに追加で設定するものなので、PrivateLink経由とNLB直接アクセスは共存可能です。とはいえ、インスタンスタイプだと挙動が異なるトラフィックを共通のターゲットで扱うことになるので、運用し

社内などから指摘があり修正しました。「Lambda関数の呼び出しタイプにてRequestResponse(同期)の場合は冪等性は考慮不要」という記述をしましたが、誤った記載となっており申し訳ありませんでした。冪等性の考慮についてはアプリケーション依存によるところが大きく、RequestResponse(同期)でもアプリやSDKにてリトライを実施し冪等性を考慮する場合があります。記事としては、冪等性という視点ではなくリトライという視点で修正しました。 コンニチハ、千葉です。社内から色々アドバイスをもらって完成した元気玉方式のエントリーです！ はじめに Lambda関数は実行トリガーとしてAPI GatewayやS3、CloudWatch Eventsなどを指定することができます。Lambda関数には呼び出しタイプ(同期、非同期、ストリーム)があるのですが実行トリガーによって呼び出しタイプが異

はじめに サーバーレス開発部@大阪の岩田です。 先日接続元IPアドレスをクラスメソッドのGIPに制限した検証環境を利用してAPIのテストを行なっていたところ、リモートワーク中のメンバーが検証環境に接続できないという状況が発生しました。 下記の記事で紹介されているように、クラスメソッドではSOCKSサーバーが構築されているので、VPN経由で社内NWに接続し、SOCKSサーバーをプロキシとして利用すれば本来リモート環境からでも検証環境が利用できるはずです。 VPN利用者のためにdelegateでSOCKSサーバーを立ててみました 最初はcurlコマンドのオプションに--proxyを付けてプロキシサーバーを指定するようお願いしたのですが、--proxy http://proxy.example.com:xxxxのような指定を行なっていたようで、問題が解決しませんでした。 結局--proxy so

OSやミドルウェアの機能検証を実施した場合など、オンデマンドで一時的な検証環境を構築できるのもクラウドサービスの醍醐味です。 検証対象のOSやミドルウェアは異なれど、検証に必要な環境はある程度共通であることが少なくなく、また費用節約のためにも検証が終わった後はきれいさっぱりとその環境を削除したいものです。 AWSでそんな使い捨ての環境を構築する場合の方法として、ファーストチョイスとなるのはAWS CloudFormationかと思います。検証環境をテンプレート化しておくことができ、またマネージメントコンソールやAWS CLIを使って簡単に環境の構築／削除ができる、使い捨て環境の構築にはぴったりのサービスです。あるいはAWS CLIやAWS SDKを使って自前の環境構築スクリプトを作成するのもよいかもしれません。 AWS公式のツールを使う以外では、Terraformが有力な選択肢の1つになる

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先日ALBでIPアドレスをターゲットとしてオンプレミスのリソースなどに対して負荷分散ができるようになりました。先日NLBでもIPアドレスをターゲットとして設定できるようになったためご紹介します。 Elastic Load Balancing: Network Load Balancer now supports load balancing to IP addresses as targets for AWS and on-premises resources IPアドレスターゲット NLBが負荷分散するターゲットをインスタンスIDではなくIPアドレスを指定することが可能な機能です。ALBでも同様の機能がありますが、一部異なる部分があります。 [新機能] ALBのターゲットにIPアドレスを指定可能になりました 指定可能なIPアドレス サ

つまりは、オートスケールやタスク数設定によるコンテナ増減に連動して、Route 53のレコードが自動的に書き換えられるということすね。 従来から存在したRoute 53のAuto Naming 実は弊社大瀧が書いた、下記記事に有るように、Route 53のAuto Naming APIを利用したサービスディスカバリー実装の機能自体はありました。 Amazon Route 53 Auto Namingでサービスディスカバリを実現する ｜ Developers.IO 今回紹介する機能は、これをECSに拡張したものと言えます。 実際にECSサービスディスカバリーを設定してみる 前置きが長くなりましたが、実際にECSに登録する様子を見てみましょう。既に、既存のECSクラスターとタスク定義がある前提で解説していきます。 従来どおり、ECSのサービスを作成していきます。今回は起動タイプもFARGATE

確認したいこと ALB（Application Load Balancer）のリスナーとして設定するTarget Groupは、随時変更することができます。変更したそのタイミングでアクセスがあった場合に、エラーになることはないのか、気になったので確認しました。 図で説明 この状態から この状態に変える瞬間に このようにエラーになってしまうリクエストが発生しないか 結論 大丈夫そうです。Target Group付け替え時にエラーになるリクエストは発生しないようです。 検証方法 httpingというpingのhttp版のコマンドを使って、ローカルからALBに対して断続的にリクエストし続けます。その途中でTarget Groupの付け替えを行なって、エラーになるリクエストが無いか調べました。 Target Groupには前述の図のように、それぞれ異なるEC2インスタンスが一台ずつ紐づいています。

自分の作業環境の作り直しをしているのですが、 たまに理解が怪しくなるので、確認ついでにここに吐き出しておこうと思います。 背景 「リモート環境にあるホストAにsshあるいはscpするためには、 踏み台(Bastion)となるホストXに一度SSHログインしないとならない」 というケース/環境はそこそこ多いと思います。 これがsshなのであればまあ、ssh X -> ssh Aとするだけなのでそこまででもありませんが、 scpだった場合は概ねこんな手順になりますよね。 まずssh XとしてホストXにログイン ホストX上でscp -p A:/path/to/datafile ~/（オプションはお好み） コピーが終わるのを待ってから、Xからログアウト scp -p X:~/datafile . コピーが終わるのを待ってssh X rm ~/datafile これで何が困るかというと、 コピー(sc

Ansibleではinventoryに対象ホストを定義します。 適用したいインフラ構成が複数ある場合、playbook毎にグループ化してください。 グループ化した場合、変数はそれぞれのgroup varsに定義できます。 詳しくは、前回のエントリーを参照してください。 inventoryの構成方法には幾つかのパターンがあります。 対象とするシステムの規模や特徴にあわせて選択しましょう。 なお、パターンを整理するにあたって、Ansibleのインベントリファイルでステージを切り替えるを参考にしました。 ベーシックパターン 開発環境・検証環境・本番環境といった目的毎に環境を作る必要がなく、ひとつの環境（本番環境）のみの場合は、inventoryファイルもひとつで十分です。 hostsという名前のファイルを作成し、inventoryを定義しましょう。 構成は次のようになります。 . ├── gro

渡辺です。 最近、Ansibleに関する書籍が増えてきていますね。 とはいえ、ほとんどは入門的な位置付けで、それはそれで需要があるんですが、実践レベルで使いこなすノウハウは少ないというのが現実かと思います。 この辺り、まだ試行錯誤を繰り返しているところも多いでしょう。 そこで、ノウハウをガンガン流出させるクラスメソッドなので、ベストプラクティスみたいなものをまとめちゃいました。 Ansibleとは？ 雑な言い方をすれば、SSH接続したリモートホストでミドルウェアのインストールや設定ファイルの更新を行うツールです。 カテゴリとしては構成管理ツールに分類されます。 SSH接続が可能であれば、リモートホスト側にエージェントのインストールが不要である点は大きな特徴です。 Playbookにサーバの状態を定義する AnsibleのPlaybookは、リモートホストの状態を定義したファイルです。 構成