DEV Community: Lucas Swanson

Code on the Road: Manage Agent Fleets Remotely Using Kiro Crew

Lucas Swanson — Fri, 28 Aug 2026 23:11:01 +0000

Plus, four features of Kiro Crew that unlocked productivity I never thought I'd have.

I'm testing AWS services on a weekly basis, so I use agentic coding tools to stand up AWS apps all the time. I had one thing on my "AI developer tools capabilities from AWS" wishlist... intuitive control over my agents. I wanted to let my agents loose to build anything I tell them, while retaining control over which tools and shell commands they execute.

It seems that my wish was granted by the team behind Kiro, the agentic coding assistant built by AWS. They recently released Kiro Crew, an open-source agentic development platform that augments Kiro with new functions while retaining its most helpful features. Let me show you some of my favorite features of Kiro Crew that have more than doubled my development speed.

But first... What is Kiro Crew?

Kiro Crew is a workspace optimized for managing multiple complex agent workloads. Think of it as an augmented interface for the Kiro agent infrastructure. You're using the same underlying Kiro agent, but with an expanded agent harness that brings more flexible chats, pre-built apps, and other features that improve your ability to interact with the agent you already use.

I've been trying every which way to build code in Kiro Crew, and I've already implemented a few of its features into my daily work, including custom agent profiles, CRON jobs, and even just the new UI layout. One feature has completely changed the game for me, though, and that's Kiro Crew's Channels feature.

1. Kiro Crew Interfaces (Slack, Telegram, Discord, etc.)

Interfaces (referred to as "Channels" in some docs) allow you to connect Kiro Crew to platforms like Slack or Discord, primarily through the Kiro Crew Gateway. For example, I created a Slack app on my company's Slack environment through which I can control Kiro Crew when its active on my laptop. This includes starting and communicating with chat sessions (tagging it with @kirocrew and sending a prompt), configuring settings (/kirocrew config), toggling YOLO mode (/kirocrew yolo, auto-approve all commands for 6 hours), and even switching between Kiro Crew Agent profiles (/kirocrew agent, which lets you switch between pre-configured agents that are specialized for different tasks).

Monitor Time-Consuming Jobs Away from My Desk

I'm no saint when it comes to discipline with my agents, as I love to let them loose on my codebase as much as the next guy, but I strictly prohibit my agents from running destructive commands without my approval. As such, when building complex apps for internal workflows, workshops for our Student Builder Groups, et cetera, I often get several tool requests every minute. I review the reasoning behind every shell command, and while it leads to a better overall product, I know that my workflow will get hung up on an approval prompt within a minute of me leaving my computer.

Now, with the Slack channel configured, I get approval requests sent straight to my phone through the connection I set up between Slack and my instance of Kiro Crew's gateway.

In this example, I ask Kiro Crew to review my recent projects, create a markdown file listing open issues in my code, and save it as a to-do list in my Projects directory.

As it builds, it will stop it's own turn if it encounters a design decision that would impact how it builds the project going forward, like in this example.

Now, I'm fully set up to continue my projects from anywhere, without splitting my committed code between devices. Follow these steps to set up a connection to your preferred platform.

2. Kiro Crew Task Runner

Task Runner is a built-in App designed for orchestrating massive multi-agent tasks. If you've used the Kiro IDE, you can think of Task Runner as a similar workflow. Task Runner will ask you to "describe your task". You can either click "Run" right out of the gate (similar to "Vibe Mode" in the Kiro IDE), or you can click "Refine into Spec" to have Kiro organize your prompt into an actionable task list for Task Runner to design the workflow against (similar to the Kiro IDE's "Spec mode" workflow).

You can also select which Agent profile will handle your task, which lets you select a model to use.

The initial task list was broad (unsurprising, given the one-sentence prompt I used to begin with), so I had a separate agent use Sonnet 5 to create a task list to feed to Task Runner.

Once you direct it to execute your task, it orchestrates subagents to tackle the task list in parallel. Each agent retains its own context window and focuses on a specific subtask, improving each individual agent's performance and reducing the likelihood of hallucinations compared to dumping everything into one agent.

Now, I can let this agent run in the background as I work on other tasks, or walk away from my computer. *NOTE: If you do not enable "YOLO" mode, Kiro Crew will still ask you for your approval to execute commands if commands are not pre-approved.

An hour or so later, with no interruptions, I returned to a completed chunk of development work. A quick playtest confirms the changes I made were implemented.

