Defining the Problem and Industry Focus

Before building a Vertical AI Agent, the first step is to clearly define its purpose. Unlike general AI, which tries to solve a wide range of problems, a Vertical AI Agent must be laser-focused on a specific task within an industry. For example, you wouldn’t build a Vertical AI Agent to write poetry and detect fraudulent transactions. That would be like hiring a famous chef to fix your car.

Key Questions to Ask:

• What business function will this AI automate or improve?
• Is there enough industry-specific data to train the AI effectively?
• Does the AI need to integrate with existing company workflows?

Example Use Cases:

• Healthcare: AI that helps radiologists detect abnormalities in X-rays.
• Finance: AI that flags potentially fraudulent transactions in real-time.
• Retail: AI that predicts which products will sell best in different seasons.

The better you define the AI’s job upfront, the more useful it’s going to be. No one wants an AI that just makes educated guesses of what to do.

Collecting and Preparing Data

Data is the fuel that powers AI. But unlike broad AI models that use massive general datasets, Vertical AI Agents need high-quality, industry-specific data to specialize in their task.

Data Sources for Training

• Structured Data: Spreadsheets, databases, transaction logs
• Unstructured Data: Text documents, images, audio recordings
• APIs & External Feeds: Real-time financial data, legal updates, medical records

Data Cleaning and Preparation

Before AI can learn from data, it has to go through a serious cleanup. You know the term, “garbage in, garbage out”? Well, that’s not just true for junk food and bad reality TV (Survivor is good — don’t fight me on that). AI is the same way. If you train it on messed up, inconsistent data, don’t be surprised when it starts spitting out nonsense.

This means removing duplicates, filling in missing info, and making sure all the formats match up. It’s like making soup. If half your ingredients are expired, you wouldn’t just throw everything in and hope for the best, right? AI is the same. It can’t magically fix bad data, so we have to clean it up first.

Oh, the soup I make is canned, so there’s that…

Choosing the Right AI Model

Ok, so now we have clean data. Now what? We need to pick the right AI model. Not all models work for all tasks. You wouldn’t use Google Maps to write an essay, right? Well maybe geography essays, but I digress…

Where Different Models Fit in Vertical AI:

• Large Language Models (LLMs) like GPT-4o, Claude, and Gemini
  • Great for anything text-based (contracts, chatbots, customer emails).
  • Example: A legal AI agent reviewing documents might use Claude, known for longer context windows, or GPT-4o, optimized for fast, accurate responses.
• Vision Models like OpenAI’s DALL·E, Google’s Gemini, Stable Diffusion, and even Midjourney
  • Best for image generation and computer vision tasks (medical imaging, quality control in factories). Models like Midjourney are mainly used for creative image generation, but could help in design-heavy industries.
  • Example: A radiology AI might use Google’s DeepMind models for X-ray analysis, while a fashion AI might use DALL·E for virtual clothing design.
• Custom Models & Fine-Tuned Engines
  • For companies that want something really specific, like an AI that can detect tax fraud but only for restaurants (because yes, that’s a thing).
  • Example: A fraud detection AI might not use GPT-4o but instead fine-tune a financial anomaly detection model on proprietary transaction data.
• Hybrid Models (RAG + API Integrations)
  • Sometimes, workflows mix and match models. Like a chatbot that pulls live product data using an API. It’s kind of like a Swiss Army knife, but for AI.
  • Example: A customer service chatbot might use GPT-4o for conversation, RAG to pull knowledge from an internal database, and an external API to check inventory in real-time.

Examples of When to Use Model Types?

(As of this writing)

How to Choose the Right Model for a Vertical AI Agent

• Define the problem: Is it text-heavy, image-based, or predictive?
• Decide on real-time vs. batch processing: Does it need instant responses or deep analysis?
• Evaluate cost vs. accuracy: Can a general LLM work, or does it need fine-tuning?
• Consider integration needs: Does it need API access to external data sources?

Types of AI Models Used in Vertical AI:

• Supervised Learning: When “labeled data” is available, which basically means examples that have both the input and expected output defined. For example, training an AI to identify fraud using past fraud cases. I remember reading about a bank that trained its fraud detection AI on old data, and it kept flagging legit transactions because consumer habits had changed. AI is only as good as the trends it learns from. And, if you’ve ever looked at Twitter (especially “X” ?) trends, you know that’s a terrifying thought.
• Unsupervised Learning: When patterns need to be discovered, like customer segmentation in retail.
• Reinforcement Learning: When AI learns through trial and error. It’s like training a dog — give it a treat (for AI, some more tasty data to chew on) when it gets something right, and it will learn to repeat that behavior.

Many companies don’t build AI models from scratch. Instead, they fine-tune existing pre-trained models using their own domain-specific data. APIs and cloud-based AI services can make this process more efficient.

Training the AI Agent

Therefore, training AI means feeding it data and allowing it to learn patterns. This process typically involves:

• Batch Training: Training the AI in steps to adjust its accuracy.
• “Hyperparameter” Tuning: Tweaking model settings to improve performance. Fancy word… Think of hyperparameter tuning like adjusting settings on a camera. Too much brightness, and the image is washed out. Too little contrast, and details disappear. (I asked my wife about this one. She’s the professional photographer ?). AI training is full of these small adjustments.
• Performance Testing: Checking how well the AI performs on new, previously unseen data.

Tools Used in AI Training:

• TensorFlow / PyTorch: Open-source AI frameworks for model training.
• AutoML Platforms: Google AutoML, Microsoft Azure ML, Databricks AutoML, and AWS SageMaker for training without extensive coding.
• Custom Training Pipelines: Built-in enterprise AI systems tailored for specific use cases.

Once the AI reaches a good accuracy level, it’s ready for deployment.

Deploying the AI into a Workflow

A Vertical AI Agent must integrate into a company’s workflow and existing tools to be useful.

Ways to Deploy AI Agents:

• As an API: AI runs in the cloud and serves results via API calls, like fraud detection as a service.
• Embedded in Software: AI is built into business applications, such as AI-powered chatbots in customer service tools.
• Standalone AI Assistants: AI works as a separate tool, like an AI-powered document reviewer for legal teams.

By embedding AI into workflow automation, businesses can maximize efficiency and create seamless, repeatable AI-driven processes. I find this to be one of the coolest uses of AI. It’s like having a digital assistant that never sleeps (and doesn’t need coffee — thinking of how much money I’d save!).

Even for personal tasks, workflow automation can help simplify the more painful tasks we have to perform in life. For example, I’m currently working on automating an existing, documented, manual workflow for preparing tax return breakdowns for my accountant. Look at the date — I better hurry! It’s a bunch of work now, but I can then do this in a fraction of the time starting next year.

Continuous Learning and Optimization

AI isn’t a “set it and forget it” tool. If industries evolve, the AI needs to, also. This means retraining it with fresh data, fine-tuning its accuracy as new trends emerge, and, of course, making sure humans stay in the loop to catch weird mistakes before they spiral out of control.

Companies use workflow automation to keep AI running smoothly. The circle of AI life — using AI to help AI — really not as scary as it sounds. For the foreseeable future, I believe humans will remain the clearinghouse for all AI processes. As long as we don’t forget how to think, you know, with AI doing all that thinking for us these days.

AI can update itself constantly, but humans need to sleep, eat, and take vacations. Yes — we need vacations ?. Workflow automation helps AI keep running 24/7 without burning out — unlike us!

Wrapping Up

Building a Vertical AI Agent isn’t just about training a model. It’s about integrating AI into a specific industry, fine-tuning it with the right data, and making it a seamless part of real-world workflows.

To recap:

1. Define the problem and industry use case.
2. Gather and clean data to ensure quality.
3. Select the right AI model for the job.
4. Train the AI using machine learning techniques.
5. Deploy AI into a workflow so it delivers real business value.
6. Continuously update and improve the AI to keep it relevant.

Okay, that was a lot of info. But, if you’ve stuck with me this far, you now know that building a Vertical AI Agent isn’t just about throwing data at an algorithm and hoping for the best. It’s about giving AI a real job, setting it up with good data, picking the right tools, and making sure it keeps learning.

Next time, we’ll skip the theory and look at real-world AI Agents already making a difference.

Until then, be polite to our future overlords. They’re making a list, and checking it twice…jk

Just a quick note — I’m writing these articles as if the reader may not be familiar with several of these terms, or if they aren’t in the software field. Even if you have this experience, you may pick up something new.

Retrieval-Augmented Generation (RAG) – AI’s Research Assistant

AI is only as good as the data it’s trained on. But what if you need it to understand a company’s intellectual property (IP) or other proprietary information? Also, what happens when the world changes? AI models trained months ago might give outdated answers. This is where Retrieval-Augmented Generation (RAG) comes in.

How RAG Works

• Instead of relying only on pre-trained knowledge, RAG allows AI to retrieve new information from external sources (like databases, APIs, or the web) when answering a question.
• It’s like an AI that can “Google” things before responding, making sure it has the latest information.

Example of RAG in Action

Imagine a legal AI assistant that helps lawyers draft contracts. Laws change all the time, so instead of only using outdated training data, RAG enables the AI to pull the latest regulations from a legal database before generating a response.

APIs – AI’s Building Blocks

APIs (Application Programming Interfaces) let different systems talk to each other. This is often how developers integrate systems with either third-party or other internal services. They’re also like bridges that connect AI to external data, tools, and applications.

Why APIs Matter for AI

• Access to external knowledge: AI can fetch real-time stock prices, weather updates, medical records, etc. via APIs.
• Access to internal systems: AI can also fetch real-time company data, or integrate with existing internal systems via APIs.
• Faster AI development: Instead of training a new AI model from scratch, developers can use APIs to access pre-trained AI models for tasks like speech recognition, image analysis, or language translation. In other words, AI models can make use of other, third-party, AI models as well.
• Better integration: AI doesn’t work in isolation. As hinted at above, APIs allow AI models to be embedded into apps, websites, and enterprise software.

Example of APIs in Action

Imagine a customer support chatbot that helps users troubleshoot problems. Instead of training an AI to recognize every possible issue, it can use APIs to:

• Pull customer data from a database.
• Check inventory levels if a replacement is needed.
• Retrieve help articles from a company knowledge base.

This makes the AI smarter and more useful without requiring endless retraining.

Workflow Automation – AI That Powers Business Processes

AI models don’t just exist. They need to be deployed, monitored, updated, and, in many cases, integrated into business workflows. Vertical AI Agents often play a key role in workflow automation, where they help automate specific, repeatable company functions. Instead of just acting as isolated models, they become part of an entire automation system that streamlines operations, reduces manual effort, and improves efficiency. Workflow automation helps AI run smoothly without requiring human intervention at every step. This helps free people up to focus on their actual creative and intellectual roles.

