Forem: steve jones

🕹️ AWS-Powered Tetris: Building a Retro Game with Amazon Q and Amplify

steve jones — Sun, 15 Jun 2025 14:19:29 +0000

There's something magical about the games we grew up with. The simple mechanics, the blocky graphics, and the maddeningly catchy music are etched into our collective memory. So when AWS announced the Build Games Challenge, a global event to recreate these classics using modern AI tools, I knew I had to jump in.

The mission was clear: build a retro-inspired game using the Amazon Q Developer CLI and document the journey. My choice? The undisputed king of puzzle games: Tetris. But this wouldn't be just any clone. My vision was a full-stack, cloud-powered version with a real-time leaderboard, secure user authentication, and a slick, modern frontend.

This is the story of how I brought a Soviet-era classic into the serverless age, with an AI coding assistant as my partner.

If you want to just look at the code or play the game head over here:-

https://github.com/sjramblings/amazonq-game-builder-challenge
https://tetrics.sjramblings.io/

The Developer's Toolkit

To bring this vision to life, I assembled a powerful trio of technologies:

Amazon Q Developer CLI: My AI pair programmer. This isn't just autocomplete; it's a generative AI assistant in the terminal that can generate code, refactor applications, and—as I discovered—even interpret images to debug UI issues.
AWS Amplify: The powerful backbone for the entire application. Amplify is a set of tools and services that makes building and deploying full-stack web and mobile apps on AWS incredibly efficient.
Phaser.js: A popular and lightweight HTML5 game framework, perfect for the 2D game logic.

Effective Prompting: How to Talk to Your AI

Before diving into the code, it's worth sharing what I learned about communicating with Amazon Q. A good prompt is the difference between a helpful suggestion and a game-changing solution.

Be Specific and Provide Context: My initial prompt wasn't just "build Tetris." It specified the tools (Phaser, AWS Amplify Sandbox), the goal (scoreboard, authentication), and the technology (DynamoDB, Cognito). This context is crucial.
Iterate and Refine: Don't expect a perfect solution on the first try. Treat it like a conversation. When Q's first solution for the UI layout wasn't quite right, I didn't start over. I refined the prompt, saying "That's closer, but now it's not resizing..."
Use Its Own Language: When I encountered a build error, I didn't try to describe it. I fed the entire raw error log directly to Q. It understands its own ecosystem's errors better than I can paraphrase them.
Show, Don't Just Tell (Multi-modality): The most powerful technique was using screenshots. Describing a visual bug is hard. Showing it is instant and unambiguous.

Chapter 1: The Foundation - From Zero to Live in Minutes

Every great journey starts with a single step. For me, that meant scaffolding a basic project from a public Phaser + React template. With the code cloned, it was time to bring in AWS.

This is where Amplify's magic first shines. Instead of wrestling with infrastructure, the process was pure development automation:

I connected my GitHub repository to the Amplify console.
Amplify instantly detected the Next.js framework and configured the optimal build settings.
I clicked "Save and deploy."

In just a few minutes, I had a live, globally accessible URL running my base template. This seamless CI/CD workflow gave me the confidence to iterate quickly.

With my production pipeline set, I moved to local development. Here, I leveraged one of Amplify Gen 2's killer features: the Sandbox. By running a single command, I spun up a fully-featured, isolated cloud backend on my local machine.

This meant I could build and test new features, like my database and authentication, in a safe, disposable environment without affecting my live URL. It’s the perfect blend of local speed and cloud power.

Chapter 2: The Art of Conversation - Coding with an AI Partner

With the foundation laid, it was time to build the game itself. I fired up the Amazon Q CLI with q chat and began the conversation.

The Initial Prompt: Setting the Stage

A good prompt is the difference between a helpful suggestion and a game-changing solution. I learned to be specific and provide rich context.

My Prompt to Q: "I'm creating a game using the Phaser game engine. I'm working locally within an AWS Amplify Sandbox... Can you assess this repo and create a Tetris game with a scoreboard that logs users' scores into an appropriate AWS Amplify construct, such as DynamoDB? Enable Cognito for authentication so that we can track user scores."

Q didn't just spit out a monolithic code block. It acted like a seasoned developer, analysing my repo, modifying the Amplify data schema for a Score table, and then generating the core game logic, React components, and AWS integration code. In a remarkably short time, Q had scaffolded a complete, playable application.

