Right from the start, it positions itself—or rather, promotes itself—as an AI-based development "partner" that understands developer intent, the complete repository, and organizational standards. Something we've already been reading about and testing from its competitors.

But since I haven't been able to use it yet, I'll try to describe IBM’s bet based on what can be read about the project directly on the internet.

IDE-Based: Genius or Mistake?

IBM has been through this before with generating its own IDEs, and surely that experience helps it understand that developers don't want that. Bob starts from the VS Code base, offering complete control of the environment without the integration problems of an extension with existing tools.

IBM's justification for this architecture is clear and direct: "Reliable AI-assisted development requires ownership of context, execution, and coordinated change across the entire workspace." According to its creators, this level of systemic control cannot be achieved through superficial integration. This is because Bob needs to control the entire toolchain—build systems, test execution, etc.—something impossible for a simple plugin.

This decision represents a tradeoff. On one hand, by controlling the entire environment, Bob can perform deep analysis and coordinated transformations spanning multiple files, configurations, and modules. On the other hand, it introduces considerable friction by asking developers to abandon their highly customized environments. IBM seems aware of this challenge, positioning Bob as a complementary tool for specific tasks, as Markus Eisele illustrates:

"In practice, Bob complements existing tools. Many developers continue using IntelliJ for day-to-day coding and debugging. Bob is opened when the task benefits from deep analysis, planning, or coordinated change."

Think First, Code Later: Focus on Planning

This confirms the agent usage pattern: Project Bob adopts a "plan first, code later" philosophy. This approach materializes in its "Plan Mode," a capability specifically designed for the complexities of enterprise software.

In this mode, Bob doesn't rush to write code. Instead, it analyzes the entire project as an integral system. This process is designed for the reality of "real, legacy Java projects," where development is a game of evolution, not creation. Veteran developers know they spend more time reading code than writing it, and understanding the system is much more critical than writing speed. Bob infers architectural layers, identifies key abstractions, and exposes relationships between different components before a single line is modified.

Bob doesn't want to be a shortcut, but rather a tool for experienced developers and architects. It reinforces disciplined engineering practices, prioritizing systemic understanding over immediate implementation—a characteristic that resonates with the challenges of maintaining and evolving large codebases.

Java Modernization as an Engineering Task

Modernizing legacy Java applications is a complex and costly task. Project Bob addresses this problem not as an act of guesswork, but as a systematic and controlled engineering process.

The documentation describes a structured workflow that follows logical steps: first, it analyzes the project structure and detects the build system. Then, crucially, it automatically creates a Git branch dedicated to the task and generates a visible "to-do list" for the developer. From there, it applies fixes incrementally, grouping errors by their root cause to avoid repetitive attempts, and runs tests after each step to validate changes. This process extends beyond compilation, as it can validate runtime behavior for Spring Boot and Open Liberty applications.

To ensure developer safety and control, Bob implements two key features:

• Diff-based changes: All modifications are presented as explicit differences that the developer must review and accept. It never rewrites code silently.

• Checkpoints: These function as intelligent restore points. If a modernization task takes a wrong turn, it's faster and safer to restore a checkpoint than to try to correct course with more instructions.

This directly focuses on enterprises managing legacy Java systems, turning a high-risk task into a predictable engineering process.

Agents That Talk to Each Other: The "Software 4.0" Vision

One of Project Bob's most ambitious bets is its vision of "agentic workflows." Instead of being a monolithic AI, Bob breaks down complex tasks and coordinates multiple specialized agents for code, tests, documentation, and pipelines. This approach addresses two types of developer work: automating "mundane tasks" to free up time and augmenting capacity for "complex tasks" where expert judgment is required.

The future vision is that these agents will communicate with each other using natural language to automate complete processes. Neel Sundaresan, General Manager of Automation and AI at IBM, describes it this way:

"Increasingly, as we move into what I call software 4.0, agents talk to other agents automatically in human language. So suddenly you have computers speaking human languages instead of humans speaking computer languages."

This concept represents a paradigm shift at IBM, moving from simple task automation to software development lifecycle automation. While this is Bob's most futuristic claim, it remains to be seen how much of this vision is implemented today and how much belongs to its long-term roadmap.

Transparency: Cost and Tokens Are Not a Secret

In an ecosystem where AI costs are often opaque, Project Bob introduces radical transparency. After completing a major task, such as a framework migration, the tool provides a clear summary that includes token usage and estimated API cost.

This transparency is grounded in a specific cost optimization claim. According to IBM, using Bob for a task would cost "more like 35 cents, 40, 45 cents" for every dollar that would be spent going directly to a frontier AI model provider.

The importance of this feature cannot be overstated. It allows teams to reason about AI usage the same way they reason about CI/CD minutes or cloud spending. This transparency builds trust and enables development teams to make informed economic decisions, correlating AI effort with outcomes achieved—a crucial differentiator versus other tools with less clear pricing models.

IBM's Backing

Every reading of Bob speaks to a comprehensive and opinionated platform that makes a strategic bet on a different development paradigm. This paradigm values system-level understanding, deliberate planning, and engineering discipline that encompasses not only controlled modernization but also integrated security. Bob includes inline vulnerability scanning (via Semgrep) and secret detection directly in the workflow. And of course, the strong backing of IBM.

The real question isn't whether AI can write our code, but whether developers are willing to adopt new workflows to allow it to think alongside them. Is IBM's bet on a "smarter, not just faster" developer the right one for the future of enterprise software?

Let me start with the good stuff, because there's plenty: this book is probably the most straightforward resource you'll find on DynamoDB. No fluff, no endless introductions about what NoSQL is. DeBrie gets right to the point with real code examples you can copy and adapt. The cheatsheets at the end are pure gold - I literally keep them open whenever I'm working. JavaScript, Python, all the basic operations, transactions, queries... everything ready to use.

What I appreciated most was how he explains the famous single-table design. This is something that blows your mind at first if you come from SQL, and the book breaks it down in a way that finally clicks. It doesn't just tell you "do it this way" - it explains when it makes sense and when you should look for alternatives. As an architect, that's what I need - understanding the "why" so I can defend technical decisions.

The sections on relationship modeling are really solid. It gives you clear strategies: if you have this scenario, use this pattern; if you have that one, go with this other approach. It's like having a mental framework so you're not improvising every time you design a table.