How Workflow Automation Helps AI and Businesses

• Data Pipelines: Automates the process of collecting, cleaning, and feeding new data into AI models.
• AI Model Updating: Instead of retraining manually, workflow automation triggers model updates when new data becomes available.
• Real-Time Decision Making: AI can be integrated into business workflows, automatically acting on new insights.

Example of Workflow Automation in Action

A fraud detection AI at a bank needs to stay updated as criminals and hackers develop new tactics. Workflow automation ensures:

• New fraud cases automatically get added to a training dataset.
• The AI model retrains itself periodically.
• The AI’s fraud detection logic updates in real-time, reducing false positives.

Without automation, AI would require constant manual updates, making it inefficient and costly. But beyond updating AI models, workflow automation ensures that Vertical AI Agents can be embedded into core business processes; whether that’s automating customer service workflows, optimizing logistics, or improving financial reporting.

Bringing It All Together

So to build a powerful Vertical AI Agent, you don’t just need a well-trained model. You need tools to keep it smart, connected, and adaptable:

• RAG keeps AI up-to-date by retrieving the latest information from internal and external resources.
• APIs give AI access to external data and services for real-time insights and data.
• Workflow automation ensures AI keeps improving without constant manual intervention.

These technologies transform AI from just a trained model into a fully functional, continuously learning, and self-improving system.

Next time, we’ll cover how Vertical AI Agents are built, discussing the steps, tools, and processes involved.

Just a quick note — I’m writing these articles as if the reader may not be familiar with several of these terms, or if they aren’t in the software field. Even if you have this experience, you may pick up something new.

Feeding the AI – Where Data Comes From

So before a vertical AI can do its job, it needs information. Imagine trying to play a new video game without ever looking at the rules. You may make some educated guesses based on general knowledge you’ve gained playing games over the years. But you’d really have no idea exactly what to do. AI is the same way; it needs examples to learn from.

Where Does the Data Come From?

• Healthcare AI: Medical images, patient records, doctor’s notes
• Finance AI: Transaction logs, fraud reports, stock market trends
• Retail AI: Purchase history, customer behavior, inventory levels

Retrieval-Augmented Generation (RAG) is a method that helps AI find the best and most useful information from huge amounts of data, improving what it learns. We’ll dig into this a bit more in the next article.

Cleaning the Data: Getting Rid of the Mess

AI can’t learn properly if the data is a mess. Garbage in leads to garbage out. Imagine trying to read a book full of spelling mistakes and missing pages. It wouldn’t make sense. That’s why data has to be cleaned before AI can use it. Cleaning means:

• Removing duplicate or useless data
• Filling in missing information
• Making sure all data follows the same format

Training the AI – Learning from Examples

Once the data is ready, it’s time to teach the AI. There are different ways AI can learn, just like us.

Three Ways AI Learns:

1. Supervised Learning: The AI is given “labeled data,” meaning it’s told what’s right and wrong. Think of a teacher grading homework and showing students their mistakes.
2. Unsupervised Learning: The AI is given data but not told what’s right or wrong. Instead, it finds patterns by itself, like a kid sorting Legos into colors without being told how.
3. Reinforcement Learning: AI learns by trial and error, like playing a video game and figuring out what works based on scores and rewards.

AI developers often use pre-trained AI models (like using a pre-made cake mix instead of baking from scratch). APIs (Application Programming Interface) allow AI to access these models to learn even faster. We’ll talk more about APIs in a future article. They have multiple uses.

Fine-Tuning – Polishing AI’s Knowledge

Training gives AI a good starting point, but it’s not perfect. It needs fine-tuning to do its job well. This step is like practicing for a test — learning from mistakes and improving over time.

How AI Gets Fine-Tuned:

• Adjusting settings to improve accuracy (we’ll talk about what these settings are in a future article)
• Testing on new, unseen data
• Removing biases that could cause unfair results

Many AI systems keep learning even after they’re deployed. With workflow automation, AI models can keep updating themselves without needing to be re-trained from scratch every time new data appears.

Putting AI to Work – Deployment

Once AI is ready, it’s time to put it to use. There are different ways to use an AI system:

• Inside apps or software (for example, an AI that detects fraud in banking apps)
• As an API (used by a chatbot that helps customer support teams)
• Standalone programs (like a medical AI that scans X-rays for doctors)
• Inside existing tools we use daily (like Slack, WhatsApp, etc.)

Continuous Learning – Keeping AI Smart Over Time

Just like we need to keep learning to stay sharp and relevant in our field, AI needs updates too. If an AI is trained on old data, it might make bad or outdated decisions. To remain useful, it must keep learning from new data.

How AI Stays Up To Date:

• New training data helps it stay accurate
• Feedback from users helps it adjust and improve
• Error checking helps fix mistakes and biases

As with initial training, AI systems can use Retrieval-Augmented Generation (RAG) to pull in the latest information whenever they make decisions. This helps them avoid outdated answers and stay fresh.

What is Inference?

Once AI is trained, it needs to use what it learned to make decisions. This is called inference. It’s when AI looks at new input and predicts an answer based on what it was taught.

• Example: A fraud detection AI is trained on thousands of real fraud cases. When it sees a new transaction, it infers whether it looks like fraud or not.
• Example: A medical AI learns from millions of X-ray images. When it sees a new X-ray, it infers if there’s a problem.

