こんにちは、鈴木(純)です。 みなさんセッションマネージャー、使ってますか？私は結構な頻度で利用しています。 EC2へ入るのにSSHするの面倒だし、プライベートサブネットにもアクセスできるので踏み台がいらなかったりと非常に便利ですよね。 しかし、いざ設定してみるとなかなか繋がらなくてドキュメントをみてもよく分からない、意外と設定が多くてどこに原因があるのかわからないなんてこともありませんか？ 今回はそんなセッションマネージャーを利用するときのハマりどころをパターンごとに整理してみました。 セッションマネージャーでEC2にアクセスする場合、大きく分けて次の3パターンで考えます。 EC2がパブリックサブネットにある場合 EC2がプライベートサブネットにあり、インターネットへのアウトバウンド通信経路がある場合 EC2がプラベートサブネットにあり、インターネットへのアウトバウンド通信経路がない場合

大半のユースケースでは、高い可用性が提供されるS3 Standard - IAを選択することになると思いますが、可用性よりもコストを優先したい場合にS3 One Zone - IAを選択しましょう。 S3オブジェクトの取り出しに許容できる時間 つづいて、「オブジェクトの取り出しに許容できる時間は？」の分岐箇所に関するチェックポイントです。 基本的にユーザーはS3オブジェクトに対しミリ秒単位でアクセスできますが、ストレージクラスによってはオブジェクトにアクセスする前に「オブジェクトの復元（取り出し）」を行う必要がありミリ秒単位でのアクセスが提供されていない場合があります。 アクセス時に「オブジェクトの復元（取り出し）」が必要なストレージクラスが以下の2つのストレージクラスです。 S3 Glacier Flexible Retrieval S3 Glacier Deep Archive ミリ秒

こんにちは、菊池です。 衝撃の新機能です。VPCに割り当てるCIDRが拡張可能になりました！ Amazon Virtual Private Cloud (VPC) now allows customers to expand their existing VPCs 「一度作成したVPCのCIDRは変更できない」という常識は過去のものになりました。この新機能によりVPCがスケール可能になりますので、EC2、RDS、ELBといったVPC内リソースが想定以上に拡張していくケースにも対応できます。また、あらかじめ作成時に巨大なCIDRを確保する、といったことも必要なくなることでしょう。 VPC CIDRの拡張 VPC作成時に割り当てるCIDRブロックがプライマリCIDRとなり、あとからセカンダリCIDRを追加可能になりました。 Associating a Secondary IPv4 CIDR B

本日のアップデートでインターフェース型の S3 VPC エンドポイント（PrivateLink）が GA になりました！ Amazon S3 now supports AWS PrivateLink S3 の PrivateLink については re:Invent 2020 まもなくリリース予定とアナウンスされていましたが遂に来ましたね！ PrivateLink for S3 インターフェース型とゲートウェイ型 今回のアップデートで S3 VPC エンドポイントは唯一、ゲートウェイ型とインターフェース型、両方の VPC エンドポイントを持つサービスとなりました。簡単に各タイプの特徴を説明すると、以下のとおりです。 ゲートウェイ型 エンドポイント料金は無料 対応しているサービスは S3 と DynamoDB のみ エンドポイントへの名前解決はグローバル IP のまま（ルートテーブルにより、V

Amazon EC2 Auto Scalingを利用すると、需要に合わせてEC2の台数を増減できます。 これにより、コストとパフォーマンスのバランスをとれます。 Auto Scalingは素晴らしい機能ですが、よく理解して利用する必要があります。 Auto Scalingの基本的な内容と、マスターEC2を使ったAuto Scalingの運用方法をご紹介します。 Auto Scalingを構成する要素 Auto Scaling グループ Auto Scaling グループは、Auto Scalingの管理単位です。 グループを作成する際に、EC2の最小数、最大数、希望する数を指定します。 EC2の最小数と最大数の間で、インスタンス数が増減または維持されます。 ヘルスチェックのタイプ Auto Scalingは起動したインスタンスに対して、定期的なヘルスチェックを実行します。 インスタンスが正

渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。

こんにちは！おおはしりきたけです！ 10月13日(水)に豆蔵さんで行われた豆ナイトのCI（継続的インテグレーション）超入門：Jenkinsのススメ」に参加してきました！ イベントURL：http://kokucheese.com/event/index/18660/ ＝＝＝　アジェンダ　＝＝＝＝ １．はじめに ２．「ビルドを料理するコツ ３．「CI超入門：Jenkinsのススメ」 ４．「CIツールの紹介」 ５．「ディスカッション」 19時開始だったのですが、若干遅刻してしまったため、一部聞けませんでしたorz。 １．はじめに 豆蔵の羽生田栄一さんからのお話でしたが、遅刻のため聞けませんでした。 ２．「ビルドを料理するコツ ここの途中から参加したので、一部足りないです。 概要：ソフトウェアのビルドに関する基本的な知識を導入します。 発表者：Microsoft Office Linguisti