Lambda Managed Instancesの実行環境と通常のLambda実行環境と差異があるのかOSコマンドで確認してみた
Lambda利用者からは意識する必要は無いですが、Lambda Managed Instancesと通常のLambdaはFirecrackerの利用有無による微妙な違いがありそうです。
2025.12.01
リテールアプリ共創部@大阪の岩田です。
本日のアップデートでLambda Managed Instancesがリリースされました。
このコンピューティングタイプは通常のLambdaとは異なり、セキュリティ境界にFirecrackerを利用していないことがドキュメントに記載されています。
Lambda (default) compute type is multi-tenant, making use of Firecracker microVM technology to provide isolation between execution environments running on shared Lambda fleets. Lambda Managed Instances run in your account, providing the latest EC2 hardware and pricing options. Managed Instances use containers running on EC2 Nitro instances to provide isolation rather than Firecracker. Capacity providers serve as the security boundary for Lambda functions. Functions execute in containers within instances.
ということはLambda実行環境から見えるOSの情報も通常のLambdaとは異なるのでは？と疑問に思ったので、Lambda FunctionのコードからいくつかのOSコマンドを実行し、Lambda Managed Instances環境と通常のLambda環境それぞれで比較してみました。
環境
今回検証に利用したランタイムは以下の通りです。通常のLambda、Lambda Managed Instancesいずれも本日時点でNode.js 24.xを選択すると以下のランタイムバージョン、ARNでした
- runtimeVersion:
nodejs:24.v25 - runtimeVersionArn:
arn:aws:lambda:us-east-1::runtime:9789c897924b8267853973afab7f065eaf98a441d27aa14bb62b2560df1ea5a0
OSコマンドの実行結果比較
ここからコマンドの実行結果を列挙していきます。
whoami
まずは定番whoamiです。実行結果はsbx_user1051で、特に通常のLambdaとの違いは見当たりませんでした。
ls /
ls /の実行結果からは特に通常のLambdaとの違いは見当たりませんでした。
total 180
drwxr-xr-x. 1 root root 4096 Dec 1 07:48 .
drwxr-xr-x. 1 root root 4096 Dec 1 07:48 ..
-rw-r--r--. 1 root root 104462 Nov 17 23:09 THIRD-PARTY-LICENSES.txt
lrwxrwxrwx. 1 root root 7 Jan 30 2023 bin -> usr/bin
dr-xr-xr-x. 2 root root 4096 Jan 30 2023 boot
drwxr-xr-x. 5 root root 340 Dec 1 07:48 dev
drwxr-xr-x. 34 root root 4096 Oct 15 11:27 etc
drwxr-xr-x. 2 root root 4096 Jan 30 2023 home
-rwxr-xr-x. 1 root root 397 Nov 12 17:49 lambda-entrypoint.sh
lrwxrwxrwx. 1 root root 7 Jan 30 2023 lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Jan 30 2023 lib64 -> usr/lib64
drwxr-xr-x. 2 root root 4096 Sep 24 07:51 local
drwxr-xr-x. 2 root root 4096 Jan 30 2023 media
drwxr-xr-x. 2 root root 40 Dec 1 07:48 mnt
drwxr-xr-x. 2 root root 4096 Jan 30 2023 opt
dr-xr-xr-x. 162 root root 0 Dec 1 07:48 proc
dr-xr-x---. 2 root root 4096 Jan 30 2023 root
drwxr-xr-x. 1 root root 4096 Dec 1 07:48 run
lrwxrwxrwx. 1 root root 8 Jan 30 2023 sbin -> usr/sbin
drwxr-xr-x. 2 root root 4096 Jan 30 2023 srv
dr-xr-xr-x. 13 root root 0 Dec 1 07:47 sys
drwxrwxrwt. 2 root root 4096 Dec 1 07:48 tmp
drwxr-xr-x. 1 root root 4096 Nov 5 20:39 usr
drwxr-xr-x. 1 root root 4096 Dec 1 07:48 var
uname -a
続いてuname -aです。
Linux 28fdc418-6c89-42e0-a020-804c0b786ca6 6.1.158 #1 SMP PREEMPT_DYNAMIC Thu Nov 13 02:29:31 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
注目したいのは28fdc...の部分で通常のLambdaであればLinux 169.254.5.207 5.10.245-269.978.amzn2.x86_64 #1 SMP Fri Oct 31 17:22:38 UTC 2025 x86_64 x86_64 x86_64 GNU/Linuxのようにホスト名が169.254...のようなIPアドレスになります。
Lambda Managed Instancesの場合はUUIDv4でホスト名を生成しているようですね。
cat /etc/os-release
cat /etc/os-releaseの実行結果は特に通常のLambdaとの違いが見当たりませんでした。
NAME="Amazon Linux"
VERSION="2023"
ID="amzn"
ID_LIKE="fedora"
VERSION_ID="2023"
PLATFORM_ID="platform:al2023"
PRETTY_NAME="Amazon Linux 2023.9.20250929"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2023"
HOME_URL="https://aws.amazon.com/linux/amazon-linux-2023/"
DOCUMENTATION_URL="https://docs.aws.amazon.com/linux/"
SUPPORT_URL="https://aws.amazon.com/premiumsupport/"
BUG_REPORT_URL="https://github.com/amazonlinux/amazon-linux-2023"
VENDOR_NAME="AWS"
VENDOR_URL="https://aws.amazon.com/"
SUPPORT_END="2029-06-30"
VARIANT_ID="202510141653-f62b5dd0-e052-4842-a6a7-97957a776441"
ls /bin | sort
続いてls /bin | sort
特に通常のLambdaとの違いは見当たりませんでした。
alias
arch
awk
b2sum
base32
base64
basename
basenc
bash
bashbug
bashbug-64
bg
ca-legacy
cat
catchsegv
cd
chcon
chgrp
chmod
chown
cksum
comm
command
coreutils
cp
csplit
curl
cut
date
dd
df
dir
dircolors
dirname
dnf
du
echo
egrep
env
expand
expr
factor
false
fc
fg
fgrep
fmt
fold
gapplication
gawk
gdbus
gencat
getconf
getent
getopts
gio
gio-querymodules-64
glib-compile-schemas
gpg
gpg-error
gpg2
gpgme-json
gpgv2
grep
groups
gsettings
hash
head
hostid
iconv
id
install
jobs
join
ld.so
ldd
link
ln
locale
localedef
logname
ls
make-dummy-cert
md5sum
microdnf
mkdir
mkfifo
mknod
mktemp
modulemd-validator
mv
nice
nl
nohup
nproc
numfmt
od
openssl
p11-kit
paste
pathchk
pinky
pldd
pr
printenv
printf
ptx
pwd
read
readlink
realpath
renew-dummy-cert
rm
rmdir
rpm
rpm2archive
rpm2cpio
rpmdb
rpmkeys
rpmquery
rpmverify
runcon
sed
seq
sh
sha1sum
sha224sum
sha256sum
sha384sum
sha512sum
shred
shuf
sleep
sort
sotruss
split
sprof
stat
stdbuf
stty
sum
sync
tac
tail
tee
test
timeout
touch
tr
true
truncate
trust
tsort
tty
type
tzselect
ulimit
umask
unalias
uname
unexpand
uniq
unlink
update-ca-trust
users
vdir
wait
wc
wcurl
who
whoami
xmlcatalog
xmllint
yes
zdump
ls /sbin | sort
同様にls /sbin | sort
こちらも特に通常のLambdaとの違いは見当たりませんでした。
alternatives
capsh
chroot
getcap
getpcaps
iconvconfig
ldconfig
setcap
update-alternatives
zic
df -h
df -hの出力は以下の通りでした。
Filesystem Size Used Avail Use% Mounted on
overlay 20G 619M 20G 4% /
/dev/loop2 519M 8.0K 507M 1% /tmp
tmpfs 64M 0 64M 0% /dev
shm 64M 0 64M 0% /dev/shm
/dev/root 663M 386M 265M 60% /var/rapid/init
tmpfs 3.8G 428K 3.8G 1% /etc/resolv.conf
/dev/nvme1n1p1 20G 619M 20G 4% /etc/hosts
tmpfs 1.6G 360K 1.6G 1% /run/rapid
tmpfs 3.8G 36K 3.8G 1% /mnt
tmpfs 3.8G 0 3.8G 0% /proc/acpi
tmpfs 3.8G 0 3.8G 0% /sys/firmware
tmpfs 3.8G 0 3.8G 0% /proc/scsi
tmpfsの出力が多いですね。通常のLambdaの場合は以下です。
Filesystem Size Used Avail Use% Mounted on
/var/rootfs/operator/runtime 129G 126G 0 100% /
/dev/vdb 1.5G 2.4M 1.4G 1% /etc/hosts
tmpfs 64M 0 64M 0% /dev
/dev/vdd 525M 8.0K 514M 1% /tmp
/dev/root 9.7G 471M 9.3G 5% /etc/passwd
/dev/vdc 128K 128K 0 100% /var/task
こうしてみると結構違いがありますね。ようやく通常のLambdaと分かりやすい差異が出てくれました！！
cat /etc/mtab
Lambda Managed Instances、通常のLambda共に特に何も出力されませんでした。
cat /proc/mounts
cat /proc/mountsの出力はこちら
overlay / overlay ro,seclabel,relatime,lowerdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/9/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/8/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/7/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/6/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/5/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/4/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/3/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/2/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/1/fs,upperdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/10/fs,workdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/10/work 0 0
/dev/loop2 /tmp ext4 rw,seclabel,relatime 0 0
proc /proc proc rw,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,size=65536k,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
mqueue /dev/mqueue mqueue rw,seclabel,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs ro,seclabel,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup cgroup2 ro,seclabel,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
/dev/root /var/rapid/init ext4 ro,seclabel,relatime,stripe=1024 0 0
tmpfs /etc/resolv.conf tmpfs ro,context=system_u:object_r:etc_t:s0,noatime,mode=755 0 0
/dev/root /etc/passwd ext4 ro,seclabel,relatime,stripe=1024 0 0
/dev/nvme1n1p1 /etc/hosts ext4 ro,seclabel,noatime,mb_optimize_scan=0 0 0
tmpfs /run/telemetry tmpfs rw,seclabel,size=1579056k,nr_inodes=819200,mode=755 0 0
tmpfs /run/rapid tmpfs rw,seclabel,size=1579056k,nr_inodes=819200,mode=755 0 0
tmpfs /mnt tmpfs ro,seclabel,size=3947636k,nr_inodes=1048576 0 0
proc /proc/bus proc ro,relatime 0 0
proc /proc/fs proc ro,relatime 0 0
proc /proc/irq proc ro,relatime 0 0
proc /proc/sys proc ro,relatime 0 0
proc /proc/sysrq-trigger proc ro,relatime 0 0
tmpfs /proc/acpi tmpfs ro,seclabel,relatime 0 0
tmpfs /proc/kcore tmpfs rw,seclabel,nosuid,size=65536k,mode=755 0 0
tmpfs /proc/keys tmpfs rw,seclabel,nosuid,size=65536k,mode=755 0 0
tmpfs /proc/latency_stats tmpfs rw,seclabel,nosuid,size=65536k,mode=755 0 0
tmpfs /proc/timer_list tmpfs rw,seclabel,nosuid,size=65536k,mode=755 0 0
tmpfs /sys/firmware tmpfs ro,seclabel,relatime 0 0
tmpfs /proc/scsi tmpfs ro,seclabel,relatime 0 0
先程と同様tmpfs関連の出力が多いですね。あとはcontainerd.snapshotter.v1.overlayfs/snapshotsから始まる出力も気になります。
通常のLambdaの場合は以下です。
/var/rootfs/operator/runtime / overlay ro,nosuid,nodev,relatime,lowerdir=/tmp/es662515619/9bac654037413555:/tmp/es662515619/57239a3592814584 0 0
/dev/vdb /etc/hosts ext4 ro,noatime,data=writeback 0 0
tmpfs /dev tmpfs rw,nosuid,noexec,relatime,size=65536k,mode=755 0 0
/dev/vdd /tmp ext4 rw,relatime,data=writeback 0 0
/dev/root /etc/passwd ext4 ro,relatime 0 0
/dev/vdb /etc/resolv.conf ext4 rw,noatime,data=writeback 0 0
/dev/vdc /var/task squashfs ro,nosuid,nodev,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
cat /proc/cgroups
cat /proc/cgroupsの結果はこちら
#subsys_name hierarchy num_cgroups enabled
cpuset 0 97 1
cpu 0 97 1
cpuacct 0 97 1
blkio 0 97 1
memory 0 97 1
devices 0 97 1
freezer 0 97 1
net_cls 0 97 1
perf_event 0 97 1
net_prio 0 97 1
hugetlb 0 97 1
pids 0 97 1
misc 0 97 1
ちなみに通常のLambdaの場合はこちらです。
#subsys_name hierarchy num_cgroups enabled
cpuset 5 1 1
cpu 2 37 1
cpuacct 2 37 1
blkio 10 34 1
memory 7 48 1
devices 11 34 1
freezer 4 4 1
net_cls 3 1 1
perf_event 9 1 1
net_prio 3 1 1
hugetlb 8 1 1
pids 6 34 1
hierarchyの出力から察するに、利用しているcgroupsのバージョンがv1かv2という違いがあるようです。
cat /proc/devices
cat /proc/devicesの結果はこちらです。
Character devices:
1 mem
4 /dev/vc/0
4 tty
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
29 fb
128 ptm
136 pts
202 cpu/msr
203 cpu/cpuid
226 drm
244 hidraw
245 nvme-generic
246 nvme
247 megaraid_sas_ioctl
248 bsg
249 watchdog
250 ptp
251 pps
252 rtc
253 dax
254 tpm
Block devices:
7 loop
8 sd
9 md
65 sd
66 sd
67 sd
68 sd
69 sd
70 sd
71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
252 device-mapper
253 virtblk
254 mdp
259 blkext
通常のLambdaの場合は以下なので、だいぶデバイスが多いように見えますね。
Character devices:
1 mem
4 /dev/vc/0
4 tty
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
128 ptm
136 pts
202 cpu/msr
203 cpu/cpuid
250 hidraw
251 bsg
252 watchdog
253 ptp
254 pps
Block devices:
7 loop
254 virtblk
259 blkext
cat /proc/filesystems
cat /proc/filesystemsの出力は以下の通りでした。
nodev sysfs
nodev tmpfs
nodev bdev
nodev proc
nodev cgroup
nodev cgroup2
nodev cpuset
nodev devtmpfs
nodev debugfs
nodev tracefs
nodev securityfs
nodev sockfs
nodev bpf
nodev pipefs
nodev ramfs
nodev hugetlbfs
nodev devpts
ext3
ext2
ext4
nodev autofs
xfs
erofs
nodev mqueue
nodev selinuxfs
nodev pstore
nodev efivarfs
nodev configfs
nodev binfmt_misc
fuseblk
nodev fuse
nodev fusectl
nodev overlay
squashfs
通常のLambdaの場合はこちら
nodev sysfs
nodev tmpfs
nodev bdev
nodev proc
nodev cgroup
nodev cgroup2
nodev cpuset
nodev devtmpfs
nodev binfmt_misc
nodev debugfs
nodev securityfs
nodev sockfs
nodev bpf
nodev pipefs
nodev ramfs
nodev hugetlbfs
nodev rpc_pipefs
nodev devpts
ext3
ext2
ext4
squashfs
nodev nfs
nodev nfs4
nodev autofs
nodev overlay
xfs
nodev mqueue
nodev pstore
selinuxfsの有無あたりが差分としては面白そうです。
まとめ
基本的にはLambda Managed Instancesでも通常のLambda環境と同じような結果でしたが、ハードウェア寄りの部分になってくると出力結果が微妙に異なっていました。
FirecrackerはFaaS環境向けに最適化されたVMMであり、デバイスエミュレーションは必要最低限に限定されているため、ある程度汎用的に設計されたEC2と違いが出るのは納得ですね。
なお、余談なのですがLambda Managed Instancesの場合はなぜかrpmコマンドを実行すると結果が返ってこずにLambda Functionがタイムアウトするという謎の現象が発生していました。原因が想像つかなかったのですが、これは何故なんでしょうね？