Wrapping Up

Vertical AI Agents don’t start smart. They learn from data, get trained, and keep improving over time. But learning isn’t enough. AI needs tools to help it stay useful. From Retrieval-Augmented Generation (RAG) to APIs and workflow automation, these technologies help AI work more efficient, stay current, and improve over time. Improving enough to think for itself? Well, that’s a debate for another time.

Next time, we’ll dive deeper into how these tools work and how they help AI stay accurate, relevant, and powerful.

Artificial Intelligence (AI) is impacting up many industries, but not all AI works the same way. Some AI systems act like generalists — they can do a lot of different things but aren’t great at any one job. Jack of all trades; master at none. Others are trained specialists so they can excel in one specific area. These are Vertical AI Agents.

Just a quick note — I’m writing these articles as if the reader may not be familiar with several of these terms, or if they aren’t in the software field. Even if you have this experience, you may pick up something new.

AI vs. Regular Software

Typical software follows predefined instructions, like a cookbook where every recipe has step-by-step directions. But AI learns from experience by looking at patterns in data and improving its output over time.

For example, look at e-commerce recommendation engines like Amazon’s. Instead of following hard-coded rules, it studies what people browse and buy, like a store employee who learns what items to suggest based on what a customer has liked before.

Broad AI vs. Narrow AI – “Swiss Army Knife vs. Precision Tool”

AI generally falls into two categories:

• General AI (the Swiss Army knife) can handle a variety of tasks but isn’t deeply specialized in one. Think about Siri, Alexa, or ChatGPT out-of-the-box. They can answer random questions but they aren’t experts in any one subject. But when models like ChatGPT are fine-tuned, they can become more focused, moving closer toward specialized AI.
• Narrow AI (the precision tool) is built for a specific task. For example, an AI designed to detect fraudulent credit card transactions is focused on that task and wouldn’t be useful for answering trivia questions or writing blog post outlines.

What is a Vertical AI Agent? – “The AI That Masters a Single Industry”

A Vertical AI Agent is an AI system built to work in one specific industry (“vertical”). It’s designed to handle tasks within that domain better than a general AI could. For example:

• Healthcare AI that assists doctors by analyzing medical images for early disease detection.
• Finance AI that monitors transactions to detect fraud before it happens.
• Music AI that helps sound engineers tweak levels for perfectly balanced tracks (something I’ve been using for my music).

AI agents don’t try to be everything to everyone. Rather, they focus on one field, like a developer who specializes in a single tech stack and eventually becomes an expert.

Other Info

AI Training and Model Optimization: AI models don’t start out smart. They need to be trained. The more relevant data they analyze, the better they get. It’s like debugging code — test, refine, reiterate, and optimize until it works correctly.

Why More Data Improves AI Accuracy: AI works best when trained with diverse, quality (and often high-volumes of) data. The more real examples it can learn from, the better its predictions become. Like as a developer writes more code, they get better at troubleshooting and problem-solving.

What’s Next?

Now that we know what Vertical AI Agents are, my next article will explain how they’re built. We’ll break down how they gather topic-specific data, train on real-world examples, and get deployed to solve specific problems.

I love Dropbox. It has saved me so much time. It’s the most reliable synchronizing software I’ve used. But beware of a fatal flaw I came across last week, which was almost a disaster.

I’m a backup fanatic. I have four copies of everything locally, and three more copies of everything in cloud services.

But I did not include my Dropbox folder in that set of backups. Because, you know, Dropbox.

On my 8-year-old MacBook Air (my traveling Mac machine), I have my Dropbox folder on an external drive. The internal drive is simply too small. If I restart the system without the drive connected, I properly get a simple warning, and I temporarily disable it. But last week the machine was already booted up, and the drive was connected. While moving things around to clean the room it was in, the drive got disconnected. I was unaware that this happened, so I did not yet reconnect it.

But Dropbox considered that to mean “delete all Dropbox files.”

All my files were disappearing on all the machines where I had Dropbox installed. I mean like five different machines. I noticed this when a development project I was working on started failing. I saw it was due to files disappearing. Panicked, I scrambled to turn off the automatic start setting of Dropbox on each machine and shut it down.

Too late.

But then I remembered I have the 30 day deletion recovery feature on Dropbox, so I desperately tried restoring. Over a million files. The site could not handle it. Spinning cursor. Spinning. Spinning. Canceling, I then tried restoring subfolders piecemeal. Spinning. Spinning. Error message.

I started digging through the site looking for a number to call to ask if I could get a physical hard drive sent to me with all my deleted files. I never found such an option (still don’t know if that’s available).

More panic.

Had lunch to take a breath. Then I realized, luckily, because the drive was never reconnected all the files were still on that drive! Saved! It took me several days, but now all my files are restored.

And now my Dropbox folder is part of my regular backup process.

I hope this helps others avoid this situation. We already have enough to worry about these days. Stay safe, everyone.

I will be posting tip sheets on a regular basis. These are called “living” tip sheets because they could be updated frequently, as I learn more.

The AWS Serverless Application Model (SAM) is a CloudFormation transformation macro used to ease the creation of serverless applications. We can think of it as a lightweight CloudFormation template with the core purpose of creating serverless infrastructure as code.

The documentation format of each attribute below is: Name – (YAML indentation level) Explanation