The Reality of Development: Iterative Debugging

But as any developer knows, the first draft is never the final one. The app was functional but needed refinement. This is where the iterative, conversational nature of Q truly shined.

Challenge 1: Taming the UI

Initially, the app was a mess—the login form, game, and controls were all displayed at once.

Q's solution was a clean refactoring of my root React component, introducing state variables to conditionally render components—a foundational pattern that saved me from manually structuring the entire UI flow.

// AI-generated logic to control the UI flow
const [isAuthenticated, setIsAuthenticated] = useState(false);
const [showAuth, setShowAuth] = useState(true);

// ... later in the return statement
{showAuth && !isAuthenticated && <AuthComponent />}
{!showAuth && isAuthenticated && <PhaserGame />}

Challenge 2: When an AI Can See

The game canvas was stuck in the corner.

Describing a visual bug in text is difficult and imprecise. So, I used Q's most impressive feature: multi-modality.

My Prompt to Q: "I've taken a screenshot of the issue here /Screenshot-issue.png. Can you assess this and make the necessary updates?"

Q analysed the image and came back with a perfect diagnosis:

"I can see the issue! The game canvas is not filling the screen properly... it's showing as a small rectangle in the upper left area. The RESIZE mode isn't working as expected."

It then generated the correct Phaser configuration to fix it.

// AI-generated Phaser scale manager configuration
const config = {
  type: Phaser.AUTO,
  scale: {
    mode: Phaser.Scale.RESIZE, // Dynamically resizes to fill container
    autoCenter: Phaser.Scale.CENTER_BOTH // Keeps it centered
  },
  // ... other scene and physics config
};

However I had limited success with these changes. In the end I actually pasted the contents of a medium blog post into Q to provide guidance and it nailed it in a single shot! Impressive.

Challenge 3: Conquering the Backend Beast

The final boss of bugs was a cryptic backend error: authenticated users couldn't save their scores. I fed the raw, intimidating error log to Q. It expertly diagnosed a conflict in my Amplify authorization rules, identifying that allow.publicApiKey() and allow.guest() were creating duplicate public access pathways. Q guided me to a clean solution using identityPool as the default authorization mode.

// After (AI-suggested fix)
const schema = a.schema({ /*...*/ }).authorization(
  (allow) => [allow.guest(), allow.owner()]
);

export const data = defineData({
  schema,
  authorizationModes: {
    defaultAuthorizationMode: 'identityPool', // The key change!
  },
});

This fix, for a complex backend issue, was the ultimate proof of Q's capability. It saved me what could have been hours of documentation-diving and frustration.

The Final Touch: An AWS-Inspired Masterpiece

With the game fully functional, it was time for a creative flourish. I asked Q to theme the game around AWS services. This was development automation at its most fun*.*

Q created a new "AWS TETRICS" mode, theming each piece after a service icon and color scheme: the I-piece became an orange AWS Lambda function, the O-piece a green Amazon S3 block, and so on. The result is a game that is not only fun but a visual celebration of the AWS ecosystem.

Conclusion: A New Era of Development

This challenge was full of fun. AWS Amplify provided the rock-solid, scalable foundation that allowed me to focus on building, not managing infrastructure. The seamless CI/CD and powerful Sandbox environment created a development workflow that was both fast and safe.

But the star of the show was the Amazon Q Developer CLI. It was more than an assistant; it was a true collaborator. It can architect solutions, automate tedious tasks, and debug complex problems across the full stack—even by examining a picture. The future of development is here, and it lives in the command line.

I hope this helps someone else. Cheers

Unlock the Hidden Power of VPC Sharing in AWS

steve jones — Mon, 22 May 2023 19:40:13 +0000

As rightly stated here by Aidan Steele (AWS Hero), VPC Sharing appears to be the forgotten superpower.

While I think it is probably more suited for the hybrid Enterprise, this article will show why we use it, its benefits, and what could still do with some work on the AWS side.

What is VPC Sharing?

VPC sharing is a feature that lets multiple accounts use a single Virtual Private Cloud (VPC). It's like a big, virtual playground where different accounts can deploy their applications and resources, while still keeping everything neatly separated.

