DEV Community: Fabricio Flores

Build without stopping to set up IAM roles in the new AWS experience

Fabricio Flores — Tue, 13 Oct 2026 14:54:34 +0000

The new AWS experience removes two pieces of permission setup that often interrupt an early build. First, a project owner can now invite another person with an emailed invite, instead of having to set up an IAM user or IAM Identity Center. Second, when you create a resource using a supported AWS service, IAM role manager can automatically set up the IAM role for you so that your project resources can talk to each other.

Those actions involve different identities. Project access authorizes the person doing the work. An IAM role authorizes the service or application that runs afterward.

If you created your account through the new AWS experience, role manager is already turned on. When you create a supported resource, such as a Lambda function, AWS creates or reuses the role it needs and attaches it automatically.

Share a project with collaborators

A project owner can share access in two ways: invite someone from theTeam page and choose one or more projects, or open a specific project and invite them from its Members area. An invitation from the Team page does not automatically share every project the owner has; access applies only to the selected projects. After accepting, the team member has admin access to the resources and services available in those projects, including the ability to create access controls for services and applications. They cannot perform owner-only team-management, project, root, or financial actions. If you need to customize a team member’s access instead of granting project admin access, you must first activate advanced AWS features. For more details about sharing projects and team member access, see Invite team members to collaborate in AWS Settings.

To see the invitation process in action, watch Invite Your Teammate to Your AWS Project.

How role manager works

An IAM role defines what an AWS service is allowed to access and do. Setting one up usually means defining which service can assume the role, choosing what that service is allowed to do, and attaching the role to the resource.

IAM role manager automates that setup. When you create a resource in one of the supported services, role manager creates a role for it or reuses one that already fits. It then attaches the role as part of the same workflow, so you do not have to stop and set it up separately in IAM.

For accounts created through the new AWS experience, role manager is enabled by default. You cannot disable it until the account owner activates advanced AWS features.

This restriction is enforced by an AWS-managed service control policy (SCP). In the new experience, AWS manages the SCPs and resource control policies (RCPs) that protect your projects' preconfigured defaults, so you do not set up or edit these guardrails. For details, see Managed policies for your organization.

After advanced features are activated, you can manage role manager from Account settings in the IAM console.

How role manager sets up a Lambda execution role

Lambda is a useful example because AWS cannot know ahead of time which services your code will call. With role manager enabled, creating a function automatically attaches an execution role that the code can use immediately. You can narrow that role later, once you know what the function actually needs.

Because those permissions are unknown at creation time, role manager starts the role with the AWS managed PowerUserAccess policy. This gives the function broad access to AWS services, but it does not allow the function to manage IAM, AWS Organizations, or account settings. The role's trust policy allows only Lambda to assume it.

After the function is created, open its Configuration tab and choose Permissions. The Execution role panel shows the PowerUserRole that role manager attached.

Follow the role link to IAM. On the role's Permissions tab, choose PowerUserAccess to inspect the AWS managed policy and the access it grants.

Roles created by role manager are standard IAM roles, so you can inspect their trust policies and permissions, edit them, or delete them. Each role records the AWS-managed template it came from, which lets you identify roles created by role manager. AWS CloudTrail records each role's creation.

Refine permissions before production

Least privilege means giving a workload only the actions and resource access it needs. Role manager's PowerUserAccess policy is useful while you are still discovering those needs, but it is intentionally broader than most production functions require.

Use IAM Access Analyzer policy generation to help refine the role's permissions toward least privilege. Editing the role removes it from role manager's control and makes it a standard role that you manage.

After activating advanced AWS features, you can disable role manager without affecting existing applications or removing their roles. Existing roles stay in place, but new resources use the standard service or IAM role-creation workflows.

Conclusion

Role manager automates the initial IAM role setup for supported AWS services. It creates or reuses a role and attaches it while you create the resource, but the result remains a standard IAM role that you can inspect and control.

Together with AWS-managed project sharing, this reduces the access setup required for both collaborators and the services they build. Before production, review how the workload actually behaves and use IAM Access Analyzer policy generation to replace broad permissions with a more focused policy.

To get started, create a resource in a supported service. In accounts created through the new AWS experience, role manager is already enabled. For more information about managing roles yourself, see IAM role creation.

How I built this serverless API with the new AWS

Fabricio Flores — Thu, 08 Oct 2026 21:56:17 +0000

AI coding agents have shortened the path from an idea to working code. The updated AWS experience is designed to make deployment keep pace. It connects your agent to an AWS project, configures the AWS tools it needs, and handles permissions between the resources it creates.

I used that workflow to turn a short prompt into a Python API using Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. The build starts by connecting the agent to AWS and ends with a working endpoint that I call from my terminal.

