ライタス株式会社公式ブログ

こんにちは。 ライタスの営業担当・Kです。 先日、 生成AIとAWSの最新動向、そしてビジネスでの活用方法をテーマにした オンラインセミナーに参加してきました。 生成AIについては日々話題になりますが、 今回は「実際にどれくらい使われているのか」や 「どう提案やサービスに落とし込んでいくのか」といった視点で整理されていて、 とても学びの多い内容でした。 【生成AIの利用率は「本番環境」で急激に伸びている】 セミナーの中で紹介されていたのが、 生成AIの本番環境での利用率に関するデータです。 2023年時点では数％程度 2025年には7割以上 2026年には8割を超える 実際の業務やサービスの中で使われるケースが 急激に増えている、という点が印象的でした。 生成AIの活用も、 初期はAIアシスタント（チャットボット）から始まり、 中期にはツール連携、 将来的には自律型AIエージェントへと進化していく流れになるそうです。 【生成AIを求められたときの提案の考え方】 「顧客が生成AIを使いたいと言ったとき、どう整理して提案するか」という話も印象に残っています。 既存システムにAI機能を組み込みたい場合には、 AWS上で複数の生成AIモデルを 共通のAPIで扱える仕組みが用意されている、という説明がありました。 この仕組みを使うことで、 モデルを切り替えたとしても、 アプリケーション側の実装を大きく変えずに済む という点は、実運用を考えるとかなり大きなメリットだと感じました。 Amazon製の生成AIが東京リージョンで使えるという安心感 正直に言うと、 Amazonが独自に生成AIモデルを開発していて、 その主要なモデルが東京リージョンでも利用できる という点は、今回初めて知りました。 国内リージョンに限定できることで、 セキュリティやデータの取り扱いを重視するお客様にも 提案しやすくなりそうだと感じます。 【すぐに使う／業務に組み込むという選択肢】 「まずは安全に、低コストで生成AIを使い始めたい」 というケースや、 「既存業務の一部をAIに任せたい」 といったニーズに向けたサービスの紹介もありました。 プロンプトを一から考えなくても よくあるユースケースをすぐに使える点や、 ノーコードで業務を自動化できる点など、 現場でも現実的に使えそうだなという印象です。 【生成AI...

こんにちは。ライタス株式会社の藤田です。 今回は、顧客の使用していないAWS環境の削除を行った際の流れなどを 備忘録も兼ねブログに残したいと思います。   【前提】  ・顧客が現在全く使用していない環境  ・使用している機能等が一切不明  【目的】  ① 費用が掛かり続けているサービスを全て停止  ② AWS自体を削除  削除にあたり、ルートユーザーアカウント※が必要となるのですが （※IAMのAdmin権限ではない）  ルートユーザーのパスワードを失念したとのこと、ログイン画面の「パスワードをお忘れですか？」から再設定しました。 ●請求ダッシュボードで金額がかかっている項目確認  無事にサインイン後、 まず確認するのは請求がかかっている項目から攻めます。  右上サインインアカウントから「請求ダッシュボード」で確認。  今回、以下の項目の設定削除・設定変更を行っていきます。     EC2(Elastic Compute Cloud)   Elastic Load Balancing  ECR  VPC  Route53  Secret Manager  AWS Support （Developer）  今回は全部止めるので、片っ端から行きます。  ●（EC2）ElasticIP 削除 公式ページを参照に実施します。 削除と書きましたが、正しくは「Elastic IP アドレスの関連付けを解除する」と言う様です。 参照： AWS公式ページ 　 ●EC２インスタンス削除 これは一筋縄ではいきませんでした。 正しく関連しているものを解除していかないと、エラーが出てインスタンスの終了ができません。 まずはEC2インスタンス自体にかかっている終了保護などを解除します。 そしていったん以下の順番でかかっている金額が高い設定を解除していきました。 　→ロードバランサー 　→NAT Gateway 　→EC２インスタンスを一旦全て削除 この後別の作業を行っていたのですが、削除したはずのEC2があることに気づきました。 そのあと削除を2回ほど実施しま...

お世話になります。 新入社員の 田所 です。 最近AWSでの構築のお仕事が重なり、「これ前もやった設定だな・・・」なんてことをSSHで設定する度に感じました。 なので最低限これはレシピとして持っておいて正解かな?っていう内容をシェルスクリプトにしてみました。 Amazon Linux 2 AMIでの方法ですのでご了承ください。 また、これだけではCloudWatch等サービスとの連携はできず、 適切なIAMロールをEC2に適応する必要があります。 今回はEC2側の設定のみです。 ※あくまで参考程度にして頂き、細かい設定は各環境に合わせて変更、運用してください。 今回は下記のような設定をスクリプトにしています。 日本時間に設定 CloudWatchAgentのインストール、起動 ec2-userのロック、新規ユーザーの作成 CloudWatchLogsのインストール、設定、起動 ↓が作成したものです。 #!/bin/bash # =====①アップデート====== yum -y update # =====②インスタンス名を環境変数に定義しておく====== echo "export INSTANCE_NAME='product-ec2-web-1a'" >> /etc/profile source /etc/profile # =====③日本時間に設定====== cp -p /usr/share/zoneinfo/Japan /etc/localtime cat << EOF > /etc/sysconfig/clock ZONE="Asia/Tokyo" UTC=true EOF # =====④amazon-cloudwatch-agentの設定====== yum install -y amazon-cloudwatch-agent /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s # =====⑤新規ユーザーを作成し、ec2-userを使用不可にする...

