「インターネットを経由した通信をどうしても行わせたくない」という場合は、このような構成を実装すれば可能です。 みなさん、こんにちは！ 福岡オフィスの青柳です。 前回のブログ記事では、「Azure OpenAI Service」を使ったチャットボットWebアプリを「Microsoft Azure」環境上に構築する手順をご紹介しました。 ご紹介した環境は、比較的シンプルな構成で実現できるものの、もしかするとネットワーク的なセキュリティ面で不安に感じる方もいらっしゃるかもしれません。 と言うのも、利用しているAzureの各サービス「Azure Open AI Service」や「Azure App Service」は、デフォルトではインターネットを経由して利用するようになっています。 そのため、悪意のある人間がこれらのサービスに対して不正なアクセスを試みたり、通信内容の盗聴を試みることが考えられ

昨年のre:Invent2019で発表されたAmazon RedshiftのFederated Queryが、RDS MySQL と Aurora MySQLをサポートしました。(Preview) これで、Amazon RedshiftとAthenaからRDSやAuroraのPostgreSQLとMySQLに直接クエリが実行できるようになりました。 Amazon Redshift Federated Queryとは RDS MySQL と Aurora MySQLのテーブルにRedshiftから直接アクセスできるようになりました。いわゆる、RedshiftからMySQLに対してデータベースリンクする機能です。 RDS PostgreSQL と Aurora PostgreSQLは既に利用可能です。Federated Queryの仕組みについては、以下のブログをご覧ください。 Federat

今回は TerraformのAWS Providerの便利機能default tagsをご紹介します。 やりたいこと 一連のリソースに同じタグを付けてタグでリソース管理をしたい時、あると思います。よくあるのが同一アカウント内に複数環境(開発/テスト/本番など)のリソースを作成するとき。また、コスト配分タグという機能を使えば、タグごとにコストをグルーピングすることができ、こちらも非常に便利です。タグの活用パターンについては以下にまとまっていますのでご確認いただければと思います。 ただ、どうやって各リソースに同じタグを設定すれば良いでしょうか。各リソースを作成時に都度都度タグの定義をしていては、抜け漏れとかタイポが発生しそうですよね。 そこでdefault tags この機能を使えば、各リソースに散らばってしまうタグ付与の設定を一元化することができます。TerraformのAWS Provid

コンバンハ、千葉（幸）です。 re:Invent 2020 の Key Note にて新たな EBS ボリュームタイプ gp3 が発表されました。 発表直後は「ブートボリュームとして指定できない」「 AMI が作成できない」などの制約がありましたが、すぐに解消されました。変更を試してみた内容もこちらに載っています。 せっかくなら現状 gp2 で動いているボリュームを新しいものに変更してみたい、と思い、いくつかの観点で検討を行いました。 コスト オンラインでの変更可否 IOPS スループット 変更を検討されている方の参考になれば幸いです。 先にまとめ gp2 と同等の性能を確保する限り、コストは gp3 の方が安い 多くの場合オンライン（無停止）での変更が可能 インスタンスタイプが旧世代の場合は変更を避けた方がよい（2020/12/16時点） 変更中に IOPS パフォーマンスが下がることは

開催中のAWS re:Invent 2020、ヴァーナーのキーノート中に、Amazon Managed Service for Prometheus（AMP）とAmazon Managed Service for Grafana（AMG）の二つが発表されました！ Amazon Managed Service for Prometheus | Fully Managed Prometheus | Amazon Web Services Amazon Managed Service for Grafana | Fully Managed Grafana Data Visualization | Amazon Web Services Our new partnership with AWS gives Grafana users more options | Grafana Labs それぞれ

本日のアップデートで Savings Plans の購入がキューイングできるようになりました。 Queuing purchases of Savings Plans Savings Plans の購入のキューイングとは 簡単に言うと「開始日の指定」ができるようになりました！ということです。 リザーブドインスタンスは開始日の指定が可能ですが、これまで Savings Plans ではサポートされていませんでした。 キューイングがサポートされたことで、以下のようなメリットがあります。 更新時の重複期間やオンデマンド利用期間を回避することで無駄なコストを削減 購入のキャンセルが可能（開始日より前の場合） 個人的には誤購入をキャンセルできることが非常にありがたい！（Savings Plans の購入は正直わかり難いですから。。） 注意点 指定できる購入日時は3年後まで 開始日の指定は UTC やっ

