2026-10-18

AWS Direct Connect と VPC を接続する構成

暑さもだいぶ和らいできたので、久しぶりに鶴舞公園で遊びました。
が、水遊び場はポンプ故障のため入れず（代わりに枝でぱちゃぱちゃしました。）、滑り台の付いた遊具も利用禁止になっていて不満げでした。
また行きたいです。

AWS Direct Connect でオンプレと AWS を専用線で接続できる、ぐらいしか知らず、具体的にどういう構成でつなぐのが理解していなかったため、メモです。
ただし、今回は VPC に接続するケースのみです。

AWS のパブリックサービス（S3とか）に接続する場合は少し違うようなので割愛。

全体構成

以下の3構成がありそう。

1. オンプレと1つの VPC を接続するケース

オンプレミス → Direct Connect → Private VIF → VGW → VPC

2. オンプレと複数の VPC を接続するケース①

オンプレミス
    │
Direct Connect
    │
Private VIF
    │
Direct Connect Gateway
 ┌──┴────┐
VGW     VGW
 │       │
VPC-A   VPC-B

3. オンプレと複数の VPC を接続するケース②

オンプレミス
    │
Direct Connect
    │
Transit VIF
    │
Direct Connect Gateway (DXGW)
    │
Transit Gateway
 ┌──┼──┐
VPC VPC VPC

Private VIF

A virtual interface is the VLAN that transports Direct Connect traffic.

CreatePrivateVirtualInterface - Direct Connect

「物理的な Direct Connect 回線の上に作る、論理的な接続口」らしい。
「VLAN」とのことなので、仮想的なネットワークという理解でも良さそう。（上の構成図とイメージが少し違うかもしれない。）

Private という名前の通り、VPC 内のプライベートIPアドレス宛ての通信を可能とします。

VGW または DXGW に接続するために使用できます。

作り方

コンソールで作成する場合はこちら。

APIで作成する場合は上記のAPIリファレンスを参考にできます。

connectionId属性で、Direct Connect を指定します。（多分）
そして、VGW に接続する場合は、virtualGatewayId属性で指定します。
DXGW に接続する場合は、directConnectGatewayId属性で指定します。

VGW

Virtual Private Gateway。
AWS 内に作成するネットワークゲートウェイらしい。
（略称が VPG ではないのはなぜなんだろう。）

VPC にアタッチします。
なお、VPC からオンプレミスに通信するときは、オンプレミス宛ての通信を VGW に向けるルートがルートテーブルに必要です。これは、自動的に設定されるらしい。
（違うかも。要出典。）

DXGW

Direct Connect と複数の VGW （すなわち複数の VPC）を接続できます。

しかも、グローバルサービスなので、複数リージョンの VGW と接続できます。
ということは、Direct Connect を1本用意して、複数リージョンの VPC とオンプレを接続できます。

また、Transit Gateway も接続できます。

Transit VIF

Direct Connect が、DXGW を経由して Transit Gateway に接続するためには、Transit VIF が代わりに必要。（Private VIFではない。）

Transit Gateway

VPC をたくさん接続して相互に通信できる。
なお、リージョンサービスなので、同じリージョンの VPC のみ接続できる。
もし、リージョンをまたいで VPC 間の接続を行いたい場合は、Transit Gateway 同士をピアリング接続するとのこと。

AWS Transit Gateway の Transit Gateway ピアリングアタッチメント - Amazon VPC

2026-09-17

EC2 AutoScaling のライフサイクルフック

この前の土曜日は初めてのボウリング大会、日曜日は七五三の前撮りに行きました。どちらもご機嫌さんでした。

EC2 AutoScaling の「ライフサイクルフック」機能のメモです。

何できる？

AutoScaling により EC2 を起動・終了する際に、EventBridge, SNS, SQS, Lambda が呼び出せます。

呼び出されるタイミング

起動開始から起動完了まで、EC2 のステータスは以下のように遷移します。
Pending -> Pending:Wait -> Pending:Proceed -> InService

起動時のライフサイクルフックが指定されていると、Pending:Waitで停止して処理が呼び出されます。
終了時も似ており、Terminating:Waitという状態で一旦停止して処理が呼ばれます。

そして、呼び出し側から処理終了の合図がAutoScalingに届くと、ライフサイクルフックを終了させて次のステータスに進むそうです。

Auto Scaling グループでのライフサイクルフックの仕組み - Amazon EC2 Auto Scaling

処理終了の合図は誰がどう出す？

処理を行う側が出します。CompleteLifecycleActionAPIを使うそうです。

