You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

最小限で基礎的なセキュリティガイダンスである「AWS Startup Security Baseline (AWS SSB)」を紹介します いわさです。 SaaS on AWS では大きく 4 つのフェーズ（設計・構築・ローンチ・最適化）で役立てる事ができるコンテンツが提供されています。 設計フェーズでは技術面からコンプライアンスに準拠したりセキュリティベースラインを考える必要があります。 これらについてベストプラクティスが提案されている動画コンテンツがあります。 その中で初期段階で実施出来ることとして次のステップが紹介されていました。 セキュリティ周りは Well-Architected Framework や Security Hub の適用から始めることも多いと思いますが、様々な制約からすぐの導入が難しい場合もあります。 そんな方に本日は上記の中の AWS Startup Secur

はじめに現代のWebアプリケーションにおいて、ユーザが写真や動画などのファイルをアップロードする機能は、しばしば求められます。 本記事では、ファイルアップロードを実現するための一手段として、「署名付きURL」を利用した方式を取り上げ、その設計について詳しく解説します。 今回は、Amazon Web Services（AWS）を利用する前提のもと、このアプローチを探求していきます。 前半部分は署名付きURLをそもそもよく知らない方向けの導入部となっていますので、要点だけ抑えたい方は設計上のポイントから読まれることをお勧めします。 ファイルアップロードの実現方式パターン署名付きURLの話をする前に、ファイルアップロード機能をWeb APIとして実現する方式について、いくつか代表的なものを紹介します。 Pattern 1. multipart/form-datamultipart/form-da

きっかけ 東京大学のAWS講義「コードで学ぶAWS入門」、いわゆる東大AWSってやつがが良いらしいと聞いたのでやってみました。 確かにこれは良いです。クラウドをこれから学びたい方にぜひおすすめ。 集中講義的に休日に半日もあれば学べます。 かかるAWS費用もわずか。 ほとんどのチュートリアルがAWSの無料枠で実行できてしまいます。ディープラーニング用のGPUインスタンスをぶん回すところは有料です。それでも数百円で済みます。 これは一通りハンズオンをやってみたAWSの費用です。 もはや学ばない理由が見当たりませんね。 これを書いた理由 けっこう有名な講義資料なのでいまごろ紹介するまでもないネタかと思っていましたが、いざやってみたらハンズオンのコードが最近のAWS環境では動作しない箇所がいくつかあったので。 動作するように修正した手順をまとめておきました。 本記事がはてブを950件ももらってしま

AWSマネージドサービスGuardDutyによる待望のコンテナランタイム脅威検知。その検知内容と設定上の注意事項、検出の様子をまとめてお届けします。 「ECSのランタイム脅威検知って、商用製品必須だよね。どれにすっかなぁ。結構高いよね」 「1年前の予告を経て、よーーーやくAWSマネージドなやつがGAされましたよ」 去年のre:Invent2022においてKeynote中に予告だけされていたコンテナ環境のランタイム検知（【速報】GuardDutyによるコンテナランタイムの脅威検知サービスが発表されました！）。 先日のre:Invent 2023のアップデートにより、待望のECSにおけるランタイム検知が、GuardDutyで実現できるようになりました！！もともとEKSにおけるランタイム検知は提供されていましたが、それがECSにも拡張されたアップデートです。 これまでAWSのECSにおいてランタ

エンタープライズ企業が新しいクラウドサービスを導入する時には、自社のセキュリティ基準を満たせていることを確認するのが通例である。「セキュリティチェックシート」と呼ばれるエクセルシートを利用して一点一点チェックしていくことが多い。（この質問票で聞かれる内容が個社ごとにばらばらで、システム導入時に双方の負担になってしまっているのを標準化してなんとかできないかと思うことはあるが、この記事ではそこには触れない。） よくあるのが、「アンチウィルスソフトウェアをサーバーにインストールしていること」というチェック項目だ。明快な質問のように見えるが具体で実現するためには色々考えなければいけないことがある。標準的なサーバー構成、つまり、ハードウェアがあって、その中でOSが稼働していて、その上でアプリケーションが動いているというシンプルな構成であれば良いのだが、クラウドインフラを使い倒すようになった今ではマイ

