DEV Community: Alan Blockley

Teaching AI to Behave: Structured Output with Amazon Bedrock in Production

Alan Blockley — Sat, 28 Feb 2026 07:07:05 +0000

There’s a moment when generative AI moves from interesting to useful. It usually happens the first time you integrate an LLM into a real system. Not a demo. Not a playground. An actual workflow with downstream dependencies.

That’s when the problem appears. The model talks too much, too loosely, too creatively. Suddenly your architecture depends on parsing paragraphs.

That’s where structured output changes everything.

The problem most builders hit

When we first introduce AI into an application, the natural instinct is simple.

Call the model.

Get text.

Extract what we need.

It works. Until it doesn’t.

To explore this properly, consider a platform that processes unstructured input, evaluates it using AI, and produces structured signals that feed downstream workflows.

In that platform, AI isn’t decorative. It sits inside a workflow that turns unstructured input into structured signals the system can trust.

In other words, the AI is part of a pipeline. It is not the destination.

Free-form text becomes a liability.

You end up writing brittle regex.
You add defensive parsing.
You introduce silent failures.

And worst of all, you lose trust in the result.

So the goal wasn’t “use AI”.

The goal was:

Make AI behave like a component.

Why “respond with JSON” isn’t enough

Most builders start by telling the model to return JSON.

It feels structured. It looks structured. It often works.

Until it doesn’t.

You’ll see:

Missing fields
Extra fields
Invalid JSON
Fields renamed subtly
Narrative leaking into structured sections

That creates a new class of reliability work. AI repair logic.

Ironically, the more important the workflow becomes, the more defensive code you write around the AI.

Which is backwards.

The system shouldn’t adapt to the model.

The model should adapt to the system.

The reliability problem behind “just return JSON”

There’s a deeper issue that most builders eventually discover.

LLMs don’t generate JSON.

They generate text that looks like JSON.

That distinction matters.

Even with careful prompting you will eventually see:

Token truncation producing partial objects
Valid JSON with missing required fields
Subtle type drift (strings vs numbers)
Extra properties the system didn’t ask for
Structurally valid output that is semantically wrong
Streaming responses cut mid-structure

None of these are unusual. They are a natural side effect of probabilistic generation.

Which means asking for JSON is not a reliability strategy.

It is a hope.

Production systems shouldn’t depend on hope.

Enter Amazon Bedrock Structured Outputs

Amazon Bedrock’s structured output capability gives you a way to solve this properly.

Instead of asking the model to return JSON, you define a schema. Bedrock enforces that schema at generation time.

The shift is subtle but important.

You stop hoping the model follows instructions.

You give the model a contract.

That contract becomes architecture.

If the model cannot produce valid output, the call fails early. Production systems prefer predictable failure.

Where it fits in the system

Inside the platform, structured output sits within an automated evaluation workflow.

At a high level:

Unstructured content is submitted via an upload or API
The backend extracts relevant text or signals
Bedrock evaluates the content against defined criteria
The result is persisted as a structured record

Before structured output, the evaluation step was fragile.

After structured output, it became deterministic.

The AI now returns a predictable object that the system can trust.

Designing the schema (this is the real work)

The biggest learning wasn’t technical.

It was architectural.

A schema forces clarity.

You have to decide:

What the system actually needs
What the model should not invent
Which fields drive decisions versus explanation
Where uncertainty must be visible

In practice, the schema focuses on signals:

Overall match score
Criteria alignment breakdown
Strengths
Gaps
Confidence
Recommendation summary

The schema intentionally biases toward signals, not prose.

Code sample 1: define a compact schema contract

This is a simplified schema that captures decision signals without turning the model into a report writer.

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "overall_score": { "type": "number", "minimum": 0, "maximum": 100 },
    "confidence": { "type": "number", "minimum": 0, "maximum": 1 },
    "strengths": { "type": "array", "items": { "type": "string" } },
    "gaps": { "type": "array", "items": { "type": "string" } },
    "recommendation": { "type": "string" }
  },
  "required": ["overall_score", "confidence", "strengths", "gaps"]
}

A couple of intentional choices:

additionalProperties: false keeps the output tight and predictable.
required is small. You can add fields later, but start with what the system truly needs.

Code sample 2: invoke Bedrock with structured output

This example uses the Bedrock Runtime converse API. The important part is that the schema is sent as part of the request, and you treat the structured output as the primary payload.

import boto3

bedrock = boto3.client("bedrock-runtime")

schema = {
    "type": "object",
    "additionalProperties": False,
    "properties": {
        "overall_score": {"type": "number", "minimum": 0, "maximum": 100},
        "confidence": {"type": "number", "minimum": 0, "maximum": 1},
        "strengths": {"type": "array", "items": {"type": "string"}},
        "gaps": {"type": "array", "items": {"type": "string"}},
        "recommendation": {"type": "string"},
    },
    "required": ["overall_score", "confidence", "strengths", "gaps"],
}

messages = [
    {
        "role": "user",
        "content": [
            {"text": "Evaluate the input against the criteria."},
            {"text": "Return ONLY structured output that matches the schema."},
            {"text": f"INPUT:\n{input_text}"},
            {"text": f"CRITERIA:\n{criteria_text}"},
        ],
    }
]

resp = bedrock.converse(
    modelId="YOUR_MODEL_ID",
    messages=messages,
    inferenceConfig={
        "temperature": 0,
        "maxTokens": 1200,
    },
    outputConfig={
        "structuredOutput": {
            "schema": schema
        }
    },
)

structured = resp["output"]["structuredOutput"]["data"]
print(structured["overall_score"], structured["confidence"])

Two practical notes:

Keep temperature low for decision workflows.
Keep your schema small so it is easy to satisfy and easy to test.

Thoughtworks context: why this mattered internally

Within Thoughtworks, much of the platform work around delivery readiness, capability intelligence, and internal decision support depends on consistent signals rather than narrative interpretation.

Structured output allowed us to standardise how AI contributes to internal decision-making without introducing additional manual validation steps.

Instead of reviewing long AI summaries, teams can consume structured signals directly inside workflows. This reduces friction in essential procedures.

That shift is subtle, but operationally significant.

Code sample 3: validate and version the contract

Structured output reduces drift, but you still want a clean contract boundary inside your own code. In practice that means validating the response and versioning the schema.

Here is a minimal validation pattern using Pydantic. It gives you a single place to enforce types and defaults.

from pydantic import BaseModel, Field, conlist, confloat

class EvaluationV1(BaseModel):
    overall_score: confloat(ge=0, le=100)
    confidence: confloat(ge=0, le=1)
    strengths: conlist(str, min_length=1) = Field(default_factory=list)
    gaps: conlist(str, min_length=0) = Field(default_factory=list)
    recommendation: str | None = None

def parse_evaluation(payload: dict) -> EvaluationV1:
    return EvaluationV1.model_validate(payload)

# Example usage:
# evaluation = parse_evaluation(structured)
# store(evaluation.model_dump(), schema_version="v1")

This buys you two things:

Your downstream code stays stable even if your prompts evolve.
You can change the contract intentionally by introducing EvaluationV2.

Why this matters beyond AI

Structured output creates a boundary.

It turns AI from a conversation into a service dependency.

Once that boundary exists:

Validation shifts left
Persistence becomes straightforward
Observability improves
Testing becomes possible

You can now write tests against the shape of AI output.

That is a meaningful step toward production readiness.

Practical lessons learned

Smaller schemas work better.

Separate signals from explanation.

Confidence changes automation.

Treat schema as versioned contract.

Failure modes improve.

What changed in the platform

Introducing structured output didn’t add complexity.

It removed it.

The workflow became:

more predictable
easier to debug
safer to evolve
easier to test
cheaper to maintain

AI began to feel less magical and more like infrastructure.

Zooming out

We are moving from prompt engineering toward interface design. The question is no longer what you should ask the model. The question is what contract should exist between the model and the system. Structured output makes that explicit and nudges architects to design AI the same way we design APIs.

In early AI integrations, the hardest part is not calling the model. It is trusting the result. Structured output helps earn that trust, not because it makes the model smarter, but because it makes the system clearer. And clarity scales. For builders, that is the real value.

Breaking News: AWS Bedrock Lands in Sydney

Alan Blockley — Tue, 09 Apr 2024 23:01:10 +0000

I’m in Sydney this week for the AWS Summit Sydney and I’ve just been left with much excitement after a MASSIVE announcement.

This must be one of the year's most anticipated announcements (in our region). I’ve had customers ask me every other week when this is happening. I can now say… TODAY rather than SOON.

I can practically hear you all leaning forward, eager to know what it is. Well, hold onto your seats because here it is: AWS Bedrock has officially landed in Sydney (ap-southeast-02)!

That’s right! AWS Bedrock is now available in Sydney (ap-southeast-02)

What does this mean for us Aussies? Lower latency for our Gen AI Workloads and the ability to respect data sovereignty.

Lower latency for Australian customers writing Gen AI Workloads
Data sovereignty can be respected

Available immediately (by request) are the following models:

Amazon

Titan Text G1 - Lite
Titan Text G1 - Express
Titan Multimodal Embeddings G1

**Anthropic

Claude 3 Sonnet
Claude 3 Haiku

Cohere

Embed English
Embed Multilingual

Mistral AI

Mistral 7B Instruct
Mixtral 8x7B Instruct
Mistral Large

So, what are we waiting for? Let's dive in and start building something amazing right here in our local Sydney region!

In fact. First thing today I asked Claude 3 Haiku in Sydney to give me a Haiku, in celebration of it's launch in Sydney.

Write me a Haiku about being an LLM hosted in Sydney

Artificial mind Housed in Sydney's bustling heart Serve humans with grace

Learn more:

Build an AI image catalogue! - Claude 3 Haiku

Alan Blockley — Mon, 18 Mar 2024 22:26:26 +0000

Building an Intelligent Photo Album with Amazon Bedrock

If you’re into your Machine Learning/Artificial Intelligence/Generative AI and have been living under a rock, it may be news to you that Anthropic have now released their latest version of the Claude Large Language Model (LLM), which they have predictively named, Claude 3. But what’s not so predictable is that not only is this the third generation of Claude, but there are also three different variations of Claude.

In this post, we’re going to explore the creation of a basic, serverless, image cataloguing application using Claude 3 and explore how it enhances the functionality of our AI photo album application. Powered by Amazon Bedrock, this application leverages the poetic prowess of Claude 3 Haiku to provide insightful summaries of uploaded images.

In today's digital era, our memories are often immortalized through the lens of a camera, capturing moments that evoke a myriad of emotions. As our photo collections grow, organizing and making sense of these images can become a daunting task. However, with the emergence of artificial intelligence (AI) and cloud computing, we now have the opportunity to create intelligent solutions that automate and enrich the photo management process.

Announcing Claude 3

“The next generation of Claude: A new standard for intelligence” - https://www.anthropic.com/news/claude-3-family

When Claude 3 was announced they came up with not just one new model, but three:

Haiku (Available on Amazon Bedrock)
Sonnet (Available on Amazon Bedrock)
Opus (Coming soon to your favourite AI provider starting with B… and ending in rock)

Now whilst I write this in celebration of the Claude 3 family, I’m not going to go into all the differing benchmark charts as I’m sure you’ve already seen, however, the links and resources in this post should provide the benchmarks you seek if this is something you’re interested in.

What really got my attention was the overall impact that the whole Claude 3 family has on the LLM landscape. Bold strokes of improvement across all three variances including;

Near-instant results
Strong vision capabilities
Fewer refusals
Improved accuracy
Long context and near-perfect recall
Responsible design
Easier to use

Source: https://www.anthropic.com/news/claude-3-family

What got my attention the most was the claim of “Strong vision capabilities”. How strong? That’s something I wanted to test out.

I originally started writing this little project about 2 weeks before the release of Claude 3 Haiku, using Claude 3 Sonnet. The appeal was that Claude 3 Sonnet was offering unmatched vision capabilities.

“The Claude 3 models have sophisticated vision capabilities on par with other leading models. They can process a wide range of visual formats, including photos, charts, graphs and technical diagrams. We’re particularly excited to provide this new modality to our enterprise customers, some of whom have up to 50% of their knowledge bases encoded in various formats such as PDFs, flowcharts, or presentation slides.”

(OK I caved in and put a benchmark chart in - worth it though!)

Exploring Claude 3 Haiku

“Claude 3 Haiku: our fastest model yet” - https://www.anthropic.com/news/claude-3-haiku

The moment Haiku was released, my colleagues at the other end of the work meeting I was attending at the time were greeted with a physical whoop of joy. I was already excited by Claude 3 sonnet so having the next in the generation arrive was like Christmas had come early.

I also knew this meant that I could change my large language model from Sonnet to Haiku.

The benefits it provided to my proof of concept were:

The fastest model in the Claude 3 family
The most cost-effective model in the Claude 3 family.

This means a lot, especially in a proof of concept like this. This gives us the speed of execution to develop fast, fail fast and iterate on solutions a lot quicker. It also means that we’re able to control the costs of the application.

“Speed is essential for our enterprise users who need to quickly analyze large datasets and generate timely output for tasks like customer support. Claude 3 Haiku is three times faster than its peers for the vast majority of workloads, processing 21K tokens (~30 pages) per second for prompts under 32K tokens [1]. It also generates swift output, enabling responsive, engaging chat experiences and the execution of many small tasks in tandem.”

This speed also means the ability to analyze documents at a much faster rate than ever with a faster recall of information.

In our use case, we want to visualize our images by using descriptive language to help create a catalogue of images with a summary and to also have it provide a category for the image.

This can create powerful use cases such as making art more accessible for the blind or improve operational overhead in managing catalogs of stock images in a creative studio.

Let’s start building!

By the end of this post, I hope to have demonstrated:

Seamlessly integrate Claude 3 Haiku into a photo album app
Calling Amazon Bedrock from a serverless application
Basic Architecture that is needed to achieve this.
Some lessons learned with Prompt Engineering

The “Lego Bricks”

The basic architecture that we’re going to build looks something like this:

I liken AWS Services to Lego bricks. There are many of them and when put together in varying combinations, they can make many unique different builds. In this build, we’ll be using:

Amazon S3

To receive images and send them to be processed using S3 Events
To store and host processed images and a static-hosted HTML page API Gateway
To accept a GET request from a static-hosted HTML page AWS Lambda
To receive the S3 event and process the image
To accept a GET request and provide the user with the image data Amazon Bedrock
To leverage Calude 3 and provide an AI-generated summary and category Amazon DynamoDB
To store the information generated by Claude 3 / Amazon Bedrock

I’ve utilised the AWS Serverless Application Model (SAM) framework to help build and deploy this as well to keep things as easy as possible.

“SAM and Bedrock? Surely not?!?” - Remember, Amazon Bedrock is a serverless service and can be called by an API or an SDK. The power is yours to call Bedrock any way you want to.

And last but not least, our language of choice. Python for our AWS Lambda functions and there’s a small sprinkling of old-school Javascript to assist the front-end HTML.

If you’re keen to get this setup yourself feel free to browse the repo and get started yourself - https://github.com/alanblockley/bedrock-haiku-image-catalog

Otherwise, for more explanation, keep reading.

Prompt Engineering - No such thing as too much

When writing this little experiment I started with a very typical MVP style approach. Get something working. We’ve all been there, right? But in this process, I fell victim to also shirking on my prompt for Claude 3. My original prompt was something like

“Provide me a summary of this image and give it a short category”.

In my defence, it worked. But as any good builder/coder/developer, I read the documentation… actually, no I didn’t… Have you read IKEA instructions, I’ve been burnt for life! But instead, I sought out a peer review from a very good friend of mine. He swiftly explained that this was a bad prompt. But I didn’t get it. Yes, I’ve done ML/AI/PartyRock/Gen AI stuff but I’ve never really had to write anything in anger until now.

The explanation of why this is a bad prompt can be complex. To make it easier to understand, let’s think of it in human terms, after all this is an emulation of human intelligence. In your prompt you need to allow for:

Time for the model to think about what it’s doing - When we are thinking about something or trying to work on something, we generally think it through 3 or 4 times maybe, sometimes we’ll jot down some notes as well.
Structure your output - Claude likes XML tags, so maybe have Claude structure it’s output. Ask it to put it’s thinking into XML tags such as <SCRATCHPAD> or <NOTES>, closing them respectively. Then have it put the output of value, your output, into another XML tag such as <OUTPUT></OUTPUT>
The more detail the better. Assume you’re explaining this task for the first time to a trainee. If a trainee runs this task for the first time and gets it wrong, you didn’t explain it well enough and Claude definitely won’t get it right. Give it a purpose or a role. It’s not good to expect a toaster to dispense ice. So ensure that your model is given a contextual purpose to work to. * This will help make your answers more accurate.

Whilst all of these actions will help find the accuracy you need in your AI tasks, they’ll also make things more consistent as well. With this advice, my prompt ended up taking up 34 lines and told a story to the model, not just a quick 1 line action that could be interpreted vaguely. Have a play with it and see what you think.

And don’t forget a little bit of logic in your code to help extract the data from the XML tags. I’ve included a Python example in my repo.

The Lambda Functions

In our architecture, we’ve detailed two functions. One that processes images and one that retrieves the stored data.

For the sake of simplicity, there’s a third function, not detailed in the diagram, which takes the image and copies it to the image store but also renames the image to a random, unique UUID. This is to help indexing and also removes any bias from the AI generation of image data. The model then has no concept of image name. You could also add MIME checking, AV scanning and other checks here and also utilise this bucket to receive from anywhere such as AWS Transfer Family or a web front end via Presigned URLs.

I’ve included the functions in a public repository for you to play with - https://github.com/alanblockley/bedrock-haiku-image-catalog

For the sake of making this an interesting read, I’ve only included a copy/paste of the function that calls Amazon Bedrock. This function performs the following:

Decode Image Name: Extracts the name of the uploaded image from the S3 event and removes any obfuscation caused by URL formatting of the name.
Retrieve Image Type: Determines the MIME type of the uploaded image using the S3 object key.
Retrieve Image Data: Fetches the image data from the designated S3 bucket.
Encode Image Data: Converts the image data to a base64-encoded string for processing by the Claude 3 Haiku model.
Generate Summary: Utilizes the Claude 3 Haiku model to produce a summary of the image content.
Extract Summary: Parses the response from the Claude 3 Haiku model to extract the generated summary.
Store Summary in DynamoDB: Stores the extracted summary along with relevant image details (e.g., object ID) in a DynamoDB table for future retrieval.

This lambda function will also handle the streaming output that Bedrock provides and format it in such a way that it can be inserted into a DynamoDB table.

Also note, that I asked for structured data from the model. So when Claude presents me with this data, it’s creating a JSON string within the XML tags which I then use to continue processing the data.

Summarise Image - Code

import os
import json
import boto3
import base64
import urllib.parse
from botocore.exceptions import ClientError


IMAGE_TABLE = os.environ['IMAGE_TABLE']
IMAGE_BUCKET = os.environ['IMAGE_BUCKET']


s3 = boto3.client('s3')
dynamodb = boto3.resource('dynamodb')
bedrock_runtime = boto3.client('bedrock-runtime')


def extract_substring(text, trigger_str, end_str):
   # Find string between two values (Thanks for this Mike!)
   last_trigger_index = text.rfind(trigger_str)
   if last_trigger_index == -1:
       return ""
   next_end_index = text.find(end_str, last_trigger_index)
   if next_end_index == -1:
       return ""
   substring = text[last_trigger_index + len(trigger_str):next_end_index]
   return substring


def decode_object_name(object_name):
   # Decode the object name from the URL-encoded format
   return urllib.parse.unquote_plus(object_name)


# Function to get the image and turn it into a base64 string
def get_image_base64(bucket, key):
   try:
       response = s3.get_object(Bucket=bucket, Key=key)
   except ClientError as e:
       print(e)
       return False
   else:
       image = response['Body'].read()
       return image


def get_image_type(bucket, key):
   # Get the Mime type using object key and head_object
   # Must use head_object


   try:
       response = s3.head_object(Bucket=bucket, Key=key)
   except ClientError as e:
       print(e)
       return False
   else:
       content_type = response['ContentType']
       print(content_type)
       return content_type


def generate_summary(image_base64, content_type):
   # Generate a summary of the input image using the Bedrock Runtime and claude3 model
   # Must usee invoke_model


   prompt = """Your purpose is to catalog images based upon common categories.
Create a structured set of data in json providing a summary of the image and a very short, generalised, image category.  Do not return any narrative language.
Before you provide any output, show your working in <scratchpad> XML tags.
JSON fields must be labelled image_summary and image_category.


Example json structure is:


<json>
{
   "image_summary": SUMMARY OF THE IMAGE,
   "image_category": SHORT CATEGORY OF THE IMAGE,
}
</json>


Examples of categorie are:


Animals
Nature
People
Travel
Food
Technology
Business
Education
Health
Sports
Arts
Fashion
Backgrounds
Concepts
Holidays

Output the json structure as a string in <json> XML tags.  Do not return any narrative language.


Look at the images in detail, looking for people, animals, landmarks or features and where possible try to identify them.
"""

   response = bedrock_runtime.invoke_model(
       modelId='anthropic.claude-3-haiku-20240307-v1:0',
       contentType='application/json',
       accept='application/json',
       body=json.dumps({
           "anthropic_version": "bedrock-2023-05-31",
           "max_tokens": 1000,
           "system": prompt,
           "messages": [
               {
                   "role": "user",
                   "content": [
                       {
                           "type": "image",
                           "source": {
                               "type": "base64",
                               "media_type": content_type,
                               "data": image_base64
                           }
                       },
                       # {
                       #     "type": "text",
                       #     "text": prompt
                       # }
                   ]
               }
           ]
       })
   )


   print(response)
   return json.loads(response.get('body').read())


def store_summary(object_id, summary, category):
   # Store the summary in DynamoDB
   # Must use put_item

   table = dynamodb.Table(IMAGE_TABLE)
   table.put_item(
       Item={
           'id': object_id,
           'summary': summary,
           'category': category
       }
   )


def lambda_handler(event, context):


   print(json.dumps(event, indent=4))
   object_name = decode_object_name(event['Records'][0]['s3']['object']['key'])


   image_type = get_image_type(IMAGE_BUCKET, object_name)
   image_base64 = get_image_base64(IMAGE_BUCKET, object_name)


   if not image_base64:
       return {
           'statusCode': 500,
           'body': json.dumps('Error getting image')
       }
   else:
       image_base64 = base64.b64encode(image_base64).decode('utf-8')
       response_body = generate_summary(image_base64, image_type)

       print(response_body)

       summary = response_body['content'][0]['text']
       json_summary = json.loads(extract_substring(summary, "<json>", "</json>"))

       image_summary = json_summary['image_summary']
       image_category = json_summary['image_category']
       store_summary(object_name, image_summary, image_category)


   return {
       'statusCode': 200,
       'body': json.dumps('Summary stored in DynamoDB')
   }

NOTE: To call a bedrock-friendly version of boto3 we’re making use of a Lambda Layer. This must be built into your account before deploying this SAM template. You will then need to include the ARN of the layer as a Parameter as you deploy. To build the boto3 lambda layer:

Open Cloud Shell from the AWS Console and type the following commands

  mkdir ./bedrock-layer
  cd ./bedrock-layer
  mkdir ./python
  pip3 install -t ./python/ boto3
  zip -r ../bedrock-layer.zip .
  cd ..

  aws lambda publish-layer-version \
  --layer-name bedrock-layer \
  --zip-file fileb://bedrock-layer.zip

Source:-
https://www.linkedin.com/posts/mikegchambers_serverless-python-activity-7154258975926964224-IL4G

The Front End

To use the information we’ve generated in a useful way I created a very simple front end. This just lists any data in the dynamoDB and gives a thumbnail.

I’ve kept this as basic as possible. The hero of the story here after all is Claude… not my horrific javascript skills.

As you can see, Claude has done pretty well at creating a summary and categorising these images. This could then lead to further features being added such as search engines in large collections or services like Amazon Polly to explain what the image is.

Imagine how good this would be at Pictionary!

The SAM Template

The glue that holds this all together is a SAM template defining the resources in a declarative language that we’re all familiar with.

I’ve kept this template as simple as possible, including a SimpleTable for the DynamoDB table and separating resources between the frontend and the backend.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
 AI Photo album


Globals:
 Api:
   Cors:
     AllowMethods: "'*'"
     AllowHeaders: "'*'"
     AllowOrigin: "'*'"
     AllowCredentials: "'*'"
 Function:
   Timeout: 30
   MemorySize: 256
   Runtime: python3.11
   Environment:
     Variables:
       INCOMING_BUCKET: !Sub '${Prefix}-${Workload}-incoming'
       IMAGE_BUCKET: !Sub '${Prefix}-${Workload}-images'
       IMAGE_TABLE: !Ref ImageTable
   Architectures:
     - arm64


Parameters:
 Prefix:
   Type: String
   Description: Prefix for all resources
   Default: my-ml


  Workload:
   Type: String
   Description: Workload of the application
   Default: photo-album


 BedrockLayerArn:
   Type: String
   Description: ARN of the Bedrock layer
   Default: arn:aws:lambda:us-west-2:168420111683:layer:bedrock-layer:1


Resources:
### Backend resources
 ImageTable:
   Type: AWS::Serverless::SimpleTable
   Properties:
     PrimaryKey:
       Name: id
       Type: String
     TableName: !Sub '${Prefix}-${Workload}-image-table'


 IncomingBucket:
   Type: AWS::S3::Bucket
   Properties:
     BucketName: !Sub '${Prefix}-${Workload}-incoming'
     AccessControl: Private
     PublicAccessBlockConfiguration:
       BlockPublicAcls: true
       BlockPublicPolicy: true
       IgnorePublicAcls: true
       RestrictPublicBuckets: true


 ImageBucket:
   Type: AWS::S3::Bucket
   Properties:
     BucketName: !Sub '${Prefix}-${Workload}-images'
     AccessControl: Private
     PublicAccessBlockConfiguration:
       BlockPublicAcls: true
       BlockPublicPolicy: true
       IgnorePublicAcls: true
       RestrictPublicBuckets: true


 RenameImageFunction:
   Type: AWS::Serverless::Function
   Properties:
     CodeUri: rename_image/
     Handler: app.lambda_handler
     Layers:
       - !Ref BedrockLayerArn
     Policies:
       - S3ReadPolicy:
           BucketName: !Sub '${Prefix}-${Workload}-incoming'
       - S3WritePolicy:
           BucketName: !Sub '${Prefix}-${Workload}-images'
     Events:
       S3ObjectCreated:
         Type: S3
         Properties:
           Bucket:
             Ref: IncomingBucket
           Events: s3:ObjectCreated:*


 SummariseImageFunction:
   Type: AWS::Serverless::Function
   Properties:
     CodeUri: summarise_image/
     Handler: app.lambda_handler
     Layers:
       - !Ref BedrockLayerArn
     Policies:
       - DynamoDBWritePolicy:
           TableName: !Ref ImageTable
       - S3ReadPolicy:
           BucketName: !Sub '${Prefix}-${Workload}-images'
       - Statement:
           - Sid: Bedrock
             Effect: Allow
             Action:
               - bedrock:InvokeModel
             Resource: !Sub 'arn:aws:bedrock:${AWS::Region}::foundation-model/*'
     Events:
       S3ObjectCreated:
         Type: S3
         Properties:
           Bucket:
             Ref: ImageBucket
           Events: s3:ObjectCreated:*


 GetImagesFunction:
   Type: AWS::Serverless::Function
   Properties:
     CodeUri: get_images/
     Handler: app.lambda_handler
     Policies:
       - DynamoDBReadPolicy:
           TableName: !Ref ImageTable
     Events:
       Api:
         Type: Api
         Properties:
           Path: /images
           Method: get


### Front end resources
 ImageHostingOriginaccessidentity:
     Type: AWS::CloudFront::CloudFrontOriginAccessIdentity
     Properties:
       CloudFrontOriginAccessIdentityConfig:
         Comment: !Sub ${Prefix}-${Workload}-originaccessidentity


 ImageHostingBucketPolicy:
   Type: AWS::S3::BucketPolicy
   Properties:
     Bucket: !Ref ImageBucket
     PolicyDocument:
       Statement:
         -
           Action:
             - "s3:GetObject"
           Effect: "Allow"
           Resource:
             Fn::Join:
               - ""
               -
                 - "arn:aws:s3:::"
                 -
                   Ref: ImageBucket
                 - "/*"
           Principal:
             CanonicalUser: !GetAtt ImageHostingOriginaccessidentity.S3CanonicalUserId


 ImageHostingCloudFront:
   Type: AWS::CloudFront::Distribution
   Properties:
     DistributionConfig:
       Enabled: true
       Comment: !Sub ${Prefix}-${Workload}-distribution
       DefaultRootObject: index.html
       CustomErrorResponses:
         - ErrorCode: 400
           ResponseCode: 200
           ResponsePagePath: "/error.html"
         - ErrorCode: 403
           ResponseCode: 200
           ResponsePagePath: "/error.html"
         - ErrorCode: 404
           ResponseCode: 200
           ResponsePagePath: "/error.html"       
       Origins:
       - Id: ImageBucket
         DomainName: !Sub ${ImageBucket}.s3.${AWS::Region}.amazonaws.com     
         S3OriginConfig:
           OriginAccessIdentity: !Join [ "", [ "origin-access-identity/cloudfront/", !Ref ImageHostingOriginaccessidentity ] ]

       DefaultCacheBehavior:                   
         TargetOriginId: ImageBucket
         ViewerProtocolPolicy: redirect-to-https
         Compress: false
         CachePolicyId: "4135ea2d-6df8-44a3-9df3-4b5a84be39ad"
         ResponseHeadersPolicyId: "5cc3b908-e619-4b99-88e5-2cf7f45965bd"
         OriginRequestPolicyId: "88a5eaf4-2fd4-4709-b370-b4c650ea3fcf"

Summary

Some of the most important lessons I learned in this experience were not about Amazon Bedrock. Whilst I utilized Bedrock to call our new friend, Sir Claude the third of Haiku, I spent more time working on my prompt than I did calling Bedrock. Many iterations of this prompt happened and also varying changes between system prompts and multi-modal prompts (The ability to use images and text in a prompt).

As we conclude our exploration of Haiku and its role in our photo album application, we're reminded of the boundless possibilities that AI and cloud computing offer in reshaping our digital landscape. I see this being used in many use cases but I can’t escape the ability to use this to make life easier who may be vision impaired:

A guided tour of an art museum
Assistive technology when going through daily life such as shopping for groceries
Advanced screen reading.

Some of these use cases can even lead to the betterment of social inclusion for people with disabilities and vision impairment.

There are many commercial use cases for Claude 3’s vision capabilities including and not limited to marketing, hospitality, healthcare/wellness and many more but I’ll leave these to your imagination, as the opportunities are endless.

What next?

Curious to explore the world of Claude 3 Haiku and its applications beyond photo management? Dive deeper into AWS services and AI technologies, and discover the endless possibilities of AI models in enriching our digital experiences. Share your thoughts and insights in the comments on my LinkedIn or below, and let's embark on an AI journey together!

Essential Steps for Securing Your AWS Environment

Alan Blockley — Mon, 19 Feb 2024 03:51:40 +0000

Today, I want to dive into a topic that's been buzzing around lately: security in AWS environments. As we kick off the year with new intentions and goals, it's crucial to ensure that our AWS setups are fortified against potential threats. So, let's delve into some fundamental steps you can take to bolster security within your AWS infrastructure.

A lot of customers have been talking about security recently. It’s the start of the year, new intentions means they want to get involved with different standards, etc. But the first place to start is with some basic foundations in security or as I call it, Well-Architected Security.

Start with the basic foundations of security before you go big. Otherwise, you're going to find there's a lot of work to do later.

Let’s go through my top 10 steps for securing your AWS Environment

Tip 1: Implement a Multi-Account Architecture

So the first step that I would take with security is to separate those workloads, have a multi-account architecture. This sounds complicated, but it's not. All we're looking for is a couple of AWS accounts, one for your production environment that nobody touches, except for when you push your deployments into production and then have another account for playing around in, like a sandbox or development account. It doesn't have to be anything big. And don't forget you don't actually pay for an AWS account unless you put something in an account. All accounts are free until you start using them. So having that dev account there is great.

What this means is, if you make mistakes in the development account with data or your application, you're not going to impact that production workload.

So as far as the multi-account architecture is concerned, you've got a production account, you've got a development account and what you've got next is a management account. This account sits above the other two in the organization and creates a consolidated billing account, so you only get one bill. So that's nice and convenient as well.

But ultimately you've separated those workloads out and you're looking after your data security.

- Bonus Tip

Have an audit account because when you go for those security standards, they're going to look for an audit trail, they're going to look for logging, and they're going to look for how you query that as well. What's an audit account? An audit account is something where you consolidate all your cloud trails into one single place from each of those accounts.

So think big, long-term. You've only got a production account and a playground account right now. But what if in three years time you've actually got an account in London? An account in the US? You've got multiple accounts for different tenancies. You want to consolidate all that logging into one place because if you have an incident, you want to make sure you can get to that information quickly and easily. And also it means you've protected that log file as well, because if you do have an incident, nobody can erase those cloud trials from your production account.

Tip 2: Design a Custom VPC Configuration

My second tip is all about your network design. Don't just dive in playing with that default VPC configuration that's been given to you within your account because at the end of the day, it looks great to get you started, but you don't want to be using a public subnet all the time.

Create yourself, your own custom VPC configuration and also create it to have three layers of security to it;

In the first layer, have a public subnet. Just put your load balances there for anything that needs to be exposed to the Internet. Or maybe you've got a reverse proxy or a VPN server.
The second layer to your VPC is going to be a private subnet. I'd put all my compute workloads here like Lambda Functions, EC2 instances and Fargate tasks as well. That way, you've separated your compute workload from the Internet, make sure you've got a NAT Gateway, so those resources can get out to the Internet for their updates. But ultimately, the only way into these workloads should be via the load balancer.
And then, lastly, the third tier. This is the secure tier. Or, as I like to call it, the data's tier. I put all my Managed AWS services here that look after my data. RDS, EFS, FSX, etc. And it keeps that data secure. Why is it secure? Well, first of all, there’s no Internet gateway or NAT Gateway. There's also a network access control list (NACL) across the bottom of this as well, which then means you're blocking that from the public subnet.

So the only way to get to your data is through the compute layer. So the flow of data starts off at the Internet, goes to a load balancer, then comes into your compute layer and then goes into your data layer if that data request is needed. But there's no way anything entering or compromising your public subnet should be able to get to your data.

Tip 3: Prioritize Patch Management

Patch management! If you've got EC2 instances, then make sure you patch them. There's nothing worse than an exposed EC2 Instance on the Internet. You want to make sure you patch those against any Common vulnerabilities and Exploits (CVEs). Whilst we all know about Microsoft patch Tuesdays, don't forget your Linux hosts as well. You can use AWS Systems Manager, Maintenance Windows and Patch Manager to automate these on a regular basis.

Tip 4: Optimize Authentication with Single Sign-On

Now, let's talk about how you log in to AWS. The main recommendation at the moment from AWS is to use a single sign on provider. AWS provides a single sign-on provider in the form of IAM Identity Centre. Now, this is great because this means you consolidate all the logins for those multiple accounts that we just created as part of my first Step, into one place.It also means you can federate that off to your favorite identity provider as well, such as Google, Azure AD or whatever it might be as this is a primary feature of IAM Identity Center.

What makes SSO so secure though? IAM Identity Center makes sure that you are using temporary credentials at all times. You log in with your preferred identity provider, and then it gives you a fresh new AWS token in the background so you can access all the AWS resources and expires them at approximately 8 to 12 hours, depending on what you've configured. This is great. This means there's no static credentials lying around nothing that can get leaked. And it even provides you with things like IAM access keys for CLI access.

- Bonus Tip

If you've got IAM User Access Keys set up for service accounts, then make sure you rotate those every 90 days. This is to make sure we reduce the potential of an attack. You can create a scheduled process for this, a business process, that is designed to have someone rotate those keys and then apply them to the service as well. But make sure you remember to do this every 90 days.

Tip 5: Secure the Root Account

This next one is all about the root account. If your root account is still in use, if you're still logging in with that magic email address that Amazon let you register with, get rid of it. You should be setting a strong password, a hardware MFA token and locking it away with a safe. The root account has privileges that could damage your business and it’s too risky to allow it to be compromised.

- Bonus Tip #1

Make sure that the root account has not got IAM User Access Keys attached to it either because these are stored in plain text and can be assumed from anywhere so make sure there's no access keys.

- Bonus Tip #2

Make sure you've got MFA enabled not just on your root account, but also across your organization as well.

Tip 6: Manage Permissions Effectively

It's always important to make sure you know who's got access to what in your environment. I often find that sometimes the AWS Managed IAM Roles/Permission Sets can actually give away too much in terms of permissions. We want our developers to do things. We want them to be productive, but sometimes you might now want them to have access to Amazon SageMaker or other services that might be expensive to play with when not properly educated. So look at those permissions. Look at what people have and then make sure you create custom roles and permission sets for your staff. Also, make sure you're checking them regularly as well. What if somebody's moved roles? Do they need those permissions?

- Bonus Tip

Service Control Policies (SCP) can also allow for controlling different permissions at an organizational level and making sure you know who has access to what. You can still maintain the access that they need if they need administrative access to the account, but from a service control policy at an organizational level, you can then limit services and regions. You can also enforce compliance too.

Tip 7: Enhance Remote Access Security

When you're remotely accessing your EC2 instances. Try not to use SSH or RDP. Keep these protocols closed away from the world. Instead, use AWS Systems Manager, Session Manager. This service allows you to log on directly to the EC2 instance from inside the AWS Management Console and get your favorite bash prompt or PowerShell prompt. If you're a Windows user and you want to use the Windows Interface, you could also use AWS Systems Manager, Fleet Manager instead to get a remote desktop.

Using these two features of Systems Manager you can close off port 22, you can close off port 3389 and access the EC2s through the console. From a compliance perspective, this also means that you're logging access to that EC2 instance against AWS CloudTrail with the username creating accountability.

- Bonus Tip

If you want to track what's going on on the command line from the Session Manager, you can log those commands to CloudWatch Logs as well. Just make sure you rotate those logs regularly so they don't get too big.

Tip 8: Enable AWS GuardDuty

Make sure you've got AWS GuardDuty enabled. GuardDuty is a lifesaver when it comes to not knowing what's going on in your account. I always tell a story about this.

THis was during my tenure in a previous role, I've seen this with a real account in real time where GuardDuty alerted us to an issue. And what it's alerting us to is something that we can't see in our usual regions or environments. It alerted us to a cluster of EC2 Instances being launched in another region. Now, as a customer, I was working in Sydney. Why would I be bothered about any other region? But GuardDuty told me that somebody had compromised our accounts by the usage of leaked IAM credentials, and we were able to stop the launch of resources in the wrong region at that time, saving us a lot of money and saving us our security reputation

- Bonus Tip

Look into AWS Security Hub! Security Hub is a service that consolidates all the other security services within AWS into a single pane of glass view. GuardDuty can send alerts to Security Hub alongside other services and then show you remediation items as you go along, giving you traffic light reports and even a percentage score of your security position. It works with many frameworks, so you'd be able to tune it to exactly what your frameworks might be

Tip 9: Protect Web Applications with WAF

Application protection with a Web Application Firewall (WAF). If you've not got a WAF, you're very possibly opening yourself up to all sorts of risk. A WAF can be tuned to your run time or hosted operating systems. It can protect you against the top 10 threats on the Internet at the time or against botnets. You can also create custom rules such as whitelists or block lists to be able to control the traffic coming in.

Tip 10: Implement Encryption Everywhere

Final tip for security today is encryption. Encrypt everything! As Werner Vogels would say;

“Dance like nobody's watching and encrypt like everybody is”

Make sure you encrypt those EBS volumes on creation. Setup your account so that every volume is encrypted by default. Use custom KMS keys, if possible. Make sure S3 buckets and RDS instances are encrypted as well. Every service should have an option for encryption. Use it. Don't lose it (your data).

Summary

Securing your AWS environment is an ongoing process that requires diligence and proactive measures. By implementing these essential steps, you can fortify your infrastructure against potential threats and mitigate security risks effectively. Remember, prioritizing security is key to maintaining the integrity and resilience of your AWS environment.

Amazon Cognito - Function over form

Alan Blockley — Thu, 18 Jan 2024 10:54:12 +0000

Many individuals, builders or backend developers, often grapple with the challenge of balancing function and form. Ultimately, the success of our application hinges on ensuring that the Minimum Viable Product (MVP), Proof of Concept (PoC), or prototype functions smoothly before investing substantial resources into a flashy frontend.

However, there lies a conundrum – how do we control access to our application without prematurely exposing it to the entire internet?

Why am I sharing this journey with you? During the holidays, I ventured into the realm of building a new project. While delving into the backend intricacies involving services like API Gateway, Lambda, and a plethora of DynamoDB databases, one unavoidable aspect surfaced – the need for a frontend. Even if it's just a basic HTML page, having a visual representation of the backend processes is crucial.

In this blog post, I aim to share my experiences with AWS Cognito. It's been a five-year mission, boldly going where many have gone before, yet I've always found myself struggling as a BUILDER.

By the end of this we’ll step through what I have learned and try to provide some code examples for you to take away and use yourself.

Introducing Amazon Cognito

“With Amazon Cognito, you can add user sign-up and sign-in features and control access to your web and mobile applications. Amazon Cognito provides an identity store that scales to millions of users, supports social and enterprise identity federation, and offers advanced security features to protect your consumers and business. Built on open identity standards, Amazon Cognito supports various compliance regulations and integrates with frontend and backend development resources.” - https://aws.amazon.com/cognito/

In my past life as a PHP Developer I’d write web applications with a specific business function. I’d create some level of users table, with an encrypted password and some questionable business logic as to how to access this table. I’d be left with having to maintain the DB, the table, the code and the server to ensure that user authentication was safe and secure.

“Did someone order a portion of operational overhead with a side of operational headache?”

Amazon Cognito is designed to take away the hassle of looking after authentication methods, userpools or even federation of users. A serverless, managed service that also has a very generous feature set and free tier. Yep… FREE! For up to 50,000 Monthly active users or 50 Monthly federated users (Federated infers social logins such as Azure AD, Google, Facebook, Apple and Amazon). It provides an authentication mechanism for your application which can then also provide IAM privileges to resources in your infrastructure such as API Gateway, DynamoDB et al.

The Problem

I’ll admit to trying my hand at Cognito several times over and getting basic knowledge of how it works but never actually getting something that is working to a level of productivity. I always ended up in the past with some random token or some obfuscated URL and then a severe lack of time to troubleshoot / educate myself on how to properly use these elements.

However in this example, I had a WHOLE festive holiday to work this out once and for all, and it really wasn’t that complicated once I got to the bottom of it.

The Theory

Yes there’s a boring theory section to this but it’ll make sense eventually.

Workflow

In order to successfully implement Cognito you’ll need a user form, to capture basic information (username and password), you send an InitiateAuth call, which sends back a series of challenge and response messages (SMS MFA,etc) to then eventually be sent an array of tokens to be used in authentication against others AWS services.

Source -
(https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html)

The key portion of this for our example is the return of the Access, ID and refresh token. This then allows us to implement the architecture that we’ll be more familiar with, below;

Let’s look at the definition of each token, based on the AWS Docs:

ID token

“The ID token is a JSON Web Token (JWT) that contains claims about the identity of the authenticated user, such as name, email, and phone_number. You can use this identity information inside your application. The ID token can also be used to authenticate users to your resource servers or server applications.” - https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html

Access token

“The user pool access token contains claims about the authenticated user, a list of the user's groups, and a list of scopes. The purpose of the access token is to authorize API operations. Your user pool accepts access tokens to authorize user self-service operations. For example, you can use the access token to grant your user access to add, change, or delete user attributes.” - https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html

Refresh token

“You can use the refresh token to retrieve new ID and access tokens. By default, the refresh token expires 30 days after your application user signs into your user pool. When you create an application for your user pool, you can set the application's refresh token expiration to any value between 60 minutes and 10 years.” - https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-refresh-token.html

The Implementation

In practice this now starts to make more sense, now we understand what the different tokens are used for.

Prerequisites

Before following the below, make sure you’ve done the below;

Grab a copy of the supporting Github repo (https://github.com/alanblockley/cognito-javascript-example)
Setup an instance of Cognito in your AWS account. A Cloudformation template has been provided for you in the attached Github repo.
Enter your pool id and client id into the config.js, supplied in the repo. The config.js file should go in the same location as the js file calling it.

Now this is done, let’s get started.

Registration

Every good authentication method needs a way of registering users. How else are your users going to sign up?

Let’s give it an interface!

<form id="registerForm" novalidate onsubmit="return false">
    <div class="form-group">
        <label for="emailInputRegister">Username</label>
        <input type="text" class="form-control" id="emailInputRegister" placeholder="Enter email">
    </div>

    <div class="form-group">
        <label for="passwordInputRegister">Password</label>
        <input type="password" class="form-control" id="passwordInputRegister" placeholder="Enter Password">
    </div>

    <div class="form-group">
        <label for="confirmationPassword">Password</label>
        <input type="password" class="form-control" id="confirmationPassword" placeholder="Confirm Password">
    </div>

    <button type="submit" class="btn btn-primary btn-block">Register</button>
</form>

...

<script src="js/register.js"></script>
<script type="text/JavaScript">
    $('#registerForm').on("submit", function (event) {
      registerUser();
      event.preventDefault();
    })
</script>

[ https://github.com/alanblockley/cognito-javascript-example/blob/main/html/register.html ]

Nothing too clever here. Just accepting an email address and a password, plus a confirmation that the password was spelt correctly.

In the <script> section of the HTML file we’re including the register.js file and then defining a trigger. This can be done in the one file normally but I like to keep triggers in line for visibility.

It’s worth noting that we also need to call a couple of other AWS specific scripts just above our script section;

<script src="assets/js/config.js"></script>
<script src="js/vendor/aws-cognito-sdk.min.js"></script>
<script src="js/vendor/amazon-cognito-identity.min.js"></script>

These two reference libraries that allow us to call Amazon Cognito via the SDK, natively in Javascript, the other is our configuration file for all Amazon Cognito calling scripts.

This trigger referenced calls the below function;

// Function to register a user
function registerUser() {
   // Get user input values from the registration form
   var email = document.getElementById("emailInputRegister").value;
   var password = document.getElementById("passwordInputRegister").value;
   var confirmationPassword = document.getElementById("confirmationPassword").value;

   // Check if the entered passwords match
   if (password != confirmationPassword) {
       // Display an alert if passwords do not match
       alert("Passwords do not match");
       return;
   }


   // Display an alert with user registration information
   alert("Registering user with email: " + email + " and password: " + password);


   // Configuration data for Cognito user pool
   poolData = {
       UserPoolId : _config.cognito.userPoolId,
       ClientId : _config.cognito.userPoolClientId
   }


   // Create a new Cognito user pool object
   var userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData);
   var attributeList = [];


   // Create an attribute for the user's email
   var dataEmail = {
       Name : 'email',
       Value : email
   }


   var attributeEmail = new AmazonCognitoIdentity.CognitoUserAttribute(dataEmail);


   // Add the email attribute to the attribute list
   attributeList.push(attributeEmail);


   // Sign up the user with Cognito user pool
   userPool.signUp(email.replace("@", "_"), password, attributeList, null, function(err, result){
       if (err) {
           // Display an alert if there's an error during user registration
           alert(err.message || JSON.stringify(err));
           return;
       }
       // User registration successful
       cognitoUser = result.user;
       alert('User registered successfully');


       // Display a success message to the user
       document.getElementById("successMsg").innerHTML = "Check email for verification code";
       $('#successMsg').show();
   });
}

[ https://github.com/alanblockley/cognito-javascript-example/blob/main/js/register.js ]

The JavaScript you've got here is all about making user registration smooth using Amazon Cognito. It kicks off by grabbing what the user typed in for email, password, and the confirmation.

Quick check to see if the passwords match, and if not, it throws a friendly alert. Assuming all's good, it sets up a user using the Amazon Cognito service, putting together some pre-configured info. The user's email is added as an attribute, and then it's signup time with Cognito. If all goes well, a success message pops up, telling the user to check their email for a verification code.

It relies on the Amazon Cognito Identity SDK to handle the heavy lifting and brings together user registration, password checks, and Cognito integration for a seamless experience on a web app.

Login

Using a simple login.html we’re able to now send basic username and password information, registered in our previous example, to Cognito and receive a token.

Again, we will now set up an interface to login. It’s not pretty, but remember, we’re not front end developers. Function over form!

<form id="signinForm" novalidate onsubmit="return false">
  <div class="form-group">
      <label for="emailInputSignin">Username</label>
      <input type="text" class="form-control" id="emailInputSignin" placeholder="Enter email">
  </div>
  <div class="form-group">
      <label for="passwordInputSignin">Password</label>
      <input type="password" class="form-control" id="passwordInputSignin" placeholder="Password">
  </div>

  <button type="submit" class="btn btn-primary btn-block">Login</button>
</form>

...

<script src="js/vendor/login.js"></script>

<script type="text/JavaScript">
  $('#signinForm').on("submit", function (event) {
    userLogin();
    event.preventDefault();
  })
</script>

[ https://github.com/alanblockley/cognito-javascript-example/blob/main/html/login.html ]

And don’t forget our libraries and config.

<script src="assets/js/config.js"></script>
<script src="js/vendor/aws-cognito-sdk.min.js"></script>
<script src="js/vendor/amazon-cognito-identity.min.js"></script>

This trigger in our not so pretty login page calls the below function;

// Function to handle user login with local storage
function userLogin() {

    // See if the id_token already exists in session storage
    let id_token = sessionStorage.getItem("id_token");

    if (id_token) {
        // If id_token exists, user is already logged in
        alert("Already logged in");
    } else {
        // Get user input values for email and password from the signin form
        var email = document.getElementById("emailInputSignin").value;
        var password = document.getElementById("passwordInputSignin").value;

        // Configuration data for Cognito user pool
        poolData = {
            UserPoolId : _config.cognito.userPoolId,
            ClientId : _config.cognito.userPoolClientId
        }

        // Create a new Cognito user pool object
        var userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData);
        var userData = {
            Username : email,
            Pool : userPool
        }

        // Create a new Cognito user object
        var cognitoUser = new AmazonCognitoIdentity.CognitoUser(userData);

        // Authenticate the user with Cognito using provided credentials
        cognitoUser.authenticateUser(new AmazonCognitoIdentity.AuthenticationDetails({
            Username : email,
            Password : password
        }), {
            onSuccess: function (result) {
                // If authentication is successful
                console.log('Successfully logged in');

                // Get and store access, ID, and refresh tokens in session storage
                var access_token = result.getAccessToken().getJwtToken();
                var id_token = result.getIdToken().getJwtToken();
                var refresh_token = result.refreshToken.token;

                sessionStorage.setItem("id_token", id_token);
                sessionStorage.setItem("access_token", access_token);
                sessionStorage.setItem("refresh_token", refresh_token);

                // Display success message to the user
                alert("Successfully logged in");

                // Additional actions or navigation can be added here
            },
            onFailure: function(err) {
                // If authentication fails, display an error message
                alert(err.message || JSON.stringify(err));
                return;
            }
        });
    }
}

This piece of JavaScript is all about handling user logins, and it's got a clever twist with local storage. It first checks if there's an existing ID token stashed in the session storage. If it finds one, it means the user is already logged in, and a friendly "already logged in" alert pops up. But if not, it goes on to grab the user's email and password from the signin form.

Then, it sets up the user pool with the familiar Cognito data and creates a new Cognito user using the provided credentials. When it tries to authenticate the user, if successful, it logs a victory message, snags the access, ID, and refresh tokens, and stores them in the session storage.

A triumphant "Successfully logged in" alert signals the completion. You can practically smell the success from here!

Once we have these two methods implemented in practice, we log in, see our wonderful app and we can carry on developing. One of the gotchas you’ll find is that after about an hour, your app will start giving you 401 errors in the development console.

This is because your access and ID token have expired. So what do we do now?

This is where the refresh token comes in!

Refresh token

One of the tricks in your code has to be to acknowledge when your resources start returning HTTP 401 errors. This can stop the whole show if not dealt with.

It’s up to you and your logic how you detect 401 errors but below is an example Javascript function to refresh the token to then keep things moving.

// Function to refresh the Amazon Cognito authentication token
function refreshToken() {

    // Retrieve the existing id_token and refresh_token from session storage
    let id_token = sessionStorage.getItem("id_token");
    let refresh_token = sessionStorage.getItem("refresh_token");

    // Check if id_token exists
    if (id_token) {
        // Configuration data for Cognito user pool
        poolData = {
            UserPoolId : _config.cognito.userPoolId,
            ClientId : _config.cognito.userPoolClientId
        }

        // Create a new Cognito user pool object
        var userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData);
        var userData = {
            Username : id_token, // Using id_token as the username for refreshing
            Pool : userPool
        }

        // Create a new Cognito user object
        var cognitoUser = new AmazonCognitoIdentity.CognitoUser(userData);

        // Create a CognitoRefreshToken object using the refresh_token
        var cognitoRefreshToken = new AmazonCognitoIdentity.CognitoRefreshToken({RefreshToken: refresh_token});

        // Refresh the session using the refresh token
        cognitoUser.refreshSession(cognitoRefreshToken, (err, session) => {
            if (err) {
                // Log any errors during token refresh
                console.log(err);
                return;
            }

            // Get and update the new id_token and access_token
            id_token = session.getIdToken().getJwtToken();
            access_token = session.getAccessToken().getJwtToken();

            // Store the new tokens in session storage
            sessionStorage.setItem("id_token", id_token);
            sessionStorage.setItem("access_token", access_token);

            // Now that we have new tokens, additional actions can be performed
            // ...

            // Display a success message to the user
            alert('Auth token refreshed');
        });
    }
}

The final JavaScript function, refreshToken, is designed to handle the refreshing of Amazon Cognito authentication tokens, specifically the id_token and access_token. It begins by retrieving the existing id_token and refresh_token from the session storage.

The function checks if an id_token exists and proceeds to configure the Cognito user pool with predefined pool data. It then creates a Cognito user object using the id_token as the username for refreshing. A CognitoRefreshToken object is created using the existing refresh_token. The function then attempts to refresh the session using the cognitoRefreshToken.

If successful, it updates the id_token and access_token with the new tokens obtained from the refreshed session and stores them back in the session storage. Additionally, the function provides a placeholder comment indicating that additional actions can be performed with the new tokens.

Finally, a success message is displayed to the user via an alert. In summary, this function ensures that the user's authentication tokens stay up-to-date by refreshing them when needed, contributing to a more seamless and secure user experience in applications using Amazon Cognito.

Sources

Introducing WeatherFIT (And PartyRock): Your Ultimate Style Wingman Powered by AI Magic!

Alan Blockley — Thu, 16 Nov 2023 17:26:17 +0000

Step into a world where fashion meets futuristic intelligence with the groundbreaking WeatherFIT app! Forget the fashion guesswork; now you can stride confidently into any day, any event, anywhere, thanks to the sensational power of PartyRock, an Amazon Bedrock Playground.

Get Ready to Rock Your Wardrobe - Picture this: you're about to head out – work, party, or just a casual shopping spree – and you're wondering, "What the heck do I wear?" Enter WeatherFIT, your personal fashion oracle. This app doesn’t just predict the weather; it crafts personalized fashion advice based on your location, ensuring you're always looking on point.

Outfit Suggestions Tailored to You - WeatherFIT doesn't stop at giving basic recommendations; it dives deep into your wardrobe dilemmas. Warm day? Cool night? Rainy morning? WeatherFIT has you covered, suggesting outfits that not only match the weather but also make you stand out. And here's the kicker – it even tells you if you need an umbrella or sunscreen. Now that's next-level fashion foresight!

Style Comes to Life - But wait, there's more! WeatherFIT doesn’t just talk the talk; it walks the runway with personalized outfit illustrations. See your ideal outfit come to life in stunning AI-generated images, catering to both the gents and the ladies. Now you're not just dressing; you're making a style statement.

NEWSFLASH - The Tech Behind the Glam - PartyRock Unleashed!

The genius behind WeatherFIT is PartyRock – an Amazon Bedrock Playground that turns app creation into an electrifying experience. No coding skills are required! Just a few clicks, a dash of creativity, and boom – you've got an app that's as exciting as your fashion choices.

“PartyRock, an Amazon Bedrock Playground, is a generative AI app building playground that makes it easy to experiment hands-on with prompt engineering in an intuitive and fun way. In just a few clicks you can build apps to play with generative AI in a variety of ways”

Easy as 1-2-3 - Don't worry if you're not a tech whiz. PartyRock is designed for everyone. PartyRock's user-friendly web-based UI lets you dive into the excitement of app creation without an AWS account. It's as easy as asking for fashion advice from your high-tech best friend (aka WeatherFIT).

Here’s how I created this little genius app;

I registered for PartyRock in a matter of seconds with my favorite federated identity.
Click “Build your own app”
Give PartyRock a prompt “an application that would suggest what to wear based upon the weather and to make recommendations for male and female”. That’s it!

Once it generated my app, I added two more widgets to create an AI-generated image of the output for males and females and positioned them where I wanted. The end result was surprisingly on point. Just like the advice WeatherFIT gives!

The extra widgets are further examples of prompt engineering inside of Amazon Bedrock, but the real magic is the ability to reference a previous prompt or output by using @ tags.

This application took me no more than 5 minutes to create! In fact I've spent longer writing this post to celebrate the release of PartyRock than making my first app.

Get started today with your own application - https://partyrock.aws/

“Everyone can build AI apps with PartyRock, an Amazon Bedrock Playground”

Demystifying permissions within AWS SAM resources

Alan Blockley — Wed, 12 Jul 2023 11:02:35 +0000

Permission seekers and control freaks, this one is for you!

In the complex world of AWS Serverless Application Model (SAM), understanding permissions is the key to unlocking secure serverless magic. Picture this: An IAM policy, an AWS Connector and a function policy template walk into a bar... Okay, this is not the start of a bad joke, but your application will be if you don’t manage your permissions appropriately.

In this weeks post, we'll explore the different permission mechanisms with some code examples for the visual learners amongst us. Prepare to navigate the realm of AWS SAM permissions.

IAM Policies, AWS Connectors and SAM Policy Templates

IAM Policy Statements: For the Control Freaks of Permission Management - IAM policies are for the detailed orientated system administrators and solutions architects amongst us. Oh, how they love to be in control! These fine-grained superheroes (the IAM Policies not the Systadmins) allow you to define who can access and perform specific actions within your AWS realm. With the power of IAM policies, you can micromanage permissions like a boss. It's like assigning bouncers to protect your AWS resources and ensuring that only the chosen ones get past the velvet rope.

Inline IAM Policy within a function

Resources:
  MyLambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.8
      Handler: lambda_function.handler
      CodeUri: ./lambda_function
    Policies:
      - Statement:
          - Effect: Allow
            Action: s3:GetObject
            Resource: arn:aws:s3:::my-bucket/*
          - Effect: Allow
            Action: dynamodb:PutItem
            Resource: arn:aws:dynamodb:us-east-1:123456789012:table/my-table

Separate IAM Policy, attached to a function.

Resources:
  MyLambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.8
      Handler: lambda_function.handler
      CodeUri: ./lambda_function
      Policies:
        - !Ref MyLambdaFunctionPolicy

  MyLambdaFunctionPolicy:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: MyLambdaFunctionPolicy
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Action: s3:GetObject
            Resource: arn:aws:s3:::my-bucket/*

N.B. It’s also worth noting you can use AWS Managed IAM Policies and any other accepted CloudFormation mechanism here too if required.

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions-cloudformation.html

AWS Connectors: The Predefined Dance Partners of SAM - Now, let's meet the AWS Connectors, the happy meal of the permission world! These connectors are almost like pre-made boxes of permission happiness where you pick your main, your side and your toy!

They come with predefined permissions, like ready-made menu options, making integration a breeze. Fancy your cheeseburger with a side of Amazon S3? The S3 Connector has got you covered. Want to savour the flavours of DynamoDB? The DynamoDB Connector will satisfy those cravings. They simplify integration and package it into fewer lines than an AWS IAM Policy.

Serverless Function using Connector

Resources:
  MyLambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.8
      Handler: lambda_function.handler
      CodeUri: ./lambda_function
    Events:
      MyS3Event:
        Type: S3
        Properties:
          Bucket: 'my-bucket'
          Events: s3:ObjectCreated:*
    Connectors:
      S3BucketConnector:
        Properties:
          Destination: 
            Id: 'my-bucket'
          Permissions:
            - Read

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/managing-permissions-connectors.html

SAM Policy Templates: Function-Specific Permission Ninjas - Enter the SAM Policy Template, the stealthy ninjas of permissions. With these policies, you can grant specific permissions to your Lambda functions without breaking a sweat. It's like having a team of specialised martial arts experts guarding each function. Whether you define policies inline or reference existing IAM policies, these ninjas ensure your functions have the right permissions, without causing unnecessary chaos. Talk about precision and elegance! To top this off, it’s much shorter than writing a whole IAM Policy statement.

Serverless Function using Connector
Resources:
  MyLambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.8
      Handler: lambda_function.handler
      CodeUri: ./lambda_function
      Policies:
        - DynamoDBReadWritePolicy:
            TableName: my-table

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-policy-templates.html

Differences and Use Cases: SAM Permissions in Action

In a nutshell, here's a breakdown of the differences and use cases for IAM Policies, AWS Connectors, and SAM Policy Templates:

IAM Policies: Offer fine-grained control over permissions at the user or role level. Ideal for managing access to multiple AWS resources or services with precision.
AWS Connectors: Simplify integration with specific AWS services by providing predefined permissions out of the box. Perfect for streamlined integration without the need for manual IAM policy configuration.
SAM Policy Templates: Grant function-specific permissions within your SAM template, eliminating the need for separate IAM policies. Well-suited for managing permissions at the function level with a focus on individual functions.

Choose IAM Policies for granular control, AWS Connectors for simplified service integration, and SAM Policy Templates for function-specific permissions. Tailor your approach based on your specific requirements, balancing control and convenience.

In closing...

And that concludes today’s lecture, permission aficionados! We’ve mastered the art of AWS SAM permissions together. IAM Policies, AWS Connectors, and SAM Policy Templates are your permission pals, each with its unique style. IAM policies provide control, Connectors are the happy meal of the permission world, and function policies bring stealthy precision. Embrace the right approach for your use cases and security needs, ensuring your serverless applications operate through the AWS SAM world with style.

Stay tuned for more AWS SAM adventures.

Sources

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions.html

Demystifying the Basic Anatomy of an AWS SAM Template

Alan Blockley — Wed, 12 Jul 2023 11:00:57 +0000

In my previous post, we looked at the basic concept of AWS SAM and the high-level problem it solves. If that wasn't enough for you, keep reading!

AWS Serverless Application Model (SAM) templates are the building blocks of serverless applications on Amazon Web Services (AWS). Understanding the basic anatomy of an AWS SAM template is essential for harnessing the full power of serverless development. In this blog post, we'll delve into the fundamental elements that make up an AWS SAM template, unlocking the secrets to crafting scalable and efficient serverless applications.

YAML at Your Service - An AWS SAM template is written in YAML (YAML Ain't Markup Language), a human-readable and expressive data serialisation format. YAML allows for a concise and structured representation of your serverless application's resources and configurations. (Just watch those tabs/spaces, IYKYK!)

Transforming the Magic - At the beginning of your AWS SAM template, you'll find the Transform section. This is where the transformation magic happens.

Transform: AWS::Serverless-2016-10-31

The above declaration instructs AWS CloudFormation to use the AWS SAM syntax and capabilities to deploy and manage your serverless application. Why? Because SAM offers a lot of flexibility by providing special resource definitions that can save an engineer a lot of time NOT writing CloudFormation! Don't panic though, you can still use CloudFormation resources too!

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/format-version-structure.html

Parameters: Flexible Configurations - In the Parameters section, you can define customizable inputs to your AWS SAM template. Parameters allow for flexible configuration options, enabling you to modify aspects of your serverless application during deployment. You can specify parameter types, and default values, and even apply constraints to ensure the correct inputs are provided.

Parameters:
  Stage:
    Type: String
    Default: Prod
    Description: Deployment stage of the application

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html

Resources. The Building Blocks of Your Application - The heart of your AWS SAM template lies within the Resources section. Here, you define the AWS resources required for your serverless application, such as AWS Lambda functions, API Gateway endpoints, DynamoDB tables, and more. Each resource is represented by a unique logical ID and its corresponding properties.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resources-section-structure.html

Functions: The Powerhouses of Your Application - Within the Resources section, AWS Lambda functions are defined under the AWS::Serverless::Function resource type. These functions encapsulate your code logic and can be triggered by various events, such as API Gateway requests or scheduled events. Specify the function's runtime, handler, memory allocation, and other properties to unleash its full potential.

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.8
      Handler: lambda_function.handler
      CodeUri: ./lambda_function

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html

Event Sources: Triggers for Your Functions - To invoke your AWS Lambda functions, you'll need event sources. Event sources define the triggers that initiate the execution of your functions. They can be API Gateway endpoints, S3 bucket notifications, or even custom event sources. Connect your functions to the relevant event sources in the Resources section to enable seamless and event-driven serverless architecture.

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.8
      Handler: lambda_function.handler
      CodeUri: ./lambda_function
      Events:
        HelloWorldApi:
          Type: Api
          Properties:
            Path: /hello
            Method: get

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-eventsource.html

Outputs: Communicating the Magic - Outputs allow you to communicate important information from your AWS SAM template to other resources or external systems. You can define outputs to export values such as API endpoint URLs or resource ARNs. These outputs can be referenced and utilized by other AWS CloudFormation stacks or external applications.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html

Parameters:
  Stage:
    Type: String
    Default: Prod
    Description: Deployment stage of the application

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.8
      Handler: lambda_function.handler
      CodeUri: ./lambda_function
      Events:
        HelloWorldApi:
          Type: Api
          Properties:
            Path: /hello
            Method: get

Outputs:
  HelloWorldApiUrl:
    Description: URL of the Hello World API endpoint
    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/${Stage}/hello"

Et Voila!!! You've now unlocked the basic anatomy of an AWS SAM template. By understanding the different sections and elements, you have the power to craft sophisticated and scalable serverless applications. With YAML as your trusty tool and the knowledge of transforms, resources, functions, event sources, outputs, and parameters, you can architect magical serverless experiences. Stay tuned for more exciting adventures in AWS SAM, where we'll explore advanced features and techniques to take your serverless applications to new heights. Happy serverless coding!
Source: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy.html

AWS SAM Demystified

Alan Blockley — Wed, 05 Jul 2023 01:43:10 +0000

Are you intrigued by the concept of serverless computing and the wonders it can bring to your applications? Well, get ready for a mind-blowing adventure into the world of AWS Serverless Application Model (SAM)! In this article, we'll take you on a journey to demystify AWS SAM and explore its key features.

Buckle up and prepare to unleash the magic of serverless development!

Firstly let's start by understanding the essence of AWS SAM. Let's start at the beginning. AWS SAM is a powerful framework designed to simplify the development, testing, and deployment of serverless applications on Amazon Web Services (AWS). It's like having a spellbook filled with pre-defined templates, ready to enchant your applications and take away the complexities of infrastructure management.

AWS SAM is driven by three pillars;

The SAM template is your ticket to serverless stardom. It allows you to describe the AWS resources needed for your application, including functions, event sources, permissions, and more. With its simplified syntax and predefined resource types, you'll be conjuring serverless applications in no time.

  AWSTemplateFormatVersion: '2010-09-09'
  Transform: AWS::Serverless-2016-10-31
  Description: >
    sam-app

    Sample SAM Template for sam-app

  Globals:
    Function:
      Timeout: 3
      MemorySize: 128

  Resources:
    HelloWorldFunction:
      Type: AWS::Serverless::Function 
      Properties:
        CodeUri: hello_world/
        Handler: app.lambda_handler
        Runtime: python3.9
        Architectures:
          - x86_64
        Events:
          HelloWorld:
            Type: Api 
            Properties:
              Path: /hello
              Method: get

  Outputs:
    HelloWorldApi:
      Description: "API Gateway endpoint URL for Prod stage for Hello World function"
      Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
    HelloWorldFunction:
      Description: "Hello World Lambda Function ARN"
      Value: !GetAtt HelloWorldFunction.Arn
    HelloWorldFunctionIamRole:
      Description: "Implicit IAM Role created for Hello World function"
      Value: !GetAtt HelloWorldFunctionRole.Arn

The SAM CLI (Command Line Interface) is your trusty sidekick in the realm of local development. It enables you to test and debug your serverless applications on your local machine using Docker. You can simulate AWS Lambda and API Gateway locally, sparing you the need to repeatedly deploy your code to AWS during development.

  $ sam local invoke

  ...

  {"statusCode": 200, "body": "{\"message\": \"hello world\"}"}%

  $ sam local start-api

  ...

  2023-06-07 15:07:08 127.0.0.1 - - [07/Jun/2023 15:07:08] "GET /hello HTTP/1.1" 200 -
  2023-06-07 15:07:08 127.0.0.1 - - [07/Jun/2023 15:07:08] "GET /favicon.ico HTTP/1.1" 403 -

With a flick of your wrist, SAM empowers you to package and deploy your serverless applications effortlessly. It bundles your code and dependencies, generating deployment artefacts ready to be deployed using AWS CloudFormation. Deploying your application becomes as simple as casting a spell!

  $ sam deploy --guided

  Configuring SAM deploy
  ======================

  Looking for config file [samconfig.toml] :  Found
  Reading default arguments  :  Success

  Setting default arguments for 'sam deploy'
  =========================================
  Stack Name [sam-app]: hello-world
  AWS Region [ap-southeast-2]:
  #Shows you resources changes to be deployed and require a 'Y' to initiate deploy
  Confirm changes before deploy [Y/n]:
  #SAM needs permission to be able to create roles to connect to the resources in your template
  Allow SAM CLI IAM role creation [Y/n]:
  #Preserves the state of previously provisioned resources when an operation fails
  Disable rollback [y/N]:
  HelloWorldFunction may not have authorization defined, Is this okay? [y/N]: y
  Save arguments to configuration file [Y/n]: n

AWS SAM embraces the thriving serverless ecosystem by supporting popular programming languages, frameworks, and tools. Whether you're a Python charmer, a Node.js ninja, or a Java guru, SAM has got you covered. It's a gateway to a vibrant community of serverless enthusiasts, who share knowledge and reusable components.

A detailed list of runtimes can be found here - https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html

And that's it! You've gained a solid foundation to embark on your serverless journey. In this article, we've unravelled the essence of AWS SAM, explored its three pillars, mastered the SAM template, and discovered the joys of local development, packaging, and deployment. Get ready for the next adventure where we'll dive deeper into the mystical world of AWS SAM and uncover more powerful spells for serverless success. Stay curious, keep exploring, and embrace the magic of AWS SAM!