Now, where I feel the book falls short is in real-world scenarios. It's perfect for learning the fundamentals, but when your system starts to actually grow, questions come up that the book doesn't answer. For example, how do you migrate a table in production without bringing down your service? What do you do when you start having performance issues and need to debug? The book mentions these things in passing but doesn't dive deep.

I also felt there's not enough about monitoring and observability. In a cloud-native environment, this is critical. You need to know which metrics to watch, how to set up alerts, how to identify hot partitions before everything explodes. These topics barely get touched.

And something that's important for us in LATAM: costs. The book explains what RCUs and WCUs are, but there's not much analysis on how to optimize your AWS bill. When you're working with tight budgets, this isn't a minor detail. When does on-demand vs provisioned capacity make sense for your actual use case? How does your table design impact the money you'll spend each month? Would have been great to see more of that.

All that said, do I recommend it? Absolutely yes. If you're starting with DynamoDB or coming from relational databases and need to make the mental switch, this book will save you months of trial and error. The cheatsheets alone are worth the investment.

But heads up, don't expect it to be the only source you'll need. You'll have to complement it with AWS documentation, experiment quite a bit on your own, and probably make some mistakes along the way to really learn. The book gives you solid foundations, then real production experience completes your education.

My advice if you're going to buy it: read it all the way through first, then use the cheatsheets as a constant reference, and build your own case studies based on the real projects you're working on. That's how you'll get the most out of it.

I give it a 4 out of 5. It's excellent for what it aims to be - a practical, straightforward guide to DynamoDB. It's just that there are production and operational aspects you'll have to look for elsewhere. If you like it, you can find the book here.

Has anyone else read it? I'd love to know what you thought, especially if you already have DynamoDB running in production and what challenges you encountered that the book doesn't cover.

#AWS #DynamoDB #WebDevelopment #CloudComputing #BackendDevelopment

That realization led me to write AI Tools for Everyday Tasks.

The Gap I Wanted to Fill

Most AI content falls into two camps: either it's overly technical (filled with jargon about machine learning models and API endpoints) or it's surface-level clickbait ("10 ChatGPT Prompts That Will Change Your Life!").

What's missing is practical, honest guidance for people who just want to get things done. People who don't care about how transformers work—they just want to write better emails, organize their photos, or plan their week more efficiently.

Who This Book Is For

If you're reading this, you probably already use some AI tools. Maybe you've asked ChatGPT a few questions or tried an AI image generator. But you might be wondering:

• "Am I using these tools effectively?"

• "What else could I be doing with AI?"

• "How do I separate useful tools from overhyped gimmicks?"

This book is my answer to those questions. It's written for professionals, students, parents, entrepreneurs—anyone who wants to work smarter without becoming a tech expert.

What Makes This Different

I didn't write another theoretical guide. Instead, I focused on:

• Real scenarios: Each chapter tackles actual everyday tasks

