DEV Community: Prakash Rao

x402 + MCP: where does the budget check go?

Prakash Rao — Sat, 26 Sep 2026 09:06:14 +0000

By Prakash Rao Bethapudi and Marco Gonzalez

An agent needs to enrich a customer record. The tool that does it costs money.

Nothing in x402 v2 says who is allowed to approve that. Nothing in MCP 2026-07-28 says it either. Both specs moved price and routing metadata into HTTP headers, which means your gateway can now see what a tool call costs. Seeing a price is not the same as having the authority to approve one.

We wrote about where that authority should sit in 402 Payment Required: What Enterprise MCP Servers Owe the Agents That Pay Them, with the Agentic AI Foundation. Then we took it to AGNTCon + MCPCon Japan in Tokyo and let an agent actually do it, live, on a test network.

If you missed either the post or the session, here is everything you need before we start.

First, the catch-up

What x402 is. HTTP has had a 402 Payment Required status code sitting unused since 1997, reserved but never specified. x402 finally gave it a meaning: a server answers 402 with the terms it wants, the client retries with a signed payment authorization, and the server returns the result plus evidence of settlement. v2 (December 2025) moved all of that into headers: PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE, instead of burying it in bodies.

What MCP is. The Model Context Protocol is how an AI agent discovers and calls tools. The 2026-07-28 revision removed sessions and the Mcp-Session-Id header, added Mcp-Method and Mcp-Name as headers, and hardened authorization with issuer validation per RFC 9207.

Why those two releases matter together. Both moved the interesting metadata out of request bodies and into headers. Your gateway, rate limiter and WAF can now see who is calling, which tool, and what it costs, without parsing a single JSON-RPC body. Metering and routing for paid agent traffic got dramatically cheaper.

And that is exactly where the problem starts. Header visibility is not authority. The moment your infrastructure can see the price, it has to decide something about it, and neither spec tells you who gets to make that call. That was the argument in our AAIF post: the spending decision belongs to a budget authority the agent cannot reach, and where you put it is the part that will still matter after the protocol details have moved on.

What we did in Tokyo. Stopped arguing and ran it: a live agent paying for MCP tool calls on a test network, including the path where it tries to spend on something it was not approved for.

The cast

Five moving parts appear throughout. You do not need to memorize these; they are here so the diagrams read cleanly.

Component	Its one job
Agent	Decides what work to do. Treated as hostile throughout. Holds no private key.
Enforcement gateway	The only permitted route out. Sees every request twice and can refuse at the boundary.
Authorization service	Decides whether spending is permitted, and reserves the budget. The agent cannot influence it.
Signing service	Produces signatures. Reads what it signs, and can refuse.
Protected resource	The tool that costs money, behind a paid server.

Our threat model, so you know what is and is not being defended: the agent process and every input to it are hostile. The gateway, the services and their policies are honest but fallible. Compromised binaries, malicious operators, key extraction from hardware and chain-level attacks are out of scope. Different problem, different post.

Now follow one request all the way through. It gets interesting about two-thirds of the way down, when the request that arrives at the boundary turns out not to be the request that was approved.

The agent goes shopping

Our agent has a task stated in business terms: enrich record 42. It does not know what that costs, and it does not know which provider will do it.

So the first problem is immediate: how do you let a hostile thing shop around, without handing it a wallet first?

It asks, and gets refused on purpose:

GET /tools/enrich?record=42 HTTP/1.1
Host: resource.example

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJ2IjoyLCJhY2NlcHRzIjpbey...

That header is base64 JSON. Decoded, it is an offer:

{
  "v": 2,
  "accepts": [{
    "scheme": "exact",
    "network": "<test-network>",
    "asset": "<stablecoin-contract>",
    "payTo": "<payee-address>",
    "maxAmountRequired": "<amount>",
    "resource": "https://resource.example/tools/enrich",
    "maxTimeoutSeconds": 60,
    "nonce": "<server-chosen>"
  }]
}

That is the HTTP binding. Over MCP the same negotiation happens, but not in the same place. Worth knowing before you meter anything at the edge:

	HTTP binding	MCP binding
Price challenge arrives as	`402` status + `PAYMENT-REQUIRED`	terms in the tool result
Routing metadata	the URL path	`Mcp-Method` / `Mcp-Name` headers
Visible to infra without parsing a body	yes	the challenge is not

The MCP binding hands your gateway a 200 for a call nobody has paid for yet. If your metering logic keys on status codes, it will sail straight past that.

Here is the first design decision that matters more than it looks. Asking is free.

If finding out what something costs itself costs money, then every agent needs spending authority before it can plan, which pushes the authorization decision to the least informed moment in the entire flow. Free discovery is what lets this first pass carry no authority to consume value at all. The boundary can admit it precisely because admitting it commits the organization to nothing.

And because this pass is cheap to allow, the boundary can do something quietly important while it is forwarding:

sequenceDiagram
    autonumber
    participant W as Agent
    participant G as Enforcement gateway
    participant R as Protected resource

    W->>G: candidate request, identity present,<br/>no authority to consume value
    G->>G: validate assertion, apply a lighter policy
    G->>G: audience translation: mint a downstream credential<br/>scoped to one resource and one action
    G->>R: forward, carrying only that credential
    R-->>G: resource-terms response, the quote
    G->>G: record the witnessed terms, from the return leg
    G-->>W: the quote

The gateway saw the quote itself, on the way back. Remember that. It becomes the whole game at the boundary.

Note also what crossed the boundary: not the enterprise credential, but a freshly minted one restricted to one resource and one action. Useful for nothing else. That is audience translation, and it is how you avoid handing a downstream service something it could turn around and reuse.

Someone has to approve it

Now the agent wants to actually do it. This is the moment the money becomes real, and the moment somebody other than the agent has to say yes.

Four decisions are tangled together here, and the useful move is to pull them apart and give each one an owner:

Decision	Who owns it
What work to do	the agent
Who is asking	identity provider, at the gateway
What it costs	the resource server, from the arguments
Whether it is permitted	a budget authority the agent cannot reach

That last row is the one people collapse, and collapsing it is how an agent ends up able to approve its own spending.

The authorization service does four things in order. Each one is load-bearing:

It fetches the quote from the gateway, never from the request. The agent is hostile; its claim about what it was offered is worthless. The boundary witnessed the real terms while the agent was shopping.

It filters on capability before it looks at price. Capability and compliance narrow the field first. A filter, not a ranking. No price advantage restores an excluded candidate. Get this backwards and you have a system that will happily route regulated data somewhere cheap.

It reserves the budget before any attempt is made, as one indivisible state transition. This is what stops concurrent agents sharing an allocation from collectively overspending it: the commitment is taken up front rather than discovered afterwards.

Then it binds the whole meaning of the action into one digest, and signs a receipt over it.

// authorization service
const fields  = deriveActionFields(proposal, witnessedTerms, selection);
const digest  = sha256(canonicalize(fields));   // RFC 8785 serialization

await reserveAtomically(allocation, ceiling);   // before any attempt

const receipt = signReceipt({
  decision: 'allow',
  digest,                                        // the binding
  policyVersion,
  expiresAt: now() + SHORT_TTL
});

One binding, over the whole meaning of the action. Alter any bound element and the digest differs.

The signer that can still say no

The agent has a receipt. It needs a signature. And here the architecture does something that surprises people:

The component that approved the action cannot sign it. The component that signs it can still refuse.

// policy-aware signing service
async function sign(request) {
  const payload = parseStructuredPayload(request);   // it can read what it signs
  const params  = recoverConsequentialParameters(payload);

  if (!withinOwnConstraints(params)) {
    return refuse('constraint_violation');           // even though the gate approved
  }
  return signWithNonExportableKey(payload);
}

A custody service that signs an opaque digest enforces nothing about meaning. Handed a blob, it has no basis on which to form an opinion at all. This one parses the payload first, recovers the parameters that actually matter, and applies its own constraints. It can refuse an action the authorization gate already approved.

Meanwhile the gate holds no key whatsoever. It is incapable of producing a signature. That is not a policy choice you can accidentally configure away. It is a property of who holds what.

There is a boring reason this split survives contact with a roadmap, and it persuades engineers faster than the security argument: the rules about what a key may be used for and the rules about what policy permits change at different rates, for different reasons, owned by different teams. Putting them in one component means every policy change touches the thing holding your keys. Nobody wants that.

And then it gets refused

The signed request heads for the exit. The receipt is valid. The signature verifies.

And the boundary refuses it.

sequenceDiagram
    autonumber
    participant W as Agent
    participant G as Enforcement gateway
    participant R as Protected resource

    W->>G: authorized request + valid receipt
    Note right of W: something changed after approval
    G->>G: re-derive the action from the bytes that will actually leave
    G->>G: recompute the digest
    G--xW: DENIED: mismatch, fail closed
    Note over G,R: nothing leaves

Here is why, and it is the single most important line in the whole design:

The gateway does not read the digest out of the receipt. It rebuilds it from the bytes that are actually leaving.

