DEV Community: Mark Freedman

How Vertical AI Agents Work

Mark Freedman — Sat, 01 Mar 2025 19:20:34 +0000

Now that we’ve talked about what Vertical AI Agents are, let’s take a look at how they actually work. These AI agents don’t start out intelligent. They have to be trained, just like people learn skills over time. But instead of sources like teachers and YouTube videos, they learn from data — often a massive amount of data. This training makes them really good at one job, whether it’s spotting fraud, assisting doctors, or even recommending new songs.

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:

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.
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.
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.

Introduction to Vertical AI Agents

Mark Freedman — Mon, 24 Feb 2025 13:00:46 +0000

What is AI, and How Do Vertical AI Agents Fit In?

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.

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.

Dropbox Cautionary Tale

Mark Freedman — Tue, 03 Nov 2020 19:50:19 +0000

This is my first post in a long time. You know, pandemic, elections, world falling apart distractions. Will be prepping for my next AWS cert soon. But in the meantime, I have a cautionary tale about Dropbox.

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.

AWS Elastic Compute Cloud (EC2)

Mark Freedman — Mon, 20 Jan 2020 13:20:43 +0000

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 🙂

AWS Simple Storage Service (S3)

Mark Freedman — Sat, 18 Jan 2020 16:52:12 +0000

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.

~~When we name our buckets, AWS automatically postfixes “S3” or the bucket's region to the name, depending on the region. Here are the two naming examples:~~

us-east-1: https://my-unique-bucket-name.s3.amazon.com/
All other regions: https://my-unique-bucket-name.us-west-2.amazon.com/

~~Based on the above, we may wonder why the names still need to be globally unique instead of regionally. My answer: I don't know. Maybe it's a legacy reason.~~

I recommend using reverse-domain naming using an appropriate domain you own. For example, I 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).

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.

AWS Pricing and Billing (Part 3)

Mark Freedman — Sat, 18 Jan 2020 15:56:35 +0000

In my last article, we discussed S3 pricing, which was an entire topic on its own. In this part, we’ll discuss other key service charges, and the options and decisions we need to make when planning.

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.

AWS Pricing and Billing (Part 2)

Mark Freedman — Fri, 10 Jan 2020 15:18:46 +0000

Last updated: 2020-02-18

In my last article, we discussed the support options’ costs and EC2 pricing. This is a large topic, so I’m going to have to have a 3rd part since S3 takes up a lot.

S3 Pricing

S3 is charged based on:

Storage class
Storage volume
Storage time duration
Requests (GET, PUT, COPY)
Lifecycle rules
Pattern monitoring for Intelligent-Tiering
Data transfer

In general, monthly storage pricing rates go down as more storage is used. I’m not going to get into many specifics here because the prices can be in flux. You can always see the latest prices and details on the AWS S3 pricing page.

Storage and Transfer Requests:

I haven’t covered S3 storage classes in detail yet, so for now, I’ll give brief descriptions, and give you relative pricing between the classes. These are all monthly charges:

S3 Standard – this is the most commonly used class for frequent millisecond access, and storage is usually charged (as of this writing) in a sliding scale of between 2 and 2.5 cents per GB of storage, a half cent per 1000 inbound transfer requests (note that “transfer requests” is different from “transfer volume,” discussed later), and a minuscule 0.04 cents per 1000 outbound transfers.
S3 Standard – Infrequent Access – as the name implies, this is for infrequently accessed storage, but also with millisecond access. Storage is a lot cheaper, though; around half the price of S3 Standard. The savings over S3 Standard is only for storage. Since it should be infrequently accessed, transfer request costs are more expensive (around double the cost of S3 Standard).
S3 One Zone – Infrequent Access – Similar to the above, but only in a single availability zone (AZ). Storage is slightly cheaper than the above; about 1 cent per GB. Transfer rates are the same.
S3 Glacier – long-term archival backups with potential access delay time of several hours, but cheap, with a storage price under 0.5 cents per GB. Inbound transfer requests is a half cent per GB, and outbound is the same as S3 Standard.
S3 Glacier Deep Archive – similar to the above, but with up to a 12 hour delay, and only accessed once or twice per year, but very cheap, with a storage price at a minuscule 1/10 of a cent per GB. Transfer request costs are the same as above.
First Year S3 Standard – this is free for up to 5 GB with 20,000 outbound transfers, 2,000 inbound transfer requests and lists, and 15 GB transfer out per month.

One other transfer request cost is lifecycle costs (you can create rules to transfer to other storage options based on certain metrics we define, or Intelligent Tiering, which does this automatically for us based upon machine learning). To transfer to another standard storage class, the price is currently 1 cent per 1000 requests. Transferring to a glacier class is at 5 cents per 1000 requests.

There are also costs for retrieving data from glacier storage:

Glacier Expedited Retrieval – $10 per 1000 requests plus 3 cents per GB.
Glacier Standard Retrieval – 5 cents and 1 cent, respectively.
Glacier Bulk Retrieval – 2.5 cents and 1/4 cent, respectively. TBH, I’m not totally sure what “bulk” transfer actually is, and couldn’t find a clear explanation. I believe it means at an entire bucket level (instead of specific files), but not sure. If anyone could clarify this for me, I’d appreciate it.
Glacier Deep Archive doesn’t have an expedited option, but standard is twice the cost of Glacier and bulk is the same price as Glacier.

Data Transfer Volume:

As mentioned above, we are also charged for data transfer volume per month:

Transferring data into S3 from the Internet is always free. The same is true for S3 data transferred to EC2 instances in the same region as the S3 buckets. Data transferred out to CloudFront is also free.
Transferring data out to the Internet from S3 is free up to 1 GB.
The next 9.999 TB is currently charged at 9 cent per GB.
The next 40 TB is currently 8.5 cent per GB.
The next 100 TB is currently 7 cents per GB.
Anything over 150 TB is currently 5 cents per GB.
Remember, these are all per-month costs.

Transferring data from S3 to other regions is generally charged at 2 cents per GB, with the exception of N. Virginia, which is 1 cent per GB.

Finally, Transfer Acceleration (uses edge locations to boost speed) has a premium cost on top of the standard. This is generally 4 cents per GB, with the exception of inbound transfers to regions outside of the US, Europe and Japan, which is 8 cents per GB.

If we have multiple accounts under an Organization, S3 offers us volume discounts when we enable Consolidated Billing.

AWS Pricing and Billing (Part 1)

Mark Freedman — Thu, 09 Jan 2020 18:32:45 +0000

Last updated: 2020-02-22

One of the critical categories of questions for the AWS Certified Cloud Practitioner exam is billing. It’s estimated to be from 12% to 20% of the exam.

Every service and support plan have their own pricing models, and I’ll try to clarify all of these here. This is a large topic, so I’m going to split this over three articles.

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.

Support Plans

There are four basic plans offered by AWS, which is similarly tiered as other services you may be familiar with:

Basic – This is the free tier. We get no direct tech support from Amazon. They’ll only provide us with accounting support and access to forums. 7 Trusted Advisor (future topic) checks are included.
Developer – $29 and up (sliding scale) per month. We get everything included in Basic, plus a primary tech contact with 12-24 hour response time via email only. They’ll respond within 12 hours if the system is impaired or down. But they’ll provide no 3rd-party support. We’re on our own for that.
Business – $100 and up (sliding scale) per month. We get everything included in Developer, but with 24×7 support, 1 hour or less response time for urgent cases (system down), within 4 hours for impaired system issues. They will help with 3rd-party issues. Communication is available via email, chat, and phone. We also have full access to Trusted Advisor checks, and access to the AWS Support API, which seems really cool, but I’ve never used it.
Enterprise – $15k and up (sliding scale) per month. We get everything in Business, plus a dedicated Technical Account Manager (TAM), a personal Support Concierge, access to Event Management, seasonal promotions, events, and migrations, and 15 minute priority response time for critical issues. It seems like a huge jump in price between Business and Enterprise, but I guess they take into account that an enterprise can afford to pay a lot more for really top-notch support.

AWS Partner Network (APN) Support Options

Although there’s no direct AWS billing around the following two services, for the certification it’s important to be aware of what’s available. Also, as we earn our AWS certifications we’ll be directly helping our company if one of their goals is to be included in the third-party AWS Partner Network. There are several requirements for each tier, and our companies will gain plenty of benefits as its members become certified.

APN Consulting Partners: These are professional service firms like System Integrators and VARs that can supplement our internal team’s knowledge and help us take advantage of AWS.

APN Technology Partners: These partners provide pre-canned SaaS or PaaS solutions and dev and security tools we can install on the AWS platform, AWS services we can integrate with, or hardware and network vendors. These are created by ISVs and often made available on the huge AWS Marketplace. We never need to start from scratch to get our company up and running quickly on AWS.

Billing Preferences and Alerts

We should put cost controls in place before the environment grows. I recommend turning on all these billing preference settings so there are no surprises:

Receive PDF Invoice by Email
Receive Free Tier Usage Alerts
Receive Billing Alerts

I also recommend setting alarms for when certain thresholds have been reached. Alarms are set via CloudWatch. Select the Billing metrics. You can choose from several individual metrics/services, but to start out, I recommend setting one on the Total Estimated Charge. The options are pretty self-explanatory. To be alerted, you’ll also need to select an SNS (Simple Notification Service) topic (future article), and email list to alert. Please note that the only email lists allowed are those in the account.

Keep in mind that we can only track the estimated charges in CloudWatch; not our actual resource utilization. Also, we can only set coverage targets for our reserved EC2 instances in Budgets or the Cost Explorer, but not in CloudWatch.

Billing Tools

We can enable Cost Explorer to visualize and manage our costs and usage over time. When we enable this, we automatically get recommendations to help us reduce our costs. We have to explicitly enable this before it starts tracking our usage.

We can use the Cost and Usage Reports for detailed, granular hourly and daily usage reports that can be exported to a spreadsheet. We also have to explicitly enable this before it starts tracking our usage. These reports give us additional service, pricing, and reserved instance metadata to better help us analyze our usage and make changes in how we allocate our resources. These reports also make great use of tags that we assign to our resources, for better categorization.

As an FYI, billing metrics only run in region us-east-1 (N. Virginia).

General Service Pricing Info

A major benefit of using cloud services are that instead of CapEx (capital expenditures), where we need to pay up-front fixed, sunk costs, cloud computing costs are OpEx (operational expenditures), where we pay for what we use, like electricity, water, or gas. We can reduce overall costs by 70% or more.

Pricing is based on:

Paying as you go
Paying for what’s used
Paying less as more is used
Paying even less when reserving capacity
Paying even less as AWS grows
Custom pricing

In general, services are charged by compute, storage, and outbound data transfer. They are priced transparently and independently. This enables our businesses to be fully elastic and allows us to focus on innovation. We don’t have to pay for services that aren’t running.

A key point to remember during the exams: billing is charged for data transfer between regions.

EC2 Pricing Models

There are very flexible pricing models for EC2:

On-Demand Instances
- This is the default launch type.
- It’s low-cost and flexible.
- We’re charged by the hour or minute, depending upon the instance type (compute power, memory size, etc.).
- It’s best for short-term, unpredictable workloads, and for first-time apps when starting out. Always monitor usage to see if you could benefit from other plans in the long run.
Reserved Instances
- These are best for long-term savings.
- It’s good for steady-state, predictable usage or reserved capacity.
- We have to make a commitment over a period of time, though; 1 or 3 years.
- These could be shared between multiple AWS accounts for the same organization.
- Unused instances can be sold in the Reserved Instance Marketplace, so it’s not a huge concern if the need disappears before the commitment period ends.
- It’s priced based on term, instance class, and payment class option. These are the payment classes. Please note that all the percentages are approximate and subject to change. I’m just providing them to give you a general idea:
  - Standard – up to a 75% savings. We can’t change the attributes, though.
  - Convertible – up to a 54% savings. We can upgrade attributes (but not downgrade; this is why it’s best to start small and work your way up).
  - Scheduled – we can reserved instances for specific periods of time. Savings vary depending on the selected periods. Terms are 1 or 3 year contracts. Of course, 3 years gives us more savings.
- Payment term options:
  - All upfront (~40% discount over On-Demand)
  - Partial upfront (~39% discount over On-Demand)
  - No upfront (~36% discount over On-Demand)
Dedicated Hosts
- This is the most expensive option.
- These are physical servers dedicated for a customer’s use.
- They give us visibility and control over how instances are placed.
- This is useful when regulatory requirements need to be met.
- They are single-tenant (physical isolation) as opposed to the multi-tenant instances used in other options.
- We would also use our own third-party software licenses that are bound to physical cores or sockets.
- These are offered in both On-Demand and Reserved (up to 70% savings).
Dedicated Instances
- Hardware is dedicated to a single customer.
- These instances are physically isolated at the host hardware level from other AWS accounts.
- The instances may share hardware with other instances from the same AWS account that aren’t necessarily dedicated instances.
- These are also offered in both On-Demand and Reserved, as well as Spot Instances (up to 90% savings).
Spot Instances
- This will bring the biggest savings — up to 90%.
- This allows us to take advantage of unused EC2 capacity sitting out there in the AWS cloud.
- We bid on Spot instances.
- These are only useful if our apps have flexible start and end times.
- These are good for non-critical background tasks, like AWS Batch use.
- These instances can be terminated at any time, so the applications running on them must be able to handle interruptions and intelligent restarts.
- If AWS terminates a spot instance (for example, when the current price exceeds our bid price), we aren’t charged for partial hour usage. But if we terminate, we are charged for partial hour usage.
- We decide the type of task needed upfront:
  - Load balancing workloads
  - Flexible workloads
  - Big data workloads
  - Defined duration workloads (1 to 6 hours)
Free Tier to start out
- We get free EC2 Micro instances for a year.

Please bear in mind that we’re also charged on the number of instances, the type of load balancing we use, auto scaling, detailed monitoring, and the use of elastic IP addresses. We’re also charged for resources used by EC2 instances, such as Elastic Block Storage (EBS), EBS snapshots, AMIs, and the actual drives on the instances themselves. We’ll be talking about these more in detail in the next billing articles, and we’ll discuss more about what these services are in later articles.

Just one more point about EC2 and Elastic IP addresses: Elastic IPs are only charged when created but unused. They are not charged when assigned to EC2 instances. It's relatively cheap, but we do want to make sure we get rid of them if we don't need to use them.

AWS Identity and Access Management (IAM)

Mark Freedman — Tue, 07 Jan 2020 18:08:22 +0000

Last updated: 2020-02-11

One of the first things you’ll do after creating an AWS account is add users and groups via the IAM console. We will initially do this as the “root” account user. But be careful — root accounts are not restricted in any way. Therefore, I strongly recommend following the Security Status checklist FIRST when visiting the IAM console:

