Self-Managed S3 Buckets for Lambda Code: You Finally Own the Artifact

Picture a platform team running a few hundred Lambda functions across a handful of accounts. Every function has several published versions kept around for safe rollbacks. One morning a deploy fails with a quota error, and the culprit isn’t the new function at all. It’s the 75 GB account-level limit on function and layer code storage, quietly filled up by copies of packages you thought lived in your own S3 bucket. If you’ve ever had to explain to a security reviewer why your deployment artifacts also sit in an internal bucket you can’t see, encrypt, or tag, this one is for you.

AWS has added a way to point Lambda at your own S3 bucket and have it read your code from there directly, with no hidden second copy.

What actually changed

There’s a new function configuration setting called S3ObjectStorageMode. It has two values.

The default is COPY, which behaves exactly like Lambda always has. If you don’t set the field at all, you get COPY, so nothing about your existing functions changes on its own.
The new value is REFERENCE. Set it when you create or update a function, and Lambda stops copying your .zip package into its internal storage. Instead it keeps a reference to your S3 object and reads the code from your bucket when it needs it. Your object becomes the one canonical artifact.

The feature works in all AWS standard regions where Lambda is available, and there’s no extra charge for it beyond the normal S3 storage and request costs you’d pay anyway.

How it works, old way and new

Under the old model (now COPY), the flow looks like this: you upload a .zip to your bucket, call CreateFunction or UpdateFunctionCode with the bucket name and object key, and Lambda pulls that artifact into a service-managed bucket. It builds the optimized, runnable version of your function from that internal copy. The catch is that this copy counts against your 75 GB account quota, and you have no say over how it’s stored.

With REFERENCE, that copy step disappears. Lambda records where your object lives and reads it directly. Two things fall out of that. First, your package no longer counts toward the 75 GB limit, because there’s no Lambda-side copy to count. Second, creating and updating functions gets faster, since Lambda skips the copy-into-internal-bucket step. AWS describes this as a faster time to first invoke for new functions and after updates.

Architecture

The diagram below contrasts the two modes and sketches the multi-account pattern that, in my experience, is the real reason to adopt this.

Two modes for S3 buckets of Lambda code.

In a COPY deployment, the artifact exists twice: once in your bucket, once inside Lambda. In REFERENCE mode there’s a single object, and your function holds a pointer to it. Extend that to an organization and the shape gets interesting: put every artifact in one bucket in a central “artifact” or shared-services account, then grant s3:GetObject to each workload account’s Lambda execution role through the bucket policy. Now one bucket is the source of truth for what’s deployed everywhere, with one place to enforce encryption, versioning, and retention.

When to reach for it

CI/CD and artifact management. Your pipeline uploads a package once, and the function references that same object. One set of lifecycle rules and access controls covers everything, and a rollback becomes “point the function at the previous S3 object version.”
Multi-account, multi-team setups. Centralize artifacts in one account, hand out cross-account s3:GetObject via bucket policies, and keep a single inventory of what code runs where.
Disaster recovery. Because you own the bucket, you can turn on Cross-Region Replication (CRR) or Same-Region Replication (SRR), and pair it with S3 Versioning and Object Lock to keep a tamper-resistant archive that survives an accidental delete or a corrupted deploy. See the S3 replication docs and S3 lifecycle examples.
Quota and compliance pressure. If you’re brushing up against 75 GB, or you need your own encryption, access logging, Object Lock, or compliance tags on the artifact, this gives you that control.

When to leave it alone

For plenty of workloads, COPY is fine and simpler. If you aren’t near the quota, don’t need custom encryption or tagging on the artifact, and have no DR requirement on your deployment packages, there’s little reason to change anything. The default exists for a reason.

Security notes

The trade in REFERENCE mode is control for responsibility. You now own the bucket’s posture: its encryption, access policies, lifecycle transitions, and audit trail are yours to configure and to get right.
For cross-account access, you grant s3:GetObject to the calling function’s execution role in the bucket policy.
Versioning plus Object Lock is the combination worth setting up early if you care about a durable, tamper-proof code archive.
The full IAM and bucket-policy details live in the Lambda developer guide.

Pricing

No additional charge for the feature. You pay the standard S3 storage and request costs for the object, which you were largely paying already if your artifacts lived in S3.

Limitations and open questions

It doesn’t state whether REFERENCE needs KMS decrypt permissions beyond s3:GetObject when you use customer-managed encryption (It should), exactly how a referenced object version is pinned for rollback, or what happens to a live function if the referenced object is later deleted or modified. Any latency effect from reading code directly at runtime isn’t discussed either. Confirm these against the Lambda console and the developer guide before you roll it out widely.

Bottom line

This is a small setting with an outsized effect for teams operating at scale. If the 75 GB quota or “we can’t audit that copy” has ever slowed you down, S3ObjectStorageMode: REFERENCE is worth a look. Start on a non-critical function, get your bucket policy and versioning right, and expand from there. Original announcement on the AWS Compute Blog.

Lambda MicroVMs: When Functions Aren’t Enough and EC2 Is Too Much

Leave a reply

Picture this: you’re building a browser-based notebook where data analysts paste in Python, load a 3 GB dataframe, generate a few charts, then wander off to a meeting. Ninety minutes later they come back and expect their kernel, their variables, and their half-finished plot to still be sitting there.

Now try to build that on what AWS gave you before June 2026. Lambda? Fifteen-minute execution ceiling, no persistent process between invocations, no way to hold that dataframe in memory across the analyst’s coffee break. ECS or EC2? Sure, but now you’re running per-user containers or VMs, paying for idle capacity, and writing your own scheduler to reap dead sessions. Fargate gets you closer, but you still own the isolation story when the code being run was generated by an LLM you can’t fully trust.

This is the gap Lambda MicroVMs is aimed at.

What actually launched

AWS Lambda MicroVMs is a new compute primitive that exposes the Firecracker virtualization layer (the same one that has always run underneath Lambda) as something you can address directly. You get per-instance hardware isolation, snapshot-based startup, and — this is the part that matters — the ability to keep a single execution environment alive for an entire working session rather than a single request.

Alongside it, AWS shipped a companion resource called the Lambda Network Connector (LNC), which is how you attach a MicroVM to a private VPC when you need it to reach a database or an internal API.

How it actually works

Two resource types, and once you understand these the rest falls into place:

