[アップデート] システムのリファクタリングを後押しするプロキシ層を提供「AWS Migration Hub Refactor Spaces」がプレビューリリースされました #reinvent re:Invent期間中に発表された新サービス「AWS Migration Hub Refactor Spaces」について紹介します。 Introducing AWS Migration Hub Refactor Spaces - Preview AWS Migration Hub Refactor Spacesは現在パブリックプレビューですので、どなたでもお試しいただけます。また、本記事の内容はパブリックプレビュー版をもとに執筆していますので、将来的に仕様が変更される可能性がある点はご注意ください。 AWS Migration Hub Refactor Spaces Strangler Fig

またまたドキュメントをながめていたところ、待望のアップデートを見つけたのでシェアします。 AWS WAFのWebACLトラフィックログをCloudwatch LogsまたはS3に直接出力することが可能になりました！ AWS WAFのWebACLトラフィックログ 従来は以下記事のようにKinesis Data Firehoseを介してCloudWatch LogsまたはS3に出力する必要がありました。 今回のアップデートでAWS WAFから直接CloudWatch Logs、S3に出力可能となりましたので控えめに言って最高のアップデートですね！ 注意点 CloudWatch Logsロググループ名およびS3バケット名はaws-waf-logs-から始まる名前であること Kinesis Data Firehoseも配信ストリーム名でも同じ制約がありましたが、CloudWatch Logs、S3

ドキュメントをながめていたところ、AWS WAFでCAPTCHAが利用可能になったようです！ CAPTCHAって何？ CAPTCHAはCompletely Automated Public Turing test to tell Computers and Humans Apartの略で、簡単に言ってしまうとWebサイトへのリクエストがコンピュータによるものか人がアクセスしているのかを区別するためのテストです。 「私はロボットではありません」 という項目にチェックを入れて、難読な文字を入力したり、簡易的なパズルを行ったりした経験が皆さんあるかと思います。それです。 CAPTCHAチャレンジパズル ささっと検証したところでは3つのパズルを確認することができました。 視覚パズル 1つはカーソルをスライドし、右上に指示された図形と同じ図形を完成させます もう1つは、車のルートをたどり、最終地点に

[アップデート] インターネットトラフィックのパフォーマンスが最大60%向上！Amazon S3 マルチリージョンアクセスポイントの紹介 アップデートからしばらく時間が経ってしまいましたが、先日リリースされた Amazon S3 Multi-Region Access Point についてご紹介します。 Amazon S3 Multi-Region Access Point が、レプリケートされたデータセットへのアクセスを最大 60% 加速 S3 Multi-Region Access Point グローバル展開されるアプリケーションやリージョン障害を考慮したアーキテクチャを設計する際に、S3 のクロスリージョンレプリケーション(CRR)は広く採用されている方法です。 しかしながら CRR で複数リージョンのバケットにオブジェクトを配置できたとしても、最短のレイテンシでアクセスするためにど

利用可能リージョン 残念ながら初期リリースでは東京、大阪ともに利用できません。利用可能リージョンは以下のとおりです。 バージニア北部 オレゴン オハイオ アイルランド フランクフルト シンガポール 注意事項 M6i で最適なネットワークパフォーマンスを得るには Elastic Network Adapter（ENA）ドライバーバージョン3 を利用する必要があります。既存環境からインスタンスタイプを変更して利用する際など、ドライバーバージョンにお気をつけください 参考：最大のネットワークパフォーマンスを得られるようにするには、EC2 インスタンスを第 6 世代インスタンスに移行する前に何をしておく必要がありますか？ 起動してみた 今回は以下の環境で起動しました リージョン : オレゴン(us-west-2) AMI : amzn2-ami-hvm-2.0.20210721.2-x86_64-

Terraformで予防的ガードレールを実装したい！「Terraform-Compliance」のご紹介 7月7日はクラスメソッドの創立記念日です。今日は次々にブログ記事があがってくることでしょう！ また、わたくしゴトですが 18 期からコンサルティング部の部長を務めさせていただくことになりました。「あいつ、部長になったらブログ書かなくなったよな」と後ろ指さされないように、ブログの書ける部長として頑張っていきたいと思います。 ここから AWS が一般的に利用されるようになった昨今最近では単に AWS を使いたいという相談よりも、どうやって AWS 環境をうまく運用するべきか？というご相談が多くなっているように感じます。よくある相談の 1 つが「ガバナンス」です。 ある程度ユーザーに権限をもたせ自由にリソースを作成できるようにした結果、 「パブリックアクセスで S3 を公開してました、、」

IAMユーザー/IAMロールの実際の操作履歴からIAMポリシーが生成可能になりました。理想（最小権限の原則)と、現実(実運用)のギャップを埋めるのにかなり役立ちそうです。 ご参考 IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity Generate policies based on access activity - Things

