【AWS】11/4(月) Amazon BedrockでAnthropic の Claude 3.5 Haiku モデルが利用可能
2024/11/4(月) Amazon BedrockでAnthropic の Claude 3.5 Haiku モデルが利用可能になったので調べてみた。
aws.amazon.com
提供リージョン
米国西部 (オレゴン) リージョンのみ
※米国東部 (バージニア北部) リージョンではクロスリージョン推論で利用可
Claude 3.5 Haikuとは
Anthropic の次世代の最速モデル、迅速な応答時間と改良された推論機能を兼ね備えている。
エントリーレベルのユーザー向け製品や特殊なサブエージェントタスク向き。
購入履歴、価格、在庫データなどの膨大なデータからパーソナライズされたエクスペリエンスを生成するのに適している。
高速で正確なコードの提案、迅速な応答時間を必要とする高度に対話的なカスタマーサービスチャットボット、eコマースソリューション、教育プラットフォームなどのユースケースにも利用可。
Claude 3.5 Sonnetとの違い
Sonnetはエンタープライズワークロード向き。
膨大な知識に基づく RAG (検索と取得)、製品のレコメンデーション、予測、ターゲットを絞ったマーケティング、コード生成、品質管理、画像からのテキストの解析が可。
感想
AnthropicのFMは会社名などをいれないといけないのがネックだね。
【AWS】11/18(月) Lambdaの一部ランタイムでSnapStartがサポート
2024/11/18(月) LambdaでPython および .NET のマネージドランタイムでSnapStartがサポートされたので見てみた。
aws.amazon.com
SnapStartを利用することで
SnapStartによりコード変更を最小限に抑え、関数の起動パフォーマンスが数秒から 1 秒未満まで高速化されるよう。
設定箇所
ここにありますね。
NoneとPublishedVersionsが選べるようです。
None：SnapStart無効化
PublishedVersions：Lambda関数の公開バージョンにのみ適用
料金
かからないようですが起動処理が変わるのでその関係でコストが変動する可能性がある模様。
【AWS】VPC Latticeを使ってみた
VPC Latticeとは
アプリケーションのサービスの接続、保護、モニタリングに使用する、フルマネージド型アプリケーションネットワーキングサービス。
docs.aws.amazon.com
やること
とりあえず、VPC Latticeを立てて動作を確認してみる
前提
EC2がすでに作成されていること
※まだの場合、下記を参考に作成する。
amegaeru.hatenablog.jp
実践！
１．Lambda関数作成
１－１．AWS - Lambda - 関数
１－２．「関数の作成」
１－３．下記を入力
関数名：VPC_Lattice_Test_Lambda
ランタイム：Python3.13
アーキテクチャ：x86_64
１－４．「関数の作成」
１－５．コードに下記を入力
def lambda_handler(event, context): return { 'statusCode': 200, 'body': 'OK', 'headers': { 'Content-Type': 'text/plain' } }
１－６．「Deploy」
２．VPC Lattice作成
２－１．サービスネットワーク作成
２－１ー１．AWS - VPC
２－１－２．左ペインから「VPC Lattice」-「開始方法」
２ー１－３．「サービスネットワークを作成する」
２ー１－４．サービスネットワーク名に「lattice-test-network」と入力、それ以外はデフォルト
※3～63 文字で、先頭と末尾は文字または数字である必要があります。小文字、数字、ハイフンのみ使用可
２ー１－５．「サービスネットワークを作成」
２－２．サービス作成
２－２－１．左ペインから「VPC Lattice」-「サービス」
２－２－２．「サービスを作成」
２－２－３．サービス名に「lambda-backend-service」と入力、それ以外はデフォルト
２－２－４．「次へ」
２－２－５．「次へ」
２－２－６．サービスネットワークの関連付けで、先ほど作成したサービスネットワークを選択
２－２－７．「次へ」
２－２－８．「VPC Lattice サービスを作成」
２－３．ターゲットグループ作成
２－３－１．左ペインから「VPC Lattice」-「ターゲットグループ」
２－３－２．「ターゲットグループの作成」
２－３－３．下記を選択
ターゲットタイプの選択：Lambda 関数
ターゲットグループ名：lambda-target-group
２－３－４．「次へ」
２－３－５．先ほど作成したLambda関数を選択
２－３－６．「ターゲットグループの作成」
２－４．サービスのルーティング設定
２－４－１．先ほど作成したサービスへ移動し、ルーティングタブを開く
２－４－２．「リスナーの追加」
２－４－３．下記を入力
リスナー名としてプロトコルとポートを使用する：✅
プロトコル：HTTP
ポート：80
デフォルトアクション：ターゲットグループへ転送します
ターゲットグループ：lambda-target-group
重み：1
２－４－４．「追加」
２－５．サービスネットワークにVPCを関連付け
２－５－１．AWS - VPC
２－５－２．左ペインから「VPC Lattice」-「サービスネットワーク」
２－５－３．先ほど作成したサービスネットワークを選択
２－５－３．「VPCの関連付け」タブ
２－５－４．「VPCの関連付けを作成」
２－５－５．「VPCの関連付け追加」
２－５－６．下記を選択
VPC：EC2が存在しているVPC
セキュリティグループ：インバウンドで80番が空いているセキュリティグループ
２－５－７．「変更内容の保存」
２－６．セキュリティ設定
２－６－１．AWS - VPC
２－６－２．左ペインから「VPC Lattice」-「サービスネットワーク」
２－６－３．「アクセス」タブ
２－６－４．「アクセス設定を編集」
２－６－５．認証ポリシーに下記を入力
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "vpc-lattice-svcs:Invoke", "Resource": "*" } ] }
２－６－６．「設定内容の保存」
３．接続確認
３－１．接続ドメイン確認
３－１－１．AWS - VPC
３－１－２．VPC Lattice - サービス
３－１－３．作成したサービスを選択
３－１－３．ドメイン名を確認
３－２．EC2から下記を実行し、200 OKが返ってくることを確認
> curl -v http://<接続ドメイン>
sh-5.2$ curl -v http://lambda-backend-service-0e41ee0d6c9b6f910.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws * Host lambda-backend-service-0e41ee0d6c9b6f910.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws:80 was resolved. * IPv6: fd00:ec2:80::a9fe:ab61 * IPv4: 169.254.171.97 * Trying 169.254.171.97:80... * Connected to lambda-backend-service-0e41ee0d6c9b6f910.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws (169.254.171.97) port 80 > GET / HTTP/1.1 > Host: lambda-backend-service-0e41ee0d6c9b6f910.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws > User-Agent: curl/8.5.0 > Accept: */* > < HTTP/1.1 200 OK < date: Tue, 26 Nov 2024 11:26:38 GMT < content-length: 2 < x-amzn-requestid: ecf13e4b-2f45-4124-8b04-6a55a0c5197c < x-amzn-remapped-content-length: 0 < x-amz-executed-version: $LATEST < x-amzn-trace-id: Root=1-6745b06e-53857c7e4a9803ff3b5f60d4;Parent=6f7f9a5decbdfe4a;Sampled=0;Lineage=1:36cc46cd:0 < content-type: text/plain < * Connection #0 to host lambda-backend-service-0e41ee0d6c9b6f910.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws left intact
感想
今回はLambdaでやったのでALBと変わらない気がした、、、次はECSあたりでやろう。
【AWS】TerraformでVPC環境とSSMで接続できるEC2インスタンスを作成してみた
なんとなく普段作っているがどこにも保存してなかったので書いてみた。
実践！
１．Terraformコード作成
１－１．下記ファイルを作成
version.tf
terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } required_version = ">= 1.0.0" }
variables.tf
variable "env" { type = map(any) default = { env = "test" } } variable "region" { description = "The AWS region to deploy resources in" type = string default = "ap-northeast-1" } variable "vpc_network" { type = map(any) default = { ser01 = "10.2.160.0/21" } } variable "area" { type = map(any) default = { region = "ap-northeast-1" az01 = "ap-northeast-1a" az02 = "ap-northeast-1c" } } variable "sub_network" { type = map(any) default = { pub_st-01 = "10.2.162.0/24" pub_st-02 = "10.2.163.0/24" pub_dy-01 = "10.2.160.0/24" pub_dy-02 = "10.2.161.0/24" pri_st-01 = "10.2.166.0/24" pri_st-02 = "10.2.167.0/24" pri_dy-01 = "10.2.164.0/24" pri_dy-02 = "10.2.165.0/24" } }
provider.tf
provider "aws" { profile = "testvault" region = "ap-northeast-1" }
data.tf
data "aws_caller_identity" "current" {}
main.tf
resource "aws_vpc" "vpc01" { cidr_block = var.vpc_network["ser01"] enable_dns_hostnames = true tags = { Name = "${var.env["env"]}vpc01" } } resource "aws_subnet" "dyprsub01" { vpc_id = aws_vpc.vpc01.id cidr_block = var.sub_network["pri_dy-01"] availability_zone = var.area["az01"] tags = { Name = "${var.env["env"]}dyprsub01" } } resource "aws_subnet" "dyprsub02" { vpc_id = aws_vpc.vpc01.id cidr_block = var.sub_network["pri_dy-02"] availability_zone = var.area["az02"] tags = { Name = "${var.env["env"]}dyprsub02" } } resource "aws_subnet" "dypusub01" { vpc_id = aws_vpc.vpc01.id cidr_block = var.sub_network["pub_dy-01"] availability_zone = var.area["az01"] tags = { Name = "${var.env["env"]}dypusub01" } } resource "aws_subnet" "dypusub02" { vpc_id = aws_vpc.vpc01.id cidr_block = var.sub_network["pub_dy-02"] availability_zone = var.area["az02"] tags = { Name = "${var.env["env"]}dypusub02" } } resource "aws_internet_gateway" "igw" { vpc_id = aws_vpc.vpc01.id tags = { Name = "${var.env["env"]}igw" } } resource "aws_eip" "nat_eip" { domain = "vpc" } resource "aws_nat_gateway" "nat_gw" { allocation_id = aws_eip.nat_eip.id subnet_id = aws_subnet.dypusub01.id tags = { Name = "${var.env["env"]}nat-gw" } } resource "aws_route_table" "public_rt" { vpc_id = aws_vpc.vpc01.id route { cidr_block = "0.0.0.0/0" gateway_id = aws_internet_gateway.igw.id } tags = { Name = "${var.env["env"]}public_rt" } } resource "aws_route_table_association" "public_rt_assoc" { subnet_id = aws_subnet.dypusub01.id route_table_id = aws_route_table.public_rt.id } resource "aws_route_table" "private_rt" { vpc_id = aws_vpc.vpc01.id route { cidr_block = "0.0.0.0/0" nat_gateway_id = aws_nat_gateway.nat_gw.id } tags = { Name = "${var.env["env"]}private_rt" } } resource "aws_route_table_association" "private_rt_assoc" { subnet_id = aws_subnet.dyprsub01.id route_table_id = aws_route_table.private_rt.id } resource "aws_iam_role" "ec2_ssm_role" { name = "${var.env["env"]}ec2_ssm_role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "ec2.amazonaws.com" } }] }) } resource "aws_iam_policy_attachment" "ec2_ssm_role_attachment" { name = "${var.env["env"]}ec2_ssm_role_attachment" policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore" roles = [aws_iam_role.ec2_ssm_role.name] } resource "aws_instance" "example_ec2" { ami = "ami-00c79d83cf718a893" instance_type = "t3.micro" subnet_id = aws_subnet.dyprsub01.id iam_instance_profile = aws_iam_instance_profile.example_profile.name vpc_security_group_ids = [aws_security_group.example_sg.id] root_block_device { encrypted = true } metadata_options { http_tokens = "required" } tags = { Name = "${var.env["env"]}example_ec2" } } resource "aws_iam_instance_profile" "example_profile" { name = "${var.env["env"]}example_profile" role = aws_iam_role.ec2_ssm_role.name } resource "aws_security_group" "example_sg" { vpc_id = aws_vpc.vpc01.id description = "Security group for example application" ingress { from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } tags = { Name = "${var.env["env"]}example_sg" } }
２．terraform実行
２－１．下記を実行
> terraform fmt
※コード成形
> terraform init > terraform plan > terraform apply
３．SSM接続
３－１．AWS - EC2 - 左ペインから「インスタンス」を選択
３－２．作成したインスタンスのIDを選択
３－３．「接続」
３－４．「セッションマネージャ」タブを選択し、「接続」
３－５．セッションマネージャに接続できることを確認
４．削除
※NATGatewayも作っているので使い終わったらすぐ消しましょう。
４－１．下記を実行
> terraform destroy
感想
【AWS】Bedrockでプレイグラウンドを使用してみた
まずは下記ユーザガイドに従ってBedrockのプレイグラウンドを触ってみた。
docs.aws.amazon.com
実践！
１．モデルアクセス有効化
１－１．AWS - Bedrock
１－２．左ペインから「モデルアクセス」を選択
１－３．「特定のモデルを有効にする」
１－４．Amazonにチェックを入れ、「次へ」
※ユーザガイドではAmazon Titan Image Generator G1 V1を有効にするよう記載されているが、東京リージョン(ap-northeast-1)では利用不可。us-east-1では可
１－５．「送信」
１－６．Amazonのモデルにアクセスが付与されたことを確認
２．テキストプレイグラウンド利用
２－１．AWS - Bedrock
２－２．左ペインから「プレイグラウンド」内の「Chat/text」を選択
２－３．「モデルを選択」
２－４．下記を選択
1.カテゴリ：Amazon
2.モデル：Titan Text G1 - Express
3.推論：オンデマンド
２－５．「適用」
２－６．テキストボックスに「Describe the purpose of a "hello world" program in one line」と入力し、「実行」
２－７．テキストが生成されたことを確認
３．イメージプレイグラウンド利用
※１－４でus-east-1リージョンで「Amazon Titan Image Generator G1 V1」を有効にしている場合、下記実施可。
３－１．AWS - Bedrock
３－２．左ペインから「プレイグラウンド」内の「イメージ」を選択
３－３．「モデルを選択」
３－４．下記を選択
1.カテゴリ：Amazon
2.モデル：Titan Image Generator G1 v1
3.推論：オンデマンド
３－５．「適用」
３－６．テキストボックスに「Generate an image of happy cats」を入力し、「実行」
３－７．猫の画像が作成されたことを確認
感想
実際手を動かすとイメージが湧くね！
【AWS】Amazon Bedrockのスキルビルダーを覗いてみた
最近何かと話題のBedrockさんを使いたいのでまずは概要を調べてみた。
Bedrockの下にスキルビルダーへのリンクがあるのでここを覗いてみる。
Amazon Bedrockとは
最先端の基板モデル(FM)と、生成型人工知能アプリケーションを迅速に構築及び拡張するための一連の機能提供する、完全に管理されたサービス。このサービスは、プライバシーとセキュリティの確保にも役立つ
。
Amazon Bedrockの機能
・チャット、テキスト、画像用のプレイグラウンド。コンソールから実験したり使用したりするためにFMに素早くアクセスできる。
・透かし検出やガードレースなどの安全対策
・ナレッジベースとエージェントを使用したアプリケーションのオーケストレーションと自動化
・モデル評価とプロビジョニングされたスループットによる評価と展開
様々なFM
・Amazon
・Al21 Labs
・Anthropic
・Cohere
・Meta
・Mistral AI
・Stability AI
また、これらにはAmazon Titan、Jurassic、Claude、Command、Embed、Llam、Mistral、Stable DiffusionファミリーのFMも含まれる。
セキュリティ
データ転送中はTLS1.2で暗号化され、保存中はKMSキーで暗号化される。
また、PrivateLinkを使用するとトラフィックをインターネットに公開することなくBedrockを利用できる。
FMへのアクセスにはIAMによる制御が可能。
ガバナンスと監査
CloudWatchでメトリクスの監視、CloudTrailによるAPIアクティビティの監視が可能
自動化
Amazon Bedrockエージェントにより幅広いユースケースの複雑なタスクを手動コーディングすることなく実行できる。
FMに組織固有の情報を補足できる
Amazon Bedrockナレッジベースを使用すると、FMとエージェントに会社のプライベートデータソースから取得したコンテキスト情報を提供して、検索拡張生成(RAG)を行うことができる。
ナレッジベースはS3にあるデータにアクセスしてストアを自動的に構築できる。
Amazon Bedrockの一般的な使用例
・テキスト生成：短編小説、エッセイ、ソーシャルメディアへの投稿などオリジナルコンテンツを作成する。
・バーチャルアシスタント：ユーザのリクエストを理解し、リクエストを満たすアクションを実行する。
・テキストと画像の検索：テキスト・画像から関連情報を検索し推奨事項を提供する。
・テキスト要約：長い文書の簡潔な要約を取得する。
・画像生成：広告キャンペーン、Webサイトなどに利用できる画像を素早く生成する。
・ガードレール：アプリケーション要件と責任あるAIポリシーに合わせてカスタマイズされた保護手段を実装する。
Amazon Bedrockの料金
・オンデマンド
・プロビジョニングされたスループット
感想
基板モデル(FM)と検索拡張生成(RAG)がポイントな予感。
【GCP】Cloud Runを使ってみた
コンテナイメージを指定するだけでコンテナ環境が作成できると聞いたのでCloud Runを使ってみた。
実践！
１．Cloud Run起動
１－１．GCP - Cloud Run
１－２．「サービスの作成」
１－３．下記を入力
既存のコンテナイメージから １つのリビジョンをデプロイする：✅(default)
コンテナ イメージのURL：サンプル コンテナでテスト
構成：
サービス名：hello(default)
リビジョン：asia-northeast1(東京)
エンドポイントURL：
認証：
未承認の呼び出しを許可：✅
CPUの割り当てと料金：
リクエストの処理中にのみ CPU を割り当てる：✅(default)
サービスのスケーリング：
インスタンスの最小数：0(default)
上り（内向き）の制御：
すべて：✅(default)
コンテナ：
コンテナポート：8080(default)
コンテナコマンド：空白(default)
コンテナの引数：空白(default)
リソース：
メモリ：512MB(default)
CPU：1(default)
リクエスト：
リクエストのタイムアウト：300(default)
インスタンスあたりの最大同時リクエスト数：80(default)
実行環境：
デフォルト：✅(default)
リビジョン スケーリング
インスタンスの最小数：0(default)
インスタンスの最大数：100(default)
起動時のCPUブースト：✅(default)
１－４．「作成」
２．動作確認
２－１．URLをクリック
２－２．陽キャが表示されることを確認
感想
コンテナイメージ指定だけじゃなかった、、、楽だったけど、、、