// enforcement gateway, egress path
async function release(outgoing, receipt) {
  if (!verifySignature(receipt)) return failClosed('bad_receipt');
  if (expired(receipt))          return failClosed('expired_receipt');

  // Re-derive from the request that will actually leave, not from the receipt.
  // RFC 8785 fixes the serialization; a normative rule both sides build
  // against fixes which fields participate.
  const rebuilt = canonicalize(deriveActionFields(outgoing));

  if (sha256(rebuilt) !== receipt.digest) {
    return failClosed('digest_mismatch');   // substituted, or altered after approval
  }

  // A valid receipt is necessary, not sufficient.
  const verdict = await policy.evaluate(deriveActionFields(outgoing));
  if (!verdict.allow) return failClosed(verdict.reason);

  return forward(translateAudience(outgoing));
}

Two independent opinions have to agree. One was formed at approval time, from the proposal; the other is formed here, from reality. Verifying a decision is not the same as verifying the thing the decision was about, and almost every system that gets this wrong gets it wrong right here.

Notice what a mismatch catches in both directions. Substituting to a more expensive resource is a budget failure. Substituting to a cheaper one can send regulated data somewhere not approved for it. Same mismatch, same refusal.

And notice failClosed on every path. Where required verification cannot be completed, the request is denied. A verifier that cannot answer is never treated as one that said yes.

Settling up

When a request does pass, the ending is deliberately unglamorous. The agent signs the value authorization but submits nothing; a facilitator submits it and bears the execution fee, so the workload needs no local balance of any kind, of any asset. Then one trace identifier binds the identity subject, the signing request, the nonce and the settlement record together, so a completed action can be reconstructed end to end from evidence held entirely outside the agent.

Neither direction requires trusting it. That is the point.

Here is the whole path, once, now that you know what each step is defending against:

sequenceDiagram
    autonumber
    participant W as Agent
    participant G as Enforcement gateway
    participant A as Authorization service
    participant S as Signing service
    participant R as Protected resource

    Note over W,R: DISCOVERY, no authority to spend
    W->>G: discovery pass, no authority to consume value
    G->>R: forward with a scoped downstream credential
    R-->>G: the quote
    G->>G: record the witnessed terms

    Note over W,R: AUTHORIZATION
    W->>A: request authorization
    A->>G: fetch witnessed terms, never from the request
    A->>A: capability filter, then cost
    A->>A: reserve atomically, before any attempt
    A-->>W: signed receipt, bound to the digest

    Note over W,R: SIGNING
    W->>S: request a signature
    S->>S: parse, recover parameters, enforce own constraints
    S-->>W: signature from a non-exportable key

    Note over W,R: EGRESS
    W->>G: authorized request + receipt
    G->>G: re-derive from outgoing bytes, recompute digest
    G->>G: independent policy re-evaluation
    G->>R: release, or refuse

What the stage taught us

Three things we did not fully appreciate until it was running in front of people.

The refusal is the demo. We prepared a success path and a denial path and rehearsed the success path harder. That was backwards. An authorization architecture is most convincing at the moment nothing happens. The receipt is valid, the signature is good, and the request still does not leave. If you demo one of these, budget your stage time for the refusal.

Canonicalization determinism is not a detail, it is the design. Two independent derivations only help if they agree. RFC 8785 fixes how to serialize; it does not fix which fields participate. Every ambiguity you leave in that question becomes a future incident that presents as a mysterious denial and resolves three layers away. Write the membership rule down as a normative artifact both sides build against, not as behaviour each side reimplements from prose.

Reachability is not authority. The agent in this flow calls the authorization service over an ordinary API, like any client. It simply cannot move its own limit. An agent that cannot reach the authorization service is isolated; an agent that reaches it and still cannot change the answer is governed. Those are very different systems and only one of them is useful.

Neither x402 v2 nor MCP 2026-07-28 makes the spending decision for you. They make the price visible and the routing cheap. Where the authority sits is still yours to place, and that placement will outlive both protocols.

The AAIF post has the full argument and the five obligations a paid tool server owes its callers.

Code is illustrative and abbreviated to the checks under discussion.

Patent pending. U.S. Provisional Application No. 64/149,249, filed 6 September 2026 (docket Y26S008-PPA)

x402 + MCP: where does the budget check go?

Prakash Rao — Fri, 25 Sep 2026 18:19:17 +0000

By Prakash Rao Bethapudi and Marco Gonzalez

An agent needs to enrich a customer record. The tool that does it costs money.

We wrote about where that authority should sit in 402 Payment Required: What Enterprise MCP Servers Owe the Agents That Pay Them, with the Agentic AI Foundation. Then we took it to AGNTCon + MCPCon Japan in Tokyo and let an agent actually do it, live, on a test network.

If you missed either the post or the session, here is everything you need before we start.

First, the catch-up

What we did in Tokyo. Stopped arguing and ran it: a live agent paying for MCP tool calls on a test network, including the path where it tries to spend on something it was not approved for.

The cast

Five moving parts appear throughout. You do not need to memorize these; they are here so the diagrams read cleanly.

Component	Its one job
Agent	Decides what work to do. Treated as hostile throughout. Holds no private key.
Enforcement gateway	The only permitted route out. Sees every request twice and can refuse at the boundary.
Authorization service	Decides whether spending is permitted, and reserves the budget. The agent cannot influence it.
Signing service	Produces signatures. Reads what it signs, and can refuse.
Protected resource	The tool that costs money, behind a paid server.

Now follow one request all the way through. It gets interesting about two-thirds of the way down, when the request that arrives at the boundary turns out not to be the request that was approved.

The agent goes shopping

Our agent has a task stated in business terms: enrich record 42. It does not know what that costs, and it does not know which provider will do it.

So the first problem is immediate: how do you let a hostile thing shop around, without handing it a wallet first?

It asks, and gets refused on purpose:

GET /tools/enrich?record=42 HTTP/1.1
Host: resource.example

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJ2IjoyLCJhY2NlcHRzIjpbey...

That header is base64 JSON. Decoded, it is an offer:

{
  "v": 2,
  "accepts": [{
    "scheme": "exact",
    "network": "<test-network>",
    "asset": "<stablecoin-contract>",
    "payTo": "<payee-address>",
    "maxAmountRequired": "<amount>",
    "resource": "https://resource.example/tools/enrich",
    "maxTimeoutSeconds": 60,
    "nonce": "<server-chosen>"
  }]
}

That is the HTTP binding. Over MCP the same negotiation happens, but not in the same place. Worth knowing before you meter anything at the edge:

	HTTP binding	MCP binding
Price challenge arrives as	`402` status + `PAYMENT-REQUIRED`	terms in the tool result
Routing metadata	the URL path	`Mcp-Method` / `Mcp-Name` headers
Visible to infra without parsing a body	yes	the challenge is not

The MCP binding hands your gateway a 200 for a call nobody has paid for yet. If your metering logic keys on status codes, it will sail straight past that.

Here is the first design decision that matters more than it looks. Asking is free.

And because this pass is cheap to allow, the boundary can do something quietly important while it is forwarding:

sequenceDiagram
    autonumber
    participant W as Agent
    participant G as Enforcement gateway
    participant R as Protected resource

    W->>G: candidate request, identity present,<br/>no authority to consume value
    G->>G: validate assertion, apply a lighter policy
    G->>G: audience translation: mint a downstream credential<br/>scoped to one resource and one action
    G->>R: forward, carrying only that credential
    R-->>G: resource-terms response, the quote
    G->>G: record the witnessed terms, from the return leg
    G-->>W: the quote

The gateway saw the quote itself, on the way back. Remember that. It becomes the whole game at the boundary.

Someone has to approve it

Now the agent wants to actually do it. This is the moment the money becomes real, and the moment somebody other than the agent has to say yes.

Four decisions are tangled together here, and the useful move is to pull them apart and give each one an owner:

Decision	Who owns it
What work to do	the agent
Who is asking	identity provider, at the gateway
What it costs	the resource server, from the arguments
Whether it is permitted	a budget authority the agent cannot reach

That last row is the one people collapse, and collapsing it is how an agent ends up able to approve its own spending.

The authorization service does four things in order. Each one is load-bearing:

Then it binds the whole meaning of the action into one digest, and signs a receipt over it.

// authorization service
const fields  = deriveActionFields(proposal, witnessedTerms, selection);
const digest  = sha256(canonicalize(fields));   // RFC 8785 serialization

await reserveAtomically(allocation, ceiling);   // before any attempt

const receipt = signReceipt({
  decision: 'allow',
  digest,                                        // the binding
  policyVersion,
  expiresAt: now() + SHORT_TTL
});

One binding, over the whole meaning of the action. Alter any bound element and the digest differs.

The signer that can still say no

The agent has a receipt. It needs a signature. And here the architecture does something that surprises people:

The component that approved the action cannot sign it. The component that signs it can still refuse.

// policy-aware signing service
async function sign(request) {
  const payload = parseStructuredPayload(request);   // it can read what it signs
  const params  = recoverConsequentialParameters(payload);

  if (!withinOwnConstraints(params)) {
    return refuse('constraint_violation');           // even though the gate approved
  }
  return signWithNonExportableKey(payload);
}

Meanwhile the gate holds no key whatsoever. It is incapable of producing a signature. That is not a policy choice you can accidentally configure away. It is a property of who holds what.

And then it gets refused

The signed request heads for the exit. The receipt is valid. The signature verifies.

And the boundary refuses it.

sequenceDiagram
    autonumber
    participant W as Agent
    participant G as Enforcement gateway
    participant R as Protected resource

    W->>G: authorized request + valid receipt
    Note right of W: something changed after approval
    G->>G: re-derive the action from the bytes that will actually leave
    G->>G: recompute the digest
    G--xW: DENIED: mismatch, fail closed
    Note over G,R: nothing leaves