Auto Scaling グループでライフサイクルアクションを完了する - Amazon EC2 Auto Scaling

EventBridgeを呼び出す

AWS推奨はこちら。

コンソールやAWS CLIの～コマンドで「ライフサイクルフック」を作成する。
EC2インスタンスの起動直前や終了直前にEventBridgeにイベントが送信されて、好きな処理を起動できる。この途中、EC2インスタンスのステータスとしてはXXで止まる。
処理の中で最後に～コマンドを実行することで、ステータスがXXからYYに移行して、スケーリング処理が再開する。

AWS CLIであれば、--notification-target-arnオプションにARNを指定することで実現できます。

Add lifecycle hooks to your Auto Scaling group - Amazon EC2 Auto Scaling

こちらの記事を拝見すると、コンソールでも設定できるらしいです。 EC2 Auto Scaling のライフサイクルフック通知が Lambda 関数へ直接ルーティング可能になっていたので試してみた | DevelopersIO

CloudFormation でライフサイクルフック作成

AWS::AutoScaling::LifecycleHook を使いましょう

AWS::AutoScaling::LifecycleHook - AWS CloudFormation

SNS、SQS（たぶんLambdaも）を起動したいときは、NotificationTargetARNにそのARNを指定するようです。

2026-08-16

S3 GetObject でストリーミング処理できる

お友達からプレゼントされたマイメロディの櫛で床屋さんごっこをしてくれました。

S3 から GetObject でオブジェクトを取得する際、一度にデータ全部を取得ももちろんできるけど、データを少しずつ取得もできると知りました。のでそれだけのメモ。

boto3

get_objectのページを見ると、Response Structure に以下の通り記載されています。

Body (StreamingBody)

get_object - Boto3 1.43.72 documentation

そしてこのStreamingBodyとは、以下のことのようです。

Response Reference - botocore 1.43.72 documentation

具体的には、get_objectを以下のように使って、例えばCSVデータを少しずつ処理できるらしい。

import boto3

s3 = boto3.client('s3')

response = s3.get_object(Bucket='sample-bucket-name', Key='sample-file.csv')

# 1行ずつストリーミング処理する例
for line in response['Body'].iter_lines():
    print(line.decode('utf-8'))

2026-07-21

キャッシュ戦略

今日は友達家族の家に遊びに行きました。子どもたちは楽しく遊んでいました。

AWS ElastiCache を勉強しようと思いましたが、そもそもキャッシュ戦略を理解していなかったのでメモ。

そもそもキャッシュ戦略って何？

キャッシュにいつデータを保存して、いつ更新・削除するかを決めるルール

種類

一般的に、以下のキャッシュ戦略がある。
つまり、読み込み時と書き込み時で方針がいくつかあり、組み合わせる必要がある。

読み込み時の戦略

アプリが DB からデータを取得する（読み込む）ときにキャッシュにデータを保存するケース。

Cache Aside (Lazy Loading)
Read Through

書き込み時の戦略

アプリが DB にデータを作成・更新・削除する（書き込む）ときにキャッシュのデータもそろえるケース。

Write Through
Write Behind (Write Back / Lazy Write)
Write Around
Refresh Ahead

Cache Aside (Lazy Loading)

アプリはまずキャッシュにアクセス。
キャッシュに欲しいデータが無ければ、アプリは DB から取得して、さらにキャッシュにも保存。

Cache-Aside パターン - Azure Architecture Center | Microsoft Learn

Read Through

アプリはキャッシュだけを参照して、キャッシュが DB からデータを自動で取得。

What is Read-Through vs Write-Through Cache?

Read-Through vs Write-Through Cache - by Stephane Moreau

Write Through

アプリが DB のデータを更新するときに、キャッシュも同時に更新する。
ざっとググると、アプリがキャッシュだけにアクセスする例もあれば、キャッシュとDB両方にアクセスする例も見られた。

What is Read-Through vs Write-Through Cache?

Database caching: Overview, types, strategies and their benefits.

Write Behind (Write Back / Lazy Write)

アプリはまずキャッシュのデータを更新して、後から DB へ非同期で反映する。

Database caching: Overview, types, strategies and their benefits.

Write Around

アプリは DB のデータを更新する。

※え、じゃあキャッシュへのデータ保存はいつ？
→「参照時にキャッシュになければ DB からデータを保存する」としている記事がいくつかあり、つまり Cache Aside との併用が前提なのかなと思いました。

Write-through, write-around, write-back: cache explained | Computer Weekly

Caching Strategy: Write-Around Pattern

Refresh Ahead