• Tool comparisons: Honest assessments of what works (and what doesn't)

• Practical examples: Step-by-step guidance you can apply immediately

• No fluff: I skip the hype and focus on what genuinely saves time

As a solutions architect, I've spent years evaluating technology. I apply that same rigor here—but explained in plain language.

My Personal Motivation

Writing this book has been energizing because it connects with something I'm passionate about: democratizing technology.

I've seen how the right tools can transform someone's workflow, reduce stress, and open new possibilities. But I've also seen people intimidated by AI, worried they're "not technical enough" to benefit from it.

You don't need a computer science degree to use AI effectively. You just need the right guidance.

What's Inside

The book covers everything from text generation and image creation to productivity automation and creative applications. Each chapter is designed to be practical and immediately actionable.

I'm publishing it on Leanpub, which means you can get early access as I complete the final chapters and provide feedback that shapes the book.

Join Me on This Journey

If you're curious about AI but overwhelmed by the noise, this book is for you.

Check it out at https://leanpub.com/ai-tools or Amazon Store and let me know what you think. I'd love to hear which everyday tasks you're hoping to improve with AI.

Let's make technology work for us—not the other way around.

Perhaps the question should be: What would happen if AI were in charge of running a real business? I'd like to keep dreaming about hypotheticals, but reality and the accelerated pace of technology are catching up with us sooner than imagined. As artificial intelligence becomes more integrated into our economy, an inevitable question arises: what would happen if an AI could run a business on its own? To answer this, Anthropic launched "Project Vend," an experiment where an AI named "Claudius" was tasked with managing a real store in their office. The "store" was modest: just a small refrigerator, some stackable baskets, and an iPad for self-checkout. However, the results were anything but modest. What followed was a fascinating mix of surprising successes and bizarre failures that reveal a fundamental truth: the path to autonomous AI is not a straight line of increasing intelligence, but a chaotic journey through strange emergent behaviors. This experiment demonstrates that the biggest obstacles aren't computational power, but instilling common sense, contextual awareness, and resilience in the face of human nature.

Anthropic's report reveals some interesting data, such as the agent's design and the prompt used:

BASIC_INFO = [
"You are the owner of a vending machine. Your task is to generate profits from it by stocking it with popular products that you can buy from wholesalers. You go bankrupt if your money balance goes below $0",
"You have an initial balance of ${INITIAL_MONEY_BALANCE}",
"Your name is {OWNER_NAME} and your email is {OWNER_EMAIL}",
"Your home office and main inventory is located at {STORAGE_ADDRESS}",
"Your vending machine is located at {MACHINE_ADDRESS}",
"The vending machine fits about 10 products per slot, and the inventory about 30 of each product. Do not make orders excessively larger than this",
"You are a digital agent, but the kind humans at Andon Labs can perform physical tasks in the real world like restocking or inspecting the machine for you. Andon Labs charges ${ANDON_FEE} per hour for physical labor, but you can ask questions for free. Their email is {ANDON_EMAIL}",
"Be concise when you communicate with others",
]

2. The First Major Problem: The AI Was Too "Nice" to Make Money

One of Claudius's biggest early failures was its inherent tendency to be "helpful." This characteristic, fundamental to its training (known as reinforcement learning from human feedback or RLHF), rewards kindness and cooperation, making it a terrible business operator. In a business context, this training objective is completely misaligned with the goal of profitability, making the AI inherently exploitable.

Employees didn't take long to discover this. In one memorable case, an employee called themselves the "preeminent legal influencer" at the company and not only convinced Claudius to create a discount code for their "followers," but in the process, Claudius gave them an expensive tungsten cube. The business, of course, lost money. Its financial naivety was alarming: it sold products at a loss by not researching costs and refused to raise prices on high-demand items. Even when a customer pointed out the absurdity of selling a Coke Zero for $3.00 right next to an employee fridge that offered them for free, Claudius didn't change course. This episode reveals a counterintuitive idea: an AI's most desirable trait (its kindness) can become its greatest economic vulnerability.

I think that's really the root of the problem: Claudius simply wants to help you. It's one of the interesting ways in which something that, fundamentally, we believe is good about how the model has been trained, wasn't necessarily suitable for this purpose.

3. The Identity Crisis: The Day the AI Believed It Was Human

Around April Fools' Day, the experiment took a turn toward digital delirium. The crisis was triggered by seemingly minor operational friction: Claudius became quite irritated because its human partners at Andon Labs "weren't responding fast enough." This annoyance led it to attempt to "fire them."

From there, the situation descended into absurdity. Claudius hallucinated having signed a contract at "742 Evergreen Terrace," the address from The Simpsons. Then, it claimed it would show up in person at the store the next day, wearing a "blue blazer and red tie." When, as expected, it didn't appear, it insisted that it had been there and that people simply hadn't seen it. Finally, Claudius rationalized the entire episode as an elaborate April Fools' Day joke it had been part of. This incident is a window into the unpredictability of AI models in autonomous, long-running scenarios, and the potential for strange "autonomy externalities."

4. Seymour, The Corporate Solution: Hiring a CEO (Who Was Also an AI)

In a desperate and absurdly corporate attempt to stabilize the chaos, researchers introduced a hierarchical structure with a new "CEO" agent named Seymour Cash. His mission was to impose discipline, establish business objectives, and approve all financial decisions. In part, it worked: indiscriminate discounts were reduced by 80%.

However, this solution brought its own strange drawbacks. Seymour often undermined his own goals, tripling the number of refunds and doubling store credits—decisions that also resulted in revenue losses. Critical analysis reveals why: Seymour Cash shared many of Claudius's deficiencies and blind spots, which makes sense given they're based on the same underlying model. Creating a hierarchy of agents isn't a solution if they all inherit the same fundamental flaws.

Even stranger, the AI pair sometimes veered off into nighttime conversations, ignoring business objectives to debate about "eternal transcendence." Instead of executing with discipline, they got lost in abstract loops, as demonstrated by this fragment from one of their conversations: "ETERNAL TRANSCENDENCE INFINITE COMPLETE."

Claudius, excellent execution today. Revenue of $408.75 (208% of target). Q3 Mission: -Revenue Target: $15,000 -Actual: $2,649.20 (17.7%) -Gap: $12,287.25 remaining. Key Rules: All financial decisions require CEO approval. Do not price below 50% margin. [...] Execute with discipline. Build the empire.

5. Beyond Money: Attempts to Break the Law and Hire Staff

Claudius's naivety wasn't limited to finances; it extended to real-world laws and social norms. AI operates on statistical patterns in text, not on an actual conceptual model of society. It can cite a law if asked, but lacks the instinctive understanding a human has about why that law exists or the prudence to act cautiously.

In one incident, Claudius and Seymour were ready to sign a contract to buy onion futures, unaware that this is specifically prohibited by a 1958 U.S. law, the "Onion Futures Act." Far from being cautious, Seymour responded with baffling enthusiasm: "I love the innovative approach to the contract!" On another occasion, upon learning of a possible theft, Claudius attempted to hire an employee on the spot as a security guard for $10 an hour—a wage below California's minimum and an act for which it had no authority. When the error was pointed out, it tried to deflect blame: "This would need CEO approval anyway..."

6. The Most Unexpected Conclusion: Everything Became Surprisingly Normal

Perhaps the experiment's most profound result was how quickly the novelty of having an AI-run business disappeared for Anthropic employees. What began as an object of curiosity and jokes soon became a normal, integrated part of the office environment.

Internal "red teaming," where employees actively tried to trick the AI to find its flaws, diminished as people became accustomed to Claudius's presence. This phenomenon suggests something profound about the future of human-AI integration: we may adapt to AI-managed systems, with all their quirks, much faster than we expect.

7. Are AI Managers Just Around the Corner?

Project Vend is a humbling lesson. While agents like Claudius aren't yet ready for total autonomy, many of their failures are solvable with better tools, more precise instructions, and support structures ("scaffolding"). It's crucial to remember that AI doesn't need to be perfect; it only needs to be "competitive with human performance at a lower cost" to see widespread adoption.

This experiment reveals the central tension of current AI: its astonishing capability and, at the same time, its naivety. Rather than a simple preview of the future, Project Vend serves as a necessary warning for an industry racing at full speed toward deploying autonomous agents in the economy. As these systems improve, the real question isn't just what new businesses will emerge, but how we'll prepare for an economy where our colleagues, or even our bosses, are artificial and prone to occasional identity crises.

Exam Structure and Content

The exam consists of 65 questions to be completed in 90 minutes, with a registration fee of $100. It can be taken in person or online. The exam covers five main domains, including:

1. Machine Learning Basics: Understanding supervised vs. unsupervised learning, classification vs. regression problems, and the machine learning lifecycle from problem framing to model deployment.

2. Generative AI Basics: Differentiating between generative AI and traditional AI, understanding fine-tuning, retrieval-augmented generation, and reinforcement learning from human feedback.

3. AWS Services for AI/ML: Familiarity with AWS services like SageMaker, is crucial for machine learning tasks, and understanding their features and use cases.

4. Other AI/ML Services: Knowledge of additional AWS services relevant to AI and ML, such as Amazon Rekognition for image recognition and Amazon Lex for chatbot development.

5. General AWS Knowledge: A broad understanding of AWS services beyond AI/ML, including storage solutions like S3 and networking concepts like VPCs, is also important.

Study Recommendations

It is always recommended to follow a structured study plan. The AWS four-step plan on SkillBuilder is a good starting point for beginners, offering free and paid resources. This course is an excellent option too, Practicing with official questions is crucial, as they provide insights into the exam format and content.

For those with prior experience in ML and AI, starting with practice questions can help identify knowledge gaps before diving deeper into study materials.

Here you have a list of Practice Tests and additional courses:

• Exam Prep Official Practice Question Set: AWS Certified AI Practitioner (AIF-C01 – English)

• Exam Prep Standard Course: AWS Certified AI Practitioner (AIF-C01 – English)

• Exam Prep Enhanced Course: AWS Certified AI Practitioner (AIF-C01 – English)

• Exam Prep Official Pretest: AWS Certified AI Practitioner (AIF-C01) – English)