The cool thing is, you can have one account (the owner) manage the VPC, while others (participants) just get to enjoy the benefits.

The Why

Everyone is all in on the multi-account strategy; however, especially in typical enterprises, not everyone is responsible for looking after networking.

When I use the word networking, I'm talking VPC, Endpoints, IGW, Direct Connect, Managing IP CIDRS etc.

Quite often internal application teams want to own, run & build within a space that is already provided and, of course, that is all doable with multiple accounts, VPCs all plumbed in through a Transit Gateway, however, VPC sharing does provide another angle for this.

Simple Example

Two application teams running workloads that need to communicate and be accessed from on-premise. A typical multi-account setup would look like this.

A few key points about this design.

Data Transfer Costs: For anything that goes over the TGW we are going to get charged. We would probably be putting VPC Endpoints in each VPC so again more cost and duplication.

Operational Overheads: Some good security practices are going to require each application team to ensure that VPC Flowlogs are enabled, and monitored, that routes are propagated correctly and that we implement appropriate NACLs and security groups.

Using a shared VPC

A few key points about this design.

Data Transfer Costs: As we are now within the same VPC, communication between App1 & 2 is only going to incur VPC data charges. If they happen to be in the same Availability Zone we get it for free.

As above, for anything that goes over the TGW we are going to get charged. We would probably be putting VPC Endpoints in the VPC but again only one set as they can be accessed by both our applications.

Operational Overheads: Each application team is still responsible for their Security Groups however the VPC owner can now ensure that VPC Flowlogs are enabled and monitored, that routes are propagated correctly and implement appropriate NACLs for both applications.

The benefits

Simplified management: One VPC owner handles the overall VPC configuration, reducing the complexity of managing multiple VPCs across accounts.

Resource efficiency: Share a single VPC across accounts, minimizing duplicate resources and enabling better resource utilization.

Cost savings: Consolidate resources and minimize network infrastructure expenses, leading to lower overall costs.

Enhanced security: Maintain account-level isolation while sharing a common VPC, ensuring a secure and controlled environment.

Improved collaboration: Facilitate seamless cooperation among teams or projects by enabling easy access to shared resources within the VPC.

What still needs work

So there are a few points that AWS still needs to address

Not all services support it: This is a small list with the top offender being FSx for NetApp however anything that wants to control route table entries is going to trip you up.

Network Access Control Lists: The VPC Owner will need to configure these on behalf of the participants or delegate access via an assumed role. Annoying but doable.

Security Hub Checks: It would seem that the VPC and Security Hub team don't have a good relationship as checks like FlowLogs are enabled and use of the EC2 API Private Endpoint will show as non-compliant for all participant accounts if you have the SecurityHub Best Practises enabled.

Summary

I hope this post has shown you another way to share resources and work together in a secure and organized way using VPC Sharing. It's a great solution for teams or projects that want to collaborate without the headache of managing multiple VPCs!

I hope this helps someone else!

Cheers

Route 53 Resolver Magic

steve jones — Mon, 22 May 2023 19:36:39 +0000

This post covers some core concepts of Route 53 Resolvers and how they can help establish inbound and outbound name resoltion with your on-premise and AWS resources.

Introduction

Route 53 resolvers are a feature of Route 53 that allows you to route DNS queries between your VPC and your on-premises network.

This feature lets you resolve domain names hosted within your VPCs and across your hybrid cloud environment.

NOTE: Route 53 Resolvers are associated with a region as they are hosted in a VPC, unlike most of the Route 53 service, which is global.

Resolver Types

There are two main types of Route 53 resolvers: inbound and outbound. Both work by forwarding DNS queries to the appropriate DNS servers.

When your device sends a DNS query for a domain name, the resolver will check its cache to see if it already has the IP address for that domain name. If it doesn't, the resolver will forward the query to the appropriate DNS servers to get the IP address.

Once the resolver has the IP address, it will return it to your device, which can then use it to connect to the resource associated with that domain name.

Inbound

Inbound resolvers enable the resolution of private hosted zones associated with a VPC.

When you create a VPC, you can configure it to use a private hosted zone in Route 53, enabling the resolution of names to IP addresses specific to your VPC.

You can then set up inbound resolvers within your VPC to help your resources find other resources by resolving their domain names to IP addresses.