キャッシュ期限前にバックグラウンドのジョブなどで更新する。
つまり、キャッシュミスを極力避けたい場合の戦略。

※キャッシュへの初回データ保存は、たぶん他の戦略と組み合わせるんだと思う。

Caching Strategy: Refresh Ahead Pattern

その他のとても参考になる記事

soudai.hatenablog.com

2026-07-04

S3 アクセスポイント

今日は曇りだったので公園で遊びました。ボールを追いかけたり山登りしたりしました。お昼寝もちゃんとできました。

S3 バケットポリシー

普通、 S3 バケットへのアクセス制御は、バケットポリシーで行う。
しかし、同じ S3 バケットをいろんなユーザーやアプリで使う場合、バケットポリシーが複雑になってしまう。

S3 アクセスポイントは、S3 オブジェクトにアクセスするための新しい入り口。
この入口には、アクセスポイントポリシーを定義して、アクセス制御が行える。
（バケットポリシーと同じように、誰がどのオブジェクトにどんな操作をできるかを定義できる。）

この入口を、ユーザーやアプリごとに用意することで、入り口を個別に用意できる。
その結果、バケットポリシーが複雑になってしまうのを回避できる。

docs.aws.amazon.com

アクセスポイントポリシー

アカウント 123456789012 の IAM ユーザー Suzukiに、
アカウント 123456789012 のアクセスポイント my-access-point を介して、
プレフィックスが Suzuki/ であるオブジェクトを、
GET および PUT するアクセス許可を付与する例。

{
    "Version":"2012-10-17",
    "Statement": [
    {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::123456789012:user/Suzuki"
        },
        "Action": ["s3:GetObject", "s3:PutObject"],
        "Resource": "arn:aws:s3:ap-northeast-1:123456789012:accesspoint/my-access-point/object/Suzuki/*"
    }]
}

ここで注意なのが、バケットポリシー側では以下のいずれかのアクセス制御を行う必要がある。

アクセスポイント経由でアクセスすることを許可（推奨）
アクセスポイントポリシーと同じアクセス許可

docs.aws.amazon.com

VPC 限定版とインターネット版

S3 アクセスポイントには、VPC 限定版とインターネット版があり、作成時に選択する。

VPC 限定版の場合は、特定の VPC のみからアクセスできる。
インターネット版の場合は、インターネット経由でアクセスできる。

ここで注意なのが、VPC 限定版の場合、以下のようにアクセスする。

EC2
Lambda
ECS
  │
  ▼
VPC Endpoint
  │
  ▼
VPC Access Point
  │
  ▼
S3 Bucket

つまり、VPC エンドポイントを先に通る。ということは、VPC エンドポイントポリシーでもこの経路を許可する必要がある。具体的には、

アクセスポイントおよび基となるバケットの両方へのアクセスを許可

Virtual Private Cloud に制限されたアクセスポイントの作成 - Amazon Simple Storage Service

アクセスポイントへのアクセスだけでなく、バケットへのアクセスも、エンドポイントポリシー上では許可する必要があるようです。

ブロックパブリックアクセス設定はどうする？

ブロックパブリックアクセス設定はオンで問題なさそう。

注意点

オブジェクト操作のみ対応。
バケット作成・削除などの管理操作には利用できない。

2026-06-23

S3 へのアクセス権

この前の日曜日に近くの川に水遊びをしてきました。とても楽しそうでした。

S3 へのアクセス権制御の仕組みがあやふやすぎたので調べました。
アイデンティティーベースのポリシー（IAM）とリソースベースのポリシー（バケットポリシー）が対象です。

2つを合わせた評価ロジック

いずれか一方で Deny なら、アクセス拒否
両方で Allow、もしくは片方で Allow （もう一方は Allow も Deny も明示なし）なら、アクセス許可

アクションがアイデンティティのポリシーかリソースベースのポリシー、または両方で許可されている場合、AWS はそのアクションを許可します。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。

docs.aws.amazon.com

Allow も Deny も明示なし、の扱い

暗黙的な拒否 というそうです。
デフォルトのバケットポリシー（= 何も書かれていない）場合は、バケットポリシー単体では暗黙的な拒否、すなわちアクセス拒否されます。
（ここでもしIAMポリシーで Allow なら、上に記載の通り、アクセス許可されます。）

docs.aws.amazon.com

知らなかった…