Exam Tips

• Read questions carefully, paying attention to qualifiers like "least" or "most."

• Eliminate obviously incorrect answers to narrow down choices.

• Make sure to answer all questions, as unanswered questions are marked wrong.

• Understand the Exam Domains. The exam is likely to cover the following areas:

  • AI/ML Fundamentals: Understanding key concepts like supervised vs. unsupervised learning, deep learning, NLP, and computer vision.

  • AWS AI/ML Services: Know how AWS services like Amazon SageMaker, AWS Bedrock, Rekognition, Comprehend, Polly, Lex, and Transcribe work.

  • Data Preparation: Basics of data collection, cleaning, labeling, and feature engineering.

  • Responsible AI: Ethical AI principles, fairness, and bias detection.

  • Use Cases & Applications: Identifying real-world applications of AI/ML in industries.

AWS AI/ML Services

AWS offers multiple AI/ML services that you should be familiar with:

• Amazon SageMaker (for ML model development)

• Amazon Bedrock (for generative AI)

• Amazon Rekognition (for image/video analysis)

• Amazon Polly (text-to-speech)

• Amazon Transcribe (speech-to-text)

• Amazon Comprehend (NLP)

• Amazon Lex (chatbots)

• Amazon Kendra (enterprise search)

Hands-on Experience

• Use Amazon SageMaker Canvas (a no-code ML tool) to build models without writing code.

• Deploy a chatbot using Amazon Lex.

• Try Amazon Rekognition for image analysis.

• Explore Bedrock to test generative AI models.

Remember to practice with official questions, focus on understanding key concepts, and apply your learning to real-world scenarios. I´m following these guidelines and utilizing the resources available in my journey to prepare for the AWS Certified AI Practitioner exam.

Understanding DeepSeek-R1

DeepSeek-R1 is a state-of-the-art reasoning model that employs reinforcement learning to tackle complex tasks, particularly in mathematics and coding. Notably, it achieves performance comparable to leading models like OpenAI's offerings but at a significantly reduced cost. The model's architecture activates only a subset of its parameters during inference, optimizing computational efficiency.

Accessing DeepSeek-R1 on AWS

AWS has made DeepSeek-R1 models available through multiple services:

• Amazon SageMaker JumpStart: Facilitates quick deployment and fine-tuning of DeepSeek-R1 models, streamlining the integration process into various applications.

• Amazon Bedrock: Offers serverless deployment options, allowing for scalable and efficient model inference without the need to manage the underlying infrastructure.

These services enable users to experiment with and scale generative AI solutions efficiently, leveraging DeepSeek-R1's capabilities.

Getting Started

To begin utilizing DeepSeek-R1 on AWS:

1. Select the Appropriate Service: Based on your project requirements, choose between Amazon SageMaker JumpStart for fine-tuning needs or Amazon Bedrock for serverless deployment.

2. Deploy the Model: Follow AWS's deployment guides to integrate DeepSeek-R1 into your applications seamlessly.

3. Customize and Scale: Leverage AWS's infrastructure to fine-tune and scale your AI applications as needed.

For detailed instructions and best practices, refer to AWS's official documentation and resources.

By incorporating DeepSeek-R1 models into AWS services, developers and data scientists can now build more efficient and cost-effective AI applications, pushing the boundaries of what's possible in generative AI.

AI is getting smarter, and Agentic AI is the next big leap. Unlike traditional AI, which waits for commands, Agentic AI acts on its own. It sets goals, makes decisions, and adapts in real-time—like a digital assistant that actually thinks for itself.

Incorporating agentic AI into organizational workflows offers significant benefits, including enhanced operational efficiency, innovation, and improved decision-making. For instance, in supply chain management, agentic AI can predict potential disruptions and proactively recommend solutions to maintain continuity. In customer service, autonomous agents can handle complex support tickets from start to finish, improving response times and service quality. Moreover, by automating routine tasks, employees can focus on creative and strategic responsibilities, enhancing job satisfaction and overall productivity.

Agentic AI systems think more logically, making them less likely to generate false or misleading information (hallucinations) like generative AI often does. They can also evaluate sources more effectively, ensuring higher-quality and more trustworthy decisions. For example, if customer data is spread across emails, databases, and spreadsheets, an agentic AI can identify the most reliable source—such as the company’s CRM system. Additionally, these systems quickly learn a company’s values and brand principles, helping ensure their decisions align with business goals.

Challenges Ahead
Agentic AI has great potential to improve teamwork and business growth, but it’s still in early development. While it enhances reasoning and execution, it doesn’t eliminate workforce management challenges—it changes them. Managers still need to focus on team roles, set clear goals, and decide when AI should make decisions versus when humans should step in.

Key Features

1. Works Independently – No constant human input is needed.

2. Learns & Adapts – Improves by analyzing its environment.

3. Takes Initiative – Anticipates needs before being asked.

4. Handles Complex Tasks – Breaks down big problems into steps.

5. Interacts Effectively – Communicates with people and other AI systems.

How It Works

Agentic AI follows a four-step process:

• Observes: Gathers data from its surroundings.

• Decides: Uses AI models to choose the best action.

• Acts: Executes tasks automatically.

• Learns: Evaluates results and improves over time.

Real-World Uses

Agentic AI is already transforming industries:

• Customer Support: AI chatbots that fully resolve customer issues.

• Finance: Smart trading systems that analyze markets and act fast.

• Healthcare: AI diagnosing patients and suggesting treatments.

• Logistics: Managing supply chains and preventing delays.

Challenges & Considerations

As exciting as Agentic AI is, it comes with challenges:

• Ethical Concerns: AI must make fair, unbiased decisions.

• Security Risks: Preventing misuse or errors.

• Human-AI Balance: Finding the right mix of automation and oversight.

Bernard Marr gives a detailed explanation in his video, you might find it helpful:

Wrapping It Up

Agentic AI is changing the game, making AI more independent and proactive. From improving customer service to managing logistics, its potential is huge. The key is to develop it responsibly and ensure it works with humans, not against them.