Inbound resolvers are also helpful for resolving domain names to IP addresses for resources outside your VPC, such as on-premise.

Outbound

Outbound resolvers enable the resolution of domain names outside of your VPC.

When you set up an outbound resolver, you can specify the IP addresses of the DNS servers you want to use for resolution. This can be useful if you want to use a specific DNS service for resolving domain names, such as a third-party or internal DNS provider.

They can help you connect to resources on the internet, such as public domain names and other AWS services that are outside of your VPC.

NOTE: The above shows an on-premise DNS server; however, this could be an external DNS server on the public internet.

Rules

A resolver rule is a set of criteria the Route 53 resolver uses to determine how to route DNS queries, and they are only applicable to the outbound resolver.

Expanding on the example above to resolve onpremise.net for instances inside the VPC, we would configure a forwarding rule for onpremise.net and point it to the internal DNS server.

Resource Access Manager (RAM)

RAM allows you to share your resolver rules and endpoints with other accounts in your organization. This method will enable you to define your rules once but use them across many VPCs.

This can be particularly useful when you have a central team responsible for managing DNS and want to ensure consistent DNS resolution across your organization.

NOTE: The traffic between the resolvers in each VPC and the outbound resolver goes over the AWS Global Network. There is no requirement for the VPC CIDR ranges to be able to route to the outbound resolver endpoints.

Best Practices

Here are a few things to consider for your architecture.

Use Resolver Rules Wisely

Create forwarding rules to route DNS queries for specific domains or subdomains to specific DNS resolvers. This allows you to control traffic flow and improve the efficiency of DNS resolution. Be sure to prioritize the most critical domains and establish a hierarchy of rules to minimize latency.

Endpoint Placement

Place Resolver Endpoints Strategically to manage DNS query traffic between your VPCs and on-premises networks. Place these endpoints in subnets with low latency and high network throughput to ensure fast and reliable query resolution. As shown above RAM can also assist with sharing those endpoints.

Restrict if required

Resolvers need protection just like any other endpoint in your network. Configure the necessary Security Groups and Network Access Control Lists (ACLs) to protect your resolver endpoints. Limit access to only necessary IP ranges and ports, ensuring that only authorized users and applications can interact with your DNS infrastructure.

Logging

Enable DNS Query Logging Enable logging of DNS queries to track and analyze traffic patterns, identify potential security threats, and debug any issues related to DNS resolution. Route 53 Resolver can send query logs to Amazon CloudWatch Logs, enabling you to create custom metrics and alarms for monitoring.

Monitoring

Monitor key performance metrics, such as query latency, query volume, and resolver endpoint health, to identify potential bottlenecks and capacity constraints. As your application and infrastructure grow, scale your Route 53 Resolver setup by adding additional resolver endpoints, rules, and VPC peering connections as needed.

Summary

Every hybrid network AWS setup is going to need some sort of name resolution and I hope you now have a good understanding of the capabilities of Route 53 Resolver.

Hope this helps someone else.

Cheers

AWS Prefix Lists for the Organization

steve jones — Tue, 07 Mar 2023 03:03:00 +0000

AWS Managed Prefix lists are a really powerful way of abstracting the details of CIDR Blocks into something meaningful for the humble cloud engineer.

Much like DNS does for IP addresses to hostnames, we can create a managed prefix for any service that has several CIDR blocks associated with it.

I've talked about this before here, but with more and more stuff needing to talk to services hosted on the internet and with our implementation of AWS Network Firewall, it is time for a re-visit.

The challenge

Most people are familiar with the AWS Public IP Address Ranges source ip-ranges.json, doco linked here, released in 2014. Can you believe it!

It provides all the Public IP ranges for all services across all regions. A very handy thing to have, and with it being hosted in a JSON file, we can automatically parse it with any automation.

But why don't AWS do this for us? I can't answer that today; however, a good example of such automation exists in the AWS samples GitHub here.

The AWS Samples repo does all the heavy lifting with Lambda and creates the following:-

But I'm feeling hacky and need some Organization-level sharing, Lambda PowerTools, AppConfig and deployment through SAM CLI.
Let's get into it!

Some Enhancements

Lambda PowerTools