MicroVM image: a versioned artifact you build from a Dockerfile. When you create one, the service runs your Dockerfile, boots your application inside a MicroVM, and takes a Firecracker snapshot of the memory and disk state. Think of it as a “warm” image — dependencies already imported, JIT already warmed, whatever init your app does already done.
MicroVM: an instance launched from that image. Because it’s restored from a snapshot rather than cold-booted, it comes up close to instantly.

Each MicroVM gets its own HTTPS endpoint, and that endpoint speaks to individual ports on the guest — plain HTTPS, WebSockets, and gRPC all work, so you connect to it the same way you’d connect to any container you were running yourself.

On sizing: the default baseline is 2 GB of memory and 1 vCPU. You can configure that up to 8 GB and 4 vCPUs at launch, with vCPU pinned to memory at a 2:1 ratio (memory in GB is double the vCPU count). From whatever baseline you pick, a MicroVM will auto-scale vertically up to 4x during peak demand. Horizontally, the service claims you can launch several hundred MicroVMs inside a minute.

Sessions can run from a few minutes up to eight hours. Egress to the public internet works out of the box; VPC access requires the LNC.

Architecture

See the diagram below. The pattern is the per-session model: user requests come into your control plane, the control plane looks up whether that user already has a live MicroVM, and either routes traffic to the existing HTTPS endpoint or launches a new instance from a MicroVM image. When the user goes idle, you decide the lifecycle — keep it warm, snapshot it, or let it go.

The interesting design question isn’t really “how do I launch a MicroVM” — it’s “who owns the session-to-endpoint mapping, and what’s my policy when the user disconnects?” You will end up building a small state machine. Plan for it.

When this is the right tool

Browser-based IDEs, notebooks, and the current wave of vibe-coding platforms — anywhere users bring their own code and expect their environment to feel persistent.
Analytics platforms running user- or LLM-generated queries where the working set is large and the session is long.
AI coding assistants that iterate on generated code and want to hold context between iterations, including RL-style loops that spin environments up and down to compare execution paths.
Security and vulnerability scanning where you need real isolation between scans and sometimes elevated OS privileges inside the guest.
CI/CD build and test runners where each job wants a clean, isolated box that starts fast.

When it probably isn’t

The launch material doesn’t call out anti-patterns directly, so treat this as my read rather than AWS’s guidance:

If your workload is stateless per-invocation and short, regular Lambda is still simpler and cheaper reasoning-wise.
If you need more than 8 GB of memory or 4 vCPUs per instance, you’re outside the MicroVM baseline envelope and you should look at Fargate or EC2.
If your sessions genuinely need to outlive eight hours without a snapshot/resume, this isn’t your primitive either.

Security notes worth reading twice

The isolation story is genuinely strong — hardware-level, one guest per user or job, which is the whole point of using Firecracker as a primitive rather than just a container runtime. That’s what makes it defensible as a sandbox for untrusted or model-generated code.

Two things to design around, though.

First, outbound internet access is on by default. If you’re running untrusted code, you almost certainly want egress controls, and the launch material doesn’t spell out how granular those are — treat this as a question to answer before you go to production.
Second, private VPC connectivity is not a checkbox; it requires configuring an LNC. Factor that into your networking design early, not late.

Pricing

Lambda MicroVMs are priced per instance-second. Check the Lambda pricing page (MicroVMs tab) before you commit to a design, especially for long-lived sessions — an eight-hour idle MicroVM has very different economics from a 200 ms function invocation.

Limitations to keep on the whiteboard

2 GB / 1 vCPU baseline, 8 GB / 4 vCPU max, 2:1 memory-to-vCPU ratio.
Vertical auto-scale capped at 4x baseline.
Horizontal scale advertised as “several hundred per minute” during spikes — quantify this against your own burst profile before betting on it.
Sessions in the “few minutes to 8 hours” range; the exact hard upper bound isn’t explicitly stated.
VPC access is opt-in via LNC.

Wrapping up

The most useful way to think about Lambda MicroVMs is that AWS unbundled Firecracker from Lambda’s request/response model and let you address it directly, while keeping the parts of Lambda that were actually pleasant — no capacity planning, no patching, no scheduler to write. If you’ve been building per-user sandboxes on top of ECS or bare EC2 and feeling like you were re-implementing Firecracker badly, this is the primitive to evaluate.

Start with the product page and the developer guide, and if snapshot-based startup is new to you, the older SnapStart post is worth a read for the mental model. Networking details live in the LNC docs, and quotas are on the service limits page. And refer to this AWS Blog which walk you through AWS MicroVms.

Know about Amazon GuardDuty Investigation: AI-powered security analysis

Leave a reply

Security teams routinely burn hours triaging a single GuardDuty finding. The workflow is familiar: pull the finding, pivot into CloudTrail, cross-reference VPC flow logs, chase the principal across accounts, map the behavior to a known technique, and finally decide whether the alert is a real incident or noise. Multiply that across an organization producing dozens or hundreds of findings a day, and investigation backlog becomes the bottleneck — not detection.

Amazon GuardDuty is now addressing that bottleneck directly. The GuardDuty investigation is available in public preview and performs on-demand, AI-powered investigations of GuardDuty findings, returning a structured assessment that a human analyst would otherwise assemble by hand.

What changed

The investigation agent adds a new capability to Amazon GuardDuty: rather than only surfacing findings, GuardDuty can now investigate them for you. Each investigation produces a structured output that includes a risk level, a confidence score, a natural-language summary, investigation details, MITRE ATT&CK technique mappings, resource mappings, and prioritized recommended actions — including specific AWS CLI commands the analyst can execute.

The agent is accessible through the AWS Management Console, the AWS CLI, AWS APIs, AWS SDKs, and the AWS MCP server — meaning it slots into both console-driven workflows and agentic security tooling built on top of the Agent Toolkit for AWS.

How it works

An investigation is initiated by an caller with appropriate permissions through the GuardDuty console, by calling the CreateInvestigation API, or via the AWS CLI. The target can be:

a specific GuardDuty finding
a member account
an entire AWS organization

CLI and API callers can supply a free-form natural-language trigger prompt of up to 2,048 characters to steer the investigation — for example, focusing the agent on a particular hypothesis or scope.

Under the hood, the agent correlates findings and evidence and returns a structured assessment. Results are retrieved with GetInvestigation, and prior investigations can be enumerated with ListInvestigations.