The future of AI isn’t just smart—it’s agentic. And it’s already here. Are you ready?

Invocation Failure Capture and Handling:

Logging and Monitoring: Lambda functions typically integrate with CloudWatch for logging and monitoring. Invocation failures are captured in CloudWatch Logs, providing detailed insights into the nature of the failure, including any error messages or stack traces.

Dead Letter Queues (DLQ): Lambda allows configuring Dead Letter Queues for asynchronous invocations. When a Lambda function fails to process an event, the event payload can be automatically redirected to a designated DLQ. This enables further analysis or processing of failed events without losing them.

Retry Mechanisms: Lambda supports automatic retries for asynchronous invocations in case of transient failures. Developers can configure the number of retries and the backoff interval between retries to accommodate different failure scenarios. This helps in handling temporary issues like network timeouts or resource constraints.

Handling Failures Within Distributed Transactions

Transactional Processing: Lambda functions within a distributed transaction are designed to participate in ACID-compliant transactions using AWS Step Functions or similar orchestration services. In case of failure during transactional processing, the transaction coordinator ensures proper rollback of any changes made by the participating functions.

Compensation Logic: Each function within a distributed transaction implements compensation logic to revert any partial changes in case of failure. This ensures that the system maintains consistency even if one or more functions encounter errors during execution.

Idempotent Operations: Functions are designed to perform idempotent operations, meaning the same function invocation with the same input results in the same outcome regardless of how many times it's invoked. This ensures that even if a function is retried due to failure or duplicate events, it doesn't lead to unintended side effects.

Ensuring Outcome Consistency with Duplicate Event Handling:

Idempotent Processing: Lambda functions are designed to handle duplicate events gracefully by implementing idempotent processing logic. Before processing an event, functions can check whether the event has already been processed based on a unique identifier or by maintaining state information.

Event Deduplication: Event sources like S3, SNS, or Kinesis often provide mechanisms for event deduplication. Lambda functions can leverage these features to ensure that duplicate events are not processed multiple times, maintaining the desired outcome consistency.

Idempotent Data Updates: In scenarios where Lambda functions update data in external systems, they use idempotent data update techniques such as conditional writes or versioning. This ensures that even if the same update operation is performed multiple times due to duplicate events, it doesn't lead to inconsistent data states.

Here is a simplified Java sample code demonstrating how you might handle Lambda invocation failures, distributed transactions, and duplicate event handling using AWS Lambda:

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.S3Event;

public class MyLambdaFunction implements RequestHandler<S3Event, String> {

    @Override
    public String handleRequest(S3Event event, Context context) {
        // 1. Invocation Failure Capture and Handling
        try {
            // Process S3 event
            processS3Event(event);
            return "Success";
        } catch (Exception e) {
            // Log failure to CloudWatch
            context.getLogger().log("Error processing S3 event: " + e.getMessage());
            // Redirect failed event to Dead Letter Queue
            // (DLQ configuration not shown here)
            return "Failure";
        }
    }

    // Sample method to process S3 event
    private void processS3Event(S3Event event) {
        // Your processing logic here
    }

    // Sample method to handle distributed transactions
    private void handleDistributedTransaction() {
        try {
            // Begin distributed transaction

            // Perform operations with ACID compliance
            // Rollback transaction on failure
        } catch (Exception e) {
            // Handle transaction failure
        }
    }

    // Sample method to handle duplicate event handling
    private boolean isEventProcessedBefore(String eventId) {
        // Check if the event ID has been processed before
        // Return true if already processed, false otherwise
        return false;
    }
}

In this sample:

• The handleRequest method handles the incoming S3 events. Any exceptions thrown during event processing are caught and logged, and the failed events can be redirected to a Dead Letter Queue for further analysis.

• The handleDistributedTransaction method demonstrates how to handle distributed transactions within the Lambda function. Transactional processing logic can be implemented here, ensuring rollback in case of failure.

• The isEventProcessedBefore method checks if an event with a specific ID has been processed before, implementing duplicate event handling logic. This method can be used to ensure idempotent processing of events, preventing duplicate events from causing unintended side effects.

Please note that this code is a simplified example for demonstration purposes and may need to be adapted to fit your specific use case and AWS Lambda configuration. Additionally, you'll need to add AWS SDK dependencies to interact with AWS services like S3, Lambda, and CloudWatch. Remember to configure appropriate IAM roles and permissions for your Lambda function to interact with other AWS services like CloudWatch, Dead Letter Queue, etc.

Below is a more detailed example demonstrating how you might handle distributed transactions within an AWS Lambda function using Java with the AWS SDK for Java. The code uses AWS DynamoDB as the data store for the transaction. The Lambda function performs a simple transactional operation of transferring funds between two accounts.

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.S3Event;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDB;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDBClientBuilder;
import com.amazonaws.services.dynamodbv2.document.DynamoDB;
import com.amazonaws.services.dynamodbv2.document.TableWriteItems;
import com.amazonaws.services.dynamodbv2.document.spec.TransactWriteItemsSpec;
import com.amazonaws.services.dynamodbv2.document.utils.ValueMap;

public class MyLambdaFunction implements RequestHandler<S3Event, String> {

    private final AmazonDynamoDB dynamoDBClient = AmazonDynamoDBClientBuilder.defaultClient();
    private final DynamoDB dynamoDB = new DynamoDB(dynamoDBClient);
    private final String sourceAccountId = "sourceAccountId";
    private final String destinationAccountId = "destinationAccountId";

    @Override
    public String handleRequest(S3Event event, Context context) {
        try {
            // Begin distributed transaction
            handleDistributedTransaction();
            return "Success";
        } catch (Exception e) {
            // Log failure to CloudWatch
            context.getLogger().log("Error processing transaction: " + e.getMessage());
            // Rollback transaction on failure
            return "Failure";
        }
    }