As the homepage displays, Lambda PowerTools is a suite of utilities for AWS Lambda functions to ease adopting best practices such as tracing, structured logging, custom metrics, idempotency, batching, and more.

One of the reasons for implementing this is to make the Cloudwatch logs nicer to parse. It also removes a few lines of code in Lambda without requiring major logging structure changes.

As I've rebuilt this into SAM Cli, this is just an addition to the requirements.txt file to include aws-lambda-powertools.

AppConfig

If you look at the original AWS example, it requires a services.json to be defined to configure what regions and services to create the WAF IPsets and VPC Prefixes. It will look something like the following:-

{
  "Services": [
    {
      "Name": "CODEBUILD",
      "Regions": [
        "ap-southeast-2"
      ],
      "PrefixList": {
        "Enable": true,
        "Summarize": true
      },
      "WafIPSet": {
        "Enable": true,
        "Summarize": true,
        "Scopes": [
          "REGIONAL"
        ]
      }
    }
  ]
}

This is in JSON format, so perfect for AppConfig.
As we have configured Lambda PowerTools, AppConfig is easily added as a Lambda Layer.

I've made several updates to the template.yaml file to define our AppConfig hosted configuration and deployment methods, adding environment variables and our Lambda layer.

Parameters:
  AppConfigAppName:
    Type: String
    Description: AppConfig Application Name
    Default: aws-ip-ranges
  AppConfigAppEnvironmentName:
    Type: String
    Description: AppConfig Application Environment Name
    Default: dev
  AppConfigName:
    Type: String
    Description: AppConfig Name
    Default: services
  AppConfigLayerArn:
    Type: String
    Description: Retrieve AWS AppConfig Lambda extension arn from `https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-lambda-extensions-versions.html#appconfig-integration-lambda-extensions-enabling-x86-64`
    Default: arn:aws:lambda:ap-southeast-2:080788657173:layer:AWS-AppConfig-Extension:91
  AwsOrgArn:
    Type: String
    Description: The ARN of the AWS Organization used to share Prefix Lists
    Default: notset

Resources:
  SAMConfigApplication:
    Type: AWS::AppConfig::Application
    Properties:
      Name: !Ref AppConfigAppName

  Environment:
    Type: AWS::AppConfig::Environment
    Properties:
      Name: !Ref AppConfigAppEnvironmentName
      ApplicationId: !Ref SAMConfigApplication

  SAMConfigConfigurationProfile:
    Type: AWS::AppConfig::ConfigurationProfile
    Properties:
      ApplicationId: !Ref SAMConfigApplication
      Name: !Ref AppConfigName
      Type: 'AWS.Freeform'
      LocationUri: 'hosted'

  SAMConfigDeploymentStrategy:
    Type: AWS::AppConfig::DeploymentStrategy
    Properties:
      Name: "SAMConfigDeploymentStrategy"
      Description: "A deployment strategy to deploy the config immediately"
      DeploymentDurationInMinutes: 0
      FinalBakeTimeInMinutes: 0
      GrowthFactor: 100
      GrowthType: LINEAR
      ReplicateTo: NONE

  BasicHostedConfigurationVersion:
    Type: AWS::AppConfig::HostedConfigurationVersion
    Properties:
      ApplicationId: !Ref SAMConfigApplication
      ConfigurationProfileId: !Ref SAMConfigConfigurationProfile
      Description: 'AWS Service configuration for update-aws-ip-ranges'
      ContentType: 'application/json'
      Content: |
        {
          "Services": [
            {
              "Name": "CODEBUILD",
              "Regions": [
                "ap-southeast-2"
              ],
              "PrefixList": {
                "Enable": true,
                "Summarize": true
              },
              "WafIPSet": {
                "Enable": true,
                "Summarize": true,
                "Scopes": [
                  "REGIONAL"
                ]
              }
            }
          ]
        }
  AppConfigDeployment:
    Type: AWS::AppConfig::Deployment
    Properties:
      ApplicationId: !Ref SAMConfigApplication
      ConfigurationProfileId: !Ref SAMConfigConfigurationProfile
      ConfigurationVersion: !Ref BasicHostedConfigurationVersion
      DeploymentStrategyId: !Ref SAMConfigDeploymentStrategy
      EnvironmentId: !Ref Environment

  LambdaUpdateIPRanges:
    Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Properties:
      CodeUri: src/
      Handler: app.lambda_handler
      Runtime: python3.9
      Architectures:
        - x86_64
      Environment:
        Variables:
          APP_CONFIG_APP_NAME: !Ref AppConfigAppName
          APP_CONFIG_APP_ENV_NAME: !Ref AppConfigAppEnvironmentName
          APP_CONFIG_NAME: !Ref AppConfigName
          AWS_ORG_ARN: !Ref AwsOrgArn
          LOG_LEVEL: INFO
      Layers:
        - !Ref AppConfigLayerArn