Here is why, and it is the single most important line in the whole design:

The gateway does not read the digest out of the receipt. It rebuilds it from the bytes that are actually leaving.

// enforcement gateway, egress path
async function release(outgoing, receipt) {
  if (!verifySignature(receipt)) return failClosed('bad_receipt');
  if (expired(receipt))          return failClosed('expired_receipt');

  // Re-derive from the request that will actually leave, not from the receipt.
  // RFC 8785 fixes the serialization; a normative rule both sides build
  // against fixes which fields participate.
  const rebuilt = canonicalize(deriveActionFields(outgoing));

  if (sha256(rebuilt) !== receipt.digest) {
    return failClosed('digest_mismatch');   // substituted, or altered after approval
  }

  // A valid receipt is necessary, not sufficient.
  const verdict = await policy.evaluate(deriveActionFields(outgoing));
  if (!verdict.allow) return failClosed(verdict.reason);

  return forward(translateAudience(outgoing));
}

And notice failClosed on every path. Where required verification cannot be completed, the request is denied. A verifier that cannot answer is never treated as one that said yes.

Settling up

Neither direction requires trusting it. That is the point.

Here is the whole path, once, now that you know what each step is defending against:

sequenceDiagram
    autonumber
    participant W as Agent
    participant G as Enforcement gateway
    participant A as Authorization service
    participant S as Signing service
    participant R as Protected resource

    Note over W,R: DISCOVERY, no authority to spend
    W->>G: discovery pass, no authority to consume value
    G->>R: forward with a scoped downstream credential
    R-->>G: the quote
    G->>G: record the witnessed terms

    Note over W,R: AUTHORIZATION
    W->>A: request authorization
    A->>G: fetch witnessed terms, never from the request
    A->>A: capability filter, then cost
    A->>A: reserve atomically, before any attempt
    A-->>W: signed receipt, bound to the digest

    Note over W,R: SIGNING
    W->>S: request a signature
    S->>S: parse, recover parameters, enforce own constraints
    S-->>W: signature from a non-exportable key

    Note over W,R: EGRESS
    W->>G: authorized request + receipt
    G->>G: re-derive from outgoing bytes, recompute digest
    G->>G: independent policy re-evaluation
    G->>R: release, or refuse

What the stage taught us

Three things we did not fully appreciate until it was running in front of people.

The AAIF post has the full argument and the five obligations a paid tool server owes its callers.

Code is illustrative and abbreviated to the checks under discussion.

Patent pending. U.S. Provisional Application No. 64/149,249, filed 6 September 2026 (docket Y26S008-PPA). A provisional application only: no patent has been granted and no patent number is asserted.

Optimizing Performance and Cost on AWS: Strategies for Large-Scale Environments

Prakash Rao — Wed, 12 Feb 2025 13:15:07 +0000

In this post, I will walk through a series of strategies based on my experience to optimize both performance and cost in large-scale AWS environments. This will be the agenda:

Auto Scaling Configuration:

Create a launch template using a recommended instance type.
Set up an ASG with defined minimum/maximum sizes and specific scaling thresholds.
Define scaling policies and create CloudWatch alarms with real input values.

Performance Tuning of Compute Services:

Utilize AWS Compute Optimizer to identify underutilized instances and determine right-sizing opportunities.
Set up custom CloudWatch metrics to monitor application performance (e.g., request latency) and trigger alerts.

Cost Optimization Strategies:

Query detailed cost data using AWS Cost Explorer to understand spending patterns.
Combine Compute Optimizer insights with reserved and spot instance strategies for significant cost reductions.

Measurable Business Impact:

Review the impact on resource utilization, cost savings, and overall performance improvements based on these optimizations.

The goal is to give actionable, real-world inputs and concrete CLI examples to achieve measurable business impact.

Note: All commands assume that you have the AWS CLI installed and configured with the appropriate IAM permissions.

1. Auto Scaling: Fine-Tuning for Demand

Auto scaling ensures that our applications maintain optimal performance while reducing idle capacity. Below are the steps with concrete inputs.

A. Create a Launch Template with a Recommended Instance Type
Based on historical load patterns, let's choose a t3.medium instance as our baseline. If analysis via Compute Optimizer indicates underutilization, switch to a t3.small or leveraging spot instances can be considered for non-critical workloads.

Command:

aws ec2 create-launch-template \
    --launch-template-name MyWebAppTemplate \
    --version-description "v1" \
    --launch-template-data '{
      "ImageId": "ami-0abcdef1234567890",
      "InstanceType": "t3.medium",
      "KeyName": "my-key-pair",
      "SecurityGroupIds": ["sg-0123456789abcdef0"],
      "UserData": "IyEvYmluL2Jhc2gKZWNobyAiU3RhcnRpbmcgd2Vic2l0ZSBhcHAtZmxvdy4uLiIK"
    }'

Output:

{
  "LaunchTemplate": {
    "LaunchTemplateId": "lt-0123456789abcdef0",
    "LaunchTemplateName": "MyWebAppTemplate",
    "DefaultVersionNumber": 1
  }
}

B. Create an Auto Scaling Group with Specific Thresholds

Set up an ASG with a minimum size of 2 and maximum size of 10. My recommendations are:

Scale-Out: Trigger when average CPU utilization exceeds 70% for two consecutive 5‑minute periods.
Scale-In: Trigger when average CPU utilization drops below 30% for two consecutive 5‑minute periods.

Command:

aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name MyWebAppASG \
    --launch-template "LaunchTemplateId=lt-0123456789abcdef0,Version=1" \
    --min-size 2 \
    --max-size 10 \
    --desired-capacity 2 \
    --vpc-zone-identifier "subnet-12345678,subnet-87654321"

Output:

{
  "ActivityId": "abcdef12-3456-7890-abcd-ef1234567890"
}

C. Define Scaling Policies and CloudWatch Alarms with Real Inputs

Scale-Out Policy Command:

aws autoscaling put-scaling-policy \
    --auto-scaling-group-name MyWebAppASG \
    --policy-name ScaleOutPolicy \
    --scaling-adjustment 2 \
    --adjustment-type ChangeInCapacity

Output:

{
  "PolicyARN": "arn:aws:autoscaling:us-east-1:123456789012:scalingPolicy:abcdef12-3456-7890-abcd-ef1234567890:autoScalingGroupName/MyWebAppASG:policyName/ScaleOutPolicy",
  "PolicyName": "ScaleOutPolicy",
  "AdjustmentType": "ChangeInCapacity",
  "ScalingAdjustment": 2
}

CloudWatch Alarm for Scale-Out Command:

aws cloudwatch put-metric-alarm \
    --alarm-name "HighCPUAlarm" \
    --metric-name CPUUtilization \
    --namespace AWS/EC2 \
    --statistic Average \
    --period 300 \
    --threshold 70 \
    --comparison-operator GreaterThanThreshold \
    --dimensions Name=AutoScalingGroupName,Value=MyWebAppASG \
    --evaluation-periods 2 \
    --alarm-actions arn:aws:autoscaling:us-east-1:123456789012:scalingPolicy:abcdef12-3456-7890-abcd-ef1234567890:autoScalingGroupName/MyWebAppASG:policyName/ScaleOutPolicy

Pro Tip: In my deployment, fine-tuning these thresholds reduced response times by 30% during peak periods while cutting idle capacity costs by 40%.

2. Performance Tuning of Compute Services: Right-Sizing and Recommendations

A. Utilizing AWS Compute Optimizer

Command for recommendations of underutilized EC2 instances:

aws compute-optimizer get-ec2-instance-recommendations

Output:

{
  "instanceRecommendations": [
    {
      "instanceArn": "arn:aws:ec2:us-east-1:123456789012:instance/i-0123456789abcdef0",
      "instanceType": "t3.medium",
      "finding": "Overprovisioned",
      "utilizationMetrics": {
        "cpuUtilizationPercentage": 12.5,
        "memoryUtilizationPercentage": 35.0
      },
      "recommendationOptions": [
        {
          "instanceType": "t3.small",
          "projectedUtilizationMetrics": {
            "cpuUtilizationPercentage": 15.0,
            "memoryUtilizationPercentage": 40.0
          },
          "performanceRisk": "LOW"
        }
      ]
    }
  ]
}

Pro Tip: Based on these recommendations, we can resize non-critical instances from t3.medium to t3.small, resulting in a 25% reduction in compute costs without compromising performance!

B. Custom CloudWatch Metrics for Application Performance

Monitoring application metrics to further optimize performance.
For example, setting an alarm on request latency:

aws cloudwatch put-metric-alarm \
    --alarm-name "HighLatencyAlarm" \
    --metric-name RequestLatency \
    --namespace "MyApp" \
    --statistic Average \
    --period 300 \
    --threshold 200 \
    --comparison-operator GreaterThanThreshold \
    --evaluation-periods 2 \
    --alarm-actions "arn:aws:sns:us-east-1:123456789012:NotifyMe"

Suggestion: For many web applications, an average latency threshold of 200ms over a 5‑minute period is a sign of degrading performance.

3. Cost Optimization: Leveraging AWS Cost Explorer and Reserved/Spot Instances

A. Querying Monthly Cost Data with AWS Cost Explorer

Retrieve detailed cost data to gain insights into spending patterns:

aws ce get-cost-and-usage \
    --time-period Start=2025-01-01,End=2025-01-31 \
    --granularity MONTHLY \
    --metrics "UnblendedCost"

Output:

{
  "ResultsByTime": [
    {
      "TimePeriod": {
        "Start": "2025-01-01",
        "End": "2025-01-31"
      },
      "Total": {
        "UnblendedCost": {
          "Amount": "1500.00",
          "Unit": "USD"
        }
      },
      "Groups": [],
      "Estimated": false
    }
  ]
}

B. Combining Compute Optimizer with Reserved/Spot Instances

Based on the cost analysis:

We can convert underutilized on-demand instances to Reserved Instances.
Use Spot Instances for stateless or non-critical workloads.

aws ec2 describe-reserved-instances --filters Name=state,Values=active

Pro Insight:

By shifting from on-demand to reserved instances for predictable workloads and leveraging spot instances for batch processing, my env. achieved a 20% overall cost reduction over three months.

4. Measurable Business Impact

Integrating these strategies resulted in significant improvements:

Auto Scaling: Reduced average CPU utilization from 85% to 55% during peak hours.
Right-Sizing: Achieved a 25% reduction in compute costs.
Cost Optimization: Realized a 20% reduction in monthly expenses.
Performance Improvement: Lowered response times by approximately 30%, enhancing overall user experience.

5. Conclusion

Optimizing performance and cost on AWS requires a comprehensive approach that combines:

Dynamic Auto Scaling: Setting precise thresholds (70% for scale-out, 30% for scale-in) to efficiently match capacity with demand.
Performance Tuning: We can utilize AWS Compute Optimizer and custom CloudWatch metrics for right-sizing instances.
Cost Management: We can use insights from AWS Cost Explorer in combination with reserved and spot instance strategies.

By continuously monitoring and refining these parameters, we can achieve tangible improvements in our AWS deployments.

Happy optimizing! :)

Securing AWS Environments with Advanced IAM & Zero Trust

Prakash Rao — Fri, 07 Feb 2025 10:00:00 +0000

In an era where cloud security is of utmost importance, implementing a zero-trust model is essential. Zero trust means that no user or resource is trusted by default—even those within your network. In this post, I’ll demonstrate how to architect a secure AWS environment by using advanced IAM policies, AWS Organization's SCPs, and AWS Security Hub for continuous monitoring and risk mitigation. This guide includes practical CLI commands, sample outputs, and a real-world case study to illustrate the impact on security posture.

Note: All commands assume that you have the AWS CLI configured with the necessary permissions and that you’re operating in a test or development environment before applying changes in production.

1. Zero Trust and AWS

A zero-trust security model requires verification for every access request—whether the request originates from inside or outside our network. In AWS, this means:

Strict Identity Verification: Using advanced IAM policies to enforce least privilege and role-based access.
Boundary Enforcement: Using AWS Organizations and SCPs to control what actions can be performed across multiple AWS accounts.
Continuous Monitoring: Leveraging AWS Security Hub to detect, report, and remediate any deviation from security best practices.

2. Advanced IAM Policies for Least Privilege

A. Creating a Restrictive IAM Policy
One of the core elements of zero trust is ensuring that every IAM user, role, or service only has permissions necessary for their job functions. Here’s an example of an advanced IAM policy that grants read-only access to S3 buckets and CloudWatch logs—but nothing else.

IAM Policy JSON (ReadOnlyPolicy.json):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyS3",
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowReadOnlyCloudWatch",
      "Effect": "Allow",
      "Action": [
        "logs:Describe*",
        "logs:Get*",
        "logs:List*"
      ],
      "Resource": "*"
    }
  ]
}

B. Applying the Policy

Creating the policy:

aws iam create-policy --policy-name ReadOnlyPolicy --policy-document file://ReadOnlyPolicy.json

Output:

{
  "Policy": {
    "PolicyName": "ReadOnlyPolicy",
    "PolicyId": "ABCDEFGHIJKLMN123456",
    "Arn": "arn:aws:iam::123456789012:policy/ReadOnlyPolicy",
    "Path": "/",
    "DefaultVersionId": "v1",
    "AttachmentCount": 0,
    "PermissionsBoundaryUsageCount": 0,
    "IsAttachable": true,
    "CreateDate": "2025-01-15T12:00:00Z",
    "UpdateDate": "2025-01-15T12:00:00Z"
  }
}

Best Practice: We need to ensure every user or role is attached only to the policies that they require. And also we need to combine this with permission boundaries when delegating administration.

3. Enforcing Boundaries with AWS Organizations and SCPs

AWS Organizations allows us to centrally manage multiple AWS accounts. By applying SCPs, we can enforce security boundaries across all accounts.

A. Example SCP for Zero Trust
Here’s an SCP that denies the use of risky actions (for example, IAM policy modifications) unless explicitly allowed. Let's save this SCP as ZeroTrustSCP.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonApprovedIAMChanges",
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicy",
        "iam:DeletePolicy",
        "iam:AttachUserPolicy",
        "iam:DetachUserPolicy",
        "iam:AttachRolePolicy",
        "iam:DetachRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalTag/ApprovedForIAMChanges": "true"
        }
      }
    }
  ]
}

B. Attaching the SCP via CLI

Let's say we have an Organizational Unit (OU) with ID ou-1234-abcdef, for attaching the SCP:

Create Policy:

aws organizations create-policy \
  --name "ZeroTrustSCP" \
  --description "Deny risky IAM changes unless approved" \
  --type SERVICE_CONTROL_POLICY \
  --content file://ZeroTrustSCP.json

Output:

{
  "Policy": {
    "PolicySummary": {
      "Id": "p-0123456789abcdef",
      "Arn": "arn:aws:organizations::123456789012:policy/o-exampleorgid/p-0123456789abcdef",
      "Name": "ZeroTrustSCP",
      "Description": "Deny risky IAM changes unless approved",
      "Type": "SERVICE_CONTROL_POLICY",
      "AwsManaged": false
    }
  }
}

Then attach the SCP to the OU:

aws organizations attach-policy --policy-id p-0123456789abcdef --target-id ou-1234-abcdef

Best Practice: We need to regularly review and update SCPs to reflect evolving security requirements.

4. Continuous Monitoring with AWS Security Hub

AWS Security Hub aggregates security findings from various AWS services and partner tools, offering a centralized view of our security posture.

A. Enabling Security Hub

aws securityhub enable-security-hub

Output:

{
  "SecurityHubArn": "arn:aws:securityhub:us-east-1:123456789012:hub/default"
}

B. Custom Insights for Zero Trust

We can create a custom insight to monitor for any IAM policy changes that fall outside your defined boundaries. For example, track any unauthorized IAM policy attachments.

Create an Insight (using JSON conf.):

{
  "Name": "UnauthorizedIAMPolicyChanges",
  "Filters": {
    "ResourceType": [
      {
        "Value": "AwsIamPolicy",
        "Comparison": "EQUALS"
      }
    ],
    "ComplianceStatus": [
      {
        "Value": "FAILED",
        "Comparison": "EQUALS"
      }
    ]
  },
  "GroupByAttribute": "ResourceId"
}

Command to create the insight:

aws securityhub create-insight --cli-input-json file://UnauthorizedIAMPolicyChanges.json

Best Practice: Integrate Security Hub with AWS Config and CloudWatch Events for real-time alerting and automated remediation.

5. Case Study: Zero Trust Implementation in a Multi-Account Setup

Scenario

Let's say our organization manages a multi-account AWS environment through AWS Organizations. A misconfigured IAM policy in one of the development accounts resulted in overly permissive access, potentially exposing sensitive data.

Remediation Steps

Advanced IAM Policies:

a. We immediately reviewed all IAM policies and enforced our custom read-only policy.
b. Applied permission boundaries to prevent escalation.

SCP Enforcement:

a. Our ZeroTrustSCP automatically denied risky IAM changes from users lacking the “ApprovedForIAMChanges” tag.
b. We quickly identified and revoked unauthorized policy attachments.

Continuous Monitoring:

a. AWS Security Hub flagged the non-compliant IAM activity through our custom insight.
b. Automated CloudWatch Events triggered remediation scripts to alert security personnel.

Outcome

The implementation of these measures reduced the risk exposure significantly. The zero-trust model ensured that even if an account was compromised, the enforced boundaries prevented lateral movement and unauthorized changes. Regular audits and automated monitoring continue to enhance our security posture.

6. Conclusion

Implementing a zero-trust security model in AWS is not a one-time task but a continuous process. By combining advanced IAM policies, enforcing boundaries through AWS Organizations’ SCPs, and continuously monitoring with AWS Security Hub, we can create a robust security framework that mitigates risk and strengthens our cloud deployments.

Feel free to share your questions or insights in the comments below.

Happy Securing ;)

IaC Deep Dive: CloudFormation vs Terraform

Prakash Rao — Wed, 05 Feb 2025 10:00:00 +0000

In today’s enterprise IT landscape, Infrastructure as Code (IaC) is a critical component for automating deployments, managing environments, and ensuring reliability. In this post, I’ll compare two popular IaC tools—AWS CloudFormation and Terraform. By exploring real-world scenarios, code examples, best practices, and challenges in multi-environment deployments. The goal is to demonstrate how a well-architected IaC approach can speed up deployments and improve overall reliability.

Prerequisites: Make sure that AWS CLI, Terraform is installed and configured with appropriate permissions.
Note: All flowcharts are made with mermaid.live

1. Introduction

IaC enables us to manage our Infra through code rather than manual processes. In enterprises with multiple environments (dev, staging, prod), consistency, version control, and repeatability are essential. CloudFormation is AWS-native and tightly integrated with AWS services, while Terraform offers a multi-cloud approach with a rich plugin ecosystem. In this deep dive, we will see both tools side-by-side.

2. Real-World Scenario: Multi-Env. Deployments

Imagine we need to deploy a common set of resources (e.g., an S3 bucket, an IAM role, and a Lambda function) across multiple environments.

Key requirements:

Consistency: All environments must have identical infrastructure configurations.
Versioning: Infrastructure definitions should be version-controlled.
Automation: Deployments must be repeatable and automated.
Flexibility: Ability to customize settings per environment (e.g., bucket naming, logging).

3. AWS CloudFormation Deep Dive

A. Sample CloudFormation Template

Below is a simple CloudFormation YAML template that creates an S3 bucket with a parameterized name. Let's save this as cf-s3-bucket.yml:

AWSTemplateFormatVersion: '2010-09-09'
Description: >
  CloudFormation template for creating an S3 bucket with environment-specific naming.

Parameters:
  Environment:
    Type: String
    Description: "Deployment environment (dev, staging, prod)"
    AllowedValues:
      - dev
      - staging
      - prod

Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "myapp-${Environment}-bucket"
      VersioningConfiguration:
        Status: Enabled

Outputs:
  BucketName:
    Description: "Name of the created S3 bucket"
    Value: !Ref S3Bucket

B. Deploying with CloudFormation

Let's use the AWS CLI to deploy the stack:

aws cloudformation deploy \
  --template-file cf-s3-bucket.yml \
  --stack-name MyApp-S3-Stack \
  --parameter-overrides Environment=dev \
  --capabilities IAM_CAPABILITY_NAME

Output:

{
  "StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/MyApp-S3-Stack/abcdef12-3456-7890-abcd-ef1234567890"
}

After deployment, we can verify the bucket:

aws cloudformation describe-stacks --stack-name MyApp-S3-Stack \
  --query "Stacks[0].Outputs[?OutputKey=='BucketName'].OutputValue" --output text

Output:

myapp-dev-bucket

C. Best Practices & Challenges with CloudFormation

Modular Templates: Use nested stacks or include statements for large infrastructures.
Change Sets: Always review change sets before applying updates to prod.
Template Validation: Use aws cloudformation validate-template to catch errors early.
Limitations: CloudFormation can be verbose sometimes, and managing the drift across environments is challenging.

4. Terraform Deep Dive

A. Sample Terraform Configuration

Below is a Terraform configuration that creates an S3 bucket similar to our CloudFormation example. Let's save this as main.tf:

provider "aws" {
  region = "us-east-1"
}

variable "environment" {
  description = "Deployment environment (dev, staging, prod)"
  type        = string
  default     = "dev"
}

resource "aws_s3_bucket" "myapp_bucket" {
  bucket = "myapp-${var.environment}-bucket"
  versioning {
    enabled = true
  }
}

output "bucket_name" {
  value = aws_s3_bucket.myapp_bucket.bucket
}

B. Deploying with Terraform

Initialize Terraform:

terraform init

Output:

Initializing the backend...
Initializing provider plugins...
Terraform has been successfully initialized!

Plan the Deployment:

terraform plan -var="environment=dev"

Output:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create
Terraform will perform the following actions:
  + aws_s3_bucket.myapp_bucket
      bucket: "myapp-dev-bucket"
Plan: 1 to add, 0 to change, 0 to destroy.

Apply the Configuration:

terraform apply -var="environment=dev" --auto-approve

Output:

aws_s3_bucket.myapp_bucket: Creating...
aws_s3_bucket.myapp_bucket: Creation complete after 3s [id=myapp-dev-bucket]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:
bucket_name = "myapp-dev-bucket"

C. Best Practices & Challenges with Terraform

State Management: Use remote state backends (e.g., S3 with DynamoDB locking) to manage state in multi-environment deployments.
Workspaces: Leverage Terraform workspaces to isolate environments (e.g., dev, staging, prod).
Modularization: Break your configurations into reusable modules for maintainability.
Challenges: Handling state drift and managing state file locks in concurrent deployments can be complex.

5. CloudFormation vs. Terraform

	CloudFormation	Terraform
Pros	AWS-Native: Tight integration with AWS services and IAM.	Multi-Cloud Support: Manage infrastructure across AWS, Azure, GCP, and more. So Developer can get familiar with code easily with cloud-switching.
	No Additional Installation: Managed directly via AWS.	Modularity: Rich ecosystem of modules and providers.
	Drift Detection: Built-in drift detection for resources.	Plan & Apply Workflow: Clear visibility of changes before deployment.
Cons	Verbosity: Templates can become lengthy and difficult to maintain.	State Management: Requires careful handling of state files, especially in team environments.
Cons	AWS-Only: Limited to AWS environments.	Learning Curve: HCL and Terraform’s workflow can be complex for newcomers.

6. Best Practices for Multi-Env. Deployments

Parameterization & Variables: Both tools support parameterization—use variables (Terraform) or parameters (CloudFormation) to adapt resources per environment.
Modularization: Breaking down of infrastructure into smaller, reusable components is beneficial.
Version Control: Store our IaC code in a version-controlled repository.
Automated Testing: Integrating with CI/CD pipelines to validate the Infra changes.
Documentation: Maintaining clear documentation of modules, parameters, and expected outputs.

7. Important Challenges

Drift Management: In CloudFormation, resource drift can lead to inconsistencies so regular audits and change sets are critical. In Terraform, we need to ensure robust state locking and frequent state refreshes.
Complex Dependencies: Managing interdependent resources across environments requires careful planning and modular design.
Rollback Strategies: Design your stacks and modules to support smooth rollbacks in case of failures.

8. Conclusion

Both AWS CloudFormation and Terraform offer good solutions for managing infrastructure as code in complex, multi-env deployments. While CloudFormation provides deep integration with AWS, Terraform’s flexibility across multiple clouds can be a significant advantage for developers. By implementing best practices such as modularization, automated testing, and effective state management, we can achieve faster deployments and improved reliability.

Architecting Advanced CI/CD pipelines in AWS

Prakash Rao — Tue, 04 Feb 2025 01:44:02 +0000

Prakash Rao

Feb 3 '25

Advanced CI/CD Pipelines on AWS

#aws #cicd #cloud #devops

4 min read

Advanced CI/CD Pipelines on AWS

Prakash Rao — Mon, 03 Feb 2025 10:00:00 +0000

In this post, I’ll walk you through setting up an advanced CI/CD pipeline on AWS using native services and show you how to create and configure components like CodeBuild, CodeDeploy, and CodePipeline using AWS CLI commands and configuration files. I will also include outputs for each command so you can see what to expect when you run these commands yourself.

Note:

Flowchart was created using mermaid.live

Since CodeCommit is no longer onboarding new customers, choosing GitHub as the source repository. If you already have a GitHub repository for your project, simply update the configuration files accordingly.

Prerequisites: Please make sure that the AWS CLI is installed and configured with the proper IAM permissions.

1. Create a Source Repository in GitHub

First, let’s create a new GitHub repository where our source code will be there.

git init
git remote add origin https://github.com/<YOUR_GITHUB_USERNAME>/advanced-ci-cd-repo.git
git add .
git commit -m "Initial commit"
git push -u origin main

2. Set Up a CodeBuild Project

Next let's create a CodeBuild project that builds our application. In this example, we’ll use a simple Node.js project. Save the following JSON configuration as codebuild-project.json:

{
  "name": "advanced-ci-cd-build",
  "description": "Build project for advanced CI/CD pipeline demo",
  "source": {
    "type": "GITHUB",
    "location": "https://github.com/<YOUR_GITHUB_USERNAME>/advanced-ci-cd-repo"
  },
  "artifacts": {
    "type": "NO_ARTIFACTS"
  },
  "environment": {
    "type": "LINUX_CONTAINER",
    "image": "aws/codebuild/standard:6.0",
    "computeType": "BUILD_GENERAL1_MEDIUM",
    "environmentVariables": [
      {
        "name": "NODE_ENV",
        "value": "production"
      }
    ]
  },
  "serviceRole": "arn:aws:iam::<YOUR_ACCOUNT_ID>:role/CodeBuildServiceRole"
}

Create project with:

aws codebuild create-project --cli-input-json file://codebuild-project.json

Output:

{
  "project": {
    "name": "advanced-ci-cd-build",
    "arn": "arn:aws:codebuild:us-east-1:123456789012:project/advanced-ci-cd-build",
    "description": "Build project for advanced CI/CD pipeline demo",
    "source": {
      "type": "GITHUB",
      "location": "https://github.com/<YOUR_GITHUB_USERNAME>/advanced-ci-cd-repo"
    },
    "artifacts": {
      "type": "NO_ARTIFACTS"
    },
    "environment": {
      "type": "LINUX_CONTAINER",
      "image": "aws/codebuild/standard:6.0",
      "computeType": "BUILD_GENERAL1_MEDIUM",
      "environmentVariables": [
        {
          "name": "NODE_ENV",
          "value": "production"
        }
      ]
    },
    "serviceRole": "arn:aws:iam::<YOUR_ACCOUNT_ID>:role/CodeBuildServiceRole",
    "created": "2024-05-10T15:00:00Z"
  }
}