MemoryDB はElastiCache の約1.5倍、Aurora の約1.2倍と若干高価です。 耐久性を重視するMemoryDBはElastiCacheで言うところの「クラスターモード」しか存在しないため、{シャード数} x {ノード数/シャード} x {インスタンス利用費} 分の利用費が発生する点にもご注意ください。 最後に Redisを永続的なデータストアとしても使える Amazon MemoryDB for Redis が爆誕しました。 データ耐久性のトレードオフとして書き込み速度は低下したものの、読み取りの速さはまさにRedisです。 クライアントはRedisコマンドを投げるだけで、MemoryDBが良しなにやってくれるため、使い勝手が良さそうです。 今後はDynamodB+DAXの代替として検討したり、RDB+キャッシュRedisなシステムを MemoryDB に集約すると

こんにちは、虎塚です。 先日のCM re:Growth Developers.IO Meetup 11 Tokyo で「10分でわかるKey Management Serviceの仕組み」という発表をしました。今日は、イベントに参加されなかった方がご覧になっても内容が伝わるように、発表内容を記事に起こしてみました。 はじめに Key Management Service（KMS）は、先月開催されたre:Invent 2014で発表された新サービスです。すでに全リージョンで利用できます。このサービスを使うと、データの暗号化/復号用の鍵をAWS上で管理できます。 ところで、KMSのAPIドキュメントを流し読みすると、マスターキーとデータキーという言葉が出てきます。そうです、KMSが扱う鍵は2種類あるんですね。 2つの鍵の違いは何か？ どう使い分けるのか？ などが、ぱっと見ではわかりづらいかもし

KMSについては優れた記事があるのですが、KMSの「対称キー」と「非対称キー」について理解していなかった点があるのでその話を書きます。 なお、以下でいう「対称キー」はKMSが生成したもの（外部からインポートしたものではなく）、「非対称キー」はRSA 4096ビットのもののみを考えます（ECCについては除外します）。 KMSの対称キーは非対称キーの上位互換である KMSの対称キーは次のような用途に利用できます。 S3のサーバーサイド暗号化 EBSの暗号化 RDSのストレージ暗号化 SNSのメッセージ暗号化 …… 非対称キーの生成 キーの自動ローテーション 非対称鍵では公開鍵と秘密鍵が固定される 当たり前といえば当たり前ですが、一度KMSで非対称キー（すなわち秘密鍵と公開鍵のペア）を作成したら変更はできません。キーIDと秘密鍵・公開鍵は一意に固定されます。権限がなければキーを削除することもでき

はじめまして、岩崎です！「APN AWS Top Engineers/APN Ambassadors Week」の4日目の記事を書かせて頂くことになりました。この度、元々モバイルアプリしか作ってこなかった私が、「2021 APN AWS Top Engineers」になることができました。ちょうど良い機会でもあるので、NRIネットコムに入社してから取り組んだことをざっくりと整理していきたいと思います。 はじめに 昨今、一口にフロントエンドエンジニアと言ってもアプリを開発するだけではなく、プロジェクト規模によってはCI/CDの仕組みを構築・管理したり、アプリに機能やコンテンツを提供するためのバックエンドを構築したり、はたまたプロジェクト管理もしてみたりと、エンジニア一人に要求される専門性がますます多様化しているように感じます。おそらく、多方面で起こっている「技術の民主化」の流れが進んでいくに

はじめにこんにちは。TIG村瀬です。 タイトルの通りですがAWS内の通信においてインターネットを経由しないことが最近になって公式ドキュメントに明記されたことを受け、改めてVPC Endpointの必要性について調べてみました。 Q:2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスが AWS のサービスのパブリックエンドポイントと通信する場合、トラフィックはインターネットを経由しますか? いいえ。パブリックアドレススペースを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。 AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。 https://a

AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 AWS CLI、どこから使っていますか？ ざっくり、以下4種類のどれかを使っている方が多数派ではないでしょうか。 ローカル端末 AWS内に構築した管理用EC2にSSHを利用して接続 AWS内に構築した管理用EC2にSSM(セッションマネージャ)を利用して接続 AWS CloudShell 一体どう違うのでしょうか。 状況によって良し悪しは異なる

こんにちは佐々木です。 先日、VPCのFAQに追加された項目が話題となっていました。2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、トラフィックがインターネットを経由するかどうかという問いに対して、AWSがノーと言っています。これは、どういうことなのでしょうか？ これがプライベートネットワークの通信と明示された意味は大きい 『Q:2つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスが AWS のサービスのパブリックエンドポイントと通信する場合、トラフィックはインターネットを経由しますか?』https://t.co/uy26KyCZKn— Takuro SASAKI (@dkfj) 2021年4月22日 このことを起点に、インターネットとは何か、AWSのネットワークの現状について考察してみます。難しい事を言っていますが、みんな疑問に