3. Kiro Crew Scheduled Tasks

Kiro Crew lets you run pre-structured agentic workflows on your device. By default, Kiro will stagger your LLM-backed CRON jobs in order to not throttle your computer's resources, but you can turn this off as a setting. You can select an agent / model, write the recurring prompt, and even select a channel within an Interface (slack / discord, etc) to send your report to.

Here's an example of a scheduled job I've set up on my machine.

Here's the full prompt:

"Every morning at 9:00am EST, generate and send a report in slack detailing the following:

Memory constraints on my device (and how constrained Kiro Crew is due to memory)

Active tasks being worked on by agents

Design gaps and unfinished work that either needs to be completed or is blocked requiring a design / architecture decision from me, the developer.

This report should be organized into clear sections, have concise action items, and only include relevant information I need to get up to speed. I will ask clarifying questions if need be, so err on the side of conciseness. NO FILES SHOULD BE CHANGED WHATSOEVER ASIDE FROM A REPORT IN A MESSAGE SENT VIA THE SLACK INTERFACE."

After test running the report, here's the result, right in my Slack environment so I can get notified and read it from my phone:

NOTE: The Scheduler will NOT retry jobs if the gateway is offline at the scheduled time for the job. You may have to re-run a job if your connection to the gateway is disconnected.

4. Persistent Preference Memory

Kiro Crew learns how you work. It analyzes your development habits as you use the platform, quantifies your development philosophy, and adheres to your preferences as you build projects.

How It Works

Every interaction you have with Kiro Crew feeds into a persistent memory layer. When you reject a suggestion, approve a command, rewrite generated code, or configure a setting, Kiro Crew logs that decision. Over time, these observations compound into a development profile that influences how Kiro approaches your projects.

For example, when I direct an agent to execute multiple tasks, I tend to ask it for a summary of changes along with several passed tests for each artifact it builds. After just a week or two of using it, this is now a default behavior my instance of Kiro Crew employs in response to my multi-task prompts.

Sessions: Context That Persists

Kiro Crew organizes work into Sessions, which are persistent conversation threads that maintain full context across days or weeks. Unlike a typical chat window that resets when you close it, Kiro Crew Sessions retain:

The full conversation history and decisions made
Files created, modified, or referenced
Tool approvals and rejections you've issued
Architectural decisions and their rationale

This means you can close your laptop on Friday, reopen a Session on Monday, and pick up exactly where you left off. Kiro Crew remembers what you were building, what constraints you established, and what approaches you already tried and rejected.

Memory in Practice

I have a few preferences that I've never explicitly documented anywhere:

I prefer functional React components with hooks over class components
I want error handling to be explicit in most of my MVPs, to make it easier for me to debug when playtesting
I deploy to us-east-1 unless there's a latency reason not to

After about a week of working in Kiro Crew, these preferences were internalized. When I spin up a new project, the scaffolding already reflects my conventions. When I ask for error handling, it writes explicit try/except blocks with logging rather than bare except: pass patterns.

Managing Your Memory

You're not locked into learned behaviors, however. Kiro Crew exposes your preference memory through the settings panel, where you can:

View all learned preferences with confidence scores
Edit or delete specific memories
Pin preferences you want enforced regardless of context
Scope memories to specific projects

This is the feature that compounds over time. The longer you work with Kiro Crew, the less friction there is between your intent and the output. It's the difference between dumping thousands of tokens of context every session just to catch your agent up to speed, versus maintaining a seamless flow between session refreshes.

What to take away

Kiro Crew turned me from a basic AI user to an agentic puppet master, and my agents feel more efficient than ever... now, I encourage you to try integrating Kiro Crew into your workflow the same way. By consolidating all of your sessions, enabling control of Kiro from your phone, and waking up to automatic performance reports and to-do lists, Kiro Crew helps maximize your productivity across complex projects.

Give these features a try yourself, starting at the installation page!

How I Keep My AI Coding Agent Costs Down as a Student

Lucas Swanson — Mon, 10 Aug 2026 14:31:06 +0000

I graduated from undergrad the year that ChatGPT was first released to the public, and I'm now applying to Master's programs for the Fall. As we inch away from the educational realm I knew, an era ruled by StackOverflow and Chegg, I can't help but think how different my learning path would have been had I had access to these tools back then. Depending on your self-control, AI can either give you a competitive edge, even over others using LLMs for everyday tasks, or it can sneakily lead your learning to a plateau.