Note: Make sure CodeBuild service role has permissions for GitHub, S3 (if you use artifacts), and CloudWatch logging.

3. Define a Build Specification (`buildspec.yml`)

Create a buildspec.yml file in the root of the repository. This file instructs CodeBuild on how to run our build.

version: 0.2

phases:
  install:
    runtime-versions:
      nodejs: 16
    commands:
      - echo "Installing dependencies..."
      - npm install
  pre_build:
    commands:
      - echo "Running lint and tests..."
      - npm run lint
      - npm test
  build:
    commands:
      - echo "Building the project..."
      - npm run build
  post_build:
    commands:
      - echo "Build completed on `date`"
artifacts:
  files:
    - '**/*'
  discard-paths: yes

Push this file to the GitHub repository so CodeBuild uses it during the build process.

4. Set Up a CodeDeploy Application and Deployment Group

For blue/green deployments, we’ll use CodeDeploy.

Create a CodeDeploy Application

Command:

aws deploy create-application \
    --application-name advanced-ci-cd-app \
    --compute-platform Server

Output:

{
  "applicationId": "abcdef12-3456-7890-abcd-ef1234567890",
  "applicationName": "advanced-ci-cd-app",
  "computePlatform": "Server"
}

Create a Deployment Group
Save the following as deployment-group.json (update below values as needed):

{
  "applicationName": "advanced-ci-cd-app",
  "deploymentGroupName": "advanced-ci-cd-deploy-group",
  "deploymentConfigName": "CodeDeployDefault.OneAtATime",
  "ec2TagFilters": [
    {
      "Key": "Name",
      "Value": "MyAppServer",
      "Type": "KEY_AND_VALUE"
    }
  ],
  "serviceRoleArn": "arn:aws:iam::<YOUR_ACCOUNT_ID>:role/CodeDeployServiceRole",
  "blueGreenDeploymentConfiguration": {
    "terminateBlueInstancesOnDeploymentSuccess": {
      "action": "TERMINATE",
      "terminationWaitTimeInMinutes": 5
    },
    "deploymentReadyOption": {
      "actionOnTimeout": "CONTINUE_DEPLOYMENT"
    }
  },
  "autoRollbackConfiguration": {
    "enabled": true,
    "events": ["DEPLOYMENT_FAILURE"]
  }
}

Create Deployment group with:

aws deploy create-deployment-group --cli-input-json file://deployment-group.json

Output:

{
  "deploymentGroupId": "abcdef12-3456-7890-abcd-ef1234567890",
  "deploymentGroupName": "advanced-ci-cd-deploy-group",
  "applicationName": "advanced-ci-cd-app"
}

Note: Make sure that the CodeDeploy service role has the necessary permissions to access EC2 and execute deployment actions.

5. Create a CodePipeline

Let's put everything together by creating a pipeline that orchestrates the source, build, and deployment stages.

Save the following as pipeline.json (adjust names, regions, and bucket names as needed):

{
  "pipeline": {
    "name": "advanced-ci-cd-pipeline",
    "roleArn": "arn:aws:iam::<YOUR_ACCOUNT_ID>:role/CodePipelineServiceRole",
    "artifactStore": {
      "type": "S3",
      "location": "<YOUR_ARTIFACT_BUCKET>"
    },
    "stages": [
      {
        "name": "Source",
        "actions": [
          {
            "name": "SourceAction",
            "actionTypeId": {
              "category": "Source",
              "owner": "ThirdParty",
              "provider": "GitHub",
              "version": "1"
            },
            "outputArtifacts": [
              {
                "name": "SourceOutput"
              }
            ],
            "configuration": {
              "Owner": "<YOUR_GITHUB_USERNAME>",
              "Repo": "advanced-ci-cd-repo",
              "Branch": "main",
              "OAuthToken": "<YOUR_GITHUB_OAUTH_TOKEN>"
            },
            "runOrder": 1
          }
        ]
      },
      {
        "name": "Build",
        "actions": [
          {
            "name": "BuildAction",
            "actionTypeId": {
              "category": "Build",
              "owner": "AWS",
              "provider": "CodeBuild",
              "version": "1"
            },
            "inputArtifacts": [
              {
                "name": "SourceOutput"
              }
            ],
            "outputArtifacts": [
              {
                "name": "BuildOutput"
              }
            ],
            "configuration": {
              "ProjectName": "advanced-ci-cd-build"
            },
            "runOrder": 1
          }
        ]
      },
      {
        "name": "Deploy",
        "actions": [
          {
            "name": "DeployAction",
            "actionTypeId": {
              "category": "Deploy",
              "owner": "AWS",
              "provider": "CodeDeploy",
              "version": "1"
            },
            "inputArtifacts": [
              {
                "name": "BuildOutput"
              }
            ],
            "configuration": {
              "ApplicationName": "advanced-ci-cd-app",
              "DeploymentGroupName": "advanced-ci-cd-deploy-group"
            },
            "runOrder": 1
          }
        ]
      }
    ],
    "version": 1
  }
}

Create pipeline with:

aws codepipeline create-pipeline --cli-input-json file://pipeline.json

Output:

{
  "pipeline": {
    "name": "advanced-ci-cd-pipeline",
    "version": 1,
    "artifactStore": {
      "type": "S3",
      "location": "my-artifact-bucket"
    },
    "stages": [
      {
        "name": "Source",
        "actions": [ { ..... } ]
      },
      {
        "name": "Build",
        "actions": [ { ..... } ]
      },
      {
        "name": "Deploy",
        "actions": [ { ..... } ]
      }
    ]
  },
  "created": "2024-05-10T15:30:00Z"
}

6. Testing and Monitoring the Pipeline

After creating the pipeline, trigger a test execution by pushing a commit to your GitHub repository. Then, check the pipeline status with:

aws codepipeline get-pipeline-execution --pipeline-name advanced-ci-cd-pipeline --pipeline-execution-id <execution-id>

Output:

{
  "pipelineExecution": {
    "pipelineName": "advanced-ci-cd-pipeline",
    "pipelineExecutionId": "12345678-1234-1234-1234-123456789012",
    "status": "Succeeded",
    "artifactRevisions": [ ..... ],
    "startTime": "2024-05-10T15:31:00Z",
    "lastUpdateTime": "2024-05-10T15:33:00Z"
  }
}

Additionally, we can set up CloudWatch dashboards and alarms to monitor key metrics such as build duration and deployment status.

Conclusion

In this blog I demonstrated how we can build an advanced CI/CD pipeline on AWS using CLI commands and configuration files. By integrating GitHub, CodeBuild, CodeDeploy (with blue/green deployments), and CodePipeline, we created a fully automated workflow.

Happy Deploying! :)

Building Serverless Applications with AWS Lambda and integrating with DynamoDB

Prakash Rao — Sat, 01 Feb 2025 03:22:50 +0000

Agenda

1.Introduction

What is serverless architecture?

2.Setting Up the Project

Creating a Lambda function with AWS CLI.
Creating an API Gateway to trigger Lambda.

3.Building the Application

Creating a simple RESTful API with AWS Lambda and API Gateway.
Integrating the API with DynamoDB to store data.

4.Testing the Application

Invoking the Lambda function using AWS CLI.
Testing the API endpoint using Postman or Curl.

5.Deploying the Application

Deploying the API to a production stage.

6.Conclusion

Summing up the steps and benefits of using AWS Lambda.
Further enhancements and scalability options.

What is serverless architecture?

Serverless architecture is not something new and has gained massive popularity for its ability to simplify development, reduce operational costs, and increase scalability. AWS Lambda, Amazon’s serverless compute service, plays a central role in this movement. With AWS Lambda, developers can run their code in response to events without having to provision or manage servers, making it easier to focus on the logic rather than infrastructure. This guide will show you how to build a complete serverless application using AWS Lambda and other AWS services like API Gateway and DynamoDB.

Setting Up the Project

Step 1: Create a Lambda Function with AWS CLI
Let's first create the Lambda function that will execute our serverless logic. Use the AWS CLI to create the Lambda function:

aws lambda create-function \
  --function-name MyLambdaFunction \
  --runtime python3.8 \
  --role arn:aws:iam::your-account-id:role/execution-role \
  --handler lambda_function.lambda_handler \
  --zip-file fileb://my-deployment-package.zip

Here, the Lambda function is written in Python, and we’ll upload the code in a ZIP file. We need to ensure that the execution-role has the necessary permissions to execute the function.

Step 2: Create an API Gateway to Trigger Lambda
Next, let's set up an API Gateway to trigger our Lambda function when an HTTP request is made. We can create a REST API using the following AWS CLI command:

aws apigateway create-rest-api \
  --name "MyAPI" \
  --description "API for serverless Lambda" \
  --endpoint-configuration types=REGIONAL

Once the API is created, let's make a note of the API ID provided in the response.

Building the Application

Step 3: Create a Resource for the API
Now, we need to create a resource, such as /items, that will handle the HTTP request.

API_ID=<api-id-which-we-got-earlier>
aws apigateway create-resource \
  --rest-api-id $API_ID \
  --parent-id $(aws apigateway get-resources --rest-api-id $API_ID --query 'items[0].id' --output text) \
  --path-part "items"

Step 4: Define a POST Method for the Resource
After creating the resource, let's define a POST method that will trigger our Lambda function when a request is made:

aws apigateway put-method \
  --rest-api-id $API_ID \
  --resource-id <resource-id> \
  --http-method POST \
  --authorization-type NONE

Next, let's integrate the POST method with the Lambda function:

aws apigateway put-integration \
  --rest-api-id $API_ID \
  --resource-id <resource-id> \
  --http-method POST \
  --integration-http-method POST \
  --type AWS_PROXY \
  --uri arn:aws:apigateway:<region>:lambda:path/2015-03-31/functions/arn:aws:lambda:<region>:<account-id>:function:MyLambdaFunction/invocations

Step 5: Set Up DynamoDB Integration
Now to store incoming data in DynamoDB we need to create a DynamoDB table:

aws dynamodb create-table \
  --table-name MyTable \
  --attribute-definitions AttributeName=id,AttributeType=S AttributeName=name,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

Then, update the Lambda function code to interact with DynamoDB, adding items to the table. Afterward, update the Lambda function code using:

aws lambda update-function-code \
  --function-name MyLambdaFunction \
  --zip-file fileb://my-updated-deployment-package.zip

Testing the Application

Step 6: Invoke the Lambda Function
Once everything is set up, we can test the Lambda function directly using AWS CLI. For example, to add an item to DynamoDB, we can run:

aws lambda invoke \
  --function-name MyLambdaFunction \
  --payload '{"id": "123", "name": "Sample"}' \
  output.txt

Step 7: Test the API Endpoint
Use Curl to test the API. For instance, we can test the /items endpoint by sending a POST request with the relevant data:

curl -X POST -d '{"id": "123", "name": "Sample"}' https://<api-id>.execute-api.<region>.amazonaws.com/dev/items

Deploying the Application

Step 8: Deploy the API
Once everything is locally tested, we can deploy the API to a production stage by following command:

aws apigateway create-deployment \
  --rest-api-id $API_ID \
  --stage-name prod

This will deploy the API to the prod stage, and we'll receive a public URL that we can use to interact with the Lambda function via the API.

Conclusion

AWS Lambda allows us to build serverless applications that scale effortlessly, without the need to manage infrastructure. By using the AWS CLI, we streamlined the process of creating and managing Lambda functions, API Gateway resources, and integrating with DynamoDB. This approach makes it possible to quickly deploy a scalable and cost-effective application that responds to events in real time.

Building Your First AWS VPC with Public and Private Subnets

Prakash Rao — Mon, 16 Sep 2024 16:50:43 +0000

Welcome to a comprehensive guide on setting up a Virtual Private Cloud (VPC) with public and private subnets in AWS. This tutorial is designed for individuals looking to understand and implement the basic network architecture within AWS to support various applications securely and robustly.

First things first, lets start with a brief introduction.

What is a VPC?

A Virtual Private Cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud. Within a VPC, you can define your own IP address range, create subnets, configure route tables, and network gateways, providing flexibility as well as security.

Public vs. Private Subnets

Public Subnet:
These are subnets with a route to the Internet through an Internet Gateway (IGW), making them accessible from the Internet. They are typically used to host external-facing resources, like web servers.
Private Subnet:
These subnets do not have a direct route to the Internet and are used for backend systems that should not be directly accessed from the outside world.

Internet Gateway (IGW)
An Internet Gateway is a VPC component that allows communication between your VPC and the Internet. Attaching an IGW to VPC is essential for public subnet to communicate with the Internet.

In this tutorial, we will walk through the process of setting up this network structure using both the AWS Management Console and the AWS CLI. This dual approach helps illustrate the underlying processes and allows you to choose the method that best fits your working style.

Using the AWS Management Console

We'll start by demonstrating each step with the AWS Management Console, providing screenshots to guide you through each part of the process. This method is especially helpful for those who prefer a visual interface and are newer to AWS.

First type VPC, in the search box and select it.

then select create VPC

Select VPC and more. Previously it used to be only VPC, but with this option we can create subnets, IGW within the same configuration

choose a CIDR range
choose no. of AZs, the public and private subnet changes automatically based on this but you can manually select as well.

In the side preview you can see what resources are going to be created.

Leave the remaining options default and select "create VPC" button at the bottom

It will start creating the resources based on selection
after few seconds, your VPC will be created.

After you select the view VPC, you can see the resource map

Using the AWS CLI

Following that, we will replicate the setup using the AWS CLI, which is ideal for those who prefer script-based configurations or need to automate their setup processes.

Create the VPC First, create a VPC with a 10.1.0.0/16 CIDR block:

aws ec2 create-vpc --cidr-block 10.1.0.0/16

This command returns a VPC ID, which we will use in subsequent steps. Let's assume it returns vpc-0a1b2c3d4e5f67890.

Create the Subnets Next, create the public and private subnets within this VPC.

Public Subnet:

aws ec2 create-subnet --vpc-id vpc-0a1b2c3d4e5f67890 --cidr-block 10.1.1.0/24 --availability-zone us-east-1a

This command returns a Subnet ID for the public subnet, assume it’s subnet-1234567890abcdef0.

Private Subnet:

aws ec2 create-subnet --vpc-id vpc-0a1b2c3d4e5f67890 --cidr-block 10.1.2.0/24 --availability-zone us-east-1a

Assume the returned Subnet ID for the private subnet is subnet-0987654321fedcba0.

Create an Internet Gateway Create an Internet Gateway and attach it to your VPC:

aws ec2 create-internet-gateway

This command returns an Internet Gateway ID, let's say it's igw-0123456789abcdef0.

Attach the Internet Gateway to the VPC:

aws ec2 attach-internet-gateway --vpc-id vpc-0a1b2c3d4e5f67890 --internet-gateway-id igw-0123456789abcdef0

Configure Route Tables Create a route table for the public subnet and configure it to route traffic to the Internet Gateway.

aws ec2 create-route-table --vpc-id vpc-0a1b2c3d4e5f67890

Assume the returned Route Table ID is rtb-02468acefdb97531.

Create Route to Internet Gateway:

aws ec2 create-route --route-table-id rtb-02468acefdb97531 --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0123456789abcdef0

Associate the Route Table with the Public Subnet:

aws ec2 associate-route-table --subnet-id subnet-1234567890abcdef0 --route-table-id rtb-02468acefdb97531

For the private subnet, we do not need to route traffic to the Internet Gateway, but we may want to create a separate route table if required for specific network rules or future modifications.

Conclusion
These CLI commands and console process will create a VPC with a public and private subnet setup, where the public subnet has internet access via an Internet Gateway. This setup is fundamental for many applications and services hosted on AWS.
This post will be extremely beneficial for those new to AWS and those needing a refresher on setting up a VPC properly :)

SAP NetWeaver Migration from On-Prem to AWS

Prakash Rao — Sat, 31 Aug 2024 16:24:13 +0000

This post provides the necessary documentation for migrating a simulated deployment of SAP NetWeaver OnPrem (simulated) to a different AWS environment.

Overview

The migration process involves the following high-level steps:

Launch an EC2 instance and install SAP NetWeaver on it.
Create a simulation as in on-prem, the SAP NetWeaver deployment in the AWS environment.
Convert the EC2 instance into an OVA file and store it in Amazon S3.
Create an Amazon Machine Image (AMI) and EBS snapshot.
Launch a new EC2 instance from the AMI and EBS snapshot in the new AWS environment.

Prerequisites

Before you can begin the migration process, you will need to have the following:

An AWS account with sufficient privileges to create and manage the necessary resources.
Access to the AWS Management Console and AWS CLI.
Familiarity with AWS services and concepts such as EC2, S3, and VPC.

Migration Process

Step 1,2: Launch an EC2 instance and install SAP NetWeaver on it

Launch an EC2 instance in the AWS environment and install SAP NetWeaver on it. Ensure that the instance is properly configured and that SAP NetWeaver is running correctly.

Now, let's install the necessary packages require for the SAP:

sudo apt-get install libaio1
sudo apt-get install csh
sudo apt install libc6
sudo apt-get install uuid
sudo service uuidd start
sudo update-locale LANG=”en_US.UTF-8"

For setting up VNC:

sudo apt update && sudo apt upgrade
sudo sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
sudo /etc/init.d/ssh restart
sudo passwd ubuntu
sudo apt install xrdp xfce4 xfce4-goodies tightvncserver
echo xfce4-session> /home/ubuntu/.xsession
sudo cp /home/ubuntu/.xsession /etc/skel
sudo sed -i '0,/-1/s//ask-1/' /etc/xrdp/xrdp.ini
sudo service xrdp restart
tightvncserver

For downloading the SAP netweaver let's install firefox:

sudo add-apt-repository ppa:ubuntu-mozilla-security/ppa
sudo apt-get update
sudo apt-get install firefox

Now let's edit system configuration needed for SAP:

Update Hostname
sudo vim /etc/hostname

Check the IP Address
sudo ip addr show
sudo vim /etc/hosts
sudo cat /etc/hosts


Check Hosts and Hostname
sudo cat /etc/hosts
sudo cat /etc/hostname

Restart System after changes and validate the changes
sudo reboot

Now the installation of netWeaver is completed, let's install SAP frontend GUI to access the netweaver.

Let's add a new connection

Give the connection a name, and add the public ip address assigned to the SAP and save it.

Now add the credentials, generally if it is developer ABAP SPO2 7.52 version, the default details are
Client: 001
username: SAP*
password: Appl1ance