ご機嫌いかがでしょうか、豊崎です。 S3のストレージクラスは現在6つあります。どういったユースケースでどのS3のストレージクラスを選択したら良いのか、整理したかったので、チャートを作ってみました。 それではまずはS3の種類からです。 S3の種類と特徴 執筆時点でS3には以下6つのストレージクラスが存在します。（正確にはAmazon S3低冗長化ストレージ(RSS)を含めると7種類ですが、推奨されていないため、除外し6種類と記載しています。） S3 Standard S3 Standard-IA S3 Intelligent-Tiering S3 One Zone-IA S3 Glacier S3 Glacier Deep Archive 6つのS3ストレージクラス 特徴 それぞれ以下のような特徴があります。 S3 Standard 頻繁にアクセスされるデータ向け S3 Standard-I

Amazonは、なぜ、Aurora（オーロラ）という名前をつけたのだろう？　僕は、どこかで見かけた、「それは、オーロラは雲（Cloud）の上にあるからさ」という一節が、とても気に入っている。 まさに、Auroraの最大の特徴は、Amazonのクラウド・サービスの上に構築されたデータベースであるというところにある。小論では、クラウド上（「雲の上」）のデータベースであるAuroraが、どのようにクラウドの機能を利用しているのかを、そのScalabilityとAvailabilityに焦点を合わせて紹介しようと思う。 AuroraのScalabilityとAvailability まず最初に、Auroraの主要なScalabilityとAvailabilityを確認しておこう。 Push-button Compute Scaling：コンソール画面で数クリックするだけで、CPU数・メモリーサイズ

Infra Study Meetup #6でのLT登壇資料になります。

CONFIG GET ができないとかいう制約があるのは別として、最近ハマって、他の人もハマりかねないだろうと思うことを書いておきます。 Cache Cluster のスペックアップができない RDS のように作成した Cache Cluster のインスタンスタイプを変更することはできません。 AWSサポートに問い合わせても現時点ではできないという回答でした。 また、異なるインスタンスタイプのノードをレプリケーショングループに追加することもできないため、現時点でスペックアップしたい場合、新たな Cache Cluster を作成して手動でデータ移行と、アプリケーション側のエンドポイント切り替えを行う必要があります。 最近 Multi-AZ なクラスタ構成がサポートされたので、近い将来にはスペックアップ(インスタンスタイプ変更)もサポートされると期待したいものです。 Freeable Mem

概念図 とりあえずECSに出てくるエンティティがそれぞれどんな多重度で関連しているのかをまとめてみました。ここからはそれぞれのエンティがどんな概念なのかを解きほぐしていきたいと思います。 図1 概念図 Serviceが中心 ECSは平たく言うと クラスター（＝複数EC2インスタンスの集合）の上で Dockerコンテナを使って、 Serviceを動作させる ものです。 図2 例えばの構成 上図は、 Front Service (裏にいるAPIをCallしてWEB UIを提供するもの） API Service （ビジネスロジック、DBへの読み書きをRESTful APIで提供するもの） と言う２つのService で構成されるWEBアプリケーションの例です。 ECSで言うServiceは、Serviceは利用者から見た「サービス」よりも一段階か二段階細かいもので、APIサーバーとか、フロントサ

コンテナ。それは便利そうではあるが、面倒くさそうであり、積極的に取り入れるべきか微妙な存在。 個人的な感想としては、慣れるまでそれなりに大変・慣れれば楽しく便利。そう、つまり触ってみないと何もわからない、いつものヤツだ！細かいことはスッとばして、最低限の感触を掴むための構築手順を AWS + Terraform を用いて懇切丁寧に分解していくぞ！ 目的 AWSはチョットデキルし、コンテナに触れてみたいんだけど、何から手を付けたらいいかよくわからない。くらいのコンテナ初心者向けの内容にしていきます。コンテナ感覚を得るための具体的な構築メインなので、細かい話は飛ばし気味にいくため、ド素人向けではないです。 今回、構築するのはよくあるWEBサイトのような形をした超簡易的なコード管理とコンテナ運用で、それをAWSで表現していきます。これがスタンダードな構成だ、というわけではなく、これを１つのベース