この度、ダイワボウ情報システム様との連携により、AWSのリセラー販売が可能となりましたので、お知らせいたします。 AWSリセラー販売は、これからAWSを利用しようとしている方だけでなく、すでにAWSを利用されている方も移行することができます。 また、請求書払い、円払いにて取り扱いが可能です。 詳細については、弊社問い合わせ窓口よりお問い合わせください。

AWSの構築依頼が増えてきており、ネットワーク構築、セキュリティのコンサルティングのご依頼が特に増えております。 昨今パブリッククラウドが普及したためか、これまでオンプレミス環境で構築されていたお客様も、一部、ないしは全部の環境をクラウドに移行することを検討されるなど、さらなる普及が進むと思われます。 しかしながら、適切なセキュリティを講じていないために、法外な請求を受けたり、情報漏洩を起こしたりと、インシデントが発生することも多々あるので、構築時からセキュアな環境を構築するように心がけていきたいところです。 セキュアな環境を構築するときに、よく登場するVPNですが、今回はこれを構築するときにはまりましたので、その記録を書きたいと思います。 構成としては、AWS VPC上に、自前VPNサーバー + NAT トラバーサルです。 今回はユーザーメンテナンスを考慮し、SoftEther VPNで構築しました。 構築については、他のサイトでもよく記載されているので、そちらをご参照いただければと思います。 AWSにSoftEther VPNServerで簡単にVPN接続しよう ｜ DevelopersIO https://dev.classmethod.jp/cloud/aws/rk-2018-02-12-softethervpn/ AWS(EC2)でSoftEtherを使ってL2TP/IPsecなVPNを構築する (Mac) - Qiita https://qiita.com/showwin/items/92861057a8b62611444d SoftEther VPNは、設定がGUIでできるので、ユーザーに環境を引き渡すときも安心なのがうれしいですね。 ところが、VPNで接続して、いざ内部のサーバーにPingをしてみたところ、うまく疎通できません。（クライアントはWindows 10） 不思議なことに、tracertをすると、何回かタイムアウトしたのちに通信ができるようになります。 一度通信できるようになったら特に問題なく疎通できるのですが、VPNを再接続すると現象が再現します。 最初はMTUが適切な値ではないとか、ルーティングの設定がおかしいのかといろいろ試してみたのですが、どれもうまくいかない上に、クライアン...

AWSでVPCを扱うとき、セキュリティポリシーとして、通信制御を行うと思います。 通信制御をするときは、ネットワークACLとセキュリティグループを活用して設定しますが、ここで幾つかハマりポイントがあります。 1. ステートレスとステートフル ネットワークACL ステートレスインスペクション セキュリティグループ ステートフルインスペクション ステートレスとは、指定したポートのみを通すもので、他のポートは通信を拒否します。 ステートフルは、指定したポートを通しますが、その通信の戻り通信も許可します。 http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Security.html 2. 設定単位 ネットワークACL サブネット単位 セキュリティグループ ENIおよびグループ単位 ネットワークACLは、VPC内に定義されたサブネット単位で作成できます。 セキュリティグループは、サーバーごとに設定するイメージですが、実態としては、ネットワークカードに対して設定するイメージと捉えています。 3. ネットワークACLとセキュリティグループを両方使う ネットワークACLとセキュリティグループを両方使う場合、両方許可されないと通信ができなくなります。 ネットワークACL セキュリティグループ 結果 許可 許可 許可 許可 拒否 拒否 拒否 許可 拒否 拒否 拒否 拒否 4. ハマリポイント 上記ルールに従って通信制御を行うことができますが、ネットワークACLがステートレスのため、ちゃんと通信ポートが開いてると思っているのに、開いていなかったということがよくあります。 また、戻りの通信ポートがダイレクトポートを使っている場合、ネットワークACLで拒否されてしまって、通信できなかったということが 検証方法としては、ネットワークACLかセキュリティグループを一瞬フルオープンにして通信できるかどうか確認する方法をよく使います。 他にも、AWS全体に言えることですが、設定上限になっているものが結構あります。 事前に把握しておくと良いかと思います。

AWS APIを実行する時に、APIエンドポイントへのアクセスをする必要があります。 この時に、HTTP/HTTPSのポートを開けておけばいいのかと思ったのですが、うまくいきませんでした。 いろいろ調べたところ、NACLのインバウンドで 49152-65535 の範囲でポートを開けておく必要があると記載があったので、設定してみたところ、うまくいきました。 http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.html このポートのことをエフェラメルポートと言い、リクエストを効率良く処理するためのポートとして使われます。 AWS APIエンドポイントもこちらのポートを使うようですので、うまくいかないようであれば、ここも疑ってみる必要がありそうです。

いきなりですが、誤操作でAWSのEC2でサーバーをTerminateしてしまいました。 ※個人で使っているアカウントです AWSを使う人にとっては、当たり前といえるこの地雷を、自らが踏むことになろうとは、予想もしていませんでした。 原因は、 酔っ払い運転 です 酔っている時にサーバーおよびコンソールを触ってはいけないルールを自分に課したところで、再発防止策について考えてみます。 調べてみれば、Terminateをロックするという機能がAWSに備わっているそうで、これを設定してやればOKです。 設定方法は、インスタンスを作成するときにチェックを入れる。 すでに作成しているインスタンスに対して設定変更を行うときは、右クリックメニューから変更可能です。 やっておいて損はないはずです 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの転載です。