• AWSTemplateFormatVersion (1) This is the version of the CloudFormation template we’re writing for. AWS versions are normally in the format of a date (YYYY-MM-DD).
• Transform (1) This is used to specify what CloudFormation macros (and, optionally, macro version) we are using. The macro for transforming this template from SAM into CloudFormation is AWS::Serverless-2016-10-31. In this example, AWS::Serverless is the macro we’re using (Serverless; that is SAM), and 2016-10-31 is the version. AWS versions are normally in the format of a date (YYYY-MM-DD). Resource names (like macros) are delimited by a double colon (::).
• Description (1) Comments describing the template. This setting must follow the AWSTemplateFormatVersion setting.
• Mappings (1) This allows us to create key/value pairs of data that we can use throughout our template. Under this, we specify a name for each of our mapping categories, and within each of those, we specify our key/value pairs that we can reference in our template. We reference these via the !FindInMap function call (documentation coming soon).
• Resources (1) This is a significant attribute in SAM templates, proceeding all the actual AWS resources to configure.
  • Logical ID (2) An alphanumeric name given to a resource. This must be unique for all resources in a template.
    • Type (3) The type of AWS resource this is. The format of this value is service-provider::service-name::data-type-name. For example, AWS::EC2::Instance. Resource names are delimited by a double colon (::).
    • Properties (3) A set of key/value pair properties (or options) for the resource.
    • DeletionPolicy (3) AWS deletes resources upon CloudFormation stack update and deletion by default. But we can specify this attribute with a value of “Retain” when we want to retain a resource beyond the life of the stack.
    • DependsOn (3) If we want a resource to be created only after another resource is created, we can force this by specifying this attribute along with the logical resource name of the dependency. We can have a resource depend on one or more other resources.

For more details on CloudFormation templates, check out Tim Harkin’s blog post .

Fixed several links.

EC2 is essentially a virtual server in the cloud. It can be available within minutes after setting it up. Compare that to how long it would take to provision and prepare a physical server in your own datacenter. Even ordering it and awaiting initial configuration and shipment can take weeks. General knowledge about EC2 is one of the key categories in the AWS Certified Cloud Practitioner exam.

Instance Types

EC2 is region-specific, so we should launch instances in a region that makes sense for latency and regulatory reasons. When we set up an EC2 instance, we get to choose from a large selection of pre-canned images across several different Linux offshoots and Microsoft Windows OSs. There are several instance types for these operating systems that we can select from. Here’s a great chart to help find the most appropriate instances to use.

Note: There’s a common mnemonic we can use to help us remember the different instance types, but that likely won’t appear on the AWS Certified Cloud Practitioner exam: FIGHT DR MCPXZ (Fight Dr. McPixie), although with a recent change, the newer mnemonic could be FIGHT DR MACPXZ, due to the A1 class that was added in 2018. Keep in mind that some exams may refer to the older mnemonic.

In general, these are the existing type categories:

• F – For FPGA (Field Programmable Gate Arrays ) (F1 instances )
• I – For IOPS (Storage Optimized , backed by IOPS SSD EBS ).
• G – For Graphics (Accelerated Computing )
• H – High Disk Throughput (I3 instances )
• T – Cheap general purpose, like T2 Micro
• D – Density (D2 instances )
• R – RAM (High Memory instances )
• M – Main choice for general-purpose apps (M class instances )
• A – ARM-based workloads (A1 instances )
• C – Compute (C class instances )
• P – Pics (graphics) (G class instances ) (an alternative is now Amazon EC2 Elastic GPUs )
• X – Extreme Memory (X1 and X1e instances)
• Z – Extreme Memory and CPU (z1d instances )

Aside from these AWS-supplied instance images, we can also create instances from a saved image (AMI) that we created from previously configured instances, or from AMIs purchased from the AWS Marketplace . This is often used for Auto Scaling launch configurations and Elastic Load Balancing target groups. This will be covered in another article.

We should always design for failure. So, at minimum, we should create an EC2 instance in each availability zone in the region.

Security

When we create an instance, we also need to create a Security Group to poke holes in the firewall for ports from specific IP address(es) or from anywhere: 0.0.0.0/0. Think of this as a virtual firewall at the instance level. By default, the SSH port (22) is opened up. But other common ports we may want to open up are:

• HTTP (80)
• HTTPS (443)
• RDP (3389)

If we want to have fine-grained (specific IP-level) access control to our EC2 instances, we’d apply network ACLs (NACLs) to our EC2s’ VPC and subnets.

Storage

When setting up an EC2 instance, we also have to configure the storage we want attached to our instance. We do that by specifying the Elastic Block Storage (EBS) type(s) to attach. These are virtual disks in the cloud, and are created in the same availability zone (AZ) as the EC2 instance. Each virtual storage device is auto-replicated:

• SSD (Solid-State Drive)
  • GP2 is a general purpose SSD, often used as the main root volume.
  • I01 is provisioned IOPS SSD high-performance drives, which are best for high-performance databases.
• HDD (Magnetic Drive)
  • HDD drives cannot be boot volumes.
  • ST1 is a throughput-optimized HDD, which is a low-cost volume for frequent, throughput-intensive workloads, such as database servers.
  • SC1 is a “cold” HDD, which is the lowest cost option for less frequently accessed workloads, such as file servers.
  • Magnetic is a previous generation EBS type, and is being phased out.

Instance Access