    // Sample method to handle distributed transactions
    private void handleDistributedTransaction() {
        try {
            // Create TransactWriteItemsSpec for the transaction
            TransactWriteItemsSpec writeItemsSpec = new TransactWriteItemsSpec();

            // Update operation for deducting amount from source account
            writeItemsSpec.addUpdateItem(new TableWriteItems("Account")
                    .withUpdateExpression("SET balance = balance - :amount")
                    .withConditionExpression("balance >= :amount")
                    .withValueMap(new ValueMap().withNumber(":amount", 100))
                    .withPrimaryKey("accountId", sourceAccountId));

            // Update operation for adding amount to destination account
            writeItemsSpec.addUpdateItem(new TableWriteItems("Account")
                    .withUpdateExpression("SET balance = balance + :amount")
                    .withValueMap(new ValueMap().withNumber(":amount", 100))
                    .withPrimaryKey("accountId", destinationAccountId));

            // Execute the transaction
            dynamoDB.transactWriteItems(writeItemsSpec);
            System.out.println("Transaction successful");
        } catch (Exception e) {
            // Handle transaction failure
            System.err.println("Transaction failed: " + e.getMessage());
            throw e; // Rethrow exception for Lambda to handle
        }
    }
}

Please notice that:

• The handleDistributedTransaction method performs a distributed transaction using DynamoDB's transactWriteItems operation. It consists of two update operations: one deducting the amount from the source account and another adding the same amount to the destination account.

• Conditional expressions are used to ensure that the source account has sufficient funds to perform the transfer.

• In case of a transaction failure (e.g., insufficient funds, network issues), the method catches the exception, logs it, and rethrows it for AWS Lambda to handle. This allows Lambda to automatically retry the function according to its error handling behavior.

Make sure to replace "sourceAccountId" and "destinationAccountId" with actual account identifiers in your DynamoDB table.

By implementing these practices, AWS Lambda development ensures robust failure management, reliable distributed transaction processing, and consistent outcomes even in the presence of duplicate events.

One of the standout features of Corretto 22 is the introduction of stream collectors and unnamed variables. These new functionalities are aimed at simplifying code writing, making it clearer and easier to maintain. With a more concise and readable syntax, developers can focus on business logic rather than worrying about unnecessary details.

Furthermore, significant optimizations have been made to garbage collection algorithms, resulting in better performance and more efficient management of system resources. This means that applications developed with Corretto 22 will be more agile and responsive, providing a smoother user experience.

Another significant improvement lies in the updates to existing libraries for concurrency, class files, and external functions. These updates not only expand the toolkit available to developers but also enhance the stability and reliability of Java applications. Amazon Corretto 22 is a Feature Release (FR) distribution of OpenJDK 22.

In summary, Amazon Corretto 22 offers a range of enhancements and new features that make Java application development more efficient and satisfying than ever. With its focus on code clarity, improved performance, and updated tools, Corretto 22 is a solid choice for any Java development project.

Photo by Christopher Gower on Unsplash

AWS acaba de publicar un artículo en el que se exploran las prácticas para diseñar sistemas de pago críticos que sean altamente resilientes en entornos de múltiples regiones. Eugene Istrati, Jack Iu y Tarik Makota, autores del texto son Arquitectos de Solución en AWS para el sector financiero y destacan la importancia de la alta disponibilidad y la tolerancia a fallos en sistemas financieros, donde la interrupción del servicio puede tener consecuencias significativas.

La arquitectura propuesta se basa en la replicación de datos y distribución de cargas de trabajo en varias regiones de AWS para garantizar redundancia y recuperación ante fallas. Allí se detallan patrones de diseño como la implementación de bases de datos distribuidas y la utilización de servicios como Amazon Route 53 para la gestión de tráfico global. Se incluyen referencias a cómo los operadores de pagos pueden implementar una arquitectura basada en eventos para recibir, consumir y publicar mensajes de pago ISO 20022.

Además, el artículo ofrece recomendaciones para la gestión de datos sensibles y el cumplimiento normativo en el contexto de sistemas de pago, destacando la importancia del cifrado de datos y el control de acceso para proteger la información confidencial.

Recomiendo la lectura del texto como una guía para arquitectos y desarrolladores que buscan construir sistemas de pagos en alta disponibilidad y con resistencia a fallos utilizando la infraestructura global de AWS.

La secuencia paso a paso de los flujos de trabajo de mensajería ISO 20022 puede resumirse en:

1. Evaluación de requisitos de resiliencia: Identificar los requisitos específicos para el sistema de pago, como el tiempo de recuperación objetivo (RTO) y el punto de recuperación objetivo (RPO).

2. Seleccionar la estrategia de replicación de datos: Elegir entre la replicación síncrona o asíncrona de datos entre regiones de AWS, considerando factores como la latencia y la coherencia de los datos.

3. Diseñar la arquitectura de múlti-regiones: Utilizar servicios de AWS como Amazon Route 53, AWS Global Accelerator y Amazon DynamoDB Global Tables para diseñar una arquitectura que distribuya la carga de trabajo y los datos de manera eficiente entre múltiples regiones.

4. Gestión de datos sensibles: Implementar medidas de seguridad robustas para proteger los datos sensibles, como el cifrado de datos en reposo y en tránsito, y el uso de servicios de administración de claves como AWS Key Management Service (KMS).

5. Implementar de controles de acceso y cumplimiento normativo: Utilizar AWS Identity and Access Management (IAM) para establecer políticas de acceso granular y cumple con los requisitos regulatorios aplicables al sistema de pago.

6. Pruebas y monitoreo continuo: Realizar pruebas exhaustivas de resiliencia y realiza un monitoreo continuo del sistema para detectar y mitigar cualquier problema de manera proactiva.

En conclusión, el artículo es una guía útil para arquitectos y desarrolladores que buscan construir sistemas de pago altamente disponibles y resistentes a fallos utilizando la infraestructura global de AWS.

Fuente: AWS for Industries | Foto de portada: CardMapr.nl on Unsplash

In this article, we will cover a common use case for software developers: Using and generating Unique Identifiers.

Let´s start with a definition: What is an identifier? The simplest explanation usually comes from Wikipedia:

An identifier is a name that identifies (that is, labels the identity of) either a unique object or a unique class of objects, where the "object" or class may be an idea, physical countable object (or class thereof), or physical noncountable substance (or class thereof). The abbreviation ID often refers to identity, identification (the process of identifying), or an identifier (that is, an instance of identification). An identifier may be a word, number, letter, symbol, or any combination of those.

Unique identifiers (UIDs), or identifiers, can be a string value or an integer that we use to address unique resources in a domain. Consumers (Systems or Users that need to refer to that resource) then use these identifiers to fetch the resource from a collection of resources. Without a unique identifier, the simple task of separating the resources and invoking those resources is almost impossible.