Processing uses cross-Region inference via the Cross-Region Inference Service (CRIS). Investigation data remains stored in the Region where the investigation was created, but inference and summary generation may occur in another Region within the same geography, transmitted over Amazon’s encrypted network.

Please go through this very detailed AWS blog that walks you through the whole investigation process – Amazon GuardDuty investigation agent: on-demand AI-powered threat assessment.

Architecture

The accompanying diagram shows the request flow: an administrator triggers an investigation from the console, CLI, SDK, API, or an MCP-connected agent; GuardDuty accepts the request in the origin Region; CRIS performs inference in-geography; and the structured assessment is returned to the caller while the underlying investigation data stays resident in the origin Region.

When to use it

The investigation agent fits naturally when you want to:

Triage a single GuardDuty finding without a manual pivot chase
Assess security posture across an entire AWS organization
Reduce manual correlation of evidence spread across CloudTrail, VPC flow logs, and other GuardDuty data sources
Wire GuardDuty investigations into AI-assisted security workflows through the AWS MCP server
Produce on-demand, structured threat assessments consumable by downstream automation

When not to use it

The agent is not the right tool if:

GuardDuty is not enabled in the account or organization
You are operating in a Region that does not support the preview
You need a member account to view another member’s or the administrator’s investigations, which is not permitted

Security considerations

Architecturally, three points matter for a review.

First, cross-Region inference. Investigation data is stored only in the origin Region, but processing and summary results may traverse another Region in the same geography. If your data-residency posture is scoped to a single Region rather than a geography, this is worth an explicit review before enabling the feature in regulated workloads. Please refer geography and their inference regions here.

Second, transport. Data moves across Amazon’s internal, encrypted network — but the residency point above still stands independently of encryption in transit.

Third, authorization. Investigations honor the existing GuardDuty authorization model. Callers can investigate only accounts they are already authorized to access. The three IAM actions to allow on principals that will drive investigations are:

guardduty:CreateInvestigation
guardduty:GetInvestigation
guardduty:ListInvestigations

Scope these on the administrator account role that runs the SOC’s investigation workflow, not broadly.

Pricing

In Preview mode, GuardDuty Investigations are made available at free of cost. Confirm current pricing in the GuardDuty product page before enabling at scale once its GA.

Limitations

The feature is in public preview.
GuardDuty must already be enabled, the account must be in a supported Region, and only administrator accounts can create investigations in admin as well as member accounts.
Member accounts cannot access investigations belonging to peer members or to the administrator.
Cross-Region inference behavior described above also applies.
During preview, 10 investigations/account/day with total limit of 100 investigations/account.Failed investigations do not count toward these quotas.
This feature is available only in the following 10 commercial AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), and Asia Pacific (Tokyo).
The trigger prompt is capped at 2,048 characters when invoked through API/CLI.

Verify latest limitations against the GuardDuty investigation documentation before committing to a design.

Conclusion

The investigation agent shifts GuardDuty from a detection surface to a triage surface. For teams whose incident response cost is dominated by evidence correlation rather than detection, that is the interesting move. Preview status means the mechanics — Regions, quotas, latency, retention — need to be validated against your environment before it lands in a runbook, but the shape of the workflow is clear enough to start piloting against a defined scope, most sensibly a single administrator account or a bounded set of high-signal findings. Details and getting-started guidance are on the AWS Security Blog and in the GuardDuty documentation.

Migrating from Amazon Linux 2 to Bottlerocket AMI in EKS Nodes

Leave a reply

In this post, I share my journey transitioning from Amazon Linux 2 to Bottlerocket as the EKS node OS, aiming for enhanced security with a hardened OS image.

In my envionment, running Kubernetes workloads on Amazon EKS with Amazon Linux 2 (AL2) worker nodes is a tried-and-tested approach. It’s stable, compatible with most tooling, and offers the flexibility of a general-purpose Linux OS.

AL2 is a full Linux distribution meaning it ships with many binaries, libraries, and utilities that aren’t strictly needed for running containers. This fully blown OS increases the attack surface if not hardened properly. If an attacker compromises a node (through a container escape, misconfiguration, or another vector), these extra tools and privileges can be leveraged for deeper intrusion, persistence, and lateral movement.

Hence, it was a wise choice to explore Bottlerocket which is CIS hardened out of the box as a EKS node OS.

Bottlerocket: Minimal, Secure, Container-First OS

Bottlerocket is an open-source Linux-based OS purpose-built by AWS to run containers securely and with minimal overhead. It’s now officially published and supported for EKS and ECS, making it a good alternative to AL2 for containerization platforms. As Bottlerocket is CIS hardened out of the box, it saves so much of manual/automation work of hardening OS image.

Key Security Advantages of Bottlerocket over AL2

Immutable Root File System
- The root filesystem is read-only and protected with dm-verity (integrity verification).
No Direct Package Installation
- There’s no package managers (yum/apt).
- All additional functionality runs in special-purpose containers (control or admin container), isolating changes from the host OS.
No Default SSH Access
- Bottlerocket blocks SSH by default.
- Administrative access is through AWS Systems Manager (SSM) Session Manager, meaning you are covered with IAM and CloudTrail.
Locked-Down System & Kernel
- No direct systemd or kernel-level access from workloads.
- The OS is configured and updated via a local API (protected by SELinux policies), avoiding risky manual edits.
Atomic, Signed OS Updates with Rollback
- Updates are applied as a full image to an inactive partition, verified with cryptographic signatures, and made active only after reboot.

Why BottleRocket could be a good choice?

Moving from AL2 to Bottlerocket removes unnecessary OS-level tools and privileges from your nodes, reducing the blast radius. Instead of manually hardening AL2 with CIS benchmarks, SELinux policies, and SSH lockdowns, Bottlerocket bakes these controls in by default.

This means:

Lower operational risk.
Less maintenance effort to stay compliant.
Better alignment with Kubernetes’ container-first security model.

Official Bottlerocket Documentation → https://bottlerocket.dev/en/os/1.42.x/

Our Migration Journey with Karpenter

In the earlier section, we discussed why we focused on Bottlerocket. Now, let’s talk about the how the actual activities we performed during our migration.

Our EKS cluster uses Karpenter for node provisioning instead of EKS-managed node groups. Hence this post focuses on Karpenter-specific configurations for using Bottlerocket AMIs.

