AWS Developer
Good AWS infrastructure does not run itself. Behind every well-architected environment is a developer who knows which SDK method avoids a cold start, how to structure a SAM template so local testing matches production behaviour, and when to reach for SQS instead of EventBridge.
AWS developer talent and team capability for agencies and product teams across Australia, the UK, and Singapore.
What Separates an AWS Developer from a Developer Who Works on AWS
Most backend developers can provision an EC2 instance, write a Lambda function in the console, and read a CloudWatch log group when something breaks. That is working on AWS. An AWS developer is doing something different: designing the local development environment so integration tests run against the same IAM role the function will use in production. Writing DynamoDB access patterns before the schema. Knowing that a 128MB Lambda function with a 500ms timeout handles a specific queue workload more cost-effectively than a 512MB function with a 3-second timeout, and demonstrating why from a CloudWatch Logs Insights query.
For agencies delivering AWS development services, the question is not whether the team can write code that runs on AWS. It is whether that code was written by someone who understands each service’s specific characteristics well enough to make decisions that hold up at scale.
AWS Developer Capabilities We Provide and Build
Six areas where AWS developer depth makes the difference between code that works and code that holds up.
Lambda and Serverless Development with SAM CLI
SAM CLI is the AWS developer tool for building, testing, and deploying serverless applications locally. SAM local invoke runs a Lambda function in a Docker container matching the production runtime with the same memory limits, execution role simulation, and timeout behaviour. SAM local start-api starts a local API Gateway endpoint routing to Lambda functions. Developers who test against the actual runtime catch permission errors, timeout issues, and cold start behaviour before deployment.
AWS SDK Integration and Idiomatic Service Usage
AWS SDK usage patterns affect correctness, cost, and operational behaviour in ways generic backend experience does not prepare for. DynamoDB GetItem defaults to eventual consistency, producing intermittent data integrity issues under concurrent access when strong consistency is required. S3 presigned URLs expire at generation time, not upload time, and short expiry durations produce client errors only under realistic production timing. Idiomatic SDK usage means knowing these characteristics before writing the call.
Local Development Environments That Mirror AWS Production
Local AWS developer environments use LocalStack for mocking SQS, SNS, DynamoDB, and S3 in a single Docker container; SAM CLI for Lambda invocation with real runtime behaviour; DynamoDB Local for access pattern testing without consuming provisioned capacity; and named CLI profiles for switching between local mock credentials and real AWS account access. The goal is to make the iteration cycle fast enough that developers test against realistic AWS behaviour on every change.
DynamoDB Data Modelling and Access Pattern Design
DynamoDB data modelling starts from access patterns, not an entity model. A table designed by mapping relational entities to items will typically require multiple queries or a full table scan for common application questions. Single-table design, with multiple entity types and a composite sort key supporting the primary access patterns, requires knowing the queries before the first item is written. Getting the model right before build is substantially cheaper than migrating it after months of production data.
Event-Driven Architecture Implementation on AWS
Event-driven implementation on AWS requires selecting the right messaging service for each communication pattern. SQS standard queues require idempotent consumers for at-least-once delivery. SQS FIFO provides exactly-once processing within a message group but with throughput limits. EventBridge routes events by content but has no dead-letter mechanism natively. SNS fan-out with SQS subscriptions provides reliable one-to-many delivery where individual consumer failure does not affect others. Knowing which pattern to apply before writing the first producer.
AWS Developer Tooling: CLI, Toolkit, CloudShell, and CDK
The AWS developer tooling ecosystem includes the CLI with named profiles for secure account switching without stored long-lived credentials, AWS Toolkit for VS Code and JetBrains for in-editor Lambda debugging and CloudWatch Logs tailing, CloudShell for quick administrative tasks with pre-configured credentials, and CDK TypeScript or Python for expressing infrastructure in the same language as application code. Each tool reduces a specific category of daily friction in AWS development work.
How We Support Agencies With AWS Developer Talent and Team Capability
Agencies that win AWS development projects need AWS developers, not just developers who can write code on AWS. The gap shows up at the moments that matter: the DynamoDB schema designed for relational thinking that requires a migration six months into production, the Lambda function with memory allocation left at the default 128MB, the SQS queue without a dead-letter queue. These are foreseeable consequences of deploying AWS-specific patterns without AWS-specific knowledge.
We provide AWS developer capability through staff augmentation and code review, both delivered under the agency brand. The AWS developer tools catalogue and the AWS SDK for Python reference the tooling our developers bring. Both engagement models run through our agency partner program under the client’s white-label model.
Four Things an Experienced AWS Developer Gets Right Before Writing Application Code
IAM Permissions Designed at the Resource Level, Not Wildcard Level
Error Handling That Accounts for Eventually Consistent Service Behaviour
A developer who grants a Lambda function s3:* on * because scoping the specific bucket ARN takes longer has created a permission configuration that survives every code review until it appears in a security audit. Scoping IAM permissions to specific resource ARNs and specific actions at the time the function is written takes twenty minutes at authoring time. Remediation in production when permission scope has grown over months of accumulated additions takes an unknown amount of effort across multiple services.
Cost-Aware Service Configuration, Not Default Settings
DynamoDB GetItem with default consistency settings may return a value just overwritten by a concurrent write. S3 list operations after a recent put may not include the newly written object. Application code that does not handle these cases explicitly passes unit tests but produces intermittent issues under concurrent production access. The correct patterns are conditional writes with version attributes on DynamoDB items and retry logic with exponential backoff on S3 operations where eventual consistency affects the workflow.
Observability Built Into the Application, Not Added After Deployment
Lambda memory allocation determines CPU allocation: a 512MB function receives twice the CPU of a 256MB function. For CPU-bound workloads, doubling memory often halves execution duration, and because Lambda pricing is memory times duration, the cost is sometimes identical or lower at higher memory. The correct approach is profiling actual CPU and memory usage with CloudWatch metrics before setting the allocation, not accepting the default or choosing a round number. The same analysis applies to RDS instance sizing and DynamoDB capacity mode selection.
Observability built at development time tells you why something broke and how long it took. Structured logging with a correlation ID propagated across service calls, request duration in every handler, and error context including the input that caused the failure. X-Ray active tracing on Lambda, ECS, and API Gateway so a slow request is traceable to the specific downstream call. The agency partner program covers our developer observability standards.
AWS Developer Support for Agency-Delivered Projects
The most common gap in agency-delivered AWS projects is not a lack of programming ability. It is a lack of service-specific knowledge at the exact point when that knowledge would prevent an expensive decision. A DynamoDB schema designed without access-pattern-first thinking will work for months, then require a migration as access patterns become clear. A Lambda timeout set to something that seemed reasonable will mask downstream dependency issues in production. We embed AWS developers at the points where this gap is most likely to produce expensive consequences. See our agency partner documentation.
Agencies that want AWS developer support on a current project can start with a code and configuration review. Contact us to describe the project and we will scope what is most useful for the stage the project is at.
Two AWS Developer Mistakes That Look Like Application Bugs but Are Actually Configuration Problems
The first mistake is Lambda timeout misconfiguration hiding downstream dependency issues. A Lambda function is given a 30-second timeout because it seemed long enough. In production under concurrent load, the RDS connection pool is exhausted. At 30 seconds the Lambda times out. The application team investigates and concludes the Lambda function is broken. It is not: the connection pool is undersized. The timeout masked the real problem. An AWS developer examining the RDS connection count metric identifies the saturation pattern and addresses it through RDS Proxy, not Lambda code.
The second mistake is SQS visibility timeout set shorter than Lambda execution duration. When the Lambda takes longer than the visibility timeout, SQS makes the message visible again while the original invocation is still running. A second invocation picks it up. If processing is not idempotent, duplicate processing corrupts state. The fix is one configuration change: visibility timeout at least six times the Lambda timeout. Neither mistake requires new code. Both require an AWS developer who knows the relationship between service parameters, which is what we bring to AWS development. The project outcomes reflect it.
AWS Developer Engagement Models for Agencies and Product Teams
Staff Augmentation for AWS Development Sprints
AWS Code and Configuration Review
Staff augmentation places an AWS developer with specific service depth into the agency sprint team for an engagement. The developer attends standups, participates in sprint planning, writes code under the agency review process, and works inside the agency delivery tooling. From the client perspective, this person is a member of the agency team. Augmentation can cover a full sprint cycle or specific technical phases where AWS service depth is most critical.
AWS Developer Onboarding for Existing Teams
Code and configuration review is a time-bounded engagement where an AWS developer reviews application code, SAM or CDK templates, and IAM role definitions. The review produces a prioritised findings report: configuration risks, permission scope issues, missing error handling for service-specific failure modes, and observability gaps. Most valuable before the first deployment to staging, when corrections are still low-cost.
Ongoing AWS Developer Retainer
AWS developer onboarding brings an existing development team up to operational proficiency on the specific AWS services used in their project. Structured around the team’s actual implementation: working through the DynamoDB access pattern design for their specific data model, configuring SAM local for their Lambda functions, and setting up CLI profile structure for their multi-account environment. Practical and project-specific, not general AWS training.
An ongoing retainer provides access to AWS-specific technical expertise on a monthly basis for product teams that deploy regularly and encounter service-specific questions every sprint. Covers code review, architecture questions, configuration guidance, and incident support when AWS service behaviour produces unexpected application outcomes. Fixed monthly pricing. Direct access to the same developer across the retainer term so context accumulates rather than restarts.
How We Bring AWS Developer Capability Into an Agency Project
Step 1: Technical Scoping Session
Step 2: AWS Developer Matching and Context Transfer
The scoping session establishes the service profile of the project: which AWS services are in scope, what stage the project is at, the existing team’s AWS familiarity level, and the highest-risk technical decisions in the immediate sprint. Typically thirty to sixty minutes. Produces a clear picture of what AWS developer capability the project needs and when. No commitment required at the scoping stage.
Step 3: Engagement Start and Communication Setup
The AWS developer assigned to the engagement has confirmed experience with the specific services the project uses. A project with significant DynamoDB access pattern complexity gets a developer who has designed DynamoDB schemas in production. Context transfer covers the project architecture, existing codebase structure, delivery team tooling, and any technical concerns the agency has identified before the engagement starts.
Step 4: First Sprint Contribution and Configuration Review
Communication setup confirms which channels the developer will use with the agency team, how they will be introduced to the client if client-facing, and what deliverables are expected in the first sprint. For staff augmentation, the developer joins the agency standups and sprint ceremonies from day one. For code review engagements, the review schedule and output format are agreed before work begins.
Step 5: Ongoing Delivery Inside the Agency Process
The first sprint includes delivery work and a configuration review of the existing codebase and infrastructure definitions. The review is a working session rather than an audit: the developer and delivery team walk through the implementation together, identifying and correcting issues in the same session. Issues caught in the first sprint that would have reached production are the primary value measurement of the engagement.
Step 6: Knowledge Transfer and Engagement Closure
From the second sprint, the developer participates in delivery as a team member. Code they produce is reviewed by the agency development lead. Code from other team members is reviewed with AWS service expertise. Architecture decisions requiring service knowledge are discussed in sprint planning. All outputs are delivered under the agency’s development process and branded under the agency identity.
From First Conversation to AWS Developer Capability Inside Your Team
At engagement close, the developer produces a knowledge transfer document covering service-specific decisions made during the project, non-obvious configuration choices and why they were made, and operational watch points for the first months of production. The document is owned by the agency and client from day one. Contact us to start the scoping conversation for your next AWS project.
AWS Developer Questions Answered
Questions about local AWS development setup, Lambda configuration, DynamoDB design, SDK patterns, and how AWS developer expertise fits into agency project delivery.
How do you set up a local development environment that accurately reflects AWS production?
A local AWS developer environment that reflects production uses three components. SAM CLI for Lambda functions: SAM local invoke runs the function in a Docker container with the same runtime, handler path, and simulated execution role so permission errors appear locally rather than after deployment. LocalStack for dependent services: LocalStack runs local versions of SQS, SNS, DynamoDB, S3, and other services in a single container. Named CLI profiles for environment switching: the AWS CLI and SDK use named profiles so a developer can point a local test at LocalStack credentials for development and switch to a real AWS account for integration testing without changing application code.
What is SAM CLI and when should an AWS developer use it?
SAM CLI is the AWS Serverless Application Model command-line interface for building, testing, and deploying Lambda-based applications. SAM local invoke runs a Lambda function locally in a Docker container matching the production runtime, with the same memory limit and timeout the SAM template specifies. SAM local start-api starts a local HTTP endpoint routing API Gateway-style requests to Lambda functions. SAM build compiles dependencies in a Lambda-compatible environment, preventing native dependency failures in the Lambda runtime. SAM deploy handles CloudFormation stack creation with guided configuration. Developers use it whenever the application includes Lambda functions because it provides local testing the console does not.
Why does DynamoDB data modelling need to happen before application development starts?
DynamoDB does not support ad-hoc queries across arbitrary attributes. Queries must use the partition key and optionally the sort key. Filtering on non-key attributes requires scanning items matching the partition key or scanning the entire table, which is expensive at scale. The correct approach: identify every query the application needs to answer, design table keys and secondary indexes to support those queries, then build the application against that model. Changing the model after the table contains production data requires migrating to a new table structure, involving a parallel write period, backfill process, and cutover with operational risk.
How should Lambda function memory and timeout be configured?
Lambda memory configuration determines both memory available and CPU allocated, with CPU scaling linearly with memory. For CPU-bound workloads, increasing from 256MB to 512MB often halves execution duration because CPU doubles. Since Lambda pricing is memory times duration, cost may be identical or lower at higher memory. The correct process is to deploy with more memory than seems necessary, observe actual memory used and execution duration in CloudWatch metrics after real traffic, then set the allocation to the point where increasing memory produces diminishing duration improvement. Lambda timeout should be set slightly above the maximum expected execution duration under realistic load, not the maximum allowed value.
What is the correct SQS visibility timeout for a Lambda consumer?
The SQS visibility timeout for a Lambda consumer must be at least six times the Lambda function timeout. When Lambda polls SQS it makes messages invisible for the visibility timeout duration. If the function does not finish within that window, SQS makes the message visible again and another invocation picks it up while the first is still running. For a 60-second Lambda timeout, SQS visibility timeout should be at least 360 seconds. Every SQS queue triggering a Lambda function should also have a dead-letter queue configured. Without a DLQ, consistently failing messages are silently discarded when MaxReceiveCount is reached.
How should structured logging be implemented in Lambda functions?
Structured logging in Lambda means writing log entries as JSON so CloudWatch Logs Insights can parse individual fields. Each entry should include at minimum: a correlation ID tying together all entries from a single user request across multiple invocations; the function name and version; duration of significant internal operations; and for errors, the full message, the input that caused it, and the stack trace. The correlation ID is typically passed from API Gateway as a custom header and propagated through SQS and SNS messages. Lambda Powertools for Python and TypeScript provides a structured logger handling JSON formatting and correlation ID propagation as a decorator on the handler function.