並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 7 件 / 7件

新着順 人気順

"AWS IAM"の検索結果1 - 7 件 / 7件

  • AWS STS でリージョナルエンドポイントの利用が推奨されるとはどういうことか | DevelopersIO

    AWS STS のサービスエンドポイントとしてグローバルエンドポイントとリージョナルエンドポイントがあります。デフォルトではグローバルエンドポイントが使用されますが、リージョナルエンドポイントの使用が推奨されています。一体それはどういうことなのか、整理してみます。 コンバンハ、千葉(幸)です。 AWS Security Token Service (STS) は、一時的な認証情報を提供するサービスです。 AWS STS に対して一時的な認証情報払い出しのリクエストを行う際、リクエスト先となる AWS サービスエンドポイントには以下の2種類があります。 グローバルエンドポイント リージョナルエンドポイント デフォルトでは前者のグローバルエンドポイントが使用されるものの、後者のリージョナルエンドポイントの利用を推奨する、という記述が各種ドキュメントにあります。 👇 デフォルトでは、AWS S

      AWS STS でリージョナルエンドポイントの利用が推奨されるとはどういうことか | DevelopersIO
    • AWSマネジメントコンソールへのアクセスを特定デバイスに制限する方法を考えてみた | DevelopersIO

      はじめに AWSマネジメントコンソールへログインするユーザーに対して、管理者側で特定のデバイスからのアクセスのみに制限することができないか調査しました。 マネジメントコンソールへのログインは、以下のパターンがあります。 IAMユーザー AWS IAM Identity Center(独自IDストア or 外部IDプロバイダー) シングルサインオン(IAM SAML) 今回は、例として、特定のPCにログイン制限することを目的に、それぞれのパターンで確認します。 結論 結論として、IAM Identity Center(外部IDプロバイダー)やシングルサインオン(IAM SAML)を利用し、外部IDプロバイダーのログイン段階で特定のデバイスに制限をかけることで、間接的にAWSマネジメントコンソールへのアクセス制限が実現可能です。 ログイン方式 制限可否

        AWSマネジメントコンソールへのアクセスを特定デバイスに制限する方法を考えてみた | DevelopersIO
      • Flaggerでも手動カナリアリリースがしたい! - ZOZO TECH BLOG

        はじめに こんにちは。株式会社ZOZOのSRE部プラットフォームSREチームに所属しているはっちーと申します。 本記事では、Kubernetesクラスター上で自動カナリアリリース機能を提供するFlaggerが導入済みのマイクロサービスにおいて、手動カナリアリリースを実施する方法について紹介します。一見、矛盾するように思えるかもしれません。しかし、時にはそのような要件も発生することがあります。また、手動カナリアリリースで運用している状態からFlaggerの導入を検討している場合、導入後も念のために現行の手動カナリアリリースができるのか、という点は気になるかと思います。すでにFlaggerを導入している、これからの導入を検討している、という方の参考になりましたら幸いです。 目次 はじめに 目次 前提知識(Flagger) Manual Gatingの基本 Manual Gatingとは Man

          Flaggerでも手動カナリアリリースがしたい! - ZOZO TECH BLOG
        • AWS統合を活用して無駄なLambdaを減らす - Qiita

          Lambdaを使用する場合 AWSのAPI Gatewayを使用している場合、S3やDynamoDBの操作をする際があると思います おそらく、すぐに思いつくのは以下のような構成かと思います LambdaでS3やDynamoDBを操作する構成ですね ただ、Lambdaがいると単体テストが必要になってきます DynamoDBを少しだけ操作するだけなのに、コードと単体テストの両方が必要となってきます しかも、CloudFormation化するなら、更にテンプレートファイルの作成まで必要となってきて、結構面倒です AWS統合とは Lambdaを経由せずAPI Gatewayから直接、S3やDynamoDBなどのAWSサービスを操作する方法です AWS 統合を使用して API Gateway REST API を構築する ※本来はAWS統合とは言わないかもで注意です 何がいいのか? まず、構成が以下

            AWS統合を活用して無駄なLambdaを減らす - Qiita
          • AWS Lambda関数をlambrollとGitHub Actionsでデプロイしてみた ~ fujiwara-ware OSS ~ | DevelopersIO

            クラスメソッドは2024年に5つのOSSに対して支援を実施しました。 当方が推薦して選定された @fujiwara さん作による Amazon ECSのデプロイツールであるecspressoについては、先日紹介記事をかきました。 本記事では、 ecspresso の姉妹プロダクトとも言える、AWS Lambdaのデプロイツール lamboll について、基本的な使い方とGitHub Actionsからデプロイする方法について紹介します。 lambrollはミニマリストのためのAWS Lambdaデプロイツール GitHubのプロジェクトページから lambroll の概要を引用します lambroll is a minimal deployment tool for AWS Lambda. lambroll はLambda関数のデプロイに必要な最小限の機能しか提供しません。やっていることと

              AWS Lambda関数をlambrollとGitHub Actionsでデプロイしてみた ~ fujiwara-ware OSS ~ | DevelopersIO
            • AWS 超入門 〜AWSを始めよう〜 - Qiita

              ◾️はじめに 以前、AWSのセミナーを受けた際のアウトプットとして、本資料では、AWSを活用することで得られる価値や主要サービスの概要について解説し、実際にAWSを始める手順を紹介します。本資料を通じて、AWSの基本的な理解を深め、実際のビジネスでの活用方法を具体的にイメージできるようになっていただければ幸いです。 ◾️AWS活用で得られる価値 スモールスタートで迅速に始められる 従来、オンプレミスでITシステムを稼働させるためには、サーバーやネットワーク機器、ソフトウェアなどを自社で保有し、運用する必要がありました。しかし、AWSを活用することで、これらのインフラ調達やセットアップにかかる時間と労力を大幅に削減し、必要なITリソースをすぐに利用開始できます。また、不要になれば削除すればよいということです。 必要な時に必要な分だけ利用可能 オンプレミスでのITシステム運用では、常にリソース

                AWS 超入門 〜AWSを始めよう〜 - Qiita
              • Addressed AWS Default Risks: OIDC, Terraform and Admin Access

                Before we begin, here is a message from AWS that I also support: AWS has taken the feedback and has implemented improvements in the default Terraform OIDC Trust Policy. AWS has also contacted customers who may have been in this configuration. AWS recommends customers always test their configurations before doing so in production, but when they do, limit the condition key "Subject" or "sub" to prev

                  Addressed AWS Default Risks: OIDC, Terraform and Admin Access
                1