Connect a coding agent to the AWS project

After signing in, I followed the instructions in the Setup Agent Toolkit for AWS dialog and pasted its setup prompt into my coding agent.

The agent then:

installed the AWS Command Line Interface (AWS CLI),
used aws login to sign me in,
configured the AWS MCP server and core AWS skills, and
added customizable rules for building on AWS.

Describe the API in one prompt

With the agent connected, I described the service I wanted:

I specified Python, asked for a stateful response I could test, and told the agent to show me the architecture before deploying. I left the AWS service choices open.

Review the proposed architecture

Before creating resources, the agent proposed this architecture:

The detailed proposal defined GET /counter as an atomic increment of a value stored in DynamoDB. API Gateway would expose the public endpoint, a Python Lambda function would handle each request, and an on-demand DynamoDB table would maintain state across calls. The atomic update would prevent duplicate values during concurrent requests.

The plan also included conservative throttling, a least-privilege IAM role for the table update and function logging, CloudWatch log retention, local tests, and deployment through an AWS CloudFormation stack.

The agent explicitly said that no AWS resources had been changed and asked me to approve the architecture and public endpoint before continuing.

Let the agent build and deploy

After I approved the plan, the agent deployed the serverless-counter-api CloudFormation stack in us-east-2. The deployment included:

a public API Gateway endpoint,
a Python 3.12 Lambda function,
a DynamoDB table to store the counter, and
an IAM role giving the function the access it needed.

The API was intentionally public for this demo. Anyone with the URL could invoke it and generate usage, so a production API should use authorization appropriate to its callers and data.

Call the live endpoint

The agent verified the deployment by calling the endpoint three times. Each call returned HTTP 200 with {"value": 1}, {"value": 2}, and {"value": 3}. A consistent DynamoDB read confirmed that the stored value was 3.

Later, I set API_URL to the /prod/counter invoke URL and called it three times in a loop:

Those calls returned {"value": 7}, {"value": 8}, and {"value": 9}. The increasing values confirmed that the service was live and maintaining state across requests.

What I kept control of

I chose what the API should do, reviewed the proposed architecture, and approved the public deployment. The agent handled the tooling setup, implementation, deployment, and first tests.

Before wrapping up, I verified the result myself: Lambda updated DynamoDB atomically and returned the new value, the permissions were limited to what the function needed, and GET /counter worked. The agent reported success, but the final call was mine.

Try this with a coding agent you already use. Get started here, then give your agent a small AWS project and ask to see the plan before it deploys anything. You make the calls and check the result. Let the agent handle the setup and get the first version running.

Now go build something 😄.

/server start: How I Let My Friends Control Our Minecraft Server via Discord

Fabricio Flores — Fri, 20 Feb 2026 15:37:28 +0000

BUZZ BUZZ BUZZ

My phone is getting blown up in the middle of the night with calls, texts, and pings from my friends wanting to hop on our Minecraft server. Turns out I had accidentally turned off my ancient laptop that was hosting it. I begrudgingly get up from my cozy bed to boot up the server. Interrupted sleep, all to preserve the sacred annual 2-week Minecraft phase...

So I put my thinking cap on. Is there a way that I could host the server in the cloud and let my friends turn it on and off themselves?

In this post, I'll show you how to build a Discord bot that can interact with your AWS resources. We'll set up a Minecraft server on EC2 as our example, but this same pattern works for any AWS service.

Before we dive in, here's what you'll need:

AWS Account
Discord Developer Account
Docker (for packaging dependencies in a Linux environment)
Python 3.12
Minecraft Account

1. Create Discord Application

Go to Discord Developer Portal
Create New Application
Go to Bot → then click Reset Token and save it securely
Go to OAuth2 → URL Generator → Select bot + applications.commands
Copy Generated URL and add bot to your server
Note your Application ID and Public Key from General Information

2. Create PyNaCl Lambda Layer

Discord requires signature verification on every request. The PyNaCl library handles this, but it has native dependencies — meaning we can't just pip install it on our Mac/Windows and upload to Lambda. We need to build it for Amazon Linux.

Build the layer zip (requires Docker)

Open up your terminal of choice and run:

mkdir -p pynacl_layer
docker run --platform linux/amd64 --rm -v "$(pwd)/pynacl_layer:/out" \
  public.ecr.aws/sam/build-python3.12 bash -c \
  "pip install PyNaCl -t /tmp/python/lib/python3.12/site-packages/ && cd /tmp && zip -r /out/pynacl_layer.zip python"

Make sure Docker Desktop is running first!
You'll get a "Cannot connect to Docker daemon" error otherwise.

Upload it to Lambda