Delete your root access keys (only shown when logged in as the root user)
- Since root accounts should only be used for console access, it should not be used for programmatic access, so the access keys should be deleted. I’ll discuss what access keys are for, later.
Activate MFA (multi-factor authentication) on your root account
- ALWAYS do this for the root account.
- We can use a “virtual” device, such as the Google Authenticator app or browser extension. You’ll generate a QR code to scan. I like to add the account to both the app and the Chrome extension, so when the QR code is displayed I scan it in the app, and while it is still displayed I scan it from the extension. If you skip to the next step, you will never see the QR code again, so make sure you capture it both ways before moving on. Also, you cannot just take a screen shot and scan in the image from the Chrome extension afterwards. It won’t let you. So make sure you do it when you’re still on the IAM console page.
- We can also use a UTF security key or other hardware MFA device instead. I’ve seen recommendations that we should use a hardware device for root accounts, but I’ve never done that. In a high-security company with exceptionally sensitive data, that may be a requirement.
Create individual IAM users
- Aside from initially creating an initial user with admin rights, and giving a user access to the Billing console (future article), I’d avoid using the root account for anything else beyond going through this initial checklist.
Use IAM groups to assign permissions
- It almost never makes sense to assign permissions directly to individual users. Even if you initially have a single user, create a group to assign the user to, and apply permissions to the group. It’s much easier to assign users to multiple groups if we have to, rather than to assign permissions haphazardly to individual users.
Apply an IAM password policy
- This is where we specify the minimum length, what characters are allowed, reuse rules, expiration rules, and if an admin is required to reset the password after expiration or if the user can do this on their own.
Rotate your access keys (not shown when logged in as root)
- This is more of a user account recommendation than a checklist item.
- I’m assuming this isn’t shown for the root account because the first checklist item is to delete any root access keys to begin with. Again, I’ll discuss what access keys are for in a bit.

Sign-in Link

At the top of the IAM console, we’ll see an IAM users sign-in link:

By clicking the Customize link, we can create an easy to remember alias instead of the numeric AWS account number as the first part of the URL. This URL will allow users to directly visit the console login page. Be aware, though, that if you have access to several AWS accounts, and you store your passwords in a manager tool such as LastPass or 1Password, what the browser pre-fills into the login fields can be misleading. Even if you customize the fields in the password manager tool, don’t trust the pre-filled values you see, and always select the specific account from the password manager dropdown. Even then, sometimes I had to manually enter the values, which is a real PITA.

Creating a Group

Now that we made it through the checklist, it’s time to create an “admins” group (or whatever you want to call it) from the Groups menu item on the left. When you hit the step for attaching policies, note that we are limited to 10 policies for a group. That shouldn’t be an issue, because we can apply several permissions to a single policy. For this group, we should just apply a single policy; AdministratorAccess. Since this encompasses all permissions, we don’t need to add any other policies to the group. That’s all we need to do to create a group.

Creating a User

Now we can create users to assign to this group. Let’s create a single user for now by clicking the Users menu item on the left. Note that we can create several users at a time if they share the same access types and permissions. Also note that it’s at the user level where we decide what type of “access” the user can have; not at the group level:

Programmatic access, which gives the user the right to access AWS via the CLI (future article), API, or SDK. Programmatic access requires the creation of an access key. Recall that we deleted the access keys for the root user, because that account should only ever have console access.
AWS Management Console access, which gives the user the right to log into this console.

I strongly recommend creating separate user accounts for programmatic vs. console access, although if you’re just creating a temporary user to learn AWS, a single user is fine for access to both.

When we select console access, the Console password fields are displayed, where we can request an autogenerated or manual password. I recommend requiring the users we create change their password upon first login, so we really only need to request “autogenerated” here. Let’s enforce that by selecting the Require password reset option as well. FYI, setting this option automatically assigns the IAMUserChangePassword policy to the user so they’ll be able to do this. Aside from this, users have zero permissions when first created.

Access Keys

After we create the user, we’ll see a “success” page, where we’ll also see the system-generated access key. Once we leave this page, we will never, ever be able to see the secret access key or password again. So I recommend either saving them into a secure location (such as the LastPass “vault” or similar tool), or downloading the CSV file containing all the values (not very secure). If we do lose this, it’s not the end of the world. We’ll just have to regenerate a new access key and delete or inactivate the lost one. From this page, we can also request AWS send an email to the user with this info.

Adding a User to a Group

The next step is to add the user to a group — in our case, the admins group we created earlier. We could instead select the option to copy permissions from another user, or attach policies directly, but as I mentioned earlier, I don’t recommend that.

We can skip over the Tags page for now; that’s a separate article, and not essential at this time.

More on Policies