Now, let's add a user, type SU01 in the searchbox, Select create user

Now the user is created.

we'll use this created user to login to SAP now

Now we're logged in as created user.

Step 3: Convert the EC2 instance into an OVA file and store it in Amazon S3

Use the AWS CLI to convert the EC2 instance into an OVA file and store it in Amazon S3. Ensure that the OVA file is stored in a secure and accessible location.

for this step if we want to convert manually to let's say to VMware platform we can use below cli to convert format and export it.
https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html

But in my case to make it easier, I am just creating image from the current VM in next step utilizing AWS automation to reduce manual overhead.

Step 4: Create an Amazon Machine Image (AMI) and EBS snapshot

Ensure that the AMI and EBS snapshot are properly configured and tagged for easy identification.

Wait until the AMI becomes available, it will take a while.

Step 5: Launch a new EC2 instance from the AMI and EBS snapshot in the new AWS environment

Now, let's Launch a new EC2 instance from the AMI and EBS snapshot in the new AWS environment with same config as previous instance.

wait until it comes to active status

Now note down the new public ip of the migrated instance

Now let's create a new connection to the new instance with the noted ip address.

Now instead of default login credentials, let's use the user and it's credentials we created to check if the migrated VM is same as the previous VM.

Now we Ensured that the instance is properly configured and that SAP NetWeaver is running correctly.

Step 6: Cleanup

Now to reduce any further costs, delete the EC2 instances launched, deregister AMI and delete the snapshot.

Database Migration from OnPrem to AWS RDS

Prakash Rao — Sat, 31 Aug 2024 16:10:25 +0000

This project provides a step-by-step guide on how to migrate a WordPress website and MariaDB database from on-premises to AWS, using peering connections and AWS services such as EC2, RDS, and DMS. The guide covers setting up the simulated environment, creating VPC and peering connection, launching instances, setting up DMS replication, and testing..

Installation

To use this project, you need to have the following:

A simulated AWS on-prem env with a WordPress website and MariaDB database.
An AWS account with access to EC2, RDS, and DMS.

The guide covers the following steps:

Assuming a simulated on-premises environment on AWS with a WordPress website and MariaDB database are already setup.
Create an AWS VPC and peering connection between the on-premises (simulated) environment and the AWS VPC.
Launch an EC2 instance in the AWS VPC and configure it as the new webserver for the WordPress website.
Launch an RDS instance in the AWS VPC and configure it as the new database server for the MariaDB database.
Set up DMS replication instance between the on-premises MariaDB database and the AWS RDS instance and start replicating.
Test the migrated WordPress website by modifying the wordpress file where the ip is pointed to on-prem to DNS of MariaDB database.
As a cleanup delete the instances, peering connection, DMS replication instance, RDS, EC2, etc.

CleanUp:

At the end as a cleanup delete the instances, peering connection, DMS replication instance, RDS, EC2, etc.

Deploying a "Hello World" Application to AWS Elastic Beanstalk

Prakash Rao — Mon, 17 Jun 2024 23:36:11 +0000

Introduction
AWS Elastic Beanstalk as an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS. This post will demonstrate how to deploy your application in AWS Elastic Beanstalk.

Prerequisites

AWS account
Basic knowledge of web application development
Familiarity with AWS services is helpful but not required

Step 1: Creating a Simple Web Application

Initial Setup

Choose a programming language and framework. For this example, let's use Python with Flask.
Create a new directory for your project and navigate into it.
Initialize a new Python virtual environment and activate it (optional but recommended).

Application Code

Create a file named application.py and add the following Flask application code:

from flask import Flask

application = Flask(__name__)

@application.route('/')
def hello_world():
    return 'Hello, World!'

if __name__ == '__main__':
    application.run()

Create a requirements.txt file specifying Flask:

Flask==1.1.2

Local Testing (Optional)

Run the application locally to ensure it works.
Open a browser and navigate to http://localhost:5000 to see the "Hello, World!" message.

Step 2: Preparing the Application for Deployment

Zip the application.py and requirements.txt files together.

zip myapp.zip application.py requirements.txt

Step 3: Creating an Elastic Beanstalk Environment

Log in to the AWS Management Console.
Navigate to the Elastic Beanstalk service and click "Create New Application".
Enter an application name and description.
Create a new environment within this application – choose the Web server environment.

Select the Python platform and choose the appropriate version.

Step 4: Uploading and Deploying the Application

When prompted to upload your code, choose the "Upload your code" option and upload the myapp.zip file.

Configure more options if needed, or simply click "Create environment".

Step 5: Configuring Service Access

For Elastic Beanstalk selecting role is crucial. For this lab purpose let's chose existing service role and existing EC2 instance profile.

Step 6: Environment Configuration and Launch

For rest of the optional parameters, keep it as is.

AWS Elastic Beanstalk will now create your environment and deploy the application.

This process might take a few minutes.

Step 7: Accessing the Deployed Application

Once the environment is ready, click the provided URL to access your application.

You should see the "Hello, World!" message served from AWS Elastic Beanstalk.

Step 8: Clean Up

To avoid incurring charges, delete the Elastic Beanstalk environment and application.

Conclusion

Congratulations! You've just taken a significant step into the world of web application deployment using AWS Elastic Beanstalk. By following the steps outlined in this post, you have learned how to deploy a "Hello World" application.

As you become more comfortable with AWS Elastic Beanstalk, I encourage you to explore its advanced features, experiment with different configurations, and consider how you can integrate other AWS services to enhance your application's functionality and performance.

Now that you have the basics down, the sky is the limit. Keep learning, keep experimenting, and most importantly, have fun building!

Additional Resources

To further your knowledge and skills in AWS Elastic Beanstalk and related AWS services, here are some additional resources you may find useful:

AWS Elastic Beanstalk Developer Guide: The official Elastic Beanstalk documentation provides detailed information on how to use and configure the service.
AWS Elastic Beanstalk Sample Applications: Explore sample applications provided by AWS that you can deploy and study.
AWS Training and Certification: AWS offers various training courses and certifications that can help you deepen your understanding of AWS services.
AWS Developer Forums: Elastic Beanstalk: Join the community forum to ask questions, share experiences, and get insights from other AWS developers.
Flask Documentation: The official documentation for Flask is an excellent resource for learning more about building web applications with this micro web framework.

DEV Community: Prakash Rao

x402 + MCP: where does the budget check go?

First, the catch-up

The cast

The agent goes shopping

Someone has to approve it

The signer that can still say no

And then it gets refused

Settling up

What the stage taught us

x402 + MCP: where does the budget check go?

First, the catch-up

The cast

The agent goes shopping

Someone has to approve it

The signer that can still say no

And then it gets refused

Settling up

What the stage taught us

Optimizing Performance and Cost on AWS: Strategies for Large-Scale Environments

1. Auto Scaling: Fine-Tuning for Demand

2. Performance Tuning of Compute Services: Right-Sizing and Recommendations

3. Cost Optimization: Leveraging AWS Cost Explorer and Reserved/Spot Instances

4. Measurable Business Impact

5. Conclusion

Securing AWS Environments with Advanced IAM & Zero Trust

1. Zero Trust and AWS

2. Advanced IAM Policies for Least Privilege

3. Enforcing Boundaries with AWS Organizations and SCPs

4. Continuous Monitoring with AWS Security Hub

5. Case Study: Zero Trust Implementation in a Multi-Account Setup

6. Conclusion

IaC Deep Dive: CloudFormation vs Terraform

1. Introduction

2. Real-World Scenario: Multi-Env. Deployments

3. AWS CloudFormation Deep Dive

4. Terraform Deep Dive

C. Best Practices & Challenges with Terraform

5. CloudFormation vs. Terraform

6. Best Practices for Multi-Env. Deployments

7. Important Challenges

8. Conclusion

Architecting Advanced CI/CD pipelines in AWS

Advanced CI/CD Pipelines on AWS

Advanced CI/CD Pipelines on AWS

1. Create a Source Repository in GitHub

2. Set Up a CodeBuild Project

3. Define a Build Specification (buildspec.yml)

4. Set Up a CodeDeploy Application and Deployment Group

5. Create a CodePipeline

6. Testing and Monitoring the Pipeline

Conclusion

Building Serverless Applications with AWS Lambda and integrating with DynamoDB

Agenda

What is serverless architecture?

Setting Up the Project

Building the Application

Testing the Application

Deploying the Application

Conclusion

Building Your First AWS VPC with Public and Private Subnets

Using the AWS Management Console

Using the AWS CLI

SAP NetWeaver Migration from On-Prem to AWS

Overview

Prerequisites

Migration Process

Step 1,2: Launch an EC2 instance and install SAP NetWeaver on it

Step 3: Convert the EC2 instance into an OVA file and store it in Amazon S3

Step 4: Create an Amazon Machine Image (AMI) and EBS snapshot

Step 5: Launch a new EC2 instance from the AMI and EBS snapshot in the new AWS environment

Step 6: Cleanup

Database Migration from OnPrem to AWS RDS

Installation

The guide covers the following steps:

CleanUp:

Deploying a "Hello World" Application to AWS Elastic Beanstalk

Step 1: Creating a Simple Web Application

Step 2: Preparing the Application for Deployment

Step 3: Creating an Elastic Beanstalk Environment

3. Define a Build Specification (`buildspec.yml`)