Let’s get into the stepwise procedure –

1. Updating the EC2NodeClass Manifest

To provision Bottlerocket nodes with Karpenter, we updated our EC2NodeClass manifest as follows:

apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: bottlerocket-nodes
spec:
  amiFamily: Bottlerocket
  amiSelectorTerms:
    - alias: bottlerocket@v1.42.0
  blockDeviceMappings:
    - deviceName: /dev/xvda
      ebs:
        deleteOnTermination: true
        encrypted: true
        kmsKeyID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx
        volumeSize: 10Gi
        volumeType: gp3
    - deviceName: /dev/xvdb
      ebs:
        deleteOnTermination: true
        encrypted: true
        kmsKeyID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx
        volumeSize: 30Gi
        volumeType: gp3

Key Points

amiFamily must be set to Bottlerocket.
amiSelectorTerms.alias specifies the desired Bottlerocket version.
Avoid using bottlerocket@latest in production environments. As it points to an AWS-managed SSM parameter, if AWS updates the parameter value, Karpenter detect it as an AMI drift and recycle nodes (default check interval is 1 hour). It shuffles all the PODs in the cluster.

Pro tip: Instead of relying on @latest, you can implement your own AMI automation pipeline. Tag new AMIs with predefined keys (e.g., owner=myteam, version=1.42.0) and reference those tags in amiSelectorTerms.

2. Understanding Block Device Mappings

We explicitly defined two block devices for Bottlerocket nodes:

/dev/xvda — OS Volume
- For Bottlerocket OS!
- Contains active/passive partitions, bootloader, dm-verity metadata, and the Bottlerocket API datastore.
/dev/xvdb — Data Volume
- Used for everything running on top of Bottlerocket i.e. container images, runtime storage, and Kubernetes persistent volumes.

If you don’t define /dev/xvdb in your manifest:

Karpenter defaults it to 20 GB of type GP2. I prefer gp3 for best price-performance ratio.
You may end up in insufficient disk space incidents.
/dev/xvda may end up larger than necessary, wasting EBS storage for the OS.

By making these changes, we were able to seamlessly migrate from AL2 to Bottlerocket in our Karpenter-managed EKS environment, gaining all the hardened security benefits without disrupting workloads.

3. User Data Script: Custom GuardDuty DNS Mapping on Bottlerocket

Background

In our setup, EKS cluster uses a self-hosted DNS instead of AWS’s default DNS. We’ve also enabled AWS GuardDuty threat detection for the cluster.

When GuardDuty protection is enabled, it creates a PrivateLink VPC endpoint whose DNS name is resolved inside the respective PODs. This PrivateLink is available in the subnets/AZs where it’s created (in our case: 3 subnets, AZs a, b, and c).

For GuardDuty’s DaemonSet to function correctly, all EKS nodes must be able to resolve its PrivateLink endpoint from within the same subnet they launched in.

How We Did It on AL2

On Amazon Linux 2, this was simple:

Add a shell script to EC2 user data.
Script fetchs the subnet-specific PrivateLink IP.
Appends the mapping to /etc/hosts.

The Bottlerocket Challenge

Bottlerocket can not execute raw shell scripts directly via EC2 user data.
Instead:

It uses TOML-formatted user data.
OS changes are made through the Bottlerocket API (apiclient).

Also, /etc/hosts exists on the read-only root filesystem, so direct edits are not possible.

Our Solution

After researching the Bottlerocket design, we found three possible approaches:

Host containers (admin, control): Could run the script but admin requires enabling an SSH keypair, which we wanted to avoid.
Bootstrap containers: Run a container at instance boot before the kubelet starts.
apiclient API calls: The correct way to update /etc/hosts on Bottlerocket.

We opted to go ahead with bootstrap containers + apiclient.

Final User Data Configuration

Here’s the relevant part of our EC2NodeClass manifest for Karpenter:

apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: bottlerocket-guardduty
spec:
  amiFamily: Bottlerocket
  amiSelectorTerms:
    - alias: bottlerocket@v1.42.0
  blockDeviceMappings:
    ...
  userData: |
    [settings.bootstrap-containers]
    [settings.bootstrap-containers.guardduty]
    source = "public.ecr.aws/bottlerocket/bottlerocket-bootstrap:v0.2.4"
    mode = "once"
    user-data = "xxxvYmlxxxxxxxxxxxxxxxxxxxxxxxyBXT1JMXX=="

Note: The base64-encoded string shown in the bootstrap-container user-data is only a placeholder. Below are the detailed steps to generate the actual base64-encoded string for your script.

Implementation Steps

a) Create the shell script (myscript.sh)
This script uses apiclient to inject the GuardDuty PrivateLink mapping into /etc/hosts via the Bottlerocket API.

#!/bin/bash
set -euo pipefail

echo "[BOOTSTRAP] Starting GuardDuty host entry setup..."

# Get IMDSv2 token
TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 60")

# Get metadata
MAC1=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/network/interfaces/macs/ | head -1 | tr -d '/')

VPCID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/network/interfaces/macs/$MAC1/vpc-id)

AZ=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/dynamic/<AWS-ACCOUNT-ALIAS>/document | jq -r .availabilityZone)

REGION=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/dynamic/<AWS-ACCOUNT-ALIAS>/document | jq -r .region)

# Get GuardDuty ENI IP
ENIIP=$(aws ec2 describe-network-interfaces \
  --filters Name=vpc-id,Values=$VPCID \
            Name=availability-zone,Values=$AZ \
            Name=group-name,Values="GuardDutyManagedSecurityGroup-vpc-*" \
  --query 'NetworkInterfaces[0].PrivateIpAddress' \
  --region "$REGION" --output text)

if [[ -z "$ENIIP" || "$ENIIP" == "None" ]]; then
    echo "[BOOTSTRAP] No GuardDuty ENI IP found"
    exit 0
fi

cat > hosts.json <<EOF
{
  "settings": {
    "network": {
      "hosts": [
        ["$ENIIP", ["guardduty-data.$REGION.amazonaws.com"]]
      ]
    }
  }
}
EOF

apiclient apply < hosts.json

b) Encode the script in Base64
Bootstrap container user data must be Base64-encoded for TOML.

base64 -w 0 myscript.sh

c) Embed the Base64 string in user data
Paste the encoded string into:

[settings.bootstrap-containers.guardduty]
user-data = "&lt;base64-encoded-script>"

d) Validate execution
You can verify your bootstrap container ran successfully using:

aws ec2 instance --> Actions --> Monitor and Troubleshoot --> Get system log

Key Takeaways:

Use the network.hosts API setting for modifying contents of /etc/hosts
Bootstrap containers are the best way to run initialization scripts at boot.
Avoid enabling the admin host container with SSH just for automation, it defeats the purpose of Bottlerocket’s out of the box hardening.

Final Thoughts

In this blog, we’ve shared the insights and hands-on learnings we’ve gathered while working with Bottlerocket. Since there’s limited practical guidance available online, we thought to share our experience. In a summary: migrating from Amazon Linux 2 to Bottlerocket for EKS node hardening not only strengthens security but also changes how we interact with the underlying OS. While certain tasks like running userdata scripts require a different approach, Bottlerocket’s design ensures a minimal attack surface, immutable infrastructure, and tighter control over system access. With the right methods, such as leveraging bootstrap containers and the Bottlerocket API, you can still meet your operational requirements without compromising on security.

KubeCon + CloudNativeCon India 2025: My experience

1 Reply

From scaling Kubernetes, observability, powering huge AI projects to real stories from PepsiCo, Flipkart, and Intuit, KubeCon + CloudNativeCon India 2025 in Hyderabad was a deep dive into where cloud-native ecosystem is headed. Here’s my personal experience about the event.

I had the chance to attend KubeCon + CloudNativeCon India this year. Its a two-day technical conference packed with thoughtfully curated keynotes, tech talks, and lightning sessions from the people shaping the Kubernetes ecosystem and the cloud-native world. The event also featured ~30 product/solutions booths showcasing solutions to help organizations with Kubernetes workloads, security, scaling, observability, platform engineering and their AI journey. Before we get into more details, take a look at these key numbers and details:

Held at Hyderabad International Convention Centre (HICC).
Happened on 6-7 August 2025.
Sessions
- 12 Keynote sessions
- 10 lightning talks
- 56 Tech sessions on K8s, Observability, Scaling, Security, AI + ML, Platform engineering, etc.
Approx ~4000 registrations
~30 product/solutions booth by various companies.
The 2026 KubeCon India is announced to be held in Mumbai!
Watch this event’s session recordings, available on the CNCF YouTube Channel.
Review session slides from speakers who provided them via the event schedule.

With so much on the agenda, it’s very difficult for one person to attend everything. That’s why pre-planning is essential for events of this scale. It was worth creating a schedule focused on the sessions and booths that match your interests. The Sched app made this much easier, helping me build my personal agenda so I wouldn’t miss anything important.

There were these ~30 product/solutions booth at the event (Sorted alphabetically)-

Akamai – Akamai Cloud. Simple, Scalable and out of this world.
Atlassian – Delivering greatness is impossible alone. Jira. Confluence. Loom. Rovo.
AWS – Scalable, Reliable and Secure Kubernetes
CAST AI – Kubernetes Automation and Performance
Clickhouse + HyperDX – The world’s fastest analytical database
Cloudflare
Coralogix – Complete Observability, Zero compromises.
D E Shaw & Co
Digital Ocean
Dragonfly – In memory data store. Cut Redis costs by 50%
EDB Postgres II by CloudNativePG – Setting the Standard for PostGres in Kubernetes
Expedia group – Careers
F5 – Optimize, Scale, and Secure Apps in Kubernetes
GitHub
Gitlab – Develop, secure and deploy software faster
Google Cloud
Grafana Labs – Open, composable and cost-effective observability.
Intel – AI inside for a new Era
Kloudfuse – Unified Observability. Your Cloud. Your Control.
Kodecloud – Kubernetes learning platform
Kong – Kube-native. Platform-forward.
Last9 – Ship fast. triage faster.
Learning Lounge CNCF – The Linux Foundation Education
Microsoft Azure – Achieve more with Azure hosted Kubernetes
Nudgebee – AI-Agentic Assistants. Troubleshooting. FinOps. CloudOps.
Nutanix – Kubernetes. Virtualization. Data. Anywhere.
PerfectScale by doit – Autonomous Kubernetes. Optimization and Governance.
RedHat OpenShift
ScyllaDB – Predictable Performance at Scale – Anywhere
Sonatype – Scalable Artifact Management
vmware – Kubernetes Made Simpler, More Flexible and Secure.
VULTR – Global cloud infrastructureand manage Kubernetes for AI-native applications

My experience

I traveled with my team to attend the event, and ignoring the travel fatigue, we made it to HICC by 8 AM for the check-in formalities. We were ready after security checks done and we received our event badges. The venue welcomed us with tea, coffee, and cookies – a much-needed warm-up before a day packed with technical deep dives.

By 9:30, as per the agenda, the keynote sessions started. The crowd was so massive that the main hall quickly filled up, but crew arranged adjacent halls with big screens for live streaming. We settled into one of those adjacent halls, but due to some technical glitches with the screen and audio, we decided to head back to the main hall and stand along the sides just to catch the keynotes live. After an hour of inspiring talks (and sore legs :D), we stepped out for a break and then dove into exploring the product and solution booths.

The booths were sparkling with energy! Attendees deep in conversations with booth teams, exploring new features and solutions – it was a energetic sight! It was great to see fresh graduates in the mix, already well-versed in cloud technologies. The enthusiasm was contagious, and of course, no developer conference is complete without a shower of freebies and laptop stickers. We do collected a healthy stash!

The iconic “Kubestronauts” blue jackets were turning heads throughout the venue. It’s a title one can earn by completing five Kubernetes and cloud-native certifications, a badge of honor that carries serious weight in the Kubernetes world today. Seeing a few Kubestronauts proudly sporting those jackets was truly inspiring!

We split up to cover more ground, each visiting different booths. My own highlights are the insightful discussions I had at the AWS and Nudgebee booths. Both offered interesting perspectives and solutions worth exploring further.

The organizers smartly arranged lunch across multiple dining designated areas, which helped spread out the crowd and made it possible for attendees to enjoy a peaceful, crowd-free meal.