We should take a look at the Policies option (select from the menu on the left). Policies can “allow” or “deny” specific rights. We’ll see the hundreds (and hundreds, and hundreds) of pre-canned AWS policies. We can create our own as well. Policies are actually defined under the hood via JSON key/value pairs. When we create our own policies, we’ll often do this directly in JSON, although there is a visual editor as well. But this is for a future article.

Since there are so many policies, AWS makes it easy for us to filter these by type (“customer managed” — ones we create, AWS managed, etc.) or by how they’re used. We can also enter a partial search string.

Roles

One other thing you may be interested in on the IAM console is a feature called Roles. These are not associated with a specific user or group within the account. We can use roles for granting/delegating permissions to resources (including IAM users in other accounts).

Roles allow us to avoid sharing long-term access keys. For example, if we want to access S3 from the AWS CLI from an EC2 instance's terminal, you can avoid storing access keys/secret keys on the machine by giving the EC2 instance S3 access via a role that has S3 access policies.

Applications can also assume roles, similar to AWS users assuming roles.

Of course, if you have no idea what I'm talking about, don't worry -- this will be a future article.

Credential Reports

One other thing you may be interested in on the IAM console: we can generate and download a Credential report that will show us user account details which an admin should review on a regular basis.

One final note — although many AWS services are available at the “region” level, IAM settings are “global.”

AWS Certified Cloud Practitioner

Mark Freedman — Mon, 06 Jan 2020 17:56:05 +0000

Last updated: 2020-02-11

The AWS Certified Cloud Practitioner exam is the most basic AWS certification you could obtain. It certifies that you have a basic knowledge of the core features and benefits of AWS. It’s a great kickoff point if you want to work towards other AWS certifications.

I’ve never had a high opinion of certifications in my field. Most exams seemed to better gauge how good someone is at taking tests or memorizing facts than actually displaying understanding and knowledge. But the AWS exams appear different, and seemed to be designed to be a lot more representative of someone’s knowledge and understanding.

It’s been many years since I’ve actively pursued a certification, but at this point in my career I feel becoming certified in AWS (and cloud computing, in general) is worth the time and effort. The benefits of cloud computing is enormous, and is the most game-changing development since I entered the field. I’ve forced myself to make use of AWS and Azure just to remain current, and to make better solution choices.

In order to pass the most basic AWS exam, we have to be well aware of these benefits:

Cloud computing allows businesses to trade capital expenses for variable operational expenses.
We can take advantage of massive economies of scale. By sharing costs with other AWS users, machine cycles are used much more efficiently, saving all of us an enormous amount of money.
We no longer have to guess our capacity needs ahead of time. We can quickly start small, and by analyzing our usage and needs (including assistance from the AWS Trusted Advisor and Cost Explorer) we can easily scale up (and down) as-needed, both manually and automatically. This is one of my favorite benefits.
There are no long-term contracts, although there are ways to save even more money by committing to 1 or 3 year contracts for certain resources.
As you can tell, cloud computing gives us tremendous increase of speed and agility. Small (even single-person) teams can quickly test and implement solutions that were impossible or cost-restrictive just a decade or so ago.
We can go global in mere minutes by deploying and replicating our solutions across regions. Not only are the costs of starting up incredibly small (even free for the first year), we no longer have to pay for running and maintaining our own data centers. From experience, I can’t even begin to express how huge this benefit is. We can focus on business solutions instead of constantly worrying about infrastructure, which was a full-time job in itself.

As I work towards my certifications, I’m going to be writing a series of articles. This will help me prepare for the exams (and for better understanding and using AWS). But I hope this will also help you work towards those same goals. Right now, cloud computing expertise is in great demand, and it is still so hard to find experts. This can be a huge boost for anyone’s tech career, no matter if you have an IT or developer background. If you always considered yourself a well-rounded tech person who is often involved in development, architecture, and implementation of solutions, becoming a DevOp is a natural next step.

My subsequent posts may be delayed as I create several of them while I work towards my certs, and I’ll post them fairly quickly once I’m done. I want to make sure my subsequent posts are well thought-out and accurate before I post them.