But, with great power, comes great responsibility. And no, I'm not just talking about the learning cost of using AI maliciously in an academic context (i.e. cheating on exams or labs), but also in financial cost. Every prompt, response, and tool call burns tokens, and tokens cost money. And given the control Chipotle had over my bank account in college, I was sticking to free tiers wherever I could. I assume you are too.

For the money you can spare, however, AI coding agents can build complex apps, explain concepts, and create study resources to help you reinforce your learning. Well-scoped prompts, frugal model choice and appropriate MCP server usage can use a tenth of the tokens of a rambling prompt, maximizing value per request and stretching out that usage window each month.

After applying to some Master's programs, and coding extensively in conjunction with editors like Kiro and Claude Code, I've settled on a few habits that postpones that dreaded "Try again tomorrow at 5:30pm" message in my chat window. Here's three of those habits.

1. Prompt Engineering (Yes, it's a real skill)

When LLMs first started gaining traction and people started talking about "Prompt Engineering", it felt like a snobby title. I thought "you know what chatgpt is, and you know how to write... so what?". Comedians were going on Jimmy Kimmel saying they asked ChatGPT what it thought, my roommate was asking ChatGPT how to make a comeback to my joke... it just seemed like people considered them more technical for knowing how to ask a genie a question.

But this is 2026. Models are smarter, MCP reduces model guesswork, and the software industry is innovating faster than ever. As such, there is MUCH to be gained in reducing your token usage, and Prompt Engineering encompasses that first critical skill; accurately and concisely structuring your request.

With that in mind, the most expensive prompt is one where the agent has to guess. So, when prompting, you should...

Show up with a plan, not a blank page. I don't ask the agent to design my whole system if I already know roughly what I want. If my assignment calls for a REST API with a database and a couple of endpoints, I say that directly. I don't make the agent spend tokens rediscovering decisions I've already made in my head.

Say what you're sure about, and flag what you're not. If your class requires Python and Flask, say so up front. If you genuinely don't know whether to use SQLite or Postgres for a small project, say that's the part you want the agent's input on. This tells the agent where to just execute and where to actually reason, and reasoning costs more tokens. "Build me an app" forces the agent to guess at dozens of small decisions and explain each one. "Build me a Flask API with these three routes, and suggest the best way to handle rate limiting" puts the expensive thinking exactly where you need it and nowhere else.

When I'm unsure which tool is best, I'll just do some research with Gemini to try and make a decision before asking my coding agent.

Compress your prompt with a free model first. Before sending a long, complicated prompt to your paid agent, paste it into a free-tier model (ChatGPT's free tier, Gemini, whatever you have access to) and ask it to tighten the prompt without losing any meaning. You're paying by the input token, so a shorter prompt with the same information is money back in your pocket.

Shape your prompt around the MCP tools you can enable.
MCP serves as a structure to streamline repeatable actions you expect your agent to take. Skills are contextual instructions, like a ruleset or a workflow, whereas Tools provide pre-written executable functions, standardizing how the agent should perform a task.

Telling your agent which MCP tools and skills to reach for will further reduce the guesswork required to accomplish your task. The difference between "What EC2 instance types fall within my budget?" and "Use the AWS Documentation MCP to identify which EC2 Instance Types fall within my budget" may be semantically minor, but it removes the need for the agent to parse it's entire MCP library, and that habit compounded over dozens of sessions will save you significant amounts of credits.

2. Match the Model to the Job

Not every task needs the most powerful model available. Picking the right model for each task is the simplest way to optimize your inference spending.

Look up how the models compare on your current task. Benchmarks like SWE-bench and HumanEval show which models are strongest at writing and debugging code versus which ones are better at prose. Know the strengths of whatever models you have access to.

Check what each model actually costs you. In Kiro (an AI coding IDE), for example, you can see how much credit each model uses relative to "Auto" mode, which picks a model automatically based on how complex your prompt looks. Auto is convenient when you're not sure, but knowing the relative costs lets you choose deliberately when you already know the task is simple or hard.

A frontier model (like Claude Opus 5, GPT Sol) is worth the extra cost for multi-file projects, tricky debugging, or anything where the agent needs to hold a lot of context at once. Yes, it costs more per token. But a wrong implementation that takes three rounds of fixing costs more overall than getting it right the first time.
A lighter model (like Haiku) is plenty for writing docs, generating boilerplate, drafting a README, or formatting code. These tasks don't need deep reasoning, and a cheaper model handles them just as well.

The rule of thumb: if the task requires the agent to think, use a strong model. If the task just requires the agent to type, use a cheap one.

3. MCP Tools: Let the Agent Check Instead of Guess

Model Context Protocol (MCP) servers are probably the most overlooked way to cut costs. An MCP tool gives your agent direct access to real information (documentation, live APIs, code search) instead of making it guess based on whatever it remembers from training.

Without a tool, an agent has two options when it needs a fact it doesn't have memorized: guess and risk being wrong, or ask you and burn your time and more prompt tokens. An MCP tool call is cheap: a quick lookup that returns the exact right answer. Compare that to the alternative, where the agent writes a plausible-looking but wrong API call, you catch it, you explain the fix, and the agent tries again. That round trip alone can cost four times as many tokens as just looking the answer up in the first place.

Two that I use regularly:

AWS Agent Toolkit gives your agent additional tools to improve it's efficiency. Enable your agent with direct search access to current AWS docs, drastically improve your agent's ability to build AWS applications, and more. Check out my colleague's video walking you through how to make the most of AWS Toolkit here, and see if it can help you study.
Strands MCP helps your agent build other agents. If you're working on a multi-agent project, this saves you from having to paste boilerplate framework code into context repeatedly.

A single documentation lookup might cost a few hundred tokens. The alternative (wrong answer, correction, retry) easily runs into the thousands. Over a semester of daily use, that adds up fast.

Keeping an Eye on What You're Spending

The three habits above reduce cost. This last one is about actually seeing it, because you can't fix what you can't measure.

Kiro's dashboard updates every few minutes and shows your credit usage against your monthly pool, plus a per-interaction cost right in the notification bar. For more detail on credit usage and limits, you can use the '/usage' Kiro command. Use the following command in the Kiro CLI:

/usage

Try running this in a separate terminal while you work.

Once you've watched your usage for a week or two, predicting cost gets easy. Kiro's Auto mode is the baseline (1x), and other models are published as multipliers against it, so if a task usually costs half a credit in Auto, you can estimate what switching models will cost before you commit. You'll also start noticing patterns: a quick bug fix costs one thing, building a whole feature costs several times that, and pasting a 500-line file into context costs more than pointing the agent at the 30 lines it actually needs (roughly one token per four characters, as a rule of thumb).

The Point of All This

Overall, the name of the game is to reduce your agent's guesswork. Every design decision you make concretely, every MCP tool you set up, and every unnecessary word you eliminate from your prompt all reduce the amount of inference your agent has to perform (and charge you for) to complete your task.

You end up with the same quality of work for a fraction of the credits, which matters a lot more when you're working on a student budget as opposed to an enterprise. Employing these skills in your project will position you well for a software industry where AI is critical infrastructure.

Thanks for tuning in.

EC2 101: Servers-as-a-service

Lucas Swanson — Wed, 18 Mar 2026 19:10:01 +0000

When I first started on AWS, I struggled to understand virtual compute. I picked T3 micro for everything because it was cheap, and for most use cases, it did the job. Sticking to one type of EC2 instance, however, is like picking one screwdriver size from your toolbox for everything... it may work for several projects, but you're creating more work for yourself if you don't select the right tool for the job. Now, I can't just select a random instance for my projects. I actually need to know what these instance types mean.

EC2 is the foundation of almost everything we build on AWS. The decisions we make in those first five minutes from considering instance types, security groups, storage, and networking will heavily influence the success of our projects. By the end of this article, you'll understand when EC2 can be useful in your projects AND be able to spin up EC2 instances for your use cases.

What is EC2?

EC2 stands for Elastic Compute Cloud. At its core, it's a virtual server running in an AWS data center. Think of it like a “server rental”, where you can shop pre-built servers designed to host specific types of applications, then “rent” space on those servers as needed. Rather than a virtual server or machine, we call it an instance. When you launch one, you pick the specs, you pick the operating system, and then you can be up and running in minutes. The elastic part is what's really key here. You can add computing resources to, remove computing resources from, or launch hundreds of instances on demand.

You may be comfortable with your current setup, however, given that you've been able to build hobby projects with no trouble. So that begs the question...

Why should I use an EC2 instance instead of running my app locally?

Think about the town that you live in, and what methods of transport you use. You may drive a car for daily transit, ride a motorcycle to save money on gas and take it for joyrides, or use a moving truck when you’re moving between homes. Do you personally own and maintain a car, motorcycle and a moving truck? Maybe you would if you owned a moving business, needed a daily driver for running errands, and enjoyed riding a motorcycle for fun. Most people, however, rarely use a moving truck, and some don’t even drive a car if their city has good public transit. Those folks wouldn’t own the moving truck... they would just rent it for the time they need it.

Imagine that you’re building a house on an empty plot of land. You’ll need some heavy equipment to build that house, including an excavator to dig the foundation, a crane to lift scaffolding, maybe a concrete mixer to lay a base layer for the house to sit on. Would you buy the excavator, crane, and concrete mixer outright, use it to build the house and just... keep them around? I’d bet that you’d rather just rent the equipment for the time you need it.

That’s what you’re doing when you spin up an EC2 instance. Lets say you’re training a machine learning model, and you only have access to a laptop with minimal graphics capacity... not very strong computing power, which is essential for fast model training. Would you buy a whole new computer to train these models, or would you rent access to an existing server for the exact computing time and computing capacity your model needs to be trained? If you chose the latter, EC2 provides that service.

EC2 has many instance types, each built for different types of workloads. EC2 can also scale automatically depending on how much traffic or compute power you demand from it. Your laptop, on the other hand, can’t install more graphics cards into itself instantly when a program bottlenecks it’s capabilities.

Now, before we launch our own EC2 instance, let me break down six key components you need to know about.

Amazon Machine Image (AMI): The Amazon Linux AMI is a maintained Linux image provided by AWS for use on Amazon EC2. It offers a stable, secure environment for running applications and includes packages for easy AWS integration, such as launch configuration tools and popular AWS libraries. AWS provides ongoing security and maintenance updates for all instances running the AMI, at no additional charge to EC2 users.
Instance Type: This is your instance's hardware specs. It defines the CPU, memory, storage, and network. We'll dive deeper into this later in the demo.
Key Pairs: With this you're able to authenticate and connect to your instance via SSH or RDP. If you are using Windows, when you use a key pair, AWS holds the public key. You hold the private key, but remember to always store this safely. Losing it can mean that you're locked out of your instance.
Security Groups: You can look at these as a stateful firewall that controls traffic that goes in and out of your instances.
Networking: This is a component that we need to discuss without going too deep. Here's what you need to know when it comes to networking on AWS. The Amazon VPC, or Virtual Private Cloud, allows you to configure subnets where you launch your instances into. These subnets can be public or private, with public subnets having a route directly to an internet gateway and private subnets not exposed to the internet. Within the VPC, you have full control over how you configure this. If you're interested in knowing more about the Amazon VPC, let me know in the comment section below.
EBS Volume (Amazon Elastic Block Store): This is a separate disk or storage that persists independently from your instance. We'll discuss why this matters later in the demo.

In this demo, we're going to launch an EC2 instance as a web server that we can connect to from the internet. To connect to the instance, we'll use Session Manager, a fully managed service that provides secure, auditable, and browser-based remote access to your EC2 instances. This means we won't need a key pair. To make this work, we first need to create an IAM role.

Part 1: Create an IAM Role for Session Manager

In the AWS Console, search for "IAM" and open the IAM console.
Click on "Roles," then click "Create role."
For the trusted entity type, select "AWS service."
Under use cases, select "EC2." Then select the additional use case "EC2 role for AWS SystemManager." This will allow us to connect to our instance via System Manager.
Click "Next." You'll see the policy that is already attached to this role. This is what allows browser-based access to your instance.
Click "Next" and enter a name for the role. We'll use ec2-ssm-role.
Verify the policy is attached in Step 1: “Select trusted entities” and click "Create role."

Part 2: Launch the EC2 Instance

Back in the AWS Console, ensure you are in the correct region. Select the region closest to you or your users. For example, if you're on the West Coast, select "US West 2 (Oregon)." If you're on the East Coast, "US East 1" may be a better fit. Remember, you want to select the region that will be geographically closest to your users as possible, whether that's you or your user base, to lower the latency for the average request.
Search for "EC2" and open the EC2 console. Click "Dashboard" in the left side menu.
Click "Launch Instance".
Enter a name for your instance. We'll use My First Instance.
Under "Application and OS Images," select "Amazon Linux." This is the AMI we will use for this session, and it provides all the AWS tools and features we need to work directly with AWS. You can optionally select the architecture (x86 or ARM). We'll leave this as default.
Under "Instance type," you can compare the different types of server. Don’t be intimidated by the instance type names. My colleague Brooke Jamieson wrote a wonderful article demystifying instance type naming conventions in AWS. For this demo, select t2.micro.

This falls under the free tier, which helps save on costs. If you're unsure which instance type to choose, you can click "Get advice," enter your workload requirements (e.g., web hosting, low cost), and AWS will provide recommendations. You can also click "Compare instance types" to view configurations side by side.
Under "Key Pair," select "Proceed without a key pair." Normally, best practice would be to generate a key pair, but for demonstration purposes we will be using SSM instead.
Under "Network settings," use the default VPC. AWS comes preconfigured with a VPC in each region that includes subnets, security groups, an internet gateway, and everything you need to launch instances and connect to the internet.
Under "Security groups," create a new security group. Allow SSH traffic (port 22) from "My IP" so that only your personal computer can access the instance via SSH. You also have the option to add HTTP and HTTPS traffic, but we'll configure that later.
Under "Configure storage," leave the default of 8 GB of EBS. You can increase this if needed.
Under "Advanced details," find the "IAM instance profile" dropdown and select the EC2-SSM-role we created earlier. This is what allows SSM to be accessed from our EC2 instance.
Click "Launch instance."

Part 3: Connect to Your Instance via Session Manager

Click on your instance ID to view its details. You'll see the state is "Running" and the status check says "Initializing." Three status checks need to pass before you can log in. You can also access this info by clicking on the "Instances" option in the left-side EC2 menu.
While waiting, scroll down to the details section. Here you'll see the instance ID, public IP address, private IP address (for access within the VPC), public DNS address, hostname, instance type, and all the configurations we set up.
Once all three status checks have passed, select your instance and click "Connect."
Select "SSM Session Manager" and click "Connect." If the Connect button is grayed out, your instance is not fully loaded yet. Wait and try again.
You're now inside your instance via the browser. Now, we can verify the identity of the users logged in to the instance. To verify, type:
```
whoami
```
You'll see the logged-in user is ssm-user.

Part 4: Install and Start a Web Server

First, update your instance:
```
sudo yum update -y
```
sudo literally means “Super User Do”. This runs the command as a super user. yum is the package manager for Amazon Linux. Think of it like an app store for your instance. update checks for the latest versions of everything installed, and -y auto-confirms so you don't have to approve each update.
Install Apache, one of the most popular web servers in the world:
```
sudo yum install httpd -y
```
Start the Apache web server:
```
sudo systemctl start httpd
```
Enable Apache to start automatically on reboot:
```
sudo systemctl enable httpd
```
Verify that Apache is running:
```
sudo systemctl status httpd
```
You should see the status as "active (running)" and "enabled."

Part 5: Fix the Security Group to Allow Web Traffic

Go back to the AWS Console and copy your instance's public IP address. Paste it into your browser. You'll notice the page doesn't load. You get a blank page or a connection error.
This is because our security group only allows port 22 (SSH). To access our web server, we need to allow port 80 (HTTP). Remember, the security group is a stateful firewall. If we don't allow the traffic, it will be denied.
In the EC2 console, go to your instance's "Security" tab and click on the security group.
Click "Edit Inbound Rules."
Add a new rule: Type "HTTP" (port 80), Source "Anywhere." This means anyone on the internet can access your web server via HTTP. We're not configuring HTTPS here because that requires a certificate.
Click "Save rules."
Go back to your browser and refresh. You should now see the default Apache test page.

Part 6: Customize Your Web Page

Back in your Session Manager terminal, run:

sudo bash -c 'echo "<h1>Hello from EC2</h1>" > /var/www/html/index.html'

This writes a simple HTML header to the Apache default index file.
Go back to your browser and refresh. You should now see "Hello from EC2."

You now have a running, customized web server in the AWS cloud.

Finishing Thoughts

Your discipline and focus have paid off, dear developer. You've created an IAM policy to control traffic, selected an EC2 instance type, started an instance and run your code on an AWS managed server. You can now officially tell your friends you "build software in the cloud". That's pretty cool if you ask me.

I challenge you to build more complex applications using EC2, and try to incorporate new instance types into your architectures. Alternatively, if this is your first step on your cloud journey, I challenge you to migrate a project from a class, club or hobby onto the cloud using AWS services. If you're an advanced developer, consider the AWS Compute Optimizer to brainstorm ideas to optimize your architecture to reduce cost. Most importantly, if there's anything I hope you learned today... it's that Lamborghini's are cheaper to rent.

Until next time,
Lucas