タグ

AWSに関するsheeploghのブックマーク (249)

  • AWS側の目線から理解する、Google Cloud ロードバランサの世界 - How elegant the tech world is...!

    はじめに お久しぶりです、iselegantです。 今回はAWSアーキテクトの目線から、多様なGoogle Cloud Load Balancingの世界を紹介してみたいと思います。 昨今、担当業務やプロジェクトによってはAWSのみならずGoogle Cloudを活用したり、マルチクラウドとして両方扱うエンジニアの方も多くなってきたのではないでしょうか? 特に、SI企業に所属する人においては、担当プロジェクトや業務、お客様が変われば利用するクラウドサービスも変わる、なんてこともよくあると思います。 私もその道を辿ってきた一人です。 現在ではクラウドサービス間においてもある程度のコモディティ化が進んでおり、ある一つのクラウドサービスに精通すると、他のクラウドサービス利用時におけるメンタルモデルが出来上がり、システムを構築する際に前提の知識や経験が大いに役立つはずです。特にAWSはサービスの幅

    AWS側の目線から理解する、Google Cloud ロードバランサの世界 - How elegant the tech world is...!
  • 【2022年版ベストプラクティス】AWS IAMまとめ - Qiita

    はじめに AWSのアクセス制御サービスであるIAMについて、2022年7月時点での機能および使用法を、初学者でも理解しやすいことを心掛けてまとめました。 IAMをよく分からないまま適当に設定するとセキュリティ的にまずいので、これを機に設定を見直して頂き、セキュリティレベル向上に貢献できれば幸いです。 特に、後述するIAM設定手順は、AWSに登録して最初に実施すべき設定に相当するため、セキュリティに興味がなくとも一度は実施することをお勧めします。 また公式のベストプラクティスは丁寧にまとめたつもりなので、初学者以外でもAWSセキュリティ確保に興味がある方は、ぜひご一読頂けると嬉しいです。 IAMとは 「Identity and Access Management」の略です。 公式ドキュメントによると、IAMは「誰」が「どのAWSのサービスやリソース」に「どのような条件」でアクセスできるかを

    【2022年版ベストプラクティス】AWS IAMまとめ - Qiita
  • S3のコストを大幅に削減した話 - Gunosy Tech Blog

    広告技術部のUTです。 最近はカービィディスカバリーをゆっくりやってます 概要 過去の失敗 どうやったか 仕組み 結果 まとめ 概要 昨今ではデータドリブンな意思決定を重視する企業がどんどん増えており、データを活用することにより事業成長へのインパクトを出そうとしています。 データを事業へと活用するためには、蓄積されるデータを分析するために保管しておく必要があります。 弊社も創業時からデータを蓄積し事業に活用することに力を入れてきた企業の一つであり、日々大量のログが収集されています。 またAWSアカウントを複数運用していますが、一番データ量の多い広告アカウントのS3にはペタバイトレベルのデータが保管されています。 普段何気なく使っているデータレイクとしてのS3ですが、少量であれば無視できるくらい小さいので、コストを気にせず使っておられる方も多いのではないでしょうか? そのようなS3でも巨大な

    S3のコストを大幅に削減した話 - Gunosy Tech Blog
  • 最小権限実現への4ステップアプローチ 前編 | Amazon Web Services

    Amazon Web Services ブログ 最小権限実現への4ステップアプローチ 前編 AWSセキュリティベストプラクティスを実現するに当たり、「最小権限の原則」に戸惑ったことはありませんか? AWS の利用では AWS Identity and Access Management (IAM)サービスを避けて通ることは出来ません。そのベストプラクティスとして掲げられているのが、最小権限の原則です。特に強固なセキュリティを求めるユースケースではこの原則の実現が課題になることが多いかと思います。ブログでは、この最小権限の原則をシステマチックに検討するアプローチの一例をご紹介します。 はじめに 「最小権限を適切に運用する」ことを計画する際、まず思いつくのはシステムの運用や開発の視点で「必要」となる操作の権限のみを人やアプリケーションに付与するというアプローチです。シンプルですが、権限が

    最小権限実現への4ステップアプローチ 前編 | Amazon Web Services
  • Fargateの運用 ~デプロイ自動化や監視等~

    初めてFargateを触ったので、運用保守の観点で構築時に設定しておいた方が良いポイントをまとめました。 デプロイの自動化と書いているのにデプロイの話薄めになってしまいました…。 こちらはJAWS-UG朝会 #28で発表したものになります。

    Fargateの運用 ~デプロイ自動化や監視等~
  • S3 静的ウェブサイトにサーバーレスなお問い合わせフォームを実装してみた(Amazon SES + AWS Lambda + API Gateway) | DevelopersIO

    S3 静的ウェブサイトにサーバーレスなお問い合わせフォームを実装してみた(Amazon SES + AWS Lambda + API Gateway) はじめに みんなが大好きな Amazon S3 の「静的ウェブサイトホスティング」で公開した HTML ウェブサイトに、メールフォーム付きのお問い合わせページが欲しくなるケースも多いと思います。 そこで今回は AWS のクラウドサービスをフル活用し、完全にサーバーレスで動作するメールフォームを構築してみました。 1時間ほどの作業でお問い合わせフォームを実装でき、AWS に触れることで「サーバーレス構成」の基を理解するのにも役立ったので、備忘を兼ねて構築方法をご紹介します! 今回の構成(概略図) サーバーレスだと何が嬉しいの? おサイフに優しい メール送信のバックエンドに利用するAWSサービス(Amazon SESLambdaAPI G

    S3 静的ウェブサイトにサーバーレスなお問い合わせフォームを実装してみた(Amazon SES + AWS Lambda + API Gateway) | DevelopersIO
  • AWS Vaultで端末内のAWSアクセスキー平文保存をやめてみた | DevelopersIO

    AWSアクセスキーセキュリティ意識向上委員会って何? 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 AWS Valutとは AWSのアクセスキー/シークレットキーを安全に保存・利用するためのOSSソフトウェアです。 AWS CLIだけではなく、boto3等AWS SDKを用いた開発、 Terraform等のサードパーティアプリケーションでも利用することが出来ます。 AWS VaultはIAM認証情報をOSのキーストアに保存し、認証情報の利用時

    AWS Vaultで端末内のAWSアクセスキー平文保存をやめてみた | DevelopersIO
  • AWS ECS Fargate のCPU性能と特徴 | 外道父の匠

    ちょいとした用途において、カジュアルにFargateの起動/停止を繰り返して、気ままに負荷全開かけていたら、あまりの違和感にCPU割り当てについて調査することにしました。 最近こんなことばっかやってる気がしますが、気にわんかったからムカムカ解消に書くしかないんや。半分くらいブラックボックス与太話な感じで夜露死苦です。 はじまり とある処理を全開でFargateにやらせて、cpu=1024(100%), 2048(200%), 4096(400%) でどのくらい RPS (requests per second) でるかを計測していると、想定通りならほぼ比例でRPSが伸びるはずが、全然そうならないパティーンに遭遇。 並列過剰やエラー・バグ起因ではないことをほぼ確させた上で、まさかCPUガチャじゃあるまいなと試したら、まんまCPUガチャでしたということで、EC2からある話ではありますが、現在

    AWS ECS Fargate のCPU性能と特徴 | 外道父の匠
  • Infrastructure as Code の静的テスト戦略 #DevOpsDaysTokyo / DevOpsDays Tokyo 2021

    DevOpsDays Tokyo 2021 で使用したスライドです。 Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか? セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行う手法について解説します。 ご存知の通り Infrastructure as Code (IaC) は、インフラをコードで定義することを通し、アプリケーション開発のベストプラクティスをインフラ領域にも輸入しようとする方法論です。IaC の考え方は近年急速に普及し、開発フローの一部として種々の IaC ツールを利用することは半ば常識のような状態にあります。 しかし同時に、IaC は銀の弾丸ではありません。特に組織的な導入を考えようとすると、得てして「なぜか上手くいかない」「余計に運用が辛くなってしま

    Infrastructure as Code の静的テスト戦略 #DevOpsDaysTokyo / DevOpsDays Tokyo 2021
  • [AWS][Fargate]ECS Scheduled TasksによるNAT Gatewayの通信費肥大化について

    [AWS][Fargate]ECS Scheduled TasksによるNAT Gatewayの通信費肥大化について投稿者: adachin 投稿日: 2021/04/082021/04/08 まずはNAT Gatewayの膨大な通信費を見てほしい….(驚愕) ECS/FargateでECS Scheduled Tasksを運用していると、NAT Gatewayの通信費が膨大にかかってしまうことがあると思います。今回はこちらをどのようにコストを削減したのかブログしたいと思いますので、ぜひ参考にしてみてください。まずは経緯から! 経緯 改善する前の構成図を書いてみました。ECS/Fargateで動作しているAppコンテナ(Private subnet)ですが、デプロイ時やECS Scheduled TasksでのバッチはNAT Gatewayを経由してECRからDocker imageをpu

  • クラウド会計ソフトfreeeのデータセキュリティと内部統制

    巨大なテーブルのテーブル定義を無停止で安全に誰でも変更できるようにする / Table-definitions-for-huge-tables-can-be-modified-by-anyone-safely-and-non-disruptively

    クラウド会計ソフトfreeeのデータセキュリティと内部統制
  • AWS IAMの属人的な管理からの脱却【DeNA TechCon 2021】/techcon2021-19

    AWSをはじめとするクラウドプラットフォームの普及に伴い、DevとOpsの境目はかなり曖昧になっています。その中でもIAMの管理は設定によっては権限昇格を引き起こしかねないことから、その管理権限は慎重な管理になりがちです。結果的に、IAMは属人的な管理を行っている組織が多いのではないでしょうか。 一方で、DevとOpsの境目がどんどん曖昧になっていく中で、IAMロールやIAMユーザーを自由に作りにくい状況があると大変不便です。IAM関係のトライ・アンド・エラーが手軽に行えないことから、開発速度の鈍化を引き起こしたり、アーキテクチャ設計の上で運用上の足かせとなったりといったことが起こります。 また、それらの問題を回避しようとした結果として、IAMロールやIAMユーザーの使い回しが横行しはじめるなど、結果的に最小権限の原則が守られなくなっていくことも少なくはないのではないでしょうか。最小権限の

    AWS IAMの属人的な管理からの脱却【DeNA TechCon 2021】/techcon2021-19
  • AWS CloudShell 禁止してみた #omoshiro_cloudshell

    とうとうAWSにもCloudShell(他と違ってスペースなし)がやってきました。ブラウザベースのシェル環境、とても便利で利用シーンも多そうですが、セキュリティ・統制面では懸念点もあります。結果的に現時点ではルールが満たせず禁止するに至ったのでその経緯を書き留めておきます。 2020/12/29 AWS CloudShellおもしろ選手権登壇資料

    AWS CloudShell 禁止してみた #omoshiro_cloudshell
  • IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO

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

    IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
  • RDSで接続数とメモリ消費量の調整事例 | 外道父の匠

    RDS Auroraを使っているところで、OSの空きメモリが少なくなったアラートが出たので、それについて細かく考察したら、それなりの量になったのでまとめた感じです。 別にAuroraじゃなくRDS MySQLでも、MySQL Serverでも同じ話なのですが、クラウドならではの側面もあるなということでタイトルはRDSにしております。 RDSのメトリクス監視 RDSはブラックボックスとはいえ、必要なメトリクスはだいたい揃っているので、CloudWatch を見たり……APIで取得してどっかに送りつけたりして利用します。 なので、まずは接続数とメモリについて復習です。 SHOW STATUS 的には Threads_connected です。 CloudWatch Metrics 的には、DBInstanceIdentifier → DatabaseConnections です。 見た感じ、ど

    RDSで接続数とメモリ消費量の調整事例 | 外道父の匠
  • Serverless Architecture Patterns in #AWS - DEV

    1- Backend API Service 2- Hosting Microservices 3- Backend and Frontend Service 4- CloudFront with Regional API Gateway 5- Backend and Frontend Service using Single CloudFront Distribution 6- Storage First 7- APIs hosted by the backend service and frontend content hosted in S3

  • AWS, AzureでRHELを利用する前に確認すること - 赤帽エンジニアブログ

    Red Hatの森若です。 パブリッククラウド上でRHELを使う場合に、クラウド事業者から購入するかRed Hatから購入するかでいくつか違いがあり、 あとから変更することができません。事故を防ぐために最初にどちらを使うか決めておく必要があります。 今回は特にお問いあわせの多い、AWSおよびAzure上でRHELを利用する場合についてまとめます。 Certified Cloud and Service Provider (CCSP) とは Red Hatは多数のパブリッククラウド事業者と協力して、クラウド環境でRHELへのサポートを提供できる体制を整えています。 そのためのプログラムが Certified Cloud and Service Provider Program で、以下ではパブリッククラウド事業者のことをCCSP事業者と呼びます。 CCSP事業者はRHELをはじめとしたRed

    AWS, AzureでRHELを利用する前に確認すること - 赤帽エンジニアブログ
  • AWS IAMの最小権限追求の旅 - プログラマでありたい

    皆さん、IAM使ってますか〜? 今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。 IAMでのセキュリティのベストプラクティス まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。 docs.aws.amazon.com AWS アカウントのルートユーザー アクセスキーをロックする 個々の IAM ユーザーの作成 IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する 最小権限を付与する AWS 管理ポリシーを使用したアクセス許可の使用開始 インラインポリシーではなくカスタマー管理ポリシーを使用する アクセスレベルを使用して、IAM 権限を確認する ユーザーの強力なパスワードポリシーを設定

    AWS IAMの最小権限追求の旅 - プログラマでありたい
  • プラットフォームの上でものを作るということ

    プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.

    プラットフォームの上でものを作るということ
  • マルチAZ構成で単一AZの障害の影響を受けるのは何故か? - プログラマでありたい

    昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装(の予想) マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB(CLB)をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス(仮称)として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが

    マルチAZ構成で単一AZの障害の影響を受けるのは何故か? - プログラマでありたい