Coder Legion - Recent posts tagged cloudcomputing

Amazon Drops NDAs on Data Center Deals Amid AI Backlash

Mon, 12 Oct 2026 11:29:09 +0000

Background: The Growing AI Data‑Center Controversy

The AI boom has turned data centers into the new frontier of public debate. Cities such as San Francisco and New York have enacted moratoriums that pause permits for large‑scale facilities. San Francisco’s recent ordinance bans new data‑center construction outright, while New York’s one‑year pause is tied to an unfinished environmental review. Historically, these moratoriums last 1–2 years, yet the engineering pipeline for a modern AI‑focused data center spans 2–5 years—from site acquisition to commissioning. This timing mismatch creates a perception that developers can “wait out” community opposition, fueling resentment.

Community concerns are concrete: property‑value depreciation, higher residential electricity rates, and amplified water consumption for cooling. The backlash is amplified by a series of high‑profile media stories that portray AI infrastructure as a secretive, profit‑driven behemoth. As a result, local activists have organized town halls, filed lawsuits, and leveraged social media to pressure municipalities into stricter oversight.

Why NDAs Became a Flashpoint

Non‑disclosure agreements (NDAs) have long been a tool for corporations to protect proprietary information during negotiations. In the context of data‑center deals, NDAs effectively shielded the terms of tax incentives, land‑use concessions, and utility agreements from public scrutiny. Critics argue that this secrecy prevents residents from understanding the true cost‑benefit balance of hosting AI‑intensive facilities in their neighborhoods.

The practice is not new. Uber, during the mid‑2010s, famously used secretive negotiations to lock in tax subsidies that later sparked public outrage when the details emerged. Tesla’s vague “sustainable/amazing abundance” mission statement has similarly been accused of glossing over the environmental footprint of its megafactories. The pattern—high‑value incentives negotiated behind closed doors—has eroded trust and given rise to the “secret‑deal” narrative that now dominates headlines.

Amazon and Microsoft’s Policy Shift

In early October 2026, Microsoft announced it would no longer require NDAs when negotiating data‑center projects with local governments. Amazon followed suit a week later, stating that it would conduct all future negotiations openly, without confidentiality clauses. The companies framed the move as a “commitment to transparency” and an effort to “re‑establish a constructive dialogue with the communities that host our infrastructure.”

Sean O’Kane, a TechCrunch contributor, summed up the sentiment:

“We’ve seen, through a lot of the controversy and backlash to AI and data centers, that the industry just does a really poor job explaining itself, and that they are obviously and constantly frustrated with the fact that most people can’t envision a world in which this stuff is useful for them.”

Rebecca Bellan added a note of cautious optimism:

“I’m curious about what effect this will have and whether it will lead to communities successfully delaying or killing any infrastructure that the companies need to build.”

By removing NDAs, Amazon and Microsoft aim to make the negotiation process visible on public record, allowing journalists, watchdog groups, and ordinary citizens to assess the trade‑offs. The policy change also aligns with broader corporate ESG (Environmental, Social, Governance) goals, where transparency is a measurable KPI.

Technical and Community Implications

Community Benefits

Public Oversight: With agreements filed openly, city councils can scrutinize incentive packages and demand stricter environmental safeguards.
Informed Consent: Residents gain access to data on projected electricity draw, water usage, and noise levels, enabling more meaningful participation in zoning hearings.
Economic Clarity: Transparent terms help local businesses understand whether a data‑center will spur ancillary services (e.g., logistics, construction) or merely siphon resources.

Technical Considerations

Energy Mix Disclosure: AI workloads are power‑hungry. Open contracts now often require providers to disclose the proportion of renewable versus fossil‑fuel electricity, prompting investments in on‑site solar or battery storage.
Cooling Innovations: Water‑intensive cooling systems must be justified. Some developers are turning to liquid‑submersion or evaporative‑free cooling, which can be documented in public filings.
Latency & Edge Strategy: To mitigate community impact, firms are deploying edge nodes—smaller, lower‑power facilities—closer to end users. These nodes can be approved more quickly and generate less local strain.

The shift also influences the industry’s communication strategy. Historically, AI firms relied on press releases and selective media outreach. The new openness forces a “direct‑to‑public” approach, where technical whitepapers, community webinars, and open‑source dashboards become essential tools for narrative control.

Future Outlook and Policy Landscape

Potential Regulatory Ripple Effects

State‑Level Legislation: If the transparency experiment proves successful, other states may codify “no‑NDA” requirements for any large‑scale tech infrastructure project.
Federal Guidance: The Federal Energy Regulatory Commission (FERC) could issue guidelines linking incentive eligibility to public disclosure standards, creating a de‑facto national baseline.
International Echoes: European Union data‑center regulations already emphasize environmental reporting; the U.S. move may accelerate trans‑Atlantic alignment on transparency.

Industry Response Scenarios

Full Adoption: Major cloud providers (Google, Meta) follow suit, leading to a standardized public‑record framework. This could reduce community opposition and shorten permitting timelines.
Partial Resistance: Some firms retain NDAs for proprietary technology clauses, prompting a hybrid model where financial terms are public but technical details remain confidential.
Backlash Reversal: If disclosed incentives are perceived as overly generous, political pressure could force stricter caps on tax breaks, potentially raising the cost of AI expansion.

The Role of Tech Events

The upcoming TechCrunch Disrupt 2026 (October 13‑15, San Francisco) will feature panels on AI infrastructure, with a special focus on community engagement. The event’s deadline for exhibitors was October 2, and a 50 % discount on a second pass encourages partners to bring colleagues for deeper discussions. Attendees will likely hear first‑hand accounts from city planners, ESG analysts, and the very executives who announced the NDA‑free policy.

For readers interested in the broader AI‑security context, recent coverage of AI‑driven exploits—such as the Zoom annotation flaw patched after an AI‑prompt attack—highlights how transparency can also improve security posture. See the detailed analysis in the TechCrunch post “Zoom Annotation Flaw Patched After AI‑Prompt Exploit”. A related zero‑day incident, documented in “Zoom Zero‑Day Exploit: Remote Takeover of iPhone & Mac”, underscores the importance of open disclosure for rapid mitigation.

FAQ

Q: What exactly is an NDA in the context of data‑center negotiations?
A: An NDA (non‑disclosure agreement) is a legal contract that prohibits the parties from sharing specific details of the negotiation—typically financial incentives, land‑use terms, or proprietary technology plans.

Read the full breakdown originally published at https://ltdeveloperblogs.github.io/posts/can-the-ai-industry-persuade-data-center-opponents-by-getting-rid-of-ndas/

Infrastructure as Code with AWS CloudFormation

Wed, 09 Sep 2026 07:23:07 +0000

By the end of this guide, you will not just know what CloudFormation does. You will understand why each feature exists, what problem it solves, what breaks without it, and how features chain together to solve real infrastructure problems. Every concept is introduced with a problem first, not a definition first.

What is CloudFormation and Why It Matters
Logical and Physical Resources
Templates: Portable vs Non-Portable
Template Parameters and Pseudo Parameters
Intrinsic Functions
Mappings
Outputs
Conditions
DependsOn
Wait Conditions and cfn-signal
cfn-init
cfn-hup
Nested Stacks
Cross-Stack References

What is CloudFormation and Why It Matters

The Problem It Solves

Imagine you are building a three-tier web application. You need a VPC, subnets, an EC2 instance, a security group, an RDS database, an S3 bucket, and a load balancer. You click through the AWS Console and get it working. Three weeks later, a colleague asks you to replicate the exact environment for staging. You click through everything again. Two hours later, something is different you missed a security group rule, the subnet CIDR is wrong, and the RDS instance has a different parameter group.

This is the core problem. Manual infrastructure is not repeatable, not auditable, and not scalable.

CloudFormation is AWS's answer. You describe your infrastructure in a template a YAML or JSON file and CloudFormation takes that description and builds the real AWS resources. The template becomes the single source of truth.

What CloudFormation Actually Is

CloudFormation is a declarative infrastructure provisioning engine. You declare what you want, not how to create it. CloudFormation figures out the how, including the order in which resources must be created, the dependencies between them, and what to clean up if something fails.

Why It Matters Beyond Convenience

Repeatability The same template deployed ten times produces ten identical environments.
Version control Your infrastructure lives in Git. Every change is tracked. Every rollback is a git revert.
Accountability Who changed the security group? Check the commit history.
Speed A 40-resource stack that takes two hours to click through manually deploys in minutes.
Disaster recovery When a region fails, you re-deploy the template in another region. Your infrastructure is code, not memory.
Cost Stacks can be deleted entirely after use. Temporary environments cost nothing when they are gone.

CloudFormation is not just a tool. It is a practice the practice of treating infrastructure with the same discipline as application code.

Logical and Physical Resources

The Concept

This is the foundation. If you misunderstand this, everything else will be confusing.

A logical resource is what you write in the template. It is a declaration a name you give to a resource and a description of what you want.

A physical resource is what AWS actually creates when CloudFormation processes your template. It has a real ID an instance ID, a bucket name, a security group ID.

The Relationship

When you write this:

Resources:
  MyWebServer:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: ami-0c55b159cbfafe1f0

MyWebServer is the logical resource. The actual EC2 instance that gets created say i-0a1b2c3d4e5f6 is the physical resource.

The logical resource exists only in your template. The physical resource exists in AWS.

Why This Distinction Matters

CloudFormation tracks the mapping between logical and physical resources in something called the stack. This mapping is what enables CloudFormation to:

Update a resource when you change the template
Replace a resource when a change requires replacement
Delete all physical resources when you delete the stack

If you manually delete a physical resource that CloudFormation manages, the stack loses track of it. On the next update or delete, CloudFormation will fail or behave unpredictably because the physical resource it expects to find is gone.

Rule: Never manually modify a physical resource that is managed by a CloudFormation stack. Make the change in the template instead.

What Happens During Stack Creation

CloudFormation reads your template.
It builds a dependency graph of all logical resources.
It creates physical resources in the correct order.
It maps each logical resource to its new physical resource.
The stack reaches CREATE_COMPLETE.

If any resource creation fails, CloudFormation rolls back it deletes everything it already created and the stack reaches ROLLBACK_COMPLETE. Nothing is left half-built.

Templates: Portable vs Non-Portable

The Problem with Non-Portable Templates

Here is a simple template:

AWSTemplateFormatVersion: "2010-09-09"
Description: Simple EC2 instance

Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: ami-0c55b159cbfafe1f0
      SubnetId: subnet-0abc1234

This works. Once. In one region. For one person.

The ImageId is an AMI ID. AMI IDs are region-specific. ami-0c55b159cbfafe1f0 in us-east-1 is not the same image in eu-west-1 in fact, it probably does not exist there at all. The SubnetId is hardcoded to a specific subnet in a specific AWS account.

If you or anyone else tries to deploy this template in a different region or a different account, it will fail.

This is a non-portable template. It has hardcoded values that only work in one specific context.

What Would Happen If You Ran It

In your account, same region: Works.
In your account, different region: Fails. AMI ID does not exist.
In a colleague's account: Fails. Subnet ID does not exist.
In a CI/CD pipeline targeting staging: Fails. Both IDs are wrong.

The Solution: Portable Templates

A portable template contains no hardcoded environment-specific values. Instead, it accepts inputs, references dynamic values, and uses lookup mechanisms to resolve environment-specific details at deploy time.

The tools that enable portability are:

Parameters Inputs you provide at deploy time
Pseudo Parameters Values AWS provides automatically (account ID, region, etc.)
Intrinsic Functions Functions that resolve values dynamically
Mappings Lookup tables built into the template

The portable version of the above template:

AWSTemplateFormatVersion: "2010-09-09"
Description: Portable EC2 instance

Parameters:
  SubnetId:
    Type: AWS::EC2::Subnet::Id
    Description: The subnet to launch the instance into

Mappings:
  RegionAMIMap:
    us-east-1:
      AMI: ami-0c55b159cbfafe1f0
    eu-west-1:
      AMI: ami-0d71ea30463e0ff49

Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: !FindInMap [RegionAMIMap, !Ref AWS::Region, AMI]
      SubnetId: !Ref SubnetId

Now this template works in any region that is in the map, and in any account. The subnet is provided at deploy time. The AMI is looked up based on which region you are deploying to.

This is the difference between a template you write once and a template you write once and use everywhere.

Template Parameters and Pseudo Parameters

Template Parameters

Parameters make your template an interface. Instead of hardcoding values, you expose inputs that the person deploying the template or an automation system provides at deploy time.

Parameters:
  EnvironmentName:
    Type: String
    Default: development
    AllowedValues:
      - development
      - staging
      - production
    Description: The environment this stack is being deployed to

  InstanceType:
    Type: String
    Default: t3.micro
    AllowedValues:
      - t3.micro
      - t3.small
      - t3.medium
    Description: EC2 instance type

  DBPassword:
    Type: String
    NoEcho: true
    MinLength: 8
    MaxLength: 32
    Description: Database password will not be displayed

Key parameter types:

Type	What It Validates
`String`	Any string
`Number`	Numeric value
`AWS::EC2::Subnet::Id`	Must be a valid subnet ID in your account
`AWS::EC2::KeyPair::KeyName`	Must be a valid key pair name
`AWS::SSM::Parameter::Value<String>`	Pulls value from Systems Manager Parameter Store

The NoEcho: true property is important. It prevents the value from being displayed in the Console or CLI output. Use it for passwords and secrets. Note: it is not encryption. The value is still stored in the stack. Do not use it for genuinely sensitive production secrets use Secrets Manager or SSM SecureString instead.

To reference a parameter inside the template:

Properties:
  InstanceType: !Ref InstanceType

!Ref on a parameter returns its value. That is it. Simple.

Pseudo Parameters

Pseudo parameters are values that AWS provides automatically. You do not declare them. They are always available.

Pseudo Parameter	What It Returns
`AWS::AccountId`	Your 12-digit AWS account ID
`AWS::Region`	The region being deployed to, e.g. `eu-west-1`
`AWS::StackName`	The name of the current stack
`AWS::StackId`	The full ARN of the stack
`AWS::NoValue`	Used to conditionally remove a property
`AWS::Partition`	`aws`, `aws-cn`, or `aws-us-gov`
`AWS::URLSuffix`	`amazonaws.com` or region-specific suffix

Usage example:

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "myapp-${AWS::AccountId}-${AWS::Region}-logs"

This creates a bucket name like myapp-123456789012-eu-west-1-logs. Because account IDs and regions are globally unique, this bucket name will never collide with anyone else's, and the same template deployed to multiple regions will always produce a unique bucket name.

AWS::NoValue is used when you want to conditionally exclude a property:

Properties:
  DBSnapshotIdentifier: !If [IsProduction, !Ref SnapshotId, !Ref AWS::NoValue]

If the condition IsProduction is false, the property is completely removed from the resource definition. AWS sees it as if you never wrote it.

Intrinsic Functions

What They Are

Intrinsic functions are built-in functions that CloudFormation evaluates when it processes your template. They let you compute values, reference other resources, join strings, look up mappings, and make decisions all at deploy time.

You cannot use them in every part of a template. They work in the Properties section of resources, in Outputs, and in Metadata. They do not work in the Parameters section.

The Core Functions

!Ref

Returns the value of a parameter or the default identifier of a resource.

# On a parameter: returns the parameter value
InstanceType: !Ref InstanceTypeParam

# On a resource: returns the resource's primary identifier
SubnetId: !Ref MySubnet   # Returns the Subnet ID of MySubnet

What !Ref returns depends on the resource type. For an EC2 instance it returns the instance ID. For an S3 bucket it returns the bucket name. For a security group it returns the group ID. Always check the CloudFormation documentation for what !Ref returns for each resource type.

!GetAtt

Returns a specific attribute of a resource not just the primary identifier.

# Get the ARN of a Lambda function
FunctionArn: !GetAtt MyLambdaFunction.Arn

# Get the DNS name of a load balancer
LoadBalancerDNS: !GetAtt MyALB.DNSName

# Get the ARN of an IAM role
RoleArn: !GetAtt MyRole.Arn

!GetAtt is how you wire resources together. You create a load balancer and then pass its DNS name to your Route 53 record. You create an IAM role and pass its ARN to a Lambda function.

!Sub

Substitutes variables into a string. The most readable way to build dynamic strings.

# Simple substitution with pseudo parameters
BucketName: !Sub "myapp-${AWS::AccountId}-${AWS::Region}"

# Substitution with logical resource references
Description: !Sub "This is the ${EnvironmentName} environment stack"

# Substitution with explicit variable map
Command: !Sub
  - "aws s3 cp s3://${BucketName}/config.json /etc/myapp/config.json"
  - BucketName: !Ref MyBucket

!Sub is cleaner than !Join for most string-building tasks. Use it by default and only reach for !Join when you are working with lists.

!Join

Joins a list of values with a delimiter.

# Join with no delimiter
PolicyArn: !Join ["", ["arn:aws:iam::", !Ref AWS::AccountId, ":root"]]

# Join with comma delimiter
AllowedOrigins: !Join [",", [!Ref Domain1, !Ref Domain2]]

!Select

Returns a single value from a list by index.

# Get the first availability zone in the region
AvailabilityZone: !Select [0, !GetAZs ""]

# Get the second
AvailabilityZone: !Select [1, !GetAZs ""]

!GetAZs returns all availability zones in a region. !Select picks one. This combination is used constantly when creating subnets across AZs.

!FindInMap

Looks up a value in a Mapping (covered in the next section).

ImageId: !FindInMap [RegionAMIMap, !Ref AWS::Region, AMI]

!If

Returns one of two values based on a condition.

InstanceType: !If [IsProduction, m5.xlarge, t3.micro]

!And, !Or, !Not, !Equals

Logical operators used when defining conditions.

Conditions:
  IsProductionAndEU: !And
    - !Condition IsProduction
    - !Equals [!Ref AWS::Region, "eu-west-1"]

!ImportValue

Imports a value exported by another stack. This is how Cross-Stack References work — covered in detail in section 14.

VpcId: !ImportValue SharedInfra-VpcId

How Functions Compose

The power comes from nesting. Functions can be composed:

SecurityGroupId: !Select
  - 0
  - !Split [",", !ImportValue SharedInfra-SecurityGroupIds]

Here: import a comma-separated string of security group IDs from another stack, split it into a list, then select the first one. Three functions, one clean result.

This is not just syntax. It is the way CloudFormation templates become self-describing infrastructure documents that adapt to context.

Mappings

What They Are

Mappings are lookup tables built into your template. They let you define a set of key-value pairs and then look up a value at deploy time based on known context like which region you are deploying to, or which environment was selected.

Structure

Mappings:
  RegionAMIMap:
    us-east-1:
      AMI: ami-0c55b159cbfafe1f0
      BastionAMI: ami-0a887e401f7654935
    eu-west-1:
      AMI: ami-0d71ea30463e0ff49
      BastionAMI: ami-08d658f84a6d84a80
    ap-southeast-1:
      AMI: ami-01f7527546b557442
      BastionAMI: ami-0c5199d385b432989

  EnvironmentConfig:
    development:
      InstanceType: t3.micro
      MultiAZ: false
      DeletionProtection: false
    production:
      InstanceType: m5.large
      MultiAZ: true
      DeletionProtection: true

Usage

Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !FindInMap [RegionAMIMap, !Ref AWS::Region, AMI]
      InstanceType: !FindInMap [EnvironmentConfig, !Ref EnvironmentName, InstanceType]

!FindInMap takes three arguments: the map name, the top-level key, and the second-level key. It returns the value at that intersection.

Limitations

Mappings are static. They are baked into the template at write time. You cannot populate them dynamically at deploy time, and you cannot look up values in external systems like SSM Parameter Store.

This means:

When an AMI is updated, you must update the mapping manually and redeploy.
You cannot have a different mapping value per account without writing account IDs into the template.

For dynamic lookups, the solution is SSM Parameter Store with AWS::SSM::Parameter::Value<String> parameter types, or Custom Resources (covered in section 19). The AWS-managed AMI parameter store path (/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64) is the standard way to always get the latest Amazon Linux AMI without hardcoding AMI IDs at all.

Outputs

What They Are

Outputs are values that CloudFormation makes available after a stack is created or updated. They serve two purposes:

Visibility Display useful information about what was created (endpoint URLs, resource IDs, ARNs).
Cross-Stack References Export a value so other stacks can import it.

Structure

Outputs:
  WebServerPublicIP:
    Description: Public IP address of the web server
    Value: !GetAtt MyWebServer.PublicIp

  LoadBalancerDNS:
    Description: DNS name for the application load balancer
    Value: !GetAtt MyALB.DNSName

  VpcId:
    Description: VPC ID for use by other stacks
    Value: !Ref MyVPC
    Export:
      Name: !Sub "${AWS::StackName}-VpcId"

When to Use Export

Only add Export when you intend for another stack to reference the value. Not every output needs to be exported. Exports create a dependency you cannot delete the exporting stack while any other stack is consuming its exports.

What Would Happen Without Outputs

Without outputs, you would need to go into the AWS Console or run CLI commands to find the DNS name of your load balancer, the ID of your VPC, or the ARN of your IAM role. Outputs surface these values automatically after deployment, making them available to operators, pipelines, and other stacks.

In a CI/CD pipeline:

# After CloudFormation deploy, grab the load balancer URL
ALB_URL=$(aws cloudformation describe-stacks \
  --stack-name my-app \
  --query "Stacks[0].Outputs[?OutputKey=='LoadBalancerDNS'].OutputValue" \
  --output text)

# Use it to run integration tests
curl -f "http://$ALB_URL/health"

Outputs make your stack queryable. This is essential for automated pipelines.

Conditions

The Problem

You want one template that can deploy to both development and production, but the production environment needs a Multi-AZ RDS instance and an additional NAT Gateway, while development needs neither. Without conditions, you need two templates. With conditions, you need one.

Structure

Conditions are defined in the Conditions section and referenced in resources.

Parameters:
  EnvironmentName:
    Type: String
    AllowedValues: [development, production]

Conditions:
  IsProduction: !Equals [!Ref EnvironmentName, production]
  IsNotProduction: !Not [!Condition IsProduction]

Resources:
  PrimaryDatabase:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceClass: !If [IsProduction, db.m5.large, db.t3.micro]
      MultiAZ: !If [IsProduction, true, false]
      DeletionProtection: !If [IsProduction, true, false]

  NATGateway:
    Type: AWS::EC2::NatGateway
    Condition: IsProduction
    Properties:
      SubnetId: !Ref PublicSubnet
      AllocationId: !GetAtt ElasticIP.AllocationId

The Condition: IsProduction on NATGateway means: only create this resource if IsProduction is true. The !If inside PrimaryDatabase means: use different property values depending on the condition.

Condition Operators

Conditions:
  IsProduction: !Equals [!Ref Env, production]
  IsUS: !Equals [!Ref AWS::Region, us-east-1]
  
  # Both must be true
  IsProductionUS: !And
    - !Condition IsProduction
    - !Condition IsUS

  # Either must be true
  IsProductionOrUS: !Or
    - !Condition IsProduction
    - !Condition IsUS

  # Invert
  IsNotProduction: !Not [!Condition IsProduction]

Limitation

Conditions are evaluated at deploy time. They cannot change during stack execution. You cannot create a condition that says "if resource X was successfully created, then create resource Y" that is what DependsOn and WaitConditions handle.

DependsOn

The Problem

CloudFormation builds resources in parallel where possible. It determines the order automatically by following !Ref and !GetAtt references if resource B references resource A, CloudFormation knows to create A first.

But sometimes resource B does not reference resource A in its properties, yet it still needs A to exist before it can be created or function correctly. CloudFormation does not know about this implicit dependency, so it might try to create both simultaneously, and B fails because A is not ready.

The Solution

DependsOn explicitly tells CloudFormation: do not start creating this resource until that resource is complete.

Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16

  InternetGateway:
    Type: AWS::EC2::InternetGateway

  VPCGatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref MyVPC
      InternetGatewayId: !Ref InternetGateway

  PublicSubnet:
    Type: AWS::EC2::Subnet
    DependsOn: VPCGatewayAttachment
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: 10.0.1.0/24

Here, PublicSubnet references MyVPC via !Ref, so CloudFormation knows it must wait for the VPC. But the subnet does not reference VPCGatewayAttachment in its properties. Without DependsOn, CloudFormation might create the subnet before the gateway is attached, and routing will not work correctly.

A More Common Use Case — RDS and EC2

Resources:
  Database:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceClass: db.t3.micro
      Engine: mysql

  AppServer:
    Type: AWS::EC2::Instance
    DependsOn: Database
    Properties:
      UserData: !Base64
        !Sub |
          #!/bin/bash
          echo "DB_HOST=${Database.Endpoint.Address}" >> /etc/app/config

The AppServer does reference Database via !Sub, which creates an implicit dependency. But DependsOn is also good practice here you want the database to be fully ready before the application server boots and tries to connect.

What Happens Without It

Without DependsOn where it is needed, resources are created in the wrong order. The stack may still reach CREATE_COMPLETE but your application may fail at runtime because the dependency was not ready when the dependent resource was configured.

Limitation

DependsOn only tells CloudFormation to wait until the resource creation is complete. It does not tell CloudFormation to wait until the resource is ready to serve traffic or until a process inside the resource has finished running. For that, you need Wait Conditions and cfn-signal.

Wait Conditions and cfn-signal

The Problem That DependsOn Cannot Solve

CloudFormation considers an EC2 instance "created" the moment the API call to launch it succeeds. From CloudFormation's perspective, the resource is done. But the instance has not finished booting. The operating system is still starting. Your bootstrap script the one that installs your application, configures the web server, and starts your process is still running.

If a second resource depends on the application being ready, DependsOn is not enough. CloudFormation will proceed the moment the EC2 API reports success, not when your application is actually ready.

The Solution: cfn-signal and WaitConditions

cfn-signal is a script that runs inside your EC2 instance and sends a signal back to CloudFormation: "I am done and I succeeded" or "I am done and I failed."

A WaitCondition is a CloudFormation resource that pauses the stack and waits for a specific number of signals before proceeding.

Together, they let you tell CloudFormation: "Wait until the bootstrap process inside the instance has finished before you continue creating other resources."

How It Works. Step by Step

You create an EC2 instance with a UserData script that runs your bootstrap logic.
At the end of the script, you call cfn-signal to send a success or failure signal.
CloudFormation sees the signal and either continues or fails the stack.

The Code

Resources:
  WaitHandle:
    Type: AWS::CloudFormation::WaitConditionHandle

  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !FindInMap [RegionAMIMap, !Ref AWS::Region, AMI]
      InstanceType: t3.micro
      UserData:
        !Base64
          !Sub |
            #!/bin/bash -xe
            # Install and configure application
            yum update -y
            yum install -y httpd
            systemctl start httpd
            systemctl enable httpd
            echo "<h1>Hello from ${AWS::StackName}</h1>" > /var/www/html/index.html
            
            # Signal CloudFormation that bootstrap is complete
            /opt/aws/bin/cfn-signal -e $? \
              --stack ${AWS::StackName} \
              --resource WebServerWaitCondition \
              --region ${AWS::Region}

  WebServerWaitCondition:
    Type: AWS::CloudFormation::WaitCondition
    DependsOn: WebServer
    Properties:
      Handle: !Ref WaitHandle
      Timeout: 600
      Count: 1

-e $? passes the exit code of the last command. If the script ran successfully, $? is 0 CloudFormation receives a success signal. If the script failed, $? is non-zero CloudFormation receives a failure signal, fails the wait condition, and rolls back the stack.

What Happens Without cfn-signal

Without signalling, CloudFormation marks the EC2 instance as CREATE_COMPLETE the moment the API call succeeds typically within 10-15 seconds. Any resource that depends on the instance being fully configured will attempt to use it before it is ready. Load balancer health checks will fail. Downstream resources will misconfigure. Your application stack reaches CREATE_COMPLETE in a broken state.

This is the most common cause of "CloudFormation says it worked but the application is not working" problems.

Timeout

The Timeout is in seconds. 600 means CloudFormation will wait up to 10 minutes for the signal. If no signal arrives, the stack times out and rolls back. Size this based on how long your bootstrap realistically takes, with a comfortable buffer.

Limitation

cfn-signal handles the moment of creation well. But what about ongoing configuration? What if you need to update the instance configuration after the stack is deployed, or re-apply configuration if it drifts? For that, you need cfn-init.

CloudFormation Init (cfn-init)

The Problem with UserData

UserData is a blunt instrument. It is a script that runs once at instance launch and that is it. If you update the CloudFormation template and the instance is not replaced, UserData does not re-run. If the configuration drifts someone manually changes a file on the instance there is no way for CloudFormation to detect or correct it.

Also, UserData is imperative: you write step-by-step instructions. The result depends entirely on the starting state of the machine. If any step fails partway through, you have a half-configured instance with no clean way to recover.

The Solution: cfn-init

cfn-init is a declarative configuration engine built into the CloudFormation helper tools. Instead of writing scripts that say "run these commands," you declare the desired state: "these packages should be installed, these files should exist with this content, these services should be running."

Configuration is written in the Metadata section of the resource using the AWS::CloudFormation::Init key.

Structure

Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Metadata:
      AWS::CloudFormation::Init:
        config:
          packages:
            yum:
              httpd: []
              php: []

          files:
            /var/www/html/index.php:
              content: !Sub |
                <?php
                echo "<h1>Environment: ${EnvironmentName}</h1>";
                echo "<p>Stack: ${AWS::StackName}</p>";
                ?>
              mode: "000644"
              owner: apache
              group: apache

            /etc/httpd/conf.d/myapp.conf:
              content: |
                <VirtualHost *:80>
                    DocumentRoot /var/www/html
                    DirectoryIndex index.php
                </VirtualHost>
              mode: "000644"
              owner: root
              group: root

          services:
            sysvinit:
              httpd:
                enabled: true
                ensureRunning: true
                files:
                  - /etc/httpd/conf.d/myapp.conf
                packages:
                  yum:
                    - httpd

    Properties:
      ImageId: !FindInMap [RegionAMIMap, !Ref AWS::Region, AMI]
      InstanceType: t3.micro
      UserData:
        !Base64
          !Sub |
            #!/bin/bash -xe
            # Run cfn-init to apply the configuration
            /opt/aws/bin/cfn-init -v \
              --stack ${AWS::StackName} \
              --resource WebServer \
              --region ${AWS::Region}
            
            # Signal success or failure
            /opt/aws/bin/cfn-signal -e $? \
              --stack ${AWS::StackName} \
              --resource WebServerWaitCondition \
              --region ${AWS::Region}

  WebServerWaitCondition:
    Type: AWS::CloudFormation::WaitCondition
    DependsOn: WebServer
    Properties:
      Handle: !Ref WaitHandle
      Timeout: 600
      Count: 1

  WaitHandle:
    Type: AWS::CloudFormation::WaitConditionHandle

The Four cfn-init Keys

Key	What It Does
`packages`	Installs system packages via yum, apt, rpm, or other package managers
`files`	Creates files with specific content, permissions, and ownership
`commands`	Runs shell commands in a specific order with optional test conditions
`services`	Ensures services are started, enabled, and restarted when dependencies change

configSets Ordering Multiple Configurations

When you have complex configuration that needs to run in phases, use configSets:

Metadata:
  AWS::CloudFormation::Init:
    configSets:
      full_install:
        - install_cfn
        - install_base
        - install_app
        - configure_app

    install_cfn:
      files:
        /etc/cfn/cfn-hup.conf:
          content: !Sub |
            [main]
            stack=${AWS::StackId}
            region=${AWS::Region}
          mode: "000400"
          owner: root
          group: root

    install_base:
      packages:
        yum:
          httpd: []
          php: []
          php-mysqlnd: []

    install_app:
      files:
        /var/www/html/index.php:
          content: !Sub |
            <?php phpinfo(); ?>
          mode: "000644"
          owner: apache
          group: apache

    configure_app:
      services:
        sysvinit:
          httpd:
            enabled: true
            ensureRunning: true

Then in UserData, reference the configSet:

/opt/aws/bin/cfn-init -v \
  --stack ${AWS::StackName} \
  --resource WebServer \
  --configsets full_install \
  --region ${AWS::Region}

What Happens Without cfn-init

Without cfn-init, you rely entirely on UserData scripts. These are harder to maintain, harder to debug, and run only once at launch. Configuration drift is invisible, and updating configuration requires replacing the instance. cfn-init makes your instance configuration as declarative and auditable as your infrastructure definition.

Limitation

cfn-init applies configuration at launch. It does not continuously monitor or re-apply configuration when the template changes, unless the instance is replaced. For tracking template changes and re-applying configuration without replacing instances, you need cfn-hup.

cfn-hup

The Problem cfn-init Alone Cannot Solve

You update your CloudFormation template specifically, you change the content of a configuration file managed by cfn-init. You run aws cloudformation update-stack. CloudFormation processes the update.

If the EC2 instance is not being replaced (because the change does not require replacement only a metadata change), CloudFormation will not re-run cfn-init. The instance keeps running with the old configuration. The update completes, the stack reaches UPDATE_COMPLETE, and your configuration is silently out of date.

The Solution: cfn-hup

cfn-hup is a daemon that runs on the instance and polls the CloudFormation stack for changes to the resource's metadata. When it detects a change, it re-runs cfn-init to apply the updated configuration.

This gives you the ability to update instance configuration through CloudFormation without replacing the instance.

How to Set It Up

cfn-hup requires two configuration files on the instance, typically created via cfn-init itself:

Metadata:
  AWS::CloudFormation::Init:
    configSets:
      full_install:
        - install_cfn
        - install_app

    install_cfn:
      files:
        /etc/cfn/cfn-hup.conf:
          content: !Sub |
            [main]
            stack=${AWS::StackId}
            region=${AWS::Region}
            interval=5
          mode: "000400"
          owner: root
          group: root

        /etc/cfn/hooks.d/cfn-auto-reloader.conf:
          content: !Sub |
            [cfn-auto-reloader-hook]
            triggers=post.update
            path=Resources.WebServer.Metadata.AWS::CloudFormation::Init
            action=/opt/aws/bin/cfn-init -v \
              --stack ${AWS::StackName} \
              --resource WebServer \
              --configsets full_install \
              --region ${AWS::Region}
            runas=root
          mode: "000400"
          owner: root
          group: root

      services:
        sysvinit:
          cfn-hup:
            enabled: true
            ensureRunning: true
            files:
              - /etc/cfn/cfn-hup.conf
              - /etc/cfn/hooks.d/cfn-auto-reloader.conf

How It Works

cfn-hup.conf tells cfn-hup which stack to watch and how often to poll (every 5 minutes in this example).

cfn-auto-reloader.conf tells cfn-hup what to do when it detects a change: watch the Metadata.AWS::CloudFormation::Init path of the WebServer resource, and when it changes, re-run cfn-init with the full configSet.

When you update the template — change a file, add a package, modify a service — cfn-hup detects the metadata change within the poll interval and re-applies the full configuration to the running instance.

The Complete Pattern

cfn-init, cfn-signal, and cfn-hup form a complete configuration management pattern:

cfn-init applies configuration at launch
cfn-signal tells CloudFormation that configuration is complete
cfn-hup keeps configuration in sync with the template over time

Together, they turn your EC2 instances into configuration-as-code managed infrastructure that stays synchronized with your CloudFormation templates without requiring replacement.

Nested Stacks

The Problem with Single Large Stacks

A CloudFormation stack has a hard limit of 500 resources. But the real problem appears well before that limit.

A template with 80+ resources becomes difficult to read, difficult to test, and difficult to reason about. Changes to one part of the template require updating and deploying the entire thing. Teams working on different parts of the infrastructure step on each other. Re-using patterns across projects is impossible because everything is in one monolithic file.

This is the same problem that led software engineers to adopt functions, modules, and packages. The solution is the same: decomposition.

The Solution — Nested Stacks

A nested stack is a CloudFormation resource of type AWS::CloudFormation::Stack. It references another CloudFormation template stored in S3 and deploys it as a child stack. The parent stack manages the lifecycle of its child stacks.

Resources:
  NetworkStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.amazonaws.com/mybucket/templates/network.yaml
      Parameters:
        EnvironmentName: !Ref EnvironmentName
        VpcCidr: 10.0.0.0/16
      TimeoutInMinutes: 20

  AppStack:
    Type: AWS::CloudFormation::Stack
    DependsOn: NetworkStack
    Properties:
      TemplateURL: https://s3.amazonaws.com/mybucket/templates/app.yaml
      Parameters:
        EnvironmentName: !Ref EnvironmentName
        VpcId: !GetAtt NetworkStack.Outputs.VpcId
        SubnetIds: !GetAtt NetworkStack.Outputs.SubnetIds
      TimeoutInMinutes: 30

  DatabaseStack:
    Type: AWS::CloudFormation::Stack
    DependsOn: NetworkStack
    Properties:
      TemplateURL: https://s3.amazonaws.com/mybucket/templates/database.yaml
      Parameters:
        SubnetIds: !GetAtt NetworkStack.Outputs.SubnetIds
        DBPassword: !Ref DBPassword

The parent template is thin it orchestrates the child stacks and passes data between them via outputs and parameters. Each child template is a focused, independently testable unit.

Passing Data Between Nested Stacks

Notice !GetAtt NetworkStack.Outputs.VpcId. This is how you pass data from one nested stack to another:

The network.yaml template has an Outputs section that exports VpcId.
The parent references it via !GetAtt NetworkStack.Outputs.VpcId.
The parent passes it as a parameter to AppStack.

# network.yaml Outputs section
Outputs:
  VpcId:
    Value: !Ref MyVPC
  SubnetIds:
    Value: !Join [",", [!Ref SubnetA, !Ref SubnetB]]

What Would Happen Without Nested Stacks

All resources live in one template. It grows. Team members modify the same file. Changes to the network layer require touching the application template. Testing one component requires deploying everything. The template becomes the infrastructure equivalent of a 5,000-line monolithic application technically functional but practically unmaintainable.

Limitation

Nested stacks solve the organization and size problem within a single deployment. They do not solve the problem of sharing infrastructure across multiple independent teams or projects. If Team A creates a VPC that Team B also needs, nested stacks are not the right tool Cross-Stack References are.

Cross-Stack References

The Problem Nested Stacks Do Not Solve

Nested stacks keep related resources together. But what about shared infrastructure that multiple independent stacks need to reference?

Your networking team creates a VPC stack: VPC, subnets, route tables, NAT gateways. This is the foundation. Three separate application teams each deploy their own stacks that need to run inside that VPC.

With nested stacks, the networking stack would need to be the parent of all three application stacks. That creates an artificial coupling the networking team owns the deployment of all application stacks. This does not reflect how real teams work.

The right model is: the networking stack exists independently, exports its values, and each application stack imports what it needs.

The Solution: Exports and ImportValue

A stack can export named values. Any other stack in the same region and account can import those values.

Exporting stack (networking stack):

Naming Convention

Export names must be unique within a region and account. The convention StackName-ResourceName is standard. You can also use !Sub with pseudo parameters for uniqueness:

Export:
  Name: !Sub "${AWS::StackName}-VpcId"

Putting It All Together.

Every feature in CloudFormation exists because there was a real problem that could not be solved without it. Here is how they connect:

None of these features are optional in a serious production environment. Each one closes a gap that, without it, requires manual intervention, custom scripting, or accepted risk.

Written by Onyedikachi Obidiegwu | Cloud Security Engineer

AWS Is Betting $500M That Students Will Learn Cloud By Building. The Payoff Is Still Unproven.

Fri, 21 Aug 2026 00:04:25 +0000

Every few years, a major cloud provider makes a play for the next generation of developers. AWS tried it before with AWS Educate, a dedicated academic program that eventually shut down. This week, the company is trying again, with more money and a different theory of what went wrong the first time.

AWS announced a commitment of more than $500 million in resources aimed at university students worldwide, delivered through a new Student Rewards program inside AWS Builder Center. Verified students can earn up to $579 in value: a year of premium AWS Skill Builder access (a $449 value covering 900-plus courses and hands-on labs), $30 in AWS Credits, and a foundational certification exam voucher worth $100. I asked Rick Suttles, Senior Manager, Product & Engineering for Builder Experience at AWS, to walk through what's actually new here, and where the open questions still sit.

What AWS says it learned from Educate

The most telling answer in the whole exchange is the one about the program AWS already tried and abandoned. "Educate was a separate, siloed experience," Suttles said. Student Rewards, by contrast, lives inside AWS Builder Center, the same community working developers already use. Students build alongside professionals, using the same tools, in the same space, rather than in a walled-off academic sandbox. AWS also cut the application process students previously had to clear. Now it's straightforward: verify enrollment, start building.

Whether that structural change actually produces better outcomes than Educate did is impossible to know yet. But it's a specific, testable claim, not a case of AWS simply doing the same thing again with a bigger number attached.

The credential doesn't expire, but AWS won't promise a job

Suttles was clear that whatever a student earns during the 12 months, certifications and completed projects, stays theirs after the program access ends. That's a real, concrete commitment. What AWS wouldn't commit to is what happens after: renewal paths beyond the first year are still being worked out, and Suttles said the company will share more "as we learn how students are using the resources."

The bigger gap is on outcomes. Asked directly whether AWS has data on how many students who complete the certification path actually land cloud or AI roles, Suttles didn't have numbers to share, since this cohort is just getting underway. Asked what number AWS would point to a year from now as proof the program worked, he named "students building things" as the leading indicator, with certifications as a secondary signal, on the theory that career outcomes follow from real project work rather than credentials alone. It's a reasonable bet, but it's a bet. There's no employer commitment on record treating this specific credential as a guaranteed hiring signal beyond the general observation that AWS certifications are already recognized in the industry.

Worth being straightforward about that gap: this is a brand-new program, and AWS not having placement data yet is expected, not damning. But it does mean the actual return on time invested is still an open question for any student deciding whether to commit to it.

Global access, with the exclusions spelled out plainly

On equity, the answers were more concrete. Eligibility isn't tiered by institution type. Community colleges and technical schools get the same access as research universities, and no prior AWS relationship is required. AWS also pointed to more than 1,000 existing Student Builder Groups spanning over 60 countries, many at schools outside the research-university tier, with the option for students to start a new group if their campus doesn't have one.

Internationally, Suttles said the reward value is identical everywhere verification is available, which currently excludes only sanctioned regions, with China, Hong Kong, and Taiwan verification coming soon. That's a cleaner answer than most global tech benefit programs manage to give, where regional pricing or partial access is often buried in fine print.

The single-vendor question, answered directly

The most obvious criticism of any vendor-run student program is that it trains people to use one company's tools rather than teaching transferable skills. Suttles didn't dodge it: his argument is that cloud fundamentals, distributed architecture, infrastructure as code, AI services, transfer across environments regardless of which vendor's console a student learned them in first. That's a defensible position, though it's also exactly what every cloud vendor running a program like this would say. Worth judging for yourself once you see what the coursework actually covers.

On that front, the AI-specific material isn't just cloud fundamentals with a new label. Skill Builder includes dedicated courses on generative AI, prompt engineering, and model training, alongside services like Amazon Bedrock and Amazon SageMaker, on top of the standard networking, security, compute, and storage curriculum.

A wrinkle worth noting: the content requirement

Part of how students unlock the full reward value is by publishing technical content, project write-ups and tutorials, on Builder Center and engaging with the broader community. Suttles framed this as reinforcing a student's own learning while building a public portfolio and a network of fellow builders. It's also, functionally, a way for AWS to generate a steady stream of community-authored technical content at essentially no cost, which isn't a criticism so much as worth naming plainly for what it is.

What this actually means if you're deciding whether it's worth a student's time