みなさん、こんにちは！ AWS事業本部の青柳＠福岡オフィスです。 前回、前々回と、ARMアーキテクチャの「Graviton2」と Docker のネタをお送りしましたが、今回は第3弾をお届けします。 前回のブログ記事 の中で、Docker Hubの「マルチCPUアーキテクチャサポート」について紹介しました。 前回は 「マルチCPUアーキテクチャ」に対応しているDocker Hubの公式イメージをプルして利用する という流れでした。 今回は一歩進んで 「マルチCPUアーキテクチャ」に対応するDockerイメージを自分でビルドしてDocker Hub上に公開する という一連の作業を試してみたいと思います。 「マルチCPUアーキテクチャサポート」とは？ Docker Hubにおける「マルチCPUアーキテクチャサポート」とは、x86 (AMD64) やARM64など複数のアーキテクチャ向けのイメー

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 アメリカ時間の2020年5月15日に新しい EC2 M6g インスタンスが GA されました。 AWS (とその関連会社) が設計したということでクラウド最適化された CPU であると勝手に期待しています。 コストパフォマンスに優れているということで汎用的なワークロードでは積極的に使用していきたいと思います。 上記が公式アナウンスですが、一部気になる箇所がありました。 現在使用しているのと同じメカニズム (yum、apt-get、pip、npm など) を介してインストール可能な一般的に使用されるソフトウェアパッケージの Arm バージョンが見つかります。一部のアプリケーションは再コンパイルが必要な場合がありますが、インタプリタ型言語 (Java、Node

ECSの運用において作成しなければならない膨大なAWSリソースを劇的に簡単なコマンドでまるっと作成〜運用〜管理できるコマンドラインツールCopilotの紹介です。 「いざECSの運用はじめようとしても、作らないといけないものめっちゃあるよなぁ。正直しんどい…」 ECS環境の構築って考慮が必要な項目ってものすごく多いんですよね。ネットワーク関連、ロードバランサー、リポジトリ、データベース、ECSそのもの、さらにそれをデプロイするためのパイプラインやデプロイ設定。 そんな辛さを一気に解消するAWS Copilotが発表されました！ AWS Copilot のご紹介 | Amazon Web Services ブログ 英語のブログ記事と同じタイミングで日本語がでるとは、toriの人も相当気合が入ってますね！ Amazon ECS でのコンテナ実行に新たな体験を提供する AWS Copilot の

GitHub Actionsのローカル実行ツール「act」を使う事でCI/CDコンフィグとローカルでのタスクランナーを1つにする actというローカル端末でのタスクランナーとしても使える、GitHub Actionsのローカル実行ツールを紹介します。 合わせて私のCI/CDのローカル実行ツールが必要だと思う理由、タスクランナーに対して感じている課題を紹介します。 はじめに おはようございます、加藤です。CI/CDツールとしてGitHub Actionsが2019年11月にリリースされてから一気に広まり、私もファーストチョイスとしてGitHub Actionsを検討・提案する機会が最近増えてきました。 先日、下記のTweetでactというGitHub Actionsのローカル実行ツールがあり、タスクランナーとしても使えるという事を知りとても興味を持ったのでブログにまとめました。 Actってい

EC2 AutoScalingでインスタンスタイプの重み付けができるようになりました。 どういうこと？ Auto Scaling Groupの設定では、一つのGroup内に複数のインスタンスタイプを指定することができます。 各インスタンスタイプごとに重み付けをすることが可能になりました。 AutoScaling Groupは、稼働中のインスタンスの重みの合計が希望キャパシティと同等かそれ以上になるようにフリートを維持します。 まずは重み付けとはどういうことか、理解する 簡単な例を使って重み付けの概要を理解しましょう。以下はAuto Scaling Groupの設定画面です。 赤枠で囲ったところに重みを入力できるようになっています。が、一旦入力なしでいきます。 インスタンスタイプも t2.small一種類だけです。 オレンジ枠で囲った通り、希望キャパシティは4です。作成されるインスタンス群は

本日のアップデートで Lambda から EFS が利用可能になりました！ AWS Lambda support for Amazon Elastic File System now generally available 何が嬉しいのか S3 を介さないファイル連携 Lambda でファイル連携を行うには一般的に S3 を介して利用されてきましたが、そもそも連携するためには連携させたいシステムが S3 にアクセスできるような仕組みになっている必要がありますが、オンプレからそのまま AWS に移行してきたようなシステムの場合、S3 へアクセスするための改修にハードルを感じる方も少なからず居られたかと思います。 今回、EFS に対応したことで単純にファイルシステムとしてファイル連携することが可能となりますので、そういった改修をせずとも Lambda と連携させた処理が実装しやすくなるのではな

最新情報については、公式の価格表を参照ください。 対応リージョン 以下のリージョンで利用可能です。 バージニア オハイオ オレゴン フランクフルト アイルランド 東京 やってみる M6g インスタンスを利用するには Arm に対応している必要があります。この一覧だと「Amazon Linux 2」「RHEL」「SUSE」「Ubuntu」などで利用が可能です。その他に、Arm をキーワードに AMI を探してみると「Debian」「Fedra」「FreeBSD」なども利用できそうです。 今回は Amazon Linux 2 を利用して、M6g.medium で起動してみます。 cpuinfo などのぞいてみたが、期待したような情報は得られませんね。。 $ cat /proc/cpuinfo processor : 0 BogoMIPS : 243.75 Features : fp asimd

しばたです。 先日EBS(プロビジョンドIOPS io1ボリューム)の複数インスタンスによるアタッチ(Multi-Attach)がサポートされましたが、本記事ではその使いどころについて考えてみました。 [アップデート]Amazon EBSの複数インスタンスへのアタッチが可能になりました！(プロビジョンドIOPS io1ボリュームに限る) AWS公式の案内はこちら。 はじめに はじめに言い訳で申し訳ないのですが、この記事では明確な答えを出せていません。 EBS Multi-Attachの使いどころについては現在進行形で悩み続けています。 本記事の内容に関してコメントなどでフィードバックを頂けると非常に嬉しいです。 EBS Multi-Attachの制限事項 使いどころについて触れるまえに、まずは現在のEBS Multi-Attachの制限事項から「何に使えないのか」を考えることにします。 先

Amazon SageMakerは機械学習における開発から運用までサポートしたフルマネージドサービスです。 SageMakerでは機械学習モデルをエンドポイントにホスティングし、APIでの推論が可能です。また、複数のモデルを同じエンドポイントインスタンスにホスティングし、指定したモデルへの推論リクエストも可能です。 今回はこの複数モデルのホスティングを試してみたいと思います。 マルチモデルエンドポイント(Multi-Model Endpoints) 複数のモデルをホストできるエンドポイントを作成するには、マルチモデルエンドポイントを使用します。マルチモデルエンドポイントでは、複数のモデルをホストできる共有サービングコンテナが使用されます。これにより、単一モデルエンドポイントを使用する場合と比較して、エンドポイントの使用率が向上し、ホスティングコストが削減されます。また、Amazon Sag

Working with Stages for HTTP APIs Lambda ペイロードバージョン2.0 Lambda プロキシ統合でペイロード形式バージョン2.0をサポートするようになりました。ペイロードバージョン2.0は、Lambda に送信されるイベントオブジェクトの形式を簡素化します。HTTP API ではデフォルトでペイロードバージョン2.0を使用します。 OpenAPI/Swagger サポート OpenAPI または Swagger構成ファイルのインポートをサポートするようになりました。サポートされたことにより、他の API Gateway サービスから HTTP API への移行が容易になります。 AWS SAM のサポート 2020年3月20日までに、これらの GA で追加された機能が AWS SAM でサポートされるとのことです！ AWS SAM support f

園部です。 CloudWatch アラームで複数のアラームの状態を条件にする複合アラームが可能となりました！ Amazon CloudWatch now allows you to combine multiple alarms 複合条件などについてはドキュメントに記載がありますのでご確認ください。 Creating a Composite Alarm やってみる 前置き 今回は、以下の内容でやってみます。 アラーム ① EC2 / CPUUtilization ② EC2 / EBSReadOps 複合アラーム アラーム① AND アラーム② 上記条件がともに 「アラーム状態」になったら SNS でメール通知 アラーム作成 アラーム① CPUUtilization CloudWatch >>> アラーム >>> アラームの作成 検証のため、閾値は極端な値を指定しています。 複合条件とする

大阪オフィスのYui(@MayForBlue)です。 つい昨日、Amazon ECRを触っていたら、AWS CLI v1 → v2 の移行で使用できなくなっているコマンドがあることを知ったのでその話です。 $ aws ecr get-login-password を使う 結論から言うと、ECRにログインするために必要な以下のコマンドがv2で使用できなくなっていました。 $ aws ecr get-login 公式のリファレンスを確認すると、以下のページに記載がありました。 AWS CLI version 2 replaces ecr get-login with ecr get-login-password このコマンドをv2で使用すると、以下のように、コマンドが使用できない旨のメッセージが表示されます。 usage: aws [options] <command> <subcommand

AWS Lambdaの開発などでAmazon CloudWatch Logsに送っているログをリアルタイムにtailしたい時があります。 AWS CLI v2を利用すると、$ tail -f相当のことが$ aws logs tail --follow LOG-GROUP-NAME で出来るようになりました。 * feature:logs: Added the logs tail command. This tracks new additions to a CloudWatch Logs group printing updates as they become available. See #3729. https://github.com/aws/aws-cli/blob/v2/CHANGELOG.rst この機能を簡単に紹介します。 準備:AWS CLI v2をインストール なにはと

本日、AWS CLI v2 の GA がアナウンスされました！ AWS CLI v2 is now generally available ちょっと使ってみましたが、あまりの便利さに感動しております！ AWS CLI v2 従来の AWS CLI v1 に比べてインストールが容易（python のバージョンがーーっ！！とか悩まない）になっているだけでなく、AWS シングルサインオン（SSO）対応、リソース名の補完やウィザードオプションなど強力なインタラクティブ機能が追加されています。 あと、YAML 形式の出力も使えますね！ 詳細については、Shirota の re:Invent のセッションレポートをあわせてお読みください。 また、今回の記事では触れていない AWS SSO 対応については、Kitano の記事を参照ください。 何はともあれインストール 今回は自分の mac に AWS