AWS Scales Academic Cloud Computing Programs Across Virginia

Amazon Web Services (AWS) has continued to expand its partnerships with academic institutions to offer associate and bachelor’s degree specializations in cloud computing. The initiative’s latest focus is the Commonwealth of Virginia — a state experiencing rapid growth in cloud-related hiring, driven in part by Amazon’s second headquarters development in Arlington, VA.

According to data cited at the time of the announcement, job postings requiring cloud computing skills in Virginia grew from approximately 5,000 per month in September 2016 to around 20,000 per month by late 2019 — a roughly fourfold increase in just three years.

Governor’s Announcement and the Virginia Partnership

Virginia Governor Ralph Northam announced a broadened collaboration between AWS, the Virginia Community College System (VCCS), four-year universities, and select K-12 school districts. The goal: create a clear educational pipeline from high school through a four-year degree, equipping students with the cloud computing skills employers are actively seeking.

Participating institutions will incorporate the AWS Educate program into high school STEM curricula, as well as into associate and bachelor’s degree programs. High school students will be able to earn college credit through dual enrollment and early college models, lowering the barrier to entry for cloud computing careers.

From 30 Students to 200: George Mason and NOVA Lead the Way

George Mason University and Northern Virginia Community College (NOVA) were among the first higher education institutions in the United States to offer cloud computing degree programs. Their combined pathway — a two-year associate program at NOVA feeding into a four-year program at George Mason — is now a proven model. The 63-credit program initially enrolled 30 students and had grown to 200 by the time of this announcement.

Starting in fall 2020, students were expected to be able to pursue a seamless degree path in cloud computing from NOVA’s two-year program through to George Mason’s four-year offering. The success of this model is what Virginia officials plan to replicate across additional community colleges and universities statewide.

Institutions Committed to the Virginia Cloud Computing Program

The following academic institutions have committed to implementing cloud computing degree programs or integrating AWS Educate curriculum as part of this initiative:

K-12 School Districts

• Fairfax County Public Schools
• Loudoun County Public Schools
• Alexandria City Public Schools
• Arlington Public Schools

Community Colleges

• Northern Virginia Community College
• J. Sargeant Reynolds Community College
• John Tyler Community College
• Thomas Nelson Community College
• Blue Ridge Community College
• Patrick Henry Community College
• Dabney S. Lancaster Community College
• Tidewater Community College
• New River Community College
• Lord Fairfax Community College

Four-Year Universities

• George Mason University
• Virginia Polytechnic Institute and State University (Virginia Tech)
• Virginia Commonwealth University
• Old Dominion University
• Hampton University
• Virginia State University

AWS Educate: A Broader National and Global Initiative

The Virginia expansion is part of a much larger AWS effort. By the time of this announcement, AWS had partnered with over 2,400 educational organizations worldwide — spanning K-12 schools, two-year colleges, and universities. Active programs were already running in New York, Los Angeles, Dallas, and the state of Louisiana.

AWS Educate provides students and educators with access to cloud curriculum, hands-on labs, career pathways, and AWS credits, lowering the cost and friction of learning cloud skills without requiring students to have an AWS account in some tiers of the program.

Industry-Wide Trend: Tech Giants Investing in Alternative Credentials

AWS is not alone in this approach. Google, Microsoft, and Facebook have all launched or expanded their own credential and educational programs aimed at building technical talent pipelines. This reflects a broader industry recognition that traditional four-year computer science degrees alone cannot meet the pace of demand for cloud, data, and software engineering skills.

For DevOps and cloud engineering teams, this expansion of structured cloud computing education is a net positive — it signals a growing supply of candidates with foundational AWS knowledge and, increasingly, formal credentials to back it up.

Key Takeaways for the DevOps Community

• Hiring pipeline growth: Virginia’s cloud job postings quadrupled in three years, and academic programs are scaling to match.
• Credential standardization: AWS Educate provides a consistent curriculum baseline across diverse institutions.
• Pathway design: The NOVA-to-George Mason model demonstrates how two-year and four-year programs can be articulated into a continuous credential journey.
• Early talent development: K-12 integration means students can begin accumulating college credit before they graduate high school.
• Industry competition: AWS, Google, Microsoft, and Meta are all competing to shape the foundational skills of the next generation of cloud practitioners.

The Confidence Gap Is Real

According to a SolarWinds survey of technology professionals, 70% do not feel completely confident that they possess all the skills they will need to successfully manage their IT environments over the next three to five years. That statistic alone signals a systemic problem: the majority of the people responsible for running enterprise infrastructure are worried about being left behind by technological change.

A healthy degree of concern about skill obsolescence can be a motivator. But concern only creates value when it translates into action — and for a significant portion of IT professionals, it isn’t.

Most IT Pros Aren’t Actively Upskilling

A follow-up SolarWinds survey, Building Confidence for Tech Pros of Tomorrow, polled 177 technology professionals across both public and private sectors internationally in August 2019. Its findings are worth examining in detail:

• 60% of technology professionals had not actively pursued learning a new skill or completed a certification in the previous six months.
• Of those who did begin a certification program, roughly 50% did not finish.
• The primary reason for non-completion was lack of time.

The pattern is familiar: professionals recognize the need to learn, intend to act on it, but operational workloads consistently crowd out development time. This is not a motivation problem — it is a structural one.

How Enterprises Are Responding

Organizations are not ignoring the skills gap. Many are investing in internal development, though the approaches vary in effectiveness:

• 35% of respondents cited internal training programs as their organization’s primary mitigation strategy.
• 54% said full-day, in-person workshops provide the most value relative to time invested — suggesting that immersive, focused formats are preferred over fragmented online modules.

The preference for structured, dedicated learning time reinforces the core problem: IT professionals aren’t struggling to find learning resources, they’re struggling to carve out uninterrupted time to use them.

Soft Skills Are Now Table Stakes

Technical depth alone is no longer enough. The survey found that non-technical competencies are increasingly viewed as career-critical by technology professionals themselves:

• Project management — cited by 56% as critical for career growth
• Public speaking and presentations — cited by 52%
• Interpersonal communication — cited by 46% as the most critical skill overall

These findings align with a broader industry trend: as IT moves closer to the business, professionals who can translate technical complexity into business language become significantly more valuable. The ability to present findings, lead projects and communicate risk to non-technical stakeholders is no longer a soft differentiator — it is increasingly a hard requirement.

Confidence in Conversations, Not in Resources

One nuanced finding from the survey is worth highlighting: the majority of technology professionals reported feeling confident when speaking with business leaders, but they do not believe they have adequate support or tools to be effective in their roles.

The top two things respondents said they need to become confident managing current and future environments were:

• Increased budget and additional resources — cited by 64%
• More support from IT or business leadership — cited by 48%

This suggests a disconnect between communication ability and organizational enablement. IT professionals can articulate needs to leadership, but those needs are not consistently being met — which in turn constrains their ability to grow and perform.

Application Performance Management Skills Are in Growing Demand

As enterprises become more dependent on software to deliver business outcomes, proficiency in application performance management (APM) is becoming a baseline expectation rather than a specialist skill. Survey respondents indicated that application support, troubleshooting and monitoring are tasks they are increasingly responsible for — regardless of their formal job title.

Additionally, 53% of respondents identified user experience monitoring of applications as a skill they are required to develop. This reflects the shift in how IT success is measured: not just uptime and infrastructure health, but the quality of experience delivered to end users.

Key Takeaways for IT Leaders and Practitioners

• Time is the real barrier to upskilling — organizations that want to close the skills gap need to schedule protected learning time, not just provide resources.
• Immersive training formats outperform fragmented ones — full-day workshops score higher than self-paced modules alone, suggesting focused blocks of time are more effective.
• Soft skills are now core skills — project management, communication and presentation skills belong in any modern IT development plan.
• APM and UX monitoring are becoming baseline competencies — professionals who can monitor, troubleshoot and communicate application performance will be increasingly valuable.
• Resource constraints are limiting growth — leadership support and budget are the top factors IT professionals say they need; organizations that ignore this signal risk accelerating attrition.