In order to pull in the config, we add the following function and a few adjustments in the handler code.

def get_service_config():
    try:
        appconfig = f"http://localhost:2772/applications/{APP_CONFIG_APP_NAME}/environments/{APP_CONFIG_APP_ENV_NAME}/configurations/{APP_CONFIG_NAME}"
        with request.urlopen(appconfig) as response:  # nosec B310
            config = response.read()
        return config
    except Exception as error:
        logger.error("Error retrieving AppConfig configuration. Exiting")
        logger.exception(error)
        raise error

Organization-level sharing

To enable all the users in our organization to benefit from our automation, we need to share the VPC Prefixes via Resource Access Manager (RAM).

We define an additional function to create the RAM share on creating the VPC Prefix List.

def create_prefix_ram(client: Any, prefix_list_name: str, prefix_list_arn: str) -> None:
    """Create the VPC Prefix List RAM Share"""
    logger.info("create_prefix_ram start")
    logger.debug(f"Parameter client: {client}")
    logger.debug(f"Parameter prefix_list_name: {prefix_list_name}")
    logger.debug(f"Parameter prefix_list_arn: {prefix_list_arn}")

    logger.info(f'Creating RAM Share "{prefix_list_name}" with Arn "{prefix_list_arn}"')
    response = client.create_resource_share(
        name=prefix_list_name,
        resourceArns=[prefix_list_arn],
        principals=[AWS_ORG_ARN],
        allowExternalPrincipals=False,
        tags=[
            {"key": "Name", "value": prefix_list_name},
            {"key": "ManagedBy", "value": MANAGED_BY},
            {"key": "CreatedAt", "value": datetime.now(timezone.utc).isoformat()},
            {"key": "UpdatedAt", "value": "Not yet"},
        ],
    )

    logger.info(f'Created VPC Prefix List RAM Share"{prefix_list_name}"')
    logger.debug(f"Response: {response}")
    logger.debug("Function return: None")
    logger.info("create_prefix_ram end")

NOTE: All the code is available at https://github.com/sjramblings/update-aws-ip-ranges

The End Result

With our updates, this is now our enhanced Lambda workflow

Update to arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged will trigger the function
Lambda will execute under the IAM Role, retrieve its service config from AppConfig and write output to Cloudwatch
For enabled services, it will create/update the VPC Prefixes & WAF IPSets
VPC Prefixes will be shared with the Organization ID via RAM

A few screenshot of the results:-

Summary

The wonderful contributors to AWS-Samples had done a great job in getting us started. However, I needed to take it a bit further, adding the VPC Prefix Sharing and a few other tweaks.

As noted above, all code is available at https://github.com/sjramblings/update-aws-ip-ranges. I will also raise Pull Requests to backport some of this into the AWS Samples repo.

I hope this helps someone else!

Cheers

Build a Terraform Community Org on GitHub Enterprise

steve jones — Wed, 16 Jun 2021 11:20:41 +0000

https://sjramblings.io/posts/community/

AWS Gp3 cost savings

steve jones — Tue, 08 Dec 2020 17:56:41 +0000

https://sjramblings.io/posts/aws_gp3/

AWS Managed Prefixes

steve jones — Wed, 11 Nov 2020 12:23:09 +0000

https://sjramblings.io/posts/aws_managed_prefixes/

Prowler on AWS

steve jones — Wed, 04 Nov 2020 11:59:41 +0000

https://sjramblings.io/posts/prowler_on_aws/

Terraform in AWS bootstrap

steve jones — Tue, 14 Jan 2020 20:57:42 +0000

https://sjramblings.io/posts/bootstrap_terraform_on_aws/