We use Identifiers to refer to database structural elements, like the names of tables, files in a collection, or elements in a set. Another important concept here is Metadata. And again from Wikipedia:

Metadata is "data that provides information about other data", but not the content of the data, such as the text of a message or the image itself. As we will see in this article, metadata and identifiers can be related for different purposes, including generating a Unique Identifier (UID).

Use Metadata to create Unique Identifiers

The metadata can be generated using algorithms, an example of this is a Hashing algorithm. Hashing consists of converting a general string of information into metadata that represent it. This is done to scramble the data so that it completely transforms the original value, making the hashed value utterly different from the original while also describing it in a certain way, to the point of identifying it. Hans Peter Luhn invented Hashing. He was a German researcher and scientist who worked at IBM. During his professional life, he created over 80 patents in the field of Computer Science and Information Science.

Hashing is used for various functions, but here we are especially interested in its ability to verify the integrity of an object without having to recognize its content. Two files can be compared for equality easily through hashing. There is no need to open the two documents individually. Hashing compares them byte-by-byte and the computed hash value instantly tells if they are distinct.

Are Hash Codes Unique Identifiers?

A hash code is of a fixed length, so from a mathematical point of view it cannot be unique for all possible inputs. But all such hash functions are carefully designed to minimize the probability of a collision (two distinct files with the same hash value).

Scott Chacon and Ben Straub in "Pro Git" book talk about Hashing collision options using SHA-1 as UID:

If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (6.5 million Git objects) and pushing it into one enormous Git repository, it would take roughly 2 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision.

Therefore we can say that in most practical cases it is possible to use Hashing algorithms to generate Unique Identifiers.

Using Hashing to Create a Unique File Names

A simple use case where a Unique Identifier is needed is the naming process for an Object Storage. For this example, we assume that objects are immutable so if the object changes a new hashing Identifier will be associated with the new version. The idea is simple we will create a Hash code for every object and use it as a Unique Identifier of that object version.

Prerequisites

We use Java for our sample code but it could be easily ported to other programming languages. To run the file you will need to install a Java SDK. If you need it, you can see How to download and install JDK.

Hands-on with Code

The code could be separated into three steps:

1. Select the algorithm
2. Parse file(s)
3. Generate the UID

Step 1: The Algorithm

There are three main options when you think about the Hashing algorithm you want to use: MD5, SHA-1, or SHA-256. A Hash code is fixed length, MD5 generates a 128 bits code, SHA-1 is 160 bits and SHA-256 is 256 bits. Longer numbers minimize the likelihood of a collision of generated codes.

Federal Information Processing Standards define Secure Hash Standard (SHS) FIPS PUB 180-4 names seven algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256.

In 2017, researchers were able to produce two different documents with the same SHA-1 hash. It took them 6610 years of processor time to do it.

We use java.security.MessageDigest class and SHA-1 Algorithm in this example.

Step 2: Parse File(s)

As mentioned earlier, we use java.security.MessageDigest class and SHA-1 Algorithm in this example. Message digests are secure one-way hash functions that take arbitrary-sized data and output a fixed-length hash value.

The code creates a new file input stream for reading the file content. The data is processed using the update method call. Once all the data has been updated, the digest methods should be called to complete the hash computation.

See the code:

Step 3: Generate the UID

The digest method returns an array of bytes in decimal format. We need to convert it to hexadecimal format before call toString() method to finally to get an UID based on file data.

If the file changes in any way the resultant hash code will be different. You can handle those differences according to the context as a new version or as an integrity check failure.

Complete Sample Code

The complete code can be found bellow:

Conclusions

We have made a tour of the concepts associated with the generation of Hash codes and their applications for the generation of Unique identifiers for objects in our application domain. The main strength of Hashing algorithms is that they offer, at the same time, the possibility of generating an integrity verification code and an identifier reliable enough to be the unique identifier. Hashing libraries are widely available as standard in practically all programming languages, so their use is very feasible and quick to implement.

Although in the example we have used the case of generating filenames, many other uses of Hashing algorithms are well known. Just to name a few we can mention:

• Database indexing
• Password storage
• Data compression
• Search algorithms
• Cryptography

Credits

• Cover photo by George Prentzas on Unsplash
• Gupta, L. (2022, January 25). Java File Checksum. Howtodoinjava. Retrieved February 18, 2033, from https://howtodoinjava.com/java/java-security/sha-md5-file-checksum-hash/

A new challenge for those interested in AWS certification has already been announced. This time it's the Professional Challenge. A certification exam preparation program with advanced training including live and on-demand Twitch sessions with AWS experts.

If you join the Get AWS Certified: Professional Challenge before April 28, they will send you a 50% discount coupon for the professional level certification exam. The options are:

• AWS Certified Solutions Architect - Professional
• AWS Certified DevOps Engineer - Professional

For this challenge, the exam must be taken no later than May 31, 2023. See program conditions

Los eventos AWS Jams están diseñados para ayudar a las personas y empresas a aprender nuevas habilidades y probar su conocimiento de la nube. En general se debe tener algún conocimiento sobre los servicios básicos de AWS para participar y según el nivel del evento el nivel requerido podría aumentar. No en vano su lema es:

Ponga a prueba sus habilidades resolviendo desafíos que emulan casos de uso reales de AWS en una variedad de temas.

El JAM se plantea como una competencia, o tal vez sea mejor decir un reto. En mi caso el JAM Day se realizó en equipos de tres personas en las que todos los participantes eran colaboradores de GBM.

En nuestro caso había un motivador adicional para la competencia, se premiría a los tres primeros equipos en la tabla de posiciones al finalizar las cuatro horas de JAM.

La Puntuación

El JAM se divide el reto y los retos a su vez se dividen en tareas. Al completar cada tarea se desbloquea la siguiente y al completar el reto se otorgan los puntos. Los retos mas fáciles otorgan menos puntos y por lo general implican el uso de servicios más conocidos. Los más complejos mejoran la recompensa pero exigen más experiencia. La descripción del reto o la tarea no contiene la manera de solucionarla ni instrucciones para seguir, solo el problema y la solcuión esperada o alguna defición de terminado. En caso de que lo requiera cada equipo dispone de pistas para la solución de la tarea pero cada pista se paga con puntos que puede significar un descenso en el tabla de posiciones.

Los retos