Head to the Lambda console and navigate to Layers → Create layer.

Name: pynacl-layer
Upload: Choose the pynacl_layer.zip file from your local machine
Compatible runtimes: Python 3.12

Click Create.

3. Create Lambda Function

Lambda lets us run code on-demand in the cloud. This is where we'll handle incoming Discord commands and control our EC2 instance.

Now go to Functions → Create function.

Basic settings:

Function name: discord-bot (or whatever you like)
Runtime: Python 3.12
Architecture: x86_64 (must match your layer!)

Click Create function.

Once created, scroll to the bottom of the page. You'll see a Layers section. Click Add a layer, select Custom layers, pick pynacl-layer from the dropdown, and hit Add.

Add your Discord public key:

Go to Configuration tab → Environment variables
Click Edit → Add environment variable
Key: DISCORD_PUBLIC_KEY
Value: your public key from Discord Developer Portal (General Information page)
Click Save

Increase the timeout:

Still in Configuration → General configuration
Click Edit
Set Timeout to 15 seconds (to reduce risk if we encounter latency)
Click Save

Lambda Code (`lambda_function.py`)

Paste this into the Lambda code editor. It verifies that requests are actually coming from Discord, then starts, stops, or checks the status of your EC2 instance based on the command. We're using boto3, the AWS SDK for Python.

import json
import os
import boto3
from nacl.signing import VerifyKey
from nacl.exceptions import BadSignatureError

PUBLIC_KEY = os.environ['DISCORD_PUBLIC_KEY']
# INSTANCE_ID = os.environ['INSTANCE_ID']  # Uncomment in step 8

ec2 = boto3.client('ec2')

def verify_signature(event):
    """Verify the request is actually from Discord"""
    body = event.get("body", "")
    headers = event.get("headers", {})
    signature = headers.get("x-signature-ed25519") or headers.get("X-Signature-Ed25519", "")
    timestamp = headers.get("x-signature-timestamp") or headers.get("X-Signature-Timestamp", "")

    verify_key = VerifyKey(bytes.fromhex(PUBLIC_KEY))
    verify_key.verify(f"{timestamp}{body}".encode(), bytes.fromhex(signature))

def handle_server(action):
    """Start, stop, or check the EC2 instance"""
    if action == "start":
        ec2.start_instances(InstanceIds=[INSTANCE_ID])
        return "🟢 Starting server..."
    elif action == "stop":
        ec2.stop_instances(InstanceIds=[INSTANCE_ID])
        return "🔴 Stopping server..."
    elif action == "status":
        response = ec2.describe_instances(InstanceIds=[INSTANCE_ID])
        state = response['Reservations'][0]['Instances'][0]['State']['Name']
        emoji = "🟢" if state == "running" else "🔴" if state == "stopped" else "🟡"
        return f"{emoji} Server is {state}"
    return "Unknown action"

def lambda_handler(event, context):
    """Entry point for Lambda"""
    try:
        verify_signature(event)
    except Exception:
        return {"statusCode": 401, "body": "Invalid signature"}

    body = json.loads(event.get("body", "{}"))

    # Discord PING check
    if body.get("type") == 1:
        return {"statusCode": 200, "body": json.dumps({"type": 1})}

    # Slash command
    if body.get("type") == 2:
        command_name = body.get("data", {}).get("name")

        if command_name == "server":
            options = body.get("data", {}).get("options", [])
            action = options[0].get("value") if options else None
            message = handle_server(action)
            return {"statusCode": 200, "body": json.dumps({"type": 4, "data": {"content": message}})}

    return {"statusCode": 200, "body": json.dumps({"type": 4, "data": {"content": "Unknown command"}})}

Hit Deploy to save your changes. That's it for the Lambda function for now. We'll come back to it later once we set up our EC2 instance.

4. Create API Gateway

Discord needs a public URL to send commands to. API Gateway gives us that. It acts as the front door to our Lambda function and exposes it as an HTTPS endpoint.

Head to the API Gateway console and create a REST API. Name it something like discord-endpoint.

Create resource /event
Create POST method on /event
Check Lambda proxy integration
Select your Lambda function
Deploy API to a stage (e.g., "prod")
Note the Invoke URL: https://xxx.execute-api.YOUR_REGION.amazonaws.com/prod/event

5. Register Discord Endpoint

Now we tell Discord where to send commands when someone uses our bot.

Go to Discord Developer Portal → Your App → General Information
Set Interactions Endpoint URL to your API Gateway URL
Discord will send a test PING - if verification passes, it saves

6. Register Slash Commands

Discord doesn't know what commands our bot supports yet. We need to register them.