We contiunued the second day with similar agenda of attending sessions and booths gathering every possible bit of the information that could help us keeping tab of the Cloud Native and Kubernetes world and industry progress in those domains. ArgoCD scaling, Platform Engineering, EKS Auto mode, EKS dashboards, Observability, AI integration for troubelshooting and Ops to name a few.

I also ran into a former colleague and reconnected with some contacts from AWS I had worked with in the past during the event. Also, got to see some open source community leaders, some well known personalities from Kubernetes/Cloud world in person. These technical conferences are they best way to network and socialize!

A Peek into the Event

Reflections on AWS Summit Mumbai 2025

Leave a reply

I had the opportunity to attend the AWS Summit Mumbai 2025 on June 19th. In this post, I’ll be sharing my insights and reflections from the event.

AWS Summit is not a AWS re:Invent!

The AWS Summit is a regional tech conference held multiple times a year, designed to showcase majorly customer stories, real-world use cases, product applications, and technical journeys powered by AWS. It’s focused on knowledge sharing and community engagement rather than major product announcements.

In contrast, AWS re:Invent is AWS’s global, annual flagship event. It’s where the company unveils new services, features, and products, alongside deep-dive technical sessions, training, and certification opportunities.

So, if you’re attending an AWS Summit, don’t expect groundbreaking announcements. Instead, think of it as a community event focused on learning, networking, and exchanging experiences with the local digital and tech ecosystem.

AWS Summit Mumbai 2025

AWS Summit Mumbai 2025 was focused on sharing the stories and products that harnesses the power of Cloud Computing and AI for accelerating digital transforming journey of India. Yes, a lot of AI was in the air!

It kicked off with the Keybote from AWS leaders: Sandeep Dutta – President – AWS India and South Asia and Ganapathy Krishnamoorthy VP – Databases – AWS. The keynote also included the the talks from Industry leaders: Dr. Tapan Sahoo (Head of Digital Enterprise and Information & Cyber Security, Maruti Suzuki India) and Rajesh Chandiramani (CEO, Comviva).

Keynote was followed by nearly 40+ breakout sessions in various technologies like databases, AI, observability, FinTech, etc. that showcased how industry in India is leveraging the power of AWS and AI to shape their future.These sessions were categorized into 6 tracks :

Building for Scale
Generative AI on AWS
Migration and modernization
AWS for Data
Security, compliance & resilience
Innovate with AWS Partners

The experiences at the venue included builders zone (offering hands-on to latest AWS services), Industry hub (business tailored, cloud native solution products), Business innovation hubs (convergence point for organizations), AWS Game Day (2-hours hackethon mainely focused on usage of AWS AI services) and AI Hub (Hands-on to AWS AI services).

My experience at AWS Summit Mumbai 2025

The event was really well organized and took place at the impressive Jio World Convention Centre in Mumbai. The venue itself was top-notch, and the food—breakfast, lunch, and high tea—was genuinely delicious.

Even though the space is huge, the number of attendees made it feel a bit crowded at times. There were some cool photo spots set up that captured the spirit of Mumbai, which added a nice local vibe to the event.

The breakout sessions were intense—over 40 sessions packed into just three hours (1:30 PM to 4:30 PM)! Even with a plan in place, it was tough to jump from one session to another, especially with sessions happening in different halls. You’d almost always miss the first few minutes of the next session. A 5-minute buffer between sessions would’ve made a big difference.

There wasn’t much time left for networking or checking out the booths unless you sacrificed a bit of your lunch or break time. That said, the overall vibe was electric—full of tech buzz, especially around AI. I also ran into a few former colleagues, which was a really nice, nostalgic surprise!

A peek into the event

Efficient & Ergonomic: A Look Inside My Home Office Setup

Leave a reply

With the rise of remote work, having a well-equipped home office isn’t just a luxury—it’s a necessity. Over the past year, I’ve fine-tuned my setup to strike the perfect balance between productivity, ergonomics, and tech aesthetics.

Instead of overloading the space with gear, I’ve focused on what actually improves my daily workflow. Each item in my setup has been carefully chosen for a balance of performance, comfort, and reliability. From a dual-monitor arrangement and a wireless mechanical keyboard to ergonomic accessories and clear audio gear, these tools help me stay efficient and comfortable throughout the day.

Here’s a quick look at the core gadgets that make up my current setup.

Home Office Gear List

Laptop: HP EliteBook 840 G11
Monitors: Acer Nitro QG221Q + Samsung 24″ LF24T350FHWXXL (mounted on dual monitor stand)
Mouse: Logitech MX Master 2S
Keyboard: AULA F87 Wireless Mechanical Keyboard
Webcam: Logitech Brio 100
Conference Speaker System: Anker PowerConf A3301
Mouse Support: Frido Mouse Wrist Support
Headphones: Poly Voyager 4320
Chair: Green Soul Zodiac Pro High Back Mesh Office Chair
Tablet: Apple iPad 9th Gen
Wireless Charging Stand: Raegr Arc M1050 MagSafe Charging Stand
Mesh Wifi: TP Link Deco X60

A home office is more than just a desk and a chair—it’s the environment that supports your focus and flow. With the right tools in place, you can turn any corner of your home into a productivity powerhouse. I hope this breakdown of my setup helps inspire yours. Have questions or want to share your own workspace? Drop a comment below—I’d love to hear from you!

Load Balancing between two ISPs with TP-Link ER605

1 Reply

In this post, we will walk you through the procedure to configure two ISPs i.e. Airtel Extreme and TATA Play Fiber in load balancing configuration with tp-link ER605 router for high availability of internet at home/small business.

Pre-requisites

Two active ISP lines (We are discussing here Airtel Extreme and TATA Play Fiber)
Both ISP routers in Bridge mode acting as a passthrough.
tp-link ER604 VPN Router (Load balancer)

Before we proceed, Airtel and TATA router’s should be configured in a Bridge mode. We explained how to enable bridge mode in Airtel router here. Please follow below procedure for TATA Play Fiber router.

How to enable Bridge mode on TATA Fiber router

Reach out to TATA engineering team through customer care for below tasks –
- Enabling bridge mode for your router from backend.
- Obtain admin credentials to log into the router
- You should have PPPoE credentials on your email (TATA generally sends them when you receive new connection). If not, then obtain them as well from the engineering team.
Please be noted that enabling bridge mode from backend by TATA engineering team is a crucial step for LAN bridge configuration.
Once both requests are completed, log into the router using the obtained credentials and configure one of the LAN port with bridge.

