AWS infrastructure work spans the full breadth of what organisations need to run reliably in the cloud: account structure, networking, compute, storage, databases, and the automation that holds it together. The work is hands-on engineering, from architecture through to delivery, not advisory work handed off to someone else to build.
Engagements vary. Some involve working embedded within a client’s existing engineering team. Others are more independent, taking a problem and delivering it end to end. The architecture and the build are never separated.
Architecture and Engineering Together
A background in AWS Technical Architecture means infrastructure is designed as well as built. The two are not separate concerns. An architecture that nobody can implement cleanly is not a good architecture, and infrastructure built without clear design thinking accumulates problems quickly.
This matters for clients who need someone who can assess a situation, make sound decisions about how to structure it, and then do the work. Not someone who produces a diagram and leaves.
Multi-Account Architecture
For organisations running multiple teams, products, or environments in AWS, account structure matters. A single account shared across everything creates security risks, makes cost attribution difficult, and limits the ability to apply different policies to different workloads.
AWS Organizations allows accounts to be structured around whatever makes sense for the organisation: by environment, by team, by product, or by compliance boundary. The right structure depends on regulatory requirements, how independently workloads need to operate, and the organisation’s operational model. There is no universal pattern that fits every situation.
Common concerns this addresses include centralised billing and cost allocation, organisation-wide guardrails through service control policies, controlled cross-account access, and centralised audit logging.
VPC Design and Networking
VPC decisions made early are expensive to change later. Getting CIDR allocation right from the start, avoiding clashes with existing on-premises networks or future accounts, matters more than which specific subnet pattern you use.
The subnet structure, routing, and connectivity approach should reflect the actual workload requirements. Some organisations need direct connectivity to on-premises networks. Some workloads require strict network isolation. Transit Gateway, PrivateLink, Direct Connect, Site-to-Site VPN, and VPC peering are all tools that solve specific problems. The question is which problems you actually have.
Compute
The right compute model depends on the workload. EC2 suits workloads that need specific OS control, persistent state, or predictable resource allocation. Lambda suits event-driven and short-lived workloads where the serverless model is a genuine fit. ECS with Fargate works well for containerised applications without the overhead of managing EC2 instances. The choice should be driven by workload characteristics and operational trade-offs, not by what is currently popular.
The compute decision also shapes how deployment, scaling, cost management, and operational complexity are handled downstream.
Database Infrastructure
Work in this area covers building and configuring database infrastructure on AWS: RDS and Aurora instances with appropriate backup policies, parameter groups, security group rules, encryption, Multi-AZ configuration, and monitoring. The emphasis is on the infrastructure layer. Database administration, query tuning, and schema design are out of scope.
S3, DynamoDB, and ElastiCache come into scope depending on the workload. The right service for a given requirement is worth thinking through carefully, but configuration and operational setup matter as much as the initial selection.
Infrastructure as Code
Terraform and OpenTofu are the tools used here. Infrastructure managed through code is auditable, reproducible, and reviewable in a way that console-managed infrastructure is not. This is not a preference, it is how the work is done.
For organisations with existing CloudFormation estates, migration to Terraform is a conversation worth having based on the specific situation and what the benefit would actually be. “We have always done it this way” is not a sufficient reason to stay with any particular tool, but there needs to be a clear case for change. That conversation happens based on facts, not preference.
Cost Optimisation
AWS spend is a regular concern across infrastructure engagements. Rightsizing compute, moving predictable workloads to Reserved Instances or Savings Plans, identifying unused resources, and structuring accounts for accurate cost attribution are all infrastructure decisions. Cost Optimization is a pillar of the AWS Well-Architected Framework for this reason: it is an engineering concern, not a separate financial discipline. This work sits within broader infrastructure engagements rather than as a standalone cost review service.
Why Infrastructure Patterns Matter
Infrastructure built without consistent patterns accumulates problems that compound over time. Security configurations get copied without being understood. Resources are created and never documented. Different teams implement the same service differently, creating inconsistency that makes support and auditing difficult.
The cost of this is often invisible until something goes wrong: a security incident traced back to a misconfiguration that was never reviewed, a compliance audit exposing resources nobody can account for, or AWS costs rising from infrastructure that outlived its purpose. Establishing clear patterns early is significantly cheaper than retrofitting them later.
Approach to Engagements
Work starts with understanding the current state, the problems being experienced, and what needs to be possible. This shapes what to tackle first. The highest-value starting point varies between engagements and is worth identifying before diving into implementation.
Delivery is iterative. Early work establishes foundations that later work builds on. Requirements that are not visible at the start tend to become clearer through delivery, so the approach needs to accommodate that.
What gets delivered depends on what is needed. It might be a new AWS estate built correctly from the ground up, IaC coverage of infrastructure currently managed through the console, a migration from on-premises, or targeted improvement to a specific area of an existing estate.
AWS Services
Core areas of work: EC2, VPC, RDS, Aurora, Lambda, ECS, Fargate, S3, DynamoDB, ElastiCache, CloudFront, Route 53, SQS, SNS, EventBridge, IAM, KMS, Secrets Manager, Systems Manager Parameter Store, CloudWatch, CloudTrail, AWS Config, Security Hub, GuardDuty, Transit Gateway, AWS Organizations.
Infrastructure as code: Terraform and OpenTofu. CI/CD: GitHub Actions and GitLab CI as primary tools.
When This Is Relevant
AWS infrastructure expertise is useful when building a new estate and wanting patterns established correctly from the start, when existing infrastructure has grown without clear structure and needs consolidating, when a compliance or security requirement demands auditable infrastructure, when a migration from on-premises or another cloud provider is underway, or when delivery has stalled waiting for infrastructure work that needs a dedicated, experienced engineer to move it forward.
For AWS infrastructure engagements, contact Digital Endeavours to discuss your specific requirements.