The structural changes from Educate are real and specific enough to take seriously: integration into a live professional community, no application gate, global parity, no institutional gatekeeping. The open question is whether "students building things" as a success metric actually translates into the career outcomes AWS is implicitly promising. Right now, that's a bet AWS is asking students to take alongside them, backed by real resources but not yet by real placement data.

The Tale of Docker the Magic Whale

Sun, 05 Apr 2026 20:04:04 +0000

A Story About Packing Toys Perfectly ✨

Before Kuberlandia... The Big Problem

Remember the Kingdom of Kuberlandia from before? ✨

Well, before the wizard could manage all the toys, there was a Big Mess! ️
Imagine you built an amazing Lego castle on your table .

It worked perfectly on your table! ✅
But when you moved it to your friend's table... CRASH!
The pieces didn't fit! The colors were wrong! ❌
This was called: "But it works on my machine!" ️

Computers were all different, and apps kept breaking when they moved.

Chapter 1: Enter Docker the Whale! ✨

One day, a friendly Magic Whale named Docker arrived!
He said:

"Don't worry! I have a special way to pack your toys so they NEVER break, no matter where they go!" ️️

Docker invented Magic Shipping Containers ✨.

Chapter 2: The Magic Photo (Image) ️

Docker taught everyone about Images.

An Image is like a perfect photo or a frozen blueprint ️ of your toy.
It captures the toy , the batteries , the instructions , and even the air around it!
Once you take the photo, it never changes. It is safe!

Lesson: A Docker Image is a read-only template that contains everything your app needs!*

Chapter 3: The Living Box (Container)

But a photo isn't fun to play with... you need the real toy!

When you use the Image to make a real, running toy, it becomes a Container!
You can make one image... and turn it into many containers! 1️⃣➡️
Each container is like a clone of the photo, but alive and playing! ♂️

Lesson: A Container is a running instance of an Image!*

Chapter 4: The Recipe Card (Dockerfile)

How does Docker know what to put in the box?

You write a special Recipe Card called a Dockerfile! ✍️

It looks like this:

 Step 1: Get a blank box 
 Step 2: Put in Python language 
 Step 3: Add my Game Code 
 Step 4: Tell it to start playing! ▶️

Docker reads this card and POOF! It builds your Image automatically! ️✨

Chapter 5: The Big Library (Docker Hub)

What if you don't want to build a toy from scratch?
You can visit the Big Library called Docker Hub! ️

It's like a toy store where people share their Images.
Need a database? ️ Grab one!
Need a web server? Grab one!
You can download them and start playing instantly! ⬇️

Lesson: Docker Hub is a cloud registry where people share Docker Images!*

Chapter 6: Docker & The Wizard (Kubernetes) ♂️

Remember Kube-Master from Kuberlandia? ♂️

He and Docker are Best Friends!

Docker's Job: Pack the toys safely so they don't break.
Kubernetes' Job: Manage the playgrounds so there's always room for the toys.

Docker builds the containers.
Kubernetes organizes the containers.

They work together to make sure the whole world can play!

The Happy Ending

Thanks to Docker the Whale:

✅ Toys work everywhere (Laptop, Cloud, Server)! ☁️️
✅ No more "It works on my machine" tears! ➡️
✅ Building apps is as easy as following a recipe!
✅ Friends can share toys easily!

Quick Recap for Little Engineers:

Remember, little builder: Docker is like a magic suitcase that packs your computer program with everything it needs, so it can travel anywhere in the world without getting lost or broken! ✈️

Swim safely with Docker! *

Next stop: Kuberlandia to manage all those containers! ♂️

The Magical Kingdom of Kuberlandia

Wed, 01 Apr 2026 20:32:13 +0000

A Kubernetes Story for Little Explorers ✨

Once Upon a Time...

In a faraway digital land called Kuberlandia, there lived a wise wizard named Kube-Master ♂️✨. His job was to make sure all the toy applications ran happily and never got lost!

Chapter 1: The Magic Toy Boxes (Containers)

Every toy in Kuberlandia lived in a Magic Toy Box ✨.

Each box had everything the toy needed: snacks , blankets ️, and instructions
These boxes were called Containers (like Docker the friendly whale!)
No matter where the box traveled, the toy inside was always happy!

Lesson: Containers keep apps safe and portable!*

Chapter 2: Cozy Little Houses (Pods) ️

Sometimes, toys liked to have roommates!

The wizard put 1 or more Magic Toy Boxes into a Cozy Little House called a Pod
Pods were the smallest homes in Kuberlandia
Friends in the same Pod could share toys and talk easily! ️

Lesson: Pods are the smallest units that hold one or more containers!*

Chapter 3: The Big Playground (Nodes)

All the Cozy Houses lived on big, strong Playgrounds called Nodes

Each Node had energy (CPU) ⚡, memory (RAM) , and space (Storage) ️
Some playgrounds were big, some were small — but all were important!

Lesson: Nodes are the computers (servers) that run your pods!*

Chapter 4: The Grand Kingdom (Cluster)

All the playgrounds together made the Grand Kingdom of Kuberlandia — also called a Cluster! ✨

The wizard could add more playgrounds whenever more toys arrived! ➕
If one playground needed a nap , the toys just moved to another!

Lesson: A cluster is a group of nodes working together!*

Chapter 5: The Helpful Helpers ✨

The wizard had magical friends to help run the kingdom:

Chapter 6: The Magic Spells (Kubernetes Features)

Self-Healing Magic ✨

If a toy got sleepy and fell over , the wizard's spell would automatically wake up a new one!
"Don't worry, little toy — we've got you!"

Scaling Spell (More Fun!)

When lots of kids wanted to play , the wizard could cast:

✨ "Make 5 more toy houses!" ✨

And POOF! More Pods appeared to keep everyone happy!

Rolling Updates (New Toys!)

When a toy got a cool new outfit ✨, the wizard updated them one-by-one — so playtime never stopped!

️ Service: The Friendly Name Tag

Instead of remembering complicated addresses ️, toys just called each other by friendly names:

"Hey, GameServer! Can I join?" ♂️

The Service magic made sure they always found each other!

Chapter 7: The Wizard's Recipe Book (YAML) ✍️

The wizard wrote all his wishes in a special recipe book using YAML scrolls ✨:

 Toy: SuperFunGame
 Boxes: 1
 Houses: 3 copies (just in case!)
 Playground: Any with extra energy! ⚡
✨ Magic: If one falls, make a new one!

Lesson: YAML files tell Kubernetes what you want it to do!*

The Happy Ending

Thanks to Kuberlandia's magic:

✅ Toys never get lost ️
✅ Parties grow automatically when friends arrive ➕
✅ Broken toys are replaced like magic!
✅ Everyone plays happily ever after!

Quick Recap for Little Geniuses:

Remember, little explorer: Kubernetes is like a magical kingdom that helps computer toys play together, stay safe, and have endless fun — all by themselves! ✨*

Now you know the secret of Kuberlandia! ️

The End... or just the beginning of your cloud adventure! ️️

Larry Ellison reveals why Oracle built a power plant to train AI - and what it means for developers.

Wed, 15 Oct 2025 00:20:30 +0000

Oracle's AI Vision: From 1.2 Billion Watts to Saving Lives

Oracle AI World delivered a message developers need to hear: AI isn't about replacing engineers. It's about building tools that solve humanity's hardest problems while making developers dramatically more productive.

The Infrastructure Reality

Larry Ellison opened with a stunning statistic: Oracle is building AI data centers consuming 1.2 billion watts of power. That's enough electricity to power a million four-bedroom homes.

The scale is staggering. Oracle's Abilene, Texas facility will house 450,000 NVIDIA GB200 GPUs when fully provisioned. The project started as empty land in June 2024 and began delivering GPUs in less than a year.

But here's what matters for developers: Oracle isn't just building infrastructure for infrastructure's sake. They're training more multimodal AI models than any other company - models that developers will use to solve real problems.

The Database + AI Integration

Ellison made a critical point that other cloud providers miss: publicly available training data isn't enough. AI models need access to private enterprise data to reach peak value.

Much of the world's high-value data already sits in Oracle databases. Oracle's strategy: make that private data accessible to AI models while keeping it secure and private.

The Oracle AI Database uses Retrieval-Augmented Generation (RAG) to vectorize any data - whether in Oracle databases, OCI object store, or even Amazon S3 - making it accessible for AI reasoning without exposing it to other customers.

For developers, this means:

No need to copy sensitive data to train models
AI can reason across both public and private data
Security boundaries remain intact
Models stay current with real-time data

Code Generation That Actually Works

Oracle's approach to AI code generation differs from competitors in one crucial way: every generated application is stateless, secure, and scalable by default.

Using Oracle APEX with AI generation, applications automatically include:

Zero security holes (the generator doesn't forget things)
Built-in reliability (stateless design means automatic failover)
Unlimited scalability (designed for millions of users from day one)
No single point of failure

Ellison noted that 80% of Oracle employees report AI has already improved their work quality. Internally, Oracle uses AI for:

Touchless expense automation
Invoice matching
AI-driven recruiting
Deal progression in sales
Real-time supply chain alerts

The productivity gains are enabling Oracle to rebuild Cerner's entire codebase, a quarter-century of healthcare software, using AI generation. All clinic operating code is already complete, with acute hospital systems planned for next year.

Real-World AI Agents

The keynotes showcased AI agents solving complex real-world problems, not toy demos.

Healthcare: Provider to Payer Integration

Oracle built an AI agent that solves a problem every healthcare provider faces: prescribe the best possible care that's fully reimbursable.

The agent:

Uses RAG to access latest medical literature and patient test results
Assists doctors in determining optimal care
Checks insurance policies to ensure full reimbursement
Handles exceptions (like UK NHS covering Ozempic only above certain BMI thresholds)
Provides banks with reimbursement data to extend credit to cash-strapped hospitals

This single agent addresses clinical care, insurance complexity, and hospital financing simultaneously - automating the entire healthcare ecosystem, not just the hospital.

Biofine Technologies: Fighting Antibiotic Resistance

Paulo from Biofine Technologies described using Oracle's vector database to save lives in Brazil.

Traditional bacterial testing takes five days. Biofine's solution:

Extracts bacterial DNA from patient samples
Creates vectors from millions of DNA elements
Uses Oracle's vector search across 700,000 bacterial DNA records
Identifies bacteria and antibiotic resistance in four hours

Results: mortality rates from bacterial infections dropped from 70% to 50%. Biofine expects to save 2,000 lives in Brazil in 2025 alone.

The vector approach handles bacterial mutations, finding close matches rather than requiring exact DNA sequences. This means identifying resistance patterns even for novel bacterial strains.

The Metagenomic Testing Vision

Ellison revealed work on a metagenomic testing device that could revolutionize pathogen detection.

Current PCR testing only works for known pathogens. If your test comes back negative, doctors simply don't know what you have.

The new device:

Sequences everything in a blood sample
Identifies any pathogen (bacteria, virus, fungus) even if novel
Detects circulating tumor DNA for early cancer diagnosis
Determines antibiotic resistance patterns
Costs low enough for widespread hospital deployment

For developers, this represents the power of AI-assisted genomic analysis. The device would have detected COVID-19 far earlier, providing pandemic early warning.

Ellison's point: if these devices existed in hospitals worldwide, we'd never be caught off guard by novel pathogens again.

Energy Sector Transformation

Calvin Butler from Exelon described managing one of America's largest electrical grids while embedding AI across operations.

The challenge: more transformation in the next 10 years than the previous 100 years. Every technology addition to the grid introduces security risks.

AI helps Exelon:

Predict outages before they happen
Communicate restoration times accurately
Manage preventive maintenance schedules
Optimize grid investments based on demand patterns

Butler emphasized that AI deployment isn't about reducing headcount - it's about capturing data and improving customer communication. The grid becomes smarter, not smaller.

Transportation: Avis Budget Group

Marius from Avis Budget Group explained why they jumped to Oracle Database 23ai despite being on a "highly deprecated version."

Their reasoning: if you're going to upgrade anyway, go to the version where Oracle is investing. The 23ai capabilities and roadmap aligned perfectly with Avis's business needs.

Using natural language queries, Avis employees become "problem solvers, not information gatherers." Instead of clicking through dashboards to slice and dice data, they ask questions directly and get answers immediately.

The goal: reduce the lag between observing a problem and taking action. AI gives back time - the most important commodity nobody controls.

Marius's metric for success: how quickly can you get to market with the right decisions? AI dramatically compresses that timeline.

Hospitality: Marriott's Human-First Approach

Ty from Marriott emphasized that AI isn't replacing human hospitality - it's enabling it.

The problem: checking someone into a Marriott property requires navigating dozens of systems. Front desk associates spend time on "swivel chair" data entry rather than engaging with guests.

Marriott's digital transformation creates a "single pane of glass" - unifying dozens of systems so associates can focus on people, not processes. Less time on keystrokes, more time sharing local recommendations and creating authentic connections.

The AI strategy started by asking associates: "What's the most painful part of your job?" Then deploying AI to fix those pain points. The result: contagious adoption as associates experience real improvements.

The Vector Database Breakthrough

Multiple speakers highlighted Oracle's vector database as the enabling technology.

For Biofine, vectors allow matching similar (not identical) bacterial DNA, handling mutations automatically.

For Marriott, vectors enable personalized guest recommendations based on preferences and history.

For Avis, vectors power natural language queries across complex operational data.

The pattern: vectorization makes unstructured data (DNA sequences, customer preferences, operational metrics) accessible for AI reasoning. Oracle's database handles the vectorization automatically for any data source.

Multimodal AI Architecture

Ellison explained that modern AI models mirror human brain structure, multiple neural networks handling different tasks:

Convolutional networks for vision (edges, color, motion)
Vision transformers for recognition
Large language models for reasoning
Specialized networks for mathematics

Like the brain's specialized regions (visual cortex, prefrontal lobe, language centers), AI models use specialized networks working together.

Oracle's infrastructure supports these multimodal models at scale - the 1.2 billion watts isn't excessive, it's necessary for reasoning at human (or superhuman) levels.

The Code Generation Philosophy

Oracle's code generation differs from competitors in approach. Rather than generating code directly from English (which Ellison calls "curiously imprecise"), Oracle created a declarative AI generation language in APEX.

The advantage: generated applications have consistent characteristics:

Stateless design (automatic failover)
Built-in security (no forgotten edge cases)
Designed for scale (millions of users)
Zero single points of failure

This matters because generated code becomes production code. If the generator produces brittle applications, you've automated technical debt creation.

Medical Devices and Robotics

Ellison revealed Oracle's work on medical robotics, arguing robots will be better surgeons than humans - not because they're smarter, but because they have better tools:

Microscopic vision (seeing individual cells without microscopes)
Perfect hand-eye coordination
Ability to cut between healthy and cancerous cell layers

For Mohs surgery (removing facial cancer lesions), robots can see exactly where cancer ends and healthy tissue begins, enabling more precise removal with better cosmetic results.

The implication for developers: AI-assisted medical devices represent a massive opportunity. The challenge isn't just training models - it's building reliable, safe systems where errors have life-or-death consequences.

The Greenhouse Vision

Ellison described Oracle's robotic greenhouses - buildings that are actually inflatable structures held up by positive air pressure.

The advantages:

90% less water than traditional farming
Grows food year-round
Locates near population centers (fresher food, lower CO2 transport)
No human contamination of growing areas
Robots move plants as they grow

For developers, this represents AI-orchestrated physical systems. The robots decide when to move plants, when to harvest, how to optimize growing conditions.

The same structure could serve as a Martian habitat - fold it up, transport it on a SpaceX rocket, inflate it on Mars. Ellison wasn't entirely joking about that possibility.

Climate Engineering with AI

Perhaps the most ambitious vision: using AI to engineer crops that manage atmospheric CO2.

Wheat modified by AI produces 20% more grain per acre while converting more CO2 into calcium carbonate (the mineral in coral reefs). The CO2 gets removed from the atmosphere permanently.

If deployed globally, modified wheat could reduce atmospheric CO2 from 440 parts per million to 400 - essentially managing the climate through enhanced photosynthesis.

The engineering challenge: designing plants that:

Produce more food
Consume more CO2
Convert CO2 to stable minerals
Maintain nutritional value

This isn't theoretical - Ellison's Wild Bio (part of Oxford's Ellison Institute) has already created wheat that produces 20% more grain per acre.

Autonomous Drones

Oracle built an air traffic control system for medical specimen delivery drones.

The system uses RFID tags to maintain chain of custody while protecting privacy - nobody knows whose blood sample is in transit, but the system ensures it reaches the right lab and results return to the right doctor.

Beyond medical delivery, the drones can:

Detect forest fires via infrared cameras
Identify arsonists who set fires
Follow suspects in police chases (safer than high-speed pursuits)
Search for lost hikers

For developers, this represents the challenge of building reliable autonomous systems operating in physical environments with safety implications.

What This Means for Developers

Oracle's AI World message: the infrastructure is ready. The models are trained. The database can vectorize your private data securely.

Now what are you going to build?

The examples from the keynotes show the pattern:

Identify a complex problem (antibiotic resistance, healthcare reimbursement, grid management)
Connect AI models to relevant private data via vector search
Build agents that orchestrate multi-step processes
Deploy at scale using Oracle's infrastructure

The competitive advantage won't come from having access to AI models - everyone will have that. It will come from:

Speed of implementation
Quality of private data integration
Sophistication of agent orchestration
Reliability of production deployment

Oracle's bet: developers who can connect AI models to real business data and build reliable agents will solve problems that were previously intractable.

The 1.2 billion watts of power isn't about showing off. It's about giving developers the computational foundation to build applications that change industries, save lives, and solve humanity's hardest problems.

That's the real AI revolution - not chatbots, but tools that let developers tackle challenges we couldn't solve before.

Hell Freezes Over: Oracle and AWS End Their Epic Feud

Tue, 08 Jul 2025 20:23:38 +0000

Oracle and AWS Just Shocked the Tech World by Becoming Partners

Here's why their database alliance changes everything.

The tech industry has witnessed numerous surprising partnerships over the years, but few have been as jaw-dropping as Oracle and Amazon Web Services' announcement of their strategic alliance. After more than 15 years of fierce competition, bitter public feuds, and aggressive poaching of each other's customers, these two giants have joined forces in a move that one industry analyst described as "hell hath frozen over."

The centerpiece of this unexpected partnership is Oracle Database@AWS, now generally available in AWS regions across Northern Virginia and Oregon, with plans to expand to 20 additional regions worldwide. This isn't just Oracle software running on AWS infrastructure; it's Oracle Cloud Infrastructure (OCI) physically deployed within AWS data centers, creating a hybrid solution that neither company could have achieved alone.

The Rivalry That Defined Cloud Computing

To understand the magnitude of this partnership, you need to appreciate the depth of the Oracle-AWS rivalry. For over a decade, these companies have been locked in a battle that went far beyond typical business competition. AWS aggressively promoted its own database services as alternatives to Oracle's flagship products, while Oracle positioned itself as the premium, enterprise-grade solution that AWS couldn't match.

The rivalry wasn't just corporate, it was deeply personal. Larry Ellison and Jeff Bezos have swapped places in the billionaire rankings and are often portrayed as business adversaries, each vying for dominance in the cloud and database markets. Oracle's marketing campaigns regularly targeted AWS's database offerings, while AWS made it increasingly easy for Oracle customers to migrate away from Oracle's ecosystem.

This competitive dynamic shaped the entire cloud database market. AWS built services like Amazon RDS and Aurora specifically to provide alternatives to Oracle Database, while Oracle doubled down on its cloud transformation to compete directly with AWS's infrastructure offerings. The result was a fractured market where customers often had to choose sides rather than leveraging the best of both platforms.

Why Now? The Perfect Storm of Market Forces

Several key factors converged to make this partnership not just possible but inevitable:

Customer Demand for Multicloud Flexibility: Modern enterprises increasingly refuse to be locked into a single cloud provider. Many large organizations have standardized AWS for their broader cloud infrastructure but rely heavily on Oracle databases for mission-critical applications. The complexity and risk of migrating these databases often kept companies from fully embracing cloud strategies.

Technical Innovation Breakthrough: Oracle Database@AWS represents a genuine technical achievement. Rather than simply running Oracle software on AWS hardware, this solution deploys OCI infrastructure within AWS data centers. This approach enables customers to leverage Oracle's advanced database features, including Real Application Clusters (RAC) and AI Vector Search capabilities, while remaining fully integrated with AWS's ecosystem.

The AI Revolution: The rapid growth of artificial intelligence and analytics workloads has significantly altered enterprise requirements. Companies want best-in-class solutions from multiple vendors, not just what's available from their primary cloud provider. Oracle's Database 23ai with embedded AI Vector capabilities combined with AWS's analytics and machine learning services creates possibilities that neither platform could offer independently.

Financial Reality: Both companies recognized that collaboration could unlock greater revenue opportunities than continued competition. Oracle's cloud and database revenues have surged, while AWS maintains its position as the dominant cloud provider. By joining forces, both can accelerate growth and capture a larger share of enterprise IT budgets.

The Technical Marvel Behind the Partnership

Oracle Database@AWS isn't just a marketing alliance; it's a sophisticated technical integration that addresses real enterprise pain points. The service includes zero-ETL (extract, transform, and load) integration, which eliminates the complex data pipelines that traditionally made it difficult to combine Oracle databases with AWS analytics services.

This integration enables seamless data flow between Oracle Database services and AWS services, allowing customers to combine their data with AWS analytics, machine learning, and generative AI services. For developers and data scientists, this means they can leverage Oracle's proven database reliability and performance while accessing AWS's cutting-edge AI and analytics tools.

The solution also supports familiar AWS management tools, including the AWS Management Console, Command Line Interface, and APIs. This means IT teams don't need to learn entirely new management paradigms; they can use the tools they already know while accessing Oracle's enterprise-grade database capabilities.

Early Adopters Are Already Seeing Results

Major enterprises are already embracing Oracle Database@AWS, with early adopters including Fidelity Investments, Nationwide, and SAS. These organizations cite improvements in operational efficiency and the ability to innovate faster while maintaining the enterprise-grade resilience their customers demand.

Fidelity Investments, managing critical applications that millions of customers depend on daily, highlighted how the partnership addresses the need for both cloud agility and performance. Nationwide emphasized how the solution aligns with their cloud strategy while maintaining the reliability their customers expect. SAS noted that the integrated capabilities provide their customers with high-performance access to applications and data within AWS.

What This Means for Developers and IT Leaders

For developers, this partnership opens up new architectural possibilities. You can now build scalable microservices-based applications using Amazon EC2, Amazon EKS, and Amazon ECS while leveraging Oracle Database features like AI Vector Search. This combination enables the development of more intelligent applications with a faster time-to-market for new features.

IT leaders gain the flexibility to pursue true multicloud strategies without the traditional complexity and risk. The unified support model from both Oracle and AWS simplifies database administration, purchasing, and deployment. Companies can also leverage existing AWS commitments and Oracle license benefits, including Bring Your Own License (BYOL) programs.

The partnership also supports major Oracle applications, including E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne, and Oracle Enterprise Performance Management, making it easier for organizations to modernize their entire Oracle stack within AWS.

The Future of Cloud Partnerships

This Oracle-AWS alliance signals a broader shift in the cloud industry. The "winner-takes-all" mentality that dominated the early cloud era is giving way to pragmatic partnerships that prioritize customer value over competitive positioning. As the cloud market matures, providers are recognizing that collaboration often serves customers and their interests better than isolation.

The partnership represents a milestone in what analysts are calling the "Multicloud Era," where enterprises expect seamless integration between best-of-breed services regardless of provider. This trend is likely to accelerate as AI and machine learning workloads become more sophisticated and demanding.

Looking Ahead

Oracle Database@AWS is currently available in AWS's Northern Virginia and Oregon regions, with expansion to 20 additional regions planned throughout 2025. This global rollout will make the integrated solution available to enterprises worldwide, potentially reshaping how organizations approach database and cloud strategy.

The partnership proves that even the fiercest rivals can become collaborators when customer needs and market opportunities align. For developers and IT leaders, it represents a new era of flexibility and possibility—one where you don't have to choose between Oracle's database excellence and AWS's cloud innovation.

The question now isn't whether other cloud providers will follow suit with similar partnerships but how quickly they can adapt to this new reality where customer value trumps vendor rivalry.

Coder Legion - Recent posts tagged cloudcomputing

Amazon Drops NDAs on Data Center Deals Amid AI Backlash

Background: The Growing AI Data‑Center Controversy

Why NDAs Became a Flashpoint

Amazon and Microsoft’s Policy Shift

Technical and Community Implications

Community Benefits

Technical Considerations

Future Outlook and Policy Landscape

Potential Regulatory Ripple Effects

Industry Response Scenarios

The Role of Tech Events

FAQ

Infrastructure as Code with AWS CloudFormation

Table of Contents

What is CloudFormation and Why It Matters

The Problem It Solves

What CloudFormation Actually Is

Why It Matters Beyond Convenience

Logical and Physical Resources

The Concept

The Relationship

Why This Distinction Matters

What Happens During Stack Creation

Templates: Portable vs Non-Portable

The Problem with Non-Portable Templates

What Would Happen If You Ran It

The Solution: Portable Templates

Template Parameters and Pseudo Parameters

Template Parameters

Pseudo Parameters

Intrinsic Functions

What They Are

The Core Functions

!Ref

!GetAtt

!Sub

!Join

!Select

!FindInMap

!If

!And, !Or, !Not, !Equals

!ImportValue

How Functions Compose

Mappings

What They Are

Structure

Usage

Limitations

Outputs

What They Are

Structure

When to Use Export

What Would Happen Without Outputs

Conditions

The Problem

Structure

Condition Operators

Limitation

DependsOn

The Problem

The Solution

A More Common Use Case — RDS and EC2

What Happens Without It

Limitation

Wait Conditions and cfn-signal

The Problem That DependsOn Cannot Solve

The Solution: cfn-signal and WaitConditions

How It Works. Step by Step

The Code

What Happens Without cfn-signal

Timeout

Limitation

CloudFormation Init (cfn-init)

The Problem with UserData

The Solution: cfn-init

Structure

The Four cfn-init Keys

configSets Ordering Multiple Configurations

What Happens Without cfn-init