AWS Services for Developers: The Last DVA-C02 Window Before DVA-C03
A recap of the AWS Egypt online meetup held on Monday, September 28, 2026 (10:00 PM Cairo time, GMT+3, via Google Meet). The live session was delivered in Arabic with English support for guests; this write-up adapts it for swac.blog. It covers a categorized map of the AWS services developers actually use, eight application architectures from simple to complex, and what to know before the AWS Certified Developer – Associate exam changes. The session recording can be viewed from here
Why this map, and why now
AWS has far more services than any developer will ever touch, and most learning material either skips the map entirely or buries it under hours of console clicks. This is a practical map of AWS services for developers, built to make the next architecture decision clearer. This session took the opposite approach, built around one sentence that kept coming back: this is the map, not the manual.
It also had a deadline attached. The AWS Certified Developer – Associate exam is being updated, and AWS’s September 2026 Training and Certification announcement sets the clock:
| Date | What happens |
|---|---|
| October 27, 2026 | Registration for the updated exam (DVA-C03) opens |
| November 30, 2026 | Last day to take the current exam (DVA-C02) |
| December 1, 2026 | DVA-C03 becomes available |
(Sources: AWS’s September 2026 Training and Certification announcement and the current certification page, checked October 24, 2026. Both list October 27 for DVA-C03 registration and November 30 as the final DVA-C02 testing date. Always confirm the current certification page before booking.)
The session looked at the same material through two lenses: the practical one (what do you build, and with what?) and the exam one (what does the Developer Associate expect you to recognize?). The two overlap far more than people expect, which is why this map of AWS services for developers works for both.
The exam in one section
Before the architectures, a quick orientation on the certification itself.
- Where it sits. AWS certifications run from foundational (Cloud Practitioner, AI Practitioner) through associate (Solutions Architect, Developer, Machine Learning, Data Engineer, CloudOps Engineer) and professional (Solutions Architect, DevOps Engineer) to specialty exams such as Security and Advanced Networking. The session focused on the Developer Associate.
- Format. 130 minutes, 65 questions, multiple choice or multiple response (per AWS’s certification page for DVA-C02).
- Overlap with DevOps. The session’s estimate is that the Developer Associate and the DevOps Engineer exam share roughly 40% of their ground. This is a rule of thumb from the speaker, not an official AWS figure – but it is good news for developers and DevOps engineers alike, because preparing for one pays off for the other.
- DVA-C02 domains. Development with AWS Services (32%), Security (26%), Deployment (24%), and Troubleshooting and Optimization (18%).
- What DVA-C03 changes. According to AWS’s announcement: AI-assisted development tools across all four domains, a new AI security task (access management for AI services, prompt injection protection, AI agent security), building and deploying containers with ECR, ECS, EKS and Fargate, and new in-scope services: Amazon Bedrock, Amazon Bedrock AgentCore, Amazon Q, Kiro, Amazon Data Firehose and AWS PrivateLink. The four domains remain, but the weights shift: Development with AWS Services (30%), Security (26%), Testing and Deployment (22%), and Troubleshooting and Optimization (22%). AWS directs candidates to check back on October 27 for more information, so treat finer details as provisional until the full exam guide is published.
- Extra time for non-native English speakers. AWS offers a 30-minute extension (“ESL +30 minutes”) for exams taken in English, as described in AWS’s exam accommodations instructions. It is requested once, from your AWS certification account, before you register for your first exam.
Part 1: AWS services for developers, grouped by category
The first part of the session laid out AWS services for developers in eight categories, each with its current lifecycle status – because a course recorded two years ago teaches you what AWS looked like two years ago.
| Category | Services covered |
|---|---|
| Compute | EC2, Lambda, Elastic Beanstalk, ECS, EKS, Lightsail, App Runner |
| Frontend and hosting | Amplify Hosting, S3, CloudFront |
| Data and storage | DynamoDB, RDS and Aurora, ElastiCache |
| Networking and APIs | API Gateway, Application Load Balancer, Route 53 |
| Identity and access | IAM, Cognito, Secrets Manager, STS |
| Messaging and integration | SQS, SNS, EventBridge, Step Functions |
| CI/CD and developer tools | CodeCommit, CodeBuild, CodeDeploy, CodePipeline, AWS SAM, CDK |
| Observability | CloudWatch, X-Ray, CloudTrail |
Reading the status column
Three labels were used throughout, and the difference matters when you are choosing what to build on. They follow AWS’s own service lifecycle definitions:
- Maintenance – you can no longer onboard new usage, but existing customers can keep using the service. AWS continues to operate and support it without adding functionality.
- Sunset – existing customers should plan to migrate to the recommended alternatives. A sunset timeline is typically 12 months, ending with the date AWS stops operating and supporting the service.
- Full shutdown – the final stage. The service is completely removed from the AWS portfolio and is no longer available or supported.
And here is what that looked like in the developer tools category, as of October 2026. The authoritative, always-current list is AWS’s page on services in maintenance – check it before you commit to anything on this list:
| Service | Status |
|---|---|
| Cloud9 | In maintenance since the July 25, 2024 announcement – AWS points to the AWS IDE Toolkits or AWS CloudShell as alternatives |
| CodeStar | Full shutdown (July 25, 2024) |
| CodeCatalyst | In maintenance since the November 7, 2025 announcement |
| CodeGuru Reviewer | In maintenance – AWS announced the change October 7, 2025; new repository associations stopped November 7, 2025. Amazon Q Developer and Amazon Inspector are alternatives depending on the need. |
| App Runner | Closed to new customers as of March 31, 2026; existing customers can continue to use it. AWS recommends exploring ECS Express Mode when migrating. |
| CodeCommit | Returned to general availability in November 2025 after an earlier new-customer restriction |
One more date worth writing down if you start with WordPress on Lightsail: from November 19, 2026, you can no longer select the older Bitnami-packaged WordPress blueprint for a new instance. Existing instances continue to run, and you can still create instances from existing snapshots; for a new build, use the Lightsail-packaged WordPress blueprint instead.
Part 2: The architecture ladder
The heart of the session: eight application architectures, one question each time – what does this application actually need? The services follow from the answer, not the other way around. (If you want the same lens on the AI-assisted side of development, the previous AWS Egypt session on spec-driven development with Kiro is the natural companion.)
Level 1 – Just WordPress
Lightsail. A Lightsail instance is a simplified facade over the same compute underneath: pick the WordPress (or LAMP) blueprint and you get the server, PHP and MySQL bundled together, one service, one price, one place to click. The contrast that was drawn live: building the same thing on raw EC2 means creating the instance, opening SSH access, installing the stack, and managing all of it yourself. Same destination, very different amount of ownership.
Level 2 – WordPress at scale
Route 53, CloudFront, EC2, RDS (with S3 for media). When “I need more control and more traffic” replaces “I just want a site”, the architecture splits into parts: Route 53 for the domain, CloudFront for caching at the edge, EC2 running WordPress, and RDS (MySQL or PostgreSQL) as a managed database kept separate from the server. Running across two or three Availability Zones is what moves this from “works” toward “survives a failure” – provided the components (the EC2 fleet, the RDS database) are actually configured for redundancy and failover. The point of the level was not to memorize four services – it was to notice that the services appeared as consequences of requirements.
Level 3 – A frontend, nothing else
Two paths, and both are worth knowing:
- The managed path – Amplify Hosting. Connect a Git repository (React, Vue, Next.js) and it builds, deploys, previews branches and serves over a CDN. If you are coming from Vercel or Netlify, this is the AWS service to try first – though that is a starting point, not a claim that the two are identical.
- The build-it-yourself path – S3 + CloudFront. S3 holds the static files, CloudFront serves them worldwide, and AWS Certificate Manager provides the certificate so CloudFront handles TLS termination for HTTPS, with Route 53 pointing the domain at the distribution.
Level 4 – Frontend plus an API (and identity)
API Gateway, Lambda, DynamoDB. API Gateway receives the request, Lambda runs the handler, DynamoDB stores the data. It is one of the most common serverless patterns on AWS, and a useful way to see how AWS services for developers work together. Lambda supports multiple runtimes (Node.js for JavaScript and TypeScript, Python, and others), and throttling behavior came up here as something to understand early rather than discover in production.
Then one new requirement – “users need accounts” – slots into the same architecture without a redesign. Cognito signs users up and in and issues a token; the frontend sends the token with each request; API Gateway validates it through an authorizer; Lambda only ever receives already-authorized requests. Cognito can also federate with external identity providers such as Google and Facebook, and the SDKs for JavaScript and TypeScript make the integration straightforward – authentication and authorization as an off-the-shelf service instead of something you write.
Level 5 – The monolith
ALB, EC2 with Auto Scaling, RDS. One codebase, one deployable unit, a load balancer spreading traffic across identical servers and one shared database. It remains a completely valid architecture; not everything needs to be serverless. This is also where the three current load balancer types were compared: Application (HTTP/HTTPS routing), Network (high-performance TCP/UDP), and Gateway (for inserting network appliances into the traffic path).
Level 6 – Microservices
ALB, then ECS (or Fargate). Take an e-commerce application and split it into independent services; this is where AWS services for developers move from one deployable unit to independently scalable components – orders, users, payments, later inventory and shipping – each in its own container, each deployable and scalable on its own, and free to use different technologies. ECS runs them either on instances you manage or fully managed through Fargate. If Kubernetes is already central to how your organization works, EKS is the other path; that comparison deserves its own session. Worth noting for exam planning: AWS’s DVA-C03 announcement adds building images with ECR and deploying with ECS, EKS and Fargate to the exam scope.
Level 7 – Event-driven
Here the shift underneath everything becomes explicit: synchronous request/response gives way to asynchronous, decoupled processing. Three tools, three patterns:
- SQS – a queue. It buffers work so the consumer catches up at its own pace.
- SNS – pub/sub. One message, fanned out to every subscriber.
- EventBridge – an event bus. Events routed by rule, across services and even accounts.
The running example: when the orders service publishes an event, inventory and shipping each react independently – and orders never needs to know they exist. That decoupling is also where resilience patterns such as retries and circuit breakers earn their place.
Level 8 – From commit to production
CodeBuild, CodePipeline, CodeDeploy. Source lives in CodeCommit or GitHub, CodeBuild compiles and tests, CodePipeline chains the stages, CodeDeploy ships to EC2, Lambda or ECS. The session also made the practical point that real pipelines mix tools: GitHub Actions and Jenkins appear next to the AWS services all the time, and that is fine.
Two operational add-ons were covered at this level:
- Feature flags. AWS AppConfig (or Flagsmith, an open-source option that is not an AWS service) lets you switch features on and off without redeploying – disabling a misbehaving chat feature, or rolling out dark mode gradually.
- Watching it all. CloudWatch for logs, metrics and alarms, X-Ray for tracing a request across services, plus third-party or open-source options such as GlitchTip (not an AWS service) for error tracking.
We have gone from writing code to operating software – which is exactly the bridge into the next episode of this series.
One more thing to know cold: Route 53 routing policies
Route 53 came up repeatedly, and its routing policies are worth knowing by name. The session covered five of them; my earlier post on Route 53 routing policies goes through all seven, including failover and geoproximity, in more depth.
- Simple – one record, one answer.
- Weighted – split traffic between endpoints by relative weights (for example, gradually shifting a small share of traffic to a new version).
- Latency-based – send users to the Region that responds fastest for them (say, Frankfurt versus US East).
- Geolocation – route by where the user is.
- Multivalue answer – return several healthy records for one DNS query.
Exam tips and tricks
The practical advice shared during the session, in one place:
- Think in scenarios, not services. Ask “what does this application need?” first. The map of AWS services for developers then becomes a set of answers rather than a list to memorize. The services are the answer to a requirement – memorizing a long list of service names without the requirement behind each one will not hold up.
- Know the resilience vocabulary. Fault-tolerant and resilient application design, error handling in Lambda, retry logic, circuit breakers, and the difference between synchronous microservices and event-driven patterns are recurring themes.
- Know your Route 53 policies and load balancer types – they are small topics that show up in architecture scenarios.
- Use the official material first. The exam guide and sample questions linked from AWS’s certification page tell you what is in scope. Then practice with mock exams.
- Create the accounts today. Set up a free account on AWS Skill Builder and an account on the AWS training and certification platform – you need the latter to book the exam and to request the ESL extension.
- Decide your timeline. If you have already prepared, book before November 30. If you have not, build a compressed study plan around the official exam guide rather than trying to learn everything.
- If English is not your first language, request the 30 extra minutes before you register.
What’s next
This session only scratched the surface, by design. The series continues with deep dives into one part of the map at a time:
- Serverless
- Developer tools and CI/CD
- Databases
- Containers and microservices
Takeaways
- A categorized map of AWS services for developers beats a service-by-service tour – especially now that the lifecycle status of a service matters as much as what it does.
- Services are consequences of requirements. Start from “what does this application need?” and the right AWS services tend to show themselves.
- The jump from monolith to microservices to event-driven is really a jump from synchronous to asynchronous thinking – and that is the theme the session kept returning to.
- The DVA-C02 window is short: registration for DVA-C03 opens October 27, and the last day for DVA-C02 is November 30.