To find your Guild ID, right-click your server name in Discord and click Copy Server ID. If you don't see that option, enable Developer Mode first: Settings → Advanced → Developer Mode.

Run this locally in your terminal:

curl -X POST "https://discord.com/api/v10/applications/YOUR_APP_ID/guilds/YOUR_GUILD_ID/commands" \
  -H "Authorization: Bot YOUR_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "server", "type": 1, "description": "Control game server", "options": [{"name": "action", "description": "What to do", "type": 3, "required": true, "choices": [{"name": "start", "value": "start"}, {"name": "stop", "value": "stop"}, {"name": "status", "value": "status"}]}]}'

7. Create EC2 Instance

EC2 is a virtual machine in the cloud. We'll set up a Minecraft server on it, but you could run whatever you want here.

Head to the EC2 console and launch a new instance.

AMI: Amazon Linux 2023
Instance type: t3.medium (go larger for more demanding games)
Key pair: Create or select one for SSH access
Security group: Under Network settings, create a new security group. By default, SSH has Anywhere selected — change this to My IP

Expand Advanced details and paste this into the User data field (this is a script that runs automatically when the instance is first created). First, go to minecraft.net/download/server and right-click the minecraft_server.jar link to copy the URL. Replace PASTE_THE_URL_HERE with it:

#!/bin/bash
dnf install -y java-21-amazon-corretto
mkdir -p /opt/minecraft
cd /opt/minecraft
curl -O PASTE_THE_URL_HERE
echo "eula=true" > eula.txt
chown -R ec2-user:ec2-user /opt/minecraft

cat > /etc/systemd/system/minecraft.service <<EOF
[Unit]
Description=Minecraft Server
After=network.target

[Service]
WorkingDirectory=/opt/minecraft
ExecStart=/usr/bin/java -Xmx1G -Xms1G -jar server.jar nogui
Restart=always
User=ec2-user

[Install]
WantedBy=multi-user.target
EOF

systemctl enable minecraft
systemctl start minecraft

Click Launch instance, then note your Instance ID (e.g., i-0abc123def456). You'll need it for the next step.

Configure security group for Minecraft:

Click on your instance, then click the Security tab and click on the security group link. Go to Inbound rules → Edit inbound rules and add a rule:

Type	Port	Source
Custom TCP	25565 (Minecraft port)	Anywhere (0.0.0.0/0)

Assign an Elastic IP:

Every time you stop and start your EC2 instance, the public IP changes. That means your friends would need a new IP every time. To fix this, assign an Elastic IP.

In the EC2 console, go to Network & Security → Elastic IPs
Click Allocate Elastic IP address → Allocate
Select the new Elastic IP, click Actions → Associate Elastic IP address
Choose your instance and click Associate

Now your server always has the same IP. This is the address you'll share with your friends.

8. Connect Lambda to Your EC2 Instance

Now that you have your EC2 instance, head back to your Lambda function.

Add the Instance ID environment variable:

Go to Configuration → Environment variables
Click Edit → Add environment variable
Key: INSTANCE_ID
Value: your EC2 instance ID
Click Save
Back in the code editor, uncomment the INSTANCE_ID line and hit Deploy

Add IAM permissions so Lambda can control your instance. IAM (Identity and Access Management) is how AWS controls what services are allowed to do. Go to Configuration → Permissions, click the role name, hit the Add permissions dropdown, and create an inline policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "arn:aws:ec2:YOUR_REGION:YOUR_ACCOUNT_ID:instance/YOUR_INSTANCE_ID"
        },
        {
            "Effect": "Allow",
            "Action": "ec2:DescribeInstances",
            "Resource": "*"
        }
    ]
}

This gives Lambda permission to start, stop, and check the status of your EC2 instance. Notice we're scoping StartInstances and StopInstances to your specific instance ARN instead of using *, so Lambda can only touch this one instance. DescribeInstances uses * because it doesn't support resource-level permissions.

Want to restrict who can use the bot commands? Discord lets server admins control that through Server Settings → Integrations. Check out Discord's command permissions docs for details.

9. Try It Out!

Head over to your Discord server and test your bot:

Type /server start and wait for the instance to boot up
Type /server status to confirm it's running
Open Minecraft, connect to your instance's public IP, and play!
When you're done, do /server stop to shut down and save money.

Lambda and API Gateway fall under the AWS Free Tier. The main cost to watch is EC2 if you size up for more demanding games.

We've now got our Minecraft server up and running. Let's hop in! Join the Minecraft server using your EC2 public IP as the server address: <your-ec2-public-ip>:25565

Your friends can start or stop the server at any time with the Discord bot.

Happy crafting!

Appendix: Cleanup

If you want to tear everything down, delete these resources: