コーヒーが好きな木谷映見です。 今日はスイッチロールの概念と設定方法についてまとめていきます。 スイッチロールとは？ ざっくりとしたイメージ 真面目なイメージ スイッチロールのイメージ 「帽子をかぶって力を得る」 IAM ポリシーの種類 アイデンティティベースのポリシー リソースベースのポリシー IAM ロールの信頼ポリシー sts:AssumeRole とは IAM ロールに付与されるポリシー スイッチロールをする際の権限まとめ スイッチロールの手順 スイッチ元アカウントA での準備① スイッチ先アカウントB での準備 スイッチ元アカウントA での準備② スイッチ元アカウントAからスイッチ先アカウントへスイッチロールする スイッチロールのユースケース 参考 具体的な設定方法を知りたい方は「スイッチロールの手順」をご参照ください。 スイッチロールとは？ ざっくりとしたイメージ 「人んちの帽

はじめに SCSの学習でIAMの奥深さに感動した勢いのまま書く。 注意：個人的な解釈であって絶対的に正しいものではない。 また、個人の責任において記載しているが抜け漏れや間違いがある可能性はあることを理解の上で読んで頂きたい。 正確な解釈は公式ドキュメントのポリシーとアクセス許可を参照。 とはいえこんな長ったるいの読んでられねえし、他ブログ記事の内容も個人的にいまいち腑落ちしなかったため書き残すことにした。 結論 面倒なんで 許可 前提で書く。 当たり前だがサービスが違う。(STSとIAM) 書く場所が違う。 iam:PassRoleは基本的にアイデンティティベースのポリシーに記載する。 sts:AssumeRoleはリソースベースのポリシーに記載する。 後で補足する。 アクションの内容が違う。 iam:PassRoleは あるIAMRoleをEC2インスタンスやLambda関数などのリソ

はじめに AWS Chatbotがカスタム通知をサポートし、通知内容のカスタマイズが可能になりました。 従来ですと、AWS ChatbotからSlackに通知する内容は、CloudWatch アラームの場合、下記のような内容で通知され、通知内容はカスタマイズできませんでした。 日本語変換もできません。 そのため、通知内容をカスタマイズする場合は、AWS Chatbotを利用せず、EventBridgeやLambdaからSlack通知するなどの方法をとられていたと思います。 今回のアップデートでAWS ChatbotからMicrosoft TeamsやSlackチャネルへの通知内容をカスタマイズできるようになりましたので、通知内容の可視性を向上させることができます。AWS Chatbotの利用が増えそうですね。 AWS Chatbotの概要は、下記のブログをご参考ください LambdaからS

はじめに AssumeRoleとはなんぞや！ そう、私はAWSを利用している中でAssumeRoleという言葉の意味がイマイチピンと来ていない人でした。そんな中、会社のAWSマスターさんから色々教わり、AssumeRoleとはなんぞやをやっと(私なりに)理解しました。サンキュー、AWSマスターさん。 要は、AssumeRoleとはなんぞや AssumeRoleとはAWS STSのサービスの1機能のことを指していて、IAMロールに設定した権限を一時的に使えるようにTokenを発行する行為や！ なので、「○○するためにAssumeRoleする」と言う言葉の使い方で通じる。 AWS STS(Security Token Service)は「AWSサービスに対して何かしら操作したい時に、一時的に操作する権利(Token)を発行する」シンプルなサービス。 正確にいうと一時的な認証情報「アクセスキー」

AWS CloudFormation の参照周り(主に Ref や ImportValue ) で意識すべきポイントやTipsを主観で並べてみました。 目次 Ref を使う場面を把握する ImportValue を使う場面を把握する Ref と ImportValue の使う場面の違いを把握する Ref で何の値を返すか調査する GetAtt で何の値を返せるか調査する Outputsセクション で何の値を渡すのかを意識する 擬似パラメータの活用を検討する Mappingsセクション を使った参照を検討する Parameter Store/Secrets Manager を使った参照を検討する おわりに Ref を使う場面を把握する 組み込み関数 Ref は以下の用途で使用します。 Parameters セクション で指定したパラメータの参照 Resources セクション で指定したリソ

本記事は 初夏のAWSアワードエンジニア祭り 1日目の記事です。 🍦 告知記事 ▶▶ 本記事 ▶▶ 2日目 💻 尾澤です。 この度、2023 Japan AWS All Certifications Engineers に選ばれました。 更新が不安です。 というわけで今回はAWSアワードとかはあまり関係ないですが、 私が日頃業務で対峙するECSさんについてお話ししようかと思います。 ECSとは もう今となってはコンテナといえばこれというサービスですね。(?) 改めての説明ですが、 Amazon ECS（Elastic Container Service）は、AWSが提供するコンテナオーケストレーションサービスです。 Webサービスなどを構成する場合、コンテナ単体で動かすにはさまざまな運用課題があるため、 基本的にはオーケストレーションツール（ex: Kubernetes, e）を使いま