コンバンハ、千葉（幸）です。 S3 のライフサイクルやバージョニング、使ってますか？ 私は「あぁそれね、4年くらい前に完全に理解しましたよ」という気分でいたのですが、いざ きちんと思い出そうとすると 90分ほどかかってしまいました。 3歩あるくと大抵のことを忘れる私としては、都度 90分かけて思い出すわけには行きません。今後は 3分くらいで思い出せるよう、まとめてみることにします。 まとめ バージョニング はバケット単位で設定する ステータスは以下のいずれか 無効 有効 停止 「以前のバージョン」のオブジェクトは復元できる 削除マーカーによる論理的な削除という状態が生まれる ライフサイクルはスコープを限定可能で、ルールを複数設定できる 選択できるアクションは以下 現行のバージョンのストレージクラスの移行 以前のバージョンのストレージクラスの移行 現行のバージョンの失効 以前のバージョンの完

本日のアップデートで Route 53 Resolver に新たな機能として DNS Firewall が追加されました。 Introducing Amazon Route 53 Resolver DNS Firewall DNS Firewall? DNS Firewall は VPC からのアウトバウンド DNS リクエストを保護します。保護方法の例としては以下のとおりです。 特定のドメイン名以外の名前解決をさせない 不良と判別されているドメイン名の名前解決をさせない これらの方法により、DNS の侵害やマルウェア感染により、ユーザーの知らないところで悪意のあるサイトへ誘導されるような攻撃から保護することが可能になりました。 管理方法 DNS FIrewall は AWS Firewall Manager を使用して AWS Organization 内のアカウント全体で一元的に設定、

想定シナリオ 想定シナリオは以下の通り(某試験文章風) ----- ある企業がAWS上で Amazon Linux 2 の EC2インスタンスからなるアプリケーションを稼働させています。 新しい社内クラウドセキュリティポリシーに準拠するために、すべてのEC2インスタンスに対して 脆弱性診断ツールが導入されました。 そして、脆弱性診断で指摘された重要度CRITICAL の指摘事項は 必ず対応しないといけないと定められています。 ある日 特定のEC2インスタンスに対して 重要度CRITICAL の脆弱性 (CVE-XXXX-XXXX ※)が検出されました。 セキュリティエンジニアであるあなたは、脆弱性が検知された EC2インスタンスに対して セキュリティパッチを当てる責任があります。 まずは検証環境のEC2インスタンスを使って、 効率よくセキュリティパッチを当てる方法を探しはじめました。 ※C

「Amazon S3 インターフェースエンドポイント（PrivateLink）ではプライベート DNS をサポートしていません」 の意味を絵をかいて腹落ちさせてみた 2023/3/15追記 「サポートしていません」の時代に本エントリを書いたのですが、アップデートによりサポートされるようになりました。その内容を以下エントリに書きました。 以降の記述は当時の内容としてお楽しみください。上記のエントリとあわせて読むとより理解が捗ると思います。 コンバンハ、千葉（幸）です。 先日、Amazon S3 向けの PrivateLink（インターフェースエンドポイント）がサポートされました。 これによりオンプレミスから S3 へのプライベートアクセスが、簡単に構成できるようになりました。 注意点として、S3 インターフェースエンドポイントではプライベート DNS 名が使用できないというものがあります。

本日のアップデートで複数の VPC から RDS プロキシ を経由して Aurora/RDS への接続が可能になりました。 Amazon RDS Proxy now supports database connectivity from multiple Amazon VPCs 複数 VPC からの RDS プロキシを利用可能 これまでは RDS プロキシは Aurora/RDS が配置されいる VPC 内でのみ利用可能でしたが、今回のアップデートにより異なる VPC 内の EC2 や Lambda からも RDS プロキシを経由して Aurora/RDS への接続が可能になりました。 VPC 間で Aurora/RDS に接続する場合、従来は以下のように VPC ピアリングなどを用いてネットワーク的に接続しているかと思います。 VPC ピアリングのようにネットワークまるごとを接続したくな

本日のアップデートで RDS プロキシ に Amazon Aurora レプリカ向けのリーダーエンドポイントが利用可能になりました。 Amazon RDS Proxy adds read-only endpoints for Amazon Aurora Replicas 想いが届いたのでしょうか、、 リーダーエンドポイント対応 従来、RDS プロキシエンドポイントが作成できるのはプライマリーエンドポイントのみが対象でしたが、今回のアップデートでリーダーエンドポイントも対象に追加することが可能になりました。 これにより、例えば Lambda などから多重にリーダーエンドポイントへの接続が発生するような仕組みも RDS プロキシを利用することで接続数問題を回避することができます。 RDS プロキシについての詳細は岩田の記事を一読いただくのが良いかと思います。 料金 価格表がまだ更新されていない