以下のようなバケットポリシーのみを設定しているとします。このポリシー単体としては、vpce-yyyyy からのアクセスは拒否されますか？
↓
明示的な拒否ではないが、暗黙的な拒否になる。
もし IAM ポリシーで許可されている場合、vpce-yyyyy からのアクセスは許可される。
もっと言うと、IAM ポリシーで許可されているなら、インターネット経由でのアクセスもできてしまう。（な、なんだってー！）

{
  "Effect": "Allow", 
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ],
  "Condition": {
    "StringEquals": { 
      "aws:SourceVpce": "vpce-xxxxxxxx"
    }
  }
}

ではアクセス制御は Deny で考えるのが良い？

ように思えるけど、設定を誤ると誰もアクセスできないゾンビバケットになるらしい。

techblog.nhn-techorus.com

なので、注意してつけるべきみたい。

アクセス制御が正しく設定できているか不安になる…

こんなときに、チェックできるのが IAM Access Analyzer for S3 らしい！！！

docs.aws.amazon.com

とても参考になる他の記事

S3の権限まわりの話 - サーバーワークスエンジニアブログ

AWS S3のセキュリティ早見表：IAM、バケットポリシー、ACL | SkygateBlog

S3の権限をマトリックスで整理する（IAM、バケットポリシー、ブロックパブリックアクセス、ACL、静的ウェブサイトホスティング） #AWS - Qiita

2026-06-15

AWS ALB のノードやら ENI やら

AWS

昨日今日とサンリオピューロランドに行ってきました。パチンコやってるバッドばつ丸見れて最高でした。

AWS ALB の実体が理解できず調べました。が、結局理解できていないですが、見たサイトだけでもメモします

Load Balancer Node が登場

ELBは複数のノードで構成される。AZに⼀つ以上ノードがあり、ノードごとにIP アドレスを持つ...。ELBの FQDNを名前解決すると、複数のAレコードが返却される。

なるほど、AZにノードが用意されてしかもIPアドレスを持つと。
他ページでも同じようなことに言及。

ELBの名前解決を⾏うと、複数のAレコードが返る。それぞれのIPアドレスは、ELBのノードを⽰しており、それらはELBをデプロイしたAZのどれかに属している。クロスゾーン負荷分散を有効にすると、AZ Aに属しているノードが、別のAZにトラフィックをルーティングするようになり、全体の負荷をより均等にすることができる。

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Elastic-Load-Balancing_0525_v1.pdf

以下でも同じようなことに言及。

ロードバランサー用のアベイラビリティーゾーンを有効にすると、Elastic Load Balancing はアベイラビリティーゾーンにロードバランサーノードを作成します。

Elastic Load Balancing の仕組み - Elastic Load Balancing

ENI も登場する

Elastic Load Balancing は、ロードバランサーを設定したサブネットにネットワークインターフェイスを作成します。

Application Load Balancer - Elastic Load Balancing

ENI がサブネットに用意されるとのことです。
ENI って IP アドレス持ってますよね。
ということは、前述のノードにこの ENI がアタッチされているということ？

以下の14ページにも、この ENI を経由して配下の EC2 にアクセスしている図があります。

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Elastic-Load-Balancing_0525_v1.pdf

ENI の IP を確認して、さらに増減することに言及した記事がこちら。

Application Load Balancer起動直後のENIを観察してみた | DevelopersIO

結局？？

たぶん ENI はノードに関連付けられている。ALB 宛てのリクエストは ENI の IP アドレスに解決されるので、ノードがこれを受け取り、配下の EC2 たちに割り振るのかな…

全体構成

1. オンプレと1つの VPC を接続するケース

2. オンプレと複数の VPC を接続するケース①

3. オンプレと複数の VPC を接続するケース②

Private VIF

作り方

VGW

DXGW

Transit VIF

Transit Gateway

何できる？

呼び出されるタイミング

処理終了の合図は誰がどう出す？

EventBridgeを呼び出す

SNS や SQS、Lambda を呼び出す

CloudFormation でライフサイクルフック作成

boto3

そもそもキャッシュ戦略って何？

種類

読み込み時の戦略

書き込み時の戦略

Cache Aside (Lazy Loading)

Read Through

Write Through

Write Behind (Write Back / Lazy Write)

Write Around

Refresh Ahead

その他のとても参考になる記事

S3 バケットポリシー

アクセスポイントポリシー

VPC 限定版とインターネット版

ブロックパブリックアクセス設定はどうする？

注意点

2つを合わせた評価ロジック

Allow も Deny も明示なし、の扱い

知らなかった…

ではアクセス制御は Deny で考えるのが良い？

アクセス制御が正しく設定できているか不安になる…

とても参考になる他の記事

Load Balancer Node が登場

ENI も登場する

結局？？