Additionally, you can disable the WiFi networks on this router as your home/office will be powered by the network created by tp-link ER605 router for high availability.

At this point in time, you should have both ISP’s i.e. Airtel and TATA’s routers configured in bridge mode. Let’s look at the tp-link ER605 configurations now.

Wired connectivity between routers

Now, its time to hookup ISP routers to tp-link ER605.

PORT 1: Primary WAN. A CAT6 cable running from Airtel router LAN port to this.
PORT 2: Secondary WAN. A CAT6 from TATA router LAN port to this.
Ensure ports configured in Bridge mode on ISP routers are used for this wired connecctivity.
PORT 3/4/5: Connected to WiFi Access Point i.e. to extend ER605 network over WiFi. I have X60 mesh network in AP mode.

ER605 configurations

Connect a laptop/desktop to ER605 using ethernet cable to any of the remaining port. Start router by plugging it in the power supply. Log into ER605 console at http://192.168.0.1/

On very first login it will prompt for setting up the username and password. Proceed with on screen instruction to setup your account. Once logged in –

Navigate to the Network > WAN > WAN Mode
Select WAN/LAN1 to enable PORT2 for WAN connectivity and click Save

The router should restart to apply this configuration.
After restart, log in and navigate to Network > WAN > WAN
Punch in connection configs for the ISP i.e. plugged into first WAN PORT. In our case, Airtel Extreme PPPoE configs.

Once saved, it will automatically try to connect and connection status will be updated in the right panel.
There are couple of options that you can configure here as bandwidth and DNS servers.
Navigate to Network > WAN > WAN/LAN1
Configure the second ISP i.e. router plugged into PORT2 of the ER605. In our case its TATA Fiber.

Both WAN should get connected. Verify in the Connection Status.
Notice, how I am making use of 4 DNS servers (a pair in each WAN from different companies)
- WAN1: 1.1.1.1 (Cloudflare) and 8.8.4.4 (Google)
- WAN2: 8.8.88 (Google) and 1.0.0.1 (Cloudflare)
At this point, Internet is made available from two WANs in the network of ER605. Rest of the LAN ports can be used for internet consumers.
I am extending this network on my WiFi Mesh DECO system which is configured in AP mode. Hence, all my home wifi clients are now consuming bandwidth from two differnt ISPs and having a very highly available internet connectivity!
Navigate to Transmission > Load Balancing
Ensure Enable Load Balancing is selected.
Select both WAN under Enable Bandwidth Based Balance Routing on ports. It will ensure bandwidth usages will be propertionate between both the WANs. If there is bandwidth up/down difference between WANs, ensure you configure them accordingly in previous connection configurations. So that, bandwith usages will be handeled accordingly.

Load balancing ensures that if one of the WAN goes down (ISP downtime) then all internet traffic is routed through other WAN hence achieving high availability of internet.

Bandwidth-based routing ensures that both ISPs’ bandwidths are fully utilized, preventing the any ISP from going unutilized and costing rentals unnecessarily.

Result!

The highly available Internet services on home mesh WiFi!

The speedtest of this setup should be carried out on two different devices ensuring they are going out on internet through different WANs. Execute the speed test at a same time and test results should show full bandwidth of respective ISPs for both devices. In a nutshell, at any given point in time total of both bandwidth’s is available.

ER605 is a powerful device for home use and there are many different things that can be configured. We did not discussed them as they are out of the scope for this article.

Setting up Mesh Wi-Fi with Airtel Xtreme Fiber

4 Replies

In this post we will walk you through step by step guide for setting up your own Mesh Wi-Fi system with Airtel Xtreme Fiber.

I’ve been an Airtel Xtreme Fiber user for many years and am now considering getting a Mesh Wi-Fi system. While the default routers provided with Airtel Xtreme are good, they tend to become sluggish as the number of connected devices increases. I was also experiencing Wi-Fi range issues, so I had to hard wired the rest of the rooms for internet connectivity. This ignited the need to explore the Mesh Wi-Fi setup.

After researching internet forums, I found that the information is available but scattered across various threads and discussions. So, I decided to write this post, which I hope will be helpful for others in setting up their own Mesh systems with Airtel Xtreme routers.

The setup goes through several steps –

Enable Bridge mode on LAN port of Airtel router
Configuration on Airtel router
Configuration on Mesh Wi-Fi router

Let’s look at the inventory before we get into the procedures –

Internet type: Airtel Xtreme Fiber
ISP Router: Airtel Dragon Path 707GR1
Mesh Wi-Fi system: TP-Link Deco X20 (Deco X60 is another great choice with more speed capabilities and inbuild extra antenna pair)

Now, we deep dive into configurations and related procedures.

Enable bridge mode on Airtel router

The Airtel router is configured with PPPoE for the Fiber Channel port. Before using another router with Airtel Xtreme, it’s essential to enable Bridge mode on the Airtel router. Bridge mode allows the Airtel router to function as a passthrough, enabling your own router to handle the PPPoE connection for internet access. This setup unleash the full capabilities of your own router and bypass the limitations of the default Airtel router.

To enable bridge mode on your Airtel router, send an email to net@airtel.com explaining your request. You should then receive a call within two days from Airtel to discuss your requirements. Explain that you need to use your own router and specify the port number where you want bridge mode enabled. Within a few hours, you should receive a confirmation callback from their backend team, confirming that bridge mode has been enabled on the specified port. No engineer visit is required (at least for the model I mentioned), as they can remotely enable bridge mode on your router. I oberved on internet forums that always the last LAN port on your router is chosen to enable the bridge mode if not all. So LAN2 or LAN4 depending on how many LAN ports you have on your Airtel router. Dragon Path 707GR1 has two LAN ports so I requested to enable it on LAN2 and its been working good for me.

Verify LAN2 bridge mode by navigating to WAN > PON WAN > select nas0_3 in dropdown on Airtel router webconsole.

For the next step—router configurations—ensure you have local access to both routers (Airtel and Mesh) by connecting them to your laptop or machine via LAN cables. This will make the configuration process easier.

Airtel router configuration

When using your own router with the Airtel Xtreme router, there are two key configurations to perform on the Airtel router:

Disable the WAN profile to allow your own router to handle the PPPoE connection.
Disable the Wi-Fi networks on the Airtel router so that your own router can manage Wi-Fi signals.