ども、もこ@札幌オフィスです。 AWSの通信利用料を調べる機会があり、アウトバウンド通信のコスト削減をするために試行錯誤していたのですが、「実は動的コンテンツとか静的コンテンツとか深く考えずにCloudFrontを挟んだ方が安くなるのでは」と思い、計算してみたところ良さげだったので、簡単な内容とはなりますがご紹介します。 ※本記事でのアウトバウンドとはCloudFrontを経由出来る通信の事であり、EC2からどこかへファイルをアップロードするなどの通信は対象外となりますのでご注意ください。 TL;DR EC2、ELB、S3のインターネットへのアウトバウンド通信は $0.114〜$0.084 per 1GB ※1 EC2、ELB、S3からCloudFrontへのアウトバウンド通信は無料 CloudFrontのアウトバウンド通信は $0.114〜$0.06 per 1GB ※1 クラスメソッド

その他に以下の料金が発生します。 Storage Rate $0.12 per GB-month Ethereum API リクエスト $0.00000488 per Request ($4.88 per million requests) 1 リクエストは交換されたデータサイズ 32 KB または 応答時間 500 ms のいずれかでカウントされます 利用可能なリージョン 執筆時点で利用可能なリージョンは以下のとおりです。 米国東部（バージニア北部） アジアパシフィック（ソウル） アジアパシフィック（東京） アジアパシフィック（シンガポール） 欧州（アイルランド） 欧州（ロンドン） 利用上の考慮点 ノードタイプ 執筆時点において Ethereum on Amazon Managed Blockchain で利用可能なノードは Geth フルノードのみです。以下のとおりアーカイブノードはグ

本日のアップデートで VPC フローログに通信元、通信先の AWS サービス名や通信経路の表示可能になりました。 Amazon VPC Flow Logs now reflects AWS Service name, Traffic Path and Flow Direction さっそく見てみる 以下のログでは後 4 つのフィールドが今回追加されたものになります。 追加されたフィールド 今回追加されたのは以下の 4 フィールドです。 pkt-src-aws-service ソース IP アドレスをもとに AWS サービス名を表示します。表示される値は以下のとおりです。 AMAZON AMAZON_APPFLOW AMAZON_CONNECT API_GATEWAY CHIME_MEETINGS CHIME_VOICECONNECTOR CLOUD9 CLOUDFRONT CODEBUIL

本日のアップデートで AWS Config で AWS コンテナサービスの構成変更の管理が可能になりました！ AWS Config now supports Amazon container services ECS/EKS ユーザー待望のアップデートが来ましたね！ AWS Config の AWS Container Service サポート AWS Config は セキュリティ、ガバナンスのために利用されるフルマネージドサービスです。AWS Config では AWS リソースのインベントリ、構成履歴、構成変更通知の機能を備えています。 これらの機能により意図しない変更を検知したり、特定時点における AWS リソースの構成状態を追跡することが可能となります。 また、AWS Config ルールを利用することで特定の条件を満たしていないリソースを「非準拠」として検出し、自動的にリカバリ

え・・・いつからそこに居たの。 ずっと待ってたんだよ・・・ ということで、ひっそりと東京リージョンでも Amazon Athena の Federated Query が GA されていました。 いつから？ 2020年12月16日にドキュメント更新されていたようです。 こんな待望のアップデートを 1 ヶ月も見落としていたなんて。。私、アップデート職人だと自負していましたが、これはアップデート職人引退が迫られる事案だと重く受け止めています。。 Amazon Athena Federated Query Amazon Athena のフェデレーテッド・クエリはリレーショナル、非リレーショナル、オブジェクト、およびカスタムのデータソースに格納されているデータに対して SQL クエリを実行できるようになる機能です。フェデレーテッド・クエリについては以下のブログを参照ください。 これまで Athen

コンバンハ、千葉（幸）です。 Amazon EFS で、ファイルシステムのストレージ使用量を CloudWatch でモニタリングできるようになりました！ ストレージサイズの確認自体は従来から EFS のパラメータを参照することで実現できたのですが、今回新たに CloudWatch メトリクスとして取得できるようになりました。 CloudWatch アラームと組み合わせることで、「いつの間にかボリュームが膨らんでコストがかかり過ぎている……」というケースを回避しやすくなりましたね。 EFS ファイルシステムのストレージ使用量が何に影響するか 今回のアップデートがどう嬉しいかを理解するために、 EFS におけるストレージ使用量の考え方についておさらいしておきましょう。 ペタバイト規模まで自動的にスケールする EFS ファイルシステムは格納したデータサイズに応じて自動的にスケールするため、（例

本日のアップデートで AWS Transfer Family から EFS への接続が可能となりました。 AWS Transfer Family for EFS 従来、AWS Transfer Family は S3 を対象とした FTP/FTPS/SFTP が可能でしたが、今回のアップデートで EFS への FTP アクセスが可能となりました。 EFS へのアクセスは FTP/FTPS/SFTP 3 つのプロトコルで利用可能です。 パブリックからの EFS アクセス EFS は VPC を経由して NFS マウントする共有ファイルシステムのマネージドサービスです。VPC 内の EC2 からは勿論のこと、Direct Connect や VPN を利用することでオンプレ環境からマウントすることが出来ます。 一方でパブリックな環境から EFS へ直接アクセスすることは出来ませんでしたが、AW