Once we get our EC2 instance(s) configured and started, we’ll often need direct access to the machines. The most common method is via SSH (port 22). Upon launch of an EC2 instance, we’re prompted to select or create a “key pair” (public/private key ) that we’ll need to SSH into Linux instances and to obtain a password to RDP into Windows instances . This creates a private key (.PEM file) that can be used directly from a Linux-based OS (including MacOS) to SSH into the instance. To use this key file from Windows, we’d need to use a utility like PuTTY to convert the key file into a .PPK file and SSH into the instance.

From a Linux-based OS, after saving the .PEM file, we need to apply read-only rights to the file owner by running chmod 400 keyname.pem.

From a local machine, we can connect via SSH by running ssh ec2-user@x.x.x.x -i keyname.pem, where x.x.x.x is the IP address we can grab from the AWS console’s IPv4 Public IP field on the EC2 instance Description panel.

We also use this key pair to run AWS CLI commands. Although this is a topic for another article, please note that we need to store this key locally (in plain text) in the ~/.aws folder. If we want to run CLI commands from the EC2 instance itself, it is far more secure to apply IAM Roles to the instance instead. If anyone ever got access to the EC2 instance, they could grab complete control of the instance for good if the private key was available in the file system.

Pricing

I cover EC2 pricing in much more detail in another article. In general, there are four main EC2 pricing models:

• On-Demand (low-cost and flexible)
• Reserved (steady-state, predictable usage)
• Dedicated (for regulatory requirements)
• Spot (flexible start and end times)

This may be the last article I can write before my first AWS certificate exam, so wish me luck

Last updated: 2020-04-05

I’ll be updating my AWS articles from time to time, as I learn more. I got my first cert — the AWS Certified Cloud Practitioner certification — on January 22nd, but as I took the practice exams (5 exams, 2x each) and the actual exam, I learned about gaps in my knowledge. So I’ll be filling those in through the articles I wrote beforehand.

S3 is object-based flat file unlimited storage. It’s unlimited, but that doesn’t mean we should throw files up there without thinking — storage still costs money. It’s not block-based, so it’s not meant for storing operating systems or live databases. But any type of file can be stored (including database file backups), and each can be from 0 bytes up to 5 TB. General knowledge about S3 is one of the key categories in the AWS Certified Cloud Practitioner exam.

Buckets

Files are stored in buckets, which we can think of as root-level folders. Bucket names must be globally unique because they resolve to URLs, which are global. Most of the time, we wouldn’t expose these URLs publicly except for static S3 websites.

Based on this article and this documentation , please note that the bucket URL naming convention is changing. AWS supports both path-style requests and virtual hosted-style requests. But any buckets created after September 30, 2020 will only support virtual hosted-style requests. Also, the region should be specified in the URL. We could leave out the region, but there’s a slight bit of overhead due to AWS forcing a 307 redirect to the specific region (us-east-1 is checked first).

Here are the updated virtual hosted-style naming examples:

• Regional-specific: https://my-unique-bucket-name.s3.us-east-1.amazonaws.com/
• Without specifying a region (will 307 redirect): https://my-unique-bucket-name.s3.amazonaws.com/

I’m changing my recommended bucket naming convention slightly, due to the Bucket Names with Dots section of this article :

I recommend using reverse-domain naming using an appropriate domain you own, but replacing dots with dashes. For example, I now start all my bucket names with com-markfreedman. An exception would be when we host a static site. In that case, we need to use a normal domain name (in my case, markfreedman.com, although I already have this hosted elsewhere).

Although bucket names must be globally unique, storage of the buckets themselves is region-specific. We should select a bucket’s region based on latency requirements. If most access would be from a certain region, create the bucket in the closest available AWS region. Using CloudFront can alleviate this need, though.

Public access is blocked by default. AWS requires us to be explicit in exposing buckets to the public Internet. All those stories of hacked data (often exposed S3 buckets) should make us thankful for this default. We can secure buckets with IAM policies (bucket policies).

We can also set lifecycle management for a bucket, which specifies which storage class to move the bucket to, and when to move it. More on storage classes, below.

Objects (Files)

When we upload a file to an S3 bucket, AWS considers the file name to be the key, and refers it as key in the S3 APIs and SDKs. The S3 data model is a flat structure. In other words, there’s no hierarchy of subfolders (sub-buckets?). This is why I described buckets as root-level folders. However, you can simulate a logical folder hierarchy by separating portions of the key name with forward slashes (/).

The file content is referred to as the value. Therefore, an S3 file is sometimes referred to as a key/value pair.

Files can be versioned, encrypted, as well as provided with other metadata. We can secure files (objects) with IAM policies (object policies) and set ACLs at the file (object) level. By default, the resource owner has full ACL rights to the file. For extra protection, we can require multi-factor authentication (MFA) in order to delete an object.

When we upload a file to an S3 bucket, we’ll know the upload was successful if an HTTP 200 code is returned. This is most important when uploading programmatically. If we do it manually, AWS will let us know if it succeeded or not.

We can expect 99.99% availability, but AWS only guarantees 99.9%. But it also guarantees 99.999999999% durability (11 x 9s). So we can be confident that our files will always be there.

There are specific “data consistency” rules:

• Read after Write Consistency — when new files are uploaded, we can read the file immediately afterwards.
• Eventual Consistency — when files are updated or deleted, immediately attempting to read the file afterwards may result in the old file content. It can take a short period of time (perhaps a few seconds or more) to propagate throughout AWS (replication, cache cleaning), which is why we may see the old file.
  
  (Update, 2020-04-05: I originally mentioned that new files use POST and updates use PUT. But according to what I can gather from their docs and some online Q&A, POST is actually an alternate to PUT that enables browser-based uploads to S3. Parameters can either be passed via HTTP headers by using PUT, or passed via form fields by using POST, no matter if the object is new or being replaced. From what I can tell, S3 doesn’t really “replace” objects per se, since versioning is an option.)

Storage Classes

S3 supports tiered storage classes, which we can change on demand at the object level. We don’t specify a class at bucket creation time. Keep in mind, when we specify lifecycle rules, we do that at the bucket level, defining the lifecycle rules for the objects in that bucket:

• S3 Standard (most common) is designed to sustain loss of 2 facilities concurrently, and has the best performance.
• S3 IA (Infrequently Accessed) is lower cost, but we’re charged a retrieval fee.
• S3 One Zone IA is a lower cost version of S3 IA, but it doesn’t require multiple zone resilience. It’s the only tier that’s just in one availability zone; all the others are replicated in 3 or more zones.
• S3 Intelligent Tiering allows AWS to automatically move data to the most cost-effective tier using machine learning AI of usage patterns. For most buckets, I recommend using this, although it’s best for long-lived data with unpredictable access patterns.
• S3 Glacier is a secure, durable, low cost archival tier, which allows for configurable retrieval times, from minutes to hours. It provides query-in-place functionality for data analysis of archived data.
• S3 Glacier Deep Archive is the lowest cost tier, but it requires up to 12 hour retrieval time. This is great for archived data that doesn’t need to be readily available.
• S3 RRS is Reduced Redundancy Storage, but is being phased out. It appears to be similar to S3 One Zone IA.

Pricing

The prices we’re charged (covered in another article) using S3 is based on:

• Storage
• Requests
• Storage Management
• Data Transfer
• Transfer Acceleration , which enables fast transfer to distant locations by using CloudFront edge locations, making use of backbone networks (much larger network “pipes”).
• Cross Region Replication , which automatically replicates to another region bucket for disaster recovery purposes.
• We can also configure buckets to require the requester pay for access .
• If we have multiple accounts under an Organization , S3 offers us volume discounts when we enable Consolidated Billing .

I don’t believe the exams will ask about specific prices, as these can always change. But the important thing is understanding the relative pricing, so you could be able to make intelligent cost analysis decisions.

Because there are often many details and variables that go into cost calculation, I’ll also link directly to the AWS pages for each service cost.

Snowball

Snowball is a physical petabyte-scale device used for migrating gigantic data sets into and out of AWS S3 storage. It’s much cheaper and faster to get on-premise data into and out of AWS using a physical device, especially when we’re talking petabytes.

Elastic Block Store (EBS)

In my first article on billing and pricing, we discussed the support options’ costs and EC2 pricing. There are a few services that work hand-in-hand with EC2 that we’ll discuss here. First off, an EC2 (or any server instance) is useless without disk storage. EBS is AWS’s virtual disks in the cloud. These disks are not tied to any single EBS instance. The flexibility of keeping it independent allows us to detach it from one EC2 instance and attach it to another, like moving a physical hard drive from one physical server to another. But like physical servers, an EBS instance can only be attached to a single EC2 instance at a time. In addition, EBS instances can only be attached to EC2 instances in the same region.

EBS pricing is based on media type and provisioned storage (not necessarily what’s physically used). The monthly prices shown are current as of this writing, and subject to change, but it will still give you an idea of relative costs:

• General purpose SSD (gp2) volumes are 10 cents per GB. These are perfect for boot drives and general file storage purposes.
• Provisioned IOPS SSD (io1) volumes are 12.5 cents per GB. Because 10s of 1000s of these volumes can be attached to a single EC2 instance, we’re also charged 6.5 cents each per month. These are mainly for I/O-intensive and database workloads. I’m still not exactly sure why so many volumes are desirable, so I hope to learn more about that soon.
• Throughput Optimized HDD (st1) volumes are 4.5 cents per GB. These are magnetic drives good for large, sequential workloads and data warehouses.
• Cold HDD (sc1) volumes are 2.5 cents per GB. These magnetic drives are for inexpensive block storage where throughput is more important than speed.

EBS Snapshots are incremental backups of any EBS store, and are charged at 5 cents per GB of actual data stored; not provisioned size.

There’s a service fee per “job.” A job is the shipping/loading/shipping/unloading of a single Snowball device. There are two sizes of Snowball; 50 TB and 80 TB. The service fee for each is $200 and $250 ($320 for Singapore and Seoul), respectively. Standard shipping charges are extra. There’s also a daily charge for holding onto the device, although the first 10 days are free. If we go beyond 10 days, we’re charged an extra $15 ($20 for Singapore and Seoul) per day afterwards. It’s free to transfer the data into S3. But transferring data out of S3 runs between 3 and 5 cents per GB, depending upon region.

Relational Database Service (RDS)

There are no up-front fees for setting up RDS use. But Amazon prices RDS use by the following:

• Clock hours of server time.
• Instance type and size.
• Provisioned storage.
• Additional storage.
• Requests.
• Engine.
• Data transfer.

The monthly prices differ by instance type and database engine:

• Aurora could potentially be a more cost-effective option if you can take advantage of the performance gains over MySQL and PostgreSQL, and you are looking for no-touch administration. But it could be up to 20% more expensive. Storage is 10 cents per GB and I/O is 20 cents per million requests. Backup storage runs between 2 and 2.5 cents per GB, depending on region.
• MySQL, PostgreSQL, and MariaDB costs vary significantly based upon instance type and region. Single-AZ on-demand costs can run from 1.7 cents per hour to almost $14 per hour! These prices double when running in multiple AZs. As with EC2 instances, we can also get significant discounts by reserving instances. 1-year terms can save us around 25%, while 3-year terms can save us around 50%. The savings can even increase as the instance type grows.
• Oracle and SQL Server prices can vary quite a bit depending upon license and instance size. I’d avoid these engines unless you have very specific needs.

DynamoDB

There are two “capacity modes” for DynamoDB:

• On-Demand capacity doesn’t require the need to predict usage. Provisioned capacity offers significant savings, if we can predict our need. We’re charged by the following:
  • Read request units.
  • Write request units.
  • Data storage.
  • Continuous backups.
  • On-demand backups.
  • Backup table restore.
  • Global tables.
  • Accelerator (DAX).
  • Streams.
  • Data transfer.

Pricing details for all of the above are too numerous to go through here, so I recommend reading all the details on the AWS site . Suffice it to say that DynamoDB is a lot cheaper than RDS costs, so only reserve RDS use for where you really need relational access.

CloudFront

CloudFront is relatively cheap considering the benefits. There are no up-front fees.

• Free Tier consists of 50 GB monthly of outbound data transfer and 2 million HTTP/HTTPS monthly requests over a year.
• On-Demand pricing for data transferred out to the Internet is on a sliding scale based on volume per month, and by region. This can range from 2 to 17 cents per GB. For regional transfer inside of AWS, the prices range from 2 to 16 cents per GB. HTTP method calls are all around 1 cent per 10,000 calls.

Elastic Load Balancer (ELB)

In order to calculate Elastic Load Balancer pricing, we first have to understand what a Load Balancer Capacity Unit (LCU) is. It’s based on the highest of the following:

• New connections per second (up to 25 = 1 LCU).
• Active connections per minute (up to 3,000 active connections per minute = 1 LCU).

ELBs are charged at a bit over 2 cents per hour (or partial hour), differing slightly by region. In addition, we’re charged 0.8 cents per LCU-hour (as described above). So if you think about it, we’d be paying well under a dollar a day for a load balancer; probably around $15 or so per month. Definitely not where we’ll take a big hit budget-wise.

Lambda

Serverless computing has become enormously popular over the last few years, especially as we consider solutions for microservices . AWS Lambda allows us to write small functions to respond to several types of events in a “single responsibility principle” model — and if you think about it, virtually everything in computing is triggered by an “event.” We can choose from various popular languages for coding these, which eliminates any real learning curve. AWS handles all the provisioning, scaling, and infrastructure for us at very low cost:

• Request pricing
  • Free tier: 1 million requests per month. Great bargain.
  • 20 cents per 1 million requests thereafter.
• Duration pricing — this is based on processing time and allocated memory.
  • 400,000 GB-seconds per month free up to 3.2 million seconds.
  • $0.00001667 for every GB-second used thereafter.
• Please keep in mind that we are still charged for the resources our Lambda functions use, such as S3 and database transactions.

One of the criticisms of Lambda is its cold startup time when it hasn’t been used for awhile. Each Lambda function is containerized, so even though containers are much more efficient than VMs, there is still start-up latency. AWS offers Provisioned Concurrency Pricing to help alleviate this issue, at a cost. As they say on their site, this “keeps functions initialized and hyper-ready to respond in double-digit milliseconds.” Provisioned Concurrency Pricing involves several variables, so it’s best to look at the examples on the AWS website .

Free is for Me

AWS gives us several free service options as well:

• Free user tier for new accounts:
  • Free EC2 micro instances for a year.
  • Free S3 usage tier.
  • Free Elastic Block Store (EBS).
  • Free Elastic Load Balancing (ELB).
  • Free data transfer.
  • Etc.

• Free services
  • VPC (virtual data center in the cloud)
  • Elastic Beanstalk (but provisioned resources aren’t free)
  • CloudFormation (but provisioned resources aren’t free)
  • Identity Access Management (IAM)
  • Auto Scaling (but provisioned resources aren’t free)
  • Opsworks (similar to Elastic Beanstalk)
  • Amplify
  • AppSync
  • CodeStar
  • Consolidated Billing
  • Cost Explorer
  • AMIs (exception: if creating from a running instance, we pay for running a micro instance (about 2 cents per hour, depending on region) plus some EBS fees).

Pricing Calculators

AWS provides us with a couple of tools for estimating costs. Apparently, this is a big part of the AWS Certified Cloud Practitioner exam, so practice using them:

• Simple Monthly Calculator
  • Allows us to build out environments for estimating costs.
  • Calculates running-cost estimates.
  • Hosted on S3 (trivia).
• Total Cost of Ownership (TCO) Calculator
  • This is a great tool for generating reports to convince C-level management the cost benefits of moving to the cloud.
  • Allows us to compare on-premise vs. AWS cloud costs.
  • Breaks things down into four categories (for overhead, space, power, and cooling costs):
    • Server costs
    • Storage costs
    • Network costs
    • IT labor costs

Again, practice, practice, practice.