DEV Community: Tetiana Mostova

AWS Strands Replaced 40 Lines of LangGraph With 3. Here’s the Full Story

Tetiana Mostova — Sun, 08 Mar 2026 16:13:51 +0000

At work, we build agents using LangChain and LangGraph. It works, but it takes a while to get anything off the ground. When AWS dropped Strands Agents earlier this year, I was curious — is this actually simpler, or just another framework with a different name?

Here’s what I found.

What Even Is Strands?

Strands Agents is an open source SDK from AWS, released in May 2025. The whole idea is a model-driven approach — instead of you wiring up every step of an agent’s logic, you hand the LLM a prompt and a set of tools, and let it figure out what to do.

Three things are all you need to build an agent:

A model (Bedrock, Anthropic, OpenAI, Ollama — your pick)
A system prompt
A list of tools

That’s it. The LLM plans, reasons, calls tools, and loops until the task is done.

By the way — why ‘Strands’? Think of each tool as a single thread. The agent weaves them together dynamically to complete a task. Compare that to LangGraph where you manually braid the threads in a specific order. With Strands, you hand the model a bundle of threads and say ‘figure it out.’ Honestly, a pretty good name for what it does.

The Code Difference Is Stark

Let’s say you want an agent that can answer a question and use a calculator tool.

With LangGraph:

from langgraph.graph import StateGraph, END
from langchain_core.messages import HumanMessage
from langchain_aws import ChatBedrock
from langchain_core.tools import tool

@tool
def calculator(expression: str) -> str:
    """Evaluate a math expression"""
    return str(eval(expression))

llm = ChatBedrock(model_id="anthropic.claude-3-sonnet-20240229-v1:0")
llm_with_tools = llm.bind_tools([calculator])

from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    messages: Annotated[list, operator.add]

def call_model(state):
    response = llm_with_tools.invoke(state["messages"])
    return {"messages": [response]}

def call_tool(state):
    last_message = state["messages"][-1]
    tool_call = last_message.tool_calls[0]
    result = calculator.invoke(tool_call["args"])
    from langchain_core.messages import ToolMessage
    return {"messages": [ToolMessage(content=str(result), tool_call_id=tool_call["id"])]}

def should_continue(state):
    last = state["messages"][-1]
    return "tool" if hasattr(last, "tool_calls") and last.tool_calls else END

graph = StateGraph(AgentState)
graph.add_node("agent", call_model)
graph.add_node("tool", call_tool)
graph.set_entry_point("agent")
graph.add_conditional_edges("agent", should_continue)
graph.add_edge("tool", "agent")

agent = graph.compile()
result = agent.invoke({"messages": [HumanMessage(content="What is 1764 square rooted?")]})
print(result["messages"][-1].content)

With Strands:

from strands import Agent
from strands_tools import calculator

agent = Agent(tools=[calculator])
agent("What is the square root of 1764?")

Yes, that’s really it. Three lines.

The LangGraph version above is ~40 lines for the same task — and that's still the happy path, no error handling yet.

So Should You Just Switch to Strands?

Not necessarily. Here’s the honest breakdown:

Strands is better when:

You’re prototyping fast and don’t need tight control over every step
You trust the LLM to reason well for your use case
You’re already on AWS and want native Bedrock + Lambda + ECS integration
Your agent is relatively self-contained (one agent, many tools)

LangGraph is still better when:

You need precise, predictable control over the flow (e.g. financial workflows, compliance-heavy systems)
You have complex branching logic that you can’t leave up to the model
You need parallel sub-agent execution with strict state isolation
Your team already has a lot of LangGraph investment and tooling

The key difference is the philosophy. LangGraph says: you design the graph, the model executes it. Strands says: you give the model tools and let it figure out the graph itself.

In practice, Strands works great for tasks where the LLM is good at reasoning through what to do next. It starts to feel shaky when you have very specific business logic that must run in a precise order — that’s where explicit graph control still wins.

AWS Integration Is a Real Advantage

If you’re already in the AWS ecosystem, Strands has a genuine edge. It deploys natively to:

Lambda (for serverless agent invocations)
ECS/Fargate
Bedrock AgentCore — a managed runtime that handles identity (IAM, Cognito), memory, long-running tasks (up to 8 hours), and observability out of the box

Adding observability is also almost zero effort. Strands has built-in OpenTelemetry support, so traces go straight to CloudWatch, X-Ray, or any OTLP-compatible tool.

With LangChain, you’re usually reaching for LangSmith or wiring up your own tracing. It works, but it’s extra setup.

What About Error Handling?

This one surprised me. In LangGraph you explicitly wire up what happens when something fails — fallback edges, retry nodes, conditional logic. It’s more code but you’re in full control.
Strands takes a different approach: when something goes wrong, the model reasons about alternatives rather than following a predetermined error path. For most cases that actually works fine.
For production tools that call external APIs, you can still add a resilience decorator with retries:


from strands import tool
from strands.tools import RetryConfig

@tool(retry_config=RetryConfig(max_attempts=3, backoff_multiplier=2))
def call_external_api(query: str) -> str:
    """Call an external API"""
    # your API call here
    pass

What About Multi-Agent Setups?

Strands has built-in patterns for this — Graph, Swarm, and Workflow modes. You can also expose one Strands agent as a tool for another agent, which makes composing multi-agent systems pretty clean.

For very large multi-agent architectures (many specialized sub-agents with their own isolated contexts), AWS actually recommends Agent Squad over Strands. Agent Squad is a separate library focused purely on routing and orchestration across many agents. Strands + Agent Squad can be used together.

LangGraph is still competitive here for complex multi-agent graphs, especially when you need fine-grained state sharing between nodes.

My Take

I came in skeptical. Another SDK, another abstraction, does the world really need this?

But Strands is genuinely simpler for the 80% case. If your agent needs to answer questions, call APIs, retrieve docs, or do multi-step reasoning — just use Strands. You’ll be done in an hour instead of a day.

If you’re building something where the sequence of operations really matters and you can’t leave decisions to the model, keep LangGraph. It’s not going anywhere, and the explicit graph control is valuable.

For teams already on AWS, I’d start new agent projects with Strands and reach for LangGraph only when I hit a wall.

Quick Start

pip install strands-agents strands-agents-tools

from strands import Agent, tool

@tool
def get_weather(city: str) -> str:
    """Get current weather for a city"""
    # your actual API call here
    return f"It's sunny in {city}, 22°C"

agent = Agent(
    system_prompt="You are a helpful travel assistant.",
    tools=[get_weather]
)

agent("What's the weather like in Lisbon?")

Make sure you have AWS credentials configured and Bedrock model access enabled (Claude Sonnet in us-west-2 by default).

Using LangGraph at work and tried Strands? I’d love to hear how it compared for your use case — drop a comment below.

Building an Intelligent Document Processing Pipeline with AWS: A Journey from Idea to Production

Tetiana Mostova — Wed, 24 Dec 2025 14:45:31 +0000

TL;DR - Want to Skip the Story?

Fork the repo, deploy in 10 minutes, start processing documents:

git clone https://github.com/Tetianamost/aws-intelligent-document-processing.git
cd aws-intelligent-document-processing
sam build && sam deploy --guided

Everything is production-ready. Just add your AWS credentials and email. Keep reading if you want to know how it works and what I learned building it.

Why I Built This (And Why You Might Need It Too)

Picture this: You're drowning in invoices, receipts, tax forms, and contracts. Your team is manually typing data from PDFs into spreadsheets. Hours wasted. Errors everywhere. Sound familiar?

I built an automated document processing system using AWS services that:

Extracts text, tables, and form data from any document automatically
Processes documents in real-time as soon as they're uploaded
Stores structured data ready for analysis or integration
Sends notifications when processing completes (or fails)
Scales effortlessly from 10 to 10,000 documents

The best part? Once deployed, it costs pennies per document and requires zero maintenance. And you don't have to build it from scratch - just fork, deploy, and use.

The Architecture: Simple but Powerful

Here's what I built:

Document Upload (S3) 
    ↓
Automatic Trigger (S3 Event)
    ↓
AI Processing (Lambda + Textract)
    ↓
Structured Storage (DynamoDB)
    ↓
Notification (SNS Email)

The magic happens in seconds:

Drop a document in S3
Lambda wakes up automatically
Textract extracts everything (text, tables, forms)
Data lands in DynamoDB, perfectly structured
You get an email notification

No servers to manage. No infrastructure to maintain. Just pure serverless goodness.

What Makes This Cool?

1. It Actually Understands Your Documents

This isn't just OCR. Amazon Textract uses machine learning to understand document structure:

Tables: Extracts rows and columns with relationships intact
Forms: Identifies key-value pairs (Invoice #: 12345, Date: Dec 23, etc.)
Text: Gets every word with confidence scores

I tested it with a business invoice containing 4 line items, calculations, and company details. Textract extracted 155 text blocks and perfectly reconstructed the entire table structure. Here's what it found:

{
  "fields": {
    "Invoice #": "INV-2024-001234",
    "Date": "December 23, 2024",
    "Total": "$30,922.50"
  },
  "tables": [
    {
      "rows": 8,
      "columns": 4,
      "data": [
        ["Description", "Quantity", "Price", "Total"],
        ["AWS Cloud Setup", "1", "$5,000", "$5,000"],
        ["DevOps Consulting (80 hrs)", "80", "$175/hr", "$14,000"],
        ...
      ]
    }
  ]
}

2. Zero Infrastructure Management

Remember the days of provisioning servers, configuring load balancers, and setting up auto-scaling? Yeah, me neither. With this serverless architecture:

Lambda handles compute (only runs when needed)
S3 triggers events automatically
DynamoDB scales infinitely
CloudWatch monitors everything

I literally deployed this, uploaded a document, and walked away. It just works.

3. Cost-Effective at Any Scale

Let's talk money:

Textract: $1.50 per 1,000 pages (first 1M pages/month)
Lambda: First 1M requests free, then $0.20 per 1M
S3: $0.023 per GB
DynamoDB: First 25 GB free

Real example: Processing 1,000 invoices per month costs about $1.50. That's it.

4. Production-Ready Error Handling

Things fail. Networks hiccup. Documents are corrupted. I built in:

Dead Letter Queue for failed processing
CloudWatch Alarms for error monitoring
SNS notifications for both success and failure
Automatic retries with exponential backoff
Status tracking in DynamoDB

When something breaks, you know immediately.

The Challenges (And How I Solved Them)

Challenge #1: Circular Dependencies in CloudFormation

My first SAM deployment failed with:

Circular dependency between resources: [DocumentBucket, DocumentProcessorFunction, DocumentProcessorFunctionPermission]

The Problem: S3 bucket needed Lambda permission, Lambda needed the bucket name, and the permission needed both. Classic chicken-and-egg.

The Solution:

Deploy infrastructure without S3 event notifications
Add S3 notifications separately using AWS CLI
Keep Lambda permission with explicit DependsOn

Lesson learned: Sometimes you need to break CloudFormation into multiple steps.

Challenge #2: PDF Format Compatibility Hell

This was the big one. I generated beautiful PDFs using Python's reportlab library. They looked perfect. Textract rejected every single one.

UnsupportedDocumentException: Request has unsupported document format

Even the official IRS Form 1040 PDF failed!

The Investigation:

Textract supports PDFs (per AWS docs) ✅
My PDFs were valid (opened fine in Preview) ✅
File size was under 5MB ✅
But still... rejected ❌

The Breakthrough: Not all PDFs are created equal. Textract is picky about internal PDF structure. PDFs generated by reportlab, fpdf, and even some government forms use formats Textract doesn't support.

The Solution: Convert PDFs to PNG/JPG images first.

# Using poppler's pdftoppm
pdftoppm -png -singlefile document.pdf output

Results:

IRS Form 1040 as PDF: ❌ Failed
Same form as PNG: ✅ 1,412 blocks extracted
Reportlab invoice as PDF: ❌ Failed
Same invoice as PNG: ✅ 155 blocks extracted

Key Takeaway: If you're programmatically generating documents for Textract, create them as PNG/JPG from the start. Save yourself the headache.

Challenge #3: IAM Permissions Maze

SAM deployment needs a surprising number of AWS permissions:

CloudFormation (to create stacks)
Lambda (to deploy functions)
IAM (to create execution roles)
S3 (to store artifacts and documents)
DynamoDB (to create tables)
SNS (to create topics)
CloudWatch (to create log groups and alarms)
X-Ray (for tracing)

Best Practice: Create an IAM user group with all required managed policies, then add your deployment user to it. This makes permission management cleaner and reusable.

Real Results: What It Actually Extracted

Test 1: Business Invoice

Input: PNG image with company header, bill-to info, 4 line items, and calculations

Extracted:

8 key-value pairs (Invoice #, dates, addresses)
Complete 8x4 table with all line items
Subtotal, tax, and total calculations
155 total text blocks

Processing time: ~2 seconds

Test 2: IRS Form 1040 (Tax Form)

Input: Official IRS form converted to PNG

Extracted:

1,412 text blocks
All form field labels
Form structure and layout
Every piece of text on the form

Processing time: ~3 seconds

Deployment: From Zero to Production in 10 Minutes

Here's what it actually took:

# 1. Build the application
sam build

# 2. Deploy to AWS
sam deploy --stack-name doc-processing-dev \
  --region us-east-1 \
  --capabilities CAPABILITY_IAM \
  --parameter-overrides NotificationEmail=your@email.com \
  --resolve-s3 \
  --no-confirm-changeset

# 3. Configure S3 event notifications
aws s3api put-bucket-notification-configuration \
  --bucket your-bucket-name \
  --notification-configuration file://s3-notification-config.json

# Done!

CloudFormation created:

1 S3 bucket
1 Lambda function
1 DynamoDB table
1 SNS topic with email subscription
2 CloudWatch alarms
1 SQS dead letter queue
All IAM roles and permissions

Total deployment time: 3 minutes

What I'd Do Differently

Start with PNG/JPG from day one - Would have saved hours of PDF debugging
Add async processing earlier - For multi-page documents, async Textract jobs are better
Include cost alerts - Set up billing alarms before deploying
Add API Gateway - Would make it easy to trigger processing via HTTP
Implement document versioning - Track changes to processed documents

The Bottom Line

Building this taught me that serverless isn't just a buzzword - it's genuinely transformative for document processing workflows.

What you get:

Automatic document processing in seconds
AI-powered data extraction (not just OCR)
Zero server management
Pay-per-use pricing
Production-ready error handling
Infinite scalability

What it costs:

~$1.50 per 1,000 documents
A few hours to set up
Zero ongoing maintenance

What you save:

Hundreds of hours of manual data entry
Countless transcription errors
Server infrastructure costs
DevOps overhead

Ready to Use It?

The entire project is production-ready and open source on GitHub: aws-intelligent-document-processing

Quick Start:

# 1. Clone the repo
git clone https://github.com/Tetianamost/aws-intelligent-document-processing.git
cd aws-intelligent-document-processing

# 2. Deploy to AWS (takes ~3 minutes)
sam build
sam deploy --guided

# 3. Upload a document
aws s3 cp your-document.png s3://your-bucket-name/incoming/

# 4. Check DynamoDB for extracted data

Everything you need is included:

✅ Lambda function code
✅ CloudFormation templates
✅ Sample documents (invoice + tax form)
✅ IAM permission templates
✅ Step-by-step deployment guide

Pro tip: Start with PNG images, not PDFs. Trust me on this one.

Have questions or built something similar? I'd love to hear about it! Drop a comment or reach out.

How I automated Certificate expiration alerts with AWS

Tetiana Mostova — Sun, 12 Jan 2025 22:00:19 +0000

Recently I faced a challenge with certificate rotation. While solving it, I discovered a neat way to automate certificate rotation alerts using AWS services. Although ACM Private Certificate Authority (PCA) with KMS can be used for signing certificates, in some cases a simpler solution using Secrets Manager might be more appropriate for your needs.

Prerequisites

AWS Account
Basic understanding of AWS services
AWS CLI configured (optional)

The Problem

For our simple signing certificate use case, we chose to store certificates in AWS Secrets Manager. This brought a new challenge: how to track expiration dates and ensure timely rotation?

Manual tracking of secret expiration dates is:

Error-prone
Easy to forget
Time-consuming
Stressful (nobody wants expired certificates in production!)

The Solution

I created a simple automation using three AWS services:

EventBridge for scheduling
Lambda for checking expiration
SNS for notifications

How It Works

Lambda checks secrets periodically
When a secret is nearing expiration, EventBridge triggers notifications
SNS sends alerts to the team

Here's the Lambda function that does the magic:

import json
import boto3
from datetime import datetime
import OpenSSL.crypto

def lambda_handler(event, context):
    secretsmanager = boto3.client('secretsmanager')
    sns = boto3.client('sns')

    try:
        # Get list of secrets
        secrets = secretsmanager.list_secrets()

        for secret in secrets['SecretList']:
            # Get the secret value
            secret_value = secretsmanager.get_secret_value(SecretId=secret['Name'])
            secret_dict = json.loads(secret_value['SecretString'])

            # Look for certificate entries (ending in .cert)
            for key, value in secret_dict.items():
                if key.endswith('.cert'):
                    # Parse the certificate
                    cert_data = value.replace('\\n', '\n')
                    cert = OpenSSL.crypto.load_certificate(
                        OpenSSL.crypto.FILETYPE_PEM, 
                        cert_data
                    )

                    # Get expiration date
                    expiry = datetime.strptime(
                        cert.get_notAfter().decode('ascii'),
                        '%Y%m%d%H%M%SZ'
                    )

                    # Calculate days until expiration
                    days_until_expiry = (expiry - datetime.utcnow()).days

                    # Alert if expiring within 60 days
                    if days_until_expiry <= 60:
                        sns.publish(
                            TopicArn='arn:aws:sns:REGION:ACCOUNT_ID:secret-rotation-alerts',
                            Subject=f'Certificate Expiration Alert - {key}',
                            Message=f'''
                            Certificate {key} in secret {secret["Name"]} is expiring soon!

                            Expiration Date: {expiry.date()}
                            Days until expiration: {days_until_expiry}

                            Please rotate this certificate soon.
                            '''
                        )

        return {
            'statusCode': 200,
            'body': 'Certificate check completed successfully'
        }

    except Exception as e:
        print(f"Error: {str(e)}")
        return {
            'statusCode': 500,
            'body': f'Error checking certificates: {str(e)}'
        }

Setting It Up

Step 1: Create an IAM Role for Lambda

Go to IAM Console
Click "Roles" → "Create role"
Select "AWS Service" and choose "Lambda"
Add following permissions (Create new policy):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:ListSecrets",
                "secretsmanager:DescribeSecret"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "sns:Publish"
            ],
            "Resource": "arn:aws:sns:REGION:ACCOUNT_ID:secret-rotation-alerts"
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:*:*"
        }
    ]
}

Name the role secret-rotation-checker-role

Step 2 Create SNS Topic:

   aws sns create-topic --name secret-rotation-alerts
   aws sns subscribe --topic-arn <your-topic-arn> --protocol email --notification-endpoint your@email.com

Next, confirm subscription via email.

Step 3: Create Lambda Function

Go to Lambda Console
Click "Create function"
Settings:
- Author from scratch
- Function name: secret-rotation-checker
- Runtime: Python 3.9
- Architecture: x86_64
- Permissions: Use existing role that we’ve created in previous stepssecret-rotation-checker-role
Paste the Lambda code above and remember to replace REGION and ACCOUNT_ID with your values then click "Deploy".

Step 4: Create EventBridge Rule

Go to EventBridge Console
Click "Rules" → "Create rule"

Settings:
- Name: quarterly-secret-check
- Description: "Check secrets every quarter for rotation"
- Rule type: Schedule
- Occurrence: Recurring schedule
- Schedule type: Cron-based schedule
- Cron: 0 9 1 1,4,7,10 ? * (Runs quarterly)

Select target:
- Target type: AWS Service
- Templated targets: Lambda Invoke
- Function: secret-rotation-checker

Why every 3 months?

Most secrets/certificates are valid for 1 year
Quarterly checks provide enough time to act
Reduces unnecessary Lambda executions
Still catches any missed rotations

Step 5: Test the Setup

Go back to Lambda console
Select your function
Click "Test" tab
Create new test event (empty {} is fine)
Click "Test"
Check CloudWatch logs for execution results
Check your email for any alerts

That's it! Now you'll get email alerts when secrets need rotation.

Customization Options

The Lambda function can be customized in several way. You can modify the code to check specific secrets by filtering them using tags, which is useful for managing different types of secrets separately. If you need earlier notifications, you can adjust the alert threshold from the current 330 days to any number that suits your rotation schedule. The notification system can be expanded beyond email by adding more SNS subscription types like Slack or Microsoft Teams. For more detailed tracking, you can enhance the alerts by including additional secret metadata and details in the notifications.

Cost Considerations

This automation solution is designed to be extremely cost-effective. Since the Lambda function only executes quarterly (4 times per year), the Lambda costs are minimal. SNS notifications are only triggered when secrets actually need rotation, making the messaging costs negligible. CloudWatch logs are kept minimal, only storing essential execution information, which keeps logging costs low. Overall, the entire setup typically costs less than a dollar per month, making it a cost-effective solution for maintaining security compliance.

Solution Comparison

While this blog post demonstrates a simple solution using Secrets Manager, it's worth mentioning that AWS offers other approaches for certificate management:

ACM Private Certificate Authority (PCA) with KMS could be used for signing certificates, but it involves:

Setting up and maintaining a CA hierarchy
Higher costs for standard CA (~$400/month per CA)
- A cheaper short-lived certificate mode exists ($50/month) but it's designed for certificates with short validity periods (hours/days)
More complex integration with KMS for signing operations
Better suited for enterprise-wide PKI needs or environments requiring frequent certificate rotation

Our Secrets Manager solution is ideal when you need:

Simple certificate storage and rotation
Direct key access for signing operations
Cost-effective solution (few dollars per month)
Quick implementation with minimal setup

Choose the approach that best fits your specific needs and scale.

Taking It Further

Want to automate the actual rotation? AWS Secrets Manager has a built-in rotation feature for some secret types. For custom secrets, you can write another Lambda function that:

Generates new secrets
Updates applications
Verifies everything works
Archives old secrets

But that's a topic for another post! 😉

Key Takeaways

Implementing this automation has taught me several valuable lessons. First and foremost, automating secret rotation tracking is significantly more reliable than manual tracking methods, eliminating human error and reducing operational overhead. The seamless integration between AWS services (Lambda, EventBridge, and SNS) demonstrates how powerful cloud services can be when used together. While the code implementation is relatively simple, it saves countless hours that would otherwise be spent on manual checks and tracking. Most importantly, this automation provides peace of mind – you can rest easier knowing that your secrets rotation schedule is being monitored automatically, and you'll receive timely notifications when action is needed.

Hope this helps someone else automate their secret management! Let me know if you have questions or suggestions for improvements.

Understanding RabbitMQ Brokers in AWS

Tetiana Mostova — Fri, 13 Dec 2024 23:32:21 +0000

What's a Message Broker?

A message broker is like a post office for your applications. Just as a post office manages the flow of mail between senders and receivers, a message broker manages the flow of messages between different parts of your system. They're called "brokers" because they broker (negotiate and manage) the communication between parties.

RabbitMQ is one type of message broker that:

Accepts messages from producers
Decides where to route them
Delivers them to consumers
Manages message storage when needed

Setting Up a Broker in AWS

AWS makes this easy through Amazon MQ. Here's how:

Go to AWS Console → Amazon MQ
Click "Create broker"
Choose engine type: RabbitMQ
Select deployment: Single-instance (dev) or Cluster (prod)

Choose broker name
Pick broker instance type (like mq.m5.large)
Set up username/password

Configure network in Advanced Settings Details (select VPC and subnets)

Review and create

After creation, AWS provides:

Endpoint for connections
Console URL for management
Monitoring through CloudWatch

Three Important Details About AWS RabbitMQ Brokers:

Network Type:
- Private: Only accessible within VPC (recommended)
- Public: Accessible from internet (use carefully)
Access Control:
- Username/password for connections
- Security groups for network access
- IAM for AWS console access
Monitoring:
- CloudWatch metrics included
- Broker health status
- Connection monitoring

Choose private access and proper security groups when starting out. You can always modify access later.

Remember: A broker is just a messenger - it needs proper setup to deliver messages reliably.

Cost Note

AWS charges for broker uptime, not message volume. Start with smaller instances for development.

Cracking the AWS Certified Database - Specialty Exam: My Tips and Tricks

Tetiana Mostova — Fri, 03 May 2024 19:17:42 +0000

Hey everyone,
I recently passed the AWS Certified Database - Specialty (DBS-C01) exam, and I wanted to share my experience and some tips that helped me along the way. If you're planning to take this exam, keep reading!

Know the Exam Guide:
First things first, make sure you read the AWS Certified
Database - Specialty (DBS-C01) Exam Guide. It tells you
exactly what services and topics you need to know before
taking the exam. Trust me, it's a lifesaver!
Use AWS FAQs and Whitepapers:
AWS has a ton of FAQs and whitepapers that can help you
prepare. Focus on the FAQs for the services mentioned in the
exam guide. They often have information that can help you
answer exam questions. And don't forget to check out the
whitepapers for a deeper understanding of database services
and best practices.
Practice with Tutorial Dojo:
Tutorial Dojo is awesome for practice questions. What I love
about them is that they explain why each answer is right or
wrong. They also have cheat sheets and other helpful
resources. Definitely check them out!
Use free exam topics questions:
Head over to examtopics.com and join the discussions. Even
though they might not give you the exact answers, following
other people discussions who have taken the exam can be
super helpful.
You can learn from their experiences and get a better idea
of what to focus on.

Exam Day Tips:

If you're taking the online exam from home, make sure you have a valid ID, a clean desk, and a quiet room. You can only use one screen during the exam.

Be ready for a lot of questions on TimeStream DB. Make sure you know this topic well.
Expect some tough questions on database migration and design, especially moving from on-premises to the cloud.
Don't panic if you come across difficult questions. Remember, there are 15 questions that don't count towards your score, but you won't know which ones they are. Let's hope it's the hardest ones and do your best on each question.

Preparing for the AWS Certified Database - Specialty exam takes time and effort, but with the right resources and practice, you can totally do it! Follow the tips I mentioned and use the study materials I suggested. Even if you feel unsure during the exam, trust yourself and keep going. When you pass, you'll feel so proud of yourself, and it will all be worth it. You've got this!
Good luck on your exam!

Handling EKS: kubectl, Namespaces, and CRDs

Tetiana Mostova — Sun, 04 Feb 2024 20:19:40 +0000

Managing EKS clusters from the command line can seem daunting at first, but having a grasp of some key kubectl commands will make you an expert in no time. In this beginner's guide, I'll walk through the most useful CLI commands for inspecting and troubleshooting your EKS workloads, nodes, namespaces and CRDs.
Let's start by looking at namespaces - these allow you to logically organize your cluster resources. To see current namespaces:
kubectl get namespaces
You can then specify a namespace when running commands:
kubectl get rs -n prod # rs stands for replica-set
This isolates prod resources from dev and test. Handy for access control between teams!

Here's a trick to set a default namespace so you don't have to enter it each time:
kubectl config set-context --current --namespace=dev
This will set the default namespace going forward to "dev". Now all kubectl commands will apply to that namespace by default:
kubectl describe secrets aws-secret # Describes aws-secret in dev namespace
And you can still override the default when needed:
kubectl get pods -n kube-system
One specially important namespace is kube-system. This houses critical cluster services and addons like:

CoreDNS - Cluster DNS
VPC Networking plugins
Node Termination Handler

Observe but don't modify kube-system to avoid issues!
Now, let's inspect pod workloads, the basic building blocks of EKS services:
kubectl get pods -n dev
This lists all pods in dev namespace and their status. To get more info on a specific pod:
kubectl describe node <node-name>
See the pattern here? "Get" for an overview, and "describe" for the nitty gritty details. This works for all Kubernetes resource types (e.g. kubectl get nodes, kubectl describe node <name> etc)
Finally, you can actually shell into a container with exec:
kubectl exec -it <pod-name> -- bash
This drops you into a bash shell running inside the pod, where you can inspect files, env vars, check connections, and troubleshoot further.