Client VPN エンドポイントにはセキュリティグループを関連付けられます。 このセキュリティグループはどのように設定するべきでしょうか？最初に私の考える結論を述べます。 結論 設定ミスによる予期せぬ通信を防ぐため、Client VPN エンドポイント専用のセキュリティグループを作成して適用しましょう。 （VPC に初期設定状態で存在する default セキュリティグループを使用しないようにしましょう。） 当該セキュリティグループにインバウンドルールは不要です。削除しましょう。 また、アウトバウンドルールはすべてのトラフィックを許可する設定にしておくのがオススメです。 セキュリティグループの役割について（おさらい） セキュリティグループは AWS の各種リソースに適用できる仮想ファイアウォールです。 インバウンドルールおよびアウトバウンドルールにプロトコル・送信元（送信先）などを設定

こんにちは佐々木です。以前、『AWSのグローバルIPの空間はインターネットなのか？』と題して、AWSのパブリックIP同士の通信が何故AWSのプライベートネットワークの通信になるのかという話をしました。その中で、PrivateLinkの必要性はどう考えるべきなのかという事に、少しだけ言及しました。今回は、そこをもう少しだけ深ぼって見てみましょう。ユースケースとしても多いであろう、EC2からS3の通信の例でみてみます。 tech.nri-net.com EC2からS3へアクセスする４つのルート EC2からS3へアクセスするルートとしては次の４つがあります Internet Gateway NAT Gateway VPC Endpoint（Gatewayタイプ） PrivateLink（Interfaceタイプ） それぞれの構成と利用に関わる費用をみてみましょう。なお、今回ご紹介するコストは、S

2016/02/05 9:30 ユースケース2 API Gatewayの対応するTLSのバージョンを修正しました。@Keisuke69さんご指摘ありがとうございます！ ども、大瀧です。 Amazon API Gateway、皆さん使ってますか？Lambdaのフロントエンドとして、既存APIのRESTful化&統合として様々なケースで利用できると思います。今回は、そんなAPI GatewayをCloudFrontと組み合わる目的とその注意点をご紹介します。 概要 ご存じの方もいると思いますが、そもそもAPI Gatewayは内部でCloudFrontの仕組みを利用しており、スケーラビリティやアベイラビリティの面でCloudFrontの特徴を享受しています。しかしながら、CloudFrontのフル機能をAPI Gatewayで利用できるわけではないため、場合によっては以下の図のようにAPI G

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 API Gatewayを使うとき手が届かないむずかゆいところがたくさんあります（HTTPSのみしか受け付けないとか、前段にWAFおけないとか）。 そのときに使われるのがCloudFrontになりますが（もちろん、API Gateway内部にCloudFrontが暗黙的に使われており、多段CloudFrontになるため遅延が大きいというのは承知）、API　Gatewayの前段用にCloudFront使うのもなんなのでS3オリジンの配信もやっちゃいたい、という内容です。 CloudFront + API Gateway + S3 S3

はじめに API Gateway に対して、直接アクセスした場合と CloudFront 経由アクセスした場合に、レスポンス時間がどの様に変化するかを調査した記事です。 API Gateway を CloudFront 経由でアクセスするパターン 私の場合は、静的リソースの配信 (S3) と、動的リソースの配信 (API Gateway) を同一ドメインで配信できるようにしたい、というのが目的です。 Same-origin policy に起因する課題をそもそも起こさせないにはこの構成を試したい、という感じです。 CORSなどの色々設定しているのですが、そもそも同一ドメインでやれるほうが楽なので。 調査しようと思ったきっかけ いくつかの記事を見かけたのですが、早くなる、遅くなるの両方の記事を見かけたので、自分で実際に環境を作って調べよう！と思ったのがきっかけです。 例えば、以下のような記事

WebSocket API Gateway の前段にCloudFrontディストリビューションを置く構成を作成する機会がありましたのでレポートします。 この構成のメリット WebSocketと他のリソースを同じFQDNから配信できる CloudFrontディストリビューションは、Behaviors(Cache Behaviors)という機能を活用することで複数のオリジンを同一FQDNから配信することができます。 例えば以下のようなことができます。 /websocket パス以下をWebSocket API Gatewayオリジンにする 他のパスは他のオリジンを使う(S3、ALBなど) ※とはいえ、FQDN分けてしまえるならその方がシンプルな構成になり良いかと思います。 ネットワークの最適化 2020/08/14現在、CloudFrontの接続ポイントは42か国84都市にある216箇所が提供

AWSのセキュリティグループ、ネットワークACLのステートレスとステートフルを噛み砕いて具体的に行ってみる クラウドソリューション事業部の倉岡です。１年目ということもあり学ぶことが多々あるのですが、つい先日AWS技術書を読んで悩んだ内容がありました。 ”AWSのセキュリティグループはステートフル、ネットワークACLはステートレス” と言った文言です。ステートフルは「状態を保持する」と言った意味合いがあり、ステートレスは「状態を保持しない」と言った意味合いがあります。その意味も踏まえて先ほどの文言を言い換えると ”AWSのセキュリティグループは状態を保持する、ネットワークACLは状態を保持しない” となります。 ますます、わからなくなってきました。そこで様々なサイトの閲覧や解説書を読み進めていくことにしました。すると、 ”セキュリティグループはステートフルで１つの通信を設定すれば戻りの通信は