Source: SolarWinds “Building Confidence for Tech Pros of Tomorrow” survey, August 2019, as reported by devops.com.

Despite the enterprise benefits assured by adopting a DevOps culture, the majority of IT leaders believe communication between IT security and software development must improve greatly to achieve success, a Trend Micro survey reveals.

DevOps implementation

Led by independent research specialist Vanson Bourne, the company surveyed the attitudes toward DevOps held by 1,310 IT decision makers from within both enterprise and SMB organizations across the globe.

Those surveyed are at various stages of the DevOps implementation as they integrate their teams, application development, information technology operations and security, to shorten and secure the development lifecycle.

While three-quarters (74%) claimed such initiatives had become more important over the past year, an even higher percentage argued that communication within the IT department needed to improve.

Some 89% said software development and IT security teams needed to be in closer contact, while 77% said the same for developers, security and operations. A third (34%) claimed that these siloes are making it harder to create a DevOps culture in the organization.

“History of software development shows that the biggest and best process improvements never happen quickly due to the most valuable variable, people, who have existing behavioral patterns and cultural components,” said Steve Quane, executive vice president of network defense and hybrid cloud security for Trend Micro.

“Organizations implementing a DevOps structure are going in a strong direction, but security cannot be forgotten during this transition.”

Respondents indicated the best ways to drive this cultural change include: fostering greater integration between teams (61%); setting common goals (58%); and sharing learning experiences across teams (50%). Yet over 78% of IT decision makers said improvement is needed in these areas.

Only a third (33%) of respondents said DevOps is a shared responsibility between software development and IT operations, which is another indication of the current communication breakdown between teams. It appears that each department feels responsibility or ownership to lead these projects.

Part of the challenge is believed to be — despite enthusiasm for DevOps, which has seen 81% of organizations already implement or currently work on projects — nearly half of respondents (46%) have only partially developed their DevOps strategy. IT leaders polled confirmed that enhancing IT security is more of a priority (46%) in DevOps than any other factor.

Quane continued by saying, “Regardless of where an organization is in their journey, there are new tools that bake security into the development process while automating rapid deployment of security at the same time as reducing risk and ensuring compliance.”

The Testing Progress We’ve Made — and the Gap We Haven’t Closed

Continuous integration (CI) and release automation (RA) have fundamentally changed how software teams approach quality assurance. By making testing both automated and integral to the development lifecycle, teams using CI alongside test-driven development (TDD) report improvements in deployment frequency and overall code quality. QA engineers and developers can focus on investigating problem areas rather than manually executing repetitive test suites.

However, security has not kept pace with this progress. In most organizations, security checks still feel like a speed bump inserted near the end of the release cycle rather than a continuous, automated concern woven throughout every phase of the pipeline.

Why Security Is Harder to Automate Than Functional Testing

There are two concrete reasons security automation lags behind functional test automation:

• Application-specific attack surfaces. Techniques such as application-level penetration testing are highly context-dependent. Tooling exists to assist — dynamic application security testing (DAST) scanners, static analysis (SAST) tools, and interactive tools (IAST) — but none of them eliminates the need for human judgment on custom application logic.
• Cultural perception. Security and compliance are still widely viewed as obstacles to deployment velocity rather than as quality dimensions equal in importance to functional correctness. This perception delays investment in security automation tooling and staffing.

The consequences of this gap are not hypothetical. High-profile breaches have been traced back to elementary vulnerabilities such as SQL injection — attacks that well-established automated scanning tools are capable of detecting before code ever reaches production. When security is excluded from the deployment pipeline, or when the security team lacks influence over release decisions, these preventable vulnerabilities ship.

What Automated Security Testing Can Cover

Automated tooling already addresses a meaningful portion of the common attack-vector landscape. Areas where automation delivers consistent value include:

• Injection vulnerabilities (SQL injection, command injection) — detectable by DAST and SAST tools during both build and deploy phases.
• Dependency and library vulnerabilities — software composition analysis (SCA) tools can flag known CVEs in third-party packages as part of any CI build.
• Infrastructure configuration drift — cloud security posture management (CSPM) tools can validate the deployment environment against a security baseline at the time of each deployment, reducing reliance on individual team members having deep cloud-security expertise.
• Secrets and credential exposure — static scanning tools can catch hardcoded credentials before they reach version control or artifact registries.
• Compliance policy enforcement — policy-as-code frameworks allow security controls to be expressed in code, version-controlled, and automatically evaluated against every environment change.

Interestingly, automated tools flagging a list of vulnerabilities tends to be received better by development teams than the same list delivered by a human security reviewer. The medium matters: an automated gate in a pipeline feels like a quality constraint rather than an interpersonal conflict.

Integrating Security Across Every Phase of the DevOps Lifecycle

Because the attack surface of a modern application spans code, dependencies, configuration, infrastructure, and runtime behavior, security cannot be a single gate at the end of the pipeline. It must be present — at some level — at every phase:

• Plan/Design: Threat modeling and security requirements defined alongside functional requirements.
• Code: SAST and secrets scanning integrated into the IDE and pre-commit hooks.
• Build: SCA for dependency vulnerabilities; SAST on the full codebase as part of the CI pipeline.
• Test: DAST scanning against a deployed test environment; IAST agents collecting runtime data during functional test execution.
• Deploy: Infrastructure configuration validation; policy-as-code checks against the target cloud environment.
• Operate/Monitor: Runtime threat detection, log analysis, and alerting on anomalous behavior.

Standardized Controls Bridge the Skills Gap

One of the most underappreciated benefits of security automation is its role in addressing skills shortages. Cloud environments expose a large and constantly changing set of security configuration options. Rather than requiring every engineer to have deep expertise in every cloud security feature, automated tooling can validate that a deployment environment meets a defined baseline before traffic ever reaches it.

This is analogous to how infrastructure-as-code tools allow operations teams to provision complex environments rapidly while learning configuration details incrementally. Security automation provides the same leverage to security teams: codify the controls, automate the validation, and use the time saved to deepen expertise where it matters most.

The practical recommendation is to build standardized security controls into both the test environment and the deployment environment. Perfect automation is not the goal — meaningful automation is. Even partial coverage of the vulnerability surface raises the overall security posture of the business, and since breaches represent direct business risk, that improvement is squarely aligned with the business value DevOps aims to deliver.

The Role of the Security Team in a Highly Automated Pipeline

A small security team cannot manually review every build, every pull request, and every deployment in a modern high-velocity engineering organization. Automation does not eliminate the security team — it changes their role. In a mature DevSecOps model, security engineers function primarily as:

• Internal consultants and trainers to development, test, and operations functions.
• Authors and maintainers of security policy as code — the rules that automated gates enforce.
• Reviewers of complex, application-specific risks that tools cannot yet evaluate reliably (custom business logic, novel attack patterns, architectural decisions).

The cultural shift required here parallels the shift development teams made when adopting agile, and the shift development and operations teams made when adopting DevOps. Security processes should not simply be mapped onto old workflows — they should be re-examined against the goal of securing the application and rebuilt using the most efficient methods available. Then, like everything else in engineering, iterated on continuously.

Key Takeaways

• Automated functional testing has matured significantly; security testing automation is catching up but still requires human augmentation for application-specific risks.
• Automated security tooling (SAST, DAST, SCA, CSPM, policy-as-code) can already address a wide range of common vulnerabilities if integrated into the CI/CD pipeline.
• Security must be present at every phase of the DevOps lifecycle, not only at release gates.
• Standardized, automated controls reduce both the employee time burden and the skills gap associated with security coverage.
• The security team’s role evolves toward consulting, training, and policy authorship — not manual review of every artifact.
• The goal is not perfect automation today; it is measurably better security posture through whatever automation is achievable now, improved iteratively over time.