Once bridge mode is enabled, your mesh Wi-Fi router will need to dial in with PPPoE for internet access, so you should remove the WAN profile on the Airtel router. Note down the username in WAN profile. Before making any changes, ensure you have a backup of the current configuration. If the backup option is disabled, take screenshots for future reference.

*Removed WAN profile from Airtel router*

Since you plan to use a mesh Wi-Fi network, disable the Airtel router’s Wi-Fi networks to prevent interference from the extra signals. At this point, the Airtel router will function solely as a passthrough for your router.

Mesh router configuration

You need to configure the very two things that you disabled on Airtel router in previosu step.

Configure PPPoE
Configure Wi-Fi network

TP-Link Deco Mesh systems are easy and quick using the Deco app. Installation guide here. Use PPPoE protocol for internet connection configuration. Username is alredy known in previous step (copied from the WAN profile in Airtel router) and password should be your Airtel Account ID. If not, please reach out to Airtel and get the credentials.

TP-Link Deco X20 is a dual band Wi-Fi with band steering. It means both 2.4Ghz and 5GHz emitted on a single SSID. Band steering optimizes which band a device connects to based on signal strength and congestion. When setting up Deco Mesh Wi-Fi network, it’s helpful to use the same SSID and password as your Airtel router. This way, all devices on your network will seamlessly connect to the Deco mesh Wi-Fi without any issues. If you prefer to start fresh, you can create a new SSID for the Deco mesh, but you’ll need to enter the new Wi-Fi password on all the devices in your network.

It is also recommended to have a wired backhaul for the Decos in your network. Or decos should be in a good range with each other to establish a good backend network between them. Wired backhaul ensures minimum bandwidth drop for the internet speed.

I already had network cables running through different rooms, which was convenient for backhauling the Deco network over a wired connection.

Now, with Mesh network my complete home is covered with full range of Wi-Fi strong signals.

With the transition to a Mesh network, I gained following benefits:

Increased device handling capacity for my Wi-Fi hardware.
Strong Wi-Fi signal coverage throughout my entire house.
Improved internet speed for all devices in every corner of the house.
Seamless network switching for devices when moving between rooms.
A single SSID broadcast that supports both 2.4G and 5G bands.

In summary, multi-story homes or houses with many rooms (which introduces wall interference) should opt for mesh systems over traditional single router and wired setups. Mesh systems offer a cleaner, maintenance-free solution without cable clutter throughout the house.

I hope this post will be helpful to our fellow readers in setting up their own mesh with Airtel Xtreme fiber internet.

AWS CloudFormation IaC Generator!

Leave a reply

AWS has recently introduced a Console-to-Code functionality, allowing users to automatically generate Infrastructure as Code (IaC) templates based on actions performed in the EC2 console. Additionally, AWS offers the CloudFormation IaC Generator, a compact tool embedded in the AWS CloudFormation console. This tool facilitates the creation of CloudFormation templates for pre-existing resources within your account. In the following post, we will walk through this tool and step-by-step instructions on how to use it.

*Exploring AWS CloudFormation IaC Generator*

What is the IaC generator?

The AWS CloudFormation IaC generator lets you generate a template for AWS resources that are already provisioned in your account and not being managed by CloudFormation. It does makes sense to exclude resources managed by CloudFormation since you already have a template for them!

Firstly, initiate a scan of your account under the IaC generator console to provide the tool with a comprehensive list of resources not governed by CloudFormation. There are a few quota limits on these scans which can be referred here.

Upon completion of the scan, the tool displays a list of resources that are not under CloudFormation management. Begin creating the template by selecting these resources, and the tool will then generate the template in either YAML or JSON format.

The powerful IaC generator capabilities of CloudFormation can also be accessed via the AWS CLI, making it a compelling choice for streamlined and efficient automation.

How to use the IaC generator?

Login to Cloudformation console.
Click on IaC generator link on the left hand side menu.

If you are using it for the first time, you might want to hit the Start a new scan button for running the first resources scan of this tool. This scan will identify all the AWS resources in your account that are not managed by CloudFormation.
Click on Create template button.
On a create wizard, provide the template details.

We are choosing to create a template from scratch. If you want to add a resource in exsiting CloudFormation stack then choose ‘Upadte the template for an existing stack‘. Make an appropriate choice for deletion and update replace policies.
On a next screen, choose resources to be included in the IaC template.

If the resource you are looking for is not in the list, probably you need to initiate the new scan since your scan inventory might be the old one.
Click on Next button and choose related resources if any.

The tool gathers the list of dependent or related resources from the resource you chose in the last step. Since we selected S3 bucket with no external dependency like KMS key, etc. we are not having any related resource.
Click on Next button for the final Review screen of the wizard.

Review the selections and click Create template button.

The teamplate will be genrated. You will have option to choose YAML or JSON format. You can copy or download it as well. Or you can import it into a CloudFormation Stack by clicking Import to stack button.
There is also AWS CDK application command in last tab AWS CDK

Importing the AWS resources in to the CloudFormation stack

It is always advisable to manage AWS resources through IaC templates, as this approach enhance resource management and minimizes the cloud clutter. One common challenge in the IaC journey is incorporating manually created existing resources into IaC. The IaC generator proves valuable in this scenario by assisting in the creation of IaC templates for your resources, facilitating a seamless transition.

Using IaC generator, you can generate the IaC template of existing resources that are not managed by Cloudformation. Once the template is generated, it also offers an option to import it in to the stack. Select that option (the last screesnhot in above section) and it will kickstart Cloudfomation import stack wizard.

Review all the information on the console, and then proceed to initiate the creation of a new stack that will import the chosen resources. I won’t go into a detailed, step-by-step procedure here, as it follows the standard CloudFormation stack process.

The CloudFormation stack will be created and you can see the selected resource is now imported and managed by CloudFormation.

This is a convenient method to scan for resources not governed by CloudFormation and subsequently import them into a CloudFormation stack, thereby fostering the adoption of Infrastructure as Code practices within your account and organization.

Conclusion

The IaC generator from AWS is a commendable initiative aimed at assisting customers in achieving 100% compliance with Infrastructure as Code for their infrastructure. It provides a seamless experience, effortlessly identifying non-IaC resources and smoothly importing them into CloudFormation stacks. Furthermore, it expedites the adoption of IaC by automatically generating code templates for you.