Cloud Application Development at Full Sail University

This post covers my experience with Cloud Application Development at Full Sail University. The previous two courses, Advanced Server-Side Languages and Deployment of Web Applications, had pushed me from writing code that ran locally to writing code that ran on a server I controlled and deployed intentionally. This course moved the boundary again. Cloud Application Development removed the server itself from the equation. The infrastructure I needed was not something I would configure and maintain. It was something I would define in code and hand off to AWS to run. That shift from managing servers to consuming cloud services is a different way of thinking about how applications are built, and the four weeks it took to internalize it changed the assumptions I carry into every project now.

---

Week 1: Cloud Services, IAM, and Why Ethics Matters Here

My thoughts at the time

The first week covered the taxonomy of cloud services: Infrastructure as a Service, Platform as a Service, and Software as a Service. Knowing the difference between IaaS, PaaS, and SaaS is the kind of foundational terminology that is easy to gloss over because it sounds theoretical until you are trying to make a real architectural decision and realize the category you pick determines everything that follows. Walking through the major cloud providers and how they map services to these categories gave me a reference frame I had been missing.

The IAM (Identity and Access Management) component was the week's practical anchor. IAM basics are not glamorous, but the principle behind them is one of the most important things I had encountered in the program up to that point: every entity in a cloud environment should have access to exactly what it needs and nothing more. The exercise built the habit of thinking about permissions as a design decision rather than a deployment afterthought.

The ethics discussion around cloud computing and data privacy also landed harder than I expected. Sharing user data with third-party cloud providers carries legal and ethical weight that does not disappear just because the infrastructure is convenient. That is not an abstract concern. It is the kind of thing that gets companies into courtrooms.

Retrospective insight

IAM is one of those topics where the knowledge feels administrative until a security incident makes it feel foundational. The discipline of scoping permissions tightly and treating every service identity as a potential attack surface is now part of how I design anything that runs in a cloud environment. The ethics framing also stuck in a way that purely technical content sometimes does not. Thinking about what data you are sending where, and under what terms, is a responsibility that does not end at the architecture diagram.

---

Week 2: Serverless Functions, Lambda, and the CDK

My thoughts at the time

Week two is where the serverless model stopped being a concept and became something I could actually build with. AWS Lambda is a function that runs in response to an event and then stops existing. There is no server to keep alive between invocations. That model is simple to describe and genuinely strange to work with the first time, because the mental habits built from months of Express and Node.js server code carry assumptions about state, persistence, and process lifecycle that do not apply.

YAML came up here as the language for configuring infrastructure, and the AWS CDK (Cloud Development Kit) introduced the idea that infrastructure itself could be expressed in TypeScript. The connection to the type discipline from Advanced Server-Side Languages was direct: defining infrastructure in the same language and with the same tooling as application code meant that the same habits of clarity and structure applied. The AWS SDK was the mechanism for interacting with cloud services programmatically, and working through it made the abstraction layers of cloud development visible in a useful way.

Retrospective insight

The CDK specifically has had lasting relevance. Infrastructure as code is the standard approach in any environment where deployments need to be repeatable, reviewable, and version-controlled. Having used it in a course exercise rather than just read about it meant that picking it up again in a later context required orientation rather than learning from scratch. The Lambda execution model also reframed how I think about backend logic: not everything needs a persistent process, and functions that run on demand are often a better fit for intermittent workloads than a server that idles between requests.

---

Week 3: AppSync, DynamoDB, Amplify, and Cognito

My thoughts at the time

Week three introduced the AWS services that form the backbone of a full-stack serverless application: AppSync for managed GraphQL, DynamoDB for NoSQL data storage, Amplify as the development and deployment platform, and Cognito for authentication. Each of these is a course on its own in the broader AWS ecosystem. Encountering them together in a single week meant tracing the connections between them rather than mastering any one in depth.

The combination of AppSync and DynamoDB was the part that changed how I thought about data access patterns. A REST API designed around MongoDB, which I had built in Server-Side Languages, treats data as rows or documents you query flexibly. DynamoDB requires you to think about access patterns at the time you design the schema, because the way you structure the table determines what queries are fast and what queries are impossible. That is a different discipline, and it is one where getting it wrong is expensive to fix later.

Cognito handled authentication in a way that offloaded a significant amount of complexity. Every authentication system I had built previously was something I maintained: I stored the credentials, managed the tokens, and handled the edge cases. Cognito moved that responsibility to AWS. The tradeoff is that you are now working within the constraints of someone else's system, but those constraints are designed around security requirements that are difficult to satisfy independently.

Retrospective insight

This week introduced me to the managed services model as a design philosophy, not just a collection of AWS products. Offloading authentication, data storage, and API management to purpose-built services means fewer things to build wrong, at the cost of tighter coupling to a specific provider. Understanding that tradeoff explicitly is more useful than having an opinion about it, because the right answer depends on the project. The ability to evaluate that tradeoff confidently came from having worked through a concrete implementation rather than just read the documentation.

---

Week 4: SAM, Facial Recognition, and Advanced JavaScript in the Cloud

My thoughts at the time

The final week pulled everything together through the AWS Serverless Application Model (SAM) and introduced Rekognition for facial recognition. SAM is a framework for defining, testing, and deploying serverless applications as a complete unit. Where earlier weeks had worked with individual services, SAM provided the mechanism for treating a serverless application as a deployable artifact that could be templated, versioned, and reproduced.

Facial recognition as a final project component was the most visibly impressive thing I had built in the program to that point, and also the one that brought the ethics discussion from week one back into focus most sharply. Rekognition works. The accuracy is high and the integration through the SDK is straightforward. The questions about when and whether it should be used do not have straightforward answers. Building something that raises those questions is a more honest preparation for professional work than building something that does not.

The advanced JavaScript methods component rounded out the week by connecting the cloud services back to the client-side code layer, reinforcing that the architecture we had been building throughout the course exists to serve a frontend that users actually touch.

Retrospective insight

SAM solidified the infrastructure-as-code habit that the CDK had introduced in week two. Defining a complete serverless application in a single template, deploying it with a single command, and being able to reproduce it in a different environment without manual configuration is a capability that was hard to appreciate from the outside but obvious in value once I had worked through it. The facial recognition component also gave me a realistic picture of what "integrating a third-party cloud-native resource" actually means in practice: the technical integration is often the easier part. The harder part is the judgment call about whether you should.

---

Closing Thoughts

Cloud Application Development was the course where the infrastructure I had been deploying to finally became something I could shape rather than just configure. The progression from Server-Side Languages to Deployment to Advanced Server-Side Languages to this course traces a path from writing backend code locally to writing applications that are defined, deployed, and operated entirely in the cloud. Lambda, DynamoDB, Cognito, AppSync, and the CDK are tools I have reached for since, and the understanding of when each one is the right choice and when it is not is what this course was actually teaching underneath the exercises.

Credits and Collaboration

A huge thank you to Esther Allin for designing the blog banner art! If you're looking for a professional digital media specialist, Connect with her on LinkedIn!