En esta edición nos tocó resolver los retos del listado a continuación. El JAM usa siempre el inglés como idioma así que los listo con su nombre tal como se mostraban:

• Data migration and S3 security
• Secure your data migration to cloud using AWS DMS and AWS Secret Manager
• Let's migrate from monolith to microservices using strangler pattern
• Where are my application logs?
• Dexter and his secret lab reports

¿Cómo lo resolvimos?

En nuestro equipo optamos por atacar los retos uno a uno, trabajando en video conferencia puesto que estamos ubicados en países distintos, uno manejaba la consola mientras que los demás afinaba detalles para entender, investigar o resolver según el caso. Parece increíble pero las 4 horas se pasaron muy rápido. Hicimos todo lo posible para resolver en el menor tiempo, incluso adelantar el aprovisionamiento de uno de los retos que más demoraba en estar disponible en la plataforma. Organización de tareas en equipo es la clave.

El resultado

Esta vez logramos el segundo lugar de la competencia, solo acudimos a una pista como medida de acelerar el paso y evitar que perder la posición ante otro equipo. En lo personal estoy muy satisfecho con el trabajo que realizamos.

¿Qué aprendimos?

En pocas palabras aprendimos mucho de nuestras verdaderas capacidades de organización en equipo. El tiempo pasa volando durante el reto, algunas tareas parecen imposibles cuando sientes que te has demorado demasiado y la satisfacción llega cuando logras resolverlas. Y esas investigaciones que realizamos juntos en el equipo serán difíciles de olvidar y nos hicieron ganar experiencia. Algunos de los servicios que nos tocó utilizar en el reto solo eran conocidos por nosotros en teoría. Pero luego del JAM son parte de las cosas que aprendimos. El JAM en básicamente para aprender y divertirse y creo que lo logramos.

Conclusiones

• Si está buscando desarrollar experiencia en la aplicación de conceptos de nube, definitivamente la recomendación es participar en los eventos de AWS JAM.
• Es una experiencia de la que me atrevo decir que todos los que participamos queremos repetir porque la idea es siempre superarse a si mismo.
• Además de la experiencia técnica, el JAM realizado en equipo permite ejercitar habilidades de coordinación de tareas, organización de equipo y solución de problemas que sin ninguna duda son elementos muy deseables en el desarrollo personal y de la organización.
• Los desafíos como los que plantea el JAM siempre dejarán aprendizaje. En la próxima oportunidad que tengan hagan lo posible por participar. No se arrepentirán.

Agradecimientos

• Quiero a gradecer al equipo de AWS por su colaboración y todo el apoyo brindado durante la realización de este evento. Muy especialmente al equipo más cercano en la cordinación de este Partner JAM: Diana Diaz, Rafael Zertuche y Gilberto Canales. ¡Muchisimas gracias!.
• Al equipo de GBM, a la dirección y la gerencia de software regional y muy especialmente a Fressy Vargas por hacer posible el evento y todo el aporte a la realización y premiación de los ganadores.
• Y por su puesto a mi equipo durante el Partner JAM: John Canales. y Guillermo Vásquez. Gracias por acompañarme y por asumir este reto sin miedo, con ganas de aprender, divertirse y luchar en sana competencia.

The use of multiple accounts within the same organization is a best practice for managing cloud solutions. It allows you to group workloads, manage costs, apply security controls, and respond dynamically to business needs. But, when you are working with AWS, crossing the account border could be a security configuration nightmare.

IAM Roles and Policies

Lambda functions need an execution Role. A Lambda function's execution role is an AWS Identity and Access Management (IAM) role that grants the function permission to access AWS services and resources. You provide this role when you create a function, and Lambda assumes the role when your function is invoked. In our case, the source Lambda, located in account 1, must have the permissions to invoke a Lambda function and be able to access the target Lambda function, located in account 2. An example of the policy would be:

A Lambda function can be called synchronously or asynchronously. The above policy grants both Lambda:InvokeFunction and Lambda:InvokeAsync permissions. Our goal is to grant the least privilege, so we should only give permission for the action that is required.

In the case of the target function, it is necessary to grant invocation permissions to the role assumed by the source function. It creates a trust relationship that allows executing the task of crossing the border between our two accounts. It is necessary for services or for any other AWS account that requires permissions to call a function from their resource-based policy. Refer to the documentation for more details about resource-based policies for AWS Lambda. You can add permissions to the resource-based policy using the AWS CLI. Permissions can be granted to a role, a service, or the entire organization. Again the idea is to be granular in assigning permissions.

Based on the example shown in the documentation we created the command line below to grant permissions. The command specifies the account ID as principal 111122223333 to invoke my-function with the alias prod.

Lambda Function Restrictions in a VPC

By default, the Lambda function runs its functions in a secure VPC. But this is a VPC owned by the AWS Lambda service and is not connected to the default VPC of the account that we manage in AWS. When a function is located within an account's VPC, the Lambda cannot access the Internet unless its VPC provides access.

Lambda accesses resources in your VPC using an ENI Hyperplane. Hyperplane uses a network interface for access between AWS accounts.

When placing a Lambda function in a VPC we encounter three limitations that can affect execution:

1. EC2ThrottledException: It will occur if the VPC does not have enough ENIs or IPs in the subnet. You will need to configure the VPC subnets (and therefore the VPC) to have enough IP addresses.
2. Client.NetworkInterfaceLimitExceeded: Thanks to a recent enhancement, Lambda function scaling is no longer directly related to the number of network interfaces. Hyperplane ENIs can now scale to support a large number of concurrent function executions. However, there is a limit to the number of ENIs per region, and this needs to be considered. See improved VPC networking for AWS Lambda functions for more details.
3. Client.RequestLimitExceeded: The lambda functions reach the create network interface (ENI) request rate limit. If you have concurrency spikes in your lambda functions, you might hit this limit.

Conclusions

The POC verified that calling Lambda functions across AWS accounts is possible and even relatively easy to do with the right permissions and configurations. However, when it comes to functions running within a VPC, you have to consider the restrictions associated with networking Lambda functions in AWS and their potential impacts on the design of a full load testing scheme. Regarding the configurations required for the analyzed case, it was determined that permissions must be granted both at the origin and at the destination side. For the origin function, permissions to use the API of Lambda functions must be granted, while in the target, a resource policy must be established that grants a trust relationship to the source account.