Inspecting Custom Resources

Many EKS addons and controllers introduce their own CustomResourceDefinitions (CRDs) - custom Kubernetes object types defined by scripts rather than baked into the main codebase.
For example, the AWS Load Balancer Controller has a CRD for defining Application Load Balancers.
You can view custom resources by running:
kubectl get crds
This will list all CRDs registered on the cluster. You can then operate on the custom resources themselves:
kubectl get albingress -n app-ns`
Here we are listing ingresses from the Application Load Balancer CRD.
CRDs allow developers to extend Kubernetes functionality without having to rebuild the core API. This enables rapid innovation. Definitely important to be aware of CRDs when running addons that enhance EKS!

As you can see, kubectl makes it easy to unlock the power of EKS! With these basic commands, you'll gain visibility and control over your clusters. The official kubectl cheat sheet lists even more goodies to try out.

Happy Kubectl-ing!

Use Go Lambda and API Gateway to Generate DynamoDB Tables on Demand

Tetiana Mostova — Sun, 10 Sep 2023 20:48:54 +0000

In my previous post, we focused on setting up Go correctly for Lambda development, zipping and uploading our function and troubleshooting issues like missing files. Now let's look at actually building our function.

Build GoLang Lambda Function

This code is a Go function that creates a DynamoDB table.

package main

import (
    "context"
    "log"

    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
    "github.com/aws/aws-sdk-go/aws"
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/dynamodb"
)

func createDynamoDBTable(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    sess := session.Must(session.NewSessionWithOptions(session.Options{
        SharedConfigState: session.SharedConfigEnable,
    }))

    // Create DynamoDB client
    svc := dynamodb.New(sess)

    // Define the table name, attribute definitions, key schema, and provisioned throughput
    tableName := "Movies"
    input := &dynamodb.CreateTableInput{
        AttributeDefinitions: []*dynamodb.AttributeDefinition{
            {
                AttributeName: aws.String("Year"),
                AttributeType: aws.String("N"),
            },
            {
                AttributeName: aws.String("Title"),
                AttributeType: aws.String("S"),
            },
        },
        KeySchema: []*dynamodb.KeySchemaElement{
            {
                AttributeName: aws.String("Year"),
                KeyType:       aws.String("HASH"),
            },
            {
                AttributeName: aws.String("Title"),
                KeyType:       aws.String("RANGE"),
            },
        },
        ProvisionedThroughput: &dynamodb.ProvisionedThroughput{
            ReadCapacityUnits:  aws.Int64(10),
            WriteCapacityUnits: aws.Int64(10),
        },
        TableName: aws.String(tableName),
    }

    // Create the DynamoDB table
    _, err := svc.CreateTable(input)
    if err != nil {
        log.Fatalf("Got error calling CreateTable: %s", err)
        return events.APIGatewayProxyResponse{
            StatusCode: 500,
            Body:       "Error creating DynamoDB table",
        }, err
    }

    return events.APIGatewayProxyResponse{
        StatusCode: 200,
        Body:       "Created the table " + tableName,
    }, nil
}

func main() {
    lambda.Start(createDynamoDBTable)
}

First we import Go packages to use DynamoDB and Lambda.

The func keyword declares our function. The ctx parameter provides "context" - extra information like time limits for the function. Ctx carries details such as the time left before the function shuts down automatically. It also contains data about the request and response between Lambda and API Gateway. You can think of ctx as getting the party location and time so you know when and where it's happening and be there on time at the right place.

Inside the function we use the AWS Go SDK to connect to DynamoDB. We call code from other packages using dot notation like aws.String.

Then we create a Movies table with Year and Title columns.
The imported packages are like toolkits that let us use DynamoDB and Lambda. We import them so our code can work with these AWS services.

The createDynamoDBTable function then uses the toolkits to connect to DynamoDB. It creates the table by calling the CreateTable method from the toolkit.

main() runs first when executed. It starts our table creation function.

Test our function

After we zipped and uploaded the function (see detailed steps here), let's test it to make sure that it's working as expected:

We're looking for the successful result:

Note: AWS may create resources for you to simulate the execution environment. If you'd like to invoke your Lambda function using API Gateway, please, remove DynamoDB table that was created in this step.

Add API Gateway to invoke Lambda

Navigate to the API Gateway service and click on "Create API" to start creating a new API.

Choose "HTTP API" or "REST API" depending on your requirements. HTTP APIs are suitable for simpler use cases, and that's what we'll use.

Define Your API's integration and Routes

Choose our "Lambda Function" as the integration type. This is the function that will be invoked when this API endpoint is accessed.

Next we'll add a Route. Routes define how incoming requests are mapped to the associated API Gateway resources and integrations. Each route can have different configurations, including the integration target (e.g., a Lambda function), request/response transformations, and authorization settings.

Our API Gateway will route POST /CreateDBTable requests to our Lambda function.

Let's choose default stage and proceed with creation process

Invoke API

In order to invoke our Lambda function through the API Gateway that we've configured with a POST route to /CreateDBTable, we can use a tool like curl or a similar HTTP client, or we can use a service like Postman. Here's how we can invoke our Lambda function using curl from the command line:

curl -X POST <base URL of our API Gateway stage> <the path to the POST route we've defined>

And voilà! We have successfully created a DynamoDB table by invoking a Lambda function with API Gateway!

Conclusion

Now you know how to build a Lambda function in Go that creates resources like DynamoDB tables. You also set up API Gateway to trigger it on demand.

You've got the skills to make serverless functions using AWS and connect them to various services. This opens up lots of possibilities to build powerful applications!

Happy coding!

Creating an AWS Lambda Function in Go and Troubleshooting Common Errors

Tetiana Mostova — Wed, 06 Sep 2023 00:39:44 +0000

Introduction

AWS Lambda is a powerful service that allows you to run your code without provisioning or managing servers. In this tutorial, we will walk through the process of creating an AWS Lambda function using the Go programming language (we are going to code a Lambda function in the next one). We'll also address a common error that you might encounter during this setup and provide solutions to resolve it.

Prerequisites

Before you begin, ensure you have the following:

An AWS account.
AWS CLI installed and configured: You can log in to your AWS account and configure the AWS CLI by running the following command in your terminal:

aws configure

This command will prompt you to enter your AWS Access Key ID, Secret Access Key, default region name, and output format. These credentials can be obtained from your AWS account settings under IAM > Users > Security credentials.

Go programming language installed.

Step 1: Setting up Go Modules

If you're working with Go, it's a good practice to use Go modules to manage your dependencies. Even for a single-file project, Go modules help maintain consistency and allow for future expansion.

In your project directory, initialize Go modules with your chosen module name:
go mod init DynamoDBCreateTable
Install any necessary dependencies using go get, if applicable.

Step 2: Building Your Lambda Function

Now, let's create your Lambda function using Go:

Write your Lambda function code in a Go file (e.g., DynamoDBCreateTable.go).
Build your Go code for the Lambda environment:
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -o bootstrap -tags lambda.norpc DynamoDBCreateTable.go

Note: The resulting binary is named "bootstrap" because AWS Lambda expects this name for Go functions (read more here). In many other programming languages, the handler for an AWS Lambda function is typically named as a method or function within your code. However, in Go, it should be specifically named "bootstrap".

Once you've created the AWS Lambda function with the correct handler name, you can proceed with the next step.

Step 3: Zip Your Go File

Before deploying your AWS Lambda function, you'll need to package your Go code into a zip file. In your terminal, navigate to the directory containing your Go code file, which in our case is "bootstrap." Run the following command to create a zip file:

zip DynamoDBCreateTable.zip bootstrap

This command will package your Go code into a zip file named "DynamoDBCreateTable.zip."

Step 4: Create the Lambda Function

Deploy your Lambda function using the AWS CLI:

aws lambda create-function \
--function-name CreateDBTable \
--runtime provided.al2 \
--handler bootstrap \
--architectures arm64 \
--role arn:aws:iam::11112222333:role/service-role/DynamoDBCreateTable**** \
--zip-file fileb://DynamoDBCreateTable.zip

--function-name: Specify a name for your Lambda function.
--runtime: Set the runtime to "provided.al2" for Go (recommended).
--handler: Set the handler to "bootstrap" to match the Go entry point.
--architectures: Specify the architecture as needed.
--role: Provide the ARN of the IAM role with necessary permissions.

Troubleshooting: Handling Common Errors

If you encounter the error message "fork/exec /var/task/bootstrap: no such file or directory: PathError," follow these steps:

Ensure that your Go code is correctly built for the Lambda environment.
Verify that the handler in your aws lambda create-function command is set to "bootstrap".
Double-check the IAM role's permissions to ensure it has access to the required AWS services.

Conclusion

Building Lambda functions with Go is a powerful way to run serverless code while making deployment easy. Just follow these steps and watch out for common mistakes. Now you've got the skills to launch your own Lambda functions using AWS CLI and leverage AWS's serverless platform.

Feel free to customize your code to connect with DynamoDB or other AWS services your app needs.

Stay Tuned: In our next post, we'll dive deeper into Lambda functions. We'll walk through creating one that dynamically generates DynamoDB tables by calling an API Gateway. This will expand your serverless skills so you can build scalable, efficient apps on AWS.

Keep coding and stay motivated!