最近ブログ名のラズパイがあまり出てきていません。どうものなめです。 タイトルにある「キャッシュなしのCloudFront」ってどういうことか分かりますか？ キャッシュサーバーのサービスなのにキャッシュを一切持たせないとはこれいかに・・・って思いませんか？知っている人からしたら当たり前なのでしょうが、私はこの構成を知ったときは、「え？なんで？？？」って思いました。しかし以外にも調べてみるとキャッシュを一切持たせないCloudFrontを使ってる情報が出てくるんですよね・・・。 ということで、今回はキャッシュを保持しないCloudFrontの利点について調べてみました！ ※追記も目を通していただけると！ 構成について 文字だけじゃイメージし難いと思ったのでさっくりシンプルアイコンでシステム図を描きました。図にいくつか余計なものが描いてあるので、勘のいい人は既に利点に気が付いたのではないでしょう

Twitter で DHH が共有していた記事が面白かったので著者の許可を得て翻訳します。 "If you don't hire juniors, you don't deserve seniors", spot on! We've had phenomenal success hiring junior developers at Basecamp. @jasonfried first tech hire was particularly junior at the time 😂https://t.co/QczMtsou4J — DHH (@dhh) September 21, 2018 ジュニアを採用しない連中はシニアに値しない、というもの。 If you don't hire juniors, you don't deserve seniors (2023) • Minimum V

こんにちは。いそやです。 オンプレミスでの経験はありますが、慣れないAWSに四苦八苦しています。それでもAWSは楽しいですね！ その四苦八苦の中でも、AWSのElastic Load Balancer(ELB)の使用にあたってプライベートサブネットに配置したサーバーへのアクセスができず、とても困ったことがありました。 AWS初心者にはなかなか理解できなかったので、その顛末をブログにしました。 初めてELBを使ってみようという方が対象になります。 今回の検証用環境 今回の目的 困ったこと 思い当たること そもそも理解できていなかったこと そもそもALBは各AZ毎に設置される 対応策 対応結果 感想 今回の検証用環境 インターネットゲートウェイ経由で、VPC内に構築したALB→各プライベートサブネットのwebサーバーにアクセスします。 上記の構成で、おや？と思われた方もいるかと思いますが、その

回答: unicorn が活躍した時代の方が長かったので、それを推す文書が多いというだけだと思います。 rails5以降は puma がデフォルトになっており、わざわざ unicorn に切り替えるメリットが皆無とは言いませんが普通にデフォルトのまま puma を使えば十分です。 unicorn と puma の違いですが、 unicorn はマルチプロセス、 puma はマルチスレッドです。 スレッドはメモリを共有し、プロセスはメモリを共有しません。通常、httpサーバーは複数のリクエストを独立に処理し、永続的なデータはデータベースに保存するので、マルチプロセスモデルの方が相性が良...

セキュリティの対策としてIP制限などを行っており、AWSのサポートに問い合わせたり調べたりとしているので、少しでも同じ状況の人の参考になれば良いなと思いまとめました。 この記事で具体的にどのように設定していくかというよりも、全体的にどんな選択肢があるのかがわかるようになれば良いなと思います。 その前に まずは要件を確認し、海外からのアクセスは全て遮断して良いのか、国単位なのか、連携しているシステムで海外IPのものは存在するのかなどを確認すると良いかなと思います。 事前に情報がまとまっている方が、無駄な情報を集めないで済みます。 AWSで海外からのアクセス制限を行う時にできること セキュリティグループ インスタンス単位でホワイトリスト型のIP制限ができるので、特定のIPからしかアクセスを許可していないシステムには使用できます。 社内IPのみとか連携しているシステムのみみたいな感じで指定するし

ALB経由で公開するAPサーバに(リバースプロキシ用の)Webサーバーを利用する意味はあるのか？立ち止まって考えてみた まずは、リフト＆シフトのリフトだ。オンプレ環境の構成を変えずにAWSでリプレイスするぜ。 静的コンテンツの処理はWebサーバーに任せてアプリケーションサーバーの負担を減らす構成だな。 次はシフトだ。だが大きくは変えない。静的コンテンツを外だしするところから始めよう。 あれ？Webサーバー(Nginx)っているんだっけ？？ALBではログも取れるし最近はでできることも多いよね？ [新機能] HTTPヘッダーやクエリ文字列などなどでルーティングができちゃう!!AWS ALBで高度なリクエストルーティングが可能になりました! 待てよ待てよ。将来的にはSPAで実装する方法も検討しているんだった。その場合はいらないでいいよね？ ということを社内チャットで呟きました。いくつか意見が出て